🚀 go-pugleaf

Cezar pisze:
> za pomoca 81 blaszakow...
> http://www.eecs.umich.edu/~valeria/research/publications/DATE10RSA.pdf
Ciekawostka, ale raczej nic więcej. Kluczowy jest następujący akapit:

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

"Michoo" <michoo_news@vp.pl> wrote in message 
news:hmql3p$5dm$1@news.onet.pl...
> Cezar pisze:
>> za pomoca 81 blaszakow...
>> http://www.eecs.umich.edu/~valeria/research/publications/DATE10RSA.pdf
> Ciekawostka, ale raczej nic więcej. Kluczowy jest następujący akapit:


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.

Cezar pisze:
> 
> "Michoo" <michoo_news@vp.pl> wrote in message 
> news:hmql3p$5dm$1@news.onet.pl...
>> Cezar pisze:
>>> za pomoca 81 blaszakow...
>>> http://www.eecs.umich.edu/~valeria/research/publications/DATE10RSA.pdf
>> Ciekawostka, ale raczej nic więcej. Kluczowy jest następujący akapit:
> 
> 
> 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

"Cezar" <cezar91@BEZtlen.pl> writes:

> 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