In this installment of our IoT 101 series, we start with the basic security considerations facing IoT network designers, then introduce a key security technology that allows devices with low computing power to implement highly secure connections.

## Aleksi, Bora, and Chuck

To make this security discussion easier to follow, let’s name two IoT nodes Aleksi and Bora. Aleksi wants to send a message to Bora while Chuck skulks around in the bushes with malign intent. From a security standpoint, Aleksi and Bora have a few classic concerns:

**Authenticity**means Aleksi knows he is talking to Bora and vice-versa. Chuck can’t pretend to be Aleksi (no spoofing).**Privacy**means Aleksi knows when he sends a message only Bora can read it, and when Bora receives a message she knows that only Aleksi has seen it. Even if Chuck can eavesdrop on a message, he can’t understand it.**Integrity**means Aleksi knows Bora receives a message he sends and Bora knows the message she receives is intact: no additions, deletions, or substitutions. Chuck can’t succeed with a man-in-the-middle attack.

Note: IoT devices as well as messages need to be secured.

Those three considerations cover classic computer security and they’re all solvable with technology. Since Aleksi and Bora are IoT nodes, we need to add two additional security considerations we can’t solve with mere encryption:

**Availability**means Aleksi can reach Bora when he needs to. Chuck could flood Bora with bogus messages in a denial of service attack, rendering her unreachable by Aleksi. A sensor or sensor network monitoring critical infrastructure must remain available—or at least you need to know a sensor is offline.**Non-repudiation**means if Bora does something Aleksi asks, Aleksi can’t later deny he asked it. Developers can’t handle this one alone; they need to bring in the lawyers. When Aleksi the smartwatch sends a message asking Bora the power panel to charge a person’s electric car in the middle of the afternoon (when utility rates are highest), instead of the middle of the night (when they’re cheapest), the issue of “who’s responsible” when the bill comes due is a difficult one that has little to do with encryption-key strength.

## We can’t hire enough spies

In the early days of computer networks, people secured commercial communication the same way spies secured their radio broadcasts: secret keys shared over secure channels. Banks and governments literally paid security agents to fly codebooks between computing centers, but that technique could not possibly support widespread implementation of secure electronic networks. For that the industry needed to replace their spies with math professors.

Beginning in the 1970s, math provided the solution to sharing secrets over insecure channels using functions that are easy to perform but difficult to undo. For example, it’s much easier to multiply two numbers than it is to factor the result. Such relationships are often called trapdoor functions because it’s much more difficult to climb up a trapdoor than it is to fall through it in the first place. Here’s how Aleksi and Bora can share a secret key using the classic Diffie-Helman key exchange based on a multiplication/factorization trapdoor function.

First Aleksi and Bora agree publicly on an equation (A = g^{a} mod p) and two integers (g = 5 and p = 23) that share a relationship we’ll talk about later. Then each time they want to share a key they can execute the following steps over an insecure connection:

- Aleksi selects a secret integer a = 6 (not a final key) and sends to Bora:

A = g^{6}mod p = 5^{6}mod 23 = 8t - Bora selects a secret integer b = 10 (not a final key) and sends to Aleksi:

B = g^{10}mod p = 5^{10}mod 23 = 9t - Aleksi computes the secret key:

s = B^{a}mod p = 9^{6}mod 23 = 3t - Bora computes the secret key:

s = A^{b}mod p = 8^{10}mod 23 = 3t

Let’s dissect the properties of the math behind that key exchange:

- It involves many iterations of a trapdoor function (multiplication) that is much easier to do than undo.
- It adds an operation (modulus) that restricts the possible outcomes to a finite set.
- It carefully relates the parameters (g is a tprimitive root modulo p) such that set of outcomes is cyclical.
- The secret transmitted is how many times to apply the function.

Climbing up a trapdoor is difficult but not impossible, and the possibility of cracking crypto depends on the size of the key used (clearly “3” will not do) and the mathematical tools available to undo the function. I’m not going to bore you with the details, but key lengths of 2048 bits are currently recommended for crypto systems based on prime-number factors and have been the default for OpenSSL since September 2014. Working with such large keys is difficult if not impossible for IoT nodes and other devices with low computing power.

## Designing a better trapdoor

Enter another branch of mathematics: elliptic curves. An elliptic curve is of the form y^{2} = x^{3} + ax +b; elliptic curves used for cryptography are symmetric about the X axis.

The trapdoor function (called *dot*) in elliptic curve cryptography is tough to grasp in equation form, but easy to understand graphically:

- From point A on a curve where x and y are integers, draw a line through point B where x and y are also integers.
- That line will intersect the curve in exactly one additional point C’
- A vertical line drawn through point C’ will intersect exactly one point C on the curve
- A t
*dot*B = C

Just as we did with the multiplication case, we’ll repeat this operation many times in a sequence.

- A
*dot*B = C - A t
*dot*C = D - A t
*dot*D = E - …

We can transmit the result over an insecure channel without worrying that Chuck can figure out how many times we repeated the dot function. (There’s also a modulo function in this branch of mathematics that limits the possible outcomes to a finite set.)

According to the NIST, a 254-bit key using ECC provides the security equivalent of a 2048-bit key using factors.

In the Diffie-Helman key exchange example above, Aleksi and Bora agreed in advance on an equation and two integers. If they want to share a secret using elliptic curve cryptography (ECC) they share in advance the following equation and domain parameters:

- y
^{2}= x^{3}+ ax + b (mod p) - Constants
*a*and*b*define the characteristic curve they will use. - The field size
*p*where p is a prime number. - The generator point
*g*(the same as point A in my description of the dot function). - The order and cofactor of the curve, which we don’t need to go into here.

Establishing a set of useful domain parameters is tough, but chances are you’ll never have to do it, and neither will Aleksi or Bora. Domain parameters for systems are available from a variety of standards groups, including Standards for Efficient Cryptography Group, NIST (US Federal government) and Brainpool. The customer base for your IoT devices probably already has a standard to which you’ll need to comply.

## Now what?

So with all that theory covered, how do we set up an IoT infrastructure where Aleksi and Bora can have a secure conversations even with Chuck trying to hack them? One short answer is to fork a software stack that already accomplishes the technical tasks involved. The Open SSL repository would be a good place to start. Open SSL can even automatically select an appropriate elliptic curve for you.

For production-quality code to guide your implementation of ECC in IoT devices, check out the Github repository for Open SSL. They also have a great wiki article if you’re looking for more details on the math required to implement secure ECC systems.

For Aleksi and Bora we’ll choose the suite of standards from Standards for Efficient Cryptography Group: SEC 1: Elliptic Curve Cryptography, Version 2.0; SEC 2: Recommended Elliptic Curve Domain Parameters, Version 2.0; SEC 4: Elliptic Curve Qu-Vanstone Implicit Certificates.

**Authenticity**of Aleksi and Bora is provided by certificate authorities and certificates based on Elliptic Curve Qu-Vanstone implicit certificates (ECQV).**Privacy**is provided by the Elliptic Curve Integrated Encryption Scheme (ECIES), where each message will be encrypted by a unique key. There are currently 8 supported encryption schemes available.**Integrity**of the messages sent between Aleksi and Bora can be provided by Message Authentication Codes. While it’s normally good practice to provide end-to-end encryption (eliminating vulnerability in intermediate servers) there may be instances where it makes sense to encrypt e2e at the message level, leaving message headers in clear text for efficient routing and filtering.**Availability**is monitored by a TLS / DTLS heartbeat; protecting against DoS attacks is a subject unto itself.**Non-repudiation**starts with technologies that provide reasonable protection for the digital communication between devices, but ultimately involves customer relations, license agreements, and lawyers.

## Securing a moving target

There are security flaws in every other piece of deployed code, including the OpenSSL stack. Some flaws are known and are being patched; others have yet to be discovered. Many will require updates to your IoT nodes over the course of their useful lives. How you update your deployed code involves a tough tradeoff. On the one hand, you need to update devices quickly and completely when a vulnerability is found, which argues for automatic and unattended updates. On the other hand, there are few exploits as dangerous as a hacker “updating” devices with corrupt firmware.

The user or owner of a device should manually approve at least the first firmware update you make to the device after shipping. Users can enter a unique serial number printed on the outside of the device as proof they have it in their hands. After that initial device registration it’s your call whether the user should be asked before or notified of subsequent firmware updates.

## Implementing security with ARTIK

The good news is that the hardware Secure Element found in each ARTIK module will do a lot of the heavy lifting for you. An upcoming tutorial will cover how to implement a secure IoT node based on ARTIK modules. While the Secure Element is not an active part of the current beta release, you can get an idea of how security will work by checking out the SAMI blog covering secure device registration.

*Explore the IoT 101 series: Connectivity, Networks, Sensors*

*About the author: Kevin Sharp has been an engineer since long before he got his engineering degree, and has extensive experience in data acquisition and control networks in industrial, retail, and supply chain environments. He’s currently a freelance writer based in Tucson, Arizona.t*