This is part two of a series. Read part one here. 

At a Sensors Expo 2018 workshop in San Jose, CA, with Embedded Computing Design, Trusted Computing Group (TCG) work group members presented information about TCG’s Trusted Platform Module (TPM) for network security, the DICE lightweight root of trust and the Trusted Software Stack (TSS 2.0). Based on the presentations, a three-part series has been developed to cover those topics. Part one discussed the TPM for Network Security. This second installment addresses the Trusted Software Stack.

Antivirus programs, firewalls, compliance management, secure communications protocols and other approaches provide top-down security. Top-down security is launched later in the boot cycle of a machine and it largely is concerned with sealing the system’s external attack surface (keeping bad things out and keeping secrets in). If only top-down security techniques are used, the lower, most critical layers of software are often left vulnerable to attack.

TCG’s hardware/firmware/software approach provides a complete bottom-up defense for all layers that can close this vulnerability. Figure 1 shows the how top-down and bottom-up defenses combine to provide “defense in depth.”

Trusted computing-enabled firmware builds upon a “transitive trust chain” and establishes system measurements from the first instruction run on a system during boot using a Core Root of Trust for Measurement (CRTM). The CRTM launches the bottom-up security necessary to achieve defense-in-depth and secure all computing devices – including networked sensors.

Boot firmware, operating systems (including real-time operating systems (RTOS)) and trusted applications place comprehensive code measurements in the TPM’s Programmable Configurations Registers (PCRs) to build their transitive trust chains. These measurements, which are within the TPM and cannot be altered by malicious code, are widely used by functions in the TPM. 

Using TSS 2.0 as a powerful and convenient TPM software service, here are a few of the major features available using TPM PCRs:

• Authorization of a wide variety of TPM operations either by themselves or in conjunction with other types of authorization to achieve multi-factor authentication
• Sealing of system secrets (keys, etc.) to protect them from revelation to potentially malicious software
• Attestation of the security health of a system
  Note: Attestation using a TPM allows a system’s code measurements to be reliably checked.  Malicious firmware cannot alter or impersonate a TPM-based attestation since it cannot see the TPM resident/secret attestation keys needed to sign digests of PCRs for attestation.

The TPM also has all the functions of a traditional hardware security module (HSM) or smartcard. PKCS#11 software interfacing with the TPM 2.0 using TSS 2.0 provides all the functions traditionally provided with those devices.  This makes a number of applications which use HSMs and smartcards easily portable to systems with TPM 2.0.

TPM 2.0 is an International Organization for Standardization (ISO) standard. It is the international standard for building hardware-based roots of trust. World Trade Organization (WTO) members are not allowed to put import/export controls on an ISO standardized security device. This facilitates the ability to ship devices worldwide without the specter of them being blocked from entry to markets because of trade barriers intended to regulate TPM and other hardware secure modules.  It already is or will be specified as a required item in Requests for Proposal (RFPs) from governments, critical infrastructure and other security-compliance-aware projects, including those with sensors.

TSS 2.0

TCG’s TSS 2.0 is the standard application programming interface (API) for using the TPM. With TSS 2.0’s cross platform support, users can easily move security applications across platforms.

It should be noted that some suppliers use the term “TSS” to describe their proprietary or non-standard TPM software.  In many cases, RFP requirements from governments and security-conscious industries do/will specifically identify the TCG TSS 2.0 as required to satisfy and RFP response. Using TSS 2.0 increases confidence in the added security for organizations in these sectors as they know it has been developed by TCG and vetted by TCG’s security experts. TCG TSS 2.0 specifications are available on the TCG website.

Security programmers also obtain key services for TPMs with TSS 2.0:

• Marshalling/unmarshalling services needed when communicating with a TPM
• Multiple TPM applications can use the same TPM without interference
• Encryption of the data stream from the software to the TPM, which stops side-channel (hardware probing) attacks.
  Note: This is necessary for Common Criteria EAL 4+ certification, which is required by many customers
• Simplification of context and session management needed for applications that work with TPMs

TSS 2.0 also provides:

• Synchronous and asynchronous function call models for communicating with the TPM
• A layered software model that allows varying levels of abstraction (depending on the TSS layer used), simplifying the task of using the TPM
  Note: The layered software model also provides scalable solutions for different code footprints, from the smallest Internet of Things (IoT) device, such as a sensor node, up to server applications

The layers of the TSS 2.0 software model are shown in Figure 2.

The TSS 2.0 layers perform the following functions:

• The device driver manages the electronic bus communicating with the TPM device. TPM Device Drivers are available today in Linux and Windows. Other OSs and RTOSs may need a modified or custom driver.
• The Tab and Resource Manager allows multiple applications and the kernel to share TPM resources. This code and the device driver are the two pieces of the TSS 2.0 software stack that are operating system-specific.
• The TPM Command Transmission Interface (TCTI) allows development programmers to target TPMs other than the hardware TPM on a platform (e.g., soft TPMs). This is a very convenient feature for debugging TPM software and allows the implementation of remote TPMs.
• The System API (SAPI) is the lowest level (least abstracted) way to interface with the TPM.  It does not need a file system or a heap. It can be integrated with boot firmware or used in the smallest IoT devices.
• The Enhanced System API (ESAPI) has easier context management and provides the ability to encrypt the data stream to the TPM, stopping side-channel attacks (essential to EAL4+).
• The Feature API (FAPI) provides new ease of use not available for TSS 1.2. It allows programmers to interface to the TPM without having to be TPM experts.

The TSS 2.0 API adheres to industry-recognized best software practices utilizing clean programming techniques. This allows programmers (including the programmer who originally wrote the code) to go back and easily read, understand and modify applications using TSS 2.0.  This is a very important factor when you consider that your code must be understood, maintained, tested and possibly certified by a variety of programmers over a product’s often lengthy lifecycle.

The clean programming techniques in TSS 2.0 are comprised of:

• No function overloading – ensuring high semantic content
• Strong type checking – no variadic (variable number of arguments) variables
• No global variables
• Meaningful variable names and function names that humans can understand

The TSS 2.0 API also provides strong code versioning and revision control. This ensures that the details of code behavioral changes for each release can be identified. Barring a version change, backwards code compatibility is maintained.

Additional Compliance

The TSS 2.0 API’s design characteristics include compliance with the Motor Industry Software Reliability Association (MISRA). This is essential for software safety compliance in the world of the industrial IoT, automotive and market segments where safety is a key concern. However, the underlying TSS 2.0 implementation may or may not be MISA compliant, so it is necessary to check with the TSS 2.0 supplier to understand whether MISRA-compliance is extended beyond the TSS 2.0 API into the actual TSS implementation (Note: The OnBoard Security TSS 2.0 is MISRA compliant).

For more information from TCG TSS 2.0 suppliers, go to:

• OnBoard Security’s TSS 2.0 link in the TCG Developers Community https://develop.trustedcomputinggroup.org/2018/03/20/onboard-security-trustsentinel-tss-2-0/  
• GitHub https://github.com/tpm2-software/tpm2-tss/releases

The third and final part of this three-part article will address TCG’s Device Identifier Composition Engine (DICE) lightweight root of trust, applicable to systems and components (including sensors and others) with or without a TPM.

Click here to read part three.