IEEE Security in Storage Working Group 1 Overview of the IEEE Security in Storage Working Group (SISWG) Matt Ball, SISWG Chair August 19, 2008 (As presented at Crypto 2008)

IEEE Security in Storage Working Group 2 Outline l History and scope of SISWG l P1619 – “Narrow Block Encryption” l LRW – Why a proof isn’t good enough l XTS – Under consideration for FIPS l P – “Authenticated Encryption” l GCM, CCM, CBC-HMAC, XTS-HMAC l P – “Wide Block Encryption” l EME2, XCB l P – “Key Management”

IEEE Security in Storage Working Group 3 SISWG History l Formed June 2002 l Created through a joint sponsorship by: l Information Assurance (Jack Cole, Chair) l Storage Systems (Curtis Anderson, Chair) l Founding Officers: l Jim Hughes, StorageTek – Chair l Serge Plotkin, Stanford/Decru – Vice-Chair l Clement Kent, Kasten Chase – Secretary

IEEE Security in Storage Working Group 4 SISWG Scope l This working group is chartered to develop standards for cryptographic algorithms and methods for encrypting data before it is sent to the storage (disk or tape) device. This will include the algorithms and modes to create interoperable solutions. 2) Create Common Criteria Protection Profiles

IEEE Security in Storage Working Group 5 SISWG Current Officers l (Current as of early 2007) l Chair: Matt Ball, Independent/Sun Microsystems l Vice-Chair: Eric Hibbard, Hitachi Data Systems (HDS) l Secretary: Fabio Maino, Cisco Systems l P Chair: Jim Hughes, Sun l P Chair: Walt Hubis, LSI Logic

IEEE Security in Storage Working Group 6 IEEE SISWG Organization IEEE Computer Society Information Assurance (IA) Jack Cole, Chair Security in Storage Working Group (SISWG) Matt Ball, Chair Eric Hibbard, Vice Chair Fabio Maino, Secretary P1619 (Done) (Disk Encryption) Serge Plotkin, Chair and Editor P (Done) (Tape Encryption) Matt Ball, Chair and Editor P (Wide Encryption) Jim Hughes, Chair Fabio Maino, Editor P (Key Management) Walt Hubis, Chair Bob Lockhart, Editor Storage Systems (SS) Curtis Anderson, Chair

IEEE Security in Storage Working Group 7 IEEE P1619 Cryptographic Protection of Data on Block-Oriented Storage Devices

IEEE Security in Storage Working Group 8 P1619 Outline l Overview – lofty goals l The fall of EME l The fall of LRW l XTS – We finally get it right l NIST consideration of XTS

IEEE Security in Storage Working Group 9 P1619: “Narrow Block Encryption” l Started in June 2002 along with formation of SISWG l Initially created for: l Storage encryption l Key management and key interchange l Common Criteria Protection Profiles l Completed in Dec 2007 with a narrow block encryption mode (XTS) and XML key interchange format

IEEE Security in Storage Working Group 10 EME (ECB Mix ECB) l EME is a wide-block pseudo-random permutation based on AES l Created by Shai Halevi and Phil Rogaway In 2003 l Broken at Eurocrypt 2003 by Antoine Joux l In 2004, Halevi and Rogaway created a fixed version called EME*, later renamed to EME-2 for P1619.2

IEEE Security in Storage Working Group 11 EME Diagram

IEEE Security in Storage Working Group 12 LRW-AES l LRW-AES proposed by Clement Kent in April l Based on paper by Liskov, Rivest, and Wagner (LRW) that provides a security proof for a “Tweakable block cipher” l Uses an XOR-universal function to tweak plaintext into and ciphertext out of ECB mode AES.

IEEE Security in Storage Working Group 13 LRW-AES Construction AES- ENC KEY1 KEY2 Tweak Plaintext Ciphertext = Mult. in GF(2 128 ) = Bitwise XOR

IEEE Security in Storage Working Group 14 LRW Security Assumptions l Tweak Key (K2) is a random number l AES is an ideal random permutation l Attacker can choose plaintext, ciphertext, and tweak value l Tweak key is created independently of attacker’s chosen plaintext l Attacker cannot choose the same tweak value twice with different plaintext/ ciphertext

IEEE Security in Storage Working Group 15 LRW Security Proof

IEEE Security in Storage Working Group 16 Why The LRW Proof Isn’t Enough l In practice, cannot assume that tweak key and plaintext are independent l Encrypted swap file may contain tweak key as temporary variable l Need stronger assumptions – let the plaintext contain the key l The group abandoned LRW-AES when Niels Ferguson of Microsoft said that he wouldn’t use LRW

IEEE Security in Storage Working Group 17 XTS – Xor-Encrypt-Xor with Tweak and Ciphertext Stealing l XEX first suggest to SISWG by Mart Sõmermaa in Jan l Not adopted until Doug Whiting “Rediscovered” XEX in Sept 2006

IEEE Security in Storage Working Group 18 XTS Diagram

IEEE Security in Storage Working Group 19 XTS Submission to NIST l The period of public comment for this proposal is from June 5, 2008 to September 3, The extract of IEEE Std is available for free during this period. Comments may be submitted to NIST particularly invites comments on the following topics:extract of IEEE Std l The XTS algorithm itself; l The depth of support in the storage industry for which it was designed; l The appeal of XTS for wider applications; l The proposal for the approved specification to be available only by purchase from IEEE; l Concerns of intellectual property rights.

IEEE Security in Storage Working Group 20 IEEE P Authenticated Encryption with Length Expansion for Storage Devices

IEEE Security in Storage Working Group 21 P Authenticated Encryption l Started in Mid Updated June l Completed in Dec 2007 l Specifies 4 authenticated encryption modes: l CCM – Counter with CBC MAC l GCM – Galois/Counter Mode l CBC-HMAC – Cipher block chaining with HMAC l XTS-HMAC – XTS encryption with HMAC

IEEE Security in Storage Working Group 22 CCM – CTR With CBC MAC

IEEE Security in Storage Working Group 23 GCM – Galois/Counter Mode

IEEE Security in Storage Working Group 24 CBC-HMAC

IEEE Security in Storage Working Group 25 XTS-HMAC

IEEE Security in Storage Working Group 26 IEEE P Wide-Block Encryption for Shared Storage Media

IEEE Security in Storage Working Group 27 P1619.2: Wide Block Encryption l Started November 2006 l Scheduled for submission to IEEE before Mar 2009 RevCom meeting l Currently in working group ballot l Includes two modes: EME-2 and XCB l Considered other modes: l ABL4, HCH, HCTR, PEP, TET

IEEE Security in Storage Working Group 28 EME2-AES

IEEE Security in Storage Working Group 29 XCB-AES

IEEE Security in Storage Working Group 30 Considered 2/20099/2009 Published Standard Submitted to IEEE 3/2009 Ballot Review 1/8/2009 Sponsor Letter Ballot 12/2/08 1/1/09 Ballot Review WG Letter Ballot 8/7/08 9/6/08 9/15/2008 P Schedule

IEEE Security in Storage Working Group 31 IEEE P Key Management Infrastructure for Cryptographic Protection of Stored Data

IEEE Security in Storage Working Group 32 P Outline l Project Authorization Request (PAR) l Goals and Priorities l Standards Committee Organization l Messaging and Grammar Options l Architecture Proposals l Other Key Management Standards l Web Links

IEEE Security in Storage Working Group 33 IEEE Project Authorization Request l The IEEE-SA (Institute of Electrical and Electronics Engineers Standards Association) creates internationally recognized standards l Examples l IEEE (Wireless Ethernet) l IEEE 1394 (Firewire) l Each IEEE standards group requires a Project Authorization Request (PAR) to define Title, Scope, and Purpose of standard

IEEE Security in Storage Working Group 34 P Project Authorization Request (PAR) l Title: l Draft Standard for Key Management Infrastructure for Cryptographic Protection of Stored Data l Scope: l This standard specifies an architecture for the key management infrastructure for cryptographic protection of stored data, describing interfaces, methods and algorithms. l Purpose: l This standard defines methods for the storage, management, and distribution of cryptographic keys used for the protection of stored data. This standard augments existing key management methodologies to address issues specific to cryptographic protection of stored data. This includes stored data protected by compliant implementations of other standards in the IEEE 1619 family.

IEEE Security in Storage Working Group 35 P Goals and Priorities 1)Create a standard that allows secure interchange of encryption keys between devices that encrypt stored data and devices that manage keys 2)Understand existing standards and use where possible to expedite the creation of this standard 3)Raise public awareness of P and encourage adoption 4)Facilitate interchange by providing open source reference implementations

IEEE Security in Storage Working Group 36 P Subcommittees CommitteeStart DateCurrentComments ARCH10/2007Complete 3/2008 NS6/2007Complete 1/2008 OO9/200710/2008 (Was 5/2008) Draft in process now. MSG9/2007In ProcessVote in Process for Mandatory Messaging. Allow 60 Days for Optional Protocols.

IEEE Security in Storage Working Group 37 P Model

IEEE Security in Storage Working Group 38 1/2008 3/2008 NS ARCH Ballot Review 1/20096/2009 Final Comments MSG 4/2009 OO 10/200 8 Messaging Vote 8/16/08 9/15/08 60 Days P Schedule

IEEE Security in Storage Working Group 39 Architectural Key Mgmt Model KM Server Storage Medium Data Transfer (outside of KMS) KMCS Ops KMSS Ops Key Backup/Archive KM Server Key Backup/Archive Encryption Entity Storage Medium Encryption Entity KM File Import/Export KMCS Ops Out of Scope Legend File transfer KM Admin In Scope

IEEE Security in Storage Working Group 40 Conceptual Key Mgmt Model KM Server Encryption Entity Cryptographic Unit KM Client Encryption Users KM SW Lib (optional) KM API Storage Media Data Plane KMCS Ops Control Plane Plaintext Data Encrypted Data Out of Scope Legend In Scope KM Client Ops

IEEE Security in Storage Working Group 41 Key Lifecycle Model

IEEE Security in Storage Working Group 42 How to Identify the Key l Each key needs an identifier, called a Security Object Global Unique Identifier (SO_GUID) l Global uniqueness is necessary to allow for integrating two different key shares, or when sharing keys between companies.

IEEE Security in Storage Working Group 43 Security Object Global Unique Identifier (SO_GUID) Proposals l Uniform Resource Identifier (URI) l Name Address Authority (NAA) l Random Number l Locally Assigned l OASIS EKMI GKID (based on IANA Enterprise number)

IEEE Security in Storage Working Group 44 URI-Based SO_GUID l Uses ICANN as the naming authority l Format: l km:// / l Examples: l km://kms.example.org/key/dir1/dir2/key123 l km://example.com/key/dir1/%00%00%EA%05 l km://kms.bigbank.example.com/key/ A0B0C0D0E0F l km://example.net/policy/bizpolicy/storsecpolicy/km spolicy/keypolicy3

IEEE Security in Storage Working Group 45 NAA-Based SO_GUID Bit Octet 'n' (6E 16 ) 1'a' (61 16 ) 2NAA... NAA specific 9 10(MSB) SO_Handle n-1(LSB) ValueDescriptionName AuthorityReference 2IEEE ExtendedIEEE OUIT10/SPC-4 3Locally assignedNoneT10/SPC-4 5IEEE RegisteredIEEE OUIT10/SPC-4 All othersReserved

IEEE Security in Storage Working Group 46 Random Number l Create a ‘probably’ global unique identifier by generating a sufficiently large random number l No need for a naming authority l Lacks metadata l Possibility of collision

IEEE Security in Storage Working Group 47 Locally Assigned SO_GUID l To support existing implementations, we will need to support a ‘locally assigned’ system for describing identifiers l Locally Assigned identifiers have no assurance of global uniqueness, and will need special handling when migrating to new systems.

IEEE Security in Storage Working Group 48 OASIS EKMI Naming Scheme l Global Key Identifier (GKID) format, specified by OASIS EKMI l Components: l Domain Identifier (DID): An 8-byte Private Enterprise Number (PEN) assigned by IANA (check whether it’s 3 bytes) l Server Identifier (SID): An 8-byte locally-assigned value that identifies a particular key manager within the scope of the DID l Key Identifier (KID): An 8-byte locally-assigned value that identifiers a particular key within the scope of the key manager and DID. l Format ek://[DID]-[SID]-[KID]

IEEE Security in Storage Working Group 49 P Objects l Key - A key blob (potentially wrapped) and its metadata l Key Blob - A symmetric key, possibly wrapped, that the cryptographic unit can use l Key_Template - Attributes and policies which may be inherited when creating a key l ENDPOINT_TYPE - An object that describes the capabilities of a KM client or crypto unit l REALM (optional) - Used to segment objects in separate administrative DNS domains l CU (cryptographic unit) - A metadata object that describes the device and its capabilities that uses keys to encrypt data l Client - an object that contains the credentials and capabilities of a KM client l Capability - A string that describes a particular capability of an endpoint (either km client or CU) l Data Sets - A manageable unit of encrypted data (e.g., range of sectors or records) l Client Groups - A group of one or more client objects l Key Groups - A group of one or more key objects l (proposed) Credential object - An authentication object that show proof of knowledge of a password or of a private key, typically by responding to a random challenge.

IEEE Security in Storage Working Group 50 P Policies l Key Assignment Policy - logic to map keys to data sets and cryptographic algorithms l Retention Policy - logic to determine which data is accessible to a client for how long l Wrapping Policy - determines whether a key should be wrapped before sending to a client l Audit Policy - determines the auditing requirements on keys and clients l Access/Distribution Policy - determines which clients and servers have access to keys l Caching Policy - Determines whether a client may cache a key and for how long

IEEE Security in Storage Working Group 51 P Operations l Register Endpoint - operation to register a KM client or CU to a KM server l Authenticate - The KM client or CU proves its identity to the KM server using certs or passwords l Capability Negotiation - The KM client sends its capabilities to the KM server l Get Server Capabilities - The KM server selects capabilities from the list provided by the KM client l Create/Generate Key - KM client passes Key_template to server and requests new key from the KM server l Store Key - Push a key generated by the KM client into the KM server l Get Key - Client requests an existing key from the KM server's key store l Push Audit Message - The KM client pushes a secure audit message into the KM server or other auditing device l Get Random Bytes - The KM server returns cryptographically secure random bytes to the KM client l GetStatus [server initiated] - The KM server asynchronously requests client or CU status from the KM client l UpdatePending [server initiated] - The KM server asynchronously notifies the KM client that the KM server has updated status l GetUpdateList [Client initiated] - Returns a list of updates from the KM server to the KM client (issued by KM client in response to receiving an UpdatePending)

IEEE Security in Storage Working Group 52 P Messaging Options l XML-Based l Raw XML l XML SOAP l XML SOAP using OASIS SKSML l XML SOAP with WS-Management l Binary-Based l Free-form l Structured Tag-Length-Value l ASN.1 Distinguished Encoding Rules (DER)

IEEE Security in Storage Working Group 53 Related Standards l Trusted Computing Group (TCG) – Key Management Services Subgroup (KMSS) l OASIS Enterprise Key Management Infrastructure (EKMI) l Internet Engineering Task Force: KEYPROV (Key Provisioning) l ISO l SNIA SMI-S l NIST SP A

IEEE Security in Storage Working Group 54 Web Links l SISWG Homepage: l l Reflector: l l Security in Storage Workshop (SISW) l l Key Management Summit (KMS 2008) l