🚀 go-pugleaf

Michoo <michoo_news@vp.pl> writes:

> Na spreparowany "na miarę" atak nikt nic nie poradzi - mam nawet
> gdzieś ze "starych dobrych czasów" bardzo prostą łatę na ssh i płytę
> bootowalną, która pozwalała na jego 'aktualizację' w 20 sec. Na
> zabezpieczenie się przed czymś takim na moim własnym laptopie nie
> liczę (zresztą mam na nim logowanie po kluczach).

Dlaczego nikt nie poradzi?
Oczywiscie, nie ma 100% bezpieczenstwa, zawsze np. "sluzby" moga Ci
dac np. narkotyki i/lub przerobic w tym czasie laptopa. Ale zakladajac
sensowny potrzebny poziom bezpieczenstwa, mozna sie skutecznie
zabezpieczyc przed realnymi zagrozeniami.

> Główny cel to zabezpieczenie przed keyloggerami (np będącymi
> składnikami jakiś robaków, czy "sprytnych" studentów) - regularnie
> loguję się z komputerów laboratoryjnych oraz komputerów znajomych (czy
> na wakacjach z kawiarenki) - nadzianie się tam na takie świństwo
> wydaje mi się prawdopodobne (ale może to tylko moja 'przeszłość'
> sprawia, że mam lekką paranoję...).

To jest prawdopodobne, zwlaszcza jesli chodzi o cafe.
Problem w tym, ze hasla jednorazowe tylko troche zwiekszaja
bezpieczenstwo - jak dla mnie, nie jest to wystarczajace do korzystania
z nich.
Przeciez sa "male" terminale. Kiedys to nieco inaczej wygladalo, ale tez
swiadomosc potencjalnych wlamywaczy byla duzo nizsza.

Zreszta nawet trywialne rozwiazania moga byc skuteczne - np. zamiana
kabli klawiatur (i moze nawet kabli monitorow), albo podpiecie
odpowiedniej "przejsciowki" do klawiatury. W cafe mozemy w ogole
zapomniec o bezpieczenstwie.

> Ale mniej wygodne - na zajęciach nawiązuję kilka..kilkanaście połączeń
> ssh/sftp.

Robienie tego z pecetow w studenckim labie nie jest po prostu
bezpieczne, i tyle.
No moze z takich odpalanych z sieci, bezdyskowych - tez ryzyko, ale
jednak mniejsze (oczywiscie trzeba zawsze resetowac przed praca).

>> Ale tez nie interesujemy sie wszystkimi kombinacjami, a tylko interesuje
>> nas sumaryczna szansa na trafienie w ilus tam probach. Przeciez lamacze
>> MD5 albo innego DESa nie musieli sprawdzac 100% kombinacji.
> Średnio trzeba sprawdzić połowę.

No tak, chyba ze interesuje nas mniejsze prawdopodobienstwo sukcesu.
Inna sprawa, ze PINy dobre sa wtedy, gdy zakladamy, ze ktos nie moze
miec (powtarzalnego) dostepu do naszego urzadzenia, i ze tego nie
zauwazymy. Zreszta, jesli ktos bedzie mial dostep, to moze urzadzenie
przerobic - przyklejenie w srodku drugiej atmegi to nie problem
przeciez (obudowa zalana zywica?).

> Poza tym dzięki tajnemu seedowi nie mamy tu problemu wygenerowania
> kolizji, czy ataku urodzinowego, tylko generowanie funkcji odwrotnej
> do haszującej co wg mojej wiedzy dla md5 nadal ma złożoność 2^n, gdzie
> n jest liczbą bitów w pierwotnej wiadomości.

Podobno nie, ale chwilowo raczej nie jest to najwazniejszy problem w tym
zastosowaniu.

> b) ponieważ będzie to tylko 1 z pluginów do PAMa zostanie cały czas
> możliwość logowania za pomocą "normalnego" hasła a jeżeli ktoś się
> będzie właśnie bawił moim tokenem to raczej ja się nim nie będę
> próbował zalogować.

Ale ktos nie musi miec wcale tokena by blokowac logowanie.

> Jak będę odczuwał, że mi na nim ciasno to pewnie zmienię na avr32/arm.
> Tylko to zwiększy cenę 2..3 razy a układ w założeniu ma być prosty i
> tani.

AVR32 i ARM to moze inna bajka, ale wsrod AVR8 tez sa rozne, np. taki
ATmega328 z 32 KB flasha. Taka sama mala obudowa.

> A jakieś inne proste funkcje haszujące dające wynik powyżej 10 bajtów?

SHA-256 typowo.

>> Poleganie na dokladnosci takiego RTC to nie jest dobry pomysl.
>> Polegac mozna na monotonicznosci.
> Tokeny RSA jakoś polegają ;)

Niespecjalnie, wystarczy nie uzywac przez dlugi czas i sie rozjezdzaja.
Trzeba jeszcze pamietac, ze ludzie nosza te tokeny np. przy sobie
(>30 st.C) oraz np. w zewnetrznej kieszeni kurtki (zima -10 st.C itp).
Albo to nie bedzie podatne na niedokladnosc RTC, albo warunkiem
poprawnego dzialania bedzie caly czas dzialajace urzadzenie, np. w
termostacie albo przynajmniej skompensowane termicznie.

> To rtc ma praktyczną dokładność +-2 minuty na rok - przy słabszym
> pewnie trzeba by aktywnie kompensować niedokładność wskazań po stronie
> hosta przez odbieranie timestampa.

Tak sie raczej nie robi, samo uzywanie powoduje synchronizacje.
-- 
Krzysztof Halasa