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?
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.
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.
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?