Zabezpieczenie zawartosci FPGA

Witam,

w jaki sposob zabezpiecza sie zawartosc obrazow konfiguracyjnych FPGA przed niedozwolonym kopiowaniem? Wiem, ze kazde zabezpieczenie da sie zlamac przy dostatecznym nakladzie sil i srodkow, ale zapewne istnieja jakies sposoby utrudniania takiego procederu. Niestety w przypadku ukladow z zewnetrznym ROMem konfiguracyjnym (w odroznieniu od antifuse) zadne zabezpieczenie nie przychodzi mi do glowy.

Pozdrawiam Piotr Wyderski

Reply to
Piotr Wyderski
Loading thread data ...

Piotr Wyderski napisal(a):

Sa kosci kodowane. Ale ZTCP trzeba troche zamowic takich FPGA. Dostajesz wtedy oczywiscie klucz do kodowania zawartosci seprom. W FPGA siedzi zas dekoder.

Reply to
Marcin E. Hamerla

Marcin E. Hamerla napisal(a):

Aha, FPGA Actela maja pamiec w srodku.

Reply to
Marcin E. Hamerla

O, to byloby rozwiazanie. Czy wiesz moze, gdzie mozna kupic pojedyncze sztuki ukladow tej firmy do prototypu, a jesli wypali, to dokonac wstepnego niewielkiego zakupu hurtowego (~100 szt.)?

Pozdrawiam Piotr Wyderski

Reply to
Piotr Wyderski

W Gliwicach (MSC Polska). Dz.

Reply to
Dziadek

  1. Użyć FPGA z wewnętrznym Flashem zamiast SRAM-u (np. ProASIC+ i ProASIC3 Actela (nie wiem czy te ostatnie są już dostępne); Lattice też ma jakąś rodzinę "flaszowalnych" FPGA),
  2. Poczekać na FPGA potrafiące konfigurować się z zaszyfrowanego bitstrimu - AFAIK wiodący producenci (TM) już nad tym pracują. Swoją drogą ciekawe jak chcą to osiągnąć? Kilkanaście/dziesiąt bajtów Flasha wewnątrz FPGA na zapisanie klucza (de)szyfrującego?

Najlepiej popytaj kolesi z comp.arch.fpga.

Regards, /J.D.

Reply to
Jan Dubiec

Cyclone mozna zakodowac wpisujac klucz do FPGA (wtedy trza podtrzymanie bakteryjne zrobic). 'Wsad' do kosci jest zaszyfrowany i trzymany w zewnetrznej pamieci konfiguracji (EPCS1/EPCS4). Podczas ladowania konfiguracji Cyclone sobie rozszyfrowuje bity. Aha - ja tego nie probowalem (nie bylo potrzeby).

Reply to
jerry1111

Mozesz wskazac jakies zrodlo tych informacji? Cyclone Handbook nic nie mowi o mozliwosci kodowania pamieci konfiguracyjnej, Google tez nic wartego uwagi nie zwrocil.

Pozdrawiam Piotr Wyderski

Reply to
Piotr Wyderski

W zasadzie nie trzeba. fpga generuje losowy klucz, wysyla do pamieci, pamiec tym szyfruje i wysyla. Dobrze dobrany algorytm szyfrowania zeby sie nie dalo szybko odczytac tresci niezaszyfrowanej z szyfrowanej i klucza. Dwa patenty i nie ma zadnej konkurencji, ops, jeden patent, bo deszyfratora nie mozna ujawnic :-)

J.

Reply to
J.F.

Aj! Opieranie bezpieczenstwa schematu kryptograficznego na tajnosci algorytmu szyfrowania/deszyfrowania to blad podrecznikowy numer 1.

Reply to
myst1

pewnei komus sie pomylilo z kompresja..jednakze ta nei rozwiazuje problemu..

Reply to
greg

Czyli trzeba wzywać serwis do wymiany baterii w urządzeniu które wykorzystuje takie rozwiązanie. Trochę to słabe. :-)

Regards, /J.D.

Reply to
Jan Dubiec

Ale do rozkompresowania strumienia skompresowanego Lempel Ziv-em 77 lub podobnym algorytmem nie trzeba przechowywać żadnych kluczy czy czegoś w tym stylu w pamięci nieulotnej. Aż tak Jerry pomylić się nie mógł. No chyba że jest właśnie podczas spożycia. ;-)

Regards, /J.D.

Reply to
Jan Dubiec

On Fri, 25 Feb 2005 17:02:02 +0100, "CosteC" snipped-for-privacy@konto.nielubiespamu.pl> wrote: [.....]

Ano rzeczywiście, Virtex-y mają taki feature. A pewnie i Stratix-y Altery też mają coś takiego. W każdym bądź razie to nie mój poziom. Na razie. ;-)

Wiesz może jak to jest zrealizowane? Tzn. w jaki sposób jest przechowywany klucz (de)szyfrujący? Jakiś EEPROM w postaci np. drugiej struktury wsadzonej do kości? No bo rozwiazanie z podtrzymaniem bateryjnym to IMO do bani jest.

Regards, /J.D.

Reply to
Jan Dubiec

On Fri, 25 Feb 2005 18:22:21 +0100, J.F. <jfox snipped-for-privacy@poczta.onet.pl> wrote: [.....]

Kolega myst1 już napisał że security by obscurity to słaby pomysł. Bo wcześniej czy później taki algorytm zostanie ujawniony. Jeśli nie przy pomocy metod analitycznych, to np. za pomocą social engineering. Poza tym patenty na algorytmy nie maja mocy w Europie (i mam nadzieję że nie będą miały) i np. w Chinach. :-) A do tego, jeśli chodzi o kryptografię, to w tej dziedzinie wszystko, co dało się opatentować, zostało opatentowane. :-)

Regards, /J.D.

Reply to
Jan Dubiec

Ten pomysł jest ciekawy:

formatting link
Regards, /J.D.

Reply to
Jan Dubiec

W artykule <cvnd5p$8uc$ snipped-for-privacy@news.onet.pl> jerry1111 napisal(a):

formatting link
Jesli duze FPGA nie ma mozliwosci zaszyfrowania bitstreamu, to mozna zrobic "klucz sprzetowy" w postaci dodatkowego prosciutkiego CPLD na pokladzie. W CPLD i FPGA zaimplementowac taka sama funkcje mieszajaca. Potem przepuscic przez obie funkcje losowy ciag danych i porownac wynik w FPGA. Jesli sie zgadza - dzialac dalej, jesli nie -- zapetlic pare negacji lub wymyslic jakas bardzie zaawansowana metode autodestrukcji ;)

Dodatkowy koszt to troche miejsca na plycie i pewno z $2. Pozdrawiam Krzysiek

Reply to
Krzysztof Olesiejuk
Reply to
Piotr Wyderski

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.