Mikhail Atallah, Eric Bryant, John Korb, and John Rice Arxan Technologies

1. Binding Software to Specific Native Hardware in a VM Environment: The PUF Challenge and Opportunity Mikhail Atallah, Eric Bryant, John Korb, and John Rice Arxan Technologies

2. Problem Statement • How to enforce policies that require software to run on a particular set of hardware? • Problem: Virtualization provides an easy way of bypassing common SW-HW binding methods • Sketch of ideal solution • Identify HW properties that cannot be simulated • Tie these properties to critical functionality of the SW such that: • Replay attacks are thwarted • Separation of SW from HW will break functionality • Reverse-engineering or knowledge of method/protocol does not reveal special HW properties • Example use cases • DRM (e.g., license management, anti-piracy) • Military (e.g., prevent rehosting in the event of a battlefield loss)

3. What is a PUF? • Physically Unclonable Function (PUF) • Cleverly exploits the inevitable variability that arises in the manufacture of complex physical objects • Two hardware chips produced from the same blueprint, same batch and at the same foundry, will have very different PUF responses • Given a challenge C, it is impossible to obtain the correct response R from C without the physical presence of the PUF • There is no software that encapsulates the PUF response and that can be used to mimic the presence of the actual physical hardware • A pair Ci,Ri reveals negligible information about what the response Rjto another challenge Cj will be

4. Example of PUF Binding • Goal: Modify software S to produce a new version of it (called S’) that is functionally equivalent to S as long as the occasional challenges issued by S’‘ get responses that only the authorized hardware H can produce • Assumptions: (1)S includes, as part of its functionality, the use of RSA encryption with a public key e, (2) The modifications of S to create S’ are made by a trusted party. • Note: The modifications described for turning S into S’ are such that, whereas S contains e and the RSA modulus n, the resulting S’ no longer contains e. We use p and q to denote the two large RSA primes; of course neither p nor q are stored in either S or S’

5. Example (cont.) • We generate from H a large (but reasonable) number of challenge-response pairs Ci, Ri. The software is modified so as to store all of the Cis (but not the Ris). • We also store in the software, associated with every Ci, the following value R’i: R’i = e ∗ Ri−1 mod (p − 1)(q − 1) where Ri−1 denotes the multiplicative inverse of Rimodulo (p−1)(q−1). Recall that the entity generating S’ from S is trusted.

6. Example (cont.) • We remove the key e from S and replace every use of the encryption of (say) a message M using e as key, by the following actions: • (a) A triplet Ci, M, n is sent to H, where the challenge Ciis randomly selected from those stored in the software S’ • (b) H uses Ci to generate the PUF response Rithen encrypts M using Rias key: ERi(M) = MRimod n and sends the result to S’. Note that these actions by H are the same for every S’and do not require H to store information specific to S’ • (c) S’ encrypts the received ERi(M) one more time, using Ri’ as key: ERi(M)Ri’ = MRi*e*Ri-1= Me mod n which is the desired encryption of M with e as the key.

7. Security Analysis • Chosen-plaintext attack • For a complete compromise, the adversary must be able to recover e from the composite number R’iand the observedtraffic between S’ and H. • Non-trivial attack; considerable effort and resources required • Replay attack • For a given message M, fix the challenge Ci and observe the response, ERi(M), from H • ERi(M) can then be replayed to the software to enable encryption of the same message M on a different hardware instance • Only effective for messages that have already been seen (i.e., new messages cannot be encrypted by a “cracked” S’ w/o PUF available) • Note, one can avoid many problems by simple protocols to verify standard messages

8. Security Analysis (cont.) • PUF server attack • User buys single legitimate copy of software, bound to a particular PUF response • Run multiple illegitimate copies on different hardware, using for each a virtualization layer that routes challenges to a single hardware instance that acts as a “PUF Server” • Not feasible in all situations, e.g., field-deployed systems • Effective attacks must be addressed; possible mitigations include • Insert an intermittent “call home” feature to indicate when and where the software is running • Leverage a Security VM to monitor other VMs running in a server environment (e.g., VMSafe API) • Use software/system “fingerprints” for additional identification of the software running • Tamperproof the software “environment” of the PUF response

9. Conclusions • PUFs present an interesting opportunity for binding software to hardware, even in the presence of virtualization • Future Work • Identify types of computations whose presence in software would facilitate binding that software to a PUF • Must satisfy the requirement that the hardware’s response involves similar computations for all such softwares • The computations should operate on dynamic data in order to mitigate replay attacks • Integration of PUF protection into the overall protection of software