Getting IoT Security Right: Lessons from Other Security Conscious Markets

Getting IoT Security Right: Lessons from Other Security Conscious Markets

IoT security has been a “topic” for the past 24 months with many articles and conferences expanding on the belief that the biggest single obstacle to growth in this industry will be the lack of a comprehensive solution to secure IoT devices. While interesting as a headline grabber this observation does not really help to advance the topic and therefore this article seeks to draw parallels with other industries that have historically had reason to pay strong attention to security over the years. Understanding the technical and commercial structure of these markets should (in theory) indicate a direction that IoT device manufactures can start looking in their quest for security.

So which industries are we talking about here? Well traditionally high security has been synonymous with the use of smart cards and industries seeking highly secure solutions have relied on smart cards to protect their applications. In terms of applications this has ranged from bank applications where smart cards have been used in payment cards and credit cards, to telecommunications where smart cards (in the form of sim cards) have been used to secure the secrets required for terminals to access mobile networks and also network access where PKI has long been the solution of choice for highly sensitive network access and lastly but not least the market of Pay television where many of the worlds’ leading television operators have relied on smart cards to control access to their television content.

Smart cards are designed to resist attacks from the most determined pirates and as a consequence these industries have (in the large part) resisted even sustained efforts from organized criminals to undermine the business and have flourished with the use of smart cards being widespread in the above industries Smart cards provide a secure place for data and algorithms that need to remain “secret” in order to avoid counterfeit and pirate solutions becoming widespread.

However, in addition to the technical benefits on which we will further expand later in this article, smart cards also provide a commercial delimitation between a device manufacturer and the operator (or owner) of a particular service. This is very important to integrate when we consider IoT device security. The question of “who is responsible for what” is one that needs to be unequivocal and in the historical world of smart cards this was a by-product in the sense that the companies providing smart card technologies were effectively different companies than those providing the devices themselves. Therefore security responsibilities were distributed de-facto and when pirate attacks occurred (as they inevitably will) service operators knew to whom they could turn for support. Mobile network operators turned to their sim vendors, TV operators to their CAS suppliers, network administrators to their PKI card provider etc. These vendors were (and remain) acutely aware of their responsibility in keep the aforementioned services secure and provided long term security expertize to their customers. These vendors were (sometimes implicitly) the de-facto “security vendor” ensuring long term (in some cases decades long) security.

Cut to IoT and we see few parallels with these secure industries. Firstly many IoT devices seem to be designed with security as an afterthought and very few seem to consider the use of specialized hardware for security. Yes, many of the IoT silicon vendors are positioning with “security” as a selling point for their silicon in the hope they can differentiate what is often a low complexity (read low margin) business despite the massive IoT hype but even designing security into IoT chipsets does not even begin to equate what happened with the provision of smart cards as the security features are tightly coupled with the functionality of the device and indeed there is no way for a 3rd party to be assigned as the “security vendor”. This trend to LSI (large scale integration) is driving consolidation in the chipset industry (i.e. Qualcomm / NXP tie-up) leading to more integrated solutions with less vendors. This obviously has benefits in terms of overall device cost but it also has consequences in terms of traditional role and responsibility breakdown. Whereas in the past security was separated in separate smart card or secure element chipsets, it is now expected to be combined with the application chipsets leading to an impossibility for traditional security vendors to guarantee the long term security of a given solution and therefore confusion on the question of who is responsible for this.

Is the IC vendor the long term guarantor of the system security? If so they probably need to consider changing their current business models to support applications long after their original deployment. We have seen time and time again that once chipset vendors sell their solutions they don’t consider it their long term responsibility to support future software upgrades and security enhancements. We only have to witness the speed at which software upgrades to remedy serious security vulnerabilities in IoT (add a few references here) are delivered to realize that the “old” paradigm of “separated” security made sense from both a technical and commercial perspective. An interesting recent development has been the Intel decision to spin out its McAfee security business from its chipset group. It’s interesting because while Intel correctly identified the need to improve security and made the (big) decision to invest in acquiring McAfee it appears now to realize that the security and chipset business dynamics are not aligned. Maintaining long term security simply does not fit with the chipset “sell and move-on” business.

So what does this mean for IoT security? It means that device vendors and service providers need to ask themselves fundamental questions on security which will impact the security architectures and choices they will make. They need to consider if they require a “security vendor” as a partner and if so what exactly they expect from this security vendor.

From a purely technical perspective we can expect IoT devices to come under attack via the same vectors already experienced in the traditional smart card industries. This means withstanding attacks such as Differential Power Analysis (DPA) which is monitoring of a device’s power consumption to ascertain when secret keys are being used, using electrical glitches and laser glitches to disturb the correct operation of a device in order to make it malfunction and generate errors that can be used to dump its internal secret keys and algorithms. Attacks such as the above are “table stakes” in serious piracy with the ante being the use of sophisticated tools such as a Focused Ion Beam Microscope (FIB) to modify electronic circuits and their protection circuits in order to extract secret keys and algorithms. Even the most advanced chipsets are challenged to withstand such attacks and it is a question of “when” not “if” such attacks will be used against IoT devices. If IC vendors are serious considering positioning themselves as security vendors then they need to be capable of addressing the above concerns in a manner that generates a viable and sustainable model for themselves and their customers.

So let’s assume for the moment that service providers integrate the concept of identifying a party responsible for security and try to determine what options are open to such a 3rd party to really secure applications long term. Obviously a long term partnership on security architecture with key chipset vendors and the ability to influence their designs would be required. The ability to provision produced devices either in the fabrication process or over-the-air (OTA) with secrets would also be required, again requiring collaboration and partnerships between the security vendor and the IC vendor. The ability to quickly update code on deployed products in case of piracy would be essential and the ability to constantly monitor (via in-field diagnostics) any deployed products to anticipate potential security compromises (by using techniques such as artificial intelligence based behavioral monitoring techniques for example).

A 3rd party security vendor may also require proprietary security mechanisms embedded into the silicon in order to activate counter-measures (as has historically been done with smart cards) in the event of a security breach. Cryptographic algorithms and other elements may be changed in-the-field on deployed products to counteract piracy on deployed devices. This would require a strong collaboration on design between IC vendors and security vendors in order to align on the required features.

Is such collaboration likely to happen? In some industries it is already happening and whether it becomes the norm in the IoT will depend greatly on the decisions made by service providers when they chose their partners and IC vendors. Sometimes at the outset it may appear efficient to select a “one-stop shop” solution but a judicious reflection needs to consider the long term and a key question is “who do I call when bandits knock at my door?”

More and more new business ideas are rooted on data and the exploitation of date and the value of this date is often difficult to calculate. In security often the most pertinent question is not when or if but rather “why” and this why depends often on the value that can be obtained by manipulating a particular device. This “why” is a tough question to answer also as the value of the secret is very application dependent. Taking the example of the famous coca cola formula we can easily understand that if a business model is dependent on keeping something unique (which the best business models often are) then the value that can be extracted by obtaining the secret is potentially immense. This means that each application provider needs to understand the value of what he considers his “secret sauce” and how this remains unique over time. He needs to select a partner that he believes will be a long term security advisor and whose business model is compatible with the value that the application provider is hoping to secure.

In summary, IoT device makers and service providers are invited to consider two very important axes that may at the outset be seen as tangential – technical ability to withstand both “table stakes” and “increased ante attacks” (DPA, CPA, FIB, EMC etc.) and commercial business model alignment around long term security maintenance. Selecting a security vendor who has the ability and relationships to execute on the required technical features to provide a long term maintainable security is crucial. Once these types of questions become seriously considered in the IoT market we will start having serious solutions and stop having pointless debates about the security risk without any serious debate on underlying issues.

Senate bill to secure Internet of Things (IoT)

Senate bill to secure Internet of Things (IoT)

The Internet of Things, and now the U.S federal government along with it, have a problem. Devices are smart enough to impact the world around them, but aren’t built smart enough to protect themselves.  In the recent past, these devices have been maliciously commandeered to bring down large swathes of the Internet, steal sensitive information, send spam emails, spy on individuals, and bring a whole city to its knees.

The first step in solving a problem is admitting you have one, and the Senate took this step with the introduction of the “Internet of Things Cybersecurity Improvement Act of 2017”.

The new legislation introduced by Sen. Mark Warner and Sen. Cory Gardner, sets minimum standards for the manufacturing, deployment and maintenance of IoT devices purchased by the U.S federal government. It received inputs from technology experts at the Atlantic Council and Harvard University to address cyber attacks that leverage IoT devices. The bill is aimed at responding to the “obvious market failures,” said Warner in an interview with Reuters and also to prevent further intrusions into federal systems “without halting the life-changing innovations that continue to develop in the IoT space,” said Gardner.

The key provisions of the bill are:

  • The manufacturer or the contractor of the device to the federal government must provide a written certification bearing, but not limited to the following:
    • No known vulnerabilities are to be present at the time of delivery of the device. If present, mitigation strategies are to be disclosed to the agency in detail.
    • Any updates to the device (inclusive of hardware, software and firmware) are to be properly authenticated by means such as digital signatures.
    • The devices are to use only non-deprecated industry-standard protocols and technologies.
    • The devices will not have fixed or hard-coded credentials such as usernames, passwords, tokens, cryptographic keys and other authentication primitives and that these credentials will not be modified or revoked by the user or manufacturer, except via an authenticated firmware update.
  • The U.S federal government and associated agencies are to outline policies and procedures for conducting cybersecurity research on Internet-connected devices and safeguards for such well-meaning and good-intended researches from criminal liabilities or penalties.
  • Finally, that if an existing third-party security standard for Internet-connected devices provides an equivalent or greater level of security, an executive agency may allow a contractor to demonstrate compliance with that standard in lieu of the requirements followed by a written certification that the device complies with the security requirements of the industry.

Assuming this bill passes, what does this mean for enterprises purchasing IoT devices? In theory, the purchasing power of the federal government should lead large IoT manufacturers to start following these minimum security standards, which would benefit all companies by default. However, an enterprise should not assume this to be the case. Companies should use the key provisions in the Senate bill as guidelines to discuss with their device manufacturers before a purchase. Ask your suppliers if they meet these provisions, and if not, where they have gaps and what their plan is to fill them.

For device manufacturers, this bill will affect your approach to security. Let’s look at each requirement and its possible ramifications:

  1. No known vulnerabilities are to be present at the time of delivery of the device to the federal government:

There are several nuances in this point that should be explored. First, a vulnerability must be known to be covered by this provision.  It’s not perfectly clear if it is specifying if the word ‘known’ means ‘publicly known’ or just ‘known by the company’, but I would guess the latter. Assuming it’s known, the company has two options: fix it or report it at procurement time along with mitigation strategies. Taking this into account, what is the incentive for manufacturers to perform detailed security testing? This is where the provision on cybersecurity research comes in. Since cybersecurity research is encouraged, it is likely someone will find vulnerabilities in your products. It is generally in the company’s best interest to find vulnerabilities internally and patch them rather than have a vulnerability exposed publicly.

Finding vulnerabilities in IoT devices includes software vulnerabilities, but there are also key hardware tests that should be performed. IoT hardware testing involves attacks such as side channel attacks, fault injection, imaging and IC modification. The testing process also involves source code audit, deobfuscation testing, fuzzing, cryptography implementation audit, software vulnerability verification, assessment of long-range wireless IoT protocols and of short-range communication protocols. The assessment process can be daunting to device manufacturers, but some IoT security solutions companies have the skills and experience to perform advanced hardware penetration testing (device, application, network) while leveraging proprietary security schemes and security intelligence.

Remember that device manufacturers do have the option to mitigate vulnerabilities without fixing the root cause. The vulnerability and mitigation strategy need to be disclosed at the time of delivery. In general, the manufacturer should continue to work on mitigating the vulnerability completely and integrate it into their future upgrades to the device, if applicable.

  1. Any updates to the device (inclusive of hardware, software and firmware) are to be properly authenticated by means such as: digital signatures: This provision is relatively straightforward: updates should be authorized and authenticated before they are applied to the device. There is no language that indicates this is a reference to over–the-air updates only, so even locally initiated updates need to be secure. Generally, authentication uses digital signatures, which can be challenging to implement correctly at scale. Device manufactures that lack expertise to implement or assess the implementation of PKI could rely on security solution companies to provide key management solutions that involve online and secure generation of device keys. Alternatively, device manufacturers can use third-party solutions to manage their updates that provide authentication.
  2. The devices are to use only non-deprecated industry-standard protocols and technologies: The federal government expects the device manufactures to adhere to industry security best practices for the manufacturing of the devices and hence, on those grounds, the device manufactures would need to stay abreast with the current trends and practices in the field of cybersecurity. Although it is best practice to use the latest version of protocols and technology if possible, this provision only prohibits deprecated technology (such as the MD5 algorithm). Device manufacturers could rely on technology consulting or security advisory companies for guidance in implementing these solutions.
  3. The devices will not have fixed or hard-coded credentials such as – usernames, passwords, tokens, cryptographic keys and other authentication primitives and that these credentials will not be modified or revoked by the user or manufacturer, except via an authenticated firmware update: Hard coded and global credentials have been the root of many IoT security incidents in the last two years. This provision ensures that keys and credentials can be changed or rotated, and hopefully are not set globally on all devices (although this isn’t technically in the provision). It also mandates that any changes to credentials be done in a secure fashion. Rotating device secrets securely at scale is a challenging undertaking, and should be approached with care. There are IoT platform vendors that provide this service today, and unless a manufacturer already has an infrastructure to support this, they should consider using third-party support.
  4. To outline policies and procedures for conducting cybersecurity research on Internet-connected devices and safeguards for such well-meaning and good-intended researches from criminal liabilities or penalties: Cybersecurity research usually involves breaking into things (this involves open source and proprietary devices, protocols, softwares, hardwares, etc.) and anything that requires breaking without prior notice or permission may be considered a crime. While the procedures to obtain permission can be rigid and expensive, it leaves little room for cybersecurity researchers to perform experiments and studies and to provide the best security measure to safeguard devices. This in turn, results in limited knowledge among device manufacturers about the best way to secure the devices. By being more open to cybersecurity research on IoT, the device manufactures could invest into cybersecurity research and the IoT community as a whole stands to benefit from the outcomes of the research as has been in the field of digital media (robust watermarking and anti-piracy technologies have morphed and evolved through over decades of research and experiments)
  5. Finally, that if an existing third-party security standard for Internet-connected devices provides an equivalent or greater level of security, an executive agency may allow a contractor to demonstrate compliance with that standard in lieu of the requirements followed by a written certification that the device complies with the security requirements of the industry: This provision allows the device manufacturers to employ third-party institutes to evaluate and certify their devices from a security perspective. One example of a device certification is the CSPN from ANSSI (L’Agence Nationale de la Sécurité des Systèmes d’Information).

Though the proposals and guidelines will later be detailed by NIST and other related federal agencies (provided the bill is passed), it is a safe bet to say that IoT security is imminent. Through rapid and educated investments in advanced labs and strong R&D base, device manufacturers can be uniquely placed to meet current and future security requirements of this fast-growing industry. Alternatively, device manufacturers also have several options to partner with IoT security solution companies that provide in-depth security assessments and evaluations of IoT products allowing the device manufacturers to identify and address security vulnerabilities before products go to market, and helping ensure their company doesn’t become the next big cyberattack headline.