- Getting Started
- Software Products
- SNAP RF Modules
- IoT Components
- IoT Gateways
- Legacy Products
Communications between SNAP devices are normally unencrypted. Using the SNAP Sniffer (or some other means of monitoring radio traffic), you can clearly see the traffic passed between devices. This can be very useful when establishing or troubleshooting a network, but it provides no protection for your data from prying eyes. Encrypting your network traffic provides a solution for this. By encrypting all your communications, you reduce the chances that someone can intercept your data.
SNAP devices offer two forms of encryption: AES-128 and Basic encryption. If you have a compatible firmware version loaded into your devices, you can configure them to use AES-128 encryption for all their communications. You must have a firmware version that enables AES-128 to be able to do this. You can determine which firmware is loaded into a device by checking the Node Info pane for the device in Portal. Firmware that supports AES-128 encryption will include “AES-128” in the firmware name.
Devices that support AES-128 encryption are not available in all jurisdictions. Also, the Si100x platform does not have an AES-128 build available, due to space constraints. (The RF300/RF301 builds, based on the Si100x platform, have external memory available and therefore do have AES-128 builds available.) Users who would like some protection for their data but do not have AES-128 encryption available can use Basic encryption instead. Basic encryption is not strong encryption and should not be relied on for high-security applications, but it does provide a level of protection to keep your data away from curious onlookers.
Enabling encryption requires two steps. First, you must indicate that you would like to encrypt your traffic and specify which form of encryption you wish to use. Then, you must specify what your encryption key is. After rebooting the node, all communications from the device (both over the air and over the UARTs) are encrypted, and the device will expect all incoming communications to be encrypted. It will no longer be able to participate in unencrypted networks.
NV50 - Enable Encryption is where you indicate which form of encryption should be used. The valid values are:
- 0 = Use no encryption
- 1 = Use AES-128 encryption
- 2 = Use Basic encryption
NV51 - Encryption Key is where you specify the encryption key for your encrypted network. The key must be exactly 16 bytes long. You can specify the key as a simple string (e.g., ThEeNcRyPtIoNkEy), as a series of hex values (e.g., x2ax14x3bx44xd7x3cx70xd2x61x96x71x91xf5x8fx69xb9), or as some combination of the two (e.g. xfbOFx06xe4xf0Forty-Two!). Standard security practices suggest you should use a complicated encryption key that would be difficult to guess.
No encryption will be used if:
- NV50 - Enable Encryption is set to a value other than 1 or 2.
- NV50 - Enable Encryption is set to 1 in a device that does not have AES-128 encryption available in its firmware.
- The encryption key in NV51 - Encryption Key is invalid.
When you are establishing encryption for a network of devices, it is important that you work “from the outside in.” In other words, begin by setting up encryption in the devices farthest from Portal and work your way in toward your nearer devices. This is necessary because once you have configured a device for encrypted communications, it is unable to communicate with an unencrypted device.
Consider a network where you have Portal talking through a bridge device, named Alice, and Alice is communicating with devices Betty, Carla, and Daphne. If you configure Alice for encryption before you configure Betty, Carla and Daphne, Alice will no longer be able to reach the other three devices to set up encryption in them. They will still be able to communicate with each other, but will not be able to talk to (or through) Alice (and therefore will not be able to report back to Portal).
In the same environment, if you are relying on multiple hops in order to get messages to all your devices, if any intermediate device is encrypted all the unencrypted devices beyond that one are essentially orphaned. If Daphne relays messages through Carla, and Carla relays messages through Betty to Alice (and thus to Portal), and you configure Carla for encryption before you configure Daphne, you will not be able to reach Daphne to set the encryption type or encryption key.
As with all NV parameter configuration, the changes you make will only take effect after the device reboots. If you lose contact with a device as a result of a mistyped or forgotten encryption key, you will have to use Portal to reset the device back to the factory default. This will set NV50 - Enable Encryption back to 0 and NV51 - Encryption Key back to “” to disable encryption. Simply making a serial connection to the device to reset the encryption key will not be sufficient, as serial communications, as well as over-the-air communications, are encrypted.