1. © 2006 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice HP Library Encryption - LTO4 Key Management API

2. 2 Tools Systems Overview Objectives Architecture

3. 3 HP KM API Objectives Objectives Objective 1 is to securely manage key generation policies in the KMA −But minimize library knowledge by the KMA Objective 2 is a standardized key management interface for each library, regardless of the key manager. KMA sets and maintains policy, and library enforces policy.

4. 4 Architecture

5. 5 HP KM API Architecture HP’s KM API lives between the Key Transport (client side), and the Key Mgmt Plug-in (server side) Server-side is a driver, containing KMA-specific code −Calls KMA functions like “create key”, “retrieve key”, “create log entry” −Over time, this component handles all key managers. The KMA owns the Key Generation Policy (KGP) −SO establishes policy for each library and partition. Library’s Key Mgmt Plug-in enforces the KGP Key is always encrypted between library and KMA −Normally via SSL or HTTPS −But key can also be separately encrypted Key Mgmt Plug-in and KMA would agree on the method

6. 6 Tools HP KM API Use Case

7. 7 Example API Use Case Encrypt data to tape Security officer enrolls, or registers, libraries with the KMA (one-time) Security officer configures KGPs for each library/partition (one-time) −Example: Key per partition, or key per tape Libraries login to KMA, receive their specific KGP. Backup app loads media Library’s Key Transport requests a key, via the Get Key API −Provides identifying data with the request. Library’s Key Mgmt Plug-in requests a key from the KMA −Key Transport loads key into drive Backup app reads or writes data to tape

8. 8 Tools Key Management API Log In, Log Out Get Key Get KMA info Get Policies Get Message Record Event

9. 9 API Log In Parameters: The library properties Returns: A session container Behavior: synchronous (client waits for response from KMA) The library properties contain The unique identifier for the library/partition The current library capabilities −Policies supported −Reporting capabilities −Messaging capabilities

10. 10 API Log In (continued) The session container contains A unique identifier for the session The current policies for the library −Cached or interactive mode (advanced feature) −Events library will record −Frequency to check for new policies (advanced feature) −Distributed policies for key generation (advanced feature) −Key usage policies Directs when or where a key may be used −Clock synchronization policy Logs use library or KMA clock −Key Generation Policy Example: key per tape, key per partition A message indicator −Indicates a message from the KMA is available

11. 11 API Log In (continued) Notes The KMA notifies the library if policies change while it’s logged in −Message field is a method of notification

12. 12 API Log Out Parameters: The library/partition identifier Returns: Status container Behavior: synchronous Status includes Status of the log out operation a message indicator. Notes Logging out will close the session. No further API calls may be placed by the library, until it re- authenticates, and logs in again.

13. 13 API Get Key Parameters: key meta data Returns: a key container Behavior: synchronous (client waits for response) Key meta-data includes −Media identifier(s) −Library/partition ID. 32 bytes, ASCII alpha-numeric. (Library vendor ID and serial number) −Drive ID. 32 bytes, ASCII alpha-numeric. (Drive vendor ID and serial number)

14. 14 API Get Key (continued) A key container includes − the data encryption key Key maybe encrypted separately, or plain text −Key usage restrictions Read-only, for a specific drive, etc. −A message indicator −The container may contain multiple keys (advanced feature)

15. 15 API Get Key (continued) Notes: −Get Key must have very low latency, high reliability −Could return a set of keys to support caching (advanced feature)

16. 16 API Get KMA Info Parameters: Library/partition identifier Returns: KMA information Behavior: synchronous KMA Information includes −KMA Description. Vendor ID, model number, serial number, firmware version of the KMA −KMA Database Status. Current operational state of the KMA database (available, offline, initializing) −KMA time of day information. −KMA physical (data center/site) location −KMA API version. −A message indicator Notes: The API version info must have the same format in all API versions

17. 17 API Get Policies Parameters: library/partition identifier Returns: Policy information for this library Behavior: synchronous Policy information includes The current policies for the library −Cached or interactive mode (advanced feature) −Events library will record −Frequency to check for new policies (advanced feature) −Distributed policies for key generation (advanced feature) −Key usage policies Directs when or where a key may be used −Clock synchronization policy Logs use library or KMA clock −Key Generation Policy Example: key per tape, key per partition A message indicator −All API calls can indicate a message from the KMA is available

18. 18 API Get Policies (continued) Notes: This API returns the same policy information as the login It is used to refresh policy information without closing the session Could be called in response to a policy-changed message on the previous API call The purpose is to allow automatic configuration updates at the libraries in response to changes in KMA policy −Use cases: SO changed partition key, or changed reporting policy

19. 19 API Get Message Parameters: library/partition identifier Returns: Message information Behavior: synchronous Message information includes Message text Message recipient −Example: Service log, key manager A message indicator Notes Advanced feature The KMA can issue messages to the clients, such as ‘policy changed’ or ‘KMA changed’.

20. 20 API Record Event Parameters: Event information Returns: Status Behavior: synchronous Event information includes Originator ID: Library, drive, and media IDs Event type: examples are “key was used”. “Decrypt error”. Event payload: The event message text. Timestamp: SO can select whether to use library’s timestamp, or KMA’s Status (from KMA) includes Number of event bytes recorded Message indicator

21. 21 API Record Event (continued) Notes SO sets reporting policies for the library Library executes the reporting policy Use cases −Record security-related configuration changes (Password changes, firmware updates, component replacements) −Record security-related errors. (decrypt failures, key mismatch, authentication failure) −Records key usage.

22. 22 Tools Supplemental Caching

23. 23 Caching May not be necessary for tape applications −If latencies are acceptable −Can be used if performance becomes an issue Expected to be a requirement for disk/server applications −Key changes may be needed per mount point, per volume, etc. −High performance requirements may not tolerate network latencies, unpredictability Example usage. Cached write-key −A write-key is cached at the library/partition −Is only updated when the policy changes −Library uses cached key without a Get Key call −Reduces latencies in the key-per-library polic