ReDABLS: Revisiting Device Attestation with Bounded Leakage of Secrets (Transcript of Discussion)

Abstract

Our work on device attestation with bounded leakage of secrets (DABLS) started in early 2010, when Adrian Perrig described an idea he had in an area that interests me quite a bit, namely how to obtain desirable security properties without relying on secrets. Briefly, he suggested that a Verifier might be able to authenticate a remote device, D, even if the device is contaminated with malicious software (malware) that could access any of D’s secrets. If both device D and Verifier could be initialized with the same large pool of high entropy secrets, S, and if the device’s output bandwidth, D _ban , could be appropriately limited, then after deployment the device malware could not leak the entire secret pool S to a network collaborator before the Verifier would cause the device software to update and overwrite pool S to a new verifiable state S′ = f(n,S). Here, n is a Verifier-sent public nonce that has to be used in the pool update and f is the update function. The Verifier would send a fresh nonce to D every T _s units of time, the device would use T _up units of time to compute the pool update f(n,S) and respond to the Verifier’s challenge. The response would be computed with a message authentication code (MAC) function using the new secret S′, namely MAC(S′, constant). Adrian thought that we could find an update function f, which would preserve pool entropy, prevent the external malware collaborator from ever discovering an entire secret pool S, and successfully masquerading device D in response to a Verifier’s nonce-based challenge. Clearly, neither the device malware nor its external collaborator could predict a nonce n and construct a future state of pool S, given that the external collaborator’s power is bounded.