Einschätzung der Anforderungen an „Strong customer authentication“ der EBA

„Final guidelines on the security of internet payments (EBA/GL/2014/12)“ aus Sicht unseres Produktportfolios

Dieser Beitrag enthält eine Gegenüberstellung der Anforderungen der European Banking Authority (EBA) an Strong Customer Authentication und der technischen Realisierungen in den Produkten „mIDentity Protection – Trusted Message Sign“ und „mIDentity Protection – Trusted Login mit OTP Berechnung“.

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 Es kommen die Faktoren Wissen (PIN) und Besitz (Gerätebindung an das mobiles Endgerät) zum Einsatz
  • mIDentity Protection – Trusted Login mit OTP Berechnung
    Es kommen die Faktoren Wissen (PIN) und Besitz (Geheimer Schlüssel für die OTP Berechnung und damit Bindung an das mobile Endgerät) zum Einsatz

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
    Die Zwei-Faktor Authentisierung geschieht (1) durch Nachweis der PIN und (2) durch Nachweis der Gerätebindung. Beide Merkmale werden unabhängig voneinander im SSMS verifiziert. Erst nach erfolgreicher Verifikation beider Merkmale wird der Signaturschlüssel freigeschaltet, der im nachgelagerten Schritt für die Payment Autorisierung mittels digitaler Signatur verwendet wird.
  • mIDentity Protection – Trusted Login mit OTP Berechnung
    Die Zwei-Faktor Authentisierung geschieht (1) durch Nachweis der PIN und (2) durch Nachweis des geheimen Schlüssels für die OTP-Berechnung und damit der Gerätebindung. Beide Merkmale werden während einer OTP Verifikation unabhängig voneinander im SSMS verifiziert. Dazu fließt auf Seiten des Client die PIN in die OTP-Berechnung ein. Eine Verifikation des OTP als Payment Autorisierung ist nur dann erfolgreich, wenn die PIN korrekt ist und der korrekte Schlüssel verwendet wurde. Umgekehrt führt eine falsche PIN oder ein falscher Schlüssel zu einem falschen OTP. Die Tatsache, dass der OTP falsch ist kann jedoch nur durch Verifikation im SSMS festgestellt werden.

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
    Die Merkmale für die Gerätebindung werden bei Erstbenutzung der Anwendung (Aktivierung) automatisch erhoben und an den SSMS übermittelt. Der Benutzer kann diese nicht beeinflussen und von daher auch nicht wiederverwenden oder reproduzieren. Das SDK verwendet Sicherheitsmaßnahmen um den unbemerkten Diebstahl dieser Merkmale zu verhindern. Die für die Payment Autorisierung erzeugte digitale Signatur ist eindeutig dem Payment Vorgang zuordenbar. Ein Wiederverwenden für die Autorisierung weiterer Vorgänge ist ausgeschlossen
  • mIDentity Protection – Trusted Login mit OTP Berechnung
    Der geheime Schlüssel für die OTP Berechnung wird bei Erstbenutzung der Anwendung (Aktivierung) vom SSMS erzeugt und dem Client übermittelt. Dabei ist die Eindeutigkeit des Schlüssels sichergestellt. Das SDK verwendet Sicherheitsmaßnahmen um den unbemerkten Diebstahl dieses Schlüssels zu verhindern. Das für die Payment Autorisierung erzeugte OTP kann nur einmal verwendet werden. Der SSMS lehnt bereits verwendete OTPs ab. Zusätzlich können Payment Daten in die OTP Berechnung einfließen. Ein solches OTP ist dann eindeutig dem Payment Vorgang zuordenbar. Ein Wiederverwenden für die Autorisierung weiterer Vorgänge ist ausgeschlossen.

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

  • Sowohl die PIN als auch die Merkmale zur Gerätebindung und der Schlüssel für die OTP Berechnung werden über einen dedizierten verschlüsselten und authentisierten Kanal ausgetauscht. Dieser Kanal durch Einsatz von Certificate-Pinning, URL-Whitelisten und eigenem SSL-Stack gegen Man-In-The-Middle und Man-In-The-Mobile Angriffe gesichert.

Dr. Erik Dahmen