Townsend Security Data Privacy Blog

“You have to encrypt your data!” More and more IT professionals, security architects, and executive leaders in the C-Suite are hearing these words. It’s no longer a question of IF there will be a data breach, but rather WHEN. And of course not just anything will do, you need NIST and FIPS 140-2 compliant solutions to help you make sure the investment you make doesn’t simply crumble when push comes to shove.

What does that all really mean? It means it’s important for you and your team to vet a solution deeply and ensure the vendor that created it dotted their i’s, crossed their t’s and hopefully didn’t cut any corners when they put their product to market. Makes sense, but again, what does that really mean????

The vendor should be established in the industry and should have gone through the proper reviews of their encryption solution. Those reviews help you determine whether they made the right choices when they created the security product you are planning on betting your company’s and your future on. A vendor that creates an encryption solution and has it NIST validated took the extra time to learn and understand the reasons NIST asks for those standards to be followed. Then they took the time to implement their solution following those standards. And then lastly the vendor took the time to get the solution reviewed and validated by a reputable and independent third party. In a study of the validation program, NIST found nearly 50% of software vendors had errors in their encryption solutions. It isn't easy to get encryption right. A certificate of validation from NIST is your assurance that AES encryption does what it is supposed to do - every time.

When comparing encryption solutions, what are things you want to look for to make sure you are getting a solid product? You want the key generator to be using a Random Number Generator sequence that is as close to true random as possible. You want the solution to use the same technology when generating a strong Initialization Vector (IV) as well, and you want this solution to run the encryption algorythm true to its standard. (Why is that important? Check out this blog) You also can’t forget about encryption key management, an often overlooked but equally crucial aspect of strong encryption. Only then can you trust that when the pieces of the puzzle are put together and your data is encrypted, it was done so in a manner that can’t be undone WHEN you have that upcoming data breach.

As we all know time, in every essence of today’s world, equals money. The time the vendor invested in this process costs the vendor money. The time that was invested in reviewing the solution most likely cost the vendor money as well. The good news is that because of this you, your company and your IT team don’t need to spend that same time creating an encryption solution in house. I think so far we are most likely in complete agreement. So where’s the problem?

Several recent industry reports show that although more and more companies are asking their IT teams to implement this right kind of robust, validated encryption to secure their or their customer’s data, they are being asked to do so with less and less money in their budgets. Certainly the notion of ‘doing more with less’ is nothing new and efficiency should be a goal, the truth remains even in the data security industry what you pay for it what you get. Good encryption is now freely available, but good key management requires an investment. If you don’t commit the necessary resources to your data security projects you will not have a data security result that will protect your data (and you) WHEN that data breach occurs.

With V7R1 IBM introduced FIELDPROC (field procedure) exit points which Alliance AES400 for IBM i uses to encrypt database files at a field level. Since the cryptographic process is called by the database directly upon access, rather than by the application, this means that the process will work regardless of what type of application uses it. No application changes are needed, which is something our customers really like to hear.

These are five frequently asked questions we get around FIELDPROC encryption.

1. What type of fields are supported with FIELDPROC?

Surprisingly, virtually every field type is supported, whether it is character (even binary character), numeric (zoned, packed or binary) date, time, timestamp, Double Byte Character Set (DBCS), and hex. Some fields have certain restrictions, for example in order to implement fieldproc encryption on date, time, and timestamp fields you must specify a default value that is not ‘current date and time’.  You can define this in DDS or structured query language (SQL), and there is an option in the DB2/400 FIELDPROC encryption menu that will do this for you.

FIELDPROC will also handle blank fields by not encrypting them at all. This helps us achieve better results from certain SQL operations. FIELDPROC encryption however does not support fields with NULL values and they should be avoided or changed if necessary.

2. Will I need to make any changes to my applications?

As I mentioned above, it is not necessary to make application changes, but here is more detail as to why: In V7R1, AES/400 can create FIELDPROC exit points that tie to individual fields in a DB/2 file. When a file is opened for any operation, read, update, insert, or delete, the exit point calls one of our FIELDPROC applications, which calls our encryption or decryption APIs. It does this regardless of which application is accessing the file, thus creating application independent encryption.

A few things to consider are: when you backup your file you will need to also backup the FIELDPROC applications, and make sure you restore them at the same time as well. It is also important to remember that if the file is accessed through FTP it will be transferred in the clear.

3. Can I encrypt index fields?

In short, yes. However, encrypting index fields will affect the performance of your SQL operations, and the more indexes you encrypt, the more your performance will be affected. This happens primarily for the following reason: For faster performance DB/2 looks up records based on their encrypted values. This means that when you tell DB/2 you are looking for the record with social security number 111223333, and that field is encrypted, it will encrypt the search string and then retrieve the matching record for you. This is done as a performance enhancement especially when working with logical files on the IBM i. However for some SQL operations it decrypts all the records in order to read the index fields, so rather than encrypting single values to look up, it needs to decrypt a multitude of records.

4. What kind of performance can I expect?

In our test environment, which consists of a single processor IBM i platform, model 515, approximately 3500 CPW, V7R1 of the operating system with TR5 installed, we can process about 16,000 records per second. Systems with higher processing power should see better performance. This means that if we have a file with one million records and one field encrypted we can read the entire file in about 60 seconds. If they are 2 fields encrypted it will take us about 120 seconds because we are handling two million decryption calls.

5. Does using external key management affect performance?

In short, no. The time it takes AES/400 to retrieve a symmetric encryption key from our Alliance Key Manager server is approximately 0.0116 seconds. And this is through a secure TLS connection. There are network infrastructures in which this time may be slightly affected, firewalls, routers, switches, distance, however it should never create a noticeable difference in performance.

To learn more about automatic encryption on IBM i V7R1 using FIELDPROC, download the podcast "FIELDPROC Encryption on the IBM i" to hear IBM i security experts Patrick Botz and Patrick Townsend discuss encryption, key management, and meeting compliance regulations on the IBM i.

Education is what remains after one has forgotten what one has learned in school.

Albert Einstein

One important aspect of our work is supporting our customers and answering their questions. There is a lot to learn, and there are a lot of sources of information, and it can be difficult at times to decide what information to take in and what to let pass by.

Beyond answering their questions about broader topics such as security and compliance, we also end up discussing some very technical issues that they have questions about as well. It’s not usually until after someone begins working with our products that we step in to answer questions about the technical aspects, the nitty gritty, of how a product addresses their security and compliance needs. In this article I will cover in greater technical detail five frequently asked questions about working with PGP encryption, as well as some tips and tricks on how to get the most out of it.

1. I have encrypted a file for my trading partner, and I want to verify it, but when I try to decrypt it, why do I get an error?

If you are encrypting a file for a trading partner you are most likely using their public key. Because a public key can be given out to anybody, it becomes important to prevent just anyone from decrypting it. Thus the file can only be decrypted with your trading partner’s private key, which only they should have. Based on the principles of asymmetric encryption, it is impossible to encrypt and decrypt with the same key.

There is however a way to encrypt the file for both your trading partner and for yourself to decrypt. You can encrypt the file with multiple public keys, in this case your trading partner’s and yours. Our PGPENCRYPT command does this through the use of the ‘Additional user IDs’ parameter, in which you would define a public key for encryption to which you had a matching private key for. That way you would be able to decrypt it using your private key to verify the contents of the file.

2. How do I provide my trading partner with my key?

When you are exporting keys from the keyring there is one important question to ask, will the key be used for encryption or decryption? When you are exchanging files with a trading partner you have to remember that you will be encrypting with their public key and they will be encrypting with your public key. But decryption, again, can only happen with a private key.
So if you need to export a key for encryption it needs to be the public key, if it’s for decryption you should export the key pair.

Our PGPKEYEXP command can accomplish both for you. You would define the key to export with the ‘Export type’ parameter, where *PUBLIC exports the public key and *KEYPAIR exports both the public and private keys in one file. You can verify what was exported by viewing the file. Even though they keys themselves are unreadable the title is. An exported key pair would list the private key first.

It is important to note that under no circumstances should you provide your private key or the entire key pair to your trading partners or vendors. The option to export the key pair is built into the application to allow you to move individual key pairs between your company’s own servers.

3. My trading partner’s key has expired, can I update its expiration date using PGP commands?

There is a way to update the expiration date on a public key, but not one you received from a trading partner. The public key can be updated only if you have the matching private key and the private key’s password. Because your trading partner should not ever share neither their private key nor their password, you cannot update the expiration date on that public key.
You will need to attain the new public key from your trading partner. The good thing is that most trading partners have a system in place that should inform you ahead of time of the impending expiration of their public key and either provide the new key with that notice or provide instructions on how you can obtain it.

4. I have received a key from a trading partner and I have added it to the keyring but I can’t encrypt with it (or I am being asked if I want to trust the key every time I try to encrypt with it), how do I trust it?

When you first import a public key PGP will not ‘trust’ it, since information encrypted with it can’t normally be recovered (see Question 1 for options). When you try to encrypt with it, PGP will error out, although when you are encrypting interactively, it will prompt you. To trust the key you need to do the following 2 steps:

1. Sign the new key with your private key to validate the key using the PGPKEYSIGN command. Because you are using your private key to do this you will need its password as well.
2. Then you need to set its trust level using the PGPKEYCHG command. Once you have done this PGP will accept the key for encryption.

5. My trading partner wants me to sign the file. What does signing a file do?

Signing a file is a way that you can help your trading partner make sure the file they received really came from you. You can encrypt and sign a file or just sign it, on the latter the contents of the file remain visible but an encrypted string is added to the bottom containing your signature. A signature can only be created with a private key, so your trading partner can be pretty certain that the file could only have come from you. The signature is verified by PGP by using your public key to decrypt and read that encrypted string. The string is never stored in the clear but it is read and PGP returns a message that it has verified it. This does mean that anyone with your public key can verify your signature, but then again that is what you want. If a file is both encrypted and signed, the signature would be read by your public key and the contents decrypted by your trading partner’s private key. You can define the signing key in our PGPENCRYPT command with the ‘Signing user ID’ parameter and by providing the command with its password. You can also sign a clear text file or an already encrypted file with the PGPSIGN command.

For more information on encrypting data in transit with PGP, download the podcast, “PGP Encryption on the IBM i,” featuring data security expert Patrick Townsend.

Key Lifecycle & Rotation Explained

Encryption key management refers to the ability of a system to administer an encryption key through the length of its crypto-cycle. From the creation of a key, through it’s use, and eventually to its deletion, an encryption key management system needs to be able to securely and efficiently handle the encryption keys. I will talk a little about each major part of the encryption key lifecycle and how our Alliance Key Manager manages and administers the key throughout the lifecycle.

Key Creation: First, the encryption key is created and stored on the key manager server. The key can be created by a sole administrator or through dual control by two administrators. Townsend Security’s Alliance Key Manager creates the AES key through the use of a cryptographically secure random bit generator and stores the key, along with all it’s attributes, into the key database (which is also encrypted). The attributes stored with the key include its name, activation date, size, instance, the ability for the key to be deleted, as well as its rollover, mirroring, and key access attributes. The key can be activated upon its creation or set to be activated automatically or manually at a later time. Alliance Key Manager can also create keys of three different sizes: 128, 192, or 256-bit. The encryption key manager also tracks current and past instances, or versions, of the encryption key. You can also choose whether or not the key can be deleted, mirrored to a failover unit, and by which users or groups it can be accessed. Alliance Key Manager also allows the change of many of the key’s attributes at any time.

Key Use and Roll: Alliance Key Manager will allow an activated key to be retrieved by authorized systems and users for encryption or decryption processes. It also manages current and past instances of the key. For example, if a key is rolled every year and the version is updated, then the key manager will retain previous versions of the key but will dispense only the current instance for encryption processes. Previous versions can still be retrieved in order to decrypt data encrypted with such versions of the key. Alliance Key Manager also uses transport layer security (TLS) connections to securely deliver the encryption key to the system and user requesting it, which prevents the key from being compromised. The encryption key manager will also roll the key either through a previously established schedule or manually by an administrator.

Key Revocation: An administrator can use Alliance Key Manager to revoke or deactivate a key so that it is no longer used for encryption requests. In certain cases the key can continue to be used to decrypt data previously encrypted with it, like old backups, but even that can be restricted. A revoked key can, if needed, be reactivated by an administrator, although this would be more an exception to the rule than common practice.

Key Deletion: If a key is no longer in use or if it has somehow been compromised, an administrator can choose to delete the key entirely from the key database of the encryption key manager. Alliance Key Manager will remove it and all its instances, or just certain instances, completely and make the recovery of that key impossible (other than through a backup). This is also an option if sensitive data is compromised in its encrypted state. If the key is deleted, the compromised data will be completely secure since it would be impossible to recreate the encryption key for that data.

To learn more about encryption key management, download our ebook, "Encryption Key Management Simplified.”

In the world of encryption there are many different names for encryption, but probably the two most common would have to be AES and PGP. But not everyone knows what these acronyms stand for. In today’s world of TLAs (Three Letter Acronyms) it’s easy to feel left behind in a data security conversation when they start replacing every other word. OMG!

First we’ll break both of them down a bit and then we’ll compare them to each other.

AES, or Advanced Encryption Standard, as we know it today is the dreamchild of two cryptographers’ proposal of a symmetric key encryption algorithm based on the Rijndael cipher. This algorithm was developed when NIST (National Institute of Standards and Technology) sent the call out to the cryptographic community to develop a new standard. NIST spent five years evaluating fifteen competing designs for the AES project and in 2001 announced the cipher developed by the two Belgians Joan Daemen and Vincent Rijmen as the adopted standard, known as FIPS-197, for electronic data encryption.

AES is a symmetric key encryption algorithm, which essentially means that the same key is used for the encryption and decryption of the data. A computer program takes clear text and processes it through an encryption key and returns ciphertext. If the data needs to be decrypted, the program processes it again with the same key and is able to reproduce the clear text. This method required less computational resources for the program to complete its cipher process, which means lower performance impact. AES encryption is a good method to protect sensitive data stored in large databases.

There is, however, a time when AES will not be your go-to encryption process. When you need to share sensitive information with trading partners or transfer information across networks, using AES has one downside when it comes to security: You would have to share your encryption key with your trading partners. Sure, they’d be able to decrypt the information you sent them, but they would also be able to decrypt anything else encrypted with that key, and if the key itself became compromised anyone in possession of it could decrypt your data.

Enter PGP. PGP stands for Pretty Good Privacy, and before you get too distracted by the name, I can tell you it is actually much better than just pretty good. PGP uses symmetric and  asymmetric keys to encrypt data being transferred across networks. It was developed by the American computer scientist Phil Zimmerman, who made it available for non-commercial use for no charge in 1991. To encrypt data, PGP generates a symmetric key to encrypt data which is protected by the asymmetric key. 

Asymmetric encryption uses two different keys for the encryption and decryption processes of sensitive information. Both keys are derived from one another and created at the same time. They are divided into and referred to as a public and a private key, which makes up the key pair. Data is only encrypted with a public key and thus can only be decrypted with the matching private key. The encryption PGP offers is just as strong as that of AES, but it adds the additional security that prevents anyone with just the public key from being able to decrypt data that was previously encrypted with it. Another benefit of asymmetric encryption is that it allows for authentication. After you have exchanged public keys with your trading partners, the private keys can be used to digitally sign the encrypted content, allowing the decryptor to verify the authenticity of the sender.

PGP does require more computational resources, which is why it is usually not recommended for encrypting data in large databases where information needs to be accessed frequently, and each record that you access needs to be ran through a cryptographic process.

When you are considering which encryption to use for your sensitive information choose whichever will suit your needs best. AES is fast and works best in closed systems and large databases; PGP should be used when sharing information across an open network, but it can be slower and works better for individual files.

Data breaches happen all the time and we do what we can to prevent that, still cyber crimes are on the rise. Verizon Business Data Breach Investigations Report for 2012 counts as many as 174 million records compromised that year. Verizon compiles the 2012 report with data collected in 2011. You can find the full report here, but I'm going to summarize just a few of the highlights.

• 98% stemmed from external agents, meaning one way or another, cyber criminals gained access to systems storing sensitive data and compromised them.
• 81% used some form of hacking, in many cases in conjunction with malware.
• The statistic that hits home hardest, 96% of victims subject to PCI DSS had not achieved compliance at the time of the breach.

That is really hard to palate because here at Townsend Security we work so hard to spread the word about the importance of merchants being PCI DSS compliant. It's not just about appeasing the auditors or passing an Annual Self-Assessment Questionnaire, it's about protecting everyone's sensitive personal information. These are our credit card numbers that are being stolen, our dates of birth, social security numbers, and a myriad of other information criminals can use to their gain, and our fault. The report lists that 48% of data compromised was payment card data, like credit card numbers.

According to the report from the 855 incidents recorded, 54% of companies affected by that year's data breaches were in Accommodation and Food Services, 20% were Retail Trade, and 10% Finance and Insurance fields. And it's not just companies in the US that are affected, in 2011 data breaches were reported in as many as 36 countries worldwide.

And as if all this information wasn't already scary enough, apparently as many as 55% of data breaches remained undiscovered for months or longer. And the majority of data breaches are discovered by external parties; meaning that the companies experiencing the data breach end up learning about it from someone else, causing bad publicity and damage to the company's reputation.

This report did not talk about the cost experienced by companies or consumers as an effect of these data breaches, however Symantec took the time to compile those numbers for 2011 and in September of 2011 extrapolated the costs over the 12 months that year to $144 Billion in cost. Obviously this has become a very lucrative business for cyber criminals and it's not surprising why they expend so much effort on their endeavors.

The Verizon Business report has one more piece of information worth sharing - their recommendations. Implementing sound security policies around system credentials, like using strong passphrases and changing them on a regular basis, as well as ensuring essential controls on data are met, like encrypting sensitive data and using recommended encryption key management practices like separation of duties and encryption key storage. Especially for larger organizations, monitoring and mining event logs is recommended to aid in discovering active data breaches quickly and internally.

A new report should be published soon and although there has been a lot of attention on these subjects in 2012, the trends in the past have been an increase in data breaches, rather than a decrease. However, knowledge is power, and we have a lot of knowledge for you. Empower yourself and your company by reading some of our white papers on encryption, logging, and data security.

We've seen experts hack into the Department of Defense (DOD) mainframe in 60 seconds, intelligence agencies decrypt hard drives in just mere hours, and teenagers preventing dark conspiracies from their satellite enabled phone. Hollywood gives us a lot of exciting stories that at times make it seem like there is almost nothing we can do to protect our sensitive data from being stolen. But it is important to remember that movie makers need to embellish details and add certain amount of artistic license to tell a more intriguing story. It is good from time to time to separate fact from fiction.

I'm not saying everything we see in movies about information protection is wrong, in fact when considered at it's most basic it's all actually rather accurate. People do walk out of businesses with hard drives jam-packed with sensitive information. There are super computers that can crack non-standard encryption, and hackers are getting more resourceful and more daring every day.

We've seen a lot of stories this year about passwords being hacked, both where the users simply were not using strong passwords and where companies failed to correctly protect the data either as it traveled or at its rest.

Let's review some data breaches from the movies and see if they could happen in reality:

In the movie Swordfish, the protagonist is tasked to infiltrate a network encrypted with a 512-bit cipher. I won't even go into the fact that they are talking about a one-time pad. A 128-bit cipher is already a very safe encryption standard, but it is theorized that it could be cracked by a brute force attack, or exhaustive key search, by a special built computer in a matter of days. However, a 256-bit key would require 2¹²⁸ times more computational power and a 512-bit key 2³⁸⁴ times more computational power. Assuming that the encryption key was generated properly using truly random and unique characters, it makes cracking them virtually impossible. Our protagonist would not have been able to do this in just a couple of days, no matter his skills or the technology at his disposal.

Another example is one where a secret agent like James Bond recovers a hard drive from a villain and his Quartermaster decrypts it and recovers the secret information. This scenario is actually not too far from what happens in reality. There are even commercially available software packages that can help you decrypt a hard drive, but the only ways they can do that is by first searching for and recovering the encryption key stored on that hard drive. If the key is stored with the encrypted data, then anyone can steal that information in a minimal amount of time. Once they find the key they can just use any decryption program and extract the plain text. But if the key is stored apart from the encrypted disk, or data, we are back to dealing with the constraints of trying to break a strong cipher like my first example.

So when you are looking at protecting your data, don't fret after watching Hackers, but choose the right tools for the job. Use an encryption key manager that uses a solid random approach and store your encryption keys separate from anything you are encrypting. Alliance Key Manager, our encryption key manager, does both.