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.
I like IoTs. (IoT-secure)
Kinda flows and only somewhat sounds like the security was bolted on as an afterthought… ;)
Hmm.. IoTs is just IoT plural form.
My pick would be IoST
Internet of Secure Things
IDIoTS – I doubt Internet of Things’s secure.
Way more accurate…
If you read this as lowercase it becomes “LOST”, as in lost cause…
Connect all the things they said. It will be fun they said.
…
“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.”
https://www.sciencemag.org/news/2017/06/china-s-quantum-satellite-achieves-spooky-action-record-distance
The big advantage of ECC over the older DH protocol is that ECC doesn’t appear to be vulnerable to Quantum computation shortcuts.
Wikipedia says the opposite: “ECC is an easier target for quantum computers than RSA.”
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.
I refer to https://en.wikipedia.org/wiki/Elliptic-curve_cryptography#Quantum_computing_attacks
Sure, practical attacks are infeasible because no large enough quantum computers exist yet. But if ECC is easier to break than RSA, I think Jonathan Bennett’s claim “ECC doesn’t appear to be vulnerable to Quantum computation shortcuts” is false.
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.
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.
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.
It’s very important to implement the ECC algorithm and key checking correctly. Else, ECC cryptography is like an open book (you can extract the privake key with only 4 guesses!). Might sound obvious, but all Bluetooth implementation (Qualcomm, Intel, …) were vulnerable to such simple attack. Please refer to http://www.cs.technion.ac.il/~biham/BT/bt-fixed-coordinate-invalid-curve-attack.pdf for an example.
Secure Hashing Internet of Things
Security Hardened Internet of Things
Microsoft used to actually have a Critical Update Notification Tool.
If you want obscure, you could consider Trusted Worldwide Attached Technology…
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.
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.
So change the encryption and keys and key lengths every second or less and the encryption would be a different encryption than the first.
Not a bad idea. I am just unnerved by crypto that depends on math knowledge not progressing, is all.
ECC is feasible even in such small esp8266. So there is no excuses to build secure enough solutions. An example is my current project EnigmaIoT https://github.com/gmag11/EnigmaIOT
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.
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.
https://github.com/SensorsIot/HTTPS-for-Makers
It’s all solved and has full TLS1.3