Discussion:
klucz prywatny w 100 godzin...
(Wiadomość utworzona zbyt dawno temu. Odpowiedź niemożliwa.)
Cezar
2010-03-05 08:48:37 UTC
Permalink
za pomoca 81 blaszakow...
http://www.eecs.umich.edu/~valeria/research/publications/DATE10RSA.pdf

c.
Michoo
2010-03-05 10:07:56 UTC
Permalink
Post by Cezar
za pomoca 81 blaszakow...
http://www.eecs.umich.edu/~valeria/research/publications/DATE10RSA.pdf
The fault-based attack that we developed in this work exploits
hardware faults injected at the server side of a public key authenti-
cation (see Figure 1.b). Specifically, we assume that an attacker can
occasionally inject faults that affecting the result of a multiplication
computed during the execution of the fixed-window exponentiation
algorithm. Consequently, we assume that the system is subjected to
a battery of infrequent short-duration transient faults, that is, faults
whose duration is less than one clock cycle, so that they impact
at most one multiplication during the entire execution of the expo-
nentiation algorithm. Moreover, we only consider hardware faults
that produce a multiplication result differing from the correct one
in only one bit position, and simply disregard all others.
Czyli zakładając, że możemy generować bardzo specyficzne zakłócenia dla
zasilania w bardzo specyficznym momencie możemy być w stanie otrzymać
dane z których możemy odzyskać klucz.

1. Właściwie każda płyta główna ma stado kondensatorów filtrujacych i
specyficzne stabilizatory. Wygenerowanie zakłóceń o odpowiednim
charakterze bez podpinania się bezpośrednio do zasilania rdzenia jest
chyba niemożliwe. Po podpięciu się mamy nadal do czynienia z
kondensatorami leżącymi w bezpośredniej bliskości procesora - sprzęt
podatny na atak musi być bardzo specyficzny.

2. Musimy mieć dużo szczęścia, żeby takie zakłócenie nie skończyło się
padem systemu - ciężko jest "trafić" zakłóceniem tak, żeby dostać błędny
wynik mnożenia a nie np błędną instrukcję po której program zostanie
zamknięty albo system się zawiesi.

3. Jeżeli dostajemy się do sprzętu bezpośrednio to dużo łatwiej podpiąć
się bezpośrednio do pamięci ram, czy wręcz ją wyjąć i odczytać klucz.
--
Pozdrawiam
Michoo
Cezar
2010-03-05 10:26:30 UTC
Permalink
Post by Cezar
za pomoca 81 blaszakow...
http://www.eecs.umich.edu/~valeria/research/publications/DATE10RSA.pdf
To nie tylko ciekawostka. Jest wiele urzadzen typu embeded, ktore klucz
prywatny maja przechowywany w chronionej czesci xROMu. Masz dostep do jego
zasilania wiec mozesz nim dowolnie manipulowac.

c.
Michoo
2010-03-05 12:49:18 UTC
Permalink
Post by Cezar
Post by Cezar
za pomoca 81 blaszakow...
http://www.eecs.umich.edu/~valeria/research/publications/DATE10RSA.pdf
To nie tylko ciekawostka. Jest wiele urzadzen typu embeded, ktore klucz
prywatny maja przechowywany w chronionej czesci xROMu. Masz dostep do
jego zasilania wiec mozesz nim dowolnie manipulowac.
Nadal bez dużej ingerencji będzie problem z odpowiednim manipulowaniem
zasilaniem - specjalnie daje się nano/piko-faradowe kondensatory aby
odciąć zakłócenia generowane w każdym cyklu.

Ale fakt, nie spojrzałem na to z tej strony. I rzeczywiście w przypadku
jakiegoś ARMa działającego ~100MHz to może być realizowalne bo wtedy też
filtrowanie będzie trochę gorsze.
--
Pozdrawiam
Michoo
Krzysztof Halasa
2010-03-06 11:49:42 UTC
Permalink
Post by Cezar
za pomoca 81 blaszakow...
http://www.eecs.umich.edu/~valeria/research/publications/DATE10RSA.pdf
To ze takie rzeczy mozna robic wiadomo od wielu lat, nawet na kartach
z DESem takie rzeczy robiono. Procesory staraja sie robic reset itp. po
wykryciu nienormalnych parametrow, i tyle. Calkiem tego problemu
wyeliminowac sie nie da, mozna tylko utrudniac proby.
--
Krzysztof Halasa
Kontynuuj czytanie narkive:
Loading...