IBM Tape Encryption and TKLM v2.0.1

IBM Tape Encryption and TKLM v2.0.1

Agenda Tape Encryption Overview TKLM – Tivoli Key Lifecycle Manager
TKLM v2.0.1 Enhancements Implementation Considerations Demo Enc Methods – Three approaches IBM architected for tape encryption Enc Process – Key and Data flows, what things actually look like on the cartridge.

IBM Tape Data Encryption
LTO6 / LTO5 / LTO4 Tape Drive Standard feature on all FC & SAS LTO6/5/4 Tape Drives Supports “traditional” and “encrypted” modes of operation TS1140 / TS1130 / TS1120 Tape Drive Standard feature on all new TS11xx Tape Drives TKLM – Tivoli Key Lifecycle Manager AIX, Sun, Linux, Windows and z/OS Serves keys ISKLM – IBM Security Key Lifecycle Manager z/OS Standard feature on all TS1120 drives shipped after 9/8/2006. MES is firmware and new front half of tape drive. LTO4 GAed May 2007 Q1) Encrypt on LTO3 media using the LTO4 drive. Not a technical reason. It could be done. But LTO Consortium decided not to because LTO3 has no knowledge of encryption. A encrypted LTO3 cart could be put in an LTO3 drive and it would return garbage to the application, but it would not know that it was returning garbage. LTO3 could have been enhanced to be encryption aware, but that would have been a substantial development effort. Consortium vendors are working on LTO5 at this point, so there is little interest in spending a lot of development effort on LTO3. If one consortium member decided to do it, they could not use the LTO logo, because the drive would be out of spec. Q2) TS1120 vs LTO4 security. Both drives just require stealing one key to get access to the data. For LTO4 you would need to steal the DK. For TS1120 you would need to steal the private key of the public/private key pair. You can argue that the TS1120 is more secure because the private key never leaves the crypto provider. And having a unique data key per cart provides a small amount of additional security. But by having a significantly large symmetrickeyset, LTO4 can have a unique key per cart. To break the cipher without stealing the key, the TS1120 is more secure. But for practical purposes, the LTO4 design is plenty secure. LTO4 data can be compromised without stealing the key if a Initialization Vector (IV) collision can be detected, but is this a real exposure. The attacker would have to steal and do data reduction on 1000s of carts, possible hundreds of 1000s of carts. The data reduction to find that IV collision would be huge. Maybe something the Soviet Union would attempt to find our ICBM launch code, but not something anyone would attempt to steal SSNs. A much more practical approach would be to bribe the company's security officer. Tivoli Key Lifecycle Manager

FIPS Certification FIPS – Federal Information Processing Standard Cryptographic Service Providers - certified CE2 Card IBM Java Cryptographic Extensions (JCE) Tape Drives TS1120 – Certified TS1130 – Certified TS1140 – In process LTO4 – Certified LTO5 - Certified 3592-E07 will be submitted for FIPS Level 2. It is the tamper-free validation labeling that allows for the Level 2. E06 has been submitted to Atlan, the testing lab. We confirmed the name for the Atlan representative on 8/10/2009 so he could request that the CMVP add 3592-E06 to the "In Process" list E06 should be included when the list is next updated. Federal Information Processing Standard has become important now that the Federal government requires all its cryptographic providers to be FIPS 140 certified. This standard has also been adopted in a growing private sector community. The certification of cryptographic capabilities by a third party in accordance with government standards is felt to have increased value in this security-conscious world. EKM does not provide cryptographic capabilities itself and therefore does not require, nor is it allowed to obtain, FIPS certification. However, EKM takes advantage of the cryptographic capabilities of the IBM JVM in the IBM Java Cryptographic Extension component and allows the selection and use of the IBMJCEFIPS cryptographic provider, which has a FIPS level 1 certification. By setting the fips configuration parameter to on in the Configuration Properties file, you make EKM use the IBMJCEFIPS provider for all cryptographic functions. Note: You should not use hardware-based keystore types when the fips parameter is set on. You can find more information on the IBMJCEFIPS provider and its selection and use at See the documentation from specific hardware and software cryptographic providers for information on whether their products are FIPS certified. Crypto servers: generating keys (symmetric or asymmetric) or encrypting. Keystore=JCEKS + FIPS=OFF = IBMJCE being used as the cryptographic service provider Keystore=JCEKS + FIPS=ON = IBMJCEFIPS being used as the cryptographic service provider Cryptographic Service Providers – entities that create encryption keys (symmetric or asymmetric) or entities that encrypt The only IBM provider that is FIPS certified is IBMJCEFIPS. TS1120 est: 2Q/08 LTO4 est: 4Q/08 From Greg G: Here is the actual FIPS certification status summarized as of last Friday 11/9: IUT (Implementation under test) is the first testing step of the cert process, (date entered step in parens) RP (Review Pending) is the second step; once a component enters RP it generally takes another 10 weeks to complete the additional steps: KeyStore Transport Drive Vendor Component Mechanism Component HP IUT (Recent) ??? IUT (Recent) Secure Key Manager & LTO4 SUN IUT (1Q07) IUT (1Q07) IUT (1Q07) Crypto KMS, Token, & T10000 IBM IBMJCEFIPS FIPS 140-2, Level1 Certified, L2 certification on roadmap for '08 IBM IBM CEX2 (Sz) FIPS Level4 Certified ISV HSMs Many level 3 or 4 for System p & x TS1120 RP (11/9/07) LTO4 IUT (4Q07) JCEKS is FIPS-2 Level 1 certified JCERACFKS is FIPS-2 Level 2 certified JCECCARACFKS is FIPS-2 Level 4 certified JCECCAKS is FIPS-2 Level 3 certified (I believe) TEMS (new name: Thales e-Security keyAuthority) will be Level 3 certified Thales offers a FIPS Level 3 keystore (same FIPS level as RKM (EKM/RSA) and LKM (Decru)). They recently concluded an agreement with Tivoli to OEM in TKLM and they have announced (for GA in probably late 2Q) version 2 of their Thales Encryption Manager for Storage which is a Keystore Appliance. Version 2 will include TKLM and with that integration they plan to support IBM Tape (LTO & TS1100) and disk devices. Thales also supports Brocade switch based encryption (which is available from IBM via RPQ) here's a link to their announcement:

Encryption Methods Library-Managed________ System-Managed________
TS3500, TS3400, TS3310_________ TS3200, TS3100, 3494________ Policy Tivoli Key Lifecycle Manager System-Managed________ z/OS, AIX, Solaris__________ Windows & Linux_________ Policy Policy – Who determines what gets encrypted and what does not get encrypted. For data that gets encrypted, who determines which public key (Key Label) is used. AME / Devclass, SME zOS / DFSMS Data Class, SME Open / Device parameter, LME / Library web interface Key Management – Who generates the data keys. Who manages and controls the key encrypting keys. AME/SME/LME is specified at the Tape Drive. This drive attribute can be updated by the 3584 Web Interface for 3584 environments. It is updated by the CE at the tape drive for 3494, Silo, and Standalone environments. SME and LME are often referred to as Transparent Encryption, in that they are transparent to the host application. This is not completely true. With TSM the customer needs to be on TSM v or v5.4 so that the Device Class parameter DRIVEENCRYPTION can be set to YES. This is required for both SME and LME. For NBU, LME/BEP is transparent, but LME/ILEP is not. For LME/ILEP NBU needs to be at v6.0 MP4 or v5.1 MP5 so that the NBU Admin can choose specific Pool IDs. BRMS needs to be a v5.3. Networker needs to be a v7.4. Conceptually, three different methods of encryption will be supported. Application managed, System Managed and Library Managed. The application layer initiates data transfer for tape storage (e.g. TSM). We are planning on providing facilities for an application to generate and provide keys to the TS1120 tape drive. In this case, the application would be responsible for the creation, storage and management of the cartridge data keys. We are defining the system layer as everything between the application and the tape drives (e.g. the OS, DFSMS, device drivers, and FICON/ESCON controllers). We are planning to provide a new key manager software program that will work in conjunction with the system layer to provide keys based on the policies established for encryption of tape data. In addition, in open systems environments, we are planning to provide Library Managed encryption. The library layer is the enclosure for the tape drives and we use an out-of-band interface to each tape drive to transmit the data encryption request and keys. Policies may be implemented based on cartridge volume serial numbers, logical libraries, or drives. We are using this nomenclature; application managed, system manager and library managed encryption across IBM development teams, to assist us in communicating with each other and in communicating customer requirements. Let’s turn to the next page to discuss some of the additional features of this approach to the IBM encryption solution. Application-Managed (TSM, NBU, et. al.) Policy

Library Managed Encryption Components
Open Systems Host TKLM/drive key exchange occurs over the LDI and TCP/IP paths Host – zOS, AIX, Linux, Windows, Solaris Fibre Key Store TKLM Crypto Services TCP/IP One needs to be on TSM or 5.4 to support AME. This is the release where they added the DRIVEENCRYPTION Device Class parameter. But if not using AME, if using LME/BEP, we support any TSM release, TSM 5.2 for example. LDI Host – zOS, AIX, Linux, Windows, Solaris TCP/IP Key Store Proxy TKLM Crypto Services

AME / LME Comparison LME AME Transparent to Backup application
No TSM Admin required No TSM Upgrade required Keystore is encrypted FIPS certified Will work with other end points Tape, Disk, SAN, HBAs Keys encrypted in transit to tape drives Allows for separation of duties Not limited to TSM Backup/Archive only AME Allows TSM control Device Class 3584 Transparent Encryption feature code not required TKLM not required NBU/AME is call MSEO (Media Server Encryption Option) One needs to be on TSM or 5.4 to support AME. This is the release where they added the DRIVEENCRYPTION Device Class parameter. But if not using AME, if using LME/BEP, we support any TSM release, TSM 5.2 for example. NBU/AME requires NetBackup

System Managed Encryption Components – zOS
Java Virtual Machine Key Store ISKLM Crypto Services Host - AIX, Linux, Windows, Sun TCP/IP And/Or FICON/ESCON Proxy Key Store TKLM TCP/IP Crypto Services DFSMS SMS Policy Data Class TKLM/drive key exchange occurs over the fibre and FICON/ESCON paths Encryption Policy defined by SMS policy, DD statement TKLM 1.1 (will have different name) planned GA 4/15/11. Will not require DB2 or SSRE. The Ficon/Escon proxy is in the zOS IO Subsystem. The TKLM ip address is entered via a parmlib member. FICON/ESCON Fibre Control Unit

System Managed Encryption – TS7700
Host - zOS, AIX, Linux, Windows, Sun Host Key Store TKLM Crypto Services Network FICON Host - zOS, AIX, Linux, Windows, Sun TS7700 Key Store TKLM Proxy The proxy in the TS7700 provides the bridge between the drive FC and the network for TKLM exchanges. Crypto Services Please turn to the slide titled Encryption Review: TS7740 as the EKM proxy. This diagram is the same as the previous slide except the TS7740 takes the place of the control unit as the proxy between the drive and the EKM. The EKMs can reside on the host connected to the TS7740 or can reside on other machines. With the TS7740, encryption is performed on the back-end TS1120 drives. The virtual drives do not encrypt. Encryption is controlled through the existing 32 storage pools on the TS7740. The host uses the existing storage constructs of Storage Group and Management Class to direct which pool of 3592 cartridges the logical volume data is stored on. If a pool is designated as an encrypting pool, the logical volume data will be encrypted when it is written to the 3592 cartridge. Each pool can define which public/private key pairs to use to encrypt the data key on the tape cartridge. Encryption policy is based on Storage Pool which is controlled through Advanced Policy Management (APM): Storage Group and Management Class Fibre

Symmetric Encryption Private Key, Secret Key, Data Key
User Data – AES25 Keystore – TripleDES Backups – DES (default) or TripleDES Used by TS1120 and LTO4 to encrypt user data. Where is DK stored? - TS1120 – stored EEDK data structure on cart in 4 places, encrypted with 2048 bit RSA key. - LTO4 – stored in keystore, TDES encrypted with keystore password User Data Encryption Keystore Encryption TKLM Backup Encryption

Asymmetric Encryption Public Key, Public/Private Key Pair, Key Encrypting Key
There are 5 primary uses for Asymmetric (public/private) keypairs in IBM’s tape encryption solution: 1) Drive authentication. The public/private keypair that is burned into the tape drive is used to authenticate with TKLM/EKM when a session is started. This public/private keypair is stored in the tape drive, not in the keystore. Used by TS1120 and LTO4. 2) Session security. A public/private keypair is generated on the fly by the tape drive for each communication session with the TKLM/EKM in which a data key is passed from the EKM to the tape drive. TKLM/EKM uses the Crypto Service Provider to encrypt the Data Key with the public key. The tape drive decrypts this session encrypted data key with the private key. This ephemeral keypair is generated on the fly by the tape drive and exists only for the length of the session. It is not stored in the keystore. Used by TS1120 and LTO4. 3) Encrypting data keys. With the TS1120, all data keys are encrypted using a public private keypair stored in a keystore. With LTO4, only data keys used for cartridges sent to BPs are normally encrypted with a public/private keypair. With both LTO4 and TS1120 the BP sends you their public key and it is stored in a keystore. With TS1120 that public key is used to create an encrypted data key, and that encrypted data key is stored on the cartridge. With LTO4 that public key is used to create an encrypted data key with tklmKeyExport (TKLM) or the export secret key keytool command (EKM). That encrypted data key is then sent to the BP as a file. 4) SSL between TKLM and device. For LME, the TS3500 has not added SSL support as of R10A. “Sync” command communications. The EKM Admin Client “Sync” command can be used to synchronize the drive tape and the config file between EKM servers. This communication is secured by a public/private keypair that is stored in a keystore. This public/private keypair is created by the customer (using keytool, iKeyman, hwkeytool, or racdcert) during the EKM setup process. Used with both TS1120 and LTO4. 5) EKM Admin Client communications. With EKM v2.1 and higher, there is a need to secure communications between the EKM Admin Client and the EKM server. This communication is secured by a public/private keypair that is stored in a keystore. This public/private keypair is created by the customer (using keytool, iKeyman, hwkeytool, or racdcert) during the EKM setup process. Used with both TS1120 and LTO4. The same public/private keypair could be used for #s 3, 4, and 5, but the recommended approach is to use a different keypair for #3. In EKM v2.1 this is accomplished by using a separate keystore for #3 and (#4 & #5) #s 1, 2, &3 are used for EKM to Device communication. #s 4 & 5 are used for EKM internal communication. SSL/TLS is used to protect these communications. These public/private keys are used in SSL/TLS communications. One might ask, why don’t you use one encryption method for both the data and the key. We actually us each method for their strength. Symmetric encryption is very fast, so we use symmetric encryption for the data and are able to encrypt at line speed. There is no performance degradation in throughput. And we use asymmetric encryption to encrypt the data key because a public/private key pair makes transferring a key to a remote site more manageable. Drive authentication Session security Encrypting Data Keys SSL between TKLM and device SSL between TKLMs TKLM web GUI communications

TS11xx and LTO Encryption
FC Port 0 FC Port 0 Tape Drive with Private Key Drive Firmware Clear Clear Clear Host Interface DMA Processor Application Specific Integrated Circuit Built-in AES 256-bit data encryption engine Look-aside decryption & decompression help assure data integrity. <1% performance and capacity impact Authentication: TKLM queries drive certificate and uses public key to authenticate exchanges Cl w*q03!k3iKm4Aw^1* #*4msW Clear Clear ear  Compression Decompression Code Memory AES Encryption AES Decryption Buffer Drive Certificate with Drive’s Public Key ECC and Format Encoding @MA8%w*q03!k3iKm4*^Fj&fgtrSIaasl Read/Write Electronics Appliances: DeCru and NeoScale Appliance +’s: Work with older tape drives. Appliance –’s: Expensive. Extra component that you are buying for a short term solution. All tape drives by all vendors today support encryption. Therefore, as you replace your older tape drives with newer ones, in a few years all you tape drives will be encryption capable. Appliances are money spent on a short term solution. You can lessen this expense by increasing your tape drive to appliance ratio, but then tape drive performance suffers. And then there is the cost of managing a more complex environment with an extra component. One of the shortcomings of encrypting at the server or with an external device is encrypted data is not compressible, therefore you need significantly more cartridges to hold your data. This is not the case with tape drive based encryption. zSeries offers a cryptographic engine. DeCru does offer a compress before encrypt option. MAC – Message Authorization Codes are done in hardware in the TS1120. Similar to read after write, the TS1120 does look aside decrypt. Look aside decrypt decrypts the data right after is has been encrypted to make sure the data is decryptable. Read/Write Head Tape Media

LTO Consortium based format
Standard LTO media Entire volume is encrypted or non-encrypted Common scratch pool with full re-format between encrypted and non-encrypted cartridge memory Control Structures Volume Label Encrypted Host Records and/or File Marks End of Data BOT EOT Data area symmetric encryption AES-256 with DK Similarities: - Both TS1120 and LTO4 use the AES256 DK to encrypt the data. - Standard media - Entire volume is encrypted or unencrypted Differences: – Where the data key is stored. With TS1120 the EEDK is stored on the tape is three areas. With the LTO4, the data key is stored in the keystore. - Where the key label identifier is stored. With the TS1120 it is stored in the EEDK data structure on the tape cartridge. With the LTO4, it is stored in a non-user accessible area at the beginning of each block of data (first 12 bytes). - LTO4 encrypts the Internal Label with the same DK as other blocks on the tape. TS1120/30 by default uses a “zero” key to encrypt the Internal Label. A mode set parameter can be changed if a TS1120/30 customer wants to use the DK rather than the “zero” key to encrypt the Internal Label. - The LTO4 drive is architected so that encrypted or non-encrypted records may co-exist on same medium. Note: currently only “all encrypted” or “all non-encrypted” is supported. - AES-256 DK is used to encrypt host data - Key Identifiers are written in clear text format - Drive must request data key for each unique Key Identifier encountered during read operations “KeyIdentifier” generated from Key Label/Alias or provided by the application is encoded in each Host Data Record & format recording element per LTO specification.

TS11xx Media Format Elements
Standard 3592 media Entire volume is encrypted or non-encrypted Common scratch pool with full re-format between encrypted and non-encrypted Full support for wrapping keys Simplifies key management and DR/ BP scenarios Two Wrapped Key Structures (EEDKs) may be active on a cartridge cartridge memory EEDK1/2 Control Structures The “pointers”, either the Key Label or a Hash of the public key are stored in the EEDK data structure. The EEDK is stored at four locations on the tape, RFID card, BOT control structure (2), and then again about 20 meters down the tape. When a TS1120/30 volume is encrypted, the Internal Label is always encrypted. There are two options for this, either use the “zero” key or the Data Key (DK) to encrypt the Internal Label. Using the DK to encrypt the Internal Label is the ultra paranoid method. The default is to use the “zero” key. This can be set using either a mode set command or the maintenance panel attached to the drive. This cannot be set from the library web interface. Typically the mode set is used to change this setting. Some consider use of the “zero” key to be "in the clear" since it is easily decrypted. However, a non-encryption capable drive cannot read the “zero” key encrypted label. When the “zero” key is used, no communication with the key manager (EKM or TKLM) is required to read (decrypt) the Internal label. The drive firmware uses the standard label structure to determine if the first block (block zero) is an internal label, or just the first block of an unlabeled tape. When encryption is enabled for a drive, other, non-encryption capable drives that access the same set of volumes must be brought up to a minimum code level. This allows them to reformat a volume that is recorded in the encryption format. For a 3592-J1A drive the minimum code level is D3I0_85A. For a 3592-E05 it is the encryption GA level or higher which is D3I0_942. The Data Key is never stored on the cartridge in the clear. The DK is not stored in the KeyStore. EEDK are stored on cart for SME and LME. For AME no EEDKs are stored on the carts because TSM does not use KEKs. TSM keeps the DKs stored in its DB. Volume Label Encrypted Host Records and/or File Marks End of Data Data area symmetric encryption AES-256 with DK BOT EOT EEDK1/2 "wrapped keys" KEK[DK] Asymmetric encryption RSA-2048 with KEK

TKLM v2.0.1 Implementation Considerations Demo TKLMv2 GA-ed August 27, 2010

Tivoli Key Lifecycle Manager (TKLM)
IBM Licensed Program Serves data keys to drive TS11xx LTO DS8000 Runs on the same or different server than the tape application AIX TKLM IP Other OS Fibre Channel SAS FICON Other OS

TKLM OS Support AIX 5.3 or later AIX 6.1 or later
Red Hat Enterprise Linux 4.0 (32 bit) Red Hat Enterprise Linux 5.0 (32 bit and 64 bit) SuSE Linux 9 (32 bit) SuSE Linux 10 (32 bit and 64 bit) Solaris 9 Sparc Solaris 10 Sparc Windows Server 2003 (32 bit and 64 bit) Windows Server 2008 (32 bit and 64 bit) z/OS 1.9, 1.10, 1.11 (TKLM v1 only) Linux is support on Intel. Linux is not support on zSeries or Power servers. Windows 2008 Note: TKLM V1 is presently (Jan 2010) supported on Windows 2008 R1, SP1 and R1, SP2. We don’t care about the SP level...only the release level. There is work being done to support Windows 2008 R2 on TLKM V2. Here is the list once the fix pack is out (current target May 09): RHEL bit and 64 bit (32 bit mode) RHEL bit SLES 9 32 bit SLES bit and 64 bit (32 bit mode) Solaris 9 SPARC 64 bit (32 bit mode) Solaris 10 SPARC 64 bit (32 bit mode) Windows bit and 64 bit (32 bit mode) Windows bit and 64 bit (32 bit mode) AIX bit (32 bit mode) AIX bit (32 bit mode) z/OS 1.9 z/OS 1.10 Note: TKLM runs as a 32 bit application on all 64 bit platforms. This is noted above as (32 bit mode). Windows XP is not supported, but works well enough for a customer demo.

EKM (z/OS and Open) TKLM 1.0 (z/OS and Open) TKLM 2.0 (Open only)
Release History EKM (z/OS and Open) Sept 2006 Bundled with IBM Java TKLM 1.0 (z/OS and Open) Nov 2008 DB2 and browser based GUI TKLM 2.0 (Open only) Aug 2010 RBAC KMIP 1.0 ISKLM 1.1 (z/OS only) Apr 2011 Built on EKM for z/OS No DB2 or Websphere New device support Service path for EKM for z/OS TKLM 2.0.1 Oct 2012 Automatic cloning KMIP 1.1 HSM support

Automated clone replication
Up to 5 Clones Clones Keystore DB2 tables Config file Replication is encrypted Master and clone systems must be identical Note: This is the same data as that taken as part of a Tivoli Key Lifecycle Manager backup. Except that during a replication, the replication configuration file is not backed-up and passed to the clone.

KMIP v1.1 support Device Credentials – how does a consumer of keys identify itself Serial number identifying the client or device Network address Instance or volume identifier Group Shared secret Device Credentials are used: To help with PCI-DSS compliance, only serve keys to known devices Ease of use for deployment – can use certificates as a right to connect rather than managing a certificate per device Improved asymmetric key support Major contributions from PGP and RSA Will be the basis for managing the key material in certificates Grouping of keys Default and fresh attributes now supported Useful for pools of shared media Useful for key rotation

TKLM Resources TKLM Info Center
TKLM Website: TKLM Info Center TKLM Installation and Configuration Guide Flash Demos Information Infrastructure Security with IBM TKLM GUI demo TKLM Data Sheet ftp://ftp.software.ibm.com/common/ssi/pm/sp/n/tid14031usen/TID14031USEN.PDF White Paper: Simplifying Key Management with Tivoli Key Lifecycle Manager ftp://ftp.software.ibm.com/common/ssi/sa/wh/n/tiw14026usen/TIW14026USEN.PDF Red Book: IBM System Storage Tape Encryption Solutions Red Paper: ISKLM for z/OS The TKLM for z/OS Red Paper is 178 pages, so effectively, it is a Red Book.

Today’s Cryptographic Environment
Enterprise Cryptographic Environments Collaboration & Content Mgmt Systems File Server Portals Disk Arrays Production Database Backup System Replica Backup Disk LAN WAN Enterprise Applications VPN eCommerce Applications Business Analytics Backup Tape Staging CRM Dev/Test Obfuscation Key Management System Key Management System Key Management System Key Management System Key Management System Key Management System Key Management System Key Management System 22

KMIP Overview Key Management Interoperability Protocol (KMIP)
Key-management to encryption client protocol Enables key lifecycle management Generation, submission, retrieval, and deletion Supports Symmetric keys Asymmetric keys Digital certificates Proposed in Feb KMIP Technical Committee members: BeCrypt Ltd. Brocade Communications Systems, Inc. Cisco Systems, Inc.* EMC Corporation Hewlett-Packard* IBM NIST* Red Hat Skyworth TTG Holdings Limited Sun Microsystems Symantec Corp.* Thales e-Security Venafi, Inc Original endorsers: Brocade EMC/RSA HP IBM LSI nCypher/Thales Network Appliance Seagate Additional participants: BeCrypt Emulex Entrust Microsoft Oracle PGP Quantum Safenet Sun Venafi Verisign

TKLM v2 Supported Devices
IBM Tape Drives LTO4 / LTO5 / LTO6 TS1120 / TS1130 / TS1140 IBM Tape Libraries TS3500 3494 TS3400 TS3310 TS3200 / TS3100 TS2900 Non-IBM Tape Libraries Quantum (ADIC) i2000 Quantum (ADIC) i500 IBM Disk Drives DS8000 DS5000 DS3000 KMIP Supported Devices Emulex OneSecure HBAs Brocade (IBM OEM) IBM SAN32B-E4 (2498-E32) FC: Encryption Blade NetApp FAS2040 FAS3200 FAS6200 Standalone encryption appliance (pizza box) E32 SAN switch Encryption blade(FC 3895) that goes into a modular chassis (Brocade DCX) FC is a feature for these two modular chassis's < and > Looking these two up on the Internet I found that Brocade's encrypting switch does compress. But I couldn't find any mention of compression associated with Emulex's encrypting HBA and so don't believe they compress. Brocade does compress then encrypt and with respectable throughput, but the blades are very expensive and then there is also required software and SW MA. TKLM for Switches is $10k. It is available via PPA, but not via AAS. Here are the PPA numbers: Tiv Key Lifecycle Mgr for Switches per Client Dev D0L4WLL Lic + SW S&S 12 Mo Tiv Key Lifecycle Mgr for Switches per Client Dev E0CQPLL Annual SW S&S Rnwl Tiv Key Lifecycle Mgr for Switches per Client Dev D0L4XLL SW S&S Reinstate 12 Mo Tape Drive / Upstream comparison: Drive advantages: Compression (2 to 3X cartridge savings) Unique AES key per tape cartridge As a general recommendation encryption at the storage end point provides the lowest cost, simplest operation. Proof Points: Encryption pervasively available in midrange and enterprise tape for no (IBM, HP, Quantum) or minimal (SnOracle) additional charge Encryption increasingly available as industry standard FDE implementation (DS5, DS8, LSI, HDS(?)) at minimal additional charge. Scales linearly with capacity/thruput requirement. New TKLM Auto-device discovery with Pended authorization allows non-disruptive administration IBM offers additional options for Switch Based and HBA encryption to accommodate customers with unique use cases and requirements. Examples: Large sunk cost / book value in existing Storage devices - implement in switch as interim strategy to device replacement if urgent encryption requirement arises. Distributed Server / Storage infrastructure with physical connectivity requirements outside secure data center - implement encryption at HBA (I ran into this one at an insurance company which had servers in the legal department san connected to a storage farm but the SAN routed in cable raceways between the two secure rooms that the Legal team did not believe sufficiently secure).

Implementation Considerations Design Considerations TS3500 (3584) Implementation Demo EKM Design: - BEP or ILEP (NetBackup only)? - Where put EKM? - Local or Remote? - What Operating System? - Dedicated Server or LPAR? - Dedicated LPAR or Shared LPAR? - What Keystore? - Hardware or Software - How implement HA? - Who manages keystore? Who managers pointers to keys? - Where put key pointers? - Library web interface - EKM drive table - EKM config file - Separation of duties? - Key rotation?

TKLM Design Considerations
What Operating System? Server sizing? Dedicated Server or LPAR? Dedicated LPAR or Shared LPAR? TKLM - Local or Remote? How implement HA? Moving keys offsite What to Encrypt? Key rotation? Number of Keys?

What Operating System? AIX Linux Solaris Windows z/OS Keystore and
Crypto Services TKLM Drive Table Configuration Whichever OS the customer is most comfortable with. Sometimes iSeries customers will choose xSeries for lower cost. i5OS 5.3 and 5.4 do not allow resource sharing. That is, if you wanted to create a new LPAR for EKM you also had to purchase an HBA for disk and tape attach. With i5OS 6.1, you can create an EKM partition and allow it to use adapters in other partitions. If a customer has a large System i with many 5.4 LPARS, you could upgrade one of the other LPARs to 6.1, and then the EKM LPAR could share resources with that LPAR. Other options for the System i customer include running EKM on a small dedicated Linux or Windows server. Windows would require TPC/BE ($3300) for each server.

What Size Server? CPU Memory Disk
The server requirements are minimal. Testing on a small server, EKM was able to deliver 28 keys per second. Times 3600 seconds in hours, that equates to over 100,000 tape mounts per hour! EKM has also been tested with 500,000 keys. TKLM Hardware Requirements: System components Minimum values* Recommended values** System memory (RAM) 2 GB 4 GB CPU for Linux and Windows GHz single 3.0 GHz dualprocessor CPU for AIX and Sun Solaris 1.5 GHz (2–way) 1.5 GHz (4–way) Disk space GBs GBs * Minimum values: These values enable a basic use of Tivoli Key Lifecycle Manager. ** Recommended values: You might need to use larger values that are appropriate for your production environment. The most critical requirements are to provide adequate system memory, and free disk and swap space. Processor speed is less important.

High Availability Keystore and Crypto Services Keystore and
TKLM TKLM Drive Table Drive Table Configuration Configuration The criticality of TKLM can be similar to the criticality of TSM (Netbackup, Networker, BRMS). If TSM is down, you cannot read or write TSM tapes. If you lose the TSM DB, and you do not have a backup, you are in big trouble. The same is true with TKLM. Having said that, most customer do run TKLM (and EKM) in HA configurations. Disk encryption increases TKLM’s criticality. Other (non-backup) uses of tape increases TKLM’s criticality. Currently in Open Systems the keystore replication needs to be done manually using the export/import commands, or by copying the file. This should be an infrequent process. Backup/Restore can be used with TKLM. RACF has the capability to mirror files, and this can be used as a replication facility for RACF based keystores. If this is one data center, all three files would be equivalent. If this was two different data centers, the drive tables would be different.

Dedicated Server or LPAR?
Option 1 Option 2 Option 3 Option 4 TKLM Other Apps TKLM TKLM Tape Application TKLM Tape Application Tape Application Tape Application Option 1 is problematic with TSM 6. TSM 6 and TKLM both use DB2 under the covers. The TKLM installer will tolerate TSM’s DB2, but TSM’s installer will not tolerate TKLM’s DB2. Best solution is to put TSM and TKLM in separate LPARs or separate VMs. Some are using Option 1, Option 2 & 3 are the most popular. Could do both, Option 2 for primary TKLM/EKM, Option 3 for backup TKLM/EKM. Option 4 is not used that often. Sometimes used by I or z customers putting TKLM on a Windows or Linux server. Option 4 is required for TKLM for zOS with DS8000. i5OS 5.3 and 5.4 do not allow resource sharing. That is, if you want to create a new LPAR for EKM you have to purchase an HBA for disk attach. If you wanted to backup this LPAR to tape, you would also need an HBA for tape, though that could be LPARed over. With i5OS 6.1, you can create an EKM partition and allow it to use disk adapters in other partitions. If a customer has a large System i with many 5.4 LPARS, you could upgrade one of the other LPARs to 6.1, and then the EKM LPAR could share resources with that LPAR. Other options for the System i customer include running EKM on a small dedicated Linux or Windows server. Windows would require TPC/BE ($3300) for each server plus the cost of the server, plus the cost of the Windows license. Q: Suppose the customer already had an LPAR'd IBM I ... How much would it cost to make a tiny LPAR for EKM? A: The minimum gear to open a small LPAR on a system that already has LPARs (eg has PowerVM) and a shared tape drive is as follows Disk Adapter card - eg fc 5737 low-end card that allows disk mirroring (drive level mirroring only) - $1, GB drives to mirror for LS + EKM - fc $999*2 = $1,998 Ethernet Adapter - POWER5+ and below - $600 approx Ethernet Adapter - POWER6 and above - no charge (system comes with integrated virtual ethernet (IVE) which is a card with 2-4 ethernet ports that can be shared/virtualized among LPARs) Tape drive to back up EKM - assume you can share an existing drive via the LPAR functions. Operating System - assume it's already paid for on the CPU we're sharing PowerVM (for micropartitioning) - assume it's already on the system IBM JRE - included with the no-charge Java Developer Toolkit Total Cost = POWER5/5+ = $4,600 POWER6 = $4,000 (see note) (compared with Windows ... $3,300 for TPC/BE + the cost of the Windows Server + Windows OS) ** So the cost to run EKM on IBM i is BETTER than Windows! Note that on POWER6, you could also use Virtual Client Partitioning to open a guest LPAR that runs IBM I using disk/ethernet resources from an existing LPAR. This virtual client partition can use a tape drive shared with another LPAR. Given that the EKM LPAR is tiny, this would be a very economical way to run it since it would use very little resources from the existing system But if you had to buy a new one, the LVD SCSI card is cheap ($1000 or so I'd guess?) and the soon-to-be-announced SAS card is supposed to be cheap. The IOP'd fc 5761 is $4200 for IOP+IOA, and the new IOPless fibre card is $3308 A tape drive is a shared resource, so you can LPAR it around to the different partitions as needed. Disk is not a shared resource, so it needs to stay put, attached to the system that owns the data.

TKLM – Local or Remote? Option 1 Option 2 TKLM Tape Application TKLM
If the customer has only has 2 or 3 Data Centers, then they could run a local TKLM as the primary key manager at each. If the have more DCs, they would probably run remote TKLMs as primary, to keep the TKLM synchronization managable. Even if they only have 2 or 3 Data Centers, some customers run one primary to save a few dollars on TKLM licensing.

TKLM Deployment – DR Site
Main Site Disaster Recovery site Second production site Many permutations. TKLM/EKM can be remote if customer is comfortable with their network reliability. Cold DR site: 2:0, Go to 0:2 after disaster Hot DR site: 1:1 or 1:2 If you have high network availability, Go to 0:2 after disaster. 2:1 or 2:2 If you have concern about network outages. Whether you run one or two at the remote site just depends on whether you want to set up the 2nd EKM at the remote site before or after the disaster. Cold DR site: - 2:0, Go to 0:2 after disaster Hot DR site: - 1:1 or 1:2 If you have high network availability - 2:1 or 2:2 If you have concerns about network outages.

Moving Keys Offsite DR Business Partner TS11xx
Keystore  (Using TKLM Backup/Restore)  Public Key EEDK w Hashed Key Label LTO - tklmkeyexport With EKM one option was to just copy the JCEKS keystore file and move it to the 2nd location. Copying the keystore is not an option with TKLM. The keys in the keystore being copied will not be recognized by the other TKLM as the metadata associated with those keys is not in that TKLMs database. The correct way to do this is to backup and restore on like OSes with the same directory structure setup OR export from 1 TKLM and import into the other. Some customers have asked about using “image” copies to restore as a DR site. Tivoli Integrated Portal (TIP) has some dependencies on the hostname and if the hostname in its config files does not match the hostname of the machine it fails to start the WAS server. It might be possible for the customer to do an image restore and change the hostname to match the original hostname, but this has not been tested. TKLM on z/OS considerations: With TKLM on z/OS the backups are a performed using a manual UNLOAD of the DB2 tables, perhaps RACF based data, and various Unix System Services files. If the UNLOAD data is encrypted, it is through keys that are not stored within TKLM. A restore of the DB2 tables using LOAD would not go through a TKLM instance, unless of course the unloaded tables were written to encrypted tape. The same would hold true if the .jar backup file created at a Windows or Linux based TKLM GUI were then saved to encrypted tape. In either case, the files required to restore a TKLM instance would need to be available outside of a TKLM instance. Best practices suggest that the backup material be stored for DR on nonvolatile media such as CD or DVD separate from the datacenter (such as in a vault). This material would be a .jar file in the distributed case, or the various files and datasets related to z/OS. Restoration of a TKLM environment on z/OS involves a LOAD of the DB2 tables as well as writing the Unix and RACF based information. In either the distributed of z/OS case, it is assumed that a TKLM has been installed at the DR site. If the backup/restore concern is purely for DR purposes, only the key material is required in order to encrypt and decrypt the tapes. It is possible to export and store only the keys from the keystore. The DB2 information (metadata) should not be needed at DR if the keys are properly exported and imported using the TKLM CLI. This process has not been proven to work if keys are stored under the protection of cryptographic hardware. There is a 'Catch-22' situation with TKLM concerning its use with DS8000 encrypted disk. It is not clear whether the client is intending to use TKLM to house keys for a DS8000, and if that DS8000 holds the DB2 data sets. If there is an encrypted DS8000 in the environment, either the TKLM can not be installed on that device or the secondary TKLM must be installed on another device. That is to say that the keys to decrypt a DS8000 can't be on the device itself. Offsite Cart Process DR – Depends on the keystore type. For JCEKS or RACF(PKDS), the file can be FTP-ed or ed. The keystore is encrypted with TDES, so no worry there. The keystore key (password) can be ed, phone, snail mailed, or couriered to the DR site. With hardware keystores, instead of exporting keys as a pkcs12 file, with jceccaks w/pkds option, and consequently the jceccaracfks, you have to move the whole pkds to the dr site, and then load the dr system with the same system master keys as the original site. If set up as CLEAR rather than PKDS, then keys can be exported. For zOS / RACF / ICSF they customers can use the keyxfer tool where the master key is used to encrypt the exported file. Business Partner – With a BP you want them to be able to read one cart, or a finite # of carts, but not all your carts, so you would send them a single key, but not the entire keystore. TS1120 – They send you their public key. Add it to the keystore. Use it as the KEK of the cart you send them. They have the private key to decrypt. If they did not also send you their key label, use hashed label rather than clear label as the label identifier. For JCERACFKS (RACF software) you export and import in PKCS12 format. LTO4 – Use a unique key to encrypt their cart(s). They send you their public key. Add it to the keystore. Create a new DK for this BP and encrypt the DK with the KEK they just sent you using the keytool exportseckey command. This wraps the DK creating an EDK. Send them the EDK which they will importseckey using their private key, into their keystore. You will also need to encrypt the cartridge with that same DK. Small libraries with ILEP – Use ILEP to drive the specific key Small library without BEP TS3400 – Use EKM Modconfig and Refresh commands to temporarily designate a new default key. LTO4 – Use EKM Modconfig and Refresh commands to temporarily designate a new SymmetricKeySet. If you choose either keystore, JCEKS or JCERACFKS on z/OS and a JCEKS on Windows, it should be very easy to set them up as a primary/secondary pair. Basically you would install and configure each TKLM separately and then use TKLM's CLI functions to export and import the certificates and key material to and from the 2 machines. TKLM has no automatic way of contacting other TKLM instances so once key material is exported from one instance it’s up to you to transfer that key material over to the other instance so it can be imported using the TKLM CLI. *Note: This type of setup should be easy because the JCEKS and JCERACFKS keystores are both using software crypto. If hardware crypto was introduced, by using a JCECCAKS or JCECCARACFKS keystore with ICSF protection, the key material would not be importable on the Windows system, and could only be transferred and imported by other z/OS systems. TKLM / EKM compatability: TKLM export/import  EKM, LTO AES Symmetric keys, Works fine TKLM export/import  EKM, TS1120/30 RSA Asymmetric keys, Works fine EKM export/import  TKLM, LTO AES Symmetric keys, Works fine EKM export/import  TKLM, TS1120/30 RSA Asymmetric keys, Does not work. Will work in TKLM V2

= What to Encrypt? Selective Encryption Encrypt All Recovery AES

Key Rotation My_2012_Key My_2013_Key My_2014_Key
My_1Q-2012_Key My-2Q-2012-Key My-3Q-2012-Key

Internal or External Perform Resource?
IBM Implementation Services for tape systems - tape encryption and key management Tasks Performed Planning session meeting Architecture and Design Implementation Procedure Development Skills transfer IBM Benefits Proven methodology Support from IBM’s dedicated storage specialists Basic skills instruction for client staff Accelerated implementation Cost is almost always $10-$12K including travel expenses inside the USA. Onsite work is typically only a couple of days, and the rest of the SOW covers prep, travel time, onsite work, and a few follow-up calls for assistance. Sample Tape Encryption Implementation Services Statement of Work (SOW) IBM I-series Encryption Install (TKLM) IBM will perform the following services related to tape encryption implementation with IBM i: · Verify encryption implementation design. · Assist Customer in configuring TKLM servers · Assist Customer in configuring tape libraries · Assist Customer in configuring BRMS (if installed) to use encryption · Test the Tape Encryption solution as discussed in the implementation design. IBM will conduct a customer-walk through/skills transfer of the process of creating an encrypted tape using the primary TKLM by: · Creating and writing to an encrypted tape · Displaying the encrypted tape · Appending to the tape just created · Restoring from the encrypted tape · Verify this encrypted tape cannot be read while the TKLM is not running · Verify this encrypted tape cannot be read while the keys are not accessible in the keystore · Showing the fail over capability by running without the primary TKLM · Conduct a final skills transfer session that describes the final configuration and walk through the test results. Services will be provided during a 1-week on site effort, estimated at up to 40 hours plus travel time.

Agenda Tape Encryption Overview Tape Encryption Process
Tape Encryption Implementation Design Considerations TS3500 (3584) Implementation Demo EKM Design: - BEP or ILEP (NetBackup only)? - Where put EKM? - Local or Remote? - What Operating System? - Dedicated Server or LPAR? - Dedicated LPAR or Shared LPAR? - What Keystore? - Hardware or Software - How implement HA? - Who manages keystore? Who managers pointers to keys? - Where put key pointers? - Library web interface - EKM drive table - EKM config file - Separation of duties? - Key rotation?

TS3500 Library Implementation
Install or upgrade tape drives Upgrade drive firmware Update TS3500 firmware Enable drives for encryption (LME) Set up TKLM IP address Update drive encryption method Setup Barcode Encryption Policy (Optional) Run Key Path Diagnostic Test Enable drives for encryption (SME)

Questions?

Demo 1) Restore TKLM base from backup (c:\tklmv2\)
2) Logout of TKLM web GUI 3) Stop TIP/TKLM service on (…33514) Via Windows Computer Management 4) Delete TKLM keystore file defaultKeyStore From C:\IBM\tivoli\tiptklmV2\products\tklm\keystore directory 5) Start TIP/TKLM service 6) Login to TKLM web GUI using IE 7) Do Next TKLM Demo

IBM Tape Encryption and TKLM v2.0.1

Similar presentations

Presentation on theme: "IBM Tape Encryption and TKLM v2.0.1"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

IBM Tape Encryption and TKLM v2.0.1

Similar presentations

Presentation on theme: "IBM Tape Encryption and TKLM v2.0.1"— Presentation transcript:

Similar presentations

About project

Feedback