ibm guardium data encryption for ims and db2 webinar

© 2012 IBM Corporation

IBM Security Systems

IBM Guardium Data Encryption for IMS and DB2

Presented by:Thomas J. HubbardProduct SpecialistRocket Software



Agenda• Overview• Why encrypt the database?• IBM Guardium Data Encryption• DB2 database encryption• IMS database encryption• Q & A



OVERVIEW



Why Should All Data at Rest be Encrypted? Why do you care?

• Keeps sensitive information confidential

- Insider threat- Lost/stolen tape or disk - Disk being repaired (Solid-state disks fail in a read-only state)

• Simplifies end-of-life-of-media scenarios - Destroy the key and the data is unusable

- Cryptographic Erasure (NIST SP800-88)- Reducing media disposal costs

• Addresses Standards

- and others

- Privacy breach disclosure laws (e.g. EU Privacy Disclosure Directive)- Protection of financial data



Cryptography has Many Applications

SSL/TLS

Link encryptionTape encryption

Database encryption

Application level encryption

PIN processing

File encryption

SAN Switch encryption

Protecting Data at Rest Protecting Data

in Motion

Digital rights management

Tokenization Protecting Data in Use

IPsec

Disk encryption

Email encryption

Data



Cryptography is a Fundamental Security Technology

• Key exchange for communication session keys• Data is transit is protected using single-use keys• Data at rest – Keys are long lived

Establishes Privacy of Data in Motion and

Data at Rest

• Being able to encrypt or decrypt proves you are in possession of or authorized to use the key

• Certificates provide additional identity informationEstablishes Identity

• Data Integrity is provided through keyed-hashes• Hashes provide integrity checking for data in transit

Protects against Unauthorized

Changes

• Digital signatures create undeniable authorshipAssigns Ownership to the Data or Message



Disk and Tape options in IBM Self-Encrypting Storage

DS8870

DS3500

XIVN series

TS3500 library

TS1140 drive

LTO6 drive

TS3310 libraryGPFS

Self-encrypting solutions that protect

Data-at-Rest



WHY DATABASE ENCRYPTION?



Security Cost/Risk

0

2

4

6

8

10

12

Security Cost vs. Risk

Cost Risk



Encryption and “Data at Rest” Protection Key requirement for most of the “current” data protection initiatives Main requirement is to protect “data at rest” to ensure that only access is for

business need-to-know, and through mechanisms which can be controlled by the native security mechanisms (such as RACF) Consider the following scenario:

– Database datasets are controlled via RACF from direct access outside of the DBMS via dataset access rules

– DBA or Storage Administrator has RACF authority to read database datasets in order to perform legitimate storage administration activities.

– Administration privileges can be abused to read the database datasets directly and access clear-text data outside of DBMS/RACF protections.

Now consider the above scenario, but with the underlying database datasets encrypted

– When DBA or Storage Administrator uses their RACF dataset authorities in a manner which is outside of business need-to-know, the data retrieved is “cybertext” and thus remains encrypted and protected.

– Only way to access and obtain clear-text data will be via DBMS services which can be protected via RACF

21

Presenter

Presentation Notes

While RACF does provide a layer of protection for unauthorized access to DB2 data, significant risk still exists With the data being in clear text form.



What value does database encryption add?

Protects sensitive data that can reside on various storage media Another layer of security For DB2, log records, image copies, and data buffers are encrypted For IMS, image copies, data buffers, and log records that log changes to

database records are encrypted IMS data that is decrypted is also logged Prevent access to decrypted data outside the control of the DBMS

– DFDSS – FDR – IDCAMS Repro– Volume reassign



ENCRYPTION ON ZSERIES



Integrated Cryptographic Service Facility (ICSF)

Provides: z/OS integrated software support for data encryption

Operating System S/W API Interface to Cryptographic Hardware − CEX2/3C hardware feature for z114, z10 and z196− CEX4S hardware feature for z12BC and z12EC− CEX5S hardware feature for z13 (2x faster over CEX4S)

Enhanced Key Management for key creation and distribution− Public and private keys− Secure and clear keys− Master keys

Created keys are stored/accessed in the Cryptographic Key Data Set (CKDS) with unique key label− CKDS itself is secured via Security Access Facility

Presenter

Presentation Notes

ICSF is an IBM product that provides the interface for data encryption services for z/OS software. As we know already at this point, keys are a crucial part of the encryption and decryption process. They are stored in what is referred to as the Cryptographic Key Data Set, or CKDS.



CKDS – Cryptographic Key Dataset

Key element of the IBM encryption solution on z/OS VSAM Key Sequenced Dataset Contents are ICSF generated data encrypted keys Accessed by ICSF API and Services

– Key Label (known by application requestor) used to find key record in the CKDS

Copy of CKDS cached in operating system storage at first ICSF invocation for performance– Refreshable

CKDS administration performed using ICSF services and ISPF interfaces.

Use of specific individual keys can be controlled via RACF profiles and permissions

CEX2/3C/4C/5C hardware feature required for use– Unless with a combination of HCR7751 or greater and clear key only,

then “crypto cards” are optional

Presenter

Presentation Notes

By using ICSF, you can generate clear keys by using either the key generator utility program (KGUP) or the key generate callable service. KGUP stores the key that it generates in the CKDS. The IBM Data Encryption for IMS and DB2 Databases tool uses data encryption keys that are stored inside the CKDS (a special RACF protected dataset) and may be extracted, encrypted, and decrypted through the use of the CEX2C hardware feature. This is an optional feature. This is the most secure key management solution available on the market today, and is the only solution that is EAL5 and FIPS 140 Level 4 compliant (these are security standards maintained by the NIST and NSA).



What are Keys? (From an ICSF Perspective)

Master Keys– Loaded into the “crypto cards” hardware, and stored NO WHERE else

• Pass Phrase Utility• ISPF Panels• TKE Workstation (optional hardware feature)

– Used to generate, encrypt, and store user keys into the CKDS (Cryptographic Key Data Set)

User Keys (Data Encrypting keys)– Generated via ICSF services – Stored inside the CKDS– Clear or Secure– Used by the IBM “Encryption Tool” in conjunction with the encryption

algorithm to convert user data to “cipher text”

Presenter

Presentation Notes

Master Keys - All other keys that are encrypted under a master key are stored outside the protected area of the cryptographic hardware (in CKDS); they cannot be attacked because the master key used to encrypt them is itself secure inside the tamper-protected cryptographic hardware and is zeroed if any attack is attempted. This is an effective way to protect a large number of keys while needing to provide physical security for only a master key.



Clear Key / Protected Key / Secure Key

Clear Key – key may be in the clear, at least briefly, somewhere in the environment

Protected Key – key value does not exist outside of physical hardware, although the hardware may not be tamper-resistant. Requires the use of a master key.

Secure Key – key value does not exist in the clear outside of the HSM (secure, tamper-resistant boundary of the card)

Presenter

Presentation Notes

Clear key is appropriate for applications that do not mandate the use of secure hardware (meaning a crypto card) to protect the key and require the highest level of performance. For example, data that is transient i.e. only exists briefly in storage or in transmission, may be able to take advantage of the better performance of clear key. Protected keys provide secure protection for the operational keys while at rest (i.e. stored in a data set) but use the CPACF to provide the best performance, so they may provide an acceptable alternative for secure keys for applications with strict performance requirements that might otherwise use clear keys. Secure keys dodo provide additional protection for key values within the operating system,but at the cost of performance.



Some general comments on using secure or clear key Clear Key vs. Secure Key Performance

– Clear key elapsed time performance is MUCH superior than secure key– Secure key (performed inside the “crypto card”) is generally viewed as more

secure from a cryptographic perspective– Clear key uses special instructions that run on the z9 – z10 general purpose

processors, so performance is measured in milliseconds– Secure key encryption is dispatched to run on the cryptographic

coprocessors on the “crypto card” feature. This tends to be measured in microseconds as this is essentially an I/O operation.

– Secure key elapsed time measurements (depending on workload and SQL type) can be from 10x to 40x more than clear key

– Secure key is probably NOT appropriate for most (to date all) OLTP workloads, but each customer needs to make this encryption decision based on their security requirements and performance expectations

Presenter

Presentation Notes

Performance is always the #1 most asked question .. Encrypting data does come at a price …. so here are some things to consider and to be aware of …



DB2 BUILT IN ENCRYPTION



DB2 Built-In Functions

Under application control – you encrypt the fields that need to be secure– ‘Password for Encryption’ is hashed to generate a unique key– Hint can be used as a prompt for remembering the key– Encrypted field must be defined as VARCHAR (since it will contain binary data once its

encrypted)– The encrypted field will be longer (next multiple of 8 bytes + 24 bytes of MetaData + 32

bytes for optional hint field)– TDES Only!

Encrypt (StringDataToEncrypt, PasswordOrPhrase, PasswordHint) Decrypt_Char(EncryptedData, PasswordOrPhrase


IBM Security Systems©

DB2 BIFs - HardwareRequirements• zEC12/zBC12, z196/z114, z10 (CPACF)

• Uses MSA instructions, not the ICSF APIs, but ICSF must be started to provide hashing support

• TDES only



IBM GUARDIUM DATA ENCRYPTION



Overview

A Single tool for both DB2 and IMS Data Encryption addresses the increased demand for data privacy and security Performs encryption and decryption through the use of exit routines. Leverages the System z®, zSeries®, and S/390® Crypto Hardware to encrypt data Protects sensitive data that can reside on various storage media

– For DB2, log records, image copies, and data buffers are encrypted– For IMS, image copies, data buffers, and log records that log changes to database

records are encrypted– IMS data that is decrypted is also logged



Features and Benefits

Enables compliance with privacy and security regulations Customization down to DB2 column level and at the IMS segment level Straightforward implementation using RACF key labels Ensures data privacy by encrypting and decrypting data Uses the following encryption algorithms:

– Triple Data Encryption Algorithm (TDEA), also known as the Triple Data Encryption Standard (Triple DES)

– ANSI Data Encryption Algorithm (DEA), also known as the Data Encryption Standard (DES)

– Advanced Encryption Standard (AES)



Features and Benefits (continued)

Requires no changes to your applications Conforms to the existing z/OS and OS/390® security model Provides an ISPF front end to create and customize encryption exit routines Enables you to leverage the power of Storage Area Networks (SANs) safely while

complying with privacy and security regulations



Data Encryption Tool – HardwareRequirements• Clear Key

• zEC12/zBC12 /z196/z114/z10

• Secure Key• zEC12/zBC12 /z196/z114/z10

• Protected Key

CPACF & crypto card for CKDS*

Requires a crypto card

• z196/z114/z10• zEC12/zBC12

Requires a CEX3CRequires a CEX4SC or CEX3C

*Prior to HCR7750 a crypto card is required to create and use a CKDS, beginning with HCR7751 ICSF supports a clear key only CKDS**Protected Key support requires HCR7770 or higher



DB2 DATABASE ENCRYPTION



Properties Self Encrypting Devices DB2 Builtin EDITPROC UDF

Satisfies PCI Yes for data at rest audit requirement App Dependent Yes . For data at rest andin flight to/fromapplication.

Yes . For data at restandin flight to/fromapplication.

Complexity No Application Changes. Complex ApplicationChanges No Application Changes Application Transparent

Implementation Mount encryptable volume onappropriately configureddrive.

ALTER and reLOAD DROP and reLOAD SQL UPDATE

Clear Passwords No Yes No No

Access Control No application securityprovided App Managed Table Level RACF secured UDF

AdditionalHardware Yes,. Major investment. No No No

Key Control Tivoli managed App Managed ICSF Managed ICSF Managed

Maintainability Transparent Transparent Easy Centralized

Performance Best App Dependent Acceptable Overhead forencryptedcolumn

Index Encryption Yes Yes No Yes

Data Protection Only protect on media Clear Key Unload Data in clear Always Protected

Data TypeIndependence Yes Yes Most data types Yes

DB2 Data Encryption



DB2 Data Encryption Flow – Insert / Update

1)

Application Storage

Encryption EDITPROC

Integrated Cryptographic Service Facility

(ICSF)

Cryptographic KeyData Set

DB2 Buffer Pool

1 SQL Insert/Update

2 5

3 Unencrypted Row

4 Encrypted Row

6

6

Encryption Put EncryptedRow

Unencrypted Row B Encrypted Row

EncryptedRow

EncryptedRow

SQL Request

Application Storage

Unencrypted Row

KeyLabel

User Key

B

B



Cryptographic Keys

• Data Encryption Tool• Key must be stored in the CKDS• When the table with an EDITPROC/FIELDPROC is in use,

the key is available in the DB2 address space

• DB2 BIF• Clear key only (it’s calculated by hashing the password

for encryption) – so it’s available in the DB2 address space

• Keys are not stored in a dataset, but the password for encryption is stored in the table



Implementing/Changing Cryptographic Data Keys

• Data Encryption Tool• Unload, change EDITPROC/FIELDPROC to reference

new key, reload• Unload, change current key, DB2 restart, reload

• DB2 BIF• Under application control



• Index not encrypted• Encryption Tool EDITPROC – index is not encrypted (EDITPROC encrypts the

entire row, so the data is encrypted, but the index is not)• Bad for security, good for performance

• Index encrypted• FIELDPROC - index can be encrypted• DB2 BIF - Application encrypts the field, if that field is an index, then the

index is encrypted• Good for security, but may impact performance

Database Indexes

INDEX SSN NAME ADDRESS

223491398 F{(œ(•´ú— GÿÞ# ¥†‰jÍiÑÆ

INDEX SSN NAME ADDRESS

F{(œ(•´ú F{(œ(•´ú— GÿÞ# ¥†‰jÍiÑÆ



Comparison of Supported DB2 Encryption Methods

Function EDITPROC FIELDPROC UDFRow based encryption

Column based encryption

Application impact during implementation (Drop/CREATE) 1

maybe

SQL based implementation

“Clear Key” AES, TDES/DES

“Protected Key” AES, TDES/DES

AES AES

“Secure Key” AES, TDES/DES

1. New encrypted columns can be added using FIELDPROC encryption by ALTER ADD COMUNN SQL. Encrypting an existing column requires DROP/CREATE.



Edit procedure DECENA00

Advantages DisadvantagesNo application code or SQL changes Cannot encrypt indexes

Is column data-type independent Uses an ICSF feature that moves the encryption key into program storage. This disadvantage is deemed an acceptable risk by some users.

Excellent performance Must drop and reload databases to implement encryption that is affecting database availability

Uses RACF and SYSADM or SECADM access control

Decrypts rows for users and applications for each access

Key may be in the clear at least briefly somewhere in the environment

Key type: ICSF Key Retrieve (Clear Key) You can use an edit procedure to transform values on a row



Edit procedure DECENB00

Advantages DisadvantagesNo application code or SQL changes Cannot encrypt indexes

Is column data-type independent Must drop and reload databases to implement encryption that is affecting database availability

Uses ICSF release HCR7770 or newer technology on the latest z/OS hardware

Decrypts rows for users and applications for each access

Uses acceptable RACF and SYSADM or SECADM access control

The key does not exist outside of the physical hardware however, the hardware may not be tamper resistant

Key type: ICSF CPACF Protected Key You can use an edit procedure to transform values on a row



Edit procedure DECENC00

Advantages DisadvantagesNo application code or SQL changes Performs poorly because of the secure, but

restrictive, processor ICSF architectureIs column data-type independent Is recommended only for small databases

Is the most secure technology available. The key does not exist outside of the tamper resistant card.

Cannot encrypt indexes


Must drop and reload databases to implement encryption that is affecting database availabilityDecrypts rows for users and applications for each access

Key type: Secure Key You can use an edit procedure to transform values on a row



FIELDPROC DECENF00

Advantages DisadvantagesPerforms well for single column Can degrade performance if more than 2

columns are encrypted

Uses ICSF release HCR7770 or newer technology on the latest z/OS hardware.

Has column data type restrictions


Cannot use column lengths that exceed 254 bytes in length

Can encrypt indexes Cannot use column names that exceed 18 characters in length

Can be implemented by using ALTER ADD NEW COLUMN, thus maintaining database availability

Decrypts columns for users and applications even when it is not necessary for the application or user

Can be implemented by using UPDATE, thus maintaining database availability

Does not decrypt unloaded columns

Key type: ICSF CPACF Protected Key You can use a field procedure to transform values in a single, short string column.



UDF DECENU00

Advantages DisadvantagesIs data-type independent Can slow down performance during mass

updates and predicate processing. Ensure that the DB2 WLM started task is set to the maximum velocity to help performance

Uses ICSF release HCR7770 or newer technology on the latest z/OS hardware.

Does not decrypt unload columns

Can use DB2 MASK, VIEW, and TRIGGER features, RACF® SYSADM or SECADM to provide comprehensive granular access control

Can encrypt indexes

Can avoid performance issues for non-authorized users (by using DB2 MASK, VIEW, and TRIGGER features)

Can be implemented by using UPDATE, thus maintaining database availability

Does not decrypt unloaded columns

Key type: ICSF CPACF Protected Key You can use the UDF to manage access control of encrypted data.



IMS DATABASE ENCRYPTION

IBM Guardium Data Encryption



IMS Encryption Flow

Encryption

1. IMS application program passes a segment REPL, ISRT, or LOAD request to the IMS control region. IMS uses the DBD to determine that a Segment Edit/Compression exit is required, so IMS loads the exit.

2. Exit invokes ICSF services, passing user-defined data encryption key label (provided by exit) and unencrypted segment.

3. When the segment has been successfully encrypted, the exit passes the segment back to IMS.

4. IMS then puts the encrypted segment into the database



IMS Decryption Flow

Decryption

1. IMS application program passes segment GET request to IMS control region. IMS determines, from DBD, that a Segment Edit/Compression exit is required, so IMS loads the exit.

2. IMS retrieves encrypted segment from the database.

3. IMS then calls the exit and passes it the encrypted segment. The exit invokes ICSF services, which passes the user-defined data encryption key label (provided by exit) and the encrypted segment.

4. When the segment has been successfully decrypted, the exit passes the segment back to IMS.

5. IMS passes the decrypted segment back to the application.



Comparison of Supported IMS Encryption Methods

Function DECENA01 DECENB01 DECENC01Segment based encryption (Key and or Data)

“Clear Key” TDES/DES

“Protected Key” AES

“Secure Key” AES, TDES/DES




ICSF Services For IMS Encryption

Function DECENA01 DECENB01 DECENC01Segment based encryption (Key and or Data)

“Clear Key” CSNBSYE and

CSNBSYD

“Protected Key” CSNBSYE and

CSNBSYD

“Secure Key” CSNBENC and

CSNBDEC




ICSF ‘to do’s”:• Configure the Integrated Cryptographic Service Facility (ICSF)• Enable CP Assist for Cryptographic Functions (CPACF)• Install and enable Crypto Express feature (Crypto card)• Generate and store in the Cryptographic Key Data Set (CKDS) Key Labels

DB2 encryption “to do’s”:• Build the DB2 EDITPROC• Generate Data Encryption Key with ICSF ISPF• Obtain Key Label from ICSF Administrator• Use the Sample JCL Provided or the ISPF Panels to generate EDITPROC• Back - Up and Unload Databases• Create EDITPROCS for DB2• Reload the Databases: Data Bases will be Encrypted• Validate your Output

IBM Data Encryption for IMS and DB2 DatabasesImplementation Summary

Presenter

Presentation Notes

As you can see above, the items in BLUE are the steps needed to prepare the ICSF environment, these tend to represent the most work, in particular to the new to encryption customer. a choice of clear key only, much of this work is bypassed. Once installed, via SMPE, the tool provides for a easy to use interface to generate appropriate EDITPROCs. The implementation of the EDITPROC is relatively straight forward, in essence: UNLOAD DROP/CREATE LOAD



IBM Data Encryption for IMS and DB2 DatabasesImplementation Summary

Implementing IMS Encryption with the Data Encryption Tool– Generate Key using ICSF KGUP (Key Generation Update Program)– Prepare your exit using Data Encryption Tool providing ICSF Keylabel– Generate the DBD and ACB(s) to include the COMPRTN value– Unload target database– Activate the ACB to your IMS systems– LOAD the target database– /STA db– Encryption is now operational



Summary

Encryption is an integral part of a total security package Database encryption provides an additional layer of data security Database encryption adds protection for “data in use”



IBM Security Guardium family

SC18-9549 IBM Data Encryption Tool for IMS and DB2 Databases User Guide

Includes an appendix on activating crypto on your hardware

ICSF Manuals

SA22-7520 ICSF System Programmer’s Guide

SA22-7521 ICSF Administrator’s Guide

Redbooks

DB2 UDB for z/OS Version 8 Performance Topics – SG24-6465

Articles

IMS Newsletter article: “Encrypt your IMS and DB2 data on z/OS”

ftp://ftp.software.ibm.com/software/data/ims/shelf/quarterly/fall2005.pdf

For more information

http://www.ibm.com/software/products/en/ibm-security-guardium-family