After working around the problem in bug #464037, I still have problems getting the OpenSSL TPM engine to work... Starting program: /usr/bin/openssl s_client -connect vpntest:332 -cert /home/dwmw2/cert.pem -key /home/dwmw2/cert.pem -keyform engine -engine tpm -crlf [Thread debugging using libthread_db enabled] [New Thread 0x7f68fa0247a0 (LWP 28806)] engine "tpm" set. SRK authorization: Program received signal SIGSEGV, Segmentation fault. 0x0000003728883b7f in memcpy () from /lib64/libc.so.6 (gdb) bt #0 0x0000003728883b7f in memcpy () from /lib64/libc.so.6 #1 0x00000000008c3442 in Trspi_UnloadBlob (offset=0x7fff02043610, size=1819239265, from=0x0, to=0x5fdc <Address 0x5fdc out of bounds>) at /usr/include/bits/string3.h:52 #2 0x00000000008c58f1 in Trspi_UnloadBlob_KEY_PARMS (offset=0x7fff02043610, blob=0x7fff02043720 "Bag Attributes\n localKeyID: 01 00 00 00 \n Microsoft CSP Name: Microsoft Enhanced Cryptographic Provider v1.0\n friendlyName: 4b158d80b5c95de9bdfbae54ed0877ed_4cd35c06-4849-425c-9237-bc97ca4385"..., keyParms=0x7fff020435b0) at trousers.c:528 #3 0x00000000008c665b in Trspi_UnloadBlob_KEY (offset=0x7fff02043610, blob=0x7fff02043720 "Bag Attributes\n localKeyID: 01 00 00 00 \n Microsoft CSP Name: Microsoft Enhanced Cryptographic Provider v1.0\n friendlyName: 4b158d80b5c95de9bdfbae54ed0877ed_4cd35c06-4849-425c-9237-bc97ca4385"..., key=0x7fff020435a0) at trousers.c:623 #4 0x00000000008b0749 in UnloadBlob_TSS_KEY (offset=0x7fff02043610, blob=0x7fff02043720 "Bag Attributes\n localKeyID: 01 00 00 00 \n Microsoft CSP Name: Microsoft Enhanced Cryptographic Provider v1.0\n friendlyName: 4b158d80b5c95de9bdfbae54ed0877ed_4cd35c06-4849-425c-9237-bc97ca4385"..., key=0x7fff020435a0) at tsp_key.c:64 #5 0x00000000008a42a3 in Tspi_Context_LoadKeyByBlob (tspContext=3221225473, hUnwrappingKey=3221225477, ulBlobLength=4096, rgbBlobData=0x7fff02043720 "Bag Attributes\n localKeyID: 01 00 00 00 \n Microsoft CSP Name: Microsoft Enhanced Cryptographic Provider v1.0\n friend---Type <return> to continue, or q <return> to quit--- lyName: 4b158d80b5c95de9bdfbae54ed0877ed_4cd35c06-4849-425c-9237-bc97ca4385"..., phKey=0x7fff02044720) at tspi_key.c:457 #6 0x0000000000113653 in tpm_engine_load_key () from /usr/lib64/openssl/engines/libtpm.so #7 0x0000003732c9ffc8 in ENGINE_load_private_key () from /lib64/libcrypto.so.7
In Trspi_UnloadBlob_KEY_PARMS(), keyParms->parmSize seems to be set to a very large number. When I enter the function, it's set to 0x48dc1426. After the call to Trspi_UnloadBlob_UINT32(offset, &keyParms->parmSize, blob); it gets set to 0x6c6f6361. On this machine, a malloc of that size succeeds, and we then try an insanely-large memcpy.
Oh, running it with -cert test.key instead of pointing it at a text PEM file makes it stop segfaulting. It's just not doing _any_ validation on its input. Still a little confused... I can use 'create_tpm_key' to put a key into the TPM, but I'm still left with a key on my file system. Isn't that supposed to be in the TPM, while I only have the certificate on the file system?
Hi David, We are still investigating the first issue. About the second question, your key isn't in a plain form on your filesystem, it's wrapped by another one in a way you'll always need a key located inside the TPM in order to decrypt the ones stored out of it.
OK, thanks. By the 'first issue' do you mean the segfault in context_free(). That's purely a libselinux bug (bug #464037) -- it's polluting the namespace, and you're calling _its_ function when you mean to call your own. You can work around the bug by renaming your context_free() function. What I'm trying to do is just the equivalent of curl_easy_setopt(curl, CURPOPT_SSLCERT, "/home/dwmw2/cert.pem"); ...except that obviously I want the key to be stored in the TPM. Is that possible?
OK, now I think I have my application working, at least using TPM-emulator. I applied the following patches to Trousers: http://david.woodhou.se/trousers-0.3.1-workaround-selinux-namespace-pollution.patch http://david.woodhou.se/trousers-0.3.1-use-tpm-emu.patch http://david.woodhou.se/trousers-0.3.1-reuseaddr.patch I also applied this patch to the openssl TPM engine from CVS, so that it would let me wrap an existing certificate rather than failing: http://david.woodhou.se/tpmengine-fix-wrap.patch I think I can now use my VPN client to connect using the certificate in the TPM: http://git.infradead.org/users/dwmw2/anyconnect.git?a=commitdiff;h=d460790a Now, it seems that I'm limited to having the 'key' and the certificate in separate files. Is there any way to store them in the same PEM file? And please can we have the openssl TPM engine shipped in Fedora?
Thanks for the patches regarding the namespace conflict and the miss of -w option, I'll commit the fixes. The only pending question here is the one regarding the key storage. The method used in create_tpm_key is, as we see, storing it in the filesystem, encrypted so it cannot be directly read. To avoid cryptanalysis, one can use the persistent storage inside the chip, by registering the key with an id (UUID) inside it, and loading it later, as done with the SRK key, using that id. This second method isn't available in create_tpm_key.c, but it's possible to be implemented using the TSS functions. Regarding shipping it in Fedora, sure, if you need anything else from me to make the request accomplished, please let me know.
For bonus points, we should have something like the ---BEGIN TSS KEY BLOB--- part in the PEM file, which can contain _either_ a UUID or the encrypted blob. In the absence of that, how would I go about using the engine with a key stored inside the chip? Or listing the keys which are stored there? Under Windows, a 3-year client certificate for our VPN has been stored in the chip. It would be nice to be able to use that under Linux instead of the 2-day certificates they're currently giving us for testing purposes. :) Strangely, key access in Windows only works if the TPM is marked as _disabled_ in the BIOS. (Thinkpad T61)
Making Rajiv the owner on our end.
(In reply to comment #7) > ------- Comment From dwmw2 2008-10-01 11:37:32 EDT------- > For bonus points, we should have something like the ---BEGIN TSS KEY BLOB--- > part in the PEM file, which can contain _either_ a UUID or the encrypted blob. > But, I can't see what are the disadvantages of using (in this context) a wrapped key instead of a key inside the tpm, if you can have virtually unlimited space available in the host machine? > In the absence of that, how would I go about using the engine with a key stored > inside the chip? Or listing the keys which are stored there? Without this, from what I know, it's impossible. To list the keys inside the tpm, you could use ps_inspect to parse your /var/lib/tpm/system.data > > Under Windows, a 3-year client certificate for our VPN has been stored in the > chip. It would be nice to be able to use that under Linux instead of the 2-day > certificates they're currently giving us for testing purposes. :) I'll check this out. > > Strangely, key access in Windows only works if the TPM is marked as _disabled_ > in the BIOS. (Thinkpad T61) > In Windows, as far as I know, there isn't a TSS compliant API implemented, but a TBS. It provides a limited set of resources, like key slots, authentication slots, so that it's possible to manage keys with it, but not necessarily take profit of its trusted computing capabilities. Since this API is more like an core interface to the device, I assume it only counts on TPM commands that doesn't require an owner flag set, so can be used when disabled. I cannot assure there isn't a TSS compliant API implemented "now", it's just what I last read about Windows status on TC. :-) David's patch that fix this is already upstream.
Created attachment 323791 [details] Upstream patch
Did we ship Fedora 10 with this still broken?
Looks like we did. I've committed the fix and built packages for F-10 and rawhide. If you approve, please push the F-10 update and also build for F-9.
(In reply to comment #12) > Looks like we did. I've committed the fix and built packages for F-10 and > rawhide. > > If you approve, please push the F-10 update and also build for F-9. ...will do that.
P.S: David, if you'd like to comaintain the package, you're welcome of course!
trousers-0.3.1-10.fc9 has been submitted as an update for Fedora 9. http://admin.fedoraproject.org/updates/trousers-0.3.1-10.fc9
trousers-0.3.1-14.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/trousers-0.3.1-14.fc10
trousers-0.3.1-14.fc10 has been pushed to the Fedora 10 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update trousers'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-4999
trousers-0.3.1-10.fc9 has been pushed to the Fedora 9 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing-newkey update trousers'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2009-5029
This message is a reminder that Fedora 9 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 9. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '9'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 9's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 9 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
trousers-0.3.1-10.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.
trousers-0.3.1-14.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.