互連網上的密碼術

網際網路引入了大量與以往不同的安全性弱點。您正在與之通訊的組織或個人可能是您不認識的或者可能是偽裝成其他組織（個人）的組織或個人。不必過分猜疑這類問題，但有必要採取適當的預防措施來防止通過各種方式造成的損失，這些方式包括資金轉移、錯誤認證的結果、機密資訊丟失、毀約等。密碼術就是主要處理這類風險的，本文介紹了某些協議和相關機制，這些協議和相關機制與網際網路活動（包括，電子郵件）有特定的相關性。
與網際網路相關的協議和機制

請求注釋（Request for comment (RFC)）
請求注釋是由網際網路網路工程工作群組（IETF）管理的正式網際網路文檔，它用作傳播有關網際網路工程諮詢和意見資訊的一種方式。RFC 描述了開放標準，使那些可能希望或需要使用那些標準進行通訊的人受益。它們是由參與不同工作群組的志願者編寫的，發布在不同位置上，特別在 IETF 網站上。有關 TLS 的詳細資料（請參閱下面的描述）就是以這種格式表示的。

IPSec
IETF 的 IP 安全性協議工作群組目前正在定義 IP 的安全性附加協議，它是為 IP 資料報這一層提供認證、完整性和保密性服務的規範。在幾個 RFC 中對它都有描述，雖然是想專門用於 IP v.6.0 的，但它也可以用於 IP v. 4.0（IP v. 4.0 是當前標準，使用點分四組形式的地址，如 192.168.1.3）。它旨在用作對網際網路通訊（例如，為 VPN 和封裝隧道等）提供安全性的基礎。一些供應商和軟體組織正在開發或提供整合了 IPSec 的產品。例如，芬蘭的 SSH Communications Security 有一種稱為 IPSec Express 的產品，它是為方便符合 IPSec 的電子商務應用程式開發而設計的，而從 1999 年 6 月開始，NetBSD Foundation 已經將 IPSec 代碼合并到了 NetBSD 分發版中。

雖然 IPSec 已經成為網際網路安全性實現的一個事實上的標準，但卻受到來自 Niels Ferguson 和 Bruce Schneier（後者是被廣泛關注的 Blowfish 密碼的設計者）等人的批評。Ferguson 和 Schneier 認為 IPSec 已經變得過度複雜並趨於難以管理。他們說，這裡的問題是：對 IPSec 進行的內容增加並沒有以期望的方式增強該產品，而是為了滿足表達出來的廣泛興趣的願望和期望。他們不合時宜地將這種方法與 NIST 採用的方法進行對照以便選擇一種新的安全性演算法來代替 DES，在有關對稱密碼術的文章（第 2 部分）中對此作了描述。

他們的結論是：IPSec 比以前任何安全性協議都好得多，但聲稱其設計中固有的複雜性已經導致了大量模糊、矛盾、低效和其它一些弱點，併產生了極其難懂的一套規範，結果他們懷疑它是否能產生一個真正安全的作業系統。他們提出了許多具體的建議，但承認文檔的拙劣品質和協議的過度複雜性意味著他們沒有完全理解系統，這是對其經驗和權威的極大挑戰。正如他們指出的，讓 90% 的安全性起作用是不行的。坦率地說，他們十分不滿意使用當前形式的 IPSec，但更強烈地反對當前任何其它協議。因此，當這些其它協議不能保護網路的安全時，他們還是建議使用 IPSec。

安全 HTTP（Secure HTTP (S-HTTP)）
安全 HTTP（S-HTTP）是在應用程式層啟動並執行 HTTP 安全性擴充。它旨在當支援不可抵賴性以及允許使用多種密碼演算法和密鑰管理機制的同時，提供保密性和認證。雖然可以在會話之前獲得經 Kerberos 伺服器同意的初始密鑰，或者可以在一個會話中產生下一個會話要使用的密鑰，但通常將 RSA 用於初始密鑰協商。

安全通訊端層（Secure Sockets Layer (SSL)）
安全通訊端層（SSL）是由 Netscape Communications 開發的用來向網際網路會話提供安全性和保密性的握手協議。它支援伺服器和客戶機認證，並且被設計成協商加密金鑰以及在交換任何資料之前證明伺服器。它使用加密、認證和 MAC 來維護傳輸通道的完整性。

雖然 SSL 最適合用於 HTTP，但它也可以用於 FTP 或其它相關協議。它在傳輸層運行並且是獨立於應用程式的，因此象 FTP 或 HTTP 之類的相關協議可以放在該層之上。使用初始握手來對伺服器進行認證。在這一過程中，伺服器把認證提交到客戶機並指定要使用的首選密碼。然後，客戶機產生在即將進行的會話期間使用的秘鑰，然後將它提交給伺服器，並相應地用伺服器的公開金鑰對它加密。伺服器使用其私密金鑰解密訊息，恢複秘鑰，然後通過向客戶機發送一條使用該秘鑰加密的訊息來向客戶機認證自己。使用這一達成協議的秘鑰對加密的資料進行進一步的交換。

可以用第二階段（可選）來進一步增加安全性。這裡，伺服器發送一個質詢，客戶機對此作出響應，向伺服器返回該質詢的數位簽章和客戶機的密鑰憑證。

質詢階段通常是使用帶有用於訊息摘要的 MD5 的 RSA 執行的。也可以使用各種對稱密碼，包括 DES、三重 DES、IDEA、RC2 和 RC4。密鑰憑證符合 X.509 標準。SSL 目前的版本為 3.0。

SSL 先前的曆史給出了一個有關密碼產品的對等複查重要性的警告，特別是 Ian Goldberg 和 David Wagner（兩名加州大學的博士研究生）在 Dr Dobb's Journal 1996 年 2 月刊中寫了一篇文章，說明了他們是如何破解加密系統然後使用它的。

因為在那時，Netscape 不想發布關於 SSL 的結構或 SSL 所使用的密碼術和其它方法的任何資訊，Goldberg 和 Wagner 對相關演算法運用了逆向工程。他們發現用來產生偽隨機數（並由此隨機數產生秘鑰）的種子取決於日期、進程標識和父進程標識。擷取這兩個標識相對容易，至少對於在運行瀏覽器的 UNIX 機器上有帳戶的任何使用者來說是這樣。嗅探器用一秒鐘就可以完成資訊包的收集。該資訊將可能的種子的數目降低為一百萬，然後使用 HP 712/80 可以在不到半分鐘的時間內完成這些值的破解。

使用電腦產生一個真正的隨機值是很困難的，因此需要隨機數的程式將以儘可能隨機的方式產生一個種子，然後使用偽隨機數發生器（PRNG）從這個種子產生一個偽隨機數。然而，使用特定 PRNG 的同一種子將產生相同的數，該數被相應地用於加密體制演算法中，它將產生相同的密鑰。這對於它本身並不是弱點，但使原始的種子儘可能隨機地產生卻非常重要。應用程式通常會遇到非常難以預料或重複的事件，例如，晶片中的隨機電子雜訊、有雜訊的二極體、某個磁碟機的運轉、使用者擊鍵或者滑鼠移動等。在這種特殊情況下，乍看，使用三個元素來建立種子是合理的，並且剛開始的設計人員明顯也是這樣做的，但是進一步的分析卻揭示了一些局限性。請別人來為這類機制挑刺恰恰是對等複查的價值所在，如果一個系統最終被認為是良好的，這一點很關鍵。

傳輸層安全性（Transport Layer Security (TLS)）
傳輸層安全性（TLS）協議是 IETF 標準草案，它基於 SSL 並與之相似。它的主要目標是在兩個正在通訊的應用程式之間提供保密性和資料完整性。它由兩層構成。較低的層稱為 TLS Record 協議，且位於某個可靠的傳輸協議（例如，TCP）上面。這一層有兩個基本特性，具體說該串連是專用的並且是可靠的。它用於封裝各種更進階協議，但也可以不加密地使用。通常使用加密時，產生的用於這個加密的秘鑰專用於每個串連，這些秘鑰基於由另一個協議（例如，更進階別的 TLS Handshake 協議）協商的秘鑰。

TLS Handshake 協議提供了具有三個基本特性的串連安全性，即可以使用非對稱密碼術來認證對等方的身份，共用密鑰的協商是安全的，以及協商是可靠的。

與 SSL 一樣，TLS 是獨立於應用程式協議的，其使用的密碼編譯演算法的種類與 SSL 使用的相似。然而，TLS 標準把如何啟動 TLS 握手和如何解釋認證認證的決定權留給運行於其上層的協議的設計者和實現者來判斷。

TLS 協議的目標，按其優先順序順序來說，是密碼安全性、互通性和可擴充性。最後一個目標意味著 TLS 提供了一種架構，當新的和改進的非對稱以及其它加密方法可用時，便可以將它們引入該架構。

無線傳輸層安全性（Wireless Transport Layer Security (WTLS)）
無線應用程式協議（Wireless Application Protocol (WAP)）體繫結構中的安全性層協議稱為無線傳輸層層安全性（Wireless Transport Layer Security (WTLS)）。它在傳輸協議層之上操作，它是模組化的，是否使用它取決於給定應用程式所需求的安全性層級。WTLS 為 WAP 的上一層提供了保護其下的傳輸服務介面的安全傳輸服務介面。另外，它為管理安全連線提供了一個介面。

WTLS 與 TLS 非常相似，但它最適合用於等待時間相對長的窄帶傳輸網路。但是，它添加了一些新特性，例如，資料報支援、經過最佳化的握手和密鑰重新整理。與使用 TLS 一樣，它的主要目標是在兩個正在通訊的應用程式之間提供保密性、資料完整性和認證。

安全電子交易（Secure Electronic Transaction (SET)）
安全電子交易（SET）協議是由 VISA 和 MasterCard 國際財團開發的作為在開放網路上的進行安全銀行卡交易的方法。它支援 DES 和三重 DES 以實現成批資料加密，並支援用 RSA 對秘鑰和銀行卡號的公開金鑰進行加密。

雖然 SET 被認為是非常安全的，但太安全使它的速度相對很慢。另外，使用者需要正確發出的數位憑證，因此不能象 SSL 或 TLS 那樣以一種簡單的特別方式來使用它。由於這些原因，以及許多銀行將風險和銀行卡安全性漏洞的後果轉嫁給其商業客戶，所以 SET 的採用遠沒有開始設想的那麼多，這是個問題。然而，有跡象表明這正在改變。

安全廣域網路（Secure Wide Area Network (S/WAN)）
安全廣域網路倡議是由 RSA Data Security 推動的，它旨在促進基於網際網路的虛擬私人網路（Internet-based Virtual Private Networks (VPN)）的廣泛部署。S/WAN 支援 IP 級的加密，因此它比相似的 SSL 或 TLS 提供了更基本的、更低層級的安全性。VPN 是一種機制，設計成當使用者使用網際網路時，允許他們維護他們之間的安全隧道。例如，可以廉價地串連遠程辦公室，而不會增加成本，或者避免使用專門租用線路造成點對點的不便。對通過通道傳遞的訊息進行了加密，因此它們應該是安全的，可以避免第三方的有效截獲。實際上，並且部分由於不同標準的開發被設計成為一個或另一個公司帶來有競爭力的利益，造成理論和實踐嚴重脫節，尤其在互通性方面。S/WAN 倡議是給產生的混亂帶來一些秩序的一種嘗試。

雖然原始的 S/WAN 倡議不再進行了，但是在 Linux FreeS/WAN 和虛擬私人網路協會（Virtual Private Network Consortium）倡議中有非常相似的倡議。FreeS/WAN 是 IPSec （請參閱前面的描述）在 Red Hat Linux 中的實現，並有效地按照 GNU GPL 下提供了可以自製的 Linux 的 VPN 實現。

安全 Shell（SSH）
安全 Shell（SSH）是目前正在由 IETF 的 SECSH 工作群組標準化的協議。它允許網路上的安全遠端存取。可以使用多種方法來認證客戶機和伺服器並在支援 SSH 的系統之間建立加密的通訊通道。然後，這個串連可以用於許多方面，例如，建立 VPN 或者在伺服器上建立安全遠程登入以替換類似的 telnet、rlogin 或 rsh。

加密的電子郵件
為何提到加密的電子郵件呢？在許多情況下，它並沒有什麼不同，但是使用者應該理解，發送明文電子郵件等於發送一張任何人都可讀的明信片。電子郵件在一條不確定的、分段路由上傳輸，並且在沿途的許多點可以毫不費力地查看它。部分時間內，它儲存在網路郵件伺服器的半公開地區或 ISP 的儲存空間中。電子郵件還可能被錯誤路由或錯誤地成批發送：Network News 期刊中收錄了一名網路經理的文章，他誤將一張在他的頭像旁寫有“I am very munchable”（我很能吃）的圖象發送到了辦公樓裡的每台印表機，這個圖象原本是作為他妻子的私人 T-恤衫上的訊息。那當然不是電子郵件，但是電子郵件也很容易發生這樣的問題，而且同樣會造成尷尬。許多產品提供安全電子郵件，該電子郵件要麼作為使用 PGP（Pretty Good Privacy (PGP)，後面的文章中會詳細討論）的補充產品提供，要麼使用如安全 MIME (S/MIME) 之類的協議將數位簽章和加密工具添加到使用適當的客戶機（例如，Netscape）建立的郵件訊息中。MIME（多用途網際網路郵件擴充 (Multipurpose Internet Mail Extensions））是一種網際網路郵件標準化的格式，它允許以標準化的格式在電子郵件訊息中包含增強文本、音頻、圖形、視頻和類似的資訊。然而，MIME 不提供任何安全性元素 — S/MIME 添加了這些元素。S/MIME 已經得到了許多連網和訊息傳遞 ISV 的認可，包括 Netscape、Qualcomm、Microsoft、Lotus、Novell 以及其它 ISV。可以從 IETF 擷取資訊。

然而，將加密的電子郵件引入大型組織會引起一些新問題。反病毒產品可能未必一定識別加密的危險附件。另外，掃描程式和防火牆（其工作可能是確保阻止機密或非法資訊出入組織或部門）也可能有相似問題。

一種解決方案可能是在外部網關上加密和解密，但這會使電子郵件在通過公司網路傳輸時保持未加密狀態，這可能不太合適。在任何情況下，無論正在使用何種電子郵件客戶機，許多電子郵件加密包作為這些客戶機的附屬工具在案頭層級工作。但是，通過分散特定Alibaba Content Security Service性策略，在案頭掃描會使問題更複雜和難以強制執行。另一個選項 — 通常是笨拙和耗費資源的，但在某些環境中卻是適當的 — 可能是僅在將電子郵件的副本發送到集中式郵箱以進行解密和檢查的同時，才允許使用加密的電子郵件；這裡的困難包括流量加倍、訊息傳遞延遲、需要即時告知使用者實際情況以及可能給使用者帶來的不便。Giga Group 在最近的一次討論中提出了該問題，建議最滿意的解決方案是加密的電子郵件，然後發送到中繼器；在那裡，對其解密，並進行檢查以確定是否符合安全性策略以及有無病毒，為既定收件者進行加密，然後適時地重新發送。和以往一樣，最好的方法取決於權衡風險與所提解決方案的成本和不便。