Remote Software-based Attestation for Wireless Sensors

1. Remote Software-based Attestation for Wireless Sensors July 13, 2005 Mark Shaneck, Karthikeyan Mahadevan Vishal Kher, Yongdae Kim Department of Computer Science University of Minnesota

2. Introduction • Securing sensors in critical applications is important • E.g. military applications • Compromise of a sensor can enable attacker to inject false sensing information • Compromise of shared keys can enable attacker to compromise secure communications

3. Attestation • How to detect compromise? Attest! • Ensure that the contents of the memory are unchanged • Detects sensor compromise that involves a modification of the program memory • Compute a checksum of the memory contents

4. Naïve Attestation Model Program Memory of Sensor • Attestation routine reads memory and computes a checksum • Attacker must offset memory reads to avoid detection • Offsets incur measurable delay in execution • Attester can measure execution time to detect compromise Attest Malcode Unmodified Copy Of Original

5. Limitations • Suitable for directly connected devices • Slight execution delays can be accurately measured • What about remote attestation? • Code is located on device - attacker can use static analysis to analyze the code offline and insert conditional offsets • Slight execution delays cannot be accurately measured - overshadowed by unpredictable network latency

6. Remote Attestation • How can we adapt the attestation model to work in a remote setting? • Prevent attacker from analyzing attestation code offline • Send the attestation routine to the sensor • Make it different each time • Prevent attacker from modifying attestation code • Use techniques to make it difficult to statically analyze

7. Why Remote Attestation? • Is remote attestation really necessary? • Physical access to the sensors is not always feasible • Military setting - sensors are located in hostile, enemy territory • Building monitoring - sensors could be located in dangerous/inaccessible locations

8. Outline • Problem Scope • Building Blocks • Attestation Procedure Construction • Discussion/Conclusion

9. Assumptions • Base Station is secure • Base Station to sensor communication is encrypted/authenticated using a pairwise shared key • Base Station has an exact memory image of each sensor • Sensors do not have virtual memory • Sensors can receive and execute binary code

10. Threat Model • Attacker can perform any software based attack on the attestation routine • Attacker cannot tamper with hardware • Impersonation and DoS attacks are out of scope

11. Requirements • Resistance to • Replay • Prediction • Static Analysis • Loose dependence on execution time • Complete memory coverage • Efficient construction

12. Building Blocks • Randomization • Encryption • Self-Modifying Code • Obfuscation • Opaque Predicates/Pointer Aliasing • Junk Instructions

13. 0x40 = “inc %eax” Self Modifying Code 1: 0xFFF6 nop 2: 0xFFF7 nop 3: 0xFFF8 mov $0x05, %eax 4: 0xFFF9 inc %eax 5: 0xFFFA xor %eax, %eax inc %eax 6: 0xFFFB test %eax, %eax 7: 0xFFFC jnz 0xFFFF 8: 0xFFFD mov 0x40, 0xFFFA 9: 0xFFFE jmp 0xFFF9 10: 0xFFFF nop

14. Opaque Predicates • Conditions that always evaluate to true or always evaluate to false • Evaluation result is not obvious from static analysis • Can be formed through pointer aliasing • known to be an NP-hard problem

15. B A B A Opaque Predicates Does A == B ?

16. Junk Instructions • Full or partial machine code instructions • Full - distract analysis • Partial - confuse analysis

17. Attestation Routine Checksum Result Attestation Protocol Generate Attestation Routine Precompute Result Base Execute Attestation Routine Sensor Compare Results Measure Response Time

18. Attestation Routine Overview • Randomly step through program memory, adding values to the checksum result • Loop repeats O(n log n) times to ensure complete coverage of the memory • Routine will incorporate the building blocks to prevent attacks on the routine itself

19. Jump Junk Instructions Junk Instructions Seed Calculation Decryption Routine Jump Memory Reads & Jump Junk Instructions Main Attestation Loop Junk Instructions Encrypted Code Memory Reads & Jump Junk Instructions Hash Calculation Random Number Generator Self Modifying Code Attestation Routine

20. Security Analysis • What can the attacker do? • Replay response • Countered by randomization and random memory read pattern (seed) • Attacker must attack each code • Goal: force attacker to do intensive computation for each attestation procedure

21. What Attacker Must Do • Break Encryption • Find key, which is protected by opaque predicates • Determine Seed • Protected the same way as the encryption key • Examine self-modifying code • Rewrite this portion of the code to insert conditional offsets

22. Emulation • Attacker could install an emulator • Each read is directed to the appropriate offset • Computation is not I/O bound - significant overhead • Attack will be foiled with an appropriate choice of the timeout period

23. Extension • Fill sensor’s free memory space with random values (known to base station) • Attest entire memory contents • Malicious code would be limited in size by data memory • Copy of original is forced to be located in data memory

24. Related Work • SWATT (Seshadri et al.) • Genuinity (Kennell et al.) • Trusted Hardware - TPM, BIND, Copilot (Sailer et al., Shi et al., N. L. P. Jr et al.) • Obfuscation (Collberg et al., Barak et al., etc) • Program Evolution (F. Cohen) • Self-checksumming (Chang et al., Horne et al.) • Integrity Verification Kernel (D. Aucsmith)

25. Future Work • Implementation • Test and measure how lightweight/heavyweight the attestation procedure is • Measure and test to determine appropriate timeout period • Impersonation Attack • May require hardware support • Enhance the attestation protocol to work in multihop settings

26. Questions?