5 ms·

I really like the idea of secure enclaves. I'd like to use them. The problem I have is that it's unclear to me: a) How the hell I'm supposed to do so? It seems

I really like the idea of secure enclaves. I'd like to use them. The problem I have is that it's unclear to me: a) How the hell I'm supposed to do so? It seems fairly arcane and in need of some higher level abstractions. fortanix[0] seems like it could be good here? b) What the implications are. What's it like to maintain an enclave? What do I lose in terms of portability, debug-ability, etc? It reminds me of GPU to some extent - it's this thing in my computer that's super cool and every time I think about using it it looks like a pain in the ass.

Scene_Cast2 5y ago
I'm not sure if the push for enclaves on phones is really meant for _you_ per se. IIRC one of the more talked-about use cases is for DRM'd content (e.g. software that you can't crack, banking apps with more resistance to malware, etc).
- staticassertion 5y ago
  True, but I'm assuming that this is all moving towards enclaves being more standard and cross platform.
- count 5y ago
  Given the audience of this site....who do you think writes those apps?
- drivebycomment 5y ago
  While it is often useful to understand what the motivating goal was for the design of a new system like secure enclaves and what the practitioners primary concerns are, in the end it doesn't actually matter what the designers intender. Rather, what matters is what it actually does and provides. As long as the new functionality can be used for other useful purposes that are still within the design goals and parameters, it would be useful. Tool doesn't care what the creator intended - it's whether the tool is useful for whatever purpose it can be used for. Thus I find most analysis and comments like this, based only on motivation and incentives, very lacking. Add to that, to be more specific to this particular topic, secure enclaves are designed not only for DRM but for many other critical applications (that are actually far more important than DRM and are/were the key motivating use cases) - it, or the general concept, is the basis of the security guarantee for iPhone's fingerprint or face ID, or the confidentiality of the key materials in various end-to-end encryption, which allows things like the-phone-as-a-security-key.
  - Scene_Cast2 5y ago
    The intention is quite important for estimating which workflows would be easy and what a response could be, given an atypical use case. (E.g. if this has a backdoor, when would it be used?)
pram 5y ago
I use the T2 SE on my Mac to generate/store ssh keys. The private key never leaves the enclave. That’s a pretty neat, functional example.
- ticviking 5y ago
  Do you know of a good tutorial or documentation on how to do that?
  - pram 5y ago
    I use this: https://github.com/maxgoedjen/secretive https://github.com/maxgoedjen/secretive
    - staticassertion 5y ago
      Awesome, thank you.
    - cma 5y ago
      > The private key never leaves the enclave. .. > While Secretive uses the Secure Enclave for key storage, it still relies on Keychain APIs to access them. Keychain restricts reads of keys to the app (and specifically, the bundle ID) that created them. Doesn't that mean the keys leave the enclave?
      - astrange 5y ago
        I think they meant to say "use" not "read".
      - pram 5y ago
        The Keychain API is how you interface with the enclave key functions. It's just saying theres separate permissions for using the generated key. https://developer.apple.com/documentation/security/certificate_key_and_trust_services/keys/storing_keys_in_the_secure_enclave https://developer.apple.com/documentation/security/certifica... "When you store a private key in the Secure Enclave, you never actually handle the key, making it difficult for the key to become compromised. Instead, you instruct the Secure Enclave to create the key, securely store it, and perform operations with it. You receive only the output of these operations, such as encrypted data or a cryptographic signature verification outcome."
amicin 5y ago
> How the hell I'm supposed to do so? You might want to check out Parsec (also from Arm). https://developer.arm.com/solutions/infrastructure/developer-resources/security/parsec https://developer.arm.com/solutions/infrastructure/developer...
gendal 5y ago
My team has built Conclave that might be interesting. https://docs.conclave.net https://docs.conclave.net. The idea is 1) make it possible to write enclaves in high level languages (we've started with JVM languages), 2) make the remote attestation process as seamless as possible. The first part is what most people fixate on when they first look at Conclave. But an equally important thing is actually the second part - remote attestation. The thing a lot of people seem to miss is that for most non-mobile-phone use-cases, running code inside an enclave is only really valuable if there is a _user_ somewhere who needs to interact with it and who needs to be able to reason about what will happen to their information when they send it to the enclave. So it's not enough to write an enclave, you also have to "wire" it to the users, who will typically be different people/organisations from the organisation that is hosting the enclave. And there needs to be an intuitive/way to for them to encode their preferences - eg "I will only connect to an enclave that is running this specific code (that I have audited)" or "I will only connect to enclaves that have been signed by three of the following five firms whom I trust to have verified the enclave's behaviour".. that sort of thing.
- staticassertion 5y ago
  Is a user necessary? I feel like one thing I'd use an enclave for is as a signing oracle for service to service communications. Like I have service A and service B. A is going to talk to B, and has some secret that identifies it (maybe a private key for mTLS). I'd like for A to be able to talk to B without having access to that secret - so it would pass a message into the enclave, get a signed message out of it, and then proceed as normal. Would that not be reasonable? Or I guess maybe I'd want to attest that the signing service is what I expect?
  - jacobr1 5y ago
    > Or I guess maybe I'd want to attest that the signing service is what I expect? Exactly. If you have a threat-model where you want to limit access to your secrets from a limited code path, you need to attest that only specific, signed code is running within the enclave that can access the secrets. You might only need this to satisfy your own curiosity, but in practice it probably is something you need to prove to your internal security team, third-party auditor, or even direct to a customer.
dmulligan 5y ago
There's a lot of projects working in this area to make enclaves easier to manage and deploy, e.g. Veracruz [0] which I work on. [0]: https://github.com/veracruz-project/veracruz https://github.com/veracruz-project/veracruz
swiley 5y ago
This is probably just going to be used so corporations can deploy software onto your device without worrying about you tampering with it (stuff like DRM.)

Scene_Cast2 5y ago

I'm not sure if the push for enclaves on phones is really meant for _you_ per se. IIRC one of the more talked-about use cases is for DRM'd content (e.g. software that you can't crack, banking apps with more resistance to malware, etc).

staticassertion 5y ago
True, but I'm assuming that this is all moving towards enclaves being more standard and cross platform.
count 5y ago
Given the audience of this site....who do you think writes those apps?
drivebycomment 5y ago
While it is often useful to understand what the motivating goal was for the design of a new system like secure enclaves and what the practitioners primary concerns are, in the end it doesn't actually matter what the designers intender. Rather, what matters is what it actually does and provides. As long as the new functionality can be used for other useful purposes that are still within the design goals and parameters, it would be useful. Tool doesn't care what the creator intended - it's whether the tool is useful for whatever purpose it can be used for. Thus I find most analysis and comments like this, based only on motivation and incentives, very lacking. Add to that, to be more specific to this particular topic, secure enclaves are designed not only for DRM but for many other critical applications (that are actually far more important than DRM and are/were the key motivating use cases) - it, or the general concept, is the basis of the security guarantee for iPhone's fingerprint or face ID, or the confidentiality of the key materials in various end-to-end encryption, which allows things like the-phone-as-a-security-key.
- Scene_Cast2 5y ago
  The intention is quite important for estimating which workflows would be easy and what a response could be, given an atypical use case. (E.g. if this has a backdoor, when would it be used?)

pram 5y ago

I use the T2 SE on my Mac to generate/store ssh keys. The private key never leaves the enclave. That’s a pretty neat, functional example.

ticviking 5y ago
Do you know of a good tutorial or documentation on how to do that?
- pram 5y ago
  I use this: https://github.com/maxgoedjen/secretive https://github.com/maxgoedjen/secretive
  - staticassertion 5y ago
    Awesome, thank you.
  - cma 5y ago
    > The private key never leaves the enclave. .. > While Secretive uses the Secure Enclave for key storage, it still relies on Keychain APIs to access them. Keychain restricts reads of keys to the app (and specifically, the bundle ID) that created them. Doesn't that mean the keys leave the enclave?
    - astrange 5y ago
      I think they meant to say "use" not "read".
    - pram 5y ago
      The Keychain API is how you interface with the enclave key functions. It's just saying theres separate permissions for using the generated key. https://developer.apple.com/documentation/security/certificate_key_and_trust_services/keys/storing_keys_in_the_secure_enclave https://developer.apple.com/documentation/security/certifica... "When you store a private key in the Secure Enclave, you never actually handle the key, making it difficult for the key to become compromised. Instead, you instruct the Secure Enclave to create the key, securely store it, and perform operations with it. You receive only the output of these operations, such as encrypted data or a cryptographic signature verification outcome."

amicin 5y ago

> How the hell I'm supposed to do so? You might want to check out Parsec (also from Arm). https://developer.arm.com/solutions/infrastructure/developer-resources/security/parsec https://developer.arm.com/solutions/infrastructure/developer...

gendal 5y ago

My team has built Conclave that might be interesting. https://docs.conclave.net https://docs.conclave.net. The idea is 1) make it possible to write enclaves in high level languages (we've started with JVM languages), 2) make the remote attestation process as seamless as possible. The first part is what most people fixate on when they first look at Conclave. But an equally important thing is actually the second part - remote attestation. The thing a lot of people seem to miss is that for most non-mobile-phone use-cases, running code inside an enclave is only really valuable if there is a _user_ somewhere who needs to interact with it and who needs to be able to reason about what will happen to their information when they send it to the enclave. So it's not enough to write an enclave, you also have to "wire" it to the users, who will typically be different people/organisations from the organisation that is hosting the enclave. And there needs to be an intuitive/way to for them to encode their preferences - eg "I will only connect to an enclave that is running this specific code (that I have audited)" or "I will only connect to enclaves that have been signed by three of the following five firms whom I trust to have verified the enclave's behaviour".. that sort of thing.

staticassertion 5y ago
Is a user necessary? I feel like one thing I'd use an enclave for is as a signing oracle for service to service communications. Like I have service A and service B. A is going to talk to B, and has some secret that identifies it (maybe a private key for mTLS). I'd like for A to be able to talk to B without having access to that secret - so it would pass a message into the enclave, get a signed message out of it, and then proceed as normal. Would that not be reasonable? Or I guess maybe I'd want to attest that the signing service is what I expect?
- jacobr1 5y ago
  > Or I guess maybe I'd want to attest that the signing service is what I expect? Exactly. If you have a threat-model where you want to limit access to your secrets from a limited code path, you need to attest that only specific, signed code is running within the enclave that can access the secrets. You might only need this to satisfy your own curiosity, but in practice it probably is something you need to prove to your internal security team, third-party auditor, or even direct to a customer.

dmulligan 5y ago

There's a lot of projects working in this area to make enclaves easier to manage and deploy, e.g. Veracruz [0] which I work on. [0]: https://github.com/veracruz-project/veracruz https://github.com/veracruz-project/veracruz

swiley 5y ago

This is probably just going to be used so corporations can deploy software onto your device without worrying about you tampering with it (stuff like DRM.)