Hlavní navigace

Kauza DigiNotar, aneb: když certifikační autorita ztratí důvěru

20. 9. 2011
Doba čtení: 17 minut

Sdílet

Nizozemská certifikační autorita DigiNotar byla kompromitována: útočníkovi, zřejmě z Iránu, se podařilo nechat si vystavit podvodné SSL certifikáty a ty následně i využít. Autorita, jejíž kvalifikované služby využíval i nizozemský egovernment, přišla nejen o svou akreditaci, ale i o celkovou důvěru.

Elektronický podpis, který dnes používáme, vychází z „centralizovaného“  principu vyjadřování důvěry, a ze „stromovitého“ způsobu šíření této důvěry: abychom nemuseli vyjadřovat svou důvěru (případně nedůvěru) konkrétním certifikátům, vyjadřujeme ji jejich vydavatelům, neboli tzv. certifikačním autoritám. A jelikož i těch by bylo stále moc, jsou tyto autority uspořádány do stromů, jejichž kořeny odpovídají tzv. kořenovým certifikačním autoritám. Nám pak stačí vyjádřit důvěru konkrétní kořenové autoritě – a fakticky tím vyjadřujeme svou důvěru i všem jí podřízeným (dceřiným, zprostředkujícím atd.) autoritám, a současně i všem certifikátům, které tyto autority vydaly.

Celý tento systém, vycházející z tzv. infrastruktury veřejného klíče (PKI, Public Key Infrastructure), je na jedné straně docela praktický: stačí nám jeden úkon (vyjádření důvěry kořeni, resp. kořenové autoritě), a naše důvěra se tím automaticky přenáší na celý podstrom. Jenže má i příslovečnou druhou stranu mince: pokud se někomu podaří zkompromitovat právě onen kořen (kořenovou autoritu), případně některý z nižších uzlů (podřízenou certifikační autoritu), rázem je „nakažen“ celý strom, resp. podstrom.

„Nakažen“ v tom smyslu, že když útočník přesvědčí uživatele, aby důvěřoval jím kompromitované (pozměněné, zfalšované) autoritě, budou uživatelem používané programy automaticky důvěřovat i všem certifikátům, které tato kompromitovaná autorita vydala. A ta je pochopitelně vydala tak, aby se to hodilo útočníkovi.

Příklad

Představme si to na následujícím modelu (hypotetické) autority A, která má jednu kořenovou autoritu A:1, jednu podřízenou (dceřinou, zprostředkující) autoritu A:1.1 vydávající kvalifikované certifikáty, a druhou podřízenou autoritu A1:2, vydávající komerční certifikáty. Což jsou například serverové SSL certifikáty, osobní šifrovací certifikáty apod. Mimochodem, stejným způsobem jsou u nás organizované akreditované autority PostSignum a eIdentity (viz přehled jejich certifikátů).

Teď si představme, že důvěřujeme certifikátu kořenové autority A:1. To je konkrétně realizováno tak, že tento certifikát je uložen v úložišti důvěryhodných certifikátů toho programu, který právě používáme (což nemusí být vždy jen webový browser).

Důležité je, že příslušný certifikát jsme tam vůbec nemuseli umístit sami, ale může tam být „sám od sebe“, od okamžiku kdy jsme si příslušný program (browser) nainstalovali. Může totiž být součástí jeho „standardní výbavy“, kterou pro něj vybral již jeho výrobce – a tím za nás (uživatele) rozhodl, čemu budeme důvěřovat a čemu ne.

Ať už se ale příslušný certifikát kořenové autority A:1 dostal do úložiště důvěryhodných certifikátů tak či onak, podstatný je efekt, který to způsobuje: program, který úložiště používá, bude důvěřovat všem certifikátům, vydaným autoritou A:1, i certifikátům vydaným jejími dceřinými autoritami A:1.1 a A:1.2. Tedy například i SSL  certifikátu, který autorita A1.2 vydala serveru X. Pokud se tímto certifikátem úspěšně prokáže nějaký konkrétní server, bude uživatelův program (browser) považovat tento SSL certifikát za důvěryhodný a věřit tomu, co je v něm napsáno. Tedy že dotyčný server je skutečně serverem X. A uživatele na tento server normálně „pustí“.

Až sem je vše v pořádku: za důležitého předpokladu, že certifikát kořenové autority A:1 je pravý, a nikoli podvržený. Pokud by totiž byl podvržený, rázem by všechno mohlo být jinak: ten, kdo „vládne“ podvrženým certifikátem autority A:1, případně A:1.2, si může s jeho pomocí sám vydat podvodný SSL certifikát. Ten pak umožní serveru Y, aby se vydával za server X.

Možný scénář zneužití

Nyní si představme následující scénář – a zatím jej berme jen jako hypotetický: někdo napadne autoritu A:1.2 a podaří se mu vystavit si od ní podvodné  SSL certifikáty. Takové, že serveru Y umožňují vydávat se za server X.

Nebo, aby to bylo konkrétnější: útočník si nechá vystavit podvodný SSL certifikát pro doménové jméno *.google.com (představující ono X). Odpovídající soukromý klíč ale svěří svému serveru (představuje server Y). Ten se díky tomu bude moci vydávat například za server mail.google.com, kde běží známá a oblíbená služba Gmail. Ale vůči komu? Kdo „půjde“ na server Y, když ve skutečnosti chce pracovat se serverem X?

K tomu je nutná ještě další část scénáře. Musí totiž dojít k podvodnému přesměrování: když uživatel zadá například mail.google.com, nebo www.gmail.com apod., nesmí se dostat tam, kam by se správně měl dostat (na server X), ale musí být přesměrován na server Y. 

Teprve v tomto případě se server Y dostane k tomu, aby se prokázal oním podvodným certifikátem, a vydával se (například) za server mail.google.com. Uživatel to ale neví, protože jeho browseru se podvodný server (Y) jeví jako pravý (jako server X).

Zbytek si asi už jistě domyslíte sami: onen server Y, jako správný „man in the middle“, ochotně přepošle veškerou konverzaci skutečnému uzlu X. Přitom si ale odposlechne to, co ho zajímá – například přihlašovací údaje k uživatelským účtům, poštovním schránkám apod.

Kauza COMODO

Vraťme se nyní od hypotetických scénářů k realitě. V březnu letošního roku došlo k útoku na jednu z registračních autorit certifikační autority COMODO. Útočníkovi, který využíval IP adresu přidělenou v Iránu (viz podrobný popis), se podařilo nechat si vystavit celkem 9 SSL certifikátů, a to podepsaných přímo kořenovou autoritou (nikoli příslušnou dceřinou autoritou). 

Autorita COMODO ale tento útok odhalila prakticky okamžitě a příslušné certifikáty ihned revokovala. Tedy předčasně zneplatnila, a informaci o tom začala šířit jak skrze tzv. CRL seznamy, tak i skrze protokol OCSP.

Jenže to v takovýchto případech nestačí. Jednak proto, že ne vždy a pro každého jsou CRL seznamy či odpovědi OCSP serverů (používané pro získávání revokačních informací) dostupné. Ne vždy také musí používané programy (hlavně browsery) s informacemi o revokaci správně pracovat. Ale hlavně: když nějaká autorita vydá nějaké podvodné certifikáty, lze následně věřit informacím o revokaci (resp. ne-revokaci), které vydává (a podepisuje) ta samá autorita? Nemohou být tyto informace také podvržené?

Proto se takovéto případy řeší ještě i jinak: výrobci těch programů, které používají vlastní úložiště důvěryhodných certifikátů, co nejrychleji vydávají jejich opravy (formou různých záplat, patchů atd.), které vyjádří nedůvěru konkrétním kompromitovaným certifikátům přímo v příslušném úložišti.

Jako příklad si ukažme systémové úložiště v MS Windows: to má pro takovéto situace speciální složku „Nedůvěryhodní vydavatelé“, a vyjádření nedůvěry se provádí umístěním (resp. přesunutím) kompromitovaného certifikátu do této složky.

Ještě před kauzou COMODO zde byly pouze dva certifikáty, které v roce 2001 vydala autorita VeriSign někomu, kdo se sice vydával za zástupce společnosti Microsoft, ale ve skutečnosti s Microsoftem neměl nic společného. Viz následující obrázek.

V důsledku kauzy COMODO se do této složky dostalo dalších 9 certifikátů, protože právě tolik jich bylo podvodně vydáno, viz následující obrázek.

I ze jmen serverů, pro které byly tyto podvodné certifikáty vystaveny, lze snadno usuzovat, jaké využití pro ně útočník asi měl:

  • mail.google.com
  • www.google.com
  • login.yahoo.com
  • login.skype.com
  • addons.mozilla.org
  • login.live.com

Důležité ale je, že tento útok se ještě nepodařil. I díky rychlé reakci autority COMODO (která podvodné certifikáty ihned revokovala)  se tyto certifikáty – až na opravdu nevýznamné výjimky – nedostaly „do oběhu“.

Kauza DigiNotar

Jinak tomu ale bylo v případě nizozemské autority DigiNotar, která je akreditovanou certifikační autoritou (podle našich měřítek), a vydává jak kvalifikované certifikáty, tak i certifikáty komerční, včetně SSL certifikátů (i SSL certifikátů s tzv. rozšířenou validací, EV, Extended Validation). No a právě její „SSL větev“ měla být napadena.

Dnes dostupné zprávy hovoří o tom, že útočníkovi (který opět využíval IP adresu přidělenou v Iránu) se již v červenci t.r. podařilo nechat si vystavit velké množství (více než pět stovek!) podvodných SSL certifikátů na nejrůznější jména. Reakce napadené autority ale nebyla zdaleka tak rychlá a důsledná, jako v případě COMODO: DigiNotar revokoval podvodně vydané certifikáty až s určitým zpožděním.

Na jeden z nich dokonce nějak „pozapomněl“, resp. ani nezaregistroval, že byl vydán. Shodou okolností či náhod šlo právě o SSL certifikát, vystavený na *.google.com, a to již 10. července 2011.  Na jeho existenci se přišlo až 29. srpna 2011, a revokován byl téhož dne v 19:09. Mezitím byl ale náležitě „využit“.

Podle společnosti Trend Micro, která se zabývá bezpečností a vyhodnocuje hrozby v rámci celosvětového Internetu, byl právě tento certifikát využit pro masivní útok vůči uživatelům asi 40 internetových providerů (a univerzit) v Iránu. Dokazuje to zcela mimořádným vzrůstem požadavků na revokační informace od CA DigiNotar (v doméně validation.di­ginotar.nl), které přicházely v době od 4. srpna do konce srpna právě z Iránu.

Tuto skutečnost potvrzují i údaje, zveřejněné v rámci vyšetřování celého incidentu přímo u autority DigiNotar (předběžná zpráva), které vycházelo z logů OCSP serveru této autority. Odkud pocházely požadavky na tento server, týkající se podvodného certifikátu na *.google.com, a jak byly rozloženy v čase (v průběhu měsíce srpna), asi nejlépe ukazuje toto video: více než 99 % jich přicházelo právě z Iránu.

Konkrétní způsob zneužití podvodného certifikátu byl nejspíše takový, jaký jsme si naznačili výše: když se internetoví uživatelé v Iránu snažili dostat na některý server Googlu (coby server X), například na svůj účet u Gmailu, byli ve skutečnosti přesměrováni na podvodný server Y, plnící roli „man-in-the-middle“.

Samotné přesměrování na server Y mohlo být realizováno třeba přes upravené DNS (bez DNSSEC), či jakkoli jinak. Podstatné je, že server Y se uživatelům prokazoval oním podvodným certifikátem, vystaveným na *.google.com – a díky tomu jejich browsery uvěřily, že jde o pravý server Googlu. Tento závěr nezvrátil ani řádně provedený dotaz na nizozemský OCSP server autority DigiNotar: ten až do 29. srpna odpovídal v tom smyslu, že certifikát nebyl revokován (předčasně zneplatněn). Revokován byl až po svém „objevení“ 29. srpna (zatímco celý útok probíhal od 4. srpna).

Když vaši důvěru má v rukou někdo jiný

K tomu, aby se právě naznačený scénář mohl odehrát, musel být splněn ještě jeden velmi důležitý předpoklad: podvodný certifikát musel být vystaven některou z certifikačních autorit, které jsou používanými browsery implicitně považovány za důvěryhodné. Tedy takovou autoritou, jejíž certifikáty (nejlépe kořenové i podřízené) se již nachází v tom úložišti důvěryhodných certifikátů, se kterým daný browser pracuje. Protože pokud by tomu tak nebylo, podvodný certifikát by nebyl považován za důvěryhodný a browser by uživatele varoval před vstupem na server, který se takovýmto certifikátem prokazuje.

Útočníkovi tedy nestačilo napadnout jakoukoli certifikační autoritu. Musel proniknout do takové, která je považována za důvěryhodnou i výrobci browserů, resp. operačních systémů, a je zařazena mezi ty, jejichž kořenové certifikáty jsou do příslušných úložišť vkládány automaticky, bez zásahu uživatele. Často i bez jeho vědomí, a někdy dokonce i proti jeho vůli (když příslušné mechanismy není tak snadné vypnout).

Nizozemská certifikační autorita DigiNotar takovouto autoritou je. Dnes už vlastně: byla.

Byla například zařazena do programu MRCP (Microsoft Root Certificate Program), podle kterého společnost Microsoft automaticky „naplňuje“ systémové úložiště důvěryhodných certifikátů. Stejně tak byl ale DigiNotar členem obdobných programů výrobců ostatních browserů a dalších programů (Apple, Adobe, Mozilla, atd.), a jeho kořenové certifikáty (i certifikáty dceřiných autorit) byly automaticky zařazovány do příslušných úložišť jako důvěryhodné. Díky tomu byly automaticky považovány za důvěryhodné i všechny certifikáty, které DigiNotar vydal svým zákazníkům.

Dnes už tomu je jinak: výrobci softwaru přišli se záplatami, které „prohlásily“ certifikáty autority DigiNotar za nedůvěryhodné (a neplatné) přímo v příslušných úložištích. Někteří tak učinili rychleji, jiní si dali více na čas. Vesměs ale takto naložili přímo s kořenovými certifikáty CA DigiNotar – což ve svém důsledku učinilo nedůvěryhodnými i všechny certifikáty, vydané koncovým zákazníkům touto autoritou, resp. všemi jejími dceřinými autoritami.. Bez ohledu na to, zda šlo o podvodné certifikáty či nikoli.

Zde najdete konkrétnější popisy příslušných „oprav“ pro konkrétní programy, resp. platformy:

Konkrétní způsob vyjádření nedůvěry, resp. zneplatnění, se pro konkrétní programy a platformy liší, v závislosti na jejich fungování. Tak například v rámci MS Windows došlo k přesunu certifikátů DigiNotaru do již zmiňované složky „Nedůvěryhodní vydavatelé“, viz následující obrázek.

Jinde, jako například i Firefoxu, resp. Mozilly, musel být vydán nový bezpečnostní update celého programu.

Problém se ale zdá být s mobilními platformami, kde k „opravám“ zatím nedošlo. Například změny od Apple se týkají pouze jeho operačního systému MAC OS, a nikoli iOSu na iPhonech a iPadech. Zde (zatím) implicitní důvěra v certifikáty DigiNotaru přetrvává. Obdobně třeba pro Google a jeho Android. Vzhledem ke stále masovějšími nasazení tabletů s těmito operačními systémy to ale je (aspoň podle mého názoru) dost na pováženou.

Proč nestačila revokace?

Na první pohled může popisovaná reakce výrobců programů vypadat jako přehnaná, a to hned ve dvou směrech: proč bylo nutné zneplatnit (vyjádřit nedůvěru) certifikátům napadené autority přímo v příslušných úložištích, a tím zneplatnit i všechny zákaznické certifikáty, vydané v příslušné „větvi“? Nestačí selektivně revokovat pouze podvodné certifikáty?

Na tuto otázku jsme si vlastně již odpověděli, při popisu kauzy COMODO: mechanismy zjišťující revokaci (CRL či OCSP) nemusí být vždy dostupné, a nemusí být vždy implementovány (a používány) správně. Ale hlavně: lze se spoléhat na informace, které o revokaci poskytuje napadená (kompromitovaná) autorita?

Velmi důležitý je ale druhý aspekt „přehnané reakce“: podle prvních informací měla být napadena a kompromitována jen jedna „větev“ CA DigiNotar, a to ta její dceřiná autorita, která vydává SSL certifikáty. Bylo pak nutné zneplatnit (vyjádřit nedůvěru) přímo kořenovým certifikátům, a tím současně i ostatním větvím, resp. všem dceřiným autoritám? Včetně těch, které vydávají kvalifikované certifikáty, používané  pro právně závazné elektronické podpisy?

Zde výrobci softwaru nejspíše vycházeli i z toho, že s nimi autorita DigiNotar nespolupracovala tak, jak by odpovídalo situaci. Svou roli jistě sehrálo i to, že podvodného certifikátu na *.google.com si „všimla“ až skoro po měsíci. A tak v očích výrobců softwaru ztratila důvěru jako celek – a proto byly zneplatněny přímo její kořenové certifikáty.

Jenže to se zase nelíbilo v Nizozemsku, kde kvalifikované certifikáty od DigiNotaru používá tamní e-government pro fungování svých služeb, pro podepisování všech dokumentů a zpráv atd. Jakmile ale došlo ke zneplatnění všech kořenových certifikátů CA DigiNotar v nejpoužívanějších programech, důsledky pro celý e-government byly okamžité a fatální.  Protože všechny služby, které se identifikují certifikátem od DigiNotar, rázem začaly vypadat jako nedůvěryhodné. Ještě větší problém pak nastává s elektronickými dokumenty, jejichž podpisy (založené na kvalifikovaných certifikátech od CA DigiNotar) jsou nyní vyhodnocovány jako neplatné.

DigiNotar přišel i o akreditaci

Když například Mozilla zneplatnila v rámci svého úložiště všechny kořenové certifikáty CA DigiNotar (a to včetně těch, používaných pro tamní e-government), ozvaly se úřady z Nizozemí a požadovaly vyjmout ze zneplatnění ty kořenové certifikáty, které jsou využívány pro potřeby tamního e-governmentu. Tak, aby vyjádření nedůvěry (zneplatnění) nedopadalo na kvalifikované certifikáty klientů e-govenrmentu.

Vývojáři Mozilly se již chystali této žádosti vyhovět – když tu nizozemské úřady svůj požadavek odvolaly (podrobněji). V rámci vyšetřování celého napadení autority DigiNotar totiž došly k závěru, že jeho rozsah nejspíše bude větší, a může se týkat i kvalifikovaných služeb a certifikátů. Včetně těch, které se používají pro potřeby e-governmentu v Nizozemí.

V důsledku těchto zjištění úřady v Nizozemí samy přistoupily k ještě zásadnějším krokům: tamní úřad OPTA (odpovídající našemu ČTÚ), který má gesci v oblasti elektronického podpisu, s účinností ke 14. září odňal autoritě DigiNotar její dosavadní akreditaci. Ta se týkala poskytování kvalifikovaných služeb (vydávání kvalifikovaných certifikátů).

To už má konkrétní dopady i na dění v tuzemsku: u nás používané uznávané elektronické podpisy mohou být založeny nejenom na kvalifikovaných certifikátech od tuzemských akreditovaných autorit (které jsou tři: I.CA, PostSignum a eIdentity), ale i na kvalifikovaných certifikátech autorit z EU, které jsou vydány v rámci služeb na seznamu důvěryhodných certifikačních služeb (seznamů TSL, Trusted Security List).

Seznamy TSL

Ohledně seznamů TSL ale musíme být přesnější. Již jen proto, že autoritu DigiNotar stále najdeme i v nejnovější (nizozemské) verzi tohoto seznamu, vydané až po odnětí akreditace.

Není to totiž tak, že na seznamu TSL byly uváděny přímo celé autority – a že by z toho vyplývalo, že jsou akreditované. Seznam TSL není seznamem certifikačních autorit, ale seznamem jejich služeb: i DigiNotar nabízel více různých služeb, v rámci kterých vydával buďto kvalifikované, nebo komerční certifikáty atd. Na seznamu TSL ale má smysl hledat jen služby, které slouží k vydávání kvalifikovaných certifikátů.

Jenže takovéto služby autority DigiNotar jsou na seznamu TSL i nadále. Jak tomu tedy rozumět? Má DigiNotar pro tyto služby stále řádnou akreditaci?

Vysvětlení je takové, že seznam TSL je jakýmsi žurnálem (log-em) změn v akreditaci či dohledu: zaznamenává, kdy byla konkrétní službě udělena či odňata akreditace (či tzv. dohled). Proto jsou zde služby CA DigiNotar stále uvedeny – ale nyní již včetně záznamů, které říkají, že ke 14.9.2011 jim byla akreditace odňata. Najdeme zde ale i záznamy o tom, kdy jim byla akreditace udělena (v roce 2005).

Díky tomuto „odstupňování v čase“ je nadále možné korektně vyhodnocovat platnost elektronických podpisů, založených na certifikátech i od takových autorit, které k určitému datu ztratily akreditaci: pokud existuje dostatečně spolehlivý důkaz o tom, že podpis vznikl v době před odnětím akreditace (například ve formě časového razítka), měl by být podpis vyhodnocen jak platný (a uznávaný, resp. založený na kvalifikovaném certifikátu od akreditované autority).

Mimochodem, zneplatnění (odnětí důvěry) v rámci úložišť důvěryhodných certifikátů takto odstupňované v čase není, protože nijak neeviduje, k jakému datu k odnětí důvěry došlo. Takže pak jsou jako nedůvěryhodné vyhodnocovány i takové podpisy, které prokazatelně vznikly před kompromitací příslušné autority a ztrátě akreditace u její služby.

Možná je to celé ještě horší

K popisovanému útoku na autoru DigiNotar se na Internetu přihlásila osoba, která se vydává již za autora předchozího útoku na autoritu COMODO (a kvůli tomu používá přezdívku COMODOHACKER). Má se údajně jednat o 21letého studenta z Iránu, ale to není nijak potvrzené.

Zajímavé je spíše něco jiného: dotyčný, který již dříve poskytoval interview médií, tentokráte popisuje svou motivaci (chtěl prý potrestat Nizozemí za události ve Srebrenici), a hlavně tvrdí, že má přístup k dalším certifikačním autoritám. V jiném svém příspěvku zmiňuje například GlobalSign či StartCom.

Faktem je, že třeba společnost GlobalSign nebrala toto tvrzení na lehkou váhu, hned následující den po jeho zveřejnění přestala dočasně vydávat všechny své certifikáty, a jala se prověřovat pravdivost celého tvrzení. Podle posledních informací (z 15. září) své služby znovu spouští teprve postupně, a přiznává i zjištění určitého průniku – ale prý jen do svého veřejného webového serveru, který pouze hostuje její webové stránky a s vlastním fungováním certifikační autority prý bezprostředně nesouvisí (viz zpráva z 9. září v tomto shrnutí).

A co naše akreditované autority?

Při přípravě tohoto článku jsem se optal i všech tří tuzemských akreditovaných autorit, zda měnily něco na svém fungování, v důsledku celé kauzy kolem autority DigiNotar.

Nejsdílnější byla I.CA, která odpověděla takto:

Dění spojené s útokem na některé významné certifikační autority pečlivě sledujeme. Jde nejen o napadení významných komerčních certifikačních autorit, jako je například GlobalSign, ale především akreditovaného poskytovatele certifikačních služeb DigiNotar. I proto věnujeme vzniklé situaci zvýšenou pozornost. Při poskytování našich služeb důsledně dodržujeme bezpečnostní politiku a aktuální standardy, a to jak v oblasti používaných kryptografických algoritmů, tak v oblasti  technologií a především bezpečné postupy a procesy při poskytování certifikačních služeb. Navíc pravidelně procházíme interními i externími bezpečnostními audity a spolupracujeme mimo jiné i s externími firmami, které testují odolnost naší infrastruktury proti různým typům útoků. Jsme přesvědčeni, že pro bezpečnost a vysokou dostupnost našich služeb děláme dlouhodobě maximum, a proto jsme v souvislosti se zveřejněnými útoky s výjimkou zvýšeného dohledu a důsledného monitoringu vzniklé situace neprovedli žádná dodatečná bezpečnostní opatření.

To PostSignum bylo stručnější:

V zásadě jsme nemuseli přijmout žádná opatření,  pouze jsme provedli kontroly, které nám byly doporučeny společností Microsoft. Naše certifikační autorita má několik úrovní zabezpečení, systémy jsou pravidelně aktualizované a podléhají pravidelným interním i externím auditům.

V obdobném duchu se vyjádřila i eIdentity, která zdůraznila, že její bezpečné prostředky (moduly HSM, Hardware Security Module) jsou zcela odděleny od Internetu.

Jaké je ponaučení?

Ačkoli dnes možná ještě neznáme plný rozsah a všechny důsledky toho, co se stalo, přesto si dovolím (za sebe) učinit určitý obecnější závěr.

Ten vyznívá tak, že nejde o žádné prolomení či jinou kompromitaci technologií, na kterých stojí elektronický podpis. Jako slabé místo, které bude potřebovat určitou nápravu a korekci, se podle mého názoru ukázaly dvě jiné věci: chování některých certifikačních autorit, a pak systém vyjadřování důvěry výrobci softwaru.

Že certifikační autority musí ještě přísněji dbát na bezpečnost svého vlastního fungování, je bez diskuse. Ale když už k něčemu dojde, rozhodně se nesmí chovat tak, jak se zachoval nizozemský DigiNotar, který nereagoval dostatečně rychle, a skoro měsíc se dokonce snažil vše ututlat. Také na to doplatil, a teď už je nejenom bez akreditace, ale i „mimo byznys“. To třeba autorita COMODO, které byla postižena podobně, se přeci jen chovala jinak, rychleji a otevřeněji, a díky tomu dnes funguje dál.

BRAND24

Změnu by si ale podle mne zasloužil i celý systém vyjadřování důvěry, který za své uživatele realizují výrobci softwaru, viz ono automatické naplňování úložišť certifikáty nejrůznějších autorit, které daný výrobce považuje za důvěryhodné. Pravdou je, že na jedné straně to je praktické, protože „běžný Franta uživatel“ pak nemusí mít o nějakých certifikátech a autoritách prakticky ani tušení. Natož aby něco musel dělat (instalovat takovéto certifikáty sám, když je předtím získal dostatečně důvěryhodným způsobem).

Jenže na druhou stranu právě toto řešení usnadňuje útoky takového typu, jaké se odehrály zde. A i samotné uživatele to jakoby „ukolébává“ a vytváří jim falešnou iluzi, že bezpečnost je něco, o co se oni sami nemusí nijak starat. Že to je starost někoho jiného. A i to se musí změnit.

Měnili jste nějak "standardní výbavu" certifikátů autorit v úložišti, se kterým pracuje vámi používaný browser?

Byl pro vás článek přínosný?

Autor článku

Autor byl dlouho nezávislým konzultantem a publicistou, od 8.6.2015 je členem Rady ČTÚ. 35 let působil také jako pedagog na MFF UK v Praze.

Upozorníme vás na články, které by vám neměly uniknout (maximálně 2x týdně).