Affiliation:
1. Department of Computer Science, University of California, Santa Barbara
2. Department of Computer Science, University of Chicago
Abstract
Most architectures are designed to mitigate the usually undesirable phenomenon of device wearout. We take a contrarian view and harness this phenomenon to create hardware security mechanisms that resist attacks by statistically enforcing an upper bound on hardware uses, and consequently attacks. For example, let us assume that a user may log into a smartphone a maximum of 50 times a day for 5 years, resulting in approximately 91,250 legitimate uses. If we assume at least 8-character passwords and we require login (and retrieval of the storage decryption key) to traverse hardware that wears out in 91,250 uses, then an adversary has a negligible chance of successful brute-force attack before the hardware wears out, even assuming real-world password cracking by professionals. M-way replication of our hardware and periodic re-encryption of storage can increase the daily usage bound by a factor of M.
The key challenge is to achieve practical statistical bounds on both minimum and maximum uses for an architecture, given that individual devices can vary widely in wearout characteristics. We introduce techniques for architecturally controlling these bounds and perform a design space exploration for three use cases: a limited-use connection, a limited-use targeting system and one-time pads. These techniques include decision trees, parallel structures, Shamir's secret-sharing mechanism, Reed-Solomon codes, and module replication. We explore the cost in area, energy and latency of using these techniques to achieve system-level usage targets given device-level wearout distributions. With redundant encoding, for example, we can improve exponential sensitivity to device lifetime variation to linear sensitivity, reducing the total number of NEMS devices by 4 orders of magnitude to about 0.8 million for limited-use connections (compared with 4 billion if without redundant encoding).
Publisher
Association for Computing Machinery (ACM)
Reference68 articles.
1. Apple firmware updates. https://blog.trailofbits.com/2016/02/17/apple-can-comply-with-the-fbi-court-order/. Apple firmware updates. https://blog.trailofbits.com/2016/02/17/apple-can-comply-with-the-fbi-court-order/.
2. Apple iOS Hardware Assisted Screenlock Bruteforce. http://blog.mdsec.co.uk/2015/03/bruteforcing-ios-screenlock.html. Apple iOS Hardware Assisted Screenlock Bruteforce. http://blog.mdsec.co.uk/2015/03/bruteforcing-ios-screenlock.html.
3. IEEE Standard Specifications For Public Key Cryptography. http://grouper.ieee.org/groups/1363/. IEEE Standard Specifications For Public Key Cryptography. http://grouper.ieee.org/groups/1363/.
4. iOS Security Guide. https://www.apple.com/business/docs/iOS_Security_Guide.pdf. iOS Security Guide. https://www.apple.com/business/docs/iOS_Security_Guide.pdf.
5. One-time pads (OTP). http://users.telenet.be/d.rijmenants/en/onetimepad.htm. One-time pads (OTP). http://users.telenet.be/d.rijmenants/en/onetimepad.htm.