スマートカードのセキュリティ、どのように証明書を偽物ではないと認証しますか？

Question

私は、スマートカードがWebサイトにアクセスするために使用されたことを確認するために、clientCertificateを読み取るASP.netサイトを開発しようとしています（ユーザー名/パスワードのログインをやめようとしています）。

私は私の心を持っているプロセスは、次のとおりです。

1. ユーザーアカウントを登録し、C＃レコードのユーザーのclientCertificate（パブリック）。
2. 次に、同じclientCertificateで次回ログインすることができ、ハッシュが有効であれば認証されたユーザーになります。
3. 私はのコードを使用して証明書の信頼性を保証します。ブラウザは秘密鍵を処理し、証明書が偽造されていないことを確認する必要があります。
4. Subject +証明書の組み合わせに基づいて、C＃は役割+アクセス権を割り当てます。

以下のコードは、証明書の正当性を証明するために使用できますか？

X509Certificate x509Cert = new X509Certificate(Request.ClientCertificate.Certificate); 
SHA1 sha = new SHA1CryptoServiceProvider(); 
byte[] hashvalue = sha.ComputeHash(Request.ClientCertificate.Certificate); 
byte[] x509Hash = x509Cert.GetCertHash(); 
// compare x509Hash WITH hashvalue to ensure they are a match. 
// If not, possibly faked certificate, not a real smartcard??? 

スマートカード認証プロセスはどのように動作するのですか？

Answer 1

クライアント証明書でユーザーを認証する必要がある場合は、IISでこれを行う必要があります。あなたは、あなたのアプリケーションにすべてのコードを追加する必要はありません。

Specify Whether to Use Client Certificates (IIS 7)

データベース・アカウントでクライアント証明書をリンクしたり、追加の検証手順を実行する必要がない限り。しかし、依然としてクライアント証明書の認証では、私はIISの設定に固執します。

更新：

X509Certificate2 x509Cert2 = new X509Certificate2(Page.Request.ClientCertificate.Certificate); 

をそしてなど、そのプロパティにアクセスします： 場合はあなたが行うことができ、クライアント証明書を操作する必要が

x509Cert2.Subject 

、検証ピースを残しますIISまで。クライアントが不正な証明書を提示した場合、IISがそれを拒否するため、asp.netコードは実行されません。

Answer 2

このスレッドをご覧ください。あなたのコードで真正性を明示的に検証する必要はありません。 IISはあなたのためにそれを行います。

Does IIS do the SSL certificate check or do I have to verify it?

も、IIS（CRLが大きい場合ただし、これは多くの場合、無効になっている）失効リストをチェックしよう。 OCSPレスポンダは、CRLが非常に大きいか、またはそれが高いとチェックする際の待ち時間がhttp://www.axway.com/products-solutions/email-identity-security/identity-security/va-suiteである場合の検証に使用する必要があります。

Answer 3

クライアント証明書認証はSSL/TLSハンドシェイク中に実行されます。

これは通常、公開鍵インフラストラクチャを使用して行われます。これにより、クライアント証明書を検証するために使用する信頼できるCA証明書のリスト（サーバーのクライアントと同じ方法で）がサーバーに格納されます。クライアントはTLSのhandhsakeにCertificate Verify messageが保証し、その証明書の秘密鍵（（SSL/TLSスタックはこれを確認しますがあり

• ：証明書は、この段階の後に、あなたのアプリケーションに提示されたら、あなたはそれを知っているだろう）あなたのために何かを実装するために、必要はありません。
• あなたは、信頼できるCAに対する検証がにユーザーを必要とし、あなたの信頼できるCA

に対してそれを検証してしまうため、クライアントは、証明書に記述のアイデンティティを持っていますあらかじめそのCAに登録されていなければなりません。信頼できるCAによって発行されていません。 （証明書の件名をローカルユーザIDにマッピングすることは別の問題です。たとえば、必要に応じて最初の接続時にこれを行うことができます。たとえば、Subject DNをアプリケーションの別の種類のユーザIDにマップするデータベースやディレクトリサービスが必要です。

ユーザーはアカウントを登録し、C＃はユーザーのclientCertificate （public）を記録します。ユーザーは同じ clientCertificateを使って次回ログインすることができ、ハッシュ が有効な場合、認証されたユーザーになります。

あなたがどの証明書が提示され、必ずしも一般的に信頼できるCAに頼ることなく、初期登録のためにそれを使用することができるようにしたいようですね

これは原則として可能ですが、私はこれをJavaのPKIの代替案として検討しました。

これを行うには、SSL/TLSハンドシェイクに関するすべての証明書を許可し、後でその証明書自体を検証する必要があります。 （は何らかの形式の検証を使用する必要があります）。これは、クライアントが提示した公開鍵証明書の秘密鍵をクライアントが保持していることを保証します。あなたが（明示的Certificate Request TLSメッセージに証明機関の空のリストを送信することにより、あなたはすべての証明書を受け入れるつもりだという事実を宣伝できるようにする必要があり

• ：これを行う

  は、2つのステップが必要ですTLS 1.1で許可されている）。

• 証明書を信頼するようにSSL/TLSスタックを構成します（このときも、アプリケーション内に独自の検証システムを実装することを忘れないでください）。 .NETで

、remote certificate validation callbackを使用して第二の点に対処することが可能なはずである一方で、私は（これもthis questionに頼まれた）最初のポイントを変更する方法を発見したことがありません。

JSSEのX509TrustManagerでは、両方のポイントに対処することができます。