© 2006 Hewlett-Packard Development Company, L.P.The information contained herein is subject to change without notice

HP Library Encryption - LTO4 Key Management API

Curt Kolovson

StorageWorks Division

2

ToolsSystems OverviewObjectives

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

ArchitectureFC

SAN

Control

LibraryController

FC

Mgmt

FC

Mgmt

ExistingLibrary

Management Software

PublicEth Mgmt

HP ETLA Tape Library

(1..*)

Library Controller(1..1)

KMA(1..1)

Library Management

(1...1)

Web Clients(0..*)

Storage Management

(0..1)

BackupServers

(1..*)

LTO-4 Tape(1..N)

FCP

SOAP

XML on HTTPS(tbd)

XML on HTTPS(tbd)

NoCryptography

Uses or transports key

material

Color Key

FC Interface

Control

FC

Backup Administrator

Security Officer

Library AdministratorEncryption

Key Transport

HPKMAPI

Mgmt

T10 (SCSI) Key Mgmt Commands

T10 (SCSI) Key Mgmt

Commands

IEEE 1619.1 Algorithms

IEEE 1619.1 Algorithms

LTO-4Tape Drive

LTO-4Tape Drive

EncryptionKey Mgmt

Plug-In

IEEE 1619.3 KeyManagement API(in development)

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

ToolsHP 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

ToolsKey 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 InfoParameters: Library/partition identifierReturns: KMA informationBehavior: 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 PoliciesParameters: library/partition identifierReturns: 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 MessageParameters: library/partition identifierReturns: 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

ToolsSupplemental

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