The cost of "security"

[Kjelt]

From my point of view it is, because the entire point is to avoid the costly and slow TLS connection setup, by using already existing symmetric cipher key pair, one key per direction.  You know, the one that can take a couple of seconds on an average 32-bit ARM MCU?  When you already have a shared secret per direction, the connection setup can be made much more lightweight using a suitable cryptographic hash.  You do need reliable random nonce generator (I recommend incremental counter and a unit-specific key, put through that same hash function), so it isn't trivial to do it right, but it worked sufficiently well before we standardized on SSL and then TLS.

I agree that you do not need TLS unless you are a public server who needs to communicate with unknown 3rd parties, therefore authenticating eachother over a TTP which bloats everything bigtime.

If you have your own closed system even over the internet the above can be enough when you keep in mind to always follow standardized security guidelines in the communication, which means a single version of the suites offered by TLS, never use the secret key directly but always indirectly with hash with a random number both parties generate in the challenge/response messages.
In the challenge/response both sides proof to eachother that they are who they are this is common security practice, can be found in every security design pattern book.

[tellurium]

It is people like you who insist on slow, bloated implementations that only seem to work in reality, because on paper they look so hip and cool.

I insist to use something standard. TLS is a standard - yes it is bloated, but it is standard. It is known, documented, and pen-tested by many security groups thus it is secure with high level of assurance.

If you're self-baking your own security mechanism to replace TLS, then there is no doubt you can make it significantly more lightweight than TLS. The problem with that it is proprietory, not known, not documented, there is no way to easily interoperate with it. And with high level of assurance, it is not secure - although you might think it is. "Don't invent security" slogan exists for a reason.

There may be an impression that I like TLS. I do not like it. Just as yourself, I think it is bloated and not really suitable for embedded systems. Said that, I still think that TLS is the way go - unless you're a security guru, or there is no way to use TLS in a given project but some degree of protection is still required. I am not a security guru.

When a security community comes together and works out a good, documented, lightweight security standard & implementation for embedded systems - I'll gladly switch to it and forget about TLS.

[Nominal Animal]

It is people like you who insist on slow, bloated implementations that only seem to work in reality, because on paper they look so hip and cool.

I insist to use something standard.

That is your prerogative, but why the heck would you even participate in a discussion that discusses non-standard solutions, then?
To try and force everyone to use the standards you prefer?

Like I said twice already, I'm only describing my preference.  I tried to describe the reasons why: it is a well known technique, whose only drawback is that the shared secrets must be provided separately.  It is the initial (connection-specific) key exchange in TLS that is slow and cumbersome; after the key exchange, TLS too uses a symmetric cipher.  Thus, in my view, the obvious solution is to avoid the key exchange, by prearranging the shared secrets.  This leaves just a lightweight authentication step for the handshake.

Just because something is standard, does not make it good or practical.  Just because a standard is popular, does not mean it is the best option for all the cases where it is popular.
TLS is best we have for transport layer (say, TCP/IP) security, but it isn't a magical bullet; and it isn't the best possible for all use cases.

The problem with that it is proprietory, not known, not documented, there is no way to easily interoperate with it. And with high level of assurance, it is not secure - although you might think it is. "Don't invent security" slogan exists for a reason.

First, it would be worth zero if it was proprietary.  The entire idea is to use the same mechanism with lots of Arduino-style Ethernet-connected devices (I happen to love Teensies, and Teensy 4.1 has both native Ethernet support, and a nice Arduino/PlatformIO development support package, Teensyduino).  Nothing about it is proprietary, and it is a well known technique.

To simplify, it is like TLS except that the costly public-key exchange (using either server public key, or Diffie-Hellman key exchange) is avoided by pre-transferred secrets.  The secrets themselves are never transferred encrypted or in plaintext; only the cryptographic hashes of (the/a) secret and random nonces are, to authenticate the other side.  (I prefer separate passphrases and symmetric keys.)  The authentication technique I'd use is the same as used for password hashing, although there might be even better, zero-knowledge ones, that would still be feasible with current MCUs.

Second, I've done server-side security stuff for a quarter of a century, and am well aware of the difficulty in implementing a "new" security solution.  I am only a hobbyist with embedded devices, and an utter Uncle Bumblefuck when it comes to EE, but I know Unix/SuS/POSIX/Linux software development and especially server side stuff.  That is, I know exactly how easy it is to do it badly by reinventing a square wheel; I would not trust myself to design a new security scheme either.   I am no cryptographer, I only know how to implement the schemes.  The point is, this is not a "new" security solution at all.  I'm old enough to have seen this pattern used before SSL and TLS became ubiquitous, and I happen to know that it still is used by parties who do not trust large integer factorization to be unfeasible, but do trust their physical site security.

(I do use TLS on the server side quite happily, but I do not use the default Apache/Nginx configuration, for example.  I can even point out the flaws in Apache SuExec mechanism that tend to bite people but are not mentioned in the official documentation, if you like.)

When a security community comes together and works out a good, documented, lightweight security standard & implementation for embedded systems - I'll gladly switch to it and forget about TLS.

That would be very nice indeed; I'd love that too.

I don't expect them to, though, because very few cryptography specialists understand the limitations of embedded systems, and how that affects the operations underlying the math.  That is, most of them tend to be mathematicians, with not so good understanding about real-world programming: they do not intuitively grasp the details in computational cost.  The few exceptions (like DJB, V. Rijmen, and J. Daemen) are rather well known, but getting them involved in something like this is a pipe dream.

[ve7xen]

Yes, we absolutely must make all our devices trivially DDOS'able.

What?

The entire point is to achieve security and robustness with currently available microcontrollers and their very limited resources.
TLS has an extremely high connection cost, and requires quite a lot of resources, which is exactly why they are not the best option for current microcontrollers.

It solves a lot of practical and security problems, and is well understood, properly implemented, and compatible with existing infrastructure. The fact that it takes 2s or whatever to establish a connection is practically irrelevant in the type of devices we're talking about that are either going to open a connection and stream data over it continuously, or open a connection occasionally with no real-time constraints.

It is people like you who insist on slow, bloated implementations that only seem to work in reality, because on paper they look so hip and cool.

It's people like you who insist on reinventing the wheel that lead to incredibly fragmented markets where nothing works together, and products go obsolete and have to be tossed in the bin. Standards are never ideal, but they are a far sight better than everyone implementing a shitty version themselves.

Just like network router manufacturers who seem to hire highschoolers to fork a random Linux installation for their devices, cobbled together with spit and bubblegum, full of security holes and inane choices.  Very, very few companies actually use the people who know how to do that stuff, too.

To be honest, your 'solution' sounds far more cobbled together than the mature protocol stack that has developed around standards, and in the real world would almost certainly be far more vulnerable to attack. As you say, few companies know how to 'do that stuff', so they shouldn't be implementing it. And those who think they know what they're doing are constantly adding themselves to the long list of security geniuses who think they know better but end up implementing something incredibly vulnerable to stupid well known attacks. Don't invent your own security.

That would be very nice indeed; I'd love that too.

DTLS + CoAP

[madires]

In case someone likes to learn some basics I recommend to get a copy of 'Network Security' by Kaufman, Perlman and Spencer (Prentice Hall). Not easy to read, but explains how the important concepts and protocols work.

[tellurium]

DTLS + CoAP

DTLS is not much different from TLS.

And CoAP is just an application protocol, like HTTP or MQTT - but over UDP. A pretty shitty protocol, shall I say.

[ve7xen]

DTLS is not much different from TLS.

Use it in one of the PSK modes and it is quite simple and avoids the expensive session setup and key agreement, though of course you could use this with normal TLS as well. DTLS allows avoiding the need to implement TCP, which saves a fair amount of code. It's about as simple as you will get for a properly designed encrypted network protocol.

And CoAP is just an application protocol, like HTTP or MQTT - but over UDP. A pretty shitty protocol, shall I say.

Yes? That's exactly what it is, and it's intended to be easily translatable directly to HTTP. For the basic request/response needs of an IoT device it's generally going to be fine. If you need more capability than that, you can probably afford to implement TCP...

[Nominal Animal]

It's people like you who insist on reinventing the wheel

Which part of "this is nothing new" did you miss?

If this was new, I'd agree with you too.  But it is not.

Don't invent your own security.

GOD DAMMIT, WHICH PART OF "THIS IS NOTHING NEW" IS TOO DIFFICULT FOR YOU TO UNDERSTAND?


That said, it turns out that some TLS libraries –– but by no means all –– do support PSK.

TLS 1.2 and 1.3 do define pre-shared key ciphersuites that would avoid the costly public key math completely (DH, ECDH, or RSA key exchange): TLS_PSK_WITH_AES_128_CBC_SHA256, TLS_PSK_WITH_AES_256_CBC_SHA384, TLS_PSK_WITH_AES_128_GCM_SHA256, TLS_PSK_WITH_AES_256_GCM_SHA384, and TLS_PSK_WITH_CHACHA20_POLY1305 cipher suites; the two first ones supported by MbedTLS, all by WolfSSL.  TLS does add a bit of comms overhead (having to parse the handshake messages to see if there is support for these cipher suites), but that is perfectly acceptable.

The last one, TLS_PSK_WITH_CHACHA20_POLY1305, pre-shared key with ChaCha20-Poly1305 is particularly interesting, as WolfSSL, OpenSSL, and GnuTLS already support it, and even mbedTLS might/should/could/ought to.  Thus, a possible approach would be to define a "TLS 1.3 application profile" (in the RFC 8446 sense) where the only cipher suite supported is TLS_PSK_WITH_CHACHA20_POLY1305, and then either find a configuration of e.g. WolfSSL or fork it (SPDX-License-Identifier: GPL 2.0+) to see how minimal an implementation would suffice.  On the server side, existing GnuTLS and OpenSSL support means developers just need to be damn careful with the pre-shared keys.  On the application side, the nonce generation would need some examination from cryptographers to verify the logic is sound; I'd like some kind of counter, device-specific ident, thrown through a cryptographic hash function, discarding half the data (to throw off attacks based on consecutive observations of the nonce), to obtain the nonce.  That counter must survive powerouts and reboots.

(The fact that DJB is behind ChaCha20 and Poly1305 is not the reason I find it so interesting; nor is it because ChaCha20-Poly1305 is being heavily used by Google and Microsoft (e.g. QUIC).  It's the fact that it looks like it is the most lightweight and performant on processors without specific encryption accelerators, and doesn't need huge buffers.)

Final note: Pre-shared keys, PSK, does have one security flaw, if you consider it one: it does not provide forward security.  On one hand, that sounds bad; but on the other hand, that –– providing the secrets "offline" to the endpoints –– is inevitable anyway, and is in my opinion acceptable tradeoff here.

[Kjelt]

Final note: Pre-shared keys, PSK, does have one security flaw, if you consider it one: it does not provide forward security. 

You mean forward secrecy?
Yes but you should provide an embedded device with multiple unique secret keys, one for the firmware update for instance another for communication etc.
With a firmware update that needs a seperate secret key you can replace or update the communication key(s) if needed 
I am also a big fan of device unique keys in such a way that if one device is cracked/hacked the other devices are not compromised and the hacked devices can be blacklisted on the companies server. A new firmware update round will then suffice to continue and block the compromised devices.

[Nominal Animal]

Final note: Pre-shared keys, PSK, does have one security flaw, if you consider it one: it does not provide forward security. 

You mean forward secrecy?

Yeah, that's the correct term.  Oops.

Yes but you should provide an embedded device with multiple unique secret keys, one for the firmware update for instance another for communication etc.
With a firmware update that needs a seperate secret key you can replace or update the communication key(s) if needed 

That would be even better, yes.  (Perhaps even one for data, one for config, and one for firmware? Perhaps with alternates for each, to make transitions easier?)

Also, if the device exposes an UART or similar local interface for configuration, that too should be possible to encrypt in the exact same way as the IP connection.  By default, I'd like it to be unencrypted, but it could add an extra hurdle for anyone wanting to compromise them.  (In particular, it would make it hard for a nefarious person to just replace my device with a similar-looking and behaving but already compromised one.)

I am also a big fan of device unique keys in such a way that if one device is cracked/hacked the other devices are not compromised and the hacked devices can be blacklisted on the companies server. A new firmware update round will then suffice to continue and block the compromised devices.

Right.

For home devices, I actually prefer devices that one cannot remotely update at all, only via local connection.  It isn't really viable for companies, but for a home user (like my own use cases), I do prefer local-only update/setup, because it makes it easier to write code that is not vulnerable to typical remote attacks.  Remember, I'm talking about "typical IOT devices", Arduino-like gadgets and sensors, not full embedded devices.

As an example, I like my own wireless router config interface to only be accessible on a dedicated ethernet port on it, not wirelessly nor from internet.  It does mean that I occasionally need to plug a laptop or something to that ethernet socket, and see what is going on... but aside from Linux IP stack bugs, it's darned hard to compromise something you cannot reach via IP.  (I do have packet filter rules dropping dedicated config ethernet port source IP addresses from all other interfaces, of course: spoofer, no spoofing.)

[ve7xen]

Which part of "this is nothing new" did you miss?

It's nothing new cryptographically, but you were talking about making your own nonstandardized implementation following a well-trodden path, to avoid perceived limitations of the standard way of doing things, rather than using TLS. This is practically the definition of reinventing the wheel. I suppose this is just because you didn't realize TLS had standardized PSK modes. Though even in the absence of those modes, I do think that in almost any case, the extra cost of the key agreement is not a great argument for making up your own system, even if it is based on sound principles and primitives (which is deceptively difficult).

Doing the PSK way to the Cloud also introduces some practical scaling and key association issues. It makes plenty sense for a locally-administered system, but you probably want PKI for something centrally managed at scale. Or you use the same PSK everywhere, but that sounds like a terrible idea. So I think the PSK model makes the most sense either where you are only interested in local clients, or where there is a local 'gateway' device that implements full TLS for the link to the cloud service. The need for that extra device might also tip the scales a bit on whether you want to include a full implementation directly on the device itself.

Final note: Pre-shared keys, PSK, does have one security flaw, if you consider it one: it does not provide forward security.  On one hand, that sounds bad; but on the other hand, that –– providing the secrets "offline" to the endpoints –– is inevitable anyway, and is in my opinion acceptable tradeoff here.

The middle ground of course is the DHE_PSK modes where you obviously do have to implement Diffie-Hellman, but you can still avoid the x509 mess needed for a complete implementation. I agree though that if you're going that far to get the features you need, you can probably afford to implement the whole shebang, and that PFS is probably not that critical for most IoT situations.

[Nominal Animal]

This is practically the definition of reinventing the wheel. I suppose this is just because you didn't realize TLS had standardized PSK modes.

No.  Using TLS for this is just one option, that's all.

The thing that worries me is whether the TLS libraries do implement it correctly; it is sort of a rare beast.  See e.g. node.js and MbedTLS support (history) for PSK, for example.

It may very well be that QUIC (RFCs 8999-9002) might be a better fit, if we look at standards.

Doing the PSK way to the Cloud also introduces some practical scaling and key association issues. It makes plenty sense for a locally-administered system, but you probably want PKI for something centrally managed at scale.

Like I said, DH and ECDH key exchange can take a couple of seconds of MCU computation.

If the server can contact the device, it is a simple matter of spoofing IP packets for an attacker to trigger costly operations, causing Denial-Of-Service of the device.

So I think the PSK model makes the most sense either where you are only interested in local clients

Which is exactly my intended use case.  The devices themselves are cheap Cortex-M4/M4+/M7 -class microcontrollers.  They have limited IP stacks and not a lot of memory.  If you want something more capable, it is a simple matter of notching up to a proper CPU with a gigabyte of RAM.  I don't want to; I have lots of Linux SBCs I can use for that stuff.  I want more tools in my toolbox, not one-spanner-fits-all-because-standards.

It is my intent that the host (or 'gateway') device(s) IP address(es) would be the only one(s) that the device even reacts to.  That way, direct access to these devices could be completely blocked at the nearest firewall.  The next step is making the device-host/gateway/server handshake lightweight enough that bad connection attempts are rejected in a fraction of a second, and do not consume all of the available computational resources for seconds at a time; while the device cannot communicate upstream, it can still do useful work.

[Kjelt]

For home devices, I actually prefer devices that one cannot remotely update at all, only via local connection. 
It isn't really viable for companies, but for a home user (like my own use cases), I do prefer local-only update/setup, because it makes it easier to write code that is not vulnerable to typical remote attacks.

Yes only one of the issues also seen with the attacks on NAS'ses at the moment, is that the typical home-user is not only not security aware, but also lacks to update the firmware often, to mitigate security vulnerabilities.
In that case you need to support multiple different versions of the firmware/protocol.

Lets discuss the big elephant in the embedded security room: the lack of a small secured storage space (locker/vault) in the uC itself.
Unreadable from the outside (jtag included) and only accessible from within the code, and after erasing the code/or write protection it should be erased instantly.
Manufacturers do become aware of the need but still not that many offer this in their affordable line of uC's.
Without it you need to obfuscate your keys yourself which is mediocre at best.

[tellurium]

Lets discuss the big elephant in the embedded security room: the lack of a small secured storage space (locker/vault) in the uC itself.
Unreadable from the outside (jtag included) and only accessible from within the code, and after erasing the code/or write protection it should be erased instantly.
Manufacturers do become aware of the need but still not that many offer this in their affordable line of uC's.
Without it you need to obfuscate your keys yourself which is mediocre at best.

Yes, keeping keys on an un-encrypted storage is a security hole.

Are you talking uCs providing functionality like secure elements do, e.g. https://www.microchip.com/en-us/product/atecc608a or https://www.st.com/en/secure-mcus/stsafe-a100.html?

As far as I understand, a secure storage is not enough, since if you can read protected data into RAM, you could read it from RAM. So not only private keys are stored inside the element, but crypto operations as well happen there. You give encrypted data to the element, read un-encrypted data back.

[Kjelt]

Agreed but such a device should be inside the uC since monitoring the traffic between external security devices can be logged and all the unencrypted data can be stored. Perhaps the secret key is safe the data is not.
That is why my previous company rejected these external devices.

[peter-h]

The basic problem with IOT security is that you can't ensure physical security.

The attacker is 100% sure to obtain a specimen of your box and attack it using all the usual means. The PCB can be copied; this is a totally casual service in china (I've been offered it for $250, when the PCB company misunderstood and thought I lost the gerber data ). The CPU can be attacked and probably read out. Then any private key can be read out. He can also rig it up and capture any data, which may not be worth anything, but you never know, but it will reveal which services the box is trying to connect to.

If you were making a product which networks wholly within a sphere under your control (clients talking to your server) then a shared key is as good as anything else, and you don't get the 2-3 sec TLS handshake which actually achieves nothing IF you assume that one of your boxes has been disassembled.

TLS is secure only if you assure a) physical security of the server and b) physical security of the client and especially its server certificate store. That's more or less ok for online banking.

The bottom line is that long term IOT product functionality is achievable only if calling up a server under your control.

It has to be under your control because some commercial service can change its API and then all the installed boxes are screwed. Lots of commercial "cloud" services have changed their APIs in recent years. It affected people using e.g. winXP, which could not update its client because the updated client checked the OS version, which you can laugh at, but lots of industrial applications still run on XP and for very good reasons. But this can be solved with a VM, if you are desperate enough. With an IOT box, you will be screwed no matter how desperate you are, unless you implemented "OTA" firmware update, and are willing to take the risk of wide deployment. And for how many years are you willing to support a product with OTA?

And if the server is under your control, you can just use AES256 with a shared key

[Nominal Animal]

Lets discuss the big elephant in the embedded security room: the lack of a small secured storage space (locker/vault) in the uC itself.
Unreadable from the outside (jtag included) and only accessible from within the code, and after erasing the code/or write protection it should be erased instantly.

Absolutely.

For device authentication purposes, it would be even better if one could just supply a salt (half the size of the hash), and after some time has passed, get back a say SHA256 hash of the salt and the built-in secret.  (Basically, a slow hash silicon module with one half of the input value an unreadable OTP.)  This would uniquely authenticate each device in a manner that would make it very, very hard to duplicate the device even if you had full access to the device itself (because finding out the unseen hash takes a lot of iterations; completely unfeasible for SHA256).  The OTP secret pepper would be completely unreadable once programmed, which is the way I like it: it's hard to divulge something you do not actually know!

Manufacturers do become aware of the need but still not that many offer this in their affordable line of uC's.
Without it you need to obfuscate your keys yourself which is mediocre at best.

I don't trust obfuscation.  I prefer schemes where the device end does not actually know the secret, but has a salted hash of the secret.
It is not perfect by any means: an attacker can still duplicate the device, but at least they have to use the same salt and hash.

In this respect, Public Key cryptography is superior, because knowing one of the keys in a key pair does not reveal the other, and what one key encrypts, the other key decrypts.  It's annoying it is so damned slow to do.

As far as I understand, a secure storage is not enough, since if you can read protected data into RAM, you could read it from RAM. So not only private keys are stored inside the element, but crypto operations as well happen there. You give encrypted data to the element, read un-encrypted data back.

Yes, exactly –– and dammit, I didn't know they're that affordable (ATECC608B less than an euro apiece in singles at Mouser, if they had any).

The problem with a separate chip is that an attacker might just swap it to the compromised device; you need to pot it all in epoxy and stuff.

The basic problem with IOT security is that you can't ensure physical security.

It's not with just IOT security, it completely applies to servers as well.  It is a public secret that the easiest way to compromise a company is to compromise someone with administrator access.  Usually the executives are much easier to compromise than the actual IT personnel.

Were you aware (wrt. your embedded HTTPS server task) that crypto chips like as ATECC608B (PDF datasheet) tellurium pointed out, are so cheap and easily available? (Well, not easily now because of chipageddon.)

I definitely wasn't, and am now looking for one to add to my Teensy 4.1 to handle the annoying parts of TLS support.  (The Teensy 4.1's I have do have both native Ethernet and a total of 17 Mbytes of directly accessible memory – 8 + 8 of it in PSRAM –, but still, those crypto chips look very interesting.  Only when bought off reputable western sources, though )

The bottom line is that long term IOT product functionality is achievable only if calling up a server under your control.

Agreed – if by your, you mean the user of the IOT product.  We all know how manufacturers will shut down the servers the instant the product stops making enough profit.

[tellurium]

Yes, ATECC608s are pretty cheap.

It is not a trivial piece of hardware to use, but offers a lot. mbedTLS can be patched to delegate crypto ops to it - see https://github.com/MicrochipTech/mbedtls-examples. Then, not only a key is kept secure, but TLS gets accelerated. Handshake time could be reduced to a sub-second numbers.

The Microchip team that developed ATECC608 did a significant job in promoting it and integrating in many places, especially those associated with AWS. There are modules like https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/peripherals/secure_element.html with ATECC608 integrated, and many devboards like https://eu.mouser.com/new/microchip/microchip-ac164160-avr-iot-eval-board/.

Another functionality ATECC608 provides is the ability to mass-provision devices - the mechanism is not trivial but when it comes to large volumes, it becomes crucial to make it secure. AWS was mentioned - they have a mass-provision process based on ATECC608.

[Nominal Animal]

The Microchip team that develops ATECC608 did a significant job in promoting it

Perhaps to the hardware folks, but definitely not to the software development side; not even to Linux kernel folks (which is, no matter how you look at it, a huge part of the embedded networked device world).  Neither linux-kernel nor openwrt-devel mailing lists have a single mention of the chip, for example.

I do understand it is impossible to reach everyone, I'm just trying to convey my surprise at these chips existing at this price point; and therefore, I expect/suspect many other integrators and software developers to not know either.

(You don't happen to have a couple of these chips spare in your kit? Sorry, had to ask )

[peter-h]

The problem with a separate chip is that an attacker might just swap it to the compromised device; you need to pot it all in epoxy and stuff.

This is always an issue where an external chip contains something of value, and is traditionally addressed by copying the unique S/N (which these devices contain) to somewhere inside the CPU FLASH. Or write the unique CPU S/N (which some CPUs have) to some secure storage. And compare the two at startup. This works unless someone disassembles the firmware... Not sure if there is any basic way to solve this "transplant" issue.

Were you aware (wrt. your embedded HTTPS server task) that crypto chips like as ATECC608B (PDF datasheet) tellurium pointed out,

Yes, I was. These chips have been around for a long time, and before that you could just put a smart card chip on your board. I did a project 27 years ago with a Siemens sle44c200 which did on-chip crypto and was a few quid back then. The Microchip chips are just a lot cheaper and faster.

The CPU I am using, 32F417, has hardware crypto, but doesn't do the really useful ones like RSA and EC. It does DES, 3DES and AES but only AES is in common use now and that is used for the session, not the handshake.

We all know how manufacturers will shut down the servers the instant the product stops making enough profit.

That's true also.

[Nominal Animal]

The CPU I am using, 32F417, has hardware crypto, but doesn't do the really useful ones like RSA and EC. It does DES, 3DES and AES but only AES is in common use now and that is used for the session, not the handshake.

Seems like ATECC608B, if they were available, would have been a good addition; it'd have handled the critical weakness of 32F417 (handshake and certificate verification), while leaving the symmetric encryption to the 32F417.

(But I really know nothing about real EE design; I'm just a verbose hobbyist software dev/physicist/bumbler.)

[peter-h]

I do agree but it depends on whether

- you want to stick even more eggs into the one basket (which these days would have been a disaster; no production for some years)
- you actually need a fast TLS handshake (faster than 3 seconds); I'd say in most embedded applications you don't need it because TLS will be a client, thus hidden
- you need a device with a unique ID (useful for a lot of stuff but the 32F417 has one already, as has the Adesto SPI FLASH I am using, etc)
- your product is likely to attract counterfeiter attention (99% of stuff won't)

The issue I had with TLS messing up something else was due to poor software design; if done properly across RTOS tasks, the TLS delay will not screw up other stuff. The problem is that this stuff is so complex that almost nobody understands it, so people are reduced to integrating libs and spending months looking for bug patches for this "open source" (read: unsupported) code on the internet.

[Nominal Animal]

I'd say in most embedded applications you don't need [a fast TLS handshake] because TLS will be a client, thus hidden

The operations involved in the TLS handshake make it pretty difficult to portably co-operate with other stuff.  Being able to offload the computation-heavy part –– be this a client or the server –– to a separate chip is definitely easier.

Consider this from the library developers' point of view.

They can make everything 'monolithic' (in the thread/task sense), and leave any thread/task switching to others.  Easiest, and most portable approach, so this is the usual choice.

You can design the library API so that each call does a capped amount of CPU work.  That amount varies on every architecture, because it is defined at the source level; and the code complexity shoots through the roof.  Not worth it for a portable library.

Now, if you offload the most computationally intensive (and most difficult security-wise) parts to a separate chip, the second one becomes feasible, because typical "heaviest" operations are moving buffer contents or parsing through received headers (marking values seen into flags, because these clients don't really need the header values per se, just detect certain header values).  Essentially, by just designing what each call does sensibly, you get an acceptable implicit runtime caps, without there being any runtime capping in the code, by virtue of what each call needs to do.

So, I'm not saying these crypto chips are interesting because "wow! faster", but because "hmm; this could really simplify a callback-based/event-driven HTTPS library API".  Like I said, my Teensy 4.1's have 17 MiB (17,825,792 bytes) of directly accessible RAM, so I'm nowhere near as constrained as you are.  (But still, I'm purely a hobbyist, so the comparison is completely nonsensical.  Also, I constantly forget the business aspects of this for you. Sorry.)

The problem is that this stuff is so complex that almost nobody understands it

I suspect it is more that "nobody wants to spend the time and effort to learn this stuff", because there are so many libraries and easier ways to get seemingly similar results (by using existing libraries without contributing to them and fixing them first).  And that those who have done it, work as a developer/integrator to one of the embedded device manufacturers at quite good salaries...

When I first started with crypto stuff (again, mostly server-side back-end programming), the learning curve was steep.  Vertical, really, even when OpenSSL came along.  (Before that, I had used Blowfish, and hash-based stuff with MD5 and SHA, but all with pre-arranged keys and XOR-data-with-hash stuff –– output feedback or OFB mode; no key exchange or anything really complicated.  Even that took me time to get right, but then again, I could just be a bit slow.)

[kjpye]

The Microchip team that develops ATECC608 did a significant job in promoting it

Perhaps to the hardware folks, but definitely not to the software development side; not even to Linux kernel folks (which is, no matter how you look at it, a huge part of the embedded networked device world).  Neither linux-kernel nor openwrt-devel mailing lists have a single mention of the chip, for example.

Possibly because the datasheet seems to be only available under NDA.

[tellurium]

(You don't happen to have a couple of these chips spare in your kit? Sorry, had to ask )

I'm pretty sure I do have a couple of them.
My company was one of the first integrating them in our product and made it work with AWS IoT (then featured on AWS's reInvent 2016).

As a demo, we had a MQTTS client (which uses two-way TLS with AWS IoT) which listened for a specific MQTT topic. The data on that topic was expected to be a JS code. Once a device received it, it executed the code and sent a result to a response topic. That was just to demonstrate how MQTTS client and JS engine running on a small device (that was ESP8266 with 50K free RAM). At the time, both TLS library and JS engine were our own. Since then, we've switched to mbedTLS cause it was free since ARM bought it.

PM me your address, I'll send over.