© 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