If you ever intend to decrypt the data, don’t you need a decryption key?
I think my point stands, you’d need this device to be only capable of encryption. Otherwise, anyone with access to the device can decrypt it. So it goes without saying, you’d have to push the data to a second device which handles decryption.
You can have an encryption key that can’t decrypt the data. That’s what public and private keys are. The device can have a public key to encrypt the data, and then it can only be decrypted with the attacker’s private key. No need to even get it out of the device, you can also perform the decryption on the same device. Just don’t store the private key in there.
Right, but that’s referring to where the encryption key lives, what kind is used, and how. In the above comment, I’m just stating you need a decryption key.
Earlier I rose that you could store the decryption key on a separate device. I thought 0x0 was contesting that idea as “not how encryption works when l implemented properly.”
Obviously not. Do you store your false equivalency fallacies on the internet in clear text? Apparently so, but I won’t call you stupid for it.
How do passwords get stored? Encrypted.
How do they get read? Decrypted.
What performs the encryption? Keys.
What can the keys be derived from? Passwords.
Where are those keys stored? On the damned device.
Are you telling me, fuck all to the popular mantra that: if they have physical access to device, you’re boned?
State sponsored forensic programs bypass TPM and shit all the time, requiring physical access.
So where is your hypothetical security coming from? To me, it sounds like you’re needlessly giving me a hard time on a subject I probably understand better than you.
A one-way function can make recovering a secret computationally infeasible, but it doesn’t eliminate the implications of allowing the device to decrypt its own data.
I presume you’re referring to a workflow where a password is put into the device, fed through a one way function to derive the key, then the key is used. So the key is derived and never stored on disk.
Nonetheless, your key was in memory. There’s an attack surface for any forensic team. There’s also the capability of trying to brute force the password in a virtual environment after having cloned the device. FBI did this to an iPhone that had full reset after 10 failed attempts.
There’s also the capability to compromise the OS, leave the device there, wait for an admin to come by and supply the password themselves.
I don’t really see how the manner by which you derive your key affects the fact that having the key on device is a vulnerability. It may mitigate the vulnerability but you’re talking about corporations and government entities with practically unlimited budgeting. If the vulnerability exists, it will be explored.
I still think my points stands. It would be stupid for someone committing espionage to allow the same device to also decrypt the data.
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:
Performance
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.
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.
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.
Honestly I wouldn’t even waste my time. That guy seems like a complete asshole, who wants to sound smart but doesn’t even understand what you’re saying.
Encryption being a one way algorithm means nothing in the context of your original concern.
How so?
If you ever intend to decrypt the data, don’t you need a decryption key?
I think my point stands, you’d need this device to be only capable of encryption. Otherwise, anyone with access to the device can decrypt it. So it goes without saying, you’d have to push the data to a second device which handles decryption.
You can have an encryption key that can’t decrypt the data. That’s what public and private keys are. The device can have a public key to encrypt the data, and then it can only be decrypted with the attacker’s private key. No need to even get it out of the device, you can also perform the decryption on the same device. Just don’t store the private key in there.
Right, but that’s referring to where the encryption key lives, what kind is used, and how. In the above comment, I’m just stating you need a decryption key.
Earlier I rose that you could store the decryption key on a separate device. I thought 0x0 was contesting that idea as “not how encryption works when l implemented properly.”
No
Oh… so how do you decrypt your data without a decryption key? Don’t tell me you use a password…
Do you store your password on the device in cleartext? Thats stupid.
Just no, youre plain wrong.
Obviously not. Do you store your false equivalency fallacies on the internet in clear text? Apparently so, but I won’t call you stupid for it.
Are you telling me, fuck all to the popular mantra that: if they have physical access to device, you’re boned?
State sponsored forensic programs bypass TPM and shit all the time, requiring physical access.
So where is your hypothetical security coming from? To me, it sounds like you’re needlessly giving me a hard time on a subject I probably understand better than you.
Sigh
https://en.wikipedia.org/wiki/One-way_function?wprov=sfla1
A one-way function can make recovering a secret computationally infeasible, but it doesn’t eliminate the implications of allowing the device to decrypt its own data.
I presume you’re referring to a workflow where a password is put into the device, fed through a one way function to derive the key, then the key is used. So the key is derived and never stored on disk.
Nonetheless, your key was in memory. There’s an attack surface for any forensic team. There’s also the capability of trying to brute force the password in a virtual environment after having cloned the device. FBI did this to an iPhone that had full reset after 10 failed attempts.
There’s also the capability to compromise the OS, leave the device there, wait for an admin to come by and supply the password themselves.
I don’t really see how the manner by which you derive your key affects the fact that having the key on device is a vulnerability. It may mitigate the vulnerability but you’re talking about corporations and government entities with practically unlimited budgeting. If the vulnerability exists, it will be explored.
I still think my points stands. It would be stupid for someone committing espionage to allow the same device to also decrypt the data.
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:
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 -> storageprocess, but say every 15 seconds or so. Then transport the encrypted data to a device with decryption keys.Honestly I wouldn’t even waste my time. That guy seems like a complete asshole, who wants to sound smart but doesn’t even understand what you’re saying.
Encryption being a one way algorithm means nothing in the context of your original concern.