On the Difficulty of Software-Based Attestation of Embedded Devices Claude Castelluccia Aurélien Francillon Daniele Perito INRIA Rhône-Alpes Claudio Soriente University of California, Irvine paper review jordan jump

introduction presentation outline introduction paper summary critique

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

paper summary one slide synopsis 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 outline assumptions and previous work generic attacks – return-oriented rootkit – code compression difficulties with specific attestation proposals – SWATT – ICE-based

paper summary assumptions/previous work 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 assumptions/previous work 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 generic attacks 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 generic attacks 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 generic attacks 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 issues time-based attestation 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 issues time-based attestation 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 issues ICE-based attestation 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 issues ICE-based attestation 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 #1 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 #2 Compression attack implementation doesn’t include decompression routine in sizes? – Decompression routine: 1707 program memory, 2565 data memory – Compression from bytes to – 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 #3 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 #4 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

! ⊕ ?