IOT HSM/crypto chip support

That's an important question, but it's not a foregone conclusion that the public PKI designed for the World Wide Web is a part of the best solution to it. The web PKI seems to be optimized for the case where popular web sites are used by large numbers of visitors who are complete strangers to each other and to the web sites' operators. That might not be very similar to the situation for embedded devices meant for industrial applications.

5 Likes

I feel that the solution should be the same. The people installing the IOT systems are not, generally, IT or security experts - just users. Faced with a message about an untrusted certificate "User" may just learn how to accept it and will do that every time for that message from then on. Put another way, the security has to be as transparent as it is on the public web if it is to be real. I see no reason why the model would not fit and proliferating security models is bad for many obvious reasons.

1 Like

Are you qualified as a network security engineer?
Do you understand public and private PKI systems?
[no real need for an answer - but, if your answer would be no to either, then you need to seek real help]

1 Like

I agree that users shouldn't be encouraged to click through warnings.

But I don't think there's a strong parallel between "is this really Google's server" and "is this really my company's industrial control device". In the first case, the user is able to outsource to Google and its partners the task of determining what it means for a server to be "Google's". In the second case, there's no entity that's obvious to me to whom the company can outsource the task of determining whether a particular industrial controller is the company's.

2 Likes

Anyone who's going to be running air-gapped industrial control systems of the sort you're describing should have some sort of IT infrastructure to allow cert deployment to any machines that would have access to those systems. Come up with an internal CA, deploy its signing cert to machines in the organization, and use it to issue certs for whatever devices need them. Here's one way to handle the CA:

3 Likes

In the scenario as presented the task is outsourced to whoever is managing the DNS (the company's IT department?). I sort of feel comfortable with that for everything to the left of the router - the Intranet.

I think that it starts to wobble when you get out to the Internet. The Cloud server has to trust the IOT box and files don't really cut it. Unless I'm missing something (likely) with a non-routable IP if I can steal the certificates from the IOT box I can spoof communications with the Cloud. The IOT box is, almost by definition, physically fairly accessible - it can't be secured in a data center - making it more vulnerable.

The original topic was HSM. After this discussion, I feel that anchoring the public certificate to hardware just makes life easier - there's no reliance on IT to set up DNS. Anchoring a private key (likely a requirement in the Cloud setup) adds the obvious level of security that you actually have to steal the whole box, which might be noticed, rather than just the certificates.

1 Like

Somewhat off-topic, but the glib answer to that is that the contract is going to go to the lowest bidder.

There are likely way more critical infrastructure projects than there are IT-savvy OT (Operational Technologies) personnel (and money) to install/maintain them. The technology is changing rapidly and the people who need the solution are also not security experts and can't judge the proposals.

The reason grandma can bank online is (in part) due to Let'sEncrypt, and others with a similar philosophy, of making the Internet not only secure, but simple.

...has nothing to do with either Let's Encrypt or anything else you've mentioned in this thread.

Maybe it's me, maybe it's you, but it really sounds to me like you're mixing up a bunch of mostly-unrelated things. The requirements (and thus the appropriate solution for) an air-gapped industrial control system are quite different from those for a mass-market device expected to be used at large by members of the general public. For the former, if TLS is called for at all (which, IMO, is questionable on an air-gapped private network), private PKI is the way to go--and it need be neither expensive nor burdensome to set up. And if you don't want the burden (such as it is) of running your own CA, it's available as a SaaS product as well. For the latter, it's a different story. If the user directly accesses the device at all (which, in my experience, isn't the norm), and they do so through a web browser (also not the norm), then yes, a public PKI cert is likely called for.

Perhaps if you could define the actual requirements you have in mind, the discussion could be more productive.

4 Likes

I think that the image is probably the most descriptive. Technically it's not air-gapped, just a segmented network. The real question is how Let'sEncrypt can make the system more robust and simpler with specific reference to HSM, so a private CA are somewhat off-topic.

It looks like the problem you're dealing with is roughly the same as the problem of providing HTTPS on home Wi-Fi routers. The router manufacturers would like to equip their routers with a certificate that will "just work" out of the box. However, there's a problem: They can't get a globally trusted certificate for https://192.168.0.1/ because each network has its own 192.168.0.1. There's no globally unique 192.168.0.1, so the rules don't allow issuing a public certificate for it.

The options for this situation are:

  1. Private PKI, or
  2. The device manufacturer automatically gives each device a unique subdomain, and software on the device obtains certificates for that subdomain (Plex model), or
  3. Devices are not administered via direct network access, but instead they establish an outbound connection to the manufacturer's datacenter. The manufacturer offers a public-facing website through which device owners can send commands to their devices (Google Home model).

It sounds like you've ruled out (1). I suspect (2) is the best option for you. It's described in detail at How Plex is doing HTTPS for all its users.

The question of whether your device has an HSM or an ATECC608A has no bearing on the choice of (1), (2), or (3) above, and doesn't affect your ability to request a publicly trusted certificate. The key thing is providing a unique domain name for each device.

4 Likes

If I understand correctly, the Plex trick is quite interesting. Given a cryptographically secure hash linked to the hardware (from, say, an HSM) if the host presents its hostname as myhash.mydomain.com and has a certificate to match all is well. Move that certificate to new system that presents its hostname as someotherhash.mydomain.com and you get a certificate mismatch.

I'm not totally sure what this gets me, what DNS tricks might be required, or what new security holes it introduces, but still interesting...

I do feel I'm missing something.

the user/server/whatever hash makes it so a certificate can only be used to authenticate a specific server (even if it can have any IP) which makes it safe to hand the private key to the user

If I've stolen the private key, what's to stop me impersonating the server? I can claim to be:
192.168.x.y.625d406a00ac415b978ddb368c0d1289.plex.direct
generating a request to 192.168.x.y which I can validate against the stolen private key file.

The Plex "hash" is not necessarily cryptographically secure, nor linked to hardware. In fact, we don't really know what it is. Maybe it's random bytes. The point is just to make sure the subdomain is unique to each user. You could just as well put <username> in place of it, though you would leak your usernames in the public CT logs.

If you've stolen a private key, you can impersonate a server that has a valid certificate with a public key corresponding to that private key. This is fundamental to HTTPS. Filippo is not talking about stolen private keys, he is talking about how having a unique subdomain for each user means user A cannot interfere with user B.

3 Likes

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.