le="display: block;">
支持互聯(lián)網(wǎng)的嵌入式設(shè)備日益受到人們的青睞,然而網(wǎng)絡(luò)安全問題制約了這些設(shè)備的發(fā)展,設(shè)計工程師必須采取適當(dāng)?shù)陌踩呗?。本文針對網(wǎng)絡(luò)安全性要求,介紹了網(wǎng)絡(luò)安全服務(wù)的概念、公共密鑰體系(KPI)和數(shù)字簽名以及加密和驗證技術(shù),并分析了安全套接層協(xié)議(SSL)和傳輸層安全協(xié)議(TLS)。
一般而言,互聯(lián)網(wǎng)安全是指保障數(shù)據(jù)在網(wǎng)絡(luò)中安全傳輸?shù)恼追?wù)。一些在網(wǎng)絡(luò)中傳輸?shù)男畔?如金融和法律文檔具有很強的保密性,不同的產(chǎn)品和應(yīng)用具有不同的安全性需求。
互聯(lián)網(wǎng)的安全服務(wù)很大程度上決定于服務(wù)提供商的可信任度。當(dāng)節(jié)點A需要將信用卡號發(fā)送至節(jié)點B時,穩(wěn)妥的方法是驗證節(jié)點B的真實身份。這時,節(jié)點A必須信任節(jié)點B,或信任為節(jié)點B身份進(jìn)行擔(dān)保的第三方?；ヂ?lián)網(wǎng)安全的核心就在于推進(jìn)不同網(wǎng)絡(luò)節(jié)點之間的信任關(guān)系。當(dāng)然,這絕不是盲目信任。例如,節(jié)點A可獲準(zhǔn)請求節(jié)點B的特定服務(wù),但不允許請求其它服務(wù),具體能獲得的服務(wù)取決于節(jié)點B對節(jié)點A的信任度。
在規(guī)定整套互聯(lián)網(wǎng)安全服務(wù)之前,每種產(chǎn)品都必須明確可能存在的安全威脅,并對網(wǎng)絡(luò)中其它節(jié)點所用的安全協(xié)議進(jìn)行評估(大多數(shù)HTTP服務(wù)器支持SSL協(xié)議)。
圖1顯示了信任等級的金字塔結(jié)構(gòu)。信任金字塔的最底層是完整性,完整性可確保兩個網(wǎng)絡(luò)節(jié)點之間的消息流不受到干擾。完整性得到保障的網(wǎng)絡(luò)通信信道可防止第三方的惡意信息影響節(jié)點間的正常通信,或改變信息流的正常順序,以及插入額外消息或在消息流中刪除消息。
完整性還包括鑒權(quán)。通過鑒權(quán)可以確定某個節(jié)點是否真的名副其實,如果節(jié)點A的身份得不到證實,那么就不能建立通信。交易的不可否認(rèn)性與鑒權(quán)密切相關(guān),它能確保發(fā)送方無法否認(rèn)成功傳送的數(shù)字簽名信息。
保密性可以保證消息的發(fā)送方和預(yù)期的接收方是唯一能在某個時間內(nèi)對消息流內(nèi)容進(jìn)行解密的兩個網(wǎng)絡(luò)實體,可以保護通信信道免遭被動攻擊,如數(shù)據(jù)包偵聽。實現(xiàn)保密性需要采用加密技術(shù),而保密性的最高保護形式是對節(jié)點A與B之間傳輸?shù)乃行畔⑦M(jìn)行加密。
信任金字塔的最高層是授權(quán)。一旦網(wǎng)絡(luò)客戶的身份得到驗證,將獲準(zhǔn)在服務(wù)器上請求各種服務(wù),如Telnet或FTP,但每個網(wǎng)絡(luò)客戶在服務(wù)器上獲得的授予權(quán)利不一定相同。初始授權(quán)一般歸屬于系統(tǒng)管理員,而網(wǎng)絡(luò)協(xié)議可以提供基本架構(gòu)以建立用戶身份標(biāo)識,并在網(wǎng)絡(luò)節(jié)點之間傳送授權(quán)。
上面概述了互聯(lián)網(wǎng)安全性的范圍,下面將描述安全互聯(lián)網(wǎng)信道的基本構(gòu)件模塊。這些構(gòu)件模塊包括:
1. 加密和解密；2. 數(shù)字簽名；3. 消息摘要(message digest)；4. 公共密鑰架構(gòu)；5. 證書。
加密和數(shù)字簽名
網(wǎng)絡(luò)通信加密可實現(xiàn)保密的信息傳輸,本文主要介紹兩類加密算法。第一類,也是最基本的一類是對稱加密。對稱加密最常用的加密方法是采用數(shù)據(jù)加密標(biāo)準(zhǔn)(DES),對稱加密方法的概念非常簡單,如圖2所示。
采用對稱加密方法時,節(jié)點B發(fā)送加密消息至節(jié)點A,原始數(shù)據(jù)均為明文,而加密后的數(shù)據(jù)則為密文。加密的過程中采用某些共享的保密數(shù)據(jù)(也稱為密鑰)將明文轉(zhuǎn)換為密文,再將密文轉(zhuǎn)換為明文。密鑰是加密和解密算法都必須采用的一段數(shù)據(jù)。
采用對稱加密方法的一個簡單實例就是ROT13。ROT13在加密過程中使ASCII文本的每個字符代碼加13,而在解密過程中則使每個字符代碼減13。加密后的取值受限于字母表的字母范圍,例如A轉(zhuǎn)換為N,P轉(zhuǎn)換為C。
為了采用對稱加密,節(jié)點B和節(jié)點A不僅需要對采用的算法達(dá)成一致,而且還必須對密鑰達(dá)成一致,這也是對稱加密的一個缺點。如果為確保安全通信,節(jié)點B和節(jié)點A必須預(yù)先了解算法和密鑰,那么如何建立一個安全的通信信道呢？這是一個經(jīng)典的先有雞還是先有蛋的問題。這里有兩種解決方案:
在安全通信信道建立之前,節(jié)點B將密鑰(可能還包括算法)發(fā)送至節(jié)點A。該解決方案一個明顯的缺點是任何對數(shù)據(jù)包進(jìn)行偵聽的人都可以獲得密鑰,從而能解密隨后所發(fā)送的任何消息。另一種方法是,密鑰(可能還包括算法)以另一種不同方式發(fā)送,這種發(fā)送過程可能要涉及到硬件設(shè)備、單獨的網(wǎng)絡(luò)協(xié)議或用作密鑰的密鑰口令,但不能以不安全的方式分發(fā)。
密鑰分配是安全系統(tǒng)的一個基本問題。Whitfield Diffie和Martin Hellman在“New Directions in Cryptographyformation Theory”一文中提出了一些改進(jìn)的方法。這些思想后來被稱為公共密鑰加密方法。本文將研究不對稱加密方法,而公共密鑰加密就是基于不對稱加密方法。不對稱加密方法具有兩套截然不同的密鑰,一套用于加密而另一套用于解密。發(fā)送方采用加密密鑰對消息加密,接收方則采用解密密鑰對消息解密。
公共密鑰加密方法進(jìn)一步提高了網(wǎng)絡(luò)的安全性。假定加密密鑰是公開的,但解密密鑰(私人密鑰)則為保密的,該密鑰只有接收方知道。消息發(fā)送方(節(jié)點B)采用公共密鑰對消息內(nèi)容加密,接收方(節(jié)點A)則采用私人密鑰對消息解密。由于只有節(jié)點A知道其私人密鑰,因此可以確保節(jié)點A是唯一能對消息解密的節(jié)點。公共密鑰加密方法如圖3所示。
某些不對稱加密算法也可逆向工作(最常用的是RSA)。在可逆算法中,私人或公共密鑰都可用于加密,而另一密鑰則用于解密。可逆算法適用于驗證身份,假定節(jié)點B希望向節(jié)點A證明身份,節(jié)點B可利用私人密鑰對一些眾所周知的數(shù)據(jù)(節(jié)點A事先已了解這些數(shù)據(jù))進(jìn)行加密,并將數(shù)據(jù)傳送給節(jié)點A。節(jié)點A利用節(jié)點B的公共密鑰對數(shù)據(jù)解密和比較。如果數(shù)據(jù)匹配,則表明節(jié)點B通過了身份驗證,因為只有節(jié)點B才能發(fā)送原始信息。
數(shù)字簽名也可基于可逆算法來實現(xiàn)。在這種情形下,節(jié)點B將采用私人密鑰對數(shù)據(jù)加密并傳送至節(jié)點A。之后,節(jié)點B不能否認(rèn)向節(jié)點A發(fā)送了數(shù)據(jù),因為只有節(jié)點B才能利用其私人密鑰對數(shù)據(jù)加密。采用公共密鑰加密的工作原理如圖4所示。
不對稱加密方法本身在安全方面與對稱加密方法相似,不對稱加密方法只是為密鑰發(fā)送提出了一種更可行的模型。決定加密方法優(yōu)劣的最主要因素是密鑰的長度以及解密密鑰的難易程度。只要時間和資金充足,任何加密方法都是可以被解密。能滿足下述條件的加密方法通常認(rèn)為是安全的:
1. 對加密方法解密所需的時間超過加密數(shù)據(jù)的有效存在期；
2. 解密加密方法的成本超過加密數(shù)據(jù)的自身價值。
與對稱加密方法相比,不對稱加密方法的主要缺點是加密所需的處理時間較長。例如,在互聯(lián)網(wǎng)上應(yīng)用最廣泛的RSA加密算法就需要對兩個非常大的質(zhì)數(shù)之積進(jìn)行因式分解。對稱加密方法的處理速率一般比不對稱加密方法高一個數(shù)量級,從而降低處理器的負(fù)荷。
因此,安全協(xié)議(如SSL/TLS)提供了密鑰安全交換的機制,一般密鑰通常采用公共密鑰加密策略傳送。在上述示例中,節(jié)點B生成密鑰并利用節(jié)點A的公共密鑰進(jìn)行加密,然后再傳送給節(jié)點A。由于只有節(jié)點A能解密該信息,因此在整個線路上發(fā)送該密鑰并不會降低密鑰的安全性。一旦節(jié)點A收到該消息,就可采用更快的密鑰方法(如DES)進(jìn)行通信。
消息摘要
消息摘要是將任意長度的位序列和密鑰作為輸入,輸出固定長度位序列的一種算法。輸出序列代表了輸入序列的內(nèi)容,而且算法可保證消息的完整性。輸入位的改變直接導(dǎo)致輸出改變。當(dāng)輸入與只被發(fā)送方和接收方所知的密鑰相結(jié)合時,消息摘要還可驗證身份。最常用的兩種消息摘要算法是消息摘要5(MD5)和安全散列算法1(SHA-1)。由于SHA-1通常采用的密鑰長度較長,因此安全性高于MD5。
摘要算法可用來計算消息載荷的消息驗證代碼(MAC),MAC可用作安全校驗和。只需以共享密鑰和消息載荷為輸入序列,即可采用上述任意一種摘要算法計算MAC。MAC不僅能為抵御網(wǎng)絡(luò)主動攻擊(如篡改或偽造消息包)提供保護,而且當(dāng)未采用加密時還可用來保障完整性(而非身份)。像SSL/TLS這些協(xié)議則采用了以上兩種MAC算法(MD5和SHA-1),這樣當(dāng)一種算法失效時,仍然能采用另一種算法保護消息。
MAC還可用于數(shù)字簽名。假定發(fā)送方和接收方在MAC計算中共享同一密鑰,發(fā)送方可采用MAC對消息載荷加密,而接收方同樣可采用共享密鑰計算MAC。只有當(dāng)兩者的MAC值匹配,發(fā)送方才能發(fā)送這條消息。
公共密鑰和證書
公共密鑰加密策略推動了三類網(wǎng)絡(luò)安全服務(wù)的發(fā)展:加密和解密、數(shù)字簽名和密鑰交換。本文不涉及密鑰管理問題,而主要討論以下問題:
1. 誰生成了這些密鑰對？2. 這些密鑰對存儲在何處？3. 怎樣確認(rèn)密鑰產(chǎn)生者的身份？
第一個問題很容易回答,可由身份明確的計算機生成密鑰。例如,網(wǎng)絡(luò)瀏覽器和一些電子郵件程序就包含生成這些密鑰對的軟件。這些密鑰存儲在本地計算機上,一經(jīng)生成即可公布公共密鑰。像SSL/TLS這些協(xié)議還包含一些規(guī)定網(wǎng)絡(luò)節(jié)點如何傳送公共密鑰的條款。
公共密鑰加密方法并不特別安全,如果任何計算機都能生成密鑰對,那么根本就不能進(jìn)行身份驗證。一些不良用戶可輕易地生成密鑰對,從而假冒第三方進(jìn)行通信。
上面的身份驗證問題可由認(rèn)證機構(gòu)(CA)解決。生成密鑰對時,將公共密鑰提交給CA。認(rèn)證機構(gòu)負(fù)責(zé)驗證提交密鑰對的個人或組織的身份和證明。驗證的級別從只驗證姓名和電子郵件地址到通過信用卡或信用報告驗證提交者的身份。
一旦CA驗證了提交者的身份,就會發(fā)給認(rèn)證證書。在網(wǎng)絡(luò)交易中,由證書建立單方或雙方的身份來建立一種信任關(guān)系。證書可由CA以數(shù)字方式進(jìn)行簽發(fā)。這樣,如果CA值得信任,那么就該相信CA頒發(fā)的證書,并信任經(jīng)過認(rèn)證過的公共密鑰。數(shù)字證書具有很多種形式,本文主要介紹的互聯(lián)網(wǎng)安全協(xié)議中常采用的。屬于ITU規(guī)范,此類證書通常包含:
1. 提交者公共密鑰；2. 發(fā)布證書(CA)的機構(gòu)名稱；3. 證書的有效期限；4. 數(shù)字簽名算法；
5. 認(rèn)證機構(gòu)的數(shù)字簽名。
SSL和TLS協(xié)議
在1995年,Netscape公司開發(fā)了安全套接層協(xié)議(SSL)并首先應(yīng)用于Navigator產(chǎn)品中。互聯(lián)網(wǎng)工程任務(wù)組(IETF)接受了該協(xié)議并最終發(fā)布了RFC 2246協(xié)議。SSL和TLS這兩個網(wǎng)絡(luò)協(xié)議非常相似,只是一些加密算法和MAC算法略有不同。本文將重點研究該協(xié)議,為簡化起見,將兩者統(tǒng)稱為TLS。TLS包含如下內(nèi)容:
1. 算法協(xié)商；2. 加密和解密；3. 通過MAC的消息驗證；4. 密鑰交換；5. 數(shù)字簽名。
如圖5所示,TLS必須位于某些可靠連接協(xié)議的上層,而可靠連接實際上就是指TCP。那些通常直接運行于TCP之上的高層協(xié)議,如HTTP和SMTP也可運行于TLS之上。目前已經(jīng)提出了將TLS與telnet、FTP、Kerberos及其它協(xié)議一起使用的互聯(lián)網(wǎng)草案。
TLS工具包一般用來精確地模擬套接字編程接口,具有套接字特征的API可以簡化高層協(xié)議(如HTTP)的編程實現(xiàn)。
實際上,TLS采用了兩種策略來保障協(xié)議安全。第一種采用不同的端口進(jìn)行安全的數(shù)據(jù)傳輸,這時高層協(xié)議必須偵聽常規(guī)端口以及用來傳輸網(wǎng)絡(luò)消息的安全端口。第二種策略在高層協(xié)議的常用端口必須區(qū)分常規(guī)傳輸流和安全傳輸流。HTTP協(xié)議采用第二種策略,當(dāng)URL以https://開頭時,就將在客戶端(網(wǎng)絡(luò)瀏覽器)和HTTP服務(wù)器之間建立安全信道。
TLS連接的會話的發(fā)起者總是客戶端。一個基于RSA加密算法的TLS會話建立過程如下(見圖6,其它的加密算法與該方法相似):
第1步,客戶端通過發(fā)送“hello”消息建立TLS連接。該消息包含協(xié)議版本號(SSL為3.0,TLS為3.1)、客戶端支持的加密方法、MAC和壓縮規(guī)則?？蛻舳诉€發(fā)送一串用以生成主秘(master secret)的隨機數(shù)；
第2步,服務(wù)器發(fā)送支持的TLS版本號,并選擇第1步中提出的一種加密方法/MAC。服務(wù)器也將發(fā)送一串用以生成主秘的隨機數(shù)；
第3步,服務(wù)器發(fā)送包含服務(wù)器公共密鑰的認(rèn)證；
第4步,服務(wù)器通知客戶端可以開始生成密鑰。如前所述,不對稱加密的計算量高于對稱加密,這就是為什么像SSL/TLS和IPSec這樣的協(xié)議會對應(yīng)用數(shù)據(jù)采用對稱加密的原因；
第5步,客戶端生成預(yù)主秘(premaster secret),這是另一串隨機數(shù)。預(yù)主秘采用服務(wù)器的公共密鑰進(jìn)行加密,并在第5步中發(fā)送至服務(wù)器。這時服務(wù)器和客戶端都生成主秘,主秘是專門為客戶端和服務(wù)器加密提供密鑰并被客戶端和服務(wù)器用來計算MAC的一串?dāng)?shù)據(jù)。主秘是根據(jù)客戶端和服務(wù)器上的隨機數(shù)和預(yù)主秘生成,并且不在線路上傳輸。一旦計算出主秘,就可進(jìn)行安全通信。
第6步,客戶端通知服務(wù)器:所有從客戶端發(fā)出的傳輸流將采用得到認(rèn)可的加密序列和獨立生成的密鑰信息進(jìn)行加密；
第7步,客戶端通知服務(wù)器,客戶端已完成了最初的握手連接。第7步的完成消息經(jīng)過了加密；
第8步,允許服務(wù)器通知客戶端,所有從服務(wù)器發(fā)出的傳輸流將進(jìn)行加密；
第9步,服務(wù)器發(fā)送“加密已完成”的消息到客戶端,這表明服務(wù)器完成了最初的握手連接；
在第10和第11步中,加密的應(yīng)用層傳輸流將在客戶端和服務(wù)器之間傳輸。這時,客戶端或服務(wù)器都可以請求結(jié)束連接。如果出現(xiàn)這種情形,客戶端或服務(wù)器將發(fā)送一條明確的提醒信息。
圖7顯示了相對簡單的TLS消息格式。可能的TLS消息格式有以下四種類型:握手、提醒、更改加密規(guī)范和應(yīng)用數(shù)據(jù)。
線路上的每次傳輸均可拆分成一系列單個或多個TLS記錄,TLS記錄的格式如圖8所示。
目前,TLS具有幾種公開源代碼的商用解決方案。RSA Security、Certicom和SPYRUS均推出了商用C語言實現(xiàn)方案。其中最常用的公開源代碼的C語言版本是OpenSSL,目前還存在其它一些版本。為實現(xiàn)與Apache網(wǎng)絡(luò)服務(wù)器集,公開源代碼的版本通常都做了適當(dāng)修改。
HTTP協(xié)議
HTTP協(xié)議具有兩種安全驗證方法:基本驗證和摘要驗證。在這兩種方法中,在客戶端通過用戶名/密碼對驗證自己的身份之前,服務(wù)器均可拒絕服務(wù)請求。作為HTTP客戶端,網(wǎng)絡(luò)瀏覽器可顯示一個對話框,以便用戶輸入用戶名/密碼對,然后將該請求再次提交給服務(wù)器。
基本驗證在線路上不對用戶名/密碼對進(jìn)行加密,盡管線路在其Base64編碼系統(tǒng)中對用戶名/密碼對進(jìn)行了編碼。在摘要驗證中,當(dāng)服務(wù)器拒絕服務(wù)請求時,服務(wù)器將向客戶端提供一個隨機數(shù),此隨機數(shù)是一段一次性使用的數(shù)據(jù),一旦客戶端獲得了用戶名/密碼對,即對用戶名、密鑰、隨機數(shù)、HTTP方法和請求的URL執(zhí)行Hash處理,而只把Hash值返回給服務(wù)器。這樣,密鑰將永遠(yuǎn)不會以明文的形式發(fā)出。盡管摘要驗證已經(jīng)在多年之前就定義了,但直到現(xiàn)在才逐漸得到廣泛應(yīng)用。
全文信息請訪問:
作者:Steve Kapp
首席技術(shù)官
EMRT咨詢公司
skapp@
