Microcontroller Cryptography Investigation

[technix]

We all know that IoT hacking is a thing and IoT traffic should be secured. I want to start a thread benchmarking crypto performance on various microcontrollers.

Methodology: For each algorithm, a maximum optimized implementation is used, which takes advantages if any and all available hardware accelerators. Then 512MB of white noise is being encrypted and decrypted to gauge its speed.

Algorithms: AES256-CTR-SHA256-HMAC (AES, 256-bit key, counter mode, separate HMAC based on SHA256), AES256-CCM (AES, 256-bit key, counter mode with CBC-MAC), AES256-GCM (AES, 256-bit key, Galois-Counter mode), Chacha20-Poly1305. All four cipher suites are TLS 1.2/1.3 AEAD ciphers

[westfw]

Isn't most "IoT hacking" more of an authentication problem than an encryption problem?
Who cares how long it takes to decrypt 512MB of data - that's more than I expect by IoT device to receive over its entire lifetime.

(OTOH, since most of the widely publicized attacks are on things like IP cameras and printers...)

[technix]

Isn't most "IoT hacking" more of an authentication problem than an encryption problem?
Who cares how long it takes to decrypt 512MB of data - that's more than I expect by IoT device to receive over its entire lifetime.

(OTOH, since most of the widely publicized attacks are on things like IP cameras and printers...)

This is the slowest of all security primitives. With efficient AEAD symmetric cipher efficient implementation of TLS can be constructed. Then you can start talking about IoT security.

[westfw]

Meh.  IoT security is more of a Systems Administration problem than an encryption problem.  If you can't even get people to enter a non-default password...

My security-involved friends are making favorable mumblings about things like the Atmel "CryptoAuthentication" chips ( http://www.atmel.com/products/security-ics/cryptoauthentication/default.aspx ), which are chip, small, things with relatively low-speed (1Mbps I2C) interfaces...

[rs20]

I'm not sure the results of this experiment would sway me; unless a chip that I was planning to use proved to be spectacularly underperforming. So I guess it sounds valuable from that point of view alone, although I'd be most interested in this from a position of pure curiosity alone.

Meh.  IoT security is more of a Systems Administration problem than an encryption problem.  If you can't even get people to enter a non-default password...

Security, or at least one-way security, doesn't require a password. For example Diffie-Hellman Key Exchange enables TLS (and therefore HTTPS) sessions to be immune to interception, all before any passwords even change hands. Highly secure private keys can be handed out from a central server when a device is first activated, once again making the question of passwords irrelevant.

If someone installs an internet-accessible webcam in their bedroom and leaves the default password on it, well then (arguably) that's just their fault. That doesn't mean that people who know about the value of good passwords should be denied good security, and we (as designers of webcams and IoT thingos) have a responsibility to make this level of security available.

Thus, dismissing security as a problem not worth considering because there are human factors at play is the height of laziness and unacceptable. I mean, if the majority of stolen bank accounts are due to people choosing bad passwords, does that mean that you'd be OK with your bank just giving up and disabling all security on your connection? What on earth are you even saying?

My security-involved friends are making favorable mumblings about things like the Atmel "CryptoAuthentication" chips ( http://www.atmel.com/products/security-ics/cryptoauthentication/default.aspx ), which are chip, small, things with relatively low-speed (1Mbps I2C) interfaces...

So you do realize that the I2C interface being limited to 1Mbps does not make a data encryption rate of 50 MBps infeasible, right? If this seems like a novel concept to you, you really do need to read up on Diffie-Hellman as a very first introduction.

[westfw]

So you do realize that the I2C interface being limited to 1Mbps does not make a data encryption rate of 50 MBps infeasible, right?

No, I didn't.  It's pretty dependent on how the chip actually works, isn't it?  It COULD be set up so that you have to pump all your data through it, or I guess it could be set up to share processing with whatever is accessing it.   I didn't look into the details of how the chip works, and my DH is knowledge is rusty and slim (took and passed the first Stanford MOOC; went "whoa; everything is more complicated than I thought, and almost everything is broken!", haven't encrypted anything since...)

Highly secure private keys can be handed out from a central server

central servers have their own sets of problems.  One of the big ones is that the people who operate the central servers seem to want to be paid rather continuously, by somebody.  So "security by server" seems to happen mostly on subscription-based things.

dismissing security as a problem not worth considering because there are human factors at play is the height of laziness and unacceptable.

I'm more along the lines of thinking that "fancy and computationally expensive encryption is necessary or sufficient to make IoT devices "secure" is the height of ivory-tower blindness to the real world."

I do agree that IoT needs to do better than it is now.  But doing that without willful cooperation of the users is a REALLY HARD PROBLEM, entirely independent of encryption algorithms.  And the truth is that no one really wants to be a sysadmin for their light bulbs, thermostats, irrigation systems, and so on.

[technix]

I'm more along the lines of thinking that "fancy and computationally expensive encryption is necessary or sufficient to make IoT devices "secure" is the height of ivory-tower blindness to the real world."

I do agree that IoT needs to do better than it is now.  But doing that without willful cooperation of the users is a REALLY HARD PROBLEM, entirely independent of encryption algorithms.  And the truth is that no one really wants to be a sysadmin for their light bulbs, thermostats, irrigation systems, and so on.

One of my friend have an IoT-disrupting backpack. Inside there is a battery bank, a Raspberry Pi and a lot of IoT interface chipsets attached to it - nRF24L01+, LoRa, Bluetooth, WiFi - you name it, he has it. The Pi have code searching for unsecured IoT devices and send them into haywire. Now let's hope he don't walk by your home with his backpack...

Speaking of Raspberry Pi, it comes with a built-in true random number generator, good for generating very high quality cryptographic keys to be injected into the devices. A BJT reverse biased can be used to generate shot noise - a quantum-backed true random number generator - for any MCU with a spare ADC channel. This way your devices can generate its own cryptographically strong private keys and send the public key off for signing and authenticating.

[nctnico]

I'm more along the lines of thinking that "fancy and computationally expensive encryption is necessary or sufficient to make IoT devices "secure" is the height of ivory-tower blindness to the real world."

I do agree that IoT needs to do better than it is now.  But doing that without willful cooperation of the users is a REALLY HARD PROBLEM, entirely independent of encryption algorithms.  And the truth is that no one really wants to be a sysadmin for their light bulbs, thermostats, irrigation systems, and so on.

If you read about security then one of the basics is that security is based on Authorisation, Authentification and Accounting (keeping track of what happens). It doesn't even say a thing about encryption! IMHO encryption is way too often used as some magic sauce to try and make a system secure.

[technix]

I'm more along the lines of thinking that "fancy and computationally expensive encryption is necessary or sufficient to make IoT devices "secure" is the height of ivory-tower blindness to the real world."

I do agree that IoT needs to do better than it is now.  But doing that without willful cooperation of the users is a REALLY HARD PROBLEM, entirely independent of encryption algorithms.  And the truth is that no one really wants to be a sysadmin for their light bulbs, thermostats, irrigation systems, and so on.

If you read about security then one of the basics is that security is based on Authorisation, Authentification and Accounting (keeping track of what happens). It doesn't even say a thing about encryption! IMHO encryption is way too often used as some magic sauce to try and make a system secure.

There will be Confidenciality, Integrity and Availability assumptions in most Authorization, Authentication and Accounting schemes which have to be fulfilled by using cryptographic primitives appropriately. (Not so much about Availability, but the remaining two...)

The cryptographic primitives employed by TLS, in effective TLS itself, can be used to construct a secured channel on which the CIA assumptions of AAA are fulfilled. Among those primitives the symmetric (bulk) cipher is the heaviest used and hence benchmarked here. All four cipher suites here offers some AEAD (that includes ARS256-CTR-SHA256-HMAC although it is prohibited in TLS 1.3 while allowed and considered strong in TLS 1.2,) with three of them available in the latest TLS 1.3 draft which mandated strong AEAD cipher (AES256-CCM, AES256-GCM and ChaCha20-Poly1305)

[Kjelt]

Still waiting for the microcontroller manufacturers to integrate a small piece of secure otp or other piece of memory that is outside the uC memorymap (so unreadable by programmers or hackers) that can be used in some sort of keyderivation operation by the security peripheral.
uCs benchmarking is dependent on your application, if you want internet connectivity the weakest link is the huge amount of codesize neccesary to implement a secure ethernet stack that can handle multiple protocols. The micro itself like a m3 or m4 is fast enough, the tls handshake with the asymetric (pk) crypto takes the most time 100s of ms) The AES symmetric data encryption took 10% overhead on my projects (ms,s)

[nctnico]

Still waiting for the microcontroller manufacturers to integrate a small piece of secure otp or other piece of memory that is outside the uC memorymap (so unreadable by programmers or hackers) that can be used in some sort of keyderivation operation by the security peripheral.

That is a contradiction. If a memory like that can be accessed somehow it can be read (or written if possible).

[Bruce Abbott]

Now let's hope he don't walk by your home with his backpack...

Your 'friend' better not walk by my home with that stuff turned on - for his sake.
 

[jnz]

. Highly secure private keys can be handed out from a central server when a device is first activated, once again making the question of passwords irrelevant.

I feel like everyone else missed this - I hope you mean central server giving the device a private key AT PRODUCTION and not when in use in the customers hands!

Asymmetric encryption:

• Data encryption, this is using (for example) an ECC PUBLIC Key to encryption something that only the PRIVATE key can decrypt. You do NOT hand out PRIVATE keys, you hand out PUBLIC. The issue with this is that you hand out the public key to someone, you don't actually know it was them that encrypted something. This gets into ECDH transfers and certs.
• Data Signature, where again using ECC as an example, the PRIVATE key adds a signature to some block of data, then anyone with the PUBLIC key can verify that this is legit. It's slightly confusing because in this case the public key is used to "decrypt" (but not really) which is backwards from using the public to encrypt (actually). In this case you still do NOT hand out PRIVATE keys. You use your private key to sign data, public key to verify it, anyone can verify only one can sign. The issue here is that your data is not encrypted, anyone can read it - but no one can change it.

Seeing you guys of all people write "hand out private keys" and no one correct it. Tisk Tisk!


In terms of the topic at hand. No. This is pointless. I can tell you an ARM Cryptocell or any hardware AES or ECC function is going to outperform any software out to a micro being 7-10x faster.

As to Atmel's Cryptochips... I looked into them. They're nice if you trust the I2C connection where you can pass a block of data in and get it encrypted, but if someone is trying to hack your device, you better have a better plan than one that can be easily thwarted with a logic analyzer. Most of the time these cryptochips are for storing a known OTP cert on, or they're programmed with the private key in an "unhackable" device and it sends the module the public key to use for encrypting or verifying the signing.  Using one to encrypt your data means you must trust the I2C physical connection, and IMO, that's dumb.

For those cryptochips, don't think ECC encrypting data device to secure all IoT traffic. Think printer cartridge loaded with a unique and validatable cert to prevent knockoffs.

[Kjelt]

Still waiting for the microcontroller manufacturers to integrate a small piece of secure otp or other piece of memory that is outside the uC memorymap (so unreadable by programmers or hackers) that can be used in some sort of keyderivation operation by the security peripheral.

That is a contradiction. If a memory like that can be accessed somehow it can be read (or written if possible).

The result can be read and the input written but all operations inbetween are for the microcontroller itself a blackbox operation. Think small cheap tpm like functionality.

[Kjelt]

For those cryptochips, don't think ECC encrypting data device to secure all IoT traffic. Think printer cartridge loaded with a unique and validatable cert to prevent knockoffs.

Yes those are authenticators. There are chips from Infineon that on their own can handle the entire tls protocol, where the uC is only the ethernet interface and shuffles the data throughput. However as you mention in the end the cleartext data has to be sent to the uC in order to do something usefull and any outside device is vulnerable in its communication. Besides those chips cost a bloody fortune well more than the uC itself.

[jnz]

There are chips from Infineon that on their own can handle the entire tls protocol, where the uC is only the ethernet interface and shuffles the data throughput. However as you mention in the end the cleartext data has to be sent to the uC in order to do something usefull and any outside device is vulnerable in its communication. Besides those chips cost a bloody fortune well more than the uC itself.

It took me awhile to understand how these chips were useful, and I pretty much decided they kind of aren't. I mean, for me. If you need fast encryption access and your micro doesn't have it, fine. But I just would feel like I was giving up too much by allowing anyone with a logic analyzer to see the unencrypted data.

Its been my prerogative the pre-shared key/cert outside of the user's hands is probably safer but I'm not doing web TLS.

[westfw]

anyone with a logic analyzer

The current set of IoT "security problems" are not the sort where logic analyzers are an "expected attack vector"...
The expected set of IoT "security problems" are not the sort where logic analyzers are an "expected attack vector"...

Now, if the logic analyzer can figure out an attack that breaks ALL of the IoT devices of that type, THAT'S a problem.
It really bugs me when "security folk" go off on "if a device can be broken with $100k worth of equipment and some liquid nitrogen, doing side-channel attacks based on power consumption, you might as well have done nothing at all" tangents...

[nctnico]

I don't think that anyone is claiming that no encryption needs to be applied because it will be broken anyway. It is just that allowing (simple) access to unencrypted data makes it easier to do a brute force attack on the encryption key.

[technix]

Now let's hope he don't walk by your home with his backpack...

Your 'friend' better not walk by my home with that stuff turned on - for his sake.

I doubt whether he would still be close to your home when the payload finally goes off. Or if you can pinpoint him among the crowds of pedestrian walking by.

[Kjelt]

It really bugs me when "security folk" go off on "if a device can be broken with $100k worth of equipment and some liquid nitrogen, doing side-channel attacks based on power consumption, you might as well have done nothing at all" tangents...

Then you have not spoken to a true security person since such a person would state that security is like an onion, you need multiple layers (as many as possible/affordable) of security.
If one fails another one should be in place.
One of those layers is physical access to the device, the ballgame gets much harder when you have to account for an attacker to have physical access to the IoT device itself.
If you sell products where everyone could have access you better have your stuff in order, so not one big secret somewhere in the code for all devices, because if you do than yes if someone can easily find it or sniff it (even with $10k of equipment) you are toast.

[Kjelt]

I don't think that anyone is claiming that no encryption needs to be applied because it will be broken anyway. It is just that allowing (simple) access to unencrypted data makes it easier to do a brute force attack on the encryption key.

It is worse, the transport is secure (TLS) but the decrypted plaintext data is sent back to the uC over a non encrypted channel (SPI or I2C), you need nothing to brute force just sniff the data back with an analyzer.
The whole issue is that using an external security chip provides some level of defense but not againtst physical access to the device.
There is only one way to do that properly and that is integrate the security on the endpoint chip itself (the uC).

Now the semicon companies I talked to that have this technology are not able to integrate the two, because they say that the secure part has to be in a high nm process with all kinds of technical challenging stuff like multilayer, intrusion detection grids etc. etc. and that the uC has to be in a low nm process in order to be small enough and affordable enough. So the two do not mix well
Broadcom could do it and they are doing it for expensive controllers like you find in the $160 routers etc. those chips are probably costing > $5 below 1Mpcs
So this is not your ordinary IoT gadget device pricepoint, and that should be the lesson to all: do not think you can make an affordable IoT device without proper security.
If you do want to have cheap IoT devices do NOT let them have a public facing ethernet interface, let them talk on their own subnet (or wireless) to a gateway which can be more expensive and let that device be the only thing visible to the outside.

[Jeroen3]

Most "hacks" of IoT products are just bugs in how the web stuff works.
Send some fancy stuff over GET. Directory traversal bugs. Put some weird chars in the username. And they'll barf the output.
That is after you've tried the default password. Or you just ask for it over sms.

https://twitter.com/terrajobst/status/850766832390750209/photo/1

You can't use encryption to fix bugs.

[technix]

I don't think that anyone is claiming that no encryption needs to be applied because it will be broken anyway. It is just that allowing (simple) access to unencrypted data makes it easier to do a brute force attack on the encryption key.

It is worse, the transport is secure (TLS) but the decrypted plaintext data is sent back to the uC over a non encrypted channel (SPI or I2C), you need nothing to brute force just sniff the data back with an analyzer.
The whole issue is that using an external security chip provides some level of defense but not againtst physical access to the device.
There is only one way to do that properly and that is integrate the security on the endpoint chip itself (the uC).

Now the semicon companies I talked to that have this technology are not able to integrate the two, because they say that the secure part has to be in a high nm process with all kinds of technical challenging stuff like multilayer, intrusion detection grids etc. etc. and that the uC has to be in a low nm process in order to be small enough and affordable enough. So the two do not mix well
Broadcom could do it and they are doing it for expensive controllers like you find in the $160 routers etc. those chips are probably costing > $5 below 1Mpcs
So this is not your ordinary IoT gadget device pricepoint, and that should be the lesson to all: do not think you can make an affordable IoT device without proper security.
If you do want to have cheap IoT devices do NOT let them have a public facing ethernet interface, let them talk on their own subnet (or wireless) to a gateway which can be more expensive and let that device be the only thing visible to the outside.

This is why I am investigating crypto on micro. If I can run a full TLS stack with elliptic curve public key cryptography, SHA256 hash and ChaCha20-Poly1305 AEAD cipher, I get a complete, strong TLS 1.2/1.3 stack.

[nctnico]

The biggest problem with a full TLS stack is that it takes way to much memory because of all the excess baggage which comes with TLS like key exchange during the link initialisation phase. In case of IoT devices you should forget about TLS because it is not going to be viable for at least 5 to 10 years. The only ability an IoT device needs to have is:
1) decrypt incoming messages using a preloaded key
2) encrypt outgoing messages using a preloaded key
3) keep the key a secret
4) allow remote reprogramming of the key
The key is used for both authentification and authorisation. A standard way of doing this isn't complicated.

[technix]

The biggest problem with a full TLS stack is that it takes way to much memory because of all the excess baggage which comes with TLS like key exchange during the link initialisation phase. In case of IoT devices you should forget about TLS because it is not going to be viable for at least 5 to 10 years. The only ability an IoT device needs to have is:
1) decrypt incoming messages using a preloaded key
2) encrypt outgoing messages using a preloaded key
3) keep the key a secret
4) allow remote reprogramming of the key
The key is used for both authentification and authorisation. A standard way of doing this isn't complicated.

If you find TLS too cumbersome, you can use something like PGP-over-HTTP. Although this does sacrifice perfect forward secrecy which TLS 1.3 offers.

I have a project coming up soon, implementing a NeoPixel LED strip controller with wired Ethernet. It controls the LED lighting in my multi-computer rack so control must be shared. I don't have a second managed Ethernet switch so it have to work in my Internet-facing main network. This will involve STM32F107RCT6 or STM32F407RGT6 implementing a full TLS 1.2 stack (and IPv6 as my home network has it.) The cipher suite I would support is ECDHE-ECDSA-ChaCha20-Poly1305 (a TLS 1.2/1.3 AEAD cipher suite with perfect forward secrecy) and also a TLS certificate using elliptic curve cryptography.