Czym jest 3DS SDK? 3DS SDK to biblioteka programistyczna wbudowywana w natywną aplikację mobilną sprzedawcy, która realizuje uwierzytelnianie EMV 3-D Secure bez przekierowania do przeglądarki. Zbiera dane o urządzeniu, szyfruje je kluczem Directory Servera i renderuje ekran challenge wewnątrz aplikacji, gdy wydawca go zażąda.
Definicja kanoniczna: 3DS SDK to komponent oprogramowania integrowany z aplikacją mobilną 3DS Requestor, który w ramach protokołu EMV 3-D Secure zbiera i szyfruje informacje o urządzeniu oraz obsługuje interakcję challenge bez opuszczania aplikacji.
To najmłodszy z czterech komponentów EMV 3DS i jedyny, który działa na urządzeniu końcowego użytkownika. Ten artykuł wyjaśnia, na co pozwala 3DS SDK i jakie wymogi – aprobaty EMVCo oraz bezpieczeństwa PCI – liczą się dla jego dostawcy.
3DS SDK – w skrócie:
- 3DS SDK istnieje w dwóch wariantach specyfikacji EMVCo: Default-SDK (kompletna biblioteka) i Split-SDK (podzielona na część kliencką i serwerową), obie w wydaniu zgodnym z EMV 3DS 2.3.1.1.
- SDK zbiera dane o urządzeniu zgodnie z osobną specyfikacją EMV 3-D Secure SDK – Device Information (aktualna wersja danych 1.6) i szyfruje je kluczem publicznym Directory Servera, tak że dostęp do nich ma wyłącznie ACS.
- SDK nigdy nie pyta użytkownika o zgodę na dostęp do danych samodzielnie – musi zweryfikować zgodę i uprawnienia udzielone aplikacji 3DS Requestor, zgodnie z oznaczeniami z SDK Device Information.
- Produkt 3DS SDK przechodzi aprobatę EMVCo (testy Default-SDK lub Split-SDK w uznanym laboratorium), a jego bezpieczeństwo ocenia odrębny standard PCI 3DS SDK Security.
- SDK musi implementować mechanizmy integralności w czasie działania (run-time integrity) – to jeden z twardych wymogów bezpieczeństwa oceniany przez laboratorium.
- Patronusec jako akredytowany QSA wspiera dostawców komponentów 3DS w certyfikacji bezpieczeństwa środowiska i przygotowaniu do oceny.
Spis treści
Czym jest 3DS SDK i czym różni się od 3DS Servera?
3DS SDK to biblioteka po stronie urządzenia, wbudowana w aplikację mobilną sprzedawcy (3DS Requestor App), która realizuje kliencką część protokołu EMV 3DS: zbiera dane o urządzeniu i obsługuje challenge w aplikacji. 3DS Server działa po stronie serwera sprzedawcy i buduje komunikaty do sieci płatniczej – to dwa różne komponenty tego samego protokołu.
Podział ról jest czytelny, gdy prześledzi się przepływ. Aplikacja mobilna z 3DS SDK inicjuje transakcję: SDK zbiera informacje o urządzeniu, szyfruje je i przekazuje aplikacji w postaci parametrów żądania uwierzytelnienia. Aplikacja przesyła je własnym kanałem do 3DS Servera sprzedawcy, który dopiero buduje komunikat AReq i wysyła go do Directory Servera. Gdy wydawca zażąda challenge, SDK renderuje jego ekran wewnątrz aplikacji – bez przeskoku do przeglądarki, który psuł konwersję w protokole 3DS 1.0.
Historycznie na urządzeniu mobilnym uwierzytelnienie odbywało się przez otwarcie strony banku w przeglądarce (WebView). EMV 3DS zastąpił to natywnym SDK: biblioteka renderuje ekrany challenge z użyciem natywnych komponentów systemu, obsługuje powiadomienia push i biometrię banku, a użytkownik nie opuszcza aplikacji sprzedawcy.
3DS SDK jest jedynym komponentem protokołu EMV 3DS działającym na urządzeniu końcowego użytkownika – dlatego jako jedyny podlega odrębnemu standardowi bezpieczeństwa dedykowanemu oprogramowaniu na urządzeniach powszechnego użytku.
Na co pozwala 3DS SDK w praktyce?
3DS SDK realizuje trzy funkcje: zbiera i szyfruje dane o urządzeniu na potrzeby oceny ryzyka, umożliwia uwierzytelnienie natywne bez przekierowania do przeglądarki oraz renderuje interfejs challenge wewnątrz aplikacji. Efektem jest uwierzytelnienie płynne dla użytkownika i bogatsze w dane dla wydawcy.
Konkretne możliwości:
Zbieranie danych o urządzeniu
SDK gromadzi zestaw elementów zdefiniowany w specyfikacji EMV 3-D Secure SDK – Device Information: parametry systemu, konfigurację, identyfikatory dostępne w ramach uprawnień aplikacji. Bogaty zestaw danych zasila ocenę ryzyka po stronie ACS i zwiększa szansę na ścieżkę frictionless.
Szyfrowanie danych do ACS
SDK szyfruje zebrane informacje kluczem publicznym Directory Servera, tak że w drodze przez aplikację i 3DS Server pozostają nieczytelne – odszyfrować może je wyłącznie ACS. To chroni prywatność posiadacza karty w całym łańcuchu.
Obsługa challenge w aplikacji
Gdy ACS wymaga dodatkowego potwierdzenia, SDK renderuje ekran challenge natywnie: pole na kod jednorazowy, potwierdzenie biometryczne, uwierzytelnienie out-of-band przez aplikację banku. Po zakończeniu SDK samo chowa dialog i zwraca aplikacji wynik.
Wsparcie wariantu Split-SDK
Dla scenariuszy, w których część logiki SDK przenosi się na serwer, EMVCo definiuje Split-SDK – z osobnymi testami i rozszerzeniem komunikatu Device Acknowledgement, którym 3DS Server przekazuje dane Split-SDK do ACS.
Rozbudowany zestaw danych o urządzeniu zbierany przez 3DS SDK jest głównym powodem, dla którego uwierzytelnienie w aplikacji częściej kończy się ścieżką frictionless niż uwierzytelnienie w przeglądarce.
Ważne ograniczenie prywatnościowe: zgodnie ze specyfikacją SDK nigdy nie prosi użytkownika o zgodę na dostęp do wrażliwych danych w trakcie samego uwierzytelnienia. To aplikacja 3DS Requestor odpowiada za pozyskanie zgód i uprawnień oraz za wyraźne poinformowanie użytkownika o wykorzystaniu danych, zgodnie z regulacjami i politykami dostawców systemów operacyjnych.
Jakie wymogi EMVCo musi spełnić 3DS SDK?
3DS SDK musi przejść aprobatę EMVCo według procesu dla komponentów 3DS: testy zgodności w wariancie Default-SDK lub Split-SDK, wykonywane w laboratorium uznanym przez EMVCo, zakończone wpisem produktu na listę zatwierdzonych. Aprobata potwierdza zgodność z aktualną specyfikacją protokołu (2.3.1.1).
Kluczowe dokumenty referencyjne EMVCo dla dostawcy SDK:
- EMV 3-D Secure – SDK Specification (Default-SDK oraz Split-SDK) – definiuje informacje i wymogi dla rozwiązań aplikacyjnych,
- EMV 3-D Secure SDK – Device Information – specyfikuje format i reprezentację danych zbieranych przez SDK; aktualna wersja danych to 1.6, dostosowana do najnowszych API dostawców systemów operacyjnych,
- EMV 3-D Secure SDK Technical Guide – praktyczny przewodnik integracji SDK z aplikacją 3DS Requestor.
Ścieżka aprobaty produktu przebiega analogicznie do pozostałych komponentów 3DS: rejestracja w EMVCo, testy zgodności na uznanej platformie i w laboratorium, złożenie dokumentacji, przegląd wyników i publikacja na liście zatwierdzonych. Testy dla SDK obejmują zarówno warstwę funkcjonalną (poprawność przepływów, formaty danych), jak i wymagane mechanizmy bezpieczeństwa.
Rozróżnienie wariantów ma znaczenie architektoniczne. Default-SDK to kompletna biblioteka po stronie urządzenia. Split-SDK dzieli funkcje między klienta a serwer, co pozwala odchudzić część urządzeniową kosztem dodatkowej komunikacji – dostawca wybiera wariant zależnie od modelu integracji i wymagań wydajnościowych aplikacji.
Jakie wymogi bezpieczeństwa PCI liczą się dla 3DS SDK?
Bezpieczeństwo 3DS SDK ocenia odrębny standard PCI: PCI 3DS SDK Security Requirements and Assessment Procedures, oceniany przez wyspecjalizowane laboratorium (3DS SDK Lab). To osobna ścieżka od PCI 3DS Core Security Standard, który dotyczy środowisk ACS, DS i 3DS Server – SDK ma własny reżim, bo działa na urządzeniu poza kontrolą dostawcy.
Charakterystyczne wymogi bezpieczeństwa SDK (za dokumentacją i FAQ PCI SSC):
- Integralność w czasie działania (run-time integrity). SDK musi implementować mechanizmy wykrywające manipulację w trakcie działania – to jeden z twardych wymogów, którego wystarczalność ocenia laboratorium 3DS SDK.
- Ochrona zbieranych danych. Dane o urządzeniu muszą być szyfrowane kluczem publicznym Directory Servera, tak by pozostały nieczytalne dla aplikacji, 3DS Servera i całej ścieżki poza ACS.
- Rygor zgód i uprawnień. SDK nie inicjuje własnych próśb o zgodę użytkownika; weryfikuje zgody i uprawnienia udzielone aplikacji 3DS Requestor, zgodnie z oznaczeniami Permission ze specyfikacji Device Information.
- Odporność na środowisko urządzenia. SDK musi działać bezpiecznie także na urządzeniach, których stanu dostawca nie kontroluje – stąd nacisk na mechanizmy samoobrony biblioteki, a nie na zaufanie do systemu.
PCI 3DS SDK Security to jedyny standard PCI oceniający bezpieczeństwo komponentu płatniczego, który z założenia działa na urządzeniu poza kontrolą organizacji – dlatego koncentruje się na samoobronie kodu, a nie na kontrolach środowiskowych.
Patronusec Insight: Z naszego doświadczenia projektowego wynika, że dostawcy SDK najczęściej mylą dwie odrębne ścieżki oceny. Aprobata EMVCo potwierdza zgodność funkcjonalną z protokołem, natomiast PCI 3DS SDK Security ocenia odporność biblioteki na manipulację. To dwa różne laboratoria, dwa różne zestawy dowodów i dwa różne harmonogramy. Zanim zaplanujesz budżet certyfikacji SDK, rozdziel te ścieżki w projekcie – próba potraktowania ich jako jednej pozycji to najczęstsza przyczyna poślizgów.
Kto potrzebuje 3DS SDK i kto go dostarcza?
3DS SDK potrzebuje każda organizacja oferująca uwierzytelnianie EMV 3DS w natywnej aplikacji mobilnej: sprzedawcy z aplikacją zakupową, dostawcy portfeli cyfrowych, PSP integrujący płatności w aplikacjach klientów. Dostawcą SDK jest zwykle wyspecjalizowana firma technologiczna, dostawca 3DS Servera lub dostawca portfela.
Modele wykorzystania w praktyce:
- Sprzedawca z własną aplikacją wbudowuje gotowy, zatwierdzony 3DS SDK, aby uwierzytelniać płatności w aplikacji zamiast przekierowywać użytkownika do przeglądarki.
- Dostawca 3DS Servera oferuje SDK jako element pakietu: klient dostaje spójną parę biblioteki klienckiej i usługi serwerowej, co upraszcza integrację.
- Dostawca portfela cyfrowego lub super-aplikacji wbudowuje SDK, aby obsłużyć uwierzytelnienie kart dodanych do portfela w ramach jednego, natywnego doświadczenia.
Dla dostawcy budującego własny SDK to złożony produkt: wymaga aprobaty EMVCo, oceny PCI 3DS SDK Security oraz utrzymania zgodności z ewoluującą specyfikacją Device Information (kolejne wersje danych dostosowywane do zmian w systemach operacyjnych). To uzasadnia rynkową dominację wyspecjalizowanych dostawców – budowa i utrzymanie zgodnego SDK rzadko opłaca się pojedynczemu sprzedawcy.
Patronusec wspiera dostawców komponentów 3DS w ścieżce bezpieczeństwa środowiska w ramach usługi certyfikacji PCI 3DS – od wyznaczenia granic po przygotowanie do oceny.
Mit i fakt: co się myli w temacie 3DS SDK?
MIT: 3DS SDK to to samo co 3DS Server, tylko na telefon.
FAKT: 3DS SDK działa na urządzeniu użytkownika i zbiera dane oraz obsługuje challenge w aplikacji. 3DS Server działa po stronie serwera sprzedawcy i buduje komunikaty do sieci płatniczej. To dwa różne komponenty tego samego protokołu.
MIT: SDK sam prosi użytkownika o zgodę na dostęp do danych urządzenia.
FAKT: Zgodnie ze specyfikacją SDK nigdy nie inicjuje własnych próśb o zgodę podczas uwierzytelnienia. Za pozyskanie zgód i uprawnień oraz poinformowanie użytkownika odpowiada aplikacja 3DS Requestor.
MIT: Aprobata EMVCo wystarczy, żeby wdrożyć SDK produkcyjnie.
FAKT: Aprobata EMVCo potwierdza zgodność z protokołem, ale bezpieczeństwo SDK ocenia odrębny standard PCI 3DS SDK Security w wyspecjalizowanym laboratorium. To dwie osobne ścieżki.
MIT: Dane o urządzeniu zbierane przez SDK widzi sprzedawca.
FAKT: SDK szyfruje dane kluczem publicznym Directory Servera, tak że odszyfrować może je wyłącznie ACS. Sprzedawca i jego 3DS Server przekazują je w postaci zaszyfrowanej, nie mając do nich wglądu.
FAQ
Czym różni się Default-SDK od Split-SDK?
Default-SDK to kompletna biblioteka realizująca funkcje SDK po stronie urządzenia. Split-SDK dzieli te funkcje między część kliencką a serwerową, co pozwala odchudzić komponent urządzeniowy kosztem dodatkowej komunikacji. EMVCo definiuje osobne zestawy testów dla obu wariantów; wybór zależy od architektury i wymagań wydajnościowych aplikacji.
Czy każda aplikacja płatnicza potrzebuje 3DS SDK?
Nie – 3DS SDK jest potrzebny do natywnego uwierzytelniania EMV 3DS w aplikacji bez przekierowania do przeglądarki. Aplikacja korzystająca z uwierzytelnienia przeglądarkowego lub przekazująca płatność zewnętrznej bramce może działać bez własnego SDK. SDK ma sens tam, gdzie liczy się płynne, natywne doświadczenie w aplikacji.
Kto może odszyfrować dane o urządzeniu zebrane przez SDK?
Wyłącznie ACS wydawcy. SDK szyfruje dane kluczem publicznym Directory Servera, a klucze prywatne DS są zarządzane przez urząd certyfikacji sieci płatniczej. Aplikacja 3DS Requestor i 3DS Server przekazują dane w postaci zaszyfrowanej, nie mając do nich wglądu – to chroni prywatność posiadacza karty.
Czym jest run-time integrity w 3DS SDK?
To zestaw mechanizmów, którymi SDK wykrywa próby manipulacji własnym działaniem w czasie wykonywania na urządzeniu. PCI 3DS SDK Security wymaga ich implementacji, a wystarczalność konkretnego rozwiązania ocenia laboratorium 3DS SDK. To odpowiedź na fakt, że SDK działa poza kontrolowanym środowiskiem dostawcy.
Czy 3DS SDK podlega PCI 3DS Core Security Standard?
Nie bezpośrednio. Środowiska ACS, DS i 3DS Server podlegają PCI 3DS Core Security Standard, natomiast bezpieczeństwo samego SDK ocenia odrębny standard PCI 3DS SDK Security Requirements. To osobne dokumenty i osobne ścieżki oceny, dostosowane do różnej natury komponentów (środowisko serwerowe kontra biblioteka na urządzeniu).
Jaka jest aktualna wersja specyfikacji 3DS SDK?
Specyfikacje Default-SDK i Split-SDK są wydawane w linii zgodnej z EMV 3DS 2.3.1.1 (2023). Osobno rozwija się specyfikacja EMV 3-D Secure SDK – Device Information, której aktualna wersja danych to 1.6, dostosowana do najnowszych API dostawców systemów operacyjnych. Dostawca SDK utrzymuje zgodność z obiema liniami.
Jak Patronusec pomaga dostawcom komponentów 3DS?
Wspieramy ścieżkę bezpieczeństwa środowiska: wyznaczamy granice środowiska 3DE, prowadzimy analizę luk względem PCI 3DS i przygotowujemy organizację do oceny. Po bezpłatnej rozmowie scope-assessment przedstawiamy stałą wycenę dopasowaną do roli i zakresu. Dla samej certyfikacji produktu SDK wskazujemy właściwe laboratoria i pomagamy skoordynować obie ścieżki.
Warto przeczytać
Ścieżka lektury dla tematu uwierzytelniania w aplikacji:
- Czym jest 3D Secure (3DS) – role ACS, DS i 3DS Server – fundament: jak działa cały protokół i jego komponenty.
- MPoC, SPoC i CPoC – rewolucja w płatnościach mobilnych – inne standardy PCI dla oprogramowania na urządzeniach powszechnego użytku.
- PCI Secure Software Framework (SSF) – kluczowy standard dla bezpieczeństwa oprogramowania płatniczego – szerszy kontekst bezpieczeństwa oprogramowania płatniczego.
Bezpieczeństwo komponentów 3DS – bezpłatna konsultacja
Patronusec jako akredytowany QSA wspiera dostawców komponentów EMV 3DS w certyfikacji PCI 3DS. Jeśli budujesz lub wdrażasz 3DS SDK, umów bezpłatną rozmowę scope-assessment.
