Zabezpieczenie zawartosci FPGA

Feb 25, 2005 40 Replies

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


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.

Marcin E. Hamerla napisal(a):

Aha, FPGA Actela maja pamiec w srodku.

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

W Gliwicach (MSC Polska). Dz.

  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.

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

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

w jaki sposob zabezpiecza sie zawartosc obrazow

IMHO Xilinx ju¿ takie robi. bitsteram jest kodowany i jako taki siedzi w jakiej¶ pamiêci zew.

CosteC

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.

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

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

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

Regards, /J.D.

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.

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.

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.

Ten pomysł jest ciekawy:

formatting link
Regards, /J.D.

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

formatting link
Nie rozumiem jak to moze cokolwiek zabezpieczac -- wystarczy wpiac sie analizatorem logicznym na linie DATA i DCLK i z skopiowac sobie rozkodowany strumien... :-)

Pozdrawiam Piotr Wyderski

Nie.:) go¶æ nam mówi³ na wyk³adzie z wieloprocesorowych systemów wizyjnych przy okazji tego jak sie zachwyca³ Virtexem II Pro. Ale moge sie dowiedzieæ. Musi to byæ robione raczej skutecznie skoro sam VIIP kosztuje jakie¶ 2k$ to program na niego jako¶ wiecej wiêcej. Zapytam go¶cia przy okazji.

CosteC

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required