4 ms·

This is admittedly unfounded speculation, but if the ME were compromised, one of the most valuable things an attacker would want would be AES keys. So _IF_ this

This is admittedly unfounded speculation, but if the ME were compromised, one of the most valuable things an attacker would want would be AES keys. So _IF_ this binary blob is up to no good, we should expect one of its tasks to jot down AES keys (remember, intel has had specialized AES instructions for a while now) and hide them somewhere for later retrieval. Perhaps it would behoove people to run a "keyscrubber" daemon that constantly generates random numbers and AES-encrypts a few kb of data and sends it to /dev/null. _IF_ the ME is jotting down keys, and _IF_ there is only a finite amount of space for it to store them, such a daemon might be able to flush out real keys and overwrite them with junk to hamper any retrieval efforts. Again, two big hypotheticals, but, if it were stealing keys, the buffer would have to be pretty small, otherwise people could eventually detect it changing sizes or hashes in NVM. I wouldn't expect such a thing in standard redable NVM anyway, it's probably on a die somewhere and only a few kb.

kogepathic 10y ago
> So _IF_ this binary blob is up to no good, we should expect one of its tasks to jot down AES keys (remember, intel has had specialized AES instructions for a while now) and hide them somewhere for later retrieval. It would have to be Intel doing this. A lot of hackers have tried to write their own modules for the ME, but to my knowledge no one has been able to run one successfully. [0] > _IF_ the ME is jotting down keys, and _IF_ there is only a finite amount of space for it to store them, such a daemon might be able to flush out real keys and overwrite them with junk to hamper any retrieval efforts. There is. The ME on consumer systems has to fit within 1.5MB, and on corporate systems (e.g. servers) within 5MB. The only persistent storage the ME has accessible is the SPI flash (which has the above size constraints) or the TPM (if there's one installed). To my knowledge, the TPM can only be used to authenticate a secret once stored, you can't ever read it back from the TPM. Otherwise, you'd have to have malware which runs inside the OS to receive the data from the ME and write or sends it somewhere else. But really, why bother going for the ME? It has a root of trust burned into the PCH silicon, and it's obviously in Intel's interest to keep the signing keys very secret. There's much lower hanging fruit if someone wanted to steal AES keys. Just install malware into UEFI or another controller (e.g. SSD, hard drive). This has already been documented in the wild, the source is speculated to be state-level actors (e.g. US, Israel). UEFI is handled by the OEM, which means they put the least amount of time/money into it as they possibly could. Just search online for BIOS/UEFI password bypassing tools if you want a sample of how terrible OEM implementations are. [0] http://www.slideshare.net/codeblue_jp/igor-skochinsky-enpub http://www.slideshare.net/codeblue_jp/igor-skochinsky-enpub
- digler999 10y ago
  sorry, I minced my words a little bit. what I mean is if the ME were already programmed to do these nasty things by design, one way to remedy such an undesirable "feature" would be to constantly run AES with new keys each time.
  - kogepathic 10y ago
    > what I mean is if the ME were already programmed to do these nasty things by design Yes, and this is possible, though I would consider the possibility remote. This would require collaboration between Intel and three letter agencies. Additionally, since the ME firmware is stored on SPI flash, anyone who suspected their ME might be eavesdropping could contact a researcher to dump their firmware for analysis. So I highly doubt Intel would be shipping this functionality in every ME firmware release. Deployment would likely be targeted against a specific individual/group. I'm not saying it couldn't be done, but the ME is not entirely a black box. The CPU architecture of the ME is known, the firmware can (and has been) dumped and analysed (though not all modules as some are encrypted). So, it's a possible attack vector, the but effort required is much higher than building persistent UEFI malware. I don't think anyone would go to the effort to build an ME rootkit when they could just do it in UEFI.
    - digler999 10y ago
      > collaboration between Intel and three letter agencies. thats part and parcel for any large US-based IT company these days. > since the ME firmware is stored on SPI flash, When you're Intel, you make the IC's and you can put whatever you want in there. If they were in bed with TLA's, I'd expect the pilfered keys would be stored in a sliver of NVM gates deep inside the die (in which chip, I can't say, perhaps in the CPU itself) (and probably encrypted with their own secret key). That's why I suggest that it would be easy to overwrite them just by constantly running aes with fresh random keys.
owenmarshall 10y ago
> This is admittedly unfounded speculation, but if the ME were compromised, one of the most valuable things an attacker would want would be AES keys. So _IF_ this binary blob is up to no good, we should expect one of its tasks to jot down AES keys (remember, intel has had specialized AES instructions for a while now) and hide them somewhere for later retrieval. If you want to get into the speculation rabbit hole, it's far more fun to assume that instead of calculating something_truly_random(), RDRAND actually returns `AES-CTR(something_truly_random(), NSAKEY, counter)` as random output - which then becomes P & Q for your RSA keys. This'd be a far easier attack to mount, and wouldn't require any exfiltration of keys; just being able to see any current RNG state would expose all the previous states. This might not be a problem for Linux, since RDRAND is mixed in, but for a while RDRAND was the exclusive entropy source for TCP sequence numbers, ASLR offsets, etc: https://cryptome.org/2013/07/intel-bed-nsa.htm https://cryptome.org/2013/07/intel-bed-nsa.htm Who knows how Windows or OS X handles this.
- digler999 10y ago
  >just being able to see any current RNG state would expose all the previous states. wow, that's insidious. I'd never even considered something like that!

kogepathic 10y ago

> So _IF_ this binary blob is up to no good, we should expect one of its tasks to jot down AES keys (remember, intel has had specialized AES instructions for a while now) and hide them somewhere for later retrieval. It would have to be Intel doing this. A lot of hackers have tried to write their own modules for the ME, but to my knowledge no one has been able to run one successfully. [0] > _IF_ the ME is jotting down keys, and _IF_ there is only a finite amount of space for it to store them, such a daemon might be able to flush out real keys and overwrite them with junk to hamper any retrieval efforts. There is. The ME on consumer systems has to fit within 1.5MB, and on corporate systems (e.g. servers) within 5MB. The only persistent storage the ME has accessible is the SPI flash (which has the above size constraints) or the TPM (if there's one installed). To my knowledge, the TPM can only be used to authenticate a secret once stored, you can't ever read it back from the TPM. Otherwise, you'd have to have malware which runs inside the OS to receive the data from the ME and write or sends it somewhere else. But really, why bother going for the ME? It has a root of trust burned into the PCH silicon, and it's obviously in Intel's interest to keep the signing keys very secret. There's much lower hanging fruit if someone wanted to steal AES keys. Just install malware into UEFI or another controller (e.g. SSD, hard drive). This has already been documented in the wild, the source is speculated to be state-level actors (e.g. US, Israel). UEFI is handled by the OEM, which means they put the least amount of time/money into it as they possibly could. Just search online for BIOS/UEFI password bypassing tools if you want a sample of how terrible OEM implementations are. [0] http://www.slideshare.net/codeblue_jp/igor-skochinsky-enpub http://www.slideshare.net/codeblue_jp/igor-skochinsky-enpub

digler999 10y ago
sorry, I minced my words a little bit. what I mean is if the ME were already programmed to do these nasty things by design, one way to remedy such an undesirable "feature" would be to constantly run AES with new keys each time.
- kogepathic 10y ago
  > what I mean is if the ME were already programmed to do these nasty things by design Yes, and this is possible, though I would consider the possibility remote. This would require collaboration between Intel and three letter agencies. Additionally, since the ME firmware is stored on SPI flash, anyone who suspected their ME might be eavesdropping could contact a researcher to dump their firmware for analysis. So I highly doubt Intel would be shipping this functionality in every ME firmware release. Deployment would likely be targeted against a specific individual/group. I'm not saying it couldn't be done, but the ME is not entirely a black box. The CPU architecture of the ME is known, the firmware can (and has been) dumped and analysed (though not all modules as some are encrypted). So, it's a possible attack vector, the but effort required is much higher than building persistent UEFI malware. I don't think anyone would go to the effort to build an ME rootkit when they could just do it in UEFI.
  - digler999 10y ago
    > collaboration between Intel and three letter agencies. thats part and parcel for any large US-based IT company these days. > since the ME firmware is stored on SPI flash, When you're Intel, you make the IC's and you can put whatever you want in there. If they were in bed with TLA's, I'd expect the pilfered keys would be stored in a sliver of NVM gates deep inside the die (in which chip, I can't say, perhaps in the CPU itself) (and probably encrypted with their own secret key). That's why I suggest that it would be easy to overwrite them just by constantly running aes with fresh random keys.

owenmarshall 10y ago

> This is admittedly unfounded speculation, but if the ME were compromised, one of the most valuable things an attacker would want would be AES keys. So _IF_ this binary blob is up to no good, we should expect one of its tasks to jot down AES keys (remember, intel has had specialized AES instructions for a while now) and hide them somewhere for later retrieval. If you want to get into the speculation rabbit hole, it's far more fun to assume that instead of calculating something_truly_random(), RDRAND actually returns `AES-CTR(something_truly_random(), NSAKEY, counter)` as random output - which then becomes P & Q for your RSA keys. This'd be a far easier attack to mount, and wouldn't require any exfiltration of keys; just being able to see any current RNG state would expose all the previous states. This might not be a problem for Linux, since RDRAND is mixed in, but for a while RDRAND was the exclusive entropy source for TCP sequence numbers, ASLR offsets, etc: https://cryptome.org/2013/07/intel-bed-nsa.htm https://cryptome.org/2013/07/intel-bed-nsa.htm Who knows how Windows or OS X handles this.

digler999 10y ago
>just being able to see any current RNG state would expose all the previous states. wow, that's insidious. I'd never even considered something like that!