Bool pisze:
> W dniu 2015-02-26 o 20:25, Sebastian Biały pisze:
>> 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.
>
> 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ę?

To chyba Ty musisz określić czego potrzebujesz.

--
AlexY
http://faq.enter.net.pl/simple-polish.html
http://www.pg.gda.pl/~agatek/netq.html

do góry

On Sat, 28 Feb 2015 13:12:45 +0100, Bool <n...@n...com> wrote:
> 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ę?

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.

--
Marek

do góry

On 2015-02-28 13:12, Bool wrote:
> W dniu 2015-02-26 o 20:25, Sebastian Biały pisze:
>> 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.
>
> Nie za bardzo rozumiem jak to działa.

http://ww1.microchip.com/downloads/en/AppNotes/91002
a.pdf

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.

do góry

W dniu 2015-02-28 o 13:51, Marek pisze:
> 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.

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.

do góry

On Sat, 28 Feb 2015 14:21:02 +0100, Bool <n...@n...com> wrote:
> 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.

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.

--
Marek

do góry

On 2015-02-28 13:31, Akond ze Skwak wrote:
>
>
>
>> 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.
>
>
> Kryptografia w czajniku ?
Ano. Sa czajniki sterowane komorka.

Pozdrawiam

Marek

do góry