-
Onion Encryption Systems
Author: NikB Date: 12-28-2009
There's a lot of talk about attacks against whole-disk encryption schemes. The usual response to an attack, is to add another layer, specifically designed to thwart the attack. But is that a reasonable and workable model?
At CL, we do a lot of security-related consulting. We're the guys you hire to audit not just your code but your entire architecture to find the subtle holes that remain after you've spent the time running your code through lint and carefully auditing all your stack-based buffers.
As part of our -- for lack of a better term -- DNA, we look at things with a very critical eye, trying to focus on the security implications of everything. It always surprises us how people with no background in security think up of elaborate 'mechanisms' that they use to protect systems from attacks, without taking a step back and really thinking about whether those attacks and their solutions are relevant or even realistic.
This was nicely demonstrated when Joanna Rutkowska implemented an attack using TrueCrypt as her stage. It wasn't an attack against the encryption algorithms behind TrueCrypt or even an attack against the implementation of TrueCrypt. She merely replaced the TrueCrypt bootloader with one designed to prompt your for your password and store for an attacker to recover at a later time.
In the aftermath, a lot of people came out and said that TrueCrypt was compromised, coming up with elaborate schemes to guard against this attack. Others argued that you absolutely needed a TPM chip to do secure whole disk encryption. And then the Fraunhofer Institute's Secure Information Technology division, then implemented a similar attack against a system using Microsoft's BitLocker, which uses the TPM to guarantee the integrity of the boot process. Their custom bootloader perfectly emulates the password prompt screen of TrueCrypt or BitLocker, snatching your password as you unwittingly type it in.
The TPM, it turned out, was no help at all against that attack. Many of the same people that had chanted the "TPM" mantra before started coming up with more exotic 'solutions' to this 'problem' without stopping to think about one simple fact: Fundamentally, this is a problem that we cannot solve perfectly -- if you create an encryption system like an onion, someone will, eventually, figure out how to peel off the first layer, and someone else will then peel another layer, and soon, there will be no onion left. What is needed is a way for the machine to identify itself to you and attest to its untampered state in a fool-proof manner before you enter your password in, attacks like this will always be possible. The question, therefore, is how to make this so impractical that it's improbable.
Well, you could setup your system to only boot from trusted devices, making life more difficult for the attacker. There are some computers in which the BIOS boot order cannot be changed without the password. Not even a CMOS reset will help and the attacker would have to physically remove your hard drive and connect it to a different machine to change the bootloader before putting it back into your computer.
You could thwart that too; just configure your PC to ignore the bootloader on the hard drive in favor of the bootloader on an external device that you always carry with you. That device can either boot your system securely, or contain code that validates the bootloader stored on the system's hard drive using a cryptographically secure hash.
A better solution could come in the form of a secure bootloader stored in ROM. Each O/S you install on your system would register a second-stage bootloader with the ROM-based secure bootloader. As part of the registration, the secure bootloader would store an encrypted cryptographically secure hash of the second-stage in the TPM. When booting, the system would initialize the Core Root of Trust Management, and invoke the secure ROM-based bootloader. It would then validate the second-stage bootloader prior to executing it, by hashing it again and comparing the hash with that stored in the TPM.
It still wouldn't be perfect: a really determined attacker could replace the ROM-chip containing the secure boot loader and you would be back to square one. For every layer we could add, an attacker could go on level lower to subvert the protection. Frankly, this sounds like an awful lot of trouble for a would-be attacker to go through. Remember we don't need to make this 'malicious bootloader' attack impossible. Just impractical enough that other attack vectors become more viable. Old-fashioned hardware-based keyloggers would have started to sound pretty good to an attacker way before we even get to secure ROM-based bootloaders with TPM support.
So if that's the case -- if this is a 'war' that cannot be won -- why bother encrypting at all? Because you do not use encryption to protect yourself from attackers who can tamper with a computer that you will then turn around and use. You use encryption because you want to keep your data private if your computer is stolen or confiscated. And if you're dealing with someone who claims otherwise, you should take a moment to think about whether what they're selling is snake oil.
Research Home -
Research Categories
