Karty FUN

no bo sluza do wielu "przekretow"

A czy da sie tak± kartê ³atwo sklonowaæ? Zastanawiam siê nad bli¿szym zapoznaniem siê z kartami FUN, bo mog± pe³niæ rolê kluczy sprzêtowych do ró¿nych systemów, ale je¶li da siê jej zawarto¶æ nieinwazyjnie sklonowaæ, to z miejsca przestaj± mnie one interesowaæ.

Pozdrawiam Piotr Wyderski

Zobacz tu, ogolnie funka to atmelek i pamiatka na i2c - jak da sie zerwac kod z atmelka to sie da i z funki...

Ten atmelek jest chyba zalany w plastyku? W metodach inwazyjnych to jest proste do zrobienia, ale zakladam, ze lamiacy ma dostep tylko do tych metalowych pol. Mimo tego da sie wyjac?

Pozdrawiam Piotr Wyderski

Ogolnie tam sa chyba dwie strukturki, wlasnie atmelek i obok 24c....cos tam od 24c64 do 1024. Sprobuj przyjrzec sie schematowi takiej dyskretnej funki, to zalane jest dokladnie tak samo polaczone tylko sama kabelkologia jest zamknieta. Mozna tez kupic takie karty z pickami i chyba powoli pojawiaja sie tez karty z atmelkami avr ktore maja na poakldzie koprocesor krypto. Nie jestem pewien ale chyba tez poajiwly sie army z dolaczonym koprocesorkiem krypto...

Jasne, tylko nigdy sie nie zajmowa³em wyci±ganiem zawarto¶ci z zabezpieczonego Atmela, wiêc nie wiem, czy to jest trudne. :-)

Mnie jest wszystko jedno jaka tam dok³adnie siedzi rodzina CPU, ka¿dej siê mogê nauczyæ. Wa¿ne, by siê w prosty sposób nie da³o wyj±æ z karty klucza symetrycznego (mniejsza o program tego Atmelka, security by obscurity to ¿adne security). I siê zastanawiam, czy FUN to dobry pomys³, czy te¿ sobie odpu¶ciæ.

Pozdrawiam Piotr Wyderski

Poczytaj może raczej o secure AVRach, np. AT90SC3232CS:

Olbrzymy (co najmniej kilkadziesi±t KiB flashu i EEPROMu) i przez to pewnie drogie. Do tego maj± ca³± masê zupe³nie zbêdnych peryferiów, jak np. szyfrator DES (i tak nikt rozgarniety nie bêdzie go u¿ywa³ ze wzglêdu na mo¿liwe b³êdy i backdoory -- nie zapominajmy, ¿e urz±dzenia stosuj±ce algorytmy o kluczu d³u¿szym ni¿ 40 bitów podlegaj± ograniczeniom eksportowym) albo generator liczb losowych (o którym _niczego_ nie napisano -- ani nie podano zasady dzia³ania, ani wyników testów statystycznych i dok³adnego opisu metodologii pomiarów). I ostatnia, ale najmniej wa¿na rzecz: spora czê¶æ dokumentacji jest pod NDA. :-)

Mnie ca³kowicie wystarczy 256 bajtów EEPROMu, ale za to musi byc on nie do ruszenia przy bud¿ecie rzêdu 30--50 tys z³. Losy programu s± mi obojetne, w nim nie bêdzie niczego do ukrycia.

Pozdrawiam Piotr Wyderski

Metoda inwazyjna nie wchodzi w grê ze wzglêdu na specyfikê problemu, wiêc s± szanse, ¿e to wystarczy.

Nie jest ju¿ u¿ywany w zastosowaniach wymagaj±cych wiêkszego ni¿ niski poziomu bezpieczeñstwa. Da siê go z³amaæ w ~2^47 prób, co dla dzisiejszych maszyn jest do¶æ proste. Nawet pe³ny przegl±d przestrzeni kluczy, czyli 2^56 prób, dla _pojedynczej_ maszyny zdolnej przeanalizowaæ 300 mln kluczy na sekundê to ~7,5 roku. We¼ takich maszyn 100 i otrzymasz bardzo sensowny czas ³amania metod± brute force przy niewielkiej cenie. A s± znacznie bardziej wyrafinowane rodzaje kryptoanalizy.

Nie jest okresowo zmieniany, bo w³a¶ciwo¶ci urz±dzenia wspó³pracuj±cego z kart± SmartCard na to niestety nie pozwalaj±. Dlatego klucz musi byæ badzo bezpieczny, nie mo¿na sobie pozwoliæ na jego odtworzenie w sensownym czasie metod± analizy kryptogramów.

Wet dreams, Williamie. :-)

Twierdzê, ¿e bardzo g³êboko wierzysz w bezpieczeñstwo oferowane przez DES i inne algorytmy z krótkim kluczem. A moje ¼ród³o to nasi kryptologowie z drugiego koñca korytarza oraz choæby tak podstawowa ksi±¿ka, jak "Applied Cryptography". S±dzê, ¿e to nieco lepiej, ni¿ xxx...

Pozdrawiam Piotr Wyderski

A czego się spodziewałeś? Większość fajnych rzeczy wymaga podpisania NDA. Wtedy się pewnie dowiesz co i jak z tym RNG (Random Noise Generator), jak go oprogramować itp., bo udostępniany na stronie PDF ma kilka stron na krzyż i służy tylko do "lizania przez szybę" możliwości secure AVR'ów.

No ale jak Ci wystarcza standardowe zabezpieczenie stosowane w popularnych mikrokontrolerach (lockbitami) i wierzysz w jego skuteczność, weź pierwszy z brzegu AVR o peryferiach pasujących do potrzeb.

Była tu też mowa o zwielokratnianiu klucza. O ile wiem, 3DES'a nikt jeszcze nie pokonał, a 5DES (czyli tak jakby 5 DESów z różnymi kluczami) to już w ogóle byłby fajny pomysł. Tylko w praktyce rzeczywiście nie jest, bo DES'a wymyślali matematycy. Kto inny by wpadł na klucz o długości 56 bitów? :-[=] Znacznie lepszym - i szybszym - obecnie stosowanym algorytmem kryptografii symetrycznej jest AES (Rijndael). Można go skalować do różnej długości klucza (standard to 128 lub 256 bitów), operuje się efektywnie na liczbach 32-bitowych używając tylko przesunięć, XOR'ów i dodawań, a przez to sam algorytm fajnie się poddaje upakowaniu w różnej maści układach FPGA czy ASIC'ach. Istnieją też implementacje 8-bitowe.

Jeszcze.

Ka¿dy _skuteczny_ algorytm kryptograficzny wymy¶lili matematycy. :-)

Pierwotnie mia³ 112 bitów, ale siê to NSA nie spodoba³o i kazali skróciæ.

Wiem, w³a¶nie go implementujê w FPGA. :->

Nie ma dodawañ, tj. s±, ale w GF(2^8), czyli xor.

Nie na ka¿dej FPGA da siê zrobiæ szyfrator -- najs³abszym ogniwem ca³ego systemu bêdzie w³a¶nie macierz FPGA. Co z tego, ¿e zaimplementuje siê dobry algorytm kryptograficzny, skoro z ko¶ci da siê wyj±æ klucz? St±d z miejsca odpadaj± wszystkie kostki SRAMowe, a wiêc Altera i Xilinx nie ma tu czego szukaæ. Anifuse'owe te¿ lepiej sobie odpu¶ciæ, wiêc zostaj± tylko flashowe: ProASiC Plus Actela i Lattice XP. Tylko nie postawie duzych pieniêdzy na to, ¿e i one s± bezpieczne: analiza statystyczna mocy pobieranej, rejestracja emisji elektromagnetycznej chipu, czy w koncu wpuszczanie uk³adowi glitchy w zasilanie albo na¶wietlanie go mikrofalami, by zacz±³ pope³niaæ b³êdy naprawdê bardzo u³atwia odtworzenie klucza. O takich ciekawostkach jak "wypalanie siê" informacji w komórkach pamiêci SRAM (!!!) i istnienie zwi±zanej z tym silnej statystycznej tendencji do przyjmowania okre¶lonych stanów w kontrolowanych warunkach zasilania nie wspomnê. Parê lat temu pewni ludzie tak wyjêli klucz prywatny z szyfratora bankowego i siê nawet dziwili, ¿e im tak szybko posz³o. Mam parê prac na ten temat z ACM digital library

-- to jest p³atne, wiêc mogê Ci udostêpniæ kopiê pod warunkiem zobowi±zania siê do nierozpowszechniania.

W implementacjach programowych z kolei bardzo du¿o daje po¶redni (za pomoc± mocy pobieranej) pomiar czasu wykonania poszczególnych ga³êzi programu kryptograficznego, dlatego te¿ szyfratory nale¿y pisaæ tak, by ka¿da mo¿liwa ¶cie¿ka wykonania programu zajmowa³a tyle samo.

Adamie, zapewniam, ¿e nie wystarczy sci±gn±æ z sieci dokumentacji algorytmu krytptograficznego, przeczytaæ jej ze zrozumieniem i nastêpnie napisaæ jego poprawn± implementacjê. W ten sposób otrzyma siê tylko _dzia³aj±cy_ szyfrator. Do _bezpiecznego_ szyfratora jest jednak jeszcze niezwykle daleko.

Pozdrawiam Piotr Wyderski

Czytelnej i jawnej dokumentacji. NDA niczego nie zmienia, je¶li chodzi o bezpieczeñstwo, mo¿e co najwy¿ej poprawiæ samopoczucie. A w obecnej sytuacji to ja mogê tylko pokazaæ Atmelowi Miêdzynarodowy Gest Przyja¼ni i poszukaæ sobie czego¶ innego...

Ja nie chcê go oprogramowaæ, tylko poznaæ w³asno¶ci statystyczne, rozk³ady wyników w przestrzeniach wielowymiarowych itd. Dopiero pó¼niej mogê pomy¶leæ albo o jego oprogramowaniu, albo o wy³±czeniu i zast±pieniu czym¶ _ODPOWIEDNIM_. By¶ siê zdziwi³, jakie regularno¶ci mog± przejawiaæ _sprzêtowe_ generatory liczb "losowych" w przestrzeni np. sze¶ciowymiarowej.

Na pocz±tek wystarczy, co nie znaczy, ¿e wierzê w jego jako¶æ.

Pozdrawiam Piotr Wyderski

To może spójrz na problem z innej strony: weź pasujący Ci FPGA (choćby i z pamięcią SRAM) i bootuj go z bezpiecznej kostki (np. AVR). Jeszcze tylko pozostaje zapewnić bezpieczne środowisko aby nikt nie mógł podejrzeć tego bootowania i po problemie.

Jasne. Mimo wszystko wiele problemów zniknie gdy zapewnisz bezpieczne środowisko pracy i nie będziesz bootował FPGA gdy np. ktoś się do niego podczepi / otworzy obudowę itp. Więcej szczegółów nie piszę, bo muszę z czegoś żyć. :) To m.in. robimy w firmie:

W³a¶nie o to chodzi, ¿e nie istnieje co¶ takiego, jak bezpieczne ¶rodowisko. Pomys³ z bootowaniem z klucza przyszed³ mi do g³owy jako jeden z pierwszych, ale szybko wymy¶li³em kilka sposobów na z³amanie takiego systemu. Podstawowym problemem w przypadku SRAMowych kostek jest to, ¿e tak naprawdê nie wiadomo, _co_ jest konfigurowane i co odsy³a potwierdzenia

-- klasyczny man in the middle attack. Dlatego idealnie nadaj±cy siê do szyfrowania Cyclone 1C3-8 szybko odpad³ jako potencjalny kandydat

-- po pierwsze konfiguracja nie jest bezpieczna (przy czym nie chodzi o jej jawno¶æ, lecz podatno¶æ na zmiany), a po drugie nie da siê na nim zrobiæ bezpiecznej dystrybucji kluczy. O takich detalach jak nieblokowalny JTAG i readback lito¶ciwie nie wspomnê. Dlatego teraz "na warsztacie" jest ProASIC+.

Wsadzenie g³owy w piasek nie powoduje znikniêcia problemu; jedynym efektem takiego dzia³ania mo¿e byæ poprawa samopoczucia.

To jest nie do wykrycia i sam dobrze o tym wiesz. :-)

To chyba konkurencja wam ro¶nie. :-)

Pozdrawiam Piotr Wyderski

ze sie wtrace... Wet to mokry ;)

No tak, to kolega przedpiszca zrobi³ b³ad ortograficzny z zwi±zku frazeologicznym "sweet dreams" :)

Piotr chce uzyc do dostepu, czyli zasadniczo obie wartosci sa znane.

np wiemy ze na poczatku pisze "Rozkaz Dzienny ..." :-)

Albo zaklejamy guma mikrofon i po chwili mamy ciag zaszyfrowanych probek o amplitudzie zero. Mozna tez wyszukac najczesciej wystepujace kody .. i to pewnie bedzie "cisza w mikrofonie", czyli jakies nieglosne szumy ..

Taaa - bedziesz zmienial kody czesto, a potem sie okaze ze z tygodniowym opoznieniem ale przeciwnik jednak wiadomosci czyta.

J.