Mały szyfrujący scalak

W dniu 2015-02-26 o 10:31, Bool pisze:

Możecie coś zasugerować?

W dniu 2015-02-26 o 10:31, Bool pisze:

Sprawdź to:

Mam wrażenie że chcesz tylko sprawdzić czy to coś jest twoje.

Jesli tak to prawdopodobnie szukasz czegoś podobnego do:

Nie wymaga on zapytania. Czyli redukuje się tylko do 1 lini "scalak"->system i samodzielnie co jakiś czas wysyła kod autoryzujący do systemu. Microchip produkuje tanie scalaki.

Przypisy do w/w artykułu typu: "How to steal cars" albo "A complete break of the KeeLoq access control system" robią wrażenie ;)

Bop KeeLoq jest stary. Przypuszczam że można wzmocnić szyfrowanie samemu rozbudowując długośc kluczy i zwiększając poziom mieszania. Ale jesli to urzadznie ma zapewnić np. że sterownik pieca bedzie pracował tylko z jakimś konkretnym piecem, to żaden kowalski tego nie zlamie.

No teraz nie jestem już taki pewien (a kiedyś byłem i podzielałem Twoje zdanie). Ostatnio zrobiła się moda na "łamanie" tudzież wyszukiwanie podatności w czymkolwiek co ma zaimplementowaną komunikację (czajnik bezprzewodowy, BMW itp.). Czasy są takie, że lepiej implementować porządną kryptografię niż taką-sobie.

W dniu 2015-02-26 o 10:49, Zbych pisze:

Dziękuję za odpowiedź. Właśnie czegoś takiego szukałem.

W dniu 2015-02-26 o 20:25, Sebastian Biały pisze:

Nie za bardzo rozumiem jak to działa. Przypuśćmy że chcę aby moja aplikacja weryfikowała czy jest odpalona na moim sprzęcie. Załóżmy że uruchamiam tą aplikację pod Linuxem. Scalak co jakiś czas wysyła dane i jakiś sterownik odbiera te dane i przeprowadza weryfikację?

Kryptografia w czajniku ?

Bool pisze:

To chyba Ty musisz określić czego potrzebujesz.

aplikacja weryfikowała czy jest

Linuxem. Scalak co jakiś czas

Twój hardware wysyła dane, które są "podpisane" (lub zaszyfrowane) kluczem znanym tylko jemu i aplikacji. Ale wtedy aplikacja jest łatwiejszym targetem na atak wydobywający klucz. Nie wiem czy bez krypt. asymetrycznej da się to zrobić zadawalająco bezpiecznie.

Keeloq standardowo używany jest w sytuacji nadajnik radiowy (pilot) -> odbiornik. Zadaniem szyfrowania jest nie tylko uniemożliwić obcej osobie wysłania pakietu otwierającego bramę ale rownież producent może zaszyć w scalaku własny "podpis" przez co może zarabiać na zastepczych pilotach (bo tylko podpisane zadziałają i da się je sparować zodbiornikiem). Ataki na keeloq nie są trywialne i do prostych zastosowań w zupełności wystarczy.

W dniu 2015-02-28 o 13:51, Marek pisze:

Czegoś nadal tu nie rozumiem. W takim dużym uproszczeniu zakładałem że u mnie wymiana informacji będzie wyglądała tak, że aplikacja wysyła jakiś losowy ciąg danych i dostaję odpowiedź z mojego hardwaeru zaszyfrowaną przy pomocy tajnego klucza. Później aplikacja ją rozszyfrowuje przy pomocy tego samego klucza i sprawdza czy odpowiedź jest poprawna.

Jeśli komunikacja jest tylko w jedną stronę hardware -> aplikacja. To skąd mam wiedzieć jak weryfikować te dane odebrane. Oczywiście mogę je odszyfrować przy pomocy tego samego klucza, którym były szyfrowane, ale skąd mam wiedzieć co one oznaczają. Dodatkowo ktoś może podsłuchać tą transmisję i dobudować układ, który będzie wysyłał dokładnie takie same ramki danych.

że u mnie wymiana informacji

i dostaję odpowiedź z mojego

aplikacja ją rozszyfrowuje przy pomocy

To skąd mam wiedzieć jak

pomocy tego samego klucza, którym

ktoś może podsłuchać tą

same ramki danych.

Poczytaj jak się zabezpieczyć przed reply attack. Wprowadza się nr sekwencyjne. Odbiorca odrzuca dane jeśli mają ten sam nr. Sekwencja może być rosnąca/malejąca whatever. W keeloq (i w podobnych) masz kod sekwencyjny zabezpieczający przed atakiem powtórzeniowym. No i oczywiście losowy wektor inicjujący aby zabezpieczyć się w przpadku szyfrowania pakietów danych zawierających w początkowych blokach te same dane.

Ano. Sa czajniki sterowane komorka.

Pozdrawiam

Marek