IOT HSM/crypto chip support

Help
#1

Please help me understand and understand whether LetEncrypt can help.

It very cost-effective to add a hardware trust platform - microchip's ATECC608A seems pretty popular - to an IOT system.

My understanding is that this should provide a level of trust in that system at least equal to the DNS-based trust mechanism. With that, is there any way to get a LetEncrypt certificate for these systems?

The IP address of these IOT systems will not usually be Internet routable, indeed in Industrial Environments (my interest) they are usually not Internet connected. However, information from these (web-displays,information sent to remote systems, etc.) needs security - trusted certificates.

Guidance, ideas, education, etc. gratefully accepted. Thanks,

3 Likes
#2

Hi @ergouser

the answer is simple: Then you have to use dns validation.

Start with some basics:

then

2 Likes
#3

Which means that the basic answer is that LetEncrypt can't help here. It's a pity. The number of non-routable IOT device (even if we allow that they must be Internet connected) is huge and growing rapidly - along with the security problems associated with them.

The lack of Root CA support seems to add to the massive disorganized fragmentation of solutions provided by, particularly the large Cloud vendors, proposing proprietary, vendor-locked, solutions to a problem that's already been solved, robustly and at scale for routable devices. "essential infrastructure for the Internet" now includes IOT devices and some of these control critical physical infrastructure, such as water distribution and the power grid.

Trusted certificates at that level would seem to be an essential step. It's possible I totally misunderstand what should be possible, or perhaps this is just a feature request...

#4

If your systems aren't connected to the internet, are they still IOT devices? :thinking:

Also, your second paragraph.. I can't make heads or tails from it. Could you perhaps clarify?

2 Likes
#5

Please explain.

I don't understand that.

You can use Letsencrypt certificates. But you have to use dns validation, not http validation. That's all.

PS: There are a lot of other IOT systems with Letsencrypt. Same with routers (like FritzBox) without public access, but with a vendor specific subdomain, so dns validation is always possible.

2 Likes
#6

Depends how you define IOT. Imagine an embedded system in, say a water treatment plant. It's on an internal network, suitable segmented but has a 192.168.x.x address. For the sake of argument, lets imagine that it can access the Internet, eg to push data to a Cloud provider. Typically you'd want a PKI infrastructure to secure that data and you want to anchor that security.

As to the second paragraph. AWS, Google, Azure ,etc. all have some unique way to add this security that's unique to them (as far as I can tell).

#7

In that case your IoT device is actually the client, not a server requiring a valid certificate.

Also, I think that for many IoT devices (and certainly critical devices) it's often more logical to use your own custom PKI and not use the public PKI.

4 Likes
#8

@ergouser

I feel like you really need to ask yourself: "At what point in time will my IoT devices actually be taking public requests?"

I, for one, don't want a chip responsible for determining the cleanliness of the public water supply to EVER be taking public requests from the internet.

This seems like the ideal circumstance for a reverse proxy server.

2 Likes
#9

It can be both a client and a server, but even clients can benefit from certificates eg MQTT. The system might serve a web-HMI viewable by someone on that network or it might not be 100% segmented.

1 Like
#10

There are many use cases that don't necessarily imply access from the public Internet. If you consider that the entire facility is behind a NAT but the IOT devices are serving web-HMIs, you still (ideally) don't want self-signed certificates.

In SCADA the systems are often remote - lift stations, distribution, etc. etc. - in which case you want no access into the system, but to push signed/encrypted data to the 'net. @ Osiris considers that a "client" which may decrease the need for a trusted certificate, but I don't think it eliminates it.

1 Like
#11

@ergouser

Please explain your setup.

I don't see a reason why it should be impossible to use Letsencrypt certificates.

#12

image

How about this first, how do we ensure that the "User" doesn't have to deal with a self-signed certificate?

#13

It should be no more difficult to issue a cert from an internal/private PKI system that a public one.
If you really care about keeping off the Internet, then you should really consider not relying on it at all, nor interacting with it either.

2 Likes
#14

Need I say that this is not a forum for - Please help me securely design my for profit business.

2 Likes
#15

Your IOT-device must have a worldwide unique domain name.

Sample:

https://wlshwxfdfwabqu2c9p.myfritz.net/

is a unique subdomain from myfritz.net (Router FritzBoxes).

That FritzBox can create a Letsencrypt certificate via dns validation.

So a user can use that domain name to connect to that device.

1 Like
#16

Is it really that easy? If I create a Fargate container on AWS it has a 10.10.a.b address (or something). If I assign mycontainer.mydomain.com to that IP can I really get a certificate for the container?

#17

Your question says: You didn't read the shared basics. Please change that.

2 Likes
#18

Fair comment but sometimes I just need someone to expose the scope of my ignorance so I know where I should be starting to back-fill. Thanks (and genuinely, not facetiously).

2 Likes
#19

You need to break the problem down until the smaller pieces are manageable.

  • How can you get certs for all your IOT devices (and renew those certs)
  • How can you deploy the new certs (and also their renewals)
  • How can the IOT device use a cert
  • How can the clients validate the certs (chain and OCSP)
3 Likes
#20

Yes, because the dns-01 challenge doesn't require public connectivity to the host, it requires public connectivity to the DNS infrastructure.

4 Likes