1

I have problem with decryption of the received authentication response SAML message. My app is connected with two IdP's of different types. Frist is ForgeRocks, OpenAM and second Microsoft's ADFS server. Both IdPs were provided with same service provider metadata document that contains same certificate public keys for encyrption and signing.

Case 01 IdP : OpenAM, ForgeRock Result : Process properly decryption and response.

Case 02 IdP : ADFS 2.0, Microsoft Result : Failed decryption with error : CryptographicException, Bad Data.

Is it possible that encryption on IdP side is different for the same asymetric key pair ? Or I am getting something wrong ?

As I see there are differences in EncryptedAssertion xml node. EncryptionMethod Algorithms are different.

Here are key nodes.

OpenAM, ForgeRock

<saml:EncryptedAssertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
<xenc:EncryptedData xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
                    Type="http://www.w3.org/2001/04/xmlenc#Element"
                        >
  <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"
                         xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
                               />
  <ds:KeyInfo xmlns:ds="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"
                             xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
                                       />
      <xenc:CipherData xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
        <xenc:CipherValue xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
        </xenc:CipherValue>
      </xenc:CipherData>
    </xenc:EncryptedKey>
  </ds:KeyInfo>
  <xenc:CipherData xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
    <xenc:CipherValue xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
    </xenc:CipherValue>
  </xenc:CipherData>
</xenc:EncryptedData>

ADFS 2.0, Microsoft

<EncryptedAssertion xmlns="urn:oasis:names:tc:SAML:2.0:assertion">
<xenc:EncryptedData Type="http://www.w3.org/2001/04/xmlenc#Element"
                    xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
                        >
  <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc" />
  <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
    <e:EncryptedKey xmlns:e="http://www.w3.org/2001/04/xmlenc#">
      <e:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p">
        <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
      </e:EncryptionMethod>
      <KeyInfo>
        <ds:X509Data xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
          <ds:X509IssuerSerial>
            <ds:X509IssuerName>CN=certName</ds:X509IssuerName>
            <ds:X509SerialNumber>-18xxxxxx</ds:X509SerialNumber>
          </ds:X509IssuerSerial>
        </ds:X509Data>
      </KeyInfo>
      <e:CipherData>
        <e:CipherValue></e:CipherValue>
      </e:CipherData>
    </e:EncryptedKey>
  </KeyInfo>
  <xenc:CipherData>
    <xenc:CipherValue></xenc:CipherValue>
  </xenc:CipherData>
</xenc:EncryptedData>

As I see there are differences on used encryption methods. Also in second case there is certificate's alias name and serial number. Also serial number has negative value (maybe because I am using self signed certificate).

Thanks,

Rastko
  • 890
  • 1
  • 17
  • 32
  • Normally the key of a certificate does not describe the algorithm; that's part of the protocol. I'm pretty sure a negative value for a serial number of a certificate indicates a bug in the certificate generation software (forgetting to pad an ASN.1 INTEGER - which is signed - with a `00` byte). Note that I'm not a SAML expert. – Maarten Bodewes Jun 26 '14 at 15:16
  • I have converted negative decimal value from message and got serial number in hexadecimal value that is appropriate, so I think that this is not the issue. – Rastko Jun 26 '14 at 15:29
  • No, I don't think it is directly related with the issue either, but it *is* probably a bug regardless. I don't know how you decrypt though, MS is using AES 256 (which could lead to problems on Java platforms without unlimited crypto) and OAEP, which is a newer, safer method of encryption. – Maarten Bodewes Jun 26 '14 at 15:48
  • It is not clear what your SP software is. Since the SP does the decryption I suppose you should check first if it implements decryption correctly. Also, if the SP is a Java application then you should make sure that the "Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files for JDK/JRE" is installed on your JVM. – Peter Major Jun 27 '14 at 10:31

1 Answers1

0

You have this exception as in corresponding xml nodes there are no data to decrypt that's the reason:

<e:CipherData>
<e:CipherValue>No data!!!</e:CipherValue>
</e:CipherData>
</e:EncryptedKey>
</KeyInfo>
<xenc:CipherData>
<xenc:CipherValue>No data!!!</xenc:CipherValue>
</xenc:CipherData>

Example how it should be:

<EncryptedAssertion xmlns="urn:oasis:names:tc:SAML:2.0:assertion">
  <xenc:EncryptedData Type="http://www.w3.org/2001/04/xmlenc#Element"
        xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
        >
      <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc" />
      <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
   <e:EncryptedKey xmlns:e="http://www.w3.org/2001/04/xmlenc#">
       <e:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p">
    <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
       </e:EncryptionMethod>
       <KeyInfo>
    <ds:X509Data xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <ds:X509IssuerSerial>
     <ds:X509IssuerName>CN=name, O=Name, S=CA, C=us</ds:X509IssuerName>
     <ds:X509SerialNumber>0</ds:X509SerialNumber>
        </ds:X509IssuerSerial>
    </ds:X509Data>
       </KeyInfo>
       <e:CipherData>
    <e:CipherValue>qSMgmgpO0+1vhdt5wvyhNT+uh3BhmOlFD4IiWTPoj2N90nOUzwEoEkWCuGzHDizxq6rvc5eoikjgcbz5TYFlIX+eizyxcJQFl02t...  SOME VALUES HERE=</e:CipherValue>
       </e:CipherData>
   </e:EncryptedKey>
      </KeyInfo>
      <xenc:CipherData>
   <xenc:CipherValue>RSCxYAMJ7RaD+MtEcnmE9EwLmvDJgTsXx5MOKJYUJiAmQWziSLNolZQYt5xgUPHJaD+co/PoWwifWuobHdClFwBBMR/lAqWAHIQldP+ro ...  SOME VALUES HERE=</xenc:CipherValue>
      </xenc:CipherData>
  </xenc:EncryptedData>
     </EncryptedAssertion>
 
Nick Prusov
  • 146
  • 7