TRUSTED COMPUTING GROUP TRUSTED STORAGE SPECIFICATION. Jason Cox, Seagate Technology

Transcription

1 TRUSTED COMPUTING GROUP TRUSTED STORAGE SPECIFICATION Jason Cox, Seagate Technology

2 SNIA Legal Notice The material contained in this tutorial is copyrighted by the SNIA. Member companies and individuals may use this material in presentations and literature under the following conditions: Any slide or slides used must be reproduced without modification The SNIA must be acknowledged as source of any material used in the body of any document containing material from these presentations. This presentation is a project of the SNIA Education Committee. Neither the Author nor the Presenter is an attorney and nothing in this presentation is intended to be nor should be construed as legal advice or opinion. If you need legal advice or legal opinion please contact an attorney. The information presented herein represents the Author's personal opinion and current understanding of the issues involved. The Author, the Presenter, and the SNIA do not assume any responsibility or liability for damages arising out of any reliance on or use of this information. NO WARRANTIES, EXPRESS OR IMPLIED. USE AT YOUR OWN RISK. 2

3 Abstract Trusted Computing Group (TCG) Trusted Storage Specification The Trusted Computing Group (TCG) Storage Work Group recently published formal specifications for security and trust services on storage devices, including hard drives, flash, and tape drives. The majority of hard drive and other storage device manufacturers participated. Putting security directly on the storage device avoids the vulnerabilities of platform OS-based software security. The details of the Specification will be highlighted, as well as various use cases, including Full Disk Encryption with enterprise key/credential management. 3

4 TCG Storage Work Group Structure Storage WG Robert Thibadeau Seagate Key Management Services Walt Hubis LSI Storage Interface Interactions James Hatfield Seagate Optical Storage Bill McFerrin DataPlay Storage Conformance Cyril Guyot HGST/ Dave Kreft/NSA 4

5 Security in Storage 3 Simple reasons Storage for secrets with strong access control Inaccessible using traditional storage access Arbitrarily large memory space Gated by access control Unobservable cryptographic processing of secrets Processing unit welded to storage unit Closed, controlled computing environment Custom logic for faster, more secure operations Inexpensive implementation of modern cryptographic functions Complex security operations are feasible 5

6 General Risk Model Storage Peripheral Controller Electronics Primary Host Interface Power Loadable Firmware Firmware Functions Data Sink / Source Special Hardware Functions Diagnostic Ports Probe Points Trust = systems operate as intended Objective: Exercise control over operations that might violate trust Needed: Trusted Storage commands 6

7 Joint Work T10 (SCSI) & T13 (ATA) TRUSTED SEND/ SECURITY PROTOCOL IN (Protocol ID = xxxx..) TRUSTED RECEIVE/ SECURITY PROTOCOL OUT T10/T13 define the container commands TCG SWG defining the TCG payload Protocol IDs assigned to TCG, T10/T13, other standards organizations, or reserved 7

8 TCG SWG Document Structure General Documents TCG Storage Core Architecture Specification Storage Interface Interactions Specific Documents Security Subsystem Class (SSC) Security Subsystem Class (SSC) Auxiliary Documents Compliance Security Evaluation Compliance Security Evaluation 8

9 TCG Storage Specification Overview TCG Storage Core Architecture Specification Version 1.0 Revision 0.9 (DRAFT) 19 June

10 TCG Storage Specification Purpose Define an architecture that: Enables application of access control over select device features Permit configuration of these capabilities in conformance to the platform security policy 10

11 Implementation Overview Enterprise Support Host Application TCG/T10/T1 3 Trusted Container Commands ATA or SCSI TRUSTED STORAGE Firmware/hardware enhancements for security and cryptography Firmware Hidden Storage Security Providers SP Controller Storage Partitioned Hidden Storage Security firmware/hardware Trusted Commands Assign Hidden Storage to Applications TRUSTED Assign Hidden Storage to Applications 11

12 TCG Storage Architecture Overview SD or TPer SW and HW features and function (e.g., Crypto Calls) TCG Storage Architecture ADMIN SP 1 SP 2 SP 3 SP 4 TCG Storage API ATA/ SCSI I/F Host Devices TPM Applications End Users Internet Mobile Devices Service Providers The host platform, applications, devices, local end users, or remote users/service providers can gain exclusive control of selected features of the storage device. This allows them to simultaneously and independently extend their trust boundary into the storage device or trusted peripheral (TPer). 12

13 Security Providers (SPs) Storage Work Group specifications are intended to provide a comprehensive command architecture for putting selected features of storage devices under policydriven access control. Features are packaged into individual functionality containers called SECURITY PROVIDERS (SPs). SP Method Name ACL Each SP is a sand box exclusively controlled by its owner. SP functionality is a combination of pre-defined functionality sets called SP TEMPLATES Base Log Admin Clock Crypto Locking Table Get Set User1 User2 SPs are a collection of TABLES and METHODS that control the persistent trust state of the Storage Device (SD). M Method invocation occurs under access control. Authorities User1 User2 M The SP has a list of authorities and their respective credentials for access control. 13

14 SPs Summary SPs have Their own storage, functional scope, and security domain SPs are created by: Manufacturer (during Storage Device creation) AND/OR Issuance Tables store persistent state information Remains active through power cycles, resets, spin up/down, device formats Methods remote procedure calls that operate on tables or the SP Table management Table read/write Authentication Access Control management are actions such as: table additions, table deletion, table read access, and table backup Authorities authentication agents. Specify cryptographic proofs required to execute the methods in the SP Access Control Lists define authorization requirements for method invocation 14

15 Templates Templates are sets of tables and methods, grouped by feature, from which SPs are built. Base All SPs include a subset of tables and methods defined by the Base template Provides authentication and access control-related tables and methods Admin Only one SP on a device includes this template Stores configuration/capability information Used in Issuance Locking Only one SP on a device includes this template Provides management capabilities for locking, encryption, and MBR shadowing Crypto Methods and tables enabling host-invoked on-device signing, verification, hash, HMAC, and encrypt/decrypt Log Adds forensic logging of SP access Clock Enables time stamping for logging, adds time limitations to authorities 15

16 Tables Tables provide data storage in SPs. Each template defines a set of tables. Capabilities provided by the Base template allow the host to create additional tables. Two types of tables: Object organized storage Byte raw data Each column stores data all of the same type. UID column contains SP-wide unique, addressable value for that row. Rows associate column values. Byte tables have 0 or more rows indexed by position in the table. Object Table UID Col2 Col3 Col4 8 byte unique identifier Data Data Data Byte Table Index Column 0 0x41 1 0x42 2 0x43 Byte tables have a single column. Each cell stores one byte 16

17 Methods Methods are remote procedure calls invoked by the host to manipulate SP state. Methods operate on tables or the SP itself, and are used for session startup, authentication, table manipulation, and access control customization. UID of the table or object upon which the method is being invoked. UID of the invoked method. List of method parameters sent by host. List of results generated by TPer InvokingUID.MethodUID [ Method Parameters ] => [ Method Result ] Key Methods Get Retrieve values stored in tables. Set Change values stored in tables. Authenticate Prove host knowledge of a secret Other methods provide capability to: Create/delete tables/table rows Generate encryption keys on the device Perform cryptographic operations on the device 17

18 Access Control - Authentication Access control defines the authorization required to invoke specific methods. Access control permissions apply at the SP, table, or table row level. Access control settings are configurable and assignable. Authorities are authentication agents Authority UID Name Credential Operation 8 byte identifier Admin C_RSA_1024 UID Sign --- User C_PIN UID Password --- User C_RSA_1024 UID Sign Link to authentication credential Authorities required authentication operation C_PIN UID Name PIN 8 byte identifier Auth PWD C_RSA_1024 UID Name Key Material 8 byte identifier Auth Key Auth Key Credential (C_*) tables store authentication secrets The Host Application invokes the Authenticate method, identifying the Authority to be authenticated and the required proof (password, signed challenge, etc.) 18

19 Access Control - Application Method: XXX.YYY [ ] AccessControl InvokingID MethodID ACL XXX YYY XXX ZZZ XXX ACL column holds a list of ACE UIDs BooleanExpr column holds Authority UIDs and Boolean Operators UID XXX Table Column1 Column2 Column3 ACE (Access Control Element) BooleanExpr Columns User1 Column1,Column Columns identifies the columns to which the ACE applies 19

20 Access Control - Hierarchy Table/Object/SP + Method (InvokingUID.MethodUID) List of ACEs ACL ACE1 ACE2 ACE3 Authority1 AND Authority2 Authority1 OR Authority3 (Authority1 AND Authority2) OR Authority3 20

21 Templates The Base Template is comprised of a core set of commonly used tables and methods. A subset of the Base Template provides the basis for every SP, and enables authentication, access control, and table management. Tables Methods SPInfo C_PIN DeleteSP GetFreeSpace SPTemplates C_RSA_1024 CreateTable GetFreeRows Table C_RSA_2048 Delete DeleteMethod Column C_AES_128 CreateRow Authenticate Type C_AES_256 DeleteRow GetACL MethodID C_HMAC_160 Get AddACE AccessControl C_HMAC_256 Set RemoveACE ACE C_HMAC_384 Next GenKey Authority C_HMAC_512 Certificates C_EC_*** 21

22 Templates The Admin Template provides capabilities to allow the host to retrieve device information, affect state of SPs, and issue new SPs. Tables Methods TPerInfo Template CryptoSuite SP IssueSP The Locking Template provides mechanisms to manage LBA range locking, encryption, re-encryption, and MBR shadow, as well as tables that allow management of LBA range encryption keys. Tables Methods LockingInfo MBRControl GetPackage SetPackage Locking MBR K_AES_128 K_AES_256 22

23 Templates The Crypto Template defines tables and methods that enable hostinvoked cryptographic operations with host-supplied data to occur in the device, including hashing, encryption, decryption, signing, and verification. Tables Methods H_SHA_1 H_SHA_384 Random HashInit H_SHA_256 H_SHA_512 Stir Hash EncryptInit HashFinalize Encrypt HMACInit EncryptFinalize HMAC DecryptInit HMACFinalize Decrypt Sign DecryptFinalize Verify XOR 23

24 Templates The Log Template provides a mechanism to enable forensic logging of host access to the SP. Tables Methods Log LogList AddLog ClearLog CreateLog FlushLog The Clock Template enables time stamping of log entries, as well as enhancement of authentication limitations by providing time-limited authorities. Tables ClockTime SetClockHigh Methods GetClock SetLagHigh SetClockLow ResetClock IncrementCounter SetLagLow 24

25 Communications Architecture 25

26 Communications - ComIDs Multiple scenarios for Application-SP communication exist: Single Application communicating with a single SP Single Application communicating with multiple SPs Multiple Applications communicating with multiple SPs. TPer App 1 ADMIN SP 1 SP 2 SP 3 App 2 App 4 App 5 SP 4 App 3 26

27 Communications - Sessions An application communicates with an SP via a session. Each separate application is assigned a ComID that it uses to identify itself to the device. Each session is associated with a ComID. Multiple sessions can be associated with a single ComID. TPer ADMIN SP 1 SP 2 SP 3 SP 4 Storage Device Application ComID assigned to application by device Host Application Session between Application and SP 27

28 Communications - Structures ComPacket unit of communication transmitted as the payload of an Interface Command. May hold multiple packets in its payload. Packet associated with a particular session between an App & SP May hold multiple SubPackets. SubPacket contains data (Tokens) or buffer management information Token encoded data Session1 Data Session2 Data Tokens Tokens SubPacket SubPacket SubPacket SubPacket SubPacket SubPacket Packet Packet ComPacket SessionX Data Tokens SubPacket SubPacket SubPacket Packet Trusted Command 28

29 SP Issuance/Personalization Overview Issuance Creation of a new SP (exchange/validation of credentials), including activation of drive features Templates Define SP s initial tables and methods. Personalization Customization of a newly created SP via modification of table data, administrator and other authorities, default access control settings, etc. Issuance Server SP 29

30 SP Issuance/Personalization Overview Users/applications/services obtain a certificate from an authorized organization to obtain an SP with the desired capabilities on a given storage device. The storage device owner must authorize the issuance. Once issued, the SP can be customized by the user/app/service. Storage Device Admin SP Storage Device owner must also authorize issuance. Org 1 Auth. Org 1 Org 1 is a preinstalled authority. SP A (Base+Locking) Auth. AppA_Auth M M App A SP A is issued with default tables/values and AppA_Auth is the only authority. App A can now customize the SP. Which Templates E.g., Base + Locking Which storage device How much storage Etc. 30

31 Some TCG Storage Use Cases Self Encrypting Drive Management LBA Range Management Locking/Unlocking of LBA Ranges Secure Erase End-of-Life, Repurposing Drive Verification Generic Secure Storage Forensic Logging 31

32 Self-Encrypting Drive Basics The storage device LOCKS when it powers OFF. The storage device remains LOCKED when it is powered back ON. Authentication UNLOCKS the storage device. The storage devices Reads and Writes data normally while drive is unlocked The plaintext data sent to the device is encrypted before being written The encrypted data read from the device is decrypted before being returned Authentication Key Management Service Write Read Here is the P%k5t$ text #&% 100% performance encryption engine in the drive Data protected from loss, disclosure 32

33 Locking SP Creation The Locking SP enables host management of Self Encrypting Drive functionality using the TCG Storage Architecture. The Locking SP incorporates a subset of at least the Base and Locking Templates. Other Templates may be incorporated at issuance to enable additional capabilities. SPInfo SPTemplates Table Column Type MethodID AccessControl ACE C_PIN C_RSA_1024 Authenticate GetACL AddACE RemoveACE GenKey Get Base Template Tables & Methods Authority Certificates Set Next Issuance Locking SP LockingInfo Locking MBRControl MBR K_AES_128 Locking Template Tables & Methods 33

34 Retrieving Configurations An authorized User can, access control permitting, read device information and configurations from the Admin SP, and locking configurations from the Locking SP. Application communication with different SPs is performed using separate sessions. Storage Device Admin SP Auth. Org 1 M User password User authenticates to the SP and retrieves configuration information using App A. Locking SP Get App A App A invokes Get to retrieve configurations. M 34

35 LBA Range Encryption & Locking The storage device can have only one SP with Locking capability. Access control to user data can be configured. The storage device will support a certain number of independent ranges of user data. Storage Device Independent encryption and access control for each range. Range 1 Range 2 Range 3 User 1 User 2 Locking SP Locking Table App A App A is responsible for configuring encryption and access control for all users Auth. M M There can only be one Locking SP per Storage Device. 35

36 Locking Ranges The Locking SP enables independent ranges of the user data space to be separately configured for read/write access control by an authorized and authenticated user (typically an Administrator). Storage Device Separately configured portions of user data space Range 1 Range 2 Range 3 User password User authenticates to the SP and configures the ranges using App A. Locking SP Locking Table Set App A App A invokes Set to configure the starting address and length of each range. M M Range settings are stored in the Locking table. 36

37 Configuring Passwords Each user can be assigned a separate password that is used for authentication to the Locking SP. Storage Device Range 1 Range 2 Range 3 User password User authenticates to the SP and configures the password using App A. Locking SP C_PIN Table Set App A App A invokes Set to change the password. M M Passwords are stored in the C_PIN table. 37

38 Unlocking Ranges The authorized user authenticates with his password and then unlocks the ranges to which she has access. Storage Device Unlocked range Range 1 Range 2 Range 3 User password User authenticates to the SP and changes unlocks the ranges to which she has access using App A. Locking SP Locking Table Set App A App A invokes Set to change the locking values of the appropriate ranges. Auth. M M Range settings are stored in the Locking table. 38

39 Secure Erase The Locking SP provides the users with the ability to erase data, securely and quickly, by replacing the encryption key for a range with a new key randomly generated securely in the drive. This ability can be assigned based on security policy and device capability. Storage Device New encrypting key for the range Range 1 Range 2 Range 3 User password User authenticates to the SP and erases the range using App A. Locking SP K_* Table GenKey App A App A invokes GenKey to generate a new key for the range. Auth. M M 39

40 Incorporating Additional Features The basic Locking SP can be enhanced by incorporating additional Templates or a larger subset of the Base Template at issuance. SPInfo SPTemplates Table Column Type MethodID AccessControl ACE C_PIN C_RSA_1024 Authenticate GetACL AddACE RemoveACE GenKey Get Base Template Tables & Methods Authority Certificates Set Next Issuance Locking SP LockingInfo Locking MBRControl MBR K_AES_128 Locking Template Tables & Methods Random Sign Crypto Template Methods 40

41 Locking SP Random Method With the Crypto Template s Random method activated at Issuance, the Locking SP can provide additional functionality for the host. The Random method allows the host to retrieve random bytes generated by the device s RNG. Storage Device Locking SP Random User App A password User authenticates to the SP and retrieves random bytes using App A. App A invokes Random to request randomly generated bytes from the device. Auth. M 41

42 Locking SP Sign Method With the Crypto Template s Sign method activated at Issuance, the Locking SP can provide additional functionality for the host. The host can verify a device by having the device sign a host-generated challenge. Storage Device Locking SP Auth. C_RSA_* Table M Sign User App A password User authenticates to the SP requests that the device sign a challenge. App A invokes Sign and sends a nonce, which the device will sign using its private key. The signed nonce validates the device to the host. 42

43 Interface Interactions Storage Interface Interactions Subgroup Define a support document for Core Spec and SSCs Maps Core Spec defined resets to associated interface resets Maps TCG-based interface command errors in IF-SEND/IF-RECV to associated interface errors Provides common place for reference 43

44 Security Subsystem Classes Storage Security Subsystem Class = SSC Storage Architecture Core Specification HDD SSC - Notebook HDD SSC - Enterprise Optical SSC (OSSC) 44

45 Optical SSC Goal transparent compatible ease of use unobtrusive FDE 45

46 Other Uses (Home banking, remote medical, Trusted Platform with Trusted Storage -Multi-factor authentication: password, biometrics, dongles -Secure/hardware storage of credentials, confidential financial/medical data -Trusted life cycle management of personal information -Integrity-checking of application software -Cryptographic functions for storage and communications security -Trusted/secure computation of high-value functions (protection from viruses/etc) 46

47 Enterprise Management of Self Encrypting Drives SP FDE Enterprise Server: Key generation and distribution Key/Password archive, backup and recovery Laptop (Application): Master/User passwords, multi-factor authentication, TPM support Secure log-in, Secure Fast Erase Self Encrypting Trusted Drive: Disk or sector encryption, sensitive credential store, drive locking 47

48 The Future Encryption Automatic performance scaling, manageability, security Standards-based Multiple vendors; interoperability Unified key management Handles all forms of storage 48

49 Thank You! 49

50 Q&A / Feedback Please send any questions or comments on this presentation to SNIA: tracksecurity@snia.org Many thanks to the following individuals for their contributions to this tutorial. - SNIA Education Committee Robert Thibadeau Michael Willett All Storage Manufacturers (contributors) 50