Rdzeń 8051 do wbudowania w FPGA

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.

Reply to
Pszemol
Loading thread data ...

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.

Reply to
Artur M. Piwko

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.

Reply to
Marcin E. Hamerla

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.

Reply to
Pszemol

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

Reply to
Adam Dybkowski

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.

Reply to
Adam Dybkowski

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.

Reply to
Artur M. Piwko

Adam Dybkowski napisał(a):

Jesli komus bardzo zalezy, to rowniez odczyta zawartosc zabezpieczonego procka, zobacz np.

formatting link
Pozdr AK

Reply to
AK

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.

Reply to
Adam Dybkowski

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.