I'm interested in using Apple's Secure Enclave on macOS or TPM on Windows to protect cryptographic keys used by an application from being accessed by other applications running with the same or higher privileges. However, the documentation I've found so far only provides limited information on how this can be achieved.

On macOS, I was hoping that the Designated Requirements (DR) concept, in code-signed objects, will be used for controlling access to keys stored in the Secure Enclave. However, the documentation doesn't specify whether the DR are verified by the Secure Enclave, making it difficult to determine whether they provide adequate protection against unauthorized access.

Similarly, on Windows, it's not clear how to ensure that only the application that created a keypair is able to access its associated private key stored in the TPM.

I would appreciate any insights or guidance on how to best leverage the security features of the Secure Enclave and TPM to protect cryptographic keys from unauthorized access by other applications.

  • 1
    This might have the same root answer to a question I answered awhile back: security.stackexchange.com/questions/269155/…
    – foreverska
    Commented Apr 28, 2023 at 20:36
  • Would your answer hold assuming that the integrity of the operating system holds, meaning no kernel vulnerabilities exploited, and protection mechanisms such as SIP are turned on? These are acceptable assumptions.
    – Pathong
    Commented Apr 28, 2023 at 21:30
  • It's a rather academic answer. In the real world we assume some things and accept some risk. The OS may have some protections in place, I didn't answer out of deference to anyone who has those details. But, principally, in all HSM formulations we accept anyone with credentials/access to the service can use the key. But it will never be exposed.
    – foreverska
    Commented Apr 28, 2023 at 21:45
  • Therefore I do not agree with the user that claimed that this question is a duplicate of the one you answered, the perspective is different and the answers I'm looking for are different. I would expect answers like 'You can do X, but Y breaks it' allowing me, or any other reader, to match the possible solution to their threat model, when deciding what is the level of risk that they are willing to accept.
    – Pathong
    Commented Apr 28, 2023 at 21:52
  • 1
    Any ability to distinguish between Windows/macOS applications relies on the security of the Windows/macOS system. There's nothing that the secure enclave can do that would resist a breach of the normal world. That being said @foreverska I don't see this question as a duplicate because the measures you can take on Windows vs macOS vs Android are different. But here there are two questions in one: one for Windows and one for macOS. Commented Apr 29, 2023 at 10:23

1 Answer 1


I don't think anyone but an Apple engineer can give an authoritative answer. But this has been bugging me so I went on a reading spree and this is my interpretation based on previous experience with mobile chip security. Hopefully this comes close to answering your question.

Notice that you still receive a reference to the private key object, even though it’s created by the Secure Enclave. The private key is logically part of the keychain, and you can later obtain a reference to it in the usual way. But the key data is encoded, and only the Secure Enclave can make use of the key.

developer.apple.com "protecting keys with secure enclave" - accesed 29Apr2023

This reads a lot like how I'm used to mobile chip manufacturers handling the situation. The key is created in the secure enclave, encrypted and handed back to the normal world for storage as a blob. It is not stored in the SE.

There isn't a shred of mention (that I could find) that the SE cares who handed it the key or that there is any proof that it was obtained at request of the app which created it. This may be because there is no convincing way to do this and every line of code is a possible vulnerability so it's best left to normal world until there is a strong way.

So it's secure storage is paramount to it's security. The Keychain is the answer for key storage in iOS and it does mention how it verifies who's asking.

The keychain is implemented as a SQLite database, stored on the file system. There is only one database, and the securityd daemon determines which keychain items each process or app can access. Keychain Access APIs result in calls to the daemon, which queries the app’s “Keychain-access-groups,” “application-identifier,” and “application-group” entitlements. Rather than limiting access to a single process, access groups allow keychain items to be shared between apps.

Apple Platform Security May 2022 - page 88

So in summary, a secure enclave key is created by the SE and handed back to the normal world in an encrypted form (blob). The is no evidence that that the SE verifies what app asked to use a blob. Due to app sandboxes it's unlikely to be found in memory assuming no kernel compromise. At rest it should be stored in the keychain. There is evidence the keychain verifies who is asking when retrieving an entry and this is likely the major action by which protection from unauthorized access is achieved in an uncompromised system.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .