Encrpyted Assertions with Shibbolet AES-GCM encryption

[Dominik]

Hi,

we are using SimpleSAMLphp in v1.19.3 with Edugain. Most idP's are currently working, but some - I believe these are Shibbolet idP's - are sending encrypted assertions.

I tried different settings and changed the key from DER format to PEM format to get this working and the errors in the logs vary:

Failed to decrypt symmetric key: Unexpected key size (3072bits) for encryption algorithm: 'http://www.w3.org/2009/xmlenc11#aes128-gcm'#0

Failed to decrypt symmetric key: Failure decrypting Data (openssl private) - error:0407109F:rsa routines:RSA_padding_check_PKCS1_type_2:pkcs decoding error

Failed to decrypt symmetric key: Failure decrypting Data (openssl private) - error:04065072:rsa routines:rsa_ossl_private_decrypt:padding check failed

Failed to decrypt symmetric key: Failure decrypting Data (openssl private) - error:0909006C:PEM routines:get_name:no start line

The shared key cannot be decrypted. The idP ist sending the following XML which includes the correct certificate of the SP:

https://gist.github.com/dkrebs/91213b32cdd29f2862c85764dc5a7ec4

Any help is appreciated.

Thanks,

Dominik

[Tim van Dijen]

Hi Dominik,

I believe this should work out of the box..  There are two possibilities:

1.  You have negotiated a shared key with the IDP and you have configured ` sharedkey` and ` sharedkey_algorithm` accordingly

2.  You haven't negotiated anything. In this case the IDP would use your public key to encrypt the data. I think this is the case because you mention 'The idP is sending the following XML which includes the correct certificate of the SP'

If my assumption is right and we're dealing with scenario 2, this means you have to configure your SP authsource with your private key, so SSP knows how to decrypt the message.

You probably only have to configure 'privatekey' in your authsources.php

- Tim

Op dinsdag 17 mei 2022 om 13:02:31 UTC+2 schreef domini...@gmail.com:

[Dominik]

Hi Tim,

Thanks for your feedback on this. You're right, we are dealing with scenario 2 - public / private key. The private key is configured in authsources.php and it can actually be read by openssl_get_privatekey:

                    case 'private':
                    $this->key = openssl_get_privatekey($this->key, $this->passphrase);
$e = new \Exception();
file_put_contents('/tmp/debug.log',$key.PHP_EOL.$e->getTraceAsString().PHP_EOL.print_r($this->cryptParams,true).PHP_EOL.($this->key).PHP_EOL,FILE_APPEND);

-----BEGIN RSA PRIVATE KEY-----

[... omitted key ...]

-----END RSA PRIVATE KEY-----

#0 /var/www/html/simplesamlphp/modules/saml/lib/Message.php(352): RobRichards\XMLSecLibs\XMLSecurityKey->loadKey('-----BEGIN RSA ...')
#1 /var/www/html/simplesamlphp/modules/saml/lib/Message.php(420): SimpleSAML\Module\saml\Message::getDecryptionKeys(Object(SimpleSAML\Configuration), Object(SimpleSAML\Configuration), NULL)
#2 /var/www/html/simplesamlphp/modules/saml/lib/Message.php(694): SimpleSAML\Module\saml\Message::decryptAssertion(Object(SimpleSAML\Configuration), Object(SimpleSAML\Configuration), Object(SAML2\EncryptedAssertion))
#3 /var/www/html/simplesamlphp/modules/saml/lib/Message.php(662): SimpleSAML\Module\saml\Message::processAssertion(Object(SimpleSAML\Configuration), Object(SimpleSAML\Configuration), Object(SAML2\Response), Object(SAML2\EncryptedAssertion), true)
#4 /var/www/html/simplesamlphp/modules/saml/www/sp/saml2-acs.php(141): SimpleSAML\Module\saml\Message::processResponse(Object(SimpleSAML\Configuration), Object(SimpleSAML\Configuration), Object(SAML2\Response))
#5 /var/www/html/simplesamlphp/lib/SimpleSAML/Module.php(266): require('/var/www/html/w...')
#6 /var/www/html/simplesamlphp/www/module.php(10): SimpleSAML\Module::process()
#7 {main}

Array
(
    [library] => openssl
    [padding] => 1
    [method] => http://www.w3.org/2001/04/xmlenc#rsa-1_5
    [type] => private
)

Resource id #16

However, decyrpting the symmetric key fails with, seemingly random, either the first or second error, while using the same "Resource id #16" as $key (see above) in

    private function decryptPrivate($data)
    {
        if (! openssl_private_decrypt($data, $decrypted, $this->key, $this->cryptParams['padding'])) {

May 19 07:33:38 simplesamlphp ERROR [c6f4174210] Failed to decrypt symmetric key: Failure decrypting Data (openssl private) - error:04065072:rsa routines:rsa_ossl_private_decrypt:padding check failed

May 19 07:16:23 simplesamlphp ERROR [c6f4174210] Failed to decrypt symmetric key: Failure decrypting Data (openssl private) - error:0909006C:PEM routines:get_name:no start line

... while both keys configured in simplesamlphp, the private and public key, do match - and the public key is exactly the same passed in the xml, as the one below:

openssl x509 -noout -modulus -in cert.pem | openssl md5

(stdin)= 8ff3bd7e2436d6b5d8d31300380ac84f

openssl rsa -noout -modulus -in key.pem | openssl md5

(stdin)= 8ff3bd7e2436d6b5d8d31300380ac84f

Any idea?

Thank you! Best Regards,

Dominik

[Tim van Dijen]

Hi Dominik!

I think I've seen this once before and it had to do with DOS/Unix-style newlines in the PEM-files..

However, I also notice in your error messages that the PEM-header starts with 'BEGIN RSA ...' meaning your key-file is password protected.

Have you also configured 'privatekey_pass' in the authsource-file?

- Tim

Op donderdag 19 mei 2022 om 09:50:37 UTC+2 schreef domini...@gmail.com:

[Dominik]

Hi Tim,

Thanks for the quick reply and the hint with the line endings. I tried back and forth with dos2unix and unix2dos, but the error message stays the same. The key is not password-protected, it can be read without password. I was trying different formats of the key (pem, der), that's why the header is different, but none of them work and the error messages are same as above. I also tried to change permissions, so that only www-data is allowed to read. No success.

Thev key itself cannot be wrong. I tried encrypting / decrypting with a minimal example in PHP and it works. But I still cannot decode the data sent by the server.

So, I suppose the error comes from the server software (I think it's Shibboleth). I'm going to ask for the specific version.

Thanks for your help!

Best Regards,

Dominik

[Dominik]

Hi Tim,

just for the reference, we did not solve the certificate issue, but got this workig by disabling encrpyted assertions on the idP-side (Shibbolet 4.4.1) just for our SP:

        <bean id="ExampleSP" parent="RelyingPartyByName" c:relyingPartyIds="https://example.com/simplesaml/module.php/saml/sp/metadata.php/default-sp">
            <property name="profileConfigurations">
                <list>
                    <bean parent="SAML2.SSO" p:encryptAssertions="false" />
                </list>
            </property>
        </bean>

Thanks for your help.

Best Regards,

Dominik

[Peter Brand]

* Dominik <domini...@gmail.com> [2022-05-20 11:30]:

> just for the reference, we did not solve the certificate issue, but got
> this workig by disabling encrpyted assertions on the idP-side (Shibbolet
> 4.4.1) just for our SP:

That's a very bad idea. The Shibboleth IDP certainly does require you
to disable this (I'm using AES GCM with several SAML SPs) and neither
should SimpleSAMLphp (though I personally haven't verified this, not
running a real prod IDP with SimpleSAMLhp).
Something in your deployment is off, it seems, and disabling
end-to-end encryption is not the proper way to deal with that.

Your solution is akin to turning off TLS because your browser is
complaining about the certificate when connecting to your ebanking web
interface (or whatever) via HTTPS.

-peter

[Peter Brand]

* Peter Brand <peter...@univie.ac.at> [2022-05-20 12:02]:

> * Dominik <domini...@gmail.com> [2022-05-20 11:30]:
> > just for the reference, we did not solve the certificate issue, but got
> > this workig by disabling encrpyted assertions on the idP-side (Shibbolet
> > 4.4.1) just for our SP:
>
> That's a very bad idea. The Shibboleth IDP certainly does require you
> to disable this

Sorry, "does NOT require you to do this", of course.

-peter

[Dominik]

Hi Peter,

Thanks for the feedback! I understand what you are saying. However, of around 10 idP's only 2 are actually sending Encrypted Asssertions by default. The others send unencrypted assertions by default anyway. To follow your argumentation we should rather ask the other 8 idP's to encrypt the assertions ;-)

Taking your example with HTTPs into account: even the unencrypted assertions are encrpyted by HTTPS and are not transmitted in plain text over the net.

> That's a very bad idea. The Shibboleth IDP certainly does require you
> to disable this

I'm actually not sure what is requiring us to do this. That's why I created this post in the mailing list. Do you have a solution?

Best Regards,

Dominik

[Peter Brand]

* Dominik <domini...@gmail.com> [2022-05-20 12:17]:

> The others send unencrypted assertions by default anyway. To follow
> your argumentation we should rather ask the other 8 idP's to encrypt
> the assertions ;-)

FWIW, I currently manage the SAML Metadata for ~150 SAML entities
(half of which are IDPs and half SPs) and all of these support
encrypted SAML Reponses/Assertions.
I.e., we actually require our community members to support end-to-end
encryption.

> Taking your example with HTTPs into account: even the unencrypted
> assertions are encrpyted by HTTPS and are not transmitted in plain
> text over the net.

No, but (assuming SAML WebSSO as the profile) both TLS tunnels
(between the browser and the SAML IDP, and again between the browser
and the SAML SP) terminate at the subject's web browser, arguably the
most insecure link in the chain.
But malware at the computer used to log in isn't the only problem here
(as such malware would possibly also have access to the credentials
used to log in to the IDP and anything else) as any software flaw with
regards to web browser TLS or network-based MITM/etc attack or
botch/break-in/error in a CA your browser trusts would completely void
the only security you're left with, very likely without you even
noticing it.

Also and probably more practically relevant, end-to-end encrypting the
SAML/XML prevents whole classes of possible exploits that are simply
not possible when the XML is unreadable to anyone except the intended
recipient (i.e., the SAML SP owning the private key with which to
decrypt the SAML Assertion or Reponse): No entity references tricks, no
XML wrapping attacks.

> Do you have a solution?

I don't claim to sufficiently understand the reason for your specific
error message (or the code involved) to fix your problem. Maybe open
an issue for that in github where you can provide any details required
to get to the bottom of this.
I'm merely saying that disabling encryption is not the proper way to
fix interop issues between Shibboleth and SimpleSAMLphp, which have
been interoperating properly for 1.5 decades now, AFAIR.

-peter