1. IEEE P1619.3 Architecture Subcommittee Model Update and Discussion November 1, 2007

2. Agenda Discuss updated KM role/layered models Discuss John Holdman’s key lifecycle model Miscellaneous Topics KM Policy Models Data Attribute Models Interaction Models?

3. Proposed KM Role/Layer Models

4. Role/Entity Model KM Server Cryptographic Unit Data Storage Data Transfer (outside of KMS) KMCS Ops KMSS Ops Key Backup KM Backup Ops KM Archive Ops KM Client KM Server Key Archive CU Agent Encryption Application Data Storage Cryptographic Unit KM Client CU Agent Encryption Application

5. Layered Model #1 KM Server Data Storage KM Client CU Agent Cryptographic Unit Plaintext Data Storage I/O Secure Comm Stack Data Plane Control Plane Encryption Service Secure Comm Stack KM Library KM API Encrypted Data Storage I/O Management/Control Network Key Management Service

6. Layered Model #2 KM Server Encryption Application CU Agent Cryptographic Unit KM Client Encryption User KM Library KM API Encryption Application Cryptographic Unit Data Storage Control PlaneData Plane

7. Updated Definitions l Data Plane l Traditional data communications term that refers to the primary data path through a system. In the case of the P1619.3 standard, it is the path that plaintext user data takes through the cryptographic unit before it is placed on the storage media, and visa versa. l Control Plane l Traditional data communications term that refers to the set of components involved in the configuration, control, and management of the data plane. These components are typically not within the data path used for primary data movement and manipulation.

8. Updated Definitions l KM Server l Implements the key management service that manages the complete key lifecycle for keys and security material used to provide cryptographic protection of stored data l Encryption Service l Is the SW and/or HW system that provides encryption services to protect stored data l KM Client l Is the component of the Encryption Service that communicates with the KMS and ensure keys and security material are properly loaded into the cryptographic unit

9. Updated Definitions l KM Library l Is the component of the Encryption Service that implements the KM API, KM messaging service, and KM transport protocol client; used by the KM Client to communicate with the KMS l KM API l The C\C++ and Java bindings that implement the interface to the KM library l Secure Communication Stack l Is the component of the Encryption Service that implements the network communication protocol stack whose services are used to provide secure communication over the internet/intranet; typically, this is the SSL(TLS)/TCP/IP stack

10. Updated Definitions l Cryptographic Unit Agent l Is the component of the Encryption Service that provides the necessary services to allow the KM Client to control the Cryptographic Unit from the control plane l Cryptographic Unit l The hardware and/or software component of the Encryption Service that actually encrypts data before it is placed on the media used to store data and decrypts data after it is retrieved from the media used to store data l Data Storage l The medium/media used to provide persistent data storage, including disk, tape, etc.

11. Proposed Key State/Transition Model See John Holdman’s document/email from 10/12/07

12. Miscellaneous Discussion

13. Key Policy Model l Currently defined under key structures l Sections 4.3.3.3 thru 4.3.3.6 l Do policies need to be defined in section 4? l Or are they more KMS specific (transparent to KM clients) l Do we need to capture the policy diagram in section 4.3.1

14. Data Attributes l Is data attribute model required in section 4? l Or can this be confined to the OO section? l If we include, what attributes to include? l Include a general data object model? l Data objects instantiate a unit of data to protect l Attributes define the unit of data and how it should be protected l Key Policies

15. Interaction Model? l Do we need a simplified interaction model to cover KMC/KMS interactions? l Coupled with data attribute model? l Coupled with policy model? l Or is this confined to OO section?