Pokus o finálny návrh technického riešenia preukazu z 13.3.2014

Na tomto mieste uvádzame návrh záverečných rozhodnutí ku kľúčovým technickým otázkam.

Utajenie prístupových kľúčov na čítanie údajov z pamäti preukazu a moduly SAM

Prístupové kľúče K1, K2 a ich alternatívy K1C, K2C pre čipy Classic vydavatelia preukazov dostanú v bežne čitateľnej forme, poskytovateľom služieb sa budú vydávať radšej v moduloch Mifare SAM AV2. V prvom prípade utajenie kľúčov bude treba zariadiť právnou cestou (NDA). V druhom prípade pôjde o bezpečnú technickú ochranu.

Treba zdôrazniť, že moduly SAM zavádzame do systému len ako nástroj na utajenie spoločných prístupových kľúčov pre poskytovateľov služieb. V ich prípade chceme, aby diverzifikácia kľúčov a dešifrovanie údajov prebehlo priamo v module SAM bez toho, aby kľúče opustili tento modul. Žiadnu ďalšiu funkcionalitu modulov SAM neplánujeme využiť, lebo všetko ostatné si vieme urobiť v klientskom programe. Samozrejme, vieme si takto urobiť aj diverzifikácii kľúčov a dešifrovaní údajov, keď kľúče budú vydané v bežne čitateľnej forme, t.j. bez modulov SAM.

Na čítanie preukazov sa použijú moduly Mifare SAM AV2 v režime kompatibility s AV1. Požitie týchto modulov v režime AV2 nateraz nie je overené. V súlade s dokumentáciou SAM AV2 p. Maňák potvrdzuje, že prepnutie modulu do režimu AV2 je nevratné, takže pri voľbe prevádzkového režimu modulu treba byť opatrný.

Diverzifikácia prístupových kľúčov

Na diverzifikáciu prístupových kľúčov pre čipy Classic aj DESFire sa jednotne použijú tzv. nové algoritmy CMAC so šifrovaním AES-128 podľa odporúčania Mifare AN10922 Symmetric key diversifications. Takúto diverzifikáciu kľúčov možno vykonať programovo v hostiteľskom počítači a aj pomocou modulu SAM.

Novší štandard CMAC je zložitejší ako dosiaľ používané "staré" mechanizmy na báze šifrovania 3DES, ale je bezpečnejší. To je osobitne dôležité v prípade čipov Classic, ktoré budú v obehu ešte veľa rokov. Pre čipy DESFire je rovnako prirodzenou voľbou.

Diverzifikáciu kľúčov technikou CMAC pre čipy DESFire vykonávajú moduly SAM na technickej úrovni bez priamej spolupráce s aplikačným programom. Pre čipy Classic modul SAM dokáže vygenerovať skrátený kód CMAC (8 bajtov) a odovzdať ho aplikačnému programu. Prvých 6 bajtov z neho program použije ako diverzifikovaný (fyzický) kľúč na prístup k sektoru.

Z bezpečnostného hľadiska by sme mohli namietať, že v prípade čipov Classic diverzifikované (fyzické) kľúče budú krátkodobo prítomné v pamäti aplikačného programu a mohli by sa nejako zneužiť. Ale keď si uvedomíme, že fyzické kľúče ku kartám sa dajú získať (prelomiť) aj jednoduchším spôsobom, toto riziko je prakticky bezvýznamné. Dôležité je uchovať v tajnosti spoločné prístupové kľúče v moduloch SAM.

Šifrovanie údajov v pamäti preukazu

Všetky údaje v preukazoch budú šifrované

Vzhľadom na to, že čipy Classic majú byť v prevádzke ešte veľa rokov (podľa diskusie na MŠ 5 - 7) a nelegálne nástroje umožňujú získanie prístupových kľúčov k údajom v nich vo veľmi krátkom čase (za niekoľko sekúnd alebo minút), je nevyhnutné začať údaje šifrovať. Zdá sa, že v prípade kariet DESFire by to nebolo potrebné, ale "zo solidarity" k čipom Classic zavedieme rovnaký mechanizmus na oboch typoch kariet. To nám zjednoduší text usmernenia aj implementáciu programového vybavenia spoločne pre obidva typy kariet.

Maximálne využitie pamäťového priestoru v súboroch / sektoroch na karte

Pri šifrovaní a dešifrovaní údajov v pamäti preukazu musíme zohľadniť ešte jeden problém, ktorý sa vynoril pri kapacitnej kontrole využitia priestoru vo fyzických záznamoch na oboch typoch čipov. Pre záznamy č. 1 a 2 na čipoch DESFire teraz rezervujeme súbory dlhé 224 a 288 bajtov, na čipoch Classic je to 2x 240 bajtov. Všetky tieto čísla sú násobkom 16 (v čipoch DESFire musia byť násobkom 32 bajtov, ale to teraz nie je podstatné).

V doterajšom znení usmernenia fyzický záznam obsahuje:

  • hlavičku - 4 bajty
  • zašifrované dáta - vždy násobok 16 bajtov (tento problém sa netýka nešifrovanej verzie dát)
  • elektronický podpis - 48 bajtov, čo je tiež násobok 16 bajtov

Z uvedeného vyplýva, že hlavička v záznamoch nám dosť prekáža - vďaka nej v každom fyzickom zázname zostane nevyužitých 12 bajtov. A to je citeľná strata najmä v prípade záznamu č. 2 na karte Classic, kde bude trochu tesno.

Tento problém sa dá jednoducho odstrániť tak, že hlavičku (4 bajty) zahrnieme do šifrovaného bloku údajov. Pri zostavovaní fyzického záznamu to nespôsobí žiadne problémy. Pri čítaní fyzického záznamu by sa dalo postupovať takto:

  • najprv sa prečíta a dešifruje prvých 16 bajtov záznamu - tým získame hlavičku záznamu
  • z nej získame dĺžku dát a podľa toho sa dešifruje ostatok záznamu

Pri podrobnejšom skúmaní tohto návrhu s ohľadom na reálne možnosti modulu SAM sme s p. Maňákom zvolili iné riešenie:

  • hlavička bude súčasťou šifrovanej časti záznamu
  • šifrovať a dešifrovať sa bude vždy celý záznam okrem elektronického podpisu na jeho konci - vždy to bude pevná časť záznamu s vopred vypočítateľnou dĺžkou
  • na konci šifrovanej časti záznamu treba rezervovať 4 bajty na CRC-32 pre šifrovací algoritmus modulu SAM

Technika šifrovania údajov - vybranej časti fyzického záznamu v pamäti preukazu

Na dešifrovanie údajov v pamäti preukazu poskytovatelia služieb budú prednostne používať moduly SAM. Ich technickým možnostiam sme preto prispôsobili štruktúru fyzického záznamu v čipe:

  • šifrovaná časť fyzického záznamu
    • hlavička - 4 B
    • dátový záznam - CSV
    • výplň - znaky 0x00 v potrebnej dĺžke
    • CRC-32 šifrovacieho algoritmu modulu SAM - 4 B,
  • elektronický podpis - 48 B (nešifrovaný)

Výplň sa nastaví tak, aby vyššie uvedená štruktúra kompletne vyplnila fyzický záznam. Inými slovami, na konci fyzického záznamu bude elektronický podpis a celý voľný priestor pred ním vyplní šifrovaná štruktúra dát s predpísanými údajmi a CRC-32 na konci.

Podľa vyjadrenia a experimentov p. Maňáka, modul SAM dokáže takto dešifrovať časť fyzického záznamu.

Dátum poslednej aktualizácie preukazu v zázname č. 1

Na záver prikladám ešte návrh na doplnenie zoznamu položiek v zázname č. 1. Ide o jednoducho realizovateľnú zmenu, ktorá by podstatne zvýšila dôveryhodnosť údajov zapísaných v preukaze.

Na začiatku záznamu č. 1 sa uvádzajú dátumy platnosti preukazu od - do, ale tie nič nehovoria o tom, k akému dátumu sú platné všetky údaje v preukaze. V usmernení niekde píšeme, že VŠ zodpovedá za správnosť údajov pri vydaní preukazu, jeho predĺžení alebo inej jeho aktualizácii po priložení k terminálu. Ak teda študent napr. v máji niekde priloží svoju kartu k čítačke, môžu ho odmietnuť a poslať späť do školy, aby im priniesol písomné potvrdenie o návšteve školy "nie staršie ako 1 mesiac".

Navrhujem preto v zázname č. 1 doplniť tretí dátum:

  • Dátum poslednej aktualizácie preukazu - 8 bajtov

V tomto zázname máme dosť voľného miesta a technicky nie je problém tento dátum aktualizovať pri každom priložení karty k terminálu na VŠ. Bez ohľadu na to, či v tej chvíli dôjde k aktualizácii nejakých údajov v preukaze alebo nie.

Viem, že čas prípravy preukazu je už vysoký, ale toto rozšírenie je veľmi jednoduché a užitočné.

13.03. - Emil Jamrich, KU Ružomberok

  • timestamp ma zhodou okolností tiež včera osvietil, ale už som sa ho obával aj navrhnúť :). Bude to veľmi dobré z hľadiska zodpovednosti VŠ za správnosť dát - v texte MU sa uvádzala zodpovednosť za správnosť v čase poslednej aktualizácie, a ten čas tam chýbal.