256-bitowy klucz elektroniczny własnej konstrukcji.

Witam.

Przedstawiam 256-bitowy klucz elektroniczny całkowicie własnej konstrukcji.
Istnieje wiele gotowych kluczy elektronicznych, które są pewnie nawet tańsze ale ja bardzo chciałem stworzyć coś samemu. Najbardziej zależało mi na napisaniu własnego protokołu łączności pomiędzy dwoma mikroprocesorami.

W roli klucza (czyli "nadajnika") będzie pracować mikroprocesor ATMEL Attiny13. Jest to mój ulubiony ponieważ mimo, że jest bardzo malutki i ma mało wyprowadzeń, mieści w sobie stosunkowo dużo programu, można go łatwo programować i wiele potrafi jak na takie rozmiary. Z resztą jakoś musiałem upchać mikroprocesor w małej obudowie.

Jeśli chodzi o odbiornik to jeszcze wersji końcowej nie ma, na razie zbudowałem tylko "na prętce" układ odbierający kod z klucza tak żeby napisać protokół łączności i sprawdzić czy to w ogóle będzie działać.

Do budowy klucza użyłem :
1. Mikroprocesor attiny13V (SMD)
2. Wtyk USB-b
3. Rezystor SMD
4. Dioda LED (SMD)
5. Dwa kondensatory (jeden SMD a drugi elektrolit)
6. Kawałek laminatu
7. Obudowa z wtyku big JACK

Jeśli chodzi o część programową klucza to została ona napisana w Bascomie. Program zajął około 500b pamięci flash klucza, czyli około połowy dostępnej pamięci. Większość pamięci zajęło 256-bitowe hasło.
Protokół nadawczy jest dość prosty, polega tylko na tym, że na jednej z nóżek pojawia się sygnał zegarowy z odpowiednią częstotliwością, a na drugiej reprezentowane są już kolejne bity hasła. Dzięki wykorzystaniu dwóch linii danych (czyli zegara i danych) uzyskałem stosunkowo dużą prędkość transmisji - cała procedura nadająca hasło, trwa tylko ułamek sekundy. Mógłbym uzyskać większą prędkość, ale tylko wtedy gdyby tiny13V był taktowany z kwarcu, ale niestety taktowany jest tylko z wewnętrznego zegara RC 9,6 Mhz.

Program odbiornika zajmuje około 3,5 kb pamięci flash procesora attiny2313. Protokół odbiorczy napisany w Bascomie i jest już dość skomplikowany. Wykorzystuje on przerwanie zewnętrzne INT0, dzięki czemu udało się uzyskać duża prędkość transmisji danych.

Na hasło składa się 256 bitów, z czego 4 pierwsze to bity staru, potem 16 bitów odpowiadających za ID użytkownika, następnie hasło a na samym końcu 4 bity stopu.

Zastanawiałem się czy łatwo jest złamać hasło ale w sumie kluczy może być 2 do potęgi 16 (tak aby sie nie powtarzały) a kombinacji hasła jest 2 do potęgi 256, więc wydaje mi się, że raczej ciężko było by trafić w właściwą kombinację.

Schematu klucza nawet nie chce mi się rysować bo po co jest to tylko procesor podłączony bezpośredni do złącza USB-B, a reszta części to tylko filtr zasilania i kontrolka LED.

Super! Mi się podoba!
Wygląda prawie jak Pendrive
Gratuluję! Własny protokół, ładne wykonanie...
Przedstaw może kod oraz "drugą stronę" urządzenia. Do czego ono służy, jak się odbywa komunikacja itp.

Pth wrote:

Program odbiornika zajmuje około 3,5 kb pamięci flash procesora attiny2313. Protokół odbiorczy napisany w Bascomie i jest już dość skomplikowany. W

A to ciekawe.. Co za pech że ATtiny2313 ma tylko 2kb pamięci flash:)
Ehh w końcu dzisiaj 1 kwietnia..

A przepraszam chodziło, mi o atmege8535, bo dla niej przygotowałem protokół odbiorczy a chciałem to upchnąć do tiny2313 już w układzie docelowym. Wydawało mi sie ze ma 4 kb ale jednak sa 2 , No to w takim razie program wgram do atmegi8 bo ta ma już 8 kb wiec spoko starczy i jeszcze trochę bajerków się zmieści.

P.S. Tak się zastanawiam, do kiedy elektroda.pl będzie zhakowane?! Podoba mi sie to, że wszyscy są administratorami no ale bez przesady

Zchakowane to pewnie nigdy..., zhakowane może kiedyś...

@Pth
Możesz udostępnić kod źródłowy?, pozd

A tak aprtopo's hakowania to chyba dość wcześnie zaczęli ten prima aprilis

Kodu nie chcę za bardzo udostępniać, bo przecież nie po to go pisałem, żeby było wiadomo jak złamać hasło Z resztą nie wiadomo jacy ludzie chodzą po tym forum...

Co to będzie za klucz jak każdy będzie znał jego wartość i sposób zabezpiecznia??

No to dlatego nie zdradzam nikomu swojego oprogramowania, więc nie ma możliwości otwarcia mojego zamka bez klucza .

Po małej zmianie programu czytnika udało mi się zmieścić cały kod w 2 Kb pamięci tiny2313, Nawet zostało mi jeszcze 20 miejsca!

A jeśli chodzi o schematy odbiornika i nadajnika to są poniżej :

To jeżeli nie chcesz udostępniać samego kodu, to powiedz jak działa algorytm, bo powiem szczerze, że mnie to ciekawi, pozd

A czy mógłbyś zdradzić na czym polega przesyłanie danych? Tzn. Czy przesyłasz tak jak przez USB czy to jest jakaś własna konstrukcja?

Witam
Konstrukcja bardzo ciekawa, ale z tego co wyczytałem to w kluczu jest zapisane jedno hasło i jest wysyłane po podłączeniu klucza, ma to ogromny minus bardzo łatwo takie hasło skopiować lub podsłuchać.
Bezpieczniejsze by było gdyby zamek wysyłał jakiś losowy ciąg do klucza a klucz przerabiał go jakiś algorytmem i odsyłał wynik, natomiast w zamku był by ten sam algorytm i wyniki były by porównywane.
A co do małych mikro kontrolerów mogę polecić ATTiny45 ma 4K pamięci i jest łatwo dostępny, np. w seguro.
Pozdrawiam

Bardzo ładnie,brawo za ambicje. 6/6

co do tego zaszyfrowania, to chyba autor sie nie zastanawiał za dużo nad tym tematem. kacperpk dobrze radzi.

Wyobraźmy sobie taką sytuacje, że ktoś chce złamać twój kod. To że może ci ukraść klucz to już pomijam, ale wystarczy że podczas twojej nie uwagi podepnie sie pod te USB i wszystko zmonitoruje. Potem zrobi sobie taki sam nadajnik i po tobie.

Należało by tu zrobić dwustronną transmisje. Klucz wysyła swój kod, odbiornik potwierdza go i wysyła swój kod do klucza. Klucz teraz potwierdza kod i powiadamia odbiornik że jest poprawny. Tylko każdy kod musi być zaszyfrowany specjalnie, tak żeby na pierwszy rzut oka był inny (tutaj to już można by dużo mówić). I jeszcze jedna sprawa, odbiornik musi kontrolować czy podany zaszyfrowany kod przez klucz już nie był wcześniej używany, bo jak był to zerwać łączność

Może i komunikacja w dwie strony to dobry pomysł ale już może się to wszystko pomieścić w proku.

Usb robi tu tylko za gniazdo.

A komunikacja?
W klucza sa dwie linie czyli zegar i dane.
Zegar jest taktowany ze stałą prędkością i co każdy jeden tak jest odczytywany bit hasła i przypożądkowywany do lini danych.

W odbiorniku gdy zgłosi się przerwanie (czyli pojawi sie sygnał zegarowy) procesor odbiorczy sprawdza stan lini data. i porównuje go z hasłem zapisanym. w Sumie nic wielkiego

Udostepnienie algorytmow dobrze swiadczy o zabezpieczeniu. Calym zabezpieczeniem ma byc Twoje haslo na kluczu (czy w glowie) a nie jakas konkretna implementacja czy sposob przesylania danych. Cale kody bez konkretnego klucza, ktory stosujesz (a ktory nie jest wcale taki krotki i latwy do zlamania) nie powoduja automatycznej kompromitacji i nie umozlowiaja obejscia niczego.

O ile nie masz dziur i bledow Jesli nie, mozesz spac spokojnie. A jesli je masz lepiej dowiedziec sie o nich publicznie zanim wykorzystasz takie zabezpieczenie niz potem niemilo jak juz ktos sprytny je zlamie.

Swietnym przykladem takiego podejscia, o ktorym pisze, jest choc by swietny program TrueCrypt, wszelkie linuxy czy inne publicznie dostepne algorytmy szyfrujace. Mimo dostepnosci wszystkich kodow, znajomosci algorytmow i sposobu dzialania zabezpieczenia sa skuteczne i powszechnie stosowane. A powszechna znajomosc i otwartosc czyni je znacznie pewniejszymi jak czegos o niewiadomym dzialaniu. Calym zabezpieczeniem jest tu zawsze jedynie klucz wybierany przez uzytkownika w danej implementacji.

Zaufal by z was ktos w niewiadomo jak dzialajace szyfrowanie z Microsoftu? A jesli bedzie to metoda tak doskonala jak ta stosowana do hasel w starym outlooku, gdzie haslo mozna bylo odszyfrowac w kilka minut z kartka papieru?

Jeśli ten klucz ma być wtykany w port USb w komputerze to należałoby przede wszystkim zmienić wtyk - w tej chwili klucz można co najwyżej wetknąć w urządzenie USB typu slave

Tak sobie patrzę , czytam i czegoś mi tu brakuje . Jeden procesor to nadajnik kodu drugi to odbiornik kodu , złącze USB ( jak sam piszesz) jest tylko po to żeby obydwa fragmenty połączyć ze sobą . No fajnie , ale co dalej . Jeżeli urządzenie ma pracować autonomicznie to to raczej mija się z celem . Natomiast jeżeli powstało samo dla siebie to masz 4+ .

Mam takie głupie pytanie, co dalej to urządzenie robi? :?
I gdzie ew. jakiś przekaźnik czy coś jest podłączone pod odbiornik? Tam gdzie złącze ISP??

Pth wrote:

Kodu nie chcę za bardzo udostępniać, bo przecież nie po to go pisałem, żeby było wiadomo jak złamać hasło Z resztą nie wiadomo jacy ludzie chodzą po tym forum...

...to bedzie slabe zabezpieczenie...zapewnienie tajnosci implementacji=porazka. Zawsze tak bylo i bedzie.

Pozdrawiam

Fakt, wystarczy podpiac pod "dziurke od klucza" urzadzonko i napierdzielac ciagiem bitow od 0 do 2^255 i w koncu peknie.

Pomysl fajny, ale gdyby to zrobic tak
Z = procek-zamek
K = procek-klucz

1. Z wysyla losowa fraze do K
2. K koduje ta fraze wg jakiegos algorytmu i klucza kory ma w pamieci, nastepnie odsyla ja do Z
3. Z porownuje czy wynik operacji wykonany przez K jest taki sam jak wynik tej samej operacji zrobiony w Z, z zastosowaniem tego samego klucza kodujacego.
4. Jesli nie to ERROR, jesli tak to zamek otwarty, Z generuje nowy klucz i wysyla go do K.

Duzo mniejsze prawdopodobienstwo ze ktos sie "wstrzeli", ale i roboty wiecej w oprogramowaniu tego

dir3ctor wrote:

Fakt, wystarczy podpiac pod "dziurke od klucza" urzadzonko i napierdzielac ciagiem bitow od 0 do 2^255 i w koncu peknie.

Gratuluję pomysłu. Sądzisz, że Ziemia wtedy będzie jeszcze funkcjonować? Masz niezłe wizje.

dir3ctor wrote:

Zamek...

Mniej więcej tak działają urządzenia autoryzujące w sieci (np tokeny do autoryzacji w banku).
W wersji prostszej-jednokierunkowej nadajnik może losowo generować i szyfrować klucz (uwzględniając ewentualnie swój indywidualny identyfikator), przesyłając obie te wartości, a odbiornik może tylko skonfrontować wygenerowany kod przed i po szyfrowaniu. Przydałby się jeszcze w algorytm wykluczający sekwencje już wykorzystane, co wykluczałoby możliwość użycia podsłuchanej sekwencji (jeśli transmisja idzie w ogólnodostępnej sieci, czy po radiołączu), ewentualnie można powielić autoryzację z losowym generowaniem kodu na obu końcach linii, dzięki czemu jakiekolwiek skanowanie linii w celu włamania traci sens.

Oczywiście w pełni zgadzam się z opiniami kolegów, że dobrze napisany algorytm szyfrujący i protokoły transmisji można bez problemu opublikować, bo CAŁA informacja zabezpieczająca zapisana jest w kluczu, czy jak kto woli książce kodów.

Pth wrote:

No to dlatego nie zdradzam nikomu swojego oprogramowania, więc nie ma możliwości otwarcia mojego zamka bez klucza .

Po małej zmianie programu czytnika udało mi się zmieścić cały kod w 2 Kb pamięci tiny2313, Nawet zostało mi jeszcze 20 miejsca!

A jeśli chodzi o schematy odbiornika i nadajnika to są poniżej :

Mam wrażenie ze nie długo będziesz musiał czekać na wymianę któregoś procka,przydały by się jakieś zabezpieczenia przed ładunkami.
Gdybym ja miał cos takiego robić skorzystałbym albo z transponderów albo chociaż coś z Keeloqa.

Chyba jednak zrezygnuje z własnego protokołu i użyje po prostu RS-232. Będzie zajmować mniej miejsca w tiny13. Dzięki temu będę mieć pewną komunikacje w 2 strony. Wszytko się napisze w C i sie wtedy więcej kodu zmieści. Nawet może nie będzie potrzebny jakiś specjalny kod tylko po prostu kod zostanie już wygenerowany według jakiegoś algorytmu ustalonego przez atmege8535.