Why not have a PUF or Two?

One of the things everybody seems to roughly agree on is that PKIs are useful, but hard. It’s easiest if your use case is running on the public internet, weirdly, since a) just use Let’s Encrypt, b) privacy was never expected. Even then, it’s telling that I’ve seen more than one security (!) blog eschew it.

PKIs are simply necessary for the public internet; since without that any security needs (n2) keys, where n in the number of computers in the network. (As Dale Peterson has previously pointed out to, erm, me). I’d argue that’s not even the biggest reason; the biggest is that without them or Kerberos, you just don’t really have a better authentication story than TOFU.

It gets harder in smaller networks, since either a) YOU’RE now responsible for running the certificate authority, or b) you’ve got to punch through all your isolation in order to reach an external, plus likely leaking a lot of your internal network structure. What the hell do you do if that network link fails? If the answer is “carry on”, congratulations, you may as well not have bothered. Any decent threat actor WILL find a way to force that traffic to be dropped. If not, easy Denial-of-Service.

This is where I think - if your solution requires say 50 to 500 keys, and your OT probably doesn’t change all that much - you can probably manage to hire someone to be in charge of installing and managing those keys.

But I wonder. Engineers, as a rule, are happy to add a device that fulfils one function well. So why not look at those? Physical Unclonable Functions (PUFs) provide a nice, consistent basis for challenge-response type authentications. Whether you bother encrypting is up to you, but signing should be trivial.

You could even go further, if a bit more speculative - one of the most famous ways of banking was to break a stick, . This is authentication, and what’s neat - it’s mutual. . It seems reasonably possible a similar, pairwise, microscopic PUF could be constructed.