Jump to: navigation, search

Hawthorn

Revision as of 12:44, 24 June 2019 by Chengfeiyoiua (talk | contribs)

Hawthorn is to providing a general unified trusted management framework for different trusted modules (such as TPM, TCM, etc.) in OpenStack.

Motivation

As we all know, security is always a hot topic in the industry. Especially, cloud security begins with credibility and visibility enabled by hardware and delivered by the infrastructure. In OpenStack, if an attacker make a system untrustworthy by tampering with BIOS/ROM monitor boot code to load modified software images, it will make a risk for entire infrastructure and affect customers confidence to deploy workloads on it.

Trusted computing is a security technology that can establish trusted cloud infrastructure based on trusted modules. The risks and threats on cloud can be mitigated and managed, which can make customer more confident when utilizing OpenStack. In recent years, more and more vendors start providing cloud security solution based on trusted computing technology.

However, there are some mainstream trusted modules supported by national standards (e.g. TPM, TCM) and some special trusted modules provided by vendors(e.g. Titan, TAM) in the industry, which causes huge development costs and interoperability issues for developers to support various trust modules.

To resolve above problem, we want to have the same management plane for various trusted modules in OpenStack.

Use Cases

A set of simple use cases are proposed here to help you understand the application scenarios of trusted computing technology. Further proving it is necessary to to provide a unified trusted management framework to accelerate development and utilization of trusted computing technology. These use cases should meet the following requirements:

  • Developers are free to choose any of various trust formats
  • Exchange information in a trusted context
  • Assess and enforce trusted policy
  • Trusted policy can be updated according to the environment

Scenario 1: Cloud computing

Use case 1: Trust computing pools

Enterprises and CSPs are creating private and public clouds which contain thousands of compute nodes across different regions. To ensure the trustworthy of the running environment, cloud tenants would like their workloads to be deployed and launched on the trusted compute nodes.

The trust computing technology supports Trusted Boot and Remote Attestation, and it can inform cloud tenants of the compute nodes being trusted for hosting their workloads. When requesting a virtual machine from the OpenStack dashboard, administrators or the application owner can specify that workloads only be executed on trusted hosts in accordance with cloud tenants’ policy requirements.

Use case 2: Workload integrity and confidentiality

Critical concerns for cloud tenants are protecting workloads in cloud. However, tenants will lose full control of their workloads in the cloud computing environment, so stopping the chain of trust at the bare hypervisor is clearly insufficient. Building on the foundation of trusted compute pools, the concept of trusted workloads should extends the chain of trust in the cloud computing environment to cover guest workloads.

Cloud tenants can protect the confidentiality and integrity of the workloads in transit, at rest, and up to execution by using the trust computing technology. The trusted workloads can bind decryption keys to the trust format on a server that has demonstrated integrity. This ensures that the workload is decrypted only inside the trusted server and not anywhere else.

Scenario 2: Internet of things

Use case 1: Establishing and protecting device identity

Almost all IoT scenarios require reliable authentication of the devices in use, but unfortunately the Internet does not provide reliable endpoint authentication, so devices must identify themselves instead.

The trust computing technology provides symmetric-key encryption, HMAC, and asymmetric cryptography capabilities to protect cryptographic device identities that are robust when facing malware attack.

Use case 2: Detecting malware infections

IoT devices should be able to resist malware infections, both volatile and persistent. In general, the detection and remediation of malware is a hard problem because malware seeks equivalent or higher privilege than the systems that are seeking to detect and isolate it.

The trust computing technology supports Trusted Boot and Remote Attestation, which can even detect changes to BIOS or other firmware.

Use case 3: Protecting computation from tampering

Malware frequently uses two techniques to insert itself into a target platform. One is modifying code in memory , other is modifying files.

The trust computing technology produces a digitally signed report of those hash measurements of important files and data at any time to any entity. An external entity accesses to the benchmark measurements that compares those signed report and determine whether code on the device in question has changed or not.

Scenario 3: Mobile device

Use case 1: Protecting mobile banking

As society becomes more cashless, the likelihood that more end users carry mobile devices than old fashioned cash is increasing. Banking also tends to be a more frequent activity, with growing demand for anytime and anywhere convenience. However, The banking application may be attacked to allow an unauthorized transaction. For example, Over-the-air personalisation can be intercepted to duplicate an account in other devices or by other media ; Confidential information about an account is leaked during transmission .

Trust computing technology can enforce platform integrity so that it can help prevent software attacks on the relevant functionality blocks. As a result, the protocols and functions are forced to be executed in the way that was intended. This can be used to counter a number of the aforementioned threats.

Use case 2: Protecting mobile payment

Security is one of the fundamental elements of any mobile payment solution, as is usability. A payment may consist of an account of a credit card, a debt card, or a pre-paid cash portal, a representation of which is stored on the mobile device. However, The payment application can be modified so as to act as a “back door” for non-payment related attacks on the device.

Trust computing technology can be used to measure the authenticity and integrity of the payment application which counters threat .

Scenario 4: Network equipment

Use case 1: Securing secrets

Network equipment often contains sensitive information such as traffic logs or cryptographic keys (e.g., shared secrets, passwords, VPN keys, SSL keys, and stored data encryption keys). Disclosure of these secrets could result in disclosure of confidential network traffic and privacy-sensitive information or even enable malicious tampering through the network.

Network operators (especially Service Providers and Enterprises) can protect these secrets against disclosure by the trust computing technology to keep their networks secure and reliable, and also to meet regulatory or customer requirements for confidentiality and privacy.

Use case 2: Protection of configuration data

Network Equipment usually requires configuration, often involving many parameters stored in a variety of files. The equipment Owner may wish to retain control over changes to configuration files on the equipment, with the goal of ensuring that unauthorized configuration changes don’t compromise their network.

The trust computing technology can encrypt and sign configuration files so each file can only be used on the intended device, and the device will only accept configuration from the authorized Owner.

Use case 3: Attestation of integrity for network devices

One extension to remote device management enabled by trust computing technology is an ability to monitor the authenticity of software versions and configurations running on each device. This allows owners and auditors to detect deviation from approved software and firmware versions and configurations, potentially identifying infected devices.

Architecture

Hawthorn Architecture 0.0

Resources