<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">> - (ii) They need to discover which slot holds the TPM token (if any)<br>
<span style="font-family:arial,sans-serif;font-size:13px">We could use a PKCS#11 URIs for this. Is this a TPM specific problem?<br></span><span style="font-family:arial,sans-serif;font-size:13px">Usually callers (ie: crypto libraries) look through all available slots<br>
</span><span style="font-family:arial,sans-serif;font-size:13px">for keys which apply. But the TPM use case may be different. Could you<br></span><span style="font-family:arial,sans-serif;font-size:13px">elaborate on it?</span></blockquote>
<div class="gmail_extra"><br></div><div class="gmail_extra">As below, I was more thinking about the case where the app (e.g., ssh-keygen) want's to store a key with certain security properties. This probably isn't as big of an issue as simply accessing the keys on the TPM sanely though. </div>
<div class="gmail_extra"><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-family:arial,sans-serif;font-size:13px">Yes, prompting is a sore point of using PKCS#11 modules. I'm working on<br>
</span><span style="font-family:arial,sans-serif;font-size:13px">a feature in p11-kit which allows prompting to be done by an agent.</span><br style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:arial,sans-serif;font-size:13px">This overrides the C_Login and related calls, and changes its behavior<br>
</span><span style="font-family:arial,sans-serif;font-size:13px">to that of CKF_PROTECTED_AUTHENTICATION_</span><span style="font-family:arial,sans-serif;font-size:13px">PATH. This indicates to the<br></span><span style="font-family:arial,sans-serif;font-size:13px">caller of the module that it does not need to prompt for a PIN but rely<br>
</span><span style="font-family:arial,sans-serif;font-size:13px">on the module to do the prompting. p11-kit intercepts the call and does<br></span><span style="font-family:arial,sans-serif;font-size:13px">the prompting (calling into the GUI) and then passes the prompted PIN<br>
</span><span style="font-family:arial,sans-serif;font-size:13px">into the underlying module.</span></blockquote><div><br></div><div>This should be a good improvement from the app developers side (at least for GUI programs - how would this work with command-line tools?), although it still relies on the users knowing what the pin is for their TPM device (and even knowing what it means when they get a pop-up stating "Enter pin for TPM device"). It seems to me that it would be better to have Linux distros setup the TPM with a SRK / user-pin which is known or can be derived by (or stored in) p11-kit or gnome-keyring - that way, p11-kit (using managed modules) can be in charge of locking-unlocking the TPM based upon it's own knowledge of whether the user is logged in or not, or requires additional password prompting. I'm not sure how this would work, and might end up being quite OpenCryptoKI specific, but it might be worth a go</div>
<div><div><br></div><div>I agreed with Nikolas that the internals of OpenCryptoKI are really complex complex, but I still think it would be nice to have a single interface to a users credentials for all apps, and PKCS#11 could provide that. One other thing I have been looking at is the Chaps library which is part of ChromeOS:</div>
<div> <a href="http://www.chromium.org/developers/design-documents/chaps-technical-design">http://www.chromium.org/developers/design-documents/chaps-technical-design</a></div><div> <a href="http://git.chromium.org/gitweb/?p=chromiumos/platform/chaps.git;a=summary" style="color:rgb(85,26,139);font-size:13px;outline:none;font-family:Arial,Verdana,sans-serif"><span style="font-size:15px;font-family:Arial;color:rgb(17,85,204);background-color:transparent;vertical-align:baseline;white-space:pre-wrap">http://git.chromium.org/gitweb/?p=chromiumos/platform/chaps.git;a=summary</span></a> </div>
<div class="im" style="font-family:arial,sans-serif;font-size:13px"><br></div><div class="im" style="font-family:arial,sans-serif;font-size:13px">This is much simpler that OpenCryptoKI and provides a PKCS#11 interface to the TPM, but it is currently quite ChromeOS specific, and its unclear how easily it could be ported to Linux. I'm going to have a look into this though.</div>
</div><div><br></div><div style>As David says though, there are some aspects of the TPM security model that don't map well onto the PKCS#11 interface. One I can think of off-hand is the consept of whether a Key is stored on the non-volatile RAM of the TPM, or on disk but wrapped in the TPMs internal key. AFAIK, OpenCryptoKI stores everything on disk wrapped.</div>
<div style><br></div><div style>I think a good aim would be to make it possible for apps which support PKCS#11 to access TPM protected keys without masses of configuration. The other use-cases (e.g., key-generation, etc.), are maybe better solved using TPM specific tools.</div>
<div style><br></div><div style>Cheers,</div><div style>Ross</div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 8 March 2013 11:46, David Woodhouse <span dir="ltr"><<a href="mailto:dwmw2@infradead.org" target="_blank">dwmw2@infradead.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Fri, 2013-03-08 at 11:31 +0100, Stef Walter wrote:<br>
> On 03/08/2013 10:14 AM, Nikos Mavrogiannopoulos wrote:<br>
> > On Thu, Mar 7, 2013 at 7:44 PM, Ross McIlroy <<a href="mailto:rmcilroy@google.com">rmcilroy@google.com</a>> wrote:<br>
> >> Hi,<br>
> >> I'm currently looking into improving the end-to-end support for storing and<br>
> >> accessing private keys / certificates on TPM devices on Linux. At present<br>
> >> it is possible to use OpenCryptoKI to provide a PKCS#11 interface to the<br>
> >> TPM, however, there are a number of issues which make doing so inconvenient:<br>
> >> - (i) Applications need to be configured to explicitly dlopen the<br>
> >> OpenCryptoKI pcsk11 module library<br>
> >> - (ii) They need to discover which slot holds the TPM token (if any)<br>
> >> - (iii) They need to provide a pin to OpenCryptoKI to login to the TPM<br>
> >> token to perform any operations (e.g., signing, encryption, etc.) with the<br>
> >> private keys stored there or to add new keys. Since this pin is not linked<br>
> >> to the users login credentials, it's an added complication for them, as well<br>
> >> as an added complication for developers who need to provide some gui /<br>
> >> command-line pin input mechanism.<br>
> ><br>
> > I was looking at the same issue a while ago. The OpenCryptoKI TPM-PKCS<br>
> > #11 module was so hard to setup for that didn't seem like a solution<br>
> > one could suggest to its users. I gave up and made a special type of<br>
> > URI, "tpmkey". It is simple and directly maps into TPM expected<br>
> > properties. This key type is now supported by gnutls 3.1.x.<br>
><br>
> With the caveat that it can't be enabled due to license<br>
> incompatibilities? [1]<br>
<br>
</div>Someone at IBM really ought to be shot for that. Releasing the TSS<br>
library under a licence which prevents people from using it in GPL'd<br>
programs is insane.<br>
<br>
Kent, is there anything we can do about that?<br>
<div class="im"><br>
> Solving these kind of things once per crypto library (and application,<br>
> like openconnect) is a bummer. Solving it once and for all is really the<br>
> way to go, and that's the goal of PKCS#11.<br>
<br>
</div>Well, yes. I resent fairly much *every* line of code I have in<br>
OpenConnect's openssl.c and gnutls*.c. All I'm trying to do is load and<br>
use a client SSL certificate that the user specifies on the command<br>
line, and validate the server's certificate. Fairly basic requirements,<br>
but still:<br>
<br>
2142 gnutls.c<br>
532 gnutls_pkcs12.c<br>
340 gnutls_tpm.c<br>
1508 openssl.c<br>
4522 total<br>
<br>
There is *more* to that problem than can be solved by PKCS#11 alone.<br>
<div class="im"><br>
> Should we try and make the opencryptoki PKCS#11 module easier to use? Is<br>
> it opencryptoki that is broken here? Or did you run into some limitation<br>
> in PKCS#11?<br>
<br>
</div>There's a little of both IIRC, although I personally got stuck on the<br>
first. It turned out to be *easier* to just write code to make GnuTLS<br>
support the TPM directly, than it was to make the whole baroque<br>
opencryptoki thing work. I tried to get opencryptoki working, and I<br>
failed. And I decided I couldn't inflict it on my users.<br>
<br>
I believe the full security model of the TPM can't easily by represented<br>
by PKCS#11. I don't remember which *part* was problematic, offhand. It<br>
has separate SRK and user PIN storage of its own for keys, and internal<br>
storage for both classes too. And it can operate using a key that<br>
*isn't* stored internally, where the user has a file containing a key<br>
that's encrypted with the TPM's internal key. When you want to *use*<br>
that key, you hand the encrypted blob to the TPM and ask nicely.<br>
<div class="im"><br>
> Should we write a simple PKCS#11 read-only TPM module which just works?<br>
> I wouldn't mind giving that a shot.<br>
<br>
</div>That might be useful, if we'd be happy with the subset of TPM<br>
functionality that can sanely be exported that way. If indeed it *is* a<br>
subset.<br>
<div class="im"><br>
> What are the requirements? Obviously there's these file based keys. If<br>
> we have a standard location for them (where they live or are symlinked<br>
> to), we can easily represent them in a PKCS#11 module.<br>
<br>
</div>Can we have full absolute file paths? :)<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
dwmw2<br>
</font></span></blockquote></div><br></div>