Zaujala mne pasáž o zaměstnancích a jejich nechuti používat jako zaměstnanci pro plnění svých služebních povinností osobní občanský průkaz.
Je ta nechuť racionální? Existuje nějaký rozumný důvod proč osobní občanský průkaz nepoužít pro plnění svých služebních povinností?
Ptám se proto, protože na konferenci ISSS 1.4.2019 vystoupil Ing. Petr Pavlinec z Krajského úřadu Kraje Vysočina.
https://www.isss.cz/do/watch?id=62
a zmínil tam, že v Estonsku je naprosto přirozené, že např. lékaři používají své občanky v nemocničních aplikacích apod.
Proč čeští úředníci, lékaři atd. touží po dalších "profi" kartách.
(audio framgment podstatné části videa https://soundcloud.com/petr-hlav-ek-516038486/obcanka-jako-identifikacni-prostredek/s-xFvPuuzMczG )
Omlouvám se, ale Vaše argumentace je nesrozumitelná.
Čip, který využívá česká eOP je na Vámi uvedeném seznamu na straně 23: "Produit Gemalto "IAS Classic V4.4 with MOC Server 1.1 on MultiApp V4" embarqué sur le microcontrôleur M7892 G12 Infineon Technologies AG", potvrzeno laboratoří Agence Nationale de Sécurité des Systèmes d'Information (ANSSI).
Tvrdíte tedy, že ve Francii certifikovaný čip použitý na české eOP, uvedený na seznamu, na který se odvoláváte, vlastně certifikovaný není? Zatímco německý čip uvedený na stejném seznamu, který používá česká I.CA, certifikovaný je?
Ještě upřesním, že právně závazné jsou akreditace vydané jednotlivými členskými státy. Odkazovaný seznam je pouze nezávazný souhrn, tak, aby akreditace jednotlivých států bylo možné najít na jednom místě. Ale předpokládejme, že EU ten seznam vytváří správně a že tedy platí rovnítko mezi akreditacemi vydanými jednotlivými členskými státy EU a tímto seznamem.
Pokračujte dále. To splnění norem musí samozřejmě někdo kompetentní posoudit. Přičemž to „někdo kompetentní“ je opět definováno eIDASem. No a abyste ty výsledky posouzení nemusel shánět po všech čertech, má EU jedno místo, kde jsou vyjmenované všechny prostředky a služby, které prošly posouzením a splňují požadavky eIDAS. Přičemž právní účinky eIDASu nezávisí na tom, zda prostředek nebo služba normy fakticky splňuje, ale na tom, zda jsou uvedeny na tomto seznamu. Nebo-li pokud je vyžadován např. kvalifikovaný prostředek, nezáleží na tom, že nějaké zařízení příslušné normy splňuje. Aby byla splněna podmínka použití kvalifikovaného prostředku, musí tento prostředek být uvedený na výše uvedeném seznamu.
No a konkrétně čipová karta STARCOS 3.5 ID ECC C1R získala akreditaci v Německu (v odkazovaném seznamu kvalifikovaných prostředků z 27. 2. 2020 ji najdete na straně 33). Českou eObčanku na tomto seznamu nenajdete.
Myslím, že si stále nerozumíme. Pokud jde o eIDAS, tak k němu jsou přijaty prováděcí akty, MV má rozcestník zde https://www.mvcr.cz/clanek/prijate-provadeci-akty-k-narizeni-eidas.aspx Pro kontext QSCD platí "PROVÁDĚCÍ ROZHODNUTÍ KOMISE (EU) 2016/650 ze dne 25. dubna 2016, kterým se stanoví normy pro posuzování bezpečnosti kvalifikovaných prostředků pro vytváření elektronických podpisů a pečetí podle čl. 30 odst. 3 a čl. 39 odst. 2 nařízení Evropského parlamentu a Rady (EU) č. 910/2014 o elektronické identifikaci a službách vytvářejících důvěru pro elektronické transakce na vnitřním trhu". Tam je přesně dané, podle jakých norem se postupuje a jaký rozsah je potřebný a mimochodem uvádí i toto "Podle 56. bodu odůvodnění nařízení (EU) č. 910/2014 je rozsah certifikace podle článků 30 a 39 uvedeného nařízení omezen na ochranu dat pro vytváření podpisů a z rozsahu certifikace jsou vyloučeny aplikace pro vytváření podpisů."
Dále pak, a skutečně doporučuji všem, kteří chtějí vést odbornou diskusi, jsou k certifikovaným produktům vydány i Security Terget (ST) dokumenty - seznamte se s nimi. Pro IAS Classic znám velmi podrobně, pro STARCOS jsem zběžně prolétl. Rozhodně nemohu potvrdit, že bych jako součást TOE viděl software (pokud tím software myslíte to co běží na PC?) Jestli jsem něco přehlédl, pak prosím o odkaz na ST, který pokrývá to o čem zde píšete, včetně informace, co nepokrývá eOP.
A pokud se podíváte na ST pro IAS Classic, tak zjistíte, že jsou v něm samozřejmě pokryty i bezpečnostní funkce pro bezpečnou komunikaci mezi čipem a terminálem/aplikací.
Další věci, které padly výše, nemá žádný smysl komentovat - zakládají se jen na nepodložených domněnkách.
Ad 2) V rámci eIDASu jsou dva možné výklady – buď ten, že certifikaci musí získat finální zařízení (např. čipová karta včetně softwaru) – a takhle to má I. CA. Druhá varianta, kterou zastává české Ministerstvo vnitra a je použitá u českých eObčanek, je – když se zařízení poskládá z certifikovaných komponent, jako celek pak splňuje potřebné požadavky a není nutné ho certifikovat jako celek. Z hlediska bezpečnosti je samozřejmě ten přístup Ministerstva vnitra špatně, protože všichni víme, že když špatně poskládáte bezpečné komponenty, výsledné řešení nebude bezpečné. Dokonce nejspíš nejvíc bezpečnostních problémů padá na vrub toho špatného poskládání, ne samotných bezpečnostních komponent.
Tedy rozdíl je v tom, že česká občanka pouze uvnitř používá certifikovanou technologii, zatímco ta karta Starcos 3.5 IF GCC C1R byla certifikována jako celek, tj. nejen samotný bezpečnostní čip, ale i komunikace s ním.
Dobrý den, pane Peterko, mám jedno upřesnění a jeden dotaz:
1. Upřesnění k odsavci "Jakmile uživatel vybere příslušný certifikát a zadá správný PIN, jeho browser (s využitím nainstalované softwarové komponenty I.CA PKI Service) podepíše výzvu od své protistrany (tj. od prostředníka, tj. NIA) odpovídajícím soukromým klíčem (přímo na čipu karty Starcos). Podepsanou výzvu, spolu s identitním certifikátem, pak browser vrátí prostředníkovi (NIA)." Aktuálně NIA a IdP komunikují přes SAML protokol a nepředpokládám, že SAMLResponse podepisuje browser (a ani čip na kartě). To by na všech čipech musel být klíč IdP a to jistě nikdo nechce.
2. Dotaz k odstavci "S tím, že karta Starcos (konkrétně verze 3.5 IF GCC C1R) jako taková prošla požadovaným testováním a najdete ji na unijním seznamu QSCD prostředků. Naproti tomu naši novou eOP na tomto seznamu nenajdete – je považována za kvalifikovaný prostředek (pro vytváření elektronických podpisů) díky vyjádření našeho Ministerstva vnitra, které se opírá o skutečnost, že v naší nové eOP je použita certifikovaná technologie. Nikoli že testováním prošla celá občanka jako taková." Můžete prosím rozvést? A ideálně uvést konkrétní rozdíly v testování 3.5 IF GCC C1R (resp předpokládám, že mělo být 3.5 ID GCC C1R nebo 3.5 ID ECC C1R?) a IAS Classic V4.4? Osobně to vidím tak, že jak česká občanka, tak "Starcos I.CA" využívají certifikovanou technologii, na které staví produkt. Mimochodem, ke každé certifikaci je publikován i Security Target dokument - doporučuji prostudovat, jde o velmi zajímavé čtení.
Moc děkuji za Vaši reakci.
Dostalo se ke mě vysvětlení od člověka z centra dění, které zde volně přepisuji a doplňuji.
NIA publikuje svoji službu pro ztotožnění, která je navázána na službu E05 - robCtiPodleUdaju. Identity Provider (IdP) má podmínky pro ztotožnění jako AISy. Pokud se ztotožnění podaří (FO je v ROB nalezena), tak si NIA vytvoří profil a uloží do něj mimo jiné AIFO a pro IdP vydá jedinečný BSI (Bezvýznamový Směrový Identifikátor). Vydávaný BSI se pro stejnou FO a různé IdP liší.
Elektronická identita je v ROB a je jednoznačně určena AIFO, pro které je v NIA zaveden profil, který vznikne při prvním úspěšném ztotožnění vůči ROB. Na profil jsou navázány jednotlivé identifikační prostředky.
Z AIFO se v NIA stává obdoba ZIFO, jsou na něj navázány BSI pro SeP i IdP. Každý IdP má pro stejnou FO přidělen jiný BSI.
Obdoba se děje (zjednodušeně, tam ještě přichází ke slovu tzv. konfigurace) u SeP, každý SeP má pro stejnou FO jiný BSI, ale už bez ohledu na IdP (SeP dostane pro FO pokaždé stejný BSI bez ohledu na to, kterým IdP se FO autentizuje).
Podle informací z I.CA je při prvotním ztotožnění odesílán do NIA pouze typ a číslo dokladu. NIA vyhledá v ROBu sadu údajů, které odpovídají zaslanému dokladu a vrátí je I.CA. Vráceny jsou: jméno, příjmení, datum narození a RUIAN kód trvalého bydliště (nebo chyba, pokud doklad neexistuje).
I.CA následně porovná data, která získala od žadatele, s daty vrácenými z NIA. Pokud data souhlasí, ztotožnění proběhlo úspěšně.
Takže I.CA nemá přímý přístup do ROBu. Přístup do ROBu má NIA. Žádné jiné údaje, kromě typu a čísla dokladu, neopouští systémy I.CA.
Mě tam pořád není jasné, jak při vydání kvalifikovaný prostředku kvalifikovaný správce (zde I.CA) jednoznačně určí FO, které byl prostředek vydán, aniž by si to ověřil v ROB, kam zřejmě nemá přístup (pokud se dobře dívám, tak zákon 250/2017 Sb. umožňuje přístup pouze SZR).
Při přihlášení je už proces jasný, ale první ztotožnění s ROB, aby se podle § 21 1b) mohlo do národního bodu (NIA) uložit AIFO pro agendu autentizace by tam mělo nějak proběhnout. Je to pouze pomocí údajů § 22 1) ac)? V bodu f) je způsob ověření totožnosti, ale číslo průkazu totožnosti, přes který by šla FO v ROB jednoznačně vyhledat, povinný není a ukládání jiných identifikací (např. RČ) tam povoleno není, jsou tam pouze způsoby.
Pokud se při vkládání ze strany I.CA pošle do národního bodu „osobě Pepa Novák, trvalý pobyt Městský úřad Bohumín, narozen 20.4.1980 byl vydán kvalifikovaný prostředek XY“, tak ho následně NIA zkusí vyhledat v ROB (NIA tam přístup má) a pokud se najde právě jedna identita, spoléhá se na to, že je to on?
V podstatě jak se řeší „zesouladění“ zmíněné v článku o BankID, když kvalifikovaní poskytovatelé zřejmě do základních registrů nemohou (nebo jsem to nedohledal).
Ještě jsem se díval a v RPP v kategoriích KU1-KU3 není po I.CA ani stopa, takže by neměla mít přístup do ZR nebo AIS.
Například soukromé pojišťovny jako SPUÚ vedeny jsou (KU4), protože mají ze zákona přístup do ROB. Jsou v tomhle "silnější" jak kvalifikovaný poskytovatel?