it-swarm-eu.dev

Jak funguje proces ověření digitálního podpisu?

Nedokážu pochopit, jak je digitální podpis ověřován. Vím, že digitální podpis bude připojen ke zprávě a odeslán odesílatelem příjemci. pak přijímač použije veřejný klíč, který se používá k ověření. Zde jsou mé otázky:

  • odkud tento veřejný klíč pochází?
  • a jak je distribuován do přijímače?
  • jak je veřejný klíč identifikován pro konkrétní digitální podpis?
  • a jaká je role certifikační autority v tomto procesu?
58
n92

Dobře, odpověď je zatím v zásadě na dobré cestě, ale jakmile dorazí, pokusím se odpovědět na vaše otázky:

* where did this public key come from?

Veřejný klíč je součástí páru klíčů používaných v asymetrické kryptografii. Existuje mnoho šifrovacích algoritmů, ale scvrkává se na veřejný klíč a soukromý klíč, které jsou matematicky propojeny. Lze je použít tímto způsobem:

Šifrovat (veřejný klíč, původní data) -> šifrovaná data

Dešifrovat (soukromý klíč, šifrovaná data) -> původní data

Povaha matematického vztahu mezi soukromým a veřejným klíčem souvisí s kryptografickým algoritmem a rychle se stává dobrým tématem Math Overflow. :)

Klíčovou součástí je, že se jedná o pár klíčů, které byly vygenerovány společně.

Dále, v případě digitálního podpisu, odesílatel pošle:

  • původní data, šifrovaná data, veřejný klíč a informace o tom, jak ověřit podpis (například jaký algoritmus se používá)

Ověřovatel provede výše uvedenou operaci dešifrovat a porovná svůj výstup s původními daty. Pokud jsou dva stejné, ví, že se zprávou nezměnilo, protože soukromý klíč má pouze odesílatel, a neexistuje žádný rozumný způsob, jak zjistit soukromý klíč z veřejného klíče.

brát to trochu mimo provoz ...

* and what is the role of the certification authority in this process?

Každý může vytvořit pár soukromých/veřejných klíčů. Vzhledem k dnešním sadám nástrojů je to docela snadný úkol. Takže poskytnout vám můj veřejný klíč, spolu se zašifrovanými daty a podpisem, jak je popsáno, je asi stejně důvěryhodné, jako kdybych vám dal vizitku, kterou jsem vytiskl na Staples za 50 USD. Abychom opravdu věřili, že jsem tím, kdo říkám, že jsem, a proto důvěřuji hodným, potřebujete někoho, kdo se podepíše na mé totožnosti (jako je kontrola řidičského průkazu).

To je práce certifikační autority (zkráceně CA). CA má svůj vlastní pár klíčů - a používá soukromý klíč k podpisu digitálního certifikátu pro držitele klíčů. Certifikát obsahuje veřejný klíč, stejně jako spoustu informací o osobě nebo věcech, které drží tento soukromý klíč. Je to jako moje vláda, která z mě dělá pěkně vypadající id s obrázkem, který nelze snadno zfalšovat bez speciálního vybavení - můžete věřit mým informacím, protože důvěřujete vládě ... ne, protože mi věříte.

Obvykle, když systém ověří podpis, nejen zkontroluje, zda se šifrovaná data shodují s původními daty, ale také, že certifikát , který ručí za identitu držitel veřejného klíče je také řádně podepsán důvěryhodným zdrojem. Systémy CA jsou obvykle organizovány v řetězcích CA, které pocházejí z kořenového adresáře. V prohlížeči můžete najít sbírku významnějších kořenových certifikačních autorit (které jsou podepsány vlastním soukromým klíčem).

U vysoce zabezpečených systémů lze provádět dodatečné kontroly až do minutových stavových informací. Vše záleží na tom, jak důležité je mít absolutně jistotu o stavu odesílatele.

* and how is it (the public key) distributed to the receiver?

Dvojitá kontrola zde - máte na mysli příjemce certifikátu nebo držitele klíče?

Odesílatel (držitel klíče) může získat pár klíčů a certifikát různými způsoby. Nejjednodušším způsobem je učinit je lokálně a poté požádat certifikační autoritu o certifikát a odeslat data veřejného klíče. V jiných případech mohou být klíče vyrobeny centrálně a distribuovány zabezpečenými kanály do držáků klíčů.

Ve většině případů podpisu je pár klíčů vytvořen držitelem klíče, protože to omezuje potenciál, že je soukromý klíč vystaven.

Když je podpis vytvořen a odeslán příjemci, je typické, že ke zprávě bude připojen také veřejný klíč (například standardem je XMLDSIG, kde jedno volitelné pole v prvku je digitální certifikát, který obsahuje veřejný klíč).

V případech, kdy je problém s šířkou pásma, mohou být veřejné klíče drženy v centrálním úložišti - jako je databáze zaměstnanců nebo často v Active Directory nebo jiném serveru LDAP. Podpis pak může odkazovat na identitu odesílatele a proces ověření může zahrnovat požadavek do úložiště, aby získal veřejný klíč.

* how the public key is identified for the specific digital signature?

Obvykle prostřednictvím digitálního certifikátu.

Když odesílatel jde k vytvoření digitálního podpisu, má obvykle pravidla spojená s tím, jaké páry klíčů může použít pro jaké účely. Ve standardu certifikátu X509 certifikáty identifikují pole Použití klíče, které specifikuje specifické účely pro pár klíčů popsaný v certifikátu. Jedním z těchto způsobů použití je digitální podpis a mnoho softwarových systémů vám nedovolí vytvořit podpis bez tohoto nastavení v certifikátu.

CA skutečně stanoví tato nastavení před podpisem certifikátu. V mnoha bezpečnostních politikách nelze určitá nastavení použití klíčů udělit bez konkrétních autentizačních procesů, takže odpovědnost za zjišťování toho spočívá na CA a na lidech, které to mají na starosti (obvykle RA, registrační autority).

Pokud z nějakého důvodu máte systém, který nepoužívá digitální certifikáty, mohou existovat i jiné způsoby, jak určit, jaký pár klíčů je. Nakonec jde o zavedené bezpečnostní politiky a to, co se považuje za vhodné pro danou činnost, která vyžadovala podpis.

37
bethlakshmi

Problém, na který odkazujete (jak distribuujeme veřejné klíče?), Je přesně to, co mají infrastruktury veřejného klíče řešit, a PKI je v podstatě banda certifikačních autorit.

V jednoduchém nastavení bychom měli centrální adresář veřejných klíčů všech; představte si to jako velkou mramorovou desku uprostřed veřejného parku s vyrytými veřejnými klíči. Kdokoli se na to může podívat a být si jistý, že se jedná o „pravou věc“, protože nemůžete jednoduše vymalovat něco, co bylo vyryto.

Veřejná část není obecně dobře připojena k internetu a počítače nemohou „vidět“, že některé informace jsou vyryty a tedy „zaručeny správné“. Také by tam mohly být miliardy držáků klíčů, což by vyžadovalo poměrně velký kus kamene. Překlad do celého počítačového světa je tedy certifikát.

Certifikát je malá struktura, která v konvenčním formátu obsahuje:

  • identita (jméno vlastníka klíče);
  • veřejný klíč (údajně vlastněný touto osobou);
  • digitální podpis vypočtený přes dvě předchozí části Certifikační autorita.

Úlohou CA je přesně vydávat certifikáty, tj. Podepisovat je. Certifikát si můžete představit jako kus velké mramorové desky, která obsahuje konkrétní veřejný klíč. Chcete-li použít veřejný klíč, musíte se nejprve ujistit, že obsahuje správné informace; Chcete-li to provést, ověřte podpis jeden certifikát, pomocí veřejného klíče CA. Pokud je tento podpis správný, pak víte, že CA dělal ten certifikát podepsal, a protože CA podepsal pouze certifikáty poté, co zkontroloval totožnost vlastníka klíče (prostřednictvím jednorázového fyzického protokolu s nimi, např. klíčový vlastník ukázal ID), můžete být „přesvědčeni“, že veřejný klíč v certifikátu skutečně patří identifikovanému vlastníkovi.

Nyní byste mi mohli říct, že jsme problém vůbec nevyřešili, jen jsme jej přesunuli: k ověření certifikátu musíte znát veřejný klíč CA; jak víte, to klíč? Odpověď je v číslech: daný CA může podepsat několik certifikátů, možná milióny z nich. Mohlo by tedy existovat, řekněme, sto CA, které vydávají certifikáty pro celý svět. S vědomím, že sto veřejných klíčů, můžete potenciálně ověřit libovolný certifikát. V jiných světech jsme nejen přesunuli problém, ale také koncentrovali to: obrátili jsme problém distribuce miliard veřejných klíčů na problém distribuce stovky z nich .

A hle! přesně tak se to dělá pro web HTTPS. Během počátečních fází spojení mezi prohlížečem a webovým serverem server odešle svůj certifikát. Prohlížeč poté ověřuje certifikát proti jeho seznamu pevně kódovaného veřejného klíče CA (který byl zahrnut s laskavým svolením dodavatele prohlížeče nebo operačního systému). Jakmile prohlížeč ověří certifikát, zná veřejný klíč serveru a použije jej k vytvoření důvěrného tunelu se serverem.

27
Thomas Pornin

Digitální podpisy se obvykle vytvářejí ve dvou krocích. Prvním krokem je použití zabezpečeného hashovacího algoritmu na datech. Příkladem toho by byly algoritmy SHA-2. Druhým krokem je zašifrování výsledného výstupu pomocí soukromého podpisového klíče.

Když je tedy podpis ověřen veřejným klíčem, dešifruje se na hash odpovídající zprávě. Tento hash lze dešifrovat pomocí veřejného klíče, pouze pokud byl šifrován soukromým podpisovým klíčem.

Veřejné klíče jsou vytvářeny vlastníkem klíčenky. Certifikační autority podepisují certifikát veřejného klíče. Majitelé serveru instalují tento podepsaný certifikát. V SSL (o kterém předpokládám, že se chystáte), certifikát včetně klíče a podpisu od certifikační autority předává server, ke kterému jste připojeni. Váš software zkontroluje, zda se web, ke kterému se připojuje, shoduje s daty v certifikátu, a ověřuje certifikát kontrolou jeho podpisu proti klíči certifikační autority. Certifikační autority používají své klíče pro podepisování a servery používají své klíče pro šifrování.

12
Jeff Ferland

Víte, co je veřejný - soukromý klíč, že?

Chcete něco zašifrovat do bob. Takže budete potřebovat jeho veřejný klíč. Jdete to hledat na internetu, ale nemůžete si být jisti, že veřejný klíč, který dostal, skutečně patří jemu.

Takže zvolíte jiný přístup: získejte klíč od někoho, kdo vás ujistí, že jeden konkrétní klíč patří k bob. CA to přesně dělá.

Jak to CA dělá? Jednoduchý. bob se identifikuje CA a pošle jim svůj veřejný klíč. Tímto způsobem má CA něco, co souvisí s „veřejnou identitou“ bob s tímto veřejným klíčem. A můžete věřit, že veřejný klíč, který jste dostali, skutečně patří uživateli bob.

7
woliveirajr