1. IBM Informix Dynamic Server 10.00 Security and Column-Level Encryption
Jerry Keesee, Director of Informix Lab
Jonathan Leffler, STSM, Informix R&D

2. Agenda IBM Informix Dynamic Server 10.00
What is Column-Level Encryption?
Manual Pages
Modes of Use
Key Management
Behind the Scenes
Auditing with IDS
Questions and Answers

3. Announcing IBM Informix Dynamic Server 10.00
IDS 10 is IBM’s flagship database for industrial-strength embedded solutions!
IDS 10 is the highest quality and highest performing release ever!
IDS 10 significantly raises the bar for autonomics, availability and low-cost operations!
Generally available since
Description / Target Customers:
Sell IDS for new applications in specific markets.
Target accounts looking to deploy new telecommunications, retail or healthcare applications.
Approach customers with IDS 10 value proposition
Disrupt Oracle’s ability to leverage their install base
Leverage this opportunity to sell new licenses for new applications / projects (‘Reason to Call’).
Promotion / Offering:
IBM wins with “refreshed” partner and customer base
IBM wins with “growth” partner via EPD
Partner wins with new revenues from existing base
Partner wins with new growth via EPD
IBM Sales wins with new application to sell
Partner end-user wins with refreshed application on a viable platform
Routes:
Database & Competitive Reps, Coverage SSRs, Business Partners, TeleSales, FTSS’s (OI)
Coverage (OI, OO):
Top accounts to be assigned to Database Reps/Database Competitive Reps/Coverage SSRs (20 accounts per Rep).
Non Top Accounts : Telesales and/or BPs
Customer Lists:
Americas:
EMEA:
AP: N/A.
Business Units Impacted: WW
Quarters to be impacted: Q1-Q4 FY 2005

4. Key Features of IDS 10.00 Ease of Administration
Automated Re-Sync of Tables in ER
BAR Ease of Use Enhancements
ER Templates / Ease Setup in ISA
External Optimizer Directives
Dynamic Set OPTCOMPIND
ON-Tape Without Involving Backup Media
App Development / SWG Integration
4GL / EGL Merge with WebSphere
.Net Native Provider
Visual Studio Integration
JDBC 3.0 Standards Compliance
Cross DB Built-In UDTs Support
DRDA in ESQL/C & Server
WORF and TDPI Bundled
Performance & Infrastructure
Query Processing Improvements
Load Performance Improvement
Shared Memory Segments more than 4GB
Multiple Fragments of a Table in a Dbspace
Safety / High Availability / Reliability
Table Level Point in Time Restore
Faster Restart
Query Plan and Tracing Tool Enhancements
HDR Setup with External Backup & Restore
Partner Enhancements
Configurable Page Size
Larger Indexes
Buffer Pools
Create or Drop Index Online
Single or Privileged User Admin Mode
Rename DBSpace
Default Roles
Security
Column Level Encryption
LDAP Support for Windows
Restricted Datablade Registration

5. IDS 10.0 is a DBA’s dream come true.”
“To sum it all up,
IDS 10.0 is a DBA’s dream come true.”
Gary Ben-Israel
CIO, National Institute for Testing and Evaluation
Jerusalem, Israel
“Companies that need their data and transaction resources to be available 24x7 will be pleased with the release of IDS With this new release, organizations can tune their database and manage index issues online, without interrupting service.”
Gerd Kaluzinski
Senior Systems Engineer
BYTEC GmbH
“… Table level restore enables us to implement a BCP plan without the need for duplicate servers.”
David A. Link
IS Manager,
West Corporation

6. What is Available in Earlier Versions of IDS?
IDS 7.3x, 9.2x, 9.30, 9.40 provides:
Auditing
A powerful and under-appreciated facility
Discussed briefly at the end
IDS 9.40 provides
PAM
Pluggable Authentication Modules
Configurable authentication mechanism for validating user identities.
Encrypted Communications
Using encryption technology from OpenSSL
Client to server communications
ER server to server communications
Not HDR server to server communications

7. What is Column-Level Encryption?
Data can be stored in encrypted format.
Using SQL functions ENCRYPT and DECRYPT.
Data encrypted using either Triple-DES or AES.
Data encrypted under application control.
DBMS is not aware that data is encrypted.
Can set password at session level with new SQL statement.
Design based on DB2 functions.
DB2 supports DES:
But, since July 2004, the US Government does not.
DB2 does not support AES:
AES (aka Rijndael) is the replacement for DES.
Analogous to Oracle’s DBMS Obfuscation Tool Kit.

8. What is Column-Level Encryption?
Assists in legislative compliance.
HIPAA (Health Insurance Portability and Accountability Act), 1996
Sarbanes-Oxley (aka Sarbox or Sox), 2002
Basel II, 2001
Gramm-Leach-Bliley Act (GLBA), 1999
California SB 1386 ‘Personal Information: Privacy’, 2002
Latest cryptographic standards (OpenSSL 0.9.7c)
128-bit AES and 112-bit Triple-DES

9. Manual Pages – Overview
Passwords and hints
ENCRYPT_TDES function
ENCRYPT_AES function
DECRYPT_CHAR function
DECRYPT_BINARY function
GETHINT function
SET ENCRYPTION PASSWORD statement
Data Space Requirements

10. Manual Pages – Passwords, Hints
Passwords are necessary.
Pass-phrase can be from 6 bytes up to 128 bytes.
Cryptographic hash is used to make random-seeming key.
Random initialization vector also used (and recorded).
Hints are optional.
Hints can be up to 32 bytes of text.
Passwords (and hints) can be set for a session.
SET ENCRYPTION PASSWORD statement.
Hence, the password and hint parameters are optional.
Explicit values override the session default values.
Passwords under six characters or over 128 are rejected.
Hints are encrypted with Triple-DES and a fixed key on disk; hence, the size is rounded up to 40 bytes on disk; over-length hints are truncated.
Anybody can get the hint information with the GETHINT() function, but the information is not visible on disk in clear text.

11. Manual Pages – ENCRYPT_TDES
ENCRYPT_TDES(data [ , password [ , hint ] ])
Input data is encrypted.
For character input data:
Output is base-64 encoded.
For binary input data (BLOB):
Output is unencoded.
Triple-DES encryption
Triple DES uses two 56-bit keys for 112-bits overall.
UPDATE SomeTable         SET EncryptedColumn = ENCRYPT_TDES(?, ?)         WHERE PK_Column = ?;
Extremely variant function.
Basic DES uses 56-bit key.
Triple DES uses two such keys:
112-bit key size
As of July 2004, US Government no longer supports plain DES.
AES is preferred.
Triple-DES is still permitted.
The ENCRYPT_TDES function is pretty much guaranteed to return a different result every time it is used – and you won’t start seeing duplicates for the same data until you’ve processed around 2^56 rows – the Birthday Paradox.

12. Manual Pages – ENCRYPT_AES
ENCRYPT_AES(data [ , password [ , hint ] ])
Input data is encrypted.
For character input data:
Output is base-64 encoded.
For binary input data (BLOB):
Output is unencoded.
AES encryption
Advanced Encryption System (aka Rijndael).
128-bit key size.
INSERT INTO SomeTable         VALUES (?, ENCRYPT_AES(?, ?))
Extremely variant function.
The ENCRYPT_AES function is pretty much guaranteed to return a different result every time it is used – and you won’t start seeing duplicates for the same data until you’ve processed around 2^64 rows – the Birthday Paradox.

13. Manual Pages – DECRYPT_CHAR
DECRYPT_CHAR(encrypted_data [ , password ])
Also known as DECRYPT
Encrypted data in base-64 encoding contains:
Information about encryption method.
All other data needed to decrypt it.
Except the password!
Error if the data is not encrypted.
SELECT         DECRYPT_CHAR(EncryptedColumn, ‘password’)         FROM SomeTable         WHERE PK_Column = ?
Invariant function.

14. Manual Pages – DECRYPT_BINARY
DECRYPT_BINARY(encrypted_data [, password ])
Encrypted data contains:
Information about encryption method.
All other data needed to decrypt it.
Except the password!
Error if the data is not encrypted.
SELECT         DECRYPT_BINARY(EncryptedByteColumn, ?)         FROM SomeTable         WHERE PK_Column = ?
Invariant function.

15. Manual Pages – GETHINT GETHINT(encrypted_data)
Returns the hint (if any) from the encrypted data.
Or an empty string (NULL).
SELECT GETHINT(enc_cc_number)         FROM cc_info         WHERE user_id = ?;
Invariant function.
Anybody can get any hint at any time.

16. Manual Pages – SET ENCRYPTION PASSWORD
New SQL statement
SET ENCRYPTION PASSWORD ‘password’         [ WITH HINT ‘hint string’ ];
Specifies the password that will be used by default.
When no password explicitly provided:
To encryption functions.
To decryption functions.
Optionally specifies the hint that will be used by default:
When no hint provided to encryption functions.
Session wide password management:
For easy programming.
Support for views, triggers, SPL.

17. Manual Pages – Storage Space Requirements
Encrypted data will be stored in character columns.
Needs more space than the unencrypted data.
If input data string is N bytes long:
AES = B64(NGM(N, 16) + H + 8) + 11
Triple-DES = B64(NGM(N, 8) + H + 8) + 11
H = 0 with no hint; H = 40 with hint.
NGM(x,y) – Next multiple of y that is greater than x.
NGM(x, y) = ((x + y) ÷ y) × y
B64(x) – Base-64 encoding size.
B64(x) = ((x + 2) ÷ 3) × 4
AES can be bigger than Triple-DES, but not by much.
Do not normally encrypt 4-byte integer numbers.

18. Manual Pages – Storage Space Requirements
Input Size (bytes)
Triple-DES (no hint)
AES
(no hint)
Triple-DES
(with hint)
1..7 35 43 87 99
8..15
16..23 55 67
107
119
24..31
32..39 75
131
139
40..47
100
163
171
215
227
200
299
355
500
695
707
747
759
Storage Space Requirements
With small data sizes, the overhead dominates; as the data size gets larger, the ratio of encrypted to unencrypted size tends asymptotically to 4:3.
When AES is bigger than 3-DES, it is bigger by either 8 bytes or 12 bytes (because 4/3 of 8 can be rounded down to 8 or up to 12).
Simple stored procedures can be written to compute these sizes.
Note that BLOB data does not have the 4/3 expansion – caused by Base-64 encoding the binary data from the encryption algorithm.

19. Performance Impact of Encryption
Comparing ‘apples to apples’ is hard.
An accurate comparison consists of:
IDS encrypting and decrypting data sent unencrypted by client
versus
Client encrypting and decrypting data sent encrypted to IDS.
Unfortunately, that requires benchmarking an application with cryptography built in.
Can be done, but is fiddly.
So, everybody makes an ‘apples to oranges’ comparison:
IDS encrypting and decrypting data
IDS not encrypting and decrypting data.

20. Performance Impact of Encryption
The performance impact of encryption is significant.
It depends on direction:
Encrypting is slower than decrypting.
It does not depend measurably on algorithm:
AES performs at the same speed as Triple-DES.
It does depend on data size:
The relative overhead is less when there is more data to encrypt.
Do not use encryption just because it is sexy.
Use it where there is a demonstrable business or legal need.

21. Performance Impact – Credit Card Number
Credit card number plus expiry date
20 digits + 5 punctuators
“ □01/99”
Needs 67 characters without hint; 119 with hint.
These comparisons should be repeated for your machine!
Mine is an old, small, slow Sun UltraSparc 10:
Solaris 8
Single CPU at 333 MHz
256 MB
Single user
No /dev/random or /dev/urandom
Running several IDS servers, Apache, etc.

22. Performance Impact – Credit Card Number
Without hints – batch mode processing – 5000 rows.
INSERT INTO NewTable         SELECT …, ENCRYPT_TDES(OtherColumn), …         FROM OtherTable;
Encryption performance:
424 µs per row (without encryption)
3601 µs per row (with Triple-DES encryption)
Ratio: 8.5:1
Cost: 3200 µs per call.
Even a trivial SPL procedure called in place of encryption levels the playing field a lot.
Performance Impact – 500 Bytes of Data
Without hints – batch mode processing – 5000 rows.
INSERT INTO NewTable         SELECT …, ENCRYPT_TDES(OtherColumn), …         FROM OtherTable;
Encryption performance:
2011 µs per row (without encryption)
5164 µs per row (with Triple-DES encryption)
Ratio: 2.6:1
Cost: 3153 µs per call.

23. Performance Impact – Credit Card Number
Without hints – batch mode processing – 5000 rows.
SELECT …, DECRYPT_CHAR(EncryptedData), …         FROM NewTable;
Decryption performance:
155 µs per row (without decryption)
1285 µs per row (with Triple-DES decryption)
Ratio: 8.3:1
Cost: 1100 µs per call.
Hence, decryption costs about 1/3 what encryption costs.
Major component of encryption cost:
Generating cryptographically random number.
Just as well you’ll normally do more decryption than encryption.
Performance Impact – 500 Bytes of Data
Without hints – batch mode processing – 5000 rows.
SELECT …, DECRYPT_CHAR(EncryptedData), …         FROM NewTable;
Decryption performance:
879 µs per row (without decryption)
2462 µs per row (with Triple-DES decryption)
Ratio: 2.8:1
Cost: 1583 µs per call.

24. Modes of Use Column-Level Encryption is an enabling technology
You decide how you are going to use it.
Consider reading:
Peter Wayner, ‘Translucent Databases’, Flyzone Press, 2002.
ISBN
Correct URL:
Not
As on the inside of the book and original version of this presentation.
Available via Barnes and Noble, or Amazon.
Two main modes of operation:
Web mode:
Different keys for each row of data.
MIS mode:
Same key for each row of data.
The inside cover of the book states the web site is but that site is now ( ) a sports blog site, and apparently semi-defunct (as of , the last updates appear to be June, presumably June 2004 since one item is referring to the Olympics in Athens).

25. Web Application Think of credit card numbers on a web site.
Different keys for each row of data.
Hints are important.
Key management is not a major problem.
You do not store the key (password) for the user.
If the user forgets their password, the data is re-enterable.
Or you get into more fancy schemes:
Encrypt user’s passwords with known key.
But these systems are generally less secure.
SET ENCRYPTION PASSWORD is irrelevant.

26. MIS Applications Same key for each row of data Hints are irrelevant
Key management is critical.
SET ENCRYPTION PASSWORD is critical.
You might be better off coding with a temporary table:
Contains one row of data – the password.
Join with that table when you need encrypted data.
Avoids revealing the password in SQL.

27. Key Management IDS does not do any key management.
Keys are handled outside the DBMS.
You can store keys in the DBMS if you want to.
Securing them is your problem.
Probably encrypted with a single high-security password.

28. Encryption Without Changing Applications
You can do it,
But it is not necessarily a good idea.
The application will not work as fast as without encryption,
But it will run about as fast as if you rework it with encryption.
So, many people will do it.
The application will use more data space.
But you won’t be using hints.
The easiest approach uses more space than necessary.
And more encryption and decryption operations.
It is a bad idea to use encrypted data as keys.
Does the SSN get used as a key?
Encrypted keys are very much more difficult to handle.
Can you use a hash checksum instead?

29. Encryption Without Changing Applications: Techniques
Changes to database schema:
Rename all tables containing encrypted data.
Change data types for columns that must be encrypted.
CHAR data type.
Expanded size.
Create views with the old table names:
CREATE VIEW oldname(key, col2, col3)   AS SELECT key, DECRYPT(col2)::type1, DECRYPT(col3)::type FROM newname;
The hard part is setting the encryption password!

30. Encryption Without Changing Applications: Techniques
Create INSTEAD OF triggers on views.
CREATE TRIGGER ti_on INSTEAD OF INSERT ON oldname   REFERENCING NEW AS new FOR EACH ROW   (INSERT INTO newname VALUES   (new.key, ENCRYPT_AES(new.col2),   ENCRYPT_AES(new.col3)));
CREATE TRIGGER tu_on INSTEAD OF UPDATE ON oldname   REFERENCING OLD AS old NEW AS new   FOR EACH ROW   (UPDATE newname SET (key, col2, col3) =   (new.key, ENCRYPT_AES(new.col2),   ENCRYPT_AES(new.col3))   WHERE key = old.key);
CREATE TRIGGER td_on INSTEAD OF DELETE ON oldname   REFERENCING OLD AS old FOR EACH ROW   (DELETE FROM newname WHERE key = old.key);
INSTEAD OF triggers were added to IDS 9.40.

31. Behind the Scenes The encrypted data contains:
Which encryption algorithm was used.
A random initialization vector (IV).
The encrypted data.
Optionally, the hint.
The IV ensures randomization:
If the same data is encrypted with the same key,
The encrypted data is different.
Assuming the IV is different (and it ‘always’ is).
Text data is converted to Base-64 encoding.
Binary data is not Base-64 encoded.
More compact.

32. Behind the Scenes Session password in shared memory is encrypted.
Constant password in shared memory is encrypted.
“onstat –g sql” will display not constant password.
Encryption VPs
Generating (cryptographically) good random numbers can block.
Define multiple ENCRYPT VP in ONCONFIG
VPCLASS encrypt,num=3
Add or drop encryption VPs online
onmode –p +1 encrypt
onmode –p –1 encrypt
If you don’t define encryption VPs and use encryption
One encryption VP is added automatically.

33. Gotchas Encrypting BLOB data requires the correct configuration
SBSPACE set in ONCONFIG file
(SYSSBSPACE set in ONCONFIG file, too)
If omitted, the errors returned in the initial release are unhelpful.
B addresses the poor error messages.

34. Things to Avoid Do not index encrypted columns.
You should not be searching for encrypted values.
If you do index a column, it is only useful for equality comparisons.
Do not create a functional index on the decrypted data.
In a web-style application, you won’t have the key.
In a MIS-style application, you will be storing the data unencrypted after all.
Avoid using encrypted columns as keys for tables.
Do not ask Tech Support to retrieve your passwords.
It can’t be done!

35. Auditing With IDS – The Forgotten Subsystem
Which Compliance Regulations?
Overview of Auditing in IDS
Roles: DBSSO versus AAO
Summary

36. Which Compliance Regulations?
The answer depends on:
Industry
Country
Application
In the USA
HIPAA ‘Health Insurance Portability and Accountability Act’ – 1996
Sarbanes-Oxley – 2002
Gramm-Leach-Bliley – 1999
California SB 1386 ‘Personal Information: Privacy’ – 2002
Worldwide
Basel II – 2001
Disclaimer: I am not a lawyer – I am not giving you legal advice.

37. Overview of Auditing in IDS
Many operations can be audited.
All auditable operations have a 4-letter mnemonic.
CREATE DATABASE = CRDB
SELECT ROW = RDRW – generates voluminous output!
Audit masks are used to dictate which operations are monitored.
Different masks for different people.
Global masks – default, require, exclude.
Template masks
User masks.
Audit logging can be done to operating system audit facilities.
Requires server running as root – on Unix only.
Audit logging can be done using Informix audit facilities.

38. Roles: DBSSO versus AAO
DBSSO controls what is audited.
Which users are audited.
Which operations are audited for each user.
Uses ON-Audit command.
Setting auditing masks.
AAO controls whether auditing is active or not.
And how the auditing is recorded.
AAO monitors the results of auditing.
Uses ON-ShowAudit command.
DBSA runs the server.
Should not be able to subvert the auditing set up by DBSSO and AAO.

39. Summary of Auditing Many industries and countries require audit trails
For compliance with legal regulations.
IDS has a powerful auditing sub-system
Very much under-used in the past.
It is important to understand the DBSSO and AAO roles.
They are complementary.
Use ON-Audit to control auditing.
DBSSO controls which events are audited for each user.
AAO controls whether auditing happens, and where the logs are.
Use ON-Showaudit to monitor what happened.
AAO analyzes the audit log files.
Control the audit log files.
Log retention policies and clean up.