Looking for advice on CRYPTO::sign and CRYPTO::verify

Granted there are a bunch of different things you can do with these commands, here's a very basic example:

set secret_key "foobar1234"

set data "This is my data"

set signed_data [CRYPTO::sign -alg hmac-sha1 -key $secret_key $data]

if { [CRYPTO::verify -alg hmac-sha1 -key $secret_key -signature $signed_data $data] } {
    log local0. "Data verified"
}

The secret key will normally be some large string, size generally dictated by algorithm. The data is just whatever content you want to sign. The result of the [CRYPTO::sign ] command will be a binary value, so if you're going store this somewhere, probably best to b64encode it first. The [CRYPTO::verify ] command essentially takes the original data and the digital signature of that data (derived from [CRYPTO::sign ]), decrypts that digital signature with the key, creates a new hash of the data, and then compares the two hashes. If they're the same, then the contents have not been modified.

Now, for what it's worth, you can encrypt a cookie with a lot less effort using the AES command. Further, an encrypted cookie only verifies that the cookie wasn't tampered with. It does not, however, protect against a cookie being stolen. It's also best practice, from a security perspective, not to put anything in a client side cookie that's of any value (that could affect server side logic with some manipulation). Then you don't have to worry about encrypting or signing the cookie.

In response to your query on using the AES commands, which are a lot more straightforward, I have a requirement to us CBC mode encryption and it is my understanding that the AES commands use CWC, the CRYPTO commands allow you to choose CBC.

 

The nature of the way AES works in iRules generally precludes it from being used "off-box", such that you could encrypt something on one device and decrypt it with another. That said, if you were only ever encrypting and decrypting on the same box, I don't see why it would matter, technically, which algorithm you used (unless you have some policy-based requirement).

 

It is appreciated that signing really only protects against cookie tampering and does not stop the cookie being stolen and used by another client. To that end I would like to have something, however small, in the cookie which could tie the cookie to the client. I'm working on an internet based app so client IP doesn't really cut it. Any suggestions?

 

There's an entire science behind this form of "fingerprinting", and not something that's particularly easy to do. A good source for information is the Panopticlick website:

 

https://panopticlick.eff.org/

 

It's also something that the Application Security Manager (ASM) module does rather well.