Best practices for porting existing software to the Secure Enclave keystore

Hi,

I was reading Storing Keys in the Secure Enclave and was thinking, "that's great if you're writing new code from scratch, or updating an iOS-only code base...", but how do people integrate this functionality into well-worn packages, such as Openssl?

What's the best practice for representing the Secure Enclave keystore in software? Is it closest to an HSM (hardware security module)? Or to a PKCS11 crypto-token like a smart card? Or maybe it's sufficiently unlike anything else.

We have some management scripting that uses Openssl and I'd like to be able to make it "just work" with Secure Enclave keystore, but don't see any guidance on how best to do that.

What is the developer community's collective experience and wisdom here?

Thanks,

-Philip

Up vote post of PhilipTP Down vote post of PhilipTP
840 views
Posted by
PhilipTP
Reply
Add a Comment

Replies

Philip,

What's the best practice for representing the Secure Enclave keystore in software?

If you have a library that already supports APIs that are available for OpenSSL and you are wanting to incorporate functions of the Secure Enclave, I think one approach you could take here is to include high level APIs that allow you to perform general operations. First, that would include routines like key generation with APIs like SecKeyCreateRandomKey. Next, since a key store in the Secure Enclave cannot be stored in your application, you could create data structures that hold references to the keys that are created in the Secure Enclave through either kSecAttrLabel or kSecAttrApplicationTag. This would then allow you to pass data and your new custom structures into APIs to perform a crypto operations with one of these referenced keys.

This would be a starting point at least.

Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com
Posted by
meaton
Post not yet marked as solved Up vote reply of meaton Down vote reply of meaton
Add a Comment