1
$\begingroup$

I want all keys in my iOS application to rely on the Secure Enclave for security as the iOS keychain becomes insecure on jailbroken devices. Currently, the Secure Enclave currently only supports generation/storage of EC and RSA keys. I'm considering the following design for indirectly using the Secure Enclave to store symmetric encryption keys, but want to validate its security:

  1. On application initialization, generate an asymmetric EC key K in the Secure Enclave.
  2. Use it to sign the device UUID (or some other constant), yielding signature S.
  3. Derive encryption key E = KDF(S)
  4. Use encryption key E to encrypt items in the local database. (E itself is not stored anywhere.)
  5. On any subsequent application start, re-derive S and E and use E to decrypt the local database.

Edit: as @zaph pointed out, the Secure Enclave protects the entire Keychain. The distinction lies in that some keys can be generated in the Secure Enclave (curve p256 EC keys and RSA keys) and some can't. Those that can, enjoy a higher level of security as their private keys cannot be exported from the Secure Enclave. It is those keys that I'm interested in exploiting to indirectly protect other keys/data.

| improve this question | |
$\endgroup$
  • $\begingroup$ Where did you find that symetric keys are not stored in the Secure Enclave? $\endgroup$ – zaph Jul 12 '16 at 21:15
  • $\begingroup$ Apple's presentation: asciiwwdc.com/2015/sessions/706 search for "The supported keys are Elliptic Curve P256". It's hard to find any actual docs about this but generating anything other than kSecAttrKeyTypeRSA and kSecAttrKeyTypeEC with kSecAttrTokenIDSecureEnclave didn't work for me (though I haven't re-tested it since a couple of months ago) $\endgroup$ – Mark Vayngrib Jul 14 '16 at 23:12
  • 1
    $\begingroup$ From that transcript: "We also moved the KeyStore component from the kernel into Secure Enclave and it's that component which controls the cryptography around Keychain items and the data protection. " which implies all keychain keys, symetric and asymmetric, are in the Secure Enclave. $\endgroup$ – zaph Jul 15 '16 at 2:16
  • $\begingroup$ @zaph private keys generated in the Secure Enclave cannot be exported, which affords a much higher security, and the type of keys that can be generated in the Secure Enclave are very few: kSecAttrTokenIDSecureEnclave, the attribute necessary for SecKeyGeneratePair to generate a key in the Secure Enclave only works with kSecAttrKeyTypeRSA and kSecAttrKeyTypeEC (and for the latter, only with curve p256). All other keys may be protected by the Secure Enclave as you say, but because their private keys can be exported, their security is far weaker. $\endgroup$ – Mark Vayngrib Jul 16 '16 at 15:23
  • $\begingroup$ This is true. Consider updating your comments where they now state: "Secure Enclave doesn't support symmetric keys" and similar wording. $\endgroup$ – zaph Jul 16 '16 at 16:16
2
$\begingroup$

I'm sorry, but chances are this doesn't work.

The reason is of course that ECDSA signatures are usually fully randomized, meaning that there's randomness introduced in between the private key and the final signature. If you're looking at an ECDSA specification, the relevant value usually is called $k$.

What you'd rather need would be an RSA encryption / decryption keypair or an ECDH keypair. In this case you'd just store an encrypted key as a file or something and let the secure enclave decrypt it at each startup and keep the key in RAM. The downside being of course if an attacker can extract it from memory this application's security is screwed. If you have a static ECDH key pair you'd just store a public ECDH share and statically derive the key each time and use it as suggested.

If you have to use signatures though, you need to find a deterministic one that is offered by the enclave and use it as proposed in your question.
This can include ECDSA if it follows any standard for deterministic ECDSA (like RFC 6979) and this can also include deterministic RSA signatures (e.g. usually the older signature standards).

Bottom line: As long as you use some (intermediate) value in the key derivation which directly relies on a hardware-backed key (in a deterministic way), chances are this will be secure.
An example of how not to do such a derivation is given in Android's FDE setup (with the counter-example for a good derivation would be iOS actually)

| improve this answer | |
$\endgroup$
  • $\begingroup$ as far as i understand, bitcoin uses deterministic ECDSA signatures, without any random component, no? $\endgroup$ – Mark Vayngrib Jul 14 '16 at 17:31
  • $\begingroup$ @MarkVayngrib yes indeed ECDSA signatures can be deterministic, I've updated my post accordingly $\endgroup$ – SEJPM♦ Jul 14 '16 at 21:09
  • $\begingroup$ yea, apple's documentation doesn't seem to indicate any support for deterministic signatures using Secure Enclave keys. But you're right, asymmetric encryption can play the same role here (Secure Enclave doesn't support symmetric keys). Do you know of any literature or explorations of this technique for key derivation? Intuitively, it's sound, but I want to be sure the math says it's secure. $\endgroup$ – Mark Vayngrib Jul 14 '16 at 21:53
  • $\begingroup$ @MarkVayngrib I don't know of any such literature, however looking for how iOS does things with regards to full-disk encryption may be a starter point for you. And even without that, you need the result of the hardware-backed function to feed it into the KDF. The KDF will only produce the right key upon the right input, which needs hardware authorization requiring the application of an unbroken cryptographic function from which no key can be extracted (or operation be forged). So it comes down to who can access the "initial secret" and authorize the HW operation. $\endgroup$ – SEJPM♦ Jul 14 '16 at 22:28
  • $\begingroup$ makes sense, thanks. I'll give the question a week to see if there are any other good answers, otherwise i'll accept yours. $\endgroup$ – Mark Vayngrib Jul 14 '16 at 23:10
2
$\begingroup$

The keychain was moved to the Secure Enclave, the Apple WWDC 2015 Session 766 transcript states:

"We also moved the KeyStore component from the kernel into Secure Enclave and it's that component which controls the cryptography around Keychain items and the data protection.""

Thus both symmetric and asymmetric keys are now in the Secure Enclave if the Secure Enclave exists for the device and the iOS version is 9.0 or above.

There is no need to perform tricks to obtain Secure Enclave support for symmetric keys.

| improve this answer | |
$\endgroup$
  • $\begingroup$ thanks for pointing that out. Am I correct that there's still the distinction that private keys generated in the Secure Enclave cannot be exported, while keys in the Keychain can? $\endgroup$ – Mark Vayngrib Jul 15 '16 at 11:34
  • $\begingroup$ It is not that there is a distinction between the Secure Enclave and the Keychain just that asymmetric private keys can not be exported (other than at generation time) and symmetric keys can be exported. $\endgroup$ – zaph Jul 15 '16 at 12:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.