On the Difficulty of Software-Based Attestation of Embedded Devices Claude Castelluccia Aurélien...

On the Difficulty of Software-Based Attestation ofEmbedded Devices

Claude CastellucciaAurélien Francillon

Daniele PeritoINRIA Rhône-Alpes

{ccastel,francill,perito}@inrialpes.fr

Claudio Soriente

University of California, Irvinecsorient@ics.uci.edu

paper reviewjordan 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 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

!⊕?jmjumps@iastate.edu