7 ms·

> a way to actually improve personal security, I'm not sure this is true. I've studied trust models in some depth now and I think that cryptographic enclaves a

> a way to actually improve personal security, I'm not sure this is true. I've studied trust models in some depth now and I think that cryptographic enclaves are at best an analgesic and sedative. Don't fall for any myth of symmetrical technology that can be used "for evil or good". The purpose of this technology is to assert logical ownership over computation under remote physical control of another. That would serve your interests and rights iff you purchase a cloud computing resource you want to make secure in an untrustworthy data-centre. Sadly "security" gets used as a bare noun. One must always ask three questions: - security for who? - security against who or what? - security to what end? DRM is a generally a net loss to security of the physical machine owner, since it is a way to hide code and functionality within the perimeter of ownership and control. It's no worse than blobs or treacherous silicon, but any security conscious operator should avoid or remove it. It is opaque "security" for vendors/content-publishers, and "security" against the owner and operator.

ulrikrasmussen 2y ago
I think it makes sense in very narrow use cases such as hardware security modules for key management, giving the user a somewhat strong guarantee that there is a one-to-one correspondence between control of the key and physical ownership of the HSM. This is an example where limitations of what you can do with the hardware is the primary feature of the hardware and the reason the user acquired it in the first place. It is analogous to physical locks being hard to pick by design. Any use of enclaves for DRM are unethical though, and solutions such as Play Integrity API is a commingling of security guarantees and totalitarian control over the user. Instead of proving to a service provider (such as your bank) that your whole phone is running a verified software and hardware stack, it suffices to communicate with a HSM with which you verify that the transaction to be authorized (1) comes from your bank, and (2) has a description which aligns with what you expect. The HSM can be built into the phone or be an external device with a small screen, but it should never ever enforce how you use the rest of the phone, it should only solve the narrow security issue of authorizing critical transactions.
miki123211 2y ago
> cryptographic enclaves are at best an analgesic and sedative Cryptographic enclaves let you securely use passwords that are otherwise very easy to break. For example, a random 4-digit pin can be broken in seconds, minutes at most, even with really strong PKDF functions. With a cryptographic enclave that destroys your key after 10 unsuccessful attempts, attackers only have a 0.1% chance of breaking that PIN. This is an acceptable security level for many users. In theory, better security than that is possible by using a complex passphrase. In practice, the passphrase ends up being "exampleDotOrgWinter25!", which is still very easy to brute force. For many users, that random 4-digit PIN plus an enclave will end up being more secure than the long and complex password.
- nonrandomstring 2y ago
  Local-only memory (say readable only from a certain CPU security ring and securely erasable in an atomic operation) is a useful tool for methods such as you describe. What I'm shooting at is private memory under cryptographic control of a remote networked entity. I should more properly have said "remotely secured enclave" or something like that. I think in this area it's hard to be precise amidst confusion about who does the encryption, who generates and keeps the private keys, and what power that affords them.

ulrikrasmussen 2y ago

I think it makes sense in very narrow use cases such as hardware security modules for key management, giving the user a somewhat strong guarantee that there is a one-to-one correspondence between control of the key and physical ownership of the HSM. This is an example where limitations of what you can do with the hardware is the primary feature of the hardware and the reason the user acquired it in the first place. It is analogous to physical locks being hard to pick by design. Any use of enclaves for DRM are unethical though, and solutions such as Play Integrity API is a commingling of security guarantees and totalitarian control over the user. Instead of proving to a service provider (such as your bank) that your whole phone is running a verified software and hardware stack, it suffices to communicate with a HSM with which you verify that the transaction to be authorized (1) comes from your bank, and (2) has a description which aligns with what you expect. The HSM can be built into the phone or be an external device with a small screen, but it should never ever enforce how you use the rest of the phone, it should only solve the narrow security issue of authorizing critical transactions.

miki123211 2y ago

> cryptographic enclaves are at best an analgesic and sedative Cryptographic enclaves let you securely use passwords that are otherwise very easy to break. For example, a random 4-digit pin can be broken in seconds, minutes at most, even with really strong PKDF functions. With a cryptographic enclave that destroys your key after 10 unsuccessful attempts, attackers only have a 0.1% chance of breaking that PIN. This is an acceptable security level for many users. In theory, better security than that is possible by using a complex passphrase. In practice, the passphrase ends up being "exampleDotOrgWinter25!", which is still very easy to brute force. For many users, that random 4-digit PIN plus an enclave will end up being more secure than the long and complex password.

nonrandomstring 2y ago
Local-only memory (say readable only from a certain CPU security ring and securely erasable in an atomic operation) is a useful tool for methods such as you describe. What I'm shooting at is private memory under cryptographic control of a remote networked entity. I should more properly have said "remotely secured enclave" or something like that. I think in this area it's hard to be precise amidst confusion about who does the encryption, who generates and keeps the private keys, and what power that affords them.