EMV 3DS Issue: Decrypting ARes.acsSignedContent

Microsoft recently diagnosed and resolved a tricky issue in our 3DS SDK. I'm sharing the details here in case it helps other merchants and ACS providers.

Symptom

In an app-based EMVCo 3DS authentication flow, there is session key generation using ephemeral keys based on elliptic curve cryptography. Contents of the authentication message are then encrypted, including the ARes.acsSignedContent field. Microsoft encountered an issue with the public keys returned in the ARes.acsSignedContent field from some ACS providers, resulting in our 3DS SDK throwing an error. The Microsoft SDK then sends a 001 (ACS Signed content verification failure) or 100 (Unknown Failure) error code in the error message to the ACS.

Impact

Currently (January 2021) 40% of Microsoft EMV 3DS challenge attempts fail with an error. Approximately 1/5 of these errors are caused by this issue.

Root Cause

Microsoft’s 3DS SDK expects the signed bits from the ACS to return with a length of 32 bytes for each of the X and Y coordinates. We noticed that some ACS providers who use Java BigInteger.toByteArray() to format the X and Y coordinate are returning 33 bytes for the coordinates. The details of why 33 bytes are returned are explained in this Stack Overflow forum thread:

• ECC Key Pair Generation produces different sizes for the coordinates of EC public key point - Stack Overflow

The EMVCo 3DS specification does not specify or set a standard for how the X,Y coordinate array should be represented. It is therefore possible that a 3DS SDK and an ACS can process these coordinates differently, resulting in an error.

Fix

Microsoft has updated our 3DS SDK to handle EC public key coordinate sizes of both 32 and 33 bytes. Onward!