Operating System - OpenVMS

Encryption and FIPS 140-2 compliance

Ross Smith_1
New Member

Encryption and FIPS 140-2 compliance

We've been told that we're required to have encryption in place that is certified as FIPS 140-2 compliant for protecting our clinical research data. Does VMS's encryption (for backup and encryption at the command line) meet that requirement?

Honored Contributor

Re: Encryption and FIPS 140-2 compliance

IIRC, AES is suitable for FIPS 140, though you'll want to ask for a statement from HP if this compliance is not already listed in the SPD.

There's a business manager inside OpenVMS that has traditionally handled Common Criteria and other issues of security standards and standards compliance.

Here's the AES (256-bit) reference for OpenVMS V8.3 encryption:


and AFAIK 256-bit AES is in the right range for FIPS 140 compliance. As for statements of compliance and verification and evaluation that aren't already included in the SPD or such, those best arrive from folks within HP and probably not from ITRC. (And I don't see FIPS 140 in the SPD.)

Alternatively, you might want to ask your own folks if products providing AES 256-bit are "good enough".

Stephen Hoffman
HoffmanLabs LLC
Jon Pinkley
Honored Contributor

Re: Encryption and FIPS 140-2 compliance

I would recommend looking at a tape drive that has encryption build in. One example is the HP StorageWorks LTO-4 Ultrium 1840 Tape Drive. There is never a better time to ask for new hardware than when you are being requested to provide a solution to a legally mandated requirement.

One drawback is that this is a new very high performance drive, and you may have a hard time sending data to it fast enough to keep it from shoeshining. And without software to turn the encryption feature on, it will just be a latent capability.

There are many advantages to having the tape drive do the encryption. Besides offloading the necessary processing, it also does the compression prior to encryption, so the amount of media used for backups will not increase drastically. Remember that encrypted data appears random, and therefore does not effectively compress.

Have a look at


According to the compatibility chart, the drive is supported by both 8.2 and 8.3, but not by 7.3-2. That does not mean that you will be able to take advantage of the encryption capabilities, as the feature must be turned on, keys loaded, etc. That will require that the software being used to write to tape have the knowledge needed to communicate with an IEEE 1619.1 encrypting tape drive. I know nothing about what is planned for VMS BACKUP or Data Protector.

I was a bit surprised that the drive doesn't have any USB port on the front panel that would allow a "key" to be inserted into the drive. Whether such a device exists, I don't know. I do know that we have a MICR check printer that has a hardware key (I am not sure if it is USB or some proprietary hardware), but it is part of the "something you know and something you have" two part security.

There seems to be quite a bit of discussion about whether or not the encryption built into the LTO4 drive is "FIPS 170-2" compliant or not. Google for ( "IEEE 1619.1" "FIPS 140-2" ) http://www.google.com/search?hl=en&lr=&as_qdr=all&q=%22IEEE+1619.1%22+%22FIPS+140-2%22&btnG=Search

HP's description in their marketing brochure has the vague verbiage "has the potential to be part of wider data encryption solutions up to FIPS 140-2 level 2." But so does a notepad to keep documentation on.

Excerpt from http://www.hpstoragemedia.com/files/english/sales_tools/storage_media_sales_tools/LTO4Brochure-EEE.pdf

"HP's LTO4 Ultrium cartridges have the potential to be part of wider data encryption solutions up to FIPS 140-2 level 2. The media on its own incorporates AES-256 bit key encryption (the highest level of AES) capabilities to provide greater security. HP's implementation meets the current draft of IEEE 1619.1 tape encryption standard giving you peace of mind that if a tape goes missing, the data it contains cannot fall into the wrong hands."
it depends
Jon Pinkley
Honored Contributor

Re: Encryption and FIPS 140-2 compliance

I haven't looked into this whole topic yet at any depth, but to support an encrypting tape drive in a general way, it should be possible to somehow specify encryption at mount time, in a way similar to /media=compaction allows compression to be turned on.

Perhaps something like mount/media=(compaction,IEEE1619_1=keyoption...)

Then you might be able to use something like Save Set Manager to migrate savesets from old tapes to new, and have them encrypted on the way.

Sorry for the diversion...

it depends
Richard W Hunt
Valued Contributor

Re: Encryption and FIPS 140-2 compliance

I went through a similar question with the HP Engineering team for the OVMS 7.3-2 and TCP/IP 5.4 environement. It is still not fully answered. Their "official" answer so far is that the SSL features are "ports" of FIPS 140-2 compliant implementations - so "of course" they are compliant.

My response was that "of course" has very limited meaning for the government. "Of course" works for "oh, you need to file seven more paper copies and twenty-one e-mail copies of this form." To which you say, "Of course I do..."

The bottom line from my security guys was, if it isn't directly certified, it isn't FIPS 140-2 compliant. The Federal Information Security Management Act (FISMA) of 2002 revoked statutory provisions to allow waivers of FIPS standards. The surrounding guidelines include something to the effect of saying "Unvalidated cryptography is viewed by NIST as providing no protection to the information or data" and basically counts as cleartext for the security evaluation process.

My own security folks say that despite it not being directly certified, it is possible to (as they say it) "socialize" the routines because despite FISMA 2002, there are ways to get waivers. Just more hoops to jump through. So I guess you need to discuss the issue with your security guys and see what, if anything, they have to say.

In case you were wondering, I'm at a DoD/USN site dealing with Privacy Act data for personnel-related information. So we have that FIPS-140-2 requirement, too.
Sr. Systems Janitor
Tom O'Toole
Respected Contributor

Re: Encryption and FIPS 140-2 compliance

and this process is perfectly designed to keep the revenue stream coming to the 'insiders' like billy bathgates and his gang of merry thieves. bathgatesOS is probably 'certified' this and that, and we all know how secure that is.
Can you imagine if we used PCs to manage our enterprise systems? ... oops.
Andre Stewart
Frequent Advisor

Re: Encryption and FIPS 140-2 compliance

I too, am wrestling with these issues. From a software perspective, how does HP's SSH and OpenSSL tools on HP-UX (11i v.1) fare in meeting the FIPS 140-2 standards?

Would HP ever put themselves out there and go on record to un-categorically state that their tools are FIPS 140-2 compliant (esp. something that is not NonStop computing?

How does one say that the System Management Homepage is FIPS 140-2 compliant? Does it involve the installation of a certificate meeting a specific compliance?
Steven Schweda
Honored Contributor

Re: Encryption and FIPS 140-2 compliance

> I too, [...] HP-UX (11i v.1) [...]

Why awaken a years-old thread in a VMS forum
to deal with an HP-UX question?

I know nothing, but from my limited attention
to OpenSSL stuff, I've gathered that actual
FIPS compliance (certification?) is a
non-trivial thing. It seems to require
platform-specific testing for each OpenSSL
version, which costs actual money, so some
particular vendor or victim needs to pay for

> [...] you'll want to ask for a statement
> from HP [...]

I'd say that that's true in your case, too.
Andre Stewart
Frequent Advisor

Re: Encryption and FIPS 140-2 compliance

You are correct. It was inappropriate to post this in the VMS forum. Forgive me.

As for awakening the thread, well, due to HSPD-12, APT, and a few other initiatives, this issue continues to be all too relevant. Meeting the compliance while continuing to provide effective, efficient, and practical services to our customers as well as keep the system administration practical is becoming a very difficult balancing act.

But your answer was perfect. Thank you. I now understand the reason why HP may not get "certifications" on every platform for every layered product and then try and maintain it going forward.

I'll also try and check within my organization to determine if any of them already have acquired a "restatement" from HP.

Again, forgive me. I'll refrain from extending this thread.
Steven Schweda
Honored Contributor

Re: Encryption and FIPS 140-2 compliance

Note that a quick Google search for
openssl fips
leads pretty directly to:


which explains some of the considerations
involved with OpenSSL.