Re: Field encryption (468 Views)
Reply
Occasional Advisor
LHicks
Posts: 6
Registered: ‎11-18-2008
Message 1 of 17 (469 Views)
Accepted Solution

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
Please use plain text.
Honored Contributor
Hein van den Heuvel
Posts: 6,585
Registered: ‎05-19-2003
Message 2 of 17 (469 Views)

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.



Please use plain text.
Honored Contributor
John Gillings
Posts: 2,992
Registered: ‎07-31-2003
Message 3 of 17 (469 Views)

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
Please use plain text.
Occasional Advisor
LHicks
Posts: 6
Registered: ‎11-18-2008
Message 4 of 17 (469 Views)

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?
Please use plain text.
Honored Contributor
John Gillings
Posts: 2,992
Registered: ‎07-31-2003
Message 5 of 17 (469 Views)

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
Please use plain text.
Occasional Advisor
LHicks
Posts: 6
Registered: ‎11-18-2008
Message 6 of 17 (469 Views)

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?
Please use plain text.
Honored Contributor
John Gillings
Posts: 2,992
Registered: ‎07-31-2003
Message 7 of 17 (469 Views)

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
Please use plain text.
Occasional Advisor
LHicks
Posts: 6
Registered: ‎11-18-2008
Message 8 of 17 (469 Views)

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.
Please use plain text.
Regular Advisor
Richard Jordan
Posts: 104
Registered: ‎10-31-2001
Message 9 of 17 (469 Views)

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.
Please use plain text.
Honored Contributor
Hoff
Posts: 4,921
Registered: ‎01-29-2006
Message 10 of 17 (469 Views)

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

Please use plain text.
Honored Contributor
Wim Van den Wyngaert
Posts: 4,561
Registered: ‎12-10-2003
Message 11 of 17 (468 Views)

Re: Field encryption

1. are all your users using encrypted transport (ssh, so not telnet) ? If not, a simple tcptrace could reveal the SSN.

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)

fwiw

Wim
Wim
Please use plain text.
Honored Contributor
Hein van den Heuvel
Posts: 6,585
Registered: ‎05-19-2003
Message 12 of 17 (468 Views)

Re: Field encryption

Wim is right in that at some point those SSN's or CC's or whatever secret info you have turn into real recognizable info and can be intercepted. Notably main memory and on the line. VMS makes it impossible for non-privved (non CMKRNL) users to glance at any memory other than your own, and standard encryption (SSH and friends) can protect the lines a long way.

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.

fwiw,
Hein.
Please use plain text.
Occasional Advisor
LHicks
Posts: 6
Registered: ‎11-18-2008
Message 13 of 17 (468 Views)

Re: Field encryption

I can see this is going to be a lot more complicated than originally thought(isn't it always), and it's looking like there are more questions than answers depending on what the company is trying to accomplish given the limited timeframe. Thank you to all who responded! I appreciate your time and will definitely use this forum again.
Please use plain text.
Honored Contributor
Hoff
Posts: 4,921
Registered: ‎01-29-2006
Message 14 of 17 (468 Views)

Re: Field encryption

Some folks have trumped the whole discussion of SSN and have switched to the use of an employee number or such; to less sensitive information. Various registries of motor vehicles finally figured this one out; not having the SSN on the driver's license was better than having it.

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.

Please use plain text.
Trusted Contributor
GuentherF
Posts: 233
Registered: ‎10-04-2006
Message 15 of 17 (468 Views)

Re: Field encryption

Non-US viewers can skip this...
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...

/Guenther
Please use plain text.
Occasional Advisor
LHicks
Posts: 6
Registered: ‎11-18-2008
Message 16 of 17 (468 Views)

Re: Field encryption

Yes, the SSN is for tax purposes.
Please use plain text.
Honored Contributor
Hoff
Posts: 4,921
Registered: ‎01-29-2006
Message 17 of 17 (468 Views)

Re: Field encryption

> Yes, the SSN is for tax purposes

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.)
Please use plain text.
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation