[elektro] kriptelt kommunikacio

[Stolmár Tamás]

>
> Adott egy mechanika meg egy zar.
> A ketto kozott digitalis busz.
> A zarat ha mozgatom a mechanika nyit/zar.
> Ezt kellene tudni atombiztosra megcsinalni.
>
> Ne lehessen megfejteni azaz szimulalni a zarat, ne lehessen menet kozben 
> belenyulni a kommunikacioba ugy hogy az eredmenye nyitas legyen pl.
Mivel kis teljesítményű prociról van szó, ezért a nagyon nagy méretű
kulcsok alkalmazása nem lehetséges - nem fér bele a ram-ba, sokáig tart 
a számolás stb.

Tehát az üzenet nem kell hogy titkos legyen
hiszen csak néhány üzenet van, a nyitás és a zárás plusz az egyéb 
szinkronizáció.

A lényeg az, hogy az üzenet authentikus legyen,
és a visszajátszhatóságot illetve a man-in-the-middle
jellegű támadásokat akarod kijátszani.

Erre ez az egyszerű megoldás:

- Aláírás az, ha az üzeneted mögé biggyeszted a saját titkos kulcsodat, 
és erre számolsz egy hash értéket.
értelemszerűen csak az alapüzenetet + hash értéket küldöd át.
- A hash függvény lehetőleg ne legyen invertálható.
- A túloldal is ismeri a titkos kulcsot, ez alapján tudja ellenőrizni az 
üzenet eredetiségét.
A védelem jóságát a kulcs és a hash mérete határozza meg. ezt lehet 
brute force módszerrel végigpróbálgatni,
illetve ha jó sok üzeneted van akkor megpróbálni kitalálni mi is a hash 
algoritmus illetve titkos kulcs.

0. Adatot küldő küld egy spec csomagot, amivel jelzi a fogadónak hogy 
üzenetet akar küldeni.

1. Adatot fogadó egység küld a másiknak egy random értéket, ez a 
challenge. Ezt ha akarod aláírod, ha akarod nem.
Mellette és ellene is vannak érvek.
Adatot fogadó megjegyzi a challenge-t, hogy ezzel lehet neki küldeni.

2. Adatot küldő küldi: challenge + üzenet + aláírás megy vissza.

3. Fogadónál:
- Ha a challenge nem ok, akkor vagy visszajátszással próbálkoznak, vagy 
vételi zavar. Kuka.
- Ha az aláírás nem ok, akkor piszkálták az üzenetet, vagy vételi zavar. 
Kuka, esetleg NACK mehet vissza.
- Ha minden OK akkor pl. challenge + ACK + hash mehet vissza ha fontos.

Ezt innentől csak bonyolítani lehet :)

Én a kucsot az atmega eeprom részbébe tenném. Lehet master kulcs is a 
programkódban,
az ezzel aláírt parancsokkal lehet pl. saját kulcsot cserélni.

További ötletek:
- Címek bevezetése - Busz topológiához :)
- A túl rövid üzenetek felhizlalása random bitekkel/byteokkal
- A felhizlalt üzenetekben nem mindig ugyanott van a tényleges adat
- a 0-1 lépést is levédheted egy másik random challenge-el

Üdv: Tamás
> Ez nem gond, automatikusan megcsinaljak a teszteles alatt, elso tapfeszkor
> Ennyire nem veszes a tortenet, hogy ez ellen is vedekezni kell.
>   
Ezt nem bíznám automatizmusra, hiszen pont ekkor válik támadhatóvá.
Áram le, közéjük a behatoló, áram vissza.




>> Szintén könnyebben visszafejthető a kulcs ha a továbbítandó üzenet nem
>> elég véletlenszerű.
>>     
>
> Hat igen... ezert gondoltam bele ál-veletlen szamot....
>
>   
>> Ez ellen úgy tudsz védekezni, hogy a master által kiküldött challenge
>> nem csak véletlenszerű
>> adatot tartalmaz, hanem van benne egy időbélyeg is. Az meg idővel lejár
>> és monoton megy előre,
>> főleg ha egy rtc-d is van.
>>     
>
> nincs, 16k-s atmel 8bit szintu proci van, slusszpassz
>
>   
>> Sokszor nem a titkosítási elv a gyenge hanem a megvalósítás, pl.
>> a vezérlő üzenetek piszkálásával lehet a rendszert átverni.
>>     
>
> Pontosan erre gondoltam, hogy igy ne legyen tamadhato...
> Aki elkezdi a titkositast visszafejteni az mar had vigye ha sikerult neki.
> De olyan ne legyen hogy az adatfolyamban vmi bitet 0-ra kenyszeritenek es 
> nyit.
>
> A. 
>
> -----------------------------------------
>           elektro[-flame|-etc]