Wybór mikrokontrolera do klucza sprzętowego USB z FT232BM - porady i sugestie

Witam wszystkich. Zwracam sie z prosba o udzielenie porady. Chcialbym zbudowac klucz sprzetowy sluzacy do zabezpieczania oprogramowania. Ma byc to uklad na USB, zakupillem juz FT232BM (z tego co czytalem na poczatek bedzie OK). Moja idea jest taka aby czesc kodu, wymagana do uruchomienia programu znajdowala sie w pamieci klucza. Sama komunikacja programu z pamiecia klucza musi byc szyfrowana, jednak algorytm szyfrowania to nie problem. Dla mnie stanowi problem jakiego mikrokontrolera moglbym do tego uzyc, w czym to pisac... Nie wiem tez jakby to mialo wygladac,a dokladnie jak mam zaszyc w pamieci ukladu czesc kodu potrzebna do uruchomienia progsa... Wydaje mi sie ze moze jakas biblioteke dll by trzeba bylo napisac... A glownie chodzi mi o to jakiego mikrokontrolera moge uzyc do tego projektu.. Z tego co czytalem na forum jest mnóstwo ludz ze sporym doswiadczeniem i do nich wlasnie zwraca sie z prosba... A moze macie jakis lepszy pomysl...Bardzo prosze o kilka slow i pomoc... Bardzo mi na tym zalezy...Pozdrowienia dla wszystkich![/b]

Do komunikacji z FT232BM możesz zastosować teoretycznie i każdy procek. Wszystko zależy ile kodu chcesz w nim ukryć to będzie decydowało o jego pamięci wewnętrznej. Dla przykładu ATmega128 ma pamięć 128kb. W tej pamięci umieszczasz program obsługi, komunikacji i dekodowania, a reszta zostanie Ci na program. To rozwiązanie jest o tyle kożystne że wszystko lokujesz w jednej kostce i jest dosyć trudne do złamania dzięki bitom blokady oprogramowania. Wszystkie te dane umieszczasz w procku, oraz zabezpieczenie, oczywiście programatorem ISP, który obsługuje te procki.

Dobrą metodą byłoby podłączenie do FT8U jakiegoś prostego procka, np AT90S2313 i pogonienie prędkości transmisji, do wysokiej szybkości (uniemożliwi to podrobienie klucza przez klucz pod port RS232) i niestandardowej, co zabezpieczy transmisje przed skanowaniem. dla przykładu 136Kbaud takiej nikt się nie będzie spodziewał Oczywiście to tylko przykład. Dobry efekt daje też tablicowe ustalenie częstotliwości UART'a co praktyce sprowadza się do tego że po przekazaniu zaszyfrowanego komunikatu, kompyter i klucz przechodzą na niestandardową szybkość transmisji znaną tylko przez program i procesor

Praktycznie, nawet nie jest Tobie potrzebny mikroprocesor po drugiej stronie. W notach aplikacyjnych FTDI jest, jak sterowac "bitowo" wyjścia FT232. Podłącz pod niego od razu jakąś pamięć Flash, np :DataFlash Atmela, czy inną, zawierającą koniecznie ! zaszyfrowaną część programu. Wystarczy napisać tylko driver do jej odczytu. Polecam Dataflash, lub SPI Flash (AT25F512) bo dla równoległej pamięci będzie za mało pinów we/wy we FT232.
Uwaga: układ ma wadę ! .... można skopiować pamięć ... i podrobić klucz.

Można też inaczej.
Pominąć układ FT232 i podłączyć bezpośrednio AVR'a do magistrali USB. Wystarczy lekko zmodyfikować układ naszego południowego sąsiada http://www.cesko.host.sk/IgorPlugUSB_RS232/IgorPlug-USB%20(AVR)%20RS232_eng.htm
W wersji z ATMega8 jeszcze sporo wolnego miejsca we Flashu, a zawsze możesz zastosować ATMEga128.
Jeżeli zależy Tobie na bezpieczeństwie, a nie tylko na "utrudnieniu kopiowania" to nadaje się tylko drugie rozwiązanie.

Co do kluczyków, po pierwsze primo trzeba by zobaczyć jak robię to ci, co już to robią.
Układowo mogę jeszcze podsunąć PDIUSBD1X Philips’a, Kość z USB i Slave I2C. Niedroga.
Gdzieś czytałem o udanym ataku na "zabezpieczonego" PIC'a, przy pomocy wiertarki, biletu autobusowego, mikroskopu i kwarcówki . "Bezpieczniejsze" pod tym względem są układy CPLD.
A czy nie jest tak, że znacznie prościej będzie podsłuchiwać po stronie PC, szczególnie w Windows?

Zastosuj pastylkę dallasa ma unikalny 64 bitowy numer.

Ale ogólnie nie masz co przesadzać ... Xitami ma jak najzupełniej racje. Sam mam program, który robi "zrzut pamięci" już po wczytaniu danych z klucza. Lepiej więc zastosuj inną metodę. Nie ładuj do programu części kodu, tylko często"odpytuj" klucz. Wysyłasz do niego (rnd) jakąś liczbę, on odpowiada. Algorytm generowania odpowiedzi może być prosty, byleby był "dziwaczny" i nieintuicyjny. I nie rób jednej takiej procedury, ale kilka. Hakerom trudniej będzie je wyszukać.
Pastylka Dallasa ma jedną wadę... można zamiast niej podstawić mikroprocesor.

Generalnie nie masz się czym przejmować bo jeśli program będzie odpowiednio drogi to i tak znajdzie sie mocarz który ominie twoje zabezpieczenia krótkim parokilowym kraczkiem a lamer i tak nie wgryzie sie w istote działania takiego klucza. Moim zdaniem FT232BM + jakiś atmel będzie ok. I nie rób zabezpieczeń w stylu pytanie - odpowiedź. Takie jest najłatwiej skrakować. Już lepiej przetrzymuj w atmelu wartości poszczególnych zmiennych.
pozdrawiam
JG

sie zastanawiam.. skoro program ma być zabezpieczony kluczem sprzętowym to nasuwają myśli:
- trzeba umieścić pewne dane w kluczu...
patrząc na aktualne systemy.. uprzywilejowany tryb debugera który może zrobić zrzut pamięci albo tym podobne dane są poważnie zagrożone... więc nasuwa sie kolejna myśl:
- układ musi potwierdzić swoją autentyczność bez ujawniania informacji, które pozwolą na fałszywą identyfikacje..
tak działają karty tpsa.. budka wysyła losowe dane do karty, karta odsyła wynik mieszania danych losowych z tajną daną znaną jej[karcie] i budce.. jest to dobry sposób, ale nie na komputerze gdyż tajne dane są symetryczne tz że klucz i komputer posiadają te same dane.. więc nasuwa się myśl:
- układ musi używać potwierdzenia swojej autentyczności za pomocą metod asymetrycznych.. można zastosować podpisywanie RSA.. całość się będzie zachowywać wspaniale.. ale to wymaga znajomości certyfikatu klucza, a ten można podrobić.. można wystawić certyfikat producenta, oraz certyfikat klucza który będzie podpisany przez producenta.. wtedy cała sprawa staje sie bardziej kolorowa... ale gożej z możliwością oszukania oprogramowania gdyz można zmienić mu certyfikat i dopuścić do użytku fałszywe klucze oraz crack na program... można również wyłączyć sprawdzanie testowania klucza w desassemblerze więc:
- komputer niemoże zweryfikować autentyczności klucza.
a więc dochodzimy do wniosku:
- rdzeń programu musi być umieszczony w kluczu, w którym niema trybu debugera, program musi wysyłać wszystkie dane do klucza, wysłać żądanie przetworzenia danych oraz żądanie o wynik...

czarno to wygląda...

BoskiDialer napisał:

- układ musi używać potwierdzenia swojej autentyczności za pomocą metod asymetrycznych.. można zastosować podpisywanie RSA..

Taaa, gotowe karty chipowe ze sprzętowymi kryptokontrolerami mogą szyfrować/deszyfrować RSA w czasie 1sekundy (dla kluczy w rozmiarze rzedu 1000bitów), a jest to i tak bardzo duże osiągnięcie.