Encryption: where and when and how
July 17, 2007
Regulations drive today's encryption needs, much of the time, for HP 3000 customers. Security and SOX, COBIT or PCI compliance go hand in hand. And even though HP has offered little in the way of MPE/iX encryption tools in recent years, the marketplace and clever administrators and developers know how to keep the mission-critical bits under wraps.
While OpenSSL routines offer encryption potential in the Apache WebWise free offering, these routines are now nearly seven years old. Even the latest OpenSSL versions date to 2005. Implementation is not for the faint of heart.
One commercial solution and some techniques emerged recently on the HP 3000 newsgroup and mailing list. A 3000 manager asked how to encrypt one field in a TurboIMAGE database. An easy-to-implement reply came from Orbit Software. Developer Mark Klein plugged Backup+/iX "that will do encryption only at backup time."
Sure enough, the 256-bit encryption key in the Orbit product stands as the strongest protection in the 3000 community. More bits in the key means a tougher challenge to crack it through a brute force method. Documents classified as Top Secret by the US Government require encryption keys of 192 or 256 bits. Orbit's software, available for MPE/iX, was driven by the needs of customers in the banking industry.
Klein, working as an independent developer for the Orbit labs, pointed out that HP 3000 databases are privileged, a step that offers reasonable security. But not crack-proof, unless good procedures to protect that privilege are in place. Without high-powered solutions, encrypting with open source software can have stiff penalties, he said.
Note that software encryption has large performance consequences, so you really need to be clear as to whether or not the data must be encrypted in the database or encrypted for other means. If your need for encryption is to secure your data transmissions, consider using a network link that itself is encrypted. These can be hardware-accelerated, which will mean the performance will be better.
Keeping up with changes and options became a lively discussion on the newsgroup.
SOX in particular forces 3000 managers to look at encryption options. Off site storage is an issue in this compliance with the Sarbanes-Oxley law, a ruling that applies to many hundreds of HP 3000 customers (publicly traded firms, large ones using security or bond-based funding, those which desire to look secure to customers.)
But things have moved on since the DES offerings of the late 1990s which HP engineered for the 3000. "DES has been replaced by AES," Klein said when a customer asked about the OpenSSL software HP offered. A common question might follow the one this customer posed while investigating how to get started with encryption:
We came across the option of installing PERL on the HP 3000, as it has some encryption functions/routines readily available; for example, 3-DES is present as a module. The question we have is whether we could write a program / executable in PERL and call it from a COBOL program on the HP 3000.
Another option we were thinking is of going the OpenSSL route, but there too, we have little knowledge on how to use the functions present in those libraries.
Klein replied,
OpenSSL has been ported to MPE by others and it may also provide you with a solution, if encryption of the data is the only way you can satisfy your need. Your real issue may be in calling these from COBOL.
In an even more interesting development, some 3000 developers and managers wonder if encryption on the 3000 host level is even necessary. We'll recap the strategy of guarded classrooms and blackboard gibberish tomorrow.