Atmel ECC508A

[hazardandy]

I've been using this platform for a while, and I just want to say I'm thoroughly impressed with the completeness and features that have been built here. Huge thanks to everyone who has dedicated their time to this project.

I'm using this platform with an ESP8266 for some AWS IoT interactions, and I'm trying to increase the level of security as well as get some available working memory back by offloading the 256-bit ECC encryption to an external crypto IC: the ECC508A. Has anyone here looked into that? I think it would be awesome to have a bit more free memory available for the application, as I've definitely been hitting roadblocks as to what is capable once the ESP is doing the crypto itself.

I know this library exists, but I'm not sure how to go about integrating it with mbedtls.
http://www.atmel.com/tools/cryptoauthlib.aspx

Thank you in advance for any and all feedback.

[malachib]

No fully conclusive answers here, but it has been done and therefore should be doable in our context as well:

1. Mongoose does it https://blog.cesanta.com/iot-security-woes-cool-to-talk-about-a-problem-but-not-a-solution
2. mbedtls docs say this is a starting point https://docs.mbed.com/docs/mbed-os-handbook/en/latest/advanced/tls_hardware_acceleration/

I would love to see you realize your goal. My impression is that the bulk of the memory consumed is the interplay between TCP and Public Keys during key exchange - I wouldn't be surprised if that doesn't change much even with hardware acceleration. But that's just a speculation on my part

[anyn99]

the problem with memory consumption is that you must have buffers on tcp layer, tls layer and application layer (e.g.http). what i found is that the tls buffer is the biggest problem since the whole certificate must be held when exchanging keys. in mbedtls for example, if you have a certificate with 2-3 kb you have to have 4-6 kb buffer (for rx and tx! no async buffers atm) for your tls connection.
The maximum fragment length extension for tls could be a solution for embedded devices, but even openssl doesn't support it : openssl/openssl#955
So if you don't control both sides of the connection,this is unlikely to work.

I ended up using psk and no certificates.

[malachib]

Due to the quiet severity and ubiquity of this problem, I'm trying to solve it a slightly different way. It's nowhere near ready for primetime, but here's the project:

https://github.com/malachi-iot/mr.provisioner

[Petezah]

I have integrated cryptoauthlib into my own esp-open-rtos project, with TinyDTLS in my case. I may be at a point, some time soon, where it would be ready to share if any were interested. Would it be good just to add them to "extras"?

[copercini]

@Petezah Could you share with me, please? or make a PR?

I'm having some TLS problems and this will solve everything also reduce the load on the chip!

[Petezah]

@copercini Ok, I will try to do that for you soon. It's basically good enough to get into a PR; I just haven't gotten around to it. I'll try to expedite since you've expressed interest. :)

[Petezah]

@copercini I have a first PR out now. It includes only cryptoauthlib. Once that is merged, at some point I will share my TinyDTLS port also. I probably need to make a blog post about this library also, since it is not necessarily intuitive. But hopefully my example project will help a little.

[copercini]

@Petezah Awesome man! This will help me a lot!

[Petezah]

I finally had some time to revisit this PR (#490). I cleaned it up, and switched to Atmel/Microchip's official GitHub repo for the submodule.