IoT Security: Intel EPID Starts at the Silicon



With a projected 100 billion IoT devices by 2020, security cannot be reliably entrusted to end users or installers deploying millions of IoT devices every month.

There are 8.4 billion Internet-connected things in use this year, which is up by 31% from 2016, according to Gartner, which also reveals that “total spending on endpoints and services will reach almost $2 trillion in 2017.”[1] The Internet of Things (IoT) is shorthand for anything connected to the Internet that can autonomously communicate to accomplish a purpose, transceiving data. Massive amounts of data, in combination with algorithms, artificial intelligence, or other paradigms, can glean information for decision-making on an unprecedented scale. IoT automates painstaking data-gathering and can also provide a low level of interpretation that sifts out irrelevant data. The potential for deeper visibility can result in productivity gains, scalpel-like precision for decision-making, risk reduction, and a heretofore unnatural depth and breadth of information for automation, which can result in savings of time, energy, expense, and capital expenditure.

However, one of our largest IoT problems is security. Another problem is the sheer scale of the number of IoT devices; one projection indicates 100 billion IoT devices deployed by 2020, thus initiating security at deployment can be a challenge. IoT solutions that require manual registration in the field are untenable and impractical. To leave installers to implement the last step in security is overly optimistic when an installation of hundreds of IoT gateway devices need provisioning across an airport, warehouse, or stadium, for example.

IoT security (or lack thereof) creates another issue: Information Technology (IT) network personnel are loath to add IoT devices to the company network. This means that added functionality from IoT devices purchased and installed by operations technologists (OT) (e.g., facilities management) may face significant delays in getting connected to the company network due to a lack of trust. Smart solar, windmills, and simple things like pump monitoring via smartphone will not get connected to the company wi-fi until IT clears the devices as secure. Vendors are left with extra steps beyond the sale to prove trustworthiness, otherwise equipment without connections loses its “smart” status. Security has become an increasingly well-known problem as Internet-connected devices from computers to smartphones to smart light bulbs create individual points of access for hackers worldwide. At the IoT DevCon held in Santa Clara last April, the majority of keynotes were directed at IoT security. Differentiation of smart product design is simply not as interesting as innovation lower down in the stack. Intel® might have an answer, however, that starts with fundamentals in hardware and can be tailored to myriad use cases that characterize IoT.

Intel Makes a Case at IoT DevCon
Jennifer Gilburg, Director of Strategy, IoT Security at Intel corporation delivered a keynote directed at Intel’s Enhanced Privacy Identification (Intel® EPID) security technology, which begins at the physical layer. The Intel IoT Platform is a reference model intended to reduce the complexity of security and interoperability in developing and deploying IoT solutions covering the gamut of use cases (see Figure 1). Intel EPID provides a foundation for addressing secure, interoperable, and affordable IoT development and deployment solutions with the ability to scale to IoT growth while also meeting the most stringent privacy requirements.

The Intel IoT Platform Reference Security Model is a starting place for IoT security implementation. (Source:  Intel white paper: A Cost-Effective Foundation for End-to-End IoT Security.)

The Intel IoT Platform Reference Security Model is a starting place for IoT security implementation. (Source: Intel white paper: A Cost-Effective Foundation for End-to-End IoT Security.)

Gilburg asserts that security in Intel’s EPID technology begins in a hardware root-of-trust and continues throughout hardware, software, and through deployment as products are released. Security cannot be reliably entrusted to end users or installers deploying millions of IoT devices every month. Security needs to be a plug-and-play event for end users and installers if it’s not to be neglected in the last mile. Intel’s effort centers around helping developers do it right with an end-to-end technology like EPID, which Intel partners such as Microchip use, beginning in the silicon. Root-of-trust offers inherently trusted elements, whether hardware or software based, in the chain of custody for deploying secure IoT.

Gilburg rightly states that effective security extends across the entire lifecycle of a product. A viable product should have a minimum of protection, which she indicates that Intel terms a “minimum viable product,” meaning “the least that you can get away with.” That the least effort starts in silicon is no surprise, considering the sophistication of hacks at the lowest level of the stack, such as at boot up or in firmware updates. In her talk, Gilburg went on to explain that “…if you do nothing else with security, you have to have these building blocks. And so we put it into our silicon. It’s protected boot, protected storage. You want hardware and software identities, you want the ability to have a hardware root of trust, but you also want to be able to store software keys in a hardened fashion, in a trusted execution environment.”

For  IT networking personnel, assuring security requires attesting the authenticity of IoT devices throughout the lifecycle, including at hardware manufacturing, throughout software integration, installation or deployment, and even within the process of creating data. Intel’s EPID uses layers of security, starting with cryptography in the bedrock silicon of the chip using advanced hardware and software security.

A boon in EPID that U.S.-only markets are now thinking about is fundamental privacy. EPID does not require personally identifiable information to work, unlike the persistent identity associated with Public Key Infrastructures (PKI). It is not feasible to expect privacy when data is associated with an identifiable entity in every instance. To maintain hope of gaining acceptance in countries with strict privacy laws, the goal should always be to collect the minimum amount of data needed to do the job, and no more. Collect only a minimum amount of information that is tied to your data so you have only the metadata necessary to accomplish a task. IoT should not be collecting anything else, as it’s simply a liability to do so. Therefore, EPID does not require individual identifiers. This is important in countries with strict privacy laws like Japan and Germany. For example, if an IoT system monitoring traffic speed has sensors that detect a car on the highway, all the IoT monitoring system needs to know is that the car is legitimate (not someone spoofing a car) and the speed of the car. Further on down the highway the same car might pass by, but the IoT system will not recognize it as the same car, only that it is again a legitimate car and that car’s speed.


EPID starts with minimum data for strict privacy use cases. PKI can always be added for use cases that require specific identification, such as positive identification for billing. (Source: White Paper, Enhancing National Cybersecurity with the Internet of Things (IoT))

EPID starts with minimum data for strict privacy use cases. PKI can always be added for use cases that require specific identification, such as positive identification for billing. (Source: White Paper, Enhancing National Cybersecurity with the Internet of Things (IoT))

Aiming IoT only at an intended target while minimizing data collection on that target also reduces network traffic while limiting security to a “need to know basis.” As mentioned above, one of the unintended consequences of traditional PKI is the ability to trace users. When you have a public key and a private key and your device requires the signature of the private key, then you know who signed it. This is how traditional PKI works. With EPID there are multiple private keys linked to one group key. With EPID, unless you intentionally add PKI on top of EPID (e.g., for billing), you cannot determine that an action was the same user authenticating twice. If EPID is a built-in technology, developers can minimize the data that they are collecting and sharing while maintaining compliance in countries with strict privacy laws. But with traditional PKI, starting with a foundation of enhanced privacy and determining later whether the use case needs additional known data is not possible.

It’s interesting to note that EPID is in all Intel silicon. EPID is an ISO standard and a Trusted Computing Group (TCG) standard. EPID security includes two-way, mutual authentication so that the new owner needs to prove itself to the device as much as the device needs to prove itself to the new owner. Rogue devices (such as such as smart drones hovering near smart lamps) are prevented from taking over devices in an ecosystem. EPID is also available in Intel partner silicon and freely and openly available for anyone to use.

The process of how EPID gets implemented has most of the heavy-lifting done before the installer ever touches a smart product, but use cases can vary. However, in a common scenario EPID-provisioned silicon goes to an OEM, who puts in a unique General Use Identification (GUID) identifier. (A GUID is a one-time-use identifier for the IoT device to identify itself to the authentication service later on.) At the time of execution or onboarding, a URL in the device allows it to “phone home” to the onboarding service upon power up. An ownership credential is generated that initiates a chain of trust. The chain of trust allows the supply chain to sign the certificate that went before it, so when the owner buys the IoT device they can observe a chain of trust all along the supply chain. Similar practices exist for authorized parts distributors, pharmaceuticals, and evidence in criminal investigations. Within the EPID framework, the process will authenticate the new owner to the device, and the device can verify the new owner.

A Proof-of-Concept Use Case
To better illustrate how EPID can work, what follows is a proof-of-concept use case. As an example, consider a smart light bulb. Once the lightbulb is assigned a GUID number at the OEM, an entity further down the chain, perhaps a distributor, might receive the lightbulb. The distributor signs the ownership proxy, which is a digital document in the chain of trust that goes with the light bulb through the supply chain. Ultimately an end user buys the light bulb and installs it in an IoT platform management system, which we will call “Wee-wow” as a fictional example. Thus, Wee-wow will manage the lightbulb once it’s deployed. When the end user buys the smart light bulb, they import the ownership proxy into their Wee-wow platform management system. Wee-wow pings the EPID service to identify itself as the end-user platform that’s using the new smart light bulb’s unique GUID number. The Wee-wow IoT platform management system contacts the EPID service with a message stating something like, “I am GUID345. I will wait at IP address 8.8.8.8.” In this example, the installer comes in the following week, hikes up a ladder and screws in the smart light bulb.  Upon power-up, the smart light bulb connects with the service, identifies itself as GUID345, and requests the identity of its new owner. The service then tells the smart light bulb to “try the owner, Wee-wow, at IP address 8.8.8.8 because it claims that it’s your new owner.” It’s important to note that the process arranges matchmaking, so to speak, between device and owner and is not negotiating trust in the cloud.

The smart light bulb then connects to the IP address 8.8.8.8 and shows its EPID signature. In this use case, there could be an attestation service that allows you to attest to the validity of the device, as in what type of device it is, or other validation characteristics. After seeing the valid EPID signature, the Wee-wow IoT platform management system sends down the owner proxy and mutual authentication is accomplished. The first signature in the ownership proxy should match the key that was put into the smart light bulb at manufacturing. If it’s a match, the service creates a secure tunnel that allows the developer to provision whatever is needed to make the device operational, for example, updated images and instructions. The service then deletes the ownership credential, onboarding service information, and the GUID, replacing the values such that if the device ever needs to be re-provisioned there are clean credentials for the smart light bulb.

As mentioned earlier, Intel is offering the EPID technology to others. According to the 2016 Intel white paper, A Cost-Effective Foundation for End-to-End IoT Security, “Intel is making Intel EPID technology freely available to all silicon and device manufacturers, software vendors, and the broader IoT community.” A de-facto standard for IoT security couldn’t come too soon. Intel’s realistic conclusion that installers should not be depended upon to key in codes atop a ladder with a smartphone or tablet app is spot-on.

Kicking the Can Down the Road Won’t Work
If IoT is to scale to 50 – 100 billion devices by 2020, depending on the estimate’s source, group and device permissions in the EPID paradigm ease the deployment phase. If an installer is deploying 500 gateways, the installer is mainly concerned with getting the work done, and should not be burdened with keying in long numbers to implement security for each device. Kicking IoT security down the road means it will need to be dealt with later, most likely after some disaster forces positive, not passive action. IoT is vulnerable to hackers, and security is best not left to the last person on the chain. New IoT devices and innovative use cases create new opportunity, revenue, and challenges. As new IoT devices and IoT system architectures are considered for IoT edge devices (which act something like a server-gateway hybrid to pre-process massive amounts of data) we can expect system designers from respected suppliers to take security seriously. As Gilburg said in her keynote, “We’re working with enabling different industry partners…We are saying, ‘Is there a need to securely onboard these devices?’ and 99% of the time the answer is yes, so there’s a lot of opportunity and a lot of interest from customers on solving this problem.” Gilburg was three-deep in a cluster of engineers after her talk, who eagerly peppered her with questions.  Interest is high in  a solution that can be tailored to individual use cases while maintaining privacy from a global viewpoint. IoT is seen as a huge money-maker, but with it comes the cost of mobilizing security.


LynnetteReese_115Lynnette Reese is Editor-in-Chief, Embedded Intel Solutions and Embedded Systems Engineering, and has been working in various roles as an electrical engineer for over two decades. She is interested in open source software and hardware, the maker movement, and in increasing the number of women working in STEM so she has a greater chance of talking about something other than football at the water cooler.


[1] “Gartner Says 8.4 Billion Connected.” Gartner. N.p., 7 Feb. 2017. Web. 15 May 2017. <http://www.gartner.com/newsroom/id/3598917>.

Share and Enjoy:
  • Digg
  • Sphinn
  • del.icio.us
  • Facebook
  • Mixx
  • Google

Tags: