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.

Szyfrowanie danych we własnym programie.

Jj_Johnys 21 Mar 2008 20:05 5464 21
  • #1 21 Mar 2008 20:05
    Jj_Johnys
    Poziom 21  

    Witam. Chciałbym zaszyfrować dane, które mój program wysyła po RS'ie.
    Jakie więc są metody, algorytmy szyfrowania? Szukałem na własną rękę, ale niestety nic nie udało mi się znaleźć.
    Nie chodzi mi tutaj o gotowe rozwiązania, czy programy lecz o sposób lub ewentualnie hasła pod jakimi można czegoś poszukać w necie.

    Nie chcę szyfrować kodów startowych rakiet, więc nie szukam jakiegoś kosmicznego rozwiązania. Wystarczy mi takie, którego nie będzie mógł złamać ktoś, kto obraca się w takich sprawach. Po za tym odbiornikiem będzie jakiś uC, więc muszę być w stanie napisać taki algorytm z ograniczonymi zasobami pamięci.

    Z góry dziękuję i liczę na jakieś naprowadzenie mnie na odpowiedni kierunek. Na dzień dzisiejszy nawet nie wiem czego mam szukać.

    pozd, JnS

    0 21
  • #2 21 Mar 2008 20:25
    trebuch1
    Poziom 24  

    Jj_Johnys napisał:
    Witam. Chciałbym zaszyfrować dane, które mój program wysyła po RS'ie.
    Wystarczy mi takie, którego nie będzie mógł złamać ktoś, kto obraca się w takich sprawach.


    Nie pomyslałeś że zawsze może trafić się ktoś lepszy od Ciebie?
    Twoje szyfrowanie moze słuzyć jako działanie hobbystyczne.

    Zastosuj na początek - na przykład - kod Cezara.
    Szyfrowanie: Do każdego znaku dodaj stałą wartość
    Odczyt: Postępowanie odwrotne
    Klucz: stała wartość

    0
  • Pomocny post
    #4 22 Mar 2008 05:21
    Remeknapr
    Poziom 33  

    Jj_Johnys napisał:
    Witam. Chciałbym zaszyfrować dane, które mój program wysyła po RS'ie.


    Skuteczność wszelkiego szyfrowania danych zależy od tego gdzie będzie klucz deszyfrujący. Jeśli w tym samym programie, to łatwo można taką procedurę zlokalizować. Sprecyzuj co chcesz osiągnąć.

    0
  • #5 22 Mar 2008 09:02
    shg
    Specjalista techniki cyfrowej

    http://www.mirrors.wiretapped.net/security/cryptography/algorithms/

    Do wyboru, do koloru.
    Proponowałbym na przykład TEA, prosty i co chyba dla Ciebie ważne - szybki i niewymagający wiele miejsca w pamięci programu.

    http://en.wikipedia.org/wiki/Tiny_Encryption_Algorithm

    Są jeszcze inne wersje, poprawione, ale mają nieco większe (aczkolwiek wciaż małe) wymagania:
    http://en.wikipedia.org/wiki/XTEA
    http://en.wikipedia.org/wiki/XXTEA

    Co do ogólnej koncepcji szyfrowania, to jest ich ogromna ilość. Niektórymi nie należy się w ogóle przejmować, co najwyżej wiedzieć, że takie coś jest i unikać jak ognia. Szczególnie jeżeli chodzi o szyfry podstawieniowe, albo nawet bardziej skomplikowane, oparte na pojedynczym LFSR.
    Znaczna część współczesnych szyfrów strumieniowych i blokowych opiera się na sieciach Feistela:
    http://en.wikipedia.org/wiki/Feistel_network

    O sposobach szyfrowania:
    http://en.wikipedia.org/wiki/Cipher

    Ładnie posortowane tematy z zakresu kryptografii:
    http://en.wikipedia.org/wiki/Topics_in_cryptography

    0
  • #6 22 Mar 2008 15:42
    Jj_Johnys
    Poziom 21  

    Witam. Ale mnie zasypałeś Shg - dzięki. Będę miał zajęcie na długi weekend.

    Remeknapr - ciekawa sugestia. Przejrzę najpierw ten algorytm. a później zastanowimy się nad samym kluczem. Program niestety pisany jest w C# - chyba oboje wiemy co to oznacza. Może pomyślę nad jakąś biblioteką w czystym C. Ale najpierw samo szyfrowanie.

    Dziękuję za odpowiedzi i Wesołych Świąt.

    0
  • #7 22 Mar 2008 19:04
    190175
    Użytkownik usunął konto  
  • Pomocny post
    #8 22 Mar 2008 19:07
    elektryk
    Poziom 42  

    Remeknapr napisał:
    Sprecyzuj co chcesz osiągnąć.
    To chyba stanowi największy problem, bo zaszyfrowanie i odszyfrowanie danych jest najmniejszym problem. Największą wątpliwością jest sama koncepcja i to przed kim chce się zabezpieczyć dane. Pamiętaj jeszcze o tym że:
    1. Można przechwycić dowolne dane z pamięci dowolnego programu, a więc zarówno przed odszyfrowaniem jak i po odszyfrowaniu. To samo dotyczy kluczy szyfrujących.
    2. Można odtworzyć na podstawie kodu binarnego dowolny algorytm szyfrujący, nawet nie trzeba analizować dokładnie, wystarczy określić rozmiar danych, liczbę rund etc.
    3. Z reguły "własne" algorytmy są znacznie łatwiejsze do złamania niż typowe algorytmy, jak DES, AES, RSA etc.

    PS apropos TEA to akurat ma on udowodnione że nie jest bezpieczny, po modyfikacja wymyślili algorytmy XTEA, ale ten chyba się już w ogóle nie przyjął.

    0
  • #9 22 Mar 2008 19:18
    lelekx
    Poziom 29  

    W takim przypadku, gdzie jeden klucz może zostać ujawniony (na przykład przez reverse-engineering oprogramowania) a drugi klucz może zostać tajny, można użyć szyfrowania asymetrycznego.
    Taka sytuacja ma miejsce tutaj, zakładam, że dostęp do firmware urządzenia po drugiej stronie RS-232 będzie nieopłacalny. Takie algorytmy (chociażby RSA) są dość silne, ale niestety okupione jest to dużym zapotrzebowaniem na pamięć programu i danych.

    http://pl.wikipedia.org/wiki/Kryptografia_asymetryczna

    0
  • #10 22 Mar 2008 19:44
    elektryk
    Poziom 42  

    lelekx napisał:
    Takie algorytmy (chociażby RSA) są dość silne, ale niestety okupione jest to dużym zapotrzebowaniem na pamięć programu i danych.
    Ja bym powiedział że większym problem jest ograniczona moc obliczeniowa mikroprocesora, musi działać na liczbach o bardzo dużej ilości bitów. O ile dla szyfrowania symetrycznego wystarczy użyć odpowiednio wielu zagnieżdżonych iteracji to dla szyfrowania asymetrycznego konieczne jest wielokrotne mnożenie.

    0
  • #11 22 Mar 2008 23:17
    lelekx
    Poziom 29  

    Niekoniecznie, MCU ze sprzętowym mnożeniem całkiem gładko sobie z tym radzą. W jednej z implementacji szyfrowania udało mi się w assemblerze naskrobać kod szyfrujący z efektywnością 16kB/s przy 4MHz taktowania. Większość operacji odybwa się wyłącznie na rejestrach, SRAM jest używany tylko do pobrania i zapisania operandów; wszystkie zmienne robocze i pomocnicze są przechowywane w rejestrach. Niestety to nie była implementacja RSA; szyfrowanie symetryczne z kluczem 128-bit, bez SBOXów.

    0
  • Pomocny post
    #12 23 Mar 2008 09:45
    And!
    Admin grupy Projektowanie

    Jest to transmisja szeregowa (w dodatku po RS), ze względu na wydajność uP oraz niski stopień ryzyka polecam wybrać szyfr strumieniowy (RC4, Twirl,Kanguru i inne).
    Będzie on szyfrował bit po bicie.

    Można przystosować także szyfr blokowy (DES, AES, SERPENT, IDEA itp) do pracy jako strumieniowy (np. w trybie CTR).
    Jednak będzie to większe obciążenie uP oraz ram oraz narzut na transmisji + buforowanie.

    0
  • Pomocny post
    #15 24 Mar 2008 05:51
    shg
    Specjalista techniki cyfrowej

    Remeknapr napisał:
    lelekx napisał:

    Jak usunę nawiasy z odnośnika jest tak:
    http://en.wikipedia.org/wiki/Rabbit_cipher


    Skrypt jest kulawy i czasem nie rozpoznaje poprawnych URI.

    A co do TEA, to owszem ma wady, ale złamanie szyfru przy ich wykorzystaniu wymaga dosć specyficznych warunków, całość można zorganizować tak, żeby ich uniknąć. W najprostszej opcji wystarczy uniemożliwić łamaczowi szyfrowanie jego własnych danych za pomocą klucza użytego do szyfrowania Twoich danych. To załatwia wszystkie trzy sposoby ataku opisane tu:
    http://citeseer.ist.psu.edu/318172.html

    Zresztą i bez tego, łamanie zabezpieczeń w urządzeniach które nie mogą stać się źródłem nielegalnego dochodu (takiego, który nawet bez łamania zabezpieczeń był by nielegalny, np. obrabianie banków) jest raczej mało ekonomiczne. W znakomitej większości przypadków znacznie mniejszym nakładem środków można zatrudnić programistę/inżyniera/kogokolwiek, kto stworzy analogiczne urządzenie. Oczywiście są też ludzie, którzy łamią zabezpieczenia nie dla zysku, a w myśl idei: "złamałem, bo... się dało"

    0
  • #16 24 Mar 2008 06:03
    Remeknapr
    Poziom 33  

    shg napisał:

    złamanie szyfru przy ich wykorzystaniu wymaga dosć specyficznych warunków...

    Złamanie silnego algorytmu bez użycia socjotechniki jest praktycznie niemożliwe. Metoda brute force bez dodatkowych zabiegów i zdobycia pomocniczych informacji jest całkowicie nieskuteczna nawet przy prostych zabezpieczeniach, nie mówiąc o 128 bitowym szyfrowaniu. To oczywiście temat "rzeka", swoją drogą bardzo interesujący.

    0
  • #17 24 Mar 2008 16:26
    Jj_Johnys
    Poziom 21  

    Witam po krótkiej przerwie. Widzę że temat jest dość ciekawy.
    Dziękuję Wam za wszystkie odpowiedzi.

    Przeglądając posty ostatecznie zdecydowałem się na algorytm DES. Właśnie skończyłem jego implementację w C#. Wszystko działa jak się należy. A co najważniejsze - zrozumiałem samą idee algorytmu. Teraz przeniesienie go do uC będzie już tylko kwestią czasu.

    Odnośnie klucza który zostanie użyty do szyfrowania myślę że będę potrzebował dodatkowych sztuczek czy zabezpieczeń. Pamięć uC będzie zabezpieczona przed odczytem, a program na PC nie będzie go zawierał w swoim programie.
    Szyfrowanie to zamierzam wykorzystać do uaktualniania firmware'u w urządzeniu, klient więc dostanie tylko zaszyfrowany plik który w takiej postaci zostanie przesłany do uC.

    Przy okazji studiowania kryptografii w sieci znalazłem dość ciekawą stronę, dzięki której zresztą udało mi się wszystko pojąć. Na stronie dość praktycznie, krok po kroku z przykładami wyjaśnione jest, jak działa DES.
    Może się komuś przyda: http://www.aci.net/kalliste/des.htm

    Jeszcze raz dziękuję za odpowiedzi i pomoc.

    pozdr, JnS

    0
  • #18 24 Mar 2008 17:02
    And!
    Admin grupy Projektowanie

    Czyli jednak blokowy,
    Do AES również jest dość ciekawa prezentacja jego działania, pozwalająca na wprowadzenie w podstawy jego zrozumienia.
    http://www.cs.bc.edu/~straubin/cs381-05/blockciphers/rijndael_ingles2004.swf

    Co to za procesor który uaktualni sobie pamięć programu ?
    Jest ona wewnątrz uP czy w zewnętrznej flash ?

    0
  • #19 24 Mar 2008 17:07
    Jj_Johnys
    Poziom 21  

    uC to ATmega128. Do upgradu używam oczywiście napisanego przez siebie bootloadera.

    0
  • #20 25 Mar 2008 22:52
    elektryk
    Poziom 42  

    Remeknapr napisał:
    Złamanie silnego algorytmu bez użycia socjotechniki jest praktycznie niemożliwe.
    Ale skoro są wykryte pewne luki we wskazanym algorytmie nie może być on uznawany za pewne i bezpieczne rozwiązanie.

    0
  • #21 26 Mar 2008 04:32
    Remeknapr
    Poziom 33  

    elektryk napisał:
    skoro są wykryte pewne luki ...

    Niewątpliwie masz rację. Trwa ciągła "walka" pomiędzy twórcami zabezpieczeń, a ich "łamaczami". Niezmiernie ciekawy i fascynujący temat. I nie chodzi o same algorytmy, a bardziej o metodologię ich stosowania i z drugiej strony "rozpracowywania".

    0
  • #22 04 Maj 2008 18:17
    vania
    Poziom 22  

    Jj_Johnys napisał:
    uC to ATmega128. Do upgradu używam oczywiście napisanego przez siebie bootloadera.

    A widział Ty na stronie Atmela AVR230: DES Bootloader i AVR231: AES Bootloader? Są kody źródłowe, opis.
    A jakby było potrzebne w asemblerze to: http://point-at-infinity.org/avraes/

    0
  Szukaj w 5mln produktów