ok :-)
I pracują tak szybko że rezystory nie wystarczą ? Cyclone II ma we/wy odporne na 5V jak dasz opornik ograniczający prąd. W książce do Cyclone I jest to opisane, zdaje się przy PCI, a w książce do Cyclone II tego rozdziału już nie ma bo Altera forsuje odejście od
5V :-) Ale z tego co się dowiedziałem, parametry elektryczne pinów to Cyclone II ma identyczne z tymi w Cyclone I.Tak jest.
In the darkest hour on Sun, 26 Feb 2006 13:42:48 +0100, J.F <jfox snipped-for-privacy@poczta.onet.pl> screamed:
SBO to zawsze kolejny poziom zabezpieczen.
Pszemol napisal(a):
Mam serie takich kart w ktorych pierwotnie zasililismy ACEXa tylko przy pomocy jednego napiecia 2.5V. Z trzech wzgledow, ale mniejsza o nie. Z wejsciami nie bylo problemow ze wzgledu na 5V tolerant. Na wyjsciach Altery mialy byc open drainy i na zewntarz rezystory podciagajace do 5V. Niestety trzeba bylo uklad przerabiac na zasilanie I/O z 3.3V, bo oporniki trzeba bylo dawac bardzo male - ~200 ohm aby to sensownie dzialalo przy 25MHz. A i tak zbocza narastajace sygalow wyjsciowych byly takie sobie. Nie dam sie znow namowic na oporniki.
Czy ktoś posiada jakieś "disasemblery" bitstreamów programujących FPGA ? Bo jeśli nie, to masz wystarczające SBO w samym zakodowaniu proca, logiki, i bootloadera w jednym bitstreamie.
J.F. napisał(a):
Innego kodu oprócz samych algorytmów kryptograficznych jest cała masa. A jako że nie ma programów bezbłędnych - lepiej nie pomagać w wykryciu potencjalnej dziury omijającej nawet najlepsze algorytmy. Poza tym dobry algorytm szyfrowania to taki, co wykorzystuje znane i sprawdzone standardy (np. 3DES) plus dodatkowe własne manglowanie danymi. Gdy za 10 lat Chińczyki złamią podstawowy algorytm szyfrowania, urządzenie będzie nadal bezpieczne. Akurat w tej dziedzinie nieujawnianie źródeł softu jest zaletą.
Pszemol napisał(a):
A może jednak posiada? Jeżeli z bitstreamu da się wygenerować spowrotem plik JEDEC (czy co tam stosuje Altera, rbf) - to znając architekturę wewnętrzną kostki można w prosty sposób utworzyć równania opisujące jej działanie. To oczywiście będzie bardzo rozbudowany zestaw, ale dający się wepchnąć do symulatora i wypróbować reakcję kostki na różne pobudzenia (znacznie szybciej niż testować elektrycznie konkretny zaprogramowany scalak). Idąc dalej - z powtarzających się zestawów równań i na podstawie listy połączeń między komórkami FPGA oraz przy dobrej znajomości tego, co wypluwa kompilator+fitter można wygenerować podstawowe bloczki wyższego poziomu (liczniki, rejestry, obliczenia arytmetyczne). Jeżeli komuś bardzo zależy, ma kupę $$$ i czasu to wszystko da się zrobić.
Dlatego podstawowa zasada to chronić binaria przed odczytem.
In the darkest hour on Sun, 26 Feb 2006 14:34:20 -0600, Pszemol snipped-for-privacy@PolBox.com screamed:
Szczerze mowiac nigdy nie sprawdzalem, czy format zapisu danych konfigurujacych bramki jest jawny.
Adam Dybkowski napisał(a):
Jesli komus bardzo zalezy, to rowniez odczyta zawartosc zabezpieczonego procka, zobacz np.
AK napisał(a):
Jasne. Ale im więcej utrudnień tym lepiej. Dane krytyczne (np. klucze szyfrowania) można np. przechowywać w pamięci EEPROM. Jeżeli procesor wykryje otwarcie obudowy (wystarczy kilka włączników w kluczowych miejscach, jeszcze lepiej siatka rezystancyjna nalepiona od wewnątrz całej obudowy), klucze są kasowane i po krzyku (można skasować też cały firmware). Oczywiście po takiej akcji urządzenie nadaje się już tylko do zwrotu do producenta, a tam raczej otwieranie obudowy nie pozostanie niezauważone.
Have something to add? Share your thoughts — no account required.
Ask the community — no account required