龍毅宏,黃 強(qiáng),王 維
(武漢理工大學(xué)信息工程學(xué)院,湖北 武漢 430070)
電子郵件是人們常用的信息傳遞工具,許多的敏感和重要信息都是通過電子郵件傳送的,保證電子郵件安全非常重要。目前保證電子郵件安全的技術(shù)方案主要有兩種,PGP(Pretty Good Privacy)[1],和S/MIME(Secure/Multipurpose Internet Mail Extensions)[2],這兩種技術(shù)方案都是采用公鑰密碼技術(shù),都能實(shí)現(xiàn)電子郵件的消息鑒別和數(shù)據(jù)保密。S/MIME 基于 PKI(Public Key Infrastructure)[3,4]安全技術(shù)體系,它通過 CA認(rèn)證機(jī)構(gòu)簽發(fā)的數(shù)字證書實(shí)現(xiàn)電子郵件的數(shù)字簽名和數(shù)據(jù)加密。PGP與S/MIME的公鑰管理機(jī)制不同,它的公鑰發(fā)布不是通過 CA認(rèn)證機(jī)構(gòu),而是通過社交網(wǎng)絡(luò)傳播。目前的大部分的標(biāo)準(zhǔn)郵件客戶端,如微軟 Outlook、Mozilla Thunderbird(雷鳥),都支持基于數(shù)字證書的電子郵件安全保護(hù),同時(shí),許多的郵件客戶端也通過插件(Plug-in)技術(shù)支持基于PGP的郵件安全。
采用傳統(tǒng)的公鑰密碼技術(shù)對電子郵件進(jìn)行郵件加密的最大問題是:郵件加密方必須事先獲得并配置加密郵件接收方的公鑰(如數(shù)字證書),并在加密郵件接收方的公鑰更新后及時(shí)獲得并配置接收方更新的公鑰,這對用戶特別是普通用戶而言是一件非常麻煩的事。實(shí)際上,數(shù)據(jù)加密方要事先獲得加密數(shù)據(jù)接收方的公鑰是傳統(tǒng)公鑰密碼體制的一個(gè)普遍性的問題,這一問題妨礙了公鑰密碼技術(shù)的廣泛應(yīng)用。為了解決公鑰密碼體制在應(yīng)用中存在的問題,人們提出了基于標(biāo)識的密碼體制(Identity Based Cryptography,IBC)[5-10],包括基于標(biāo)識的簽名(Identity Based Signature)[5,6]和基于標(biāo)識的加密(Identity-Based Encryption)[7-10]。IBC密碼體制屬于公開密鑰密碼體制,其將用戶的一個(gè)身份標(biāo)識(比如 Email地址、手機(jī)號、身份證號等)作為用戶的公鑰,同時(shí)用戶身份標(biāo)識對應(yīng)一個(gè)私鑰,私鑰由一個(gè)私鑰生成器(Private Key Generator,PKG)根據(jù)用戶標(biāo)識計(jì)算得到。
基于IBC(IBE)進(jìn)行加密數(shù)據(jù)交換時(shí)(如加密郵件),加密數(shù)據(jù)的發(fā)送方(如加密郵件的發(fā)送方)只需使用加密數(shù)據(jù)接收方(如加密郵件接收方)的一個(gè)身份標(biāo)識(如接收方的電子郵箱地址)作為公鑰進(jìn)行數(shù)據(jù)加密即可;而加密數(shù)據(jù)(加密郵件)的接收方使用從 PKG獲得的身份標(biāo)識對應(yīng)的私鑰對加密數(shù)據(jù)(加密郵件)進(jìn)行解密即可。
IBC特別是IBE很好地解決了公鑰分發(fā)、獲取的問題,使得公鑰密碼技術(shù)的應(yīng)用變得容易。雖然 IBE技術(shù)具有很多獨(dú)特的優(yōu)點(diǎn),但它目前的最大的問題是缺少應(yīng)用的支持,目前IBE應(yīng)用研究得最多的還是電子郵件加密[11-14]。但已有的方案都存在不足。劉鏹等人[11]以及趙旭東[12]的論文都沒有給出IBE郵件客戶端的具體實(shí)現(xiàn),更沒有說如何在已有郵件客戶端上實(shí)現(xiàn)IBE郵件加密。劉丹[13]等人則是自己開發(fā)出了基于IBE安全的電子郵件系統(tǒng),不能在已有郵件客戶端上實(shí)現(xiàn) IBE郵件加密、解密。李海江[14]采用Outlook的加載項(xiàng)技術(shù),由Outlook的加載項(xiàng)直接進(jìn)行電子郵件IBE加密、解密。這種方案本文作者也曾采用過,這種方案存在如下問題:(1)與Outlook已有的安全功能不兼容,比如,Outlook本身有發(fā)送加密郵件的選項(xiàng),如果用戶發(fā)送時(shí)選擇了 Outlook的加密選項(xiàng),則IBE加密無法正常實(shí)現(xiàn);(2)處理起來非常麻煩,比如,加載項(xiàng)自己要判斷接收的郵件是否被加密,而且是否被 IBE加密;(3)在郵件有附件時(shí)處理起來更麻煩;(4)與S/MIME不兼容。
本研究以電子郵件IBE加密為突破口,解決IBE的應(yīng)用問題。
目前的很多加密應(yīng)用都支持基于 RSA公開密鑰密碼算的數(shù)據(jù)加密和解密,因此,如果引入一種偽RSA密鑰,以偽RSA密鑰為橋梁,將使得使用RSA密碼算法的加密應(yīng)用能夠使用IBE密碼算法進(jìn)行數(shù)據(jù)的加密和解密,這種案具體如下。
所謂偽RSA密鑰,即假RSA密鑰,包括偽RSA公鑰和偽RSA私鑰,它的密鑰數(shù)據(jù)在數(shù)據(jù)結(jié)構(gòu)上與RSA密鑰的密鑰數(shù)據(jù)一樣,但它的密鑰數(shù)據(jù)中存放的不是真正的RSA密鑰數(shù)據(jù),而是IBE密鑰數(shù)據(jù)。為了區(qū)分真正的RSA密鑰和偽RSA密鑰可以采用在 RSA密鑰數(shù)據(jù)結(jié)構(gòu)的某幾個(gè)約定的數(shù)據(jù)位上加上特殊的標(biāo)志,所選擇的這些數(shù)位對于真正的RSA密鑰而言,不可能是這個(gè)特殊標(biāo)志的值,或者是這個(gè)特殊標(biāo)志的值的概率幾乎為零。
基于偽 RSA密鑰,再實(shí)施一個(gè)通過標(biāo)準(zhǔn) RSA密碼接口,如Windows CSP的CyrptoSPI、RSA公司的PKCS#11[15],提供IBE密碼功能的IBE密碼模塊。當(dāng)加密應(yīng)用通過RSA密碼接口使用RSA密鑰調(diào)用密碼功能時(shí),IBE密碼模塊通過RSA密鑰數(shù)據(jù)中的特征位判斷使用的RSA密鑰是真正的RSA密鑰還是偽RSA密鑰,并將針對偽RSA密鑰的密碼功能調(diào)用轉(zhuǎn)化成針對相應(yīng)IBE密鑰的密碼功能調(diào)用。
在IBE的具體應(yīng)用中,通常將一個(gè)身份標(biāo)識與一個(gè)時(shí)間段結(jié)合,形成一個(gè)擴(kuò)展身份標(biāo)識:<身份標(biāo)識> || <時(shí)間期限>,這里,<身份標(biāo)識>指身份標(biāo)識的字串表示,<時(shí)間期限>指時(shí)間段的字串表示(如用2013-8-28:2013-9-28,表示時(shí)間期限2013年8月28日到2013年9月28),“||”表示身份標(biāo)識字串和時(shí)間期限字串的組合;用時(shí)間期限限定的擴(kuò)展身份標(biāo)識僅在對應(yīng)時(shí)間期限用于數(shù)據(jù)加密,并對應(yīng)有一個(gè)IBE私鑰用于數(shù)據(jù)解密。
采用時(shí)間期限對身份標(biāo)識的使用進(jìn)行限定降低了身份標(biāo)識的私鑰泄露所帶來的風(fēng)險(xiǎn),但也給基于偽RSA密鑰的數(shù)據(jù)加密和解密帶來了額外的問題:如果不同的IBE密鑰對對應(yīng)不同的偽RSA密鑰對,那么,IBE密鑰對更新后,加密應(yīng)用的用戶需要定時(shí)進(jìn)行偽RSA密鑰對的更新和配置,IBE密碼模塊需要定時(shí)創(chuàng)建新的IBE私鑰對象,這當(dāng)然很麻煩。那么,能否將不同的IBE密鑰對對應(yīng)到同一個(gè)的偽RSA密鑰對?這樣將能避免定時(shí)進(jìn)行偽 RSA密鑰對的更新和配置的問題。但這又帶來額外的問題,進(jìn)行數(shù)據(jù)加密時(shí),IBE密碼模塊可以根據(jù)當(dāng)前時(shí)刻知道使用哪個(gè)IBE公鑰(即擴(kuò)展身份標(biāo)識)進(jìn)行加密,但進(jìn)行數(shù)據(jù)解密時(shí),IBE密碼模塊如何知道使用哪個(gè)私鑰進(jìn)行解密?本研究的方案如下:
IBE密碼模塊通過標(biāo)準(zhǔn) RSA接口提供密碼功能;一個(gè)身份標(biāo)識在IBE密碼模塊中對應(yīng)一個(gè)IBE密鑰組,這個(gè)密鑰組是由同一個(gè)身份標(biāo)識對應(yīng)于不同時(shí)間段的擴(kuò)展身份標(biāo)識對應(yīng)的IBE私鑰或密鑰對所組成,這個(gè)IBE密鑰組對外作為一個(gè)密鑰對象用一個(gè)密鑰對象標(biāo)識符標(biāo)識、并通過密鑰對象標(biāo)識符對外使用(這與通常的密鑰對象不同)。
每個(gè)身份標(biāo)識對應(yīng)一個(gè)偽RSA密鑰對,偽RSA公鑰和偽 RSA私鑰的數(shù)據(jù)結(jié)構(gòu)中存放的是身份標(biāo)識或身份標(biāo)識的散列值,以及一些密碼運(yùn)算時(shí)所需的輔助信息。
當(dāng)密碼應(yīng)用程序和密碼管理工具調(diào)用IBE密碼模塊的接口請求生成一個(gè)RSA密鑰對時(shí),IBE密碼模塊在內(nèi)部生成一個(gè)(空的)IBE密鑰組,并返回生成的IBE密鑰組的密鑰對象標(biāo)識符。
當(dāng)密碼應(yīng)用程序?qū)氩⑹褂靡粋€(gè) RSA公鑰進(jìn)行數(shù)據(jù)加密時(shí),IBE密碼模塊根據(jù)密鑰數(shù)據(jù)中的特征數(shù)據(jù)判斷導(dǎo)入的RSA公鑰是真正的RSA公鑰還是偽RSA公鑰,若是真正的RSA公鑰,則使用RSA密碼算法進(jìn)行數(shù)據(jù)加密運(yùn)算,若是偽RSA公鑰,則根據(jù)當(dāng)前時(shí)刻,確定合適的擴(kuò)展身份標(biāo)識,并用擴(kuò)展身份標(biāo)識采用IBE密碼算法進(jìn)行數(shù)據(jù)加密運(yùn)算;在完成加密后,IBE密碼模塊將當(dāng)前使用的擴(kuò)展身份標(biāo)識的限定時(shí)間段作為附件數(shù)據(jù)填充到加密運(yùn)算的結(jié)果中(密碼運(yùn)算的直接結(jié)果中,非PKCS#11中的密鑰標(biāo)識信息中)。
當(dāng)密碼應(yīng)用程序以使用 RSA私鑰的方式通過IBE密鑰組的密鑰對象標(biāo)識符使用密鑰對象進(jìn)行數(shù)據(jù)解密時(shí),IBE密碼模塊從待解密的數(shù)據(jù)中獲得加密時(shí)的擴(kuò)展身份標(biāo)識的限定時(shí)間段,然后查看 IBE密鑰組中是否有對應(yīng)時(shí)間段的IBE私鑰,若有,則使用對應(yīng)時(shí)間段的IBE私鑰進(jìn)行數(shù)據(jù)解密運(yùn)算,否則,調(diào)用IBE密鑰服務(wù)客戶端、連接IBE密鑰服務(wù)系統(tǒng)獲取對應(yīng)的IBE私鑰。
在需要進(jìn)行IBE私鑰更新或恢復(fù)時(shí),IBE密碼模塊自動調(diào)用IBE密鑰服務(wù)客戶端從IBE密鑰服務(wù)器獲取更新的IBE私鑰或恢復(fù)IBE私鑰;在更新或恢復(fù)IBE私鑰的過程中,IBE密碼模塊以密碼模塊中存儲的當(dāng)前有效的IBE私鑰作為客戶端用戶身份證明的私密數(shù)據(jù)(這樣就無需手工干預(yù))。
目前采用公開密鑰密碼技術(shù)(如RSA)的密碼應(yīng)用通常不是直接使用公開密鑰對的,而是通過X.509數(shù)字證書[16],如RSA X.509數(shù)字證書。在進(jìn)行數(shù)據(jù)加密時(shí),密碼應(yīng)用通過配置信息找到要使用的數(shù)字證書,或者在已有的多個(gè)數(shù)字證書中提示用戶選擇要使用的數(shù)字證書,然后從數(shù)字證書中獲取公鑰,然后將獲取的公鑰提交給密碼模塊進(jìn)行數(shù)據(jù)加密運(yùn)算;而在進(jìn)行數(shù)據(jù)解密時(shí),密碼應(yīng)用從加密數(shù)據(jù)中獲得加密時(shí)所用數(shù)字證書的標(biāo)識信息(如PKCS#7即CMS[17]格式的加密數(shù)據(jù)中包含的加密時(shí)所用數(shù)字證書的簽發(fā)者名和序列號),然后在證書庫或密碼模塊中找到對應(yīng)的帶私鑰的數(shù)字證書,然后再使用存儲在密碼模塊中的數(shù)字證書的私鑰進(jìn)行數(shù)據(jù)解密運(yùn)算。
由于目前的絕大多數(shù)公鑰密碼應(yīng)用都支持RSA數(shù)字證書,因此,使得支持RSA數(shù)字證書的密碼應(yīng)用能夠使用IBE密碼技術(shù)進(jìn)行數(shù)據(jù)加密、解密的一種方案是引入偽RSA數(shù)字證書。所謂偽RSA數(shù)字證書,是一種采用X.509標(biāo)準(zhǔn)格式、標(biāo)識為使用RSA密鑰的數(shù)字證書,只是數(shù)字證書上的用戶公鑰不是真正的RSA公鑰,而是包含用戶身份標(biāo)識的偽RSA公鑰,而數(shù)字證書的私鑰對象是前面所述的IBE密碼模塊中的IBE密鑰組密鑰對象。這樣,支持RSA數(shù)字證書的公鑰密碼應(yīng)用可以像使用 RSA數(shù)字證書一樣使用偽 RSA數(shù)字證書進(jìn)行數(shù)據(jù)的加密、解密,而通過IBE密碼模塊實(shí)際上被轉(zhuǎn)化為IBE數(shù)據(jù)加密、解密。
如果偽RSA數(shù)字證書也是通過一個(gè)CA系統(tǒng)簽發(fā),那么此方案有傳統(tǒng)數(shù)字證書方案一樣的問題。對此,本研究的方案如下:
引入一個(gè)偽RSA數(shù)字證書簽發(fā)工具,并安裝在每個(gè)IBE密碼算法的使用者(用戶)的計(jì)算機(jī)上;每個(gè)用戶計(jì)算機(jī)上的偽 RSA數(shù)字證書簽發(fā)工具自動生成一個(gè)帶私鑰的RSA根CA證書,用于簽發(fā)偽RSA數(shù)字證書,并將生成的RSA根CA證書安裝到可信任的根 CA證書庫中;每個(gè)用戶計(jì)算機(jī)上生成的RSA根CA證書具有一樣的簽發(fā)者名,一樣的證書序列號,但對應(yīng)的RSA密鑰對不一樣(這不影響偽證書的使用);加密郵件發(fā)送者、接收者自己使用工具生成郵件接收者的不帶私鑰或帶私鑰的偽偽RSA數(shù)字證書。
但這種方案仍存在不足,它需要用戶手工操作,本研究通過插件來解決這一問題。
郵件客戶端,如微軟的 Outlook,Mozilla的雷鳥等,通常有專門的聯(lián)系人通訊薄或地址??;使用數(shù)字證書進(jìn)行郵件加密的郵件客戶端會通過一定的方式(手工或其他方式)將聯(lián)系人的加密數(shù)字證書配置在通訊薄或地址薄中的聯(lián)系人的聯(lián)系信息中;在進(jìn)行郵件加密時(shí),郵件客戶端從通訊薄或地址薄的聯(lián)系人信息中獲得加密郵件接收者的加密數(shù)字證書,并用獲得加密數(shù)字證書對郵件進(jìn)行加密。當(dāng)接收到加密郵件后,郵件客戶端會從郵件客戶端所使用的密碼模塊所對應(yīng)的證書庫中查找對應(yīng)的帶私鑰的數(shù)字證書,然后通過密碼模塊使用數(shù)字證書的私鑰對加密郵件進(jìn)行解密。另外,郵件客戶端在進(jìn)行郵件加密時(shí),還需要使用郵件發(fā)送帳戶對應(yīng)的帶私鑰的數(shù)字證書,因此,郵件客戶端的要發(fā)送加密郵件的帳戶還需要配置對應(yīng)的(發(fā)件者本人的)帶私鑰的數(shù)字證書。
郵件客戶端使用數(shù)字證書進(jìn)行電子郵件加密的最大問題是加密郵件的發(fā)送者需事先獲得加密郵件接收者的加密數(shù)字證書,并將加密數(shù)字證書配置到郵件客戶端的聯(lián)系人通訊薄或地址薄中的聯(lián)系人信息中,這對于用戶而言是一件非常麻煩的事。要使得使用數(shù)字證書進(jìn)行郵件加密的郵件客戶端能夠通過偽 RSA數(shù)字證書實(shí)現(xiàn)郵件的IBE加密,并避免用戶手工配置郵件接收者的偽RSA數(shù)字證書,那么需要通過一定的技術(shù)手段自動在聯(lián)系人通訊薄或地址薄中的聯(lián)系人信息中自動配置郵件接收者的偽RSA數(shù)字證書。
有些郵件客戶端,如Outlook,雷鳥等,提供了通過加載項(xiàng)(Add-Ons)擴(kuò)展程序功能的機(jī)制。加載項(xiàng)是插入到郵件客戶端的郵件發(fā)送和接收或讀取處理過程中的一種插件(Plug-in),能對郵件客戶端的事件進(jìn)行響應(yīng)和處理。本研究的基于加載項(xiàng)(即插件)的電子郵件IBE加密方案如圖1所示。
圖1 基于加載項(xiàng)的郵件IBE加密方案Fig.1 Add-on based Email Encryption with IBE
這里的郵件客戶端是支持使用數(shù)字證書進(jìn)行郵件加密和解密、并提供加載項(xiàng)機(jī)制擴(kuò)展功能的電子郵件專用客戶端。
這里的IBE密碼模塊是前面所述的基于偽RSA密鑰及RSA密碼接口、提供IBE密碼功能的密碼模塊,此IBE密碼模塊是(或配置為)郵件客戶端進(jìn)行郵件加密和解密時(shí)所使用的密碼模塊;IBE密碼模塊中的IBE密鑰組密鑰對象是帶私鑰的偽RSA數(shù)字證書的私鑰對象。
這里的偽 RSA數(shù)字證書是作為郵件客戶端使用IBE加密算法進(jìn)行郵件加密和解密橋梁的X.509格式的具有加密用途的偽 RSA數(shù)字證書;偽 RSA數(shù)字證書被保存在郵件端所使用的密碼模塊所對應(yīng)的證書庫中(若郵件客戶端使用的密碼模塊是Windows CSP,則對應(yīng)的證書庫是Windows證書庫,若是PKCS#11,則證書庫在PKCS#11中)。
這里的偽 RSA數(shù)字證書生成模塊在需要的時(shí)候被IBE加載項(xiàng)調(diào)用用于生成偽RSA數(shù)字證書,并由IBE加載項(xiàng)將所生成的偽RSA數(shù)字證書放入到郵件客戶使用的密碼模塊(即IBE密碼模塊)所對應(yīng)的證書庫中。
這里的IBE密鑰服務(wù)客戶端,是IBE密碼模塊與IBE密鑰服務(wù)器交互、獲取IBE公開參數(shù)以及用戶身份標(biāo)識對應(yīng)的IBE私鑰的動態(tài)庫。
這里的IBE加載項(xiàng)是擴(kuò)展郵件客戶端功能的插件,在郵件客戶端啟動以及發(fā)送和接收或讀取郵件時(shí)被觸發(fā)調(diào)用,并對涉及加密郵件的發(fā)送和接收或讀取操作進(jìn)行處理。
當(dāng)電子郵件客戶端啟動時(shí),IBE加載項(xiàng)檢查郵件客戶端中的每個(gè)發(fā)件人郵箱帳戶在郵件客戶端所使用的證書庫中是否有對應(yīng)的帶私鑰的偽RSA數(shù)字證書,若沒有,則調(diào)用偽RSA數(shù)字證書生成模塊生成與發(fā)件人郵件帳戶相對應(yīng)的帶私鑰的偽RSA數(shù)字證書;之后,IBE加載項(xiàng)進(jìn)一步檢查郵件客戶端中的每個(gè)發(fā)件人郵箱帳戶是否已配置使用帶私鑰的偽RSA數(shù)字證書進(jìn)行郵件加密,若沒有,則進(jìn)行配置。
當(dāng)電子郵件客戶端發(fā)送加密郵件時(shí),IBE加載項(xiàng)根據(jù)不同情況分別按如下方式進(jìn)行處理:
若郵件客戶端從聯(lián)系人通訊薄或地址薄中獲取加密郵件接收人的數(shù)字證書,則IBE加載項(xiàng)針對當(dāng)前正待加密的電子郵件的每個(gè)郵件收件人,依次檢查聯(lián)系人通訊薄或地址薄中是否有相應(yīng)的郵件收件人,若沒有,則創(chuàng)建相應(yīng)的聯(lián)系人,調(diào)用偽RSA數(shù)字證書生成模塊,生成與收件人電子郵件地址相對應(yīng)的不帶私鑰的偽 RSA數(shù)字證書,并將生成的偽RSA數(shù)字證書加入到聯(lián)系人通訊薄或地址薄中的相應(yīng)郵件接收人的聯(lián)系信息中;若有,則進(jìn)一步檢查聯(lián)系人通訊薄或地址薄中的對應(yīng)郵件收件人是否有相應(yīng)的偽RSA數(shù)字證書,若沒有,調(diào)用所述偽RSA數(shù)字證書生成模塊,生成與收件人電子郵件地址相對應(yīng)的不帶私鑰的偽RSA數(shù)字證書,并將生成的偽RSA數(shù)字證書加入到聯(lián)系人通訊薄或地址薄中的相應(yīng)郵件接收人的聯(lián)系信息中。
若郵件客戶端從所使用的密碼模塊的證書庫中獲取加密郵件接收人的數(shù)字證書,IBE加載項(xiàng)針對當(dāng)前正待加密的電子郵件的每個(gè)郵件收件人,依次檢查證書庫中是否有相應(yīng)的偽RSA數(shù)字證書,若沒有,調(diào)用所述偽RSA數(shù)字證書生成模塊,生成與收件人電子郵件地址相對應(yīng)的不帶私鑰的偽RSA數(shù)字證書,并將生成的偽RSA數(shù)字證書加入證書庫中。
當(dāng)電子郵件客戶端接收或讀取加密郵件時(shí),IBE加載項(xiàng)在IBE密碼模塊所對應(yīng)的證書庫中查看是否有當(dāng)前郵件收件人的帶私鑰的偽 RSA數(shù)字證書,若沒有,則調(diào)用所述偽RSA數(shù)字證書生成模塊,生成與當(dāng)前收件人電子郵件地址相對應(yīng)的帶私鑰的偽RSA數(shù)字證書,并將生成的帶私鑰的偽RSA數(shù)字證書加入到IBE密碼模塊所對應(yīng)的證書庫中的相應(yīng)證書存儲區(qū)中(郵件客戶端啟動時(shí)IBE加載項(xiàng)已為發(fā)件人的每個(gè)郵件帳戶生成、配置了帶私鑰的偽RSA數(shù)字證書,故此處理通常是不必要的,只有在郵件客戶端啟動后,用戶人為刪除了郵件帳戶的帶私鑰的偽RSA數(shù)字證書時(shí),這個(gè)處理才需要)。
采用以上技術(shù)方案后,加密郵件的發(fā)送者在發(fā)送加密郵件前無需獲取和配置收件人的加密數(shù)字證書,只需在發(fā)送加密郵件時(shí)點(diǎn)擊郵件客戶端的加密按鈕,或者只需在郵件客戶端的聯(lián)系人通訊薄或地址薄中相關(guān)收件人的聯(lián)系信息中設(shè)置相應(yīng)的加密選項(xiàng)即可;當(dāng)需要進(jìn)行郵件加密時(shí),若聯(lián)系人通訊簿或地址簿中沒有相應(yīng)收件人的偽RSA數(shù)字證書,或者若加密所用證書庫中沒有相應(yīng)收件人的偽 RSA數(shù)字證書,則郵件客戶端的IBE加載項(xiàng)會自動為郵件收件人生成、配置相應(yīng)的偽RSA數(shù)字證書;當(dāng)郵件客戶端接收或讀取加密郵件時(shí),若沒有相應(yīng)的帶私鑰的偽RSA數(shù)字證書,則IBE加載項(xiàng)會自動調(diào)用偽 RSA數(shù)字證書生成模塊為用戶生成解密郵件所需的帶私鑰的偽RSA數(shù)字證書。
以上描述的是一個(gè)一般性的技術(shù)方案,針對具體的電子郵件客戶端還會有一些特別的處理,下面針對微軟Outloo,對基于插件的郵件IBE加密的具體實(shí)施作進(jìn)一步的描述。
Outlook是微軟的郵件客戶端,它支持基于數(shù)字證書的郵件加密和解密。Outlook所使用的密碼模塊是Windows CSP,發(fā)送方的Outlook從聯(lián)系人通訊簿中獲得加密郵件接收方的加密數(shù)字證書,而加密郵件接收方的Outlook從Windows證書庫中查找?guī)借€的數(shù)字證書解密被加密郵件。Outlook提供加載項(xiàng)機(jī)制用于功能擴(kuò)展?;谇懊嫠龅幕诓寮腎BE郵件加密技術(shù)方案,Outlook郵件加密的具體技術(shù)實(shí)施方案如圖2所示。
圖2 基于插件的Outlook IBE郵件加密的技術(shù)方案Fig.2 Plug-in based Outlook IBE Email Encryption
這里的IBE CSP是具有RSA接口、通過偽RSA密鑰技術(shù)實(shí)施 IBE密碼功能的 Windows CSP。Outlook使用的證書庫是 Windows證書庫。這里的IBE加載項(xiàng)采用COM(Component Object Model)技術(shù)開發(fā)實(shí)施,具體可實(shí)施_IDTExtensibilty2接口。在實(shí)施IBE加載項(xiàng)時(shí)有如下幾點(diǎn)需要注意:
(1)對于Outlook2003,IBE加載項(xiàng)對Outlook郵件及數(shù)據(jù)(如聯(lián)系人通訊簿)的訪問采用消息應(yīng)用程序編程接口(MAPI,Messaging Application Programming Interface),而對于 Outlook2007和Outlook2010及以后版本,則采用 Microsoft.Office.Interop.Outlook接口;
(2)IBE加載項(xiàng)向 Outlook注冊要響應(yīng)ApplicationEvents中的OnStartup (0xF006)事件,對應(yīng) Outlook啟動;注冊要響應(yīng) ApplicationEvents中的OnItemSend(0xF002)事件,以及ExplorerEvents中的 OnSelectChange(0xF007)事件,它們分別對應(yīng)郵件發(fā)送和郵件讀取事件;
(3)響應(yīng)OnStartup事件時(shí),IBE加載項(xiàng)針對Outlook中的每個(gè)發(fā)件人郵件帳戶在 Windows證書庫中檢查是否有對應(yīng)的帶私鑰的偽RSA數(shù)字證書,若沒有,則調(diào)用調(diào)用偽RSA數(shù)字證書生成模塊生成發(fā)件人郵件帳戶對應(yīng)的帶私鑰的偽RSA數(shù)字證書;
(4)響應(yīng)OnItemSend事件時(shí),IBE加載項(xiàng)通過檢查郵件加密按鈕是否按下,確定發(fā)送的是加密郵件還是非加密郵件,或者總是假設(shè)發(fā)送的是加密郵件;在確定是發(fā)送加密郵件后,IBE加載項(xiàng)檢查確定 Outlook聯(lián)系人通訊簿中是否有郵件中的接收人,以及在 Outlook聯(lián)系人通訊簿中的接收人信息中是否配置有用于郵件加密的不帶私鑰的偽 RSA數(shù)字證書,若沒有,則進(jìn)行相應(yīng)的處理;
(5)響應(yīng)OnSelectChange時(shí),IBE加載項(xiàng)檢查郵件內(nèi)容(是否是 S/MIME)確定郵件是否加密,或者總是假設(shè)郵件是加密的;在確定郵件是加密的后,IBE加載項(xiàng)在Windows證書庫中檢查是否有收件人的帶私鑰的偽RSA數(shù)字證書,若沒有,則調(diào)用偽RSA數(shù)字證書生成模塊生成;
(6)Outlook聯(lián)系人通訊簿中的聯(lián)系人可能是一個(gè)郵件組,因此,在響應(yīng)郵發(fā)送事件時(shí),IBE加載項(xiàng)要通過聯(lián)系人通訊簿檢查郵件接收者是個(gè)人還是一個(gè)郵件組,若是一個(gè)郵件組,則還需針對郵件組中的每個(gè)人在聯(lián)系人通訊簿中進(jìn)一步檢查是否有相應(yīng)的聯(lián)系人信息及偽RSA數(shù)字證書,若沒有,則作相應(yīng)的處理;
(7)由于沒有相應(yīng)的應(yīng)用編程接口,因此Outlook中的某個(gè)郵箱要配置安全郵件選項(xiàng)時(shí),用戶必須手工選擇、配置用于發(fā)件人本人的帶私鑰的簽名數(shù)字證書和加密數(shù)字證書,而選擇、配置的用于發(fā)件人本人的的帶私鑰的簽名數(shù)字證書和加密數(shù)字證書來自Windows證書庫;用戶選擇、配置的帶私鑰的簽名數(shù)字證書可以是任何一個(gè) CA機(jī)構(gòu)或系統(tǒng)簽發(fā)的具有簽名用途的數(shù)字證書,而用戶選擇、配置的帶私鑰的加密數(shù)字證書即是 IBE加載項(xiàng)在Outlook啟動時(shí)調(diào)用偽RSA數(shù)字證書生成模塊生成的具有加密用途的帶私鑰的偽RSA數(shù)字證書。
采用以上所述方案后的Outlook,當(dāng)用戶通過信任中心進(jìn)行電子郵件安全配置、選擇加密數(shù)字證書時(shí),由IBE插件生成的、具有加密用途的帶私鑰的偽RSA數(shù)字證書已存在,用戶無需手工生成,只需選擇就行了。
查看郵件客戶端所使用的證書庫可以看到,當(dāng)發(fā)送加密郵件時(shí),若沒有郵件接收者的偽RSA數(shù)字證書,則接收者的偽RSA數(shù)字證書會被(插件)自動生成并放置到證書庫中。加密郵件接收者讀取加密郵件時(shí),若IBE密碼模塊中沒有相應(yīng)的當(dāng)前有效IBE私鑰解密郵件,則IBE密碼模塊會自動連接IBE密鑰服務(wù)器進(jìn)行IBE私鑰獲取處理,包括彈出窗口提示用戶進(jìn)行操作;若IBE密碼模塊中沒有之前的IBE私鑰解密郵件,則IBE密碼模塊會自動連接IBE密鑰服務(wù)器并使用當(dāng)前有效的IBE私鑰申請恢復(fù)之前的IBE私鑰。進(jìn)一步,當(dāng)需要進(jìn)行IBE私鑰更新時(shí),IBE密碼模塊會自動連接IBE密鑰服務(wù)器并使用當(dāng)前有效的IBE私鑰獲取更新的IBE私鑰。
本論文研究工作通過偽RSA密鑰、偽RSA數(shù)字證書及插件解決了IBE技術(shù)在電子郵件加密中的應(yīng)用問題,從應(yīng)用效果可以看到,采用本論文提出的方案,用戶可以在僅作極少量配置或不作任何配置的情況下使用 Outlook等郵件客戶端發(fā)送、接收經(jīng)IBE加密的電子郵件,在應(yīng)用IBE進(jìn)行郵件加密和解密的過程中,用戶的手工干預(yù)是非常少的,這個(gè)方案既發(fā)揮了IBE加密的優(yōu)勢,又使得已有的郵件客戶端能在不修改的情況下使用IBE技術(shù),進(jìn)一步地,本論文中的方案對IBE在其他加密應(yīng)用中的應(yīng)用具有借鑒作用。
[1] Callas J. OpenPGP Message format[S]. IETF RFC4880,November 2007.
[2] Dusse S. S/MIME Version 2 Message Specification[S]. IETF RFC2311, March 1998.
[3] 李建新. 公鑰基礎(chǔ)設(shè)施(PKI)理論及應(yīng)用[M]. 北京: 機(jī)械工業(yè)出版社, 2010.
[4] 郁建. PKI應(yīng)用安全支撐平臺研究與構(gòu)建[J]. 信息安全與通信保密, 2013, 11(8): 60-62.
[5] Shamir A. Identity-Based Cryptosystems and Signature Schemes. Advances in Cryptology[C], Proceedings of CRYPTO 84, Lecture Notes in Computer Science, 7: 47-53, 1984.
[6] Hess F. Efficient Identity Based Signature Schemes Based on Pairings[J], Selected Areas in Cryptography, Lecture Notes in Computer Science,Vol.2595,February 2003, pp. 310-324.
[7] Polychroniadou A, Chalkias K, Stephanides G. A compatible implementation between Identity-Based and certificateless encryption schemes[C]. IEEE Computer Society: 8th International Conference on Web Information Systems and Technologies, Engineering Village, 2012.
[8] Siad A. Anonymous identity-based encryption with distributed private-key generator and searchable encryption[C],IEEE Computer Society: 5th International Conference on New Technologies, Mobility and Security, 2012.
[9] Boneh D, Franklin M. Identity-Based Encryption From the Weil Pairing[C]. Proceedings of Crypto 2001. Springer-Verlag, 2001: 213-229.
[10] Anand D, Khemchandani V, Sharma R K. Identity-based cryptography techniques and applications[C]. IEEE Com-puter Society: 5th International Conference on Computa-tional Intelligence and Communication Networks. 2013.
[11] 劉鏹, 王勝男. 基于身份標(biāo)識的密碼體制及其在安全電子郵件的應(yīng)用[J]. 信息安全與技術(shù), 2014, 5(6): 70~72.
[12] 趙旭東. 一種基于身份加密的安全電子郵件方案研究與實(shí)現(xiàn)[D]. 成都: 西南交通大學(xué), 2010.
[13] 劉丹, 劉暢, 宋樵. 基于身份的安全電子郵件系統(tǒng)[J]. 信息網(wǎng)絡(luò)安全, 2010, 10(5): 64-66.
[14] 李海江. 新型安全電子郵件加密系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)[J]. 信息安全與技術(shù), 2012, 3(7): 11~13.
[15] RSA Laboratories. PKCS #11 v2.11: Cryptographic Token Interface Standard[S]. November 2001.
[16] Cooper D, Santesson S, Farrell S et al. Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List(CRL) Profile[S], IETF RFC5280, May 2008.
[17] Housley R. Cryptographic Message Syntax (CMS)[S], IETF,RFC5652, September 2009.