Trusted Systems in Networking Infrastructure

1

Trusted Systems in Networking Infrastructure Rafael Mantilla Montalvo

Cisco Systems

June 2013

2

From Counterfeit to Trusted Systems

Counterfeit Secure Boot Device Identity Authentication

Counterfeiter Signing Key Identity Key and Certificate

Identity Key and Certificate

SignedImage TPM

NetworkAuthentication

System

3

Network Devices Security Goals• Protect network devices against counterfeit

• Strong identity using cryptographic techniques

• Protect software using cryptographic keys• Image signing

• Ensure execution of trusted software• Signed image validation at boot time (Secure Boot)

• Protect signing keys (Identity) in hardware• Secure storage in Trusted Platform Module (TPM)

• Strong device authentication using certificates• TPM NV storage provisioning at manufacturing time

• Authenticate network devices during operation• Network authentication system

Aggregation

Enterprise Network

Data CenterServer FarmAccess

Core

Services

4

Agenda• Counterfeit and mitigation mechanisms• Secure boot

• Device Identity and TPM

• Network authentication system

4

Company Culture

Trusted Infrastructure

Policies Processes Technologies

Genuine Products with Embedded Security

Supply Chain Security

Solutions

Individual and Group Threats

Gray Market/ Counterfeit

SoftwareManipulation

Espionage

HardwareTampering

Disruption

5

Counterfeit Landscape• There has been an increase in counterfeit, grey market and illegal

product modification across the globe

• Industry estimates that up to 10% of electronic products worldwide are counterfeit, increasing the potential of multiple counterfeit devices within the network infrastructure

• Counterfeiters target hardware and software vulnerabilities, without any consideration of users business concerns, devices performance, devices safety or security

• Lost Revenue for OEM, Lost Security, Productivity, and Reputation for the Customer• Example: Customs investigation lead to seizure of network gear having an estimated

retail value of more than $143M (Operation Network Raider)

• Counterfeiters main motivation is driven by monetary gain

• Counterfeiters target OEM with high reputation, majority market share and leadership in IT equipment as high monetary opportunity

6

Counterfeiters Attacks• Reverse engineer equipment and build from lower cost and lower

quality components• Spoofing OEM serial numbers and product identifiers

• Change devices appearance outside of OEM manufacturing facility to make it appear like an enhanced or upgraded unit

• Build multilayer PCBs where only the outer layers look genuine and populated them using scrap parts

• Use modified boot code to bypass software interaction with the TPM resulting in:

• Inability to authenticate hardware• Able to bypass software licensing checking

7

Dark Reading Reports (May 23, 2013)

http://www.darkreading.com/vulnerability/bios-bummer-new-malware-can-bypass-bios/240155473?nomobile=1

8

Counterfeit Mitigation Factors• Secure boot

• Ensure boot of genuine code using image signing

• Device identity• Establish device identity using cryptographic keys and certificates

• Authenticate devices in the network• Verify device identity using keys and certificates• Verify code licensing using certificates• Verify product serial number, product identifier, electronic

components serial number and others• Verify device software, firmware, programmable devices image and

configuration files

9

Agenda• Counterfeit and mitigation mechanisms

• Secure boot• Device Identity and TPM


9

Company Culture





Solutions




Espionage

HardwareTampering

Disruption

10

Secure Boot Requirements• Immutable Root-of-Trust in hardware

• Typically a boot loader and cryptographic key residing in CPU ROM

• Root-of-Trust protects the initial boot process• Authentication, integrity and confidentiality of boot image

• Root-of-Trust uses cryptographic keys to authenticate and validate the integrity of the boot image

• Boot image is signed using cryptographic keys• Boot image could be encrypted to provide confidentiality• Boot image resides typically in FLASH

• Root-of-Trust starts a secure boot chain by passing control to the boot image after authentication and integrity verification

• The boot image passes control to the OS after authentication

11

Secure Boot ChainStep 3Step 2Step 1

CPU

Immutable

OS

CPU

ROMBoot

Loader

Boot Image

CPU

Authentication and integrity validation

Root-of-Trust

1. Boot Loader authenticates and validates integrity of the Boot Image

2. Boot Image authenticates and validates integrity of the OS

3. OS is launched

12

Boot Image Authentication• Boot Image is authenticated and integrity verified using

cryptographic keys• Cryptographic keys are typically asymmetric RSA keys

• The Root-of-Trust is anchored in the OEM private key• OEM private key is used to sign the boot image and kept secret

• The Boot Loader uses the OEM public key to authenticate and verify integrity of the boot image

• The OEM public key resides typically in FLASH

• The OEM public key is typically protected with an asymmetric key• Provides biding of public key with the CPU

• The asymmetric key is CPU specific and OTP (fuses)

13

Secure Boot Keys• Public Root-of-Trust Key

• Resides in ROM• Used to Authenticate and Verify Boot Image Public Key• Owned by the OEM

• Public Boot Image Key• Resides in FLASH• Used to Authenticate and Verify Boot Image• Signed with Private Root-of-Trust Key• Owned by the OEM

• Boot Image signed using private key

14

Secure Boot Diagram

ROMBoot Loader

Root-of-Trust Key

Processor

Core Core

SP

I Int

erfa

ces

Boot Image Public Key

Digital Signature

Boot Image

Digital Signature

Authenticate

Authenticate

Flash

RAM

15

Boot Image AuthenticationStep 3Step 2Step 1

CPU

Immutable

OS

CPU

ROMBoot

Loader

Boot Image

CPU

Authentication and integrity validation

Root-of-Trust

• Boot Loader in ROM initializes device

• Establish Public Root-of-Trust key in ROM

• Loads and Authenticates from FLASH Public Boot Image Key

• Loads and Authenticate from FLASH Boot Image

• Passes control to Boot Image

16

Secure Boot Summary• Ensures only authentic OEM software boots up on

an OEM Device

• Anchored in hardware (ROM CPU)

• As the boot image is created, the signature is installed using a secure private key

• As the software boots, the system checks to ensure the installed signature is authentic

• Same process is repeated to boot the platform OS

17


• Secure boot

• Device Identity and TPM• Network authentication system

17

Company Culture





Solutions




Espionage

HardwareTampering

Disruption

18

Device Identity• The device identity is cryptographically represented by a key pair

and a certificate

• The key pair and the certificate are owned by the OEM

• The OEM generates an asymmetric RSA key pair and signs a certificate with the private part of the RSA key

• The RSA key pair is inserted in the TPM and protected in TPM shielded location

• The OEM certificate is permanently stored in a TPM NV Index location

• The NV Index is locked after the certificate is stored to make it permanent and immutable for the life of the platform

19

Identity Verification• After Secure Boot, the OS verifies the authenticity of the

certificate pre-provisioned in the TPM

• The identity is in the form of a X.509 certificate

• The certificate is an assertion by the OEM relating the platform identity with the OEM public key

• The assertion is validated using asymmetric cryptographic means

• The TPM contains the OEM identity key pair and the certificate as a unique, permanent and immutable objects

• The OS uses the identity public key to validate the authenticity of the identity certificate

• The identity certificate maybe chained to a root certificate (OEM)

20

Secure Unique Identity in TPM

Step 3Step 2Step 1

CPU

Immutable

OS

CPU

ROMBoot

Loader

Boot Image

CPU

Authentication and Integrity Validation

Root-of-Trust

Secure Boot

Step 4

OSCPU

IdentityTPM

Step 5

OSCPU

IdentityTPM

Secure Device Identity (TPM)

Identity Authentication

Other TPM Services

21

Certificate Chain Verification Diagram

TPM OS

Request CertificateChain

Return CertificateChain

Verify CertificateChain

CASub-CAIdentity Certificate

TPM_NV_ReadValue()

22

Identity Key Verification Diagram

Send ChallengeWith Nonce

Send ResponseWith Signature

Verify Signature

TPM OS

Nonce

Sign

Signed Noncewith Private Identity Key

Sign

Verify Signaturewith PublicIdentity Key

Identity Authenticated!

TPM_Sign()

23

TPM Provisioning – Identity Certificate• In order to verify the authenticity of the device the TPM needs to

be provisioned with Identity Key and Certificate

• The OEM is responsible for initially provisioning the TPM

• In this context, provisioning refers to allocating part of the TPM’s NVRAM and writing data to the NVRAM

• OEM provisioning can be used to store identity and other (licensing) certificates in NV Indexes

TPM_NV_DefineSpace()TPM_NV_WriteValue()

24

OEM Responsibility• A new TPM comes in a state that makes it very easy for the OEM

to provision

• The OEM can create TPM NV Indexes to store certificates

• The OEM creates a certificate and writes the certificate to NV Index

• Once the certificate is correct, the OEM write-protects the certificate Index and then performs an OEM Lock on the TPM

• The lock terminates the “easy provisioning” state and forces the TPM to enforce access permission

• It prevents anyone from altering the OEM’s indexesTPM_NV_DefineSpace()TPM_NV_WriteValue()

25

Locking the TPM – NV Indexes• The OEM may wish to create several indexes and if so they must

be created before asserting the OEM Lock

• NV Indexes have a “D” bit in the Attribute

• The TPM Lock operation sets the “D” bit in the Attribute

• It is impossible to create or redefine an Index after the “D” bit is set

• Indexes must be properly defined before the Lock operation

• Failure to do so requires replacing the TPM

• Locking is not recommended until manufacturing (i.e. not during development and debug)

TPM_NV_WriteValue(Length = 0)

26

TPM Keys - Typically RSA• Endorsement Key (EK)

• Unique TPM identity• Created by the TPM manufacture in a secure environment• Non-migratable, store inside the chip, cannot be remove

• Storage Root Key (SRK)• It is the top level element of TPM key hierarchy• Created during take ownership• Non-migratable, store inside the chip, can be remove

• Storage Keys• Keys used to wrap (encrypt) other elements in the TPM key hierarchy• Created during user initialization

• Signature Keys• Keys used for signing operations (Identity)• Must be a leaf in the TPM key hierarchy

27

Endorsement Key (EK)• The EK is an asymmetric, typically RSA, key unique for every

TPM and therefore uniquely identifies a TPM

• Generation of the TPM EK is usually done during manufacturing

• The EK is backed by a certificate typically issued by the TPM manufacturer

• The EK certificate guarantees that the key actually is an EK and is protected by a genuine TPM

• The EK can not be changed or removed

TPM_CreateEndorsementKeyPair()

28

TPM Ownership• Taking ownership of a TPM is the process of inserting a shared

secret into a TPM shielded location

• Any entity that knows the shared secret is a TPM Owner

• To provide confidentiality the proposed TPM Owner encrypts the shared secret using the public part of the EK

• This requires the private part EK to decrypt the value

• As the private part of the EK is only available in the TPM the encrypted shared secret is only available to the intended TPM

• Typically the TPM ships with no Owner installed

TPM_TakeOwnership(OwnerAuth)

29

Storage Root Key (SRK)• Taking Ownership of the TPM creates an SRK

• SRK is the top level element of TPM key hierarchy

• After taking Ownership, the Owner has the public part of the SRK

• It follows that objects owned by a previous owner will not be inherited by a new owner

• The SRK key is deleted from the TPM when a new Owner is established

• Notice that EK and SRK are the only keys permanently stored in the TPM and not lost during reset

• All other keys (Identity) must be restored after a reset cycleTPM_TakeOwnership()

30

Device Identity Key• It is desirable that he device identity keys for Network

Infrastructure Devices be created outside the TPM by the OEM back-end system

• The private part of the identity key is encrypted with the public part of the SRK by the OEM back-end system

• The identity key can then be loaded and stored in the SRK hierarchy and used to proof the identity of the device

• Notice that if the Ownership changes, a new SRK is created by the new Owner and the private part of the identity key must be encrypted with the new public part of the SRK before loading

TPM_MakeIdentity()TPM_ActivateIdentity()TPM_LoadContext()

31

Benefits of Strong Authentication• Opportunity to assure users have Authentic OEM devices

• Opportunity for users to Identify and Replace Non Compliant and Inferior Counterfeit devices within their network

• Opportunity for users to confirm their suppliers are providing authentic OEM devices

• Opportunity for users to confirm their procurement practices are providing the quality devices they are paying for

• Assure users their devices will be serviceable under OEM Services

32


• Secure boot

• Device Identity and TPM


32

Company Culture





Solutions




Espionage

HardwareTampering

Disruption

33

Network Authentication• Network authentication helps identify suspicious devices in users

networks

• Network authentication validates the collected data from the network against the OEM backend manufacturing/shipping database

• Network authentication identify the devices as genuine or not-genuine

• Network authentication processes the device secure identifier, MAC addresses, serial number and Product ID among other parameters

• The end user is provided with a report indicating if the device is suspicious, non-suspicious or missing data

Suspicious

Non-Suspicious

MissingData

34

Network Authentication DiagramSuspicious

Non-Suspicious

MissingData

Customer

Networ

k

WAN

ReportsDiscovery

OEMAnalytics

Network

OEMDiscoveryServices

1. OEM Discovery Services performs devices discovery and inventory

2. OEM Discovery Services transfers collected data to the OEM where data is analyzed

3. Analyzed data is returned to OEM Discovery Services to produce vendor reports (suspicious, non-suspicious or missing data)

35

Summary• Counterfeit issues require new technologies to mitigate hardware

and software attacks

• Secure Boot ensures execution of genuine software from the boot loader to the OS

• Trusted OS authenticate the hardware using identity held by the TPM

• Strong identity can be used by Network Authentication tools to validate the Network Infrastructure Devices as genuine OEM devices

• Network Authentication tools can be used to provide deeper attestation analysis to determine the Trustworthiness of the Network Infrastructure

Thank you.

Trusted Systems in Networking Infrastructure

Documents

Transcript of Trusted Systems in Networking Infrastructure