11-18-2008 10:43 AM
I'm supporting an OpenVMS v7.3-1 Alpha using Cobol with DECForms and RMS files.
Within one of the files I've been asked to encrypt just the social security number field.
Is it even possible to encrypt a single field and would special software be needed?
Solved! Go to Solution.
11-18-2008 11:49 AM
There is no generic, of the shelf, software to deal with this. You'll need to roll your own service routine for the field. Not sure whether that would be best done at the GUI level or the data access level. I woudl want the data encrypted as long as possible, in which can you can perhpas DECforms teach the conversion/lookup trick.
You may want to deal with this through a secondary file to map an application defined user-id onto an SSN which is stored encrypted. So a main record read might be followed by an encryption table lookup for the SSN and vice versa: a lookup by SSN first hits the table to find the application ID, and then selects the details using that.
Similar for credit cards.
Encrypting whole files would be extra tricky if key -order is important. More often than not, it is.
11-18-2008 12:32 PM
Without knowing your exact requirements and constraints it's difficult to suggest a solution, but in general terms you need an extra step in your record processing to encrypt and decrypt(?) the field in and out of the file. There are numerous mechanisms you could use ranging from simple textual obfuscation, for example, a trivial substitution cypher, through to complex "unbreakable" algorithms with keys thousands of bits long. It all depends on why you're protecting the data and how much money you have to spend on compute power.
Note that if the application can decrypt the SSN without the operator having to give a key, then there's not a lot of point in encrypting it in the first place.
On the other hand, maybe you don't need to decrypt at all? Perhaps the SSN is there for lookup only? In that case there is a simple solution... use the OpenVMS password hash algorithm - SYS$HASH_PASSWORD. It will give you a quadword hash value which you can use as a key in your file.
To find a record by SSN, hash the given SSN and lookup the hash value in the file. You can't reverse the hash algorithm, so accessing an arbitrary record will not give you the SSN.
To use the hash algorithm you need a "username" and optionally a salt value. For this purpose you can make them both constant, or, for slightly increased security, require both SSN and surname to perform the hash.
11-18-2008 12:58 PM
The SSN in the file is not a key field so it wouldn't be involved in any record lookups. And it would only be decrypted for document printing and maybe if a single user had to maintain it for corrections. I don't even have all the details yet though. Not alot of time or money available to come up with a solution.
So do you think my best bet is to come up with some type of substitution cipher as John suggested?
11-18-2008 01:04 PM
Depending on your auditors, you may not even need encryption, just higher protection of the file containing SSNs.
Only your print run needs access to the SSN file. As it processes the file, it looks up the SSN in the other file to add to the other information in the record for printing.
11-18-2008 01:18 PM
Am I being overly optimistic?
11-18-2008 01:30 PM
Think about it, you want to encrypt the field, BUT some random user from a web site needs to be able to decrypt it? So what's the point?
Is the encryption to prevent people who may be able to steal (say) the whole file from getting a list of SSNs? Who are you protecting data from, and how will those who are permitted to access it authenticate themselves?
If your objective is just to be able to control the data to the standards of auditors, then have a look at protected subsystems. They allow you to protect files so they can only be accessed from specific applications, so you have total control over data flow. From outside those applications, you can clamp down the security so tight that the files are not even visible, let alone readable.
11-18-2008 01:48 PM
Our internal alpha users(employees) are captive users who are locked into menus so they do not have access to the system level.
This system will be mothballed in the next couple of years and there's no system manager resource to tap into as far as security issues (which is above my level of expertise). Hence my predicament.
11-18-2008 03:24 PM
An encrypted filesystem would be acceptable; I still hope that LD will gain that capability down the road since it should be transparent to the applications.
We're currently experimenting with using the VMS Encryption package built into V8.3 (a pay for product on your version); the API allows you to encrypt smaller blocks of data which a program can then place into fields in an indexed file (or sequential fixed length record in our test case). But its key handling for API use is primitive; retaining a key across sessions or reboots is (as far as I've been able to determine) a manual operation, requires its own careful security handling (do you have to encrypt the file that stores the key between sessions/boots?), and I'm not sure its even supported. The version you could run probably doesn't support anything better than DES encryption either.
I've been told that CDSA also provides the tools for manually encrypting chunks of data under program control, so could do the same thing but with more "standard" PKI infrastructure, but I don't believe that is on your version and I haven't had time to start reviewing it yet. So sorry, i don't have any real suggestions for you. Your options improve if you can upgrade VMS though.
11-18-2008 03:29 PM
So do you ever need to display the value or retrieve it, or is this a case where you're using it as a verification?
If you never need to display it, then GET RID OF IT.
Hash it. (Create a message digest or password hash or such, and then compare against the hashed value.)
>We want to encrypt that SSN field as its being passed from the website to the Alpha. And then we want to encrypt it on the Alpha also.
If you never need it back, GET RID OF IT. Hash it.
>Since auditors were involved, I'm assuming it's to prevent theft from an outside source.
The vast majority of these are inside jobs; folks (like you, sorry) that gain access to this information.
>Our internal alpha users(employees) are captive users who are locked into menus so they do not have access to the system level.
Consider me skeptical; the folks I've worked with in these environments could and often did have far more system access than folks realized. Either directly, or through parallel paths. When I'm asked about these cases, I always presume the employees and the attackers are smarter.
>This system will be mothballed in the next couple of years and there's no system manager resource to tap into as far as security issues (which is above my level of expertise). Hence my predicament.
This isn't system management.
This is application programming.
The routines needed to encrypt data or to generate a cryptographic digest (hash) are in the security libraries on recent OpenVMS releases; CDSA arrived at V7.3-1.
There's an intro here:
11-19-2008 03:32 AM
2. Idem for printers, db links, etc (I can get even the Sybase sa password with tcptrace !).
3. I hope you are using httpS.
4. if you split the SSN in different parts (e.g. 1 filed containing the even positions and 1 field containing the uneven positions), then it's no longer a SSN and thus doesn't need to be encrypted (thus by pass the requirement of encryption).
5. I wonder what Volker could get out of memory of a process having the decrypted data in memory.
6. Do you print directly to a (secured) printer or do you keep the file on disk (oeps, unsecured) ? Idem cobol workfiles, sort files.
IMO a loss of time (just as most sox stuff)
11-19-2008 04:40 AM
I would recognize permanent disk storage as the greatest vulnerability in the whole cycle.
The data just sits there for years or decades, and over and over.
Those files get backed up, moved off site.
The disks may be retired and improperly disposed of. Well meaning consultants (myself) may snarf a copy to analyze (performance) patterns and while not interested in the data themselves, move it out of the careful into the careless realm.
Or maybe it is 'just' an RMS convert producing a CONVWORK in a spot you failed to protect (sys$scratch is often sys$login).
VMS tries to help with file protections, High-water marking, delete/erase, init/erase and such. But once a disk, tape or whole storage subsystem is outside of the running environment pretty much anything can be done to it by anyone.
All that suggests to me that encryption of sensitive data in the files is probably a desirable thing to do. Encrypting the whole (virtual) disk is probably the more transparent, easiest, way to accomplish this for the applications.
11-19-2008 05:37 AM
11-19-2008 07:18 AM
I am extremely skeptical of any site that requests the SSN. Even those organizations authorized to request it tend to botch it. (One open WiFi or WEP WiFi or weak WPA PSK can ruin your whole day.)
It's a particularly questionable human identifier value, too, given the folks running the SSN system have made multiple fundamental flaws in its design (eg: no check digit), and the address space is rather limited, and the set of folks that possess such identifiers might not be what you want it to be.
Organization-generated identifiers (company employee numbers, etc) can be a better solution, as can digital certificates and such. Both of these can be part of other security-related protocols, too. DCs are very handy, including for use with https and with VPNs.
And the SSN is a target regardless, and I'd rather not have a target painted on my applications. Which is why I seek to avoid having SSN or other data. Or to one-way hash the data. The less data and the less recoverable the data, the less that can be exposed in a breach.
11-19-2008 12:41 PM
It is my naive understanding that my SSN is only needed by a 3rd party if they have to report some of my tax activities to the IRS. If this is the case here then yes, enhance the application and use some form of encryption.
Otherwise replace the SSN with an new ID. Again a change in the application but the right one in the long term.
Now how can I get my credit card number encrypted on my card so that no one else can read it...
11-19-2008 02:05 PM
Ok; I'd then head toward public key encryption (PKE) here, and use the hashed values save for when I specifically needed to retrieve and view the cleartext.
The advantage with PKE is its asymmetry; there is a key to encrypt the data and a second and separate key to decrypt the data.
For most purposes here, only the encryption (public) key is "floating" around. For SSN comparisons and for anything else that doesn't need to retrieve the SSN can use the public key to encrypt the provided SSN and can compare the results against the saved SSN.
Only when the cleartext SSN is required does the private key come out to play.
(And use one of the provided PKE crypto libraries. Don't roll your own crypto.)