TCG updated multiple specs

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.
http://www.trustedcomputinggroup.org/pc-client-specific-platform-firmware-profile-specification/

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.
http://www.trustedcomputinggroup.org/tcg-efi-protocol-specification/

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.
http://www.trustedcomputinggroup.org/tcg-storage-opal-test-cases/

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.
http://www.trustedcomputinggroup.org/multiple-stakeholder-model/
http://www.trustedcomputinggroup.org/tpm-library-specification/
http://www.trustedcomputinggroup.org/tcg-tpm-2-0-mobile-common-profile/
http://www.trustedcomputinggroup.org/tpm-2-0-mobile-reference-architecture-specification/

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.

TCG Updates IF-M Segmentation to Enable Efficient Information Exchange


http://www.trustedcomputinggroup.org/tnc-ifm-segmentation-specification/

Trusted Network Communications (TNC)

TPM2 ACPI table

Finnbarr P. Murphy has a new blog post about viewing the TPM2 ACPI table:

[…] Why two definitions for the same header? The current ACPI standard defines the table description header as follows: […]
I believe that the second definition is closer to the intent of the ACPI. For a more detailed look at the actual TPM2 support in the EDK2, read the Intel white paper entitled A Tour Beyond BIOS with the UEFI TPM2 Support in EDKII by Jiewen Yao and Vincent J. Zimmer. […]

http://blog.fpmurphy.com/2016/03/examining-tpm2-acpi-table.html

FPMurphy on TPM access via UEFI

Finnbarr P. Murphy does not blog often, but each post is usually very well written, and often focused on using some UEFI Shell commands to do some specific task. In the current post, the topic is accessing TPM’s features from the UEFI Shell, and it is called “part 1”, with more to come!

“Why an I writing this series of posts? Because there are few published examples of working UEFI code that interacts with a TPM. Such example code is useful to security researchers and computer forensics practitioners.”

http://blog.fpmurphy.com/2016/02/accessing-tpm-functionality-from-uefi-shell-part-1.html

Using TPMs in embedded systems

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. […]

Full article:
http://electronicdesign.com/embedded/standardizing-trust-embedded-systems

Windows 10 health check features

https://twitter.com/dfullerto/status/690555872917987328

Microsoft has an article that describes the new health check security features of Windows 10, which include use of UEFI Secure Boot and TPM technology, among others:

This article details an end-to-end solution that helps you protect high-value assets by enforcing, controlling, and reporting the health of Windows 10-based devices, including hardware requirements.

https://technet.microsoft.com/en-us/library/mt592023%28v=vs.85%29.aspx

Intel Quark gets Measured Boot

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

SeaBIOS gets TPM2 security

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

Full message:
http://www.seabios.org/pipermail/seabios/2011-April/001609.html
https://lists.gnu.org/archive/html/qemu-devel/2011-08/msg03835.html

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:
http://wiki.qemu.org/Features/TPM
https://github.com/stefanberger/seabios-tpm

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

Full message:
http://www.seabios.org/mailman/listinfo/seabios

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:
https://news.ycombinator.com/item?id=9185719

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! 🙂

http://www.seabios.org/

TPM 2.0 is an ISO standard

https://www.trustedcomputinggroup.org/community/2015/12/tcg_tpm_20_library_specification_now_available_from_iso_and_the_iec
http://www.trustedcomputinggroup.org/resources/tpm_library_specification
http://www.trustedcomputinggroup.org/resources/errata_for_tpm_library_specification_20

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.

GRUB and TPM

For GRUB 0.x, there is the Trusted GRUB, from TrouSerS and the GRUB Legacy project:

New UEFI-patched GRUB Legacy


http://trousers.sourceforge.net/grub.html

I may have missed it, but I don’t think the recent GRUB Legacy project has Trusted GRUB ‘s TPM support. I hope they pick it up, it would be nice to have a single GRUB Legacy with latest UEFI and TPM support. I wonder what other forks of GRUB 0.x are worth watching?

For GRUB2, I missed this activity from Matthew back in September, but it appears that he’s added TPM support to GRUB2:

http://mjg59.dreamwidth.org/37656.html
https://github.com/mjg59/grub

The above blog post mentions Sirrix AG’s TrustedGRUB, that it was based on.

I just noticed that the TrustedGRUB2 project from Sirrix AG has also been recently updated:

https://github.com/Sirrix-AG/TrustedGRUB2
https://github.com/Sirrix-AG/TrustedGRUB2/commits/master

Hmm, there’s some UEFI 2.5-centric checks in the Sirrix tree, too:
https://github.com/Sirrix-AG/TrustedGRUB2/commit/c79c59f1295df8ea660f8a858f9532d76a5f67b7

https://www.gnu.org/software/grub/

So it appears that both Matthew’s GRUB2 as well as Sirrix’s current TrustedGRUB2 are both of interest, probably others (how many others??).  Why doesn’t upstream GRUB2 take all these patches, anyway? Is it an FSF issue with TPM/UEFI-centric code? I wish UEFI Form was a bit more proactive with GRUB[2], two of the most influential UEFI ‘pre-OS’ applications in use.

 

Guido Stepken on Linux UEFI TPM 2.0 backdoors

https://twitter.com/SecNewsBot/status/677681956176404480

Guido Stepken has a Google+ post from September (which I didn’t notice back then), and the SecNewsBot on Twitter just posted this like it is news. Well, it is news to me. 😦

Linux UEFI TPM 2.0 security impacts:
The “security chain” begins with one or more TPM 2.0 “Endorsement Keys” (EK), that are stored on the motherboard and that cannot be overwritten without “allowance” by either the owner (hardware manufacturer) or somebody, that is “higher” in key hierarchy, such as Microsoft or U.S. government authorities. Key Exchange Keys (KEK) establish a trust relationship between the operating system and the platform firmware. Each operating system (and potentially each 3rd party application, that needs to communicate with platform firmware) enrolls a public key (KEKpub) into the platform firmware. When your hardware comes “Windows Certified”, the “Endorsement Key” already is initialized, is signed by Microsoft and U.S. authorities. “Windows certified” here automatically means “NSA backdoor” included and activated in all encryption modules. Hardware encryption on newer INTEL Xeon machines, at boot, load those key rings from UEFI tables into processor buffer. From then on, the CPU hardware encrypts everything with Microsoft and U.S. authorities keys being enclosed in the key ring, independent of used operating system! […]

Full article:

https://plus.google.com/+GuidoStepken/posts/XZsgDcuairt

TCG releases/revises many specs

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
http://www.trustedcomputinggroup.org/resources/guidance_for_securing_iot_using_tcg_technology_reference_document
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
http://www.trustedcomputinggroup.org/resources/tcg_physical_presence_interface_specification
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
http://www.trustedcomputinggroup.org/files/resource_files/BC34DFDC-1A4B-B294-D057321AEB737B9B/TCG_Errata_Combined_June_16_2015%20Rev%201%203_Final.pdf
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
http://www.trustedcomputinggroup.org/resources/tpm_keys_for_platform_identity_for_tpm_12
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) [4] device identity module definition and formatting.

TNC SWID Message and Attributes for IF-M Specification, Version 1.0, Revision 29
http://www.trustedcomputinggroup.org/resources/tnc_swid_messages_and_attributes_for_ifm_specification
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
http://www.trustedcomputinggroup.org/resources/storage_work_group_storage_interface_interactions_specification
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
http://www.trustedcomputinggroup.org/resources/storage_work_group_storage_security_subsystem_class_enterprise_specification
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
http://www.trustedcomputinggroup.org/resources/storage_work_group_storage_security_subsystem_class_opal

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
http://www.trustedcomputinggroup.org/resources/tcg_storage_enterprise_feature_set_psk_secure_messaging
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
http://www.trustedcomputinggroup.org/resources/tcg_storage_opal_ssc_feature_set_psk_secure_messaging
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
http://www.trustedcomputinggroup.org/resources/tcg_storage_feature_set_block_sid_authentication_specification
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
http://www.trustedcomputinggroup.org/resources/tcg_storage_opal_feature_set__psid
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
http://www.trustedcomputinggroup.org/resources/tcg_storage_security_subsystem_class_pyrite
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
http://www.trustedcomputinggroup.org/resources/tcg_storage_opal_ssc_feature_set_single_user_mode
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
http://www.trustedcomputinggroup.org/resources/tcg_storage_security_subsystem_class_opalite
This specification defines the Opalite Security Subsystem Class (SSC). Any SD that claims Opalite SSC compatibility SHALL conform to this specification.

TPM-tools for TPM 2.0

I was just looking on Intel’s 01.org to see what’s new, or some older things I’ve not yet noticed.

I just noticed there are two projects with updated TPM 2.0 support:

TPM2-0-TSS:

TPM (Trusted Platform Module) 2.0 Software Stack (TSS). This stack consists of the following layers from top to bottom:
 * Feature API (FAPI), see specification 0.12, (published but still in progress and unimplemented)
 *  Enhanced System API (ESAPI), (specification in progress and unimplemented)
 *  System API (SAPI), see 1.0 specification, (public, 0.97 implementation complete)
 *  TPM Command Transmission Interface (TCTI), used by SAPI to communicate with next lower layer (either the TAB/RM or TPM 2.0 device driver), see SAPI specification
 *  Trusted Access Broker/Resource Manager (TAB/RM), see 0.91 specification, (public, implementation complete)

https://github.com/01org/TPM2.0-TSS

TPM2-0-tools:

This site contains the code for the TPM (Trusted Platform Module) 2.0 tools based on TPM2.0-TSS. Below is the name list of the implemented tools:
Subset 1: NV tools: tpm2_nvdefine tpm2_nvrelease tpm2_nvread tpm2_nvwrite tpm2_nvlist
Subset 2: Attestation tools: tpm2_takeownership tpm2_getpubek tpm2_getpubak tpm2_akparse tpm2_makecredential tpm2_activatecredential tpm2_listpcrs tpm2_quote
Subset 3: Key management tools: tpm2_createprimary tpm2_create tpm2_evictcontrol tpm2_load tpm2_loadexternal
Subset 4: Encryption tools: tpm2_encryptdecrypt tpm2_rsaencrypt tpm2_rsadecrypt tpm2_unseal
Subset 5: Signing tools:  tpm2_sign tpm2_verifysignature tpm2_certify
Subset 6: utilities:  tpm2_getrandom tpm2_hash tpm2_hmac tpm2_readpublic

https://github.com/01org/tpm2.0-tools

new Linux-IMA patchset closes multiple measurement/appraisal gaps

Mimi Zohar and Dmitry Kasatkin have created a new patchset for Linux IMA which:

“closes a number of measurement/appraisal gaps by defining a generic function named ima_read_and_process_file() for measuring and appraising files read by the kernel (eg. kexec image and initramfs, firmware, IMA policy). To differentiate between callers of ima_read_and_process_file() in the IMA policy, a new enumeration is defined named ima_read_hooks, which initially includes KEXEC_CHECK, INITRAMFS_CHECK, FIRMWARE_CHECK, and POLICY_CHECK.

separate ‘security.ima’ reading functionality from collect
load policy using path
update appraise flags after policy update completes
measure and appraise kexec image and initramfs
measure and appraise firmware (improvement)
measure and appraise the IMA policy itself
require signed IMA policy

 Documentation/ABI/testing/ima_policy      |  2 +-
 drivers/base/firmware_class.c             | 15 +++++–
 include/linux/ima.h                       | 12 +++++
 kernel/kexec_file.c                       | 28 +++++++—–
 security/integrity/digsig.c               |  2 +-
 security/integrity/iint.c                 | 24 +++++++—
 security/integrity/ima/ima.h              | 24 +++++—–
 security/integrity/ima/ima_api.c          | 51 +++++++++++++++——
 security/integrity/ima/ima_appraise.c     | 40 +++++++++++——
 security/integrity/ima/ima_crypto.c       | 56 ++++++++++++++++——–
 security/integrity/ima/ima_fs.c           | 45 ++++++++++++++++++-
 security/integrity/ima/ima_init.c         |  2 +-
 security/integrity/ima/ima_main.c         | 55 ++++++++++++++++++—–
 security/integrity/ima/ima_policy.c       | 73 ++++++++++++++++++++++++——-
 security/integrity/ima/ima_template.c     |  2 –
 security/integrity/ima/ima_template_lib.c |  3 +-
 security/integrity/integrity.h            | 14 +++—
 17 files changed, 329 insertions(+), 119 deletions(-)

More information:
https://lists.sourceforge.net/lists/listinfo/linux-ima-devel

fTPM 2.0 research from Microsoft

There’s a new paper from Microsoft Research, on a firmware-based TPM implementation (fTPM):

https://twitter.com/h0x0d/status/662465826503524352

This paper presents the design and implementation of a firmware-based TPM 2.0 (fTPM) leveraging ARM TrustZone. The fTPM is the reference implementation used in millions of mobile devices, and was the first hardware or software implementation to support the newly released TPM 2.0 specification. This paper describes the shortcomings of ARM’s TrustZone for implementing secure service (such as our implementation), and presents three different approaches to overcome them. Additionally, the paper analyzes the fTPM’s security guarantees and demonstrates that many of the ARM TrustZone’s shortcomings remain present in future trusted hardware, such as Intel’s Software Guard Extensions (SGX).

Authors: Himanshu Raj, Stefan Saroiu, Alec Wolman, Ronald Aigner, Jeremiah Cox, Paul England, Chris Fenner, Kinshuman Kinshumann, Jork Loeser, Dennis Mattoon, Magnus Nystrom, David Robinson, Rob Spiger, Stefan Thom, and David Wooten

http://research.microsoft.com/apps/pubs/default.aspx?id=258236

GRUB with Trusted Boot for TPM v1 or v2

This from September, I only just noticed it. 😦

Matthew Garrett has updated GRUB bootloader with support for Trusted Boot, on TPM v1 or v2 systems!

In a follow-up to the above tweet, Matthew also states:

“I need to add equivalent code to Shim now lucky me”

 

https://github.com/mjg59/grub

 

So I need to check if that happened, and if Debian and other distros are using this version of GRUB and Shim…

I wish somebody — Wikipedia, the Linux Foundation, the Linux kernel security wiki, the UEFI Forum, etc. —  were tracking the various hardware/firmware security features of various vendors, and what system components (grub and shim in this case) had support for the various technologies, with a table of red/green boxes. Then we could more easily see things like tboot only supporting BIOS and not UEFI, etc..

Nikolaj on UEFI Security, part 7!

Nikolaj has written a 7th part to his 6-part series on UEFI security!

It covers AMD security processors, Intel STM, Intel SGX, TPM 2.0, and other current technologies.

There is mention at the end of an upcoming article on taming Secure Boot, generating your own keys, looking forward to that!

http://habrahabr.ru/post/268423/

https://translate.google.com/translate?sl=auto&tl=en&js=y&prev=_t&hl=en&ie=UTF-8&u=http%3A%2F%2Fhabrahabr.ru%2Fpost%2F268423%2F&edit-text=