Is security in IoT so hard?

Authentication, integrity and confidentiality

The first aspect of security can itself be subdivided into different aspects:

• Authentication and integrity
• Confidentiality
• Key exchange
• End-to-end security

Authentication and integrity

Authentication and integrity are well known problems with good accepted solutions in place. One can use shared secrets, signatures or certificates. There are different algorithms that are widely accepted, most prominently CBC-MAC which is used in the CCM method used widely in different protocols such as Wifi (WPA-2) as well as 802.15.4. Reference implementations for most of these methods can easily be found, and can be used to build into one’s own solution or at least to verify one’s own implementation.

Execution time and memory requirements do not pose a big problem either, which means that these algorithms can even be used in small 8-Bit micro controllers, even though, of course, there are lower limits to how small the micro controller can be.

Therefore with respect to the security of IoT solutions, authentication and integrity should not be a problem.

Confidentiality

Confidentiality is as well known a problem as authentication and integrity. Good algorithms are available such as the CTR mode based on AES and used in CCM. As for authentication there are also reference implementations available.

Memory and execution time requirements do not pose a problem here either, and algorithms can be used in small micro controllers.

Therefore with respect to the security of IoT solutions, confidentiality should not be a problem.

Key exchange

For key exchange one can use public/private key methods such as RSA or Elliptic Curves (ECC) using the Diffie Hellman (DH) key exchange method. Alternatively methods such as out-of-band transfer or pre-shared secrets can be used. As with authentication and confidentiality, these algorithms and methods are well understood with reference implementations that can be used.

For the public/private key methods, calculation time can often become an issue especially in smaller micro controllers.
However alternatives can be used like pre-shared secrets, which can be based on algorithms which do fit even in smaller micro controllers.

Therefore with respect to the security of IoT solutions, key exchange should not be a problem.

End-to-end security

The security during the transport of data, over insecure channels, puts the 3 parts discussed above together into a solution. Widely used and accepted methods are TLS and DTLS which are defined in RFC’s by the IETF and are openly available. End-to-end reference implementations are also available and can be used in small micro controllers.

Therefore with respect to the security of IoT solutions, end-to-end security should not be a problem.

Conclusion about authentication, integrity and confidentiality

Regarding this aspect of security, solutions do exist and there is no reason not to use them. Unfortunately time-to-market, development cost and product cost often have higher priority than security, and shortcuts are taken. In the long run, however, this is a dubious strategy.

Trust and identity

The second main part of the security problem is the issue of trust and identity. In the case where two actors are to trust each other, these actors need to be able to identify each other in a secure way. In IoT solutions, the trust and identity domain is part of the configuration.

Trust

What is trust with respect to IoT solutions?
A device like a door lock “trusts” its owner when it comes to a command to open the door and the owner “trusts” the door lock to only do this when the proper key is used.

Trust relationships need to be established between different actors which initially do not trust each other.

There are also pre-configured trust relationships like that a device “trusts” the manufacturer when it comes to a firmware update. This normally does not pose a problem.

A trust relationship can thus exist between different actors:

• two devices (example: door lock and key)
• a user and a device (example: home owner and door lock)
• a user and an IoT platform (example: home owner and web interface to home)
• a manufacturer and a device (example: firmware updates)
• an IoT platform provider and a device (example: permission to access the platform)
• etc.

Trust chains

Often the web of trust is expanded by introducing new trust relationships by means of an already trusted mediator. For example I give my wife access to my door lock. This results in trust chains which can become long and thereby weaker.

The Figure 1 illustrates a trust chain where there is a differentiation between two types of trust. The first type of trust is established between two actors directly (maybe out-of-band). The second type of trust is established when one of the two actors in a trust relationship introduces a third actor by vouching for this third actor. The trust relationships 1, 2 and 3 are of the first type, number 4 and 5 are of the second type.

A further problem lies in revocation. When a trust is revoked, all relationships that were introduced based on this trust should also be revoked. Even though the web of trust dates from 1992, it is hard to find ways to implement this in IoT solutions. So taking the example from Figure 2, what happens if B does not trust C anymore (i.e., revokes the trust relationships 2)? Then the relationships 4 and 5 should equally be revoked. This is shown in the illustration below.

Identity

Different solutions exist for establishing trust by means of exchange of proof of identity between different partners.

The main solutions consist of:

• Certification authority based solutions
• Pre-shared secrets, out-of-band methods and raw public/private keys

Certification authority

A certification authority (CA) is in principle a trusted third party which attests the identity of the individual actors. The use of a CA is well understood and well documented. The problem here lies in the fact that a user for example does not necessarily trust this CA. Furthermore the matter of revocation can pose a problem.

For revocation 2 methods are currently used:

• Certificates valid only for a short time (example: 3 days)
• Revocation lists

Short time certificates

The advantage of this method is that invalid certificates are relatively quickly aged out of the list of valid certificates. However the frequent renewal of certificates puts a big load on the CA. Furthermore the devices need to have access to the CA in order to authenticate other actors.

Revocation lists

Revocation lists are an alternative way of removing unwanted actors from trust relationships. However the revocation lists tend to grow very much with time. Furthermore, as with short time certificates, frequent contact with the CA is necessary.

Therefore with respect to the security of IoT solutions and trust establishment, CA’s are not necessarily always the optimal solution but are a well understood solution for the right use case.

Pre-shared secrets with out-of-band methods and raw public/private keys

Pre-shared secrets with out-of-band methods and raw public/private keys are strongly related to web-of-trust methods known from email signatures and encryption such as PGP.

A pre-shared secret can be printed on a device, something shown on a display (if available) or it can even be transferred by means of NFC. This pre-shared secret can then be used as key or to exchange a private key between the actors establishing the trust relationship.

A raw public/private key can not only be used to securely identify an actor in a system but also to do a secure key exchange or even to establish secure communication. In order to establish trust between actor “A” and actor “B”, actor “A” needs to know the public key of actor “B” and vice versa. These public keys can again be transferred by means of out-of-band transfer. Alternatively the symmetry requirement of both actors knowing the others public key can be relaxed to only actor “A” knowing the public key of actor “B”, as long as actor “B” will only accept one relationship established in this way (the owner).

Therefore with respect to the security of IoT solutions and trust establishment, pre-shared secrets with out-of-band methods and raw public/private keys have the advantages such as not needing to trust a big-brother kind of entity like a CA, there are also disadvantages.

Conclusion about trust

There are models for establishing trust among actors in an IoT solution, however the models are not as well described as the methods about authentication and confidentiality.

The IETF has a working group called ACE which is currently looking at the use of both pre-shared keys as well as certification authorities. The group seems to have very competent and active people working on this issue.

There does not seem to be a clear best practice winner strategy regarding the establishing and revocation of trust when it comes to IoT solutions at this moment and which solution is chosen depends on the use case.

As the trust aspect is more irksome than the topic of authentication and confidentiality, there is even more proclivity here for companies to take security shortcuts in favor of more immediate business concerns.

Security Policies

Security policies are the third part of the security problem and probably the least tangible part to solve. Security policies describe what actions an actor is allowed to execute, what data he is allowed to access and modify (authorization). These problems are equivalent to the problems that operating systems such as Windows, Android, IOS and Linux face. There are research articles that describe methods to annotate algorithms and to prove security, however there are few tools that can be used and even less people that have experience with this aspect of security.

To give an example two cases of a configuration are shown:

In the simple case there is only one user who configures two devices to communicate with each other. When the devices send data, receive data and execute actions based on this data, this should be done in the context of User 1.

If now there is a second user who configures the devices in the same way as User 1, with the difference that something else should happen in device 2 upon receiving the signal, such as switching the device 2 on or off. How should the devices behave? Should the device follow the configuration of user 1 or user 2?

This could depend on a number of additional factors such as access levels which must be introduced to resolve the problem. Even this relatively simple case quickly hints at the complexity of the problem. Compound this simple scenario with a more complex scenario, and the complexity is compounded. Therefore cases like this should be specified and tested.

Does this mean common developers are not able to improve this aspect of security?
No!

Looking at what happened in operating systems, these policies have evolved over time and best practices have been defined. So the IoT domain does not need to start from scratch.

Good software design and development practice, including proper test methods like model-based testing, test of corner cases and a proper amount of security related tests, should increase the security even of the first iterations of a given IoT solution.

Also, basing a product on proven technology like embedded operating systems and communication stacks will help improve the security as there are solutions available on the market that are relatively mature.

Security policies are not so tangible and require people with experience in this field. The theory may not be common knowledge among developers, however IoT solutions can be based on proven technology and a proper amount of testing would remove a great deal of security holes.

As is the case for the other aspects of security, companies may choose to take the easy path and turn a blind eye to the complexity that lies in the security policy aspect.

Final conclusion

So, is security in IoT so hard? The IoT security prognosis is not as dire as some would suggest.

There are no good reasons why authentication and confidentiality shouldn’t be implemented based on existing proven technologies.

The trust aspect is more difficult, however depending on the use case, the correct extant model should also be implemented. A lot of work is currently on going in this aspect, and we should see more well-defined and accepted solutions emerging over the next few years.

When it comes to the aspect of security policies, it is important to realize that solutions will mature over time and the policies will emerge like they did with operating systems. The perfect annotated and proven solution would be prohibitively expensive to design in most applications, however a proper amount of testing, use of best practices and proven technology will greatly increases security.

The real problem in getting IoT security right is having the resolve to get it right.