SWATT A softwarebased attestation method for embedded devices

SWATT A software-based attestation method for embedded devices Arvind Seshadri, Adrian Perrig, Leendert van Doorn, Pradeep Khosla Tomer shani Topics in Information Security

Lecture outline Introduction • Problem definition, assumptions & model • SWATT • Future work •

Introduction Attestation!! Is that English? � Attestation is the ability to affirm to be correct, true, or genuine � We would like to provide the ability to verify the memory content of a device we are about to interact with � This is one way to establish the absence of malware (viruses worms, trojan horses…)

Introduction Computers have been around for a long time, why do we need this ability now? � It is expected that embedded devices will surround us in the not too far future: � Furniture, clothing & appliances, for automated checkout, inventory control… � Sensor networks deployed for monitoring the environment , agriculture, military applications… � This large scale deployment, means devices cannot be physically secured & may often be in a hostile surrounding

Introduction OK, but what’s so special about embedded devices? � Cost is a major issue, even a small increase in device cost leads to a significant increase in high volume production � Hardware solutions may be expensive (NGSCB, TCG) � Devices will typically have no virtual memory. (Kennel & Jamieson method)

Introduction So I’m convinced attestation is needed, but what does SWATT do? � Software based attestation method (can be used on legacy devices, no need for special hardware) � Attests the device code, static data & configuration settings � The verifier does not require direct (hardware) access to device memory

Introduction How SWATT works: A challenge response protocol Generate Random challenge Challenge (+ Attestation Routine) Precompute result Embedded Device Verifier Compare results Measure response time Challenge Result Execute Attestation Routine

Introduction Applications � Gas pumps – MOIT performs regular checkups, in which the mechanical properties of the pump are tested, currently impossible to attest software � Network printers – could be a significant breach in corporate security (eavesdropping, active attack ), administrator can use SWATT to attest code & configuration � Voting machines – there have been cases where software not certified by the state was used by electronic voting machines � Smart cards used to hold passwords – before entrusting passwords user could use SWATT to verify code

Lecture outline Introduction • Problem definition, assumptions & model • SWATT • Future work •

Definitions Naïve attempt: � Verifier sends a challenge, device uses challenge as MAC key & computes MAC on memory, result is returned to verifier ü Replay attack ü Pre-computation × Malware can cheat – empty memory content can be used to store malware & skipped during the MAC computation. Malware code could also move original code to another device which will be used for MAC computation

Definitions � � MAC is not good enough, can we find an effective verification procedure? What’s effective? If the memory contents of the device is the same as the value expected by the verifier the checksum will always be correct & verification will be successful Verification will fail with high probability if the memory contents of the device differs from the expected content

Assumptions � � � Verification procedure exists on the device (or downloaded prior to verification) Verifier knows the expected memory layout Verifier is intimately familiar with device HW � Clock speed � Memory architecture � Memory size � Instruction set (ISA)

Threat model � � Attacker has full control over the device memory Attacker does not modify the device HW � Increase memory size � Change memory access timing � Increase CPU clock speed � Attacker does not tamper with bios

Lecture outline Introduction • Problem definition, assumptions & model • SWATT • Future work •

SWATT General concept: � The random challenge is used to seed the pseudorandom number generator � Number are used to traverse memory & update MAC � Malware cannot predict which memory will be requested next (altered memory or original memory) � An extra if statement must be added to divert load operations from the altered memory � The increase in running time will be noticeable

SWATT Desired verification process properties � The PRG should be optimized for CPU architecture (rc 4 for 8 bit, Helix for 32 bit) � Resistance to replay & pre-computation attacks is achieved by seeding the PRG with a random challenge � High probability of detecting changes � Every memory location must be accessed Coupon collector problem shows that we need to make O(nln(n)), where n is the memory size � MAC should reflect changes to a single byte

SWATT Desired properties – Cont. � Small code size – an ‘if’ statement translates to a compare instruction + a conditional branch i. e. ~2 -3 CPU cycles. If this is to be noticeable the verification procedure should take few tens of CPU cycles (not inc. init & epilogue) � Optimized implementation – if attacker can find a more optimized implementation of the verification procedure it will be possible to conceal the extra ‘if’

SWATT Desired properties – Cont. � Non parallelizable – To prevent multiple devices from performing distributed computation, to solve this the actual memory access is based on the RNG & the current checksum value

SWATT Implementation � Architecture: � Atmel AT-MEGA 163 L microcontroller � 8 -bit Harvard Architecture � 16 K of program memory and 1 K of data memory � RISC ISA � PRG: RC 4 - first 256 bytes dropped to avoid known attacks 8 RC 4 bits are concatenated with current checksum value (for 16 bit address)

SWATT Implementation– cont. � Design Goals: Fast !!! (No mac optimized for 8 bit) reduce collision probability ( 64 bit checksum ) Avalanche effect - a changed memory location should perturb all fields of the checksum. � Non parallelizable � � Algorithm: Verify(m) //in: iterations, out: Memory checksum //C = checksum vector, j = index in checksum vector for i ← 1 to m do //Construct address for memory read Ai ← (RC 4 i ≪ 8) + C((j− 1) mod 8) //Update checksum byte Cj ← Cj + (Mem[Ai] ⊕ C((j− 2) mod 8) + RC 4 i− 1) Cj ← rotate left one bit(Cj) //Update checksum index j ← (j + 1) mod 8 return C

SWATT Implementation – Cont. � Assembly Generate ith member of random sequence using RC 4 zh← 2 ldi r 15← *(x++) yl← yl + r 15 zl← *y *y← r 15 *x← r 16 zl← zl + r 15 zh← *z Generate 16 -bit memory address zl← r 6 Load byte from memory and compute transformation r 0 ←*z r 0 ←r 0 ⊕ r 13 r 0 ←r 0 + r 4 Incorporate output of transformation into checksum r 7 ←r 7 + r 0 r 7 ←r 7 << 1 r 7 ←r 7 + carry bit r 4 ←zh � � zh, 0 x 02 ld r 15, x+ add yl, r 15 ld zl, y st y, r 15 st x, r 16 add zl, r 15 ld zh, z mov zl, r 6 lpm r 0, z xor r 0, r 13 add r 0, r 4 add r 7, r 0 lsl r 7 adc r 7, r 5 mov r 4, zh Manually optimized 16 instructions, 23 machine cycles. If statement (compare + branch) = 3 cycles -> 13 % overhead No mathematical argument that further optimization is impossible

SWATT Implementation summary � Optimization � � � Resistant to replay & pre-computation � � Additional if will present an overhead of 13 % Non parallelizable � � Coupon collector 64 bit checksum Avalanche effect Small code size � � RNG seeded from verifier High probability of detecting changes � � Optimized PRG (RC 4) Optimized checksum (proprietary) Address is derived from RNG & memory content Optimized implementation

SWATT Experimental results � � Genuine software Attacker’s version Single byte of modified code � Single ‘if’ statement in the verification procedure �

SWATT Considerations for practical use: � Number of iterations � Architecture: � Harvard: only program memory (code + static) needs to be verified. Different read latencies can be serve an attacker � Von – Neumann: code & data share memory. How do we handle the data section (stack, sensor readings…) Software must be designed to have checkpoints where data state is predictable Verifier can download data section � Empty memory regions: � should be filled with a random pattern (so that an attacker cannot suppress the read operation & save time)

Lecture outline Introduction • Problem definition, assumptions & model • SWATT • Future work •

Future work � Checksum / RNG � Will � vary between platforms Code Optimization � Theoretical framework to proof maximum optimization � How to perform device attestation remotely � Untrusted network � Unpredictable networking latencies � Devices with sophisticated architecture � Vitrual Memory � Branch prediction

SWATT Questions