やる気の出ない情報セキュリティ７ 「セキュリティプロトコル」
セキュリティプロトコル
セキュリティプロトコルとは、
データを暗号化して通信するだけでは、通信のセキュリティは万全とは言えません。
暗号化だけではなく、なりすましや改ざんなどの脅威への対抗策を実現するための通信技術が必要となります。
それがセキュリティプロトコルです。
セキュリティプロトコルの例は、SSL/TLSやIPsec、SSH、S/MIME等が挙げられます。
セキュリティプロトコルは、公開鍵暗号化方式、共通鍵暗号化方式、ハッシュ関数やディジタル署名といった要素技術を組み合わせることで実現されています。
よってセキュリティプロトコルを設計し実装するうえでは、要素技術と、それらをどう組み合わせるかという、2つの観点から安全性についての議論が必要です。
利用する要素技術の安全性については、要素技術の安全性が脅かされた場合、それを用いて構成されるセキュリティプロトコルの安全性も損なわれます。
また、安全な要素技術を用いたところで、それらを組み合わせる設計に間違いがあれば、セキュリティプロトコル自体の安全性は損なわれます。
SSL/TLS
SSLは、WebサーバとブラウザのベンダーであったNetscape社によって、主にWeb通信の安全性の確保を目指して設計・実装されました。
それにいろいろ改善を加えていったのがTLSとなります。
SSL/TLSは、TCP上でのセキュリティプロトコルとして、設計されてきました。が、IP電話などで利用されるSIP等でも利用できるようにUDP上でTLSを実現するDTLSなどが現在は策定されています。
SSL/TLSは、「Record」、「Handshake」、「ChangeCipherSpec」および「Alert」という4つのプロトコルから構成されています。
SSL/TLSを利用して暗号化された通信を行う際には、まずHandshakeプロトコルで通信相手とのセッションを確立します。
ここで、SSLクライアントとSSLサーバ間で、相手の特定、利用する暗号アルゴリズムの情報、通信データの圧縮方式の情報、暗号鍵の情報などを交換し、合意した状態を持つことを指します。
SSL/TLSの通信中は、セッションIDという識別子によって、セッションが一意に特定されます。
セッションを確立した後、ChangeCipherSpecプロトコルにより、平文の通信から、Handshakeプロトコルで合意した暗号アルゴリズムを用いて暗号通信に切り替えることを通知します。
SSLクライアントとSSLサーバ上で稼働するアプリケーションは、そのあと、Recordプロトコルを通して、アプリケーションデータのやり取りを通信相手と行います。
その間に何らかの異常が発生した場合には、Alertプロトコルによりその異常が通信相手に通知されます。
SSL/TLSは、TCP/IPで利用するので、SSL/TLSの通信に先駆けてTCPにおけるコネクションを張ってからSSL/TLSのHandshakeを行います。
暗号化された通信を行い、SSL/TLSの終了を行った後で、TCPの接続を終了します。
Recordプロトコル
SSL/TLSのすべての通信は、送信するデータを最大214バイト以下に分割し、圧縮した後、暗号化などをして受信側に送ります。その手順を定義しているのがRecordプロトコルになります。
送信側では、送信するデータについてMAC(Message Authentication Code)値を計算し、添付、Recordヘッダを追加してデータを送信します。
Recordヘッダには、サイズ、SSLのバージョン、コンテントタイプ(メッセージの種類)の情報を含みます。Handshakeプロトコル
Handshakeプロトコルの目的は、保護するデータの送受信に必要な情報の共有状態を確立することです。共有状態とは、SSLサーバとSSLクライアントが、暗号鍵やアプリケーションデータの暗号アルゴリズムなどの情報（暗号スイート）を、お互い意図通りに等しく保持している状態です。SSL/TLSのHandshakeにはいくつかのバリエーションがあり、RSAやDSSを用いてサーバーを認証する「サーバー認証モード」と サーバとクライアントが相互に認証する「クライアント認証モード」などがあげられます。
サーバー認証モードとは、SSLクライアント(Webブラウザ)がSSLサーバー(Webサーバー)を一方向で認証するものを言います。
SSLサーバーからは、SSLクライアントが何者かわかりませんが、クレジットカードの情報などをサーバへ送信する場合においては、これでもよいといえます。
Webサーバー側で利用者を認証したいときには、サーバー認証モードでのSSL通信路上でパスワードにより利用者を認証するBasic/Digest認証(apacheなどのWebサーバの機能)を行うか、 Webアプリケーションで認証(Form認証)を行います。RSAを用いたサーバ認証モードでは、ClientHello、ServerHello、Certificate、ServerHelloDone、 ClientKeyExchange、Finishedなどのメッセージを順番にやり取りして接続を行います。
クライアント認証モードは、SSLクライアントとSSLサーバーがHandshakeにおいて互いに認証するものを言います。
ただSSL/TLSでは、サーバー認証モードに比べると利用が多くありません。クライアントに証明書の提示を求めるので、一般的な利用者やWebサイトの管理者にとって負担が大きいからです。
鍵の生成
SSL/TLSで暗号化やMACに使う暗号鍵は、クライアントとサーバーがそれぞれ、Handshakeでやり取りした同じ素材から、同じ関数を使って作ります。
このような鍵の生成に使う関数をKDF(Key Derivation Function)と呼びます。DTLSの概要
順番が入れ替わったり、パケットが通信中消えたりするUDP上でTLSをそのまま実現しようとすると、問題があります。- レコードの順番が入れ替わったり消えたりすると、MACのエラーとなり、通信が遮断される
- Handshakeはメッセージが順序通りすべて届くことを前提としているのでHandshakeが成立しなくなる。
そこでDTLSでは、UDPに対応するように変更を加えています。
例えば、Handshakeの修正(確認用メッセージの追加、再送機能の追加)、レコードにシーケンス番号などのフィールドを追加 など
また再送攻撃対策や、DoS攻撃対策もしているみたいです。。強い
IPsec
IPsecはIETF(Internet Engineering Task Force)において策定されたセキュリティプロトコルです。
ホストやルーターといったゲートウェイに導入、設定することによって、ホスト間やゲートウェイ間のIP通信を安全にする技術です。
具体的には以下の機能を提供します。
- アクセス制御
セキュリティポリシーに従ったパケットのフィルタリング - データの完全性確保
MAC(メッセージ認証コード)によるデータの完全性確保 - データの送信元の認証
MAC(メッセージ認証コード)によるヘッダを含めたパケットの真正性の確保 - 再送攻撃の防御
シーケンス番号を用いた再送攻撃の防御 - DoS攻撃の防御
ステートレスクッキーを用いた、送信元偽装パケットの判別 - データの機密性
データの暗号化による機密性の確保 - トラフィック情報の機密性
IPより上位の層のヘッダを暗号化することによる機密性確保
IPsecはIPパケットを暗号化するので、OSI参照モデルのネットワーク層より上位の通信プロトコルを利用するアプリケーションソフトは安全な通信を利用出ます。
IPsecは、AH(Authentication Header)およびESP(Encapsulating Security Payload)という２つのプロトコルから主に構成されます。
AHはIPパケットの真正性と、IPパケットの完全性を確保します。
ESPは、IPパケットの機密性を確保します。
IPsecとともに使用されることが多いほかのプロトコルとして、IPComp(IP Payload Compression Protocol)やIKE(Internet Key Exchange)があります。
IPCompはIPsecパケットの圧縮に関するプロトコル、IKEはAHやESPに先立って行われる鍵の共有、および暗号方式などの合意のためのプロトコルです。
これらは組み合わせて利用することが多いので、AH、ESP、IPComp、IKEをまとめてIPsecと呼ぶ場合もあります。
IPsecでは、トランスポートモードとトンネルモードという２つの方式が用意されています。
トランスポートモードは、ホスト間で接続し、IPヘッダおよびペイロード部のセキュリティを確保します。
トンネルモードは、主にIPsecを実装したルーター(セキュリティゲートウェイ)間で、IPパケット全体のセキュリティを確保します。
トンネルモードでは、転送されるパケットにセキュリティゲートウェイが新たにIPヘッダを追加して、相手側のセキュリティゲートウェイに転送します。これでVPN(Virtual Private Network)を実現し、通信を保護します。
IPsecの処理の概要
IPsecでは、単方向のコネクションごとに、AHのケース、ESPのケース、もしくはその両方のケースで、コネクションをそれぞれ確立します。
IPsecでは様々なパラメータを伴う一方向のコネクションのことをSA(Security Association)と呼んでいます。SAのパラメータには、暗号化アルゴリズム、暗号化カギ、IV、MACアルゴリズムなどが含まれます
IPsecの送信側処理
IPsecパケットがホストやセキュリティゲートウェイから送信される際には、以下のような処理が行われます① 対象となるIPパケットの始点IPアドレス、終点IPアドレス、上位層プロトコル、ポート番号などの情報(これらをセレクタという)に応じて対応する処理(セキュリティポリシー)を決めます。
② SPD(Security Policy Database)を検索して、「破棄」だった場合は、当該パケットを破棄します。「IPsecを適用しない」であった場合は、通常のパケット処理をします。 「IPsecを適用」であった場合は、IPsecの処理に進みます
③ 送信用SAD(security Assosciation Database)から該当するSAの情報を検索します
④ SADを検索した結果該当するSAがない場合は次に進みます。SAが存在する場合、SAに関する情報を取り出します。
⑤ IKEの利用が設定されている場合、IKEを用いて新しいSAを作成します。
⑥ 受信側のIKEモジュールとのネゴの後、SAを確定させます。AHとESPの両方を利用する場合は、ESPのSAのネゴを先に行い、AHのネゴを行います。確立したSAはSADに登録します。
- IPsecの受信側処理
IPsecパケットがホストやセキュリティゲートウェイで受信される際には、以下のように処理されます。
① 受信したIPsecパケットに含まれるSPI（Security Parameter Index）により、受信側用SADから該当するSAの情報を検索します。
② 該当するSAが存在しない場合、IPsecパケットを破棄します。該当するSAがある場合、次の処理に進みます。
③ 暗号アルゴリズムや暗号かぎの情報を取り出して、AH、ESPの受信処理を行います。
④ IPパケットの始点IPアドレス、終点IPアドレスなど(セレクタ)を検索キーとして、受信側用SPDからセキュリティポリシーを検索します。 選択して得られたセキュリティポリシーの内容と、適用されていたIPsec処理の内容が合致していることを確認します。
- AH
AHはIPsecパケットの送信元の真正性と完全性を確保するプロトコルです。
ICV(Integrity Check Value)と呼ばれるMAC(メッセージ認証コード)を用いて転送パケットの送信元の真正性と完全性を確保します。
AHの処理ではICV値をAHヘッダに埋め込みます。
- ESP
ESPは、IPsecパケットの機密性を暗号化によって確保するセキュリティプロトコルです。オプションで、IPsecパケットのメッセージ認証(MAC)の機能も提供します。
ESPのメッセージ認証機能は、AHと同じ手法が採用されており、メッセージ認証機能を有効にすると、パケットの真正性と完全性を確保できます。
