Rafal Jankowski <j...@o...wsisiz.edu.pl> writes:

> Ktoś mający przez chwilę dostęp do tokena jest w posiadaniu
> znajdującego się w nim klucza (w sensie: może go użyć) jeśli nie mamy
> dodatkowych zabezpieczeń które powiązują token z osobą. Jeżeli
> aplikację wgrywa bank to:
>
> - po pierwsze w dalszym ciągu można postawić mu zarzut "daliście mi token
> z kluczem i aplikacją, a teraz mówicie, że transakcja była
> uwierzytelniona bo tak wskazuje wasz system informatyczny". W przypadku
> gdy klient sam generuje klucz i wgrywa aplikację taki zarzut pod adresem
> banku już jest niemożliwy

Owszem, ale 99,xxx% klientów banku nie potrafi tego bezpiecznie zrobić.
Nie ma sensu rozważać takich sytuacji.
Po prostu należy założyć, że bank (ale niekoniecznie jego szeregowi
pracownicy) jest godny zaufania.

Alternatywą jest normalny podpis cyfrowy, ale to bardziej skomplikowane,
wymaga "przeszkolonego pracownika", i nie do zaoferowania klientowi
indywidualnemu. Zresztą w sytuacji z przeszkolonym pracownikiem to także
zwykle nie jest bezpieczne, przecież jak przyjedzie serwisant z banku to
XX % ludzi da im pełny dostęp do wszystkiego. Po prostu to są
technologie dla specyficznych części wojska albo innych agencji itp.

> - po drugie wyobrażam sobie że można wtedy dość skutecznie przeprowadzić
> od strony banku atak ukierunkowany na konkretną osobę wysyłając coś co w
> rzeczywistości bezpiecznym tokenem nie jest a klucz prywatny ma
> atakujący.

Dlatego napisałem, że programowanie tokena (inne niż
generowanie/ustawianie klucza) nie powinno być dostępne.

> Jak dyrektor banku przeczyta, że ktoś go zwyzywał na niusach
> od debili to ma pokusę aby to zrobić.

Poważnie? Może jakiś partyjny dyrektor :-)

> Jeśli w token każdy zaopatruje się
> indywidualnie i anonimowo tudzież w podobny sposób wgrywa aplikację to
> taki atak jest właściwie wykluczony.

Nie jest, każdy wie do czego służą takie tokeny i co może dać atak na
nawet niewielką część z nich. Przykład - afera w RSA Security
(i spowodowane nią włamania w Lockheedzie oraz przypuszczalnie wiele
innych, o których nie wiemy).

> Piszesz, że nie koniecznie potrzebujemy kluczy asymetrycznych. Możesz
> wyjaśnić jak to się odbywa bez takich kluczy? Wyobrażam sobiem, że
> taki sam klucz symetryczny musiałby powstać jednocześnie w tokenie
> użytkownika i infrastrukturze banku. Ale zakładając, że wogóle on nie
> powinien opuszczać chipa jest to jakieś wyzwanie technologiczne.

Bez problemu, bank może generować klucz i zapisywać go w tokenie (typowy
schemat). User także może zapisać nowy klucz (przy odrobinie wysiłku) -
token przestanie wtedy "działać" z bankiem.

> Rozumiem, że coś na kształt takiej technologii istnieje?

Tak naprawdę to nie jest nawet żadna specyficzna technologia, to tak
jakby pytać o technologię kalkulatora.

Ja osobiście nie zajmuje się projektowaniem dokładnie takich rzeczy,
ale jakbym miał coś takiego zrobić, to sprawa byłaby prosta: Cortex M4,
wyświetlacz OLED 3"+, touchscreen MT, akumulator, mała kamera. Ew. USB
jako "wyjście" (emulacja klawiatury?). Sklejona obudowa.

> Chodzi o
> provisionowanie klucza na zasadzie jakiegoś DRMa?

Rozwiniesz skrót? Żaden mi nie pasuje. Generalnie to są proste rzeczy,
aczkolwiek niewątpliwie wiele "zamkniętych" implementacji było
wadliwych. Teraz można zamówić taki sprzęt "pod klucz" w niewielkich
seriach (nie tylko w kontekście banku). Kryptograficznie wszystko składa
się ze znanych klocków - AES, SHA, RSA itd.
--
Krzysztof Hałasa