- クライアントとサーバーが信頼できる（ローカル）ネットワークで通信する場合。
- クライアントとサーバーは、グローバルで安全でないネットワークを介して通信します。
違いは、クライアントとサーバーがローカルネットワークを介して対話するとき、システムを設計するときに、外部からの侵入の脅威が排除されることです（あなたの隣に座って、トラフィックをコンピューターにリダイレクトするハッカーの脅威が最小限に抑えられました）。 さらに、ローカルネットワーク上のクライアントとサーバーの相互作用は、クライアントとサーバーがインターネットにアクセスできないか、望ましくないことを意味します。つまり、証明機関へのアクセスも存在しないため、公開キーを使用した認証を完全に使用することはできません。
ローカルネットワークとは異なり、攻撃を行うために攻撃者は何らかの方法でそれに接続する必要があります（そして、そのようなシステムが優れたシステム管理者によって管理されている場合、これは非常に問題です）、クライアントとサーバーが安全でないネットワークを介してやり取りするとき、トラフィックをリッスンします。 したがって、ここでは認証アルゴリズムが必要です。これは、ローカルネットワークでの相互作用のアルゴリズムとは異なります。
さらに、認証システムにいくつかの追加の制限が課されました。
一般に、制限は次のように説明できます。
- クライアントとサーバー間のトラフィックの強力な暗号化が必要です。
- クライアントは、ユーザーにパスワードを要求することなく、コンピューターにインストールした直後に動作するはずです。 つまり、従業員は、自分のコンピューターにインストールされているそのようなクライアントの存在について知る必要はありません。 クライアントのすべての設定はサーバーから取得され、クライアントは暗号化されたトラフィックを送信するために単純に身元を確認できなければなりません。
- 好奇心employees盛な従業員がクライアントとその秘密キーにアクセスできる場合、できることは、このキーが作成された特定の期間だけメッセージを復号化することです。 つまり、前方秘匿性（将来のメッセージの秘匿性）と後方秘匿性（過去のメッセージの秘匿性）が部分的に保証されます。
- 従業員が必要なくローカルコンピューターにクライアントのインストールを開始する場合、これは重要ではありません。 クライアントには、サーバーを中断したり、暗号化されたデータにアクセスしたりする機能はありません。 さらに、サーバーはそのようなクライアントを禁止できます。
これらの制限に基づいて、次のプロトコルとアルゴリズムが選択されました。
- ローカルネットワークでの認証には、HMACを使用した共有秘密キーに基づく認証プロトコルが使用され、共有秘密キーの生成にはDiffie-Hellmanアルゴリズムが使用されます（Habrには多くの詳細な記事がすでに存在するため、ここではアルゴリズムについては説明しません彼について）。
- 安全でないネットワーク内のクライアントとサーバー間の認証では、RSAアルゴリズムを使用した公開キー暗号化を使用した認証プロトコルを使用することになっています（WikipediaでRSAを参照できます）。
HMACを使用した共有秘密キー認証
このタイプの認証は、クライアントとサーバーが2人だけが知っている秘密鍵を持っていることを意味します。 Diffie-Hellmanアルゴリズムを使用してこのようなキーを生成しました。
HMAC（ハッシュベースのメッセージ認証コード、メッセージ識別ハッシュコードの略）。 つまり、暗号化ハッシュ関数を秘密鍵と組み合わせて使用するメカニズムです。
プロトコル認証シーケンスは次のとおりです。
N、N-クライアントとサーバーが個別にランダムに選択した128ビットの数値。
K、C-クライアントとサーバーの識別子（IPアドレスなど）。
HMAC-メッセージ識別用のハッシュコード。
Ksは共有秘密キーです。
最初のステップでは、クライアントはランダムに選択した番号をサーバーに送信し、クライアントの共通キーで暗号化して、実際にサーバーであり、それを装った攻撃者ではないことを確認します（後で説明しますが、この例では、この番号は暗号化されませんが、他のデータと一緒にハッシュに変換され、プロセスの本質は変わりません）。
2番目のステップでは、サーバーは乱数Nをクライアントに送信するとともに、HMAC関数を使用して値N、N、、、およびsをハッシュすることによって形成されたHMACハッシュを送信します。 なぜなら クライアントはNk、Nc、K、C、Ksを知っているため、独自のHMACハッシュを生成し、サーバーから受信したハッシュと比較できます。 ハッシュが一致する場合、サーバーが主張するとおりのサーバーになります。 同時に、攻撃者はHMACハッシュ（N、N、、、s）を生成できませんでした。 少なくとも彼は秘密鍵Ksを知らないはずです。
3番目のステップでは、クライアントの「アイデンティティ」を確認する番でした。 このプロセスは、2番目のステップと同様に実行されます。
公開キー暗号化を使用した認証
このタイプの認証は、クライアントとサーバーの両方に証明書がある場合に使用されます。 このタイプの認証の一連の手順を以下に示します。
N、N-クライアントとサーバーが個別にランダムに選択した128ビットの数値。
K、C-クライアントとサーバーの識別子（IPアドレスなど）。
Ksは共有秘密キーです。
Ec、Ek-証明書の形式で送信される、それぞれサーバーとクライアントの公開鍵。
最初に、クライアントは証明機関にサーバー（Ec）の公開キーを要求します。 次に、ランダムに選択された番号とその識別子を暗号化します（ステップ3）。 このメッセージを解読できるのは実サーバーのみです。 したがって、このメッセージを受信したサーバーは、メッセージを復号化し、クライアントの公開キー（認証局から受信）でランダムなクライアント番号、ランダムな番号、共有秘密キーを暗号化します（ステップ6）。 さらに、クライアントが本人である場合、サーバーメッセージを解読し、共有秘密キーを見つけ、サーバーメッセージを解読できたことを確認するために、番号Ncをランダムにサーバーに送信し、共有秘密キーで暗号化します（ステップ7）。
認証システムを設計する場合、標準プロトコルとは対照的に、クライアントは独自の証明書を持たず、証明書を使用して取得したサーバーの公開鍵で暗号化して公開鍵をサーバーに送信することが想定されます。 これにより、クライアントごとに複数の証明書を取得する必要がなくなります。これにより、このクライアントのユーザーは、システムの制限と矛盾する設定に気を取られる必要があります。
ランダムな期間（Tk）の後に共有秘密キー（Ks）を変更することにより、追加の保護が提供されます。 詳細については、「攻撃に対する保護のためのシステム分析」セクションを参照してください。
認証システムアルゴリズム
さらに、接続を確立するためのすべてのステップは、フローチャートを使用して説明されています。
クライアント側の認証システムのアルゴリズムは次のとおりです。
サーバー側から：
認証に成功すると、暗号化されたトラフィックを送信できます。 トラフィックは、Ks秘密鍵を使用するAESアルゴリズムを使用して暗号化されることが想定されています。 なぜAESなのか？ これはこれまでで最高の対称暗号化アルゴリズムであるためです。 インターネットで詳細を知ることができます。
攻撃に対する保護のためのシステム分析
次に、発生する可能性のあるさまざまな状況をシミュレートし、それらに対するシステムの抵抗を分析しました。
MITM攻撃に対するDiffie-Hellmanアルゴリズムの脆弱性
これはおそらくこのアルゴリズムの主な欠点です。 攻撃者がサーバーをクライアントに偽装し、クライアントをサーバーに偽装すると仮定すると（たとえば、ARPスプーフィングを使用）、すべてのトラフィックが攻撃者を通過します。
ネットワークアーキテクチャと企業の情報セキュリティルールを慎重に検討することによってのみ、この種の攻撃から身を守ることができます。 たとえば、ARPスプーフィングなどの攻撃を検出するソフトウェアをインストールできます。
クライアントを不必要にサーバーに接続する
誰かが私たちのアナライザーのクライアントを受け取ったらどうなりますか？
一方で、 サーバーは重要な情報をクライアントに送信せず（コマンドのみ）、クライアントはサーバーの重要なデータにアクセスできず、トラフィックを送信するだけです。これは深刻な不便を引き起こしません。
不便を招く唯一のことは、サーバーデータベースが不用意に増加する可能性があることですが、データベースから不要なクライアントを切断することはサーバーと管理者の関心事です（データベースを満たすのに多くの時間がかかるため）。
一方、クライアントは、共有キーを確立するための多くのリクエストを送信し、受信したキーを削除して秘密キーの新しいリクエストを送信することにより、DOS攻撃を開始できます。
ここでは、単にそのようなクライアントをしばらくの間単に禁止することができます。 また、クライアントは秘密鍵の更新を開始できません。 共有秘密キーの期間を知っているのは、サーバー自体だけです。 そして、彼だけが共有秘密鍵を更新するリクエストを送信できます。
クライアントの秘密鍵とそのクライアントのトラフィックを受信する攻撃者
この状況では、攻撃者が秘密鍵とクライアントトラフィックを取得したと想定されます。
m-秘密鍵で暗号化されたネットワークパケット（メッセージ）。
前述したように、エージェントとトラステッドゾーンのサーバー間の共有秘密鍵の確立は、Diffie-Hellmanアルゴリズムを使用して行われます。 標準のDiffie-Hellmanとは異なり、私の場合、ランダムな期間の後に共有キー（Ks）を変更することになっています。これは、アプリケーションのサーバー側の設定でTminとTmaxが設定されている時間間隔（Tmin、Tmax）にあります。
この方法では、前方秘匿性（将来のメッセージの機密性）と後方秘匿性（過去のメッセージの機密性）を部分的に保護できます。 つまり、企業内の侵入者が以前にトラフィックを記録しており、同時に現在の共有秘密鍵Ks（i）を取得できたと仮定すると、その間隔で送信されたトラフィック（Tmin（i）、Tmax（ i））ここで、iは生成された共有秘密鍵の現在の番号です。
おわりに
この記事では、よく知られた認証プロトコルに基づいた認証システムの設計について説明しました。 HMACを使用した共有シークレットと公開キー暗号化を使用した認証プロトコルに基づく認証プロトコルの簡単な説明が提供されました。
最後に、設計されたシステムのコンピューター攻撃に対する感受性の簡単な分析が行われました。
PS私はコメント、訂正、および合理的な批判に喜んでいるでしょう。