On Tue, 22 Mar 2016, Krzysztof Halasa wrote:

> Rafal Jankowski <j...@o...wsisiz.edu.pl> writes:
>
>> "Bank wysyła urządzenie do klienta z już wygenerowanym kluczem
>> prywatnym (którego nigdy nie opuszcza scalaka), sobie zostawia
>> publiczny. Wszystkie operacje są podpisywane (w urządzeniu) przez
>> klucz prywatny. Aplikacja bamnkowa jest podpisana żeby było wiadomo,
>> że żaden malware nie prosi o podpis."
>>
>> To jeden z możliwych scenariuszy. Wyśmiałeś go i OK, ale sam nie
>> podałeś lepszego.
>
> Nie jest najlepszy, bo zawsze można wtedy bankowi zarzucić, że sam sobie
> podpisał zlecenie. Jeśli już się w ogóle bawimy w kryptografię
> asymetryczną, to klucz prywatny powinien być generowany w tokenie,
> a bank dostawałby tylko część publiczną, w obecności klienta.
>
> Ale to trudniejsze w użyciu niż wersja z challenge & response.

Zakładamy, że transakcja została podpisana kluczem z TPMa, który go nie
opuścił, więc tak czy inaczej musiałby ją podpisać użytkownik jedynie na
podstawie tego co wyświetla mu aplikacja (też podpisana). Wówczas
teoretycznie można zweryfikować czy taka aplikacja mogła wyświetlić
userowi coś innego a co innego podpisać. Może jeszcze coś przeoczyłem. To
oczywiście nie jest takie proste ale to najlepszy scenarusz który w danej
chwili przyszedł mi do głowy i (zwróć uwagę) to w dodatku nie jako
kandydadat do wdrożenia tylko punkt wyścia do mojej uwagi że sam TPM nie
jest rozwiązaniem problemu nieautoryzowanych transakcji. Problem w tym, że
mój przedpiśca mnie wyśmiał, a sam poza zapodaniem hasła TPM nic lepszego
w sumie nie zaproponował.