Dawid Rutkowski <d...@w...pl> writes:

> Ja piszę o generowaniu CVC2 na podstawie numeru karty i jej daty
> ważności,

No ale to jest nieprzydatne, bo lepiej wygenerować to losowo.
Generatory losowe też zwykle nie używają bezpośrednio np. spróbkowanych
szumów termicznych, tylko "zasilają" nimi "pulę" bitów, z której
"wydobywają" następnie ("manglując" np. hashem, ale może to być także
DES) potrzebne dane "losowe". Więc w ogóle ten DES mógłby być tam gdzieś
zastosowany. Tyle że to wewnętrzna sprawa banku.

> a Ty o sprawdzaniu ew. poprawności wpisania za pomocą cyfry
> kontrolnej.

Wydawało mi się, że to miało być powiązane.

> To pierwsze oczywiście w terminalu nie może być, to drugie - gdyby
> istniało - mogłoby być jak najbardziej, bo to nie szyfr, tylko jawny
> algorytm detekcji błędów.

Tyle że nie chodzi o to, by można było "niedobre" CVV* eliminować bez
kontaktu z bankiem. Dokładnie tak samo jak z PINami - raczej chodzi
o to, by właśnie zawsze był kontakt z bankiem, i by np. ograniczyć
liczbę nieudanych prób (i/lub ją monitorować).

> https://en.wikipedia.org/wiki/Card_security_code#Typ
es_of_codes
> https://en.wikipedia.org/wiki/Card_security_code#Gen
eration

No w każdym razie to nie jest w ogólnym przypadku prawda, chociaż, tak
jak pisałem, bank robi to po swojemu.

> A czemu bez sensu?
> Bezpieczniej trzymać w bazie banku komplet numer+data+CVV czy też
> trzymać tylko numer+data, a CVV obliczać sobie w razie potrzeby
> sprawdzenia?

Jasne że to pierwsze.

> Obliczać oczywiście w osobnym, sprawdzonym i bardzo chronionym module.

Łatwiej ukraść pojedyncze klucze niż bazę CVV*. Dodatkowo kradzież
kluczy ma skutki także dla kart wyprodukowanych w przyszłości (do
momentu zmiany klucza), kradzież bazy nie ma tego problemu.

Inaczej to zaczyna wyglądać, gdy ktoś chce być w stanie obliczać
niejawne wartości długo po tym, gdy jego misja w danym miejscu się
zakończyła (pewne przykłady można znaleźć).

> Dynamiczne to już na pewno musi iść jakimś kluczem, i ten klucz musi
> być w pamięci karty. Do tego na pewno ATC jako seed - a w sumie w tym
> wypadku dlaczego nie numer+data+ATC?

Tyle że klucze są różne dla różnych kart. W przeciwnym przypadku dałoby
się je wyciągnąć z karty, nie jest to może najłatwiejsze, ale nie jest
też takie trudne (scalaki są "duże", to nie jest 7 czy 12 nm).

> Więc tych kluczy trzeba znaleźć miriady - i do tego mieć miriady
> prawdziwych przykładów, które pozwolą odsiać klucze "prawidłowe tylko
> dla jednego przykładu" - aż w końcu znajdziesz ten właściwy.

Nie musi ich być tak bardzo dużo - klucze DES mają 56 bitów, oczywiście
musisz mieć tu więcej niż 56 bitów, ale nie aż nie wiadomo ile razy
więcej.

> I dlatego zapewne taka baza nie istnieje - a CVV2 za każdym razem, gdy
> jest potrzeba sprawdzenia, jest generowany w banku - i dlatego nie
> może być losowy.

Napiszę tak, teoretycznie mogłoby tak być. Ale to proszenie się o kłopoty.
Kiedyś coś takiego mogłoby istnieć (podobne rozwiązania w tej dziedzinie
oparte na DES istniały), ale wtedy raczej nie było jeszcze nawet CVV2.

> No to też PINy - jako mające 4 znaki, cyfr kontrolnych nie mają, bo
> raczej się nie pomylisz.

Oczywiście że nie mają, przecież mogę ustawić sobie dowolny 4-cyfrowy
PIN.

> Samo CVV, jako trzycyfrowe, pewnie nie ma cyfry kontrolnej dla "samego siebie".
> Ale może mieć dla 18-cyfrowej sekwencji numer karty+2 pierwsze cyfry CVV.
> Pewnie jednak tak nie jest, bo podanie błędnego CVV nie może
> spowodować, że wskazane zostanie inne prawidłowe konto.

Przede wszystkim
a) to nie jest do niczego przydatne
b) taki algorytm musiałby być publiczny (zaimplementowany
w terminalach), a to spowodowałoby dodatkowe zmniejszenie (10-krotne)
już i tak bardzo małej przestrzeni CVV*.

> Inkasent z elektrowni.

Tego też nie pamiętam :-) Spojrzę w wolnej chwili.

> Tzn. co, nie da się "skrócić kryptograficznie" PINu czy CVV i tak ich
> trzymać w bazie?

Owszem, nie ma takiej praktycznej możliwości.

> Przecież się da, ważne tylko, by ten "skrót" nie skracał, a szyfrował
> - czyli żeby jego długość była większa niż PINu czy CVV - i oczywiście
> żeby algorytm gwarantował, że dla dwóch różnych PINów nie powstanie
> taka sama wartość zaszyfrowana.

Niczego to nie da, ponieważ PINów (i CVV*) jest tak mało, że można bez
najmniejszego problemu sprawdzić wszystkie.
Teoretycznie algorytmy "rozciągające" mogłyby tu minimalnie pomóc, ale
w praktyce dla 4-cyfrowych wartości żaden algorytm nie pomoże.
IOW, czy ktoś ma dostęp do bazy PINów, czy do bazy skrótów PINów, to
jeden diabeł.

Oczywiście zaszyfrowanie tych PINów zmienia sytuację - jeśli atakujący
nie ma dostępu do klucza. Podobnie, jeśli nie miałby dostępu do bazy.

> Zaś to, że prawdopodobieństwa możliwych pomyłek zostały zbadane przy
> opracowywaniu algorytmu generacji liczby kontrolnej - to chyba można
> domniemywać.

Nie trzeba domniemywać, algorytm jest przecież znany.
--
Krzysztof Hałasa