數字證書就是網絡通訊中標志通訊各方身份信息的一系列數據,其作用類似于現實生活中的身份證。它是由一個權威機構發行的,人們可以在互聯網上用它來識別對方的身份。
證書的格式遵循ITUTX.509國際標準
一個標準的X.509數字證書包含以下一些內容:
證書的版本信息;
證書的序列號,每個證書都有一個唯一的證書序列號;
證書所使用的簽名算法;
證書的發行機構名稱,命名規則一般采用X.500格式;
證書的有效期,現在通用的證書一般采用UTC時間格式,它的計時范圍為1950-2049;
證書所有人的名稱,命名規則一般采用X.500格式;
證書所有人的公開密鑰;
證書發行者對證書的簽名。
1.密碼學
在密碼學中,有一個五元組:{明文、密文、密鑰、加密算法、解密算法},對應的加密方案稱為密碼體制(或密碼)。
明文:是作為加密輸入的原始信息,即消息的原始形式所有可能明文的有限集稱為明文空間。
密文:是明文經加密變換后的結果,即消息被加密處理后的形式,所有可能密文的有限集稱為密文空間。
密鑰:是參與密碼變換的參數,一切可能的密鑰構成的有限集稱為密鑰空間。
加密算法:是將明文變換為密文的變換函數,相應的變換過程稱為加密,即編碼的過程。
解密算法:是將密文恢復為明文的變換函數,相應的變換過程稱為解密,即解碼的過程。
對稱算法:
加密和解密使用同一密鑰
主要算法包括:DES、3DES、RC2、RC4
加/解密速度快,但密鑰分發問題嚴重
非對稱算法:
不需要首先共享秘密
兩個密鑰同時產生:一把密鑰(公鑰)是公開的,任何人都可以得到。另一把密鑰(私人密鑰)只有密鑰的擁有者知道。
用其中一把密鑰(公鑰或者是私鑰)加密的信息,只能用另一把打開。
RSA算法,ECC(橢圓曲線)算法
由已知的公鑰幾乎不可能推導出私鑰
強度依賴于密鑰的長度
很慢-不適合加密大數據
公鑰可以廣泛地、開放地分發
用于加密,簽名/校驗,密鑰交換
數字摘要:
把可變輸入長度串轉換成固定長度輸出串的一種函數。稱輸出串為輸入串的指紋,或者數字摘要;
不同明文的摘要相同的概要是非常非常小的;而同樣明文其摘要必定一致;
明文的長度不固定,摘要的長度固定。
沒有密鑰
不可回溯
典型算法:MD5,SHA-1
用于完整性檢測,產生數字簽名
最好的解決方案:
使用對稱算法加密大的數據
每次加密先產生新的隨機密鑰
使用非對稱算法交換隨機產生的密鑰
用非對稱算法做數字簽名(對散列值即摘要做數字簽名)
四條基本規則
先簽名,然后加密
加密之前先壓縮
用你自己的私鑰做簽名
用接收者的公鑰做加密
加密:
解密:
怎樣解決4個通訊安全需求?
私密性 加密
完整性 ?
不可否認性 ?
身份認證? ?
數字簽名
數字簽名采用公鑰體制(PKI),即利用一對互相匹配的密鑰進行加密、解密。每個用戶自己設定一把特定的僅為本人所知的私有密鑰(私鑰),用它進行解密和簽名;同時設定一把公共密鑰(公鑰)并由本人公開,為一組用戶所共享,用于加密和驗證簽名。當發送一份保密文件時,發送方使用接收方的公鑰對數據加密,而接收方則使用自己的私鑰解密,這樣信息就可以安全無誤地到達目的地了。通過這種手段保證加密過程是一個不可逆過程,即只有用私有密鑰才能解密。在公開密鑰密碼體制中,常用的一種是RSA體制。其數學原理是將一個大數分解成兩個質數的乘積,加密和解密用的是兩個不同的密鑰。即使已知明文、密文和加密密鑰(公開密鑰),想要推導出解密密鑰(私密密鑰),在計算上是不可能的。按現在的計算機技術水平,要破解目前采用的1024位RSA密鑰,需要上千年的計算時間。公開密鑰技術解決了密鑰發布的管理問題,商戶可以公開其公開密鑰,而保留其私有密鑰。購物者可以用人人皆知的公開密鑰對發送的信息進行加密,安全地傳送給商戶,然后由商戶用自己的私有密鑰進行解密。
用戶也可以采用自己的私鑰對信息加以處理,由于密鑰僅為本人所有,這樣就產生了別人無法生成的文件,也就形成了數字簽名。采用數字簽名,能夠確認以下兩點:
(1)保證信息是由簽名者自己簽名發送的,簽名者不能否認或難以否認;
(2)保證信息自簽發后到收到為止未曾作過任何修改,簽發的文件是真實文件。
數字簽名具體做法是:
(1)將報文按雙方約定的HASH算法計算得到一個固定位數的報文摘要。在數學上保證:只要改動報文中任何一位,重新計算出的報文摘要值就會與原先的值不相符。這樣就保證了報文的不可更改性。
(2)將該報文摘要值用發送者的私人密鑰加密,然后連同原報文一起發送給接收者,而產生的報文即稱數字簽名。這樣就保證了簽發者不可否認性。
(3)接收方收到數字簽名后,用同樣的HASH算法對報文計算摘要值,然后與用發送者的公開密鑰進行解密解開的報文摘要值相比較。如相等則說明報文確實來自所稱的發送者。
數字證書是如何生成的?
數字證書是數字證書在一個身份和該身份的持有者所擁有的公/私鑰對之間建立了一種聯系,由認證中心(CA)或者認證中心的下級認證中心頒發的。根證書是認證中心與用戶建立信任關系的基礎。在用戶使用數字證書之前必須首先下載和安裝。
認證中心是一家能向用戶簽發數字證書以確認用戶身份的管理機構。為了防止數字憑證的偽造,認證中心的公共密鑰必須是可靠的,認證中心必須公布其公共密鑰或由更高級別的認證中心提供一個電子憑證來證明其公共密鑰的有效性,后一種方法導致了多級別認證中心的出現。
數字證書頒發過程如下:用戶產生了自己的密鑰對,并將公共密鑰及部分個人身份信息(稱作P10請求)傳送給一家認證中心。認證中心在核實身份后,將執行一些必要的步驟,以確信請求確實由用戶發送而來,然后,認證中心將發給用戶一個數字證書,該證書內附了用戶和他的密鑰等信息,同時還附有對認證中心公共密鑰加以確認的數字證書。當用戶想證明其公開密鑰的合法性時,就可以提供這一數字證書。
證書的產生:認證中心把用戶證書的基本信息做哈希算法,然后用自己的私鑰對哈希值進行加密。
五.數字證書是如何分發的?
CA將證書分發給用戶的途徑有多種。第一種途徑是帶外分發(Out-of-band Distribution),即離線方式。例如,密鑰對是由軟件運營商代替客戶生成,證書也是由運營商代替客戶從CA下載,然后把私鑰和下載的證書一起儲存在軟盤里,再交給用戶的。這樣做的好處是免去了用戶上網下載證書的麻煩。第二種途徑是帶內分發(In-band distribution),即用戶從網上下載數字證書到自己的電腦中。下載時,用戶要向CA出示“參考號”和“授權碼”,以向CA證明自己的身份。這樣做成本較低,但對使用計算機不太熟悉的用戶來說,可能在下載時會碰到一些麻煩。除了以上兩種方式外,CA還把證書集中放置在公共的數據庫中公布,用戶可以隨用隨查詢隨調用。
六.數字證書是如何存儲的?
數字證書和私鑰儲存的介質有多種,大致分為硬證書和軟證書。可以存儲在計算機硬盤、軟盤、智能卡或USB key里。
1、關于私鑰的唯一性
嚴格地講,私鑰既然是世上唯一且只由主體本身持有,它就必須由主體的計算機程序來生成。因為如果在別處生成將會有被拷貝的機會。然而在實際應用上并非如此,出于某些特殊需要(例如,如果只有一份私鑰,單位的加密文件就會因為離職員工帶走 私鑰而無法解密。)加密用的公/私鑰對會要求在可信的第三方儲存其備份。這樣,加密用的私鑰可能并不唯一。然而簽名用的私鑰則必須保持唯一,否則就無法保證被簽名信息的不可否認性。
在生成用戶的密鑰對時,用于加密的公/私鑰對可以由CA、RA產生,也可以在用戶終端的機器上用專用的程序(如瀏覽器程序或認證軟件)來產生。用于數字簽名的密鑰對原則上只能由用戶終端的程序自行產生,才能保證私鑰信息的私密性以及通信信息的不可否認性。
有人可能會產生疑問:有的加密和簽名的密鑰對都是由軟件運營商代替客戶生成的,這是否破壞了上述的私鑰唯一性原則呢?答案是否定的。這時候,私鑰的唯一性要依靠法律合同的保證以及操作過程中相應制度的約束,使得不可否認性得到支持。出于這種機制,我們仍然可以認為,用戶的簽名私鑰是唯一的。
2、證書,私鑰,到底保護哪一個?
我們常常聽到有人說:“保管好你的軟盤,保管好你的KEY,不要讓別人盜用你的證書。”有些教科書上也這樣講。應該說,這句話是有毛病的。數字證書可以在網上公開,并不怕別人盜用和篡改。因為證書的盜用者在沒有掌握相應的私鑰的情況下,盜用別人的證書既不能完成加密通信,又不能實現數字簽名,沒有任何實際用處。而且,由于有CA對證書內容進行了數字簽名,在網上公開的證書也不怕黑客篡改。我們說,更該得到保護的是儲存在介質中的私鑰。如果黑客同時盜走了證書和私鑰,危險就會降臨。
七.如何驗證數字證書?
以Alice驗證Bob證書為例:
校驗Bob的證書的合法性
(1)Alice獲得Bob的證書和簽發Bob證書的CA的證書
(2)用CA的公鑰解密Bob的證書摘要
(3)計算Bob的證書的摘要
(4)比較這兩個摘要
(5)校驗Bob的證書證書有效期
(6)校驗簽發者簽名(證書鏈)
(7)檢查證書作廢列表(CRL,OCSP)
八.CRL和OCSP是什么?
證書的有效性取決于兩個方面因素:第一個因素是證書有效期:證書的有效期在證書被頒發之日就已經確定了,例如CFCA(中國金融認證中心)規定個人證書的有效期是一年(可擴展),企業證書的有效期是三年。證書的有效期(Validity Period)作為一項內容被寫進了數字證書之中,它用兩個日期——證書開始生效的日期和證書失效的日期來表示。顯然,已經過了有效期的證書不能通過驗證。
證書有效期的設定是出于安全的考慮,當一張證書有效期將結束時,如果想繼續使用就需要更新,證書更新時將產生新的公私密鑰對,密鑰定期更新對于證書的安全性是有好處的。
第二個因素是證書注銷:雖然證書有效期沒有過,但是如果發生了特殊情況,例如用戶發現證書遺失或私鑰失密,用戶會向CA/RA提出注銷證書的申請,CA/RA經過審核后將實施證書注銷。那么,被注銷的證書也不能通過驗證。 第一種情況比較簡單,證書的有效期就寫在了證書之中,安全認證應用軟件只要調出證書的內容,判斷一下就知道這張數字證書當前是否還在有效期內。 第二種情況則比較復雜,證書一旦發出,是不可能收回的。怎么辦呢?只能申請注銷。所謂注銷,就是要求當初頒發這張證書的單位(CA)出一張告示,宣布某張證書已經被注銷作廢,警告有關的交易者注意,不要再使用與這張證書綁定的公鑰。在PKI安全認證體系中,這種“告示”稱為證書注銷列表(或證書撤銷清單、證書注銷清單、證書廢止列表等),英文原文是Certificate Revocation List,縮寫為CRL。 對于第二種情況,安全認證應用軟件在驗證證書的有效性時就需要去訪問證書注銷列表(CRL)。這個列表相當于“黑名單”,一旦發現通信對方的證書在這張列表中,就不能通過驗證。 證書注銷機制可以防止證書遺失或發現私鑰失密后,不法分子冒用用戶證書、私鑰實行欺詐交易所帶來的損失。這和信用卡注銷、有效證件注銷的機制十分類似。 注銷證書的其他原因還包括:銀行方面認為證書用戶信用喪失、用戶身份姓名發生改變、用戶從他所屬單位離職、崗位和職權發生變更等情況。
CRL的內容
根據X.509標準,CRL的內容和數據結構定義如所示:
版本
簽名算法
簽發者
更新時間
下一次更新時間
廢止的證書列表
用戶證書序列號
廢止時間
CRL入口擴展
CRL的內容包括CRL的版本號、計算本CRL的數字簽名所用的算法的標識符(如加密算法RSA、數字摘要算法MD5等算法的標識符)、頒發CRL的CA的可識別名(DN)、CRL的發布/更新時間、被注銷證書的列表(僅列出被注銷證書的唯一序列號)以及擴展項。
擴展項中的內容有:
(1)理由代碼——指出該證書被注銷的理由,如:密鑰損壞、CA損壞、關系變動、操作終止等;
(2)證書頒發者——列出該證書頒發者的名字;
(3)控制指示代碼——用于證書的臨時凍結;
(4)失效日期——列出該證書不再有效的日期。? ? 為了保證CRL的真實性和完整性,CRL數據的后面附有頒發CRL的CA對CRL的數字簽名。
九.常見的數字證書格式
1.在Security編程中,有幾種典型的密碼交換信息文件格式:
DER-encoded certificate: .cer, .crt
PEM-encoded message: .pem
PKCS#12 Personal Information Exchange: .pfx, .p12
PKCS#10 Certification Request: .p10
PKCS#7 cert request response: .p7r
PKCS#7 binary message: .p7b
.cer/.crt是用于存放證書,它是2進制形式存放的,不含私鑰。
.pem跟crt/cer的區別是它以Ascii來表示。
pfx/p12用于存放個人證書/私鑰,他通常包含保護密碼,2進制方式
p10是證書請求
p7r是CA對證書請求的回復,只用于導入
p7b以樹狀展示證書鏈(certificate chain),同時也支持單個證書,不含私鑰。
2.數字證書文件格式(cer和pfx)的區別
作為文件形式存在的證書一般有這幾種格式:
1.帶有私鑰的證書
由Public Key Cryptography Standards #12,PKCS#12標準定義,包含了公鑰和私鑰的二進制格式的證書形式,以
pfx作為證書文件后綴名。
2.二進制編碼的證書
證書中沒有私鑰,DER 編碼二進制格式的證書文件,以cer作為證書文件后綴名。
3.Base64編碼的證書
證書中沒有私鑰,BASE64 編碼格式的證書文件,也是以cer作為證書文件后綴名。 由定義可以看出,只有pfx格式的數字證書是包含有私鑰的,cer格式的數字證書里面只有公鑰沒有私鑰。在pfx證書的導入過程中有一項是“標志此密鑰是可導出的。這將您在稍候備份或傳輸密鑰”。一般是不選中的,如果選中,別人就有機會備份你的密鑰了。如果是不選中,其實密鑰也導入了,只是不能再次被導出。這就保證了密鑰的安全。
如果導入過程中沒有選中這一項,做證書備份時“導出私鑰”這一項是灰色的,不能選。只能導出cer格式的公鑰。如果導入時選中該項,則在導出時“導出私鑰”這一項就是可選的。
如果要導出私鑰(pfx),是需要輸入密碼的,這個密碼就是對私鑰再次加密,這樣就保證了私鑰的安全,別人即使拿到了你的證書備份(pfx),不知道加密私鑰的密碼,也是無法導入證書的。相反,如果只是導入導出cer格式的證書,是不會提示你輸入密碼的。因為公鑰一般來說是對外公開的,不用加密
3.X.509定義了兩種證書:公鑰證書和屬性證書
PKCS#7和PKCS#12使用的都是公鑰證書
PKCS#7的SignedData的一種退化形式可以分發公鑰證書和CRL
一個SignedData可以包含多張公鑰證書
PKCS#12可以包含公鑰證書及其私鑰,也可包含整個證書鏈
十.數字證書命名
C(county)? 國家
O(organization)頒發機構名稱
OU(Organizational Unit) 組織單位名稱
CN (common name) 持有者的名稱
例如:CN=zhangsan,OU=beijingICBCbank,O=ICBCbank
十一.證書工具使用
1.KeyTool工具
Java自帶的keytool工具是個密鑰和證書管理工具。它使用戶能夠管理自己的公鑰/私鑰對及相關證書,用于(通過數字簽名)自我認證(用戶向別的用戶/服務認證自己)或數據完整性以及認證服務。它還允許用戶儲存他們的通信對等者的公鑰(以證書形式)。keytool 將密鑰和證書儲存在一個所謂的密鑰倉庫(keystore)中。缺省的密鑰倉庫實現將密鑰倉庫實現為一個文件。它用口令來保護私鑰。
Java KeyStore的類型
JKS和JCEKS是Java密鑰庫(KeyStore)的兩種比較常見類型(我所知道的共有5種,JKS, JCEKS, PKCS12, BKS,UBER)。
JKS的Provider是SUN,在每個版本的JDK中都有,JCEKS的Provider是SUNJCE,1.4后我們都能夠直接使用它。
JCEKS在安全級別上要比JKS強,使用的Provider是JCEKS(推薦),尤其在保護KeyStore中的私鑰上(使用TripleDes)。
PKCS#12是公鑰加密標準,它規定了可包含所有私鑰、公鑰和證書。其以二進制格式存儲,也稱為 PFX 文件,在 windows中可以直接導入到密鑰區,注意,PKCS#12的密鑰庫保護密碼同時也用于保護Key。
BKS 來自BouncyCastle Provider,它使用的也是TripleDES來保護密鑰庫中的Key,它能夠防止證書庫被不小心修改(Keystore的keyentry改掉1個 bit都會產生錯誤),BKS能夠跟JKS互操作,讀者可以用Keytool去TryTry。UBER比較特別,當密碼是通過命令行提供的時候,它只能跟keytool交互。整個keystore是通過PBE/SHA1/Twofish加密,因此keystore能夠防止被誤改、察看以及校驗。以前,Sun JDK(提供者為SUN)允許你在不提供密碼的情況下直接加載一個Keystore,類似cacerts,UBER不允許這種情況。