盡管許多lank">寬帶" title="寬帶">寬帶 VPN" title="VPN">VPN 運(yùn)行于隧道模式，PacketCable 安全規(guī)范卻規(guī)定了傳輸模式的安全性。
 |
這為電子監(jiān)控（也稱作法律執(zhí)行通信協(xié)助法，即 CALEA）的安全性提出了新的挑戰(zhàn)。此外， PacketCable 電子監(jiān)控規(guī)范定義了從線纜調(diào)制解調(diào)器終端系統(tǒng) (CMTS) 開始的安全模型，但許多 VPN 都始于 PC 或 IP 電話，其通過 CMTS 和/或媒體網(wǎng)關(guān) (MG) 連接至多媒體終端適配器/線纜調(diào)制解調(diào)器 (MTA/CM) 以及隧道。只有這些具體的終端設(shè)備知道密鑰及相關(guān)參數(shù)。另一個(gè)要考慮的問題則是安全 RTP (SRTP)，它提供語音的端至端加密。不僅加密/解密是一個(gè)挑戰(zhàn)，在某些情況下截取消息也困難。具體而言，其實(shí)例之一就是在 NAT 存在時(shí)嘗試加密/解密。
在本論述中，德州儀器 (TI) 將研究上述安全挑戰(zhàn)，給出技術(shù)背景與專業(yè)知識(shí)，幫助參與者了解上述問題的分歧，并探討業(yè)界可如何處理并解決這些問題。
CALEA 安全挑戰(zhàn)
安全服務(wù)的目標(biāo)在于保障隱私、數(shù)據(jù)包完整性、認(rèn)證與不可否認(rèn)性。以下我們給出這四項(xiàng)的簡(jiǎn)單定義：
隱私：數(shù)據(jù)包不能被截取。
數(shù)據(jù)包完整性：數(shù)據(jù)包未被修改。
認(rèn)證：參與通信者是他/她指定的人
不可否認(rèn)性：發(fā)送與接收的消息不可否認(rèn)。
在本文中，數(shù)據(jù)包可為數(shù)據(jù)、語音、信號(hào)、視頻、影像或任何其它格式。 CALEA 是電子監(jiān)控的另一說法，指執(zhí)法人員接入通信通道進(jìn)行信息截取（而不是修改）。但是，CALEA 的目的似乎與安全性目標(biāo)相沖突，但是，我們確實(shí)有截取 VoP 數(shù)據(jù)包的執(zhí)法需求。在 VoP 上支持 CALEA 對(duì)反恐斗爭(zhēng)非常有意義，因?yàn)樵S多恐怖活動(dòng)都在因特網(wǎng)上發(fā)生。美國通信工業(yè)協(xié)會(huì) (TIA) 力推因特網(wǎng)上的 CALEA，目前還在為 PSTN 與分組網(wǎng)絡(luò)上的 CALEA 制定標(biāo)準(zhǔn)。此外，美國聯(lián)邦通信委員會(huì) (FCC) 希望對(duì)分組網(wǎng)絡(luò)的 CALEA 支持加以管理。所有美國 PSTN 一直都支持 CALEA，但在 VoP 網(wǎng)絡(luò)上支持 CALEA 尚未完全實(shí)施，分組網(wǎng)絡(luò)支持它的最終期限也延長至 2004 年 1 月 30 日。
從后勤角度看，分組網(wǎng)絡(luò)（特別是因特網(wǎng)）是否應(yīng)接受 FCC 電信規(guī)則管理尚有爭(zhēng)論。從技術(shù)角度說，還有許多問題尚待解決。
安全機(jī)制
安全機(jī)制始于在兩個(gè)端點(diǎn)間建立安全關(guān)聯(lián) (SA)。建立 SA 要求分兩步走：第一步是進(jìn)行兩個(gè)端點(diǎn)的認(rèn)證；第二步是交換加密與解密的密鑰。SA 建立后，兩個(gè)端點(diǎn)都用密鑰進(jìn)行加密與解密。
在兩個(gè)端點(diǎn)之間，數(shù)據(jù)路徑上還有許多其它設(shè)備要考慮到。如果路徑中至少有一個(gè)設(shè)備與 SA 建立相關(guān)，則 SA 處于傳輸模式。中間設(shè)備稱作安全網(wǎng)關(guān) (SG)，SG 具有從兩個(gè)端點(diǎn)進(jìn)行數(shù)據(jù)包加密與解密的密鑰，而兩個(gè)端點(diǎn)不能進(jìn)行數(shù)據(jù)包的加密與解密。因此，在傳輸模式中，SG 可提供截取盒子 (box) 所需的密鑰，以支持 CALEA。
如果路徑中沒有其它設(shè)備參與 SA 建立，則 SA 運(yùn)行于隧道模式。在這種情況下，只有這兩個(gè)端點(diǎn)具有加密與解密的密鑰。這時(shí)，執(zhí)法人員仍可截取數(shù)據(jù)包，但他們沒有密鑰就無法進(jìn)行數(shù)據(jù)包解密。因此，隧道模式網(wǎng)絡(luò)不采取新方法就無法支持 CALEA。
呼叫信號(hào)發(fā)送與 CALEA
在 VoP 網(wǎng)絡(luò)中，信號(hào)數(shù)據(jù)包采用與媒體路徑不同的路徑。信號(hào)數(shù)據(jù)包在端點(diǎn)與呼叫服務(wù)器 (CS) 或代理服務(wù)器 (PS) 之間傳輸，而媒體數(shù)據(jù)包則在兩個(gè)端點(diǎn)間傳輸。端點(diǎn)與 CS 或 PS 之間通常有一個(gè) SA，兩個(gè)端點(diǎn)間通常也有一個(gè) SA。每個(gè) SA 都彼此獨(dú)立。端點(diǎn)與 CS 之間的 SA 可對(duì)所有呼叫建立一次，也可對(duì)每次呼叫分別建立。但是，端點(diǎn)與 PS 之間的 SA 則必須在兩個(gè)端點(diǎn)間每次呼叫的 SA 之前建立。為了防止干擾信號(hào)，SA 必須具有有限的時(shí)限，通常為幾秒鐘至幾分鐘。如果時(shí)限過期，則 SA 將斷開。因此，SA 必須在時(shí)限過期前重新建立或更新。
在信號(hào)數(shù)據(jù)包內(nèi)，媒體路徑在會(huì)話描述協(xié)議 (SDP) 等不同的協(xié)議中指定。媒體路徑由多個(gè)參數(shù)決定，如應(yīng)用端口、RTP/RTCP 端口以及 IP 端口。如果執(zhí)法人員不能進(jìn)行信號(hào)發(fā)送路徑與媒體描述協(xié)議的解密與解釋，則執(zhí)法人員就不知道兩個(gè)端點(diǎn)間選擇了哪條路徑，因此也就無法進(jìn)行媒體數(shù)據(jù)包的截取與解釋。
NAT 與 CALEA
網(wǎng)絡(luò)地址轉(zhuǎn)換 (NAT) 用于設(shè)備中將一系列專用 IP 地址映射到一個(gè)或更多公用 IP 地址中。對(duì) SIP、SNTP、FTP 等不同應(yīng)用，每個(gè)應(yīng)用中必須實(shí)施專用算法 (ALG) 以支持 NAT。
當(dāng) 端點(diǎn)進(jìn)行數(shù)據(jù)包（其在報(bào)頭與媒體描述字段如 SDP 中帶有專用 IP 地址）加密時(shí)，NAT 器件必須有進(jìn)行數(shù)據(jù)包解密的密鑰以及修改報(bào)頭與媒體描述字段中地址字段所需的密鑰，否則它就必須關(guān)閉 NAT 功能，并向每個(gè)設(shè)備分配公用 IP 地址。如果端點(diǎn)不愿向 NAT 器件提供密鑰，則 NAT 器件可實(shí)施與 CALEA 截取盒 (intercept box) 獲得相同密鑰的安全與 CALEA 機(jī)制。但是，NAT 器件與執(zhí)法人員不同，它不能獲得授權(quán)合法進(jìn)行數(shù)據(jù)包截取與解釋。
執(zhí)法人員必須具有密鑰，并得到帶有 ALG 的 NAT 的支持，這樣應(yīng)用才能截取來自目標(biāo)設(shè)備的數(shù)據(jù)包。這里的挑戰(zhàn)在于如何知道應(yīng)將哪個(gè)專用 IP 地址映射到給定公用 IP 地址。此外，截取盒必須從 NAT 器件得到此信息。
不同的安全與加密協(xié)議
可用的安全協(xié)議有很多種。舉例來說，有 IPSec、SSH、SRTP 等。在每個(gè)安全協(xié)議中可能采用不同的加密/解密協(xié)議。不管是數(shù)據(jù)加密標(biāo)準(zhǔn) (DES)、三重?cái)?shù)據(jù)加密標(biāo)準(zhǔn) (3DES)，還是高級(jí)加密標(biāo)準(zhǔn) (AES)，IPSec 可與任何加密協(xié)議共同使用。每個(gè)加密協(xié)議中還可使用不同的密鑰大小。加密協(xié)議、密鑰大小以及其它參數(shù)在 SA 建立時(shí)協(xié)商制定。CALEA 截取盒必須能夠支持各種安全協(xié)議、加密方法及其相關(guān)參數(shù)（如密鑰大小）。
軟硬件加密的比較
加密要占用大量的處理時(shí)間。為提高效率，某些設(shè)備用硬件進(jìn)行加密/解密。由于硬件加密只是針對(duì)一種加密協(xié)議，因此 CALEA 截取盒很難為多種安全與加密協(xié)議提供硬件加密。當(dāng)目標(biāo)設(shè)備可能用硬件進(jìn)行加密/解密時(shí)，CALEA 截取盒必須配備快速處理器進(jìn)行加密。
安全機(jī)制與CALEA
“PacketCable 安全規(guī)范”PKT-SP-SEC-I109-030728 與“PacketCable 電子監(jiān)控規(guī)范”PKT-SP-ESP-I102-030815 僅指定了傳輸模式的安全模型。這兩個(gè)規(guī)范沒有提到如何處理隧道模式的情況。
“PacketCable 電子監(jiān)控規(guī)范”顯示，安全傳輸模式由 CMTS 執(zhí)行，而不是由 PC 或 IP 電話 (IPP)等端點(diǎn)執(zhí)行。但是，目前 VoP 市場(chǎng)上的安全性大多數(shù)實(shí)施于端點(diǎn)上，且其中大部分為隧道模式，因此 PacketCable 必須處理這種安全架構(gòu)。
前面各部分中列出的 CALEA 面臨的其它安全問題同樣也是 PacketCable 的問題。
解決方案 為了解決 CALEA 的安全問題，CALEA 截取盒必須在 SA 建立的初期截取發(fā)自目標(biāo)設(shè)備的數(shù)據(jù)包，以獲得所需的密鑰以及其它安全參數(shù)。在哪里進(jìn)行截取取決于以下諸多因素：NAT、動(dòng)態(tài)主機(jī)配置協(xié)議 (DHCP)、VPN/安全端點(diǎn)等。
如果 VPN/安全端點(diǎn)為 PC 或 IPP，則端點(diǎn)如何獲得 IP 地址非常重要。如果端點(diǎn) IP 地址通過動(dòng)態(tài)主機(jī)配置協(xié)議 (DHCP) 獲得，則不存在 NAT，截取可在任何設(shè)備中進(jìn)行。但是，來自相同設(shè)備的數(shù)據(jù)包可能選擇不同的路由，因此，我們最好在數(shù)據(jù)包選擇另一路徑前（通常是從 CMTS 到因特網(wǎng)）截取數(shù)據(jù)包。
有 NAT 時(shí)，最好的截取處就是 NAT 功能所在的地方。正如“PacketCable 電子監(jiān)控規(guī)范”定義的一樣，這常常是 MTA，而不是 CMTS。但是，NAT 也可能在 CMTS 上。NAT 單元將專用 IP 地址映射到公用 IP 地址上，反之亦然，因此數(shù)據(jù)包應(yīng)在執(zhí)行 NAT 之前在 LAN 站點(diǎn)上截取。否則，截取盒就要在相同公用 IP 地址的混合消息流中進(jìn)行數(shù)據(jù)包過濾。此外，NAT 單元帶有應(yīng)用算法 (ALG)，可處理專用的轉(zhuǎn)換功能。例如，最初傳送進(jìn)來的 SIP 呼叫只有公用 IP 地址。NAT 單元如何知道應(yīng)該映射到哪個(gè)專用 IP 地址呢？它必須運(yùn)行 SIP ALG，其以 SIP 消息中的用戶 ID（如alice@wonderlane.com）或報(bào)頭中的 CallerID 來查找 Alice 的專用 IP 地址。請(qǐng)注意，Alice 必須已經(jīng)以她專用的 IP 地址及其姓名和/或 CallerID 在 NAT 器件上注冊(cè)。
一旦 CALEA 截取盒能夠截取目標(biāo)設(shè)備的數(shù)據(jù)包，則其應(yīng)設(shè)法獲得 SA建立消息。如果安全機(jī)制不是基于標(biāo)準(zhǔn)協(xié)議之上，則執(zhí)法人員解釋安全消息以及隨后進(jìn)行 SA 消息與媒體數(shù)據(jù)包的解密就會(huì)面臨很大的困難。如果安全消息基于標(biāo)準(zhǔn)協(xié)議之上，則 CALEA 截取盒應(yīng)該可從 SA 建立消息計(jì)算出密鑰、密鑰大小以及加密方法。
美國 TIA 發(fā)布了一系列 PSTN 中 CALEA 的消息格式。由于因特網(wǎng)的架構(gòu)、協(xié)議集、消息格式與呼叫流程 (call flow) 完全不同，因此 TIA 必須發(fā)布因特網(wǎng) CALEA 傳輸?shù)娜孪盗幸?guī)范。PacketCable 規(guī)范可作為子集，事實(shí)上 TIA 也提到了這些情況。但是，PacketCable 安全規(guī)范與 PacketCable 電子監(jiān)控的修改必須滿足許多 VoP 安全要求。此外，盡管原理相同，非基于線纜的 VoP 安全解決方案應(yīng)在 PacketCable 規(guī)范外另行規(guī)定。
結(jié)論
VoP 網(wǎng)絡(luò)中的 CALEA 面臨許多新的安全挑戰(zhàn)，主要挑戰(zhàn)就是如何截取發(fā)自或發(fā)往目標(biāo)設(shè)備的數(shù)據(jù)包以及如何進(jìn)行數(shù)據(jù)包的解釋與加密/解密。本文提出了一些 VoP 網(wǎng)絡(luò)安全" title="網(wǎng)絡(luò)安全">網(wǎng)絡(luò)安全問題的解決方案，但還有一些 VoP 廠商、服務(wù)提供商與執(zhí)法人員面臨的難題未能解決。解決這些問題將推動(dòng)業(yè)界實(shí)現(xiàn)下一步發(fā)展。