🚀 go-pugleaf

On Mon, 05 Apr 2010 20:53:07 +0200, Michoo wrote:

> Projekt ten to sprzętowy generator haseł jednorazowych służących do 
> logowania po ssh (a właściwie to każdego via PAM). Wiem, że istnieją 
> przynajmniej 2 projekty powiązane z generowaniem haseł jednorazowych 
> (OPIE  i OTPW), ale ich główną wadą jest czas potrzebny na zalogowanie - 
> działają one na zasadzie challenge-response przez co każde logowanie 
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I tak właśnie mają działać. 

> Jako hasło generowane będzie md5 z:
> 1. losowego ciągu kilkudziesięciu znaków zapisanych w pamięci EEPROM - 
> jego zadaniem jest utrudnienie ataków brute-force, wyciągnięcie go z 
> urządzenia jest teoretycznie niemożliwe (zmiana programu wymaga 
> wyczyszczenia EEPROMu), chyba, że znajdzie się na nie (urządzenie) 
> eksploit, no i jest potrzebny fizyczny dostęp
> 2. numeru sekwencyjnego - system będzie sprawdzał np 100 następnych 
> haseł (albo znacznie mniej aby utrudnić ataki brute-force umożliwiając 
> jednocześnie atak DOS) i po poprawnym zweryfikowaniu nie akceptował 
> wcześniejszych tak więc wygenerowane w chwili nieuwagi właściciela hasło 
> na nic się nie przyda jeżeli tylko się on zaloguje przed jego 
> wykorzystaniem, przypadkowe wygenerowanie hasła też nie będzie problemem
> 3. (opcjonalnie) kodu pin generowanego za pomocą naciskania 2 przycisków 
> - dodatkowe zabezpieczenie aby ktoś, kto "pożyczy" sobie token nie mógł 
> się zalogować, ani wygenerować zestawu haseł do zużycia przed naszym 
> kolejnym logowaniem. W połączeniu z wykładniczymi opoźnieniami (np 2^n 
> sekund gdzie n jest liczbą błędnych prób) już 4 kliknięcia (16 
> możliwości) poważnie utrudniają a 6-8 (64-256 możliwości) praktycznie 
> uniemożliwia sprawdzenie wszystkich kombinacji.
> Pin wystarczy podać raz po podłączeniu urządzenia do komputera. Nie jest 
> on w żaden sposób weryfikowany przez token.
> 
> Czy są jakieś uwagi co do tej metody? - mile widziane wytknięcie błędów 
> w rozumowaniu jak i miejsc dla możliwych przeoczeń w implementacji.

No więc mnie się cała koncepcja niezbyt podoba, z paru powodów. Jednym z
nich jest to, że wymagany jest specjalny moduł do PAM (podczas gdy moduł do
OPIE zwykle już masz w systemie, przynajmniej w Linuksie). Drugim to, że to
token, a nie serwer, wybiera numer sekwencyjny. Trzecim to, że jeśli PIN
jest opcjonalny, to jeśli się z niego nie korzysta, token może wykorzystać
każdy, kto na chwilę dostanie go w ręce ("jeżeli tylko" w punkcie 2 to jest
VERY BIG IF). Czwartym to, że w razie utraty tokena trzeba będzie
natychmiast zmienić seed (znaczy, ten ciąg losowy) po stronie serwera
(oczywiście rozwiązanie z hasłami na kartce też tę wadę posiada;
software'owy generator, np. w formie aplikacji w komórce, nie, jeśli do
generacji seedu wykorzystuje każdorazowo wprowadzany passphrase).
 
> W przypadku propozycji innych algorytmów liczenia hasha proszę pamiętać 
> o ograniczeniach:
> 1KB RAM
> 6KB wolnego FLASHa
> 512B EEPROM
> 12MHz
> brak sprzętowego dzielenia (tylko mnożenie)
> FPU jedynie emulowane.

SHA-256 nie jest chyba aż tak dużo bardziej złożone od MD5. MD5 w zasadzie
nie jest już uznawane za bezpieczne. 

-- 
Szymon Sokół (SS316-RIPE) -- Network Manager                                 B
Computer Center, AGH - University of Science and Technology, Cracow, Poland  O
http://home.agh.edu.pl/szymon/ PGP key id: RSA: 0x2ABE016B, DSS: 0xF9289982  F
Free speech includes the right not to listen, if not interested -- Heinlein  H

On 5 Kwi, 20:53, Michoo <michoo_n...@vp.pl> wrote:
> Szanowni grupowicze,
> chciałbym przedstawić "do recenzji" swój pomysł - mile widziane
> wszystkie uwagi odnośnie jego bezpieczeństwa jak i "okołoprojektowe".

W sumie to podobne do YubiKey http://www.yubico.com/products/yubikey/
Pomysł podobny choć detali implementacji różne.

Pozdrawiam!

--
Bartosz Małkowski

Bartosz Ma?kowski wrote:

> On 5 Kwi, 20:53, Michoo <michoo_n...@vp.pl> wrote:
>> Szanowni grupowicze,
>> chciałbym przedstawić "do recenzji" swój pomysł - mile widziane
>> wszystkie uwagi odnośnie jego bezpieczeństwa jak i "okołoprojektowe".
> 
> W sumie to podobne do YubiKey http://www.yubico.com/products/yubikey/
> Pomysł podobny choć detali implementacji różne.

Jesli mozna bedzie wymienic oprogramowanie. Bedzie mozna jak postulowalem 
WYPISAC informacje na ekranie (komunikacja w obie strony) 3 przyciski i 
przelacznik 4 stanowy (sa potrzebne rozne tryby i reset)

To masz w mojej osobie dobrego testera lub programiste. 
Powiedz kiedy zaczynasz.

Michoo <michoo_news@vp.pl> writes:

> Projekt ten to sprzętowy generator haseł jednorazowych służących do
> logowania po ssh (a właściwie to każdego via PAM).

Ale tak w ogole, wiesz jak to wyglada teoretycznie?
Teoretycznie takie urzadzenia sa bezuzyteczne :-)
W praktyce nie jest wiele lepiej, IMHO ich jedyne zastosowanie to praca
w sytuacji awaryjnej, gdy nie mamy dostepu do "bezpiecznego terminala",
i gdy kazdorazowo oceniamy ryzyko i wybieramy "mniejsze zlo".

Dlaczego? Bo haslo (logowanie sie itd) nie jest wartoscia sama w sobie,
ono tylko i wylacznie ma ograniczac dostep do czegos. Nie ma sensu
bardziej chronic hasla (logowania itd) niz samego dostepu (np. sesji).
Jesli nie uzywamy bezpiecznego terminala, sesja nie jest chroniona.

Jesli jednak uzywamy bezpiecznego terminala (tj. takiego, ktory jest
nasza wlasnoscia, o ktorym wiemy, ze np. nikt w nim nie grzebal w czasie
naszej nieuwagi itd), to caly ten patent z haslami moze byc czescia
terminala, i np. moze to byc po prostu logowanie kluczem asymetrycznym
w ssh, np. z jakims haslem na starcie do szyfrowanego systemu plikow,
zeby po utracie terminala nie bylo katastrofy.

> Ich głównymi
> zaletami jest brak dodatkowych urządzeń (generator w komórce albo
> lista na kartce).

Owszem. Ale biorac pod uwage, ze z tego nie wyjdzie zadne zastosowanie
"militarne", to pewnie taki generator i lista sa wystarczajaco
bezpieczne.

> Jako hasło generowane będzie md5 z:
> 1. losowego ciągu kilkudziesięciu znaków zapisanych w pamięci EEPROM - 
> jego zadaniem jest utrudnienie ataków brute-force, wyciągnięcie go z
> urządzenia jest teoretycznie niemożliwe (zmiana programu wymaga
> wyczyszczenia EEPROMu), chyba, że znajdzie się na nie (urządzenie)
> eksploit, no i jest potrzebny fizyczny dostęp

Czyli staly seed.

> 2. numeru sekwencyjnego - system będzie sprawdzał np 100 następnych
> haseł (albo znacznie mniej aby utrudnić ataki brute-force umożliwiając
> jednocześnie atak DOS) i po poprawnym zweryfikowaniu nie akceptował
> wcześniejszych tak więc wygenerowane w chwili nieuwagi właściciela
> hasło na nic się nie przyda jeżeli tylko się on zaloguje przed jego
> wykorzystaniem, przypadkowe wygenerowanie hasła też nie będzie
> problemem

Dosc typowe w niektorych zastosowaniach, gdzie ryzyko nie jest wielkie
(np. moj pilot do samochodu tak robi).

> 3. (opcjonalnie) kodu pin generowanego za pomocą naciskania 2
> przycisków - dodatkowe zabezpieczenie aby ktoś, kto "pożyczy" sobie
> token nie mógł się zalogować, ani wygenerować zestawu haseł do zużycia
> przed naszym kolejnym logowaniem. W połączeniu z wykładniczymi
> opoźnieniami (np 2^n sekund gdzie n jest liczbą błędnych prób) już 4
> kliknięcia (16 możliwości) poważnie utrudniają a 6-8 (64-256
> możliwości) praktycznie uniemożliwia sprawdzenie wszystkich
> kombinacji.

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.

Wykladnicze opoznienia to, z drugiej strony, potencjalnie bardzo powazny
problem, gdyz umozliwiaja odciecie dostepu prawdziwej uprawnionej osoby
(np. mozna uniemozliwic adminowi reakcje na wlasnie przeprowadzany
atak). Takie cos moze jest dobre, jesli wiadomo, ze takie odciecie nie
spowoduje zadnych powazniejszych skutkow, ale normalnie nie mozna tego
zalozyc.

> W przypadku propozycji innych algorytmów liczenia hasha proszę
> pamiętać o ograniczeniach

To nie tak, to procesor dobiera sie do potrzeb.
MD5 jest podatny na ataki (a) praktyczna latwosc generowania kolizji
oraz b) (mozliwe ze w dalszym ciagu niepotwierdzona w praktyce)
mozliwosc znalezienia takiego m' do danego m, by md5() obu byly
jednakowe).
"a" nie ma tu wielkiego znaczenia, "b" - to zalezy od szczegolow.
Tak czy owak MD5 w wielu dziedzinach zycia zostal wycofany, w innych
jest wycofywany, i chyba nigdzie nie jest polecany do nowych zastosowan.

> do urządzenia zostaje domontowany RTC (jest to pewien problem, gdyż
> tanie są niedokładne a dokładne są drogie i prawie niedostępne w
> Polsce, więc się nim zajmę tylko jeżeli otrzymam sample od Maxima)

Poleganie na dokladnosci takiego RTC to nie jest dobry pomysl.
Polegac mozna na monotonicznosci.
-- 
Krzysztof Halasa

Dzięki za odpowiedź.


Krzysztof Halasa pisze:
> Michoo <michoo_news@vp.pl> writes:
> 
>> Projekt ten to sprzętowy generator haseł jednorazowych służących do
>> logowania po ssh (a właściwie to każdego via PAM).
> 
> Ale tak w ogole, wiesz jak to wyglada teoretycznie?
> Teoretycznie takie urzadzenia sa bezuzyteczne :-)
> W praktyce nie jest wiele lepiej, IMHO ich jedyne zastosowanie to praca
> w sytuacji awaryjnej, gdy nie mamy dostepu do "bezpiecznego terminala",
> i gdy kazdorazowo oceniamy ryzyko i wybieramy "mniejsze zlo".
> 
> Dlaczego? Bo haslo (logowanie sie itd) nie jest wartoscia sama w sobie,
> ono tylko i wylacznie ma ograniczac dostep do czegos. Nie ma sensu
> bardziej chronic hasla (logowania itd) niz samego dostepu (np. sesji).
> Jesli nie uzywamy bezpiecznego terminala, sesja nie jest chroniona.

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).

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ę...).
> 
>> Ich głównymi
>> zaletami jest brak dodatkowych urządzeń (generator w komórce albo
>> lista na kartce).
> 
> Owszem. Ale biorac pod uwage, ze z tego nie wyjdzie zadne zastosowanie
> "militarne", to pewnie taki generator i lista sa wystarczajaco
> bezpieczne.
Ale mniej wygodne - na zajęciach nawiązuję kilka..kilkanaście połączeń 
ssh/sftp. Gdybym do każdego z nich miał szukać hasła na kartce, albo 
przepisywać kod do komórki a potem hasło z powrotem szybko by mi się 
znudziło. A tak podpinam token, wbijam pin a dalej wystarcza już jedno 
kliknięcie.

> 
>> Jako hasło generowane będzie md5 z:
>> 1. losowego ciągu kilkudziesięciu znaków zapisanych w pamięci EEPROM - 
>> jego zadaniem jest utrudnienie ataków brute-force, wyciągnięcie go z
>> urządzenia jest teoretycznie niemożliwe (zmiana programu wymaga
>> wyczyszczenia EEPROMu), chyba, że znajdzie się na nie (urządzenie)
>> eksploit, no i jest potrzebny fizyczny dostęp
> 
> Czyli staly seed.
Tak.

Jego główne zadanie to uniemożliwienie ataku brute-force na pin (który 
nie będzie miał raczej więcej niż 2 bajty).

Jeżeli ktoś będzie w stanie odczytać seed to będzie też w stanie 
przeprogramować tą zabawkę tak, żeby zalogowała pin. A potem zrobić 
duplikat.

>> 3. (opcjonalnie) kodu pin generowanego za pomocą naciskania 2
>> przycisków - dodatkowe zabezpieczenie aby ktoś, kto "pożyczy" sobie
>> token nie mógł się zalogować, ani wygenerować zestawu haseł do zużycia
>> przed naszym kolejnym logowaniem. W połączeniu z wykładniczymi
>> opoźnieniami (np 2^n sekund gdzie n jest liczbą błędnych prób) już 4
>> kliknięcia (16 możliwości) poważnie utrudniają a 6-8 (64-256
>> możliwości) praktycznie uniemożliwia sprawdzenie wszystkich
>> kombinacji.
> 
> 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ę.

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.

> 
> Wykladnicze opoznienia to, z drugiej strony, potencjalnie bardzo powazny
> problem, gdyz umozliwiaja odciecie dostepu prawdziwej uprawnionej osoby
> (np. mozna uniemozliwic adminowi reakcje na wlasnie przeprowadzany
> atak). Takie cos moze jest dobre, jesli wiadomo, ze takie odciecie nie
> spowoduje zadnych powazniejszych skutkow, ale normalnie nie mozna tego
> zalozyc.
Tak, istnieje możliwość DODu, przy czym:
a) opóźnienia można generować per ip (tu się osłabia metodę, bo ktoś 
może użyć choćby neostrady, czy kolejnych komputerów w naszym laboratorium).
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ć.
c) w moim przypadku opóźnienie jest nawet szkodliwe i go nie zastosuję - 
im szybciej się delikwent nadzieje na DenyHosts tym lepiej.
> 
>> W przypadku propozycji innych algorytmów liczenia hasha proszę
>> pamiętać o ograniczeniach
> 
> To nie tak, to procesor dobiera sie do potrzeb.
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.

> MD5 jest podatny na ataki (a) praktyczna latwosc generowania kolizji
> oraz b) (mozliwe ze w dalszym ciagu niepotwierdzona w praktyce)
> mozliwosc znalezienia takiego m' do danego m, by md5() obu byly
> jednakowe).
> "a" nie ma tu wielkiego znaczenia, "b" - to zalezy od szczegolow.
Wydaje mi się, że też nie - wg mnie jedyna słabość algorytmu haszującego 
wykładająca to rozwiązanie to możliwość (być może na podstawie wielu 
haszy) odtworzenia seeda i pinu.

> Tak czy owak MD5 w wielu dziedzinach zycia zostal wycofany, w innych
> jest wycofywany, i chyba nigdzie nie jest polecany do nowych zastosowan.
A jakieś inne proste funkcje haszujące dające wynik powyżej 10 bajtów? 
Mogę od biedy nawet whirpool'a tam wsadzić, ale wydaje mi się to 
przerostem formy nad treścią tak długo jak długo spełniony jest 
poprzedni punkt.

> 
>> do urządzenia zostaje domontowany RTC (jest to pewien problem, gdyż
>> tanie są niedokładne a dokładne są drogie i prawie niedostępne w
>> Polsce, więc się nim zajmę tylko jeżeli otrzymam sample od Maxima)
> 
> Poleganie na dokladnosci takiego RTC to nie jest dobry pomysl.
> Polegac mozna na monotonicznosci.
Tokeny RSA jakoś polegają ;)
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. Przy oknie 1.5 minuty myślę, że ewentualna 
synchronizacja tokena raz na pół roku załatwi sprawę.

-- 
Pozdrawiam
Michoo

Szymon Sokół pisze:
> On Mon, 05 Apr 2010 20:53:07 +0200, Michoo wrote:

>> Czy są jakieś uwagi co do tej metody? - mile widziane wytknięcie błędów 
>> w rozumowaniu jak i miejsc dla możliwych przeoczeń w implementacji.
> 
> No więc mnie się cała koncepcja niezbyt podoba, z paru powodów. Jednym z
> nich jest to, że wymagany jest specjalny moduł do PAM (podczas gdy moduł do
> OPIE zwykle już masz w systemie, przynajmniej w Linuksie).
Opie też jakoś zaczynało. Projekt miałem zamiar zrealizować na własny 
użytek, ale potem przyszło mi do głowy, że a nóż się komuś jeszcze przyda.

> Trzecim to, że jeśli PIN
> jest opcjonalny, to jeśli się z niego nie korzysta, token może wykorzystać
> każdy, kto na chwilę dostanie go w ręce
Tak, ale wg mnie nie należy zabraniać posiadania nożyczek z ostrymi 
czubkami tylko dlatego, że się ktoś może nimi pociąć.

Tokeny RSA działają w taki sposób a są reklamowane jako bardzo 
bezpieczne rozwiązanie.

> Czwartym to, że w razie utraty tokena trzeba będzie
> natychmiast zmienić seed (znaczy, ten ciąg losowy) po stronie serwera
> (oczywiście rozwiązanie z hasłami na kartce też tę wadę posiada;
> software'owy generator, np. w formie aplikacji w komórce, nie, jeśli do
> generacji seedu wykorzystuje każdorazowo wprowadzany passphrase).
Tak. Pin został pomyślany właśnie na wypadek utraty tokena. Brak 
mechanizmu challenge-response ma skrócić czas logowania.

Gdyby nie zależało mi na czasie i małych rozmiarach to bym dał 
klawiaturę i wprowadzało by się najpierw hasło a potem challenge.

>> W przypadku propozycji innych algorytmów liczenia hasha proszę pamiętać 
>> o ograniczeniach:
>> 1KB RAM
>> 6KB wolnego FLASHa
>> 512B EEPROM
>> 12MHz
>> brak sprzętowego dzielenia (tylko mnożenie)
>> FPU jedynie emulowane.
> 
> SHA-256 nie jest chyba aż tak dużo bardziej złożone od MD5. MD5 w zasadzie
> nie jest już uznawane za bezpieczne. 
W tym zastosowaniu chyba jego wady nie będą problemem (OPIE też używa 
md5), ale fakt, sha wydaję się być ciekawym rozwiązaniem - dzięki za 
sugestię.


-- 
Pozdrawiam
Michoo

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