Użytkownik Andrzej Popek napisał:

>>Może pamiętać ale to bez sensu - po każdej transakcji na podstawie
>>starego klucza i paru innych rzeczy jest liczony nowy klucz transkacyjny
>>i tym nowym kluczem _musi_ być podpisana kolejna transakcja. Inaczej
>>(tzn jak jeszcze raz podeślemy PIN zakodowany starym kluczem) to host
>>autoryzacyjny powinien odmówić autoryzacji.
>>
>>A tu jak widać dał autoryzację. Nieładnie, bardzo nieładnie. Wręcz
>>kryminalnie.
>
>
> Z czystej ciekawosci spytam skad wiesz, ze za kazdym razem generowany jest
> nowy klucz transakcyjny. Z tego co wiem jest to jeden staly klucz za pomoca
> ktorego szyfrowany jest PIN.
>

Dane które idą z bankomatu do Centrum Autoryzacyjnego wyglądają tak:

NR_bankomatu:nr karty:godzina:typ operacji:{troche innych
danych}:(szyfrowany PIN)

Szyfrowany jest tylko PIN a cała reszta nie. I taki pakiecik leci sobie
po nieszyfrowanych łączach. Wyobrażasz sobie, co by się działo gdyby
ktoś się włączył pośrodku transmisji? Tzw 'attack man in the middle'?
Ano wysłałby pakiecik z poleceniem przelewu (a niektóre bankomaty
pozwalają przecież na dokonanie przelewu) i włożył jako dane Twój nr
karty i PINblok (zaszyfrowany PIN) który poszedł godzinę temu razem z
Twoją transakcją. Nie miałbyś szans (no poza nagraniem video) udowodnić
że to nie Ty przelałeś 2000 PLN na konto jakiegoś gościa - przecież PIN
się zgadza. Dlatego za pomocą tego stałego klucza o którym wspomniałeś
do każdej transakcji generowany jest w bankomacie nowy klucz (pewnym
ustalonym algorytmem). I komputer w CA też generuje klucz transakcyjny w
taki sam sposób - i dlatego się dogadują. I teraz ten 'man in the
middle' nie ma szans - bo stary PINblok nic mu nie daje - na jego
podstawie nie jest w stanie poznać ani PINu ani klucza.

Pozdrawiam

Łukasz