Prof Riccardo Bernardini from the University of Udine tells us about the importance of stabilization in Physically Unclonable Constants
The main issue in system security is how to be sure that a specific user is authorised to carry out a specific action. This requires authentication, a procedure that allows the system to verify true user identity. Authentication, however, is not limited to humans only, but can apply to inanimate objects (hardware devices) as well. Just think about a PC that must accept only “certified” USB dongles. To authenticate a user, we can ask for a password or use two-factor authentication, but how do you ask for a password to a USB dongle?
As an answer to this problem, a researcher proposed to exploit the characteristic behaviours of hardware systems to give them an “identity”, an idea somehow similar to recognising your brother by the way he speaks. This idea is not really new: already in 1983, Bauder (D.W. Bauder, “An anti-counterfeiting concept for currency systems”, Report PTK-11990. Sandia National Labs., 1983.) proposed a fibre-based anti-counterfeiting for currencies; but it is only in the 2000s that the idea gets popularity with the concept of Physically Unclonable Function (PUF).
Physically Unclonable Function (PUF)
A PUF is just a function (something that gets some inputs and returns some outputs) embedded in the hardware to be authenticated and implemented in an “ill-conditioned” way, that is, using circuits that change their behaviour in response to the unavoidable random variations that happen during production. Usually, engineers aim to design circuits that are “resilient” to such variations, but in this case, they are exploited to give each piece of hardware its own characteristic behaviour. This makes the PUF behaviour random and impossible to predict; it is also impossible to clone it since this requires replicating exactly the conditions present during production (hence, the word unclonable). In a sense, a PUF is so secret that not even the one who produced it knows about it.
A problem with authenticating your brother by the way he speaks is that someone could try to imitate him. The same problem happens with PUF: how can we be sure that someone cannot learn to behave as a specific PUF? Actually, some PUF can be attacked in this way: for example, in a 2021 paper, Strieder et al. (doi: 10.46586/tches.v2021.i2.1-36) used machine learning to attack PUF; see also the 2014 overview by U. Rührmair and J. Sölter (doi: 10.7873/DATE.2014.361).
Indeed, a PUF is akin to a cryptographic function, and it is well known that, despite the wealth of knowledge accumulated in cryptography during many years of development, it is hard to design cryptographic primitives robust against attacks by powerful opponents. Add to this the fact that PUF design is a fairly young discipline, and it is no surprise that even recent proposals are not robust enough for practical security.
A way to solve this problem is to observe that a PUF is actually a fusion of two cryptographic primitives: a one-way function (that is, a function that is easy to compute, but almost impossible to invert) and a random generator that makes the PUF behaviour unpredictable. The idea is to apply the motto Do One Thing and Do It Well: instead of mashing the two functions together, use a standard one-way function (whose strengths and weaknesses are well known) and use the PUF to generate a random secret, so that it is unique to the specific chip. In this case, we need a function that takes no input and always returns the same value, that is a constant, hence the name Physically Unclonable Constant (PUC) (also known as Physically Obfuscated Key, although the two concepts are slightly different).
Physically Unclonable Constant (PUC)
The solution of using a PUC with a one-way function allows to reuse all the known cryptographic knowledge and it is a strong guarantee of security, as long as the generated secret is uniformly distributed.
A problem with PUCs is that the secret is not “burnt” in the chip at production time but regenerated by the hardware at every turn-on and noise could induce errors in the regenerated secret. This is a serious problem because even a single wrong bit can be disastrous when using cryptographic functions. Therefore, it is important that the PUC is stable, that is, it always produces the same number with overwhelming probability.
Many PUCs (e.g., the popular PUC based on non-initialized memory) are not stable enough, and they need to be stabilized. Many popular stabilizers are based on helpers. A helper is a value that is computed from the PUC output and saved in non-volatile memory. When the chip is turned on, the helper is used to correct any error in the regenerated secret.
This approach has, however, two drawbacks: it requires error-correction circuits that can be quite expensive (in terms of silicon area) and the helper can leak some information about the secret. Ideally, a good helper should not do that, but the cited work by Strieder et al. shows that this is not always the case.
Helper-less stabilizers research
This promoted research in the field of helper-less stabilizers that require neither helpers nor error correction hardware (doi:10.1007/s10207-019-00473-8, doi:10.1109/TETC.2014.2386137). Also, the design of very stable PUCs (that require very simple stabilizers or no stabilizer at all) has received attention (doi:10.1016/j.vlsi.2017.06.010, doi:10.1016/j.vlsi.2017. 06.010).
We believe that a safe and resilient PUF will be key to solving the issues of security and privacy that are getting even more pressing, and we also believe that to have the necessary guarantees of security and resilience the simplest approach is the use of a PUC together with well-known cryptographic primitives. For this approach to be successful, however, it is necessary to have PUCs that are simple and economic to embed and that are resilient against sophisticated attacks like the ones based on machine learning. Using a very stable PUC together with a helper-less stabilizer is a very promising approach that could make the use of PUC commonplace even in the least expensive devices.
Please note: This is a commercial profile
