Tag Archives: encryption

Apple, the FBI, and the Omnipotence Paradox

“Can God create a rock so heavy He could not lift it?” this is one version of the omnipotence paradox. To make a long story short, ominpotence as a concept leads to similar logical problems as the naïve set-of-sets and sets-containing-themselves constructions in Russel’s paradox. Some use this paradox to question religion; others use it to question logic; and pondering such questions generally seems to belong to the realm of philosophy. But the ongoing new round of (civil) crypto wars is bringing a tranformed version of this paradox into everyone’s pocket.

Can Apple create an encryption mechanism so strong that even Apple cannot break it? Apple claims so, at least for the particular situation, in their defense against the FBI’s request for help with unlocking a dead terrorist’s iPhone: “As a result of these stronger protections that require data encryption, we are no longer able to use the data extraction process on an iPhone running iOS 8 or later.” Although some residual risk of unknown vulnerabilities remains, this claim seems believable as far as it concerns retroactive circumvention of security defenses. Just as a locksmith can make a lock that will be as hard to break for its maker as for any other locksmith, a gadgetsmith can make gadgets without known backdoors or weaknesses that this gadgetsmith might exploit. This is challenging, but possible.

However, the security of any encryption mechanism hinges on the integrity of key components, such as the encryption algorithm, its implementation, auxiliary functions like key generation and their implementation, and the execution environment of these functions. The maker of a gadget can always weaken it for future access.

Should Apple be allowed to make and sell devices with security mechanisms so strong that neither Apple nor anyone else can break or circumvent them in the course of legitimate investigations? This is the real question here, and a democratic state based on justice and integrity has established institutions and procedures to come to a decision and enforce it. As long as Apple does not rise above states and governments, they will have to comply with laws and regulations if they are not to become the VW of Silicon Valley.

Thus far we do not understand very well how to design systems that allow legitimate law enforcement access while also keeping data secure against illiegitimate access and abuse or excessive use of legitimate means. Perhaps in the end we will have to conclude that too much security would have to be sacrificed for guaranteed law enforcement access, as security experts warn almost in unison, or that a smartphone is too personal a mind extension for anyone to access it without its user’s permission. But this debate we must have: What should the FBI be allowed to access, what would be the design implications of guaranteed access requirements, and which side effects would we need to consider?

For all we know, security experts have a point warning about weakening what does already break more often than not. To expectat that companies could stand above the law because security, however, is just silly.

PS, remember Clarke’s first law: “When a distinguished but elderly scientist states that something is possible, he is almost certainly right. When he states that something is impossible, he is very probably wrong.”

PPS: Last Week Tonight with John Oliver: Encryption


How much security do we gain from Trusted Computing?

My colleague Jan is going to present our paper Attacking the BitLocker Boot Process at Trust 2009 (Oxford, 6th – 8th April). The paper is an improved version of the draft we presented at ETISS.

BitLocker is the volume encryption function built into recent versions of MS Windows. It is capable of using a Trusted Platform Module if the PC has one. Our paper describes five attack scenarios that using the TPM does not prevent from succeeding. Some are based on particular features of BitLocker while others rely on the implementation of authenticated booting that is currently used in Trusted Computing.

All five scenarios seem suitable for targeted attacks and require that the attacker can access the target system twice. Executing such attacks is thus roughly as complex as installing a hardware keylogger in the system and returning later to retrieve the sniffed password along with the encrypted data – or just the machine in a condition that permits decrypting the data on disk.

What makes our attacks interesting is the fact that they can be implemented in software. Ideally, Trusted Computing should reliably prevent such attacks from succeeding. However, a TPM does not prevent software from being modified. The TPM only compares measured states with stored reference data. This leaves several holes. For instance one can temporarily modify software and later restore the reference state, or modify boot components before the reference state is determined and stored inside the TPM. While such actions are useless in an opportunisitc attack where the attacker just grabs an unattended machine unprepared, a dedicated attacker might take advantage of them.

Update 2009-12-03: There is a more comprehensive explanation in a later post.