前のトピック「パスワードは20世紀です。将来、個人データの新しい認証方法と保存方法が必要になります」で、ネットワークでパスワードを使用する際の既存の問題とEDSを使用して認証を作成する方法について説明しました。 このトピックでは、EDSを使用してインターネット上で詳細な認証スキームを提供します。これにより、詐欺師やサイバー犯罪者から高レベルのセキュリティが提供されます。
ここで紹介するスキームは、前の記事で詳しく説明したインターネットリソースに対して単一の認証センターを使用する認証モデルのフレームワーク内でも検討されます。 したがって、プロセスをよりよく理解するために、前の記事から少し引用します。
セキュリティの観点から、これまでの最高の保護は、3回の試行からPINコードで保護されたUSBトークンと、（オプションで）統合された指紋スキャナーによって提供されます。 承認プロセスでは、個人のデジタル署名で署名されたバイオメトリック指紋のデジタルコピーの単一の承認センターへの転送を使用できます（秘密キーを使用した暗号変換）。 同時に、USBトークンと使用されたキーからバイオメトリック指紋のデジタルコピーを抽出することはできません。また、2番目の公開キーペアを持っている人だけが送信されたデータを解読できます。 各認証中の傍受から保護するために、送信されるデータは一意である必要があります。たとえば、認証ごとに、バイオメトリックフィンガープリントのコピーとともに、認証成功のランダム文字列とカウンタ値を暗号化します。 毎日の公開キーと秘密キーの個人セットが作成され、キーの使用期間全体（たとえば、10-20年）に事前に保存され、トークンが認証中に日付をサーバーと比較し、現在の日付に必要なキーでデータに署名するとさらに良い。 同時に、公開キーも確実に保護し、承認サーバー上にのみ配置する必要があります（たとえば、受信したデータの正確性をチェックするが、インターネットへの直接アクセスがない単一の承認センターの内部サーバー内）。各USBトークンには固有の番号が必要です。 また、公開キーと秘密キーのペアを生成する場合、USBトークン番号はこれらのキーと一緒に保存する必要があります。 これにより、認可サーバーは、認可プロセス中にトークン番号で必要な公開鍵を照合できます。
そのため、承認プロセスの発生方法を検討します。
1）ユーザーは、バイオメトリック指紋のデジタルコピー+認証カウンターの値+ USBトークンを使用したランダムな文字列を暗号化します。 一意のUSBトークン番号が受信データに追加され、認証のためにWebサーバーに送信されます。
2）Webサーバーはユーザーのメッセージを受信し、その一意のトークン番号を追加します。 受信したデータは、単一の認証センターに送信されます。
3）認証センターのサーバーは、ユーザーの公開鍵を使用して受信したメッセージを復号化します。 復号化の結果、サーバーがユーザーの生体認証指紋の正しいデジタルコピーを受信した場合、メッセージは認証キーで暗号化されます。 結果が成功した場合、ランダムなユーザー文字列も現在の認証シーケンス番号と一緒にサーバーに保存されます。
4）承認サーバーは、Webサーバーの公開キーを使用して肯定的な判定+ランダムなユーザー行を暗号化し、応答メッセージを送り返します。 判定が否定的な場合、サーバーは新しいランダム文字列を使用して応答メッセージを暗号化します。
5）Webサーバーは、受信したメッセージをトークンで復号化し、承認のための肯定的または否定的なコマンドを受け取ります。
6）認証に成功すると、Webサーバーはランダムな文字列を平文でユーザーに返します。受信した文字列は送信された文字列で検証され、USBトークンが一致すると、認証成功のカウンターが1単位増加します。
どのような状況でもUSBトークン内の成功した認証のカウンターの値は、サーバー上よりも大きくなる可能性があることに注意してください。 また、値が小さい場合、サーバーは指定された認証番号を使用して、保存された文字列でユーザーのランダムな文字列を検証する必要があります。 これにより、犯罪者の特定が容易になります。 これらの行が一致する場合、前の承認からのインターセプトされたトラフィックの送信で改ざんが試行されます。つまり、サーバーはアクセスを拒否し、これについてセキュリティ専門家に即座に通知し、侵入者のIPアドレスを監視対象のリストに追加する必要があります。 これらの行が異なる場合、最後の認証中にWebサーバーはランダム文字列をユーザーに返さなかったため、サーバーはアクセスを許可し、有罪Webサーバーのカルマを減らし、ランダムなユーザー文字列に特別なコードを追加して、成功した認証のカウンターを調整します。
利点：
1）公開鍵と秘密鍵のペアは、トークンが日付に応じて異なる鍵を使用できる場合、少なくとも毎日変更できます。
2）認証ごとに、生体認証データとともに、成功した認証のカウンターの読み取りとランダムな文字列が暗号化されている場合、トラフィックを傍受することは無意味です。 カウンターとランダムな文字列を確認することで、改ざんが判別されます。
3）公開キーペアが認証センター内にあり、確実に保護されている場合、認証プロセスを偽のサーバーにリダイレクトしようとしても機能しません。 偽のサーバーは、Webサーバーの公開キーで暗号化された判定を返すことができません。
4）サイトで使用されている認証スクリプトの脆弱性が認証プロセスを危険にさらすことはありません。
5）Webサーバーをハッキングしても、ユーザーのバイオメトリック指紋およびデジタル署名を受信することはできません。 実際、このスキームでは、各承認参加者は自分のセキュリティにのみ関心があり、別の参加者のセキュリティについては責任を負いません。
6）成功した認証のカウントが一致しない場合、サーバーは認証が侵害されているかどうかを正確に判断できます。または、最後の認証中にWebサーバーがランダム文字列をユーザーに返しませんでした。
7）実際、この場合、すべての機密データは暗号化された形式で送信されるため、安全なSSL接続は必要ありません。 それでも、セキュアなSSLプロトコルを使用すると、セキュリティの程度がさらに向上します。
短所：
1）各参加者の信頼性を確認するために必要なデータの2倍の暗号化と復号化を使用します。
2）キーの容量は、認証プロセス中にサーバーに過負荷をかけないように、できるだけ小さくする必要があります。
3）Webサーバーで使用されるトークンは、高速データ復号化を提供する必要があります。 特に、サイトのトラフィックレベルが高い場合は、USBトークンを使用する代わりに、高性能の拡張カードまたは信頼できるソフトウェアトークンを提供する必要があります（仮想サーバー上にあるサイトの場合）。
4）承認センターは、DDoS攻撃に対して「沈めない」高性能クラスターから構築する必要があります。
テキストの改訂および改訂2015年3月11日