<div dir="ltr">Hi,<div><br></div><div>I'm currently looking into improving the end-to-end support for storing and accessing private keys / certificates on TPM devices on Linux.  At present it is possible to use OpenCryptoKI to provide a PKCS#11 interface to the TPM, however, there are a number of issues which make doing so inconvenient:</div>


<div><br></div><div>   - (i) Applications need to be configured to explicitly dlopen the OpenCryptoKI pcsk11 module library</div><div>   - (ii) They need to discover which slot holds the TPM token (if any)</div>
<div>   - (iii) They need to provide a pin to OpenCryptoKI to login to the TPM token to perform any operations (e.g., signing, encryption, etc.) with the private keys stored there or to add new keys.  Since this pin is not linked to the users login credentials, it's an added complication for them, as well as an added complication for developers who need to provide some gui / command-line pin input mechanism.</div>


<div><br></div><div>p11-kit seems a good place to start to address (i) - if p11-kit becomes the standard for merging the system-wide pkcs11 modules, then apps only need to load a single well-known module to have access to all the keys provided, including those on the TPM.</div>


<div><br></div><div>However, even with p11-kit, (ii) and (iii) still present a challenge.  It would be great to have a situation where the user specifies that they want keys to be stored on the TPM rather than on-disk, and the app could figure out how to do this without the user having to specify exactly which slot to use.  I'm not sure if it's possible within the constraints of PCKS#11, but has there been any thought on creating some kind of structured hierarchy of the slots/modules provided by p11-kit, whereby an app could decide on which slot to use based on its security properties?</div>

<div><br></div><div style>Similarly, having to unlock the TPM using a pin which is separate from the users credentials seems unwieldy.  Would it be worth considering enabling p11-kit to handle login operations on behalf of it's delegate modules?  For example, p11-kit could be configured to load a TPM module with two slots - one of which p11-kit logs-in automatically on user login (perhaps using a pin based on the users login-credentials), while the other is only logged-in when an app requests it to be, at which point p11-kit throughs up a system prompt to request the users unix-credentials and uses these to derive the correct pin.  This might be something that would be better suited to being part of gnome-keyring, but as far as I know, it's not possible to have gnome-keyring load keys from PKCS#11 providers other than those it defines itself (please correct me if I'm wrong).</div>

<div style><br></div><div style>Being new to gnome-keyring / p11-kit / PKCS#11 I'm not sure if these are sensible ideas, but please let me know your thoughts.</div><div style><br></div><div style>Cheers,<br>Ross</div>

<div style><br></div><div style> </div>
</div>