PKI証明書を使用したWeb認証

私はPKIを概念的な観点から合理的によく理解しています-秘密鍵/公開鍵-それらの背後にある数学、証明書に署名するためのハッシュと暗号化の使用、トランザクションやドキュメントのデジタル署名など。 Cライブラリは、通信と認証を保護するために証明書とともに使用されました。また、opensslコマンドラインツールにも非常に精通しています。

ただし、WebベースのPKI対応プロジェクトの経験はほとんどないため、これをよりよく理解するために個人プロジェクトを設計およびコーディングしようとしています。

要求事項

これは銀行のウェブサイトです。すべてのインターネットバンキングユーザーは、いくつかの既知のCA（verisign、Thawte、entrustなど）によって発行された証明書を使用できます。銀行は、ユーザーの証明書を取得する責任を負いません。これらの証明書は、銀行のWebサイトへの認証に使用されます。プラットフォーム/ OSなどはまだ修正されていません。

設計

認証を行うための最良の方法は何だろうと思っていました。

1. Apacheには2方向SSLを有効にする方法があることがわかりました。この場合、Webサイトに移動すると、ユーザーに証明書を自動的に要求すると思います。しかし、証明書が信頼できるCAによって署名されているかどうか、および証明書の件名行のホワイトリストに含まれるかどうかを検証するだけであると思われるため、これで十分かどうかはわかりません。しかし、これは十分ではありません。 bankuseridを証明書に関連付ける必要があるため、銀行の場合。

2. IISには、Active Directoryの各ユーザーの証明書を保存する方法があるようです。これは、いくつかのMSDN記事を読んで理解したことです。IISで2方向SSLをオンにし、ユーザーがWebサイトに移動しようとすると、IISは承認されたCAのリストを使用してブラウザーに要求を送信し、ブラウザーはユーザーが証明書ストアから適切な証明書を選択して送信できるようにしますバックエンドに。IISは2つのことを行うと仮定しています

   • ユーザーが証明書に対応する秘密キーを持っていることを確認します（カバーネゴシエーションにより）
   • ADユーザー証明書マッピングに基づいて、IISはユーザー名をアプリケーションに報告します。

3. 暗号化関数を呼び出すことで明示的に認証を行いますが、Webサーバーに依存することに依存します。

   • 証明書をアップロードするユーザー画面を表示すると、アプリケーションは、ユーザーが証明書に対応する秘密鍵を持っていることを確認します（証明書を使用して文字列に署名するようフロントエンドに要求します）。
   • アプリケーションにはいくつかのデータが保存されているデータベースがあり、各ユーザーを自分のユーザーIDにマッピングできます。これは
   • 各ユーザーIDに対応する証明書全体
   • 各ユーザーIDに対応するCAおよび証明書のシリアル番号。

よく使われる方法はどれだろうと思っていましたか？ベストプラクティスは何ですか？＃3に進む必要がある場合、これを行う最良の方法は何ですか？

スマートフォンアプリでも簡単に機能するものは、追加のボーナスになります。

更新

「認証部分を自分でコーディングする」というステートメントを明確にしましょう。答えの一部は、それが誤解されていることを示しているようです。

これは、私が自分で暗号文を書くという意味ではありません。これは、IISや他のWebサーバーに暗黙的に依存する代わりに、実際に明示的に暗号化ルーチンを呼び出すことを意味します。

私は本当に問題ごとに答えたいと思っていましたが、私はトピックごとにこのトピックをヒットすると思います：

認可/認証

OK、まず最初に。あなたの例では、両方が必要です：

• 認証 -ユーザーが本人であることを証明します。PKIを選択し、秘密鍵の暗示的な証明を認証として使用しました。
• 許可 -ユーザーが許可されていることへのユーザーの接続。これは、ログインと許可されたアカウントへのアクセスの接続ポイントです。アカウントとアカウントアクセス機能への証明書のマッピングは承認です。

認可に関しては、ユーザーのサブジェクトDNを銀行口座に接続するプロセスを把握するという問題があります。トランザクションの重要性を考えると、あなたは間違いなくこのための強力なプロセスを持ちたいです。そして、ここに単一の正しい方法はありません。ポリシーに従ってこれを行う方法を理解するには、銀行、おそらく弁護士に相談する必要があります。

SSL、クライアント/サーバー認証、秘密鍵の証明

SSLプロトコルには常にサーバー認証が含まれており、クライアント側の承認のための追加のオプション設定があります。Apacheは、PKIによるクライアント認証を追加する設定を提供し、信頼できるCAのリストを使用してプロビジョニングできるという点で、あなたは正しいです。PKIを介したクライアント認証を必要とするSSLセッションのセットアップ中に、秘密鍵の証明を取得します。

オプション＃1またはオプション＃2がこれを提供します。ApacheとIISの両方をこのように構成できます。賢明なベストプラクティス、私はどちらかをあなた自身のソリューションをロールオーバーするだろう。＃3は、「独自の暗号を記述しない」ルールに非常に近いです。トランザクションを認証済みのSSLセッションの存在に結び付けることができると仮定すると、独自にロールバックする理由はありません。

また、オプション＃1またはオプション＃2のいずれかで、証明書全体を取得し、そこから証明書の任意の部分にアクセスする方法があります。通常、サブジェクトDNや証明書のシリアル番号は、認証目的でユーザーのIDを決定するために使用されます。

「一般的な使用」という点では、すべての主要なWebサーバーはかなり一般的です。IIS、Apache、Tomcat、およびその他の多くは、クライアント認証SSLで構成できます。そこからの決定は、主に全体的な実装に基づいています。主要なWebサーバーにはすべて、SSLセッションで提供される証明書にアクセスする方法があります。これは、より詳細な検証に必要なものです。

証明書検証アドオン

少なくとも、次のことが必要です。

• SSLセッションをセットアップする
• 証明書をプルします（ほとんどのWebサーバーは証明書の署名と秘密鍵の証明を確認します）
• 証明書の有効期限を確認します（ウェブサーバーで指定されたものではありません）
• この証明書がアクセスできるアカウントの認証チェックを実行します

銀行の利害が大きいため、証明書の失効ステータスを確認することもできます。ユーザーの秘密キーが紛失または盗難にあった場合、証明書を失効させる必要があります。

IISには、OCSPまたはCRL検証用のフックがある場合があります。これは、より包括的な（手で保持する）タイプのシステムになる傾向がありますが、頭の外では覚えていません。また、マイクロソフト製品を使用することを強制するかどうかも覚えていません。Apacheの場合、ほぼ確実にOCSP / CRLチェックをコーディングまたは追加する必要があります。SSLセッションの確立中にフックがあると思います-通常、このチェックはSSLセッションのセットアップ時に1回実行されます。

認可

＃1対＃2-IISには、SSLセッションで提供される証明書をADリポジトリに結び付ける機能が組み込まれています。これは、Microsoftがより多くの製品を簡単に購入して使用できるようにするためにさらに努力するケースの1つです。:) IISがADとどのように結び付いているかには微妙な違いがありますが、それはこの質問の範囲を超えており、すぐに思い出すこともできません。私はIISとADでかなりおかしなことをしてきましたが、私の一般的な考えは、ADリポジトリから証明書に基づいてユーザー名を取得するのと同じくらい簡単なことをしている間、おそらく大丈夫だと思います。それは、データストレージ、奇妙なADルックアップ、およびPKIで特にクレイジーな（しかし正当な）ことのより複雑な問題に陥ったときです。

IISを使用する場合でも、AD構造に何かを追加するか、ユーザー名を銀行口座に関連付ける必要があります。通常、銀行では、ユーザーは複数のアカウントを持っています。また、2人のユーザーが共同アカウントを持つことができるため、これは多対多の関係です。

＃1-はい、独自のルックアップを書く必要があります。次のコードを作成する必要があります。-証明書をユーザーに、ユーザーをユーザーの銀行口座に接続するデータベースまたはLDAP階層。証明書の保証された一意の部分は、シリアル番号+発行者DNです。多くの場合、サブジェクトDNは機能しますが、すべてのPKIシステムで保証されるわけではありません。

これは通常、Apacheでのハイエンド認証にPKIを使用する開発者が行う方法です。これらのシステムの多くで働いてきたので、簡単に認証を再利用するケースにまだ出会っていないので、それが大きなマイナスになることは決してありません-ロール/特権はどちらかと言えば特別なものを持たなければなりません決して簡単ではありません。

これは、＃1と＃3の組み合わせのように聞こえます-私の強力なアドバイスは-SSLセッションの生成に使用するアプリケーション/ Webサーバーのネイティブ機能を使用することです。これにより、証明書クエリを使用したブラウザからサーバーへのセットアップが、標準的なベストプラクティスの方法で行われます。そこから、Apacheを使用して、独自の承認システムをロールする必要があります。IISは、これがどのように機能するかについてのマイクロソフトのアイデアを提供します。

既知の落とし穴

一連のブラウザーテストを実行します。毎年、ブラウザからブラウザへ、SSLセッション処理に関する落とし穴があります。SSLセッションを一連のWebページリクエストに正しくチェーンし、ログアウトが正しく処理されるようにすることが最大の懸念事項です。そして、サーバーとブラウザーソフトウェアの両方に多くのことが関係しています。SSLは十分に安定しているため、動作する場合は通常動作しますが、IEと他のすべての人々の問題が発生する場合があります。

特に、前回これを行ったとき、強制コーディングとセッションタイムアウトの問題は大したことでした。

スマートフォン

良い。幸運。私が言えることはすべてです。私はモバイルアプリの開発者ではありませんが、これまでの私の印象では、平均的なスマートフォンでは、PKI証明書の処理は同等または存在しません。

私は間違っていると証明されるのが大好きです。

個人証明書は、証明書の定期的な更新（その背後には非常に堅牢なプロセスがあります）に有効であり、顧客が好む「パスワードなし」認証として実装できます。

しかし、失敗するのは

• 証明書あたりのコスト
• 最新のブラウザとの互換性
• エンドユーザーが証明書を抽出し、秘密鍵を安全に保存しない

sha-2署名付きの最新の個人証明書は、iPadのSafariや多くの最新のブラウザーでは機能しないことに注意してください。これは、認証局組織がそうであると考えたように、個人証明書が実際に離陸したことがないためです。30,000個の証明書の発行（私たちが行うこと）は、一部のハードウェアトークンタイプとほぼ同じ証明書あたりのコストです。

顧客が自分の証明書を見つけられるようにする戦略は、実際には有効ではありません。現在、個人証明書のサプライヤーを見つけるのは難しく、かなり高価です。ビジネスケースが機能することを確認する必要があります。

さて、ここで多くのことが起こっています。まず、クライアント証明書認証はエンドポイントでサポートされていない場合は役に立ちません。そのため、スマートフォンアプリのクライアント認証の基本について、Intrepidusから素晴らしい投稿があります。

次に、独自の認証ルーチンをコーディングしないことを強くお勧めします。これを処理する多くの優れた、吟味されたライブラリがあります。認証用の成熟したライブラリを使用して実行することにより、機能とセキュリティのバグを節約できます。検証済みの成熟したライブラリを使用することは、間違いなくベストプラクティスです。

次のベストプラクティスは、client：certificateマッピングの処理にディレクトリを使用することです。したがって、ADまたはLDAPを確認します。既に述べたように、WindowsとIISはこれを非常にシームレスにします。IIS.netには、IISでの証明書マッピングの構成に関する適切な要約があります。

Apacheを使用する場合、これはすぐに使用できるほど簡単ではありません。mod_authz_ldapがクライアント証明書のマッピングを行うように見えますが、私は個人的にそれを使用していません。

そのため、このようなことを実際に実装するためのロジスティクスに進みます。ユーザーの証明書に署名しているわけではないため、ユーザーが証明書を送信し、アプリでディレクトリに公開するための強固なプロセスが必要です。これには、パスワード認証とテキストメッセージ、または信頼できる番号への呼び出しという2つの要素が必要です。ユーザーにメールを送信して、アカウントに証明書が追加されたことを知らせます。ユーザーがアプリのアカウント管理ページからユーザー証明書マッピングを削除できるようにします。

ツーファクターを回避するために、信頼できるデバイスにCookieを設定するためにGoogleとFacebookが行うことを検討します。証明書のみの認証を許可する前に、2要素で新しいデバイスを認証します。

失効したユーザー証明書の処理方法についても考えます。これは、外部証明書失効リスト（CRL）をチェックすることを意味します。クライアント証明書にCRL配布ポイントが定義されていない場合はどうしますか？ユーザーがログインするたびに、またはジョブの一部としてスケジュールに基づいてCRLを確認しますか？

要するに、ユーザーの証明書が侵害されていないことをどのように信頼できるか、そして証明書XをユーザーYにマップできることをどのように信頼できるかということです。