Non-invasive Techniques Towards Recovering Highly Secure Unclonable Cryptographic Keys and Detecting Counterfeit Memory Chips

Abstract

Due to the ubiquitous presence of memory components in all electronic computing systems, memory-based signatures are considered low-cost alternatives to generate unique device identifiers (IDs) and cryptographic keys. On the one hand, this unique device ID can potentially be used to identify major types of device counterfeitings such as remarked, overproduced, and cloned. On the other hand, memory-based cryptographic keys are commercially used in many cryptographic applications such as securing software IP, encrypting key vault, anchoring device root of trust, and device authentication for could services. As memory components generate this signature in runtime rather than storing them in memory, an attacker cannot clone/copy the signature and reuse them in malicious activity. However, to ensure the desired level of security, signatures generated from two different memory chips should be completely random and uncorrelated from each other. Traditionally, memory-based signatures are considered unique and uncorrelated due to the random variation in the manufacturing process. Unfortunately, in previous studies, many deterministic components of the manufacturing process, such as memory architecture, layout, systematic process variation, device package, are ignored. This dissertation shows that these deterministic factors can significantly correlate two memory signatures if those two memory chips share the same manufacturing resources (i.e., manufacturing facility, specification set, design file, etc.). We demonstrate that this signature correlation can be used to detect major counterfeit types in a non-invasive and low-cost manner. Furthermore, we use this signature correlation as side-channel information to attack memory-based cryptographic keys. We validate our contribution by collecting data from several commercially available off-the-shelf (COTS) memory chips/modules and considering different usage-case scenarios

    Similar works