jordan jump
On the Difficulty of Software-Based Attestation of
Embedded Devices
Claude Castelluccia
Aurélien Francillon
Daniele Perito
INRIA Rhône-Alpes
{ccastel,francill,perito}@inrialpes.fr
Claudio Soriente
University of California, Irvine csorient@ics.uci.edu

introduction
• introduction
• paper summary
• critique

introduction
• BS CprE, 2005, ISU
• Rockwell Collins, Cedar Rapids, IA
• Software Engineer, Embedded focus

paper summary
• If a remote node can only use software to prove that it is still running as it should, it is difficult to do so.
• The paper shows two general attack methods that make the node appear to be uncompromised when required to prove itself.
• It also shows attacks against specific techniques, and how modifications can prevent the attacks.

paper summary
• assumptions and previous work
• generic attacks
– return-oriented rootkit
– code compression
• difficulties with specific attestation proposals
– SWATT
– ICE-based

paper summary
• Software code attestation
– Remotely verify a node has not been compromised
– Verify via memory checksum + nonce
• Attack goals
– Modify executable memory
– Still pass attestation

paper summary
• General assumptions
– Compromised device doesn’t interact with other malicious nodes
– Unmodified hardware (not tamper-resistant)
– Verifier aware of configuration
• Hardware: MicaZ
– COTS wireless sensor
– Atmel AVR
– Harvard memory architecture (program, data, and external memories)
• Paper contents applicable to similar micro-controllers

paper summary
• return-oriented programming (ROP)
• executes existing code (no code changes necessary)
• Arbitrary functionality (given large enough code size)
• Manipulates program stack so return executes desired code
• Segment starts near a return statement, segments strung together
• If existing code known, compilers make creation of ROP easy
– Attack uses ROP rootkit

paper summary
• ROP root-kit attack
• Start of attestation code modified to initiate cleanup sequence
• Cleanup modifies return address on stack
• Attestation occurs
• Returns to ROP that initiates re-infection code

paper summary
• Compression attack
– Previously, unused program space filled with pseudorandom values so attacker cannot use them.
– Compress code to make space for attack code
– Decompressed on-the-fly during attestation
– Achieved average of 11.6% compression

paper summary
• SoftWare-based ATTestation (SWATT), Seshadri et. al.
• Introduces time-to-respond
• Attacker would slow down function if redirecting memory
• Relies on fastest redirection and checksum known
– Paper introduces faster redirection
• Requires half program memory unused
• Redirect 0x11xx…xx accesses to 0x10xx…xx and store malicious code in 0x11xx…xx
• 2 cycles vs previously fastest 3 cycles.
• Still detectable .. relies on processor capabilities
– Porting SWATT required rewrite of algorithm, changed timing

paper summary
• Preventing rootkit attack on SWATT
– Data memory not verified, allows attack
– Verify memory or clean memory after attestation
– Verification difficult
• Architecture uses different address space, instructions
• Pseudorandom verification requires branch
• Unpredictible contents (registers, I/O, stack)
– Clean memory and reboot
• Disrupts rootkit attack, not shadow attack

paper summary
• Indisputable Code Execution (ICE)
– Self-checksumming function
– Bijective function selects order of memory locations
– 10x16bit registers (C) used to calculate result:
PC = Program Counter, SR = Status Register
• Several protocols based on ICE
• Not all processors support PC access

paper summary
• ICE-based vulnerability
– PC xor current address (move both)
– 0xA0000 xor 0xC5678 = 0x65678
– 0x20000 xor 0x45678 = 0x65678
• Root cause: weak mixing in checksum routine

critique
• Paper briefly dismisses self-modify code attestation
– Claim self-modifying code is too slow and complex/impossible to implement on flash-based device.
– Similar technique successfully used for rootkit

critique
• Compression attack implementation doesn’t include decompression routine in sizes?
– Decompression routine: 1707 program memory, 2565 data memory
– Compression from 31836 bytes to 27368
– Claim 2961 bytes free after 512 canonical huffman tree and 995 for checkpoints. Doesn’t account for decompression routine.
– Should be 1254 free. Data memory is only 4k; decompression routine uses substantial portion (could use measurement storage)
– Compression algorithm not included (only direct-access attack?)

critique
• Attacks preventable/detectable using simple or known methods
– Compression attack detectable by SWATT
– SWATT shadowing attack solved by filling empty space
– Root-kit evicted by re-booting during attestation

critique
• Rootkit requires knowledge of program contents
– Static analysis to tailor attack to software
– Suitable only for directed attack
• ICE-attack needs to be carefully crafted if modified routine

!
⊕ ?
jmjumps@iastate.edu