Hello everyone,
I am working on a project that has a file of about 15MB that needs to be transferred to an SD card. I have this working using the HTTP and SDFat libraries. The problem is that i cannot use HTTP because of security concerns. I do not have the space to use https. What other options do i have?
Thanks in advance to anyone who looks.
Ali
If you have control over both the server and device side and can settle for less fancy encryption what I would do is:
Use a lightweight encryption library. I like this library using the Speck encryption protocol. It will add less than 6K of code size.
You can’t connect to an ordinary https server, of course, but you can, for example, do Speck over TCP to a node.js server that implements the server-side encryption.
Use static encryption keys, say 192-bit or 256-bit ECB keys.
This is not ideal from a security standpoint! It’s a compromise between small code side and is way better than clear text, but not establishing a session key isn’t great especially if your data is somewhat predictable. You’ll probably want to send along a validation hash (SHA-256, for example) to verify your file contents. That code is pretty small as well.
You could also use AES-128 with static encryption keys. The code for that is pretty small too.
I second this. Speck is very controversial, and ECB is probably not a great idea. From Wikipedia
(And the particle.io CTO in AES encryption demo and secure TCPClient usage - #3 by zachary)
@Ali what do you mean by 'security concerns'? Just needing to be sure the files were not tampered with is a different problem than needing to make sure no one can read them in transit.
@kenmacd Both the issues need to be addressed.
For now the former is more important. The file being downloaded is a binary tft file. I am using a checksum to check validity of the downloaded file before uploading it to the touch screen. This however is not enough for the powers that be and they want more secure options.
I plan to implement a camera and send pictures in the next upgrade. So those do need to be encrypted before being sent.
Is AES the way to go then?
AES alone would get you confidentiality, but not authentication.
If it was normal hardware I'd say TLS (SSL) by default unless you had a strong reason to need something else. There is this project that looks like it tries to keep it pretty small, but you'd have to see if it's fast enough for your use-case. Going outside standard TLS is risky as it's easy to mess things up (even in TLS), and this will be the most standard for connecting to a backend server.
If this didn't work you could look at using DTLS and CoAP, like the devices are already using to talk to the cloud. This might require more work on both sides of the channel though.
If you're not necessarily talking to a webserver, or you're processing so much data that the above just doesn't work, then you could look at using another algorithm. I would avoid ECB though. You want one that's AEAD (authenticated encryption with associated data). I'd probably land on Acorn128 (also in the above library). Something using speck in a non-ECB mode is also probably fine, but the algorithm is controversial.
Do you know what the size of the above example is? It seems like it would be workable for me. My application size is currently at ~90kb.
Edit:
I did a compile on build
Output of arm-none-eabi-size:
text data bss dec hex
85332 240 10268 95840 17660
In a nutshell:
Flash used 85572 / 110592 77.4 %
RAM used 10508 / 20480 51.3 %
Hi I am trying to send large pdfs and svgs across a boron particle board. I am wondering if the libraries needed were ever figured out how to send these large files. And if there was a more secure library to use to make sure the data is secure?