Huawei launches trusted computing project for ARM servers

Introduction

The Kunpeng Security Libraries (KunpengSecL) open-source project provides basic security software components running on Huawei’s Kunpeng ARM processors used in the TaiShan server family. The project currently focuses on trusted computing capabilities such as remote attestation to empower security developers in the community.

Overview

Each feature of the KunpengSecL will consist of components and services. A component is deployed on a server node that provides resources (computing, storage, and network) for users to run workloads. It converts platform security and trust capabilities into software interfaces and provides them for services. A service is deployed on a dedicated management server node, aggregates the security and trust capabilities from all worker server nodes, and provides them to users and their designated management tools to meet the user’s specific requirements for system security and trustworthiness design.

Remote Attestation

The first security feature of the KunpengSecL is remote attestation. The purpose is to help users obtain trust status reports on the software and hardware in worker server nodes and to support the end-to-end remote attestation solution. Resource management tools can formulate policies based on trust status reports in order to schedule and to use server resources in a differentiated manner.

The remote attestation feature of the KunpengSecL builds on the mature TPM root of trust and it supports complex deployment environments and multi-layer scalability.

The remote attestation service (RA Service or RAS) and remote attestation client (RA Client or RAC) in the remote attestation architecture correspond to the services and components in the general definition of the KunpengSecL.

The remote attestation feature of the KunpengSecL intends to support the following scenarios:

1. Server scenario: The administrator sends a request to the RAS to query the trust status of a worker server. The RAS attests the worker server with the RAC and returns the trust status of the worker server. This scenario has been fully implemented.
2. Container scenario: The administrator sends a request to the RAS to query the trust status of a container. The RAS attests the worker server with the RAC and returns the trust status of the container. This scenario has been partially implemented, and the full implementation will rely on the availability of IMA namespace feature.
3. PCIe device scenario: The administrator sends a request to the RAS to query the trust status of a PCIe device. The RAS attests the worker server with the RAC and returns the trust status of the PCIe device. This scenario is in early design stage.

The remote attestation service (RAS):

• provisions the remote attestation key certificate for the TPM on the worker server through the PrivacyCA,
• manages the trust related data of the worker server through the TrustMgr,
• receives trust status reports from the worker server through the ClientAPI,
• verifies the trust status of the target through the Verifier,
• provides the trust status cache service through the Cache,
• manages configuration information such as policies through the Config and
• provides remote attestation services for users through the RestAPI.

The remote attestation client (RAC):

• uses the Trusted Boot provisioning tool (TBProvisioner) to detect and enable the measured boot capability of the platform in the deployment phase,
• uses the RAC Tools to obtain required data from the RAS and
• uses the RA Agent to communicate with the RAS to complete the registration and to send trust status reports.

The RAC Tools abstracts the details of the interaction with trusted modules and the worker server system, and assumes the responsibility of supporting other trusted modules in the future.

The RA Hub is responsible for the communication convergence and proxy role for the local RAC when required. In addition, the RA Hub will provide the capability of adapting the communication channel between the RAC and the RAS in the future.

Advantages of KunpengSecL

1. Uses heartbeat handling flow to help target server piggy-back action request from the RAS, in order to avoid opening new communication ports in the target worker server, thus reducing the attack surface.

2. Uses policies in the RAS to support automatic extraction of reference measurements and automatic update of the reference measurements for upgrading a target worker server.

3. Deploys the RAHub to enable client aggregation (cascading) in the case that some RACs in a network are not able to reach the RAS due to network isolation or communication channel restrictions.

Next steps

In the next few years, the KunpengSecL will:

• fully expand its scalability to support:
• additional RoTs and trusted modules such as TCM, TPCM, and DICE,
• complex infrastructures such as VMs, secure containers, TEEs,
• different management channels such as BMC and edge management engines,
• gradually integrate with typical applications such as OpenStack, K8S, and SIEM,
• bring the trusted computing features of the platform to developers and users in an easy-to-use manner.

Community

Developers and end users are welcome to actively participate in the open source development of the KunpengSecL from design to development. For more ideas, please access https://gitee.com/openeuler/kunpengsecl/issues and leave your valuable comments there or submit issues.

Project details

• Repository: https://gitee.com/openeuler/kunpengsecl – (click “English” at the bottom right of the page)
• License: Mulan Permissive Software License v2 (MulanPSL – 2.0)
• Main programming language: Go
• Contact person: Wei Gang (Jimmy): weigang12@huawei.com