33

In previous versions of Arduino, the limiting 8-bit microcontroller board, it seems that implementing HTTPS (not merely HTTP) was almost impossible. But the newer version of Arduino Due provides 32-bit ARM core - see spec here.

I tried to check several network libraries (libcurl, openssl, yaSSL), but I didn't find anyone that was already ported to work with Arduino Due.

OpenSSL is probably too heavy to be able to run on this processor, but I believe that yaSSL as an embedded library should be possible to do.

Do you have any information of a library that I can use to trigger HTTPS requests on Arduino Due?

Guy
  • 12,388
  • 3
  • 45
  • 67
  • 1
    Why not just compile OpenSSL for ARM? –  Apr 07 '13 at 19:47
  • 1
    @H2CO3 - 96KB of RAM? Good luck. – Brett Hale Apr 07 '13 at 19:48
  • @BrettHale Encryption-only parts with pure computation? Hash init tables put into the ROM or progmem? –  Apr 07 '13 at 19:50
  • @H2CO3, you *might* get something like [yaSSL](http://yassl.com/yaSSL/Home.html) to work, but Arduino development is still essentially poll-driven. It would still be a lot of work. – Brett Hale Apr 07 '13 at 19:53
  • @BrettHale Poll-driven? What do you mean by that? There are quite a few libraries already ported to Arduino - and not only to the ARM kind of device, even AVRs are targeted. –  Apr 07 '13 at 19:55
  • I've updated the question to reflect you comments. The target is to do the minimum possible to interact with HTTPS end point like Amazon SQS. – Guy Apr 07 '13 at 20:33
  • Even if you could do this, actually making HTTPS requests would take a while, considering the extremely limited processing power available. – Linuxios Apr 09 '13 at 00:36
  • @Linuxios, you are right, but we need such security as many end-points are only supporting HTTPS now. – Guy Apr 09 '13 at 09:04
  • @Guy: Does the arundio have to do this self sufficiently? If you can, for example, have it hooked up by ethernet to a Rasberry Pi (or just any computer) to which it sends very basic commands that the main computer (Pi or other) does the encryption work and the sending work? It's kinda cheating, but it really makes this more plausible. – Linuxios Apr 09 '13 at 13:32
  • 2
    Check out [this answer over at the security stack exchange](http://security.stackexchange.com/a/3213). Following that, the only other lightweight library I know of is [polarSSL](https://polarssl.org/) – stormCloud Apr 09 '13 at 18:55
  • Arduino Due is much stronger than previous version. If it is ready for real world scenarios, it should be able to handle it. If not, we might need to wait... – Guy Apr 09 '13 at 18:57
  • This might be another option, written by Peter Gutmann: "*[cryptlib](http://www.cs.auckland.ac.nz/~pgut001/cryptlib/)'s highly portable nature means that it is also being used in a variety of custom embedded system environments including AMX, ChorusOS, eCos, FreeRTOS/OpenRTOS, uITRON, MQX, PalmOS, RTEMS, ThreadX, T-Kernel, uC/OS II, VDK, VxWorks, and XMK.*" – autistic Apr 11 '13 at 17:40
  • "Must use Arduino" is not a reasonable functional requirement at a stage in a project where you are free to research and choose a one-board computer or microcontroller. (Tell that to Arduino fanbois though ...) – Kaz Apr 12 '13 at 21:07

3 Answers3

20

Unfortunately this is too long for a comment.

► No out of the box solution

From what I have gathered, there is no straightforward solution for a webserver running on the Atmel SAM3X8E ARM Cortex-M3 CPU that outputs HTTPS out of the box. Texas Intstruments provides better options at the moment using their boards equipped with a Stellaris Microcontroller ARM Cortex-M3 CPU.

► Alternative

There are several options available that render cryptographic functions, based upon which one could lay out and implement a simple secure communication protocol that communicates with an intermediary device, which in turn facilitates Rapid Application Development and SSL.

This intermediary device, for instance an off-the-shelf 70$ Android smartphone that keeps your project mobile and connected, runs a service on a specified port which in turn communicates with Amazon SQS. Already available. This may sound ugly or tough, but is much easier than doing the programmatic groundwork for a webserver with full TLS 3 support on the Arduino. Given the proper motivation the latter may be easy, but not if one just wants a fast pragmatic solution to one's own project.

► Cryptographic libraries

► Discussions

Following is a list of discussions to get you started:

Many of these libraries would still need to be adapted, but community experts can help you with that fairly quickly.

Good luck! If you are at liberty to upload your final project to github then you just gained a thanks and a follower.

simon04
  • 3,054
  • 29
  • 25
Lorenz Lo Sauer
  • 23,698
  • 16
  • 85
  • 87
  • 1
    Another cryptographic library worthy of mention is [cryptlib](https://www.cs.auckland.ac.nz/~pgut001/cryptlib/). According to the homepage, "cryptlib's highly portable nature means that it is also being used in a variety of custom embedded system environments including AMX, ChorusOS, eCos, FreeRTOS/OpenRTOS, uITRON, MQX, PalmOS, RTEMS, ThreadX, T-Kernel, uC/OS II, VDK, VxWorks, and XMK." – autistic Feb 20 '17 at 04:21
7

IMHO Arduino (including the DUE) is the wrong tool for heavy and/or encrypted web based communication. I would strongly suggest to look for more appropriate hardware in the same size and price range. As soon you get into https you are close enough to also want a lot of the other stuff that real operating systems provide. With other words I suggest to go for something like the Raspi. Similar size and prize but way more powerful, especially it can run Linux. --> HTTPS becomes simple.

Udo Klein
  • 6,784
  • 1
  • 36
  • 61
7

The big problem with https support on an arduino is the danger of overloading your processor which could make the project unviable.

Even embedded platform targetted solutions like PolarSSL can eat up too much memory and use too much processing power. Remember that even on the most streamlined implementations, SSL support is going to have to be generalized for wide adoption and will include components that you won't find necessary. There's also the question of which Certificate Authorities you will trust and how you will communicate with them for things like certificate revocation.

I would look instead towards a solution that isn't as broken on the surface for your needs. Something like CurveProtect, which is an implementation of CurveCP.

Of course, your decision will largely be based on what you want to do and how much time you want to spend figuring the problem out. PolarSSL has a footprint that can be as small as 30K (more typically close to 100K).

Steve Kallestad
  • 3,484
  • 2
  • 23
  • 31
  • 2
    Exactly my point. SSL is very heavy on resources and already tricky on real OS platforms. If at all possible this is something that I would try to avoid on an embedded system. Your revocation point is also very valid. Key management for embedded systems is definitely not trivial. Actually it is never trivial no matter which platform. But embedded adds some more subtle twists. – Udo Klein Apr 14 '13 at 13:01