[elektro] kriptelt kommunikacio

[Stolmár Tamás]

Fuzesi Arnold írta:
> Addot ket eszkoz ami koze ossze kene hajitanom egy titkos kommunikaciot.
>
> pl:
> MASTER kerdez vmit az ismert, de kb veletlen sorszamu 1db slave-tol egy 
> veletlen szammal. (elso kommunikaciokor megkerdi a sorszamot, utana soha nem 
> kerdi, es nem is lehet modositani stb)
> SLAVE valaszol a (sorszamaval + veletlen) szammal mint kulccsal kriptelve 
> pl.
> MASTER dekriptel, pl crc rendben, idoben megjott akkor oke, feldolgozunk...
> ha nem akkor pánikbaesik mert valszeg szabotalni akartak a vonalat.
> (mondjuk 2-3 ilyen kiesett vagy hibas valasz utan....hogy azert ne legyen 
> erzekeny a tavaszi szelre)
>   
Mit értesz titkos kommunikáción?
Csak az eszköz azonosításáig akarsz eljutni, vagy teljes titkosítás a cél?
Vagy elég az is ha más nem tud a küldött adatokba belepiszkálni?
Mennyire komoly a történet?
Mi a hardver? Mik az erőforrások, lehetőségek?

Amit kitaláltál az abban a pillanatban támadható ha valaki a közbülső 
forgalmat el tudja kapni
és ismeri a protokollodat. (a slave soha nem jön rá, hogy nem a jó 
szerverrel beszélget :)

Amit kitaláltál ahhoz a CRAM-MD5 hasonló. Itt egyirányú az azonosítás: a 
szerver megbizonyosodik arról hogy a kliens OK, de a kliens nem jön rá, 
hogy adott esetben a szerver nem is az amire ő gondolt.
Ha ez baj, lehet megoldás hogy egymást azonosítgatják - de nincs titkosítás.

Ha még titkosítani is akarsz, akkor valahogy kulcsot kell cserélni, és 
ha mindent akarsz, gyakorlatilag eljuthatunk a nyilvános kulcsú 
titkosításig is.
(persze az a kiindulási ötlettől bonyolultabb, de szinte egyszerűbb a 
jól bevált algoritmusokat használni, mint újra feltalálni a kereket, és 
utána állandóan debuggolni.)

Még egy fontos dolog: A sikeres azonosítás eredményeképpen kapott 
kulcssal ha lehet nem titkosítunk adatot.
Ugyanis ha túl sokat kommunikálnak akkor a kulcs visszafejthető.
Helyette ezzel csak a kommunikációhoz használt kulcsot cserélik ki, amit 
időnként lecserélnek.
Szintén könnyebben visszafejthető a kulcs ha a továbbítandó üzenet nem 
elég véletlenszerű.
Ezen akár egy röptömörítéssel is célszerű lehet segíteni.
Ez innnentől azért is gáz mert a kommunikációs folyamat működése eléggé 
összetett protokollt igényelhet.
> Van ennek a megoldasnak gyenge pontja a hasznalt algoritmuson, es rajtam 
> kivul?
> Tudom, ez epp eleg... :)
>
> Mint pl az ugrokodos rendszereknel hogy felveszem a valaszt mikozben a vevot 
> zavarom, majd visszajatszom...
> Vagy a telefonkartyanal anno hogy lelakkozom a vpp labat.
> Hasonlo egyszeru dologra gondolok...amivel megszivathato egy ilyen 
> rendszer?!
>   
Fontos, hogy a master a kiadott challenge-eket tárolja és ha a slave 
válaszolt rá, onnantól kezdve érvénytelen. Ha nem, akkor is idővel lejár 
és törlődik. -> nem lehet visszajátszani.
> Pl azt latom ha ketszer ugyan az a veletlen szam akkor mar szivas van, mert 
> arra az uzenetre megvan a helyes valasz.
>   
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.
Téli-nyári átállásra vigyázni!
> Ide kellene vmi szekvencialis veletlen szam generalo jo szeles szammal 
> dolgozo algoritmus...
> Hogy vagy evek utan ismetlodjon kb... mp-enkenti kerdes eseten....
>
> De ilyet nem nagyon ismerek... tablazat nelkul vajon lehet ilyet gyartani!?
> Vagy hasznaljak jo szeles veletlenszamot oszt csokolom, nincs ertelme ezen 
> kuzdeni?!
>   
pl. Egyes intel flash chipekben hardveres véletlenszám generátor is van.
jó minőségű, nagy hosszúságú véletlenszámok jó védelmet adnak.
100 bites jó véletlenszám: 2^100 lehetőség, kb ennyi atom van az 
univerzumban.
Titkosítási kulcsnak kevés, egyszer használatos challenge-nek jó.

Más.

Lehet hogy neked a Diffie-Hellman algoritmus + fenti authentikáció 
megfelelő lenne.
http://wiki.hup.hu/index.php/Diffie-Hellman_kulcscsere_algoritmus
http://www.linuxjournal.com/article/6131
A jó DH alapkulcs legalább 1000, de inkább 2000 bites.

Ami ennél komolyabb, ahhoz erős és biztos matematikai tudás kell
ha nekem ilyen feladatom volna, biztos valami meglévő algoritmust 
használnék,
nem állnék neki barkácsolni.
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.

> Köszi elore is,
> Arnold
>
>
> -----------------------------------------
>           elektro[-flame|-etc]
>
>