Trusted Computing (TC) is a security chip-based solution to device security. It determines that a device is trustworthy if the device's software operates as designed and is not invaded or tampered with.

TC provides the following security services:

· Trusted startup—TC measures the integrity of software during device startup, and saves the integrity measurements to integrity measurement logs (IMLs).

· Trust status measuring—TC supports measuring the trust status of a running system. Available features include integrity self-verification (performed by a managed device locally) and integrity authentication (performed by the manager).

· Early warning for trustiness problems—TC issues early warnings in response to trust status exceptions.

For more information about IMLs, integrity self-verification, and integrity authentication, see "Configuring PTS."

Concepts

Platform

The term "platform" in this chapter refers to the device itself.

TC chips

TC chips are security chips installed on platforms.

TC chips include trusted platform modules (TPMs) and trusted cryptography modules (TCMs). The device supports only TPMs.

TCSM

Trusted Computing Services Management (TCSM) is a fundamental module for the TC solution. You can use TCSM to manage the keys generated by TC chips and the digital certificates signed for the keys.

TCSM keys

TCSM keys are generated by TC chips. The following types of TCSM keys are available:

· Endorsement key (EK)—Embedded decryption key of a TC chip, which uniquely identifies the chip. An EK is not used for data encryption or signing, and it is not directly used for identity authentication.

· Attestation key (AK)—A replacement generated to protect the privacy of an EK. An AK is a type of signing key that can be used only to sign data created by a TC chip to attest to the identity of the platform.

· Device ID (DevID) key—A type of signing key that is compliant with IEEE 802.1AR. Together with a DevID certificate, a DevID key can be used to identify a device in IPsec and SSL.

· Ordinary key—A TCSM key that is not any of the previously mentioned types.

TCSM certificates

TCSM certificates are digital certificates signed for TCSM keys. The following types of TCSM certificates are available:

· EK certificate—Embedded EK certificate of a TC chip. When the manager signs an AK certificate or DevID certificate for a platform, the platform uses its EK certificate to attest to its identity.

· AK certificate—Certificate signed by the manager for the AK of a platform. A platform uses its AK certificate to attest to its identity in an integrity report.

· DevID certificate—Certificate signed by the manager for the DevID key of a platform.

A digital certificate is an electronic document that binds a public key to the identity of its owner. A digital certificate is signed by a CA. The signature of the CA proves that the certificate is trustworthy. For more information about digital certificates, see "Configuring TC."

Network architecture for TC

As shown in Figure 1, the TC system consists of managers and managed devices (Device A, Device B, and Device C). A manager communicates with managed devices by using NETCONF over SSH.

· Manager—H3C Trusted Platform Module Manager (TPMM), which is software that provides features including device resource management and CA. A TC network can have multiple managers.

For more information about the H3C TPMM, see the online help of the software.

· Managed device—Network devices integrated with TC chips. The manager obtains integrity measurement reference hash values and integrity reports from managed devices and thereby authenticates the integrity of the managed devices.

Figure 1 Network architecture for TC

AK and DevID certificates request and maintenance

You can use the following procedure to request and maintain a local certificate for the AK or DevID key of a platform:

1. On the platform, create an AK or a DevID key, and load the key to the TC chip.

2. On the platform, load the embedded EK to the TC chip.

3. On the platform, configure a certificate subject, which contains the identity information of the platform.

4. On the manager, view the AK or DevID key of the platform and sign an AK certificate or DevID certificate.

During the certificate signing process, the manager uses the EK and EK certificate of the platform to authenticate the identity of the platform.

The signed certificate associates the identify information of the platform with the public key of the platform.

If a private key of the platform is leaked or a certificate is expiring, you can destroy the local certificate and request a new certificate.

Primary key, storage key, and child key

As shown in Figure 2, TCSM keys are managed in a tree structure. The following are the roles of TCSM keys:

· Primary key—Root key. Its key parameters are stored on a TC chip and protected by the chip. This key will be automatically created by using the parameters when you load the key to the TC chip.

· Storage key—Key that has authorization data. A storage key can have child keys.

In Figure 2, keys A through D are all storage keys. Key A is the primary key.

· Child key—A child key is encrypted and stored on a storage medium. You can load it to the TC chip when necessary.

In Figure 2, a parent key and its child keys are in the same color.

Figure 2 TCSM key hierarchy

Endorsement hierarchy and storage hierarchy

The device supports configuring TCSM keys in the following hierarchies:

· Endorsement hierarchy—Used for privacy-sensitive data related operations, for example, platform identity authentication.

· Storage hierarchy—Used to store encrypted user data.

The hierarchies are separate from each other. Each hierarchy can have an unlimited number of primary keys.

Protocols and standards

· Trusted Platform Module Library Family “2.0” Level 00 Revision 01.16

· TCG EK Credential Profile For TPM Family 2.0; Level 0 Specification Version 2.0 Revision 14

· TCG Attestation PTS Protocol: Binding to TNC IF-M Specification Version 1.0 Revision 28

· TCG Infrastructure Working Group Core Integrity Schema Specification Version 2.0 Revision 5

· TCG PC Client Platform TPM Profile (PTP) Specification Family “2.0” Level 00 Revision 00.43

· TSS TAB and Resource Manager Specification Family "2.0" Level 00, Revision 00.91

· TSS System Level API and TPM Command Transmission Interface Specification Family "2.0" Level 00, Revision 01.00

· TCG Software Stack Feature API Family “2.0” Level 00 Revision .12

Restrictions and guidelines: TC configuration

This chapter describes only the configuration tasks on a managed device.

When configuring a TCSM key, follow these guidelines:

· As a best practice, configure an AK in the endorsement hierarchy.

· The manager can sign certificates for AKs and DevID keys only after you load system-defined EKs, for example, default_rsa_ek.

TC tasks at a glance

To configure TC, perform the following tasks:

1. Managing TCSM keys:

a. Creating a TCSM key

b. Loading a TCSM key

c. (Optional.) Unloading a TCSM key

d. (Optional.) Destroying a TCSM key

2. Managing TCSM certificates:

a. Configuring a TCSM certificate subject

b. Signing a TCSM certificate

c. (Optional.) Destroying a TCSM certificate

Prerequisites for TC

Configuring the managed devices as NETCONF over SSH servers

Enable NETCONF over SSH on the managed devices so the manager can use NETCONF over SSH sessions to send configuration information to the managed devices. For more information about NETCONF over SSH, see NETCONF configuration in Network Management and Monitoring Configuration Guide.

Preparing TCSM key templates

A TCSM key template defines the basic parameters used to create a TCSM key, including the key type, key attributes, and relevant algorithms.

A platform can use system-defined key templates or global key templates assigned by the manager. To view available key templates, execute the display tcsm key-template command. System-defined key templates are listed in the System-defined key template files field. Global key templates assigned by the manager are listed in the User-defined key template files field. For information about how to assign global key templates to a device from the manager, see the online help of the H3C TPMM.

Managing TCSM keys

Creating a TCSM key

Restrictions and guidelines

A primary key can have a maximum of four levels of child keys.

Before creating a child key, make sure you have used the key load command to load the parent key to the TC chip.

Procedure

1. Enter system view.

system-view

2. Enter TCSM view.

tcsm

3. Create a TCSM key.

key create name key-name [ authorization authorization-string ] { endorsement | storage | parent-key parent-name [ parent-authorization parent-authorization ] } { preset-template | user-template } template-name [ ak | devid ] slot slot-number

Loading a TCSM key

About this task

You can use a created TCSM key only after you load the key to the TC chip.

Restrictions and guidelines

To load a child key, you must load the parent key first.

Procedure

1. Enter system view.

system-view

2. Enter TCSM view.

tcsm

3. Load a TCSM key to the TC chip.

key load name key-name [ parent-authorization { cipher | simple } parent-authorization ] slot slot-number

Unloading a TCSM key

About this task

Keys use system resources. As a best practice, unload unused keys.

Prerequisites

To unload a TCSM key that has a child key, unload the child key first.

Procedure

1. Enter system view.

system-view

2. Enter TCSM view.

tcsm

3. Unload a TCSM key from the TC chip.

undo key load name key-name slot slot-number

Destroying a TCSM key

About this task

If a private key of a platform is leaked or a certificate is expiring, you can destroy the local key and re-create a key.

Restrictions and guidelines

You can destroy a key successfully only if the following conditions are met:

· You are an administrator or the key creator.

· The key is not loaded to the TC chip.

To unload a key, use the undo key load command.

· The key does not have a child key.

If the key has a child key, you must destroy the child key first.

To identify whether the key has child keys, use the display tcsm key list command.

Procedure

1. Enter system view.

system-view

2. Enter TCSM view.

tcsm

3. Destroy a TCSM key.

key destroy name key-name slot slot-number

Managing TCSM certificates

Configuring a TCSM certificate subject

About this task

A TCSM certificate subject contains the identity information of the platform. CA uses the identity information in TCSM certificate subjects to uniquely identify certificate applicants.

A TCSM certificate subject must contain a common name.

Restrictions and guidelines

The current software version supports only one TCSM certificate subject. To change the name of the TCSM certificate subject after you create the subject, you must delete the subject and then re-create the subject by using the new name.

Procedure

1. Enter system view.

system-view

2. Enter TCSM view.

tcsm

3. Create a TCSM certificate subject and enter its view.

certificate subject subject-name

4. Specify a common name for the TCSM certificate subject.

common-name string

By default, a TCSM certificate subject does not have a common name.

5. (Optional.) Specify a country code for the TCSM certificate subject.

country string

By default, a TCSM certificate subject does not have a country code.

6. (Optional.) Specify a state or province name for the TCSM certificate subject.

state string

By default, a TCSM certificate subject does not have a state or province name.

7. (Optional.) Specify an organization name for the TCSM certificate subject.

organization string

By default, a TCSM certificate subject does not have an organization name.

8. (Optional.) Specify an organization unit name for the TCSM certificate subject.

organization-unit string

By default, a TCSM certificate subject does not have an organization unit name.

9. (Optional.) Specify the additional information for the TCSM certificate subject.

devid-additional-information string

By default, a DevID certificate subject does not have additional information.

Signing a TCSM certificate

Use the H3C TPMM to sign a TCSM certificate for a key of the device. For more information, see the online help of the H3C TPMM.

Destroying a TCSM certificate

About this task

A certificate issued by a CA has a validity period, which is determined by the CA. If a private key of a platform is leaked or a certificate is expiring, you can destroy the local certificate and request a new certificate.

Restrictions and guidelines

System-defined TCSM certificates cannot be destroyed. A user-defined TCSM certificate can be destroyed only by an administrator or its creator.

Procedure

1. Enter system view.

system-view

2. Enter TCSM view.

tcsm

3. Destroy a TCSM certificate.

certificate destroy name certificate-name slot slot-number

Display and maintenance commands for TC

Perform display tasks in any view.

· Display the TCSM certificate list.

display tcsm certificate list [ slot slot-number ]

· Display detailed information about a TCSM certificate.

display tcsm certificate name certificate-name slot slot-number

· Display the TCSM key list.

display tcsm key list [ endorsement | storage ] [ loaded ] [ ak | devid ] [ slot slot-number ]

· Display detailed information about a TCSM key.

display tcsm key name key-name slot slot-number

· Display TCSM key template information.

display tcsm key-template [ { preset | user } template-name ]

· Display PCR values.

display tcsm pcr [ algorithm algorithm ] [ index index ] [ slot slot-number ]

· Display TC chip information.

display tcsm trusted-computing-chip [ slot slot-number ]

TC configuration examples

Example: Requesting a certificate from the manager

Network configuration

As shown in Figure 3, the device is integrated with TC chips and connected to a TC manager.

Configure the device as the NETCONF over SSH server so the TC manager can manage the device.

Create an AK for the device and obtain an AK certificate from the manager so the manager can authenticate the integrity of the device.

Figure 3 Network diagram

Prerequisites

1. Assign IP addresses to the device and manager. Make sure a network connection is available. (Details not shown.)

2. Configure the device as the NETCONF over SSH server:

# Create local user abc and set the password. Assign user role network-admin and service type SSH to the user.

<Device> system-view

[Device] local-user abc

[Device-luser-manage-abc] password simple 123456TESTplat&!

[Device-luser-manage-abc] authorization-attribute user-role network-admin

[Device-luser-manage-abc] service-type ssh

[Device-luser-manage-abc] quit

# Enable the NETCONF over SSH server feature.

[Device] netconf ssh server enable

3. Display summary information about all TCSM key templates.

[Device] display tcsm key-template

System-defined key template files:

default-rsa-sk: rsa storage key

default-rsa-devid: rsa signature key

default-rsa-ak: rsa attestation key

...

In this example, system-defined key template default-rsa-ak will be used to create a key for the device.

Procedure

1. On the device, create and load keys and configure a TCSM certificate subject:

# Enter TCSM view.

[Device] tcsm

# Use system-defined key template default-rsa-ak to create a primary AK named pk1 for the endorsement hierarchy. Set the authorization data to pk1.

[Device-TCSM] key create name pk1 authorization pk1 endorsement preset-template default-rsa-ak ak slot 1

# Load AK pk1 to the TC chip.

[Device-TCSM] key load name pk1 slot 1

# Load system-defined EK default_rsa_ek to the TC chip so the TC manager can sign a certificate for the AK.

[Device-TCSM] key load name default_rsa_ek slot 1

# Create TCSM certificate subject abc and set the common name to device.

[Device-tcsm] certificate subject abc

[Device-tcsm-cert-subject-abc] common-name device

[Device-tcsm-cert-subject-abc] quit

2. On the manager, use EK default_rsa_ek to sign a certificate for the AK of the device (pk1). Name the certificate pk1cert. For more information, see the online help of the H3C TPMM.

Verifying the configuration

# On the device, display detailed information about TCSM certificate pk1cert.

[Device-TCSM] display tcsm certificate name pk1cert

Status: Enabled

Key Name: pk1

User name:

Usage: AK

...

The output shows that the device has obtained an AK certificate.

Configuring PTS

About PTS

Platform Trust Services (PTS) is a feature of the TC solution. This feature is used to verify whether executable program files on a managed device have been tampered with. The manager obtains the integrity measurement reference hash values and integrity reports from the PTS feature on a managed device, and thereby authenticates the integrity of the device. For more information about TC, see "Configuring TC."

Concepts

Platform

The term "platform" in related chapters refers to IRF member devices.

Integrity measurement

Integrity measurement performs the following operations:

1. Uses a hash algorithm (for example, SHA256) to compute a hash value for a program file.

2. Compares the computed hash value with the reference hash value to identify whether the program file has been tampered with.

A program file is trustworthy only if its computed hash value is the same as its reference hash value.

PCR

Platform configuration registers (PCR) are a set of registers on a TC chip used to store the integrity measurements of program files on the platform. For more information about the measurements, see "Configuring PTS."

PCR values can be modified by using the extend operation. The notation of the extend operation is PCRnew = Halg (PCRold || digest), where:

· PCRnew—New PCR value.

· PCRold—Old PCR value.

· Halg—Uses a hash algorithm to compute the hash value.

· ||—String concatenation operation. For example, A || B = AB.

· digest—Hash value to be extended to the PCR.

Integrity report

The device sends an integrity report to the TC manager as its authentication information. The report includes the PCR values, IMLs, AK certificate, and PCR signature. The PCR signature is produced for PCR values by using the AK. For more information about PCR, AKs, and AK certificates, see "Configuring TC."

IML

An integrity measurement log (IML) contains the hash values computed for program files of a type of software.

The device has the following types of software:

· Basic BootWare segment.

· Extended BootWare segment.

· Comware images.

· Runtime.

Figure 4 depicts the integrity measurement operations that occur on types of software during platform startup.

Figure 4 Integrity measurement process during platform startup

During integrity measurement of a type of software, the following operations are performed for each program file:

1. Computes the hash value of the file.

2. Computes the template hash value based on the file hash value, measurement time, and hash algorithm.

3. Writes the two hash values to the IML.

The TC chip of a platform also extends the template hash value of each type of software to the corresponding PCR.

Integrity self-verification

The integrity self-verification feature enables a platform to measure its own integrity in the following aspects:

· Whether a program file has been tempered with—Identifies whether the hash value of the program file in a log entry matches the integrity measurement reference hash value of the program file.

· Whether an IML has been tempered with—Identifies whether the template hash value that is computed by using the file hash values, measurement time, and hash algorithm matches the template hash value in the IML.

· Whether the number of entries in an IML has changed—Identifies whether the PCR values computed by using the template hash value of the type of software match the PCR values of the type of software stored in the TC chip.

Integrity authentication

As shown in Figure 5, a manager authenticates the integrity of a platform by using the integrity measurement reference hash values and integrity report of the platform.

Compared with integrity self-verification, integrity authentication includes the following extra authentication items:

· Examines the AK certificate of the platform to authenticate the identity of the platform.

· Uses the AK certificate of the platform to authenticate the PCR signature, and thereby determines the authenticity of the PCR values of the platform.

Figure 5 Integrity authentication process

Restrictions and guidelines: PTS configuration

PTS is supported only on devices that have TC chips.

Configuring integrity self-verification

Manually performing an integrity self-verification

1. Enter system view.

system-view

2. Enter PTS view.

pts

3. Perform an integrity self-verification.

integrity selfverify [ slot slot-number ]

Configuring periodic integrity self-verification

About this task

When you enable periodic integrity self-verification, the device immediately performs an integrity self-verification. Then, the device performs integrity self-verifications at intervals.

Procedure

1. Enter system view.

system-view

2. Enter PTS view.

pts

3. Enable periodic integrity self-verification.

integrity periodic-selfverify enable

By default, periodic integrity self-verification is disabled.

4. (Optional.) Set the integrity self-verification interval.

integrity periodic-selfverify interval interval

By default, the integrity self-verification interval is 7 days.

The integrity periodic-selfverify enable command starts the integrity self-verification timer. If the specified integrity self-verification interval is equal to or shorter than the time that has elapsed, the device immediately performs an integrity self-verification.

Specifying the AK for integrity reporting

About this task

The platform requires an AK to sign an integrity report.

Restrictions and guidelines

The specified key must meet the following requirements:

· It already exists and is an AK.

You can create a key by using the key create command.

· It is already loaded to the TC chip.

You can load a key to a TC chip by using the key load command.

· It is used by a certificate.

You can verify whether a key is used by a certificate by using the display tcsm key name command.

For more information about the commands, see TC configuration commands in Security Command Reference.

Procedure

1. Enter system view.

system-view

2. Enter PTS view.

pts

3. Specify the AK for integrity reporting.

integrity report attestation-key key-name [ authorization { cipher | simple } authorization-string ] slot slot-number

By default, no AK is specified for integrity reporting.

The key authorization data specified for this command must be the same as the key authorization data used to create the AK.

Display and maintenance commands for PTS

Perform display tasks in any view.

· Display IML information.

display pts integrity measurement-log [ bootware | runtime | package ] [ slot slot-number ]

· Display integrity self-verification information.

display pts integrity selfverify [ slot slot-number ]

12-Security Configuration Guide

Platform

TC chips

TCSM

TCSM keys

TCSM certificates

AK and DevID certificates request and maintenance

Managing TCSM keys

Restrictions and guidelines

Procedure

About this task

Restrictions and guidelines

Procedure

Unloading a TCSM key

About this task

Prerequisites

Procedure

Destroying a TCSM key

About this task

Restrictions and guidelines

Procedure

Managing TCSM certificates

About this task

Restrictions and guidelines

Procedure

Signing a TCSM certificate

Destroying a TCSM certificate

About this task

Restrictions and guidelines

Procedure

Network configuration

Prerequisites

Procedure

Platform

Integrity measurement

PCR

Integrity report

Configuring integrity self-verification

About this task

Procedure

About this task

Restrictions and guidelines

Procedure

Intelligent Terminal Products

Product Support Services

Technical Service Solutions

Resource Center

Policy

Online Help

Become a Partner

Partner Policy & Program

Global Learning

Partner Sales Resources

Service Business

News & Events

Contact Us