Otázky k metodickému usmerneniu z obdobia 12/2013 - 02/2014

Na tejto stránke uvádzame staršie otázky k metodickému usmerneniu o študentských preukazoch, ktoré sa už prebrali a uzavreli na rokovaniach na MŠ.

CSV a položky s pevnou dĺžkou - sú naozaj potrebné ? 05.12.2013

Formát CSV slúži na úsporné uloženie znakových údajov s premenlivou dĺžkou. Tento koncept je jednoduchý a mal by byť prijateľný pre všetky programovateľné zariadenia na prácu s kartami. Pre prípad výskytu "ťarbavých" zariadení, ktoré dokážu pracovať len s položkami na pevných pozíciách, sme do usmernenia zaviedli pojem "reťazec znakov s pevnou dĺžkou" a všetky takéto položky sme zaradili na začiatok dátového záznamu. Tento kompromis trochu narúša čistotu dátových štruktúr a môže spôsobiť zbytočné nedorozumenia (napr. položky Osobné číslo a PSČ by mali obsahovať koncové medzery, ak nemajú potrebnú dĺžku). Existujú naozaj takto "obmedzené" zariadenia, alebo tento kompromis možno zrušiť a všetky položky môžu byť orezané, t.j. bez koncových medzier ?

EMtest 12.12.2013:  Nie je pre nás potrebné.

Orenič 20.01.2014:  Súhlas, ak to nevadí kľúčovým poskytovateľom služieb - dopravcom.

Sýkora 25.02.2014:  Žiadne položky nebude treba dopĺňať medzerami na pevnú dĺžku.

Budú sa šifrovať len textové položky na konci záznamu ? 05.12.2013

Návrh šifrovať len textovú časť dátových záznamov (konkrétne meno a adresy) je opäť len kompromisom s ohľadom na "menej inteligentné" čítacie zariadenia. Naozaj môžu nastať problémy s dešifrovaním údajov na niektorých zariadeniach a kvôli tomu základné osobné údaje treba nechať voľne čitateľné (nešifrované) ?

EMtest 12.12.2013:  Je vhodné šifrovať celý záznam, externé aplikácie nepoužívajú zariadenia, pre ktoré by bolo potrebné deliť dátové záznamy na šifrované a nešifrované.

Orenič 20.01.2014:  Súhlas, ak to nevadí kľúčovým poskytovateľom služieb - dopravcom (železnice by mali byť bez problémov).

Sýkora 25.02.2014:  Budú sa šifrovať celé dátové záznamy, t.j. okrem úvodných bajtov v hlavičke technického záznamu a elektronického podpisu,

Elektronický podpis má len 48 bajtov 05.12.2013

V písomnom návrhu Prílohy č. 2 k usmerneniu sme uvádzali elektronický podpis v dátovej štruktúre ASN.1 DER, ktorý mohol mať až 56 bajtov. To sa ukazuje ako zbytočné a na stránke Demo je šírka podpisu minimalizovaná na 48 bajtov (obsahuje len dvojicu čísel R a S po 24 bajtov).

EMtest 12.12.2013:  Ide o úsporu miesta.

Orenič 20.01.2014:  Súhlas, ak sú tieto informácie správne.

Sýkora 25.02.2014:  Elektronický podpis bude mať len 48 bajtov.

Kód vydavateľa preukazu 05.12.2013

V návrhu Prílohy č. 1 k usmerneniu je uvedené, že kód vydavateľa preukazu je 9-miestny a zodpovedá číselníku CRŠ. V Prílohe č. 2 k usmerneniu je uvedený 4-miestny kód podľa staršieho číselníka ÚIPŠ, ktorý sa na preukazoch používa teraz. Keďže číselník ÚIPŠ je už zastaraný, mali by sme prejsť na číselník CRŠ, ale jeho kód je zbytočne dlhý. Mohli by sme urobiť kompromis a z číselníka CRŠ použiť len prvé 3 znaky, ktoré dostatočne presne určujú konkrétnu VŠ ?

EMtest 12.12.2013:  Pre externé funkcionality je identifikácia školy postačujúca. Je možné používať aj plný 9-miestny číselný kód.

EUNIS Nitra:  Účastníci stretnutia nenamietali proti použitiu 3-miestneho kódu podľa CRŠ a ukážka Demo je už takto upravená.

Orenič 20.01.2014:  Všetky školy si to budú musieť prerobiť, a pritom to nie je veľmi dôležité.

CKM SYTS 31.01.2014:  Urcite je vhodne pouzit cely 9-miestny kod, nakolko toto riesenie, ako je spomenute aj v texte tychto stranok, budu vo vysokej miere kopirovat aj stredne resp. zakladne skoly pre svoje preukazy ziaka. Podla UIPS stredne skoly pouzivaju 9-miestny kod:  Register škôl a školských zariadení.

Sýkora 25.02.2014:  Kód vydavateľa preukazu bude obsahovať aj kód fakulty a miesta štúdia študenta, t.j. všetkých 9 znakov podľa číselníka CRŠ.

Kompetencie a zodpovednosť vydavateľa preukazu za umiestnenie aplikácií 05.12.2013

Text usmernenia naznačuje, ako majú byť v pamäti preukazu umiestnené údaje o študentovi a niektoré ďalšie aplikácie preukazu. Je na zváženie, či by tam nemalo byť osobitne zdôraznené aj to, ako má vydavateľ preukaz inicializovať (formátovať), aby poskytovatelia iných služieb mohli naň následne zapísať svoje dáta - pre dopravné a iné aplikácie.

EMtest 12.12.2013:  Áno, môže byť, treba bližšie špecifikovať.

Doplnené 18.12.2013:

Ide o to, že VŠ ako vydavateľ preukazu zodpovedá len za „študentské záznamy“, ktoré musí zapísať na kartu ako prvé. Zároveň musí na karte vyhradiť miesto aj na ostatné plánované záznamy (aplikácie) pre všetkých interných aj externých poskytovateľov služieb študentom.

Externí poskytovatelia služieb (vrátane dopravy) musia vychádzať z už existujúcich údajov v „študentských záznamoch“. Prakticky to znamená, že napr. dopravný terminál EMtest musí byť schopný vytvoriť svoje dopravné záznamy na preukaze aj bez priameho prístupu k informačnému systému VŠ, t.j. len na základe údajov prečítaných zo študentského preukazu. Takto nakonfigurovaný terminál môže byť umiestnený napr. na železničnej alebo autobusovej stanici, v nákupnom centre a pod. Samozrejme, môže byť aj vo vestibule školy, ak ho tam škola chce mať.

Tento koncept má niečo spoločné s experimentom na UKF v Nitre, kde škola štandardne vydá preukaz študenta bez dopravných oprávnení. Tie si študent môže dodatočne objednať a zaplatiť cez osobitný web a dopravný terminál mu ich dodatočne zapíše na študentský preukaz. To umožňuje znížiť cenu preukazu pre tých študentov, ktorí neplánujú využívať zľavy v doprave.

Rovnako by mali fungovať aj ostatní poskytovatelia služieb, ktorí teraz nemajú priamy prístup na VŠ a do preukazu sa vlastne vôbec nedostanú.

Orenič 20.01.2014:  Určite áno. Neviem, či je na to priestor v usmernení... skôr to dať ako prílohu usmernenia alebo iný formát, aby sa to dalo dopĺňať. Web portalVs – sekcia preukazov ?

Sýkora 25.02.2014:  Táto kompetencia a zodpovednosť vydavateľa je aspoň naznačená v texte usmernenia.

Organizačné a právne opatrenia na ochranu osobných údajov u poskytovateľov služieb 18.12.2013

Dala by sa zodpovednosť za ochranu osobných údajov zmluvne preniesť na poskytovateľov služieb - aj s prípadným trestným postihom pri porušení zákona ?

Dala by sa do usmernenia doplniť povinnosť viditeľne označiť všetky zariadenia, ktoré z preukazu čítajú nielen UID, ale aj osobné údaje študentov ?

Dalo by sa zakázať zbieranie osobných údajov v bežných turniketoch a iných bezobslužných zariadeniach ?

Orenič 20.01.2014:  Podľa mňa to všetko rieši Zákon o ochrane osobných údajov a do usmernenia to isto neprejde.

Sýkora 25.02.2014:  Niečo sa v tomto smere urobilo.

Centrálna technická podpora pre nové preukazy18.12.2013

Niektoré centrálne povinnosti pri práci s preukazmi nové usmernenie zveruje do pôsobnosti MŠ:

  • generovanie spoločných čítacích kľúčov K1 a K2 k preukazom a ich distribúcia na VŠ a poskytovateľom služieb
  • registrácia a publikovanie verejných kľúčov VŠ na overovanie elektronických podpisov

Bude sa na tom nejako podieľať aj EUNIS ?

Orenič 20.01.2014:  K1 a K2 by som nechal na MŠ. Čo sa týka verejných kľúčov podpisov VŠ, opäť vidím priestor pre portál VS – sekcia preukazu študentov a zamestnancov.

CKM SYTS 31.01.2014:  Urcite by to malo byt v posobnosti oficialnej autority – mozno by to prac. skupina EUNIS pre preukaz studenta mohla zastresovat/vykonavat pre MS.

Sýkora 25.02.2014:  Navrhol som technické služby k preukazom zveriť do kompetencie združenia EUNIS (po vzájomnej dohode s MŠ), ale teraz sa to neriešilo. Žiadosti na registráciu nových AID v Mifare pre MŠ už pripraví EMtest.

Odporúčané technické vybavenie na prácu s novými preukazmi18.12.2013

Kto môže pripraviť zoznam technických zariadení, ktoré sú vhodné a budú odporúčané na prácu s novými preukazmi - ide najmä o typy čítačiek a modulov SAM ?

Podľa odporúčania spoločnosti EMtest nové čítačky by mali zvládnuť aj prácu s ďalšou generáciou bezkontaktných kariet DESFire EV2.

Orenič 20.01.2014:  Toto možno ponechať na dodávateľov riešení pre konkrétne VŠ.

CKM SYTS 31.01.2014:  Aka je pravdepodobnost, ze v najblizsich rokoch sa bude nasadzovat EV2 ?

Sýkora 25.02.2014:  V texte alebo v prílohe usmernenia by mali byť uvedené štandardy alebo aj zoznam konkrétnych zariadení, a ktorými to celé bude fungovať. Zatiaľ sa tak nestalo, ale aspoň typ modulu SAM je tam uvedený explicitne.

Podpora pre mobilné zariadenia - NFC a NDEF28.12.2013

Usmernenie by mohlo podporiť spoluprácu preukazov s novými technológiami v mobilných zariadeniach, a to najmä v inteligentných telefónoch:

  • NFC - Near Field Communication - nfc-forum.org
    Štandard ISO/IEC 18092, ktorý definuje bezdrôtovú komunikáciu na malé vzdialenosti (do 1 cm) medzi mobilnými zariadeniami navzájom a s RFID "tagmi" .
  • NDEF - NFC Data Exchange Format
    Formát správ prenášaných medzi NFC zariadeniami a tagmi.

Čipové karty Mifare DESFire a Classic sú zahrnuté do oboch štandardov ako nosič údajov (tag). Používajú sa na uchovanie a elektronickú výmenu menšieho množstva jednoduchých informácií položkového typu. Často obsahujú "elektronickú vizitku" držiteľa karty, ktorú si každý môže sám zostaviť a udržiavať pomocou bežne dostupných mobilných aplikácií (napr. "NFC interactor"). Tieto údaje sú elektronicky čitateľné bez obmedzení (public) po priložení preukazu k čítačke alebo k mobilnému zariadeniu poskytovateľa služieb alebo iného dôveryhodného partnera držiteľa karty.

Usmernenie by mohlo definovať osobitnú oblasť v pamäti preukazu na uloženie údajov NDEF. V terminológii Mifare by išlo o samostatnú aplikáciu s predpísaným číselným označením v adresári MAD. V preukaze typu Classic by zabrala napr. sektory 0x26 a 0x27 (2x 240 bajtov) a v preukaze typu DESFire by pre ňu bol určený osobitný súbor. Vydavateľ preukazu by takúto oblasť v pamäti preukazu vyhradil a inicializoval počas úvodného formátovania preukazu.

Môžeme zvážiť aj to, či pri vydaní preukazu do tejto oblasti vložíme niekoľko základných údajov o držiteľovi preukazu - napr. jeho meno, kontaktné údaje a pod. Vydavateľ preukazu by neniesol žiadnu zodpovednosť za tieto údaje, lebo držiteľ preukazu si ich môže neskôr sám upraviť.

Oblasť NDEF na preukaze a v nej uložené údaje držiteľa preukazu nesúvisia priamo so základnou funkcionalitou preukazu študenta. Ale mohli by byť jej vítaným obohatením v rámci multifunkčného využitia preukazu. Verejne dostupné údaje o držiteľovi preukazu v oblasti NDEF by mohli byť plne postačujúce pre mnohých poskytovateľov služieb študentom, vďaka čomu by sa mohlo podstatne obmedziť šírenie tajných kľúčov K1 a K2 k dôvernejším údajom v oficiálnych záznamoch o študentovi.

Ak by sme išli ešte ďalej, záznam č. 1 o študentovi by sme mohli vyhlásiť za verejne dostupné potvrdenie o návšteve školy a spolu s elektronickým podpisom vydavateľa preukazu by sme ho mohli presunúť do oblasti NDEF na preukaze. Dátum narodenia študenta by sme presunuli k ostatn7m osobným údajom v zázname č. 2 a ten by sme chránili dosiaľ opísaným spôsobom, t.j. mimo štruktúry NDEF. Tajný kľúč K2 k tomuto záznamu by však dostalo len minimum poskytovateľov služieb - možno len dopravcovia.

Nevýhodou posledného riešenia je to, že záznam č. 1 v preukaze študenta by bol súčasťou dátovej štruktúry NDEF a záznam č. 2 by zostal mimo nej. Z technického hľadiska by bolo jednoduchšie do oblasti NDEF umiestniť aj záznam č. 2 v kryptovanej forme, len by sme sa museli vyrovnať so skutočnosťou, že tu by bol trochu viac "na očiach".

Aj vám sa zdá, že toto celé je trochu provokatívna úvaha v súčasnom štádiu schvaľovania usmernenia ? Áno, ale prečo to neskúsiť, ak je to užitočné ... :-)

Orenič 20.01.2014:  Je otázne, či je vhodné orientovať sa na jednu technológiu, ktoré ešte aj Apple ignoruje. Verejná vizitka je reálne nepoužiteľná bez epodpisu školy. A aj keby tam bol, zase je to to isté ako publik K1 kľúč - neviem kto ma prečíta...

Sýkora 07.02.2014:  Navrhnem odporúčanie pre VŠ, aby na karte rezervovali a naformátovali oblasť pre NDEF. Študent si ju môže naplniť sám pomocou vhodného mobilného telefónu, alebo mu ju môže naplniť priamo "univerzitný terminál", keď ho o to študent požiada príslušným klikom na obrazovke.

Sýkora 25.02.2014:  Odporúča sa v čipe vyhradiť priestor pre aplikáciu NDEF.