On the Difficulty of Software-Based Attestation of Embedded Devices Claude Castelluccia Aurélien Francillon Daniele Perito INRIA Rhône-Alpes {ccastel,francill,perit o}@inrialpes.fr Claudio Soriente University of California, Irvine [email protected]paper review jordan jump
19
Embed
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.
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
On the Difficulty of Software-Based Attestation ofEmbedded Devices
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 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 #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