Pokračovanie technickej diskusie zo 14.3.2014

Keďže k finálnemu návrhu technického riešenia preukazu prišli odmietavé stanoviská, budeme pokračovať v technickej diskusii a až po dosiahnutí zhody sa dostaneme k paragrafovému zneniu usmernenia.

Prečo je to zložitejšie ?

13.03. - Daniela Ukropová, TU Zvolen:, EUNIS

  • Ucelom noveho usmernenia bolo zabezpecit bezpecnost, ale nekomplikovat si zivot tam, kde to nie je potrebne. Prosim o take riesenie, co bude prijatelne.

Pri spracovaní nového usmernenia som určite nehľadal komplikácie, ktoré nie sú potrebné. Problém je v tom, že som vychádzal z predchádzajúceho usmernenia z roku 2010, ktoré niekto napísal ľahkým perom ako nezáväzné literárne cvičenie a vôbec sa nestaral o technickú realizovateľnosť jednotlivých opatrení. Kľúčové technické aspekty v texte neboli uvedené vôbec, ďalšie sú tam len naznačené, ale nedajú sa realizovať, a iné veci sú také bludy, že o nich netreba ani hovoriť. V porovnaní s takouto povrchnosťou všetko trochu reálnejšie musí vyjsť zložitejšie.

V usmernení z roku 2010 sú napr. takéto vety: "Vydavateľ preukazu zabezpečí bezpečné uloženie prístupových kľúčov pre komunikáciu s ním vydávanými preukazmi, napríklad modulu SAM. Bezpečné úložisko kľúčov rovnako zabezpečuje všetky šifrovacie operácie vykonávané s údajmi...". Typ modulov SAM tam nebol uvedený, ale keďže preukazy sú postavené na štandarde Mifare, dá sa predpokladať, že išlo o Mifare SAM AV1/2. A tie nedokážu pracovať s hlavičkami a dátovými štruktúrami uvedenými v usmernení. A práve toto sme dolaďovali v posledných dňoch.

EMtest používa sofistikovanejšie moduly SAM iného typu, ktorých funkcionalitu si dokážu sami naprogramovať v jazyku Java. Ale takéto moduly asi nebudú vhodné na širšie použitie u bežných poskytovateľov služieb - kvôli cene, zložitosti nasadenia do prevádzky alebo závislosti na technológiách spoločnosti EMtest.

Ďalším dôsledkom povrchnosti usmernenia z roku 2010 je to, že na ŽU si zvolili príliš krátke súbory na dátové záznamy. Vtedy ešte netušili, že len elektronický podpis môže zabrať 56 bajtov. Ja som ho síce skrátil na 48 bajtov, ale aj to je veľa.

Pokiaľ viem, šifrovanie ani elektronický podpis sa vtedy nezaviedli do praxe. Ak to chceme teraz oživiť, nutne z toho vznikajú komplikácie.

Treba chrániť kľúče v moduloch SAM ?

Ako som uviedol vyššie, ochrana kľúčov pomocou modulov SAM bola uvedená už v usmernení z roku 2010. Teraz chceme kľúče rozdávať potenciálne väčšiemu počtu poskytovateľov služieb, takže potreba bezpečnosti je ešte vyššia. Preto sú teraz moduly SAM viac prítomné v usmernení a v posledných dňoch sme overovali ich možnosti. Tým sa veci ešte skomplikovali.

Ak vedenie EUNIS jednoznačne a záväzne rozhodne o tom, že moduly SAM používať nebudeme, môžem z usmernenia vyhodiť všetky zmienky o nich a všeličo sa zjednoduší. Ale musí byť absolútne jasné, kto o tom rozhodol. Menovite pre prípad, že sa raz niektorí študenti začnú súdiť so svojimi VŠ o tom, že ako vydavateľ preukazu nevykonal dostatočné opatrenia na ochranu ich osobných údajov v preukazoch, ktoré im nanútil v mene zákona a vydal podľa tohto usmernenia. Alebo až sa nám začnú chechtať v novinách, že v IT na VŠ pracujú rovnakí hlupáci ako tí, čo prednedávnom vymysleli heslo NBUSR123.

Máme sa ešte starať o preukazy Classic ?

13.03. - Róbert Orenič, ŽU, EUNIS:

  • Budúcnosť mala byť v desfire kartách a nakoniec sa desfire komplikujú na úrok štandartiek. (so solidaritou v tomto mieste moc nesúhlasím).

Už v roku 2010 sa tieto čipy považovali za výbehové natoľko, že vtedajšie usmernenie ich takmer obišlo a nevytvorilo v nich rovnaké dátové štruktúry ako na nových čipoch DESFire. Teraz je rok 2014 a pri poslednej debate na MŠ tieto čipy dostali ďalší priestor min. do roku 2021. Lebo majú životnosť 6 rokov a študentom nechceme vydávať nové preukazy ani vtedy, keď ukončia jedno štúdium a začnú nové (bakalárske -> magisterské). Takto o tom hovoril EMtest, ale v podstate len citoval názory viacerých VŠ. A za tieto spiatočnícke názory zodpovedá aj EUNIS (naša pracovná skupina), ktorá ich nemala len počúvať, ale aj rozumne usmerňovať.

Pri takto dlhej perspektíve čipov Classic ich nemôžeme nechať zastarať so zlou úrovňou bezpečnosti a nedostatočnými informáciami v záznamoch. Dokonca aj odsunutie týchto preukazov do prechodných ustanovení je nesprávne.

Považujem za správne, aby vedenie EUNIS akceptovalo reálny stav a pri rozhodovaní o preukazoch plnohodnotne zastávalo aj držiteľov preukazov Classic. Z posledných mailov mám skôr pocit, že kolegovia hája skôr záujmy vlastných škôl ako záujmy všetkých VŠ.

Treba šifrovať údaje v preukazoch ?

Z predchádzajúcej diskusie jasne vyplynulo, že údaje v čipoch Classic treba šifrovať. Súhlasíte aspoň s tým ?

Treba šifrovať údaje aj v čipoch DESFire ?

13.03. - Róbert Orenič, ŽU, EUNIS:

  • Desfire karty v podstate šifrovať nieje potrebné, a myslel som, že my (ŽU) ich ani nebudeme šifrovať, nakoľko bola hlavička súboru, ktorá hovorilo o tom či je súbor šifrovaný alebo nie takže poskytovateľ bude vedieť čo s tým.
  • Teraz sa navrhuje šifrovať aj údaj o tom či je to šifrované...
  • Osobne by som navrhoval desfire vôbec nešifrovať.

Vo finálnom návrhu som včera uviedol, že aj preukazy DESFire budeme šifrovať, lebo to "zjednoduší text usmernenia aj implementáciu programového vybavenia spoločne pre obidva typy kariet". Mal som na mysli to, že štruktúru fyzického záznamu pre obidva čipy môžeme pripraviť rovnako a odlišný bude len ich zápis na konkrétny typ karty v najnižšej vrstve programového vybavenia. Cenou za túto jednotnosť je nutnosť rezervovať 4 bajty na CRC-32 šifrovacieho algoritmu modulu SAM a čas potrebný na dešifrovanie údajov (neviem kvantifikovať).

Vyššie uvedený diskusný príspevok Roba Oreniča nateraz beriem ako jeho osobný názor, vyslovený s miernou neistotou v hlase :-). Ale ak vedenie EUNIS jednoznačne a záväzne rozhodne o tom, že údaje v čipoch DESFire sa nebudú šifrovať, tak fajn - môžeme to tak urobiť. Len si treba uvedomiť nevyhnutné dôsledky:

  • Rozhodnutie o šifrovaní údajov v čipoch Classic bude napísané v  usmernení "na fix" a rovnako tak by malo byť uvedené aj rozhodnutie o čipoch DESFier. Aký význam má individuálne zapínanie alebo vypínanie šifrovania na jednotlivých VŠ ? Kto tam má o tejto veci "viac rozumu" ako teraz EUNIS po konzultáciách s externými expertmi ? A prečo jedni študenti majú byť vo väčšom bezpečí ako iní, keď pre všetkých platí rovnaký zákon o ochrane osobných údajov ?
  • Ak by sme predsa chceli šifrovanie v DESFire zapínať / vypínať individuálne, nebude to už na základe osobitného bajtu v hlavičke záznamu, lebo tá už bude súčasťou šifrovaného bloku údajov (kvôli lepšiemu využitiu pamäťového priestoru na karte). Na začiatku týždňa som ešte počítal s tým, že o prípadnom šifrovaní súboru sa dozvieme z AID aplikácie, ale túto poznámku som medzičasom zrušil ako zbytočnú.
  • Ak globálne rozhodneme o tom, že DESFire sa šifrovať nebudú, stane sa toto:
    • zmienka o šifrovaní v čl. 9 o čipoch DESFire sa stane bezpredmetná a zruší sa
    • štruktúra údajov vo fyzickom zázname DESFire sa zjednoduší takto - hlavička, dáta, podpis, výplň (pekne jednoduché :-)
    • postup šifrovania sa definuje až v prechodných ustanoveniach o čipoch Classic, t.j. v čl. 17
    • tam bude treba napísať aj štruktúru údajov v sektore podľa môjho finálneho návrhu, t.j. - hlavička, dáta, výplň, CRC-32, podpis
    • primerane tomuto sa skomplikuje programové vybavenie na prácu s preukazmi
  • Nie som zásadne proti takejto zmene, ale treba poznať dôsledky.

Preformátujeme karty DESFire ?

13.03. - Róbert Orenič, ŽU, EUNIS:

  • Ešte predsa len k tým „našim“ 4kB kartám. Problém sa asi netýka len nás, ale aj univerzít ktoré využívajú desfire karty aktívnejšie a týmito „značnými“ zmenami vo veľkostiach súborov za behu nastávajú komplikácie (napr.školy ktoré značnú časť využívajú pre prístupový offline systém SALTO - UK napr. atď): Čiastočným (skoro univerzálnym) riešením by bolo:
    1. Podmienka: Na desfire nemeniť AID aplikácie
    2. Pre takéto karty využívať len doterajších 192B (bez podpisu) čo by malo skoro na celý záznam postačovať.
    3. Bezproblémový prístup k hlavičke súboru by mal byť tiež podmienkou

O problémoch spojených s preformátovaním kariet DESFire sme už hovorili v súvislosti s tým, že bude treba "zachrániť" študentské peňaženky používané v doprave. A uzavreli sme to s tým, že EMtest k nim má prístup a snáď to dokáže zariadiť.

Teraz sa môžeme zamerať na priestor potrebný na študentský preukaz na karte. Tu sú moje poznámky k danej téme:

  • Karta, o ktorej hovoríme, sa volá "Študentský preukaz" a tomuto účelu by sme mali venovať primárnu pozornosť. S kolegami z EMtestu sme sa na MŠ zhodli na tom, že 1/2 kB na karte s kapacitou 4 kB alebo 8 kB je rozumné a snáď aj postačujúce minimum. Aj keď v usmernení sa hovorí, že na kartách Classic sa rezervuje "sektor 0x22 na uloženie prípadných ďalších centrálne určených údajov", čo by bolo už 3/4 kB. Čo na to povieme v prípade karty DESFire ?
  • Na kartách Classic už 10 rokov využívame kapacitu 2x 240 B = 480 B. Kto a prečo na terajších kartách DESFire rezervoval pre študentský preukaz menší priestor ako je toto číslo ?
    ospravedlňujem sa - táto otázka je trochu nekorektná. S novým usmernením pracujem už tak dlho, že som celkom zabudol, že na kartách Classic sa ešte stále používa len 1 sektor, t.j. 1x 240 B (druhý sektor bol len rezervovaný).
  • Prečo sú v prevádzke karty DESFire s kapacitou 4 kB a celé sú zapratané tak, že sa do nich nezmestí ani to, čo zvládnu staručké karty Classic ? To vtedy ešte neboli karty DESFire 8 kB, alebo niekto chcel ušetriť a teraz z toho máme problémy ?
  • Rozhodnutie o tom, že v oboch záznamoch na karte sú elektronické podpisy, je v návrhu usmernenia od mája 2013. Prečo to ideme meniť v polovici marca 2014 ?
  • Rovnako dlho vieme, že diakritika v kódovaní UTF-8 predlžuje texty a že adresy v zázname č. 2 môžu byť celkom dlhé (ja som to nevymyslel)...

Ok, môžeme to riešiť, lebo záznam č. 2 bude natesno aj na karte Classic. Schválili by ste napr. také riešenie, že v zázname č. 1 bude spoločná hlavička a spoločný elektronický podpis, ktorý pokrývať dáta uvedené v obidvoch záznamoch ? To by však znamenalo, že z karty treba prečítať vždy obidva záznamy súčasne a kľúče K1 a K2 môžu byť rovnaké. Takže toto asi nie.

Ak jednoducho vynecháme elektronický podpis v zázname č. 2, tak údaje v ňom uvedené nebudú chránené proti falšovaniu. A to asi tiež nie.

Má niekto pocit, že týmto systém nejako zjednodušíme ? Má niekto iné návrhy ?

14.03. - Manak Libor, Cominfo

  • Na DESFire se uvažuje o změně velikostí souborů, což obnáší nutnost jejich vymazání z karty. Vymazané údaje lze však definitivně uvolnit pouze formátováním celé karty. Čili zde mluvíme o cca 1kB dat (stará + nová aplikace), což je 1/4 kapacity karty.
  • U DESFire lze přece jednoduše vyřešit nedostatek místa v souboru přídáním dalších souborů do existující aplikace. Do nových souborů by se např. mohl uložit podpis a původních 192 bytů ve stávajícíh souborech využít pouze pro data.

Zrušiť doterajšiu aplikáciu a pre ňu alokovaný priestor (súbory) nechať zavadzať na karte asi nie je dobré riešenie. To už radšej kartu preformátovať, ako som predpokladal doteraz.

Ak nechceme kartu preformátovať, asi by sme mali vedieť, čo na nej máme teraz. Z textu p. Maňáka sa zdá, že sú to 2 súbory po 192 B. Je to tak rovnako na celom Slovensku ?

Do prvého súboru by sme možno vtesnali záznam č. 1 aj s elektronickým podpisom. Ale pre záznam č. 2 je to dosť málo aj bez elektronického podpisu - vlastne rovnako ako v sektore Classic s podpisom (rozdiel v dĺžke sektora a súboru je práve 48 B).

Návrh p. Maňáka na virtuálne predĺženie terajšej dvojice súborov o ďalšiu dvojicu súborov znie veľmi dobre až geniálne :-), ak to nespôsobí priveľkú réžiu pri práci s kartou. Aplikoval by som ho trochu univerzálnejšie tak, že v predlžujúcich súboroch by mohli plynulo pokračovať dáta a za nimi elektronický podpis. A vôbec by nevadilo, keby zlom medzi záznamami nastal uprostred nejakej položky alebo elektronického podpisu. Pokračujúce súbory by mali rovnaké prístupové kľúče K1 a K2 ako základné súbory a ich dĺžka by bola 32 B (+ 192 = 224 B) a 96 B (+ 192 = 288 B). Zmienku o takomto riešení pre už existujúce karty si viem živo predstaviť v prechodných ustanoveniach usmernenia.

14.03. - Emil Jamrich, KU Ružomberok

  • Túto variantu - t.j. podpis v osobitnom súbore - som navrhoval ako alternatívu už dávnejšie, ale narazila na mne málo pochopiteľnú požiadavku identickosti štruktúry záznamov na Classic aj Desfire.
  • Btw: ak je doteraz alokovaná veľkosť 192B, po odrátaní podpisu a crc ostáva 140B na užitočné data, čo by malo byť pre drvivú väčšinu záznamov typu 1 viac než dosť. Iba ak by sa tam vyskytol nejaký "Juan Miguel Rodrigez ..." Prípadne sa môžu položky skracovať obdobne, ako to bolo plánované pre Classic. Osobne si však stále myslím, že v záznamoch je nadnormatívne množstvo nepotrebných položiek.

Ak vec budeme riešiť tak, aby sme mali málo roboty v tomto júli alebo septembri, tak môžeme vymýšľať všakovaké krkolomnosti v dátových štruktúrach a ťahať ich za sebou v aplikačných programoch ďalších 17 rokov. Karty Classic používame od roku 2004 a skončia možno v roku 2021. Takže DESFire vyradíme z obehu v roku 2027.

Ja osobne dávam prednosť čistej architektúre systému pred krkolomnými záplatami, ktoré sa lepia jedna cez druhú. V IT brandži robím práve preto, že veci sa dajú pružne zmeniť a už zajtra môžu fungovať inak. Ak by mi vyhovovali prístavby, prestavby, opravy a vysprávky, bol by som stavbár.

Takže radšej karty preformátujem a budem rád, že som tento proces zvládol, lebo do roku 2027 sa mi to zíde ešte viackrát.

Tento text som napísal počas piatej hodiny mojich odpovedí na vaše pripomienky a zjavne som už nebol celkom pozorný. S odstupom času to nechcem zmeniť, len vyššie uvedený žltý text už nepovažujem za kostrbatú záplatu, ale systémovo čisté riešenie pre staré karty na dožitie. A ľutujem, že ma to nenapadlo skôr.

Ale aj tak, nebolo by lepšie preformátovať karty ... ?  :-)

Dala by sa nejako eliminovať hlavička záznamov ?

13.03. - Emil Jamrich, KU Ružomberok

  • K hlavičke, ktorá má podľa draftu stále 4 B - osobne by som sa jej rád nejako zbavil: Z pôvodnej hlavičky už potrebujeme len jeden bajt na verziu záznamu.
  • Čo keby sme zrušili pojem hlavička a povedali by sme, že prvou položkou záznamu je verzia záznamu ?
  • K ostatným položkám hlavičky:
    • šifrovanie/nešifrovanie sa stáva zbytočným, ak sa prijme jednoznačné rozhodnutie
    • dĺžka záznamu sa po posledných úpravách a dohodách stala tiež zbytočnou - koniec užitočného dešifrovaného záznamu určuje prvý null byte. A keby nebodaj sa štruktúra naplnila na chlp bez paddingu: rec_size = fixed_file_size - signature_size - crc_size.
    • Inak sa mi ten draft po technickej stránke už celkom páči :)
  • Stále ostáva nevyužitá možnosť využívania sub-AID poslednými 4 bitmi z 3B Desfire AID

S indikáciou šifrovania v hlavičke záznamov už nepočítam, len som to tu takto explicitne nenapísal. Verzia záznamu by mohla byť súčasťou "aplikačných dát", lebo určuje zoznam položiek v zázname a ten aplikácia musí poznať a rešpektovať. Trochu je otázne, či v tejto verzii je zahrnutá aj zmena technikálií, o ktorých tu teraz diskutujeme, alebo tie budú spojené skôr s AID. Dĺžka dát by sa mohla vynechať, keby za nimi vždy nasledovala výplň 0x00 a podpis by bol až na konci fyzického záznamu. Ale to je trochu nečisté - priveľmi to závisí na kontexte dát a výsledku týchto diskusií. A zabudli ste ešte na číslo kľúča na overenie elektronického podpisu - to je taká technikália, ktorá príliš nepatrí do aplikačných dát.

Takže hlavičku chcem zatiaľ zachovať. Dosť som o tom rozmýšľal, keď som zistil, že mi zavadzia a kvôli nej by sme stratili 12 B v každom zázname.

Ak zmeníme len sub-AID v posledných 4 bitoch, zostane zachovaná väzba aplikácie na doterajšie súbory ? Ak áno, tak verzovanie technických aspektov aplikácie by sme mohli robiť takto (súbory, diverzifikácia kľúčov, šifrovanie) a v dátach by sme mali len verziu dátovej štruktúry, t.j. zoznam položiek. To by bolo celkom pekné riešenie.