Public key / private key pair usage


#1

I wonder if anyone has used Lucee or ACF or Railo to create public key and private key pair to protect some sensitive data. If so, I’d love to read up the entire process.

Thanks.


#2

You didn’t really state where you’re trying to protect that data, so I’ve got several thoughts…

If you’re securing files on the filesystem or that are to be transported over the wire (mail, socket, ftp, http, etc.), then I would use PGP (gnupg on linux) via cfexecute()

If you’re just stuffing things into the database, then you can do multi-pass encryption (ex: the triple pass ‘db’ encryption in https://github.com/ddspringle/framework-one-secure-auth/blob/master/model/services/SecurityService.cfc).

A not very secure alternative would be to use the PBE encryption method available with encrypt() which let’s you use a salt (password) to secure the data. You could also use some combination thereof.

Either way, using PKI for the database is probably overkill and there are easier ways to implement user level security (e.g. unique keys per user) than having to resort to PKI techniques. That said, there is nothing stopping you from using PGP and storing the result in the database either.

And if you’re real adventurous Bouncy Castle is included with Lucee, so you could drop down into Java and do all kinds of PKI encryption available there. Including PGP. You could also try and use http://pgp.riaforge.org/ which uses Bouncy Castle under the hood. There were some PGP changes in either 1.57 or 1.59 of Bouncy Castle iirc though so YMMV.

Not so much a ‘process’ for you, but a handful of ideas to consider. Implementation is pretty straight forward in all but the last couple of cases.

HTH

– Denny


#3

Thanks for the informative response, I’d like to see some sample implementation using public key / private key pair with “Bouncy Castle (is) included with Lucee,”, anything like that available?


#4

Not that I’m aware of, no. There’s nothing in Lucee directly that ties into BC’s PKIX that I know of (though someone more familiar with the Java code than I may know otherwise of some undocumented gem), and aside from examples of using PGP (which is PKI, fwiw) I doubt you’ll find anything CFML related on using other PKI tech.

You’d probably have to find a Java example of what you’re trying to do and then wire it together inside CFML (as outlined, briefly: https://cfdocs.org/java), or build a Java CFX (or Lucee extension). Or… just use PGP.

If there’s a specific business requirement for a specific PKI implementation, then you can always talk with Rasia or, I think, Ortus Solutions about paying to have a solution developed and implemented into Lucee that meets your needs.

Otherwise, throw it into an ER and try to garner support for inclusion in some later release. You’ll need something a little more well defined than what you’ve offered here though either way :wink:

HTH

– Denny


#5

Hi,

The zip download at http://pgp.riaforge.org/index.cfm?event=action.download contains multiple CFML examples. The code (and Railo extension) was written by Bilal Soylu, who is always very thorough with documentation.

Kind regards,

Paul Klinkenberg


#6

Thanks Paul.

Key generation function works but key reference URL was incorrect but that’s no biggie, I’ll play with it.

Issue tho.
Upon encryption, attempt at decryption even without signature generated the following error:

Error (fDecryptSimpleFile):org.bouncycastle.util.Arrays.constantTimeAreEqual([B[B)Z-

Please make sure you selected a private key file containing a valid key and supplied a valid key passphrase

a private key file containing a valid key = Yes
and supplied a valid key passphrase = Yes

What could cause this problem?
Btw, I’m on Railo 3.1.1.


#7

Progress.
I’m doing some debugging and noticed that the the order of the four parameters passed via the caller using argumentcollection was not the same order that the controller cfc expects. When order matched decryption were successful while it still generates an error (false positive), equally importantly, it copied over the source file (file to be encrypted) to the usr directory, from security point of view, very undesirable.
Since the targetFile parameter is optional, I tried to leave it out. Good. It no longer copied over the source file.

Signing works in similar fashion.

Thanks.


#8

Anyone else pick up on this? I realize that there are always reasons for not upgrading, but that is seriously out of date. Railo is no longer supported or patched and likely to contain security vulnerabilities.

At the very least, have you attempted to move to Lucee 4.5?


#9

I have different cfml engines running, some Lucee 5.x, some Railo and some ACF 2016.