SWATT

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

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

3. 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…)

4. 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

5. 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)

6. 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

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

8. 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

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

10. 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

11. 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 successfulVerification will fail with high probability if the memory contents of the device differs from the expected content

12. 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)

13. 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

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

15. 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

16. SWATT Desired verification process properties • The PRG should be optimized for CPU architecture (rc4 for 8bit, Helix for32 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 accessedCoupon 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

17. 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’

18. 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

19. SWATT Implementation • Architecture: • Atmel AT-MEGA163L microcontroller • 8-bit Harvard Architecture • 16K of program memory and 1K of data memory • RISC ISA • PRG:RC4 - first 256 bytes dropped to avoid known attacks8 RC4 bits are concatenated with current checksum value (for 16 bit address)

20. SWATT Implementation– cont. • Design Goals: • Fast FastFast !!! (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 vectorfor i ← 1 to m do //Construct address for memory read Ai ← (RC4i ≪ 8) + C((j−1) mod 8) //Update checksum byteCj ← Cj + (Mem[Ai] ⊕ C((j−2) mod 8) + RC4i−1)Cj ← rotate left one bit(Cj) //Update checksum index j ← (j + 1) mod 8return C

21. SWATT Implementation – Cont. • Assembly Generate ith member of random sequence using RC4 zh← 2 ldizh, 0x02 r15← *(x++) ld r15, x+ yl← yl + r15 add yl, r15 zl← *y ld zl, y *y← r15 st y, r15 *x← r16 st x, r16 zl← zl + r15 add zl, r15 zh← *z ld zh, z Generate 16-bit memory address zl← r6 movzl, r6 Load byte from memory and compute transformation r0 ←*z lpm r0, z r0 ←r0 ⊕ r13 xor r0, r13 r0 ←r0 + r4 add r0, r4 Incorporate output of transformation into checksum r7 ←r7 + r0 add r7, r0 r7 ←r7 << 1 lsl r7 r7 ←r7 + carry bit adc r7, r5 r4 ←zhmov r4, zh • Manually optimized • 16 instructions, 23 machine cycles. • If statement (compare + branch) = 3 cycles -> 13 % overhead • No mathematical argument that further optimization is impossible

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

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

24. 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)

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

26. 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

27. SWATT Questions