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

> Inna sprawa, że w wersji z tokenem, który ma kamerkę i tą kamerką
> zczytuje kod QR z zawirusowanego systemu też mamy problem tego typu,
> że na tym tokenie musi być aplikacja zaufana, więc jak bank nie jest
> zaufany to mamy dokładnie ten sam problem. Pewnie i to da się jakoś
> rozwiązać, ale mi się już chyba nie chce kombinować, bo ja tu miałem
> być od czepiania się a nie od podawania rozwiązań.

Jeśli nie ufamy bankowi, to niestety problem jest nierozwiązywalny -
przynajmniej do momentu, w którym sami jesteśmy w stanie zbudować sobie
system do podpisywania zleceń. Ale to nie jest nasz aktualny problem.

Zakładamy, że bankowi możemy jednak ufać. To m.in. dlatego nie wymagamy
od klienta bezpiecznego podpisu cyfrowego, a jedynie jakieś tam kody
autoryzujące.
Bank może dać nam (klientowi) bezpieczne urządzenie (token), który
będzie wyświetlał nam na ekranie szczegóły zlecanej właśnie operacji,
oraz (w przypadku akceptacji) będzie informował bank, np. wyświetlając
kod jednorazowy, który wklepiemy w przeglądarkę. To jest rozwiązanie
bezpieczne (wystarczająco).

Jeśli coś takiego będziemy mieć w np. telefonie, albo w ogóle w pececie,
to niestety nie będzie to bezpieczne, ponieważ na tych urządzeniach
instalujemy nie wiadomo jaki soft, i nie możemy mieć do nich żadnego
zaufania. TPM ani nic podobnego też nam go nie zapewni. Musimy mieć
urządzenie, na którym w praktyce nie można nic zainstalować, najlepiej
odporne na zanurzanie w wodzie, na upadki na podłogę itd.

Stąd (często wykorzystywana) koncepcja kamery z kodem QR, trzeba jedynie
zadbać by program czytający QR przypadkiem nie wykonał tego, co
przeczyta (a tylko wyświetlał to, liczył odpowiednie m.in. hashe
i generował odpowiedź).
--
Krzysztof Hałasa