Digitally Sign SOAP Request using PKI and SSL Cert Created and Sent in an iRule Side Band Connection

3a. This would never be possible. Digital signatures are created with an entity's PRIVATE key, which no one but its owner should ever have access to.

3b. iRules similarly do not have access to the private keys stored on the device.

You can still digitally sign messages, but you'd have to use a pre-established key/key pair. Take a look at the wiki section on the CRYPTO:: commands.

3a. SSL Server Certs with public and private keys (CA or self signed) are stored on the F5. The F5 iRule has access to the public and private keys attached to the F5 VS and knowing the algorithm specified by the standard, one solution may be to use the CRYPT command to generate the digital signature using the SSL Cert private key. However, this is very time consuming to code. The F5 VS SSL private key would be used to sign the SOAP request.

This is not true. iRules do not have access to the certificates and private keys stored on the F5. To use the CRYPTO commands, you'd necessarily have to generate and/or pre-establish a private key. That said, I believe it would be possible to use a private key from a known certificate, but it'd be a manual process.

3b. The F5 has access to personal certs, i.e. stored in the browser, through session variables, and the X509 attributes, including the public key.

The F5 would have access to the complete client certificate, which includes the public key, if the client submitted it during an SSL handshake. But a digital signature requires a private key, which the client would NEVER provide.

Calvin, The CRYPTO command will not accomplish what you wish to do. They allow you to perform symmetric encryption with a shared key, but they provide no mechanism for public/private keys.

From what I can see, we do not have a native way to support what you want in iRules.

Lee

If by "RSA private public key pair", you're referring to PKI-based digital signing as the process by which a sender will create a hash of some piece of data, encrypt that hash with his PRIVATE key, and then send the data and the signed hash to the receiver, where the receiver creates another hash of that same data, decrypts the signed hash with the sender's PUBLIC key, and then compares the two hashes for the purposes of validating integrity (no data loss or tampering in transit) and non-repudiation (authentication by means of an assertion that the sender is who they claim to be by virtue of a private key possession), then I'd say the concepts you're referring to aren't all that complex.

Using PKI encryption (RSA private public key pair) for digital signatures, the signature is created by the sender with the private key, which the F5 or any other server has in its possession

This is completely and vehemently wrong. In no way would any entity other than the private key's owner, ever possess a copy of that private key. That would constitute compromised security, and would invalidate the private key (and its public peer).

You asked in your original request if an iRule could be used to digitally sign using either the PKI (person) cert associated with the session, or the SSL cert associated with the F5 VS, and the answer again is no, for the following reasons:

1. Certificates aren't used to digitally sign. A certificate is a component of the public key, and private keys are used to digitally sign data. The public key is then used to decrypt the data (hash) encrypted by the private key.

    

2. No entity other than the intended holder should ever have a copy of another entity's private key. There is no mechanism in the PKI protocol that exposes a sender's PKI private key to a receiver. That would be a bad thing.

    

3. As of the current 11.4.1 HF2 version of BIG-IP, there is no mechanism within iRules to access the certificates and private keys stored in the file system.

    

And as Lee states, the CRYPTO::sign command will in fact perform a type of digital signature, but it does so with symmetric shared keys, not PKI.

Thank you for the answer on CRYPT.

You left out a step. The public key is authenticated with the CA. Otherwise, all that has been verified is that the sender can generate a key pair, which anyone can do with keygen. And, one assumption is incorrect. As the cert is issued by the CA for the F5 VS, the F5 VS has both public and private keys as the subject of the cert. And the cert keys (person or non person certs) are used for signing & verification and other purposes.

You left out a step. The public key is authenticated with the CA. Otherwise, all that has been verified is that the sender can generate a key pair, which anyone can do with keygen.

I left that part out because it wasn't relevant to the question. The CA element is a function of the PKI model. From a purely cryptographic perspective, digital signatures provide authenticity and data integrity services. Trust is a separate, but important, piece of the puzzle. Plus, since it is the receiver that must do the work of validating both the trust of the sender's certificate and validity of its digitally signed message, the CA component has little bearing on what the BIG-IP can or cannot do in terms of message signing.

And, one assumption is incorrect. As the cert is issued by the CA for the F5 VS, the F5 VS has both public and private keys as the subject of the cert.

Not totally sure what you're saying here, but I'd probably disagree slightly. A certificate is an issued assertion of the identity of a subject, for which the public key is generally embedded. The private key is just a blob of data that cryptographically and mathematically "pairs" with the public key. The F5 VS has both public and private keys assigned in the client SSL profile, but the "subject of the cert" relates more to the certificate than anything else.

And the cert keys (person or non person certs) are used for signing & verification and other purposes.

I would agree.

Finally, I would like to retract one specific comment. The CRYPTO::sign command does provide a cryptographic signing function for data integrity, but it does not provide "digital signature" - a semantic that generally applies to PKI.

I would only add that this is not a current capability, not any specific technical limitation. The Access Policy Manager module actually does do PKI-based digital signatures for SAML requests and responses. Much of what BIG-IP can do today is the result of this forum and user requests. If digital signing is something you'd like to see in iRules, by all means please open a case and ask for it.

I'm looking to open a sideband connection and obtain an OAuth token to access Google APIs and I came across this thread.

The documentation (at https://developers.google.com/accounts/docs/OAuth2ServiceAccount) says I need to use my private key to create a signature of the request using "SHA256withRSA (also known as RSASSA-PKCS1-V1_5-SIGN with the SHA-256 hash function)".

For the sake of argument let's say my private key belongs to this iRule so the iRule certainly does and should have access to its private key. However I see no algorithm provided by CRYPTO to create an RSA digital signature. Based on this, sadly, I'm stumped and can't sign my assertion to send off to Google and get a JWT in return.

If you care my goal is for this to be a proxy for my in-house developers to access Google Maps Engine using a centrally managed Google "service" account that they don't have to know about.

I've had great success with a similar proxy setup to access other Google APIs that simply require a SHA1 MAC without having to expose the signing key to my devs.