Plovouci kod

[Thomas Shaddack]

Podobnou problematikou jsem se teoreticky zabyval.

Plovouci kod sice neovladam, ale napadlo mne par jinych reseni.

Pokud muze byt komunikace oboustranna, vhodny pristup je 
challenge-response, kde challenge je neopakovatelna (napr. odvozena z 
RTC - zde je nutno zajistit, aby protivnik nemohl RTC nastavit).

Pokud je jen jednostranna, potencialni reseni je pouzit OTP (one-time 
pads); hromadu klicu kde se kazdy smi pouzit jen jednou a po pouziti se 
vymaze nebo zablokuje. Zde je nevyhodou omezene mnozstvi klicu a tedy 
omezene mnozstvi pokusu o otevreni. To vsak lze kompenzovat vhodnym 
technickym resenim.

Napr. pri pouziti 128-bit klice (16 byte) se nam jich do jedine 24C256 
vejde 2048 - coz je na obvykle aplikace dost, zejmena pokud po odemceni 
napr. auta pote zasuneme klic do konektoru, kde si popovida s palubnim 
pocitacem a dostane nove vygenerovane klice. Ruzne klice ke stejnemu 
zarizeni mohou mit sve vlastni sady OTP klicu, cimz se resi problematika 
kolizi kde by jeden klic pouzival klice druheho klice, ktery by pak 
nefungoval.

Klice je pak mozne odepisovat bud sekvencne (musi byt pouzite v urcitem 
poradi), nebo nahodne (jakykoliv klic co jeste nebyl pouzit je platny). 

Nevyhoda sekvencniho pouziti je moznost ztraty synchronizace (napr. kdyz 
zmacknu klic v kapse a posunu sekvenci, aniz by o tom zamek vedel), system 
je tedy ponekud "krehky".

Pri nahodnem pouziti 2048 klicu nam sice odolnost proti brute force klesa 
ze 128 bitu na 117, ale to je napr. pro auto porad jeste dost na to, aby 
se protivnikovi radeji vyplatilo jej odtahnout do dilny a tam odvrtat 
zamek, nebo v pripade domu prokopnout dvere. Kontrola klice trva dele, 
nebot zamek musi proverit vsechny klice co jeste nebyly pouzity, ale 
spolehlivost je vyssi a pri rychlosti dnesnich pocitacu na par instrukcich 
moc nezalezi.

Mozna zranitelnost zde je generator entropie, ze ktereho se vyrabeji nove 
klicove pary, ale kombinace Zenerky a ADC v PICu a vhodneho algoritmu na 
kryptograficke beleni vysledneho sumu (a sanity-checks pro pripad ze by 
dioda prestala dodavat sum - napr. kdyz se vstupni hodnota vyrazne nemeni 
po urcitou dobu, hlas poruchu) by mela resit i toto.




On Fri, 25 Feb 2005, Lubor Otta wrote:

> Zdravim konferu,
> rád bych si udělal představu o bezpečnosti subjectu proti několikanásobnému  odposlechu kódu z téže klíčenky.
> Prohlédl jsem si zběžně popis keeloq od michrochipu.
> Zdá se mi, že použití konkrétní veřejně prodávané klíčenky s obvodem keeloq, třeba od Jablotronu je bezpečné pokud se neví co je uvnitř HCS362 za mikrokód. Jeho provalením (a zdali už k němu nedošlo) bezpečnost končí.
> 
> Kdybych u konkrétní sady kličenek a přijímače změnil manufacturer kod, asi bezpečnost trochu zvýším, ale netuším o kolik.
> 
> Za obecně bezpečnější zatím považuji systémy, u kterých je po rozsynchronizaci klíčenky nutné její nové vložení do přijímače autorizovanou osobou, ale vyzkoušení všech kódů a jejich ofsetů simulací na rychlém počítači zase asi bude otázkou dnů?
> 
> Zabýval jste se někdo bezpečností klíčenek s plovoucím kódem?
> Dík, Lubor.
> 
> 
> 
> _______________________________________________
> HW-list mailing list  -  sponsored by www.HW.cz
> Hw-list@list.hw.cz
> http://list.hw.cz/mailman/listinfo/hw-list
>