No, nawet jest rysunek jak to zrobić :-) Z tym że autor twierdzi że przygotowanie wsadu dla programatora z tak zripowanego bitstrimu jest czasochłonne. Czyli kosztowne. A gdy połączy się kilka technik to będzie bardzo kosztowne. IMO z tych zaproponowanych metod najlepszą jest podział projektu między FPGA i CPLD.
regards, /J.D.
On 25 Feb 2005 20:18:38 +0100, Jan Dubiec snipped-for-privacy@SPAMTRAP.slackware.pl> wrote: [.....]
No i wyczytałem sobie: niestety, klucze są przechowywane w specjalnym kawałku RAMu podtrzymywanym bateryjką. Ale podobno bateryjka trzyma długo. :-)
Regards, /J.D.
I bardzo dobrze - wtedy bedziemy juz sprzedawali nastepna rodzine, gdzie bedzie to samo, ale jednak pare bitow klucza zmienionych :-)
Ale tu bedzie konkretne zastosowanie, i to imho da sie opatentowac.
W kazdym badz razie na tyle zeby konkurencyjny producent pamieci musial zaplacic za licencje :-)
J.
mozan to podsluchac na nozkach FPGA, chociaz zawsze jakies utrudnienie
W artykule <cvpqsl$6o4$ snipped-for-privacy@news.onet.pl> greg napisal(a):
Podsluchanie bezposrednio nic ci nie da, jesli wysylasz losowy ciag danych. Musialbys na podstawie ilus tam probek dane -> mieszane dane wydumac postac funkcji mieszajacej. Pod warunkiem, ze zorientujesz sie o co w ogole chodzi. Dla utrudnienia mozna na przyklad wysylac n bitow, z ktorych tylko m (<n) tworzy klucz. W odpowiedzi wyslac znow n bitow, w tym m istotnych.
Najslabszym punktem jest sam bitstream, ktory nadal da sie odczytac, ale zrekonstruowanie tej funkcji mieszajacej na podstawie bitstreamu to tez calkiem powazna trudnosc.
Pozdrawiam Krzysiek
Pomylily sie rodzinki scalakow tylko :-)
Ale juz wszystko sie wyjasnilo. Siakas pomrocznosc jasna mnie dopadla. A raczej pomrocznosc 'ciemna', bo po ciemnym piwku :-)
Z drugiej strony - IMHO niemozliwe jest (znaczy ja wiem co jest niemozliwe, hehe) albo baaardzo trudne zrobienie kroku z bitstreamu fpga do schematu ukladu. No bo co z tego, ze bedziem mieli schemat z miliona bramek? Kto nam to podzieli na siakies bloczki wieksze i mniejsze zeby zlapac obraz calosci - jak to dziala i co projektant mial na mysli (a to czasem nie jest oczywiste). Poza tym bitstream jest juz po optymalizacji, a ta pewnie produkuje dosc dziwne konstrukcje. Chyba ze ktos zrobi 1:1 kopie plytki (a w zasadzie to pewnie calego urzadzenia). Nawet jak zrobi - i tak ma 0 mozliwosci zmiany czegokolwiek.
Nigdy nie analizowales cudzego schematu ? Fakt ze milion moze byc problemem :-)
A Odre ponoc z dokumentacji zaprojektowali od nowa, ale fakt ze to moze latwiejsze.
I o to chodzi.
Jak urzadzenia sprzedaje to ma juz czas i pieniadze na druga wersje ..
J.
On Sat, 26 Feb 2005 15:36:25 +0000, jerry1111 snipped-for-privacy@wp.pl wrote: [.....]
Tez tak uważam. Dlatego osobiście za bardzo się nie przejmuję brakiem zabezpieczeń software'u w niektórych uC i PLD.
Czytałem jakieś papiery nt. zabezpieczania IP i wg. autorów problem klonerów jak najbardziej istnieje i nie jest pomijalny.
Regards, /J.D.
Nie bardzo rozumiem jakim cudem - jak bedziemy spisywac z ekranu to moze, ale przeciez sobie program napiszemy do tego.
J.
W artykule snipped-for-privacy@4ax.com J.F napisal(a):
Program jest w stanie odtworzyc strukture bramek. Najmniejszy Spartan 3 to 50k "bramek". Opis na poziomie bramek jest w zasadzie tak samo czytelny jak bitstream... Pozdrawiam Krzysiek
czyzbys w ramach rozrywki proponowal wrzucic Odre w FPGA? ;-)
No - byloby to moze i ciekawe :-)
Ale ja nie mam szacunku dla staroci - mozna zrobic, ale po co ? :-)
J.
Ale do skopiowania urzadzenia zywcem nie trzeba sie interesowac co tam jest wpisane. A jak trzeba - to nie ma sensu wstawiac cpld do szyfrowania, bo problem jest i tak wystarczajaco trudny.
J.
A jakim odtwarzaniu struktury bramek mowisz? :o) Chodzi o proste skopiowanie obrazu konfiguracyjnego, a nie rozgryzanie, co i w jaki sposob zostalo zrobione
-- to nikogo nie obchodzi, do skutecznego klonowania nie potrzeba nawet znajomosci elektroniki. :-)
Pozdrawiam Piotr Wyderski
W artykule <cvr7ud$ok$ snipped-for-privacy@news.dialog.net.pl> Piotr Wyderski napisal(a):
Absolutnie sie zgadzam, chyba zastosujesz klucz sprzetowy
-- dodatkowo polozysz na plycie proste CPLD, tak jak sugerowalem pare postow wczesniej. Wtedy juz tego nie da sie sklonowac bezposrednio, bez rozebrania CPLD lub modyfikacji bitstreamu. Pozdrawiam Krzysiek
W artykule snipped-for-privacy@4ax.com J.F napisal(a):
CPLD z funkcja mieszajaca zapobiega skopiowaniu zywcem calkiem skutecznie. Roznica jest taka, ze bez tego CPLD jestem w stanie skopiowac design w zasadzie bez zadnych dodatkowych srodkow finansowych/technicznych. Z CPLD problem przerasta mozliwosci przecietnego polskiego/rosyjskiego/chinskiego "malego przedsiebiorcy". Pozdrawiam Krzysiek
No wlasnie ze nie zapobiega - zapisze bitstream ktory z cpld _wychodzi_, wpisze do kostki, omine cale cpld. I zajmie mi to gora pare dni, a potem nawet bedzie trudno zarzucic ze to kopia, bo przeciez inna od oryginalu.
Potrzebny do tego tylko sprzet ktory nagra bitstream - w ciagu tych paru dni minus 1 go sobie zlutuje, o ile nie mam gotowego ..
J.
To sie odnosi do proponowanexo przez Xilinx "zabezpieczenia", ale Krzysztof proponuje cos innego: jawny bitstream + badanie odpowiedzi tajnego ukladu w CPLD. To rzeczywiscie ma szanse odstraszyc niezbyt zaawansowanych kopistow. Tylko zostaje jedna sprawa: skad wziac losowe ziarno do inicjalizacji generatora liczb pseudolosowych w FPGA?
Pozdrawiam Piotr Wyderski
Znaczy sie - zabezpieczenie konstrukcji w FPGA przy pomocy "sprzetowego klucza" na CPLD ? To ma szanse dzalac.
W CPLD zaimplementowac :-)
J.
Wlasnie tak.
A skad CPLD go wezmie? Tylko prosze mi tu nie sugerowac RTC, bo uklad zabezpieczajacy zrobi sie wiekszy od zabezpieczanego. :-)
Pozdrawiam Piotr Wyderski
Have something to add? Share your thoughts — no account required.
Ask the community — no account required