5 ms·

... I confess I'm very frustrated reading about how trusted computing modules hurt the cause of FOSS but no alternatives to actually try and carry out cryptogra

... I confess I'm very frustrated reading about how trusted computing modules hurt the cause of FOSS but no alternatives to actually try and carry out cryptography to execute trusted code. Inevitably the complaint is, "Well if they have physical access you're screwed anyways." And I just don't understand how anyone can maintain that farce when the last year has shown that it's a genuine challenge even for the US FBI to unlock a mobile device without the owners say-so and it's getting harder all the time. If you truly believe that physical access is a trump of any security then you can never trust your hardware anyways, as it is exceptionaly hard to prove it conforms to a spec.

the8472 10y ago
> And I just don't understand how anyone can maintain that farce when the last year has shown that it's a genuine challenge even for the US FBI to unlock a mobile device without the owners say-so Difficulty? Yes. But the FBI is not the NSA, they don't specialize in such attacks. It's like asking your plumber to do heart surgery. So they commissioned it to else who does, and boom, they had access. Strong cryptographic security shouldn't have a pricetag any lower than "we feed all the hydrogen in the universe to black holes to harvest enough energy for the computations". And phone security is orthogonal to baked-in firmware signing keys. The only change you need is allowing the user to add their own signing keys maybe with the caveat that all data in the protected keystore gets destroyed in the process. Then you have freedom and secure boot in one package. The signing keys are the issue, not the ring -1 management code. > If you truly believe that physical access is a trump of any security then you can never trust your hardware anyways, as it is exceptionaly hard to prove it conforms to a spec. Here are some simple steps 1. compel a manufacturer to create a spy-firmware, signed with their signing key 2. get access to a device for a few minutes 3. patch firmware that exfiltrates the data once the device is unlocked by the user 4. return device to user / to where the user placed it This is assuming strong encryption keys. If it is only protected by an unlock code your steps look like this. 1. acquire device 2. a) compel manufacturer to create a firmware that bypasses "delete on unlock failure" feature b) unsolder chips, apply silver needles to flash controllers so you can read/restore internal key storage whenever it gets wiped 3. enumerate all N-digit pass codes until it is unlocked As you can see hardware security does not save you when the strong keys are on the device and the user only enters a weak key. Similarly hardware security does not save you if a hostile entity got access to your hardware.
- KirinDave 10y ago
  I feel like you danced around the central point of my post: there is no suggestions for how to secure and harden devices without refining these trusted computing techniques. We need to harden these devices. Your argument is no one can be trusted to make them. But my argument is that if you believe that then you know you can't trust anyone to make anything one way or the other. Surely rather than botch the whole thing (because we don't like the vendors) we should start to propose stronger and more consumer-centric versions of these? A skeptical and cyncial part of me notes: given the tiny tiny number of users who can actually verify their machines are what they say they are, all "trusted computing" rebukes do is argue against a tech that actually does mitigate rwal attacks for the vast majority of uses.
  - jrcii 10y ago
    We can harden the devices by moving to a paradigm where our desktop and server executables are available exclusively through Intel AMT App Store and signed by Intel.
  - AnthonyMouse 10y ago
    > there is no suggestions for how to secure and harden devices without refining these trusted computing techniques. We need to harden these devices. Because the thing you are asking for is not possible. You have a bad premise: > And I just don't understand how anyone can maintain that farce when the last year has shown that it's a genuine challenge even for the US FBI to unlock a mobile device without the owners say-so and it's getting harder all the time. Which has two flaws. First, it wasn't a challenge for them, they were just using it as an excuse to whine about the second one that actually is. And second, the only real security is math (encryption), but it doesn't require any special support from the hardware. If you have full disk encryption with a strong passphrase and the device is currently locked (i.e. the key is not in memory), the only way to get that data is to have the passphrase or break the encryption, and breaking the encryption is not expected to be possible. The problem is, if someone has physical access to your device and can compromise your firmware, they can record your passphrase the next time you unlock the device, and then they don't need to break the encryption. But this is not a thing you can do anything about. If someone has physical access to your device they can just steal it and leave you with one that looks the same up to the point of you entering your passphrase and then transmits it to the attacker. Nothing about the original device can fix that because it isn't the original device. Similarly they can install a surveillance device in your room that can record you entering your passphrase and then come back tomorrow to take your device. The only answer to these attacks is physical security. Secure boot does nothing.
Bartweiss 10y ago
I'm not sure I understand your argument here, and I'd like to. For physical access, I though the case was "If anyone has access to your device while unlocked, or locked but not disk-encrypted, consider it permanently compromised. If anyone has access to it while disk-encrypted, consider replacing it if you're very concerned." The 'permanently' bit is for unknown firmware compromise, and this position seems pretty sane. But trusted computing modules are something else altogether. Even non-physical access can compromise them. There's some evidence that they can be compromised around a fully-encrypted disk. And checking whether they're compromised is effectively impossible. Yes, it might be possible to execute trusted code around the module, if it never hits the machine in a vulnerable form. But that's slow, non-interactive, and virtually nonexistent at present. Right now, trusted computing modules do compromise machines are roughly Ring -3, with no real recourse.
Spooky23 10y ago
The FBI issue wasn't a technical issue. When they gave up on grandstanding, the phone was cracked in hours.
- KirinDave 10y ago
  They purchased a hack for an old phone, according to the stories I read.

the8472 10y ago

> And I just don't understand how anyone can maintain that farce when the last year has shown that it's a genuine challenge even for the US FBI to unlock a mobile device without the owners say-so Difficulty? Yes. But the FBI is not the NSA, they don't specialize in such attacks. It's like asking your plumber to do heart surgery. So they commissioned it to else who does, and boom, they had access. Strong cryptographic security shouldn't have a pricetag any lower than "we feed all the hydrogen in the universe to black holes to harvest enough energy for the computations". And phone security is orthogonal to baked-in firmware signing keys. The only change you need is allowing the user to add their own signing keys maybe with the caveat that all data in the protected keystore gets destroyed in the process. Then you have freedom and secure boot in one package. The signing keys are the issue, not the ring -1 management code. > If you truly believe that physical access is a trump of any security then you can never trust your hardware anyways, as it is exceptionaly hard to prove it conforms to a spec. Here are some simple steps 1. compel a manufacturer to create a spy-firmware, signed with their signing key 2. get access to a device for a few minutes 3. patch firmware that exfiltrates the data once the device is unlocked by the user 4. return device to user / to where the user placed it This is assuming strong encryption keys. If it is only protected by an unlock code your steps look like this. 1. acquire device 2. a) compel manufacturer to create a firmware that bypasses "delete on unlock failure" feature b) unsolder chips, apply silver needles to flash controllers so you can read/restore internal key storage whenever it gets wiped 3. enumerate all N-digit pass codes until it is unlocked As you can see hardware security does not save you when the strong keys are on the device and the user only enters a weak key. Similarly hardware security does not save you if a hostile entity got access to your hardware.

KirinDave 10y ago
I feel like you danced around the central point of my post: there is no suggestions for how to secure and harden devices without refining these trusted computing techniques. We need to harden these devices. Your argument is no one can be trusted to make them. But my argument is that if you believe that then you know you can't trust anyone to make anything one way or the other. Surely rather than botch the whole thing (because we don't like the vendors) we should start to propose stronger and more consumer-centric versions of these? A skeptical and cyncial part of me notes: given the tiny tiny number of users who can actually verify their machines are what they say they are, all "trusted computing" rebukes do is argue against a tech that actually does mitigate rwal attacks for the vast majority of uses.
- jrcii 10y ago
  We can harden the devices by moving to a paradigm where our desktop and server executables are available exclusively through Intel AMT App Store and signed by Intel.
- AnthonyMouse 10y ago
  > there is no suggestions for how to secure and harden devices without refining these trusted computing techniques. We need to harden these devices. Because the thing you are asking for is not possible. You have a bad premise: > And I just don't understand how anyone can maintain that farce when the last year has shown that it's a genuine challenge even for the US FBI to unlock a mobile device without the owners say-so and it's getting harder all the time. Which has two flaws. First, it wasn't a challenge for them, they were just using it as an excuse to whine about the second one that actually is. And second, the only real security is math (encryption), but it doesn't require any special support from the hardware. If you have full disk encryption with a strong passphrase and the device is currently locked (i.e. the key is not in memory), the only way to get that data is to have the passphrase or break the encryption, and breaking the encryption is not expected to be possible. The problem is, if someone has physical access to your device and can compromise your firmware, they can record your passphrase the next time you unlock the device, and then they don't need to break the encryption. But this is not a thing you can do anything about. If someone has physical access to your device they can just steal it and leave you with one that looks the same up to the point of you entering your passphrase and then transmits it to the attacker. Nothing about the original device can fix that because it isn't the original device. Similarly they can install a surveillance device in your room that can record you entering your passphrase and then come back tomorrow to take your device. The only answer to these attacks is physical security. Secure boot does nothing.

Bartweiss 10y ago

I'm not sure I understand your argument here, and I'd like to. For physical access, I though the case was "If anyone has access to your device while unlocked, or locked but not disk-encrypted, consider it permanently compromised. If anyone has access to it while disk-encrypted, consider replacing it if you're very concerned." The 'permanently' bit is for unknown firmware compromise, and this position seems pretty sane. But trusted computing modules are something else altogether. Even non-physical access can compromise them. There's some evidence that they can be compromised around a fully-encrypted disk. And checking whether they're compromised is effectively impossible. Yes, it might be possible to execute trusted code around the module, if it never hits the machine in a vulnerable form. But that's slow, non-interactive, and virtually nonexistent at present. Right now, trusted computing modules do compromise machines are roughly Ring -3, with no real recourse.

Spooky23 10y ago

The FBI issue wasn't a technical issue. When they gave up on grandstanding, the phone was cracked in hours.

KirinDave 10y ago
They purchased a hack for an old phone, according to the stories I read.