Hlavní navigace

Vlákno názorů k článku Datové schránky ante portas od Petr Menšík - Nedá mi to a musím se zeptat: jak...

  • Článek je starý, nové názory již nelze přidávat.
  • 25. 3. 2009 12:35

    Petr Menšík
    Nedá mi to a musím se zeptat: jak vlastně potom funguje technická realizace zákonem podporovaného podpisu, když se pomocí toho nelze přihlásit? Který program s tím kvalifikovaným certifikátem nakládat smí a jak se zaručí, že ten program zůstal opravdu tím programem, za který ho považuju (tedy že mě jej nepřepsal vir).

    Myslím, že uživatelé to téměř nikdy nedocení, ale pokud bych dostal od ministerstva vnitra program, který budu mít například na CD, do kterého vložím nějaký náhodný řetězec, on mě jej podepíše, a já pomocí podepsaného výstupu prokáži svoji totožnost, je to v pořádku a kryptograficky čisté, ne?

    Já nejsem majitelem kvalifikovaného podpisu a nejsem si jistý, k čemu takový podpis vlastně mohu použít. Nicméně, problém s důvěryhodným programem musí mít přece už samotný podpis a musí být lépe nebo hůře vyřešen. Jak se to řeší tam? Asi by to chtělo černou skříňku, do které pošlu vstup a na výstupu mě vyleze text. Jenže pokud dojde na aspoň vzdáleně uživatelskou přívětivost a schopnost úředníků s takovým systémem pracovat, nechtěl bych vidět takovou realizaci v praxi.
  • 25. 3. 2009 13:39

    Martin Calko (neregistrovaný)
    Svůj certifikát svěřím bez výčitek svědomí Javovému apletu. Ne tak už svůj soukromý klíč, který mu odpovídá. Pokud budu mít soukromý klíč na tokenu a podporu pro přístup k tokenu nainstalovanou v prohlížeči, můžu podepisovat přímo z prohlížeče bez použití apletu.

    Pokud se týká autentizačních certifikátů, nevím nic o tom, že by jejich vydávání bylo vázáno v ČR na nějakou akreditaci.

    Asi bych neměl problém s tím si na autentizaci pořídit zvláštní certifikát a používat je tak skutečně v páru jak naznačuje Dan Ohnesorg. Vzhledem k vlastnostem certifikátů pro ověření elektronického podpisu by jejich použití pro autentizaci asi opravdu nebylo moc praktické.
  • 25. 3. 2009 14:07

    Zdenek (neregistrovaný)
    Nemyslel jsem rozlisovani typu certifikatu. Vim proc a jak to funguje.

    OS s PIN padem je vam opet na dve veci. Stejne nevite co podepisujete, protoze rootkit v OS vam muze zobrazit na displeji neco jineho nez posila do karty.
  • 26. 3. 2009 0:29

    Dan Ohnesorg
    Ten postup je obecne: Klient se pripojuje, server mu posila svuj certifikat a seznam CA od kterych akceptuje certifikat klienta. Klient overi, ze certifikat serveru je platny a pokud ano posila svuj klientsky certifikat, ktery vybere z uloziste tak, aby byl vystaveny serverem akceptovanou CA. Server overuje certifikat klienta a pokud je OK, tak dochazi k ustaveni SSL spojeni oboustranne zajisteneho certifikaty.

    Je to v zasade stejny princip, jaky znate z ustavovani IPsec spojeni.

    Fundamentalni rozdil mezi timhle a beznym SSL spojenim s pouzitim serveroveho certifikatu (to je to co zna vetsina ctenaru, kdyz jde do banky) je v tom, ze kdyz nekdo na takove spojeni zautoci, server se to dozvi. Neuvidi totiz platny certifikat klienta. U bezneho SSL spojeni pouze dostava klient hlaseni, ze certifikat serveru je asi spatny, ale muze jej klidne ignorovat a komunikovat bez obav s utocnikem, ktery si dela kopii klientovych dat a na server data forwarduje, takze klient dostava ocekavane odpovedi a netusi, ze je neco spatne.
  • 31. 3. 2009 9:02

    MB (neregistrovaný)
    Úředník si myslí, že má systém pod kontrolou, protože mu top ajťák řekl. On ani nemá možnost věřit něčemu (někomu) jinému. Upřímně i ten ajťák, ač velmi poučený, má jen povšechné vědomosti, jak to v kterém tokenu chodí a jaké operace se uvnitř provádí a jak bezpečně.
  • 1. 4. 2009 10:03

    Petr Menšík
    Měl jsem za to, že podepisovat to nebude applet, ale moje vlastní aplikace, do které zkopíruju text z appletu typu:
    Přihlašuji se ke schránce XY jako oprávněný uživatel ZY.
    Do appletu vložím podepsaný text a odešlu. Pravda tady asi trochu narážím na rozdílnost od PGP, kde certifikáty a jejich podpisy se asi často neobalují do ASCII obalu, aby šly bez problémů kopírovat schránkou. Dobře, tenhle způsob by možná byl bezpečnější, ale uživatelsky zcela nepříjemný a odpudivý. Minimálně bez nějakého pomocného programu v prohlížeči.

    Napadá mě, proč by nemohl úřad přijmou nějaký můj klíč, kterým se budu prokazovat. Jak to asi provést - prostě si sám vygeneruju self-signed přihlašovací certifikát nebo použiju jakýkoliv, který už mám odjinud, veřejnou část certifikátu podepíšu kvalifikovaným podpisem a pošlu do datové schránky jako přidělení klíče k té dané schránce. Potom se můžu přihlašovat jiným, ale pro úřad jsem jednoznačně spárován se svým jménem. Samozřejmě to má celkem háček, že potom se musí spravovat ten certifikát a musím mít možnost jej zrušit v případě zcizení.

    Druhá možnost by byla použít něco typu openid, kde já se přihlásím svým certifikátem k mnou důvěřované autoritě a kvalifikované autoritě podepíšu, že moje.openid.com prohlašuju za svoje a chci umožnit pomocí něj přístupu do schránky. I když tady teda nevím, jestli openid je dostatečně odolné i pro zcela seriózní kryptografii, spíš ne. Tohle by sice bylo uživatelsky přívětivější, ale výrazně náchylnější k problémům.

    Prostě ke správě domén mám možnost použít PGP klíč, a pro důležitější projekty je myslím prosté heslo ne vždy dostačující. Pokud si vezmu běžného uživatele, jak si zadá do schránky heslo typu amálka, nebo případně cokoliv, co si dal i k mailu někam na centru bez podpory šifrování, asi se docela pobavíme.

    K tomu flashi, to nejde dát dostatečně viditelný odkaz na hlavní stránku s popisem problémů při přihlášení? V opeře aspoň to po mě kdysi chtělo vybrat certifikát, při zrušení výběru vypíše web normální chybu forbidden. Jestli to jeden prohlížeč prostě není schopen udělat, mělo by se to konzultovat především s výrobcem, nebo zajistit, že uživatelé budou vědět co s tím i přes nic neříkající hlášku. Např. přibalením návodu pro IE k distribuci přístupových údajů. Zahodit solidnější bezpečnost kvůli neschopnosti programátorů konkrétního prohlížeče vyplivnout srozumitelnou chybu je myslím politování hodné.
  • 1. 4. 2009 13:50

    MB (neregistrovaný)
    Potom se můžu přihlašovat jiným, ale pro úřad jsem jednoznačně spárován se svým jménem. Opravdu jednoznačně? Co když se o přihlášování do téže datové schránky přihlásí více osob a více certifikátů podepsanými různými el. podpsisy s kvalifikovanými certifikáty. Který je ten správný? (Uvažme i spory ve firmě.) Úřad nevidí a nemá právo vidět, kdo je skutečný držitel certifikátu. A nepozná to ani pro fyzickou osobu! Identitu zná a má zdokladovanou jen certifikační autorita a tu nesmí nikomu poskytnout. Poskytuje jen údaje, které obashuje certifkát. Jiná možnost pak je přijít s takovým certifikátem na úřad a zaregistrovat si tam ten svůj cerrtifikát s osobním předložením dokladů. Ale to už by mohl dělat certifikační autoritu přímo každý úřad a to vždy jen pro sebe.
  • 3. 4. 2009 20:42

    Petr Menšík
    Tak tyhle spory se mohou vést i o heslo nebo jakýkoliv jiný prostředek pro přihlašování. Pravda, nedošlo mi úplně, že firmy asi často nejsou jenom fyzické osoby s jednoznačným přiřazením jedné osoby k jedné firmě, ale že osoba pověřené správou firmy se může změnit na jinou. Otázka ovšem je, kdo vlastně a jakým procesem dostane heslo k firemní schránce a jak by se to lišilo při použití certifikátu. Jestli to dobře chápu, heslo přijde na firmu v obálce pravděpodobně s pruhem. Takové si otevře a přečte první sekretářka na příjmu listin? Nebo komu to vlastně bude adresováno? Jak pověřená osoba přijde k přístupovému klíči? Jak se zajistí, že přístupový údaj nemůže zneužít někdo jiný, než člověk odpovědný za firmu? Dejme tomu právo pověřit další certifikát přístupem by měl pouze člověk spravující firmu, elektronicky ten, kdo si aktivoval první certifikát. Takové právo by mohl pouze převést na jiného a sám se jej zbavit. To by mohl být problém pro společníky, kde je více vlastníků se stejným dílem ve firmě. Ale na tyhle nepamatuje ani to heslo...

    Myslím že informace v podepisovacím certifikátu je naprosto dostatečná a co leží v přihlašovací certifikátu je úplně jedno. Ten by byl jenom jako nástroj pro přihlášení. Nejdůležitější asi je, jak bezpečným způsobem k tomu heslu přijde. Jestli by tam dostal heslo, nebo nějaký elektronický klíč, už asi není zas tak podstatné. Pravda povinná čtečka za peníze firem by se asi nelíbila firmám, stejně tak za peníze státu zaměstnancům. Pravda přihlašování více lidí k jedné schránce není zas tak triviální problém a jeho řešení není úplně jednoduché. Pro provozovatele služby je určitě mnohokrát jednodušší, když si budou po firmě šuškat heslo všichni stejné, než řešit přístupové oprávnění každého zaměstnance firmy odděleně. Zkušenost ale praví, že sdílené heslo není dobré na vážné věci, celkem mě zajímá, jak se s tím poperou.

    Taktéž vnitrofiremní spory je oprávněn řešit tak možná soud. Jestli se budou lidé ve firmě přetahovat o certifikát nebo o heslo je úplně jedno, ani jeden způsob přetahování zabránit nemůže. Ostatně podle mě vůbec žádný technický způsob tomu zabránit nemůže. když je spor administrativní či právní.
  • 25. 3. 2009 8:18

    kolemjdoucí (neregistrovaný)
    Docela by mě zajímal způsob přihlašování k datové schránce prostřednictvím elektronického podpisu. Bude se nějakým způsobem autentizovat i server? Jak bude zajištěno, že aplikace, která bude sloužit k autentizaci uživatele ve skutečnosti nenechává podepsat něco jiného, než uživateli prezentuje? Která aplikace bude kvalifikována k použití elektronického podpisu a jak bude toto možné ověřit?
  • 25. 3. 2009 8:30

    Zdenek (neregistrovaný)
    Pri prihlasovani pomoci certifikatu (alias el. podpisu) nedochazi k podepisovani, tak jak ho chapete. Pouze se overi, ze certifikat je platny a ze ho vydala spravna autorita. Server se pochopitelne taktez prokazuje svym certifikatem a prohlizece to zobrazuji.
  • 25. 3. 2009 8:54

    Zdenek (neregistrovaný)
    Mate pravdu, mel jsem predpokladat, ze nasi zakonodarci opet neco nedomysleli. Takze to vidim v tom lepsim pripade na java applet.
  • 25. 3. 2009 10:14

    anonymní
    K navázání ssl spojení neslouží klientský certifikát (jedno jestli veřejný nebo kvalifikovaný), ale certifikát serverový. Pro přihlášení můžete využít několik mechanismů - jedna z možností je použít certifikát přenesený v okamžiku handshakingu - to je klasická autentizace certifikátem. K tomu nelze ze zákona použít certifikát určený pro podpis - bez ohledu na to, o jaký druh certifikátu jde - primárně to však jsou kvalifikované certifikáty. Tedy pro tento způsob je vhodný veřejný certifikát nebo certifikát, který není od kvalifikované CA (např. certifikát banky apod.). Druhý způsob je vámi popsaný - podpis prohlášení, že se přihlašuji.
  • 25. 3. 2009 10:22

    Dan Ohnesorg
    Zakon jasne zakazuje pouziti kvalifikovaneho certifikatu pro jiny ucel nez podpis. Dela to logicky proto, protoze kopiruje zakladni bezpecnostni standardy pro praci s pristupovymi a podpisovymi certifikaty.

    Jakykoliv java applet sice opticky vypada, ze resi technicky problem, ale ve skutecnosti porusuje bezpecnostni standardy. To ze kvalifikovany certifkat neumoznuje otevrit SSL spojeni neni nejaka vada, kterou musime slozite obchazet. Je to ochrana proti tem, kdo kryptografii vubec nerozumi.

    Ve chvili, kdy vam nekdo posle java applet a ten nacte vas certifikat, je uplne jedno, jestli zobrazi nejaky text, ktery musite podepsat. Je to situace, kdy jste sverili svuj kvalifikovany certifikat vcetne privatniho klice *cizi* aplikaci a dusledky jsou jasne, takovy stav se rovna kompromitaci privatniho klice kvalifikovaneho certifikatu.

    Bohuzel urednici tohle neradi slysi, protoze argumentuji tim, ze nejlepe placeni bezpecnostni experti CSOB toto reseni prosadili do jejich bankovnictvi a nikdy s nim nemeli problem. Soucasne nemaji odvahu chtit po lidech, aby si porizovali zvlast pristupovy a zvlast podpisovy certifikat.

    Ono je mozna z hlediska dusledku, ktere muze prinest kompromitace, lepsi pro takovyhle ucel pouzivat proste to jmeno a heslo, samozrejme s nejakym SSL tunelem a rozumnym zpusobem ukladani osolenych hashu hesel na strane provozovatele datovych schranek.
  • 25. 3. 2009 10:28

    Zdenek (neregistrovaný)
    Prijde mi celkem nesmyslne, neduverovat appletu stazenemu skrz zabezpecene spojeni z duveryhodneho zdroje. To muzeme rovnou zacit resit jak bezpecny je operacni system na kterem s tim soukromym klicem pracujete. A tam velmi rychle skoncime :-)
  • 25. 3. 2009 13:58

    cmartin
    Pokud ověříte náhodný řetězec kvalifikovaným certifikátem, dopouštíte se porušení certifikační politiky. Certifikační politika kvalifikovaných certifikátů totiž předpokládá, že to co podepisujete dokážete pochopit a případně podpisem vyjadřujete svůj postoj k obsahu, což u řetězce náhodných čísel může být jen stěží splněno.

    Tak jak to popisujete velmi zhruba funguje autentizační certifikát, který ovšem nezaručuje Vaši skutečnou identitu.

    Je možné, že by pro tyhle účely mohly certifikační autority začít vydávat autentizační certifikát se zaručenou identitou držitele. Takový postup ovšem v současnosti nemá oporu v zákoně, což je asi ve vztahu ke státnímu informačnímu systému (ISDS) vážný problém.

    Problém s uložením soukromého klíče pro podpis je obvykle řešen buďto uložením na čipové kartě, jak už zmínil Dan Ohnesorg, nebo na tokenu (hardwarově skoro totéž ale bez potřeby čtečky karet) nebo v nejhorším případě v aplikaci. Rozdíl je v tom, že soukromý klíč po nahrání do karty nebo tokenu už nelze nijak vyexportovat (výrobce i konstruktér věnovali nemalé úsilí tomu, aby to nešlo) a požadavky na šifrování a podpisování pomocí uloženého klíče řeší přímo token nebo karta na které je klíč uložen (je vyžadováno zadání PIN pro odblokování funkce, PIN po vyjmutí tokenu z počítače nebo karty ze čtečky zmizí). Je to pravda, vzhledem k rychlosti procesoru karty nebo tokenu, trochu pomalé ale klíč je dosti bezpečně uložen mimo dosah neoprávněných osob. V aplikaci je to jednodušší, rychlejší a méně bezpečné protože soukromý klíč lze principiálně vyexportovat ven a tím kompromitovat. Je to ale oproti "bezpečnému" uložení mnohem rychlejší ;)
  • 26. 3. 2009 0:18

    Dan Ohnesorg
    S prvnim odstavcem jednoznacne souhlasim.

    Kvalifikovany certifikat je vazna vec a pracuje se s nim nasledujicim zpusobem:

    vytvorim dokument

    podepisu dokument

    odeslu dokument protistranne.


    Prvni dva kroky provadim pomoci software, kteremu verim, ktery je zcela pod mou kontrolou, ktery muze byt napr. na pocitaci nepripojenem k Internetu. Jedna se o software standardizovany, siroce pouzivany, mnohokrat auditovany. Dokonce mohu vytvorit software vlastni, protoze uplne vsechny operace prvnich dvou kroku jsou popsany v normativnich dokumentech. Resp. predevsim zasadni druhy krok podpisu samotneho.

    Co se stane v pripade prihlaseni pres kvalifikovany certifikat ala tato reseni:

    uzivatel si stahne nejaky applet, ktery je pri kazdem stazeni jiny, tezko si schovate ten, ktery tam byl kdyz jste se prihlasoval, kdyz jej nekdo zameni, nedokazete to.

    server posle appletu certifikacni vyzvu a ten ji uzivateli zobrazi, vyzva je dejme tomu: "Ahoj, je 1.1.2009 13:05:06, chces se podivat do sve schranky?"

    applet !spocita! kryptografickou sumu dane vyzvy a podepise ji. Jak sumu spocital a jestli nepodepisuje nejakou jinou nemate moznost ovlivnit ani overit.

    podepsana suma se odesle na server a mate poskytnuty pristup

    K tomu si prictete, ze ceske zakony neumoznuji mit vice variant kvalifikovaneho certifikatu, takze uplne stejne podepisujete prihlaseni do danove schranky, kde najdete stejne jen informace, ktere si potom prectete ve sbirce listin na obchodnim rejstriku, jako prodej sveho bytu, uzavreni hypoteky, vzdani se prava odvolani proti platebnimu rozkazu....

    To je proste zasadne spatne. Lide se musi naucit pracovat se svou digitalni identitou a stat neni ten, kdo je ma ucit od zacatku vadne navyky.

    Bohuzel prosazovat variantu prihlaseni/otevreni spojeni SSL certifikatem je tezke. Implementace v soucasnych prohlizecich neni nic moc, takze treba IE pri odmitnuti certifikatu hodi chybu -301. Manageri ale chteji takovemu uzivateli zobrazit sexy flashovou animaci ukazujici, jak se strka cipova karta do ctecky a to je fakt orisek nejak vyresit, kdyz bylo spojeni serverem uzavreno. Pritom jedina moznost, jak detekovat MIM utok na strane serveru, je nechat otevrit spojeni oboustranne certifikaty.
  • 25. 3. 2009 12:38

    Dan Ohnesorg
    Prekvapive se autor meho operacniho systemu nedomniva, ze podpisovy a pristupovy certifikat je to same. I kdyz si vlezete do outlooku, tak tam najdete v nastaveni sifrovani certifikat pro popis a certifikat pro sifrovani.

    Autori prohlizecu take prekvapive nenabizeji kvalifikovane certifikaty pro otevreni SSL spojeni. A proc to nedelaji? Protoze respektuji nastaveni jednoho bitu v hlavicce certifikatu.

    Proste tak nejak mam pocit, ze ten kdo implementuje veci podle standardu si zaslouzi duveru. Ten kdo standardum navzdory presne naopak. Navic OS umi pracovat s certifikaty na cipovych kartach vlozenych v cteckach s PIN padem. OS prochazi kontinualnim bezpecnostnim testovanim, ma miliony a miliony uzivatelu. Nemeni se mi pri kazdem stazeni pod rukama. To je na cely clanek.
  • 30. 3. 2009 13:47

    petr_p (neregistrovaný)

    A teď se na to podívejme prakticky.

    Například vnitro se dohodlo s poštou, že se kryptografie na Czech POINTech bude provádět v USB tokenu iKey 4000 a to celé poběží na Windows Vista Business.

    Takže úřad zakoupí uzavřený software a hardware a úředník odmítne takovou věc používat, protože si oprávněně myslí, že takový systém není pod jeho výhradní kontrolou.

  • 25. 3. 2009 8:37

    kolemjdoucí (neregistrovaný)
    Teď Vám asi nerozumím: kvalifikovaný certifikát nemůže sloužit k navázání spojení pomocí ssl. Pokud mám být přihlášen (autentizován), pak musím nějakým způsobem odeslat podepsaná data (něco jako "Přihlašuji se k serveru blabla.cz pod účtem lojza"), abych doložil, že vlastním i tajný klíč.
  • 30. 3. 2009 14:33

    anonymní
    Obavam se, ze urednikovi je srdecne jedno, zda je system pod jeho kontrolou. Hlavne, aby to bylo jednoduche a pri ovladani neotravovalo s nejakymi PINy nebo hesly.
Upozorníme vás na články, které by vám neměly uniknout (maximálně 2x týdně).