Full disk encryption may be the most used encryption strategy in practice today for data at rest, but it may not be the best choice for every situation.  File-based encryption is another form of transparent encryption that fills in the gaps where full disk encryption falls short. As companies look to leverage encryption as part of their security landscape, it can be tempting to just implement disk-level encryption. As security requirements continue to grow and compliance regulations become even more stringent for the IBM i environment, administrators are finding they need to implement encryption at the field level versus disk level encryption. Watch this on-demand webinar to learn: - What are the use cases for disk level and field level encryption? - How do I satisfy PCI compliance auditors' requirements for encryption? - What types of fields should be encrypted? -What are IBM i Field Procedures?

1. Why Disk-Level
Encryption is not
enough for Your IBM i
Bill Peedle | Principal Sales Engineer

2. Today’s Topics
• Benefits of encryption
• Comparing encryption strategies
• Field-level encryption on IBM I
• Additional considerations
• How Precisely can help
2

3. Why use encryption at all?
3
• Applications frequently use and store sensitive data such
as confidential personal details, payment information, or
proprietary data.
• In some jurisdictions, this type of data is subject to
governance, privacy, and security compliance mandates.
• Unauthorized access of sensitive data or a failure to
comply with a mandate often results in significant
reputation damage and financial penalties.
• Therefore, it is important to keep sensitive data secure to
protect your corporate data from unauthorized access.

4. Protect your stored data
with AES Encryption
• The US government and agencies have accepted the
Advanced Encryption Standard (AES) as a format
standard (FIPS -197) for encrypting data in databases.
• For PCI-DSS, HIPAA, and specific government privacy
rules, AES is the preferred encryption method.
• The encryption methods recognized by the National
Institute of Standards and Technology (NIST) ensure
that your data is protected to the highest standards.
4

5. 5
Protect your encryption keys and data by
keeping them separate
If you keep your encrypted data and
keys in the same place, it’s like placing
your house key beneath the mat
Security best practices require you to store encryption
keys separately from your encrypted data and
manage them with an encryption key manager

6. What is a key management server?
6
When encrypting fields in a file, an encryption key is required
• Many customers use an external key manager to store and manage
the master key as well as the encryption keys for the individual fields.
• They may already have an external key manager for other platforms
and can leverage that server for the IBM i encryption as well.
• An example of an external key server would be Thales Cipher trust
or Alliance Key Manager. There are others as well.
• For those who do not want to support an external key manager on a
Windows or Linux server, a local key store can be used on the IBM i
to store and manage the keys. Third party encryption tools typically
include a local key store for this use case.

7. Comparing encryption
strategies

8. What is disk level
encryption?
8
• On the IBM i, full disk encryption allows you to encrypt
data that is stored in basic disk pools and independent
disk pools
• Full disk encryption protects data from several
different threats:
• Protects data transmission to and from the disk drive
(important in a SAN environment)
• Protects data transmission in the cross-site mirroring
environment (only when the data being mirrored is on
an encrypted independent disk pool)
• Protects data in the case of theft of the disk drive

9. 9
What is field level encryption?
• Field procedures can provide field level (or column level) encryption on DB2 for IBM i
• A field procedure is a user-written exit routine to transform values in a single column
• When values in the column are changed, or new values inserted, the field procedure is invoked for each value
• The field procedure can transform values (encode it) in any way.
• The encoded value is then stored
• When values are retrieved from the column, the field procedure is invoked for each encoded value.
• The field procedure decodes each value back to the original value.
• Any indexes defined on a column that uses a field procedure are built with encoded values.
• The fields are encrypted at rest and will be decrypted when a database operation is performed against
the file that has the field in it.
• Fields can be ”masked” based on specific users or groups.

10. What is field level masking?
10
Individual fields can be “masked”
in addition to being encrypted
• One of the big benefits of field
level masking versus disk level
encryption.
• For example, a Social Security
Number (SSN) field can be
masked so that:
• Only certain users or groups can
see the fully unmasked SSN data
• Other users or groups can be
masked to see only the last four
digits of the field
• Other users will see a fully-
masked SSN
Let’s use the Social Security
Number 123456789 as an example
• For users that need to see the full
SSN such as a payroll administrator,
the field is encrypted but gets
decrypted on the fly and they can
see the full number
• For other users, you may decide
that they should not see the full
SSN, so in that case, you can mask
the first 5 digits, so the SSN# would
look like this: XXXXX6789
• You can mask the entire field for
certain people or groups if
appropriate, so the SS# would look
like this: XXXXXXXXX

11. Field level masking
• If the field in question is a numeric field, the mask will
be the number 9. However, if the field in question is
a character field, you can choose the character that
you want to use for the mask.
• For example, if you want to mask a credit card
number that happens to be a character field, you
can choose “X” or whatever other character you
want to use for the mask.
• Let’s use the credit card number 1234567890123456
as an example. If we decide to mask everything but
the last 4 digits (or characters in this case), it looks
like this: XXXXXXXXXXXX3456
• If you decide to mask the entire field, it looks like this:
XXXXXXXXXXXXXXXX
11

12. Field-level encryption
on IBM i

13. What does field level encryption look like on
the IBM i?
13
The best way to see that the field or fields are encrypted on the IBM i is by leveraging the
DSPFFD command. Below is an example of a social security number that is not encrypted:

14. What does field level encryption look like on
the IBM i?
14
After encrypting a field with field level encryption, you will notice new attributes on the
field called “Field Procedure Name” and “Field Procedure Library”. Below is an example
of a social security number that is encrypted via a field procedure.

15. 15
Field procedures are part of the IBM i OS.
They can be used for other purposes but
are primarily used for encryption and
masking
The best way to encrypt and decrypt fields with
field procedures is to use a third-party interface
that will develop the code for you, attach it to
the field in question and help you to manage
and track which fields are encrypted or
decrypted and to set up the masking rules
A field procedure is a procedure that can
be written by hand and attached to the
field, however, that can be a large
undertaking
How do I encrypt
sensitive fields in a file?
Working with Field Procedures

16. Implications with for field level encryption
• While encrypting or decrypting a file, the IBM i requires an exclusive lock on the file until the encryption or decryption
has completed. This means users need to be out of the file until the operation has completed.
• For smaller files, this may not be an issue as you may be able to lock the file for a short period of time. However, for
larger files, this process can take several hours.
• In addition, many customers have requirements to “roll” the encryption keys periodically, which requires decryption
and then re-encryption of the fields with a new key.
• For legacy RPG-ILE programs, if the encrypted field is an index or key on the file, the sort order will be based on the
encrypted data instead of the actual values. There are technologies that can help overcome this situation available
on the market.
Once you have decided on a tool to develop and manage field level encryption on
your IBM i, there are some technical considerations:

17. Minimizing the downtime required
to encrypt/decrypt fields
17
• In order to avoid the downtime required to encrypt fields in
larger files, there are technologies that allow you to ”Encrypt
while active”.
• This technology allows you to make a copy of the file empty
(using CRTDUPOBJ) into a temporary library. Once the file is
duplicated, it can encrypt while it is empty.
• The “Encrypt while active” technology will then copy all the
records from the production copy of the file into the temporary
copy. As they are being copied in, the records are encrypted.
• This technology keeps the file in sync with ongoing changes
since the file is still being used by end users and applications.

18. Minimizing the downtime required
to encrypt/decrypt fields (cont.)
18
• Once you have a maintenance window and have users out
of the file, the process that keeps the file in sync is ended, the
old copy of the file can be moved out of production, and new
encrypted version of the file can be moved into production.
• The file is moved into production using the MOVOBJ
command which simply updates the pointer to the location
of the file from the temporary library to the production library.
It does not perform a full copy of the data so the process
is very quick.
• The ”Encrypt while active” technology can save many hours
of downtime on initial encryption, and then also during the
roll of the key when the file needs to be decrypted and
re-encrypted with a new key.

19. What can I do
if I have legacy
RPG-ILE
programs that
no longer sort
correctly by
an encrypted
key field?
There are technologies
available to help with the
sorting issues that may
occur because of an
encrypted key field in
legacy RPG-ILE programs
These technologies require
access to your source code
Handler software can be
used to convert traditional
record-oriented file access
to SQL Query Engine
(SQE) access
Only one line of code is added
to make this conversion
Presentation name
19

20. Presentation name
What can I do if I have legacy RPG-ILE
programs that no longer sort correctly
by an encrypted key field? (cont.)
20
• This is what the additional line of code would look like to handle the sorting issues in a legacy RPG-ILE program:
• The handler program converts record-oriented reads into SQL access which corrects the sorting issues
experienced by having an encrypted key in legacy RPG-ILE programs

21. Additional considerations

22. Field level encryption performance considerations
22
Any time you add
a new process
into the mix when
dealing with
database
transactions,
expect to have
additional
overhead on your
IBM i processing
time
Since a program
will get executed
each time a new
record is read to
perform the
decryption and
then re-encryption,
that will produce
overhead
Expect programs
to run longer than
they currently do
when the fields
are not encrypted
Testing and
benchmarking
should be done
so that you
will know what
impact the
addition of field
level encryption
will have in your
environment
Performance is
also dependent
on the conditions
of your system –
additional
resources may
be required to
support the
additional
overhead of
encrypting fields
in your database

23. How does field level encryption work with a
HA/DR solution?
• If you have a replication solution in place for high availability or disaster recovery in your environment,
there are a few considerations
• First off, the field procedure program needs to be included in replication. The best practice is to generate
the field procedure in the same library as the file that has encrypted fields.
• Depending on your third-party software solution for encryption, you should have the product installed
and licensed on the HA/DR systems so they are ready to go for a role swap.
• If you are using an external key manager, your HA/DR partition will need to be able to access the server
as it did on the production system

24. So why is field level encryption better than
disk level encryption?
24
Disk level encryption utilizes
the same key for everything.
If the key gets compromised,
all the data on the system
can be decrypted with
one key
Field level encryption can
utilize a different key for
every field, or every file
depending on how you want
to implement it. If one key
gets compromised, the rest of
your data is still protected
Disk level encryption does
not allow for masking
individual fields, whereas
field level encryption allows
for masking to hide sensitive
data from those that may
have access to the file but
shouldn’t be able to see the
sensitive field data

25. How Precisely can help

26. Assure Encryption
26
Complete protection for data at rest and in motion
• IBM i FieldProc exit program-based encryption
• High performance encryption libraries
• Built-in masking of decrypted data based on user or group
• Simplifies and ensures secure encryption key management
• Includes extensive data tokenization capabilities
The only NIST-certified
AES encryption solution for IBM i

27. Assure Encryption
27
Integrates with other applications and key managers
• Encryption commands for Save Files, IFS, and much more
• Extensive encryption APIs for RPG and COBOL
• Native support for Townsend Security’s Alliance Key Manager
• Integrates with any OASIS KMIP-compliant key manager

28. Questions?