ネットワークセキュリティ–アプリケーション層
現在、さまざまなビジネスサービスが、クライアントサーバーアプリケーションを介してオンラインで提供されています。最も人気のあるフォームは、Webアプリケーションと電子メールです。どちらのアプリケーションでも、クライアントは指定されたサーバーと通信し、サービスを取得します。
クライアントとサーバーは、任意のサーバーアプリケーションのサービスを使用しているときに、基盤となるイントラネットまたはインターネット上で多くの情報を交換します。これらの情報取引は、さまざまな攻撃に対して脆弱であることを認識しています。
ネットワークセキュリティでは、データがネットワーク上で転送されている間、攻撃からデータを保護する必要があります。この目標を達成するために、多くのリアルタイムセキュリティプロトコルが設計されています。このようなプロトコルは、少なくとも次の主要な目的を提供する必要があります-
- 当事者は、相互に認証するために対話的にネゴシエートできます。
- ネットワーク上で情報を交換する前に、秘密のセッションキーを確立します。
- 暗号化された形式で情報を交換します。
興味深いことに、これらのプロトコルはネットワークモデルのさまざまな層で機能します。たとえば、S / MIMEプロトコルはアプリケーション層で機能し、SSLプロトコルはトランスポート層で機能するように開発され、IPsecプロトコルはネットワーク層で機能します。
この章では、電子メール通信のセキュリティと関連するセキュリティプロトコルを実現するためのさまざまなプロセスについて説明します。DNSを保護する方法については、後で説明します。後の章では、Webセキュリティを実現するためのプロトコルについて説明します。
電子メールのセキュリティ
今日、電子メールは非常に広く使用されているネットワークアプリケーションになっています。電子メールのセキュリティプロトコルについて理解する前に、電子メールのインフラストラクチャについて簡単に説明しましょう。
電子メールインフラストラクチャ
電子メールを送信する最も簡単な方法は、送信者のマシンから受信者のマシンに直接メッセージを送信することです。この場合、両方のマシンがネットワーク上で同時に実行されていることが不可欠です。ただし、ユーザーが自分のマシンをネットワークに接続することがあるため、この設定は実用的ではありません。
そのため、電子メールサーバーをセットアップするという概念が生まれました。この設定では、メールはネットワーク上で永続的に利用可能なメールサーバーに送信されます。受信者のマシンがネットワークに接続すると、メールサーバーからメールを読み取ります。
一般に、電子メールインフラストラクチャは、メールサーバーのメッシュで構成されます。 Message Transfer Agents (MTA)およびユーザーエージェント(UA)とローカルMTAで構成される電子メールプログラムを実行するクライアントマシン。
通常、電子メールメッセージはUAから転送され、MTAのメッシュを通過して、最終的に受信者のマシンのUAに到達します。
電子メールに使用されるプロトコルは次のとおりです-
電子メールメッセージの転送に使用されるSMTP(Simple Mail Transfer Protocol)。
ポストオフィスプロトコル(POP)とインターネットメッセージアクセスプロトコル(IMAP)は、受信者がサーバーからメッセージを取得するために使用されます。
MIME
基本的なインターネット電子メール標準は1982年に作成され、インターネット上で交換される電子メールメッセージの形式を記述しています。主に基本的なローマ字のテキストとして書かれた電子メールメッセージをサポートします。
1992年までに、同じものを改善する必要性が感じられました。したがって、追加の標準多目的インターネットメール拡張機能(MIME)が定義されました。これは、基本的なインターネット電子メール標準の拡張機能のセットです。MIMEは、キリル文字(ロシア語で使用)、ギリシャ文字、さらには中国語のイデオグラフィック文字など、基本的なローマ字以外の文字を使用して電子メールを送信する機能を提供します。
MIMEが満たすもう1つのニーズは、画像やビデオクリップなどの非テキストコンテンツを送信することです。この機能により、MIME標準は電子メール通信用のSMTPで広く採用されるようになりました。
電子メールセキュリティサービス
重要かつ重要なトランザクションでの電子メール通信の使用の増加には、次のような特定の基本的なセキュリティサービスの提供が必要です。
Confidentiality −電子メールメッセージは、意図された受信者以外の誰にも読まれるべきではありません。
Authentication −電子メールの受信者は、送信者の身元を確認できます。
Integrity −電子メールメッセージが送信者によって送信されてから変更されていないことを受信者に保証します。
Non-repudiation −電子メールの受信者は、送信者が実際にメッセージを送信したことを第三者に証明できます。
Proof of submission −電子メールの送信者は、メッセージがメール配信システムに渡されたことの確認を受け取ります。
Proof of delivery −送信者は、受信者がメッセージを受信したという確認を受け取ります。
プライバシー、認証、メッセージの整合性、否認防止などのセキュリティサービスは、通常、公開鍵暗号を使用して提供されます。
通常、電子メール通信には3つの異なるシナリオがあります。これらのシナリオで上記のセキュリティサービスを実現する方法について説明します。
1対1の電子メール
このシナリオでは、送信者は1人の受信者にのみ電子メールメッセージを送信します。通常、通信には2つ以下のMTAが関与します。
送信者が受信者に機密の電子メールを送信したいとします。この場合のプライバシーの提供は次のように達成されます-
送信者と受信者は、それぞれ(S PVT、S PUB)と(R PVT、R PUB)の秘密公開鍵を持っています。
送信者は、秘密対称鍵、K生成Sを暗号化するために。送信者は暗号化にRPUBを使用できたかもしれませんが、対称鍵を使用して暗号化と復号化を高速化します。
送信者が暗号化キーKとのメッセージSともはK暗号化Sを、受信者、R用の公開鍵でPUB。
送信者は、暗号化されたメッセージと暗号化されたK送信Sを受取人に。
受信者は最初にKを取得SをエンコードされたK解読することによってSを自分の秘密鍵、R使用PVTを。
受信者は、次に、対称鍵、K使用してメッセージを復号化するSを。
このシナリオでメッセージの整合性、認証、および否認防止サービスも必要な場合は、上記のプロセスに次の手順が追加されます。
送信者はメッセージのハッシュを生成し、このハッシュに自分の秘密鍵SPVTを使用してデジタル署名します。
送信者は、この署名されたハッシュを他のコンポーネントとともに受信者に送信します。
受信者は公開鍵SPUBを使用し、送信者の署名の下で受信したハッシュを抽出します。
次に、受信者は復号化されたメッセージをハッシュし、2つのハッシュ値を比較します。それらが一致する場合、メッセージの整合性が達成されたと見なされます。
また、受信者は、メッセージが送信者によって送信されたことを確認します(認証)。そして最後に、送信者はメッセージを送信しなかったことを否定できません(否認防止)。
1対複数の受信者の電子メール
このシナリオでは、送信者は2人以上の受信者に電子メールメッセージを送信します。このリストは、送信者の電子メールプログラム(UA +ローカルMTA)によって管理されます。すべての受信者は同じメッセージを受け取ります。
送信者が多くの受信者(R1、R2、R3など)に機密の電子メールを送信したいとします。この場合のプライバシーの提供は次のように達成されます-
送信者とすべての受信者は、独自の秘密公開鍵のペアを持っています。
送信者は、秘密対称鍵、K生成秒と、このキーでメッセージを暗号化します。
次に、送信者は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を生成秒をしてから、このキーでメッセージを暗号化します。
次に、送信者はリストに関連付けられた公開鍵を使用してK Sを暗号化し、リストPUB(K S)を取得します。
送信者は暗号化されたメッセージとリストPUB(K S)を送信します。発破MTAリストの復号PUB(K Sリストを使用して)PVTのとK取得Sを。
エクスプローダはK暗号化Sを、リスト内のメンバーがあるとして多くの公開鍵などで。
発破は、受信した暗号化されたメッセージを転送し、K暗号化された対応するSをリスト内のすべての受信者に。たとえば、Exploderは暗号化されたメッセージとR1 PUB(K S)を受信者1に転送します。
メッセージの整合性、認証、および否認防止を提供するために従うべき手順は、1対1の電子メールシナリオの場合と同様です。
興味深いことに、電子メールを保護するために上記のセキュリティ方法を採用している電子メールプログラムは、上記で説明したすべての可能なシナリオで機能することが期待されています。上記の電子メールのセキュリティメカニズムのほとんどは、Pretty Good Privacy(PGP)とS / MIMEの2つの一般的なスキームによって提供されます。次のセクションでは、両方について説明します。
PGP
Pretty Good Privacy(PGP)は、電子メールの暗号化スキームです。これは、電子メール通信のセキュリティサービスを提供するための事実上の標準になっています。
上で説明したように、公開鍵暗号、対称鍵暗号、ハッシュ関数、およびデジタル署名を使用します。それは提供します-
- Privacy
- 送信者認証
- メッセージの整合性
- Non-repudiation
これらのセキュリティサービスに加えて、データ圧縮とキー管理のサポートも提供します。PGPは、新しい暗号化アルゴリズムを発明するのではなく、RSA、IDEA、MD5などの既存の暗号化アルゴリズムを使用します。
PGPの動作
メッセージのハッシュが計算されます。(MD5アルゴリズム)
結果の128ビットハッシュは、送信者の秘密鍵を使用して署名されます(RSAアルゴリズム)。
デジタル署名はメッセージに連結され、結果は圧縮されます。
128ビットの対称鍵KSが生成され、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 MailExtensionの略です。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 ofTrustは実際には使用されていません。人々は別の媒体を介して公開鍵を交換します。取得すると、通常は電子メールを交換する相手の公開鍵のコピーを保持します。
次の図に、PGPおよびS / MIMEスキームのネットワークアーキテクチャの実装レイヤーを示します。これらのスキームは両方とも、電子メール通信用のアプリケーションレベルのセキュリティを提供します。
環境に応じて、PGPまたはS / MIMEのいずれかのスキームが使用されます。キャプティブネットワークでの安全な電子メール通信は、PGPに適応することで提供できます。メールが新しい未知のユーザーと頻繁に交換されるインターネットを介した電子メールのセキュリティでは、S / MIMEが適切なオプションと見なされます。
DNSセキュリティ
最初の章では、攻撃者がDNSキャッシュポイズニングを使用してターゲットユーザーを攻撃できることを説明しました。 Domain Name System Security Extensions (DNSSEC)は、このような攻撃を阻止できるインターネット標準です。
標準DNSの脆弱性
標準のDNSスキームでは、ユーザーが任意のドメイン名に接続する場合は常に、コンピューターがDNSサーバーに接続し、そのドメイン名に関連付けられたIPアドレスを検索します。IPアドレスが取得されると、コンピューターはそのIPアドレスに接続します。
このスキームでは、検証プロセスはまったく含まれていません。コンピューターはDNSサーバーにWebサイトに関連付けられたアドレスを要求し、DNSサーバーはIPアドレスで応答します。コンピューターは間違いなくそれを正当な応答として受け入れ、そのWebサイトに接続します。
DNSルックアップは、実際にはいくつかの段階で発生します。たとえば、コンピュータが「www.tutorialspoint.com」を要求すると、DNSルックアップはいくつかの段階で実行されます。
コンピューターは最初にローカルDNSサーバー(ISP提供)に問い合わせます。ISPのキャッシュにこの名前がある場合、ISPは応答します。それ以外の場合は、クエリを「ルートゾーンディレクトリ」に転送し、そこで「.com」を見つけることができます。およびルートゾーンの応答。
次に、応答に基づいて、コンピュータは「tutorialspoint.com」を見つけることができる「.com」ディレクトリに問い合わせます。
受け取った情報に基づいて、コンピューターは「tutorialspoint.com」にwwwを見つけることができる場所を問い合わせます。tutorialspoint.com。
DNSSEC定義
DNSルックアップは、DNSSECを使用して実行される場合、応答エンティティによる応答の署名を伴います。DNSSECは、公開鍵暗号に基づいています。
DNSSEC標準では、すべてのDNSゾーンに公開鍵と秘密鍵のペアがあります。DNSサーバーによって送信されるすべての情報は、信頼性を確保するために発信元ゾーンの秘密鍵で署名されています。DNSクライアントは、署名を確認するためにゾーンの公開鍵を知っている必要があります。クライアントは、すべてのトップレベルドメインの公開鍵またはルートDNSで事前構成されている場合があります。
DNSSECを使用すると、ルックアッププロセスは次のようになります-
コンピュータが.comを見つけることができるルートゾーンに尋ねると、応答はルートゾーンサーバーによって署名されます。
コンピュータはルートゾーンの署名キーをチェックし、それが真の情報を持つ正当なルートゾーンであることを確認します。
返信では、ルートゾーンが.comゾーンサーバーの署名キーとその場所に関する情報を提供し、コンピューターが.comディレクトリに接続できるようにして、それが正当であることを確認します。
次に、.comディレクトリはtutorialspoint.comの署名キーと情報を提供し、その上のゾーンで確認されているように、google.comに接続して、実際のtutorialspoint.comに接続していることを確認できるようにします。
送信される情報は、リソースレコードセット(RRSet)の形式です。次の表に、最上位の「.com」サーバーのドメイン「tutorialspoint.com」のRRSetの例を示します。
ドメイン名 | 有効期間 | タイプ | 値 |
---|---|---|---|
tutorialspoint.com | 86400 | NS | dns.tutorialspoint.com |
dns.tutorialspoint.com | 86400 | A | 36..1.2.3 |
tutorialspoint.com | 86400 | キー | 3682793A7B73F731029CE2737D .. .. |
tutorialspoint.com | 86400 | SIG | 86947503A8B848F5272E53930C .. |
KEYレコードは、「tutorialspoint.com」の公開鍵です。
SIGレコードは、フィールドNS、A、およびKEYレコードの最上位の.comサーバーの署名付きハッシュであり、それらの信頼性を検証します。その値はKCOMあるPVT(H(NS、A、KEY))。
したがって、DNSSECが完全に展開されると、ユーザーのコンピューターはDNS応答が正当で真実であることを確認し、DNSキャッシュポイズニングによって開始されるDNS攻撃を回避できると見なされます。
概要
電子メールを保護するプロセスは、通信のエンドツーエンドのセキュリティを保証します。機密性、送信者認証、メッセージの整合性、および否認防止のセキュリティサービスを提供します。
電子メールのセキュリティのために、PGPとS / MIMEの2つのスキームが開発されました。これらのスキームは両方とも、秘密鍵と公開鍵の暗号化を使用します。
標準のDNSルックアップは、DNSスプーフィング/キャッシュポイズニングなどの攻撃に対して脆弱です。DNSルックアップの保護は、公開鍵暗号を採用するDNSSECを使用することで実現可能です。
この章では、エンドツーエンド通信にネットワークセキュリティを提供するためにアプリケーション層で使用されるメカニズムについて説明しました。