12
$\begingroup$

I'm developing an IoT system that uses small nodes connected through RF. This allows messages under 250 bytes long. You can check it at https://github.com/gmag11/EnigmaIOT.

All messages are encrypted using ChaCha20+Poly with a dynamic key obtained using DiffieHellman algorithm. But first association is only protected with a shared key so anyone that have that key may join the network.

I'd like to use mutual certificate authentication between nodes and gateway while keeping the number of messages during association as small as possible.

What is the minimum, secure enough, certificate that you can build? How could I generate it using OpenSSL?

There is a prior question similar to this but I guess my case is less constrained. Certificate validation on an IoT device using few bytes

Maybe here there is another solution

Thank you

$\endgroup$
  • 2
    $\begingroup$ It's been a long time since I've studied this, so not writing it as an answer, but if you're willing to go beyond what OpenSSL provides, ECQV implicit certificates might be useful to you. On top of small certificates, the generation procedure is also very simple and generally IoT-friendly. $\endgroup$ – Ruben De Smet Sep 3 at 15:56
12
$\begingroup$

What is the minimum, secure enough, certificate that you can build? How could I generate it using OpenSSL?

Generally you'd need to flatten certificates if you want to go below 256 bytes. X.509 version 3 certificates have a certain overhead due to the ASN.1 tree structure. So those are not as efficient as they could be.

For smart card systems generally so called "card verifiable" certificates are used. CVCertificates are proprietary structures that are generally also specified using ASN.1. However, they try and use a minimum of bytes, generally a SEQUENCE of OCTET STRINGs with possibly a few INTEGER's and OID's thrown into the mix. They would also use flattened public keys and signatures where a minimum of overhead is used.

For instance, if Elliptic Curves are used (ECDSA) there could be a dedicated named curve used, or a single byte indication of the curve used. Then the (compressed) public key would just be a single OCTET STRING containing just X for compressed or X and Y for uncompressed as statically sized unsigned integers. Similarly the signature would not be DER encoded but consist of simply a concatenation of R and S.

Generally you'd avoid RSA. RSA can be used in such a way that part of the signature actually contains the data of the certificate itself. For this "digital signature schemes giving message recovery" are used. These schemes are however rather uncommon. More importantly, a 2048 bit RSA key only allows about 88 bits of security (compared to a AES key, for instance), and already takes 256 bytes for the signature, with the public key taking another 256 bytes for just the modulus. So generally a 64 byte ECC signatures and 33 / 65 byte public keys are preferred (e.g. P-256 or ed25519 offering about 128 bits of security).

OpenSSL command line won't support CVCertificates. Generally CVCertificates are build for a specific purpose. The OpenSSL library can of course be used for both the ASN.1 / DER functionality and the cryptographic functionality. The Java / Bouncy Castle library has some CVCertificate functionality build in that is probably just compatible with the ePassport specifications (where it is used to gain access to the biometrics on the smart card chip - or at least it could be used for that).

Currently EJBCA (an open source Java EE Certifcate Authority) offers CVCertificate support compatible with the ePassport standards. Beware that the software is relatively tricky to use and setup. As it is Open Source you could probably tweak the certificate format for it to meet your needs. But whatever you do, you are entering a rather specialized territory (... welcome!)

| improve this answer | |
$\endgroup$
7
$\begingroup$

There are two questions here: What's the minimum, and what's the minimum standard certificate you can build. The former is shorter than the latter, as noted in Maarten Bodewes' answer.

If you're willing to go beyond what OpenSSL supports, you can modify the client and server to only send/receive the non-constant bits of the certificate, and hard-code the rest. Microchip/Atmel's ATECC chips require doing this to save space. Their method is described in this application note. That lets you store all the non-constant information of a certificate in 72 bytes. If you don't have any need for more than one entity to sign device certificates, you can save an additional 3 bytes. Skipping their custom format information saves another 2. So I the minimum for a decently secure ECC certificate is 67 bytes.

| improve this answer | |
$\endgroup$
  • $\begingroup$ Interesting. Note that I did actually did implement full X.509 certificate validation and verification on a smart card before. One way is to reconstruct the data using a template, the other is to stream the certificate and only keep those elements required. As relatively common, it never got used though. It had the disadvantage that you'd still have to transmit the entire thing. $\endgroup$ – Maarten Bodewes Sep 3 at 15:50
  • $\begingroup$ Yeah, I'm familiar with this chip format because I've used them before. Basically template reconstruction, and bit packing and fixing various fields. EG dates are limited to a resolution of hours, 2000-2031 creation date, 1-year expiration resolution, 31-year max lifetime. That lets them encode the creation and expiration dates in only 3 bytes. Likewise the serial number can be generated from hashing the public key and dates, instead of explicitly storing/transmitting it. $\endgroup$ – SAI Peregrinus Sep 3 at 15:57
  • $\begingroup$ Pretty smart, but you'd still need the required software to generate the specific X.509 components + conversion utilities of course, so I'd use it specifically when X.509 compatibility is a must. $\endgroup$ – Maarten Bodewes Sep 3 at 15:59
  • $\begingroup$ Yeah, it was a decent amount of work to get working. But it lets TLS work with client authentication, so we could use an existing TLS library, preventing a lot of potential security hazards. $\endgroup$ – SAI Peregrinus Sep 3 at 16:07
1
$\begingroup$

Just for information, you might be interested in following this work that aims at compressing certificates significantly and according to the Expected Certificate Sizes might be appropriate for you. Note that it is far from being completed at this time.

| improve this answer | |
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.