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

>> > W ramach podstawowego standardu bezpieczeństwa jest zmiana
>> > hasła i inne hasło do każdego urządzenia.
>>
>> I co dwa dni zmieniać i dystrybuować nowe hasło?
> Czyli problemem jest wprowadzanie setek haseł z
> uprawnieniami, ważnością, itd?

W pewnym sensie tak. To ma być awaryjny mechanizm odzyskania hasła, który
w większości urządzeń nigdy nie będzie wykorzystany, bo:

a) służy jedynie do zarządzania -- o ile się tego explicte nie włączy, to
do normalnej obsługi urządzenia nie jest potrzebne żadne hasło

b) ustawienie hasła na menu zarządzania nie jest obowiązkowe, użytkownik
ma po prostu taką możliwość, żeby jego pracownicy mu nie grzebali

Zdarzają się pojedyncze sytuacje, w których użytkownik ustawi hasło, a
potem albo zapomni, albo w ogóle nie ogarnia, że jakieś hasło ustawiał.
Wtedy dzwoni i trzeba mu jakoś pomóc, niekoniecznie od razu wymieniając
urządzenie na nowe.

Te sytuacje są na tyle rzadkie i wyjątkowe, że nie jest uzasadnione
wprowadzanie setek haseł, wydawanie tokenów itd., ale jednak się zdarzają
i musi być na to procedura (inna niż całkowita wymiana urządzenia).

> Jeśli to ma być bezpieczne,

Ma być tak bezpieczne, jak to możliwe w logistycznych realiach. Tzn. są
pewne realia logistyczne (jak np. to, że nie będziemy dystrybuować po
użytkownikach tokenów), w których rozwiązanie techniczne musi się zamknąć.
Sam problem wyciągnięcia klucza z urządzenia też jest raczej teoretyczny,
po prostu nie podoba mi się sam fakt, że ten klucz tam będzie i chcę to
zrobić na tyle zgodnie ze sztuką, na ile to możliwe, nie zmieniając
logistyki rozwiązania.

> to nie widzę innej możliwości, jak potraktowanie tego (o czym wyżej
> już pisałem z dwa razy) jako transmisję danych. W danych które
> użytkownik wprowadza powinny być uprawnienia, data ważności, nazwa
> użytkownika i wszystko, co tam jeszcze potrzeba.

Tu nie ma szczególnej nazwy użytkownika.

Jest jeden superuser (właściciel urządzenia, który może mieć swoich
pracowników), który dodaje poszczególnych użytkowników (swoich
pracowników; oni mają swoje identyfikatory). Ten superuser ma możliwość
zresetowania hasła użytkownika. Rozwiązanie, którego szukam, ma z kolei
umożliwić reset hasła tego superusera.

> Dane powinny być zaszyfrowane i i podpisane. W systemie powinien być
> klucz prywatny systemu. Dane powinny być zaszyfrowane kluczem publicznym
> systemu. W systemie powinny być wszystkie klucze publiczne użytkowników,
> czyli i tak i tak do bezpiecznego(!) systemu trzeba trochę się na
> pierniczyć i wprowadzić dane. Jeśli publicznych kluczy użytkowników nie
> będzie w systemie, to nie będzie pewności czy użytkownik jest tym, za
> kogo się podaje.

Jest jedna ważna rzecz, o której chyba nie napisałem. Użytkownik
(superuser) jest lokalny dla urządzenia. On nie istnieje poza nim, jego
dane nie są nigdzie przesyłane. On odpowiada tylko za swoje urządzenie, a
hasło ma zapewnić, że tylko on będzie miał dostęp do wszystkich pozycji
menu.

> Przychodzi mi do głowy pewne rozwiązanie, ale nie ręczę za jego jakość.
> Można w danych zawrzeć informację o nazwie użytkownika, zaszyfrować je
> kluczem prywatnym użytkownika, a potem klucza prywatnego nie udostępniać
> użytkownikowi. Wydaje mi się, że użytkownik bez klucza prywatnego nie
> jest w stanie spreparować danych w celu podszycia się pod kogoś. Reszta
> jak powyżej, klucz publiczny w systemie.

Tu użytkownik też nie będzie miał żadnego klucza. Chodzi mi o teoretyczną
sytuację, w której ktoś dobierze się do urządzenia lub do plików update'u
(które nie są normalnie dystrybuowane, ale nie są też specjalnie tajne) i
wyciągnie sobie klucz. Nie zna oczywiście algorytmu, który generuje hasło
na podstawie tego klucza, ale security by obscurity nie biorę pod uwagę i
zakładam, że algorytm jest znany (lub może być łatwo poznany).

> Ale na kilku bitach tego nie zrobisz...

No właśnie... wyobrażasz sobie przepisywanie 40-cyfrowego hasła przez
telefon? Klient po 15 cyfrze powie, że ma to w gdzieś, nic nie będzie
przepisywał i chce, żeby przyjechał technik i mu to zrobił lub wymienił
urządzenie... i w sumie nie ma co mu się dziwić.

> Jeśli masz 100 użytkowników, to teoretycznie wystarczą Ci dwie cyfry na
> hasło, ale wtedy są dwie oczywiste wady:
> - nawet pomyłka przy wprowadzaniu hasła oznacza podszycie się pod innego
> użytkownika - nie trzeba się włamywać nawet.

Tak jak wyżej -- użytkownik nie istnieje poza urządzeniem. Jak sobie
zmieni hasło lub w ogóle je zdejmie, jak tak woli, to ta informacja nie
jest nigdzie przesyłana. Wystarczy, że urządzenie o tym wie.

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