What algorithms must an embedded client support?

I’m about to begin developing an ACME client for an embedded system. The self-issued certs I’m using for testing use ECC keys because performance is so much better with them than with RSA.

I am trying to reduce program memory consumption to make room for the ACME client while staying within my memory use target. About 2/3 of my current executable is consumed by crypto libraries. If I can eliminate support for some algorithms, I may be able to recover a substantial amount of memory.

I recognize that required algorithms will change in the future, but knowing the bare minimum that must be supported now would be helpful. For instance, could I safely eliminate RSA and still get certs from Let’s Encrypt?

Section 6.2 of the ACME protocol [RFC8555] links to the JSON Web Signature (JWS) [RFC7515] spec with regards to algorithms, but also defines some requirements and limitations. In particular, no HMAC algorithms are supported and the server must implement ES256 (ECDSA using P-256 and SHA-256). However, the rest is left up to the client and server developers.

At the moment, I believe Let’s Encrypt’s Boulder implementation supports the following for both account keys and certificate keys:

  • RS256 - RSASSA-PKCS1-v1_5 using SHA-256 with key sizes 2048-4096
  • ES256 - ECDSA using P-256 and SHA-256
  • ES384 - ECDSA using P-384 and SHA-384

So dropping RSA would likely work as long as the clients connecting to the services hosting the resulting certificates are not too old for ECC key support.

1 Like

However, your HTTPS library still needs RSA validation support, since https://acme-v02.api.letsencrypt.org/ currently uses RSA certificates.

2 Likes

I was afraid of that. Do you know offhand what key size is currently used?

It’s 2048-bit RSA at the leaf.

However, a properly implemented X.509 client would have to be able to chain that certificate to a trust anchor, in order to verify it. One of the (two, currently) trust anchors of the acme-v02.api.letsencrypt.org certificate is the 4096-bit RSA ISRG Root X1. And who knows, maybe one day the intermediate will also be 4096-bit.

When I read this thread a few hours ago, what popped out to me was perhaps that you should establish some kind of proxy/broker between the client and the ACME server. So that the embedded device can minimize its work without blowing up the security model of ACME.

You might want to read this other recent thread about embedded clients:

It's not about your algorithm question, but other matters.

That’s an interesting idea. Can an intermediary reside in a different domain than the system for which the cert is being requested? Specifically, what I have in mind is:

  1. The intermediary is abc.com, and there are embedded systems def.com, ghi.com, etc that need certificates.
  2. When def.com requests a certificate, it generates a key pair, creates a CSR containing the signed public key, signs the CSR and calls a service on abc.com that submits the request.
  3. Upon receipt of the CSR, abc.com verifies the signature using the provided public key and if it matches, submits the CSR to letsencrypt’s API.
  4. When letsencrypt responds with challenges, abc.com sends the HTTP-01 token to def.com, which stores it at http://def.com/.well-known/acme-challenge/.
  5. abc.com confirms that the token is installed then informs letsencrypt, which verifies domain control by retrieving the token from def.com.
  6. letsencrypt issues a cert that is retrieved by abc.com.
  7. def.com downloads the cert from abc.com and installs it.

Would this work?

Oh, are you planning on def.com and ghi.com being customer-owned domains?

If they are customer-owned domains, then I don’t think there’s a way to make it safe unless each embedded device signs its own ACME requests with its own ACME account key. Otherwise, there’s a lot of potential for mischief.

For example, Let’s Encrypt authorizations are not “one shot”. Once an ACME account has a valid authorization for a domain, it can create many different certificates using that authorization, all with different CSRs. (For up to 30 days after a valid authorization is performed, currently).

The person who owns def.com would not want to hand such a carte blanche to an intermediary that they do not control.

That’s correct; the two domains are owned by third parties and abc.com should not have the ability to act on the other domains’ behalf except as described here.

If that can’t be done securely it sounds like I’m back to implementing the entire client on the embedded systems.

After considering further, I’m not sure I agree with the notion that authorizing a 3rd party to act as an intermediary is a bad idea. We routinely install software updates on our servers, desktops, laptops, routers and switches that a trusted 3rd party vouches for, and the consequences of error or betrayal of trust by them could potentially be catastrophic to business operations as well as personal privacy. Is trusting that a 3rd party wouldn’t issue unauthorized certificates for non-existent devices that they lack the ability to install on a domain controlled by one of their customers even in the same class of risk?

What if Cisco, ASUS or D-Link realized one day that many of their consumer customers wanted to be able to manage their home router over the internet? While we no doubt all agree this would be a bad idea, humor me for a moment. If these companies offered to serve as an intermediary for their customers in the manner I’ve described here in order to shield them from complexity or reduce reliance on the customer routinely updating their firmware, to what risk would that business model expose their customers?

Yes, agreed. After all, when you delegate your domain to a web host or DNS host, you’re doing exactly that.

It’s fine to make an intermediary that doesn’t work exactly like ACME. Different trust model and everything.

Maybe you can solve the problems in the design (for example, by binding each distinct embedded device to a separate ACME account on the intermediary). But it’s kind of a case of circumventing the safeties in ACME and then trying to re-implement them yourself …

We’re already there. Nowadays, ISPs can upload settings and code over the internet to your router using CWMP/TR-069. Sometimes it is exposed to the entire internet. Every time an ISP ACS gets hacked, a bunch of consumer routers get malware installed onto them. And then sometimes the TR-069 port on the device is straight up vulnerable on its own.

1 Like

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