AMI has announced support for TPM on Arm®-based systems running AMI’s flagship Aptio® V UEFI Firmware. […] Previously, AMI only provided TPM support for x86 platforms. With the growing need to extend TPM support for additional platforms, AMI has added TPM support for Arm-based systems currently running AMI’s Aptio® V UEFI firmware. The added TPM support for Arm-based systems includes features specifically for the Arm architecture such as TPM driver support within Arm® TrustZone® technology and Linux OS support. The Arm TrustZone TPM Firmware can be accessed by the BIOS and OS via the Command Response Buffer interface using Secure Monitor calls. Other generic features supported by TPM include cryptographic algorithms and measurement of SecureBoot variables.[…]
“Firewalls and gateway routers are already important components of any organization’s network security strategy. But network architects can often overlook the fact that the networking equipment itself can be attacked. Ensuring these devices are resistant to attacks is just as important as conventional security mechanisms that protect PCs and servers.”
Establishing Network Equipment Security
TCG Guidance for Securing Network Equipment Preview Synopsis
I just noticed there’s a new file on the list of ACPI specs, a 1.0 doc from TCG on D-RTM from mid-June:
TCG D-RTM Architecture
Document Version 1.0.0
June 17, 2013
This specification describes the architecture and implementation examples for a Dynamic Root of Trust for Measurement (D-RTM) used for measured platform initialization without a hardware platform restart. This specification extends the TCG PC Client specification (See (1)). The term “dynamic” is used because the measured platform initialization may occur while the hardware platform is running. In contrast, the Static Root of Trust for Measurement (S-RTM) requires a platform shutdown or restart.
I wish there was an ACPI-announce list, or even a Twitter feed, to keep track of new ACPI specs…
Excerpting the recent TCG announcement:
BSSSD: Trusted Computing now available for FreeBSD and OpenBSD: All pieces to utilize Trusted Computing and build Trusted Computing applications on FreeBSD and OpenBSD have been made available by the BSSSD-project.
* TPM device driver for the FreeBSD-kernel
* TPM device driver for the OpenBSD-kernel
* TCG Software Stack TrouSerS
* TrustedGRUB boot-loader
Kernel drivers were developed for the following TPMs:
* Atmel 97SC3203
* Broadcom BCM0102
* Infineon IFX SLB 9635 TT 1.2
* Intel INTC0102
* Sinosun SNS SSX35
* STM ST19WP18
* Winbond WEC WPCT200
The Trusted Computing Group (TCG) has released revisions to multiple specifications:
I wish I knew why WordPress inserts the additional whitespace in these posts…. 😦
PC Client Specific Platform Firmware Profile Specification, Family 2.0, Level 00 Revision 00.21 and Errata
The PC Client Platform Specific Profile for TPM 2.0 systems defines the requirements for platform firmware to initialize and interact with a TPM 2.0 device in a PC Client platform. This specification should be used in conjunction with the TCG UEFI Protocol Specification Family 2.0, the TCG Physical Presence Interface Specification, and the TCG ACPI Specification to design and implement a PC Client TPM 2.0-enabled platform. This specification replaces the requirements defined in the PC Client Implementation Specification for Conventional BIOS and the PC Client UEFI Platform Specification for systems with TPM 2.0 devices.
PC Client Work Group EFI Protocol Specification, Family 2.0, Level 00, Revision 00.13
The purpose of this document is to define a standard interface to the TPM on an UEFI platform. It defines data structures and APIs that allow an OS to interact with UEFI firmware to query information important in an early OS boot stage. Such information include: is a TPM present, which PCR banks are active, change active PCR banks, obtain the TCG boot log, extend hashes to PCRs, and append events to the TCG boot log.The latest revision of this specification is written with platforms with TPM 2.0 devices in mind, but nothing in this specification prevents the use with platforms with TPM 1.2 devices.
TCG Storage Opal Test Cases Specification, Version 2.00 Errata Version 1.00, Revision 1.00
The Opal Test Cases Specification contains a set of tests that are intended to verify the correct behavior of a storage device implementing the Opal SSC Specification. These test cases are intended to be used as a basis for the compliance component of the projected Storage certification program, which would seek to ensure a high level of interoperability of storage devices from multiple vendors.
Multiple Stakeholder Model , Revision 3.40
The Multiple Stakeholder Model (MSM) is an informative reference document that describes use cases, recommended capabilities, and various implementation alternatives to allow multiple stakeholders to coexist safely on a mobile platform. This document includes guidance on how to leverage TCG specifications to realize each alternative. In particular, this document emphasizes the role of the Trusted Platform Module (TPM), the Mobile Common Profile, and the Mobile Reference Architecture specifications to support these capabilities for multiple stakeholders. The goal of the MSM is to provide trusted services, for example, TPM and Trusted Network Communications (TNC), in a secure and efficient manner to all interested stakeholders (both local and remote) for a given mobile device. This guidance is applicable to all mobile devices (smartphones, feature phones, basic phones, etc.) and may be useful for other computing devices. The target audience for this document includes designers, manufacturers, system integrators, application developers, and implementers of Trusted Computing technologies in mobile platforms.
TNC IF-M Segmentation Specification Version 1.0, Revision 5
The Trusted Network Communications (TNC) Work Group defines an open solution architecture that enables network operators to evaluate and enforce policies regarding endpoint integrity when granting access to a network infrastructure. As TCG’s Trusted Network Communications (TNC)-enabled technology is deployed in real-world environments, we’re learning that deplorer’s have the need to collect robust posture information to support endpoint compliance, security automation, and continuous monitoring. IF-M is the communication layer of the TNC architecture used to connect the endpoint components that collect information about the endpoint, and the corresponding components on a policy server that receive that information and act on it. IF-M is designed to be flexible to support communication of virtually any type of information about the endpoint that the enterprise might wish to know.
Eric Dong of Intel has updated UEFI’s TCG OVAL support, used with SEDs, how the UEFI-based system will work with the locked SEDs, when the user has no valid password:
[Patch] SecurityPkg OpalPasswordDxe: Enhance input password process.
Enhance the input password process, when device in unlock status and user press ESC, shutdown the device. If user reach the max try number, shutdown the device.
+ L”Confirm: Not unlock device and continue boot?.”,
+ L”Press ENTER to confirm, Press Esc to input password”,
+ L”Warning: system in unkown status, must shutdown!”,
+ L”Press ENTER to shutdown.”,
– L”Opal password retry count is expired. Keep lock and continue boot.”,
+ L”Opal password retry count exceeds the limit. Must shutdown!”,
L”Press ENTER to continue”,
For more information, see the patch on the edk2-devel list:
Rafael Antognolli of Intel posted a patch to the Linux-(NVMe,Block,Kernel) mailing lists, adding TCG OPAL unlock support to NVMe:
Add Opal unlock support to NVMe. This patch series implement a small set of the Opal protocol for self encrypting devices. It’s implemented only what is needed for saving a password and unlocking a given “locking range”. The password is saved on the driver and replayed back to the device on resume from suspend to RAM. It is specifically supporting the single user mode. It is not planned to implement the full Opal protocol (at least not for now).
Add optane OPAL unlocking code. This code is used to unlock a device during resume from “suspend to RAM”. It allows the userspace to set a key for a locking range. This key is stored in the module memory, and will be replayed later (using the OPAL protocol, through the NVMe driver) to unlock the locking range. The nvme_opal_unlock() will search through the list of saved devices + locking_range + namespaces + keys and check if it is a match for this namespace. For every match, it adds an “unlocking job” to a list, and after this, these jobs are “consumed” by running the respective OPAL “unlock range” commands (from the OPAL spec):
* SET(locking range, readwrite)
NVMe: Add ioctls to save and unlock an Opal locking range. Two ioctls are added to the NVMe namespace: NVME_IOCTL_SAVE_OPAL_KEY and NVME_IOCTL_UNLOCK_OPAL. These ioctls map directly to the respective nvme_opal_register() and nvme_opal_unlock() functions. Additionally, nvme_opal_unlock() is called upon nvme_revalidate_disk, so it will try to unlock a locking range (if a password for it is saved) during PM resume.
For more information, see the post on the list archives:
Eric Dong of Intel has submitted an 8-part patch to enable TCG OPAL password support in UEFI:
Enable Opal password solution: These patches used to enable opal password solution in BIOS. Opal feature defined in TCG storage Opal spec. This opal solution is a sample driver shows how to use opal feature in bios. It enables user to config opal feature in the setup page and popup dialog to let user unlock device in boot phase. It auto unlock opal device in S3 resume phase.
MdePkg: Add definition for TCG Storage Core and Opal specs.
SecurityPkg: TcgStorageCoreLib: Add TCG storage core library.
SecurityPkg: TcgStorageOpalLib: Add TCG storage opal library.
SecurityPkg: OpalPasswordSupportLib: Add Opal password support
SecurityPkg: Add library header file definition to package.
SecurityPkg: OpalPasswordDxe: Add Opal password dxe driver.
SecurityPkg: OpalPasswordSmm: Add Opal password Smm driver.
SecurityPkg: Enable Opal password solution build in Security package
39 files changed, 21524 insertions(+)
For more information:
Stefan Thom (Microsoft), Steve Hanna (Infineon), and Stacy Cannady (Cisco) have an article in Electronic Design on TPM use in embedded systems. If you are new to TPM, this is a nice introduction.
Standardizing Trust for Embedded Systems
It’s time to get more serious about the lack of security in embedded products. With recently developed standards, it’s implementation just got easier. If you haven’t been concerned about malicious players hacking into your products in the past, or haven’t found success with previous efforts, it’s time for renewed attention and action. Hacking efforts aren’t slowing and, in fact, are on the rise. These days, hackers can accomplish far more than ever before—and the repercussions are far more costly. […]
The Intel Quark support in the UEFI Forum’s public EDK-II has been updated to support Trustworthy Computing Group’s TPM-based Measured Boot. For more information, see the patch thread on the edk2-devel mailing list.
QuarkPlatformPkg: Add MEASURED_BOOT_ENABLE feature
Add MEASURED_BOOT_ENABLE flag
Add TPM_12_HARDWARE flag
Add TrEEConfigPei to detect TPM 1.2 hardware device
Use Tpm12DeviceLib instance for Atmel I2C TPM
Use Tpm12DeviceLib instance for Infineon I2C TPM
Add TcgPei and TcgDxe modules for TPM 1.2 support
Clean up TpmMeasurementLib mappings
BIOS was designed in the era of the initial IBM PC, running IBM PC-DOS — when DOS meant Disk Operating System not Denial of Service — back when there was no security in any hardware, firmware, or software designs. 🙂 As UEFI documentation likes to mention, BIOS has no security, unlike UEFI (well, at least v2, EFI v1 had much less security). But SeaBIOS, the open source BIOS implementation, has had TPMv1 support for BIOS (and ACPI) since 2011, and today it just got TPMv2 support! It appears that initial TPMv1 support was added to SeaBIOS in 2011 by Stefan Berger of IBM, including TPM support for ACPI; excerpt from his patch email:
The following set of patches add TPM and Trusted Computing support to SeaBIOS. In particular the patches add:
– a TPM driver for the Qemu’s TPM TIS emulation (not yet in Qemu git)
– ACPI support for the TPM device (SSDT table)
– ACPI support for measurement logging (TCPA table)
– Support for initialzation of the TPM
– Support for the TCG BIOS extensions (1ah handler [ah = 0xbb]) (used by trusted grub; http://trousers.sourceforge.net/grub.html)
– Static Root of Trusted for Measurement (SRTM) support
– Support for S3 resume (sends command to TPM upon resume)
– TPM-specific menu for controlling aspects of the TPM
– [An optional test suite for the TIS interface]
All implementations necessarily follow specifications.
When all patches are applied the following services are available
– SSDT ACPI table for TPM support
– initialization of the TPM upon VM start and S3 resume
– Static root of trust for measurements (SRTM) that measures (some) data of SeaBIOS in TCPA ACPI table
– 1ah interrupt handler offering APIs for measuring and sending commands to the TPM (trusted grub uses them)
– User menu for controlling aspects of the state of the TPM
Steven has an article on the QEMU wiki on SeaBIOS TPMv1 support. And Stephan has a SeaBIOS-TPM project on Github, I’m unclear how this relates to SeaBIOS source tree:
So, that was the old 2011 TPMv1 news, that I am catching up to…. Today, Stephan has a new TPM2 patch for SeaBIOS, excerpt of announcement:
This series of patches adds TPM 2 support to SeaBIOS in the way previously proposed. TPM 2 support also changes the log entry format, which I have not addressed at all so far, and would append to the end of the series.
tpm: Extend TPM TIS with TPM 2 support.
tpm: Factor out tpm_extend
tpm: Prepare code for TPM 2 functions
tpm: Implement tpm2_startup and tpm2_s3_resume
tpm: Implement tpm2_set_timeouts
tpm: Implement tpm2_prepboot
tpm: Implement tpm2_extend
tpm: Implement tpm2_menu
tpm: Implement TPM 2’s set_failure
Also search the recent checkins for other interesting TPM checkins, eg, Physical Presence API, etc.
I asked on the SeaBIOS list if there was a security roadmap for me to point to, and what consumer devices have TPM support; Kevin O’Connor replied, mentioning the addition of TPMv2, and:
I’m not aware of any new consumer devices shipping with the support, and I understand that KVM/QEMU have had TPM support for some time already.
I think some Google Chromebooks come with coreboot-based TPM-enabled SeaBIOS, and TPM is used to store developer mode state instead of CMOS. I haven’t found canon spec in ChromeOS site, but there are a few online references such as this:
I’m not aware of any new consumer devices shipping with the support. If you have a new system, check with the vendor to see if it supports TPM or not. If your BIOS is not SeaBIOS-based, check if it has TPM support; if not, ask the vendor why not.
It would be interesting for a security researcher to compare the BIOS security measures in currently-available consumer devices, SeaBIOS-based and other BIOS codebases. I am not sure how many different BIOS codebases there are, these days. Perhaps AMI and Phoenix have one, and some OEMs? I should research that more. Ralph Brown: help! 🙂
The Trustworthy Computing Group has a new blog post, talking about IoT security, specifically about Industrial IoT Security Working Group involvement.
TPM is now an ISO standard.
Hurray, now I get to pay to access them from ISO. 🙂
TCG’s current specs are for members-only, not the public.
I hope TCG keeps the public specs on their site freely-available.
From the TrustedComputingGroup.org’s newsletter, here’s a list of the most recently published TCG specs/docs. Usually it’s only a few documents, this time it’s a pretty large list:
Guidance for Securing IoT Using TCG Technology
This document describes typical IoT security use cases and provides guidance for applying TCG technology to those use cases. Because IoT devices vary widely in their cost, usage, and capabilities, there is no one-size-fits-all solution to IoT security. The practical security requirements for different devices and 71 systems will vary. Therefore, this list of solutions should be regarded as a menu from which the implementer can pick the options most suitable for their product or service.
Physical Presence Interface Specification Version 1.30, Revision 00.52
The Physical Presence Interface utilizes the industry-standard Advanced Configuration and Power Interface (ACPI) to provide a communication mechanism between the OS and the BIOS, enabling the OS and the BIOS to cooperate to provide a simple and straightforward platform user experience for administering the TPM without sacrificing security.
Errata Version 1.3 for Trusted Platform Module Library Specification, Family “2.0”, Level 00, Revision 01.16
This document describes errata and clarifications for the TCG Trusted Platform Module Library Version 2.0 Revision 1.16 as published.
TPM Keys for Platform Identity for TPM 1.2
This specification addresses ways to incorporate TPM created keys into solutions for device identities. It addresses how the resulting device identities interface with and are represented within an existing public key infrastructure. This specification uses the IEEE Standard for Local and Metropolitan Area Networks, Secure Device Identity (802.1AR)  device identity module definition and formatting.
TNC SWID Message and Attributes for IF-M Specification, Version 1.0, Revision 29
The Trusted Network Communications (TNC) Work Group defines an open solution architecture that enables network operators to enforce policies regarding endpoint integrity when granting access to a network infrastructure. Software Identification tags (SWID tags) are XML documents that identify a specific software product.
Storage Interface Interactions Specification. Version 1.04. Revision 1.00
The TCG Storage specifications are intended to provide a comprehensive command architecture for putting storage devices under policy control as determined by the trusted platform host, the capabilities of the storage device to conform with the policies of the trusted platform, and the lifecycle state of the storage device as a trusted peripheral (TPer).
Storage Security Subsystem Class: Enterprise, Version 1.01, Revision 1.00
The Storage Workgroup specifications are intended to provide a comprehensive architecture for putting storage devices under policy control as determined by the trusted platform host, the capabilities of the storage device to conform with the policies of the trusted platform, and the lifecycle state of the storage device as a Trusted Peripheral.
Storage Security Subsystem Class: Opal, Version 2.01 Revision 1.00
This specification defines the Opal Security Subsystem Class (SSC). Any SD that claims OPAL SSC compatibility SHALL conform to this specification.
Storage Enterprise Feature Set: PSK Secure Messaging, Version 1.00, Revision 1.00
This specification defines PSK Secure Messaging for the Enterprise Security Subsystem Class (SSC). Any Storage Device that claims Enterprise SSC PSK Secure Messaging compatibility SHALL conform to this specification.
Storage Opal SSC Feature Set: PSK Secure Messaging, Version 1.00, Revision 1.00
This specification defines PSK Secure Messaging for the Opal Security Subsystem Class (SSC). Any Storage Device that claims Opal SSC PSK Secure Messaging compatibility SHALL conform to this specification.
Storage Feature Set: Block SID Authentication, Version 1.00 Final, Revision 1.00
This specification defines the Block SID Authentication Feature. Any Storage Device that claims Block SID Authentication compatibility SHALL conform to this specification.
Storage Opal SSC Feature Set: PSID Version 1.00, Revision 1.00
This specification defines the PSID Feature Set for the Opal Security Subsystem Class (SSC). Any Storage Device that claims Opal SSC PSID Feature Set compatibility SHALL conform to this specification.
Storage Security Subsystem Class: Pyrite, Version 1.00 Final, Revision 1.00
This specification defines the Pyrite Security Subsystem Class (SSC). Any SD that claims Pyrite SSC compatibility SHALL conform to this specification. The intended audience for this specification is both trusted Storage Device manufacturers and developers that want to use these Storage Devices in their systems.
Storage Opal SSC Feature Set: Single User Mode Specification, Version 1.00, Revision 2.00
This specification defines the Single User Mode for the Opal Security Subsystem Class (SSC). Any Storage Device that claims Opal SSC Single User Mode compatibility SHALL conform to this specification.
Storage Security Subsystem Class: Opalite Version 1.00 Revision 1.00
This specification defines the Opalite Security Subsystem Class (SSC). Any SD that claims Opalite SSC compatibility SHALL conform to this specification.
TCG’s monthly newsletter came out today. Here are a few highlights:
TCG’s Stefan Thom has an article on the IoT security implications of remote firmware updates:
TCG has announced a new liaison relationship with the Industrial Internet Consortium (IIC), related to Industrial IoT security and trust:
TCG’s TPM 2.0 Library Specification was approved as a formal international standard under ISO/IEC. The specification was submitted to the ISO/IEC JTC 1 by the TCG following the JTC 1 Publicly Available Specification (PAS) Transposition process.
TCG has a few specs for public review:
* TCG PC Client Specific Platform Firmware Profile for TPM 2.0 Systems Revision 1.0 Version 21
* TPM 2.0 Mobile Common Profile Family 2.0 Level 00 Revision 29
* TCG Storage Opal Integration Guidelines, Version 1.00 Revision 1.14
* TCG Trusted Network Communications Server Discovery and Validation Version 1.0, Revision 19
The presentation PDFs (no A/V) are now available for the NVMe Flash Memory Summit, as well as NVME’s presentations from IDF.
The Flash Memory Summit presentations ZIP includes all of the PDFs of that conference, including one on NVMe security, discussing OVAL, Self Encrypting Drives (SEDs), integration with Trustworthy Computing standards, among other things.
The Trusted Computing Group likes Embedded Computing’s story on TPM-flavored IoT security:
There are Opal specs, and UEFI/TPMv2 specs in public review, amongst a few others:
Also see some TCG talks at the Flash Summit, proceedings are now available (free, but email required). There are hundreds of PDFs, a few security and firmware related, in addition to TCG stuff.
This week at the Flash Memory Summit, the Trusted Computing Group (TCG) and NVM Express (NVMe), put out a new joint white paper called “TCG Storage, Opal, and NVMe“. Opal is a set of specs from the TCG, designed to add TCG-style security to NVMe-based storage devices (‘self-encrypting drives’ (SED’), by adding new technology layers to manage encryption of user data, to enable features beyond ‘data at rest protection’. The ‘family’ of Opal specs include 3 levels: Opal, Opalite, and Pyrite, which provides a range of capabilities for vendors to choose from.
From their whitepaper’s summary, Oval offers these values to NVMe:
* Avoids the need to add security to NVM Express standard, or rely on proprietary functionality
* Leverages the existing storage security industry standard for a consistent set of requirements
* Commonly associated features enable a more consistent and secure overall solution
* Simplifies ecosystem enabling, validation, product identification, SKU management
* Reduces standardization to a more streamlined process
* Provides an extensible interface for additional value-adds to Opal/Opalite/Pyrite functionality, as well as other storage security features
I’m not sure if UEFI 2.5 has this ability or not. UEFI 2.5 did add some new NVMe and crypto storage interfaces, though.
PS: Going off-topic(?) a bit, but for NVMe and Linux, check out this doc from June: