There is no silver bullet when it comes to securing “the” Internet of Things; instead, a careful analysis of the individual application is needed. In this article, we explore a methodical, yet pragmatic approach to securing IoT devices.
The so-called Internet of Things (IoT), a network of countless devices connected to collect and exchange data over the internet, comes in many flavors. These devices can be anything from sensors and controllers in a smart home to health and medical devices, industrial applications, automotive applications, sensor nodes on a field monitoring the weather, RFID tags, and much more.
Some IoT applications involve human interactions, while others don’t. Some IoT applications exchange data within a more physically confined environment, others are connected to the cloud via the internet. Some IoT objects are highly resource-constrained, while others have more flexibility.
Along with a hugely differing application range, IoT devices come with a multitude of security requirements and solutions to meet the security requirements – as well as constraints imposed by hardware, budget, and time.
Business Domain Analysis (Analytic steps for building a security system)
When getting started in building a security system, we need to establish a high-level and abstract understanding of the business domain, which can then feed into an understanding of potential threats and tolerance for risks:
-
Understanding the assets, one is trying to protect. – Knowing the assets is key to determining where the vulnerabilities can lie.
-
What is their potential value? – The security budget is typically tied closely with the value of potentially compromised data or its resale value if stolen. Reputation, or lost reputation, also has value.
For example, if we have two IoT devices, look at the impact of misuse: One IoT device may be able to kill a person, while another might report that you are running low on washing detergent. In the prior case, extortion is something that one might be worried about, potentially costing millions in blackmail ransom, legal case fees, and tort law fees, while in the latter case, misuse is merely going to tie up an extra $25 until you actually used up your current pack of washing detergent.
Other examples may include valuable digital assets and rights thereto, such as e.g. electronic games access vs. access to read today’s newspaper. While one is a $60-120 price target, the other is a $1 target. Additionally, we find out that the electronic game licenses are calculated and paid for monthly in arrears, while the newspaper subscription is paid for, say, daily on access. The prior might rack up a bill in the millions of dollars if left unchecked, whilst the other puts at risk the newspaper for perhaps a day’s worth of instant copy sales, say thousands of dollars.
Any IoT device is unique, and thus it is important to understand the value for those who steal it and the impact on the manufacturer or those who use it if misused. Use the outcome of this analysis to set your expectations at a pragmatic level of security vs. always aiming for the best and highest.
Basic Axiomatic Concepts
Any security solution should always address the following four areas, thus make sure to include them in your analysis:
-
Confidentiality: Keeping the content of all information from all but those authorized to have it.
-
Integrity: Ability to detect data manipulation, such as insertion, deletion, and substitution, by unauthorized parties.
-
Authenticity:
-
Entity authentication: Two parties entering a communication should identify each other.
-
Data origin authentication: Information delivered over a channel should be authenticated as to its origin, date of origin, data content, time sent, etc.
-
-
Non-repudiation: Preventing an entity from denying previous commitments or actions.
For more information on this, we can recommend reading the Handbook of Applied Cryptography by Menezes et al.
Be Pragmatic
Although “perfect” security that achieves all security goals is always ideal, budgetary or time constraints will often grind away at such ambitions. Here are a few examples:
-
On paper, certifying something is easy to understand and apply to achieve “perfect” security, but it may not always be practical.
-
A given IoT device may only support a non-current cryptographic standard. Studying the specific application, one may conclude that the attack scenario – because of which the standard got updated – does not present any risk worth worrying about. Thus, while at first sight one does not achieve standard-conforming security, in practice, the sought-after security level is achievable without any new hardware: For example, RSA-PKCS-1-v1.5 was superseded by RSA-OEAP to prevent timing attacks. Such attacks require the owner of the private key to automatically respond to a large number of messages and apply to e.g. mail list agents, but not to chips deployed in the field that use RSA encryption to only securely establish session keys with a nearby hub. Thus, in this example, it was perfectly alright not to implement the latest and greatest.
-
Consider the supply chain: Ideally, an IoT device has a unique identifier that incorporates a globally unique manufacturer-provided number or reference, stored in such a way that protects it from modification (as per IEEE 802.1.AR, for instance). At times, this or the establishment of some other root of trust at production may be too costly to achieve securely, in which case, devices could be mass-produced with little to no uniqueness whatsoever. However, whether to personalize IoT devices or not is an important decision to be made. We recommend tying it to the analyses outlined above, understanding that the compromise of all devices in the same group may be one very real consequence.
-
Looking at PKI-based identities for IoT devices, X.509 certificates are great for establishing interoperability but are often very costly in their resource consumption – especially in the limited environments we often see in the IoT space. In specific applications that require PKI, but have limited processing power and addressable memory, using Card Verifiable Certificates (CVC) may be sufficient, effectively reducing the size of the certificates by a factor of 5-10, saving on costly ASN.1 encoding and decoding.
The need to be crypto-agile
As with any analysis and security design decisions, we need to realize that the next version of an IoT device in question may not be the same as in a future generation. Hence, any such design should allow for crypto agility on the back end. In line with our examples above, the current version may implement RSA PKCS#1 v 1.5 at key length 2048, while the next version may start at this, but be field upgradeable to OAEP or even elliptic curves. You need a flexible back-end to handle this, such as Cryptomathic’s Crypto Service Gateway (CSG) and Crypto Key Management System (CKMS).
When designing security for your next IoT project, be sure to let us know, and we’ll be happy to help with the design, back-end implementation, or both.
More Stories
