> Czy to znaczy ze w polszcze sie chipy nie przyjely i trzeba je
> promowac w bardziej zacofanych krajach? ;-))

Jak na moj gust - to sie nie przyjely. Chyba sie zgodzimy, bez polemiki, ze
jesli tylko jeden bank, w ograniczonym zreszta zakresie, zdecydowal sie na
kontynuacje wydawania karty po zakonczeniu pilota, to o sukcesie nie moze
byc mowy. Ale z naszej terminalowej strony, polski projekt jest poki co
zamkniety, wiec korporacja przerzuca sily w inne rejony:)

> > To miala byc podstawowa zaleta EMV - off-line PIN. Decyduje o tym na
pewno
> > nie TVR, ale CVM+dodatkowo mozliwosci terminala do wykonywania sprawdzen
> > opisanych w CVM. Nie bez znaczenia jest tez bit 5, 1 bajtu AIP.
Natomiast
> > TVR zbiera tylko dane o tym, co w czasie transakcji zostalo zrobione i z
> > jakim skutkiem.
>
> Mowisz oczywiscie o TVRe generowanym w chipie, bo ten terminalowy to
> raczej jeszcze nic nie wie o transakcji ;-)

Hmmmm TVR - w karcie?!?!?!? TVR=_ TERMINAL_ Verification Result. Kazdy bit
tego rejestru to pewna operacja i jej rezultat - wykonana przez _terminal_ -
w odroznieniu od CVR - _CARD_ Verification Result - gdzie na podobnej
zasadzie biciki ustawia sobie karta - ale inne biciki, bo i inne operacje
wykonuje karta.
>
> > Nie zapominaj, ze w danych na chipie sa powtorzone 1 i 2 sciezka -
natomiast
>
> Ale przeciez nie musza (nie chce mi sie grzebac, ale w chipie nie
> musisz miec wcale drugiej sciezki - nawet ekwiwalentu). O tym co tam
> jest mowia pewne tagi, ale ze sie wlasnie ratuje po czesciowym padzie
> dysku to nie moge sie na nie powolac.

Musi byc - otagowana jest chyba numerkiem 57 (track 2) i numerkami 9F1F i
9F20 (discretionary data sciezek 1 i 2). Specyfikacja VIS 1.3.2 zezwala aby
nie bylo discr. data dla sciezki 1, natomiast dane sciezki 2 sa ciagle
Mandatory (polecam dodatek A1 do specyfikacji VIS 1.3.2)

>
> > moga byc powtorzone bez PVV. Teoretycznie bank nie powinien znac PINu do
> > chipa i nie powinien miec mozliwosci jakiejkolwiek jego weryfikacji. Z
>
> To akurat dotyczy chyba kazdego przypadku PINa - ciekawia mnie wtedy
> pozycje w niektorych TOiP pewnych bankow - 'odzyskanie pinu' ;-)

Mysle, ze HSM jest w stanie wygenerowac nowy _on-line_ PIN - w koncu ma
kopie 2 sciezki z wartosciami PVV.
>
> I chcialbym troche popolimeryzowac z tym 'niemoznoscia weryfikacji
> pinu przez bank' - nie pamietam a sprawdzic nie moge, ale mam wrazenie
> ze karta moze zazadac online i wtedy do banku idzie
> m.in. pinblok. Sugerujesz ze nie jest on sprawdzany?

Oczywiscie, ze jest - nie jest to jednak uzaleznione od on-line, tylko od
wzmiankowanej juz listy CVM. Teoretycznie jednak oba piny nie maja ze soba
nic wspolnego i moga byc rozne. Generalnie jednak polecam odpowiedni
rozdzial ze specyfikacji VIS 1.3.2 rozwodzacy sie nad ta materia np. 14.6.4

> > Nie do konca tak - wybierana jest bardziej rygorystyczna metoda. Do
> > generacji pierwszego kryptogramu terminal musi poinformaowac karte czego
> > zada (TC, AAC, ARQC), a robi to rzeczywiscie na podstawie anlizy TVR
(ale
> > robi to terminal!!!) i porownania z maskami Terminal Action Codes.
>
> Siem nie zgadzam nieco.
>
> Transakcje robi karta - terminal nie moze od niej zadac. Terminal
> sugerowac stopien ryzyka.

I tu znowu rozdzial 2.4.5 EMV Card - opis komendy Generate AC. Terminal zada
w tej komendzie typ kryptogramu. Karta moze to zmienic, ale jesli terminal
zada on-line, to karta nie moze chciec off-line. Jesli terminal zazada AAC -
to karta _musi_ odpowiedziec z AAC, jesli zazada ARQC - musi odpowiedziec
ARQC lub AAC, jesli zazada TC - ma najwieksza swobode:)))
Obie czesci aplikacji (Terminal i Card) dokonuja tego (wyboru sposobu
przeprowadzenia transakcji) poprzez analize TVR'a i zestawienie wartosci
tego rejestru ze swoimi maskami Action Codes (odpowiednio Terminal i Card).
Daje nam to mozliwosc podjecia decyzji jednoczesnie ze strony issuera (Card)
oraz ze strony acquirera (Terminal) - w zaleznosci od specyficznych wymagan
obu stron - ale zawsze wybierana jest metoda bardziej rygorystyczna.
>
> > A stary dobry DES - na karcie jest kilka DESowych kluczy issuera,
> > zdywersyfikowanych numerem seryjnym karty. Jakos trzeba obsluzyc secure
> > messaging i generacje wzmiankowanych juz kryptogramow:)
>
> To ma byc kryptografia? ;-)

DES??? Oczywiscie:)))))) ciagle podstawa systemow bankowych. W EMV potrzebny
do:
1. generacji i sprawdzania kryptogramow transakcji,
2. MACowania komend post-issuance (skryptowych),
3. autentykowania issuera.

> Mam nadzieje ze szykuje sie dluzsza dyskusja.

Ja tez, ale chyba na tym cierpia wzmiankowane juz projekty...
Jacek