web-dev-qa-db-ja.com

CA署名付き公開鍵を作成するにはどうすればよいですか？

他の誰かに秘密データを私の公開鍵で暗号化してもらい、秘密鍵で復号化する必要があります。 OpenSSLを使用してRSA秘密/公開キーのペアを作成し、公開キーを提供してすべてが機能するようにしました。

ごく最近、悪意のある人が私の公開鍵を受け取り、自分の公開鍵を反対側に渡す可能性がある中間者攻撃の可能性があると誰かが指摘しました。次に、秘密のデータを忠実に暗号化し、MITMに渡します。MITMはそれを復号化し、公開鍵で再暗号化してから、私に賢くせずに渡します。推奨される解決策は、公開鍵を渡す前に、相手側が信頼するCAによって署名されるようにすることです。

実験として、自分のCAで署名できるCSRを作成しましたが、作成された証明書には（暗号化された）秘密鍵も含まれています。暗号化されているかどうかに関係なく、秘密鍵を他の人に渡したくない。

公開鍵に署名するだけの方法はありますか？

certificatespublic-key-infrastructurecertificate-authoritydigital-signature
9
user1683793

公開鍵への署名は事実上証明書です。これらが私と安全に通信できるように他の人に配布できる公開鍵証明書を作成するために実行する手順は次のとおりです。

セットアップ

  1. 秘密鍵を生成：

    openssl genrsa -out private.pem 2048

  2. 公開鍵を生成します：

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

  3. CSR（証明書署名要求）を作成する

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

  4. 自己署名証明書を作成します（この証明書を共有できます）

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

暗号化する

openssl rsautl -encrypt -inkey private.pem -keyform PEM -in data> encrypted_data

復号化

  1. 証明書から公開鍵を抽出する

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

  2. データを復号化する

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

CAがキーに署名する予定がある場合は、選択したCAにCSRファイル（および現金）を送信する必要があります。これにより、自己署名証明書の代わりに使用できる証明書が提供されます。上記のステップで述べた。

10
Whome

プロセスに関与する3つのエンティティが必要です。

  1. 送信者-あなた
  2. レシーバー-ユーザー
  3. 認証局-信頼できるサードパーティ（場合によってはあなた）

物事を安全に保つプロセスは「送信者」であり、鍵のペア（公開と秘密）を生成します。私は、これらをキーとロックとして参照し、より見やすいようにしています。キー（プライベート）が送信者の所有物を離れることはありません。そのため、秘密キーと呼ばれます。

次に、送信者は公開鍵（ロック）を使用して証明書署名要求（CSR）を生成し、これを認証局（信頼できる第三者）に転送します。認証局は、公開鍵（ロック）に認証局の秘密鍵で署名します。

認証局は、認証局の秘密鍵で署名された「送信者」公開鍵を、現在は証明書である「送信者」に送り返します。

レシーバーは証明書を取得し（Webブラウザーで通知します）、信頼できるサードパーティであるため、「送信者」と「受信者」の両方が持つ認証局の公開鍵でそれが有効であることを確認します。検証されると、証明書の公開鍵は変更されない「送信者の」公開鍵であると信頼できます*。

「受信者」が「送信者」にデータを送信する必要がある場合、信頼できる証明書からの公開鍵を使用してデータを暗号化し、「送信者」に渡されます。 「The Sender's」の秘密鍵だけが「The Sender's」の公開鍵で暗号化された暗号文を解読できるので、真ん中の誰かは本質的に役に立たない文字化けしたテキストを持っています。

場合によっては、「送信者」は、異なるキーのセットで自分のCSRに署名するか、同じキーのセットで自己署名することにより、自分の認証局を生成できます。この場合、「送信者」の公開鍵は、信頼を得るために安全なチャネルを通じて両方の当事者に知られている必要があります。ソフトウェアでは、信頼できるサードパーティとして使用できる証明書を成果物に含めることができます。

* trustedは、認証局がCRL（証明書失効リスト）を管理し、すべての関係者がリストを監視して、発行された証明書が侵害されていないことを確認する場合にのみ有効です。認証局が侵害され、秘密鍵が漏洩するケースが存在し、その場合、侵害を行うエージェントは秘密鍵を使用して、「送信者」を模倣する信頼できる証明書を生成できます。その場合、MITMは可能であり、MITMは「The Sender」からデータを受信し、「The Sender」のような有効な証明書で復号化、保存、暗号化してから、それを「The Receiver」に渡します。

2
Harry Chilinguerian

作成したCA証明書のコピーから暗号化された秘密鍵を取り出します（他の人に渡す場合）。秘密鍵は、別の公開鍵を含む証明書に署名するために使用する場合を除いて、存在する必要はありません。

公開鍵を送信する場合は、代わりに、関連するCA秘密鍵を使用して署名された証明書全体（秘密鍵を除く）を送信します。内部の公開キーの有効性を確認するには、証明書のハッシュを（CAの秘密キーを使用して暗号化された）暗号化されたハッシュと照合する必要があります。これは、CAの公開鍵を使用して復号化されます。復号化が成功し、ハッシュが証明書のハッシュと一致する場合、証明書内の情報を信頼できます。

暗号化以外にも、攻撃者が以前に保存した暗号化データを送信するリプレイ攻撃などがあります。 TLSは、平均的な人が考えるよりもはるかに多くをカバーしており、同様のシステムを実装することは絶対にお勧めできません。プライベートにするつもりであれば、可能な限りTLSを使用してください。

0
Jonathan Gray