Vincent: This is a bit of a long question. If user A generates a key with a given context and user B gets hold of the context data, it could generate the same key as user A. This would compromise the encrypted data of user A. I believe only one trusted user can use the Key Generating function block. Is that correct?
Roel: That's a very good comment actually. And that's really going to the heart of setting up a secure key management system. You are right about the users and that's one of the reasons why you should make the allowed key owners (or users) part of the key context. That is one thing. So that already gives you differentiation. The other thing of course, is that the key management system itself should not be accessible by just anyone. It needs to be part of a bigger security architecture where you have security domains and there is control over who is allowed to do what. And especially in setting the key context. So not everyone, like you suggest, should be allowed to mess with the key contexts. That key context should be under the control of the key management system.
Vincent: You talked about context binding at one point. Is context binding something that is mandatory according to the NIST standards?
Roel: So, NIST defines context binding, first of all. So it's not something that we invented. It's actually a concept that is coming from NIST and it is mandatory in the sense that you need to put the key length there. In NIST terms, even key length is a special key context because you even have to present it specially. It is also a fact that the key length is the only context parameter that is actually interpreted by the key derivation function because the key derivation function needs to know how long the key is that it should produce. So in that sense, there is definitely mandatory context binding for the key length. For all of the other possible key context fields that you can think of, nothing is really mandatory in NIST terms. It is all highly recommended, but it's not a shell requirement.
Vincent: PUFs exists with multiple challenge-response pairs, which could lead to producing multiple keys. Is there a benefit of having a PUF with a KDF over having a PUF that can produce multiple keys itself?
Roel: I would say, yes. The benefit is the overall trust we put in crypto, which is very high. You don't have this when you use a PUF that has many challenge-response pairs. There are many PUF proposals out there that can produce many challenge-response pairs, the so-called strong PUFs. They all come with their own security models and, unfortunately, I would say most of these security models after some time get broken. For example, using machine learning attacks. So if you would base your key management system on such a PUF, you might end up in trouble at some point. It's not guaranteed, but we see that as a systematic thing that most of these PUFs, after some time get broken. While if you would base your key management system on the NIST compliant key derivation function, which uses very widely-used and very widely-trusted cryptographic algorithms, I would say that you have a lot higher assurance that that will stand the test of time.
