Reuse of AES initialization vector in AESCipher / UsernamePasswordMako / Server

The Server class randomly generates a fixed 16-byte initialization vector (IV) for the purpose of encrypting data. Then, via the UsernamePasswordMako class, that fixed IV makes its way to the AESCipher class, where it is consistently reused for encrypting data.

Initialization vector reuse like this is a security concern, since it leaks information about the encrypted data to attackers, regardless of the encryption mode used. For example, if the IV is reused with the same key in AES-CTR mode, the attacker will very likely be able to entirely decrypt the encrypted data: https://crypto.stackexchange.com/questions/2991/why-must-iv-key-pairs-not-be-reused-in-ctr-mode

Instead of relying on a fixed, randomly-generated IV, it would be better to randomly-generate a new IV for every encryption operation. Here are a couple of links that have more information on why that is the preferred approach:

• https://defuse.ca/cbcmodeiv.htm
• https://crypto.stackexchange.com/questions/39615/best-way-to-generate-a-iv-for-aes-cbc-when-encrypting-files

[laserlemon]

@jkakavas 👋 Hello! I’m on the GitHub team responsible for sending security alerts for vulnerable versions of Python libraries. It appears that the issue described here (assigned CVE-2017-1000246) affects all versions as of its writing (<= 4.4.0). Since its writing, version 4.5.0 was released. Can you share whether version 4.5.0 fixes this issue?

As it stands now, we plan to alert pysaml2 users today on vulnerable versions <= 4.5.0 (all currently released versions), providing no remediation steps as no fixed version has yet been identified. Can you please confirm that this information is accurate? Thank you! 💛

[c00kiemon5ter]

The library we use to implement AESCipher is cryptography. I’ve looked into AES, the different modes and how they are supported. The recommended practice by cryptography is to use Fernet (spec).

Fernet guarantees that a message encrypted using it cannot be manipulated or read without the key. Fernet is an implementation of symmetric (also known as “secret key”) authenticated cryptography.

The interface is also very simple 👍Fernet provides generate_key, encrypt and decrypt. Behind the scenes:

Implementation

Fernet is built on top of a number of standard cryptographic primitives. Specifically it uses:

AES in CBC mode with a 128-bit key for encryption; using PKCS7 padding. HMAC using SHA256 for authentication. Initialization vectors are generated using os.urandom().

I think Fernet fills our use case and it is recommended practice. It does not use GCM or GCM-SIV (both of which are supported by cryptography, but introduce the authentication tag that needs to be kept available.)

I think I will go ahead and wrap Fernet to replace AESCipher.

---

Thank you everybody for your comments! After hearing your feedback, we decided not to send notifications to repos that currently use a version of pysaml2 that’s “vulnerable” to this specific issue. Please note though, should someone push a new requirements.txt that targets a vulnerable pysaml2 version, they will receive a notification at that time.

I think this is reasonable 👍 Thanks!

Yes, you can see the public repos that depend on pysaml here on your Dependency Graph page. We are not able to provide additional contact information for users of pysaml2.

That’s great, thanks for pointing us there - I did not know about the dependency graph.

Cheers :octocat: