🚀 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