Account and Server private Keys

Client dev
1

I'm writing my own ACME client for a deeply embedded IOT device.

If I have a standalone IOT device that is going to create a single account for just itself,
and then renew its certificate when it expires...

I've read elsewhere that account and server keys must be different.
Can I pre generate the account key and use the same account key across multiple devices/accounts?

What are the risks if the account key is not as secure as the device key?

Can I dynamically generate an account key, create an account.... get my device certificate then delete the account keeping the certificate valid?

Here is the use case I have a standalone IOT device providing a service paulshouse.fancythermostat.com

it generates an account key and a server key....
It goes through the whole process to get a certificate...
It renews etc...

At some point the IOT hardware dies....(no file system , no backups etc...)
It gets tossed in the trash....
fancythermostat sends out a new hardwar emodule with ZERO knowledge of the prior state of keys, certs etc....

The only thing it knows or gets configured for is its name paulshouse.
Its put in the same place as the previous thermostat it setup dynamic DNS or assumes the same address/DNS NAT passthrough as its predecessor....

Now it sets up a new account with new keys, and generates a new server key.... (all internal, nothing exposed) Will letsEncrypt let it ask for a new certificate for paulshouse.fancythermstat.com?
As it has lost ALL the keys for the previous occupent of paulshouse.fancythermostat.com is in the dumpster headed for a land fill....

If it wont allow that then how do you recover?

One approach would be to have a global compiled in account and account key for ALL fancythermstats.com,,,, and distribute it unchanged for all fancythermostats...
That seems insecure as any fancy thermostat that is ever compromised will give up its account info...

2

Only if all the devices will belong to the same subscriber. See Who is the Subscriber in the Integration Guide.

The ACME specification has this to say:

Compromise of the private key of an account key pair has more serious consequences than compromise of a private key corresponding to a certificate. While the compromise of a certificate key pair allows the attacker to impersonate the entities named in the certificate for the lifetime of the certificate, the compromise of an account key pair allows the attacker to take full control of the victim's ACME account and take any action that the legitimate account holder could take within the scope of ACME.

I personally would disagree with the exact phrasing there, but if devices share an account, then any device would be able to revoke any other device's certificates, or re-issue a certificate for a domain that a different device had recently authenticated.

Sure. Though I think your device would have to be pretty space-constrained to not want to hold onto a little account key.

Yes. Any account can authenticate itself for a domain and get certificates for it, even if a different account also has authenticated itself for that same domain name.

Yeah, that sounds like a terrible idea.

Also, while making any sort of embedded device, be sure to Plan for Change (also from the Integration Guide). If Let's Encrypt runs out of funding and shuts down the day after you start deploying these, you don't want your devices to turn into bricks.

5 Likes
3

To add to this a little: A highly optimized implementation can theoretically require as little as 32 bytes of persistent memory in total for the account key (by using a P-256 EC key and storing nothing but the private key in binary form). Most implementations will store more metadata, but even embedded systems should be capable of providing room for it (unless you're already fighting for every last byte, but in that case there are other tradeoffs I would consider first).

5 Likes
4

I would centralize/externalize the entire ACME process.
All you have to do is provide each device some unique [and clever] method of cert retrieval.
[So that you can be certain only the specific device can obtain the cert intended for it]

Presuming:

  • Each device will have sufficient Internet access.
  • Each cert will have to be renewed periodically
4 Likes
5

Another thing to keep in mind is that the ACME service you are connecting to can and will change. Sometimes this necessitates changes to the client, so plan for the device to be updateable (especially CA root certificates it trusts etc).

One technique is to install a pre-shared key unique to each device (updateable), so the device uses this to authenticate against your API which in turn gives it a cert that's already been acquired for it's use. This does mean the private key associated with the cert needs to be part of the bundle you update, but it's unique to that devices name anyway.

While this is a compromise (having the private key created on the central server and passed to the device), it does mean there are less moving parts on the device itself (which already presumably needs to speak to your API anyway), the private key can be updated every time the cert renews and there is no requirement to interact with the ACME CA (or any other internet services other than your own central API).

With some CAs you can even opt to have short lifetime certs, so even a fully compromised device would only expose a cert that's going to expire soon (or already has) and the current pre-shared key (which you have complete control over trusting via your central server).

3 Likes
6

Not really related to OPs question, but I'm wondering how the IoT device is going to validate the challenge if the device at the customers premise is going to do it? dns-01?

4 Likes
7

Not really related to OPs question, but I'm wondering how the IoT device is going to validate the challenge if the device at the customers premise is going to do it? dns-01 ?

Since the iot device is a webserver it will respond to the http-01 challenge...

8

FYI, many others on this forum have done this and run into issues due to:

  • Trusted Roots expiring, potential revocation
  • TLS/etc methods changing
  • openssl behaviors changing
    etc

I suggest searching the archives for "embedded" to find some of the discussions. There are a lot of learnings and teachings on this that have been shared here over the past 5+ years, and can help you avoid a lot of pitfalls and headaches during operation and future updating.

5 Likes
9

It's that a local webserver only? I assume that if it's a thermostat, it'll hang on the wall of customers at home, probably sitting behind NAT, with no reliable way of making sure the device is accessible directly from the public internet.

Personally I wouldn't want that anyway, as IoT devices are often a security risk. No way I'd want such device directly accessible from the public internet.

2 Likes
10

For inside the NAT one can use .local addresses and don't need https and certs...
Some of our customers want to hang things out on the public internet and hence the need for https and certs...

Yes security matters.... but some customers are really opposed to having a cloud service that can go away and really want it all self contained.

11

Ignoring any other design issues ...

Yes, usually. Exceptions are when the account has special criteria associated with it such as expanded rate limits or is on the ECDSA allow-list.

Yes. As an example, people spin up docker containers and get a cert but don't place it in persistent storage (bad on them). Each time they spin up they start over and get a new cert up to the point they get rate limited (5 certs with identical names per week).

3 Likes
12

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