it-swarm-eu.dev

Jak fungují procesy pro digitální certifikáty, podpisy a ssl?

Snažil jsem se pochopit, jak ssl funguje. Místo Alice a Boba umožňuje zvážit komunikaci mezi klientem a serverem. Server má digitální certifikát získaný od CA. Má také veřejné a soukromé klíče. Server chce odeslat zprávu klientovi. Veřejný klíč serveru je již klientovi k dispozici.

Předpokládejme, že je handshake ssl dokončen.

Server to Client:

  • Server připojí ke zprávě svůj veřejný klíč.
  • Spustí hašovací funkci zapnutou (zpráva + veřejný klíč). Výsledky jsou známé jako HMAC.
  • Zašifrujte HMAC pomocí soukromého klíče. Výsledek se nazývá digitální podpis.
  • Zašlete jej klientovi společně s digitálním certifikátem.
  • Klient zkontroluje certifikát a zjistí, že je z očekávaného serveru.
  • Dešifruje HMAC pomocí veřejného klíče serveru.
  • Spustí hašovací funkci zapnutou (zpráva + veřejný klíč) pro získání původní zprávy.

Klient na server

  • Klient spustí hash funkci na (zpráva + veřejný klíč) a poté zašifruje pomocí stejného veřejného klíče.
  • Server dešifruje pomocí soukromého klíče, spustí hašovací funkci na výsledných datech, aby získala zprávu.

Prosím, dejte mi vědět, jestli moje chápání je správné.

27
John

Ve vašem příspěvku je několik zmatků. Za prvé, HMAC není hashovací funkce . Více o HMAC později.

Hašovací funkce

Ahašovací funkceje zcela veřejný algoritmus (v tom není žádný klíč), který rozbije bit dohromady způsobem, který je skutečně nemožný rozmotat: kdokoli může spustit hašovací funkci na kterémkoli data, ale nalezení dat zpět z hašovaného výstupu se zdá být mnohem nad naším vtipem. Hašovací výstup má pevnou velikost, obvykle 256 bitů (se SHA-256) nebo 512 bitů (se SHA-512). Funkce SHA- *, která vydává 160 bitů, se nazývá SHA-1, nikoli SHA-160, protože kryptografové ponechaní na svých vlastních zařízeních mohou zůstat rozumní pouze tak dlouho, a určitě ne za pátým pintem.

Podpisové algoritmy

Algoritmus Apodpispoužívá pár kláves, které jsou matematicky propojeny,soukromý klíčaveřejný klíč(připsání soukromého klíče z veřejného klíče je teoreticky proveditelné, ale v praxi je to příliš obtížné, dokonce iu skutečně velkých počítačů, což je důvod, proč je veřejný klíč veřejný a je veřejný) zatímco soukromý klíč zůstává soukromý). Pomocí matematické struktury klíčů umožňuje algoritmus podpisu:

  • togenerovatpodpis na některých vstupních datech pomocí soukromého klíče (podpis je matematický objekt, který je přiměřeně kompaktní, např. několik set bytů pro typický podpis RSA) ;
  • naověřitpodpis na některých vstupních datech pomocí veřejného klíče. Ověření bere jako parametry podpis, vstupní data a veřejný klíč a vrací buď „perfektní, člověče!“ nebo „kámo, ty se neshodují“.

Pro algoritmus zabezpečeného podpisu je údajně nemožné vytvořit hodnotu podpisu a vstupní data tak, aby ověřovací algoritmus s daným veřejným klíčem řekl „dobrý“,pokudvíte odpovídající soukromý klíč, v tom případě je to snadné a efektivní. Nezapomeňte na drobný tisk: bez soukromého klíče nemůžete vyčarovat některá dataahodnotu podpisu, která pracuje s veřejným klíčem, i když si můžete vybrat data a podpis jak si přeješ.

„Údajně neuskutečnitelný“ znamená, že na něm všichni inteligentní kryptografové na světě pracovali několik let a přesto nenašli způsob, jak to udělat, a to ani po pátém pintu.

Většina (ve skutečnosti všech) podpisových algoritmů začíná zpracováním vstupních dat pomocí hashovací funkce a poté pracuje pouze na hašovací hodnotě. Je to proto, že podpisový algoritmus potřebuje matematické objekty v některých daných množinách, které jsou omezené velikostí, takže musí pracovat s hodnotami, které nejsou „příliš velké“, jako je například výstup hashovací funkce. Vzhledem k povaze hašovací funkce fungují věci dobře (podepsání hašovacího výstupu je stejně dobré jako podepsání hašovacího vstupu).

Výměna klíčů a asymetrické šifrování

Aprotokol pro výměnu klíčůje protokol, ve kterém obě strany házejí matematické objekty na sebe, přičemž každý objekt je pravděpodobně spojen s některými tajnými hodnotami, které pro ně uchovávají, a to způsobem hodně podobné párům veřejného/soukromého klíče. Na konci výměny klíčů mohou obě strany vypočítat společnou „hodnotu“ (další matematický objekt), která se zcela vyhýbá pochopení toho, kdo pozoroval bity, které byly vyměněny na drátu. Jeden běžný typ algoritmu pro výměnu klíčů jeasymetrické šifrování. Asymetrické šifrování používá pár veřejných a soukromých klíčů (ne nutně stejný druh než pro podpisový algoritmus):

  • Pomocí veřejného klíče můžetešifrovatčást dat. Velikost těchto dat je obvykle omezena (např. Ne více než 117 bajtů pro RSA s 1024bitovým veřejným klíčem). Výsledkem šifrování je, hádejte, co je matematický objekt, který může být zakódován do posloupnosti bajtů.
  • Pomocí privátního klíče můžetedešifrovat, tj. Provádět reverzní operaci a obnovit počáteční vstupní data. Předpokládá se, že bez soukromého klíče, velké štěstí.

Pak se spustí protokol pro výměnu klíčů: jedna strana vybere náhodnou hodnotu (posloupnost náhodných bajtů), zašifruje ji veřejným klíčem partnera a pošle jej. Peer používá svůj soukromý klíč k dešifrování a získává náhodné hodnoty, což je sdílené tajemství.

Historické vysvětlení podpisů je: „šifrování soukromým klíčem, dešifrování veřejným klíčem“.Zapomeňtetoto vysvětlení. To je špatně. To může platit pouze pro konkrétní algoritmus (RSA) a pak znovu pouze pro bastardizovanou verzi RSA, která ve skutečnosti nemá dostatečné zabezpečení. Takže ne , digitální podpisy nejsou asymetrické šifrování „obráceně“.

Symetrická kryptografie

Jakmile mají dvě strany sdílenou tajnou hodnotu, mohou použít symetrickou kryptografii k výměně dalších údajů důvěrným způsobem. Nazývá se symetrický, protože obě strany mají stejný klíč, tj. Stejnou znalost, tj. Stejnou sílu. Už žádná soukromá/veřejná dichotomie. Používají se dva primitivové:

  • Symetrické šifrování : jak spravovat data a později je zaměnit.
  • Kódy ověřování zpráv : "kontrolní klíčový klíč": pouze lidé, kteří znají tajný klíč, mohou vypočítat MAC na některých datech (je to jako podpisový algoritmus, ve kterém jsou soukromý a veřejný klíč identické - takže „veřejný“ klíč by neměl být lepší!).

HMAC je druh MAC, který je postaven na hašovacích funkcích inteligentním způsobem, protože existuje mnoho ne-inteligentních způsobů, jak to udělat, a které selhávají kvůli jemné detaily o tom, co hashovací funkce poskytuje a neposkytuje.

Certifikáty

Acertifikátje kontejner pro veřejný klíč. S výše vysvětlenými nástroji je možné si představit, že server bude mít veřejný klíč, který klient použije k výměně klíčů se serverem. Jak se však klient ujistí, že používá veřejný klíč správného serveru, a nikoli tajný útočník, darebák, který server chytře předstírá? Tam přicházejí certifikáty. Certifikát jepodepsánněkým, kdo se specializuje na ověřování fyzických identit; nazývá se aCertifikační autorita. CA se setká se serverem „v reálném životě“ (např. V baru), ověří identitu serveru, získá veřejný klíč serveru od samotného serveru a podepíše celou partii (identita serveruaveřejný klíč). Výsledkem je šikovný svazek, který se nazývá certifikát. Certifikát představuje zárukuCA, že jméno a veřejný klíč se navzájem shodují (doufejme, že CA není příliš naivní, takže záruka je spolehlivá - nejlépe, CA vydávánepodepisuje certifikáty po pátém pintu).

Klient, když vidí certifikát, může ověřit podpis na certifikátu relativně k veřejnému klíči CA, a získat tak důvěru v to, že veřejný klíč serveru skutečně patří k zamýšlenému serveru.

Ale řekli byste mi, co jsme získali? Stále musíme znát veřejný klíč, jmenovitě veřejný klíč CA. Jak to můžeme ověřit? Můžeme použítdalšíCA. Tím se problém pouze posouvá, ale může to skončit problémem znáta priorijedinečný nebo hrst veřejných klíčů od über-CA, které nejsou podepsány kdokoliv jiný. Microsoft se zamyslel nad tím, že hluboko v samotném Internet Exploreru vložil asi sto takových „kořenových veřejných klíčů“ (nazývaných také „kotvy důvěry“). Odtud pochází důvěra (přesně jste propadli základu své důvěry ve firmu Redmond - nyní chápete, jak se Bill Gates stal nejbohatším chlapem na světě?).

[~ # ~] ssl [~ # ~]

Nyní to pojďme dohromady, v protokolu SSL, který je nyní známý jako TLS („SSL“ byl název protokolu, když to byla vlastnost Netscape Korporace).

Klient si přeje mluvit se serverem. Odešle zprávu („ClientHello“), která obsahuje spoustu administrativních dat, například seznam šifrovacích algoritmů, které klient podporuje.

Server odpoví ("ServerHello") řeknutím, které algoritmy budou použity; poté server odešle svůj certifikát („Certifikát“), případně s několika certifikáty CA pro případ, že by je klient mohl potřebovat (ne kořenové certifikáty, ale střední certifikáty, certifikáty underling-CA).

Klient ověří certifikát serveru a extrahuje z něj veřejný klíč serveru. Klient generuje náhodnou hodnotu ("tajný klíč"), zašifruje jej veřejným klíčem serveru a odešletentona server ("ClientKeyExchange").

Server dešifruje zprávu, získá pre-master a odvodí z ní tajné klíče pro symetrické šifrování a MAC. Klient provádí stejný výpočet.

Klient odešle ověřovací zprávu („Dokončeno“), která je zašifrovaná a MACed s odvozenými klíči. Server ověří, zda je dokončená zpráva správná, a v odpovědi odešle svou vlastní „dokončenou“ zprávu. V tomto okamžiku klient i server mají všechny symetrické klíče, které potřebují, a vědí, že „handshake“ uspěl. Aplikační data (např. Požadavek HTTP) se pak vyměňují za použití symetrického šifrování a MAC.

Neexistuje žádný veřejný klíč ani certifikát, který by se mimo proces handshake účastnil. Pouze symetrické šifrování (např. 3DES, AES nebo RC4) a MAC (obvykle HMAC s SHA-1 nebo SHA-256).

38
Tom Leek

Po dlouhém boji. Níže mám přehled o rozdílech mezi SSL, šifrováním asymetrického klíče, digitálním certifikátem (DC) a digitálním podpisem (DS).

Co je digitální certifikát, známý také jako certifikát veřejného klíče?

DC je elektronický dokument, který používá digitální podpis k navázání veřejného klíče na informace o identitě, jako je jméno, adresa atd

Obsah certifikátu: Certifikát veřejného klíče

Nejdůležitější je bytost, podpisový algoritmus, vydavatel a veřejný klíč.

Co je šifrování asymetrického klíče a digitální podpis?

Vysvětleno pomocí příkladu.

Oba počítače mají dvojici kryptografických klíčů - veřejný šifrovací klíč a soukromý dešifrovací klíč.

Stroj-A má přístup k veřejnému klíči a certifikátu stroje-B.
Stroj-B má přístup k veřejnému klíči a certifikátu stroje-A.

Machine-A to Machine-B

Na stroji A:

  • Hash_function (Data) = Hash
  • Šifrovat (hash) pomocí soukromého klíče Machine-A = DS
  • Připojit data k DS a DC = Data + DS + DC
  • Šifrovat (Data + DS + DC) pomocí veřejného klíče stroje-B.
  • Zašlete to do stroje B.

Na stroji B:

  • Dešifrujte (Data + DS + DC) pomocí soukromého klíče stroje B.
  • Ověřte DC k ověření počítače-A).
  • Dešifrovat (DS) pomocí veřejného klíče stroje-A = Hash # 1
  • Hash_function (Data) = Hash # 2
  • if (Hash # 1 == Hash # 2) Data a podpis jsou platné.

Machine-B to Machine-A

Proces je nyní přesně obráceným postupem.

Co je to SSL/TLS?

Protokol TLS umožňuje aplikacím klient/server komunikovat v síti způsobem navrženým tak, aby zabránil odposlouchávání a manipulaci. Ve většině komunikace mezi klientem a serverem musí být ověřen pouze server. TLS zjednodušuje asymetrické šifrování klíčů, aby bylo možné tento jev efektivně využít. Secure Sockets Layer

Příklad klienta a serveru.

Server má digitální certifikát získaný od CA. Má také veřejné a soukromé klíče.

Uživatel klikne na adresu URL začínající na

https: //

Pro tuto relaci je nutné zabezpečené připojení. Prohlížeč naváže připojení TCP na HTTPS TCP Port 443).

  1. Klient> Server: SYN
  2. Klient <Server: SYN + ACK
  3. Klient> Server: ACK

    SSL Handshake při novém připojení TCP:

  4. Klient> Server: CLIENT_HELLO

    Klient odešle na server příkaz CLIENT_HELLO, který zahrnuje:

    • Nejvyšší verze SSL a TLS podporovaná klientem.
    • Šifry podporované klientem. Šifry jsou seřazeny podle preferencí.
    • Metody komprese dat, které jsou podporovány klientem.
    • ID relace. Pokud klient zahajuje novou relaci SSL, ID relace je 0.
    • Náhodná data generovaná klientem pro použití v procesu generování klíčů.
  5. Klient <Server: SERVER_HELLO

    Server odešle klientovi příkaz SERVER_HELLO, který zahrnuje:

    • Verze SSL nebo TLS, která bude použita pro relaci SSL.
    • Šifra, která bude použita pro relaci SSL.
    • Metoda komprese dat, která bude použita pro relaci SSL.
    • ID relace pro relaci SSL.
    • Náhodná data generovaná serverem pro použití v procesu generování klíčů.
  6. Klient <Server: CERTIFIKÁT (VEŘEJNÝ KLÍČ)

    Server odešle příkaz CERTIFICATE. Obsahuje certifikát serveru.

  7. Klient <Server: SERVER_DONE

    Server odešle příkaz SERVER_DONE. Tento příkaz označuje, že server dokončil tuto fázi handshake SSL.

  8. Klient> Server: CERTIFICATE_VERIFY

    Klient informuje server, že ověřil certifikát serveru

  9. Klient> Server:

    S využitím všech dosud vygenerovaných dat v handshake klient (ve spolupráci se serverem, v závislosti na použité šifře) vytvoří pre-master tajemství relace, zašifruje je veřejným klíčem serveru (získaným z certifikátu serveru) ) a poté zašle zašifrované tajné předběžné master na server.

    Server používá svůj soukromý klíč k dešifrování tajemství před masterem a poté provede řadu kroků k vytvoření hlavního tajemství.

    Klient také provádí stejnou sérii kroků v tajnosti před masterem, aby vygeneroval stejné hlavní tajemství.

    Poznámka: V situacích, kdy je třeba klienta autentizovat, podepisuje klient také jinou část dat, která je pro tento handshake jedinečná a je známa klientem i serverem. V tomto případě klient odešle na server podepsaná data i vlastní certifikát klienta spolu se zašifrovaným tajným předběžným masterem.

  10. Klient <> Server:

    Klient i server používají hlavní tajemství ke generování klíčů relace, což jsou symetrické klíče používané k šifrování a dešifrování informací vyměněných během relace SSL a k ověření jejich integrity.

    Poznámka: Od nynějška je to symetrické šifrování klíčů.

  11. Klient> Server:

    Klient odešle na server zprávu informující, že budoucí zprávy od klienta budou šifrovány klíčem relace.

  12. Klient> Server: FINISHED

    Klient poté odešle samostatnou (šifrovanou) zprávu, která označuje, že je část handshake hotová.

  13. Klient <Server:

    Server odešle klientovi zprávu informující, že budoucí zprávy ze serveru budou šifrovány klíčem relace.

  14. Klient <Server: DOKONČEN

    Server odešle samostatnou (šifrovanou) zprávu, která označuje, že je část handshake hotová.

    Handshake SSL je nyní dokončen a relace začíná. Klient a server používají klíče relace k šifrování a dešifrování dat, která si navzájem posílají, ak ověření jeho integrity.

4
John

Pro podrobnější vysvětlení „pod kapotou“ mohu také navrhnout následující článek: Prvních několik milisekund připojení HTTPS autor Jeff Moser. Tento článek používá zachytávání paketů komunikační relace HTTPS k ilustraci fungování protokolu. Je zajímavé vidět věci, o kterých mluvíme v akci, a vyjasňuje mnoho „tmavých“ skvrn.

2
George

Ne tak docela; certifikáty vstupují do hry pouze během počátečního SSL handshake nebo během nového vyjednávání SSL. Poté bude použita symetrická šifra jako AES, (3) DES nebo RC4. Krypto veřejný klíč je obecně dražší než symetrické krypto, takže se obvykle používá k dohodě o symetrickém klíči na začátku.

1
Steve Dispensa