eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plPrawoGrupypl.soc.prawoPłatność kartą powyżej (...)złRe: Płatność kartą powyżej (...)zł
  • Path: news-archive.icm.edu.pl!news.icm.edu.pl!not-for-mail
    From: Robert Jaroszuk <z...@n...iq.pl>
    Newsgroups: pl.soc.prawo
    Subject: Re: Płatność kartą powyżej (...)zł
    Date: Wed, 28 Jul 2010 10:09:15 +0200
    Organization: Dzial Sieciowy ICM, Uniwersytet Warszawski
    Lines: 98
    Message-ID: <i2oojd$lgs$1@news.net.icm.edu.pl>
    References: <i2hs56$b9l$1@inews.gazeta.pl> <i2jc9b$gbi$1@polsl.pl>
    <i2jfue$3bt$1@news.net.icm.edu.pl> <mrc3o.339191$NW.9244@hurricane>
    <i2jku9$89d$1@node2.news.atman.pl> <i2jmjq$lue$1@news.onet.pl>
    <4c4d93a1$1@news.home.net.pl> <p...@r...org>
    <i2k6es$619$2@news.onet.pl> <s...@p...org>
    <i2kcue$nlt$1@news.onet.pl> <i2m3a3$mnp$1@news.onet.pl>
    <p...@r...org> <i2m854$59n$1@news.onet.pl>
    <i2n8ds$t19$2@news.net.icm.edu.pl>
    <p...@l...org.pl>
    <i2ngih$eg3$1@news.net.icm.edu.pl> <p...@r...org>
    NNTP-Posting-Host: apn-95-40-196-152.dynamic.gprs.plus.pl
    Mime-Version: 1.0
    Content-Type: text/plain; charset=ISO-8859-2
    Content-Transfer-Encoding: 8bit
    X-Trace: news.net.icm.edu.pl 1280304558 22044 95.40.196.152 (28 Jul 2010 08:09:18
    GMT)
    X-Complaints-To: u...@n...net.icm.edu.pl
    NNTP-Posting-Date: Wed, 28 Jul 2010 08:09:18 +0000 (UTC)
    User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.11) Gecko/20100713 ""
    In-Reply-To: <p...@r...org>
    Xref: news-archive.icm.edu.pl pl.soc.prawo:647725
    [ ukryj nagłówki ]

    On 07/28/2010 09:07 AM, Olgierd wrote:
    > Dnia Tue, 27 Jul 2010 22:46:09 +0200, Robert Jaroszuk napisał(a):
    >
    > Co do zasady: troszkę w tym jednak ploty (którą sam rozpowszechniałem...)
    > -- "liability shift" dotyczy sprzedawców, którzy nie wdrożyli czip-
    > terminali (http://www.chipandpin.co.uk/business/card_payments/
    means/
    > shift_liability.html); natomiast co do odpowiedzialności za transakcje to
    > w ustawie EIP jest to dość dokładnie rozpisane.

    Nie wiem o jakich plotkach mówisz, ale jeśli chodzi o resztę, to masz w
    zupełności rację.

    >> W przypadku transakcji offline, weryfikacja PIN odbywa się poprzez
    >> komunikację z kartą, a nie z centrum autoryzacyjnym. Tego typu
    >> architektura z założenia będzie mniej bezpieczna niż transakcje
    >> online'owe, ponieważ nie ma "trzeciej strony", która autoryzuje
    >> transakcje. Myślę że nie muszę się specjalnie gimnastykować żeby
    >> udowodnić że jest to mniej bezpieczne, prawda?
    >
    > Jednak "dawca" karty i techniki tam zaszytej też ma coś tu do powiedzenia
    > (i stracenia?).
    > Z drugiej strony transakcję online można podsłuchać. Nie mam pojęcia
    > (nietechniczny jestem) czy w ramach autoryzacji "idzie" PIN i jak to jest
    > szyfrowane, ale ryzyko zawsze istnieje.


    Technika zaszyta w karcie musi być kompatybilna z resztą świata, tak
    więc issuer nie ma tutaj zbyt szerokich możliwości "poprawiania" EMV.
    Jeśli o to Tobie chodziło :-)

    Jeśli chodzi o komunikację np. terminali POS z hostem autoryzacyjnym,
    najczęściej używa się ISO8583. Są różne wersje, bo protokół ewoluował
    przez szereg lat. Jednakże zasada jest taka, że cały pakiet informacji o
    karcie nie jest zaszyfrowany, z wyjątkiem PINBlock, który szyfruje się
    kluczem transmisyjnym, który z kolei szyfrowany jest tzw. kluczem TMK
    (Terminal Master Key).
    W bankomatach zasada jest ta sama, tyle że częściej używa się protokołu NDC.

    Tak więc podsłuchanie transakcji nie daje Tobie możliwości podsłuchania PIN.

    Inną sprawą jest to, że obecnie operatorzy sieci bankomatów czy POSów są
    zobowiązani przez VISA/MC do certyfikacji PCI-DSS.
    Dlatego modernizuje się infrastrukturę płatniczą i dodaje urządzenia
    szyfrujące cały ruch pomiędzy bankomatem a hostem.
    Tak więc w wielu przypadkach podsłuchiwanie nic Tobie nie da, bo cała
    transakcja lata wewnątrz tuneli VPN czy transmisji SSL.

    Ale to są zabezpieczenia na warstwie transmisyjnej a nie na warstwie
    protokołu EMV.

    >> Są przez to podatne na różnego rodzaju ataki typu Man-in-the-middle, czy
    >> nawet na klonowanie i przeprogramowanie, przez co stają się tzw. 'yes
    >> card'. Po prostu sklonowana karta zawsze odpowiada twierdząco na
    >> zapytanie o poprawność PINu.
    >
    > Czyli tak czy inaczej wychodzimy albo od sklonowanej, albo wytworzonej we
    > własnym zakresie -- w oparciu o cudze numery kart -- plasticzki.

    Lub kradzionej.

    >> W przypadku kart DDA, które posiadają klucze RSA, istnieje możliwość
    >> oszukania terminala poprzez modyfikację pakietów autoryzacyjnych,
    >> przesyłanych pomiędzy kartą a terminalem. Oczywiście nie będzie to
    >> możliwe gdy musimy podać kartę sprzedawcy w sklepie i to on wtyka ją w
    >> terminal, ale często jest tak, że klient sam to robi i wtedy można użyć
    >> kradzionej karty.
    >
    > Kradzionej czy podrobionej? Zakładając, że miałbym kartę tego rodzaju i
    > dałbym ją Tobie -- da się "podrobić" PIN? E...

    Wkładam Twoją (kradzioną) kartę do czytnika podpiętego do komputera,
    ktory mam w plecaku. Podpinam do niego także inną kartę (nazwijmy ją
    "serwisową"), którą wkładam do terminala POS (jako że z rękawa będzie mi
    wystawała mała wiązka kabelków, to nie zadziała jeśli kartę trzeba podać
    sprzedawcy).
    Komunikacja pomiędzy POS a moją kartą jest transmitowana przez laptopa,
    do Twojej karty, tak więc POS de facto rozmawia z TWOJĄ kartą.
    Gdy przychodzi do autoryzacji, wpisuję dowolny PIN.
    POS wysyła go do karty i oczekuje odpowiedzi 0x9000 jeśli PIN się zgadza
    lub 0x63CX (gdzie X to ilość pozostałych prób PIN), jeśli się nie zgadza.

    Twoja karta odpowiedziałaby 0x63Cx, natomiast ten fragment transmisji
    został przechwycony przez komputer, który odesłał poprzez moją kartę do
    terminala odpowiedź 0x9000.

    Podstawowym niedociągnięciem EMV jest brak uwierzytelniania tej
    komunikacji. Dlatego offline jest mniej bezpieczne niż online.

    Pozdrawiam,

    --
    ... Robert Jaroszuk ...
    GCS/IT/O d- s: a- C ULB++++$ P+ L++++$ E- W++ K- N++ DI+
    V- M- PS+ PE++ Y(+) PGP++ t 5? X R !tv b+>++++ D- y+ G++
    We do not see things as they are, we see them as we are.
    GPG key id: 0x5D9659C3
    GPG fingerprint: E1A9 C793 FCF2 8EBD 89E9 39D5 DED4 03D1 5D96 59C3

Podziel się

Poleć ten post znajomemu poleć

Wydrukuj ten post drukuj


Następne wpisy z tego wątku

Najnowsze wątki z tej grupy


Najnowsze wątki

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1