Apple Pay vs Google Pay
Z jakiej metody uiszczania płatności za pomocą sprzętu mobilnego warto korzystać? Nie zamierzam Wam pisać poradnika. Wyboru zresztą już dokonaliście, wszak macie jakiś sprzęt. Albo wybraliście Androida, albo Apple. Alternatywy tak naprawdę nie ma. Chcąc zatem korzystać ze zbliżeniowych płatności mobilnych, korzystacie albo z Apple Pay, albo z Google Pay. Musicie oczywiście również posiadać wystawioną przez Wasz bank kartę płatniczą (nie ma znaczenia czy debetową, czy kredytową) i powiązać ją z urządzeniem mobilnym i daną usługą (Apple Pay lub Google Pay). Od strony użytkownika realizacja płatności na obu platformach fintechowych stworzonych przez potentatów branży technologicznej wygląda podobnie. Widzimy cenę, przykładamy urządzenie do terminala, interfejs NFC przesyła dane i voilà! Odbieramy zakupiony produkt/usługę.
Ten artykuł pochodzi z archiwalnego iMagazine 10/2022
Ale w jaki sposób tak naprawdę działają obie usługi? Ani Apple, ani Google nie pobierają od użytkowników żadnej kwoty za transakcję. Na czym zatem obie firmy zarabiają? Gromadzą dane o naszych transakcjach, powiecie. Otóż niekoniecznie, a przynajmniej niekoniecznie w przypadku Apple, bo w przypadku Google są powody, by podejrzewać, że wyszukiwarkowy potentat ma wiedzę na temat absolutnie każdej transakcji, którą realizujesz za pomocą Google Pay.
Chcąc skorzystać z Apple Pay lub Google Pay, zawsze zaczynamy z tego samego poziomu. Mamy kartę płatniczą i chcemy ją powiązać z naszym urządzeniem mobilnym i właściwą dla danego urządzenia usługą płatności zbliżeniowych. Dodanie danych karty wygląda podobnie, zarówno na Androidzie, jak i na iPhonie, ale potem zaczynają się różnice. Istotne.
Apple Pay
Co się dzieje, jak dodajesz swoją kartę do Portfela w iPhone? Najpierw dane karty płatniczej (tzw. PAN – Primary Account Number) wraz z Twoimi danymi wiążącymi tożsamość ze środkiem płatniczym są wysyłane przez aplikację Portfel na serwery Apple Pay. Na podstawie tych danych Apple rozpoznaje bank – wystawcę karty, a następnie przekazuje pakiet PAN + tożsamość do tegoż banku, prosząc jednocześnie o token płatności. Bank musi współpracować z Apple Pay, jeżeli dany bank nie oferuje usługi przesyłania tokenów płatności do Apple, na tym nasza przygoda się kończy. Nie dodamy karty do Portfela Apple.
Jeżeli jednak bank współpracuje z Apple Pay, to kontaktuje się (oczywiście wszystko odbywa się automatycznie) z TSP (dostawca tokenów płatności – Token Service Provider). TSP generuje token płatności, wiąże go z siecią płatności PAN i przekazuje bankowi wraz ze specjalnym kluczem publicznym (Payment Token Key). Bank – wystawca karty po otrzymaniu tokena płatności i klucza z TSP dodaje własny klucz publiczny (CVV key) i całą taką paczkę danych odsyła na serwery Apple Pay.
Apple Pay umieszcza token płatności, klucz tokena i klucz publiczny banku – wystawcy karty w kryptograficznym chipie (w architekturze bezpieczeństwa płatności ten element jest nazywany po prostu Secure Element) wbudowanym w Twojego iPhone’a. Taki zbiór danych przechowywanych na bezpiecznym chipie w urządzeniu Apple nazywa DAN (Device Account Number). W przypadku Google Pay analogiczny twór nazywany jest „wirtualną kartą płatniczą”. Na obu platformach (Apple Pay i Google Pay) zobaczymy tylko cztery ostatnie cyfry tej „karty” czy też DAN. Z tym że smartfon z Androidem, a przynajmniej nie każdy, nie ma bezpiecznego chipu Secure Element. Chcąc zatem zapewnić usługi Google Pay na każdym urządzeniu z Androidem, Google musiało rozwiązać ten problem. I to zrobiło. Secure Element można wdrożyć na kilka sposobów: m.in. jako fizyczny chip wewnątrz urządzenia (tak zrobiło Apple), ale również jako chronioną usługę w chmurze (metoda wybrana przez Google). Od strony użytkownika działa to prawie identycznie. Np. w obu platformach można realizować płatności za pośrednictwem NFC, również gdy urządzenie (smartfon) nie jest w ogóle online. Jednak w przypadku Google Pay mamy ograniczenie liczby transakcji (wiedzieliście o tym?). Otrzymałem informacje od jednego z banków, że za pomocą Google Pay mogę przeprowadzić offline nie więcej niż 25 transakcji. W przypadku Apple Pay takiego ograniczenia nie ma, bo dzięki obecności fizycznego chipu kryptograficznego w smartfonie nie ma ryzyka, że DAN może zostać zmanipulowany. Oczywiście DAN jest unikalny dla każdego urządzenia Apple. Ta sama karta płatnicza dodana do innego iPhone’a czy Apple Watcha będzie mieć w usłudze Apple Pay inny numer DAN, bo inne jest fizycznie urządzenie.
W momencie, gdy dana usługa – Apple Pay lub Google Pay – ma już wygenerowany token płatności (czyli DAN w przypadku Apple lub wirtualną kartę w przypadku Google Pay), możemy realizować płatności zbliżeniowe. Co jednak dzieje się, gdy zbliżysz Androida lub iPhone’a do terminalu POS w sklepie? Najpierw musisz odblokować urządzenie i uwierzytelnić się (biometrią, kodem PIN etc.). Dane biometryczne odczytane przez iPhone’a czy Androida w ogóle nie trafiają do terminala, służą jedynie jako przełącznik odblokowujący transmisję danych. Na te dane składa się dynamiczny kryptogram (zaszyfrowany kluczem publicznym dostawcy usług tokenów – TSP) zbudowany m.in. z kwoty transakcji, licznika transakcji, klucza publicznego dostarczanego przez TSP oraz oczywiście tokena płatności zapisanego w danym urządzeniu mobilnym. Dodatkowo generowany jest dynamiczny, jednorazowy CVV (co chroni przed atakami typu Man-in-the-middle). W przypadku Apple za stworzenie paczki danych odpowiada bezpieczny chip, w Androidzie taka paczka danych (zgodna ze standardami płatności zbliżeniowych EMVCo) jest… po prostu wygenerowana (chipu bezpiecznego tu nie ma). Jednak nie znaczy to, że posiadacze Androida nie są chronieni. Zaraz to wyjaśnię.
Informacje zebrane w procesie komunikacji NFC przez terminal POS są przesyłane do sieci płatniczej, która natychmiast rozpoznaje, że przesłane dane nie są numerem fizycznej karty płatniczej, lecz mobilnym tokenem płatności. Token z dynamicznym kryptogramem jest przekazywany do TSP (dostawcy usług tokenów). TSP jako wyłączny posiadacz klucza prywatnego deszyfruje zaszyfrowany dynamiczny kryptogram (weryfikując jego prawidłowość) i odnajduje numer PAN w skarbcu tokenów, przekazując rzeczywisty numer karty do sieci płatności. Ta, gdy otrzyma PAN, przekazuje go do banku – wystawcy karty z dynamicznym, jednorazowym CVV. Transakcja jest autoryzowana i dochodzi do skutku. Skąd bank – wystawca karty „wie”, że transakcja jest prawidłowa? Bo odszyfrowuje dynamiczny CVV za pomocą własnego klucza prywatnego (który tylko bank posiada). Bank sprawdza saldo klienta i autoryzuje transakcję. Ta dochodzi do skutku, a pieniądze trafiają do banku sprzedawcy towaru/usługi. Wszystko to odbywa się w ciągu zaledwie kilku sekund.
Google Pay
No dobrze, ale właściwie w jaki sposób chronieni są właściciele Androida? W przypadku Apple dane zabezpiecza wbudowany na stałe w każde urządzenie (każdego iPhone’a) chip kryptograficzny. A jak jest w Google Pay? Jak wspomniałem, Google zdecydowało się na chmurową implementację „bezpiecznego elementu” (Secure Element). Od strony technicznej to jak najbardziej wykonalne, ale w internecie pojawiły się informacje sugerujące, że przez to Google Pay jest mniej bezpieczny od Apple Pay czy że Google wie o każdej Twojej transakcji, podczas gdy Apple – niekoniecznie. To nie do końca tak. Jak mogliście się zorientować, cała wymiana danych w procesie płatności zbliżeniowych realizowanych z wykorzystaniem platform Apple Pay i Google Pay korzysta z architektury kryptografii z kluczem publicznym. Oznacza to, że nad integralnością zaszyfrowanych danych wymienianych pomiędzy urządzeniem mobilnym, terminalem, bankiem wystawcą czy siecią płatności czuwa architektura kryptografii z kluczem publicznym (zmiana choćby jednego bitu w szyfrogramie zaszyfrowanym kluczem publicznym spowoduje, że próba jego odszyfrowania kluczem prywatnym z pary kluczy będzie nieudana). Niemniej platforma Google Pay pozbawiona bezpiecznego chipu na każdym fizycznym urządzeniu zdolnym do komunikacji NFC wymusza komunikację z serwerami Google nie tylko do utworzenia „wirtualnej karty” podczas dodawania fizycznej karty do Portfela Google, ale również podczas absolutnie każdej transakcji! Oczywiście w przypadku, gdy nie ma łączności online, dane i tak są wymieniane z terminalem POS, ale później muszą być zsynchronizowane, stąd ograniczenie liczby transakcji, jakie za pomocą Google Pay można przeprowadzić offline. W przypadku Apple Pay nie ma potrzeby łączenia się z serwerami Apple podczas każdej transakcji, bo wszystkie niezbędne dane wrażliwe konieczne do jej realizacji przechowywane są wyłącznie w chipie kryptograficznym wewnątrz urządzenia.
Rozwiązanie Apple jest w tym przypadku bardziej eleganckie, bo jesteśmy pewni, że Apple nic nie wie na temat naszych transakcji, czego o Google nie sposób powiedzieć na pewno.
