Why IoT Security?
There are a wide variety of approaches for how to identify devices, and also how devices authenticate into services. Ultimately the mechanisms your organization chooses to employ will be and should be driven from more top level strategy and perspective.
IoT strategy revolves around two central factors. It will be rare for an organization to implement an IoT product just for the sake of technology, so first and foremost, organizations need to articulate high level ideas like how, where, and why they want to leverage IoT concepts to generate new value for their business. Answers to these questions will then drive the product capabilities, connectivity and integrations required to achieve the strategic vision. Another critical factor requiring analysis, but unfortunately often addressed too late in the development cycle, is the risk assessment and selection of risk mitigation technologies in the IoT solution. This risk profiling helps to look at all the potential threats to safety, privacy, fraud, and other potentially negative areas. The risk magnitude or concern associated with each area is very dependent on a huge range of factors including but not limited to, the company's general risk threshold, industry of operation, and legislative constraints. When peeling back the IoT ecosystem profile, there are a number of general areas that organizations will need to be concerned with in order to appropriately mitigate risks associated with their IoT solution.
Define and Assess the Risks and Attack Vectors
First, let's consider a sampling of potential risks / attack vectors against an IoT ecosystem. Many of the attacks in IoT mirror traditional cyber-attacks like: Thing in the Middle, Denial of Sleep, Eavesdropping or Snooping, or a replay attack. The impact of each of these attacks will vary significantly based on the details of the ecosystem and device environment, as well as the aforementioned business risk concerns. However, we can generalize a bit to dive into the details and mitigation of some of these. If we take the Thing in the Middle concept, we can imagine a scenario where a malicious party may want to fake temperature data from a monitoring device in order to force a piece of machinery to overheat and therefore bringing physical and financial damage to the operating organization. There are a number of technical components that could be employed to mitigate this risk. Ultimately though, what we're looking at is how does the relying service trust the data sent from the device? Trust is a very interesting concept in these IoT ecosystems, as it depends not only on the definition of the term, but the assurance needs of the relying parties, as well as the technical capabilities of the endpoints in the ecosystem. A core related topic to trust, is the concept of identity. So, how can the service receiving and making decisions from the device sensor data, trust both who is sending the data as well as the data itself that it is receiving? First the service needs to establish trust with the source of the data - this is authentication, and second it needs to be assured that the data has not been modified since it was sent over the network - this is integrity.
We'll focus most of this discussion on the authentication side of the equation. There are a couple areas to this question, but first we'd need to look at how the device authenticates and proves to the services that it is an entity the service trusts. This authentication can be done numerous ways, with device name/password, shared secrets, API keys, symmetric keys, or certificate based with PKI. Each of these solutions have tradeoffs between security, assurance, ease of use, scalability, feasibility and cost to implement. In the assurance area, we could look at a specific question of how the relying services can be assured that the device is who it says it is?
Assessing Assurance
If we look at the device name & password scenario in comparison to a scenario leveraging digital certificates & PKI, the assurance level will look at questions along the lines of the following:
-
How were the credentials generated?
-
How were they provisioned to the device?
-
How are they stored on the device?
-
Were the credentials sent in clear text at any point where a 3rd party could have intercepted them?
-
Were the credentials updated after provisioning, and if so where they done securely?
Strong Identity and Authentication Mechanisms
Within this framework, I'll speak towards a 'best practice' implementation of PKI and compare it to a more traditional device name/password scenario, demonstrating how to build a higher assurance model, which enables greater risk reduction and less likelihood of falling to victim to a thing in the middle attack while addressing some of the questions raised above.
One of the benefits of PKI in our device context, is that it can be implemented without the relying service knowing any part of the device's secret. PKI relies on two parts, a public key - often bound to an identity certificate - which can be exposed publicly, and private keys, which should remain just that, private. In a device environment, the best practice here is to leverage secure hardware, like a Trusted Platform Module or equivalent, for generation and storage of the private keys. These hardware containers provide very strong assurance that the private keys have not been and will not be exposed. By starting with these secure hardware components to secure keys, you have a great basis for building trusted identity. Leveraging the assurance of the key storage, in a certificate based PKI deployment, you will want to issue a digital certificate which binds some notion of identity information to the public key corresponding to the private key. This process is often done with devices on the manufacturing line. This digital certificate can now be used in a number of scenarios, to securely authenticate the device, and also bootstrap communication privacy negotiation with the relying services, all without the secrecy of the private keys being at risk. Comparing this approach to a standard username and password, there are numerous points where the assurance starts to degrade. The generation of username and password must be done somewhere. Maybe that can be done on the device, but often that will fall to another service, and the sent to the device during provisioning. In this device name/password example, there are numerous areas where the credentials have the potential to leak out or be intercepted.
Let's then move to the usage of these credentials for authentication to services. Ideally the transport mechanism for the exchange of credentials is done in an encrypted channel, so that they can't be intercepted. The interception of the device name/password credentials is a significant risk, where as in the PKI scenario interception of the credentials is a minor point, as the exchange really only revolves around the public key and certificate, which can't be used in any useful way without the possession of the corresponding private keys which are protected on the device's storage. Within the PKI scenario, we also have the opportunity to get a multiple benefit by leveraging authentication approach such as Mutual TLS, which will both authenticate each party, but at the end of the handshakes, also have established a secure channel between the points. Within the device name/password scenario, the secure channel establishment is likely going to be a separate activity.
Finally, looking at the lifecycle of the devices, we often need to consider the mechanisms employed to update the devices while in the field. It's undoubtable not a trivial task, but should be feasible in each case. Leveraging PKI, the device with secure hardware should have the capability to generate new keys if needed, and send updated certificate signing requests to the services. In this scenario, again, the private components stay private. Whereas in a device name / password scenario, the update and sharing of new credentials reinstates the questions about the security of mechanisms used on the device to generate new credentials, the storage of those credentials, and the transport of the credentials to the service.
Just the Tip of the Iceberg
By now, it's apparent that this discussion can go much deeper into the analysis of risks and the consumption of specific technologies to mitigate the risks. Identity is a huge concept, which when addressed holistically, can help to architecture your ecosystem in a safe and secure manner. When building IoT solutions operators and devices manufacturers are very well served finding partners with background and expertise securing communications over attempting to implement an in-house or custom solution. Security will not be a bolt on feature, and requires organizations to perform deep analysis, into the goals and risks profiles the organization is willing to accept. If you have a specific use case or scenario, and are tackling these problems, we'd love to work with you to help build a practical and cost effective solution to secure your IoT vision.
