5 ms·

> How useful are such measures when Intel has backdoored each and everyone of their CPUs with its "Intel Management Engine" [0] (and AMD has a similar mechanism

by j_s 9y ago

> How useful are such measures when Intel has backdoored each and everyone of their CPUs with its "Intel Management Engine" [0] (and AMD has a similar mechanism)? If you trust this YubiHSM but not Intel CPUs, then it is very useful since encryption/decryption occurs on the YubiHSM, not the connected CPU. Just plug it into a computer with a CPU you do trust first to get the official public key(s) for future verifications! If you don't trust this YubiHSM because of the example of Intel CPUs, then please share at what point you do trust third party hardware, so we can discuss how to get to useful encryption from there. Would you only trust RAM you wire-wrapped yourself? Would you only trust a motherboard you built from 7400 series logic gates, each of which you personally verified using X-rays? The line has to be drawn somewhere, but without knowing where you want to do so your comment serves mostly to hijack discussion (which is fine).

Cyph0n 9y ago
If an attacker controls your computer, there is always the possibility of a man in the middle, even if you use a Yubikey. The attacker could simply wait for a request to the HSM and intercept the response.
- j_s 9y ago
  But they don't have the private key, that's the whole point of the hardware device! They can't MITM the encrypted data without it. plaintext <-> crypto <-> blob <-> *compromised server/anything but quantum computing* <-> blob <-> crypto / YubiHSM Edit: I'm not talking about this: *my compromised PC* <-> plaintext <-> crypto <-> blob <-> crypto / Yubikey In practice, getting anything done involves some CPU doing something useful with plaintext, if that's what you're getting at. As I said, you have to draw the line somewhere. Without sharing where you do this there is little point in talking about it. Personally, I can't see any problem with an Intel CPU (or any other hardware) acquired with cash in person, then never networked and if I wanted to go ultra paranoid: a chain of custody from the time of my acquisition demonstrating continuous physical surveillance. My point is that I could securely "crypto" from my academic-dreamland/whatever secure computer through any transport to a YubiHSM connected to a compromised PC, if I trust Yubico (and the supply chain delivering their hardware) and the YubiHSM's initial/one-time setup.
  - Cyph0n 9y ago
    There are two potential attack scenarios, assuming some attacker A has full control of the PC connected to the Yubikey: 1. A somehow convinces the remote party that the actual public key is X' instead of X. Ciphertext comes in, attacker decrypts it. Done. 2. A intercepts ciphertext, feeds it to Yubikey for decryption, and gets the resulting plaintext over USB (or whatever). Note: this is assuming that the Yubikey doesn't have encrypted filesystem support or similar. Combining 1&2, A can use the Yubikey as an oracle to perform unlimited authentications, signing, and decryptions. The only advantage provided by a Yubikey is that your keys cannot be remotely exfiltrated. Physical attacks on the hardware are still possible though.
    - deleted 9y ago
      [deleted]
    - j_s 9y ago
      I don't understand what option one has to do with any of this, if you can switch keys there's nothing any amount of extra hardware can do. In that case, just use the key you switched to. It is true that hardware tokens without an integrated external I/O (not through the PC it is plugged into) are vulnerable to this type of attack during initial key setup. Maybe they should support using the indicator LED to morse code thumbprints or something, but if you can't trust I/O to the device during setup you're going to have a bad time. I will quote my original caveat here: > Just plug it into a computer with a CPU you do trust first to get the official public key(s) for future verifications! Your second point seems to be that the plaintext has to be exposed (either going in or coming out) at the USB/hardware interface level, which makes more sense to discuss. The sales page promises the following, but I didn't quickly find any details on how it works: https://www.yubico.com/products/yubihsm/ https://www.yubico.com/products/yubihsm/ Secure session between HSM and application The integrity and privacy of commands and data in transit between the HSM and applications are protected using a mutually authenticated, integrity and confidentiality protected tunnel.
      - Cyph0n 9y ago
        > I don't understand what option one has to do with any of this, if you can switch keys there's nothing any amount of extra hardware can do. In that case, just use the key you switched to. Take TLS/HTTPS as an example. The underlying assumption is that your browser's and/or OS certificate store are trusted. If an attacker compromises your machine and adds a new certificate to that "trusted" store, all secure communication is broken. That is the inherent weakness of public-key crypto. Back to the Yubikey scenario. Let's say a remote server R wants to talk to the Yubikey Y on your PC. Y initially generates a key pair and then (somehow) securely delivers the public key to the remote server R. Clearly, whenever R sends something to Y, an attacker wouldn't be able to decrypt the message unless it has the private key which is securely stored on the HSM. Scenario (1) above was looking at the case of an attacker who somehow "tricks" R into updating/replacing/revoking the original public key and inserting his own key into the remote key database. If successful, the attacker could then intercept all inbound communication from the remote server and decrypt it. > The sales page promises the following, but I didn't quickly find any details on how it works: It looks like marketing speak to me honestly. If the computer/server the Yubikey is talking to is compromised, there really is nothing stopping an attacker from using the Yubikey to perform arbitrary encryptions and decryptions.
- morpheuskafka 9y ago
  MITM can't capture something that is never sent, like the private key. Same thing with a TPM.
- deleted 9y ago
  [deleted]
madez 9y ago
If your computer is backdoored, then a HSM does not protect effectively against that attacker. At some point the computer will see the data, at which point it can be extracted. The key is not important to the attacker which can read the unencrypted data. A HSM does make attacks more difficult, and that is important. On the other hand, computers without backdoors would be _the_ significant step, though, to change the game. I fundamentally dislike Intel and AMD for their stance on this. And I'm not alone.
- deleted 9y ago
  [deleted]
- deleted 9y ago
  [deleted]

by j_s 9y ago

Cyph0n 9y ago

If an attacker controls your computer, there is always the possibility of a man in the middle, even if you use a Yubikey. The attacker could simply wait for a request to the HSM and intercept the response.

j_s 9y ago
But they don't have the private key, that's the whole point of the hardware device! They can't MITM the encrypted data without it. plaintext <-> crypto <-> blob <-> *compromised server/anything but quantum computing* <-> blob <-> crypto / YubiHSM Edit: I'm not talking about this: *my compromised PC* <-> plaintext <-> crypto <-> blob <-> crypto / Yubikey In practice, getting anything done involves some CPU doing something useful with plaintext, if that's what you're getting at. As I said, you have to draw the line somewhere. Without sharing where you do this there is little point in talking about it. Personally, I can't see any problem with an Intel CPU (or any other hardware) acquired with cash in person, then never networked and if I wanted to go ultra paranoid: a chain of custody from the time of my acquisition demonstrating continuous physical surveillance. My point is that I could securely "crypto" from my academic-dreamland/whatever secure computer through any transport to a YubiHSM connected to a compromised PC, if I trust Yubico (and the supply chain delivering their hardware) and the YubiHSM's initial/one-time setup.
- Cyph0n 9y ago
  There are two potential attack scenarios, assuming some attacker A has full control of the PC connected to the Yubikey: 1. A somehow convinces the remote party that the actual public key is X' instead of X. Ciphertext comes in, attacker decrypts it. Done. 2. A intercepts ciphertext, feeds it to Yubikey for decryption, and gets the resulting plaintext over USB (or whatever). Note: this is assuming that the Yubikey doesn't have encrypted filesystem support or similar. Combining 1&2, A can use the Yubikey as an oracle to perform unlimited authentications, signing, and decryptions. The only advantage provided by a Yubikey is that your keys cannot be remotely exfiltrated. Physical attacks on the hardware are still possible though.
  - deleted 9y ago
    [deleted]
  - j_s 9y ago
    I don't understand what option one has to do with any of this, if you can switch keys there's nothing any amount of extra hardware can do. In that case, just use the key you switched to. It is true that hardware tokens without an integrated external I/O (not through the PC it is plugged into) are vulnerable to this type of attack during initial key setup. Maybe they should support using the indicator LED to morse code thumbprints or something, but if you can't trust I/O to the device during setup you're going to have a bad time. I will quote my original caveat here: > Just plug it into a computer with a CPU you do trust first to get the official public key(s) for future verifications! Your second point seems to be that the plaintext has to be exposed (either going in or coming out) at the USB/hardware interface level, which makes more sense to discuss. The sales page promises the following, but I didn't quickly find any details on how it works: https://www.yubico.com/products/yubihsm/ https://www.yubico.com/products/yubihsm/ Secure session between HSM and application The integrity and privacy of commands and data in transit between the HSM and applications are protected using a mutually authenticated, integrity and confidentiality protected tunnel.
    - Cyph0n 9y ago
      > I don't understand what option one has to do with any of this, if you can switch keys there's nothing any amount of extra hardware can do. In that case, just use the key you switched to. Take TLS/HTTPS as an example. The underlying assumption is that your browser's and/or OS certificate store are trusted. If an attacker compromises your machine and adds a new certificate to that "trusted" store, all secure communication is broken. That is the inherent weakness of public-key crypto. Back to the Yubikey scenario. Let's say a remote server R wants to talk to the Yubikey Y on your PC. Y initially generates a key pair and then (somehow) securely delivers the public key to the remote server R. Clearly, whenever R sends something to Y, an attacker wouldn't be able to decrypt the message unless it has the private key which is securely stored on the HSM. Scenario (1) above was looking at the case of an attacker who somehow "tricks" R into updating/replacing/revoking the original public key and inserting his own key into the remote key database. If successful, the attacker could then intercept all inbound communication from the remote server and decrypt it. > The sales page promises the following, but I didn't quickly find any details on how it works: It looks like marketing speak to me honestly. If the computer/server the Yubikey is talking to is compromised, there really is nothing stopping an attacker from using the Yubikey to perform arbitrary encryptions and decryptions.
morpheuskafka 9y ago
MITM can't capture something that is never sent, like the private key. Same thing with a TPM.
deleted 9y ago
[deleted]

madez 9y ago

If your computer is backdoored, then a HSM does not protect effectively against that attacker. At some point the computer will see the data, at which point it can be extracted. The key is not important to the attacker which can read the unencrypted data. A HSM does make attacks more difficult, and that is important. On the other hand, computers without backdoors would be _the_ significant step, though, to change the game. I fundamentally dislike Intel and AMD for their stance on this. And I'm not alone.

deleted 9y ago
[deleted]
deleted 9y ago
[deleted]