Trusted Computing Benefits · –TPM 2.0 Mobile Reference Architecture –TPM 2.0 Mobile Common...

Trusted Computing Benefits

Storage Work Group

Jorge Campello

Sr. Director, Systems and Software Technologies

Western Digital

Data at Rest for Storage Devices

• Threat Model:

– Offline attempts to read data by unauthorized

entities

• High-Level Use Cases:

– Stolen / Lost / Misplaced Storage Device

– Repurposing of Storage Device

Data at Rest for Storage Devices

• Goal:

Provide Specifications that address the threat

model for the identified use cases supporting

the broadest possible set of storage devices.

Basic Constructs for Solution

• Encryption– Encrypt data once it enters the storage device before committing it

to persistent media• Provides: Physical security and Cryptographic Erase

• Locking– Disable IO to the storage device until proper access control is

provided• Provides: Access control to prevent unauthorized access

• Core Specification– Encryption, locking and all other cryptographic and architectural

elements are detailed in the Core Spec

Storage Interface Interactions Spec

• Abstract the underlying storage interface– Provide uniform management framework over all interfaces

– Deal with all interface specific Issues

• Addressing many storage interface standards

– NVMe, ATA, SCSI, eMMC, UFS, etc

Storage WG Specifications

Core Specification (Core Spec) Overall architecture – a description of the underlying constructs to

be used in the device specifications.

Storage Interface Interactions Specification (SIIS) Describes the interactions of the TCG* SWG specifications with the

underlying storage interface protocols, such as ATA, SCSI, NVMe,

eMMC, UFS, etc.

Security Subsystem Class (SSC) Device specifications, consist primarily of a subset of the

functionality contained in the Core Spec.

Opal, Opalite, Pyrite and Enterprise

Feature Sets These are documents that define extensions to the basic

functionality of SSCs.

Created to allow for simple extensions to be added to the SSC

at a faster pace.

Additionally, it allows for features that only appeal to a subset

of the market to be standardized.

Generally “Optional”, may be “Mandatory” by spec (e.g., PSID)

SpecSIIS

Opalite

Feature Set 1 Feature Set 2

Security

Subsyste

Genera

Feature Set 3

Pyrite

SSCEnterprise

Current Security Subsystem Classes

Range 1

Range 2

Range 3

Opal• Centralized Management, Multi-Authority, Multi-Range

Locking/encryption, pre-boot support

Storage Device

Authority 2

Authority 3

Authority 1

Admin Authority

Range 1

Range 2

Range 3

Enterprise• Decentralized Management, Multi-Authority, Multi-

Range Locking/encryption, no pre-boot support

Storage Device

Authority 2

Authority 3

Authority 1

Opalite• Centralized Management, Multi-Authority, Single-Range

Locking/encryption, pre-boot support

Storage Device

Authority 2

Authority 1

Admin Authority

Pyrite• Centralized Management, Multi-Authority, Single-Range

Locking, pre-boot support optional

Storage Device

Authority 2

Authority 1

Admin Authority

Encryption

Locking

Trusted Computing Benefits via

Networking

Charles SchmidtPrincipal Cyber Security Engineer

The MITRE Corporation

Trusted Endpoints

• Trusted Computing and Trusted Storage

powerfully help to secure computing devices,

but…

Trusted Endpoints

• … devices do not exist in a vacuum

Trusted Endpoints

• How do administrators know a device on their

network is trusted and correctly configured?

Trusted Network Communications (TNC)

• Collect endpoint information you need

• Expose collected information to tools

• Act on collected information

TNC Capabilities

• Compliance – get the information you need from endpoints

• Orchestration – get collected information to tools that can use it

• Access control – use information to manage access to resources

TNC Architecture

Endpoint Enforcement

Points

Policy

Server

CMDB CMDB

Clients

MAP MAP

Clients

TNC Architecture (Compliance)

Points

Policy

Server

CMDB CMDB

Clients

MAP MAP

Clients

TNC Architecture (Orchestration)

Points

Policy

Server

CMDB CMDB

Clients

MAP MAP

Clients

TNC Architecture (Orchestration)

Physical

Controls

Network

Controls

Dynamic

Device

Configuration

Finance

Dept. (₩)

Network Monitoring

and Security

TNC Architecture (Access Control)

Points

Policy

Server

CMDB CMDB

Clients

MAP MAP

Clients

Extensible Framework

• Base framework easily supports vendor custom

components

– New types of data to collect

– New consumers/producers of orchestration

– Custom access control criteria and actions

Trusted Network Communications

• Get endpoint security information where it is needed

• Know you can trust your endpoints comply with policy

• Using an open, easily extensible framework

Trusted Computing Benefits for

Embedded, IoT, Automotive and

Network EquipmentDr. Seigo Kotani

Steve Hanna

Tom Laffey

Embedded Systems WG comprises four subgroups (SG)

- Vehicle Services SG

- Internet of Things SG

- Network Equipment SG

- Root of Trust Measurement SG

EmSys Work Group Chairs (from June 2011)

Seigo Kotani, Principal Expert, Fujitsu

Steve Hanna, Senior Principal, Infineon

Vehicle Services SG

- Chairs (from Sep. 2012)

Seigo Kotani, Fujitsu

Hisashi Oguma, Toyota

Vehicles are vulnerable to cyber attacks• Mitsubishi car alarm hacked

BBC News, 6 June 2016, Technology

http://www.bbc.com/news/technology-36444586

Researchers have found that the alarm on

Mitsubishi's Outlander hybrid car can be

turned off via security bugs in its on-board wi-fi

• RFCs from National Highway Traffic Safety Admin.– Automotive Electronic Control Systems Safety and Security

Due Dec. 08, 2014, https://www.regulations.gov/document?D=NHTSA-2014-0108-0001

– Federal Automated Vehicles PolicyDue Nov. 22, 2016, https://www.regulations.gov/document?D=NHTSA-2016-0090-0001

TPM for Automotive improves vehicle security

• TCG TPM 2.0 Library Profile for Automotive-ThinPublished: March, 01, 2015http://www.trustedcomputinggroup.org/tcg-tpm-2-0-library-profile-automotive-thin/

• Demonstration of

Remote Firmware Update for

Vehicle ECU with TPM

• Proposals for World-wide org.RFC from NHTSA, ITU-T, etc.

2016/2 RSA Conf. SF,

2016/4 SAE World Cong. Detroit

IoT SG

- Chairs (from Oct. 2014)

Steve Hanna, Infineon

Sung Lee, Intel

IoT Risks

Define

• IoT Demos

• IoT Security Use Cases

• TCG Guidance for Securing IoT

• Architect’s Guide for IoT Security

Refine

• Guidance for Classes of Constrained Devices

• Secure Software and Firmware Update

• Market Review – Expand EmSys-WG?

TCG Approach to IoT

Network Equipment SG

- Chairs (from May 2015)

Tom Laffey, HPE

Nicolai Kuntze, Huawei

Threats to Network Equipment

• Shared threats common with other systems

• Some specific characteristic due to Infrastructure:

– Always on (attackable anytime)

– Wide connectivity

• Leads to specific concerns:

– Authorization of connected devices

– Detecting unauthorized firmware or software

– Special logging and management needs

Network Equipment Guidance

TCG Guidance for Securing Network Equipment

• Under development by TCG members involved

in Networking

– Juniper, Cisco, Huawei, HPE and others

• Intended to help networking equipment vendors

use TCG technology to secure network

infrastructure

Applications for a TPM in Networking

• Cryptographic Random Number Generator

– Secure protocols can rely on entropy from TPMs

• Cryptographic Device Identification

– Unambiguous identification of network devices is critical for secure operation

– Especially important for remote or auto-config applications

– IEEE 802.1AR Secure Device Identity can be implemented with TPMs

• Software Attestation / Health-Check

– TCG technology can demonstrate integrity of software images

… And more

What Can You Do?

• Consider joining our Subgroup

• Review and use NetEq Guidance

• Review and use upcoming specs

• See NetEq Synopsis for more examples

– http://www.trustedcomputinggroup.org/wp-

content/uploads/NetEq-Synopsis_1_0r3.pdf

Thank you, Questions?

Seigo Kotani, skotani@jp.fujitsu.com

Steve Hanna, steve.hanna@infineon.com

Hisashi Oguma, oguma@jp.toyota-itc.com

Sung Lee, sung.lee@intel.com

Tom Laffey, tom.laffey@hp.com

Nicolai Kuntze, nicolai.kuntze@huawei.com

Ronald Aigner, ronald.aigner@microsoft.com

Join us! Embedded Systems WGhttp://www.trustedcomputinggroup.org/developers/embedded_systems

https://members.trustedcomputinggroup.org/apps/org/workgroup/emsys_wg

If you are interested in the following applications:Standardization for

- Automotive

- Hardcopy devices

- Network Equipment

- Mobile communication devices

- Household applications (TV/Settop box, etc)

- Industrial control and machinery

- Financial transaction terminals

- Medical equipment

- Smart Grid/Smart meter

- Sensor network/Monitor cameras …

Please contact us!

We have 222 members!

Please join us!

A Survey of Trusted Computing Work

and Focus Areas

Infrastructure Work Group

Monty Wiseman, GE

Carolin Latze, siroop

Infrastructure Working Group• Defines Provisioning and Certificates for TCG and TPM protocols

• Provisioning

– Endorsement Key provisioning• Common parameters for creating Endorsement Key

– Guidelines

– Other standard key formats• E.g., 802.1ar iDevID and lDevID, etc

• Certificates

– Endorsement Key Certificates

– Platform Certificates

– AK (AIK) Certificates

– Etc.

Infrastructure: Provisioning and Certificates

Client

Verifier

Attestation (Privacy) CA

Protocols

(e.g., TNC)

Initial Provisioning

Trust? YES

Mobile – MPWG and TMS WG

Alec Brusilovsky, TMS WG Co-Chair

InterDigital Communications

Mobile Problem Statement (1 of 3)

• Key Challenges for Mobile Devices and Infrastructure– Complexity of mobile device hardware and software is high

– Complexity of mobile infrastructure is increasing with the trend toward virtualization and network slicing

– Rapid increase in the number of connected devices (e.g., IoT, mobile, and industrial) on telecom networks

– Mobile updates are sometimes delayed by users or networks

– Applications are frequently managed by users and third-parties

• Platform Integrity of Mobile Devices and Infrastructure

– Assurance of platform integrity is required to protect the identities and data of major stakeholders (e.g., users, banks, governments)

– TCG technologies are ideal for protecting platform integrity

Mobile Problem Statement (2 of 3)

• Architecture Complexity– Mobile phones typically contain 30+ chips from 8+ suppliers

– Regulatory mandates for emergency calling, LI, and GPS location support

– Hardcoded secure boot, no BIOS or ACPI, system rarely rebooted

– Network CPU, application CPU, and UICC/SIM cards are required

– Diverse operating systems and microprocessor architectures

– Multiple wireless technologies (3G/4G, Wi-Fi, Bluetooth, NFC, etc.)

– Mobile phone product lifecycles are typically 6 months or less

• Power Management Complexity– Limited battery life with no explicit suspend or hibernate power states

– Carrier roaming handoffs, base station handoffs, variable signal quality

– Applications are completely unaware of power state transitions

Mobile Problem Statement (3 of 3)• Mobile Threat Landscape

– Nation-states are constantly hacking and monitoring phones

– Phones are often lost or stolen – physical attacks are easy

– Denial of service and man-in-the-middle attacks are common

– SMS/MMS phishing and infected OS/app updates are common

– Hundreds of infected apps found every year on “official” app stores

– Telecom carrier network infrastructure attacks are common

– Bank fraud, credit card fraud, and POS attacks are common

– User privacy and personal identity/data losses are common

• Mobile Market Priorities

– In spite of mobile threats, mobile security is not a priority in the market

– Benefits of mobile device security must be crystal clear

Mobile Solutions – Core Technologies (1 of 2)

• Platform Integrity – enhanced w/ TPM 2.0

– TPM 2.0 Mobile Reference Architecture

– TPM 2.0 Mobile Common Profile

– Runtime Integrity Preservation – in progress

• Trusted UI, Applications, and Transport Protocols

– Integration w/ Global Platform TEE – ongoing

• Platform Monitoring and Attestation – TNC Clients

• Secure Storage – SEDs, TPM 2.0 auth & key mgmt

Mobile Solutions – Mobile Ecosystem (2 of 2)

• Trusted Mobile Use Cases and Guidance

– TMS UC v1 (BYOD)

– TMS UC v2 (Mobile Enterprise, Financial, NFV) –in progress

• Trusted Device Collaboration w/ other SDOs

– ETSI and 3GPP 3G/4G/5G Security Standards –collaboration by TCG TMS WG

– Mobey Forum Payment/Biometrics Whitepapers –collaboration by TCG TMS WG and MPWG

Virtualized Platform Workgroup

(VPWG)

Lee H. Wilson, VPWG Chairman,

Security Innovation

Mission of the Trusted Virtualized Platform• The primary mission of the VPWG is to specify how to create environments where

virtual TPMs can be provided by hypervisors and the trust guarantees of such vTPMs can be met.

• Broadly, the mission can broken into three parts:

1. First, you must create a base hypervisor/system definition that is capable of protecting vTPMs and can prove it is doing so (attestation). Doing a vTPM implementation and announcing it to the world is a nice beginning for vendors… but until you can guarantee that the environment where the vTPMs reside is providing trust guarantees close to what a physical TPM provides you are far from done. (NOTE: This is not an easy thing to specify.)

2. VM Migration is the ultimate attack surface. If you can get someone to migrate a desired VM to you in a usable form you’ve just robbed Fort Knox. So, you have to specify a migration authority (which we may call a vTPM trust authority) that can manage migration, backup and recovery.

3. You need to be capable of interoperation between vendors. VMs move between different cloud vendors and different types of physical platforms and hypervisors.

• More specificity will be needed to meet this goal.

A Trusted vPlatform

Hypervisor

MvTPM-Set

Primary VM(Client or Server

based on PC

Client

Specification)

Utility VM(Client or Server

based on PC

Client

Specification)

Utility VM(Client or Server

based on PC

Client

Specification)

Address space(s) for user VMs in this Trusted

vPlatform

vTPMvTPMvTPMvTPM-Set

Hypervisor

Physical Platform (Hardware, Firmware, pTPM)

Taxonomy of the Hypervisor

Service

Domain Service

Domain

vPlatform

Manager

vFactory Attestation

Migration

Engine

How Can TCG Address Migration and

Large Data Center Requirements?

• Version 1.0 of the Trusted Virtualized Platform must address “migration authorities” for backup and restore – but not live migration.

• Version 2.0 of the Trusted Virtualized Platform will be focused on the broad specification of a “Migration Authority”

– Guarantees target platforms are trusted before migration

– Guarantees that TPM rules are not violated (only one instantiation at a time).

– Guarantees TPM content confidentiality.

– Note: It turns out that the problem of backing up and restoring TPMs is in many ways identical to TPM migration. So, even version 1.0 of the Trusted Virtual Platform Implementation has to address this in part.

Work Group Roadmap

Complete PC Client

Virtualization Spec for

Public Review

Conduct Public Review,

Edit and Submit v1.0

Document

Add Migration Authority

specification and other

pieces needed for

live migration

(v2.0 Specification)

TPM Software Stack Workgroup

(TSS 2.0)

Lee H. Wilson, TSS Chairman,

Security Innovation

TSS 2.0Application

ApplicationApplication

Crypto Library

SAPI(System API)

TCTI (TPM Command Transmission Interface)

ESAPI(Enhanced

System API)

FAPI(Feature API)

Scenario 1

(Local

Application)

Scenario 2

(Remote

Application)

Tab and Resource Manager

Network

Connection

TPM Device Driver

ApplicationApplication

Application

Crypto Library

SAPI(System API)

TCTI (TPM Command Transmission Interface)

ESAPI(Enhanced

System API)

FAPI(Feature API)

System API (SAPI) - GoalsTPM DriverThe TPM driver is the OS-specific driver that handles all the handshaking with the TPM and reading and writing of data to the TPM.

TAB and Resource ManagerThe resource manager manages the TPM context in a manner similar to a virtual memory manager. It swaps objects, sessions, and sequences in and out of the

limited TPM onboard memory as needed. This layer is transparent to the upper layers of the TSS and is not required . However, if not implemented, the upper

layers will be responsible for TPM context management. The TPM access broker (TAB) handles multi-process synchronization to the TPM. A process accessing

the TPM can be guaranteed that it will be able to complete a TPM command without interference from other competing processes.

TCTIThe TPM command transmission interface (TCTI) handles all the communication to and from the lower layers of the stack. For instance, different interfaces are

required for local HW TPMs, firmware TPMs, virtual TPMs, remote TPMs, and the TPM simulator. Also, there are two different interfaces to TPMs: the legacy TIS

interface and the command/response buffer (CRB).

SAPIThe System API (SAPI) is the lowest level interface that understands how to build command byte streams (marshalling) and decompose response byte streams

(unmarshalling). The SAPI provides a bare metal (meaning very low level) software interface to the Part 3 commands in the TPM 2.0 specification.

ESAPIThe Enhanced System API (ESAPI) is an interface that is intended to sit directly above the System API. The primary purpose of the ESAPI is to reduce the

complexity required of applications that desire to send individual “system level” TPM calls to the TPM, but that also require cryptographic operations on the data

being passed to and from the TPM. In particular, applications that wish to utilize secure sessions to perform Hash-based Message Authentication Code (HMAC)

operations, parameter encryption, parameter decryption, TPM command audit, and TPM policy operations could benefit from using the ESAPI.

FAPIThe feature/environment API provides a higher level software abstraction to application developers. For instance, an application may want to create a key without

any knowledge of the low level details. This level of abstraction will be provided by the feature and application APIs.

• Type Checking – Type Safefy– Our TSS design requires different functions for different TPM calls in order to provide type safety of the parameters

– Two possibilities to implement the API.

• You have one function to call a program layer and you enter one generic parameter. This does not provide type safety,

• You can create approximately ~100-300 (around 100 TPM commands) functions to call that API with specific type safe parameters

• Note: You may create wrapping layers that present either of these interfaces.

– The ~100-300 approach reduces the cognitive load and education for programmers. It reduces the errors that

programmers encounter. It also helps facilitate modern IDE auto-completion features (Windows visual studio, etc.)

– Rule: A good programmer is a lazy programmer - but you have to be smart about where you are lazy. We are trying to

minimize the application programmers complexity - not necessarily library complexity. Libraries are implemented one or two

times but used thousands of times. Many, many applications can then use these libraries.

Design Goals for TSS 2.0 (Reqmt. #1)

• Async Support– Async support is a much easier alternative to forcing the user to do extensive multi-threading.

– You can counter the lack of async with multi-threading but multi-threading is expensive and it is complicated. Race

conditions and improper locks (ie. Deadlocks) between the threads are a problem.

– (note: one function for sync and two additions functions for async is how this is done).

• TSS Must be written in C99 (Linux needs C)– C99 is the greatest common denominator.

– C11 is the most recent ANSI C – it is not supported across all architectures and platforms in target communities.

– Calling C++ from C is extremely hard

Design Goals for TSS 2.0 (Reqmt. #2 & 3)

• No Global State (Need context)– Problem Statement: If you have two threads or modules calling the TSS library how do you keep them from continually

overwriting their state. They share a process id but they don’t necessarily share state. Each module (or thread) will have its

own context in our current design point.

– There are two parts to avoiding global state. On the library side you need to provide context. On the application side you

need to allocate library contexts for execution contexts. Execution contexts are modules and/or threads.

– Note: Session handles are only allowed an restricted to be used within the context they were created in. It’s like a tree

structure with the context at the root of the tree.

– We decided to not have global state. We decided to provide contexts.

– Example of how TSS will be used: with a virtual smart card for a web browser TSS is there but it is three layers deep so the

web browser doesn't see it. Same thing with disk encryption.

– In that example the two don't know about each other, these two would be in the same process and the same memory space.

Global means there is only state per process, so there would be a problem with these two programs - they have to do locking,

mutexing (style of locking - synchronization between threads) etc. With contexts we can have multiple contexts in a process.

Each OS and often language has a different threading model - we make code portability much harder when we mandate multi-

threaded. Multi-threaded debugging is very hard. By introducing the required locking, we would introduce a threading model

into our library. We do not want to do threading in the library (the TSS). We provide a multi-context API. Per context you

need to be sequential, but the context can be interweaved in an arbitrary way. You can interleave them and you can use

them sequentially. You can use them from different threads simultaneously. Our synchronization point is the TAB. TAB not

only does resource scheduling between processes but also the resource scheduling between different contexts in processes.

Design Goals for TSS 2.0 (Reqmt. #4)

Work Group Roadmap

Complete SAPI v1.1, Tab

And Resouce Mgr v1.0, Hdr

Document v1.0.

Finish and publish

ESAPI Specification for

Public Review

Update FAPI document

Document to v1.0 Release

Finish and publish

ESAPI v1.0

Specification

Trusted Computing Benefits · –TPM 2.0 Mobile Reference Architecture –TPM 2.0 Mobile Common...

Documents

TRUSTED COMPUTING - TU Dresdenos.inf.tu-dresden.de/Studium/KMB/WS2012/12-Trusted... · 2013. 1. 8. · TPM is cryptographic coprocessor: ... TPM life cycle, platform requirements

Guide to TCG Seminar and Demonstration Showcase...the trusted platform module (tpm) 2.0 with an accompanying tpm software stack (tss) 2.0 provides an effective way to determine the

cTPM: A Cloud TPM for Cross-Device Trusted Applications · trusted hardware, such as the trusted platform module (TPM), does not provide good support for cross-device functionality

OPTIGA™ TPM SLB 9665 TPM 2.0 Data Sheet

NPCT42x Trusted Platform Module (TPM) - Digi-Key Sheets/Nuvoton PDFs/NPCT42x... · NPCT42x Trusted Platform Module (TPM) General Description The NPCT42x single-chip Trusted Platform

TCG TPM 2.0 Automotive-Thin Profile · Module (TPM). This specification of a TPM 2.0 Automotive-Thin Profile defines a TPM that is applicable to vehicle systems. This TPM 2.0 Automotive-Thin

tpm guide e - Toshiba · 4 TPM Installation Guide 1 Introduction Your computer has an integrated Trusted Platform Module (TPM). To activate TPM, you will …

TPM, UEFI, Trusted Boot, Secure Boot

OPTIGA™ TPM SLM 9670 TPM 2.0 Data Sheet

Trusted Platform Module (TPM)

TCG Trusted Attestation Protocol (TAP) Information Model · TAP adds support for DICE and TPM 2.0, including several new capabilities not available in older TPM versions. As TPM 1.2

Trusted Platform Module - Computer Scienceit666/reading_list/Hardware/tpm_fundamen… · Trusted Platform Module (TPM) Specification defines two generic portions of the TPM Shielded

Trusted Platform Module (TPM) TCG 1.2 / 2 · PDF file8 TPM User Guide B. Types of TPMs for TPM 2.0 The TPM-9665 series uses TCG 2.0 (Trusted Computing Group). The following SKUs are

Trusted Platform Module (TPM) TCG 1.2 / 2.0

Dell OptiPlex 3070 Tower · 1 day ago · 256 Mbit (32 MB) localizado em SPI_FLASH no chipset Dispositivo de Segurança com Trusted Platform Module (TPM) 2.0 (TPM Dedicado Ativado)

TCG FIPS 140-2 Guidance for TPM 2.0 TCG - Trusted ...trustedcomputinggroup.org/wp-content/uploads/TCG-FIPS...0 FIPS_140_2 SET (1): indicates that the TPM is designed to comply with

TCG PC Client Protocol Specification - Trusted Computing Group · 5.4 PCR Banks TCG PC Client Specific Platform TPM Profile for TPM 2.0

TPM 2.0 Authenticated Countdown Timer (ACT) Command · TPM 2.0 Authenticated Countdown Timer (ACT) Command TPM 2.0 Authenticated Countdown Timer (ACT) Command | Version 1.0 | Revision

TPM: Trusted Platform Module

TPM 2.0 Mobile Basic Profile - Welcome To Trusted ... · TPM 2.0 Mobile Common Profile ... eBook readers, and other similar constrained mobile devices. The target audience for this