Network-security-application-layer
ネットワークセキュリティ-アプリケーション層
現在、クライアントサーバーアプリケーションを介してさまざまなビジネスサービスがオンラインで提供されています。 最も一般的なフォームは、Webアプリケーションと電子メールです。 両方のアプリケーションで、クライアントは指定されたサーバーと通信し、サービスを取得します。
サーバーアプリケーションからサービスを使用している間、クライアントとサーバーは、基盤となるイントラネットまたはインターネット上で多くの情報を交換します。 これらの情報トランザクションはさまざまな攻撃に対して脆弱であるという事実を認識しています。
ネットワークセキュリティでは、データがネットワーク上で転送されている間、攻撃からデータを保護する必要があります。 この目標を達成するために、多くのリアルタイムセキュリティプロトコルが設計されています。 そのようなプロトコルは、少なくとも以下の主要な目的を提供する必要があります-
- 当事者は相互に交渉して、相互に認証することができます。
- ネットワークで情報を交換する前に、秘密セッションキーを確立します。
- 暗号化された形式で情報を交換します。
興味深いことに、これらのプロトコルはネットワークモデルのさまざまな層で機能します。 たとえば、S/MIMEプロトコルはアプリケーション層で機能し、SSLプロトコルはトランスポート層で機能するように開発され、IPsecプロトコルはネットワーク層で機能します。
この章では、電子メール通信および関連するセキュリティプロトコルのセキュリティを実現するためのさまざまなプロセスについて説明します。 DNSを保護する方法については、後で説明します。 後の章では、Webセキュリティを実現するプロトコルについて説明します。
メールセキュリティ
現在、電子メールは非常に広く使用されているネットワークアプリケーションになっています。 電子メールセキュリティプロトコルについて知る前に、電子メールインフラストラクチャについて簡単に説明しましょう。
メールインフラ
電子メールを送信する最も簡単な方法は、送信者のマシンから受信者のマシンにメッセージを直接送信することです。 この場合、両方のマシンがネットワーク上で同時に実行されていることが不可欠です。 ただし、ユーザーがマシンをネットワークに接続する場合があるため、この設定は実用的ではありません。
そのため、電子メールサーバーをセットアップするという概念が生まれました。 この設定では、メールはネットワーク上で永続的に利用可能なメールサーバーに送信されます。 受信者のマシンがネットワークに接続すると、メールサーバーからメールを読み取ります。
一般に、電子メールインフラストラクチャは、メールサーバーのメッシュ（ Message Transfer Agents （MTA）とも呼ばれる）と、ユーザーエージェント（UA）とローカルMTAで構成される電子メールプログラムを実行するクライアントマシンで構成されます。
通常、電子メールメッセージはそのUAから転送され、MTAのメッシュを通過して、最終的に受信者のマシンのUAに到達します。
電子メールに使用されるプロトコルは次のとおりです-
- 電子メールメッセージの転送に使用される簡易メール転送プロトコル（SMTP）。
- ポストオフィスプロトコル（POP）およびインターネットメッセージアクセスプロトコル（IMAP）は、サーバーから受信者がメッセージを取得するために使用されます。
MIME
基本的なインターネット電子メール標準は1982年に作成され、インターネット上で交換される電子メールメッセージの形式を記述しています。 主に、基本的なローマ字のテキストとして記述された電子メールメッセージをサポートします。
1992年までに、それを改善する必要性が感じられました。 したがって、追加の標準_Multipurpose Internet Mail Extensions_（MIME）が定義されました。 これは、基本的なインターネット電子メール標準に対する一連の拡張機能です。 MIMEは、キリル文字（ロシア語で使用）、ギリシャ文字、または中国語の表意文字など、基本的なローマ字以外の文字を使用して電子メールを送信する機能を提供します。
MIMEによって満たされる別のニーズは、画像やビデオクリップなどの非テキストコンテンツを送信することです。 この機能により、MIME標準は電子メール通信用にSMTPで広く採用されるようになりました。
電子メールセキュリティサービス
重要で重要なトランザクションのための電子メール通信の使用の増加には、次のような特定の基本的なセキュリティサービスの提供が必要です-
- 機密性-電子メールメッセージは、意図した受信者以外には読まれてはなりません。
- 認証-電子メールの受信者は送信者の身元を確認できます。
- 整合性-電子メールメッセージが送信者によって送信されてから変更されていないことを受信者に保証します。
- 非拒否-電子メールの受信者は、送信者が実際にメッセージを送信したことを第三者に証明できます。
- 提出の証明-電子メール送信者は、メッセージがメール配信システムに渡されたことの確認を取得します。
- 配達証明-送信者は、受信者がメッセージを受信したことの確認を取得します。
プライバシー、認証、メッセージの整合性、否認防止などのセキュリティサービスは、通常、公開キー暗号化を使用して提供されます。
通常、電子メール通信には3つの異なるシナリオがあります。 これらのシナリオで上記のセキュリティサービスを実現する方法について説明します。
一対一の電子メール
このシナリオでは、送信者は1人の受信者のみに電子メールメッセージを送信します。 通常、通信に関与するMTAは2つ以下です。
送信者が受信者に機密の電子メールを送信したいとします。 この場合のプライバシーの提供は次のように達成されます-
- 送信者と受信者の秘密公開鍵は、それぞれ（S〜PVT〜、S〜PUB〜）および（R〜PVT〜、R〜PUB〜）です。
- 送信者は、暗号化のために秘密の対称キーK〜S〜を生成します。 送信者は暗号化にR〜PUB〜を使用できたかもしれませんが、対称キーを使用して暗号化と復号化を高速化します。
- 送信者はキーK〜S〜でメッセージを暗号化し、受信者の公開キーR〜PUB〜でK〜S〜も暗号化します。
- 送信者は、暗号化されたメッセージと暗号化されたK〜S〜を受信者に送信します。
- 受信者は、最初に自分の秘密キーR〜PVT〜を使用してエンコードされたK〜S〜を復号化することによりK〜S〜を取得します。
- 次に、受信者は対称キーK〜S〜を使用してメッセージを復号化します。
このシナリオでメッセージの整合性、認証、および否認防止サービスも必要な場合、上記のプロセスに次の手順が追加されます。
- 送信者はメッセージのハッシュを生成し、彼の秘密鍵S〜PVT〜でこのハッシュにデジタル署名します。
- 送信者は、この署名付きハッシュを他のコンポーネントとともに受信者に送信します。
- 受信者は公開鍵S〜PUB〜を使用し、送信者の署名の下で受信したハッシュを抽出します。
- 次に、受信者は復号化されたメッセージをハッシュし、2つのハッシュ値を比較します。 それらが一致する場合、メッセージの整合性が達成されたと見なされます。
- また、受信者は、メッセージが送信者によって送信されたことを確認します（認証）。 そして最後に、送信者はメッセージを送信しなかったことを拒否できません（否認防止）。
1対多の受信者の電子メール
このシナリオでは、送信者は2人以上の受信者に電子メールメッセージを送信します。 リストは、送信者の電子メールプログラム（UA +ローカルMTA）によって管理されます。 すべての受信者が同じメッセージを受け取ります。
送信者が機密メールを多くの受信者（R1、R2、R3など）に送信したいとします。 この場合のプライバシーの提供は次のように達成されます-
- 送信者とすべての受信者は、秘密と公開鍵の独自のペアを持っています。
- 送信者は秘密の対称キーK〜s〜を生成し、このキーでメッセージを暗号化します。
- 次に、送信者はR1、R2、およびR3の公開キーでK〜S〜を複数回暗号化し、R1〜PUB〜（K〜S〜）、R2〜PUB〜（K〜S〜）、およびR3〜PUB〜（ K〜S〜）。
- 送信者は、暗号化されたメッセージと対応する暗号化されたK〜S〜を受信者に送信します。 たとえば、受信者1（R1）は暗号化されたメッセージとR1〜PUB〜（K〜S〜）を受信します。
- 各受信者は、まず自分の秘密キーを使用してエンコードされたK〜S〜を復号化することにより、キーK〜S〜を抽出します。
- 各受信者は、対称キーK〜S〜を使用してメッセージを復号化します。
メッセージの整合性、認証、および否認防止を提供するための手順は、1対1の電子メールシナリオで前述した手順と同様です。
1対1の配布リストの電子メール
このシナリオでは、送信者は2人以上の受信者に電子メールメッセージを送信しますが、受信者のリストは送信者によってローカルで管理されません。 通常、電子メールサーバー（MTA）はメーリングリストを管理します。
送信者がメーリングリストを管理するMTAにメールを送信すると、MTAによってリスト内のすべての受信者にメールが展開されます。
この場合、送信者がメーリングリストの受信者（たとえば、R1、R2、およびR3）に機密の電子メールを送信する場合。プライバシーは次のように保証されています-
- 送信者とすべての受信者は、秘密と公開鍵の独自のペアを持っています。 Exploder Serverには、各メーリングリスト（List〜PUB〜、List〜PVT〜）が保持する秘密鍵と公開鍵のペアがあります。
- 送信者は秘密の対称キーK〜s〜を生成し、このキーでメッセージを暗号化します。
- 次に、送信者はリストに関連付けられた公開鍵でK〜S〜を暗号化し、List〜PUB〜（K〜S〜）を取得します。
- 送信者は、暗号化されたメッセージとList〜PUB〜（K〜S〜）を送信します。 エクスプローダーMTAは、List〜PVT〜を使用してList〜PUB〜（K〜S〜）を復号化し、K〜S〜を取得します。
- エクスプローダは、リストにあるメンバーと同じ数の公開キーでK〜S〜を暗号化します。
- Exploderは、受信した暗号化されたメッセージと対応する暗号化されたK〜S〜をリスト内のすべての受信者に転送します。 たとえば、Exploderは暗号化されたメッセージとR1〜PUB〜（K〜S〜）を受信者1などに転送します。
メッセージの整合性、認証、および否認防止を提供するための手順は、1対1の電子メールシナリオの場合と同様です。
興味深いことに、電子メールをセキュリティで保護するために上記のセキュリティ方法を採用している電子メールプログラムは、上記のすべての可能なシナリオで機能することが期待されます。 電子メールの上記のセキュリティメカニズムのほとんどは、Pretty Good Privacy（PGP）とS/MIMEの2つの一般的なスキームによって提供されます。 次のセクションで両方について説明します。
PGP
*Pretty Good Privacy* （PGP）は、電子メール暗号化スキームです。 これは、電子メール通信のセキュリティサービスを提供するための事実上の標準となっています。前述のように、公開キー暗号化、対称キー暗号化、ハッシュ関数、およびデジタル署名を使用します。 それを提供します-
- プライバシー
- 送信者認証
- メッセージの完全性
- 否認防止
これらのセキュリティサービスに加えて、データ圧縮とキー管理サポートも提供します。 PGPは、新しいものを発明するのではなく、RSA、IDEA、MD5などの既存の暗号化アルゴリズムを使用します。
PGPの働き
- メッセージのハッシュが計算されます。 （MD5アルゴリズム）
- 結果の128ビットハッシュは、送信者の秘密キー（RSAアルゴリズム）を使用して署名されます。
- デジタル署名はメッセージに連結され、結果は圧縮されます。
- 128ビットの対称キーK〜S〜が生成され、IDEAで圧縮メッセージを暗号化するために使用されます。 *K〜S〜は、RSAアルゴリズムを使用して受信者の公開鍵を使用して暗号化され、暗号化されたメッセージに結果が追加されます。
PGPメッセージの形式を次の図に示します。 IDは、KSの暗号化に使用されるキーと、ハッシュの署名の検証に使用されるキーを示します。
PGPスキームでは、メッセージは署名および暗号化され、MIMEは送信前にエンコードされます。
PGP証明書
PGP鍵証明書は通常、信頼のチェーンを通じて確立されます。 たとえば、Aの公開鍵はBが彼の公開鍵を使用して署名し、Bの公開鍵はCが彼の公開鍵を使用して署名します。 このプロセスが進むにつれて、信頼の輪が確立されます。
PGP環境では、すべてのユーザーが認証機関として機能できます。 すべてのPGPユーザーは、別のPGPユーザーの公開鍵を認証できます。 ただし、そのような証明書は、ユーザーが認証者を信頼できる紹介者として認識した場合にのみ、別のユーザーに有効です。
このような認証方法にはいくつかの問題があります。 既知の信頼できる公開キーから目的のキーに至るチェーンを見つけるのは難しいかもしれません。 また、複数のチェーンが存在する可能性があり、それらが目的のユーザーの異なるキーにつながる可能性があります。
PGPは、認証局でPKIインフラストラクチャを使用することもでき、公開鍵はCAによって認証されます（X.509証明書）。
S/MIME
S/MIMEは、Secure Multipurpose Internet Mail Extensionの略です。 S/MIMEは、安全な電子メール標準です。 これは、MIMEと呼ばれる以前の非セキュアな電子メール標準に基づいています。
S/MIMEの動作
S/MIMEアプローチはPGPに似ています。 また、公開キー暗号化、対称キー暗号化、ハッシュ関数、デジタル署名も使用します。 電子メール通信用のPGPと同様のセキュリティサービスを提供します。
S/MIMEで使用される最も一般的な対称暗号は、RC2とTripleDESです。 通常の公開キー方式はRSAであり、ハッシュアルゴリズムはSHA-1またはMD5です。
S/MIMEは、暗号化後のデータエンベロープのために、「application/pkcs7-mime」などの追加のMIMEタイプを指定します。 MIMEエンティティ全体が暗号化され、オブジェクトにパックされます。 S/MIMEでは、暗号化メッセージ形式が標準化されています（PGPとは異なります）。 実際、MIMEは、メッセージ内の暗号化および/または署名された部分を識別するためのいくつかのキーワードで拡張されています。
S/MIMEは、公開キー配布のためにX.509証明書に依存しています。 認定サポートにはトップダウンの階層PKIが必要です。
S/MIMEのエンプロイアビリティ
実装には認証機関からの証明書が必要であるため、一部のユーザーは公開/秘密キーペアでメッセージを暗号化する場合があるため、すべてのユーザーがS/MIMEを利用できるわけではありません。 たとえば、証明書の関与や管理オーバーヘッドなし。
実際には、ほとんどの電子メールアプリケーションはS/MIMEを実装していますが、証明書の登録プロセスは複雑です。 代わりに、PGPサポートでは通常、プラグインを追加する必要があり、そのプラグインには鍵の管理に必要なものがすべて付属しています。 Web of Trustは実際には使用されません。 他の媒体を介して公開鍵を交換します。 取得すると、通常は電子メールを交換する相手の公開鍵のコピーを保持します。
次の図に、PGPおよびS/MIMEスキームのネットワークアーキテクチャの実装層を示します。 これらのスキームはどちらも、電子メール通信のアプリケーションレベルのセキュリティを提供します。
環境に応じて、PGPまたはS/MIMEのいずれかのスキームが使用されます。 キャプティブネットワークでの安全な電子メール通信は、PGPに適応することで提供できます。 新しい未知のユーザーと頻繁にメールが交換されるインターネット上の電子メールセキュリティでは、S/MIMEが適切なオプションと見なされます。
DNSセキュリティ
最初の章では、攻撃者がDNSキャッシュポイズニングを使用してターゲットユーザーに攻撃を実行できることを説明しました。* ドメインネームシステムセキュリティ拡張機能（DNSSEC）は、このような攻撃を阻止できるインターネット標準です。
標準DNSの脆弱性
標準のDNSスキームでは、ユーザーがドメイン名に接続するたびに、コンピューターはDNSサーバーに接続し、そのドメイン名に関連付けられたIPアドレスを検索します。 IPアドレスが取得されると、コンピューターはそのIPアドレスに接続します。
このスキームでは、検証プロセスは一切含まれていません。 コンピューターはDNSサーバーにWebサイトに関連付けられたアドレスを要求し、DNSサーバーはIPアドレスで応答し、コンピューターは間違いなくそれを正当な応答として受け入れ、そのWebサイトに接続します。
DNSルックアップは、実際にはいくつかの段階で行われます。 たとえば、コンピュータが「www.finddevguides.com」を要求すると、DNSルックアップはいくつかの段階で実行されます-
- コンピューターは最初にローカルDNSサーバー（ISP提供）に問い合わせます。 ISPがキャッシュにこの名前を持っている場合、ISPは「ルートゾーンディレクトリ」にクエリを転送します。「ルートゾーンディレクトリ」では、「。com。」とルートゾーンの応答を見つけることができます。
- 次に、コンピュータは応答に基づいて、「finddevguides.com」を見つけることができる「.com」ディレクトリを尋ねます。
- 受け取った情報に基づいて、コンピューターはwwwを見つけることができる「finddevguides.com」に問い合わせます。 finddevguides.com。
DNSSEC定義
DNSSECを使用して実行されるDNSルックアップには、応答エンティティによる応答の署名が含まれます。 DNSSECは公開キー暗号化に基づいています。
DNSSEC標準では、すべてのDNSゾーンに公開キーと秘密キーのペアがあります。 DNSサーバーから送信されるすべての情報は、信頼性を確保するために、発信元ゾーンの秘密キーで署名されます。 DNSクライアントは、署名を確認するためにゾーンの公開キーを知る必要があります。 クライアントは、すべてのトップレベルドメインまたはルートDNSの公開キーで事前に構成されている場合があります。
DNSSECを使用すると、検索プロセスは次のようになります-
- コンピューターが.comを見つけることができるルートゾーンに尋ねると、応答はルートゾーンサーバーによって署名されます。
- コンピューターはルートゾーンの署名キーをチェックし、それが正しい情報を持つ正当なルートゾーンであることを確認します。
- 応答では、ルートゾーンは.comゾーンサーバーの署名キーとその場所に関する情報を提供し、コンピューターが.comディレクトリにアクセスできるようにして、正当であることを確認します。
- .comディレクトリは次に、finddevguides.comの署名キーと情報を提供し、それがgoogle.comに連絡して、その上のゾーンで確認されているように、実際のfinddevguides.comに接続していることを確認できるようにします。
- 送信される情報は、リソースレコードセット（RRSet）の形式です。 トップレベルの「.com」サーバーにあるドメイン「finddevguides.com」のRRSetの例を次の表に示します。
| Domain Name | Time to live | Type | Value |
|---|---|---|---|
| finddevguides.com | 86400 | NS | dns.finddevguides.com |
| dns.finddevguides.com | 86400 | A | 36..1.2.3 |
| finddevguides.com | 86400 | KEY | 3682793A7B73F731029CE2737D… |
| finddevguides.com | 86400 | SIG | 86947503A8B848F5272E53930C… |
- KEYレコードは「finddevguides.com」の公開鍵です。
- SIGレコードは、最上位の.comサーバーのフィールドNS、A、およびKEYレコードの署名付きハッシュであり、それらの信頼性を検証します。 その値はKcom〜pvt〜（H（NS、A、KEY））です。
したがって、DNSSECが完全にロールアウトされると、ユーザーのコンピューターはDNS応答が正当かつ真実であることを確認でき、DNSキャッシュポイズニングを通じて開始されるDNS攻撃を回避できると考えられます。
概要
電子メールを保護するプロセスにより、通信のエンドツーエンドのセキュリティが確保されます。 機密性、送信者認証、メッセージの整合性、および否認防止のセキュリティサービスを提供します。
電子メールセキュリティのために、PGPとS/MIMEの2つのスキームが開発されました。 これらのスキームは両方とも、秘密鍵暗号と公開鍵暗号を使用します。
標準のDNSルックアップは、DNSスプーフィング/キャッシュポイズニングなどの攻撃に対して脆弱です。 DNSルックアップの保護は、公開鍵暗号方式を採用するDNSSECの使用により実現可能です。
この章では、アプリケーション層で使用され、エンドツーエンド通信のネットワークセキュリティを提供するメカニズムについて説明しました。
