How to encrypt element with 3DES by (Non-SOAP) Encrypt XML Element Assertion and how the recipient decrypt the payload

book

Article ID: 205593

calendar_today

Updated On:

Products

CA API Gateway API SECURITY CA API Gateway Precision API Monitoring Module for API Gateway (Layer 7) CA API Gateway Enterprise Service Manager (Layer 7) STARTER PACK-7 CA Microgateway

Issue/Introduction

How to encrypt element with 3DES by (Non-SOAP) Encrypt XML Element Assertion?

How the assertion works and what are in the encrypted payload?

How the recipient decrypt the payload if it's not gateway?

Environment

Release : 9.2

Component : API GATEWAY

Resolution

A sample policy tripledes-cbc.xml is attached.

When test it, the recipient certificate of the (Non-SOAP) Encrypt XML Element Assertion needs to be replaced by the certificate from real recipient.

A sample output of the encrypted payload,

<xenc:EncryptedData xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
   <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc" />
   <dsig:KeyInfo xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
      <xenc:EncryptedKey>
         <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p" />
         <dsig:KeyInfo>
            <dsig:X509Data>
               <dsig:X509IssuerSerial>
                  <dsig:X509IssuerName>CN=apimgw10mark.sgn.broadcom.net</dsig:X509IssuerName>
                  <dsig:X509SerialNumber>17954182631641905354</dsig:X509SerialNumber>
               </dsig:X509IssuerSerial>
            </dsig:X509Data>
         </dsig:KeyInfo>
         <xenc:CipherData>
            <xenc:CipherValue>UOfFaQG2QponnFbF+l3nnU0FyYkoLt4SnjtEO0RkH9tQYt+S6iKjhtK5oZuNfvTo7HQwiUlbMOahpTWJf23nFlMQ8iEAYrNpGRmG4kDjgJ+XBgdUJCiaEYCewCz9vxZl0l+YEkyiVSXcPrfCQ2VMUvLUBiwMD+3eHaAC6twXWA3+SeIL2FJGMywJmewAtNTbmC1wXVipIpmrNq2btmigjnLotgYno2+XrTAlTvtVPHgsjc23vgpp0QQ03+Y/9jJDwKrEpxG2GjqMk2lKUkrJDbbfM+Doxt0tTC44xlCOdb7gPCCay75MADkENXDljOCMoJ251fEWlsVwLNhjeDVKNw==</xenc:CipherValue>
         </xenc:CipherData>
      </xenc:EncryptedKey>
   </dsig:KeyInfo>
   <xenc:CipherData>
      <xenc:CipherValue>ijPQZ8l9b75UE0EdniadMe3tdWZqB5A2kL1rDFKpqnY=</xenc:CipherValue>
   </xenc:CipherData>
</xenc:EncryptedData>

 

The assertion works like this,

The 3des is symmetric encryption, the gateway should generate a random symmetric key to encrypt the message, then the recipient certificate specified in the assertion will be used to encrypt the symmetric key.

-- the xpath of the encrypted data,
/xenc:EncryptedData/xenc:CipherData/xenc:CipherValue
-- the xpath of the encrypted symmetric key,
/xenc:EncryptedData/dsig:KeyInfo/xenc:EncryptedKey/xenc:CipherData/xenc:CipherValue

All the <xenc:CipherValue> is base64 encoded.

Then the recipient can extract the symmetric key using its private key and then decrypt the message using this symmetric key.
if the recipient is gateway, it's much easier to decrypt the payload by "(Non-SOAP) Decrypt XML Element" assertion

 

Another sample policy tripledes-cbc-decript-by-asym-sym-asertions.xml shows how to use asym/sym tactical assertion to decrypt the payload

NOTE:

1. need to install those tactical assertions to run the demo;

2. just to explain how the payload is generated, on gateway, the "(Non-SOAP) Decrypt XML Element" assertion should be used to decrypt the payload

Attachments

1608678828489__tripledes-cbc-decript-by-asym-sym-asertions.xml get_app
1608677365467__tripledes-cbc.xml get_app