GNOME Bugzilla – Bug 537237
Use PKCS#11 (smartcard) API for handling certificates and private keys
Last modified: 2014-07-23 15:45:00 UTC
PKCS#11 is a standard API for handling credentials such as X509 certificates and RSA keys on cryptographic devices such as smartcards. The primary benefit is that private credentials can not be copied off of the secure device preventing their theft from system memory. Widely available free software PKCS#11 implementations include gnome-keyring, openCryptoki, and OpenSC. Qt also provides a PKCS#11 implementation that will be used in KDE4's kwallet. wpasupplicant has support for using PKCS#11 for 802.1x connections, both WPA EAP-TLS and wired.
Created attachment 112358 [details] [review]
Add PKCS11 related fields to 802.1x setting objects and methods
Created attachment 112359 [details] [review]
Add support to the supplicant mangaer for setting PKCS11 options
Agreeing with Tambet here; we should probably use the same cert/key fields as non-pkcs11? Since I'm pretty sure that pcks11 and normal is an either/or choice we should just use the same fields in the 802.1x setting.
Also, when using pkcs11, what would the content of those fields look like? Right now we send the binary certificate data as blobs; what would NM pass down to the supplicant instead?
So I lied, you can use them in combination. But the question is, do we want to allow that? It might be better to require that if you choose pkcs11, you import all your certs and keys into the pkcs11 database and thus we could use the same fields and determine at runtime in NM whether it was an ID or a cert blob.
Are some smartcards locked down such that you cannot import more stuff into them, and if so, can you import the certs/keys into another store using the same pkcs implementation so they would still be in the database and thus have an ID even if they aren't on the smartcard itself?
> So I lied, you can use them in combination. But the question is, do we want to
> allow that? It might be better to require that if you choose pkcs11, you
> import all your certs and keys into the pkcs11 database and thus we could use
> the same fields and determine at runtime in NM whether it was an ID or a cert
> Are some smartcards locked down such that you cannot import more stuff into
> them, and if so, can you import the certs/keys into another store using the
> same pkcs implementation so they would still be in the database and thus have
> an ID even if they aren't on the smartcard itself?
Locked smartcards are definitely a possibility, though I have never experienced one and I think they are very rare. I don't quite understand the second part of your question, but it sounds like you want to mix and match. Like, if you had an organization-issued smartcard that had a cert and private key, and you had a CA cert on disk, and you couldn't import the CA cert onto the smartcard, would it be possible to import the CA cert somewhere so that the PKCS#11 implementation could handle it similarly to the cert and private key, but just with a different backing store? The short answer to that is it would be very difficult and in the general case impossible. The long answer is that almost all PKCS#11 supporting software works with objects that all be on the same token, and the situation in the example requires the cert and private key to be on one token but the CA cert to be on another. If we use openCryptoki as an example, since it has a software storage module as well as hardware modules, since you would not be able to import the CA cert into the hardware device, you'd have to instantiate a new token with the software storage backend and it would look to PKCS#11 devices as if it was a separate smartcard slot, and using two slots at the same time is generally not implemented in applications (wpasupplicant and strongswan definitely don't, and I doubt even OpenSSL's PKCS#11 engine supports it).
The ultimate solution to all of this would be for gnome-keyring to implement a PKCS#11 proxy, so that it could be configured to make objects in different backends all look to be on the same device.
But, that all being said, I think the vast majority of situations would function well just assuming all objects exist on the same token, whether that token be gnome-keyring or openCryptoki. The last mile of supporting such locked smartcards seems like a niche problem that can be fixed later. According to http://images.apple.com/server/macosx/docs/Smart_Card_Setup_Guide.pdf , in MacOS when you configure a smartcard for login, the keychain is configured to use that smartcard for all certificates and keys. So, I'm ok with NM just using PKCS#11 for everything and that either going to gnome-keyring or some other implementation. For cnetworkmanager, there is a python PKCS#11 wrapper called PyKCS11 and for knetworkmanager there is the Qt Cryptographic Architecture's PKCS#11 support.
Yeah, I'd like to ditch the custom cert stuff and only use a cert database (keyring perhaps), potentially requiring users to import their certificates and keys into that store. Obviously that store would also have to interface with PKCS#11 to pull certs off smartcards too.
Simplifies things, plus we've wanted a well-integrated _single_ certificate database/store for quite a long time.
Right. Supplicants that actually use the certs and keys use PKCS#11 to get access to them, so NM has to transport that config data to them. I think it would be ok for NM to just point them by default to keyring's PKCS#11 interface by default and make changing the path to the PKCS#11 library from keyring to something else a gconf-tool configurable setting. That's the reality and enhancing keyring to proxy other PKCS#11 implementations is not in scope for NM.
Created attachment 115362 [details] [review]
Rename PKCS#11 CA cert object to just "pkcs11-ca-cert" to match other objects
This is a fix for an earlier patch, the CA cert object's gconf key was "pkcs11-ca-cert-object" where as none of the other objects had "-object" in their names, so fix that.
Created attachment 115363 [details] [review]
Make PKCS#11 related settings use containers use regular char* strings, instead of GStrings
Replace GStrings with char* strings, just because their's no reason to use GStrings here and they only add to the noise.
Just chatted with Dan about this. From the whiteboard:
* Short term solution
- Cert stuff still done in applet
- For hardware devices, we have a UI that allows you to enter the key ID, this gets passed down to supplicant
- Add settings for key ids to connections
* Longer term solution
- Have a system crypto store service that can talk to both hardware and filesystem keys
- Extend gnome-keyring with a UI for interacting with that service (getting the ID for a particular key, adding keys if possible, etc.)
- Supplicant can talk to system store natively
- Possibly port supplicant to NSS, NSS can talk to system store
- Also we want user-level key store; ideally we just run the system store in the user's session in some way, pointing it at ~/.local/pki or whatever instead of /etc/pki
There were some bugs in the libnm-util portions of the patches regarding PIN handling. I've fixed them and am attaching a new patch for this.
I would like to have this considered on its own for inclusion immediately without any corresponding changes in nm-applet, because it is already useful via the system-settings daemon.
Created attachment 118857 [details] [review]
add pkcs11 related settings to nm-supplicant-settings-verify.c
Created attachment 118858 [details] [review]
remove the pkcs11_pin options and replace it with the existing pin option. Also, fix the handling of the pin.
Created attachment 118859 [details] [review]
all of the previous patches, in one big patch
Just put all of the small patches together in one clean patch. Please try it.
Created attachment 121724 [details] [review]
Cleaned up patch.
I ported the patch to the latest SVN (r4241) and fixed a bunch of memory leaks in it.
Created attachment 125862 [details] [review]
updated patch for nm 0.7 release
Thanks for looking at the patch, Tambet. There were some small bugs that I fixed and I updated it to build against NM 0.7 release.
I still hope that it can be included soon, possibly for 0.8, without waiting for a more full migration to NSS in wpasupplicant.
And if this is pedantic, I apologize, but please make sure you're clear that with hardware crypto devices like smartcards, you can't build a system where network manager would be able to get the private key as a binary blob and pass it to wpasupplicant; hardware crypto is all about keeping the private data out of system memory. So if you are coming up with a system that is radically different from this one, please discuss it so it gets done right.
Created attachment 125866 [details] [review]
updated patch for nm 0.7 release
Introduced a regression in verify_tls. Fixed.
Created attachment 125900 [details] [review]
updated patch for nm 0.7 release
Found another regression in need_secrets_tls.
Duping to a newer bug that we'll use as the overall for this issue.
*** This bug has been marked as a duplicate of bug 719982 ***