Wednesday, June 27, 2007

GPG to the rescue (lipstick on the pig)

So I have been a little side tracked from my Ruby ISO8583 work for the past couple of weeks. But never fear I have been getting familiar with a really amazing API for the GPG project known as GPGME (GPG Made Easy). So why would a person be interested in this? Glad you asked.

Problem: Company A has a very, very old POS application that was written entirely in-house. The programming language/database that the app is written in is Progress (something like a 4GL). I'm not surprised if you have never heard of it. One problem is that the version of the database/language that the app is written in is now over 10 years old. Well company A needs to capture some PCI data for a very short period of time during the transaction and this data needs to be sent off to various backend systems for settlement, etc. (so this is not entirely unrelated to the ISO8583 work). The problem is that the language/database has no way to handle this, period.

The Solution: What Progress does offer is a HLC (Host Language Call) mechanism which allows custom C routines to be written and called from the application; complete with a way to pass data back and forth through shared variables and temporary tables. This is actually very cool! So what we are going to do is let the native Progress applications call a GPG encryption routine (we will be using asymmetric encryption in this case) and bingo, we have encryption in a older-than-dirt application.

The first step was to investigate the GPG libraries and see how we might integrate them and develop a very simple API for our app developers to use. And this is where GPGME came into the picture. Someone has already done a lot of the work for us and created an "Easy" API to the GPG engine. The post compile tests which are bundled with the GPGME source came in very handy when it was time to actually write our routines (it's great to see actual tests).

A few days of hacking together some C code and I had injected an encryption routine into our antique language/database.

A basic architecture and sample use case for this project would be as follows:
  1. Create a public/private key pair somewhere super-safe. Guard the private key with a pass-phrase and with your life.
  2. Distribute the public key to the legacy application systems. These applications will then use the public key to encrypt sensitive data which can be stored locally (only if you really need to) or shipped off to another super-safe system. The original 'clear-text' data must me removed after it is encrypted or the whole process is worthless!
  3. The 'super-safe' system which has the private key will then be able to access the sensitive data when it needs to.
  4. Because the legacy application systems only have the public key they cannot even decrypt the data that they themselves encrypted.
For all those out there who spend way too much time holding a well past their prime system together, I have this to say... I put lipstick on the pig. The lipstick may be pretty but it is still a pig.

Next entry teaser: " do you get several legacy applications to send data to a modern .Net based system when they only know how to talk to each other..."

No comments: