VO nebolo, lebo sa išlo cez špajzovú zmluvu https://www.crz.gov.sk/index.php?ID=3005679&l=sk . Tam mal Atos dodať “SW pre správu užívateľských identít v organizáci”, požadovaný bol 1ks IBM Security Identity Manager and Role Management. Namiesto toho sa objednal de-facto vývoj na zákazku úplne iných vecí (ktorý samozrejme nerobí Atos). Dodávka vraj do 30 dní od účinnosti zmluvy - čiže už to bolo vopred dohodnuté/vyvíjané.
Zial prislovie co ta nezabije, ta posilni plati aj pre Rašiho a Pelleho … ked im nezlomila krk (ale ani len ranku nenechala) kauza Edunet a dalsie medializovane - tak sa prave zacalo nove eldorado …
V tých dokumentoch, čo spomína Lubor je opísaný aj proces vzdialenej obnovy a vydania certifikátu, a je tam teda vyriešená aj záhada storočia, ako sa bez toho aby som sa fyzicky dostavil a nechal sa identifikovať na JP/RA (jednotné pracovisko / registračná autorita), dá vzdialene získať nový kvalifikovaný certifikát, a pritom nemám ani čím podpísať že si preberám nový certifikát (lebo starý je zneplatnený).
V “procese vydania resp. obnovy certifikátu” sa na začiatku vytvára bezpečný komunikačný EAC kanál medzi eID kartou a serverom RA, a to vďaka zadaniu BOK (bezpečnostný osobný kód). Identifikácia zostala aj po revokovaní podpisovacích certifikátov funkčná, lebo nepoužíva certifikáty ale iba identifikačný kľúč. Zadanie BOK-u je teda ekvivalent toho, ako keď pracovník JP identifikuje fyzicky prítomnú osobu podľa fotky.
Následne sa vygenerujú kľúčové páry a nasleduje zobrazenie PKCS#10 žiadosti pre kvalifikovaný certifikát a jej podpísanie pomocou zadania QES PIN (píše sa v dokumente).
Ako môžem niečo podpísať pomocu zadania QES PIN, keď certifikát (ktorého kľúč tento PIN chráni) je neplatný? Tak že sa podpisuje technická PKCS#10 žiadosť, a to už pomocou nového (bezpečnejšieho 3Kb) privátneho kľúča. V tomto čase ešte neexistuje nový certifikát ani sa nevytvára normálny KEP (kvalifikovaný elektronický podpis) ale už sa použije nový privátny kľúč, ktorým sa podpíše technická žiadosť o vydanie nového certifikátu.
RA tomuto technickému podpisu verí, lebo s ňou komunikuje overená identita cez EAC kanál a použil sa (nejaký) QES PIN. Čiže osoba ktorá komunikuje s RA zjavne v minulosti mala záujem vydať podpisovací certifikát, a tým je zabezpečené aby sa nestalo, že “paranoik” ktorý mal eID len s BOK bez QES PIN, zrazu týmto vzdialeným spôsobom vie získať aj podpisovací certifikát. RA teda nechá vydať certifikát a nechá osobu podpísať protokol o prevzatí a pošle o tom protokol do eDesku. Posledné dva kroky sú ale poloirelevatné lebo už sa udejú za existencie nového platného certifikátu.
Správne som pochopil akým zázrakom vzdialená obnova revokovaných certifikátov zafunguje?
A čo keď ten “paranoik”, ktorý má len BOK (a nikdy nechcel QES PIN a vyrábať KEPy, chcel len využiť eID na identifikáciu a safe operácie v eDesku) nejakým spôsobom príde o eID + BOK alebo útočník inak prelomí bezpečnosť EAC kanálu? Ako je potom zabepzečené že útočník nezašle požiadavku cez nadvizaný EAC kanál o podpisový certifikát a s tým že podpíše PKCS#10 so svojím vymysleným privátnym kľúčom? Útočník by tak získal privátny podpisovací kľúč paranoika, ktorý mal eID len na účely identifikácie/autentifikácie a žiaden QES PIN nikdy nezadával (počítal s tým že aj keď niekto zlomí bezpečnosť “BOKU” / identifikácie, tak prinajhoršom mu dačo niekto prečíta z eDesku, ale takto vie útočník vzdialene vytvoriť certifikát, ktorým vytvorí notársky overený podpis že paranoik sa vzdáva všetkého majetku). Ak útočník vie prelomiť bezpečnostné mechanizmy pre autorizáciu na základe toho že prelomil bezpečnostné mechanizmy pre autentifikáciu, tak načo ich máme oddelené?
Pochopil si to imho správne.
Akurát že QES PIN (KEP PIN) v tomto celom hrá nepodstatnú rolu, “iba” odomyká sa ním prístup k privátnemu kľúču. Z dokumentu nie je jasné, či sa pri obnove certifikátu vytvára aj nový KEP PIN (ale z logiky veci by sa samozrejme mal).
Riešenie Tebou načrtnutých útokov:
používateľ príde o eID+BOK -> nahlásiť stratu OP, asap, následne sa nebude dať použiť ani na vydanie certifikátov - MV by samozrejme malo vo chvíli zablokovania eID automaticky nechať revokovať všetky na neho vydané certifikáty (neviem či to robí / bude robiť)
prelomenie bezpečnosti EAC - toto bude vždy krvavé, na EAC je postavených veľa vecí, dôležitejších než slovenské eID, napr. validácia cestovných dokladov (pasov) na celom svete
ak sa o tom bude vedieť vopred -> samozrejme stihnúť upgrade, v havarijnom prípade zablokovať všetky na ňom založené veci - najmä sa vypne autentifikácia cez eID
ak sa o tom nebude vedieť vopred -> možno už to je aj teraz hacknuté, kto vie? pomôže staniolový klobúk?
ani ak niekto nechce KEP, nedokáže zabrániť jeho “vyrobeniu” cez internet - áno, z dokumentu to vyzerá, že to takto bude možné, považujem to za reálny problém, imho riešenie je prvé vydanie certifikátu vždy vyžadovať osobne
Škoda, že pochopili hneď, že dodať 3 distribúcie neznamená dodať 3 systémy distribúcii a prijali tútu ponuku, ktorá bola chybne specifikovaná. <Naivety>Možno by sa troch druhov balíčkovacích systémov zľakli a dodali by to radsej open source. </endOfNaivety>
Problém má byť v tom, že pri personalizácii neboli (privátne) kľúče generované v čipe, ale niekde externe a do čipu boli iba nahraté. To je samozrejme kritická chyba. Pravdepodobne v Estónsku Gemalto nielen dodáva karty, ale robí aj personalizáciu.
V SK je to tak, že celá personalizácia je vykonávaná Ministerstvom vnútra, t.j. aj generovanie kľúčov. Navyše OS karty je certifikovaný, čo pokiaľ viem zahŕňa aj overenie nemožnosti exportovať privátny kľúč.
