密碼技術(shù)

要理解SSL就必須理解密碼系統(tǒng)、消息摘要函數(shù)(單向或散列函數(shù))和數(shù)字簽名，這些技術(shù)是許多文獻(xiàn)所討論的主題(比如[AC96)，提供了保密性、完整性和認(rèn)證的基礎(chǔ)。

密碼系統(tǒng)

假設(shè)Alice想給她的銀行發(fā)一個(gè)消息以劃轉(zhuǎn)資金，并希望這個(gè)消息是保密的，因?yàn)槠渲泻兴膸ぬ柡蛣澽D(zhuǎn)金額等信息。一種方案是使用密碼系統(tǒng)，將要傳輸?shù)男畔⑥D(zhuǎn)變?yōu)榧用苄问�，從而只能為希望他讀懂的人讀懂。一旦加密為這種形式，這條消息也許只能用一個(gè)密鑰來破譯，如果沒有，那么這條信息毫無用處，因?yàn)楹玫拿艽a系統(tǒng)可以使破譯難度高到入侵者認(rèn)為原文不值得他們花費(fèi)那么大的努力。

密碼系統(tǒng)有兩大類：常規(guī)的和公共密鑰。

常規(guī)密碼

又稱為對稱密碼，需要發(fā)送者和接收者共同持有一個(gè)密鑰：一小段用來加密和解密的秘密信息。如果這個(gè)密鑰是保密的，那么這條消息除了發(fā)送者和接受者以外可能沒有人可以閱讀。如果Alice和銀行共同持有一個(gè)密鑰，則可以互相發(fā)送保密信息。但是，私有通訊密鑰的選擇行為本身，卻可能不是無懈可擊的。

公共密鑰密碼

又稱為不對稱密碼，定義了一種使用兩個(gè)密鑰的算法以解決密鑰交換問題，一個(gè)密鑰用于加密，另一個(gè)用于解密，從而使簡單公布一個(gè)密鑰(公共的密鑰，簡稱：公鑰)而保留其他的(私有的密鑰，簡稱：私鑰)以接收保密消息成為可能。

任何人都可以用公鑰加密一條消息，而僅允許私鑰的持有者閱讀。如此，Alice就可能使用公鑰加密其保密消息，發(fā)送給私鑰的持有者(銀行)，只有銀行能夠?qū)λ饷堋?/p>

消息摘要

雖然Alice可能加密其消息使它稱為私有的，但仍應(yīng)注意到某些人可能會(huì)篡改或替換其原始消息，以劃轉(zhuǎn)資金到他們自己的帳戶。一種保證Alice消息完整性的方法是同時(shí)發(fā)一個(gè)其消息的簡單摘要給銀行，供銀行與消息本身比對，如果相符則消息正確。

這樣的方法被稱為消息摘要、單向函數(shù)或散列函數(shù)。消息摘要用于對較大而且變長的消息建立較短而且等長的一種表述，其設(shè)計(jì)使將摘要還原成消息極其困難，而且對兩個(gè)不同的消息幾乎不可能生成相同的摘要，從而排除了替換一個(gè)消息為另一個(gè)而維持相同摘要的可能性。

Alice面臨的另一個(gè)挑戰(zhàn)是要保證摘要發(fā)送到銀行的安全，如此，才能確保消息的完整性。

一種解決方法是在摘要中包含數(shù)字簽名。

數(shù)字簽名

當(dāng)Alice發(fā)送消息到銀行，銀行需要確認(rèn)此消息的確是她發(fā)送的，而不是入侵者盜用其帳號。為此，可以在消息中包含一個(gè)由Alice建立的數(shù)字簽名。

數(shù)字簽名是以加密的消息摘要和其他信息(比如一個(gè)流水號)以及發(fā)送者的私有密鑰建立的。雖然任何人都可能用公共密鑰解密簽名，但是只有簽發(fā)者知道其私有密鑰，也就是，只有密鑰的持有者才能簽發(fā)。包含在簽名中的摘要只對該消息有效，以確保沒有人可以改變摘要而保持簽名不變。

為了避免簽名日后被入侵者破譯和再利用，簽名包含有一個(gè)流水號。如此，萬一(只是假設(shè))Alice并沒有發(fā)送此消息，雖然她可能真的簽發(fā)過，銀行可以免遭其欺詐性指控。

證書

雖然Alice可能已經(jīng)發(fā)送了一個(gè)保密的消息給銀行，簽了名，并可以保證消息的完整性，但是她仍然需要確認(rèn)她的確是在和那個(gè)銀行通訊，也就是說，她需要確認(rèn)她用的公共密鑰的確對應(yīng)于銀行用的私有密鑰。同樣，銀行也需要驗(yàn)證此消息的簽名的確對應(yīng)于Alice的簽名。

如果各部分有驗(yàn)證其余部分一致性的證書，以確認(rèn)公共密鑰，并是由一個(gè)可以信任的代理所簽發(fā)的，那么他們雙方都可以肯定其通訊對象的身份。這個(gè)可以信任的代理稱為證書機(jī)構(gòu)(Certificate Authority)，其證書用于認(rèn)證。

證書的內(nèi)容

與一個(gè)公共密鑰關(guān)聯(lián)的證書有一個(gè)主題，即一個(gè)個(gè)體或者服務(wù)器或者其他實(shí)體的真實(shí)身份，如表1所示。主題中的信息包含身份信息(識別名[Distinguished Name])和公共密鑰，還包括發(fā)布此證書的證書機(jī)構(gòu)的名稱和簽名以及證書的有效期限，還可能會(huì)有證書機(jī)構(gòu)監(jiān)管者信息和流水號等附加信息。

表 1: Certificate Information

識別名用于在一個(gè)特定的上下文中指明身份，比如，一個(gè)個(gè)體可能有一個(gè)個(gè)人證書，同時(shí)還有一個(gè)其雇傭者的證書。X.509標(biāo)準(zhǔn)[X509]中定義了識別名的各個(gè)項(xiàng)及其名稱和縮寫(見表2)。

表 2: Distinguished Name Information

證書機(jī)構(gòu)可能會(huì)定義規(guī)定哪些識別名是可選的，而哪些是必須的一個(gè)規(guī)范，還可能對項(xiàng)的內(nèi)容和證書使用人數(shù)有所要求。比如，一個(gè)Netscape瀏覽器要求證書中的Common Name項(xiàng)必須是服務(wù)器名稱，此名稱可以是服務(wù)器域名的通配模式，形如：*.snakeoil.com 。

證書的二進(jìn)制形式用ASN.1記號法[X208] [PKCS]表示，記號法定義了如何表示內(nèi)容，編碼規(guī)則定義了如何將信息轉(zhuǎn)變成二進(jìn)制形式。證書的二進(jìn)制編碼使用了基于更通用的基本編碼規(guī)則(Basic Encoding Rules[BER])的識別名編碼規(guī)則(Distinguished Encoding Rules[DER])。為了在不能處理二進(jìn)制的情況下進(jìn)行傳輸，二進(jìn)制形式用Base64編碼方式[MIME]轉(zhuǎn)換成ASCII形式，其編碼結(jié)果是以開始和結(jié)束符號分隔的若干的行，稱為PEM形式(其名稱來源于"Privacy Enhanced Mail")，如下所示：

-----BEGIN CERTIFICATE-----
MIIC7jCCAlegAwIBAgIBATANBgkqhkiG9w0BAQQFADCBqTELMAkGA1UEBhMCWFkx
FTATBgNVBAgTDFNuYWtlIERlc2VydDETMBEGA1UEBxMKU25ha2UgVG93bjEXMBUG
A1UEChMOU25ha2UgT2lsLCBMdGQxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhv
cml0eTEVMBMGA1UEAxMMU25ha2UgT2lsIENBMR4wHAYJKoZIhvcNAQkBFg9jYUBz
bmFrZW9pbC5kb20wHhcNOTgxMDIxMDg1ODM2WhcNOTkxMDIxMDg1ODM2WjCBpzEL
MAkGA1UEBhMCWFkxFTATBgNVBAgTDFNuYWtlIERlc2VydDETMBEGA1UEBxMKU25h
a2UgVG93bjEXMBUGA1UEChMOU25ha2UgT2lsLCBMdGQxFzAVBgNVBAsTDldlYnNl
cnZlciBUZWFtMRkwFwYDVQQDExB3d3cuc25ha2VvaWwuZG9tMR8wHQYJKoZIhvcN
AQkBFhB3d3dAc25ha2VvaWwuZG9tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB
gQDH9Ge/s2zcH+da+rPTx/DPRp3xGjHZ4GG6pCmvADIEtBtKBFAcZ64n+Dy7Np8b
vKR+yy5DGQiijsH1D/j8HlGE+q4TZ8OFk7BNBFazHxFbYI4OKMiCxdKzdif1yfaa
lWoANFlAzlSdbxeGVHoT0K+gT5w3UxwZKv2DLbCTzLZyPwIDAQABoyYwJDAPBgNV
HRMECDAGAQH/AgEAMBEGCWCGSAGG+EIBAQQEAwIAQDANBgkqhkiG9w0BAQQFAAOB
gQAZUIHAL4D09oE6Lv2k56Gp38OBDuILvwLg1v1KL8mQR+KFjghCrtpqaztZqcDt
2q2QoyulCgSzHbEGmi0EsdkPfg6mp0penssIFePYNI+/8u9HT4LuKMJX15hxBam7
dUHzICxBVC1lnHyYGjDuAMhe396lYAn8bCld1/L4NMGBCQ==
-----END CERTIFICATE-----

證書機(jī)構(gòu)

證書機(jī)構(gòu)在授予證書前會(huì)驗(yàn)證證書的申請信息，以確認(rèn)密鑰對中私有密鑰的持有實(shí)體。比如：如果Alice申請一個(gè)個(gè)人證書，則證書機(jī)構(gòu)首先會(huì)確認(rèn)Alice的確是申請證書的那個(gè)人。

證書鏈

一個(gè)證書機(jī)構(gòu)也可能給另一個(gè)證書機(jī)構(gòu)授予證書。所以，Alice可能需要檢查證書的授予者，及其父授予者，直到找到一個(gè)她所信任的。她可以只信任由一個(gè)有限的授予者鏈所授予的證書，以減小這個(gè)鏈中"劣質(zhì)"證書帶來的風(fēng)險(xiǎn)。

建立頂級CA

如前所述，每個(gè)證書要求其授予者指定證書主題中實(shí)體的有效性，直到最高一級的證書機(jī)構(gòu)。這樣就產(chǎn)生一個(gè)問題：最高一級的證書機(jī)構(gòu)沒有授予者，那么誰為它的證書作擔(dān)保呢？僅在這種情況下，此證書是"自簽名的"，即證書的授予者和主題中的一樣，所以，必須對自簽名的證書備加注意。頂級機(jī)構(gòu)廣泛發(fā)布的公共密鑰可以減小信任這個(gè)密鑰所帶來的風(fēng)險(xiǎn)--這顯然比其他某個(gè)人發(fā)布密鑰并宣稱他是證書機(jī)構(gòu)要安全一些。瀏覽器被默認(rèn)地配置為信任著名的證書機(jī)構(gòu)。

許多公司是專業(yè)證書機(jī)構(gòu)，如Thawte和VeriSign，提供如下服務(wù)：

• 驗(yàn)證證書的申請
• 處理證書的申請
• 授予和管理證書

自己建立一個(gè)證書機(jī)構(gòu)也是可能的，雖然在Internet環(huán)境中有風(fēng)險(xiǎn)，但在驗(yàn)證個(gè)體或服務(wù)器較容易的Intranet環(huán)境中，會(huì)很有用。

證書的管理

建立一個(gè)證書機(jī)構(gòu)需要一個(gè)堅(jiān)強(qiáng)的監(jiān)管、技術(shù)和管理體系。證書機(jī)構(gòu)不僅僅是授予證書，還必須管理證書的有效期和更新，并維護(hù)一個(gè)已授予的但已經(jīng)失效的證書列表(作廢證書列表[Certificate Revocation Lists，或CRL])。比如，Alice作為公司雇員有資格申請證書，又如，Alice離開公司后需要作廢此證書等。由于憑證書可以到處通行無阻，所以不可能從證書本身看出已經(jīng)作廢，因此，驗(yàn)證證書的有效性就必須查作廢證書列表(而這通常不是自動(dòng)處理的一部分)。

安全套接字層(SSL)

安全套接字層協(xié)議是位于可靠的面向連接的網(wǎng)絡(luò)層協(xié)議(如TCP/IP)和應(yīng)用程序協(xié)議層(如HTTP)之間的一種協(xié)議層。SSL通過互相認(rèn)證、使用數(shù)字簽名確保完整性、使用加密確保私密性，以實(shí)現(xiàn)客戶端和服務(wù)器之間的安全通訊。

這個(gè)協(xié)議被設(shè)計(jì)為支持許多用于密碼、摘要和簽名的特定算法，允許因各種目的對特定的服務(wù)器選擇算法，并允許采用新算法以得其利。其選擇的協(xié)商操作發(fā)生在客戶和服務(wù)器建立協(xié)議對話的開始階段。

表 4: Versions of the SSL protocol

如表4所示，SSL協(xié)議有多種版本。SSL3.0的一個(gè)優(yōu)點(diǎn)是增加了對加載證書鏈的支持，以允許服務(wù)器在發(fā)給瀏覽器的授予者證書上附加一個(gè)服務(wù)器證書。鏈的加載也允許瀏覽器驗(yàn)證服務(wù)器證書，即使對此授予者的證書機(jī)構(gòu)證書并沒有安裝，因?yàn)樗呀?jīng)包含在這個(gè)證書鏈中了。SSL3.0目前正由Internet Engineering Task Force(IETF)研發(fā)，是傳輸層安全[TLS]協(xié)議標(biāo)準(zhǔn)的基礎(chǔ)。

會(huì)話的建立

SSL會(huì)話在客戶端和服務(wù)器的握手過程之后建立，如Figure 1所示，其過程可能因服務(wù)器是否配置為支持服務(wù)器證書和是否要求有客戶證書有所不同。雖然存在密碼信息管理需要額外握手操作的情況，本文只說明其中有共性的部分，參見所有可能情況下的SSL規(guī)范。

Figure 1: Simplified SSL Handshake Sequence

客戶端和服務(wù)器的握手過程如下所示：

1. 協(xié)商用于數(shù)據(jù)傳輸?shù)拿艽a組
2. 建立并共享客戶端和服務(wù)器的會(huì)話密鑰
3. 可選的客戶端對服務(wù)器的認(rèn)證
4. 可選的服務(wù)器對客戶端的認(rèn)證

第一步的密碼組協(xié)商，允許客戶端和服務(wù)器選擇一個(gè)共同支持的密碼組。SSL3.0協(xié)議規(guī)范定義了31個(gè)密碼組。密碼組由以下各部分組成：

• 密鑰交換法
• 數(shù)據(jù)傳輸密碼
• 建立消息認(rèn)證代碼(Message Authentication Code[MAC])的消息摘要

此三個(gè)組成部分說明如下。

密鑰交換方法

密鑰交換法指明如何在客戶端和服務(wù)器的數(shù)據(jù)傳輸中使用共享的對稱密鑰。SSL2.0僅使用RSA密鑰交換，而SSL3.0可以在啟用證書時(shí)，選擇使用包括RSA的多種密鑰交換算法，以及無須證書和客戶端-服務(wù)器先期通訊的Diffie-Hellman密鑰交換法。

密鑰交換法的一個(gè)變數(shù)是數(shù)字簽名(可用可不用)，如果用，用哪一種。私有密鑰配合簽名可以確保在生成共享密鑰[AC96, p516]的信息交換過程中抵御攻擊。

數(shù)據(jù)傳輸密碼

SSL使用在前面加密對話消息中有所講述的常規(guī)密碼算法(對稱密碼)，可以有包括不加密在內(nèi)的九種選擇：

• No encryption
• Stream Ciphers
  • RC4 with 40-bit keys
  • RC4 with 128-bit keys
• CBC Block Ciphers
  • RC2 with 40 bit key
  • DES with 40 bit key
  • DES with 56 bit key
  • Triple-DES with 168 bit key
  • Idea (128 bit key)
  • Fortezza (96 bit key)

這里的"CBC"是Cipher Block Chaining，指在加密當(dāng)前塊時(shí)會(huì)用到先前已經(jīng)加密的部分文本；"DES"是Data Encryption Standard[AC96, ch12]，有多個(gè)變種(包括DES40和3DES_EDE)；"Idea"是現(xiàn)有最好的最堅(jiān)強(qiáng)的加密算法之一；"RC2"是RSADSI[AC96, ch13]的專屬的算法。

摘要函數(shù)

摘要函數(shù)指明對一個(gè)記錄單元如何建立摘要。SSL有如下支持：

• No digest (Null choice)
• MD5, a 128-bit hash
• Secure Hash Algorithm (SHA-1), a 160-bit hash

消息摘要用于建立加密的消息認(rèn)證碼(MAC)，與消息本身一同發(fā)送，以確保消息完整性并抵御還原攻擊。

握手序列協(xié)議

握手序列使用三個(gè)協(xié)議：

• SSL Handshake Protocol ，以完成客戶端和服務(wù)器之間對話的建立。
• SSL Change Cipher Spec Protocol ，以實(shí)際建立對話用密碼組的約定。
• SSL Alert Protocol ，在客戶端和服務(wù)器之間傳輸SSL出錯(cuò)消息。

這些協(xié)議和應(yīng)用協(xié)議的數(shù)據(jù)用 SSL Record Protocol 進(jìn)行封裝，如Figure 2所示，在不檢查數(shù)據(jù)的較底層的協(xié)議中傳輸。封裝協(xié)議對其底層協(xié)議來說是未知的。

Figure 2: SSL Protocol Stack

SSL控制協(xié)議對記錄協(xié)議的封裝，使一個(gè)正在進(jìn)行的對話在重協(xié)商其控制協(xié)議后得以安全地進(jìn)行傳輸。如果事先沒有建立對話，則會(huì)使用Null密碼組，也就是說，在建立對話以前，不使用密碼，且消息沒有完整性摘要。

數(shù)據(jù)傳輸

SSL記錄協(xié)議，如Figure 3所示，用于客戶端和服務(wù)器之間的傳輸應(yīng)用和SSL控制數(shù)據(jù)，可能把數(shù)據(jù)分割成較小的單元，或者組合多個(gè)較高層協(xié)議數(shù)據(jù)為一個(gè)單元。在使用底層可靠傳輸協(xié)議傳輸數(shù)據(jù)單元之前，它可能會(huì)對這些單元進(jìn)行壓縮、附著摘要簽名和加密(注意：目前所有主要SSL的實(shí)現(xiàn)都缺乏對壓縮的支持)。

Figure 3: SSL Record Protocol

保護(hù)HTTP通訊

SSL的一個(gè)常見的用途是保護(hù)瀏覽器和網(wǎng)絡(luò)服務(wù)器之間的網(wǎng)絡(luò)HTTP通訊，但這并排除應(yīng)用于不加保護(hù)的HTTP。其方法主要是，對普通HTTP加以SSL保護(hù)(稱為HTTPS)，但有一個(gè)重要的區(qū)別：它使用URL類型https而不是http ，而且使用不同的服務(wù)器端口(默認(rèn)的是443)。mod_ssl為Apache網(wǎng)絡(luò)服務(wù)器提供的功能主要就是這些了...

References

[AC96]

Bruce Schneier, Applied Cryptography, 2nd Edition, Wiley, 1996. See http://www.counterpane.com/ for various other materials by Bruce Schneier.

[X208]

ITU-T Recommendation X.208, Specification of Abstract Syntax Notation One (ASN.1), 1988. See for instance http://www.itu.int/rec/recommendation.asp?type=items&lang=e&parent=T-REC-X.208-198811-I.

[X509]

ITU-T Recommendation X.509, The Directory - Authentication Framework. See for instance http://www.itu.int/rec/recommendation.asp?type=folders&lang=e&parent=T-REC-X.509.

[PKCS]

Public Key Cryptography Standards (PKCS), RSA Laboratories Technical Notes, See http://www.rsasecurity.com/rsalabs/pkcs/.

[MIME]

N. Freed, N. Borenstein, Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies, RFC2045. See for instance http://ietf.org/rfc/rfc2045.txt.

[SSL2]

Kipp E.B. Hickman, The SSL Protocol, 1995. See http://www.netscape.com/eng/security/SSL_2.html.

[SSL3]

Alan O. Freier, Philip Karlton, Paul C. Kocher, The SSL Protocol Version 3.0, 1996. See http://www.netscape.com/eng/ssl3/draft302.txt.

[TLS1]

Tim Dierks, Christopher Allen, The TLS Protocol Version 1.0, 1999. See http://ietf.org/rfc/rfc2246.txt.