something I hadn't really considered about hard disk encryption, before reading this, is how it could protect against compromised disk controllers. if the OS encrypts the data stored on the disk, it would be a lot harder (perhaps, with the right composition, impossible) for a malicious disk controller to insert/change/modify important data (like code, or password files) stored on the computer.
we think of the system as a holistic entity, but turned on its head, you can see how the inside of a computer is just a network...
yes there is, you encrypt the OS that is stored on the hard drive
edit: sorry, chain looks like this: BIOS reads boot block from hard drive, checks digital signature, signature invalid, boot fails. BIOS check for signature works in concert with TPM to do key storage, so you're fine. albeit, sleeping with 'evil' technology like UEFI and TPM.
You're still going to have the "who can you trust" problem. If you're worried about a compromised disk controller then you ought to be worried about a compromised BIOS or TPM too.
Ought you? Those are all different bits of hardware. One being subverted doesn't mean the others are - if nothing else, the attacker isn't likely to have a vulnerability for every combination of firmware and chip.
This sort of attack is usually going to be more trouble than it's worth to execute, but that doesn't mean it's out of reach for a motivated, educated individual.
You don't need a combination, just compromising the BIOS gets you root. You don't need to separately compromise the disk firmware, it's either or.
The point is that it's the same kind of attack. Relying on the BIOS may save you from an attack on the disk firmware but that doesn't much help if the same class of attack is still effective against the BIOS.
Sure. My point is there's no guarantee the attacker will be able to compromise the TPM or BIOS just because they can compromise the disk controller.
I'd bet most systems see different disk controllers more often than they see different BIOS chips. I'd bet (though not at so high odds) that reasonably secure TPM chips are relatively easier to find outside of the high-end server niche. I'd bet that most non-state actors executing this sort of attack wouldn't have equivalent exploits ready for many different types of hardware.
All of those factors shift risk around (again, what little risk there is from this sort of vulnerability). Forgetting about patching a hole here because of an equal-sized hole over there is silly.
except the TPM is explicitly designed to resist this kind of attack and be tamper-evident / tamper-proof, it's security hardware. so if someone can successfully attack the TPM, you are having a very big problem and will not go to security today.
so if someone can successfully attack the TPM, you are having a very big problem and will not go to security today.
"That isn't supposed to happen" doesn't mean it won't happen. The Titanic wasn't supposed to sink.
The point is, you want to be able to recover from attacks. It isn't about security today. The premise here is that you've already been compromised to the point that the attacker may have been able to screw with the firmware on your hardware. What you need then is not an assurance that the thing that already happened not be very easy, what you need is a way to hard reset the hardware to a known-good (i.e. factory) state given the assumption that every piece of EEPROM in the machine has been replaced with malicious code. Having something like a jumper on the logic board that will do that in hardware would be a welcome security feature.
The DMA mentioned in the article was internal to the drive, between the hardware interfaces and it's internal cache. The drive did not have DMA access to system memory.
Even though it wasn't discussed in the article, I think firewire and thunderbolt external drives DO have direct DMA access to system memory. Google for SBP-2 and DMA, and a bunch of articles about protecting against firewire attacks against full-disk-encryption (among other things) appear.
I know you're right on FW. I believe DMA was designed in because they recognized that the CPUs of the time weren't powerful enough to move uncompressed full-resolution video from around. I don't know about Thunderbolt, but I'd expect you're right.
IIRC DMA was designed to allow peripherals (floppy drives, parallell ports, etc.) to move data from their input lines to regular memory without having to bother the CPU. Uncompressed, full resolution video wasn't too much of a real concern back in the days of the 80286 :-)
Comments
something I hadn't really considered about hard disk encryption, before reading this, is how it could protect against compromised disk controllers. if the OS encrypts the data stored on the disk, it would be a lot harder (perhaps, with the right composition, impossible) for a malicious disk controller to insert/change/modify important data (like code, or password files) stored on the computer.
we think of the system as a holistic entity, but turned on its head, you can see how the inside of a computer is just a network...
[deleted]
yes there is, you encrypt the OS that is stored on the hard drive
edit: sorry, chain looks like this: BIOS reads boot block from hard drive, checks digital signature, signature invalid, boot fails. BIOS check for signature works in concert with TPM to do key storage, so you're fine. albeit, sleeping with 'evil' technology like UEFI and TPM.
You're still going to have the "who can you trust" problem. If you're worried about a compromised disk controller then you ought to be worried about a compromised BIOS or TPM too.
Ought you? Those are all different bits of hardware. One being subverted doesn't mean the others are - if nothing else, the attacker isn't likely to have a vulnerability for every combination of firmware and chip.
This sort of attack is usually going to be more trouble than it's worth to execute, but that doesn't mean it's out of reach for a motivated, educated individual.
You don't need a combination, just compromising the BIOS gets you root. You don't need to separately compromise the disk firmware, it's either or.
The point is that it's the same kind of attack. Relying on the BIOS may save you from an attack on the disk firmware but that doesn't much help if the same class of attack is still effective against the BIOS.
Sure. My point is there's no guarantee the attacker will be able to compromise the TPM or BIOS just because they can compromise the disk controller.
I'd bet most systems see different disk controllers more often than they see different BIOS chips. I'd bet (though not at so high odds) that reasonably secure TPM chips are relatively easier to find outside of the high-end server niche. I'd bet that most non-state actors executing this sort of attack wouldn't have equivalent exploits ready for many different types of hardware.
All of those factors shift risk around (again, what little risk there is from this sort of vulnerability). Forgetting about patching a hole here because of an equal-sized hole over there is silly.
except the TPM is explicitly designed to resist this kind of attack and be tamper-evident / tamper-proof, it's security hardware. so if someone can successfully attack the TPM, you are having a very big problem and will not go to security today.
"That isn't supposed to happen" doesn't mean it won't happen. The Titanic wasn't supposed to sink.
The point is, you want to be able to recover from attacks. It isn't about security today. The premise here is that you've already been compromised to the point that the attacker may have been able to screw with the firmware on your hardware. What you need then is not an assurance that the thing that already happened not be very easy, what you need is a way to hard reset the hardware to a known-good (i.e. factory) state given the assumption that every piece of EEPROM in the machine has been replaced with malicious code. Having something like a jumper on the logic board that will do that in hardware would be a welcome security feature.
Maybe I misunderstood, but didn't the harddrive have direct memory access (DMA)?
The DMA mentioned in the article was internal to the drive, between the hardware interfaces and it's internal cache. The drive did not have DMA access to system memory.
Even though it wasn't discussed in the article, I think firewire and thunderbolt external drives DO have direct DMA access to system memory. Google for SBP-2 and DMA, and a bunch of articles about protecting against firewire attacks against full-disk-encryption (among other things) appear.
I know you're right on FW. I believe DMA was designed in because they recognized that the CPUs of the time weren't powerful enough to move uncompressed full-resolution video from around. I don't know about Thunderbolt, but I'd expect you're right.
Thunderbolt is just pci-express in new clothes, so yes, it does.
Good point.
IIRC DMA was designed to allow peripherals (floppy drives, parallell ports, etc.) to move data from their input lines to regular memory without having to bother the CPU. Uncompressed, full resolution video wasn't too much of a real concern back in the days of the 80286 :-)
Hence http://www.breaknenter.org/projects/inception/ and similar attacks.
It had DMA to its own memory, not to the host computer's memory.