I'm currently working on a rather simple project that requires an Android device to fetch values measured by analog sensors.
I have decided to make the Arduino Uno a Web Server over HTTP that sends an HTML page directly defined within the code (through the client.println() function). Everything works just fine, with the smartphone properly reading the HTML page alongside the values.
The phone also regularly downloads the "raw" values from the sensors in order to display a notification if one of them rises above a specific threshold (pull connection).
Now, I'm concerned about security issues. If I did this project back in the 90s or the 2000s, I'd probably not have worried yet today secure connections become a proeminent requirement to ensure that the data is properly transferred; especially because of man-in-the-middle attacks.
So, I've concluded that securing the transfer is a necessity. Now, the Arduino Uno card is not powerful enough to handle the SSL or TLS protocols, meaning that HTTPS cannot be achieved (I'd need a certificate anyway).
However, I found that the Arduino Uno card could handle AES-256 encryption. From what I know, it requires the two ends to have a similar "key" that allows decrypting and encrypting data. But it 's actually more complex than that.
Although the final project will run over the Internet, our prototype isn't linked to the Internet and uses a local network. As such, I was wondering if directly storing the AES key on the Android device and the Arduino card was enough of a security? Should the Arduino send the key to the application?
I don't really know how to handle AES-256.
Hopefully it wasn't too much of a pain to read, thanks in advance.
If security is really a concern then sending the key isn't going to work, since that could be intercepted too. You would need to set it on both the Arduino and Android device.
Trevor_M has it right. A pre-shared key for symmetric encryption has to be secure, always. You cannot send it in the clear and expect it to be safe, and Arduino isn't really able to handle asymmetric encryption on its own to allow for encryption without a pre-defined symmetric encryption key.
Also consider that for best practice security, you also need to sign messages after encrypting them (and you need to verify the message before decryption). This is what HMACs (hash-based message authentication code) are used for, and they also use a pre-shared key which should be separate from the encryption key.
Hashing will be somewhat more computationally heavy for the Arduino, but it is very much doable. E.g. use an HMAC based on SHA256 for strong security.
AVR-Crypto-lib implements both SHA256 and SHA1 based HMAC. The execution time on their wiki indicates that their HMAC-SHA256 is in the order of around 2-4 times more computationally demanding as their implementation of AES256.
Trevor_M:
If security is really a concern then sending the key isn't going to work, since that could be intercepted too. You would need to set it on both the Arduino and Android device.
That's what I guessed, but I also believe that there should be some kind of algorithm to avoid similar files to have a similar encrypted form.
logan893:
Trevor_M has it right. A pre-shared key for symmetric encryption has to be secure, always. You cannot send it in the clear and expect it to be safe, and Arduino isn't really able to handle asymmetric encryption on its own to allow for encryption without a pre-defined symmetric encryption key.
Also consider that for best practice security, you also need to sign messages after encrypting them (and you need to verify the message before decryption). This is what HMACs (hash-based message authentication code) are used for, and they also use a pre-shared key which should be separate from the encryption key.
Hashing will be somewhat more computationally heavy for the Arduino, but it is very much doable. E.g. use an HMAC based on SHA256 for strong security.
AVR-Crypto-lib implements both SHA256 and SHA1 based HMAC. The execution time on their wiki indicates that their HMAC-SHA256 is in the order of around 2-4 times more computationally demanding as their implementation of AES256.
If we consider that two or more different packets might be exactly similar, should this encrypt the data differently for both packets? I'm not sure that it does…
Robin2:
Are you worried about someone else reading your data?
Or are you worried about the possibility that the received data might not be the same as the transmitted data?
They are two very different issues. I suspect the latter could be dealt with by including a CRC check value in your data.
I am curious to know what you are doing that might be interesting enough (or valuable enough) to make hacking worthwhile ?
...R
The main problem is possible man-in-the-middle attacks. The data is not especially sensible — no credit card number, no password —, but may be modified to cause false reports.Yet adding a CRC check is not a bad move.
Why would anyone waste their time trying to do that unless they know who you are (or what business you are in) and know that the false reports would cause you a lot of inconvenience.
If you are just worried about the chance occurrence of somebody hacking you rather than any one of a million other patsies with Arduino programs then it is not something that would bother me beyond including some extra data in the message that the receiver could use to know that it had not been altered.