Decrypting XML without an X.509 certificate in the message body

Products

• STARTER PACK-7
• CA Rapid App Security
• CA API Gateway

Issue/Introduction

Solution

Background

An XML message encrypted traditionally has a specified format and schema. Most importantly, an XML message contains the encrypted data in ciphertext as well as identifying information of the certificate used to encrypt the element. A message recipient may possess one or more private keys for encryption. As such, it might be necessary to specify which certificate was used for encryption to expedite processing of the message. Failing to do so might result in failed decryption or delays as a recipient attempts to decrypt a message with the incorrect key. XML encryption allows for the presence of identifying information such as serial numbers or an issuer DN. A combination of attributes can be used to uniquely identify a private key used to encrypt a particular message.

The Gateway currently requires that identifying information for the encrypting X.509 certificate be present in the request. A sample request may appear as follows (with the identifying elements emboldened):

<xenc:EncryptedData xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">

<xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>

<dsig:KeyInfo xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">

<xenc:EncryptedKey xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">

<xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>

<dsig:KeyInfo xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">

<dsig:X509Data>

<dsig:X509IssuerSerial>

<dsig:X509IssuerName>CN=server.domain.com</dsig:X509IssuerName>

<dsig:X509SerialNumber>14702280663861022428</dsig:X509SerialNumber>

</dsig:X509IssuerSerial>

</dsig:X509Data>

</dsig:KeyInfo>

<xenc:CipherData>

<xenc:CipherValue>ooRG0tUiHbAfnBpJrwsPo7//0wUjbztdTrhez3iFi6x4/CEJGcR7ypVH70R0ywcm2VFYNH3HMtFWvhm1VIJSSTIqLJjUUyI9RFzUF1rgAPLWJB0BS==</xenc:CipherValue>

</xenc:CipherData>

</xenc:EncryptedKey>

</dsig:KeyInfo>

<xenc:CipherData>

<xenc:CipherValue>zNKWvomrFAaA3ajy9g0RKds6sPN6MmNccWKO4bSiHMeyNomjnYc0+kkra9NP0=</xenc:CipherValue>

</xenc:CipherData>

</xenc:EncryptedData>

If this information is not present then the Gateway will not be able to decrypt the message without intervention from an operator responsible for administering or managing the service policy that is decrypting the message. The Gateway uses the information in this request to identify a private key stored in the?Manage Private Keys key store that can be used to decrypt the request. If the Gateway cannot identify a single specific key then the request will fail.

Presentation

If a request message does not contain the required information then the following error log or audit record may be generated, the Decrypt XML Element assertion will fail, and the request will fail as a result:
Unable to decrypt elements(s): EncryptedKey includes no KeyInfo element. Exception caught!?

This message indicates that one or more elements are missing from a particular required element. More specifically, the X.509 certificate information that is required to identify the decryption key is not present.

Resolution

Recomposing a message to contain the identifying information of the X.509 certificate would resolve this issue. If a client application cannot be modified to provide this information then the service policy published on the Gateway can be altered to inject the required elements using the certificate data of the expected private key. This workaround requires one or more prerequisites:

1. The private key used to decrypt the?message must be stored in the?Manage Private Keys key store.
2. The certificate used to encrypt the message must be stored in the?Manage Certificates trust store.
3. The certificate used to encrypt the message must be known in advance.

The third prerequisite is unique to this issue. The Gateway will automatically decrypt a message when instructed to do so if decrypting messages containing certificate information with known private keys. In this example, the identifying certificate is not present in the request so the author of the published service policy will need to adjust the policy to do the following:

1. Look up the encrypting certificate in the Manage Certificates trust store.
2. Build the required XML elements containing the certificate information.
3. Insert the previously built?XML elements into the appropriate part of the original request
4. Decrypt the message after changes are made.

An example is displayed below. The service policy displayed below is attached.

<Please see attached file for image>

The attached service policy may require additional changes to work. For example, the search parameters for the trusted certificate may be different or the format of the XPath used to identify the location to insert the new elements may vary. If there are any questions on how to implement this workaround into an existing published service policy then please open a new Support Case with Layer 7 Support. Please ensure that the desired trusted certificate as well as your existing service policy are provided when the case is opened.

Attachments:

• injectKeyInfo.xml

Environment

Release:
Component: APIGTW