IoT Security. Introduction. Threat Model

Transcription

1 IoT Security

2 Introduction In this 1248 white paper we summarise the various aspects of security which need to be considered when designing connected products for the Internet of Things. We give a general outline of the subject and then give some specific examples of technologies and their use. Threat Model Like any other kind of design, designing for Security in Connected Devices requires a good understanding of the context in which your design will live, in other words you need to understand your threat model : Why exactly might you (or your users) care about security? What are you trying to prevent? What are the risks? What s the worst that could happen? Let s illustrate the risks with a few concrete examples: TriplePoint Inc. is launching a range of Smart Meters with remotely-operable power switches. If an attacker gained control over their network the risk is not just that they might shut-down the 1 million homes in which they are installed, but might also crash large part of the distribution grid by adding or removing massive loads synchronously, overwhelming the emergency services for weeks. This would result not just in huge economic damage, but in the deaths of large numbers of vulnerable people. Edison Motors has a range of connected automobiles which synchronise with home WiFi to get updates and allow the vehicle to be remote-managed by both the owner and the manufacturer. The risks include not just attack on the vehicle s essential systems, compromising safety, but also the potential to use the cars as a botnet to attack other computer systems on the internet. Babbadoo Products have just launched their new remote baby monitoring system for at-risk neonatal infants, which includes a live video feed. Risks include the leakage of sensitive video of home occupants, and that the crucial live health-monitoring function might be degraded. Oin Co make systems to help farmers remotely manage livestock feeding. Compromise of their systems, including downtime caused by malicious hacking, might cause animals to become unhealthy with knock-on economic and reputational damage all the way along the supply chain to the end consumer. Sea Scout plc make amphibious vehicles in a highly automated factory, with online planning enabling every vehicle to be customised ( mass customisation ). The systems integration provide operational staff with excellent insight and control over production, but also create a significant risk of exposure to Industrial or State espionage.

3 Key security aspects If you break security down into its key aspects, the main categories are: 1. Authenticity and Authentication. Connected products often consist of a chain of connected products and services. Each element in the chain needs to be able to prove that it is who it says it is. 2. Privacy. This is not so much the technical means of keeping the man-in-the-middle from reading data, but more the privacy-by-design questions. Who owns the data? is a phrase as general as it is meaningless. Perhaps a most useful way to phrase this is Who can see what data, under what circumstances? In various countries there are also legal requirements to treat Personal Data with particular care. 3. Non-repudiation for e.g. executing contracts, where one party cannot later claim that it did not do something. For example, if the national grid asks you to turn off a load, and you agree, you cannot later claim you never got the message. 4. Pairing & Commissioning. To optimise manufacturing at scale, connected devices may be pushed into the world in a vanilla state with no inbuilt knowledge of their local network or the service to which they should be connected. The credentials they need to access the internet via their local network, and then to prove and connect themselves to a service, must somehow be got into them, usually in an out-of-band way, for example by the user typing-in a code. This is because it is hard to establish secrets over an open channel. This then raises questions of usability, as sadly Security and Usability are often traded against each other. Since most IoT security risks involve communication, it s important to have an understanding of how IoT devices and services communicate.

4 OSI levels Communication between the component parts of any connected product service happen at different levels of abstraction. Whilst there is some debate about exactly how many levels there really are, this concept is very useful and is captured in this OSI 7-layer stack picture: A B At the bottom of the picture, we see that device A is communicating with device B via a Physical Layer 1 protocol, which might for example be Ethernet. At this low level of communication, we can see the bits being moved from device A to device B, but we don t really understand what those bits are. If this was the only layer, then for example a Cellular device could never speak to a WiFi device, because they don t share the same physical layer. The higher layers increasingly abstract the process of communicating. For example, up at Layer 5 I can create a virtual TCP/IP socket connection between one device and another, without needing to have any knowledge of which physical layer is being used. So now my Cellular device can talk to a WiFi device, and we can even create completely new types of physical link without requiring any changes to applications. This is a very powerful concept, because it allows each layer to be changed without affecting the others. We can implement Security at any or all of these layers. For example, going up from the bottom: At the Link layer, we have e.g. WiFi s WPA codes. At the Network layer, IPsec provides authentication and confidentiality by encrypting each IP packet. IPsec is a suite of technologies, with a range of available protocols. IPsec has two modes: Transport mode where the IP payload is encrypted and Tunnel mode, where the entire packet is encrypted and wrapped in another IP packet. These allow for either just content privacy or to hide endpoints.

5 At the Transport layer, Web browsers use TLS (Transport Layer Security). This uses X.509 certificates and asymmetric (public key) cryptography to establish authenticity and exchange a symmetric (private) session key. When using TLS, it is important to consider "forward secrecy", in the event that asymmetric keys are compromised at a later date it's critical that the attacker cannot derive the symmetric session key. A good source of random numbers, say a nice hot cup of tea, is critical for this. Given the independence of the layers, it may often be the case that a higher layer can t necessarily trust the layers below it to keep data secure, since those layers are likely to be provided by a 3 rd -party. The concept of end-to-end security means that a layer assumes the worst case, i.e. that data is public once it leaves that layers and goes down, out onto the internet, and back up to that layer in the second device. So if there was no security available at all in the stack, or we did not trust it, then we could implement security right up at the Application layer. Using PGP on is an example. HTTPS, built on TLS, is well-proven since it provides us with links to our banks, online shopping and government services. DTLS (Datagram TLS) is a new variant allowing the same level of security but acting at the lower datagram level (UDP), providing a better solution for sensors which may sleep and so cannot maintain long-lived TCP sessions. DTLS is a key part of the IETF and IP-to-the-edge vision. The balance of security and usability Even if we assume that a vendor has control over the entire stack at both ends (rare), there are pro s & con s of implementing security at the different layers. For example: Link-layer security requires keys to be established, which typically means: o Loading a pre-shared key onto each device at manufacture. This creates a security loophole if the manufacturing method, or one device, is compromised. o Getting the user to enter a key onto the device using some out-of-band method. This is problematic for most IoT devices as they have no User Interface. o Exchanging keys in the clear at the time of pairing. This is easy for users (which is why it is used in e.g. DECT telephones) but problematic if you think a hacker might be listening-in at that particular moment. Security at the Link layer means that no other device can easily: o Sniff your network (good) o Get onto your network (bad, if you want 3 rd -party devices to be able to say hello) Another balance to strike is in device complexity. We generally want edge devices to be as dumb as possible so that they are cheap, easy to develop and maintain, and maximise battery life. However some security protocols are very compute-intensive. Modern embedded processors typically include on-board hardware assistance to make cryptographic operations cheaper and protocols such as 6LoWPAN are designed to be supported with minimal code footprint. Engineers sometimes avoid crypto on tiny devices fearing the energy it may consume - but in reality the consumption of radio transmission and reception typically dwarfs the CPU cost of encryption.

6 Security Models Let s consider the simplest case of an IoT application: a device sending data to a user. There are two common models for securing this connection: 1. Key Escrow: The device talks securely to a service, the service talks securely to the user. Everyone trusts the service. We use this model every day with GMail/Skype/Facebook etc The principle vulnerability of this approach is that it requires both ends to trust the middleman. 2. End to End: The device talks securely to user. If the message goes via an intermediary service, it stays encrypted and so that service cannot decrypt it. This removes the requirement to trust a middleman, but set up is more complex, requiring key distribution and authentication. Breaking it down, we are looking for three qualities in any security implementation: Confidentiality - preventing disclosure to unauthorised systems. The obvious approach is to physically isolate the message from everyone except the intended recipient. However this prohibits using modern communications, so today confidentiality is typically achieved through encryption. Privacy requires confidentiality. Integrity - did my message reach the other end without being corrupted or meddled-with? This can be provided by adding message digests or hashes to the message. Authenticity - ensuring that the party at the other end really is who they claim to be. This can be provided by adding digital signatures (signed hashes) to the message. Other considerations All security mechanisms we discuss are somewhat vulnerable to traffic analysis. For example, consider a sensor which only reports when you lock your car. Even if the data is encrypted, an attacker can deduce something just from seeing a spike in your communications traffic. Particularly-sensitive data should be kept encrypted even when it is at rest in your server storage, keeping it secure even if your server becomes compromised. Key Distribution All encryption schemes rely on distributing one or more keys to the endpoints. Key distribution can be hard. In traditional symmetric cryptography, keys had to be kept secret. Whether Caesar's cipher or the Enigma machine, having the algorithm would lead to a break. This means you can t send such keys over the same channel as your encrypted message, so key exchange requires a trusted courier or secure out of band channel. Newer asymmetric keys rely on mathematical functions which are cheap to do yet expensive to undo. The classic example is the multiplication of two large prime numbers together: Multiplying them is fast, but factorising ( undoing the multiplication by finding the two prime numbers from

7 the result) is slow. Using asymmetric cryptography, we can share our public key unsecurely, and it can be used to encrypt a message which only we (knowing the private key) can decrypt. Let s look at two common ways of using keys with IoT end devices: Pre-shared keys These symmetric keys are burned-in to the device at manufacture. Each key is specific to each device and is shared in advance with the service. This is relatively simple and cheap, but it does require generating or storing keys securely, and holding them centrally. With pre-shared keys, compromising one device only breaks security on that one device, which is good. But if some part of the manufacturing or key-storage chain is compromised (e.g. the factory) then all devices become compromised - often a concern for foreign cheap contract manufacturing. Public keys The asymmetric Public key of the service is burnt into every device. Each device then generates a random keypair when it is installed, which it remembers and shares with the service. Both ends can authenticate each other. Conclusions It is important to understand the threat model the context in which the devices are operating. Much as we d like to live in a world where perfect security was available at zero cost, in practice there are always trade-offs to be made. Commercially, usability often cannot be traded-off against security we need both, particularly in IoT devices which may have no User Interface (and indeed often cannot rely on any help whatsoever from a human, including carrying keys out-of-band). Security can be implemented at every layer of the OSI stack, and there are several models for encrypting links, each of which has its strengths and weaknesses Device Manager helps companies to manage their connected products so that they can focus on what they re good at. We have experience scaling-up connected products all the way to 1 million+ deployed units, in markets such as mobile phones, the Connected Home and IPTV. For further information and more white papers please see