1745824 Members
3974 Online
108722 Solutions
New Discussion юеВ

Field encryption

 
SOLVED
Go to solution
LHicks
Occasional Advisor

Field encryption

I've seen questions on file encryption but I'm trying to find out if it's possible to encrypt a single field within a file.
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?
thank you
16 REPLIES 16
Hein van den Heuvel
Honored Contributor

Re: Field encryption

Sorry, No can do.
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.

fwiw,
Hein.



John Gillings
Honored Contributor
Solution

Re: Field encryption

Yes it's possible to encrypt a single field, but there isn't a simple flag you can give COBOL to do it for you.

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.
A crucible of informative mistakes
LHicks
Occasional Advisor

Re: Field encryption

thank you for the info Hein & John.
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?
John Gillings
Honored Contributor

Re: Field encryption

In that case I'd be recommending Hein's suggestion of storing the SSNs in a separate file, keyed on whatever you use for an unique ID on the main file.

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.
A crucible of informative mistakes
LHicks
Occasional Advisor

Re: Field encryption

I like the idea of a separate file. However I forgot to mention that SOME of the records being loaded into this table are coming from a flat text file from a front-end website in addition to the users loading them thru DECforms on the Alpha. So we were hoping to encrypt the field at the website level too. That same cipher substitution could then be used at the website level too, along with the Alpha.
Am I being overly optimistic?
John Gillings
Honored Contributor

Re: Field encryption

Now you need to step back and examine the reasons for encryption.

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.
A crucible of informative mistakes
LHicks
Occasional Advisor

Re: Field encryption

The website customer(not a company employee) is giving us their SSN as one part of a service we're providing. 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. Since auditors were involved, I'm assuming it's to prevent theft from an outside source.
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.
Richard Jordan
Regular Advisor

Re: Field encryption

We're also looking at options for doing this kind of work (again) for financial systems. I have been told that the PCI requirements 'almost' mandate that certain information must be encrypted if its hits the disks. There are exceptions available for systems without the capability but having to use them "doesn't look good".

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.
Hoff
Honored Contributor

Re: Field encryption

> The website customer(not a company employee) is giving us their SSN as one part of a service we're providing.

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:

http://64.223.189.234/node/372