Understanding Elliptic Curve Cryptography And Embedded Security

We all know the usual jokes about the ‘S’ in ‘IoT’ standing for ‘Security’. It’s hardly a secret that security in embedded, networked devices (‘IoT devices’) is all too often a last-minute task that gets left to whichever intern was unfortunate enough to walk first into the office that day. Inspired by this situation, All About Circuits is publishing a series of articles on embedded security, with a strong focus on network security.

In addition to the primer article, so far they have covered the Diffie-Hellman exchange (using prime numbers, exponentiation and modular arithmetic) and the evolution of this exchange using elliptic curve cryptography (ECC) which prevents anyone from brute-forcing the key. Barring any quantum computers, naturally. All three articles should be understandable by anyone, with a simple, step-by-step format.

The upcoming articles will cover implementing security on microcontrollers specifically.  For those who cannot wait to learn more, Wikipedia has a number of articles on the topic of Elliptic Curve Cryptography (comparing it to the more older and still very common RSA encryption) specifically, as well as the Elliptic-Curve Diffie-Hellman key agreement protocol as discussed in the All About Circuits article.

A detail of note here is that the hardest problem in secure communications isn’t to keep the communications going, but to securely exchange the keys in the first place. That’s why a much much computationally expensive key exchange scheme using an asymmetric (or public-key) cryptography scheme  is generally used to set up the second part of the communications, which would use a much faster symmetric-key cryptography scheme, where both parties have the means to decode and encode messages using the same private key.

All the math aside, one does have to wonder about how one might denote ‘secure’ IoT. Somehow ‘SIoT’ doesn’t feel very catchy.

26 thoughts on “Understanding Elliptic Curve Cryptography And Embedded Security

      1. If you refer to this article: “Quantum resource estimates for computing elliptic curve discrete logarithms” from Roetteler, then you have to account for the fact that a simple 256 bits keys requires 2400 qubit, and 120 billions gates. Current technology does not have such amount of quantum gate (nor the number of “real” qubits), and I would expect it’ll not appear soon. At least not sooner than the life expectancy of your IoT gizmo.

          1. You’re just referring to how it can be solved with “brute force”, the RSA algo has weaknesses that can be exploited with far less qbits. So you’re both right, and wrong at the same time (you’re talking about different things).

            And while 2400 qbits can be achieved in the foreseeable future, that was just for 256 bits.

          2. Huh. I may have thinking of the resistant variant also described there. Or maybe misremembering something, or even passing on somebody else’s error. *Shrugs* Today I Learned.

        1. So Intel’s plan to have 1000 qubits by 2023 and 1 million silicon spin qubits by 2028 at their 300nm process should not be a concern because that would be outside the lifetime of the current generation of Internet of Trash items.

  1. The only security I will believe in is the one where the vendor is held legally accountable for flaws. The only way to escape legal liability should be to open source it.

  2. There are plenty of cases in iot where it would make sense to use one time pads. Key exchange would work by just physically swapping out sd cards. This is not feasible in all cases, but I think the knee-jerk reaction against one time pads needs to be reconsidered.

  3. My first scientific publication was a conference paper about using ECC on embedded devices. That was back in 2008 (http://jphblog.com/assets/content/Mache_et_al_ECC.pdf). At that time our rationale was that ECC requires much smaller keys than comparable public key algorithms– (160-bit/224-bit ECC keys are approximately as secure as 1024-bit/2056-bit RSA keys respectively), but much more feasible to implement on embedded hardware. We did some efficiency benchmarks on obscure hardware from 2008, but I expect the general conclusions would still hold on ESP’s and other modern microcontrollers.

    Granted that was an undergraduate research project, and I haven’t been involved in that community in a long time, so there very well may be other advantages that I am not aware of. In any case, it’s cool to see that ECC is getting more attention these days.

    1. I had lots of fun with RSA keys while trying to secure ESP8266-based devices as part of my BMaC project. Essentially the problem I ran into was that while the secure connection and handling of encrypting/decrypting data wasn’t the issue, the handshake was where things went south.

      Essentially the problem is that the TLS handshake by default uses two 16 kB buffers for RX/TX, which completely overwhelms the available SRAM in the chip after it has set up its WiFi and TCP/IP stack. I had to use a proxy as TLS endpoint on which I could configure the SSL Fragment Size option, setting it to use two 2 kB buffers instead.

      Main issue I see with embedded security is that it could be made so much easier for those who are not interested in spending weeks reading up on the finer details and tweaking the configuration until it finally begins to work.

Leave a Reply to Jesper (@J_B_N_P)Cancel reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.