HOME >> 情報セキュリティ >> 調査・研究報告書 >> 情報セキュリティ技術動向調査（2010 年上期） >> 2 MACsecによるレイヤ2暗号化

情報セキュリティ技術動向調査（2010 年上期）

2 MACsecによるレイヤ2暗号化

馬場 達也

1. はじめに

 　近年、ソフトウェアやハードウェアなどのリソースをネットワーク経由で利用する形態である「クラウドコンピューティング」が流行っている。しかし、クラウドコンピューティングをビジネスに適用しようとした場合に、セキュリティの問題が指摘されてきている。このセキュリティを確保するために、データセンタ用機器において、レイヤ2レベルでメッセージの暗号化および認証を行うMACsec（Media Access Control Security Protocol）の実装が進んでいる。本報告では、このMACsecの概要とクラウド環境におけるセキュリティについて考察する。

2. MACsecとは

 　MACsecは、暗号鍵インフラを用いて、イーサネットなどのレイヤ2プロトコルで流れている「フレーム」を暗号化するための技術である。IPsec（IP Security Protocol）やSSL（Secure Sockets Layer）/TLS（Transport Layer Security）などと異なり、レイヤ2レベルで暗号化されるため、スイッチやルータ、ファイアウォール、IPS（Intrusion Prevention System）などの中間ノードでのインスペクションが可能となる点が大きく異なる。

3. MACsecに関する仕様

 　MACsecに関する仕様は、以下のふたつがある。MACsec本体の標準化は2006年に完了しているが、鍵管理プロトコルの仕様が長くドラフトのままであった。しかし、2010年2月に標準化承認が下り、MACsecの標準化が実質的に完了した。

  • IEEE 802.1AE-2006 “Media Access Control (MAC) Security”
      • MACsec本体の仕様であり、2006年6月に標準化承認されている。
  • IEEE 802.1X-2010 “Local and Metropolitan Area Networks - Port-Based Network Access Control”
      • IEEE 802.1X-2004 （EAPOL：EAP over LAN）に、MACsecのサポートと、MACsecの鍵交換プロトコルの仕様として検討されていた IEEE P802.1afの内容をマージしたもの。2010年2月に標準化承認されている。

4. MACsecの提供機能

 　MACsecでは、以下のセキュリティ機能を提供するように設計されている。IPsecとの違いは表1の通りである。

  • コネクションレスデータ完全性確保
      • MACフレームに付加されるICV（Integrity Check Value）をチェックすることにより、フレームの内容が途中で改ざんされていないことを確認することが可能となる。
  • データ送信元の認証
      • ICVをチェックすることにより、データ送信元が正しい共通鍵を保持している、正当な相手であることを確認することが可能となる。この共通鍵は、鍵交換プロトコルによって、相手認証を行ったうえで共有される。
  • データの機密性確保
      • 共通鍵暗号によって、MACフレームのデータ部が暗号化される。京津鍵暗号で使用される共通鍵は、鍵交換プロトコルによって、相手認証を行ったうえで共有される。
  • リプレイ防御
      • MACフレームに付加されるPacket Numberフィールドに、ユニークなIDを埋め込むことにより、同じIDを持ったMACフレームを受信することを防止することが可能となる。これにより、悪意を持った者が、ネットワーク上を流れているMACフレームをコピーして、再度送信するという「リプレイ攻撃」から防御することが可能となる。
  • 受信遅延制限（Bounded receive delay）
      • MACフレームを受信する間隔を設定することにより、不自然に遅れたMACフレームの受信を拒否することが可能となる。
  • サービス妨害攻撃からの防御
      • 上記の仕組みにより、ある一定のサービス妨害攻撃から防御することが可能となる。
      ※　送信否認やトラフィック分析に対する保護は提供しない

表１　IPsecとMACsecの比較

 IPsec MACsec
暗号化範囲 レイヤ3パケット全体（トンネルモード）
レイヤ3データ（トランスポートモード）		 レイヤ2データ（レイヤ3パケット全体）
メッセージ認証範囲 レイヤ3パケット全体（トンネルモード）
レイヤ3データ（トランスポートモード） 		レイヤ2フレーム全体
鍵交換プロトコル IKEv1 / IKEv2 IEEE 802.1X-2010
セキュリティ保護の範囲 エンドツーエンド ノード間のみ
スループット 暗号化のみハードウェア すべてハードウェアレベル
リプレイ保護 32ビットのシーケンス番号によるチェック 32ビットのPN（Packet Number）によるチェック
トラフィック解析保護 △ ×
受信遅延制限 × ◯

5. MACsecにおけるコネクションの概念

 　IPsecでは、コネクションの概念として、SA（Security Association）が定義されているが、MACsecでは、CA、SC、SAの3つの概念が定義されている（図1）。

  • CA（Connectivity Association）
      • 単方向のSCによって接続されるステーションのグループ
      鍵交換プロトコルによって管理される
  • SC（Secure Channel）
      • 単方向の接続
      SAの連続によって構成される
      SCI（Secure Channel Identifier） = System Identifier（6バイト）+Port Identifier（2バイト）で識別される
  • SA（Secure Association）
      • SAK（Secure Association Key）を使ってセキュリティサービスを提供する
      SAI（Secure Association Identifier）= System Identifier（6バイト）+Port Identifier（2バイト）+Association Number（2ビット）で識別される

図1　MACsecにおけるCA/SC/SAの概念

6. MACsecのフレームフォーマット

 　MACsec適用前のイーサフレームのフォーマットを図2に、MACsec適用後のイーサフレームのフォーマットを図3に示す。MACsecを適用したイーサフレームには、ユーザデータの前にSecTAG（MAC Security TAG）が、ユーザデータの後にICV（Integrity Check Value）が付加される。
 　SecTAGは、以下のフィールドから構成される。

  • MACsec EtherType
      • MACsecが使われていることを示す2オクテットのフィールド。値は「88-E5」となる。
  • TCI（TAG Control Information）
      • MACsecのバージョンを示すVビット（当面は0が入る）や、SCIフィールドの存在を示すSCビット、暗号化の有無などを示すEビットなどを含む6ビットのフィールド。
  • AN（Association Number）
      • 同一のSCの中でSAを識別するための2ビットのフィールド。つまり、SCは最大4つのSAから構成される。
  • SL（Short Length）
      • Secure Dataの長さが48オクテット未満の場合に、その長さ（オクテット）が入る。48オクテット以上の場合には0が入る。
  • PN（Packet Number）
      • 同一のSAで送信されたパケットを識別するユニークなIDが入る4オクテットのフィールド。
  • SCI（Secure Channel Identifier）
      • TCIのSCビットが1の場合に存在する、8オクテットのフィールドであり、6オクテットのSystem Identifierフィールドと2オクテットのPort Identifierフィールドからなる。SCを識別するために利用される。また、デフォルトの暗号アルゴリズムであるGCM-AES-128では、SCI値とPN値によってIV（Initialization Vector）が作られる。

 　TCIフィールドのEビットが１の場合に、ユーザデータ部（Data）が暗号化される（暗号化されたDataはSecure Dataと呼ばれる）。そして、DMAC（宛先MACアドレス）、SMAC（送信元MACアドレス）、SecTAG、Secure Dataがメッセージ認証の範囲となる。


図2　MACsec適用前のイーサフレームフォーマット

 

図3　MACsec適用後のイーサフレームフォーマット

7. 暗号アルゴリズム

 　MACsecでは、デフォルトの暗号アルゴリズムとして、GCM-AES-128が指定されている。GCMとは、Galois/Counter Modeの略であり、データの暗号化とメッセージ認証の両方の機能を同時に実現する、高速で動作するアルゴリズムである。共通鍵には、128ビットの鍵を使用する。送信側と受信側が実装していれば、異なる暗号アルゴリズムを使用することも可能である。

8. 鍵交換の役割

 　MACsecでは、鍵交換プロトコルとしてIEEE 802.1X-2010が利用される。鍵交換プロトコルの役割には以下の4つがある。

  • 相手認証日付など 形式など 説明など
  • CA/SC/SAの確立日付など 形式など 説明など
  • 暗号アルゴリズムの折衝
  • 共通鍵の配布

9. MACsecの実装状況

 　MACsecは、Cisco SystemsやIntelによって実装が進められている。
 　Cisco Systemsでは、同社の提唱する”TrustSec”において、MACsecを採用しており、同社のスイッチ製品である、Nexus 7000、Catalyst 3750-X、Catalyst 3560-X、そして、RADIUSサーバ製品であるCisco Secure Access Control System 5.1にて実装済みである。鍵交換プロトコルは、同社独自のSecurity Association Protocol (SAP)を使用しているが、IEEE 802.1X-2010にリプレースする見込みとなっている。
 　また、IntelのIntel 82567LM ギガビット LAN ドライバーがMACsecに対応している。

10. クラウドへの流れがMACsecの利用を加速

 　MACsecが注目されてきた背景としては以下のような特徴を持つクラウドの流れがあると考えられる。

  • ライブマイグレーションによるデータセンタ内のレイヤ2化

    •  　VMwareのvMotionのような、ライブマイグレーションを実現するには、レイヤ2で接続されていなければならないため、データセンタ内はレイヤ2でフラットに構築するという流れが出てきた。そのため、MACsecが利用できる環境になってきた。

  • データセンタ間接続のレイヤ2化

    •  　DR（Disaster Recovery）用に、データセンタが地理的に複数に分かれていても、同じように見せたいという要望が出てきたため、データセンタ間をVPLS（Virtual Private LAN Service）、MAC-VPN、Cisco Overlay Transport Virtualization（OTV）などのレイヤ2で接続する技術を使う流れが出てきた。

11. MACsec適用時に検討すべき点

  • 何からデータを守るのか

    •  　MACsecを適用する場合は、何からデータを守るのかということをよく考える必要がある。他の暗号プロトコルにも言えることであるが、暗号化する人≠盗聴する人でなければならない。MACsecをデータセンタに導入した場合、暗号化されるのはデータセンタ内のケーブルを流れるデータであり、ネットワーク機器の内部ではデータは復号化されているため、ネットワーク機器に侵入できる人物は盗聴することが可能である。つまり、データセンタの機器の管理者からデータを保護することはできない。MACsecが保護できるのは、データセンタにデータセンタ運用者以外の人間が侵入してケーブルを流れるデータを盗聴する行為や、レイヤ2で構成されたWAN上で盗聴する行為に対してである。ネットワーク機器に侵入できる人物からデータを保護したいのであれば、IPsecなどのエンドツーエンドの暗号プロトコルの利用を検討すべきだろう。ただし、実際のデータはデータセンタ内のストレージなどに格納されるため、IPsecのような通信路上のデータを保護する仕組みだけでは十分ではない。サーバやストレージなども考慮した対策を検討する必要があるだろう。

  • パフォーマンスへの影響

    •  　MACsecは、レイヤ2以上のすべての機器でフレームの復号化/暗号化を行う必要があるため、機器への負荷や、通信のパフォーマンスへの影響を考慮する必要がある。すべてハードウェアで実装されていることが条件となるだろう。

12. まとめ

 　MACsecの仕組み自体は2006年に標準化済みであったが、鍵交換の仕組みが2010年にようやく標準化承認されたことにより、今後、実装が進むと考えられる。すでに、Cisco Systemsがデータセンタ向けスイッチに実装を進めており、IntelもNICに実装を進めている。
 　今後、クラウドデータセンタがレイヤ2化されていくに従い、利用が加速する可能性がある。ただし、「何のために暗号化するのか」といった検討は常に検討していく必要があると考えられる。

以上

 

ページトップへ
目次へ 次へ