Encryption/Decryption

[dwhite]

Hello,
I am trying to learn about how encryption/decryption works in Progress. I have a need to build an encryption process for clients who use our software for messages that would be sent from them to a third party vendor.

It appears that Progress only uses symetric encryption and that the key must be the same in the encrypt and decrypt process. This means that I need to store the key somewhere so that the software can encrypt it and the vendor will need to know that key so that they can decrypt it.

Storing the key is where I'm worried. Because the process for encryption will be done automatically on each client's server, the key has to be stored on their server somewhere and the only way I can think to do that is through a database table. But that doesn't seem very secure from someone who could write a query to read into that table.

The other issue (not sure if it is an issue) is that the third party vendors won't have Progress and will have to use their own processes to decrypt the message. I've been told that as long as I supply the algorithm to them that this isn't an issue, that they can use whatever language they want to do the decryption. I wanted to verify that this is true?

I have read through how to build an encryption process in Progress and know how to do that, basically I'm wondering on how keys are typically securely stored in a situation like this and if it is true that the third party vendor does not need to have Progress to decrypt the message?

 

[TomBascom]

When speaking of encryption it is very important to specify the version of Progress being used. Capabilities vary dramatically.

Is there a reason why you wouldn't want to use SSL?

 

[dwhite]

By the time this is in place we'll be using 10.2B.

We are doing this for a certification process - in which the certification requires us to prove to the tester that the information is unreadable. From what I understand of SSL, it's unreadable while in transit but is readable when it reaches it's destination. So we couldn't prove that it was ever unreadable.

 

[TomBascom]

I'm finding it hard to believe that any reputable certification authority would prefer a home-grown "encryption" solution over a mature industry standard.

But perhaps I'm missing the point.

What is it that needs to be encryptyed? The data on disk? If so then that would seem to be the point of TDE or encrypt()/decrypt(). The message from server to client? If that's it then SSL seems like the right solution. Something else? If it's something else then it needs to be described.

 

[dwhite]

Here is the exact specification for the test:

Using Vendor-identified functions, the Tester encrypts the information using a
symmetric algorithm. ​

​

​

​

The Tester validates that the information is unreadable.

We essentially need to verify that we can encrypt data that is leaving a client of ours and going to a third party vendor. SSL won't be "good enough" for the test because of the requirement above (that the tester must be able to validate the information is unreadable.​

 

[RealHeavyDude]

IMHO: Maybe it's more about data from reports that users can save to disk. Usually data is understood to be "save" as long as it is not leaving the application - as long as their is an authorization model introduced into the application which enforces data access controls. But as soon as the users have options to extract or download data in form of reports which they can save to their local disk or send via email you need to prove that such data is either encrypted when stored in insecure locations or can only be stored in secure locations.

Furthermore you need to have data and information security policies in place which clearly state who is responsible for what. Is the application responsible if sloppy users send sensitive data that they have extracted in form of an Excel report via unencrypted email?

You should get a hold on whoever is responsible for that audit and ask them what it really is that they want to be proven so that you can bring the evidence to prove it. Storing data in encrypted form on whatever device might just be one point. Usually auditors, as far as I have seen, want to see a lot more - and they will ask you for it.

One last thing: Auditors usually appreciate the use of proven industry standards. If you present the with a proprietary solution they might raise an issue or require you to go into all the gory details of it.


Heavy Regards, RealHeavyDude.

 

[TomBascom]

I still don't understand the requirement. I suppose a manager might think that it is clear.

As far as the "encryption" part of it goes you could seemingly satisfy it with rot13.

 

[RealHeavyDude]

Me too. The test description is completely out-of-context. Can be all or nothing.

Usually, when auditors attempt to set a foot into a development department, somebody should have walked the developers through the audit process in the first place. If this is not happening - for whatever reason - there will be findings ( meaning issues ) reported by the auditors, simply, because usually auditors and people involved with risk management are talking a different language than developers do ( here I can speak out of experience - we had to learn this the hard way ... ).

Heavy Regards, RealHeavyDude.