OGÓLNE PERSPEKTYWY MECHANIZMÓW PŁATNOŚCI

Chociaż omówiliśmy szereg mechanizmów płatności i powiązanych technologii, powinno być jasne, że nie ma oczywistego zwycięzcy. Być może nie powinniśmy oczekiwać, że będzie jakieś jedno rozwiązanie. Być może proces rozstania się z naszymi pieniędzmi jest na tyle wrażliwy, że zajmie nam trochę czasu, zanim bezwarunkowo ustalimy preferowaną drogę. Być może istnieje już satysfakcjonujące rozwiązanie – karta kredytowa – i wystarczy mieć pewność, że firmom internetowym można zaufać, że będą korzystać z jej danych w sposób rozsądny i bezpieczny. To przede wszystkim może być decydującym czynnikiem przy ostatecznym wyborze: wydajność rozwiązania technicznego będzie oceniana na podstawie otoczenia operacyjnego, a nie jego własnych zalet. W niedalekiej przeszłości kilka razy doszło do naruszeń bezpieczeństwa dotyczących danych kredytowych, które zostały naruszone z powodu ułomności i awarii procesu, a nie technologii. W zbyt wielu przypadkach dane kart kredytowych i konta były podatne na ataki hakerów po prostu z powodu złej konstrukcji lub działania systemu, a nie z powodu nieodłącznych słabości szyfrowania. Nie przepraszamy za kolejne ostrzeżenie przed tym. Jeśli poziom profesjonalizmu w tym obszarze nie ulegnie poprawie, to e-biznes odczuje znaczną komplikację, która będzie miała duży wpływ na przychody i zyski. Istnieje realna możliwość bankructwa niektórych firm.

INFRASTRUKTURA KLUCZU PUBLICZNEGO

\Można zauważyć, że większość opisanych powyżej mechanizmów płatności opiera się na istniejącej infrastrukturze klucza publicznego (PKI). To powoli staje się rzeczywistością, z pewnym naciskiem na „powoli”. Wystąpiły pewne problemy z interoperacyjnością ze starszymi systemami i istnieje prawdziwy problem z zapewnieniem, że certyfikaty cyfrowe mogą być szybko unieważnione, ale bez nadmiernej biurokracji z legalnymi użytkownikami. Istnieją również pewne obawy związane z trudnością ścinania tej technologii. Jednak postęp na wszystkich frontach jest osiągany i, ogólnie rzecz biorąc, branża zaczyna optymistycznie patrzeć na szerokie zastosowanie PKI w ciągu zaledwie kilku lat

SERWERY PŁATNOŚCI

Obecnie większość systemów płatności opiera się na pobieraniu danych karty kredytowej, chociaż większość zasad można przenieść na inne systemy. Bardzo proste podejście polega na tym, że akceptant po prostu zbiera dane dotyczące płatności we własnej bazie danych (miejmy nadzieję, w formie zaszyfrowanej) i przeprowadza negocjacje z agencją płatniczą, off-line, albo ponownie wprowadzając informacje, albo przez elektroniczny transfer danych. Bardziej zaawansowanym podejściem jest automatyczne przekazanie danych płatności do agencji autoryzującej niemal natychmiast. Wiąże się to z zapewnieniem bramki przetwarzania on-line lub bramki płatności, która przekazuje dane karty kredytowej i szczegóły płatności i przesyła je za pośrednictwem bezpiecznego łącza do banku. Zauważ, że jest to do banku handlowca („przejmującego”), który ustalił z handlowcem warunki, głównie dotyczące wielkości transakcji, która może być zaakceptowana bez sprawdzania. Systemy takie jak I/Net Merchant/400 [106] umożliwiają odpowiedź z centrum przetwarzania kart „zazwyczaj w ciągu jednej minuty”. Bank autoryzacyjny może również korzystać z takich bramek, aby przesłać do systemu sprzedawcy listę „gorących” kart lub inne dane zabezpieczające, które mogą być wykorzystywane przez procesy sprzedawcy do sprawdzania transakcji przed zaakceptowaniem zamówienia. Cały ten ruch danych musi przechodzić w bezpieczny sposób, albo bezpiecznymi liniami, albo coraz częściej przez Internet, przy użyciu protokołów bezpieczeństwa, takich jak SET. Niezależnie od wybranej metody, najbardziej podstawową decyzją architektoniczną, jaką należy podjąć, jest to, jak bezpośrednio dostawcy będą zaangażowani w projektowanie i wdrażanie usługi. Jedną z opcji jest wykupienie go od specjalistycznego dostawcy. Czasami może to być zintegrowane z projektem koszyka, który jest następnie instalowany na serwerze dostawcy. Alternatywnie, dostawcy mogą umieścić w swojej witrynie łącze internetowe, które prowadzi do serwera płatności obsługiwanego przez dostawcę usług płatniczych. Użycie tego linku dostarcza formularz klientowi do wypełnienia. Jest on następnie przesyłany w bezpiecznej formie do dostawcy usług płatniczych. W przypadku większych dostawców lub tych, którzy wymagają dodatkowej kontroli płatności, istnieje również możliwość zakupu oprogramowania, które działa na serwerze akceptanta i działa jako bezpieczny klient strony dostawcy usług płatniczych. Biorąc pod uwagę ciągłą niepewność co do ostatecznych „zwycięzców” w wyścigu o płatności elektroniczne, nie byłoby nienaturalne oczekiwać, że dostawcy serwerów płatności zabezpieczają swoje zakłady. Serwery i bramy płatności są projektowane do obsługi różnych opcji protokołów.

TELEFONY KOMÓRKOWE JAKO POJEMNIKI NA TOKEN

Łatwo zauważyć, że funkcjonalne elementy transakcji finansowej eCommerce mogą być realizowane w postaci nowoczesnego (np. GSM) telefonu komórkowego i powiązanej z nim infrastruktury sieciowej: kanał jest w miarę bezpieczny (o tym później), istnieje klawiatura i wyświetlacz, moc obliczeniowa i pamięć. Mniej oczywista jest personalizacja zapewniana przez moduł identyfikacji abonenta GSM (SIM) i względna łatwość, z jaką można dostarczyć załączniki, takie jak interfejsy kart inteligentnych. Każdy telefon GSM zawiera kartę SIM, która sama jest inteligentną kartą, która zawiera prawa dostępu i inne szczegóły dla użytkownika telefonu komórkowego. Zauważ, że jest on powiązany z użytkownikiem, a nie z telefonem. Użytkownicy mogą wyjąć kartę SIM i włożyć ją do innego telefonu, jeśli chcą. Dotychczas eksperymenty z wykorzystaniem telefonów komórkowych do usług bankowych przebiegały ostrożnie. Większość z nich polega po prostu na zapewnianiu sprawdzania salda, zamawianiu wyciągów i przeglądaniu ostatnich transakcji, a także wpłacaniu z góry określonych rachunków (np. do mediów), zasadniczo te same usługi, które są dozwolone dla klientów korzystających z bankowości przewodowej. Przeprowadzono jednak pewne próby, dzięki którym gotówka elektroniczna może zostać doładowana do karty płatniczej bankiera podłączonej do telefonu komórkowego. Dzwoni do banku wydającego, a klient za pomocą klawiatury telefonu wprowadza wymaganą kwotę i kod PIN. Informacje te są szyfrowane przez telefon za pomocą klucza prywatnego i przesyłane przez sieć do banku. Bank odszyfrowuje i weryfikuje żądanie, a następnie wysyła tokeny gotówkowe, które odejmuje z konta klienta. Poważnym problemem jest tutaj użycie dwóch inteligentnych chipów i rozmieszczenie aplikacji pomiędzy nimi. W co najmniej jednym z przeprowadzonych testów karta SIM telefonu komórkowego musiała zostać zmodyfikowana, aby móc obsłużyć proces dla konkretnego banku; włączenie tej samej usługi dla innego banku wymagałoby ponownej modyfikacji. Pojawia się tutaj dość poważna kwestia, która w pewnym sensie jest powtórzeniem problemu dotyczącego aplikacji zorientowanych na klienta i serwer. Czy większość aplikacji (bankowość, uzyskiwanie biletów itp.) znajduje się na karcie inteligentnej dostawcy aplikacji (banku, agencji biletowej), w telefonie komórkowym lub na serwerze? Karta SIM telefonu komórkowego może zapewnić bezpieczeństwo na poziomie transmisji, a także bezpieczeństwo aplikacji, a także stopień uwierzytelniania. Karta aplikacji zewnętrznej może zawierać uprawnienia użytkownika do funkcji aplikacji oraz informacje uwierzytelniające. W ten sposób SIM operatora komórkowego i inteligentna karta bankowa oferują zdublowaną funkcjonalność. Oznacza to, że konkurują oni (a raczej ich firmy wydające). Alternatywnie, czy lepiej byłoby zachować prawa i przywileje na serwerze aplikacji, używając jedynie inteligentnych chipów po stronie klienta dla bezpieczeństwa? Ale czyj serwer aplikacji? Operatora komórkowego czy banku? Są to kwestie, które można rozwiązać dopiero po zajęciu się kwestiami praktycznymi i polityką biznesową. Będzie to zależało między innymi od tego, czy eCash ma stać się ważnym i relatywnym znaczeniem interakcji z bankami w zakresie czystego przelewu konta w stosunku do zakupu eCash lub tokenów niepieniężnych. Pewną rolę odegrają kwestie networkingowe: załóżmy, że z góry kupujemy prawo do umieszczenia samochodu na parkingu. Po przybyciu musisz przedstawić to prawo do bezobsługowej bariery. Jeżeli szlaban jest podłączony do sieci rozległej, np. GSM, wtedy możliwe są różne strategie cienkie/grube, klient/serwer. Alternatywnie, jeśli terminal nie jest podłączony, musisz przekazać mu token, który posiadasz lokalnie i który może „zrozumieć” i usunąć z terminala. W ten sposób część aplikacji będzie w kliencie.

ELEKTRONICZNE POJEMNIKI NA ŻETON

Wcześniej wspomnieliśmy o portfelach elektronicznych jako mechanizmie przechowywania gotówki elektronicznej. Chociaż odnieśliśmy się do portfela rezydującego na PC, koncepcja ta może zostać rozszerzona znacznie dalej. Portfel może być kartą inteligentną, osobistym organizerem, a nawet telefonem komórkowym, a urządzenie może służyć do kredytowania, przelewu gotówki, a także kupowania i przechowywania niepieniężnych tokenów, takich jak bilety i inne zezwolenia. Zaleta korzystania z tych urządzeń jest oczywista – przenośność. Najprostszą formą portfela jest prawdopodobnie karta inteligentna, o której mówiliśmy już w części 3, Bezpieczeństwo. Karty mogą przechowywać klucze osobiste i inne stałe dane oraz mogą być doładowywane tymczasowymi tokenami, m.in. gotówka elektroniczna. Oprócz karty wymagane są prawdopodobnie trzy inne warunki wstępne: terminal do ładowania tokenów, terminal do ich wyciągania i prawdopodobnie jakiś sposób odczytywania zawartości, aby sprawdzić, czy wymagają uzupełnienia. Jednym z wczesnych przykładów jest karta ze zmagazynowaną wartością firmy Mondex. Składała się ona z inteligentnej karty wielkości karty kredytowej, która zawierała tokeny, małego czytnika, który przypinał się do karty i umożliwiał odczytanie zawartości (z ochroną hasłem), większego portfela wielkości kieszonkowego pamiętnika, który pozwalał na bardziej złożone odpytywanie i programowanie oraz różnorodne terminale załadunkowe i rozładunkowe. Ostatnia z nich obejmowała jednostki nablatowe specjalnego przeznaczenia do użytku przez sklepikarzy, które można było połączyć za pomocą telefonii dial-up lub usług pakietowych X25, w celu okresowego pobierania gotówki do banku sprzedawcy. W przypadku prób Mondex telefony korzystające z sygnalizacji CLASS (patrz strona 323) zostały również zmodyfikowane, aby zapewnić gniazdo na kartę, do którego była podłączona karta Mondex, i podobne modyfikacje były dostępne na wielu automatach telefonicznych. Karta Mondex to nie tylko urządzenie pamięci z szyfrowaniem; w rzeczywistości zawiera pojedynczy mikroprocesor i system operacyjny MULTOS, który pozwala na ładowanie wielu aplikacji, być może od różnych dostawców lub usługodawców. MONDEX jest również niezwykły, ponieważ tokeny są rzeczywiście gotówką, w tym sensie, że są potrącane bezpośrednio z konta bankowego właściciela jako wypłata gotówki. Następnie są anonimowymi „monetami”, które mogą przenosić się od kupującego do sprzedającego bez śladu audytu, a jeśli karta zostanie zgubiona, zostaną z nią utracone.

SZCZEGÓŁY PŁATNOŚCI SET

Przed operacją płatności SET należy najpierw podjąć szereg kroków: maszyna klienta (należąca do nabywcy) musi być wyposażona w portfel SET, który zawiera certyfikowany certyfikat posiadacza karty wydany przez organizację wydającą. Podobnie sprzedawca (kupiec) ma certyfikat cyfrowy i konto w banku przejmującym, który później rozliczy się z bankiem nabywcy.

1 Gdy nadejdzie czas na zapłatę, serwer akceptanta wysyła wiadomość do klienta dokonującego zakupu, zawierającą szczegóły towaru oraz żądanie do portfela SET klienta. Ta wiadomość została podpisana cyfrowo przy użyciu prywatnego klucza sprzedawcy.

2 Klient może sprawdzić, czy nie został naruszony, dekodując go za pomocą klucza publicznego sprzedawcy. W komunikacie zawarte są certyfikaty dla akceptanta oraz dla bramki płatniczej obsługiwanej przez bank przejmujący. Można je również sprawdzić pod kątem autentyczności, dekodując za pomocą kluczy publicznych.

3 Teraz kupujący tworzy zaszyfrowaną wiadomość opisującą szczegóły zamówienia i instrukcje płatności. Te dwie części są zakodowane osobno, dzięki czemu kupujący może ukryć przed sprzedawcą szczegóły płatności. Klient podpisuje wiadomość i wysyła ją do sprzedawcy.

4 Akceptant sprawdza autentyczność wiadomości, dekoduje szczegóły zamówienia i wysyła (wciąż zaszyfrowaną) dyspozycję płatniczą do bramki płatniczej.

5 Bramka weryfikuje to żądanie płatności, w tym autoryzację z banku wydającego klienta, a następnie wysyła do akceptanta token, który można wymienić na płatność z banku

SET – SECURE ELECTRONIC TRANSACTIONS

Dostawcy kart VISA i MasterCard zdefiniowali mechanizm pod nazwą Secure Electronic Transactions (SET), który dotyczy tych bardziej złożonych aspektów transakcji. Ma on stać się standardem otwartym, chociaż postęp w tym kierunku jest jak dotąd powolny. Opiera się na łańcuchu certyfikatów cyfrowych, które są dostarczane posiadaczom kart, sprzedawcom i agentom rozliczeniowym przez ich organizacje sponsorujące. Wydawanie certyfikatów cyfrowych wymaganych przez proces jest wysoce hierarchiczne i wymaga głównego urzędu certyfikacji SET najwyższego poziomu. Mechanizm jest konwencjonalną wersją opisanych wcześniej procesów bezpieczeństwa, w której dane wiadomości są szyfrowane za pomocą losowo wygenerowanego klucza, który jest następnie szyfrowany za pomocą klucza publicznego odbiorcy. Nazywa się to „cyfrową kopertą” wiadomości i jest wysyłane do odbiorcy wraz z zaszyfrowaną wiadomością. Odbiorca odszyfrowuje cyfrową kopertę za pomocą klucza prywatnego, a następnie używa klucza symetrycznego do odblokowania oryginalnej wiadomości. Użytkownicy SET skutecznie szyfrują dane swojej karty kredytowej w sposób, którego nie może odblokować sprzedawca, a jedynie centrum przetwarzania kart.

ELEKTRONICZNY PRZELEW SZCZEGÓŁÓW Z KART KREDYTOWYCH/DEBETOWYCH

Chociaż zamierzamy teraz omówić nowe metody przyjmowania płatności o wyższej wartości, musimy zdać sobie sprawę, że dzisiaj żadna z nich tak naprawdę nie wystartowała w porównaniu z prostym mechanizmem wpisywania danych karty kredytowej. Wiele osób wydaje się wierzyć, że wygoda w tym zakresie przewyższa poziom ryzyka. Oczywiście ankiety wskazują również na dużą liczbę osób, które nie robią zakupów on-line właśnie dlatego, że nie ufają systemowi. Jednym ze sposobów zmniejszenia ryzyka, że ​​ktoś wykradnie dane karty i wykorzysta je później do nieuczciwych zakupów, jest szyfrowanie transakcji kartą za pomocą, na przykład, metody Secure Sockets Layer (SSL). Zasady działania SSL dla transakcji finansowych są dość proste: serwer eCommerce wydaje maszynie klienta klucz publiczny, którego własność jest gwarantowana przez zaufaną stronę trzecią i którego klient używa do kodowania danych karty. To przynajmniej chroni więź między klientem a sprzedawcą; to, co dzieje się później, może być czymś innym. Dane karty klienta mogą zostać odszyfrowane przez sprzedawcę, a następnie wykorzystane według uznania sprzedawcy. Wystąpiło wiele przypadków, w których sprzedawcy przechowywali dane karty w niezaszyfrowanej formie w bazie danych, do której następnie włamano się. Zauważ również, że na kliencie spoczywa obowiązek podjęcia decyzji, czy zaufać autentyczności klucza sprzedawcy, czy też wywołać procedurę sprawdzającą ważność certyfikatu cyfrowego. Nie powinno być problemu z tym procesem, ale jest on podatny na ewentualne nadużycia. Niemniej jednak SSL jest dość szeroko stosowany jako środek ochrony transakcji, ponieważ jest wbudowany w przeglądarki internetowe jako standardowa i łatwa w użyciu funkcja. Jednym z problemów związanych ze wszystkimi proponowanymi alternatywami jest potrzeba pewnej formy tokena weryfikacyjnego (na przykład karty inteligentnej), którą można podłączyć do sieci. Zwykle wymagałoby to zakupu dodatkowego sprzętu, jeśli jest używane do zakupów w domu, i musiałby istnieć wcześniej ustalony standard jego podłączenia. Transakcje zakupowe wymagają oczywiście ochrony przed podstawowymi oszustwami, np. kradzieżą kodu PIN i jego ponownym wykorzystaniem. Ale są też inne rzeczy, które wymagają ochrony: sposób, w jaki wydajesz własne pieniądze, powinien być czymś, co możesz zrobić bez wiedzy innych. Z listy twoich transakcji konkurent może odgadnąć twoją strategię produktu; wiedza na temat twoich transakcji na akcjach może dać komuś możliwość wykorzystania informacji poufnych; stan Twojego zdrowia może być znany pracodawcy z zakupionego przez Ciebie leczenia; informacje o szczegółach zakupu mogą umożliwić popełnienie bardziej skomplikowanego oszustwa i tak dalej. Tak więc tylko te części transakcji, które są wymagane do jej realizacji, powinny zostać ujawnione osobie, z którą przeprowadzasz transakcję. Agencja kredytowa, która obsługuje kredyt, nie powinna koniecznie wiedzieć, co kupiłeś, ale po prostu wystarczającą ilość informacji, aby wiedzieć, że transakcja płatnicza jest ważna.

STANDARYZACJA MIKROPŁATNOŚCI W INTERNECIE

Jak donosi WWW.org, nie ma w pełni ustandaryzowanego podejścia do mikropłatności za towary lub usługi dostarczane w sieci. Niedawno wydali publiczny projekt [104], który próbuje określić wytyczne dla takiego podejścia. Celem jest przedstawienie opisu procesu obsługi łącza za opłatą, który ułatwi programistom oznaczanie stron internetowych w standardowy sposób i zapewni użytkownikom tych stron prosty mechanizm „kliknij, aby zapłacić”. Zasadę przedstawiono na rysunku.

Moduł obsługi łącza Per Fee znajduje się na komputerze klienckim użytkownika. Służy do komunikacji z serwerem sprzedawcy za pomocą protokołu HTTP. (Ściśle zalecany jest bezpieczny wariant SSL/HTTPS, omówimy to dalej w następnej sekcji.) Komunikaty, które przechodzą między klientem a serwerem, muszą być kompatybilne z istniejącymi przeglądarkami. W tych komunikatach określona jest liczba pól obowiązkowych, zalecanych i opcjonalnych. Obejmują one:

† Lokalizacja on-line strony sprzedawcy (obowiązkowe).

† Nazwa sprzedawcy (opcjonalnie).

† Odniesienie on-line do tego, co jest kupowane (obowiązkowe).

† (krótki) tekstowy opis tego, co jest kupowane (obowiązkowe).

† (długi) opis (zalecane).

† Obraz/opis graficzny (opcjonalnie).

† Cena (obowiązkowe).

† Trwałość w czasie witryny sprzedaży (zalecane).

(Istnieją inne, mniej oczywiste terminy. Więcej szczegółów można znaleźć na stronie.) Działania W3C zalecają sposoby osadzenia tych informacji w istniejących przeglądarkach HTML, przy użyciu prostego mechanizmu „wtyczek” lub jako apletu JAVA. (Zauważ, że ten drugi kurs nie jest zalecany dla HTML w wersji 4.0 i nowszych, gdzie preferowanym rozwiązaniem jest element OBJECT. Ponownie, zobacz pełny tekst, aby uzyskać szczegółowe informacje.) Omówiono również pojawiające się zastosowania XML. Grupa zarekomendowała również projekty, które jasno pokazują użytkownikom, że podążają za linkiem płatnym, na przykład wyświetlając tytuł linku w formularzu „Chcę to kupić”.

GOTÓWKA ELEKTRONICZNA

Większość transakcji finansowych obejmuje kwoty mniejsze niż kilka funtów; wiele z nich to nawet mniej niż funt. Każda taka transakcja, która wiąże się z obsługą przez bank, wiąże się z niedopuszczalną dopłatą. W taki sam sposób, w jaki nie wypisałbyś czeku na funta, a zamiast tego użyłbyś gotówki, zdalne płatności tego typu wymagają elektronicznej gotówki, a nie przelewu. Z „prawdziwymi” pieniędzmi nosisz ze sobą monety i banknoty, które wcześniej wypłaciłeś w ramach jednej transakcji ze swojego banku lub które zostały przekazane przez osobę trzecią. Podobnie, ładujesz elektroniczną gotówkę do elektronicznego portfela, na pewnym etapie przed wypłaceniem jej części, gdy coś kupisz. Jedną z najprostszych form eCash jest karta przedpłatowa, np. karta telefoniczna. Wczesne wersje były czysto mechaniczne: karta miała metalizowany pasek, który był stopniowo erodowany przez mechanizm automatu telefonicznego, co obniżało jej wartość za każdym razem, gdy była używana. Dziś karty mogą być bardziej wyrafinowane, ale zasada jest taka sama: klienci dokonują przedpłat na rzecz wystawcy karty lub pobierają środki ze swojego konta na karty. Raz w karcie pieniądze zachowują się jak gotówka – można je zgubić, a strata spada na posiadacza karty. Zasadniczo jest niemożliwy do wykrycia i można go wydać bez jakiejkolwiek strony trzeciej, w tym czyjegoś banku, który nic o tym nie wie. W rzeczywistości część dotycząca anonimowości jest kontrowersyjna; niektóre władze postrzegają to jako sposób na ułatwienie popełnienia przestępstwa, zapłaty za narkotyki lub innej działalności przestępczej. Pojawiły się pewne żądania, aby gotówka była mniej niż całkowicie anonimowa, a niektóre implementacje rzeczywiście etykietują tokeny gotówkowe za pomocą unikalnego odniesienia. Argumenty polityczne i społeczne dotyczące celowości lub braku tej anonimowości wykraczają poza zakres tej książki, ale oczywiście mają pewne znaczenie dla jej akceptowalności [102]. Jedną z różnic w stosunku do gotówki jest stopień zabezpieczenia. eCash jest zwykle przechowywany w portfelu elektronicznym w postaci zaszyfrowanej i wymaga od właściciela podania tajnego hasła w celu otwarcia portfela i dokonania wypłaty. Microsoft oferuje tego typu portfel elektroniczny w swoich nowszych przeglądarkach. Serwis Mondex [103] oferuje mały, przenośny portfel. Jednym z interesujących postępów jest uświadomienie sobie, że sama gotówka nie musi znajdować się w portfelu użytkownika, jeśli chcesz handlować tylko online, robi to tylko mechanizm odblokowujący. Możesz po prostu zakupić zapas „pieniędzy” na przedpłatę w postaci konta u sprzedawcy eCash i dokonywać płatności z tej gotówki, uwalniając ją z dowolnego terminala, używając hasła, które wprowadzasz jako zaszyfrowaną wiadomość.