Intel® Enhanced Privacy ID (EPID) Security Technology

Introduction

With the increasing number of connected devices, the importance of security and user privacy has never been more relevant. Protecting information content is critical to prevent exposure of trade secrets for businesses, identity theft for individuals, and countless other harmful scenarios that cost both money and time to repair. Part of protecting data and privacy includes ensuring that the devices touching the data are authentic, have not been hijacked, or even replicated into a non-genuine piece of hardware.

In this article we will discuss the Intel® Enhanced Privacy Identification (EPID) security scheme, which helps to specifically address two device level security issues; anonymity and membership revocation. Billions of existing devices, including most Intel® platforms manufactured since 2008, create signatures that need Intel® EPID verification. Intel is providing the Intel® EPID SDK open source and encouraging device manufacturers to adopt it as an industry standard for device ID in IoT.

Security Review – Public Key Encryption and Infrastructure

When exchanging data between two people or systems, it is important to ensure that it arrives securely, and is not forged. The recipient should have a high confidence that the sender is who they say they are. One of the most widely used methods of ensuring this trusted data transport is by employing a DigitalSignature.One method of creating a digital signature is using the Public Key Encryption (PKE) security scheme. Using a mathematical hashing algorithm, two binary keys are generated which work together to encrypt and decrypt the data. Data that is encrypted (or signed in this use case) using the private key can only be decrypted (verified) using the matching public key. The private key is never shared with anyone, and the public key is available to everyone. This method guarantees that any data decrypted using a public key was indeed encrypted using the matching private key. For the most part, using Public Key Encryption for device authenticity works well, however it does have a few limitations.

Problem 1: Certifying Keys

The first limitation involves the validity of the sender’s key. In order to verify a signature, the public key of the sender is required, however there is no way to guarantee it belongs to the sender, or has not been stolen or tampered with. An additional step can be taken to ensure the validity of the public key which involves certification from a third party called an issuer. Using Public Key Infrastructure (PKI), the level of security can be raised by introducing a new element called a digital certificate, which is signed by the issuer’s private key. The certificate contains the public key of the member, the member’s name, and other optional details. Using this method guarantees that the public key being used is the actual key issued, and hence is the actual sender of the data. Think of an issuer as a notary who guarantees that this signature is correct because they witnessed the person writing it. A digital certificate issued from a certified authority solves the problem of certifying that a public key is authentic.

Problem 2: Shielding Unique Identity

A second limitation with PKI is the inability to remain anonymous while still being granted access. Because one public certificate contains the key owner’s name and information, the ownership of the secured information is inherently known, and if the same device is verified multiple times, its activity could be tracked. Usage of PKI for signed and encrypted emails is useful in this scenario where it is desired for the users to be identified. The recipient installs the public certificate of the sender, and when opening the message has a level of trust that the sender signed these emails using a protected matching private key.

As devices increasingly play roles in requesting authentication to systems, there is a greater need for both devices and users to be anonymous. While a valid attestation is required, it is not a requirement that the device be individually identified or that the device provide any additional details other than the minimum amount of information necessary to prove that they are a genuine member of a trusted device family. Taking this approach allows devices to access a system based on their approved level of access and not any personal information like a MACID or who they are. In other words, in the Intel® EPID scheme, if a hundred authentic signatures are verified, the verifier would not be able to determine whether one hundred devices were authenticated, or if the same device was authenticated one hundred times.

Problem 3: Revoking Access

Yet another limitation with PKE is in the fact that there exists no easy mechanism for revoking a private key that has been compromised. If anyone other than the user gets access to the private key, they can masquerade as that user resulting in a loss of trust for the device. These private keys are often stored in a separate chip called a Trusted Platform Module (TPM) which is also encrypted. While this hardware trusted module approach is much more secure, the existence of the private key on the device still creates the possibility that it can be stolen. Fixing the problem of a stolen key would involve issuance of a new certificate and manual intervention to flash a new private key onto the device. Adding the ability to easily revoke a compromised private key would allow a device to be flagged and disabled automatically, and prevent any further identify theft.

Roles in a Public Key Infrastructure

CA	A Certified Authority is the entity that is issuing security certificates.
RA	The Registration Authority accepts requests for new certificates, ensures the authenticity of the requestor and completes the registration process to the CA for the requestor.
VA	A Validation Authority is a trusted third party that can validate a certificate on behalf of a Certificate Authority.
Member	The role of member can be assumed by an end user or a device. The member is the role that is requesting attestation of itself during secure exchanges.

Figure 1 - PKI Roles and Process Flow

Authentication vs Identification

Gaining access to a system should not always require user identification. The intent behind requesting access to a system is to obtain access; providing only a minimal, certifiable proof that access has been granted. Each user might require a certain level of anonymity based on specific use-cases. Take, as an example, a medical wristband device that monitors sleep habits of someone that is experiencing insomnia. For the individual, it is important to ensure that the data is provided to the doctors for analysis without allowing anyone else to potentially identify them or their private medical data.

For users accessing services, the authentication process is owned by the access provider, which unfortunately often ties access rights directly to an account identifier, which is usually then linked directly to additional account details that the user may want to hold private. Unfortunately, most systems today require a user or device to actually identify themselves in a way that can in fact be traced back to the original user with every transaction. An example in software would be a username. For a device, it might be a MACID or even a public key provided that was stored on secure storage. To prevent this from occurring, the ability must exist by which a user can effectively and rightfully use a system without being required to provide any information that can be immediately linked to themselves. One example would be a toll both. A user should be able to pass through the booth because they were previously issued a valid RFID tag, however no personal information should be required, and the user is not directly known in any transaction or tracking on that device. If the requirement is to trace whom is travelling through the toll booth, then that right is reserved by the access provider, however there are instances when authentication should be separated from identification.

Direct Anonymous Attestation is a security scheme proposed in 2004 that permits a device in a system to attest membership of a group while preserving the identity of the individual. Drafted by Ernie Brickell (Intel Corp), Jan Camenisch (IBM Research®), and Liqun Chen (HP Laboratories®), DAA is now approved by the Trusted Computing Group (TCG) as the recommended method for attestation of a remote device, and is outlined in ISO/IEM 20008.

What is EPID?

Enhanced Privacy Identification (EPID) is an implementation ISO 20008 from Intel that addresses two of the problems with PKI Security Scheme: anonymity and membership revocation. Intel includes EPID keys in many of its processors, starting with chipset series 5 in 2008 which includes all Intel® Core™ processor family products. In 2016, Intel as a certified EPID Key Generation Facility, announced that it has distributed over 4.5 billion EPID keys since 2008.

The first improvement over PKI provides a user or device “Direct Anonymous Attestation” which provides the ability to authenticate a device for a given level of access while allowing the device to remain anonymous. This is accomplished by introducing the concept of a Group level membership authentication scheme. Instead of a 1:1 public to private key assignment for an individual user, EPID allows a group of membership private keys to be associated together, and linked to one public group key. This public EPID group public key can be used to verify the signature produced by any EPID member private key in the group. Most importantly, no one, including the issuer, has any way to know the identity of the user. Only the member device has access to the private key, and will validate only using a properly provisioned EPID signature.

The second security improvement that EPID provides is the ability to revoke an individual device by detecting a compromised signature or key. If the private key used by a device has been compromised or stolen, allowing the EPID ecosystem to recognize this allows the device to be revoked as well as prevent any future forgery. During a security exchange, the EPID protocol requires that members perform mathematical proofs to indicate that they could not have created any of the signatures that have been flagged on a signature revocation list. This built in revocation feature allows devices or even entire groups of devices to be instantly flagged for revocation, instantly being denied service. It allows anonymous devices to be revoked on the basis of a signature alone, which allows an issuer to ban a device from a group without ever knowing which device was banned.

Intel® EPID Roles

There are three roles in the EPID security ecosystem. Firstly, the Issuer is the authority group that assigns or issues EPID Group IDs and Keys to individual platforms; similar devices that should be grouped together from an access level perspective. The issuer manages group membership and maintains current versions of all revocation lists. Using a newly generated private key for the group, the issuer generates one group public key, and as many EPID member private keys as requested, all of which are paired with the one group public key. The Member role is an end device, and represents one individual member in a group of many members, all sharing the same level of access. Finally, the Verifier role serves as the gatekeeper: checking and verifying EPID signatures generated by platforms ultimately ensuring they belong to the correct group. Using the EPID group public key, the verifier is able to validate the EPID signature of any member in the group with no knowledge of membership identity.

Figure 2 – EPID Roles

Issuer	Creates, stores, and distributes issuer signed public certificates for groups. Creates, distributes, and then destroys private keys. Private keys are not retained by an issuer, and are held private by member devices in Trusted Storage such as TPM 1.2 compliant device. Creates and maintains revocation lists.
Verifier	Challenges member verification requests using EPID Group Public Key and revocation lists. Identify any member or group revocations.
Member	An end device for a particular platform. Protect private EPID keys into protected TPM 1.2 complaint storage. Sign messages when challenged.

Now that the roles in EPID have been discussed, let’s discuss the different security keys used in the EPID security scheme. First, for a given group of devices or platforms, the issuer generates the group public key and group private key simultaneously. The group private key has one purpose: the issuer uses it as the basis to create new member private keys, and for that reason the issuer keeps the group private key secret from all other parties. The EPID group public key is maintained by the issuer and verifier, and the private member keys are distributed to the device platforms before the issuer destroys its local versions.

Figure 3 - Using a unique key allocated for a group, an issuer will create one EPID Group Public key and many member EPID private keys as requested.

Security Keys used in EPID

Owner	Pub/Pri	Description	Usage
Issuer	PRI	CA Root Issuing authority private ECC key	Used to sign EPID Group public key and parameters, ensures trust all the way to member.
Issuing CA	PUB	Issuing authority public ECC key	Provided to platform members to enable trust with a verifier and issuer.
Issuer	PRI	Group Private Key. One per group.	Created by issuer for a group. Used to generate private member keys.
Group	PUB	EPID Group Public Key Generated by issuer	Provided to platform devices during provisioning upon request. Used by verifiers to validate EPID member signatures.
Member	PRI	EPID member private key. Private unique key for each device, can be fused, must be secured.	Generated by issuer using Group Private Key. Stored securely or embedded/fused into Silicon Golden private key ready for provisioning into final EPID key. Used to create valid EPID signatures that can be decrypted using a paired EPID Group public key.

The Intel® EPID scheme works with three types of keys: the group public key, the issuing private key, and the member private key. A group public key corresponds to the unique member private keys that are part of the group. Member private keys are generated from the issuing private key, which always remains secret and known only to the issuer.

To ensure that material generated by the issuer is authentic, another level of security is added: the issuing CA certificate. The CA (Certificate Authority) public key contains the ECDSA public key of the issuing CA. The verifier uses this key to authenticate that information provided by the issuer is genuine.

Intel® EPID Signature

An Intel® EPID signature is created using the following parameters:

Member private key
Group public key
Message to be signed
Signature revocation proof list (to prove that it did not create any signatures that were flagged for revocation in the past)

An Intel® EPID signature is verified using the following parameters:

Member’s signature
CA certificate (to certify authenticity of issuer material before it is used)
Group public key
Group revocation list
Member private key revocation list
Signature revocation list

Intel® EPID Process Flows

Embedding

By including the Intel® EPID key into the manufacturing process for a device, a part can be identified as genuine after deployment into the field without any human intervention. This process saves time and improves security by not distributing any private keys or requiring any interaction with the end user. Sequence 1 shows a vendor of a hardware device initiating a request with an Intel® EPID Issuer and ultimately deploying the generated Intel® EPID member keys with the device. The process starts by the vendor requesting to join the ecosystem managed by this Issuer. It can also be said that this member is choosing this Issuer as the Key Generation Facility. When a new member requests to join, an issuer first generates a set of platform keys which are held private and used to generate one group public key and one or more member private keys. The member private keys are deployed with each device securely, and are not known by anyone else including the issuer who does not retain any of the private keys. The Intel® EPID group public key is stored with the issuer and distributed to verifiers upon request.

Sequence 1 – Intel® EPID key request and distribution process

For products supporting Intel® EPID, Intel fuses a 512 bit number directly into a submodule of the processor called the Management Engine. This Intel® EPID private member key is encoded with an Intel® EPID Group ID that uniquely identifies the device as part of the group. As an Issuer and Verifier, Intel maintains public certificates for each of devices encoded with Intel® EPID keys. The private member keys require the same level of protection as a standard PKI private key. Access to the private key can only be achieved using an application that is signed by an RSA Security Certificate whose root of trust is Intel. Other silicon manufactures can follow a similar process, allowing only trusted applications of their corporations to access the private key on their products.

Provisioning

After deployment into the field, a device is not ready to use Intel® EPID out of the box. Before it can be brought to life, it must follow a process called provisioning, which allows it to attest its authenticity using a valid Intel® EPID signature for all future transactions. Sequence 2 shows a possible provisioning process for first boot of an IOT device that uses Intel® EPID. Once granted access to the Internet, a device can call home to state it is online and also check for software updates.

Before granting access however, the provider answering the call must ensure that the device is authentic. In a typical onboarding scenario, a verifier will be sent to a member device requesting a provisioning status. If the device is not already provisioned, meaning it has previously been authenticated, it can complete provisioning by requesting a public Intel® EPID Group Key from the verifier. The member device then stores both the private and public Intel® EPID keys into secure storage, and is able to successfully sign Intel® EPID signatures as well as reply to provisioning status challenges.

SEQUENCE 2 – Intel® EPID Provisioning Flow

Revocation

Because the Intel® EPID security scheme allows for anonymous, group membership attestation, it must also provide the ability to reject or decommission members or groups at any time. Intel® EPID supports revocation at the membership level through identification of an Intel® EPID member signature, or if known, the private member key.

In addition, Intel® EPID supports revocation of an entire Group, which revokes access for all devices in that group. One typical use case, as shown in SEQUENCE 3, Member revocation can be initiated by a verifier or an issuer, however only the issuer can revoke an Intel® EPID member or group. Once a group is revoked, verifiers will no longer reference any signature or key based revocations for the group, meaning it will be ignored.

The Intel® EPID protocol that is exchanged between member-verifier-issuer contains revocation lists, which can grow in size over time for a platform group that has many compromised members. An increase in revocations comes at a linear performance decrease, meaning it will take longer to validate everyone in the chain over time. One solution an issuer can pursue when this occurs is to create a new Group and move the uncompromised members into that new group. The old group can then be revoked.

SEQUENCE 3 – Verifier submits request to Issuer to revoke a member or group

Summary of Revocation Lists
PRIV-RL – Private Member Key is known
SIG-RL – Platform Member Key is not recovered, however signature is known
GROUP-RL – Entire Group should be revoked

While members normally exchange signature exchanges with verifiers, communication also occurs directly with the issuer. The join protocol between a member device and issuer supports the possibility to transport a valid Intel® EPID private key to the device. This can be used for replacement of a compromised key or remote provisioning when the key is not available by the member. A secure, trusted transport mechanism of the key is assumed and outside the scope of the protocol.

Intel® EPID Use Cases

A perfect example usage of Intel® EPID is to prove that a hardware device is genuine. After deployment from a manufacturer, it is important for a device to have the ability to truthfully identify itself during software updates or requesting access to a system. Once authorized, the device is then said to be genuine and a valid member of a group while still remaining anonymous.

Another example is related to digital streaming content. Digital Rights Management (DRM) currently uses Intel® EPID to ensure that a remote hardware device is secure prior to streaming data to the device. This process ensures that the hardware player streaming the content is authentic. Intel® Insider™ technology, which focuses on ensuring digital movie content delivered from service providers, only works on clients that also support Intel® Insider™. This gives content providers a level of trust that their content cannot be copied simply by viewing on the device. There is no disruption to current services, and the only impact would be to those trying to pirate digital content that has been protected using Intel® Insider™.

Intel® Insider™
http://blogs.intel.com/technology/2011/01/intel_insider_-_what_is_it_no/

Intel® Identity Protection Technology with One Time Password (OTP) also uses Intel® EPID keys to implement a two factor authentication method that enhances security beyond a simple username/password.

One time password
https://www.intel.com/content/www/us/en/architecture-and-technology/identity-protection/one-time-password.html

SGX – Software Guard Extensions on Intel® products allow applications to run in a trusted, protected area of memory allocated as an ‘enclave,’ preventing any outside access to the application memory or execution space.

SGX
https://software.intel.com/en-us/sgx

Silicon providers such as Microchip* and Cypress Semiconductor* are now implementing Intel® EPID into their products as well.

Microchip announces plans for implementing Intel® EPID
http://download.intel.com/newsroom/kits/idf/2015_fall/pdfs/Intel_EPID_Fact_Sheet.pdf

Intel Products offering Intel® EPID

Beginning with the release of Series 5 Chipsets, EPID keys have been fused and deployed in all products included in all series five and newer chipsets. For more information on which products are supported, visit the ARK at http://ark.intel.com/#@ConsumerChipsets

Intel® EPID SDK – Member and Verifier APIs

The Intel® EPID SDK is an open source library that provides support for both member and verifier Intel® EPID tasks. It does not include any Issuer APIs, which means it is not meant to create EPID keys. The SDK comes with documentation and examples for signing and verifying messages using included sample Issuer material, which in a real system would be generated by the issuer (Public group Intel® EPID key, Private member Intel® EPID key, and additional information such as the revocation lists.) Verifier APIs do exist that allow populating a special kind of signature revocation list known as the verifier blacklist, however that list can only be populated if members opt-in to allowing themselves to be tracked, and only the issuer can perform the creation of revocation lists that apply to the entire group.

First steps with Intel® EPID

To get started, download the latest Intel® EPID SDK, and begin by reading the documentation included in the doc subfolder with each distribution. https://01.org/epid-sdk/downloads

After building the SDK, navigate to the _install\epid-sdk\example folder and try out the included examples for signing and verifying signatures. The folder contents are shown below which include the sample private key, Issuer certificates, and revocation lists required to complete verifications. The files are well named, making it very easy to know their contents.

Figure 4 – Directory listing of the Intel® EPID 4.0.0 SDK

Intel® EPID Member Example

Create a digital signature using the sample Intel® EPID member private key, groupID, and a sample text string of any content.

signmsg.exe --msg=”TEST TEXT BLOB”

The signmsg command will output a signature file (./sig.dat) whose contents can only be verified using a matching Intel® EPID public key, and the message to be signed. Regardless of what initiates or triggers the verification process, the verifier and member have to use the same message parameter for verification to succeed.

Intel® EPID Verifier Example

Creation and validation of signatures depends that both ends (Member and Verifier) use the same message, hashing algorithm, basename, and signature revocation lists. A change to any of these will result in a signature verification failure. During a validation flow, the verifier may send a text message for the member to sign.

Verify a digital signature using the SDK with the same message.

verifysig --msg=”TEST TEXT BLOB”

Figure 5 – Console sign and verify success

If not specified, the SDK will use default values for the hashing algorithm.

If a different message or hashing algorithm are used, the verification will fail.

Figure 6 – Console sign and verify failure

The executables included with the Intel® EPID SDK examples are intended only for quick validation or integration tests of signatures, and to demonstrate basic member and verifier capability. A developer wanting to implement member or verifier functions would start by taking a look at the included documentation, which includes both an API reference and sample walkthroughs for signing and verifying in Intel® EPID.

Figure 7 – Intel® EPID SDK Documentation

The Intel® EPID SDK is constantly improving with each release, aligning to the newest Intel® EPID standards and providing optimizations for hashing algorithms using Intel® Performance Primitives.

How to implement Intel® EPID

OEM and ODMs can take advantage of the fact that Intel® EPID keys are available on all Intel® products that include series 5+ firmware. The Intel® EPID SDK can be used to create the platform code that will run on the device, however it can only be executed on a platform device in a secured, trusted environment that is signed by Intel. Only a signed application running in the ME secure firmware can access the Intel® EPID key for the purpose of provisioning. An OEM/ODM can work with an Intel representative for guidance on how to enable Intel® EPID on an existing Intel® product that supports Intel® EPID.

Other silicon manufacturers are following suit and adopting Intel® EPID technology. Both Cypress Semiconductor and Microchip are starting to ship products with embedded Intel® EPID member keys as well. What this means is that employment of an Intel® EPID ecosystem can be accomplished regardless of Intel® Silicon – adhering to the rules of the Intel® EPID Security scheme is what permits a device to take advantage of the Intel® EPID features.

Visit the Intel Intel® EPID SDK deployment site for more documentation and API walkthroughs for signing and verifying messages https://01.org/epid-sdk/ .

If you are interested in implementing Intel® EPID into your products, or to join our Zero Touch Onboarding POC, start by emailing iotonboarding@intel.com

If you would like to use Intel’s Key Generation Facility to act as an Intel® EPID issuer for creation of Intel® EPID keys, please start by contacting iotonboarding@intel.com.

Quick Facts

Intel has issued over 4 billion Intel® EPID keys since the release of the Series 5 chipset in 2008
Devices in an Intel® EPID Ecosystem are allowed to authenticate anonymously using only a Group ID
Intel® EPID is Intel’s implementation of Direct Anonymous Attestation
Intel® EPID supports revoking devices based on Private Key, Intel® EPID Signature, or an entire Group
Silicon providers can create their own Intel® EPID ecosystem
OEM/ODMs can use Intel® EPID compliant silicon devices to provide quick and secure provisioning
Intel® products include an embedded true random number generator – providing quicker, more secure seed values for hashing algorithms. (The SDK requires a secure random number generator to be used in any implementation of Intel® EPID.)

Summary

In this article, we discussed an Intel ® security scheme called Intel® EPID that allows devices to attest membership of a group without being individually identified. Intel® Enhanced Privacy Identification technology 2.0 enhances direct anonymous attestation by providing a member revocation ability based on member or group signatures. Choosing Intel products allows OEM/ODMs and ISVs to take advantage of built-in security keys provided by Intel already available in numerous product families. Silicon providers can also take advantage of the Intel® EPID technology by embedding private keys directly into their hardware, and joining their own Intel® EPID ecosystem. With a predicted 50 to 100 billion connected IOT devices by 2020, security and device authenticity should be imperative for both manufacturers and end users.

A very special thanks to the members of the Intel® EPID SDK team for taking time to answer questions on Intel® EPID and the Intel® EPID SDK.

Terminology

AES-NI	AES - New Instructions is a hardware embedded feature available in most newer Intel® products.
AIK	Attestation Identity Key
AMT	Active Management Technology - Support out of band remote access.
Anonymity	A property that allows a device to avoid being uniquely identified or tracked.
Attestation	A process by which a user or device guarantees they are who they say they are.
Certificate	An electronic document issued by a third-party trusted authority (issuer) that verifies the validity of a Public Key. The contents include a subject and a verifiable signature from the Issuer, which adds an additional layer of trust around the contents.
DAA	Direct Anonymous Attestation
DER	Certificate File format - Distinguished Encoding Resource
ECC	Elliptic Curve Cryptography
EPID	Enhanced Privacy Identification
EPID key	A private key held by an individual and not shared with anyone. Is used to create a valid Intel® EPID signature that can be verified using a matching Intel® EPID public group key
iKGF	Intel® Key Generation Facility
Intel SCS	Setup and Configuration Software - Used to access AMT capabilities
ISM	Intel® Standard Manageability
ISO 2008-2:2013	ISO standard for Anonymous digital signature security mechanisms https://www.iso.org/obp/ui/#iso:std:iso-iec:20008:-2:ed-1:v1:en
ME	Intel® Management Engine, sometimes also called Security and Management Engine
ODM	Original Device Manufacturer
OEM	Original Equipment Manufacturer
PEM	Certificate File format - Privacy Enhanced Mail
PKE	Public Key Encryption
PKI	Public Key Infrastructure
Platform	A platform is considered a piece of hardware or device.
Private Key	A key that is owned by an individual or device and is held private and never shared with anyone. It is most commonly used to encrypt a message into cipher-text that can only be opened using a matching Public key.
Public Key	A key provided to the public that will only decrypt a document encrypted using a matching private key
SBT	Small Business Technology
Secure Key	A text string that matches the output of a defined algorithm and allows plain text to be transformed into cipher-text or vice-versa.
SIGMA	SIGn and Message Authentication - A protocol from Intel for platform to verifier two way authentication.
X.509	IEEE standard for certificate format and content

About the Author

Matt Chandler is a senior software and applications engineer with Intel since 2004. He is currently working on scale enabling projects for Internet of Things including ISV support for smart buildings, device security, and retail digital signage vertical segments.