- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: Field encryption
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-18-2008 10:43 AM
тАО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?
thank you
Solved! Go to Solution.
- Tags:
- encryption
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-18-2008 11:49 AM
тАО11-18-2008 11:49 AM
Re: Field encryption
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-18-2008 12:32 PM
тАО11-18-2008 12:32 PM
SolutionWithout 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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-18-2008 12:58 PM
тАО11-18-2008 12:58 PM
Re: Field encryption
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-18-2008 01:04 PM
тАО11-18-2008 01:04 PM
Re: Field encryption
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-18-2008 01:18 PM
тАО11-18-2008 01:18 PM
Re: Field encryption
Am I being overly optimistic?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-18-2008 01:30 PM
тАО11-18-2008 01:30 PM
Re: Field 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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-18-2008 01:48 PM
тАО11-18-2008 01:48 PM
Re: Field encryption
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-18-2008 03:24 PM
тАО11-18-2008 03:24 PM
Re: Field encryption
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-18-2008 03:29 PM
тАО11-18-2008 03:29 PM
Re: Field encryption
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