Silne uwierzytelnianie klienta w finalnym RTS – koniec z SMS’ami?

Komisja Europejska po kilku zmianach wydała w listopadzie stworzony przez European Banking Association standard technologiczny (RTS), dotyczący silnego uwierzytelniania w ramach nowej unijnej dyrektywy PSD2. Zgodnie z finalną wersją RTS, w docelowej architekturze rozwiązania, spełniającego wymogi dyrektywy, musi się zmienić kilka istotnych szczegółów.

Jedna z kluczowych zmian w RTS (opisana w Artykule 32.) wprowadza zakaz przekierowań na stronę banku w celu realizacji silnego uwierzytelniania. To oznacza, że standard OAuth2 w swojej czystej postaci nie będzie używany przez banki. Standard PolishAPI będzie zatem wymagał zmiany w tej kwestii. Konsekwencją wprowadzenia tego wymagania będzie w praktyce zakończenie ery potwierdzania płatności przez SMS’y.

Dyrektywa PSD2 w Artykule 97. nakłada obowiązek stosowania silnego uwierzytelniania klienta (SCA – Strong Customer Authentication) przez dostawcę usług płatniczych. Zasadniczo obowiązek ten obejmuje każdorazowy dostęp do konta. RTS’y wprowadzają kilka możliwych przypadków zwolnienia ze stosowania tego obowiązku, ale każdy klient banku będzie musiał się przyzwyczaić do spełniania tej procedury.

Dyrektywa silne uwierzytelnianie zdefiniuje jako uwierzytelnianie w oparciu zastosowanie co najmniej dwóch z trzech elementów: wiedza (coś, co wiem), posiadanie (coś, co mam), cecha klienta (coś, czym jestem).

Wymagania do silnego uwierzytelniania definiuje zarówno oficjalna Dyrektywa PSD2, jak i dokument Regulacyjnego Standardu Technicznego (RTS), który stanowi (na mocy Artykułu 98. dyrektywy) standard techniczny dotyczący uwierzytelniania i komunikacji. Wymagania te są opisane min. w artykułach: 6., 7., 8. i 9. finalnego dokumentu RTS.

Poza wymaganiami do silnego uwierzytelniania dla dalszych rozważań warto jeszcze wyróżnić wymagania dotyczące dynamicznego wiązania, które są opisane w artykule 5. RTS. Aktualnie, usługa płatności przy wykorzystaniu zdalnego kanału, jakim jest bankowość internetowa, wiąże się z wprowadzeniem kodu potwierdzającego przelew. Kod zazwyczaj jest nam wysyłany przez bank za pośrednictwem wiadomości SMS, która zawiera również informacje na temat kwoty oraz odbiorcy płatności.

Tak realizowany proces wykorzystuje kanał SMS w dwóch aspektach. Pierwszym jest element uwierzytelniania typu „posiadanie”. Na nasz telefon wysyłany jest SMS zawierający kod, który wprowadzamy do naszej usługi bankowości internetowej. Drugi aspekt wiadomości SMS to realizacja wymagań, dotyczących dynamicznego wiązania. W tym aspekcie SMS zawiera informacje na temat kwoty oraz beneficjenta przelewu.

Pierwszy aspekt użycia SMS jest zgodny z wymaganiami RTS’a. Artykuł 7 nakłada wymaganie dotyczące wdrożenia zabezpieczeń wobec nieautoryzowanego użycia oraz replikacji elementu „posiadanie”. Nieautoryzowane użycie można zabezpieczyć proceduralnie (np.: blokowanie numeru telefonu w banku na żądanie klienta), a replikacja wymaga klonowania karty SIM – które są jednak dobrze zabezpieczone na taką ewentualność już od wielu lat.

Drugi aspekt użycia, czyli „dynamiczne wiązanie” jest jednak bardzo wątpliwy. SMS nie spełnia wymagań Artykułu 5. punktu 2. Standardowy SMS nie zapewnia informacjom w nim przesłanym ani poufności, ani integralności. Wymagania dotyczące dynamicznego wiązania można było teoretycznie zrealizować poprzez drugi kanał, czyli stronę bankowości internetowej (który dodatkowo realizuje uwierzytelnianie typu „wiedza”). Czy jednak w związku z zakazem przekierowań na stronę banku kanał ten będzie wciąż wykorzystywany w tym celu?

Opisana sytuacja postawiła przed bankami nowe wyzwania. Będą musiały znaleźć sposoby na spełnienie wymagań zapisanych w dyrektywie i RTS w kontekście silnego uwierzytelniania i dynamicznego wiązania. Kolejnym wyzwaniem będzie przemyślenie strategii i przyszłości swoich dotychczasowych zdalnych kanałów kontaktu z klientem.

Pośród wielu wymagań, którym będą musiały stawić czoła banki w Unii Europejskiej, dochodzi jeszcze konieczność zastosowania w komunikacji z różnymi dostawcami usług (TPP, AISP, PISP) standardów wydanych przez międzynarodowe lub europejskie organizacje standaryzujące. W APILOGIC oparliśmy się na OAuth2 z profilami UMA, OpenID Connect oraz standardami FIDO. Dzięki realizacji silnego uwierzytelniania (dwa czynniki uwierzytelniające) oraz bezpiecznego „dynamicznego wiązania” w jednym urządzeniu wszystkie wymagania dyrektywy oraz RTS zostały spełnione.

Tym samym nasz produkt spełnia wymagania zarówno silnego uwierzytelniania, jak i dynamicznego wiązania, opisanych w RTS.

 Czytaj więcej:  GDPR/ RODO: jak to się ma do PSD2? 5 najważniejszych zmian w prawie i ich konsekwencje dla banków

W świetle wchodzących w życie regulacji, największym dla banków wymaganiem jest konieczność zrewidowania strategii biznesowej. Kiedy spojrzymy na dzisiejszy rynek usług nie możemy nie zauważyć, że lekkość i zwinność wygrywają dzisiaj na polu walki o klienta. Niektóre banki już to wiedzą. Otwierają nowe podmioty gospodarcze oraz uzupełniają swoje API o dodatkowe funkcjonalności, nie tylko te związane z PSD2.

Czy będą w stanie nawiązać rywalizację z fintech’ami w kontekście obsługi i akwizycji klienta? Jedna kwestia stawia je z góry na przegranej pozycji. Są to zobowiązania wobec prawodawców, z KNF i Rekomendacją D czy RODO na czele. Obwarowania prawne tego typu nie obowiązują żadnej firmy z branży fintech.

 Czytaj więcej:  Uwierzytelnianie biometryczne, standardy FIDO i bezpieczeństwo naszych pieniędzy