28

ユーザーがユーザー名/パスワード認証に加えて、クライアント証明書を使用して登録し、その後認証できるシステムを設計しています。

クライアント証明書は、構成された認証局のリストによって発行された有効な証明書である必要があり、提示されたときにチェック (検証) されます。

登録フェーズでは、クライアント証明書で認証するユーザーを内部の「ユーザー」にマップできるように、クライアント証明書の一部をユーザー リポジトリ (DB、LDAP など) に保存する必要があります。

かなり明白な選択肢の 1 つは、証明書のフィンガープリントを使用することです。ただし、衝突が発生する可能性があるため (発生する可能性は低くても)、フィンガープリント自体では十分ではないため、証明書から追加情報を保存する必要があります。この SO の質問は、この点でも有益です。

RFC 2459は、証明書のシリアル番号が特定の CA 内で一意でなければならないことを定義しています (4.1.2.2)。

これらすべてを組み合わせて、登録ユーザーごとに証明書のシリアル番号と証明書の発行者を保存することを考えています。クライアント証明書が検証されて有効であることを考えると、これは各クライアント証明書を一意に識別する必要があります。そうすれば、クライアント証明書が更新された場合でも、それは引き続き有効です (シリアル番号は同じままで、発行者も同じです)。

私は何か見落としてますか？

4

3 に答える 3

22

いくつかの解決策があります：

  1. 指紋の保存。 はい、その通りです。衝突は理論的には可能ですが、確率は非常に低く、衝突が起こらないと考えることができます。システム内の 2 人のユーザーが誤って同じ証明書フィンガープリントを持つことはありません。ただし、ハッシュ アルゴリズムは時間の経過とともに弱くなっており、攻撃者は、登録された指紋と一致する指紋を持つ証明書を偽造しようとする可能性があります。この攻撃は 2 番目のプリイメージ攻撃と呼ばれ、攻撃者はフィンガープリントに一致するランダム データを偽造しようとするのではなく、最初の検証フェーズ (つまり、PKI のハッキング) を通過できる実際の X.509 証明書を偽造しようとするため、実行するのは非常に困難です。かなり難しい :) しかし、本当に衝突を防ぎたい場合は、2 つの異なるアルゴリズム (例: SHA-1 と SHA-256) を使用して 2 つの指紋を保存できます。

  2. 証明書の発行者とシリアル番号を格納します。はい、一意の証明書識別子として使用できます。あなたが書いたように、標準 ( RFC 5280は RFC 2459 を廃止します) は示し[The serial number] MUST be unique for each certificate issued by a given CA.ていますが、証明書が更新されると、新しい証明書が CA によって発行されるため、シリアル番号が変更されることも意味します。

最後の発言: 証明書の更新を処理したい場合、それは良い考えです。多くのソフトウェア編集者は、証明書を更新する必要があることを忘れています。ただし、証明書のほとんどすべてが変更される可能性があることに注意する必要があります: サブジェクト名 (人々は名前を変更する可能性があり、女性は結婚する可能性があります...)、発行者名 (証明書のサプライヤー会社は変更する可能性があります...)、キーアルゴリズム。 、鍵のサイズ、拡張子... システムでは、証明書の更新プロセスは、おそらく最初のユーザー証明書の登録にかなり近いでしょう。

于 2011-03-13T17:48:47.343 に答える
1

ユーザーを一意に識別する最良の方法は、電子メールアドレスを使用することです。登録プロセスでは、有効な電子メールアドレスが必須である必要があります。次に、証明書のシリアル番号と発行者、または証明書自体のハッシュを電子メールとユーザーIDに関連付けます。次に、証明書の有効期限が切れたり、ユーザーが証明書を変更したりすると、「証明書の更新リンク」が表示され、電子メールアドレスを入力すると、新しい証明書をアップロードするためのリンクが表示されます。その後、古いシリアル/発行者を新しいものと交換できます。

于 2011-05-18T13:08:53.413 に答える