22

bouncycastle wiki ページを通じて、X.509 ルート証明書と認証要求を作成する方法を理解できましたが、その後の概念とプログラミングの進め方がよくわかりません。

当事者 A が証明書要求を行い、CA からクライアント証明書を取得するとします。一部の当事者 B は、A の証明書をどのように検証できますか? Aさんにはどのような証明書が必要ですか。ルート証明書？「通常の」クライアント証明書?

また、A が自分の証明書を DER または PEM 形式で B に正常に送信したと仮定した場合、プログラミング レベルでの検証はどのように機能するのでしょうか?

どんな助けでも大歓迎です。

よろしく、 ロブ

4

2 に答える 2

38

プログラマーの観点から見ると、X.509 証明書を検証するにはいくつかのことが必要です。

  1. 「トラスト アンカー」のセット — 信頼する CA のルート証明書。攻撃者が CA 証明書を自分の偽物に置き換えないように、これらは改ざんから保護する必要があります。これらの証明書の公開鍵は、他の証明書のデジタル署名を検証するために使用されます。
  2. 中間証明書のコレクション。アプリケーションはこれらのコレクションを保持する場合がありますが、証明書を使用する SSL や S/MIME などのほとんどのプロトコルには、追加の証明書を提供する標準的な方法があります。これらを保管するのに特別な注意は必要ありません。それらの整合性は、ルート CA の署名によって保護されています。
  3. 失効情報。証明書が CA によって発行された場合でも、秘密鍵が開示されたか、エンド エンティティが ID を変更したために、時期尚早に取り消された可能性があります。(たとえば、ある人が転職し、以前の会社名が記載された証明書が取り消された場合。) CRL または OCSP などの Web サービスを使用して、証明書のステータスに関する更新を取得できます。

これらの入力が利用可能になると、組み込みの PKIX サポートを使用して、証明書パスを構築および検証できます。

/* Givens. */
InputStream trustStoreInput = ...
char[] password = ...
List<X509Certificate> chain = ...
Collection<X509CRL> crls = ...

/* Construct a valid path. */
KeyStore anchors = KeyStore.getInstance(KeyStore.getDefaultType());
anchors.load(trustStoreInput, password);
X509CertSelector target = new X509CertSelector();
target.setCertificate(chain.get(0));
PKIXBuilderParameters params = new PKIXBuilderParameters(anchors, target);
CertStoreParameters intermediates = new CollectionCertStoreParameters(chain)
params.addCertStore(CertStore.getInstance("Collection", intermediates));
CertStoreParameters revoked = new CollectionCertStoreParameters(crls);
params.addCertStore(CertStore.getInstance("Collection", revoked));
CertPathBuilder builder = CertPathBuilder.getInstance("PKIX");
/* 
 * If build() returns successfully, the certificate is valid. More details 
 * about the valid path can be obtained through the PKIXBuilderResult.
 * If no valid path can be found, a CertPathBuilderException is thrown.
 */
PKIXBuilderResult r = (PKIXBuilderResult) builder.build(params);

注意すべき重要なことは、パスが見つからない場合、その理由について多くの情報が得られないということです。これはイライラするかもしれませんが、設計上そうなっています。一般に、多くの潜在的なパスがあります。それらがすべて異なる理由で失敗した場合、パス ビルダーはどのように理由として報告するかを決定しますか?

于 2010-03-16T21:36:45.203 に答える
9

OK、CA の背後にある考え方は次のとおりです。

  • CA は誰もが信頼する人物です。この目的のために、信頼できる CA の選択をブラウザ/電子メール クライアント/モバイルでも利用できます。あなたの場合、公開ルート キー (証明書) がアプリケーションに含まれている必要があります。
  • ユーザーは、公開鍵を使用した PEM 形式の証明書の要求を CA に送信します。CA は、料金を請求したり、強化された検証 (グリーン) 証明書の場合はバックグラウンド チェックなど、エンド ユーザーの検証のいくつかの形式 (意図的にあいまいなままにしておきます) を行います。
  • CA がユーザーの要求が有効であると判断しない場合、CA は何らかの方法でこれを伝えます。
  • その場合、公開鍵に署名し、この情報を含む証明書を作成します。ここで、cert-req を処理して X.509 証明書に変換します。
  • 他のユーザーは、架空のユーザーに出くわし、信頼できるかどうかを知りたがっています。そのため、彼らは証明書を見て、信頼リストに登録されている誰かによってデジタル署名されていることを発見しました。したがって、彼らがルート CA を信頼し、ルート CA だけが (秘密鍵を介して) このユーザーの公開鍵に署名でき、CA がユーザーを信頼しているという事実から、新しいユーザーは mr fictitious を信頼できると推測されます。

プログラム レベルでは、X.509 証明書を読み取り、CA が誰であるかを判断することで、これを実装します。その CA のフィンガープリントがあれば、それをデータベースで見つけて、署名を検証します。一致する場合は、信頼のチェーンがあります。

これが機能するのは、既に述べたように、デジタル署名を作成できるのは CA だけであり、誰でも検証できるからです。これは、暗号化の概念の正反対です。あなたがすることは、署名したいデータを「秘密鍵で暗号化」し、「公開鍵で復号化」が取得したデータと等しいことを確認することです。

于 2010-03-16T20:45:48.380 に答える