Encrypted LD logical disks

[Troodon]

Just an idea. It would be really neat to be able to specify encryption on logical disk volumes as part of the initialize and mount commands.

The encryption functions are now standard as I recall, so why not make logical disks a secure storage mechanism, with a command like
$
$ init node$lda3: mydisk -
/key=mykey-
/algorithm=AESCBC128
$
$ mount/group node$lda3: mydisk -
/key=mykey-
/algorithm=AESCBC128
$
$
Which would make node$lda3 a secure volume to group members and sysadmins with the correct privileges. Of course, subsequent reads and writes would have to call the encrypt and decrypt routines as part of the $QIO pre or post processing, but I don't see that as a huge project at the operating system level.

Depending on where this code has to be implemented, it might even be possible to encrypt all physical data drives, and not just logical disks, although I would be very happy with just logical drives.

[Jur van der Burg]

This is already on the wishlist, but it may take a long time to implement. Don't hold your breath.

Jur (LDdriver author).

[Jon Pinkley]

I have played with TrueCrypt volumes on a Windows XP system. I agree the ability to do something like it on VMS would be nice.

However, I am not convinced that it would not be a "huge project". At least it is unlikely to be as simple as adding conditionalized routines to call the encryption/decryption routines from the pre processing (FDT) routines and post-processing routines.

First, consider that LDDRIVER is at a layer below initialize and mount. LD devices currently use unmodified VMS software to do the initialization and mounting of devices. TrueCrypt (windows version at least) provides a front end to create, format (What VMS call INITIALIZE), and mount volumes (mounting volume in TrueCrypt/Windows is more like the combination of connecting an LD device and mounting it in VMS).

If this is going to be done at the Mount and Init time, then I will argue that this needs to be done by VMS engineering, not by a third party. This approach would possibly be the most general method, and could work on top on any LBN addressable storage. So it would be compatible with LD devices.

On the other hand, if it is going to be done by the LD software, I would guess that the "ld connect" is the place that a key would be supplied. I am not aware of a way to connect a device at anything less than system scope (i.e. the io database is a system wide construct, it is not designed to be group, job or process specific).

So it isn't clear to me how that would work with you mount/group example.

LDDRIVER was developed as a midnight project in Digital/Compaq/HP, but it is no longer being developed by hp. Jur no longer works for hp, and therefore his work on LD is now completely on this own time.

If this capability is ever added, I would suggest that the TrueCrypt implementation at least be investigated. I don't know how much of the work is being done by TrueCrypt software vs. Windows. My guess is that the TrueCrypt front end is just calling Windows routines to do the formatting of the underlying volume. I do know that it is possible to use the Windows format disk routine after the volume has be mounted by TrueCrypt, so that suggests to me that the encryption/decryption is being done at a lower level than the "file system" level. I created a 10 MB TrueCrypt volume and let it get formatted as FAT, then used windows to format the "drive" to NTFS (no key needs to be specified here). I was able to copy a file to the reformatted volume, then dismounted and remounted it (specifying the original key) and verified that the file was usable, so it does appear to me the encryption/decryption is being done at the logical block (device level) and not by the file system.

Jon

[Troodon]

I never suspected that this would be implemented by a third party, but it ought to be quite possible for the OpenVMS team.

It's clear there is an obvious demand for such a feature; Apple has it....

[Hoff]

An example of this "cryptodisk" encrypting disk device driver has existed for almost twenty years, and is openly available in the OpenVMS source code archives. Go look for the VDDRIVER and FQDRIVER pieces at <>

There were some fixes to VDDRIVER a decade or so back to better synchronize it with XFC; make sure you have those.

[Jon Pinkley]

Glenn's crypto disk doesn't use strong encryption. Here's what

http://mvb.saic.com/freeware/vlt93b/virtualdisk_cookbook.doc

says:

"Crypto disk - uses a file as its storage, but encrypts (fast) all data written, decrypts on read. The host process must be initialized with the right crypto key or the disk looks like random garbage. The algorithm is not DES, since DES is SLOW. It is however one I can't see any simple way to break. Its algorithm is XOR with a fairly long stream of bits, which is blindingly fast and good enough to foil non-cryptographers."

There are well known attacks against this type of cipher, so I wouldn't use it to protect anything valuable. It is better than nothing, but so is ROT13.

It wasn't designed with the same goals as something like TrueCrypt, and low overhead was a higher priority goal than security.

It depends on what you are trying to protect. When a disk is mounted in VMS, the data can be protected from non-privileged users, and using things like high water marking and erase on delete can prevent data scavenging. If the purpose is to store data on a removable drive, and that drive would be accessible by an "adversary", then the protection provided by something like TrueCrypt is much higher that that provided by FQDRIVER.

Jon

[Hoff]

Crypto can always be broken.

It's a question of how much you want to spend up front to encrypt and decrypt and to securely manage your keys (in terms of time and effort and process and crypto), and particularly a question of how much your expected opponent wants to spend to expose your data.

And it's not always what you expect: I've seen AES256 encrypted data read in minutes, and I've seen ROT13 thwart access. Your attacker will quite often utilize an asymmetric attack. Here for instance, utilizing AES65536 matters not if the SYSTEM password was exposed.

Most folks encrypt specific files, and not usually (due to the performance overhead that modern "reliable" encryption entails) whole disks.

[Jon Pinkley]

I agree with what Hoff said (even the open ended "crypto can always be broken", as long as no time limits are imposed).

I would have said that keeping something secret from something that can use any method possible to extract it is almost futile. They will probably not have to worry about breaking the crypto, there are almost always more direct ways to obtain the info. People are, in my opinion, much more vulnerable targets than modern crypto.

I also question the value of using encryption on a disk that is permanently mounted. The data is not protected from a privileged user. About the only benefit is that if a disk fails, you would not need to worry as much about physically destroying the drive.

On the other hand, using something like TrueCrypt on a USB flash drive or an executive's Laptop is something that is useful. In this case, you are protecting something that could be easily lost/stolen, and the confidentiality of the data is worth far more than the hardware.

This is one reason I don't agree that because Apple has it, there must be an obvious demand for it (for VMS). That's comparing Apples to Alphas (sic).

I don't have FQDRIVER, so I can't test this, but given the description of the crypto disk cipher "XOR with a fairly long stream of bits", consider what will be on the disk oxide after an $ init/erase.

Jon

[Troodon]

Not all OpenVMS environments pass out privileges like candy and some data is only used during production and then left in a dismounted state the balance of the day. I imagine all those NSA C2 sites would be glad to have encryption available, especially considering the number of embarrassing experiences the British NHS and Revenue departments have had recently.

With our modern storage array systems it is possible to remove and replace a shadow volume and carry it off site without immediately alerting someone about the security failure. Encryption would make this less useful.

It seems to me that encrypting data in the Backup program without the same opportunity with the user data on a file or volume basis is a weak link in security for this very robust operating system.

[David Jones_21]

Encrypting makes sense where the primary threat is theft of the media. If the primary threat is unauthorized system access, drive encryption is of limted usefulness. Once mounted, the effective protection of the encrypted drive is no better than an unencrypted drive.

[Jon Pinkley]

RE:"With our modern storage array systems it is possible to remove and replace a shadow volume and carry it off site without immediately alerting someone about the security failure. Encryption would make this less useful."

That assumes the person that is making unauthorized copies of the disks does not have access to the keys used for encryption.

Hopefully the sites that don't "pass out privileges like candy" also limit physical access to the computer room.

I agree it would be nice for VMS to provide encrypted volumes, but I don't think it would add much protection under normal computer room conditions. If the disks are being used for data transfer between sites, then having the data encrypted makes sense, otherwise it's a bit like putting a deadbolt on a screen door. If you need encryption to protect the data disks in your computer room, you have bigger problems to deal with.

Jon