essential guide encryption pdf

7/29/2019 Essential Guide Encryption PDF

1/7

BY CAROL WOODBURY APRIL 2006

RIVEN BY REGULATORY COMPLIANCE

issues and the ever-grow ing threat o f compro-

mised private data, more and more organizations

are sta rting encryption projects. When d one

right, encryption can add an excellent layer of defense on

top of the good access controls already protecting your data.

Before you jump right into the implementation phaseof your encryption project, lets look at the most critical

part understanding the purpose and the scope of the

project. An encryption pro ject, pa rticularly one involving

the encryption of fields in database files, is not a trivial

undertaking. Its critical that you plan and design it properly.

Understand the Purpose of Your ProjectIf you w ant to keep your data secure, simply encrypting it

w ill probably no t a chieve your goal (well discuss this in

more detail later). If your goal is to comply with a regulation

such as the Pa yment C ard Industry (PC I) Dat a Security

Standard, then you must carefully read and understand its

requirements. The PCI Data Security Standard has detailedencryption requirements and sets the expectations o f w hat

PCI auditors will look for in your implementation.

If you are encrypting to satisfy a law (such as the

notification laws that have recently sprung up in numerous

states), I recommend that you design your implementation

as though you were meeting a standard such as PCIs. Most

states notification laws do not provide details about the

type or strength of encryption required; rather, they simply

exempt the entity from having to notify individuals if the

breached data was encrypted. You might as well implement

a strong encryption scheme with strong key management

processes in case the law s change and start specifying strict

requirements (or your business changes, and you suddenly

find yourself having to comply with a strict law or regula-

tion). In other words, if youre going to the trouble of

implementing encryption, you might as w ell do it right. For

a list of encryption resources, see Find Out More, on page 3.

Identify the Scope of Your ProjectThe first step in identifying the scope of your encryption

project is to determine w hat dat a you a re going to encrypt.

This decision is not one that should be made in a vacuum

in other words, what data gets encrypted should not

be the sole decision of the IT administrator or programmer

in charge of the project. The decision needs to be made

with the help of the data owners and possibly your

organizations legal counsel. Why? Because no single

person is aware of all of the regulations that determine

w hat constitutes private data , of the laws a nd regulations

that govern protection of private data, of the ramificationsof not protecting the data or having the data compromised,

and of all the places where the data is stored and how it

is used. To d o t his project right, you need input f rom

numerous individuals from around your organization.

Only after you gather this input can you know the true

scope of your project and decide how to proceed. Lets look

at the steps you need to determine the scope of your project.

Step 1 Determi ne the type of data to be encrypt ed.

The laws and regulations with which your organization

must comply might dictate the type of data you must

D

T H E E S S E N T I A L G U I D E T O

1 SUPPLEMENT TO iSeries NEWS 2006


2/7SUPPLEMENT TO iSeries NEWS 20062


3/7

T H E ES SE N T I A L G U I D E T O EN C RY PT I O N

encrypt. For example, if your organization stores credit

card numbers, the PCI Data Security Standard dictates

the type of data to encrypt. If youre storing protected

electronic healthcare informa tion, then H IPAA dictates

the data to encrypt especially w hen data is being

transmitted. In other cases, your organization might be

doing business with a company that has encryption

requirements to fulfill its service agreement. Finally,

the datas owners might determine that their data mustbe encrypted.

Step 2 Determ i ne where the data i s stor ed.

Determining the type of data to encrypt is the easy step.

A more difficult ta sk is determining all and I do mean

all of the places where the data resides. Without fail,

private or confidential data resides in more places than

one first ima gines. To ensure that this list is complete, you

will probably need to assemble a group of programmers,

system administrators, database owners (such as the lead

HR administrator), database administrators, system

analysts, and even representatives from your third-party

software vendors. In making this list of all data occur-

rences, remember the private information that resides in

spooled files, outfiles, query files, text files, stream files,

and printed reports. Also make note of databases replicated

to high availability (HA) machines, databases residing on

development machines (including copies of the production

dat aba se made into developers libraries), logical files

that include the fields to be encrypted, and data residing

on network servers and desktop applications (e.g.,

Excel spreadsheets).

After listing all the places where the private data resides,

examine each instance to determine whether the private

data is actually required or can be eliminated for that

specific instance. In many cases, you can significantly

reduce the scope of yo ur project (as w ell as the exposure

to your organizations private data) if you dont store theprivate data on servers, disallow it to be included in queries,

create a logical file that does not conta in the fields w ith

private data, and eliminate the private data from printed

reports and Excel spreadsheets. Often, the data is included

in these places simply because its part of the information

in the original file structure, not because its actually

necessary. Or, perhaps the data has o nly recently come

to be considered susceptible to abuse at one time,

information such as Social Security numbers were not

considered to be sensitive. Oh, how times have changed!

For example, do credit card numbers really need to be

included on a printed report of all returns to a store if the

person viewing the report is interested only in what s being

returned and the reason for the return? No, they dont.

Viewing credit card information is not part of this persons

job function, and therefore it should be removed from the

report. And without question, removing the credit card

number from the report is much easier than adding logic

to the application to allow this individual to see decrypted

data. It also eliminates the problems of putting appropriate


FIND OUT MOREOther Resources

Appli ed Cr yptography: Proto cols, Al gorithms, and Source Code in C

Wiley, 1995. ISBN: 0471117099

Cryptography for D ummies

For Dummies, 2004. ISBN: 0764541889

Cryp tography Decrypt ed

Addison-Wesley Professional, 2000. ISBN: 0201616475

Cry ptographic Toolkit from the Na tional Institute of Sta ndard s and Technology (NIST)

csrc.nist.gov/CryptoToolkit

NISTs recommendations fo r key ma nagement (direct link to .pdf)

csrc.nist.gov/publications/nistpubs/800-57/SP800-57-Part1.pdf

O ffi cial (ISC)2 Guide to the CISSP Exam,Chapter 6AUERBACH , 2003. ISBN: 084931707X

Payment Card Industry (PCI) Data Security Standard

usa.visa.com/business/accepting_visa/ops_risk_management/cisp.html?ep=v_sym_cisp

Practical Crypt ography

Wiley, 2003. ISBN: 0471223573

Sans Organization

sans.org

iSeri es NEWSarticles at

iSeriesNetwork.com

Accessing V5R2 Cry ptographic

Services APIs from RPG

(article ID 20374)

APIs by Example: Cryptographic

Services APIs, Parts 14

(article IDs 51236, 51786,

51863, and 51962)

Cryptographic Services APIs:

A Tutor ial (ar ticle ID 20312)

Triple-DES Encryption from RPG

(article ID 51211)
http://csrc.nist.gov/CryptoToolkit/http://csrc.nist.gov/publications/nistpubs/800-57/SP800-57-Part1.pdfhttp://usa.visa.com/business/accepting_visa/ops_risk_management/cisp.html?ep=v_sym_cisphttp://sans.org/http://iseriesnetwork.com/http://sans.org/http://usa.visa.com/business/accepting_visa/ops_risk_management/cisp.html?ep=v_sym_cisphttp://csrc.nist.gov/publications/nistpubs/800-57/SP800-57-Part1.pdfhttp://csrc.nist.gov/CryptoToolkit/http://iseriesnetwork.com/



access controls on the file, a dding routines to encrypt the

credit ca rd number, a nd dealing w ith the proper disposal

(shredding) of the printed reports.

Step 3 Determine how the inf ormati on i s being used.

This step, w hile easier tha n step 2, still usually ta kes an

assembly of individuals to complete. You want to under-

stand how the data is being used so you can determine

the type of encryption thats required. For example, if the

data is a Social Information number (in Canada) or adrivers license number used only for verification purposes,

you can likely store it in a one-way hash. A hash cannot

return the original data; it is one way only. For that reason,

hashing private data is much easier to implement and

even more important more secure than implementing

more complex encryption algorithms that allow decryption

of data.

To ensure encryption provides a n a dditiona l layer o f

protection on top of the access controls you have on the

files containing your data, you will want limit the scenarios

for which the data must be decrypted. For example, if

the data is being sent to a bank for transaction processing

or to a clearinghouse for verification, it is likely tha t clear

text da ta is required. For this scenario, you w ill have to

determine how and w hen to d ecrypt the data so t hat the

dat a is in clear text for a s short a time as possible. Also,

as soon a s the clear text da ta has been tra nsmitted over

an encrypted session, it w ill need to be removed or cleared

as soon as possible.

Types of EncryptionD ont w orry, Im not going to get into a full dissertation

on encryption algorithms. But a s you start to read aboutencryption and do further investigation for your encryption

project, you w ill hear a bout various algorithms, a nd you

might find a quick explanation helpful. G enerally speaking,

there are three types of encryption algorithms (Figure 1).

Symmetri c key al gori thmsuse the same key to both

encrypt a nd d ecrypt da ta. They are generally fa ster tha n

asymmetric key a lgorithms and are oft en used to encrypt

large blocks of data. Algorithms youll hear mentioned

include Da ta Encryption Standa rd (DES), Triple DES, RC5,

and Advanced Encryption Standard (AES) the standard

for the U.S. government.

Asymmetric k ey al gori thmsuse one key to do one

function and another key to do the opposite function. In

other words, the same key cannot be used to both encrypt


4

Figure 1:Types of encryption


5/7


SUPPLEMENT TO iSeries NEWS 2006

use a formal random number generator to ob tain the

seed for your key generation system.

Changi ng the keys. You must also be prepared to

explain to auditors your process for changing keys. If a

breach occurs or you become aw are that the encryption

key has been compromised, you will need to decrypt the

data and reencrypt it using a different key. You will want

to ca refully plan a nd then do cument yo ur procedure for

accomplishing this task. Best practices also state thatkeys regardless of whether they have been compromised

should be changed every year or t w o. The exception

to this rule is when theres a good chance of compromising

the data by decrypting and reencrypting it rather than

leaving it encrypted w ith an old key. Whether or not you

change keys regularly, you need to establish and document

a policy reflecting your key management change practices.

Stor i ng the keys. Appropriate placement and access

control of stored keys is vital. Many people think they

need to keep their encryption algorithm a secret, but the

secret that must be kept is the key itself. Therefore, storing

keys in clear text in the program source or in a data area

is a bad idea. One choice is to use a validation list for

secure storage of keys (by the time you read this, V5R4

will be released, and it provides some integrated key

management features). Validation lists provide a method

for storing and encrypting small amounts of data, such

as encryption keys. Another choice is to use a vendor

product tha t provides key ma nagement w ith the vendors

product offering.

Controll ing access to the keys and encryption/decrypt ion

routines. Without strong a ccess controls (that is, object

security) on the keys and encryption routines (especially

the decryption routine), you get no additional security

benefit by encrypting the data. If anyone on the systemhas access to the decryption key, whats the point? In

addition, you must realize that you cannot protect your

encrypted data from being decrypted by an *ALLOBJ user.

Remember, users w ith *ALLO BJ special a uthority ca n

access any object on the system (this is why I prefer to

use hashes whenever possible). The best you can do to

ward off access by *ALLOBJ users is to throw up some

roadblocks to make it more difficult to run the encryption

routine, a nd thus discourage them from try ing to decrypt

the data . O ne such road block is to q uery the process to

see whether its running with *ALLOBJ, and if it is, reject

the request. Another is to check the program calling the

decryption routine and decrypt only if the calling programis in an approved list. But understand no method is

a perfect prevention mechanism against abuse by an

*ALLOBJ user.

Now lets look at the issues surrounding the two methods

people are currently most interested in encrypting

backups and encrypting a field in a database file.

Encrypting Backup MediaTwo popular methods exist for encrypting backup media.

One is to first save the data to a save file (*SAVF), encrypt

and decrypt the dat a. These algorithms a re typically used

for authentication; for example, they are used during

an SSL handshake to verify that the client knows the

server to which its trying to connect. Asymmetric key

algorithm types include Rivest-Shamir-Adlem (RSA)

and Elliptic Curve.

H ash algori thmsproduce a result that cannot be

decrypted. They are typically used f or t he comparison

of two values to ensure they are the same. For example,the verification of a digital signature uses a ha sh function

to ensure that the signed document has not been altered.

Because a hashed value cannot return the original value,

this method provides the most secure form of storing data

and is the most a ppropriate method w hen the original

form is not required. Message-D igest algorithm 5 (MD 5)

and Secure Ha sh Algorithm (SHA-1) are tw o exa mples

of hash algorithms.

What Are the Challenges?Transmitting encrypted cardho lder data isnt a challenge

for most shops; theyre already doing it either through the

funct ions pro vided b y i5/OS (e.g., https, secure FTP) orthrough a vendor solution. Some organizat ions are deciding

that encrypting their backup media is a requirement.

Although this poses some interesting challenges, the bigger

challenge for mo st orga nizations is the requirement to

encrypt private data residing in database files. This brings

up several issues the implementa tion w ill most likely

require some redesigning of the database, you must

determine how to securely store and manage the encryption

keys so t hat only the a ppropriate people have a ccess to

them, and you must plan how to handle the new disaster

recovery issues tha t encryptio n presents. The online

version of this Essential G uide contains a discussion of

key management issues.

The Key Is Key ManagementI cannot emphasize enough that without solid key manage-

ment, your encryption project will likely be a disaster and

provide absolutely no additional security to your data.

C onsider these best practices for key ma nagement.

Separat ion of du ti es. The same person should not create

the keys, use the keys (write programs to use the keys for

encryption or decryption), and act as the custodian of the

keys. For large shops, this should not be an issue, but for

small iSeries shops, it may present a challenge. Either w ay,

you must be prepared to explain your separation of key

management duties to any a uditor w ho a sks.

Cr eati ng the keys. C reating strong encryption keys

hinges on seeding the key generatio n a lgorithm w ith a

totally random number. You might think just typing in

some number will suffice after all, it looks random to

you, right? But studies have show n tha t people type in

a certain pat tern; in reality, the key is not ra ndom b ut a

manifestation of the persons typing pa ttern. Therefore,

your data is weakly encrypted, allowing hackers to easily

decrypt it using dubious methods. Word to the w ise

5


6/7

Carol Woodburyis cofounder of SkyView Partners, Inc., a firm

specializing in security compliance management and assessment

software as well as security services. Carol is the former chief

security architect for AS/400 for IBM in Rochester, Minnesota,

and has specialized in security architecture, design, and c onsult-

ing for more than 15 years. Carol speaks around the world on a

variety of secur i ty topics and is c oauthor of Experts Guide to

OS/400 and i5/OS Security (29th Street Press, 2004). E-mail

Carol at carol.woodbury@skyview partners.com.

the *SAVF, and then save the encrypted *SAVF to the

media. This method requires that you have storage available

for the *SAVF. Depending on how much data is being

saved, this approach can use a significant amount of

storage, which will present problems on some systems.

The other method is a hardw are solution in w hich the

device performs the encryption before the data is written

to media. This technique removes the requirement for the

intermediate save file.Rather than encrypt data on the media, some people use

compression softw are. C ompression softw are reduces the

space required for the backup data and produces what I

call mangled data. While mangled data is not easily read,

it is not the same as encrypted data, and it may not meet

the requirements of the laws or regulations with which

you need to comply. Make sure to take this into account

when considering this option.

Whichever method you choose, you should determine

how key management will be performed and develop a

procedure for retrieving the key when da ta needs to be

restored to the system. You must also determine the impact

on yo ur disaster recovery plan, then upda te your d isaster

recovery plan to include the procedure for recovering the

keys, as well as account for any new hardware requirements

for ho t site locations. Although its not a security issue,

you w ill also w ant to look at t he performance impact of

encrypting backups and the subsequent impact on your

system operators schedules.

Encrypting a Field in a Database FileIBM provides several options for encrypting data in a

database field. The most rudimentary one (but the only

one provided before V5R2) is coding to the CIPH ER

machine instruction. If you are running V5R3, APIs are

integrated into i5/OS tha t provide soft w are encryption

functionality. A subset of this function is available via PTFs

in V5R2. Finally, for t he most secure method, as w ell

as the most complex, you can install a FIPS-compliant

hardware cryptographic coprocessor card and write to

the APIs provided. The crypto card is the only IBM

solution that provides encryption key management features

prior to V5R4.

You can find documentation for all of these encryption

methods in IBMs Information C enter (publib.boulder.

ibm.com/iseries). However, writing to these interfaces

yourself without some knowledge of encryption method-

ology w ill result in a less-than-optimal implementat ion.Another IBM solution is to use the SQL ENCRYPT_RC2

keyword, but I dont recommend this method. Remote

da tab ase access requires that the key be passed in clear

text. Because of this and other issues, its doubtful that

using this keyword w ill provide an implementat ion tha t

will pass any type of regulatory compliance.

Several vendors also provide solutions for database

encryption. When investigating these solutions, make

sure you und erstand their key ma nagement capab ilities

to ensure they meet your project requirements.

Whatever method you choose, some amount of

redesigning may be required. The ideal solution is to

redesign your application and move each type of private

data into its own da taba se (e.g., one for cardholder data ,

another for HR data). This method makes it much easier

to ensure the encryption/decryption functions are called

only w hen necessary, w hich helps keep the dat a secure.

It a lso helps minimize the effect of encryption on system

performa nce because the data is decrypted only w hennecessary, not on every file open. Additionally, you are

in a much better position to respond quickly should the

encryption requirements change in the future.

If moving the data to another file is not an option,

you will most likely have to declare a new field for the

encrypted value because the encrypted value is almost

always significantly larger than the original value. Once

the encrypted field is populated, youll have to take steps

to neutralize or otherwise w ipe out the clear text

version of the private da ta currently residing in t he file.

Again, you need to restrict w hen the data is being

decrypted. Using a trigger program that blindly decrypts

the da ta w henever the file is opened d efeats m ost if

not all benefits gained by encrypting the data. Make

sure that when you implement your decryption scheme,

it is invoked o nly w hen the clear text da ta is required.

Disaster Recovery ConsiderationsWhen planning your encryption project, remember to take

into account the impact on your disaster recovery plans.

If the media is encrypted, youll need to make the keys

available at your a lternate location so that media can be

read and data restored. If you used a hardware encryption

method (for either encrypted backups or encrypting data

in database files), the same hardware must also be available

at your recovery site. Finally, w hen encrypting data w hile

its being transmitted, ma ke sure that yo u have the

appropriat e digital certificates installed in your servers

or VPN configurations.

Success Depends on PlanningAn encryption project should not be taken lightly. It takes

significant planning and a well-designed implementation

to ensure success. Determining the regulatory issues with

which you must comply as well as the scope of your project

are keys to your projects success. This information will

help you decide whether to implement one of the options

from IBM or to evaluate vendor solutions.



About t he Aut hor
http://localhost/var/www/apps/conversion/tmp/scratch_2/publib.boulder.ibm.com/iserieshttp://localhost/var/www/apps/conversion/tmp/scratch_2/publib.boulder.ibm.com/iserieshttp://localhost/var/www/apps/conversion/tmp/scratch_2/publib.boulder.ibm.com/iserieshttp://localhost/var/www/apps/conversion/tmp/scratch_2/publib.boulder.ibm.com/iserieshttp://localhost/var/www/apps/conversion/tmp/scratch_2/publib.boulder.ibm.com/iseries

essential guide encryption pdf

Documents