王兵
摘要:該文介紹了可追蹤匿名證書,并對提出的可追蹤匿名證書的發(fā)布和追蹤協(xié)議進(jìn)行了詳細(xì)的分析,可追蹤匿名證書應(yīng)該具有匿名性和不可否認(rèn)性兩個核心特點,這兩個特點保證了用戶可以在不泄露自己的真實身份的情況下來證明用戶的身份,這樣的證書可以被用于需要提供匿名服務(wù)的網(wǎng)絡(luò)應(yīng)用中。
關(guān)鍵詞:可追蹤匿名證書;匿名性;不可否認(rèn)性
中圖分類號:TP393 文獻(xiàn)標(biāo)識碼:A 文章編號:1009-3044(2014)14-3260-03
Abstract: This paper introduces the traceable anonymous certificate, and analyzes the proposed traceable anonymous certificate issuing and tracing protocol in detail, the traceable anonymous certificate should possess two core characteristics: anonymity and non-repudiation, the two features ensure that users can prove the identity himself but without revealing his true identity, this certificate can be used to provide anonymous service in network application.
Key words: traceable anonymous certificate; anonymity; non-repudiation
1 概述
本文對RFC中提到的可追蹤匿名證書(TAC)所使用的密碼技術(shù)作了總結(jié)和概述,RFC是由互聯(lián)網(wǎng)工程工作小組發(fā)布的一系列以編號排定的文件,這些文件收集了有關(guān)因特網(wǎng)的相關(guān)資訊,以及UNIX和因特網(wǎng)社群的軟件文件,這些文件為以x.509為標(biāo)準(zhǔn)的PKI體系提供了詳細(xì)的技術(shù)支持,并通過應(yīng)用盲簽名和門限密碼學(xué)來保護(hù)證書的持有者,防止通過證書鏈接到證書持有者的真實身份。在實體間的通信信道安全的情況下,TAC具有兩個核心特點:匿名性和不可否認(rèn)性。匿名性是指證書的主體域中使用匿名來標(biāo)識實體,只有在很嚴(yán)格的條件下才允許匿名鏈接到用戶的真實身份。這點是TAC最重要的一個特點,如果達(dá)不到匿名性,那么使用TAC就沒有什么意義了。用戶可以自己選擇證書中包含的匿名,如果這個匿名已經(jīng)被CA公布,那么,AI可以選擇一個隨機(jī)數(shù)作為新的匿名或者停止被公布的這個匿名的使用。不可否認(rèn)性是指證書的持有者不能否認(rèn)他參加了證書申請與使用,基于這個特性,一個用戶為另一個用戶申請TAC是不可能的。
2 PKI中的TAC
在RFC5636中,介紹了基于X.509標(biāo)準(zhǔn)的匿名證書發(fā)布方案。通常,發(fā)布的基于X.509標(biāo)準(zhǔn)的普通證書的實體域中會使用真實名字,而TAC的實體域中會使用匿名來代替真實名字,因此,就不能暴露證書持有者的真實身份信息。
作為一般的終端用戶希望使用這樣的匿名證書,因為它具有普通證書的功能,而且還不能由證書鏈接到用戶的真實名字,這點是可行的,因為終端用戶的名字對于可信機(jī)構(gòu)去驗證證書的真實性通常不重要,它并不同于公司企業(yè)所使用的證書,公司名字作為公共信息一般不會鏈接到個人。但是值得注意的是,TAC不能給用戶提供一種完全的匿名,一個權(quán)威機(jī)構(gòu)仍然可以得到用戶的真實身份信息。
使用TAC來代替普通的證書,TAC通過隱藏真實名字來為用戶提供額外的安全保護(hù),為了獲得證書,用戶像往常一樣發(fā)起獲得證書的程序。為了進(jìn)行簽名過程,用戶會從盲簽名發(fā)布者(BI)那里得到一個匿名,這個符號會被傳遞給匿名證書發(fā)布者(AI)。AI和BI共同證明這個匿名的唯一性和正確性,驗證通過后它們使用門限簽名方法對證書簽名。
為了完成證書的追蹤BI保持了實名與匿名間的聯(lián)系,AI則完成實際的簽名。因此,BI知道用戶的真實身份,但是AI是不知道的。在這種情況下,BI相當(dāng)于一個普通的證書注冊機(jī)構(gòu)(RA),AI則完成了作為證書頒發(fā)機(jī)構(gòu)(CA)的工作。這個模型的前題是RA和CA必須分離,否則就實現(xiàn)不了匿名性。
另外一個需要注意的是在可追蹤的匿名證書方案中,一個用戶不能為了不同的應(yīng)用使用同一個匿名來獲得不同的證書。這雖然限制了可追蹤匿名證書的應(yīng)用,但卻確保了證書不能被濫用。為了不同的應(yīng)用而申請多個匿名證書,這是可以實現(xiàn)的。一個用戶在注冊過程中可以申請多個證書,例如證書個數(shù)最多為K,BI中設(shè)置一個計數(shù)器,初始值為K,只有當(dāng)AI收到K時,BI記錄盲簽名哈希值。為了防止證書被濫用,BI應(yīng)該知道證書的個數(shù),而且AI和用戶之間也要求更嚴(yán)格的身份認(rèn)證,來防止黑客獲得這些證書的部分信息。
同樣也是防止證書被濫用,RFC中也不允許用戶自己更新TAC。一個用戶允許從CA那獲得多個TAC,所以,獲得足夠的密鑰信息應(yīng)該不成問題。當(dāng)TAC達(dá)到了證書的有效期,考慮到可信實體和用戶之間的交互,用戶可以申請一個新的證書,使用現(xiàn)有(這個)的證書來鏈接兩個TAC。
3 TAC的發(fā)布與追蹤
TAC中需要解決的問題是怎樣仍然使用X.509標(biāo)準(zhǔn),但是卻可以提供更多的匿名性。為了給證書提供適當(dāng)?shù)暮灻植恍孤队脩舻恼鎸嵭彰?,這里使用了密碼學(xué)中的盲簽名技術(shù)。盲簽名允許消息發(fā)送者先將消息盲化,簽名者對盲化后的消息進(jìn)行簽名,消息的接收者對消息去除盲化因子,最后得到簽名者對原消息的簽名。為了阻止黑客的攻擊,同時也為了通過證書追蹤到真實的用戶,證書的匿名與用戶的真實名之間的鏈接需要分別存儲在不同的實體中。
3.1 TAC的發(fā)布協(xié)議endprint
TAC的發(fā)布過程如圖1所示。
第1步 證書申請者即用戶向BI證明自己身份的真實性。BI與RA相似,BI驗證用戶的真實身份并存儲用戶的身份信息,同時設(shè)置用戶的密鑰及證書的效期,而且不能由這個用戶的密鑰鏈接到用戶的真實身份,為此,BI可以向用戶發(fā)送一個信息,這個信息包含用戶的密鑰和證書的有效期,并用自己的私有密鑰進(jìn)行簽名。
第2步 BI通過一個安全信道將簽名后的信息發(fā)送給用戶,用戶收到信息之后需要在開始下一步之前驗證這個簽名,以后由TAC追蹤到用戶過程中會用到這個信息,用來防止用戶不在BI那注冊就申請證書。
第3步 用戶根據(jù)通用的標(biāo)準(zhǔn)形式來制定證書申請證書,如常用的PKCS10格式。在申請書的格式中,主體域中應(yīng)該包含一個用戶自己選擇的匿名。為了避免主體域名的沖突,這個匿名也可以由CA提供的程序自動生成。然后用戶就通過一個安全信道把請求信息發(fā)送給AI,而用戶從BI那接收到的信息作為這個請求信息的一部份。注意,這個信道不能用于認(rèn)證用戶,因為這會暴露用戶的真實身份,減少了匿名性。
第4步 AI檢查接收到的信息的格式并驗證信息中的簽名,然后驗證證書的有效期,如果是合法的,與最近已存儲的合法的信息進(jìn)行比較,來防止重放攻擊。如果主體域名已經(jīng)被另一個證書所使用,那么AI或者拒絕申請,或者選擇一個隨機(jī)的匿名。AI設(shè)置所有的域,包括證書的簽名數(shù)據(jù),對這個數(shù)據(jù)計算哈希值,對這個哈希值再進(jìn)行盲簽名。注意,如果想要實現(xiàn)匿名的話,那么BI就不應(yīng)該知道進(jìn)行盲簽名的密鑰對。隨后,AI對盲簽名后的哈希值進(jìn)行簽名,連同用戶提供的信息,并對過雙向認(rèn)證的安全信道發(fā)送給BI,AI簽名用的證書也應(yīng)該包括在內(nèi)。
第5步 BI驗證AI對盲簽名哈希值的簽名,以及自己的簽名。然后驗證匿名確保它以前沒有被用來申請過證書。為了實現(xiàn)TAC的追蹤,這個匿名是與數(shù)據(jù)庫中用戶的信息相聯(lián)系的。然后BI使用自己的門限簽名密鑰對盲簽名哈希值進(jìn)行簽名,在這之后,用自己的簽名密鑰對結(jié)果進(jìn)行簽名,然后把它發(fā)送給AI。
第6步 AI驗證BI對盲簽名哈希值的簽名,然后AI對結(jié)果去除盲化因子,最后使用自己的門限簽名密鑰來完成對TAC的簽名。TAC與匿名間的關(guān)系會被存儲,以便以后由TAC追蹤到用戶。最后,AI把TAC發(fā)送給用戶,現(xiàn)在用戶可以使用TAC了。
3.2 TAC的追蹤協(xié)議
當(dāng)發(fā)現(xiàn)證書被濫用時,為了獲得證書持有者的真實身份信息,一個可信機(jī)構(gòu)通過分別與AI和BI通信的方法啟動證書的追蹤協(xié)議,如圖2所示。
Step A 首先可信息實體向AI提供匿名證書被濫用的證明?,F(xiàn)行的IP地址系統(tǒng)很大程度上取決于服務(wù)提供商為它的用戶提供的保護(hù)有多好。對于CA而言,規(guī)則應(yīng)該更嚴(yán)格,因為公布證書的匿名會比公布用戶的IP地址泄露更多的信息。之后,TAC就由權(quán)威機(jī)構(gòu)提供給AI,然后,AI撤銷TAC并添加到證書撤銷列表(CRL)中。
Step B 接下來,AI搜索與TAC相對應(yīng)的匿名,并通過雙向認(rèn)證的安全信道把它發(fā)送給可信實體。
Step C 可信實體把匿名發(fā)送給BI,并且要求得到用戶的身份信息。BI可以根據(jù)協(xié)議獨立驗證可信實體的投訴的正確性。
Step D BI驗證匿名中它自己的簽名,檢索TAC證書用戶的身份信息并把身份信息發(fā)送給可信實體。
4 結(jié)束語
在網(wǎng)絡(luò)應(yīng)用中,很多情況都可以用到RFC中提到的匿名數(shù)字證書,如果需要提供臨時或永久的身份證明而又不想泄露自己的身份信息,如在線的匿名投票、電子政務(wù)及網(wǎng)絡(luò)交易等。TAC的使用,使現(xiàn)行的PKI體系有了一個全新的發(fā)展,相信會成為未來研究的熱點。該文就是基于PKI體系發(fā)布TAC的,TAC對于外部的攻擊者充分地達(dá)到了匿名的目標(biāo),但對于來自于AI內(nèi)部的攻擊,就不能很好地保護(hù)TAC的用戶,如果AI內(nèi)部的攻擊者想要攻擊系統(tǒng),他可以發(fā)送一個對應(yīng)不同匿名的盲簽名哈希值,這就會導(dǎo)致最終的證書被鏈接到其它的用戶而不是想要得到TAC的用戶。為了解決這樣的問題,該文建議AI的員工不能在相關(guān)的BI中注冊,考慮到AI的角色類似CA,CA是一個可信任的實體,所以應(yīng)該在實際的應(yīng)用中限制發(fā)生這種攻擊的可能性。
參考文獻(xiàn):
[1] AndrewNash,williamDuane,CeliaJoseph,DerekBrink,張玉清,陳建奇,楊波,薛偉,等,譯.公鑰基礎(chǔ)設(shè)施(PKl)實現(xiàn)和管理電子安全[M].北京:清華大學(xué)出版社,2002:45-65.
[2] Michael Spalding. Deciding Whether or not to use a Third Party Certificate Authority [J].Network Security, 2000,(20):7-8.
[3] 王建業(yè),周振國,陳森發(fā).Internet X.509 PKI深入討論與分析[J].計算機(jī)應(yīng)用研究,2003,(2): 97-99.
[4] 宋玲.基于證書實現(xiàn)多媒體會議安全身份認(rèn)證的方案[J].計算機(jī)工程,2006,32(1):166-168.
[5] 杜煒,王行剛.構(gòu)造基于X.509公鑰證書的密鑰管理系統(tǒng)[J].計算機(jī)工程,2006,25,(10):133-135.
[6] 劉知貴,楊立春,蒲潔,張霜.基于PKI技術(shù)的數(shù)字簽名身份認(rèn)證系統(tǒng)[J].計算機(jī)應(yīng)用研究,2004,(9):158-160.endprint
TAC的發(fā)布過程如圖1所示。
第1步 證書申請者即用戶向BI證明自己身份的真實性。BI與RA相似,BI驗證用戶的真實身份并存儲用戶的身份信息,同時設(shè)置用戶的密鑰及證書的效期,而且不能由這個用戶的密鑰鏈接到用戶的真實身份,為此,BI可以向用戶發(fā)送一個信息,這個信息包含用戶的密鑰和證書的有效期,并用自己的私有密鑰進(jìn)行簽名。
第2步 BI通過一個安全信道將簽名后的信息發(fā)送給用戶,用戶收到信息之后需要在開始下一步之前驗證這個簽名,以后由TAC追蹤到用戶過程中會用到這個信息,用來防止用戶不在BI那注冊就申請證書。
第3步 用戶根據(jù)通用的標(biāo)準(zhǔn)形式來制定證書申請證書,如常用的PKCS10格式。在申請書的格式中,主體域中應(yīng)該包含一個用戶自己選擇的匿名。為了避免主體域名的沖突,這個匿名也可以由CA提供的程序自動生成。然后用戶就通過一個安全信道把請求信息發(fā)送給AI,而用戶從BI那接收到的信息作為這個請求信息的一部份。注意,這個信道不能用于認(rèn)證用戶,因為這會暴露用戶的真實身份,減少了匿名性。
第4步 AI檢查接收到的信息的格式并驗證信息中的簽名,然后驗證證書的有效期,如果是合法的,與最近已存儲的合法的信息進(jìn)行比較,來防止重放攻擊。如果主體域名已經(jīng)被另一個證書所使用,那么AI或者拒絕申請,或者選擇一個隨機(jī)的匿名。AI設(shè)置所有的域,包括證書的簽名數(shù)據(jù),對這個數(shù)據(jù)計算哈希值,對這個哈希值再進(jìn)行盲簽名。注意,如果想要實現(xiàn)匿名的話,那么BI就不應(yīng)該知道進(jìn)行盲簽名的密鑰對。隨后,AI對盲簽名后的哈希值進(jìn)行簽名,連同用戶提供的信息,并對過雙向認(rèn)證的安全信道發(fā)送給BI,AI簽名用的證書也應(yīng)該包括在內(nèi)。
第5步 BI驗證AI對盲簽名哈希值的簽名,以及自己的簽名。然后驗證匿名確保它以前沒有被用來申請過證書。為了實現(xiàn)TAC的追蹤,這個匿名是與數(shù)據(jù)庫中用戶的信息相聯(lián)系的。然后BI使用自己的門限簽名密鑰對盲簽名哈希值進(jìn)行簽名,在這之后,用自己的簽名密鑰對結(jié)果進(jìn)行簽名,然后把它發(fā)送給AI。
第6步 AI驗證BI對盲簽名哈希值的簽名,然后AI對結(jié)果去除盲化因子,最后使用自己的門限簽名密鑰來完成對TAC的簽名。TAC與匿名間的關(guān)系會被存儲,以便以后由TAC追蹤到用戶。最后,AI把TAC發(fā)送給用戶,現(xiàn)在用戶可以使用TAC了。
3.2 TAC的追蹤協(xié)議
當(dāng)發(fā)現(xiàn)證書被濫用時,為了獲得證書持有者的真實身份信息,一個可信機(jī)構(gòu)通過分別與AI和BI通信的方法啟動證書的追蹤協(xié)議,如圖2所示。
Step A 首先可信息實體向AI提供匿名證書被濫用的證明。現(xiàn)行的IP地址系統(tǒng)很大程度上取決于服務(wù)提供商為它的用戶提供的保護(hù)有多好。對于CA而言,規(guī)則應(yīng)該更嚴(yán)格,因為公布證書的匿名會比公布用戶的IP地址泄露更多的信息。之后,TAC就由權(quán)威機(jī)構(gòu)提供給AI,然后,AI撤銷TAC并添加到證書撤銷列表(CRL)中。
Step B 接下來,AI搜索與TAC相對應(yīng)的匿名,并通過雙向認(rèn)證的安全信道把它發(fā)送給可信實體。
Step C 可信實體把匿名發(fā)送給BI,并且要求得到用戶的身份信息。BI可以根據(jù)協(xié)議獨立驗證可信實體的投訴的正確性。
Step D BI驗證匿名中它自己的簽名,檢索TAC證書用戶的身份信息并把身份信息發(fā)送給可信實體。
4 結(jié)束語
在網(wǎng)絡(luò)應(yīng)用中,很多情況都可以用到RFC中提到的匿名數(shù)字證書,如果需要提供臨時或永久的身份證明而又不想泄露自己的身份信息,如在線的匿名投票、電子政務(wù)及網(wǎng)絡(luò)交易等。TAC的使用,使現(xiàn)行的PKI體系有了一個全新的發(fā)展,相信會成為未來研究的熱點。該文就是基于PKI體系發(fā)布TAC的,TAC對于外部的攻擊者充分地達(dá)到了匿名的目標(biāo),但對于來自于AI內(nèi)部的攻擊,就不能很好地保護(hù)TAC的用戶,如果AI內(nèi)部的攻擊者想要攻擊系統(tǒng),他可以發(fā)送一個對應(yīng)不同匿名的盲簽名哈希值,這就會導(dǎo)致最終的證書被鏈接到其它的用戶而不是想要得到TAC的用戶。為了解決這樣的問題,該文建議AI的員工不能在相關(guān)的BI中注冊,考慮到AI的角色類似CA,CA是一個可信任的實體,所以應(yīng)該在實際的應(yīng)用中限制發(fā)生這種攻擊的可能性。
參考文獻(xiàn):
[1] AndrewNash,williamDuane,CeliaJoseph,DerekBrink,張玉清,陳建奇,楊波,薛偉,等,譯.公鑰基礎(chǔ)設(shè)施(PKl)實現(xiàn)和管理電子安全[M].北京:清華大學(xué)出版社,2002:45-65.
[2] Michael Spalding. Deciding Whether or not to use a Third Party Certificate Authority [J].Network Security, 2000,(20):7-8.
[3] 王建業(yè),周振國,陳森發(fā).Internet X.509 PKI深入討論與分析[J].計算機(jī)應(yīng)用研究,2003,(2): 97-99.
[4] 宋玲.基于證書實現(xiàn)多媒體會議安全身份認(rèn)證的方案[J].計算機(jī)工程,2006,32(1):166-168.
[5] 杜煒,王行剛.構(gòu)造基于X.509公鑰證書的密鑰管理系統(tǒng)[J].計算機(jī)工程,2006,25,(10):133-135.
[6] 劉知貴,楊立春,蒲潔,張霜.基于PKI技術(shù)的數(shù)字簽名身份認(rèn)證系統(tǒng)[J].計算機(jī)應(yīng)用研究,2004,(9):158-160.endprint
TAC的發(fā)布過程如圖1所示。
第1步 證書申請者即用戶向BI證明自己身份的真實性。BI與RA相似,BI驗證用戶的真實身份并存儲用戶的身份信息,同時設(shè)置用戶的密鑰及證書的效期,而且不能由這個用戶的密鑰鏈接到用戶的真實身份,為此,BI可以向用戶發(fā)送一個信息,這個信息包含用戶的密鑰和證書的有效期,并用自己的私有密鑰進(jìn)行簽名。
第2步 BI通過一個安全信道將簽名后的信息發(fā)送給用戶,用戶收到信息之后需要在開始下一步之前驗證這個簽名,以后由TAC追蹤到用戶過程中會用到這個信息,用來防止用戶不在BI那注冊就申請證書。
第3步 用戶根據(jù)通用的標(biāo)準(zhǔn)形式來制定證書申請證書,如常用的PKCS10格式。在申請書的格式中,主體域中應(yīng)該包含一個用戶自己選擇的匿名。為了避免主體域名的沖突,這個匿名也可以由CA提供的程序自動生成。然后用戶就通過一個安全信道把請求信息發(fā)送給AI,而用戶從BI那接收到的信息作為這個請求信息的一部份。注意,這個信道不能用于認(rèn)證用戶,因為這會暴露用戶的真實身份,減少了匿名性。
第4步 AI檢查接收到的信息的格式并驗證信息中的簽名,然后驗證證書的有效期,如果是合法的,與最近已存儲的合法的信息進(jìn)行比較,來防止重放攻擊。如果主體域名已經(jīng)被另一個證書所使用,那么AI或者拒絕申請,或者選擇一個隨機(jī)的匿名。AI設(shè)置所有的域,包括證書的簽名數(shù)據(jù),對這個數(shù)據(jù)計算哈希值,對這個哈希值再進(jìn)行盲簽名。注意,如果想要實現(xiàn)匿名的話,那么BI就不應(yīng)該知道進(jìn)行盲簽名的密鑰對。隨后,AI對盲簽名后的哈希值進(jìn)行簽名,連同用戶提供的信息,并對過雙向認(rèn)證的安全信道發(fā)送給BI,AI簽名用的證書也應(yīng)該包括在內(nèi)。
第5步 BI驗證AI對盲簽名哈希值的簽名,以及自己的簽名。然后驗證匿名確保它以前沒有被用來申請過證書。為了實現(xiàn)TAC的追蹤,這個匿名是與數(shù)據(jù)庫中用戶的信息相聯(lián)系的。然后BI使用自己的門限簽名密鑰對盲簽名哈希值進(jìn)行簽名,在這之后,用自己的簽名密鑰對結(jié)果進(jìn)行簽名,然后把它發(fā)送給AI。
第6步 AI驗證BI對盲簽名哈希值的簽名,然后AI對結(jié)果去除盲化因子,最后使用自己的門限簽名密鑰來完成對TAC的簽名。TAC與匿名間的關(guān)系會被存儲,以便以后由TAC追蹤到用戶。最后,AI把TAC發(fā)送給用戶,現(xiàn)在用戶可以使用TAC了。
3.2 TAC的追蹤協(xié)議
當(dāng)發(fā)現(xiàn)證書被濫用時,為了獲得證書持有者的真實身份信息,一個可信機(jī)構(gòu)通過分別與AI和BI通信的方法啟動證書的追蹤協(xié)議,如圖2所示。
Step A 首先可信息實體向AI提供匿名證書被濫用的證明?,F(xiàn)行的IP地址系統(tǒng)很大程度上取決于服務(wù)提供商為它的用戶提供的保護(hù)有多好。對于CA而言,規(guī)則應(yīng)該更嚴(yán)格,因為公布證書的匿名會比公布用戶的IP地址泄露更多的信息。之后,TAC就由權(quán)威機(jī)構(gòu)提供給AI,然后,AI撤銷TAC并添加到證書撤銷列表(CRL)中。
Step B 接下來,AI搜索與TAC相對應(yīng)的匿名,并通過雙向認(rèn)證的安全信道把它發(fā)送給可信實體。
Step C 可信實體把匿名發(fā)送給BI,并且要求得到用戶的身份信息。BI可以根據(jù)協(xié)議獨立驗證可信實體的投訴的正確性。
Step D BI驗證匿名中它自己的簽名,檢索TAC證書用戶的身份信息并把身份信息發(fā)送給可信實體。
4 結(jié)束語
在網(wǎng)絡(luò)應(yīng)用中,很多情況都可以用到RFC中提到的匿名數(shù)字證書,如果需要提供臨時或永久的身份證明而又不想泄露自己的身份信息,如在線的匿名投票、電子政務(wù)及網(wǎng)絡(luò)交易等。TAC的使用,使現(xiàn)行的PKI體系有了一個全新的發(fā)展,相信會成為未來研究的熱點。該文就是基于PKI體系發(fā)布TAC的,TAC對于外部的攻擊者充分地達(dá)到了匿名的目標(biāo),但對于來自于AI內(nèi)部的攻擊,就不能很好地保護(hù)TAC的用戶,如果AI內(nèi)部的攻擊者想要攻擊系統(tǒng),他可以發(fā)送一個對應(yīng)不同匿名的盲簽名哈希值,這就會導(dǎo)致最終的證書被鏈接到其它的用戶而不是想要得到TAC的用戶。為了解決這樣的問題,該文建議AI的員工不能在相關(guān)的BI中注冊,考慮到AI的角色類似CA,CA是一個可信任的實體,所以應(yīng)該在實際的應(yīng)用中限制發(fā)生這種攻擊的可能性。
參考文獻(xiàn):
[1] AndrewNash,williamDuane,CeliaJoseph,DerekBrink,張玉清,陳建奇,楊波,薛偉,等,譯.公鑰基礎(chǔ)設(shè)施(PKl)實現(xiàn)和管理電子安全[M].北京:清華大學(xué)出版社,2002:45-65.
[2] Michael Spalding. Deciding Whether or not to use a Third Party Certificate Authority [J].Network Security, 2000,(20):7-8.
[3] 王建業(yè),周振國,陳森發(fā).Internet X.509 PKI深入討論與分析[J].計算機(jī)應(yīng)用研究,2003,(2): 97-99.
[4] 宋玲.基于證書實現(xiàn)多媒體會議安全身份認(rèn)證的方案[J].計算機(jī)工程,2006,32(1):166-168.
[5] 杜煒,王行剛.構(gòu)造基于X.509公鑰證書的密鑰管理系統(tǒng)[J].計算機(jī)工程,2006,25,(10):133-135.
[6] 劉知貴,楊立春,蒲潔,張霜.基于PKI技術(shù)的數(shù)字簽名身份認(rèn)證系統(tǒng)[J].計算機(jī)應(yīng)用研究,2004,(9):158-160.endprint