Evaluation of EBA requirements towards “Strong customer authentication“

Final guidelines on the security of internet payments (EBA/GL/2014/12)” from our product portfolio’s point of view

The article compares the requirements stipulated by the European Banking Authority (EBA) towards Strong Customer Authentication and technical implementations in the products “mIDentity Protection – Trusted Message Sign“ and “mIDentity Protection – Trusted Login plus OTP calculation“.

Requirement: Strong customer authentication is, for the purpose of these guidelines, a procedure based on the use of two or more of the following elements – categorised as knowledge, ownership and inherence: i) something only the user knows, e.g. static password, code, personal identification number; ii) something only the user possesses, e.g. token, smart card, mobile phone; iii) something the user is, e.g. biometric characteristic, such as a fingerprint.

  • mIDentity Protection – Trusted Message Sign
    Deployed are the factors of knowledge (PIN) and ownership (device-linkage to mobile terminal equipment)
  • mIDentity Protection – Trusted Login plus OTP
    calculation Deployed are the factors of knowledge (PIN) and ownership (proprietary key for OTP calculation and thus linkage to mobile terminal devices)

Requirement: In addition, the elements selected must be mutually independent, i.e. the breach of one does not compromise the other(s).

  • mIDentity Protection – Trusted Message Sign
    Two-factor authentication is realized (1) by PIN verification and (2) by verifying the device- linkage. Both of these features are verified independently in the SSMS. Once both features have been verified successfully, the signature key used to authorize payments by digital signatures in a subsequent step is enabled.
  • mIDentity Protection – Trusted Login plus OTP calculation
    Two-factor authentication is realized (1) by PIN verification and (2) by verifying the proprietary key for OTP calculation and thus linkage to specific devices. Both features are independently verified in the SSMS in the course OTP verification. For this purpose, the PIN is integrated with OTP calculation by the Client. The successful verification of the OTP as payment authorization requires the correct PIN as well as the use of the correct key. Likewise, the wrong PIN or wrong key will result in an incorrect OTP. However, the determination of an incorrect OTP will generally require verification in the SSMS.

Requirement: At least one of the elements should be non-reusable and non-replicable (except for inherence), and not capable of being surreptitiously stolen via the internet.

  • mIDentity Protection – Trusted Message Sign
    The features required for device-linkage will be automatically acquired when the application is first used (activated) and transmitted to the SSMS. Users have no influence on this process and can thus neither re-use nor reproduce it. The SDK deploys safety precautions to prevent any unidentified theft of the respective features. The digital signature generated for payment authorization can clearly be allocated to the respective payment transaction. Any repeated use for the purpose of authorizing additional transactions is excluded.
  • mIDentity Protection – Trusted Login plus OTP calculation
    The SSMS generates the proprietary key for OTP calculation when the application is first used (activated) and is then transmitted to the Client. The key’s uniqueness is guaranteed. The SDK deploys safety precautions to prevent any unidentified theft of this key. The OTP generated to authorize payments can only be used one single time. The SSMS will reject OTPs already used. Additionally, payment data can be considered for the OTP calculation. Respective OTPs can be clearly be allocated to individual payment transactions. Any repeated use for the purpose of authorizing additional transactions is excluded.

Requirement: The strong authentication procedure should be designed in such a way as to protect the confidentiality of the authentication data.

  • The PIN as well as the features related to device-linkage and the key required for OTP calculation are communicated via a dedicated encrypted and authenticated channel. Certificate-pinning, URL white lists and an individual SSL-stack serve to protect the respective channel against Man-In-The-Middle and Man-In-The-Mobile attacks.

Dr. Erik Dahmen