4
votes

I am trying to figure out what encryption/security strategy to adopt for IoT based solution. Here's my assessment.

  1. The fundamental assumption of any security system is that the algorithm can be cracked, hence the key has to protected.

  2. TLS will act as a protective layer for packets sent over the air. This is mostly taken care by the wireless device. This is not enough & data has to be protected further.

  3. The data that has to be encrypted we can use various encryption algorithms. Out of that AES seems to be the most reliable one. I am not able to confirm if AES is a public - private key algorithm or symmetric key (single key for encode-decode) algorithm. Please shed more light on this.

Has anyone come across a strategy wherein:

  1. Every device / node has a different encryption key. This is very important because a hacker can simulate certain periodic data without understanding the underlying encryption. So if the hacker is able to figure out that xyz packet produces certain behaviour in the device, encryption is of little consequence.

  2. Can we change the secret key on the fly, so something like for each session created, the server will update the key for the next connection ?

Are my assumptions right ? Also it would be great if you can suggest me best practices for security in an IoT environment.

Regards,

Chaitannya

1
I'm voting to close this question as off-topic because asking for security advice is better suited for Information Security Stack Exchange not Stack Overflow. - Scott Arciszewski
What do you mean by TLS... is not enough and data has to be protected further.? If you are using TLS to communicate between devices then you don't need any further encryption... - Luke Joshua Park
Though I don't have the ability to vote, I agree with Scott that this is off topic. An example of an on topic question might be how to scale such security. - Taylor Kidd
If you are creating a mass market IoT device you really need to hire a cryptographic domain expert with experience with IoT devices. That will save you in the long run and you will be able to sleep well at night. Otherwise it is almost guaranteed that there will be a security flaw. - zaph
I’m voting to close this question because as indicated, this is security advice and not programming advice. - Maarten Bodewes

1 Answers

4
votes

Your assessment is not entirely correct.

  1. The assumption is not that the algorithm can be cracked, but that the algorithm and all input data other than the key is known to an attacker. In the case of AES, the standard is widely published, but this does not make it ineffective as it is designed so that the data cannot be easily decrypted without applying the key. AES128 and the other (higher) key sizes are considered secure enough to withstand modern day brute-force attacks.

  2. The wireless device, assuming you are using WPA/WPA2, will encrypt traffic over the air however that encryption ceases to apply once the packets have been received in the wireless access point. They will not be encrypted between the access point and their final destination.

  3. AES is a symmetrical key algorithm. There are two encryption strategies for you to consider. Encryption in transit between the source and the destination, and encryption at rest. It is unclear which of the two you are referring to, however each requires separate consideration and implementation. If you are referring to encryption in transit between servers, consider using an encrypted protocol such as HTTPS/SSL which is designed to encrypt data in transit using a variety of ciphers. AES is widely used as an appropriate cipher for encryption at rest, either at the file system level or using libraries to encode the data before storing in a database.

  4. In the case of HTTPS, it is strongly recommended that each client/server have its own private key. In the case of AES, again, each server should encrypt data at rest using it's own key.

  5. You are concerned about the possibility of packet capture and replay to control your server, however if you use a protocol similar to SSL, it will use a different key for each session to prevent pattern analysis via eavesdropping. If you are encrypting the data yourself to send, adding a simple time stamp or sequence number to the encoded data will ensure it has a vastly different encrypted output each time. For example CONTROL|START|10:20pm will result in completely different encrypted data to CONTROL|START|10:21pm. AES also allows the use of what is known as an initialisation vector (IV) that, by using a random seed, will encode the same data into a completely different output each time.

There are also a number of IOT messaging systems provided by cloud providers such as Microsoft and Amazon that contain some of the encryption strategies that might be useful to you.

In regards to best practices, I am not recommending any particular vendor, however this link may be useful to show you how such a setup may operate: AWS IoT Security