221
The ‘Sophisticated’ Bug OpenAI Found in Its Conference Room Can Be Yours for $13.99 (gizmodo.com)
submitted 3 weeks ago by to c/technology@lemmy.world
61 comments fedilink hide all child comments
 

The Seeed Studio XIAO ESP32-S3 Sense is for tinkerers, not super-spies.

you are viewing a single comment's thread
view the rest of the comments
[–] 2 points 3 weeks ago (2 children)

You originally asked what the point is of a self encrypting device. Even assuming this particular device in question has the attack vector you pointed out (I don't know, I haven't checked), it isn't pointless.

Your attack vector assumes the key is in memory. That would be a very odd and weird design that I've never seen... The auth key is usually stored on cryptographically secure hardware (a tpm), you unlock it at boot and it talks to the drive, the OS doesn't know about it or see it.

There's technically an attack vector there, an unproven one that assumes they have a backdoor or an undisclosed flaw at the hardware level... so sure, if you really really don't want to risk it, encrypt your data yourself.

There are a lot of reasons to choose these devices:

  1. Performance
  2. Nothing to configure os side, you just write to it and it's encrypted. Power loss means it cannot be decrypted by a malicious actor.
  3. Disposal. You can often issue a single command that scrambles the auth key and now all the data is unrecoverable without you needing to write every byte.
  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 2 points 3 weeks ago* (1 child)

    Yeah totally fair, thanks for the corrections. I’m not really all that exposed to this field, I was feeling a little frank about the details but I was trying to make a larger point.

    TPM can make it infeasible to extract the key, but there’s also the attack surface of bugging the bug. Once access is authorized to encrypted storage, protection depends on what happens outside TPM. That’s one. There’s also the potential to sniff the password, which would be two. They have full access to the device and room, with capacity to wait for the culprit to return for fetching data.

    Correct me if I’m wrong but I also think drive encryption with TPM would require that the drive be decrypted while in use. This device wouldn’t be of any value if it weren’t in use, so there’s also that.

    It seems like something you can probably count on being secure for something like a home security system. If running an espionage campaign against a trillion dollar company with Uncle Sam in the back pocket, I’d confidently bet against this system.

    Not trying to make grandiose claims about the security of TPM. I just think this scenario was a particularly risky adventure — one which could have feasibility been easier to perform with less risk, had the device come with no capability to decrypt its own data.

    I’m imagining something that perhaps micro-batches audio through a raw_audio - encrypt -> storage process, but say every 15 seconds or so. Then transport the encrypted data to a device with decryption keys.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 3 points 3 weeks ago

    Correct me if I’m wrong but I also think drive encryption with TPM would require that the drive be decrypted while in use. This device wouldn’t be of any value if it weren’t in use, so there’s also that.

    Effectively, yes, but that's misleading. Self encrypting drives talk directly to the tpm and encrypt/decrypt on the fly with each read/write. It isn't decrypting the whole drive when you boot, it just unlocks the key.

    If it's powered on and running normally, then yes they can potentially gain access by infiltrating the OS layer, and then the drive just willingly decrypts anything they want to read on the fly. As soon as they power off (or it crashes or receives a remote reboot command, etc), they are locked out. Unless of course they can break the TPM, but that's going into conjecture territory.

    The main scenario where a SED is better than something like bitlocker is the fact that the OS never knows about the key. Say they grabbed the device while it's running and were able to compromise the OS, now they have access to the drive data as long as it keeps running, but as soon as it shuts down the drive cannot be decrypted without unlocking the key at boot again. With bitlocker, they can read the key from the protected OS memory and decrypt the drive whenever/wherever.

    If running an espionage campaign against a trillion dollar company with Uncle Sam in the back pocket, I’d confidently bet against this system

    I would use all the tools available to me, and wouldn't count on one single solution, it's one of many layers of protection you can use.

    Point is, it isn't a pointless technology, there are lots of use cases.

    I’m imagining something that perhaps micro-batches audio through a raw_audio - encrypt -> storage process, but say every 15 seconds or so. Then transport the encrypted data to a device with decryption keys.

    Sure... Now imagine having setup this system where everything you record is encrypted and sent to a remote location. When they access the drive, which only has encrypted recording data, it's useless, but they can see your script that's sending it to your remote location, and potentially track you down that way. Wouldn't it be nice to have that encrypted at rest too, even if it's not 100% foolproof?

  • permalink
  • fedilink
  • source
  • parent