Podepsání veřejného klíče je ve skutečnosti certifikát. Jedná se o kroky, které podnikám k vytvoření certifikátu veřejného klíče, který mohu distribuovat ostatním, aby se mnou mohli bezpečně komunikovat:

Nastavení

1. Generovat soukromé klíče:
   

   openssl genrsa -out private.pem 2048

2. Generovat veřejné klíče:
   

   openssl rsa -in private.pem -outform PEM -pubout -out public.pem

3. Vytvořit požadavek CSR (Certificate Signing Request)
   

   openssl req -new -key private.pem -out certificate.csr

4. Vytvořit certifikát podepsaný svým držitelem (tento certifikát můžete sdílet)
   

   openssl x509 -req -days 365 -in certificate.csr -signkey private.pem -out certificate.crt

šifrování

openssl rsautl -encrypt -inkey private.pem -keyform PEM – v datech> encrypted_data

Dešifrování

1. extrakce veřejného klíče z certifikátů
   

   openssl x509 -pubkey -noout -in certificate.crt> certpubkey.pem

2. dešifrovat data
   

   openssl rsautl -decrypt -inkey certpubkey.pem -keyform PEM -pubin -in encrypted_data> data

Pokud máte v úmyslu mít svůj klíč podepsaný CA, budete muset poslat soubor CSR (a nějaké peníze) vaší CA, kterou si vyberete, dají vám certifikát, který můžete použít místo certifikátu s vlastním podpisem zmíněno v krocích výše.

Komentáře

• Toto je pravý opak toho, co žádám, ale bude to pro účely diskuse. Aby mohla druhá strana dešifrovat, potřebují buď veřejný klíč, který jsem extrahoval, který je předmětem útoku MITM, nebo potřebují celý certifikát, který obsahuje (šifrovaný) soukromý klíč
• @ user1683793 The druhý konec potřebuje dva certifikáty. První z nich by již měli mít (certifikát CA s vlastním podpisem). Druhý obsahuje veřejný klíč, který chcete ověřit, a je podepsán certifikátem CA (pomocí přidruženého soukromého klíče CA). Platnost druhého certifikátu se testuje pomocí veřejného klíče v certifikátu CA. Soukromé klíče jsou vždy uloženy jako soukromé.
• Myslím, že chcete “ -encrypt “ a “ -decrypt “ místo “ -sign “ a “ -verify „. (Podrobnosti zde: czeskis.com/random/openssl-encrypt-file.html )
• nefunguje: 2. Dešifrovat data nepracoval pro mě. S: openssl rsautl -decrypt -inkey certpubkey.pem -keyform PEM -pubin -in encrypted_data > data Zobrazuje se mi tato chyba / msg: A private key is needed for this operation
• Sekce Setup, krok 2 dává public.pem – již se ‚ nepoužívá kroky. Jaké je použití tohoto veřejného klíče, když se CSR generuje pomocí soukromého klíče?

Do procesu by měly být zapojeny tři entity:

1. Odesílatel – Vy
2. Příjemce – Uživatel
3. Certifikační autorita – Důvěryhodná třetí strana (nebo v některých případech vy)

Proces který udržuje věci v bezpečí je „Odesílatel“, generuje pár klíčů (veřejný a soukromý). Rád bych je označil jako klíč a zámek pro lepší vizuál. Klíč (soukromý) by nikdy neměl opustit vlastnictví odesílatele, proto se nazývá soukromý klíč.

Odesílatel poté vygeneruje požadavek na podpis certifikátu (CSR) s veřejným klíčem (zámek ), který je předán certifikační autoritě (důvěryhodná třetí strana), podepíše certifikační autorita veřejný klíč (zámek) soukromým klíčem certifikační autority.

Certifikační autorita nyní odešle veřejný klíč „The Senders“ který je podepsán soukromým klíčem Certifikačních autorit zpět na „Odesílatele“, kterým je nyní certifikát.

Příjemce získá certifikát (řekněme prostřednictvím webového prohlížeče) a ověří, že je platný pomocí veřejný klíč certifikačních autorit, který „Odesílatel“ i „Příjemce“ mají, protože jsou důvěryhodnou třetí stranou. Jakmile je veřejný klíč v certifikátu ověřen, lze mu důvěřovat *, aby byl veřejný klíč „Odesílatele“ nezměněn.

Pokud „Příjemce“ potřebuje odeslat data „Odesílateli“, použije veřejný klíč z důvěryhodného certifikátu k zašifrování dat do cypertextu, který se poté předá „odesílateli“. Protože pouze soukromý klíč „odesílatele“ může dešifrovat cyphertext, který byl zašifrován veřejným klíčem „odesílatele“ kdokoli ve středu má v podstatě zbytečný zkomolený text.

V některých případech může „Odesílatel“ vygenerovat vlastní Certifikační autoritu podepsáním své vlastní CSR jinou sadou klíčů nebo vlastním podpisem se stejnou sadou V takovém případě musí mít veřejný klíč „Odesílatel“ obě strany znát prostřednictvím zabezpečeného kanálu, aby získal důvěru. V softwaru můžete do dodávky zahrnout certifikát, který lze použít jako důvěryhodnou třetí stranu.

* důvěryhodný je platný, pouze pokud certifikační autorita udržuje seznam CRL (seznam odvolaných certifikátů) a všechny strany seznam sledují zajistit, aby vydaný certifikát nebyl kompromitován. Případ, kdy je certifikační autorita potlačena a došlo k úniku soukromého klíče, existuje, a když k tomu dojde, může kompromitující agent pomocí soukromého klíče vygenerovat důvěryhodný certifikát, který napodobuje „Odesílatele“ , v takovém případě je možné MITM a MITM může přijímat data od „odesílatele“ dešifrovat, ukládat, šifrovat pomocí platného certifikátu, který vypadá jako „odesílatel“, a poté jej předat „příjemci“.

Vyjmout zašifrovaný soukromý klíč z kopie certifikátu CA, který jste vytvořili (při předávání ostatním). Soukromý klíč ano nemusíte tam být, pokud ho nepoužíváte k podepsání certifikátu obsahujícího anoth e veřejný klíč.

Když odesíláte přes svůj veřejný klíč, místo toho odešlete celý certifikát (kromě soukromého klíče) podepsaný pomocí přidruženého soukromého klíče CA. Chcete-li zkontrolovat platnost veřejného klíče uvnitř, musíte zkontrolovat hodnotu hash certifikátu oproti šifrovanému kódu hash (který byl zašifrován pomocí soukromého klíče CA). To je dešifrováno pomocí veřejného klíče CA . Pokud je dešifrování úspěšné a hodnota hash se shoduje s hodnotou hash certifikátu, lze důvěryhodným informacím uvnitř certifikátu.

Existuje také více než jen šifrování, například útok opakování, při kterém útočník odešle dříve uložená šifrovaná data. TLS pokrývá mnohem více, než by si průměrný člověk myslel, a implementace podobného systému se absolutně nedoporučuje. Použijte TLS, kdykoli je to možné, pro cokoli, co má být soukromé.