publicKeyFingerprint SHA1 vs SHA256

[patrick7kelly]

We recently went live with Issuer-Initiated Digitization for MDES.

The implementation wasn't flawless though. One issue that came up - it seems like MC is expecting publicKeyFingerprint to be the SHA1 fingerprint of the certificate. However, the FieldLevelEncryptionConfig.__compute_fingerprint method only returns the SHA256 fingerprint.

In the "MDES Issuer Implementation Guide" (dated 5/12/2021) on page 101, the example payload shows a SHA1 fingerprint in publicKeyFingerprint.

I'm happy to submit a PR for this but wondering if any maintainers have feedback.

[jaaufauvre]

Hi @patrick7kelly, thanks for having opened this issue.

Until now, publicKeyFingerprint has always been a SHA-256 digest: https://developer.mastercard.com/platform/documentation/security-and-authentication/securing-sensitive-data-using-payload-encryption/#publickeyfingerprint

SHA-256 is also the value displayed in the Mastercard Developers dashboard: https://developer.mastercard.com/platform/documentation/security-and-authentication/securing-sensitive-data-using-payload-encryption/#getting-keys-for-your-application

Can you confirm SHA-256 values are rejected and you had to replace the SHA- 256 value with a SHA-1 value you compute yourself?

SHA-1 has been on the way out for years. For that reason, I'm not sure about updating our set of libraries to compute SHA-1 fingerprints (even if in this case it's for key identification, not for digital signature purposes).

An option with the current version of this package is to put already computed (SHA-1) fingerprint values in configuration. see: encryptionCertificateFingerprint and encryptionKeyFingerprint. Is it what you used?

Thanks!

[patrick7kelly]

Hi @jaaufauvre,

Yes, MDES was rejecting the payload entirely when publicKeyFingerprint had the SHA-256 fingerprint, and would consistently return a "CRYPTOGRAPHY_ERROR". API Support advised us that we needed to use the SHA-1 fingerprint instead, and the payloads were accepted once we started hardcoding that value.

We can technically work around this using something like the code below:

from Crypto.Hash import SHA1
from client_encryption.field_level_encryption import encrypt_payload
from client_encryption.field_level_encryption_config import FieldLevelEncryptionConfig

encryption_config = FieldLevelEncryptionConfig('/path/to/config.json')
encryption_config._encryption_certificate_fingerprint = SHA1.new(encryption_config._encryption_certificate).hexdigest()

encrypted_data = encrypt_payload(<payload>, encryption_config)

My main concern is that I doubt we are alone. Anyone trying to use this library out-of-the-box for Issuer-Initiated Digitization would face similar issues. And once they realize the issue, the only workarounds involve overwriting the fingerprint generated by the libraries.

It might make sense to add something like oaepPaddingDigestAlgorithm but for the fingerprint hash. That would make it easy to support both SHA-1 and SHA-256 for now, and any other algorithms that may be supported down the road.

[jaaufauvre]

Hi,

We double-checked with the Pre-Digitalization team and prefer not to introduce a new piece of configuration here. The "client-encryption" packages already allow to use a custom (SHA1) fingerprint value in configuration, and SHA1 fingerprints should be replaced with SHA-256 fingerprints in the future.

Best regards,