search

microsoftarchive / iot-journey

a guidance project for implementing an IoT solution on Azure
Other
89 stars 34 forks source link

IoT Security : hashing the payload to avoid encryption if possible #197

Open ppatierno opened 9 years ago

ppatierno commented 9 years ago

Hi,

reading the "Introduction to IoT security" I found this in the Trustworthiness section :

"The data transmitted by a device to the IoT system must not be easily corrupted or tampered with. This will typically necessitate encrypting data that is visible on the public network. Devices might not support encryption natively, and might instead rely on a field gateway to perform this operation on their behalf. In this case, the device-to-field gateway connection must be shielded from outside interference."

It's all true but I'd like to point out that in some cases ... it's not so true :-)

If you need confidentiality on the payload that you are transferring from device to cloud, you need encryption of course but ... if you need "integrity" only you can have a simple way to achieve that (for constrained devices). In some cases you are not interested to encrypt your data because you don't want eavesdropper to see it but you simply want that the data arrives to the cloud not tampered. In this case, encryption isn't needed but you can use an hashing algorithm to process a signature (HMAC). In this case, an eavesdropper can see your data but can't tamper it. If he changes the value, the server can check that the signature isn't valid and refuses the data.

For example, in a home automation system, I'm not interested to encrypt the temperature value that is sent from my home to the cloud but I'm interested to know that my temperature value arrives to destination without modifications. I'm not interested to know that an eavesdropper knows what's temperature in my house but I don't want that he can chage the value for example from real 20 °C to false 30 °C so that the cloud sends the command into my house to start HVAC even if it's not necessary with real 20 °C.

If it's your scenario you can use low constrained devices that haven't complex encryption algorithms but simpler hashing algorithms.

Paolo.

VeronicaWasson commented 9 years ago

That's a great point that "secrecy" and "integrity" are distinct and may have different requirements/solutions.

VeronicaWasson commented 9 years ago

But also - can someone use your temperature data to infer that you went out of town for the weekend? (You stopped using your AC.) Just think really carefully before sending data in the clear, I guess is my point.

ppatierno commented 9 years ago

If you stopped your AC, it won't send data even if you decided to send them encrypted or only signed. In this scenario, the eaversdropper knows that you are out of town because he can't see any traffic (encrypted or not). However, in some other scenario it could be useful to distinct "confidentiality" from "integrity". For example, telemetry data from a connected car. Imagine oil temperature value that is useful to your car manufacturer to provide you a great service to call you when your car has a possibile oil temperature problem. In this case the main point is integrity of the data to the cloud not confidentiality. Different for health information if your doctor can check patient status at home. In this case you need confidentiality of your health information from home to the hospital.