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