back

Thwarting Evil Maid Attacks

Physically Unclonable Functions for Hardware Tamper Detection

If you suspend your transcription on amara.org, please add a timestamp below to indicate how far you progressed! This will help others to resume your work!

Please do not press “publish” on amara.org to save your progress, use “save draft” instead. Only press “publish” when you're done with quality control.

Video duration
00:58:27
Language
English
Abstract
Increasingly, users and their computing hardware are exposed a range of software and hardware attacks, ranging from disk imaging to hardware keylogger installation and beyond. Existing methods are inadequate to fully protect users, particularly from covert physical hardware modifications in the "evil maid" scenario, and yet are very inconvenient. Victims include governments and corporations traveling internationally (e.g. China), anti-government activists in places like Syria, and anyone who is a target of a motivated attacker who can gain physical access.

Physically Unclonable Functions, combined with a trusted mobile device and a network service, can be used to mitigate these risks. We present a novel open-source mobile client and network service which can protect arbitrary hardware from many forms of covert modification and attack, and which when integrated with software, firmware, and policy defenses, can provide greater protection to users and limit potential attack surface. We'll also be showing video of an unreleased tool to the public utilized by surveillance teams.

Additional Notes for our talk:

1) The attack addressed is an entire class of hardware, firmware, and software attacks around the attacker gaining surreptitious access and modification (of hardware/firmware/software) on one or more occasions, followed by the authorized user making normal use of the device after these modifications.

A software-only attack can be addressed through "trusted boot" or "measured boot" systems (e.g. what TCG does). Firmware attacks are generally not addressed by most measured boot processes, but that's just an implementation problem. The most novel category of attack is defeating the addition of hardware components or modification of hardware components, which becomes a desirable attack once software/firmware are locked down.

One scenario is that an investor flies to China with a laptop and a cellphone and intends to remain in the country for several weeks, conducting business online as well as in person. On several occasions, the investor leaves his laptop in his hotel room, while taking his cellphone with him at all times. Adversary agents, as hotel staff, enter the room and make modifications to hardware, with the intent of circumventing either local software protections (cloning drives, capturing pass phrases, etc.) or subverting network resources later accessed, either while the investor remains in China or after he returns to the home office with the laptop.

In-depth physical analysis of the hardware, conducted at home base, can often discover hardware modifications. Best current practice is to quarantine "travel" machines and never allow them back on high security networks. Unfortunately, this leaves the user exposed for the entire duration of a single trip -- in some situations the entire transaction happens during a trip, so all sensitive information must be protected for that trip.

PUFs and our network verification can be used to effectively "sign" hardware in the field in a way which can be automatically verified and verified interactively with a "home base" network service. This lets network resources be protected continuously; before every access, the client device's integrity can be checked and attested.

An interesting strategy is to not travel with any sensitive hardware (beyond the cellphone) and buy random laptops at the destination, enroll them in the service while at the destination, provision them with services, and ensure no subsequent unauthorized hardware/firmware/software changes can be made, using the same system.

2) PUFs

The PUFs are functions which can't be (tractably) cloned. Unfortunately, virtually none of these can be inspected/verified/attested directly by an unaided human -- anything which is a simple serial number seal or other human-verifiable thing can be fairly trivially counterfeited.

The PUFs make use of large amounts of random and changing data, created through physically random processes which are impossible to (tractably) reproduce. The innovation is to use a user's cellphone and a network service as the verifier -- the phone can remain in the user's physical custody at all times, and by splitting the verification between the phone (on site with the user) and a network service acting as gatekeeper to protected network resources, the system can be protected from various attacks.

The PUFS that we take advatage of are that of the physical systems themselves. When a device is created during manufacture a multitude of processes are utilized to produce the compute device. As it turns out reproducibility on the sub millimetre scale of a identical compenents such as a laptop case is excessively difficult to clone/counterfit/interact with without disturbing the previous state. We take advantage of these flaws to aid the user in detecting modification to their computing devices through photography and other standard low cost tamper evidencing devices which a untrained user can deploy in the field.

Clear technical documentation w/ photos explaining why it is incredibly difficult with current attack methods to perfectly clone manufactured parts which on the surface are indistinguishable from another manufactured assembly.

Talk ID
5600
Event:
30C3
Day
4
Room
Saal 1
Start
12:45 p.m.
Duration
01:00:00
Track
Security & Safety
Type of
lecture
Speaker
Eric Michaud
Ryan Lackey
Talk Slug & media link
30C3_-_5600_-_en_-_saal_1_-_201312301245_-_thwarting_evil_maid_attacks_-_eric_michaud_-_ryan_lackey
English
0.0% Checking done0.0%
0.0% Syncing done0.0%
0.0% Transcribing done0.0%
100.0% Nothing done yet100.0%
  

Work on this video on Amara!

English: Transcribed until

Last revision: 2 years, 2 months ago