Elektroda.pl
Elektroda.pl
X
Proszę, dodaj wyjątek www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

256-bitowy klucz elektroniczny własnej konstrukcji.

Pth 31 Mar 2007 23:52 8733 24
  • 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.


    Fajne! Ranking DIY
    Potrafisz napisać podobny artykuł? Wyślij do mnie a otrzymasz kartę SD 64GB.
  • #2 01 Kwi 2007 05:50
    dj_volt
    Poziom 22  

    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.

  • #3 01 Kwi 2007 09:02
    JollyRoger
    Poziom 21  

    Pth napisał:

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

  • #4 01 Kwi 2007 09:30
    Pth
    Poziom 26  

    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 :D, 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 :P:P:P

  • #5 01 Kwi 2007 10:12
    vcd_a
    Poziom 18  

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

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

  • #6 01 Kwi 2007 12:43
    Pth
    Poziom 26  

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

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

  • #7 01 Kwi 2007 12:49
    Duch__
    Poziom 31  
  • #8 01 Kwi 2007 13:24
    Pth
    Poziom 26  

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

    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 :

  • #9 01 Kwi 2007 15:45
    vcd_a
    Poziom 18  

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

  • #10 01 Kwi 2007 15:53
    ks_fenix
    Poziom 23  

    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?

  • #11 01 Kwi 2007 16:46
    zbyrek
    Poziom 23  

    A co do tego wsadu to mógłbyś zamieścic przecierz do ciebie nie przyjade specjalnie żeby łamac zabezpieczenia 0,o nawet nie wiem gdzie mieszkasz.......

  • #12 01 Kwi 2007 17:09
    kacperpk
    Poziom 13  

    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

  • #13 01 Kwi 2007 17:29
    BartekWB
    Poziom 27  

    Bardzo ładnie,brawo za ambicje. 6/6

  • #14 01 Kwi 2007 18:17
    Batmanmen
    Poziom 15  

    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ść

  • #15 01 Kwi 2007 18:37
    zbyrek
    Poziom 23  

    zależy co i przed kim chce się chronić bo np: barek przed dziećmi to zupełnie wystarczy.

  • #16 01 Kwi 2007 20:25
    Pth
    Poziom 26  

    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 :D

  • #17 02 Kwi 2007 00:19
    KuchateK
    Poziom 11  

    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? :D

  • #18 02 Kwi 2007 13:05
    badworm
    Poziom 18  

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

  • #19 02 Kwi 2007 13:43
    Tomasz.W
    Poziom 35  

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

  • #20 03 Kwi 2007 13:51
    NeoX
    Poziom 15  

    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??

  • #21 07 Kwi 2007 17:00
    czuga
    Poziom 23  

    Pth napisał:


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


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

    Pozdrawiam

  • #22 07 Kwi 2007 20:20
    dir3ctor
    Poziom 27  

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

  • #23 26 Kwi 2007 12:32
    marek_Łódź
    Poziom 36  

    dir3ctor napisał:
    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 napisał:
    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.

  • #24 26 Kwi 2007 21:28
    michalko12
    Specjalista - Mikrokontrolery

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

    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.

  • #25 14 Sty 2008 23:07
    Pth
    Poziom 26  

    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.