Forum Discussion

Magnum_IP's avatar
Magnum_IP
Icon for Nimbostratus rankNimbostratus
Nov 08, 2013

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

Hoping someone can help...

 

The documentation around the CRYPTO::sign and CRYPTO::verify commands is minimal and I can't find any worked examples online. Couple that with my limited knowledge of cryptography and the challenge of providing cookie integrity checking in an iRule and I'm struggling.

 

I'm currently using the CRYPTO::encrypt and CRYPTO::decrypt commands to set and encrypted cookie in the response to a client and the decrypt it in subsequent requests and that seems to be working well. How to use the sign and verify commands around this to check that the cookie hasn't been tampered with eludes me though.

 

Any help or advice appreciated.

 

fergu5

 

application delivery
cryptography
devops
iRules
  • Kevin_Stewart's avatar
    Kevin_Stewart
    Icon for Employee rankEmployee
    Nov 08, 2013

    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.

  • Kevin_Stewart's avatar
    Kevin_Stewart
    Icon for Employee rankEmployee
    Nov 11, 2013

    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.