分組語音VoIP網(wǎng)絡的CALEA安全挑戰(zhàn)

　　盡管許多寬帶 VPN 運行于隧道模式，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)關 (MG) 連接至多媒體終端適配器/線纜調(diào)制解調(diào)器 (MTA/CM) 以及隧道。只有這些具體的終端設備知道密鑰及相關參數(shù)。另一個要考慮的問題則是安全 RTP (SRTP)，它提供語音的端至端加密。不僅加密/解密是一個挑戰(zhàn)，在某些情況下截取消息也困難。具體而言，其實例之一就是在 NAT 存在時嘗試加密/解密。

　　在本論述中，德州儀器 (TI) 將研究上述安全挑戰(zhàn)，給出技術背景與專業(yè)知識，幫助參與者了解上述問題的分歧，并探討業(yè)界可如何處理并解決這些問題。

　　CALEA 安全挑戰(zhàn)

　　安全服務的目標在于保障隱私、數(shù)據(jù)包完整性、認證與不可否認性。以下我們給出這四項的簡單定義：

　　隱私：數(shù)據(jù)包不能被截取。

　　數(shù)據(jù)包完整性：數(shù)據(jù)包未被修改。

　　認證：參與通信者是他/她指定的人

　　不可否認性：發(fā)送與接收的消息不可否認。

　　在本文中，數(shù)據(jù)包可為數(shù)據(jù)、語音、信號、視頻、影像或任何其它格式。 CALEA 是電子監(jiān)控的另一說法，指執(zhí)法人員接入通信通道進行信息截�。ǘ�不是修改）。但是，CALEA 的目的似乎與安全性目標相沖突，但是，我們確實有截取 VoP 數(shù)據(jù)包的執(zhí)法需求。在 VoP 上支持 CALEA 對反恐斗爭非常有意義，因為許多恐怖活動都在因特網(wǎng)上發(fā)生。美國通信工業(yè)協(xié)會 (TIA) 力推因特網(wǎng)上的 CALEA，目前還在為 PSTN 與分組網(wǎng)絡上的 CALEA 制定標準。此外，美國聯(lián)邦通信委員會 (FCC) 希望對分組網(wǎng)絡的 CALEA 支持加以管理。所有美國 PSTN 一直都支持 CALEA，但在 VoP 網(wǎng)絡上支持 CALEA 尚未完全實施，分組網(wǎng)絡支持它的最終期限也延長至 2004 年 1 月 30 日。

　　從后勤角度看，分組網(wǎng)絡（特別是因特網(wǎng)）是否應接受 FCC 電信規(guī)則管理尚有爭論。從技術角度說，還有許多問題尚待解決。

　　安全機制

　　安全機制始于在兩個端點間建立安全關聯(lián) (SA)。建立 SA 要求分兩步走：第一步是進行兩個端點的認證；第二步是交換加密與解密的密鑰。SA 建立后，兩個端點都用密鑰進行加密與解密。

　　在兩個端點之間，數(shù)據(jù)路徑上還有許多其它設備要考慮到。如果路徑中至少有一個設備與 SA 建立相關，則 SA 處于傳輸模式。中間設備稱作安全網(wǎng)關 (SG)，SG 具有從兩個端點進行數(shù)據(jù)包加密與解密的密鑰，而兩個端點不能進行數(shù)據(jù)包的加密與解密。因此，在傳輸模式中，SG 可提供截取盒子 (box) 所需的密鑰，以支持 CALEA。

　　如果路徑中沒有其它設備參與 SA 建立，則 SA 運行于隧道模式。在這種情況下，只有這兩個端點具有加密與解密的密鑰。這時，執(zhí)法人員仍可截取數(shù)據(jù)包，但他們沒有密鑰就無法進行數(shù)據(jù)包解密。因此，隧道模式網(wǎng)絡不采取新方法就無法支持 CALEA。

　　呼叫信號發(fā)送與 CALEA

　　在 VoP 網(wǎng)絡中，信號數(shù)據(jù)包采用與媒體路徑不同的路徑。信號數(shù)據(jù)包在端點與呼叫服務器 (CS) 或代理服務器 (PS) 之間傳輸，而媒體數(shù)據(jù)包則在兩個端點間傳輸。端點與 CS 或 PS 之間通常有一個 SA，兩個端點間通常也有一個 SA。每個 SA 都彼此獨立。端點與 CS 之間的 SA 可對所有呼叫建立一次，也可對每次呼叫分別建立。但是，端點與 PS 之間的 SA 則必須在兩個端點間每次呼叫的 SA 之前建立。為了防止干擾信號，SA 必須具有有限的時限，通常為幾秒鐘至幾分鐘。如果時限過期，則 SA 將斷開。因此，SA 必須在時限過期前重新建立或更新。

　　在信號數(shù)據(jù)包內(nèi)，媒體路徑在會話描述協(xié)議 (SDP) 等不同的協(xié)議中指定。媒體路徑由多個參數(shù)決定，如應用端口、RTP/RTCP 端口以及 IP 端口。如果執(zhí)法人員不能進行信號發(fā)送路徑與媒體描述協(xié)議的解密與解釋，則執(zhí)法人員就不知道兩個端點間選擇了哪條路徑，因此也就無法進行媒體數(shù)據(jù)包的截取與解釋。

　　NAT 與 CALEA

　　網(wǎng)絡地址轉(zhuǎn)換 (NAT) 用于設備中將一系列專用 IP 地址映射到一個或更多公用 IP 地址中。對 SIP、SNTP、FTP 等不同應用，每個應用中必須實施專用算法 (ALG) 以支持 NAT。

當　　端點進行數(shù)據(jù)包（其在報頭與媒體描述字段如 SDP 中帶有專用 IP 地址）加密時，NAT 器件必須有進行數(shù)據(jù)包解密的密鑰以及修改報頭與媒體描述字段中地址字段所需的密鑰，否則它就必須關閉 NAT 功能，并向每個設備分配公用 IP 地址。如果端點不愿向 NAT 器件提供密鑰，則 NAT 器件可實施與 CALEA 截取盒 (intercept box) 獲得相同密鑰的安全與 CALEA 機制。但是，NAT 器件與執(zhí)法人員不同，它不能獲得授權合法進行數(shù)據(jù)包截取與解釋。

　　執(zhí)法人員必須具有密鑰，并得到帶有 ALG 的 NAT 的支持，這樣應用才能截取來自目標設備的數(shù)據(jù)包。這里的挑戰(zhàn)在于如何知道應將哪個專用 IP 地址映射到給定公用 IP 地址。此外，截取盒必須從 NAT 器件得到此信息。

　　不同的安全與加密協(xié)議

　　可用的安全協(xié)議有很多種。舉例來說，有 IPSec、SSH、SRTP 等。在每個安全協(xié)議中可能采用不同的加密/解密協(xié)議。不管是數(shù)據(jù)加密標準 (DES)、三重數(shù)據(jù)加密標準 (3DES)，還是高級加密標準 (AES)，IPSec 可與任何加密協(xié)議共同使用。每個加密協(xié)議中還可使用不同的密鑰大小。加密協(xié)議、密鑰大小以及其它參數(shù)在 SA 建立時協(xié)商制定。CALEA 截取盒必須能夠支持各種安全協(xié)議、加密方法及其相關參數(shù)（如密鑰大�。�。

　　軟硬件加密的比較

　　加密要占用大量的處理時間。為提高效率，某些設備用硬件進行加密/解密。由于硬件加密只是針對一種加密協(xié)議，因此 CALEA 截取盒很難為多種安全與加密協(xié)議提供硬件加密。當目標設備可能用硬件進行加密/解密時，CALEA 截取盒必須配備快速處理器進行加密。

　　安全機制與CALEA

　　“PacketCable 安全規(guī)范”PKT-SP-SEC-I109-030728 與“PacketCable 電子監(jiān)控規(guī)范”PKT-SP-ESP-I102-030815 僅指定了傳輸模式的安全模型。這兩個規(guī)范沒有提到如何處理隧道模式的情況。

　　“PacketCable 電子監(jiān)控規(guī)范”顯示，安全傳輸模式由 CMTS 執(zhí)行，而不是由 PC 或 IP 電話 (IPP)等端點執(zhí)行。但是，目前 VoP 市場上的安全性大多數(shù)實施于端點上，且其中大部分為隧道模式，因此 PacketCable 必須處理這種安全架構。

　　前面各部分中列出的 CALEA 面臨的其它安全問題同樣也是 PacketCable 的問題。

　　解決方案 為了解決 CALEA 的安全問題，CALEA 截取盒必須在 SA 建立的初期截取發(fā)自目標設備的數(shù)據(jù)包，以獲得所需的密鑰以及其它安全參數(shù)。在哪里進行截取取決于以下諸多因素：NAT、動態(tài)主機配置協(xié)議 (DHCP)、VPN/安全端點等。

　　如果 VPN/安全端點為 PC 或 IPP，則端點如何獲得 IP 地址非常重要。如果端點 IP 地址通過動態(tài)主機配置協(xié)議 (DHCP) 獲得，則不存在 NAT，截取可在任何設備中進行。但是，來自相同設備的數(shù)據(jù)包可能選擇不同的路由，因此，我們最好在數(shù)據(jù)包選擇另一路徑前（通常是從 CMTS 到因特網(wǎng)）截取數(shù)據(jù)包。

　　有 NAT 時，最好的截取處就是 NAT 功能所在的地方。正如“PacketCable 電子監(jiān)控規(guī)范”定義的一樣，這常常是 MTA，而不是 CMTS。但是，NAT 也可能在 CMTS 上。NAT 單元將專用 IP 地址映射到公用 IP 地址上，反之亦然，因此數(shù)據(jù)包應在執(zhí)行 NAT 之前在 LAN 站點上截取。否則，截取盒就要在相同公用 IP 地址的混合消息流中進行數(shù)據(jù)包過濾。此外，NAT 單元帶有應用算法 (ALG)，可處理專用的轉(zhuǎn)換功能。例如，最初傳送進來的 SIP 呼叫只有公用 IP 地址。NAT 單元如何知道應該映射到哪個專用 IP 地址呢？它必須運行 SIP ALG，其以 SIP 消息中的用戶 ID（如alice@wonderlane.com）或報頭中的 CallerID 來查找 Alice 的專用 IP 地址。請注意，Alice 必須已經(jīng)以她專用的 IP 地址及其姓名和/或 CallerID 在 NAT 器件上注冊。

　　一旦 CALEA 截取盒能夠截取目標設備的數(shù)據(jù)包，則其應設法獲得 SA建立消息。如果安全機制不是基于標準協(xié)議之上，則執(zhí)法人員解釋安全消息以及隨后進行 SA 消息與媒體數(shù)據(jù)包的解密就會面臨很大的困難。如果安全消息基于標準協(xié)議之上，則 CALEA 截取盒應該可從 SA 建立消息計算出密鑰、密鑰大小以及加密方法。

　　美國 TIA 發(fā)布了一系列 PSTN 中 CALEA 的消息格式。由于因特網(wǎng)的架構、協(xié)議集、消息格式與呼叫流程 (call flow) 完全不同，因此 TIA 必須發(fā)布因特網(wǎng) CALEA 傳輸?shù)娜�新系列�?guī)范。PacketCable 規(guī)范可作為子集，事實上 TIA 也提到了這些情況。但是，PacketCable 安全規(guī)范與 PacketCable 電子監(jiān)控的修改必須滿足許多 VoP 安全要求。此外，盡管原理相同，非基于線纜的 VoP 安全解決方案應在 PacketCable 規(guī)范外另行規(guī)定。

　　結論

　　VoP 網(wǎng)絡中的 CALEA 面臨許多新的安全挑戰(zhàn)，主要挑戰(zhàn)就是如何截取發(fā)自或發(fā)往目標設備的數(shù)據(jù)包以及如何進行數(shù)據(jù)包的解釋與加密/解密。本文提出了一些 VoP 網(wǎng)絡安全問題的解決方案，但還有一些 VoP 廠商、服務提供商與執(zhí)法人員面臨的難題未能解決。解決這些問題將推動業(yè)界實現(xiàn)下一步發(fā)展。

作者：德州儀器 Sophia Scoggins 博士 來源：《世界電子元器件》