Openede RCode signing (verification)

Posted by SJProgress on 21-Sep-2017 06:27

Hi,

for some legal requirements in some countries we have to make sure, that OpenEdge RCode ist not altered in any way by a customer and only "secure/signed" code is executed within our application.

I had a look at RCode MD5 value, but this does not do, what we need. (we can alter string in RCode file via some editor and code can be executed and MD5 value does not change!).

So my questions:

Does anyone have created some "signed code" "secure code" framework with OpenEdge?

Does anyone have some guidelines/ideas what route to go?

OpenEdge General - Forum

All Replies

Posted by Lieven De Foor on 21-Sep-2017 08:05

I would also like to hear more on this from Progress, as this is (becoming) a requirement more and more...

Posted by jbijker on 21-Sep-2017 09:46

When you compile you need to specify GENERATE-MD5.

E.g.:

compile myfile.p SAVE GENERATE-MD5.

We're using MD5 to track which programs were changed between 2 releases. It's much better compared to the CRC.

See documentation.progress.com/.../index.html

Posted by SJProgress on 21-Sep-2017 09:59

Thanks, for the answer.

I know how to create MD5 value for RCode. But regrattably this does not solve the problem. When you change RCode with some hex-editor, the MD5 value does not change and there is no functionality to use on the client side to calculate MD5 for existing rcode and compare it to MD5 value acutally stored in rcode file.

(Besides: MD5 is considered to be not sure any more)

Posted by Peter Judge on 21-Sep-2017 10:00

You can also create a hash-of-hashes for the whole codebase.
 
So, something like
- compile each .p/.cls with MD5,
- sort the files in a directory and the directories (alphabetically or by size or by mtime or something known and consistent).
- calculate a new hash, with the previous file’s MD5 as a salt
    So file1.p hash = md5-digest(rcode-info:md5-value, <previous-md5>)
- you should use a salt for the first file.
- this produces a single hash. Store this value (per release?) and the first salt securely (in a db field? At the end of a URI?)
- when the application starts, recalculate the hash across the whole application code.
- compare to the final hash.
- technicolour yawn if they don’t match . you can also tell from this approach exactly which files were tampered with, since you know where the hash value differs from your correct value.
 
I’d like to create a set of Ant/PCT tasks to do this, but time …

Posted by George Potemkin on 21-Sep-2017 10:14

RCODE-INFO:MD5-VALUE is /not/ MD5 value of rcode. It's MD5 value of a source code that was used at compile time.

You can use MD5-DIGEST() function to calculate MD5 value for rcode as a file.

Posted by jmls on 21-Sep-2017 10:38

made a *lot* simpler if you shove the .r code into a pl - then md5 / digest that file ;)

md5=($(md5sum file.pl))

with the added advantage that if you name the .pl as `YYYY-MM-DD-release.pl` you can swap out any "bad" pl and start using the older pl immediately. practically no down time ..

Posted by Lieven De Foor on 22-Sep-2017 07:21

While people can create very creative *solutions* for this problem, I really think it's up to Progress to quickly provide something robust to handle this...

@Peter, I don't think calculating a hash like that at every application startup (with sometimes lots of files/large files) is the way to go...

Posted by jankeir on 22-Sep-2017 07:38

Also, how do you make sure that the .r file that does the verification isn't tampered with? I would expect one can either change no .r files or all of them, only some sounds unlikely.

This thread is closed