Archiv der Kategorie: Trusted Computing

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

Soziale Kontrolle, technisch unterstützt

»Lance Maggiacomo was out of work, bored and lonely when he started hiding his online relationships from his wife.

There was no affair, only chatting through e-mail, yet it felt like cheating just the same.

A few years later, a reformed Maggiacomo has an in-house check on his impulses. He and his wife Lori, like other Christian couples around the country, share one e-mail account as a safeguard against the ever-expanding temptations of the Internet.«

Christian couples share e-mail addresses to stay faithful)

By the way,

… if it’s worth the effort, this TPM hack may nicely complement an Evil Jan attack. First the attacker carries out the Evil Jan attack to obtain any user-provided key material, next he takes the machine away and cracks the TPM for the rest of the key material. Usually there are easier ways after the initial step, but if, for whichever reason, they should become infeasible, going for the TPM might be an option.

Leaving the TPM exposed to physical attacks while protecting the RAM of a system from wire access, DMA, and cold boot attacks would be a pretty stupid design error, though. But who knows?

The Evil Jan Attack

[See only posts in English]

Microsoft’s BitLocker is, for all we know, a proper disk encryption software. It encrypts data at rest against attacks originating outside the running system. If you use BitLocker and your computer is stolen while turned off, there is essentially no way of reading data from the disk without having the proper key(s)—your BitLocker PIN, a key file on a USB stick, or both. If an attacker gets access to the machine while it is running, there may be ways of compromising it through Windows or in other ways, but such attacks are clearly outside the scope of disk encryption.

We know, however, another class of attacks against disk encryption: evil maid attacks. This term describes a general strategy rather than a particular implementation. If you leave your computer unattended, let’s say in a hotel room, an attacker, let’s say an evil maid, might manipulate it such that your data will be compromised as soon as you return and provide it with your encryption keys. There are various ways of doing so, for instance installing a hardware keylogger if your keys are based on passwords, or altering the unencrypted boot code to install a Trojan horse that will leak your keys later. The Evil Jan Attack weiterlesen

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.

Drunken Computing PARTIES Partition

Start of informative comment

The PARTIES Partition is a hidden partition on the hard drive that BIOS can use for additional storage space and as a virtual drive. In the PARTIES Partition, there is a small section called the BEER. Prior to turning control over to the PARTIES Partition, the BIOS must measure the BEER area into PCR[5].

The partition that is booted to in the PARTIES Partition must also have the initial IPL image code measured into PCR[4] prior to turning control over to this code.

End of informative comment

When executing, this is treated as IPL Code including the measurement of it even if the binary image is already measured into PCR[0].

TCG PC Client Specific Implementation Specification For Conventional BIOS Version 1.20 FINAL, Revision 1.00, page 62

(According to Google, this seems to be there at least since 2003.)

Sicherheitstipp: Drahtlos gegen Keylogger

Keylogger sind eine wachsende Bedrohung für die IT-Sicherheit. Ein Keyloger protokolliert alle Eingaben eines Benutzers: E-Mail, Passworte, PINs, TANs, Chatnachrichten und was sonst noch so alles über die Tastatur in den Computer gelangt. Besonders gefährlich sind Hardware-Keylogger. Sie laufen nicht als Programm auf dem Computer, sondern sie stecken unauffällig irgendwo im Verbindungskabel zwischen Tastatur und PC. Dort tun sie ihre Arbeit, bis jemand kommt und mit einem geheimen Kommando die gespeicherten Daten ausliest. Solche Keylogger werden weder von Antivirus- oder Antispywareprogrammen noch von der Trusted-Computing-Technologie erkannt.

Unser Sicherheitstipp:  Benutzen Sie stets drahtlose Tastaturen, dann kann Ihnen keiner einen Keylogger ins Kabel schmuggeln. Mit dem Problem konfrontiert, wird ein Datendieb mit hoher Wahrscheinlichkeit nach einem anderen, leichteren Ziel suchen und von Ihrem System ablassen.

BitLocker-Leitfaden veröffentlicht

Wir haben uns zusammen mit dem BSI die Partitionsverschlüsselung BitLocker Drive Encryption genauer angeschaut. Herausgekommen ist der Leitfaden BitLocker Drive Encryption im mobilen und stationären Unternehmenseinsatz. Das BSI hat auch eine Seite dazu und die gemeinsame Presseinformation gibt es hier.

BitLocker ist Bestandteil der Versionen Enterprise und Ultimate von Windows Vista. Mit Unterstützung des Trusted Platform Module (TPM) verschlüsselt BitLocker die Systempartition, demnächst ab Service Pack 1 auch beliebige andere Volumes (tatsächlich geht das jetzt schon, aber nur inoffiziell).

Die Kombination aus Plattenverschlüsselung und Trusted Computing hält jede Menge Stolpersteine bereit für den Anwender, der gleichzeitig an Vertraulichkeit, Benutzbarkeit und Verfügbarkeit interessiert ist. Ein Problem wurde bereits vor dem Erscheinen von Windows Vista heftig diskutiert: Multiboot-Systeme. Prinzipiell geht das auch mit BitLocker, solange man nicht mit einem Fremdsystem auf die BitLocker-Partition(en) zugreifen möchte. Es macht aber in der Praxis keinen rechten Spaß.

Unser Leitfaden zeigt eine Reihe weiterer Klippen und wie man sie umschifft. Die Sache mit dem gekühlten Speicher hat in dieser Form allerdings auch uns überrascht.

Und das steht drin (die Numerierung stimmt nicht ganz mit dem Leitfaden überein): BitLocker-Leitfaden veröffentlicht weiterlesen