httpS webserver Arduino Nano RP2040 Connect

[ams1]

Hi all,

First of all THANK YOU for... like... everything you do! 🤗

Regarding the:
https://docs.arduino.cc/tutorials/nano-rp2040-connect/rp2040-ap-web-server-rgb

Is there example/plan regarding a SECURE HTTP server?

I'd be particulary interested IF taking advantage of the ATECC608A-MAHDA-T Crypto IC would make serving via HTTPS even faster.

I've tried HTTPS on a RP2040 (without a crypto chip) using circuitpython, but the initial session setup takes 5-6 seconds with a 1024-bit RSA.
The ESP32-S3 claims 2 seconds: https://docs.espressif.com/projects/esp-idf/en/latest/esp32s3/api-reference/protocols/esp_https_server.html#performance

Again, thank you.

[gershnik]

I wrote up one possible way of doing it at https://gershnik.github.io/2024/04/03/https-arduino-nano-rp2040.html and a fully functioning example at https://gist.github.com/gershnik/072d112071d0d61adc495d6f36947d45

It is not using the crypto chip but I get about 2.6 seconds for SSL handshake part with 1024 bit RSA key. This is without MBed TLS session cache which might improve it even more at some memory cost.

[ams1]

Hi @gershnik,

Thanks for the reply!

I did some related experiments and cache helps a LOT if you need to re-connect in a short time window - subsequent connections are like instant (at least using Chrome).

Please post here if you do more experiments - ex. with 2048 bits keys.

[gershnik]

Well in my own work I use 384 bits ECC key which clocks at 3.2 sec for handshake. This is far superior to larger RSA due to small key and certificate size.
But for my needs whether it is 2 seconds or 6 is all the same - too slow to be used pervasively. I use HTTPS the way people run web servers in the 1990s 🙂. Most communications are over plain HTTP with a few rare calls that need to be secure over HTTPS. (This is why I also don't use session caching. Since secure calls are rare there are no reconnects in short time window and no reason to pay the memory price for cache.)

[gershnik]

@ams1 you got me curious with the idea of using the secure chip so I decided to investigate if this is indeed possible. As a first step I simply built and used the latest LTS version (3.6.0) of Mbed TLS rather than to use the one included with the board's MBedOS. (This step is not for faint hearted since you need to rip out old Mbed TLS from libmbed.a to avoid symbol collisions).

In any event after figuring out how to configure it just doing this ¹ produces: ~1.5 sec for TSL handshake with 384 bits ECC key. That's half of what I get with the stock version!

Further, building it with -O3 flag rather than tradition Arduino -Os drops the time to ~1 seconds. Now this is getting close to being fully usable pervasively.

My next step is to actually try to use the secure chip for random number generation and elliptic curve stuff (if I can figure that out).

Footnotes

1. I made one possibly significant change to how MbedTLS is configured. The stock one defines MBEDTLS_AES_ROM_TABLES while I left it undefined under the assumption that RAM access is faster than memory mapped flash and the memory savings aren't that significant on Nano RP2040. ↩

[ams1]

Thank you for going down this 🐰 hole! For sure I would have fainted along the way 😅.

I realize it's a high risk endeavor (there could be "catches" along the way) - hope for you the journey is be rewarding per se -> respect!

Let me know if there is ANYTHING I can do to help.

[gershnik]

Thank you for the kind words!
So I looked into using the crypto chip and even got it almost working but... There are a couple of big problems (both facets of the same issue) that make it pretty much useless to me.

First it only supports a single elliptic curve (it doesn't do RSA at all as far as I can see, in case you care) - SECP256R1. Which is pretty old (my OpenSSL needs special pleading to use it) only has 256 bits and severely limits the types of certificates you can use.

Second, in order to use that chip for anything you have to irreversibly lock its configuration 🙂. There is not even a "test mode" as far as I can see and no ability to experiment.

It seems that the chip's primary and only use case is to serve as a "secure enclave". Not a general purpose crypto accelerator. It can help with TLS as long as you basically have it generate CSR with the certificate parameters it wants and have the certificate then issued by some authority and locked into chip. And it requires somebody knowledgeable with a lot of spare chips to brick to properly configure. In short this is something for a commercial company building a "solution" on top of it, not a hobbyist tinkering.

So in short I am going to abandon the effort to use it. I'll see if I can package the solution with newer custom built MbedTLS and make it usable for a normal user without requiring to do surgery on the board library 🙂. Another interesting idea might be to try BearSSL which appears to have an Arduino port and see if it does any better speed-wise.

[gershnik]

@ams1 With BearSSL (either using one packaged in ArduinoBearSSL library or latest release from BearSSL site) I get the following for handshake:

1024bit RSA: ~700ms 🙂
384 bits ECC: ~1.6s

-Os vs. -O3 makes no difference in this case - it seems that the BearSSL code is hand optimized and doesn't benefit from compiler's help.

Overall the newest MBedTLS is still faster (if built correctly - a big "if" for Arduino IDE users!) and is much more user friendly and mature w.r.t. documentation, absence of random bugs and API familiarity/simplicity. Bear has some nice features though, like full control over memory use and lesser RAM footprint.

Either solution handily beats ESP32-S3 claimed performance, and actually makes it possibly to use SSL pervasively. I'll put together samples using both soon.

[ams1]

@gershnik WOW! The quality of your previous write-up etc. is... impeccable and I was thinking: "How?!"
Then I saw your LinkedIn and realized "Oooh, that's how!" 😄 🙏

In your opinion: why isn't what you did with HTTPS on the Nano "mainstream"? I mean to me it feels like climbing the Everest. Are the trade-offs so big?

Again THANK YOU!

[gershnik]

@ams1 Thank you!

I've put together a write-up on how to easily make a fast HTTPS server on RP2040. You can find it here.

There two samples it refers to are at:

• Mbed TLS Sample
• Bear SSL Sample

Hopefully it should allow anybody to create a reasonably fast HTTPS server on RP2040.

Why isn't running an HTTPS server on Arduino mainstream? There are quite a few reasons, some technical some not. The most important I think are

• Memory usage: regular HTTPS server takes about 40kB per connection. With Bear SSL it is possible to trim this to about 20kB but still this makes HTTPS server not practical on 32kB boards. RP2040 can handle it of course but it is only one board among many. Client only HTTPS can be run with much smaller memory footprint
• Simplicity: to run a server you need to manage certificates and deploy them to devices. It is far easier to make your device trust a single issuer and connect to a local hub or a cloud "mothership" to be told what to do. It is misguided in the long term, both architecturally (if your mothership is not accessible your device is a brick) and from security standpoint (there is a word for a bunch of devices controlled from the cloud: botnet) but it is far easier to roll out initially