1. VIPER: Verifying the Integrity of PERipherals’ Firmware Yanlin Li, Jonathan M. McCune, and Adrian Perrig Carnegie Mellon University

2. Motivation Triulzi injected Malware into a Tigon NIC to eavesdrop on traffic (2008) Malware on NIC deploys malicious code into GPU, causing GPU to store and analyze data sent through NIC 2 OS PCI Bus

3. Motivation Chen injected key logger into Apple Aluminum keyboard firmware (2009) Buffer overflow vulnerability in Broadcom NIC was disclosed (2010) 3

4. Malware on Peripherals Eavesdrops on data handled by peripherals Modifies executable programs or scans data in main memory through DMA if IOMMU is not perfectly configured Spread malware to other peripherals through DMA Collaboration with malware on other peripherals through communication through PCI bus 4

5. Challenge & Problem Definition Open challenge to detect malware on peripherals –Limited memory and computational resources on peripherals –Hardware-based protection is expensive and impractical 5 Verifying the integrity of peripherals’ firmware, and guaranteeing absence of malware

6. Contributions 1.Systematically analyze malware features on computer peripherals 2.Propose VIPER, a software-only primitive to verify integrity of peripheral devices’ firmware 3.Propose a novel attestation protocol that prevents all known software-only attacks 4.Fully implement VIPER on a Netgear GA620 network adapter on an off-the-shelf computer 6

7. Outline Motivation Challenge & Problem Definition Assumptions & Attacker Model Software-Based Root of Trust VIPER Implementation Evaluation Related Work Conclusion 7

8. Assumptions & Attacker Model Assumptions –Physical attacks are out of scope –Verifier Program on host CPU is protected & trusted –Verifier program knows peripherals’ information Attacker Model –Compromises peripherals’ firmware –Controls remote machines to assist the compromised device –Cannot break cryptographic primitives 8

9. Verifier verifies checksum & timing results –Malicious code or operations either result in invalid checksum or require longer computation 9 Software-based Root of Trust Peripheral Host CPU Checksum Simulator Expected Firmware Timer Checksum Function Communi- cation Func Hash Func Verifier Code Verification Code 2. Untampered environment and Compute Checksum 1. nonce 3. checksum 4. hash

10. Proxy Attack Proxy Helper: a remote machine –Has a copy of correct firmware –Computes expected checksum for untrusted device 10 1. Random Nonce 4. Checksum Result Untrusted Device Verifier Proxy Helper 2. Random Nonce 3. Checksum Result

11. VIPER: Challenges Local Proxy Attack –Peer-to-peer communication between two peripherals through DMA –A faster peripheral helps a slower peripheral 11 Verify faster peripheral first! How to defend against a Remote Proxy Attack? Remote Proxy Attack –E.g., a NIC can communicate with a remote proxy helper over Ethernet

12. Verifier verifies checksum & timing results –Malicious code or operations either result in invalid checksum or require longer computation 12 Software-based Root of Trust Peripheral Host CPU Checksum Simulator Expected Firmware Timer Checksum Function Communi- cation Func Hash Func Verifier Code Verification Code 2. Untampered environment and Compute Checksum 1. nonce 3. checksum 4. hash

13. Latency-Based Attestation Protocol Time line Host CPU Peripheral T send T recv cpu T comp per Overhead Normal Case: nonce cksum 13 helper Time line Host CPU Peripheral Proxy Helper T send T recv cpu T send per T recv per Proxy Attack: nonce cksum T comp

14. Can we defend against a proxy attack all the time? Parameters –Computation time on proxy helper: –Communication time of a proxy attack: –Checksum computation time: –Timing accuracy on host CPU: 14 proxy T communication > peripheral T checksum > cpu T accuracy proxy T overhead proxy T communication peripheral T checksum cpu T accuracy proxy T communication peripheral T checksum proxy T overhead = _ proxy T comp = zero

15. Idle Times Between Multiple Nonce- Checksum Pairs Time line Host CPU Peripheral nonce1 cksum1 nonce2 15 Multiple nonce-checksum pairs to check all memory locations –Peripheral is idle between two nonce- checksum pairs Idle time computation cksum2 …… cksumn

16. Improvement Time line Host CPU Peripheral nonce1 cksum1 nonce2nonce3 16 Host CPU sends next nonce before the peripheral returns checksum The new nonce determines which checksum to return –Proxy helper cannot know which checksum to return, so has to return all checksum states that have been updated –Increases overhead of a proxy attack computation cksum2 …… cksumn computation

17. Latency-based attestation protocol –Multiple nonce-response pairs From faster peripheral to slower peripheral 17 VIPER PeripheralsHost CPU Checksum Simulator Expected Firmware Timer Checksum Function Communica tion Func Hash Func Verifier Code Verification Code Untampered environment and Compute Checksum hash nonce1 checksum1 nonce2 nonce3 Checksum N …

18. Implementation PCI-X Netgear GA620 NIC –Two MIPS Microcontrollers (200 MHz) –4 MB SRAM –Open Firmware Version 12.4.3 –Checksum and communication code: 656 MIPS instructions –SHA-1 Hash Function: 2 KB binary Sun Fire rack-mount server –Single-core AMD Opteron Processor –2 GB RAM, Two PCI-X slots –Linux 2.4.18 18

19. Netgear GA620 NIC SRAM (4 MB) CPU ACPU B Scratch- Pad Mem (16 KB) Scratch-Pad Mem (8 KB) Checksum Malicious codeBenign code 19

20. Verification Procedure SRAM (4MB) CPU ACPU B Scratch- Pad Mem (16 KB) Scratch-Pad Mem (8 KB) Checksum Hash Func 1. Verify entire scratch pad memory PC stays within the trusted code 2. Verify checksum and hash func 3. Compute Hash over Firmware Contents 20 1.CPU A and CPU B cannot access each other’s scratch-pad memory 2.Attestation can start from either A or B No hash func Only verify Scratchpad memory

21. Checksum Design 32 checksum blocks All 31 available registers are used –No extra registers for malicious operations Strong-ordered AND, XOR operations Includes PC, DP, other checksum states, memory contents Each checksum block fits into a cache line –Instruction Cache: 64 Bytes (16 MIPS instruction) –Additional code will cause more cache miss 21

22. Evaluation Various Attacks –Ethernet-Based Proxy Attack –Data Pointer (DP) Forging Attack –Program Counter (PC) Forging Attack We implemented all three attacks –Real Ethernet-Based Proxy Attack: 43 us –Theoretical Fastest Proxy Attack over 1 Gbps Ethernet: 1.2 us –DP/PC Forging Attack: 5 extra MIPS instructions and 2 more cache misses 22

23. Evaluation Results 23 Benign Case Threshold (4.5% over benign case) Various Attacks

24. Related Work L. Duflot, Y.-A. Perez, and B. Morin. Run-time firmware integity verification: what if you can not trust your network card? In CanSecWest, 2011. Y. Li, J. M. McCune, and A. Perrig. SBAP: Software-Based Attestation for Peripherals. Trust 2010. F.L. Sang, V. Nicomette, Y. Deswarte, and L. Duflot. Atteaues DMA peer-toppeer et contremeasures. SSTIC, 2011. K. Chen. Reversing and exploiting an Apple firmware update. In Black Hat, 2009. L. Duflot, Y.-A. Perez, G. Valadon, and O. Levillain. Can you still trust your network card? CanSecWest, 2010. A. Seshadri, A. Perrig, L. van Doorn, and P. Khosla. SWATT: SoftWare-based ATTestation for embedded devices. Oakland, 2004. M. Shaneck, K. Mahadevan, V. Kher, and Y. Kim. Remote software-based attestation for wireless sensors. ESAS, 2005. A. Seshadri, M. Luk, E. Shi, A. Perrig, L. van Doorn, and P. Khosla. Pioneer: Verifying Integrity and Guaranteeing Execution of Code on Legacy Platforms. SOSP, 2005. C. Castelluccia, A. Francillon, D. Perito, and C. Soriente. On the difficulty of software- based attestation of embedded devices. CCS. 2009. A. Perrig and L. van Doorn. Refutation of “on the difficulty of software-based attestation of embedded devices”. http://sparrow.ece.cmu.edu/group/pub/perrig- vandoorn-refutation.pdf, 2010. 24

25. Conclusion Detecting malware on peripherals’ firmware becomes increasingly important Extend previous software-based root of trust mechanisms to defend against proxy attacks Implementation & evaluation on a Netgear GA620 NIC Anticipate that these techniques will make software-based root of trust practical on current platform 25

26. 26