Otázky k metodickému usmerneniu zo začiatku marca 2014

Na tejto stránke uvádzame novšie otázky k metodickému usmerneniu o študentských preukazoch, ku ktorým sa vyjadrili technickí experti vyjadrili v dňoch 5.-10.3.2014.. K otázkam sa vyjadrili títo kolegovia a partneri:

  • 05.03. - Emil Jamrich, IT, Katolícka univerzita v Ružomberku
  • 07.03. - Libor Manak, Cominfo
  • 09.03. - Róbert Orenič, IT, Žilinská univerzita a EUNIS
  • 10.03. - Peter Mráz, EMtest
  • 11.03. - Stanislav Sýkora, Ipex IT / VŠZSP v Bratislave - záverečné poznámky
  • 11.03. - Manak - dodatok k bodu 7
  • 12.03. - Orenič - dodatok k bodu 10
  • 12.03. - Manak / Sýkora - závery z telefonických rozhovorov k bodu 3

Farebne sú označené nejasnosti, ku ktorým sa treba ešte vrátiť.

Spoločný prístupový kľúč pre obidva záznamy - K = K1 = K2 ?

Ak dáta v preukaze sú rozdelené na 2 záznamy len z kapacitných dôvodov, aby sa vošli do sektorov v čipe Classic (max. 240 B každý), tak obidva by mohli mať rovnaký (spoločný) čítací kľúč "K". Tomu zodpovedá doterajšie znenie usmernenia, v ktorom kľúče K1 a K2 vystupujú vždy spolu a spolu sa aj distribuujú.

Túto úvahu sme vyslovili na rokovaniach v súvislosti s tým, že pri rozdielnych kľúčoch pre obidva sektory vraj bude treba zaregistrovať 2 samostatné aplikácie Mifare (AID) pre študentský preukaz. Technicky si viem predstaviť použitie odlišných kľúčov aj v rámci jedného AID, ale vraj také sú pravidlá Mifare. Je to pravda ?

Spoločný kľúč sme odmietli z dôvodov uvedených v ďalšom bode, takže asi budú potrebné 2 AID pre Classic. Platí to rovnako aj pre DESFire ?

Jamrich:

  • Podľa môjho vedomia AID nijako nesúvisí s množstvom použitých kľúčov. Nie je o tom žiadna zmienka v registračnom formulári ani v špecifikácii MAD 1,2,3. pokiaľ ide o registráciu.
  • Pre Desfire sa podľa MAD špec. dá použiť mapovanie pôvodného 16bit AID na 24bit AID nasledovne: 0xF(16b)X, posledné 4 bity môže použiť vlastník AID podľa ľubovôle, de facto teda z pôvodného AID získa 16 AID disponibilných pre Desfire.

Manak:

  • Zmíněné pravidlo o tom, že pro jedno AID musí být A/B klíče ve všechy využitých sektorech neznám. Umím si představit různé A klíče klíče pro sektor 0x20 a 0x21.
  • Co se týká DESFire:
    • aplikace (AID) může používat 14 klíčů
    • K1 je uložen v pozici 1 a je určen pro čtení souboru 1 (ekvivalent sektoru 0x20 na Mifare Standard)
    • K2 je uložen v pozici 2 a je určen pro čtení souboru 2 (ekvivalent sektoru 0x21 na Mifare Standard)

Mráz:

  • Nove AID pre Classic sú už zaregistrované: 585F, 5860
  • stále požadujeme pre dva rozdielne kľúče dve AID

Sýkora:

  • Spoločný prístupový kľúč pre obidva záznamy nebude.
  • Potreba dvoch AID kvôli rozdielnym prístupovým kľúčom k sektorom / súborom č. 1 a 2 sa ešte dokonzultuje. Prosím p. Mráza o jej zdôvodnenie.

Rozdielna miera utajenia prístupových kľúčov K1 a K2

Rozdelenie údajov na dva záznamy vzniklo už v usmernení z roka 2010 vraj nielen z kapacitných dôvodov, ale aj kvôli možnému odlíšeniu miery utajenia jednotlivých údajov:

  1. Prvý záznam obsahuje (takmer) verejné potvrdenie o návšteve školy, kde z osobných údajov študenta zostane len meno s titulmi (dátum narodenia sa presúva do záznamu č. 2).
  2. Druhý záznam obsahuje osobné údaje študenta, ktoré sa budú chrániť prísnejšie - kľúč K2 sa vydá poskytovateľom služieb len v odôvodnených prípadoch.

Nateraz sa rozhodlo, že všetci poskytovatelia služieb, ktorí o to požiadajú, dostanú kľúč K1 a len vybraní z nich aj kľúč K2. Zatiaľ sme však nepovedali, ako odlíšime tých "vážnych záujemcov" ?

Jamrich:

  • K odôvodneniu poskytnutia K2 - asi ťažko nájdeme všeobecne aplikovateľné pravidlá.

Manak:

  • lze takto používat

Orenič:

  • Už pri verzii 2010 som navrhol 2 kľúče pre dva záznamy a všetky dôvody trvajú ďalej. Takže som za takéto rozdelenie prístupu k dátam.

Sýkora:

  • Rozdielnu mieru utajenia prístupových kľúčov K1 a K2 som už vpísal do usmernenia. Rozhodnutie o tom, ktorému poskytovateľovi služieb sa vydá aj kľúč K2, bude asi trochu subjektívne a zostane na posúdení ministerstvu.

Verejný prístupový kľúč K1 ?

Kľúč K1 by sme mohli aj zverejniť, keby všetci ľudia už používali tieniace (hliníkové) karty medzi dokladmi. Bez nich stále trochu hrozí, že potenciálni útočníci na verejných miestach prečítajú údaje z kariet okolostojacich ľudí bez ich vedomia. Osobne si myslím, že tieniace karty alebo púzdra na doklady s "alobalom" sa časom začnú masovo používať aj kvôli bezkontaktným bankovým kartám, ale teraz to ešte nie je bežné. Takže ešte raz a naposledy - čo si myslíte o tejto možnosti ?

Túto možnosť sme zatiaľ neprijali, ale neskôr sa k nej určite vrátime.

Jamrich:

  • Public K1 - ak nebodaj, nech je to default key pre daný typ čipu.
  • Mohlo by to mať zmysel, keby Záznam č. 1 obsahoval údaje v rozsahu obvyklom pre registráciu do nejakého systému - napr. meno, adresa, číslo OP - registrácia vstupu do budov, registrácia ubytovania, reg. do knižnice a pod.

Manak:

  • Jakýkoliv znamý klíč použitý na kartě Mifare Standard zvyšuje sanci na úspěšně provedený útok a odhalení VŠECH kličů karty.
  • U karty DESFire toto nebezpečí nehrozí a dává smysl údaje nepodléhající ochraně osobních údajů zveřejnit.

Orenič:

  • Rozprával som sa s jedným „šikovným“ študentom, ktorý sa venuje bezpečnosti na Standard kartách. A vraj on, ak pozná akýkoľvek aspoň jeden kľúč k Mifare Standatd, tak mu výrazne uľahčí prístup aj k ostatným. Podrobnosti mi nechcel povedať, ale aj pán Maňák niečo také spomína, takže niečo na tom bude... Takže navrhujem žiadny verejný kľúč.
  • PS: dokonca vraj má jenu „čarovnú kartu“ z Číny, ktorej už takmer vie nanúťiť SNR podľa zadania. Dokonca už nieje daleko od naemulovania čísla cez NFC na rootnutom HTC One...

Mráz:

  • Priklanam sa nezverejňovať pri mifare strandard, pri DESfire na zváženie.

Sýkora:

  • Prístupový kľúč K1 nateraz nebude verejný a z bezpečnostných dôvodov na čipoch Classic nebudeme odporúčať ani oblasť NFC / NDEF na osobné záznamy držiteľa preukazu.

Manak / Sýkora - dodatok 12.03.:

  • Za rizikový sa považuje už verejný kľúč k sektorom MAD, ktoré na kartách predpisuje štandard Mifare a používame ho aj my. V citlivých aplikáciách sa preto odporúča nepoužívat sektory MAD a aplikácie alokovať na fixné sektory. To je však značne nekorektné voči štandardu Mifare a utajeniu obsahu karty to veľmi nepomôže.
  • Pre istotu na tento typ karty nemusíme pridávať ďalšie verejné sektory, ale aj tak sa musíme zmieriť s tým, že v súčasnosti dostupné softwarové nástroje umožňujú prelomiť fyzické kľúče k sektorom a získať obsah sektorov za niekoľko sekúnd alebo minút. Preto je nutné kľúče spoľahlivo diverzifikovať (CMAC) a obsah šifrovať.

Odlišné sady prístupových kľúčov pre DESFire a Classic -  KD1, KD2 a KC1, KC2

Keďže bezpečnosť kľúčov v čipoch Classic je nižšia ako v čipoch DESFire, mohli by sme zaviesť oddelené dvojice kľúčov pre tieto dva "svety". Ak niekto prelomí kľúče pre Classic, neprezradia sa zároveň aj kľúče pre DESFire.

Nezníži to riziko úniku kľúčov v dôsledku ľudskej chyby, lebo všetci poskytovatelia služieb musia dostať obidve sady kľúčov. Ale aj tak by to mohlo stáť za mierne zvýšenie administratívy a technickej zložitosti systému. Tento návrh sme predbežne prijali.

Jamrich:

  • Odlišné sady kľúčov pre Classic a Desfire - viac než dobrý nápad - faktická nevyhnutnosť, keby sa pre Classic nepoužívala diverzifikácia.

Manak:

  • Vzhledem k bezpečnostním problémům Mifare Standard je to rozumné.

Orenič:

  • Z dôvodu problémov na standartkách, je to podľa mnňa dobrý nápad mať inú sadu kľúčov - najmä ak nevieme, ako to dopadne s diverzifikáciou.

Mráz:

  • Áno, súhlasím.

Sýkora:

  • Do usmernenia som už vpísal osobitné sady prístupových kľúčov pre DESFire a Classic s označením K1, K2 a K1C, K2C.

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

Prístupové kľúče K1 a K2 hrajú rozhodujúcu úlohu v celom systéme ochrany osobných údajov študenta v pamäti preukazu. Preto im treba venovať osobitnú pozornosť.

Vydávanie kľúčov v bežne čitateľnej forme

Dosiaľ používaný spoločný prístupový kľúč k preukazom s čipom Classic je na svete už 10 rokov a zdá sa, že zatiaľ neunikol na verejnosť. Ale pozná ho snáď len spoločnosť EMtest a niekoľko vysokých škôl. Bude to takto fungovať aj vtedy, keď nové kľúče dostane napr. 100 poskytovateľov služieb ?

Mám obavu, že nie, ak budeme kľúče ďalej vydávať v bežne čitateľnej forme. Mohlo by to fungovať snáď len vtedy, keby kľúč K1 bol verejný a kľúč K2 by dostalo len niekoľko spoľahlivých subjektov - max. cca 20.

Ako som už uviedol, prezradenie kľúčov alebo rovno ich zverejnenie v usmernení, by nemuselo príliš vadiť, keby študenti používali tieniace karty. Karty by vybrali z vrecka len na registračných miestach poskytovateľov služieb a tam by im nemuselo vadiť, že odovzdávajú o sebe všetky dáta zapísané v pamäti preukazu. Ale kým to tak nie je, mali by sme kľúče spoľahlivo tajiť.

Povinné používanie modulov SAM

Po dohode na MŠ je v aktuálnom usmernení veta: "Poskytovateľom služieb ministerstvo vydá kľúče zapísané v pamäti bezpečnostných modulov „SAM“, odkiaľ ich nemožno spätne prečítať; iný spôsob vydania kľúčov sa použije len v odôvodnených prípadoch.". Tou výnimkou sa rozumie vydanie kľúčov v bežne čitateľnej forme, čo sa predpokladá len u veľkých a spoľahlivých firiem, ktoré budú kľúče zapisovať do veľkého počtu svojich modulov SAM v už existujúcich zariadeniach.

Povinné používanie modulov SAM prináša viacero vážnych otázok a nových problémov, ktoré by sme mali zvážiť pred definitívnym rozhodnutím:

  1. Kľúče zapísané v module SAM naozaj nemožno spätne prečítať a zneužiť ?
  2. Ak tieto kľúče nebudeme mať k dispozícii v aplikačných programoch, všetky kryptografické operácie s nimi musia zvládnuť moduly SAM. V našom prípade je to diverzifikácia kľúčov a šifrovanie len časti (!) fyzických záznamov (oboje je podrobnejšie uvedené ďalej).
  3. Ako možno zneužiť stratený alebo ukradnutý modul SAM - buď samostatne, alebo aj s čítačkou alebo celým terminálom ?
  4. Ako bude možné zneužiť nelegálne získaný modul SAM - len "lokálne" v rukách "nálezcu" ? Alebo bude možné funkcionalitu modulu zneužiť hromadne prostredníctvom nejakej webovej služby alebo mobilnej aplikácie tak, že ďalší ľudia dokážu na diaľku diverzifikovať kľúče a dešifrovať záznamy v cudzích preukazoch ?
  5. Existuje ochrana modulov SAM proti zneužitiu pomocou PIN (programovo alebo manuálne) a dokáže nám reálne pomôcť ?
  6. Koľko modulov Mifare SAM AV1/2 bude treba kúpiť, kto ich zaplatí a koľko stoja na slovenskom trhu (na webe niekde v zahraničí som videl veľkoobchodnú cenu do 10 $) ?

Zneužitie ukradnutých modulov SAM považujem za nebezpečné len v prípade čítania preukazov na diaľku bez vedomia ich držiteľov, ak sa nechránia tieniacou kartou. Na registračných miestach poskytovateľov služieb študenti odovzdajú svoje dáta vedome a dobrovoľne.

Použitie kariet Mifare na distribúciu utajených kľúčov

Ak nechceme vydávať kľúče v bežne čitateľnej forme a striktné používanie modulov SAM sa nám zdá príliš zaťažujúce alebo obmedzujúce, mohli by sme tajné kľúče vydávať na inom médiu. Mohli by byť zapísané napr. v osobitných kartách Mifare, ktoré pracovne označujeme ako Master-karty. K nim by sme dodávali jednoduchý program alebo programovú knižnicu, ktorá by dokázala tajné kľúče prečítať z Master-karty a použiť na prácu so študentskými preukazmi. Tajné kľúče by sa v počítači nikam neukladali - boli by prítomné len v pamäti počítača počas behu programu. Po reštarte programu by sa musela znova priložiť Master-karta k čítačke.

Takéto riešenie je menej bezpečné ako moduly SAM, ale na daný charakter aplikácie možno postačujúce. Najmä ak uvážime, že po zavedení tieniacich kariet (alebo po prechode na kontaktné / hybridné karty) tie tajné kľúče možno rovno zverejníme. Každodenné používanie Master-kariet však niekto môže považovať za obťažujúce.

Sprístupnenie tajných kľúčov on-line cez zabezpečenú webovú službu

Sprístupnenie tajných kľúčov, alebo rovno vykonanie príslušných operácií, na ktoré sú kľúče určené (diverzifikácia kľúčov, dešifrovanie údajov), by sme mohli vykonať aj on-line prostredníctvom centrálne zriadenej a dostatočne zabezpečenej webovej služby. Každý by dostal svoje prihlasovacie údaje a nebolo by treba kupovať moduly SAM ani vydávať iné fyzické nosiče kľúčov (Master-karty).

Ak webová služba bude mať prístup k údajom v CRŠ, mohla by sa použiť aj na overenie statusu študenta podľa UID preukazu, t.j. bez čítania akýchkoľvek údajov v pamäti preukazu. Alebo naopak, na zistenie neplatnosti preukazu s daným UID v "black-liste".

Podmienkou na použitie tejto metódy je dobre premyslená bezpečnosť webovej služby a internetové pripojenie na registračnom mieste poskytovateľa služieb. To by mohlo byť k dispozícii v drvivej väčšine prípadov - a kde nie, tam nech vystačia s vizuálom preukazu.

Kombinácia uvedených metód

Kto už má moduly SAM, nech ich používa ďalej. A ostatní si môžu vybrať iný mechanizmus práce s tajnými kľúčmi.

Jamrich:

  • Vydávanie read kľúčov v otvorenej forme - určite aj táto možnosť, MF SAM AV1/2 nie sú predsa jediným riešením.
  • Povinné používanie SAM - určite nie - nežiadúci vendor locking. Existujú aj iné alternatívy pre bezpečné uloženie kľúčov a krypto funkcie - smartcard, usb tokeny... Pokiaľ ide o bezpečnosť SAM - sú zdokumentované prípady zraniteľnosti vedľajším kanálom (napr. únik kľúčov z EEPROM/RAM procesora v čitačke). Vydolovanie kľúčov priamo zo SAM (zatiaľ) asi nehrozí.
  • Použitie MF kariet na distribúciu kľúčov - asi najmenej žiadúce riešenie, priveľa rizík a komplikácií.
  • Web service - naráža na reálnu potrebu offline režimu čítačiek, v praxi by to bolo asi primálo spoľahlivé s ohľadom na garantovateľné parametre siete.

Manak:

  • Pro subjekty, které budou karty vydávat, bude nezbytné dodat klíče v otevřeném tvaru (na papíře), aby si je mohl personalizovat do svých SAM/HSM modulu. Vyýdavatel karty potřebuje mít ve stejném SAMu dostupné i své vlastní klíče pro zápis.
  • Možnosti vydání klíčů na kartě DESFire lze zvážit, je nutné však údaje zabezpečit dalsím klíčem odvozeným např. od PINu. Pokud bude formát dat dokumentovaný, může si vydavatel karet personalizovat SAMy bez nutnosti opisovat údaje. Podobnou metodu pouziváme pro uchování klíčů i našich aplikacích.
  • Vytvoření webové služby je taky možné řešení, vystavením čehokoliv na internetu vzniká riziko napadení tohoto systému. Taková služba by se rovněž mohla stát úzkým hrdlem v celém systému.

Orenič:

  • Myslím že si to nezoberieme na triko, ak to bude celé zle. Osobne by som stále preferoval „otvorené“ odovzdanie kľúčov a každý poskytovateľ, resp. UNI si vyrieši bezpečné uloženie kľúčov vo svojom riešení. Nemusí pritom nutne ísť o vytlačenú A4, ale napr. len bezpečnejšie odovzdanie kľúčov (napr. zašifrovaný text na nosiči a tajomstvo odovzdané inou cestou). Nemyslím, že by sme mali riešiť, či to poskytovateľ naschvál neposkytne ďalej - to neustrážime.
  • Striktné SAMy sa mi stále moc nepozdávajú, keďže sme o nich funkčnosti neni presvedčení.
  • Spôsob uloženia kľúčov v pamäti pri behu aplikácie (načítanie z karty použitím PINu) podľa mňa nebude vyhovovať všetkým riešeniam. Nám napr. určite nie, keďže plánujeme verejné univerzitné terminály po celej škole.

Mráz - k modulom SAM:

  • 1 - kľúče nemožno spätne vyčítať
  • 2 (zvládnu diverzifikácia kľúčov a šifrovanie len časti (!) fyzických záznamov) - áno
  • 3 - strateny SAM sa samostatne zneužiť nedá, s terminálom áno, ale len v rozsahu pôvodnej aplikácie
  • 4, 5, 6 - skúste si predstaviť analógiu so stratenou SIM kartou v mobile, ale aj tu je veľa moznosti, ako zabezpečiť, aby nedošlo k zneužitiu (riešením je napr. aktivácia SAMu cez vzdialenú autentifikáciu ...)

Sýkora:

  • Zabudol som tu zdôrazniť, že vydavatelia preukazov dostanú spoločné kľúče v čitateľnej forme, takže tieto úvahy sa týkali len vydávania kľúčov poskytovateľom služieb. Pre istotu citujem celý text, ktorý je teraz napísaný v usmernení: "Prístupové kľúče K1 a K2 k údajom v pamäti preukazov ministerstvo vydá vydavateľom preukazov a poskytovateľom služieb na základe ich žiadosti. Poskytovateľom služieb ministerstvo vydá kľúče zapísané v pamäti bezpečnostných modulov „SAM“, odkiaľ ich nemožno spätne prečítať; iný spôsob vydania kľúčov sa použije len v odôvodnených prípadoch. O vydaných kľúčoch ministerstvo vedie evidenciu.".
  • Po tejto diskusii si myslím, že tento text netreba meniť. Takže zostane v hre len vydávanie kľúčov v čitateľnej forme a v moduloch SAM.
  • V telefonickom rozhovore dňa 10.3. mi p. Mráz povedal, že moduly Mifare SAM AV1 na študentské preukazy pravdepodobne nikto nepoužíva, takže všade môžeme pracovať s novšími modulmi SAM AV2. Toto je kľúčové zjednodušenie celého systému, ktoré má vplyv aj na diverzifikáciu kľúčov a šifrovanie údajov - podrobnejšie ďalej.
  • P. Mráz zároveň uviedol, že EMtest nepoužíva moduly SAM od MIfare, ale iné typy, ktoré sú programovateľné v jazyku Java. Preto sa vedia prispôsobiť rôznym požiadavkám. Možno by sme mohli v usmernení začať hovoriť o takýchto moduloch SAM, ale mám z toho trochu obavu - či nebudú príliš drahé alebo zložité na použitie pre bežných poskytovateľov služieb. Preto sa budem ďalej držať modulov "kompatibilných s Mifare SAM AV2".
  • Odpovede na otázku, či SAM AV2 dokáže dešifrovať len časť fyzického záznamu, zostali hmlisté - podrobnejšie ďalej.

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

Ak na čítanie údajov z preukazov nebudeme povinne používať moduly SAM, tak diverzifikáciu kľúčov aj dešifrovanie údajov budeme robiť v aplikačných programoch a môžeme si na to vymyslieť ľubovoľné algoritmy.

Ak tajné kľúče budú skryté v moduloch SAM, tak programovo sa k nim nedostaneme a diverzifikáciu kľúčov i dešifrovanie údajov musia zvládnuť samotné moduly SAM, resp. v spolupráci s čítačkou kariet na technickej úrovni. V takomto prípade postup diverzifikácie kľúčov uvedený v decembrovej verzii usmernenia pre čipy DESFire aj Classic nebol správny.

Vo februárovej verzii usmernenia sme uviedli opravený algoritmus diverzifikácie kľúčov pre čipy DESFire, ktorý zodpovedá doterajšej praxi v spoločnosti Cominfo a snáď aj EMtest (prosím potvrdiť!). Obdobný algoritmus pre čipy Classic som dostal, resp. ešte čakám v týchto dňoch (začiatok marca). Algoritmus pre čipy Classic sa považuje za dôverný a využíva sa v ňom staršia kryptografia typu 3DES. Spoločnosť Mifare obidva tieto algoritmy označuje ako "staré" a mal by ich zvládnuť aj starší modul Mifare SAM AV1.

Ako "novú" a bezpečnejšiu techniku diverzifikácie kľúčov spoločnosť Mifare prezentuje CMAC - Cryptographic Message Authentication Codes, ale tú poznajú až novšie moduly Mifare SAM AV2. V tomto algoritme možno použiť novšiu a spoľahlivejšiu kryptografiu typu AES-128. Technika CMAC je verejne zdokumentovaná a spoločnosť Mifare ju dôrazne odporúča použiť vo všetkých nových systémoch. Obzvlášť vhodná je v systémoch, kde sa budú kombinovať zariadenia s modulmi SAM i bez nich.

Otázky:

  1. Sú informácie uvedené vyššie správne ?
  2. Už existujúce moduly SAM v súčasnej prevádzke sú typu AV2, alebo väčšina z nich sú ešte staršie typy AV1 ?
  3. Dokázali by sme všade prejsť na nové moduly SAM AV2 - aspoň na registračných miestach poskytovateľov služieb (najmä v doprave) ?
  4. Sme natoľko technicky zdatní, že dokážeme prejsť na aktuálnu technológiu diverzifikácie kľúčov na báze CMAC ?
  5. Alebo budeme "novo" zavádzať do praxe staré diverzifikačné mechanizmy, ktoré už nie sú dostatočne spoľahlivé a firma Mifare ich ešte tají ?
  6. Ak neprejdeme na CMAC, nebolo by lepšie nezavádzať žiadnu diverzifikáciu čítacích kľúčov na čipoch Classic (na čipoch DESFire by sme ponechali existujúcu "starú" diverzifikáciu kľúčov) ?

Poznamenávam, že zavedenie alebo zmena diverzifikácie kľúčov si môže vyžiadať registráciu nového AID aplikácie Mifare (treba overiť).

Jamrich:

  • Diverzifikácia - prikláňam sa k CMAC a AES-128 - je to síce na prvý pohľad najkomplikovanejšie, ale otvorené a zdokumentované riešenie. V technickej zvládnuteľnosti problém nevidím. Div. algoritmy, ktoré nie sú priamo podporované SAM, by sme používať nemali.
  • Naši partneri môžu mať problém s CMAC - museli by meniť SAM moduly vo svojich čítačkách (aj keď vlastne ani nevieme, či ich vôbec používajú). K potrebe zmeny AID - viď bod 1.

Manak:

  • V závislosti na bodě 5). Pokud bude využíváno SAM modulu DESFire SAM AV2, je nutné využívat pouze takové metody diverzifikace klíčů, které SAM AV2 umožňuje.

Mráz:

  • Po telefonickom dohovore s p. Sýkorom je CMAC algoritmus pre Mifare standard najvyhodnejší.

Sýkora:

  • Keďže už nemusíme brať do úvahy staré moduly SAM AV1 (pozri poznámku v predchádzajúcej otázke), navrhujem okamžite a s veľkým rozbehom "odkopnúť" všetky "staré" diverzifikačné algoritmy. Podľa vyjadrenia Mifare sú vhodné už len v systémoch, ktoré musia byť spätne kompatibilné so SAM AV1. V nových systémoch Mifare striktne odporúča používať novú techniku CMAC podľa dokumentu AN10922 Symmetric key diversifications.
  • Techniku CMAC navrhujem použiť jednotne v čipoch Classic aj DESFire. Modul SAM AV2 by ich mal zvládnuť v režime AV2 aj v režime kompatibility s AV1.
  • Prosím o praktické overenie tohto návrhu !!!

Šifrovanie častí fyzických záznamov v pamäti preukazu

Vo fyzickom zázname (súbor, sektor) sa šifruje len tzv. "dátový záznam", t.j. bez úvodnej hlavičky (4 B) a záverečného elektronického podpisu (48 B). Dokáže to vykonať starší modul SAM AV1 ? A dokáže to vykonať nový modul SAM AV2 - napr. pomocou príkazu na dešifrovanie údajov "off-line" ?

Ak nie, tak nám to celé nebude fungovať a v usmernení musíme všetko prepísať. Alebo tajné kľúče nebudeme skrývať v moduloch SAM a kryptografiu budeme robiť v aplikačných programoch.

Jamrich:

  • Dokumentácia k SAM ako obvykle podlieha NDA, ale RSA by mal zvládať, s ECDSA to ružovo nevyzerá.

Manak:

  • V režimu AV1 toto SAM neumí. Umí použe šifrovat/dešifrovat data pro komunikaci s kartou (data která jsou vzduchem).
  • Režim AV2 nabízí offline kryptografii, která by podle dokumentace měla umožnovat šifrování libovolných dat. Neměl jsem zatím možnost toto ověřit.

Manak - dodatok:

  • SAM v rezimu AV1 umí šifrovat libovolná vstupní data. Klíč musí být správně nakonfigurován pro takové použití.
  • SAM automaticky před šifrováním doplní záznam o CRC32 a padding, zašifrovaný záznam tedy může být o jeden blok (16 byte) delší než vstup.
  • Zpracování dat musí být ve dvou krocích. Toto nelze spojit do jednoho kroku v žádném režimu SAMu:
    1. zašifrování dat pomocí SAM
    2. komunikace s kartou pomocí SAM

Mráz:

  • Encrip / Decript na AV1/AV2 SAMe sme neriešili. Náš SAM podporuje ľubovolnú navrhovanú variantu.

Sýkora:

  • Ak chcem dešifrovať len časť záznamu, mám na mysli takýto postup:
    • prečítam si dáta zo sektoru / súboru do počítača bez kryptografických úprav - v režime "plain text" (?)
    • pozriem si nešifrovanú hlavičku záznamu a v nej dĺžku šifrovaných dát
    • vyberiem zo záznamu príslušnú časť, pošlem ju modulu SAM a požiadam ho o dešifrovanie údajov - v režime off-line (?)
    • počas toho tajný šifrovací kľúč neopustí modul SAM
  • P. Maňák píše, že modul SAM AV2 v režime kompatibility s AV1 to nevie urobiť a v režime AV2 to nie je prakticky overené.
  • Veľmi dúfam, že to bude fungovať, lebo ak nie, máme len tieto možnosti:
    • dáta nebudeme šifrovať vôbec
    • dáta budeme šifrovať v celom sektore / súbore pri prenose na kartu a dešifrovať pri prenose z karty
    • kľúče nebudeme rozdávať v moduloch SAM

Elektronický podpis s inou eliptickou krivkou - sect163k1 ???

Na rokovaní 25.2. p. Mráz (EMtest) navrhol použitie inej eliptickej krivky na elektronický podpis údajov v preukaze. Konkrétne ide o krivku "sect163k1", ktorá pracuje s menším počtom bitov a jej podpis je dlhý len 42 bajtov. Takéto podpisy by vedel robiť a overovať nejaký iný "SAM" modul, s ktorým vo firme experimentujú.

O eliptických krivkách (ECDSA) sa hovorilo už v usmernení z roku 2010 a konkrétne o krivke P-192 hovoríme od mája 2013. Vieme o tom, že moduly Mifare SAM AV1/2 ich nepoznajú a sme pripravení podpisy overovať v klientskych aplikáciách. Nie je v tom žiadny problém, lebo na overovanie podpisov sa používajú verejné kľúče vydavateľov preukazov, ktoré netreba tajiť v moduloch SAM.

Uvedený návrh odporúčam nateraz zamietnuť z týchto dôvodov:

  1. Prijatím návrhu by sme sa pripútali k menej známej technológii, ktorá nie je kompatibilná so štandardom Mifare SAM AV1/2 a aj EMtest s ňou len teraz experimentuje (ak som dobre rozumel - nemám bližšiu písomnú špecifikáciu návrhu).
  2. Návrh prichádza VEĽMI neskoro - na krivku P-192 už máme všetko pripravené a odskúšané.

Jamrich:

  • Nevidím praktický význam takejto zmeny, ponechajme P-192. Ak krypto funkcie pre šifrovanie záznamu alebo overovanie podpisu nezvláda MF SAM, zvládne to aplikačný program, alebo iný - non MF hardvér.

Manak:

  • Myslím, že je na změnu pozdě.

Orenič:

  • Krivku P-192 vlani navrhol EMtest po rôznych experimentoch a problémoch s inými krivkami. Teraz to meniť je veľké riziko.

Mráz:

  • Bol to návrh, uvedenú krivku podporujú všetky doteraz vydané SAM moduly. Ak je možnosť zmeny, budeme radi, ale vieme si poradiť aj s existujúcou variantou.

Sýkora:

  • Ďalším dôvodom na opatrnosť je skutočnosť, že americký NIST do svojich odporúčaní zahrnul len krivky od P-192 vyššie - pozri Digital Signature Standard (DSS).

Elektronický podpis umiestniť na koniec fyzického záznamu ???

Na rokovaní 25.2. p. Mráz (EMtest) navrhol elektronický podpis umiestniť na koniec fyzického záznamu (súbor, sektor) tak, že nevyužité miesto v zázname sa ocitne v jeho strede - za dátovým záznamom a pred elektronickým podpisom. S tým by súvisela aj nejaká zmena šifrovania dát (nemám písomnú špecifikáciu návrhu).

Uvedený návrh odporúčam zamietnuť z týchto dôvodov:

  1. Nevidím žiadnu výhodu iného rozloženie voľného priestoru vo fyzickom zázname. Skôr naopak, terajšie umiestnenie všetkých častí záznamu za sebou s voľným miestom na konci je kompaktnejšie a v prípade potreby umožňuje skrátiť proces čítania alebo zápisu záznamu do čipu.
  2. Návrh prichádza VEĽMI neskoro - štruktúru záznamov máme už zdokumentovanú a máme k nej už naprogramované Demo na webe.

Jamrich:

  • Nevidím praktický význam takejto zmeny

Manak:

  • Verze záznamu určuje jeho strukturu, tedy s jinou verzi zaznum je mozne pozici podpisu posunovat. Nedokážu teď narychlo posoudit veškeré pro a proti obou variant.

Mráz:

  • OK súhlasím, zmena nie je nutná.

Sýkora:

  • Usmernenie v tomto smere nebudeme meniť.

Staré preukazy vydané podľa usmernení z rokov 2004 a 2010 by sa mali v septembri 2014 predĺžiť so starými dátovými štruktúrami ???

Na rokovaní 25.2. p. Škarbová (EMtest) vyslovila očakávanie, že preukazy vydané podľa starších usmernení sa predĺžia so starými dátovými štruktúrami. Ja som oponoval tým, že staré usmernenie sa ruší a nové v prechodných ustanoveniach povoľuje ponechať na preukazoch len starý vizuál, aby sa nemuseli fyzicky vymieňať všetky karty. Ale elektronické záznamy sa vymeniť dajú a s tým sa aj počíta, A tak sme to aj uzavreli.

Na tomto mieste považujem za potrebné zhrnúť dôvody, pre ktoré by sme takéto "zjednodušenie" nemali akceptovať ani v budúcnosti:

  1. Ak chceme systém otvoriť väčšiemu počtu poskytovateľov služieb, musíme ho aj zjednodušiť. Tomu sme podriadili aj návrh dátových štruktúr a snáď nejako zjednodušíme aj navrhované bezpečnostné prvky. V žiadnom prípade však nemôžeme nechať v obehu 3 rôzne dátové štruktúry z 3 generácií usmernenia.
  2. Jednotné dátové štruktúry podľa tohto usmernenia garantujú rovnaké dáta na preukaze bez ohľadu na to, či ide o nový alebo starý (predĺžený) preukaz a či obsahuje čip typu DESFire alebo Classic. Podľa starších usmernení v preukazoch bolo kadečo, a to ešte inak v rôznych čipoch.
  3. V starých preukazoch by nám chýbalo jedno PSČ pre železničnú dopravu, ktoré sme teraz doplnili do záznamu č. 2.. V dôsledku toho by sme nevedeli dosiahnuť jeden z hlavných cieľov novej právnej úpravy, a to že doprava sa dá nastaviť kompletne off-line ako každá iná externá aplikácia, t.j. len na základe údajov v študentských sektoroch preukazu - bez priameho prístupu do databázy VŠ.

Jamrich:

  • Jediným dôvodom by mohla byť administratívna neschopnosť - oneskorené schválenie MÚ, dlhé testovanie a pod. Zbytočne dlhé prechodné obdobia sú skôr na škodu - súbežne udržiavanie "po starom" a "po novom" je zvyčajne pridrahé.

Manak:

  • V zásadě by to znamenalo prehrání všech karet na nový formát. Pokud by se měnilo AID, byl by to u DESFire problém, odstranění aplikace neuvoňuje místo na kartě, pouze formátování.

Orenič:

  • Načo to zbytočne predlžovať ? Ak sa nové majú vydávať po novom, univerzity aj poskytovatelia budú pripravení, takže nech sú čo najskôr všetky rovnako.

Mráz:

  • Stále je z môjho pohľadu zmena existujúcich kariet rádovo zložitejšia ako nová štruktúra na novo vydávaných kartách.
  • Pri DESFire kartách môže nastat situacia, že na karte sa bez jej formátovania nové štruktúry nevojdu - minimálne na 4k DESFire vydávaných ŽU.
  • Rozumiem vyhodam, ale treba zvážiť aj rizika a všetky možne problémy, ktoré nastanú.

Sýkora:

  • Aj po varovaní p. Mráza som presvedčený, že jednorazová transformácia záznamov na všetkých kartách prinesie menej problémov ako dlhoročné trápenie sa s tromi rôznymi formátmi dát na dvoch typoch čipov a absencia niektorých údajov na starších kartách. Verím, že profesionáli to zvládnu a amatéri nech sa živia inak :-)..
  • Prosím špecifikovať riziká a navrhnúť riešenia.

Orenič - dodatok 12.03.:

  • Problémom je skutočne nedostatok miesta (najmä na našich 4 kB ŽU kartách vydávaných roky, teraz už máme 8kB), keďže obsadené miesto so starou štruktúrou vieme odstrániť len formátovaním karty a nie len vymazaním aplikácie. Na 8 kB by to asi problém nemal byť.
  • Keďže sa to týka len nás, nechcem, aby sa s tým zdržovalo schválenie Usmernenia. Tak to radšej uzavrime a my sa s P. Mrázom pokúsime nájsť riešenie problému (najmä aby študenti neprišli o nabitú peňaženku v SAD).

Treba overiť vzorové kalkulácie na stránke Demo

Na záver žiadam všetkých znalcov aj amatérov, aby overili naše vzorové kryptografické výpočty na stránke Demo. Tým získame istotu, že navrhované technické riešenia v usmernení sú správne a realizovateľné.

Manak:

  • Můžu potvrdit správnost diverzifikace klíče pro DESFire. Ostatní příklady jsem neměl možnost ověřit.