Encrypt/Create and group

[Aaron Sakovich]

I'd like to create a key for the Encryption utiltiy, but restrict it to the System group ([1,*]). I want to easily create this after any system reboot, but of course don't want to put my passphrase into a script file.

My first thought was to issue a $ SET UIC [1,4] then run the $ ENCRYPT/CREATE/GROUP, but this failed -- the key was created in my own UIC's group, not [1,*].

So now I'm thinking about creating a small script that will accept the passphrase as input, the RUN/DETACH/UIC=[1,4] with the passphrase in a temporary input file, then immediately DELETE/ERASE that input file. There's more exposure doing this, as I'll be writing the passphrase to the disk temporarily, whereas the other option would not.

But, are there any other options I've not considered? Any other ideas on how to easily and securely create a key in a group that I'm not a member of? (It would be cool if /GROUP was /GROUP{=[UIC]} and required CMKRNL, but it's not.)

TIA,
Aaron

[Hoff]

Please forget you ever heard about or knew of SET UIC. That command never worked right. If you want to do that sort of across-UIC thing, use RUN /UIC or SUBMIT /USER.

As for RUN, pick either RUN /DETACH or RUN /UIC. Not both. The former is a detached process under your UIC. The latter is a detached process under the specified UIC.

I might punt the whole of the existing encryption support and pick something better; what's there (DES and AES) works, but you have to deal with and secure keys whenever you pick symmetric encryption.

Public key encryption (PKE) can potentially be useful here. (There are multiple gpg ports around; the HP gpg port seems a little unstable, but there are others around.)

Though yes, there's the question of integration; there's the level of DCL integration provided by the existing ENCRYPTION for OpenVMS product (or the V8.3 and later integration of same). (I don't know off-hand if anyone has stuffed PKE into the encryption layer. I'd hope it's at least planned, as symmetric encryption is far from the only game in town.)

As for passing the key around, it's intended to be entered by a human. If you're automating that and using a file or a mailbox or such, lock it all down to the best of your ability and then worry about something else; you're already risking your key. (This is why I tend to prefer PKE; you can freely expose your public key.) But since folks that can peek at the system-level files can see it, you can't secure it any further than the folks and the servers and the applications that have access via the system-level protection mask.

[Aaron Sakovich]

Good points, Hoff. Sorry 'bout the brain fart on the /UIC/DETACH switches -- I've run into that before, but for some reason I've got a mental block on that pair. The block frees up about the time I run it the first time after I've coded it that way! 8)

BTW, I'm not looking to encrypt files -- I just want to /AUTHENTICATE them to make sure they've not been tampered with (above and beyond the file auditing already done).

[Hoff]

So you're off with a quest for system integrity? Ok. That's not typically implemented with symmetric encryption on any platform; that's more commonly implemented (as with OpenVMS and its password storage) with a one-way hash.

Depending on the skills of your attacker and your OpenVMS version, the default CHECKSUM command can be applied, or (better) MD5 or (best) SHA.

http://64.223.189.234/node/647
http://64.223.189.234/node/832

I'll post up some other stuff at that site later today.

There are pre-built versions of MD5 around (there's a known wrinkle here with building on VAX; you have to disable one of the compiler options due to a permanent restriction in the compiler's code generator) on the Freeware, gpg and openssl dgst (part of recent OpenVMS) and other such tools include signature capabilities.

Suggestion: don't ask point questions for these. Or if you're going to ask point questions on specific commands, consider providing some background on why.

[Steven Schweda]

> [...] the HP gpg port seems a little
> unstable [...]

Nah. It's _very_ stable, especially for the
VAX, where it's still dated "November 2003".

http://h71000.www7.hp.com/opensource/gnupg.html

(They broke the VAX build when they added,
badly, IA64 support.)

The pyramids in Egypt are also _very_ stable,
but there're not much use if what you wanted
was a GnuPG implementation.

[Aaron Sakovich]

Hmmm, I asked pointed questions because the other options you mentioned are not possible. As is often the case with many customers, we can not run non-vendor software on some of our systems, and I want a solution that will always be there.

CHECKSUM is indeed a possibility that I considered, but a simple checksum is far easier to subvert than the MAC in ENCRYPT.

But I didn't want to talk about that -- I was simply interested in finding out if there was an alternative or better way of populating a key outside of my group. Based on the lack of a response, I'll presume there isn't.

[Hoff]

OpenSSL is built into current OpenVMS, though I've not dealt with the digest mechanisms within in OpenVMS. (It works in the other boxes I deal with that have OpenSSL baked in.)

The code to MD5 is freely available, and can be acquired directly out of the associated RFC.

And here's a discussion with some related details.

http://64.223.189.234/node/992