Plovouci kod

[Thomas Shaddack]

Mozne vylepseni je zde pouziti PIN kodu, ktery se pouzije jako klic pro 
zasifrovani ulozenych OTP klicu. Pak ani pri odcizeni klice nemuze bez 
znalosti PIN dojit k jeho uspesnemu pouziti.

Dalsi mozne vylepseni je zablokovani prijimace na napr. 10 sekund, pokud 
bude prijat vadny klic. Pri vhodne delce klice toto staci na zpomaleni 
protivnika do doby zaniku vesmiru.

Zrychleni prohledavani ulozenych klicu muze byt provedeno pomoci jejich 
indexace podle hashe.

Pro zvyseni bezpecnosti je mozne mit klice ulozene po 4 bitech, kde 
komplementarni 4 bity v bajtu jsou jejich invertovanou podobou (nebo uplne 
nahodne). Pak mame zajisteno, ze pocet zmen bitu v registrech pri 
zpracovani hodnot je vzdy stejny (nebo alespon nepredvidatelny), cimz 
protivnikovi ztizime analyzu pomoci DPA (diferencni proudove analyzy) i 
detekce elektromagnetickych emisi. Dalsim moznym vylepsenim je pak to, ze 
kdyz prohledavame tabulku klicu, prohledavame ji vzdy celou a jen 
nastavujeme flag uspesnosti nalezeni. Tim nam operace trva vzdy stejnou 
dobu, coz znemoznuje timing attacks.

Ale to je pro vetsinu domacich aplikaci ponekud overkill.



On Sat, 26 Feb 2005, Thomas Shaddack wrote:

> 
> 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
> >