HP Library Encryption - LTO4 Key Management API

1. HP Library Encryption - LTO4 Key Management API Curt Kolovson StorageWorks Division

2. Tools Systems Overview Objectives Architecture

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. Architecture

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. Tools HP KM API Use Case

7. Example API Use CaseEncrypt 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. Tools Key Management API Log In, Log Out Get Key Get KMA info Get Policies Get Message Record Event

9. APILog 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. APILog 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. APILog In (continued) Notes • The KMA notifies the library if policies change while it’s logged in • Message field is a method of notification

12. APILog 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. APIGet 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. APIGet 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. APIGet Key (continued) Notes: • Get Key must have very low latency, high reliability • Could return a set of keys to support caching (advanced feature)

16. APIGet 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. APIGet 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. APIGet 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. APIGet 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. APIRecord 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. APIRecord 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. Tools Supplemental Caching

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