Physical Unclonable Functions (PUFs) have not only been suggested as new key storage mechanism, but - in the form of so-called "Strong PUFs"- also as cryptographic primitives in advanced schemes, including key exchange, oblivious transfer, or secure multi-party computation. This notably extends their application spectrum, and has led to a sequence of publications at leading venues such as IEEE S&P, CRYPTO, and EUROCRYPT in the past[3,6,10,11,29, 41]. However, one important unresolved problem is that adversaries can break the security of all these advanced protocols if they gain physical access to the employed Strong PUFs after protocol completion [41]. It has been formally proven[49] that this issue cannot be overcome by techniques on the protocol side alone, but requires resolution on the hardware level - the only fully effective known countermeasure being so-called Erasable PUFs. Building on this work, this paper is the first to describe a generic method how any given silicon Strong PUF with digital CRP-interface can be turned into an Erasable PUFs[36]. We describe how the Strong PUF can be surrounded with a trusted control logic that allows the blocking (or "erasure") of single CRPs. We implement our approach, which we call "GeniePUF", on FPGA, reporting detailed performance data and practicality figures. Furthermore, we develop the first comprehensive definitional framework for Erasable PUFs. Our work so re-establishes the effective usability of Strong PUFs in advanced cryptographic applications, and in the realistic case adversaries get access to the Strong PUF after protocol completion.

Erasable pufs, Geniepufs, Physical unclonable functions (pufs), Puf re-use model, Reconfigurable pufs
doi.org/10.1145/3411504.3421215
ACM Workshop on Attacks and Solutions in Hardware Security
Centrum Wiskunde & Informatica, Amsterdam, The Netherlands

Jin, C, Burleson, W, van Dijk, M.E, & Rührmair, U. (2020). Erasable PUFs: Formal treatment and generic design. In ASHES 2020 - Proceedings of the 4th ACM Workshop on Attacks and Solutions in Hardware Security (pp. 21–33). doi:10.1145/3411504.3421215