Elektronicke autorizace zarizeni - algoritmy
Jindrich Fucik
fulda na seznam.cz
Úterý Září 26 20:51:37 CEST 2017
Ahoj,
jestli ti do toho mohu radit, tak se zamysli, v jaké fázi budeš tu
identifikaci dělat.
Obecně se používá buď logon a nebo provoz.
Tedy že nejprve zařízení vyzkoušíš z toho, jestli je to to správné
zařízení a pak si komunikuješ už tak nějak otevřeně. Ale ještě je
metoda, kdy prostě posíláš nějak zašifrovanou celou komunikaci.
Pochopitelně se hodí používat sůl, ta bezvadně celou situaci zašmodrchá.
Používání soli má jeden zásadní předpoklad - "unpredictable random
number". Dá se trochu zjednodušit na random number s dobrou startovní
entropií. (Někdy byl článek tady: http://mcu.cz/comment-n3607.html)
Pak je docela ftipné, když některé znaky ze soli používáš jako efektivní
- například bajt číslo 10 znamená random seed pro odpověď a tak.
Tady doporučují používat Blowfish, ale ten počítá s uint32.
https://www.embedded.com/design/configurable-systems/4024599/Encrypting-data-with-the-Blowfish-algorithm
Já jsem na osmibitech používal spíš nějaké jednodušší polynomy.
Také bezvadně situaci komplikuje, když zařízení odpovídá o jeden dotaz
později. Tedy nejprv dostane příkaz od PC, ale na ten odpoví téměř
čistou solí. Pak dostane jiný příkaz, ale na ten odešle odpověď z toho
předchozího příkazu. Pochopitelně to vyžaduje něco jako prázdný příkaz,
na který dostaneš tu poslední odpověď. A také to vyžaduje, aby jsi tim
prázdným příkazem šetřil.
Dne 26.9.2017 v 14:20 Karel M napsal(a):
> Díky za podněty, musím si to podrobně prostudovat. Veškeré výpočty musí
> probíhat na osmibitu, takže nic náročného to nesmí být. Jinak pro
> opakované pokusy prolomení hrubou silou nakonec půjde udělat teda i to,
> že zařízení odpoví až po několika sekundách, což výrazně zpomali pokusy.
> Asi se ještě ozvu než budu provádět realizaci, ať mi to můžete zkritizovat.
> Ještě jednou díky.
> Karel
>
> Dne 26. září 2017 8:48 Zuffa Jan <ZuffaJ na cgc.sk <mailto:ZuffaJ na cgc.sk>>
> napsal(a):
>
> Ake su moznosti MCU?
>
> Zvladne implementaciu napr. PGP?
> Kazde zariadenie ma svoje seriove cislo. Tym sa da osetrit, ze na
> jednu ustrednu nepripojite
> zariadenia s rovnakym seriovym cislom. (to si ustrazi ustredna).
> Seriove cisla - zvolite vhodny format (napr. verzia, vyrobca, sn) ,
> podpisete (zahashujete) cislo privatnym klucom.
> Tento ostava u vas na firme. Verejny kluc ma ustredna, ktora overi
> ze seriove cislo je platne
> (zabranite tym vytvaraniu neplatnych ser. cisiel) Aj ked sa attaker
> dostane k verejnemu klucu
> nepomoze mu to , len overi ze cislo je platne. A teraz k tej
> zlozitejsej casti.
> Ak date do zariadenia privatny kluc, stane sa, ze ak attaker hackne
> firmware, ma kluc do vsetkych zariadeni.
> Takze je potrebne zvolit v kazdom zariadeni kluc iny. Ten
> vygenerujete tak, ze zo serioveho cisla
> privatnym klucom vygenerujete hash ktorym budete kryptovat vyzvy z
> ustredne v zariadeni pri autentikacii.
> V ustredni budete mat tento kluc tiez, pomocou ktoreho si vypocita
> hash v zariadeni. Tu je problem ten,
> ze ak sa attaker dostane k tomuto klucu bude si moct vyrabat vlastne
> hashe. Kryptovaniie samotnej vyzvy-
> xor by som dal az ako posledne riesenie pretoze sa da zlomit s
> obycajnou kalkulackou. Pouzil by som DES alebo nieco lepsie.
> Samozrejme symetricka sifra je nezmysel sam o sebe ale keby ste
> chceli pouzit privatny kluc, musel by byt
> pre kazde zariadenie unikatny a k nemu odpovedajuci verejny kluc v
> ustredni - co pre vas nie je riesenie.
> Ku dlzke samotneho hashu - cim dlhsi tym vacsia casova narocnost,
> 1024-4096 bitov (dnes standard) je
> pre vas ucel uz riadny overkill ale date tam 128 bitov a zlomia vam to.
>
>
> j.
>
>
> -----Original Message-----
> From: Hw-list [mailto:hw-list-bounces na list.hw.cz
> <mailto:hw-list-bounces na list.hw.cz>] On Behalf Of Ales Prochaska,
> Divesoft
> Sent: Monday, September 25, 2017 10:28 PM
> To: HW-news
> Subject: Re: Elektronicke autorizace zarizeni - algoritmy
>
> 80 bitů pro challenge i response by mělo imho stačit, nebude to
> louskat NSA :-). Místo prodlevy bych tam raději viděl výpočetně
> složitý algoritmus, třeba udělat hash, z něj zase hash atd., to celé
> třeba stokrát, takže prodleva bude zaručená nejen při odpovědi ale i
> při vyhodnocení.
>
> Otázka je, zda útočník bude mít exemplář zařízení a z něj získaný
> algoritmus (bude...), pak by to ještě chtělo, aby sériová čísla byla
> dostatečně dlouhá (80 bitů) a nepředpověditelná (vygenerovaná jako
> kryptograficky bezpečná náhodná čísla).
>
> Aleš Procháska
>
> > A je opravdu nutne aby jeden cyklus byl 50ms? Co kdyby zarizeni
> > odpovedelo ne okazite, ale za nejakou relativne dlouho dobu (par
> > sekund). Tim padem jeden dotaz (ten od vas - opravdovy) sice bude
> > trvat par sekund, ale to by nemuselo vadit. Utok hrubou silou se
> ale svinsky protahne...
> > Marek
>
> > 2017-09-25 16:28 GMT+02:00 Karel M <a8dtljb na gmail.com
> <mailto:a8dtljb na gmail.com>>:
>
> >> Zapomněl jsem dodat jednu důležitou věc, celé zařízení nemá běžný
> >> přístup k síti, v podstatě jde o měřící ústřednu ke které se
> >> připojují čidla a nejde v něm skladovat databáze už vydaných klíčů,
> >> protože zákazník si může koupit nové originální čidla a nikdo nebude
> >> do ústředny kvůli tomu nahrávat aktualizace.
> >> Takže ano, každé čidlo může mít své jedinečné výrobní číslo a šlo by
> >> poslat z ústředny xxx bajtů, které čidlo zašifruje a pošle zpátky,
> >> dle toho by se poznalo zde se jedná o originál.
> >> Otázka je, kolik těch bytů by minimálně muselo být, aby útok hrubou
> >> silou nebyl možný, tím myslím, že by jako někdo zjistil všechny
> možné kombinace.
> >> Nějaké časové ošetření asi také nepůjde udělat, protože by šlo
> poslat
> >> dotaz, přečíst odpověď a udělat reset a zas dokola, jesme tomu do
> >> 50ms jeden cyklus. Ono nejde ani tak o to, že si někdo čidla
> >> kopíruje, ale ta kopie nemá vlastnosti originálu a zákazník pak
> >> reklamuje špatnou funkci u výrobce originálu i když ten s tím
> čidlem nemá nic společného.
> >> K.
> >>
> >> 2017-09-25 15:10 GMT+02:00 Zuffa Jan <ZuffaJ na cgc.sk
> <mailto:ZuffaJ na cgc.sk>>:
> >>
> >>> A este doplnim:
> >>>
> >>> Ak si budete drzat databazu privatnych klucov u seba a viete
> >>> skotrolovat
> >>>
> >>> duplikovane zariadenia v sieti, jedine co bude moct attaker urobit
> >>> je, ze nahradi
> >>>
> >>> uz dodane zariadenie svojim. Kluce by mali byt samozrejme
> generovane
> >>> nahodne
> >>>
> >>> a dostatocne velke aby sa nedali uhadnut.
> >>>
> >>>
> >>>
> >>> j.
> >>>
> >>>
> >>>
> >>> *From:* Hw-list [mailto:hw-list-bounces na list.hw.cz
> <mailto:hw-list-bounces na list.hw.cz>] *On Behalf Of
> >>> *Zuffa Jan
> >>> *Sent:* Monday, September 25, 2017 3:07 PM
> >>> *To:* HW-news
> >>> *Subject:* RE: Elektronicke autorizace zarizeni - algoritmy
> >>>
> >>>
> >>>
> >>> Dobry den,
> >>>
> >>>
> >>>
> >>> Okremtoho, ze pouzijete nejaky chalenge – response algoritmus,
> >>> minimalne by bolo vhode zabezpecit
> >>>
> >>> aby kazde zo zariadeni malo svoj privatny kluc. Najjednoduchsie ma
> >>> napada ze bude korelovat so seriovym cislom zariadenia.
> >>>
> >>> Teda pre vas to bude znamenat ze na zaciatku si vyziadate seriove
> >>> cislo, nasledne poslete chalenge a vycitate response.
> >>>
> >>> Alebo si budete drzat databazu privatnych klucov u seba.
> >>>
> >>>
> >>>
> >>> j.
> >>>
> >>>
> >>>
> >>> *From:* Hw-list [mailto:hw-list-bounces na list.hw.cz
> <mailto:hw-list-bounces na list.hw.cz>
> >>> <hw-list-bounces na list.hw.cz
> <mailto:hw-list-bounces na list.hw.cz>>] *On Behalf Of *Karel M
> >>> *Sent:* Monday, September 25, 2017 2:48 PM
> >>> *To:* HW-news
> >>> *Subject:* Elektronicke autorizace zarizeni - algoritmy
> >>>
> >>>
> >>>
> >>> Pekny den, mam zarizeni, ktere ma v sobe MCU s vnitrni EEPROM, kde
> >>> jsou ulozeny parametry zarizeni, komunikace s vnejskem je po RS485.
> >>> Zarizeni neni trvale napajeno a jde tedy resetovat, nema
> informaci o datu a case.
> >>>
> >>> Co bych potreboval nove udelat, je nejaky sikovny algoritmus pro
> >>> autentizaci tohoto zarizeni, tedy ze se v nem nachazi nami vyrobena
> >>> elektronika. Predstava je takova, ze se posle nejaky paket s
> >>> pseudonahodnym slozenim, zarizeni to pomoci nejakeho algoritmu
> prepocte a posle zpet.
> >>>
> >>> Zajima me priklad nejakeho algoritmu vhodneho pro MCU a jak osetrit
> >>> utok hrubou silou, kdyz zarizeni jde resetovat, nepamatuje si
> tedy v
> >>> case chybne pokusy.
> >>>
> >>> Samozrejme je tu jeste priklad, kdy zarizeni bude kopie a paralelne
> >>> k nemu na RS485 elektronika z naseho zarizeni (treba ze starsiho
> >>> jinak zniceneho), to ale asi osetrit nejde.
> >>>
> >>> za tipy diky
> >>>
> >>> Karel
> >>>
> >>> _______________________________________________
> >>> HW-list mailing list - sponsored by www.HW.cz
> <http://www.HW.cz> Hw-list na list.hw.cz <mailto:Hw-list na list.hw.cz>
> >>> http://list.hw.cz/mailman/listinfo/hw-list
> <http://list.hw.cz/mailman/listinfo/hw-list>
> >>>
> >>>
> >>
> >> _______________________________________________
> >> HW-list mailing list - sponsored by www.HW.cz
> <http://www.HW.cz> Hw-list na list.hw.cz <mailto:Hw-list na list.hw.cz>
> >> http://list.hw.cz/mailman/listinfo/hw-list
> <http://list.hw.cz/mailman/listinfo/hw-list>
> >>
> >>
>
>
> _______________________________________________
> HW-list mailing list - sponsored by www.HW.cz <http://www.HW.cz>
> Hw-list na list.hw.cz <mailto:Hw-list na list.hw.cz>
> http://list.hw.cz/mailman/listinfo/hw-list
> <http://list.hw.cz/mailman/listinfo/hw-list>
> _______________________________________________
> HW-list mailing list - sponsored by www.HW.cz <http://www.HW.cz>
> Hw-list na list.hw.cz <mailto:Hw-list na list.hw.cz>
> http://list.hw.cz/mailman/listinfo/hw-list
> <http://list.hw.cz/mailman/listinfo/hw-list>
>
>
>
>
> _______________________________________________
> HW-list mailing list - sponsored by www.HW.cz
> Hw-list na list.hw.cz
> http://list.hw.cz/mailman/listinfo/hw-list
>
Další informace o konferenci Hw-list