Post on 12-May-2020
transcript
© 2016 Trus ted Comput ing Group 1
Trusted Computing Benefits
Storage Work Group
Jorge Campello
Sr. Director, Systems and Software Technologies
Western Digital
© 2016 Trus ted Comput ing Group 2
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
© 2016 Trus ted Comput ing Group 3
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.
4© 2016 Trus ted Comput ing Group
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
© 2016 Trus ted Comput ing Group 5
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
6© 2016 Trus ted Comput ing Group
Storage WG Specifications
© 2016 Trus ted Comput ing Group 7
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)
Core
SpecSIIS
Opal
SSC
Opalite
SSC
Feature Set 1 Feature Set 2
Fe
atu
re
Sets
Security
Subsyste
m C
lass
Genera
l
Feature Set 3
Pyrite
SSCEnterprise
SSC
Current Security Subsystem Classes
8
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
…
Sin
gle
Range
Opalite• Centralized Management, Multi-Authority, Single-Range
Locking/encryption, pre-boot support
Storage Device
Authority 2
Authority 1
Admin Authority
Sin
gle
Range
Pyrite• Centralized Management, Multi-Authority, Single-Range
Locking, pre-boot support optional
Storage Device
Authority 2
Authority 1
Admin Authority
Pre
-Boot
Pre
-Boot
Pre
-Boot
© 2016 Trus ted Comput ing Group
Encryption
Locking
Trusted Computing Benefits via
Networking
Charles SchmidtPrincipal Cyber Security Engineer
The MITRE Corporation
© 2016 Trus ted Comput ing Group 9
Trusted Endpoints
• Trusted Computing and Trusted Storage
powerfully help to secure computing devices,
but…
© 2016 Trus ted Comput ing Group 10
Trusted Endpoints
• … devices do not exist in a vacuum
© 2016 Trus ted Comput ing Group 11
Trusted Endpoints
• How do administrators know a device on their
network is trusted and correctly configured?
© 2016 Trus ted Comput ing Group 12
??
Trusted Network Communications (TNC)
• Collect endpoint information you need
• Expose collected information to tools
• Act on collected information
© 2016 Trus ted Comput ing Group 13
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
© 2016 Trus ted Comput ing Group 14
TNC Architecture
© 2016 Trus ted Comput ing Group 15
Endpoint Enforcement
Points
Policy
Server
CMDB CMDB
Clients
MAP MAP
Clients
TNC Architecture (Compliance)
© 2016 Trus ted Comput ing Group 16
Endpoint Enforcement
Points
Policy
Server
CMDB CMDB
Clients
MAP MAP
Clients
TNC Architecture (Orchestration)
© 2016 Trus ted Comput ing Group 17
Endpoint Enforcement
Points
Policy
Server
CMDB CMDB
Clients
MAP MAP
Clients
Share
MAP
Clients
MAP
TNC Architecture (Orchestration)
© 2016 Trus ted Comput ing Group 18
Physical
Controls
Network
Controls
Dynamic
Device
Configuration
Finance
Dept. (₩)
Network Monitoring
and Security
TNC Architecture (Access Control)
© 2016 Trus ted Comput ing Group 19
Endpoint Enforcement
Points
Policy
Server
CMDB CMDB
Clients
MAP MAP
Clients
Share
Extensible Framework
• Base framework easily supports vendor custom
components
– New types of data to collect
– New consumers/producers of orchestration
data
– Custom access control criteria and actions
© 2016 Trus ted Comput ing Group 20
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
© 2016 Trus ted Comput ing Group 21
Trusted Computing Benefits for
Embedded, IoT, Automotive and
Network EquipmentDr. Seigo Kotani
Steve Hanna
Tom Laffey
© 2016 Trus ted Comput ing Group 22
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
© 2016 Trus ted Comput ing Group 23
© 2016 Trus ted Comput ing Group 24
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
© 2016 Trus ted Comput ing Group 25
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 Trus ted Comput ing Group 26
2016/2 RSA Conf. SF,
2016/4 SAE World Cong. Detroit
© 2016 Trus ted Comput ing Group 27
IoT SG
- Chairs (from Oct. 2014)
Steve Hanna, Infineon
Sung Lee, Intel
IoT Risks
© 2016 Trus ted Comput ing Group 28
Define
• IoT Demos
• IoT Security Use Cases
Solve
• 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
© 2016 Trusted Computing Group 29
© 2016 Trus ted Comput ing Group 30
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
© 2016 Trus ted Comput ing Group 32
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?
© 2016 Trus ted Comput ing Group 35
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
- IoT
- Network Equipment
- RTM
- 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!
© 2016 Trus ted Comput ing Group 36
A Survey of Trusted Computing Work
and Focus Areas
Infrastructure Work Group
Monty Wiseman, GE
Carolin Latze, siroop
© 2016 Trus ted Comput ing Group 37
© 2016 Trus ted Comput ing Group
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.
38
© 2016 Trus ted Comput ing Group
Infrastructure: Provisioning and Certificates
39
Client
TPM
Verifier
Attestation (Privacy) CA
TNC
TSS
Protocols
(e.g., TNC)
Initial Provisioning
Trust? YES
NO
Mobile – MPWG and TMS WG
Alec Brusilovsky, TMS WG Co-Chair
InterDigital Communications
© 2016 Trus ted Comput ing Group 40
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
© 2016 Trus ted Comput ing Group 41
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
© 2016 Trus ted Comput ing Group 42
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
© 2016 Trus ted Comput ing Group 43
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
© 2016 Trus ted Comput ing Group 44
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
© 2016 Trus ted Comput ing Group 45
Virtualized Platform Workgroup
(VPWG)
Lee H. Wilson, VPWG Chairman,
Security Innovation
© 2016 Trus ted Comput ing Group 46
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.
© 2016 Trus ted Comput ing Group
A Trusted vPlatform
48
Hypervisor
vTP
MvTP
M
vTP
MvTPM-Set
vTP
MvTP
M
vTP
MvTPM-Set
vTP
MvTP
M
vTP
MvTPM-Set
Primary VM(Client or Server
based on PC
Client
Specification)
vBIOS
Utility VM(Client or Server
based on PC
Client
Specification)
vBIOS
Utility VM(Client or Server
based on PC
Client
Specification)
Address space(s) for user VMs in this Trusted
vPlatform
vTPMvTPMvTPMvTPM-Set
Hypervisor
© 2016 Trus ted Comput ing Group
Physical Platform (Hardware, Firmware, pTPM)
Taxonomy of the Hypervisor
49
Service
Domain Service
Domain Service
Domain
vPlatform
Manager
vFactory Attestation
Agent
Migration
Engine
VMM
TSS
TCB
© 2016 Trus ted Comput ing Group
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.
50© 2016 Trus ted Comput ing Group
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)
© 2016 Trus ted Comput ing Group
TPM Software Stack Workgroup
(TSS 2.0)
Lee H. Wilson, TSS Chairman,
Security Innovation
© 2016 Trus ted Comput ing Group 52
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)
© 2016 Trus ted Comput ing Group
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.
© 2016 Trus ted Comput ing Group
• 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)
55© 2016 Trus ted Comput ing Group
• 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)
56© 2016 Trus ted Comput ing Group
• 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)
57© 2016 Trus ted Comput ing Group
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
© 2016 Trus ted Comput ing Group