User manual
Nodes that support AES-128 encrypon are not available in all jurisdicons. Also, the Si100x plaorm does not
have an AES-128 build available, due to space constraints. (The RF300/RF301 builds, based on the Si100x
plaorm, have external memory available and therefore do have AES-128 builds available.) Users who would like
some protecon for their data but do not have AES-128 encrypon available can use Basic encrypon instead.
Basic encrypon is not strong encrypon, and should not be relied on for high-security applicaons, but it does
provide a level of protecon to keep your data away from curious onlookers. Basic encrypon is available in all
SNAP nodes running firmware version 2.4 or newer.
Enabling encrypon requires two steps. First you must indicate that you would like to encrypt your traffic, and
specify which form of encrypon you wish to use. Then you must specify what your encrypon key is. Aer
reboong the node, all communicaons from the node (both over the air and over the UARTs) is encrypted, and
the node will expect all incoming communicaons to be encrypted. It will no longer be able to parcipate in
unencrypted networks.
NV parameter #50 is where you indicate which form of encrypon should be used. The valid values are:
0 = Use no encrypon
1 = Use AES-128 encrypon
2 = Use Basic encrypon
NV parameter #51 is where you specify the encrypon 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.,
\x2a\x14\x3b\x44\xd7\x3c\x70\xd2\x61\x96\x71\x91\xf5\x8f\x69\xb9) or as some combinaon of the two (e.g.
\xOF\x06\xe4\xf0Forty-Two!). Standard security pracces suggest you should use a complicated encrypon
key that would be difficult to guess.
No encrypon will be used if:
• NV parameter #50 is set to a value other than 1 or 2.
• NV parameter #50 is set to 1 in a node that does not have AES-128 encrypon available in its firmware.
• The encrypon key in NV parameter #51 is invalid.
When you are establishing encrypon for a network of nodes, it is important that you work “from the outside
in.” In other words, begin by seng up encrypon in the nodes farthest from Portal and work your way in
toward your nearer nodes. This is necessary because once you have configured a node for encrypted
communicaons, it is unable to communicate with an unencrypted node.
Consider a network where you have Portal talking through a bridge node (named Alice), and Alice is
communicang with nodes Bey, Carla, and Daphne. If you configure Alice for encrypon before you configure
Bey, Carla and Daphne, Alice will no longer be able to reach the other three nodes to set up encrypon in
them. They will sll 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 mulple hops in order to get messages to all your nodes, if any
intermediate node is encrypted all the unencrypted nodes beyond that one are essenally orphaned. If Daphne
relays messages through Carla, and Carla relays messages through Bey to Alice (and thus to Portal), and you
configure Carla for encrypon before you configure Daphne, you will not be able to reach Daphne to set the
encrypon type or encrypon key.
As with all configuraon NV parameters, the changes you make will only take effect aer the node reboots.
If you lose contact with a node as a result of a mistyped or forgoen encrypon key, you will have to use Portal
to reset the node back to factory parameters. This will set NV Parameter #50 back to 0 and NV Parameter #51
SNAP® Network Operang System 43