M.M. <m...@g...com> wrote:

>> > Jeśli jest ryzyko że ktoś wyciągnie dane dające się zdekodować z
>> > urządzenia, to w urządzeniu powinny być przechowywane tylko funkcje
>> > skrótu - tak jest np. w logowaniu do linuxa. Dlaczego nie możesz
>> > zastosować takiego rozwiązania?
>>
>> Bo te dane nie są stałe.
> Ja już tego nie rozumiem. Co ma stałość lub nie stałość danych wspólnego
> z szyfrowanym protokołem którym są przesyłane?

Protokół nie musi być szyfrowany, ważne jest, żeby urządzenie prawidłowo
rozpoznało podpis.

>> Chcę żeby były generowane w oparciu o datę i SN,
> Ja myślałem, że chcesz bezpieczeństwa.

Widzisz inny sposób na podanie użytkownikowi awaryjnego hasła, które
umożliwi mu awaryjne wykonanie funkcji, jak zapomni swojego hasła?
Jakimś pomysłem jest challenge / response, tylko nie widzę przewagi
challenge / response nad tym rozwiązaniem... Ty widzisz? (nie pytam
złośliwie, może czegoś nie dostrzegam)

To, że hasło będzie mogło być użyte wielokrotnie danego dnia, to nie
problem. Użytkownik, który wejdzie w jego posiadanie (a wejdzie po
telefonicznej weryfikacji), i tak będzie mógł zmienić hasło na urządzeniu
na swoje.

>> bo nie chcę, żeby ten klucz działał w nieskończoność i na
>> każdym urządzeniu.
> W ramach podstawowego standardu bezpieczeństwa jest zmiana
> hasła i inne hasło do każdego urządzenia.

Użytkownik będzie miał swoje hasło, które ustawi sobie sam. Ono będzie
przechowywane w postaci posolonego skrótu, więc nie do wyciągnięcia bez
brute-force. Problem pojawi się, gdy użytkownik zapomni hasła. Helpdesk
będzie musiał wtedy jakoś mu pomóc.

--
[ Email: a@b a=grp b=chmurka.net ]
[ Web: http://www.chmurka.net/ ]