360 likes | 515 Views
Trusted Systems in Networking Infrastructure . Rafael Mantilla Montalvo Cisco Systems June 2013. From Counterfeit to Trusted Systems. Identity Key a nd Certificate. Identity Key a nd Certificate. Signing Key. Counterfeiter. Device Identity. Counterfeit. Authentication. Secure Boot.
E N D
Trusted Systems in Networking Infrastructure Rafael Mantilla Montalvo Cisco Systems June 2013
From Counterfeit to Trusted Systems Identity Key and Certificate Identity Key and Certificate Signing Key Counterfeiter Device Identity Counterfeit Authentication Secure Boot Signed Image Network Authentication System TPM
Network Devices Security Goals Enterprise Network • 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 Core Aggregation Services Data Center Server Farm Access
Agenda Gray Market/ Counterfeit • Counterfeit and mitigation mechanisms • Secure boot • Device Identity and TPM • Network authentication system Trusted Infrastructure Espionage HardwareTampering Software Manipulation Solutions Individual and Group Threats Disruption Genuine Products with Embedded Security Supply Chain Security Policies Processes Technologies Company Culture 4
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 OEMwith high reputation, majority market share and leadership in IT equipment as high monetary opportunity
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
Dark Reading Reports (May 23, 2013) http://www.darkreading.com/vulnerability/bios-bummer-new-malware-can-bypass-bios/240155473?nomobile=1
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
Agenda Gray Market/ Counterfeit • Counterfeit and mitigation mechanisms • Secure boot • Device Identity and TPM • Network authentication system Trusted Infrastructure Espionage HardwareTampering Software Manipulation Solutions Individual and Group Threats Disruption Genuine Products with Embedded Security Supply Chain Security Policies Processes Technologies Company Culture 9
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
Secure Boot Chain Step 1 Step 2 Step 3 • Boot Loader authenticates and validates integrity of the Boot Image • Boot Image authenticates and validates integrity of the OS • OS is launched CPU ROM Boot Loader CPU CPU OS Boot Image Root-of-Trust Authentication and integrity validation Immutable
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)
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
Secure Boot Diagram Flash Processor Boot Image Public Key ROM Boot Loader Root-of-Trust Key Authenticate Digital Signature SPI Interfaces Boot Image Authenticate RAM Core Core Digital Signature
Boot Image Authentication Step 1 Step 2 Step 3 • 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 CPU ROM Boot Loader CPU CPU OS Boot Image Root-of-Trust Authentication and integrity validation Immutable
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
Agenda Gray Market/ Counterfeit • Counterfeit and mitigation mechanisms • Secure boot • Device Identity and TPM • Network authentication system Trusted Infrastructure Espionage HardwareTampering Software Manipulation Solutions Individual and Group Threats Disruption Genuine Products with Embedded Security Supply Chain Security Policies Processes Technologies Company Culture 17
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
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)
Secure Unique Identity in TPM Secure Device Identity (TPM) Secure Boot Step 5 Step 1 Step 2 Step 3 Step 4 CPU TPM CPU CPU TPM CPU CPU Identity Boot Image Identity OS OS OS ROM Boot Loader Root-of-Trust Identity Authentication Authentication and Integrity Validation Other TPM Services Immutable
Certificate Chain Verification Diagram Request Certificate Chain Verify Certificate Chain TPM OS Return Certificate Chain Identity Certificate CA Sub-CA TPM_NV_ReadValue()
Identity Key Verification Diagram Verify Signature Send Challenge With Nonce TPM OS Send Response With Signature Identity Authenticated! Sign Sign Nonce Signed Nonce with Private Identity Key Verify Signature with Public Identity Key TPM_Sign()
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()
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 indexes TPM_NV_DefineSpace() TPM_NV_WriteValue()
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)
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
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()
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)
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 cycle TPM_TakeOwnership()
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()
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
Agenda Gray Market/ Counterfeit • Counterfeit and mitigation mechanisms • Secure boot • Device Identity and TPM • Network authentication system Trusted Infrastructure Espionage HardwareTampering Software Manipulation Solutions Individual and Group Threats Disruption Genuine Products with Embedded Security Supply Chain Security Policies Processes Technologies Company Culture 32
Non-Suspicious Network Authentication Missing Data Suspicious • 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
Reports Non-Suspicious Network Authentication Diagram Missing Data OEM Discovery Services OEM Analytics Suspicious • OEM Discovery Services performs devices discovery and inventory • OEM Discovery Services transfers collected data to the OEM where data is analyzed • Analyzed data is returned to OEM Discovery Services to produce vendor reports (suspicious, non-suspicious or missing data) WAN Customer Network Discovery Network
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