As I discussed in an earlier blog, the IBM i enjoys an enviable reputation in the world of business servers for its security and reliability (see How Secure Is The IBM i?). However, as I also covered in that blog, the platform does have some vulnerabilities that, if left unresolved, can result in hackers or even staff (maliciously or not) gaining access to data that they should not be privy to. While it is extremely important that organisations lock down access rights and implement auditing on the IBM i systems as best they can, there is another important layer of security that needs to be considered – Encryption!
Often considered the last line of defence, encrypting the sensitive data residing on your servers is a hardy mechanism that will ensure that, should that data get into the wrong hands, it will be in a format that is unintelligible, and therefore useless, to the holder.
Some Background on Encryption
Chances are that if you are reading this blog that you will have at least a basic understanding of what encryption is and entails. For those who do not, let me first provide a brief history and overview of some important components of the topic here. (Those already knowledgeable in these areas can skip ahead to the discussion on IBM i Encryption Options).
A Brief History of Encryption
Individuals, governments, pharaohs, kings, queens, and even lovers, have had interests in keeping information secret for millennia. Encryption, or more generally cryptography, goes back thousands of years with the first known example dating to the ancient Egyptians around 1900 BC, in hieroglyphs carved on the wall of a tomb. Generally in very primitive forms, such as simple substitution ciphers, examples can be found throughout many societies around the world since that time, such as the ancient Greeks (including the Spartans, with a very interesting technique using rods), the Romans, and even in India the art of writing in cipher was documented in the Karma Sutra as a way for lovers to communicate secretly with each other – so if you thought that you and your significant other were clever using encoded messages to secretly express your love, well you were beaten to the idea by almost 2500 years!
The Arabs are credited with making very important contributions to the field since the Middle Ages. Though its use and contributions by the Europeans during that period, particularly during periods of political and religious tension, such as during the Renaissance, should not be discounted. Up until the First World War much of the techniques around encrypting and decrypting were manual hand-written processes, but by the end of WWI machines had been introduced that enabled the creation of far more sophisticated ciphers, leading to the famous Enigma machine that was used by Nazi Germany during the Second World War.
The closing years of that saw the introduction of computers for cryptographic tasks, with Britain’s Colossus generally recognised as the “world’s first fixed program, digital, electronic, computer”. And apart from an extremely complex hand-cipher called VIC, developed by the Russians in the 1950s, the world of cryptography has been the realm of computers ever since.
Components of Encryption
Regardless of its time in history, the objective of cryptography has always been the same. To convert plain text into an unintelligible jumble of letters, numbers, characters, and/or symbols called cipher text, which only the sender and the rightful recipient will be able to decrypt. The only difference between our modern world and ancient times is the complexity of the “algorithms” used to effectively jumble up the plain text, with the evolution of our modern computers able to take the complexity to increasingly higher levels.
All encryption, in our modern computer based understanding of it, consists of three essential components:
- The data to be encrypted (plaintext)
- Pretty clear what this should be
- The encryption algorithm
- The program (in modern computer terms) used to jumble the data up
- The key
- A random string of bits that is essentially fed into an algorithm along with the plaintext to generate the ciphertext.
Three Important Considerations for Encryption
Regardless of the platform you are using there are three key areas to consider when it comes to beginning to think about encrypting your data.
Classification
You generally don’t need to stampede in and encrypt all the data on your system! One should be a little more delicate and sophisticated than that. First of all, it does not make practical sense – doing so will take up extra space on your disks, as well as take up a lot of processing power if every single database I/O has to undergo encryption and decryption. Furthermore, doing so can actually risks generating patterns that can aid hackers in deciphering the ciphertext (using a cryptoanalytic technique known as frequency analysis). Hence, one of the first jobs in an encryption project will normally be to determine how important your different sets of data are to the organisation and who is actually allowed to see such data – a process known as classification. Data classifications is a project in itself.
Strong Encryption
This is actually an industry term used to refer to cryptographic algorithms and keys that are highly resistant to being broken. It is often achieved by using long keys – the longer the key, the harder it is to break the code. It is a rather broad definition, but some generally accepted strong encryption keys and algorithms include AES 128 (and higher), and TDES/TDEA.
Key Management
Encryption mechanisms are only as good as the key management. Of the algorithm and the key, the key is the more important. In many cases the algorithms are public knowledge, but the secrecy of the keys is extremely important and their access needs to be managed diligently. If your keys get into the hands of the wrong people, they will be able to decrypt your ciphertext. If you loose your keys, or access to them, – you will effectively lose access to your data. Think of key management like managing the keys to your car – if you lose your key then you loose access to your car. If you park at a hotel carpark and the valet locks your keys in a central vault – if they loose the key to the vault, then you (and more so the hotel) have a big problem! Key management is critical – and complex!
IBM i Encryption Options (for data-at-rest)
From an IBM i perspective, we generally consider encryption from 3 standpoints: Data in Motion, Data at rest (in database files), and Backups. What I would like to focus on in this blog are the encryption options for data at rest on the IBM i – that data sitting in our DB2 files right now! This is your main silo of data which your users are accessing on a daily basis, whether through applications (RPG, Cobol, JDBC, etc) or via backend techniques such as DFU, SQL, or Query. While access to such data can be controlled by the IBM i’s powerful access controls, it is still very prudent (and very often a commercial or legal requirement) to encrypt sensitive components of this data – just in case rogue employees, staff with high system security level access, or hackers, manage to gain access to areas they should not.
There are a few techniques that we have available to us for encrypting data at rest on the IBM i. Lets look at these here.
Disk Encryption
With the arrival of V6R1, IBM introduced the concept of encrypted disk, which provided the ability to encrypt auxiliary storage pools (ASP) and independent ASPs (IASPs). Disk encryption enables any data that is written to the disk to be automatically encrypted. While quite a simple solution to implement, its benefits are limited. This feature simply encrypts the data sitting on the disk – however any I/O done on the local disk is still read in its natural (unencrypted) form – so anyone accessing the database through an RPG read, DFU, SQL, FTP, Client Access, and so forth will be able to see the data in its unencrypted form. All that the IBM i disk encryption really protects you against is someone walking into your server room, pulling out the disk, and walking away with it – an occurrence that is probably not very realistic. Furthermore, thanks to single level store on the IBM i you can’t just take a disk and install it in another computer and expect to be able to read it (because the data is scattered across all available disks, so stealing one disk would be kind of meaningless).
Encrypting with IBM i Database Functions (APIs)
A technique to encrypt data at a more refined level, that’s is at a field/column level versus the entire disk (as for the encrypted disk approach), has been available since IBM i 6.1 and on earlier OS versions of i5/OS with the introduction of some IBM i APIs. With this approach, IBM i user programs can be called to encrypt your fields as you write them to the database or decrypt them as you read them.
There are a few drawbacks with this approach however. First up, encrypted data is oftentimes longer than the original plaintext field and is always alphanumeric, meaning that the encrypted data cannot be stored in the original field on the file – so the database field definitions need to be modified, with a resultant change to the file. Changes to the files of course mean that all programs accessing that file need to be discovered and recompiled to avoid any runtime file level checking errors (whether they are accessing the fields concerned or not). Next, all programs accessing the data need to need to be modified to issues calls to the IBM i APIs or user programs that will actually perform the encryption and decryption. The programs also need to be modified to handle new fields holding the encrypted data, and to manage whether the plaintext or ciphertext is presented to the end user.
In theory, DB2 triggers could be used to encrypt the data when writing to the database, mitigating some of this required work. However, due to an IBM i restriction preventing a user program invoked by a read trigger from modifying incoming data, modifications at an application level are still going to be required. So using triggers will only minimally reduce the amount of changes required to your existing code.
Another draw back to this approach is that the data can only be decrypted through these API calls. So users accessing the data legitimately through features like SQL, Query, ODBC etc will not be able to see the plaintext data.
Needless to say, this approach has not been adopted in significant numbers. And it is probably fair to say that the API approach is perhaps best useful for software vendors – those companies who own the source code and can make the modifications once, then deploy the to many. Otherwise, it might be considered a bit of an inefficient exercise.
Field Procedures
In OS V7.1 IBM introduced Field Procedures to the IBM i. This has been a game changer as it eliminates the need to make changes to the database files and applications when incorporating encryption. Essentially, all the encrypted data is managed behind the scenes, so we do not have to alter the file structure – the operating system handles it all for us. Much like a trigger, the system handles the encryption and decryption of the data during the I/O.
This saves the developers a lot of work in terms of modifying fields, files, and applications needing to work with the encrypted data. Lets look at an example. Say a salary field stores data as type Packed, length 9,0 – this field cannot handle encrypted data (it will probably be too short, and needs to be alphanumeric anyway). So, without field procedures we’d have to change the field format and length, recompile the file and change any programs that accessed that field (not just to read a different field type, but to also encrypt/decrypt it from/to the numeric value displayed on the screen). With FieldProcs, the operating system maintains the space to store the encrypted value without us having to do anything. This approach also avoids the need to recompile any files to avoid file level checking errors.
And one more important advantage, this approach means that users cannot access the plaintext data simply by writing another RPG program or using an alternative data access facility like DFU, SQL, or Query.
Using 3rd Party Tools to Make Encryption Easier
Field procedures really are a game changer and do warrant serious attention for those concerned about the security of their data. Especially by organisations who do not have access to the source code of their applications, plus those who simply want to avoid the hassle of making the arduous field, file, and application changes otherwise required. It should be said though that FieldProcs are not a complete panacea for your encryption project, and some application coding is required to actually define the field procedures. In addition to this, by embarking on this encryption journey organisations have to handle their key management, which can be quite a heady exercise. For this reason, many organiations are turning to 3rdparty solutions to aid them in these areas.
One of the 3rdparty solutions that we, here at Joule Tech, represent is extremely clever in this area. With this tool, field procedures are assigned to the required columns in their tables automatically (no coding required on your behalf). It also incorporates robust key management. With little more than filling in a few details about the column concerned and the press of a button, an authorised administrator can control who has access to plaintext data, who can see partially masked data, and who cannot see any unencrypted data whatsoever. All the encryption and decryption is handled behind the scenes and permission to the encrypted data is handled by IBM I’s authorisation lists. And the rules about who can see what are applied to all data access mechanisms – whether RPG/Cobol programs or utilities like SQL, Query, and DFU.
Want More Information On IBM i Encryption?
For more information on IBM i encryption options, contact us here at Joule Tech. We carry a number of solutions from a number of vendors that can make your encryption projects much easier, and we’d be delighted to explore the options with you!