IBM Internal Label Encryption Policy for NetBackup Setup and Implementation Version 4 · PDF file · 2011-10-24February 2011 ® IBM® Internal Label Encryption Policy for NetBackup

February 2011

®

IBM® Internal Label Encryption Policy for NetBackup Setup and Implementation

Version 4.0

IBM Americas Advanced Technical Skills

www.ibm.com/support/techdocs

Internal Label Encryption Policy for NetBackup - Setup and Implementation Version 4.0 February 2011

Page 2 of 25 Copyright 2011, IBM Americas Advanced Technical Skills www.ibm.com/support/techdocs

Changes............................................................................................................................... 3 Introduction......................................................................................................................... 4 What Is Internal Label Encryption Policy?......................................................................... 6 What Gets Encrypted using ILEP? ..................................................................................... 7

ILEP Mapping Table for NetBackup.............................................................................. 8 ILEP Mapping Table for NetWorker.............................................................................. 9

Key Label Mapping in the TS3500 and 3494................................................................... 11 Cloning Keys in the Keystore ........................................................................................... 14 Code Requirements for ILEP............................................................................................ 15

Code Requirements for NetBackup ILEP..................................................................... 15 Code Requirements for NetWorker ILEP..................................................................... 16

ILEP User Setup ............................................................................................................... 17 Selection of ILEP Method for Logical Library................................................................. 19 ILEP Encrypted Write Operation – from BOT................................................................. 20 ILEP Read or Write-Append Operation ........................................................................... 20 NetBackup Error Cases..................................................................................................... 21 NetWorker Error Cases..................................................................................................... 22 Determining Encryption Status of a Volume.................................................................... 23 NetBackup vmpool Command.......................................................................................... 24



Changes • Version 2.0

o Add TS1040 (LTO4) encryption support for ILEP • Version 3.0

o Add Internal Label Encryption Policy support for EMC NetWorker o Added 3494 capabilities to the text.

• Version 4.0 o The required delimiter for NetWorker is “#” instead of ‘_’



Introduction A new family of enterprise tape drives was introduced in September of 2003 with the debut of the 3592-J1A. The 3592-J1A offered native tape capacities of up to 300 GB. The second generation drive was introduced in December 2005 with the TS1120 (3592-E05) offering native tape capacities of up to 500 GB. On September 8th, 2006, the TS1120 was enhanced to support encryption in the drive and in December 2006 the JB media was introduced which increased the capacity to 700 GB. On May 6th, 2007 the TS1040 tape drive was introduced along with the 800 GB LTO4 cartridge. The TS1040 drive also supports drive based encryption. Encryption within the drive results in virtually no reduction in performance or capacity. The TS1120 and TS1040 drives support three methods of encryption; Application, System and Library Managed Encryption (AME, SME, LME). The TS1040 drive supported SME and LME starting in June, 2007. Library Managed Encryption (LME) means the policy used to determine which volumes are encrypted and which key labels will be used is determined by a policy at the library. Initially, the LME method only allowed for encryption policy to be based on a volser range. This was called “Scratch Encryption Policy” (SEP). The term “Scratch” is used since the policy applied to writes from BOT which indicates a scratch volume mount. During the TS1120 encryption beta program, a customer was using NetBackup and the LME method with SEP. However, NetBackup organizes data into pools, not in volser ranges. An enhancement to LME was needed to provide an encryption policy that utilizes the NetBackup pools to determine which volumes get encrypted and which key labels to use. This new policy is called Internal Label Encryption Policy (ILEP) and is grouped with the existing LME method. NetBackup has added vendor specific metadata to the VOL1 header it writes to a tape. The NetBackup written header contains a NetBackup signature and a pool ID. The TS1120 and TS1040 drives examine the VOL1 contents looking for the NetBackup signature and pool ID. When recognized, the drive uses the pool ID and the ILEP mode to determine whether to encrypt the volume and which key labels should be used in the encryption process. Since the ILEP method is also a “Scratch Encryption Policy”, the existing volser range policy is renamed to the Barcode Encryption Policy (BEP) because it is based on the volser barcode. Collectively, both ILEP and BEP are referred to as Scratch Encryption Policies. The ILEP architecture is extensible to other storage software. ILEP is now available for EMC NetWorker software also. This document has been updated to include EMC’s NetWorker, referred to as NetWorker in this document. Similar to NetBackup, NetWorker also writes a signature to the VOL1 record along with a pool name that contains an Encryption Control Field (ECF). When recognized, the drive uses the ECF and the ILEP mode to determine whether to encrypt the volume and which key labels should be used in the encryption process.



This document addresses the Internal Label Encryption Policy for NetBackup and NetWorker. The reader should already be familiar with the existing IBM encryption methods. This document does not discuss the key negotiations between the drive and the Encryption Key Manager (EKM).



What Is Internal Label Encryption Policy? Before Internal Label Encryption Policy (ILEP), Scratch Encryption Policy (SEP), now renamed Barcode Encryption Policy (BEP), allowed a TS3500 administrator to define ranges of volsers that are to be encrypted. One or two key labels can be associated with each range. If a volser falls into a range, the data on that volume will be encrypted. For the TS1120, the data key (DK) will be encrypted using the keys referenced by the key labels defined for the range. For the TS1040, the data is encrypted with the DK referenced by the single key label. For some backup/archive software such as NetBackup and NetWorker, volser ranges are not the natural way to group volumes. The application writes metadata, typically in the volume header, that the TS1120 and TS1040 drive automatically uses to determine if a volume’s data is to be encrypted and which key labels to use in the process. The first implementation of ILEP is for Symantec’s Veritas NetBackup. ILEP is a result of a customer request during the encryption beta. IBM worked with Symantec to enhance NetBackup and the IBM encryption solution. Two types of ILEP are available; Selective Encryption and Encrypt All. The second implementation of ILEP is for EMC’s NetWorker. The addition of NetWorker to ILEP is a result of a customer request. IBM worked with this customer to enhance ILEP to support NetWorker. NetWorker itself was not changed to support ILEP. Instead, the tape drive code was enhanced to take advantage of metadata already written to the tape by NetWorker. Two types of ILEP are available; Selective Encryption and Encrypt All. However, for NetWorker, the Encrypt All selection is really an Encrypt-All-But-One function. This will be explained later in this document. ILEP is easily extended to other vendor software. This presentation covers the NetBackup and NetWorker ILEP implementations. Scratch Encryption Policy is now changed to Barcode Encryption policy. All three LME methods are considered Scratch Encryption Policies. Below is an example of changes made to the TS3500 web interface to reflect the change to the name Barcode Encryption Policy from Scratch Encryption Policy.



What Gets Encrypted using ILEP? There are two ILEP modes available; Selective Encryption and Encrypt All. Both methods use the pool ID or pool name written by the application (NetBackup or NetWorker) in the metadata of the volume header to determine whether to encrypt the volume’s data and which key labels to use in the process. For NetBackup, Selective Encryption Mode allows NetBackup to select whether to encrypt a volume’s data as well as which key labels are used when encryption is indicated. As shown in the NetBackup table below, certain ranges of pool IDs indicate no encryption, one range indicates encryption and to use the default Encryption Key Manager (EKM) key labels, and another range indicates encryption and to construct one or two key labels based on the pool ID. For NetWorker, Selective Encryption Mode allows NetWorker to select whether to encrypt a volume’s data as well as which key labels are used when encryption is indicated. As shown in the NetWorker table below, when an invalid, out of range, or no Encryption Control Field (ECF) is provided, or the ECF ends in “#U999”, no encryption is performed. If the ECF ends with a recognized value (not #U999) encryption is performed. One range of values will use the default EKM key labels, and the other values will cause the drive to construct one or two key labels based on the last characters in the ECF. The ECF will be described later. For NetBackup, Encrypt All Mode allows NetBackup to always request encryption and to specify which key labels to use. Some ranges indicate the default EKM key labels should be used and other ranges indicate one or two key labels should be constructed based on the pool ID. For NetWorker, Encrypt All Mode allows NetWorker to request encryption for all but two cases. The mode is the same as the Selective Encryption Mode except for the case where the ECF is invalid, out of range, or not provided. In this case the drive will generate a special “NOTAG” key label or labels. If the Keystore has keys with this label, encryption will occur. However, the intended use of the “NOTAG” key label is to flag jobs that have not updated their ECF for encryption. If the “NOTAG” key does not exist in the keystore, the write will be failed and thus the job will be failed. This allows the customer to flag all jobs that have not been altered for encryption. When the ILEP method indicates EKM default key labels should be used, the user must have set up the default key labels at the EKM. The default EKM key labels can be specified per drive (TS1120 only) or on a global basis (EKM global default key).



ILEP Mapping Table for NetBackup This table is stored in the drive. Based on this table and the ILEP mode the drive is set to, the drive determines whether to encrypt and which key labels should be used.

ILEP for NetBackup

NetBackup Selective Encryption Mode

NetBackup Encrypt All Mode

Pool ID Range Keys Used Keys Used 0000 not encrypted EKM default key labels

0001 – 1499 not encrypted EKM default key labels 1500 – 1999 EKM default key labels EKM default key labels 2000 – 9999 mapped labels from pool_ID

TS1120 internal_label_nbu_poolID_a internal_label_nbu_poolID_b

TS1040 il_nbu_poolID

mapped labels from pool_ID TS1120

internal_label_nbu_poolID_a internal_label_nbu_poolID_b


other (> 9999) not encrypted mapped labels from pool_ID TS1120

internal_label_nbu_poolID_a internal_label_nbu_poolID_b


no recognized label

not encrypted EKM default key labels



ILEP Mapping Table for NetWorker NetWorker writes a signature to the VOL1 record to indicate the tape is being written by NetWorker. NetWorker also writes a pool name in the VOL1 record. The pool name may be of any length up to 128 characters allowed by NetWorker, but the last 4 digits of the pool name will be used as an Encryption Control Field (ECF). The pool name has the form: poolnameofuserchoice#LDDD

• The Encryption Control Field is the last four digits of the pool name after the required ‘#’ delimiter

• Where L is a letter (a-z, A-Z) and DDD is a decimal number (000-999). • The drive has no case sensitivity on the ECF



ILEP for

NetWorker NetWorker Selective

Encryption Mode Networker Encrypt All Mode

ECF LDDD Keys Used Keys Used Invalid, Out of Range, No ECF

Provided

Not encrypted The drive will attempt to encrypt with Fixed Key labels

generated as follows:

TS1120: internal_label_nw_notag_a

internal_label_nw_notag_b

LTO-4 :

il_nw_notag

As long as a key with this label is not populated in the attached keystore, an error is generated and the drive halts. The user

may choose to populate a key with this label to encrypt, map this label to another key label using the 3584/3494 mapping

table to encrypt with a different key, or leave

unpopulated for error behavior (halt and post error)

L = A-T DDD = 000

EKM default key labels EKM default key labels

L = A-T DDD = 001-999

mapped labels from ECF TS1120

internal_label_nw_LDDD_a internal_label_nw_LDDD_b

TS1040 il_nw_LDDD

mapped labels from ECF TS1120

internal_label_nw_LDDD_a internal_label_nw_LDDD_b

TS1040 il_nw_LDDD

U999 Not Encrypted Not Encrypted



Key Label Mapping in the TS3500 and 3494 For ILEP, if the pool ID and drive ILEP mode indicate a key label should be constructed; one or two key labels are constructed. Key labels are generated by the TS1120 drive by taking the drive generated ASCII string (internal_label_nbu_ or internal_label_nw_), and for the TS1040 drive one key label is generated by taking the drive generated ASCII string (il_nbu_ or il_nw_), followed by the ASCII representation of the decimal digits of the Pool ID with no leading zeroes for NetBackup, or the ECF for NetWorker. For the TS1120 the constructed key labels are also followed by "_a" for the first key label and "_b" for the second key label. For the TS1040, nothing is added past the pool ID or ECF. Examples of constructed labels include:

internal_label_nbu_3505_a and internal_label_nbu_3505_b (for NetBackup pool ID 3505, TS1120 drive)

internal_label_nw_m105_a and internal_label_nw_m105_b (for ECF m105, TS1120 drive)

il_nbu_3505 (for pool ID 3505, TS1040) il_nw_p107 (for ECF p107, TS1040)

The TS3500 and 3494 each provide a function which allows a constructed key label to be translated into a user defined key label. When a key label is constructed by the drive, the one or two key labels are passed to the library for key mapping as determined by the key mapping table in the library, and subsequently passed back to the drive for transfer to the EKM for key selection. This function is useful if the customer wants to use more meaningful key labels in their keystore. Also, multiple constructed key labels can be mapped to a single key label. This reduces the number of key labels required at the EKM. It is essential the keystore contain keys with key labels that match the mapped key labels as well as constructed key labels that do not have a key label mapping. For example, two keys with key labels of internal_label_nbu_4201_a and internal_label_nbu_4201_b, or their mapped key label name equivalents, must exist in the keystore if the NetBackup Pool ID 4201 is specified in the metadata of the volume header of a NetBackup written 3592 cartridge. For example, the user can use the Key Label Mapping Table function to map constructed keys as follows:



Pool ID or

ECF

Constructed “A” Key Label built by drive

Mapped Key Label in

Library Key Mapping

Table

Constructed “B” Key Label built by drive

(3592 only)

Mapped Key Label in

Library Key Mapping

Table 3000 internal_label_nbu_3000_a system_1 internal_label_nbu_3000_b vendor_2 3001 internal_label_nbu_3001_a system_1 internal_label_nbu_3001_b vendor_2 3002 internal_label_nbu_3002_a No mapping internal_label_nbu_3002_b No mappingm105 internal_label_nw_m105_a system 1 internal_label_nw_m105_b vendor_2 m106 internal_label_nw_m106_a system 3 internal_label_nw_m106_b vendor_1 m107 internal_label_nw_m107_a No mapping internal_label_nw_m107_b vendor 3 4000 il_nbu_4000 system_2 N/A 4001 il_nbu_4001 system_2 N/A 4002 il_nbu_4002 No mapping N/A p507 il_nw_p507 system 2 N/A p508 il_nw_p508 system 3 N/A p509 il_nw_p509 No mapping N/A

In this case, keys must exist in the key store with the key labels:

system_1 system_2 system_3 vendor_1 vendor_2 vendor_3 internal_label_nbu_3002_a internal_label_nbu_3002_b internal_label_nw_m107_a il_nbu_4002 il_nw_p509

Below is a TS3500 web specialist screen shot for Key Label Mapping. The 3494 screen is similar. Refer to the 3494 Operator Guide for details specific to the 3494 panels. This is basically a From/To panel. Previously entered labels can be recalled making entry of a new label easier. Using this recall control a previously entered value, such as internal_label_nbu_3000_a, can be recalled and easily changed to internal_label_nbu_3001_a while still using the same user defined key label. When a map to a key label is defined, the key label encryption method must also be defined. There are 5 methods available, three that are associated with 3592 media and two that are associated with the LTO4 media.



• Wrapped-Default: The map-to key encryption method will be configured using the encryption key manager default. (3592 cartridges only)

• Wrapped-Clear: The externally encoded data key (EEDK) is referenced by the specified key label. (3592 cartridges only) The Clear method is typically specified when encrypted volumes are kept in house where each keystore references the keys using the same key labels.

• Wrapped-Hash: The EEDK is referenced by a computer value which corresponds to the public key that is referenced by the specified key label. (3592 cartridges only) The Hash method facilitates exchange with a business partner or when volumes are sent to a disaster recovery site where the key labels may be different for the same key.

• Direct-Default Set: The map-to label will be determined from the encryption key manager symmetricKeySet. (LTO cartridges only)

• Direct-Specific: The specified key label references a symmetric data key. (LTO cartridges only)

An SK/ASC/ASCQ (Sense Key/Additional Sense Codes/Additional Sense Code Qualifier) and FSC (Fault System Code) will be sent back to the application (NetBackup or NetWorker) in the case of a failure. Refer to IBM System Storage TS1120 Tape Drive 3592 SCSI Reference GA32-0562 (dated 09/08/2006 or later) for a definition of the new codes.



Cloning Keys in the Keystore An alternative to the Key Label Mapping function on the TS3500 or 3494 is to associate multiple Key Labels to a single Key or Key pair at the keystore. Some keystores provide an easy mechanism to do this. The example below is for the software keystore JCEKS (Java Cryptographic Extensions KeyStore) which provides a cloning a key function. For example JCEKS keytool provides a keyclone command:

-keyclone {-alias alias} [-dest dest_alias] [-keypass keypass] [-new new_keypass] {-storetype storetype} {-keystore keystore} [-storepass storepass] [-provider provider_class_name] {-v} {-Jjavaoption}

This creates a new keystore entry, which has the same private key and certificate chain as the original entry. In the example table below, the key labels of type _a or _b will actually end up using the same pair of keys.

Key Label 1 Desired Key Label

1

Key Label 2 Desired Key Label

2 internal_label_nbu_3000_a Key 1 internal_label_nbu_3000_b Key 2 internal_label_nbu_3001_a Key 1 internal_label_nbu_3001_b Key 2 internal_label_nbu_3002_a Key 1 internal_label_nbu_3002_b Key 2 internal_label_nbu_3003_a Key 1 internal_label_nbu_3003_b Key 2 internal_label_nw_m105_a Key 1 internal_label_nw_m105_b Key 2

il_nbu_4001 Key 3 N/A il_nbu_4002 Key 3 N/A il_nw_p507 Key 3 N/A



Code Requirements for ILEP ILEP requires updates to several of the system components. Sections for both NetBackup and NetWorker are included below.

Code Requirements for NetBackup ILEP ILEP for NetBackup requires updates to several of the system components. A Maintenance Pack (MP) is required for NetBackup. For NetBackup 5.1, MP6 or higher is required. For NetBackup 6.0, MP4 or higher is required. Without the update, NetBackup automatically assigns the next sequential pool number when a pool is created. This doesn’t allow the administrator to control the pool number, thus there is no control for encryption. The update allows the administrator to assign a name to a specific pool ID when a pool is created. The administrator will decide if this pool should encrypt based on the pool ID as described earlier in this document. The NetBackup Command Line Interface (CLI) must be used for this new functionality. The CLI command definition appears later in the document. A code update is required for the TS1120 tape drive. The minimum drive code level is D3I1_A27. This new code adds the support for ILEP for NetBackup. The drives in a logical library can now also be set to one of the two ILEP modes, selective and all. All drives within a logical library are set to the same encryption method. The ability for the drive to recognize the NetBackup signature and pool ID as well as to construct the key labels is added. Also, the drive will ask the TS3500 or 3494 if key label mapping is available for the constructed key labels. A code update is required for the TS1040 tape drive. The minimum code level is designated df070509_7590. The TS3500 and 3494 code is updated to support the ILEP. For the TS1120 the TS3500 6830 code level is the minimum level required (R6C release) to support ILEP. For the TS1040 the TS3500 7260 code level is the minimum level required (R7A’) to support ILEP. The logical library configuration panels are updated to support the two forms of ILEP. Also, the constructed key mapping panel is added. For the 3494 the minimum code level is 535.03 to support key label mapping For the TS1120 there are no code changes are required for the EKM, Keystore or Crypto Services. For the TS1040 EKM Version 2 is required in order to support symmetric keys. Also make sure your keystore supports symmetric keys if you are using the TS1040 drive. Refer to the latest version of the IBM Encryption Key Manager Introduction, Planning and User’s Guide for more information.



Code Requirements for NetWorker ILEP ILEP for NetWorker requires updates to several of the system components. The TS1120 drive supports NetWorker header record levels MREC_VER5 and MREC_VER6, but will attempt to find the pool name in other versions (if there are any) by looking for the "volume pool" entry according to that aspect of the format from v5 and v6. A code update is required for the TS1120 tape drive. The minimum drive code level is D3I1_D12. This new code adds the support for ILEP for NetWorker. The drives in a logical library can now also be set to one of the two ILEP modes, selective and all. All drives within a logical library are set to the same encryption method. The ability for the drive to recognize the NetWorker signature and pool name with ECF as well as to construct the key labels is added. Also, the drive will ask the TS3500 or 3494 if key label mapping is available for the constructed key labels. For the 3494 the minimum code level is 535.03 to support key label mapping. A code update is required for the TS1040 tape drive. The minimum code level is designated: DF080528a_85V1. The TS3500 code is updated to support the ILEP. For the TS1120 the TS3500 6830 code level is the minimum level required (R6C release) to support ILEP. For the TS1040 the TS3500 7260 code level is the minimum level required (R7A’) to support ILEP. The logical library configuration panels are updated to support the two forms of ILEP. Also, the constructed key mapping panel is added. For the TS1120 there are no code changes are required for the EKM, Keystore or Crypto Services. For the TS1040 EKM Version 2 is required in order to support symmetric keys. Also make sure your keystore supports symmetric keys if you are using the TS1040 drive. Refer to the latest version of the IBM Encryption Key Manager Introduction, Planning and User’s Guide for more information.



ILEP User Setup To use ILEP, the user needs to setup the following:

Planning is always first:

1. Decide which ILEP method you plan to use; Selective or Encrypt All 2. Decide which pool IDs or ECFs you plan to use. 3. Determine how many keys and key labels you need. 4. Map constructed key labels to user friendly labels, if so desired.

At the TS3500 web interface: 1. Configure Logical Library for Library Managed Encryption.

1. Barcode (default) – defined using Barcode Encryption Policy 2. Internal Label – Selective Encryption 3. Internal Label – Encrypt All

2. Setup EKM IP addresses. This is the same as today. 3. Create key label mappings if desired.

At the 3494 web interface:

1. Configure the appropriate drives for Library Managed Encryption. a. Barcode (default) – defined using Barcode Encryption Policy b. Internal Label – Selective Encryption c. Internal Label – Encrypt All

2. Setup EKM IP addresses. This is the same as today. 3. Create key label mappings if desired.

At NetBackup: 1. Define pools for encryption and non-encryption. For encrypting pools determine

which pools will use the default EKM key labels and which will use the constructed key labels.

2. Policies need to be created to assign volumes to pools that meet encryption requirements.

3. Plan how you will handle existing pools that were created before ILEP was implemented.

At NetWorker:

1. Alter jobs to define the “#LDDD” ECF for the pool name. 2. Plan how you will handle existing pools that were created before ILEP was

implemented.

At EKM/Keystore: 1. Load/create required keys and associated key labels. All key labels that can be

generated by the ILEP method must have a corresponding key and key label. 2. For TS1120 drives, two key labels must be specified for each Pool ID/ECF

requiring a constructed label without a mapping.



3. For TS1040 drives, one key label must be specified for each Pool ID/ECF requiring a constructed label without a mapping.

4. Default keys must be specified in the EKM if default key pool ID/ECF ranges are to be used, or the key mapping function maps a constructed key label to the EKM defaults.

Here is a summary of activities requiring user entry or code updates. All of these steps need to be completed before using ILEP encryption.

• The NetBackup Maintenance Pack needs to be applied (If using NetBackup). • For NetBackup, create the pools using admin entered pool IDs based on

encryption needs • For NetWorker update jobs to include the “#LDDD” ECF at the pool name. • Update the code in the drive. • Update the TS3500/3494 code. • At the TS3500 web specialist setup the logical Library for ILEP, either Selective

or Encrypt All. • At the 3494 set the appropriate drives to ILEP, either Selective or Encrypt All. • At the TS3500/3494 web specialist setup Key Label Mapping if desired. • At the EKM/Keystore add/create the new key and associated key labels.



Selection of ILEP Method for Logical Library The drives are configured for ILEP at the TS3500/3494 web interface. For the TS3500, the ILEP mode is selected for a logical library. All the drives in the logical library are set to the selected ILEP mode. For the 3494 each drive can be individually set to the selected ILEP mode. This screen shot shows the setting of a logical library to one of the 3 LME methods in a TS3500. The setting of encryption method for drives in a 3494 is similar. Refer to the 3494 Operator Guide for details. On the TS3500 or 3494, when Library Managed is selected, 3 sub-selections appear:

• Barcode (default) • Internal Label – Selective Encryption • Internal Label – Encrypt All

All three of these methods are considered Scratch Encryption Policies.



ILEP Encrypted Write Operation – from BOT The following is the sequence of events that occur when a write from Beginning of Tape (BOT) occurs when ILEP is the encryption policy.

1. Tape is mounted. 2. NetBackup/NetWorker issues write command and transfers first block (media

header) to the tape drive. The header includes the NetBackup/NetWorker signature and pool ID/pool name with ECF.

3. The tape drive recognizes the NetBackup/NetWorker signature in the header, parses the Pool ID/pool name with ECF field, and determines the desired encryption policy and key label selection from the Encryption Mode settings and the pool ID/ECF encryption table.

4. The tape drive either proceeds without encryption or proceeds with encryption using the default EKM key labels or proceeds with encryption by building one or two constructed key labels.

5. If constructed key labels are used, the tape drive sends one or two constructed key labels to the TS3500/3494 library.

6. The library returns either mapped key labels (if a mapping is defined for the received constructed label) or the original constructed key labels if no mapping is available.

7. The drive uses the received key labels to build and send a Data Key request to the EKM with the applicable key labels; constructed, mapped or EKM default keys.

8. Encryption proceeds as it does today.

ILEP Read or Write-Append Operation For a read or write-append operation, the decryption/encryption occurs as it does today. ILEP is not involved. For the TS1120 drive, the Externally Encrypted Data Key (EEDK) is passed to the EKM for unwrapping. The EKM returns the unwrapped Data Key (DK) (in a secure manner) to the drive. The drive uses the DK to either write append or read data from the volume. For the TS1040 drive, the key label is passed to the EKM. The EKM retrieves the Data Key associated with the key label and returns the Data Key (DK) (in a secure manner) to the drive. The drive uses the DK to either write append or read data from the volume.



NetBackup Error Cases This section covers error cases involving NetBackup and ILEP. These error cases apply when the logical library is set to either one of the ILEP modes. If the header in the first record written to a drive does not contain the NetBackup signature, the action taken depends upon the ILEP encryption mode as follows:

• If Selective Encryption is selected, the drive will not encrypt. • If Encrypt All is selected, the drive will encrypt using the default EKM key labels.

Regardless of the ILEP mode, when the NetBackup signature is recognized and the pool ID can be read, one or two constructed key labels, or their key label mappings must exist in the EKM/Keystore. If they don’t, the write is failed with a permanent write error and appropriate SK/ASC/ASCQ. If the key request completes successfully, but the subsequent cartridge reformat or first block write fails, a permanent error is reported with the appropriate SK/ASC/ASCQ. Refer to IBM System Storage TS1120 Tape Drive 3592 SCSI Reference GA32-0562 (dated 09/08/2006 or later) for a definition of the new codes.



NetWorker Error Cases This section covers error cases involving NetWorker and ILEP. These error cases apply when a drive is set to either one of the ILEP modes. If the header in the first record written to a drive does not contain the NetWorker signature, the action taken depends upon the ILEP encryption mode as follows:

• If Selective Encryption is selected, the drive will not encrypt. • If Encrypt All is selected, the drive will encrypt using the default EKM key labels.

Regardless of the ILEP mode, when the NetWorker signature is recognized and the pool name can be read and the last 5 characters are in the form of an ECF (“#LDDD”), one or two constructed key labels, or their key label mappings must exist in the EKM/Keystore. If they don’t, the write is failed with a permanent write error and appropriate SK/ASC/ASCQ. For the Selective Encryption Mode, when the NetWorker signature is recognized but the pool name/ECF is invalid, out of range, or doesn’t exist, the drive will not encrypt. For the Encrypt All Mode, when the NetWorker signature is recognized, but the pool name/ECF is invalid, out of range, or doesn’t exist, the drive will generate “notag” key labels. If the “notag” labels exist in the keystore, or are mapped to keys that exist in the keystore, the drive will encrypt using the keys associated with the “notag” key labels. If the “notag” labels do not exist in the keystore, the write is failed with a permanent write error and appropriate SK/ASC/ASCQ. If the key request completes successfully, but the subsequent cartridge reformat or first block write fails, a permanent error is reported with the appropriate SK/ASC/ASCQ. Refer to IBM System Storage TS1120 Tape Drive 3592 SCSI Reference GA32-0562 (dated 09/08/2006 or later) for a definition of the new codes.



Determining Encryption Status of a Volume Determining the encryption status of a volume in the TS3500/3494 is not specific to ILEP. The methods are described here for your convenience. The TS3500/3494 and the TS1120 drive can be used to determine the encryption state of a volume. The TS3500 should be used to determine a cartridge’s encryption for the TS1040 drive.

• The TS3500/3494 web interface is the best method to determine the encryption state of a volume. The cartridge search results panel displays the encryption status of a volume. Upon insert the encryption state is indicated as unknown. Once the volume is mounted and subsequently unloaded, the status is updated to indicate encrypted or not encrypted. This applies to both TS1120 and TS1040 cartridges.

• The TS1120 indicates the encryption status of the volume currently mounted. • When encrypted, the front panel places a small “e” in the left most

character position of the 8 character display. If it is an encrypted worm tape there is a crown or “w” over the “e”.

• The TS1120 maintenance panel displays 2 or 3 characters on the second line in the upper right of the display. If the first character is a small “e” the volume is encrypted. The other 2 characters indicate media format (J1A=1 or E05=2) and the media type (A, B, J, R, W, X).



NetBackup vmpool Command This section contains the documentation for the vmpool command that is used to define a pool ID and name. This is documentation from Symantec. vmpool [-pnum < pool number> ] -add < pool_name> "< description> " < host> < uid> < gid>

The -pnum option must be specified before the -add option. The -pnum has no effect when the -change option is specified.

vmpool - Manage volume pools SYNOPSIS /usr/openv/volmgr/bin/vmpool [-h EMM_server | volume_database_host] -listall [-b] | -listscratch | -list_catalog_backup_pool | -add pool_name "description" host uid gid | -change pool_name "description" host uid gid | -delete pool_name | -set_scratch pool_name | -unset_scratch pool_name | -set_catalog_backup_pool pool_name | -unset_catalog_backup_pool pool_name DESCRIPTION Use this command to add, change, delete, or list volume pools. The -h option is not required, but you must choose one and only one of the other seven options (for example, -listscratch). This command can be executed by any authorized users. For more information about NetBackup authorization, refer to "Enhanced Authorization and Authentication" in the NetBackup System Administrator's Guide or the NetBackup Media Manager System Administrator’s Guide. OPTIONS -h EMM_server | volume_database_host This option is only applicable for NetBackup Enterprise Server. The name of the Enterprise Media Manager database host which contains information about volumes. If no host is specified, the configured EMM server is used by default. For communicating with pre-6.0 systems not in the EMM domain, this is the EMM server. -listall [-b] List information about all volume pools. You can use the -b option to specify a brief format for volume pool information. -listscratch List all configured scratch pools. -list_catalog_backup_pool Lists the volume pool to be used for catalog backup. -add pool_name "description" host uid gid Add a new volume pool. -change pool_name "description" host uid gid Change an existing volume pool. -delete pool_name Delete a volume pool. “description” Description of the volume pool. The double quote marks are required if the description contains any spaces. host Name of the host that will be permitted to request and use volumes in this volume pool. The following applies only to NetBackup Enterprise Server: To permit only a specific host to access the volume pool, enter the name of



that host. To permit any host to access the volume pool, enter ANYHOST. Using the value ANYHOST is recommended. The following applies only to NetBackup Server: You can only specify the value ANYHOST. uid Specifies the user id of the user that is permitted to request and use volumes in the volume pool. Enter a specific user id to permit only processes running at that user id, to access the volume pool. Enter the default value, -1 (ANY), to permit any user id to access the pool. For a NetBackup or Storage Migrator volume pool, always enter the user id for root. If you specify a specific user id and a different user id requests the pool, then Media Manager verifies the group id (see gid). gid Enter the group id of the group that is permitted to request and use volumes in this volume pool. Enter a specific group id to permit only processes running as that group id, to access the volume pool. Enter the default value, -2 (NONE), to permit only the user id specified by uid to request or access the volume pool. -set_scratch pool_name If pool_name is a previously defined volume pool, pool_name will become the scratch pool and its description will not be changed. The NetBackup, DataStore, Catalog Backup, and None volume pools cannot be changed to scratch pools. If pool_name is a new volume pool, a new pool will be created with "Scratch Pool" as the description. Only one scratch pool at a time can be defined. -set_catalog_backup_pool pool_name Enables you to use this volume pool to back up the NetBackup catalog. You can also create a dedicated catalog backup pool to be used for catalog policies. A dedicated catalog volume pool reduces the number of tapes needed during catalog restores since catalog backup media are not mixed with other backup media. -unset_catalog_backup_pool pool_name Enables you to define a volume pool that you do not want to use to back up the NetBackup catalog. -unset_scratch pool_name Undefines pool_name as the scratch pool and defines it as a regular volume pool. The pool can be deleted using vmpool -delete pool_name. NOTES Only limited validation of the option parameters is done. uid and gid should only be used for restricting access to volumes by user or by group on UNIX hosts. A pool cannot be both a scratch pool and Catalog Backup. EXAMPLES The following command adds a new pool 3001 named MyPool on the host named llama with the default host, user id, and group id permissions: vmpool –pnum 3001 -add MyPool "my description with spaces" ANYHOST -1 -2 The following command lists all pools configured on the host where the command is executed: vmpool -listall -b

Documents

IBM Internal Label Encryption Policy for NetBackup Setup and Implementation Version 4 · PDF file · 2011-10-24February 2011 ® IBM® Internal Label Encryption Policy for NetBackup