
數(shù)據(jù)安全解決方案
目錄
數(shù)據(jù)安全解決方案 ........................................................................................................................... 1
1. 數(shù)據(jù)安全與防泄密保護系統(tǒng)模型 ........................................................................................... 3
1.1. 數(shù)據(jù)威脅模型 ............................................................................................................... 3
2. 數(shù)據(jù)安全與防泄密系統(tǒng)模型形式化描述 ............................................................................... 5
3. 數(shù)據(jù)加密與封裝技術 ............................................................................................................... 7
3.1. 數(shù)據(jù)加密保護機制 ....................................................................................................... 7
3.2. 數(shù)據(jù)加密策略 ............................................................................................................... 7
3.3. 數(shù)據(jù)加密保護流程 ....................................................................................................... 8
4. 密鑰管理技術 ......................................................................................................................... 11
4.1. 密胡管理模型 ............................................................................................................. 11
5. 數(shù)字證書 ................................................................................................................................. 12
5.1. 簽名和加密 ................................................................................................................. 12
5.2. 一個加密通信過程的演化 ......................................................................................... 12
5.2.1. 第一階段 ......................................................................................................... 13
5.2.2. 第二階段 ......................................................................................................... 13
5.2.3. 第三階段 ......................................................................................................... 14
5.2.4. 第四階段 ......................................................................................................... 15
5.2.5. 第五階段 ......................................................................................................... 17
5.2.6. 完整過程 ......................................................................................................... 17
5.3. 數(shù)字證書原理 ............................................................................................................. 18
6. 內容安全 ................................................................................................................................. 19
1. 數(shù)據(jù)安全與防泄密保護系統(tǒng)模型
1.1. 數(shù)據(jù)威脅模型
數(shù)據(jù)的安全技術主要建立在保密性(Confidentiality)、完整性(Integrity)和可用性(Availability)三
個安全原則基礎之上。實際上,數(shù)據(jù)面臨著嚴重的威脅(如下圖所示),主要受到通信因素、存
儲因素、身份認證、訪問控制、數(shù)據(jù)發(fā)布、審計因素、制度因素和人員問題八大因素,具體
因素內容在圖2-1中詳細的列舉出來。
數(shù)據(jù)威脅模型
(1)通信威脅
通信威脅指數(shù)據(jù)在網(wǎng)絡通信和傳輸過程中所面臨的威脅因素,主要包括數(shù)據(jù)截獲算改、盜竊
和監(jiān)聽、蠕蟲和拒絕服務攻擊。
(2)存儲因素
存儲因素是指數(shù)據(jù)在存儲過程中由于物理安全所面臨的威脅,包括自然因素或者人為因素導
致的數(shù)據(jù)破壞、盜竊或者丟失。
(3)身份認證
身份認證因素是指數(shù)據(jù)面臨的各種與身份認證有關的威脅,包括外部認證服務遭受攻擊、通
過非法方式(如使用特洛伊木馬、網(wǎng)絡探等)獲取用戶認證信息、身份抵賴。
(4)訪問控制因素
訪問控制因素是指數(shù)據(jù)面臨的所有對用戶授權和訪問控制的威脅因素,主要包括未經(jīng)授權的
數(shù)據(jù)訪問、用戶錯誤操作或濫用權限、通過推理通道獲取一些無權獲取的信息。
(5)數(shù)據(jù)發(fā)布因素
數(shù)據(jù)發(fā)布因素是指在開放式環(huán)境下,數(shù)據(jù)發(fā)布過程中所遭受的隱私侵犯、數(shù)據(jù)盜版等威脅因
素。
(6)審計因素
審計因素是指在審計過程中所面臨的威脅因素,如審計記錄無法分析、審計記錄不全面、審
計攻能被攻擊者或管理員惡意關閉。
(7)法律制度因素
法律制度因素是指由于法律制度相關原因而使數(shù)據(jù)面臨威脅,主要原因包括信息安全保障法
律制度不健全、對攻擊者的法律責任追究不夠。
(8)內部人員因素
人員因素是指因為內部人士的疏忽或其它因素導致數(shù)據(jù)面臨威脅,如管理員濫用權力、用戶
濫用權限、管理員的安全意識不強等。
2. 數(shù)據(jù)安全與防泄密系統(tǒng)模型形式化描述
一個安全的數(shù)據(jù)防泄密信任模型包括主體、客體、數(shù)據(jù)內容加密保護、權限許可狀態(tài)管理等
四部分。其中,數(shù)據(jù)內容瞬態(tài)加密保護是最為核心也最為基礎的階段,而權限許可狀態(tài)決定了
數(shù)據(jù)使用控制的安全許可粒度。
數(shù)據(jù)安全與防泄密系統(tǒng)模型
(1)主體
數(shù)據(jù)安全與防泄密信任模型中主體是指數(shù)據(jù)使用主體、分發(fā)主體、創(chuàng)建主體、管理主體。其
中,前兩者是數(shù)據(jù)用戶,而后兩者則是用于管理數(shù)據(jù)的主體。
(2)客體
客體是指授權主體執(zhí)行權限的對象,包括一切形式的電子數(shù)據(jù)作品。
(3)數(shù)據(jù)內容加密保護
數(shù)據(jù)內容瞬態(tài)加密保護模型本質上是在內核態(tài)安全執(zhí)行環(huán)境(Kemel environment, KE)下,對原
始明文內容在特定的密鑰管理組件控制下實施瞬態(tài)同步(SYN)加解密(Crypto),生成受保護內
容C的一個復合模型。涉及到相關加解密(對稱加解密、非對稱加解密)、摘要和簽名等基本
操作,而對稱加密涉及到ECB、CBC、OFB、CFB等加密模式密鑰包括密胡的生成、分發(fā)、吊
銷、更新等環(huán)節(jié)。
(4)權限許可狀態(tài)管理
權限許可狀態(tài)管理模型通過不同的授權方式(比如用戶授權、使用時間、設備授權、環(huán)境授
權、文件授權等)對文件設置不同的操作權限,細化到閱讀次數(shù)、使用有效期限、使用地點等
權限,防止用戶非法拷貝、復制、打印、下載文件、通過電子郵件、移動硬盤等傳輸介質泄
密。
3. 數(shù)據(jù)加密與封裝技術
3.1. 數(shù)據(jù)加密保護機制
數(shù)據(jù)加密保護基于如下機制:
(1) 過濾驅動文件透明加解密:
采用系統(tǒng)指定的加解密策略(如加解密算法、密鑰和文件類型等),在數(shù)據(jù)創(chuàng)建、存儲、傳輸?shù)?/span> 瞬態(tài)進行自動加密,整個過程完全不需要用戶的參與,用戶無法干預數(shù)據(jù)在創(chuàng)建、存儲、傳輸、 分發(fā)過程中的安全狀態(tài)和安全屬性。 (2) 內容加密: 系統(tǒng)對數(shù)據(jù)使用對稱加密密鑰加密,然后打包封裝。數(shù)據(jù)可以在分發(fā)前預先加密打包存儲,也 可以在分發(fā)時即時加密打包。 (3) 內容完整性: 內容發(fā)送方向接收方發(fā)送數(shù)據(jù)時,數(shù)據(jù)包包含數(shù)據(jù)的Hash值,接收方收到數(shù)據(jù)包解密后獲得 數(shù)據(jù)明文,計算Hash值,并與對應數(shù)據(jù)包中攜帶的Hash值作比較,兩者相同表示該數(shù)據(jù)信息未 在傳輸過程中被修改。 (4) 身份認證: 所有的用戶都各自擁有自己唯一的數(shù)字證書和公私鑰對,發(fā)送方和接收方通過PKI證書認證 機制,相互確認對方身份的合法性。 (5) 可靠與完整性: 為保證數(shù)據(jù)包的可靠性和完整性,數(shù)據(jù)包中攜帶的重要信息(如內容加密密鑰)采用接收方的 公鋼進行加密封裝,從而將數(shù)據(jù)包綁定到該接收方,確保僅有指定的接收方才能正確解密該數(shù) 據(jù)包,使用其私鑰提取內容加密密鋼。另外,發(fā)送方向接收方發(fā)送數(shù)據(jù)包前,先用其私鑰對封裝 后的數(shù)據(jù)包進行數(shù)字簽名。接收方對收到的數(shù)據(jù)包采用發(fā)送方的公朗對數(shù)字簽名進行驗證, 從而確認數(shù)據(jù)包是否來自于發(fā)送方,且在傳輸過程中未被修改。 3.2. 數(shù)據(jù)加密策略 數(shù)據(jù)加解密系統(tǒng)采用系統(tǒng)指定的加解密策略(如加解密算法、密鑰和文件類型等)自動的對數(shù) 據(jù)進行加解密操作,從而對數(shù)據(jù)安全方便有效的進行保護。針對不同的文件類型,系統(tǒng)將自動 采用不同的密鑰以及算法對數(shù)據(jù)文件進行加密,實時動態(tài)的對數(shù)據(jù)進行保護。數(shù)據(jù)加密策略 主要包括加解密算法、密鑰生成算法、密鑰保護算法、密鑰類型以及文件類型等。 本模型主要采用的密碼學算法列表如下: 數(shù)據(jù)加解密策略列表 3.3. 數(shù)據(jù)加密保護流程 開放絡環(huán)境下數(shù)據(jù)加密保護流程包括: 開放網(wǎng)絡環(huán)境下數(shù)據(jù)加密保護流程圖 ? 數(shù)據(jù)創(chuàng)建者創(chuàng)建電子文檔,客戶端采用過濾驅動透明加解密技術對電子文檔進行加密,數(shù) 據(jù)以密文形式存儲在終端中 ? 創(chuàng)建者設置數(shù)據(jù)消息安全屬性Leve/ (如密級)以及相關權限信息Metedata.不同的等級 對應不同的權限操作 ? 創(chuàng)建者將內容加密密鑰以服務端的公鑰進行加密 ? 創(chuàng)建者將數(shù)據(jù)明文作Hash計算,并將數(shù)據(jù)密文、明文Hash值、密鑰加密密鑰以及權限 信息進行打包封裝 ? 創(chuàng)建者通過私鑰對數(shù)據(jù)包進行簽名以保證數(shù)據(jù)包的可靠性和完整性,發(fā)送給服務端備份 存儲 ? 服務端收到數(shù)據(jù)包后,用創(chuàng)建者的公鑰驗證數(shù)據(jù)簽名以確認數(shù)據(jù)包的可靠性和完整性,并 利用自己的私鑰提取內容加密密鑰以及數(shù)據(jù)的相關安全屬性 ? 服務端通過提取出來的內容加密密鑰對數(shù)據(jù)密文進行解密后,將得到的數(shù)據(jù)明文做Hash 計算與數(shù)據(jù)包中提取出來的Hash值做比較,若比較一致,則根據(jù)相關安全屬性對數(shù)據(jù)進 行備份存儲 場景描述:A:發(fā)送方 B:接收方 A要發(fā)送一段消息給B,但是又不想以明文發(fā)送,所以就需要對消息進行加密.如果采用對 稱加密技術,那么加密與解密用的是同一把秘鑰.除非B事先就知道A的秘鑰,并且保存好.這 樣才可以解密A發(fā)來的消息. 由于對稱技術只有一把秘鑰,所以秘鑰的管理是一個很麻煩的問題.而非對稱技術的誕生 就解決了這個問題.非對稱加密與解密使用的是不同的秘鑰,并且秘鑰對是一一對應的,即用A 的私鑰加密的密文只有用A的公鑰才能解密. 這樣的話,每個人都有兩把秘鑰,私鑰和公鑰,私鑰是只有自己才知道的,不能告訴別人,而 公鑰是公開的,大家都可以知道.這樣,當A想要發(fā)送消息給B 的時候,只需要用B的公鑰對消 息進行加密就可以了,由于B的私鑰只有B才擁有,所以A用B的公鑰加密的消息只有B才能 解開.而B想更換自己的密鑰時也很方便,只須把公鑰告訴大家就可以了. 那么,既然非對稱加密如此之好,對稱加密就沒有存在的必要了啊,其實不然,由于非對稱 加密算法的開銷很大,所以如果直接以非對稱技術來加密發(fā)送的消息效率會很差.那么怎么辦 呢?解決的辦法也很簡單,就是把對稱加密技術與非對稱加密技術結合起來使用. A要發(fā)送一個消息給B ? A先生成一個對稱秘鑰,這個秘鑰可以是隨機生成的, ? A用B的公鑰加密第一步生成的這個對稱秘鑰 ? A把加密過的對稱秘鑰發(fā)給B ? A用第一步生成的這個對稱秘鑰加密實際要發(fā)的消息 ? A把用對稱秘鑰加密的消息發(fā)給B 對于B ? 他先收到A發(fā)來的對稱秘鑰,這個秘鑰是用B的公鑰加密過的,所以B需要用自己的私鑰 來解密這個秘鑰然后B又收到A發(fā)來的密文,這時候用剛才解密出來的秘鑰來解密密文 這樣子的整個過程既保證了安全,又保證了效率. 4. 密鑰管理技術 4.1. 密胡管理模型 在一個安全系統(tǒng)中,總體安全性依賴于許多不同的因素,例如算法的強度、密鑰的大小、口令 的選擇、協(xié)議的安全性等,其中對密鑰或口令的保護是尤其重要的。根據(jù)柯克霍夫假設 (KerckhoffsAssumption),密碼系統(tǒng)的安全完全取決于可隨時改變的密鑰。即使密碼算法公開, 也不會危及密碼體制的安全性,但是,當密鑰丟失時,非法用戶將有可能竊取保密信息。另外, 有預謀的修改密鑰和對密鑰進行其他形式的非法操作,將涉及到整個安全系統(tǒng)的安全性。因 此,密鑰管理在整個密碼系統(tǒng)中是極其重要的。密鑰管理包括密鑰的產(chǎn)生、裝入、存儲、備 份、分配、更新、吊銷和銷毀等環(huán)節(jié),是提供數(shù)據(jù)保密性、數(shù)據(jù)完整性、可用性、可審查性 和不可抵賴性等安全技術的基礎。 5. 數(shù)字證書 5.1. 簽名和加密 我們說加密,是指對某個內容加密,加密后的內容還可以通過解密進行還原。比如我們 把一封郵件進行加密,加密后的內容在網(wǎng)絡上進行傳輸,接收者在收到后,通過解密可以還 原郵件的真實內容。 這里主要解釋一下簽名,簽名就是在信息的后面再加上一段內容,可以證明信息沒有被 修改過,怎么樣可以達到這個效果呢?一般是對信息做一個hash計算得到一個hash值,注 意,這個過程是不可逆的,也就是說無法通過hash值得出原來的信息內容。在把信息發(fā)送 出去時,把這個hash值加密后做為一個簽名和信息一起發(fā)出去。接收方在收到信息后,會 重新計算信息的hash值,并和信息所附帶的hash值(解密后)進行對比,如果一致,就說明 信息的內容沒有被修改過,因為這里hash計算可以保證不同的內容一定會得到不同的hash 值,所以只要內容一被修改,根據(jù)信息內容計算的hash值就會變化。當然,不懷好意的人 也可以修改信息內容的同時也修改hash值,從而讓它們可以相匹配,為了防止這種情況, hash值一般都會加密后(也就是簽名)再和信息一起發(fā)送,以保證這個hash值不被修改。至 于如何讓別人可以解密這個簽名,這個過程涉及到數(shù)字證書等概念,我們后面在說到數(shù)字證 書時再詳細說明,這里您先只需先理解簽名的這個概念。 5.2. 一個加密通信過程的演化 我們來看一個例子,現(xiàn)在假設“服務器”和“客戶”要在網(wǎng)絡上通信,并且他們打算使 用RSA(參看前面的RSA簡介)來對通信進行加密以保證談話內容的安全。由于是使用RSA這 種公鑰密碼體制,“服務器”需要對外發(fā)布公鑰(算法不需要公布,RSA的算法大家都知道), 自己留著私鑰。“客戶”通過某些途徑拿到了“服務器”發(fā)布的公鑰,客戶并不知道私鑰。 “客戶”具體是通過什么途徑獲取公鑰的,我們后面再來說明,下面看一下雙方如何進行保 密的通信。 5.2.1. 第一階段 ? “客戶”->“服務器”:你好 ? “服務器”->“客戶”:你好,我是服務器 ? “客戶”->“服務器”:???? 因為消息是在網(wǎng)絡上傳輸?shù)模腥丝梢悦俺渥约菏?/span>“服務器”來向客戶發(fā)送信息。黑客 在“客戶”和“服務器”之間的某個路由器上截獲“客戶”發(fā)給服務器的信息,然后自己冒 充“服務器”。例如上面的消息可以被黑客截獲如下: ? “客戶”->“黑客”:你好 ? “黑客”->“客戶”:你好,我是服務器 因此“客戶”在接到消息后,并不能肯定這個消息就是由“服務器”發(fā)出的,某些“黑客”也 可以冒充“服務器”發(fā)出這個消息。如何確定信息是由“服務器”發(fā)過來的呢?有一個解決方法, 因為只有服務器有私鑰,所以如果只要能夠確認對方有私鑰,那么對方就是“服務器”。因此 通信過程可以改進為如下: 5.2.2. 第二階段 ? “客戶”->“服務器”:你好 ? “服務器”->“客戶”:你好,我是服務器 ? “客戶”->“服務器”:向我證明你就是服務器 ? “服務器”->“客戶”:你好,我是服務器 {你好,我是服務器}[私鑰|RSA] 注意:這里約定一下,{} 表示RSA加密后的內容,[ | ]表示用什么密鑰和算法進行加密, 后面的示例中都用這種表示方式,例如上面的 {你好,我是服務器}[私鑰|RSA] 就表示用私 鑰對“你好,我是服務器”進行加密后的結果。 為了向“客戶”證明自己是“服務器”,“服務器”把一個字符串用自己的私鑰加密,把 明文和加密后的密文一起發(fā)給“客戶”。對于這里的例子來說,就是把字符串“你好,我是 服務器”和這個字符串用私鑰加密后的內容 {你好,我是服務器}[私鑰|RSA] 發(fā)給客戶。 “客戶”收到信息后,她用自己持有的公鑰解密密文,和明文進行對比,如果一致,說 明信息的確是由服務器發(fā)過來的。也就是說“客戶”把 {你好,我是服務器}[私鑰|RSA] 這 個內容用公鑰進行解密,然后和“你好,我是服務器”對比。因為由“服務器”用私鑰加密 后的內容,由并且只能由公鑰進行解密,私鑰只有“服務器”持有,所以如果解密出來的內 容是能夠對得上的,那說明信息一定是從“服務器”發(fā)過來的。 假設“黑客”想冒充“服務器”: ? “黑客”->“客戶”:你好,我是服務器 ? “客戶”->“黑客”:向我證明你就是服務器 ? “黑客”->“客戶”:你好,我是服務器 {你好,我是服務器}[???|RSA] ? “客戶”->“黑客”:???? 這里黑客無法冒充,因為他不知道私鑰,無法用私鑰加密某個字符串后發(fā)送給客戶去驗 證。 由于“黑客”沒有“服務器”的私鑰,因此它發(fā)送過去的內容,“客戶”是無法通過服 務器的公鑰解密的,因此可以認定對方是個冒牌貨! 到這里為止,“客戶”就可以確認“服務器”的身份了,可以放心和“服務器”進行通 信,但是這里有一個問題,通信的內容在網(wǎng)絡上還是無法保密。為什么無法保密呢?通信過 程不是可以用公鑰、私鑰加密嗎?其實用RSA的私鑰和公鑰是不行的,我們來具體分析下 過程,看下面的演示: 5.2.3. 第三階段 ? “客戶”->“服務器”:你好 ? “服務器”->“客戶”:你好,我是服務器 ? “客戶”->“服務器”:向我證明你就是服務器 ? “服務器”->“客戶”:你好,我是服務器 {你好,我是服務器}[私鑰|RSA] ? “客戶”->“服務器”:{我的帳號是aaa,密碼是123,把我的余額的信息發(fā)給我看看}[公 鑰|RSA] ? “服務器”->“客戶”:{你的余額是100元}[私鑰|RSA] 注意上面的的信息 {你的余額是100元}[私鑰],這個是“服務器”用私鑰加密后的內容, 但是我們之前說了,公鑰是發(fā)布出去的,因此所有的人都知道公鑰,所以除了“客戶”,其 它的人也可以用公鑰對{你的余額是100元}[私鑰]進行解密。所以如果“服務器”用私鑰加 密發(fā)給“客戶”,這個信息是無法保密的,因為只要有公鑰就可以解密這內容。然而“服務 器”也不能用公鑰對發(fā)送的內容進行加密,因為“客戶”沒有私鑰,發(fā)送給“客戶”也解密 不了。 這樣問題就又來了,那又如何解決呢?在實際的應用過程,一般是通過引入對稱加密來 解決這個問題,看下面的演示: 5.2.4. 第四階段 ? “客戶”->“服務器”:你好 ? “服務器”->“客戶”:你好,我是服務器 ? “客戶”->“服務器”:向我證明你就是服務器 ? “服務器”->“客戶”:你好,我是服務器 {你好,我是服務器}[私鑰|RSA] ? “客戶”->“服務器”:{我們后面的通信過程,用對稱加密來進行,這里是對稱加密算 法和密鑰}[公鑰|RSA] ? “服務器”->“客戶”:{OK,收到!}[密鑰|對稱加密算法] ? “客戶”->“服務器”:{我的帳號是aaa,密碼是123,把我的余額的信息發(fā)給我看看}[密 鑰|對稱加密算法] ? “服務器”->“客戶”:{你的余額是100元}[密鑰|對稱加密算法] 在上面的通信過程中,“客戶”在確認了“服務器”的身份后,“客戶”自己選擇一個對 稱加密算法和一個密鑰,把這個對稱加密算法和密鑰一起用公鑰加密后發(fā)送給“服務器”。 注意,由于對稱加密算法和密鑰是用公鑰加密的,就算這個加密后的內容被“黑客”截獲了, 由于沒有私鑰,“黑客”也無從知道對稱加密算法和密鑰的內容。 由于是用公鑰加密的,只有私鑰能夠解密,這樣就可以保證只有服務器可以知道對稱加 密算法和密鑰,而其它人不可能知道(這個對稱加密算法和密鑰是“客戶”自己選擇的,所 以“客戶”自己當然知道如何解密加密)。這樣“服務器”和“客戶”就可以用對稱加密算 法和密鑰來加密通信的內容了。 到這里,“客戶”就可以確認“服務器”的身份,并且雙方的通信內容可以進行加密, 其他人就算截獲了通信內容,也無法解密。的確,好像通信的過程是比較安全了。但是這里 還留有一個問題,在最開始我們就說過,“服務器”要對外發(fā)布公鑰,那“服務器”如何把 公鑰發(fā)送給“客戶”呢?我們第一反應可能會想到以下的兩個方法: ? A:把公鑰放到互聯(lián)網(wǎng)的某個地方的一個下載地址,事先給“客戶”去下載。 ? B:每次和“客戶”開始通信時,“服務器”把公鑰發(fā)給“客戶”。 但是這個兩個方法都有一定的問題, 對于A方法,“客戶”無法確定這個下載地址是不是“服務器”發(fā)布的,你憑什么就相 信這個地址下載的東西就是“服務器”發(fā)布的而不是別人偽造的呢,萬一下載到一個假的怎 么辦?另外要所有的“客戶”都在通信前事先去下載公鑰也很不現(xiàn)實。 對于B方法,也有問題,因為任何人都可以自己生成一對公鑰和私鑰,他只要向“客戶” 發(fā)送他自己的私鑰就可以冒充“服務器”了。示意如下: ? “客戶”->“黑客”:你好 //黑客截獲“客戶”發(fā)給“服務器”的消息 ? “黑客”->“客戶”:你好,我是服務器,這個是我的公鑰 //黑客自己生成一對公鑰和私鑰,把公鑰發(fā)給“客戶”,自己保留私鑰 ? “客戶”->“黑客”:向我證明你就是服務器 ? “黑客”->“客戶”:你好,我是服務器 {你好,我是服務器}[黑客自己的私鑰|RSA] //客戶收到“黑客”用私鑰加密的信息后,是可以用“黑客”發(fā)給自己的公鑰解密 的,從而會誤認為“黑客”是“服務器” 因此“黑客”只需要自己生成一對公鑰和私鑰,然后把公鑰發(fā)送給“客戶”,自己保留 私鑰,這樣由于“客戶”可以用黑客的公鑰解密黑客的私鑰加密的內容,“客戶”就會相信 “黑客”是“服務器”,從而導致了安全問題。這里問題的根源就在于,大家都可以生成公 鑰、私鑰對,無法確認公鑰對到底是誰的。如果能夠確定公鑰到底是誰的,就不會有這個問 題了。例如,如果收到“黑客”冒充“服務器”發(fā)過來的公鑰,經(jīng)過某種檢查,如果能夠發(fā) 現(xiàn)這個公鑰不是“服務器”的就好了。 為了解決這個問題,數(shù)字證書出現(xiàn)了,它可以解決我們上面的問題。先大概看下什么是 數(shù)字證書,一個證書包含下面的具體內容: ? 證書的發(fā)布機構 ? 證書的有效期 ? 公鑰 ? 證書所有者(Subject) ? 簽名所使用的算法 ? 指紋以及指紋算法 證書的內容的詳細解釋會在后面詳細解釋,這里先只需要搞清楚一點,數(shù)字證書可以保 證數(shù)字證書里的公鑰確實是這個證書的所有者(Subject)的,或者證書可以用來確認對方的身 份。也就是說,我們拿到一個數(shù)字證書,我們可以判斷出這個數(shù)字證書到底是誰的。至于是 如何判斷的,后面會在詳細討論數(shù)字證書時詳細解釋。現(xiàn)在把前面的通信過程使用數(shù)字證書 修改為如下: 5.2.5. 第五階段 ? “客戶”->“服務器”:你好 ? “服務器”->“客戶”:你好,我是服務器,這里是我的數(shù)字證書 //這里用證書代替了公鑰 ? “客戶”->“服務器”:向我證明你就是服務器 ? “服務器”->“客戶”:你好,我是服務器 {你好,我是服務器}[私鑰|RSA] 注意:上面第二次通信,“服務器”把自己的證書發(fā)給了“客戶”,而不是發(fā)送公鑰。“客 戶”可以根據(jù)證書校驗這個證書到底是不是“服務器”的,也就是能校驗這個證書的所有者 是不是“服務器”,從而確認這個證書中的公鑰的確是“服務器”的。后面的過程和以前是 一樣,“客戶”讓“服務器”證明自己的身份,“服務器”用私鑰加密一段內容連同明文一起 發(fā)給“客戶”,“客戶”把加密內容用數(shù)字證書中的公鑰解密后和明文對比,如果一致,那么 對方就確實是“服務器”,然后雙方協(xié)商一個對稱加密來保證通信過程的安全。到這里,整 個過程就完整了,我們回顧一下: 5.2.6. 完整過程 ? “客戶”->“服務器”:你好 ? “服務器”->“客戶”:你好,我是服務器,這里是我的數(shù)字證書 ? “客戶”->“服務器”:向我證明你就是服務器,這是一個隨機字符串 //前面的例子中為了方便解釋,用的是“你好”等內容,實際情況下一般是隨機生成 的一個字符串。 ? “服務器”->“客戶”:{一個隨機字符串}[私鑰|RSA] ? “客戶”->“服務器”:{我們后面的通信過程,用對稱加密來進行,這里是對稱加密 算法和密鑰}[公鑰|RSA] ? “服務器”->“客戶”:{OK,已經(jīng)收到你發(fā)來的對稱加密算法和密鑰!有什么可以幫 到你的?}[密鑰|對稱加密算法] ? “客戶”->“服務器”:{我的帳號是aaa,密碼是123,把我的余額的信息發(fā)給我看看}[密 鑰|對稱加密算法] ? “服務器”->“客戶”:{你好,你的余額是100元}[密鑰|對稱加密算法] ? ?? //繼續(xù)其它的通信 5.3. 數(shù)字證書原理 為了保證安全,在證書的發(fā)布機構發(fā)布證書時,證書的指紋和指紋算法,都會加密后再 和證書放到一起發(fā)布,以防有人修改指紋后偽造相應的數(shù)字證書。這里問題又來了,證書的 指紋和指紋算法用什么加密呢?他們是用證書發(fā)布機構的私鑰進行加密的。可以用證書發(fā)布 機構的公鑰對指紋和指紋算法解密,也就是說證書發(fā)布機構除了給別人發(fā)布證書外,他自己 本身也有自己的證書。證書發(fā)布機構的證書是哪里來的呢?這個證書發(fā)布機構的數(shù)字證書 (一般由他自己生成)在我們的操作系統(tǒng)剛安裝好時(例如windows xp等操作系統(tǒng)),這些證書 發(fā)布機構的數(shù)字證書就已經(jīng)被微軟(或者其它操作系統(tǒng)的開發(fā)機構)安裝在操作系統(tǒng)中了,微 軟等公司會根據(jù)一些權威安全機構的評估選取一些信譽很好并且通過一定的安全認證的證 書發(fā)布機構,把這些證書發(fā)布機構的證書默認就安裝在操作系統(tǒng)里面了,并且設置為操作系 統(tǒng)信任的數(shù)字證書。這些證書發(fā)布機構自己持有與他自己的數(shù)字證書對應的私鑰,他會用這 個私鑰加密所有他發(fā)布的證書的指紋作為數(shù)字簽名。 6. 內容安全 內容安全主要是直接保護在系統(tǒng)中傳輸和存儲的數(shù)據(jù)(信息)。在做內容安全工作中, 主要是對信息和內容本身做一些變形和變換,或者對具體的內容進行檢查。我們也可以將內 容安全理解為在內容和應用的層次上進行的安全工作,一些系統(tǒng)層次的安全功能在這個層次 都有對應和類似的功能。 可以歸結到內容安全類型的典型技術包括: 序號 技術 技術說明 1 加密(保密性、完是一個非常傳統(tǒng),但又一直是一個非常有效的技術 整性、抗抵賴等) 2 內容過濾 對于企業(yè)關心的一些主題進行內容檢查和過濾,技術可能用關鍵 字技術,也可能使用基于知識庫語義識別過濾系統(tǒng)。 3 防病毒 計算機病毒一般都隱藏在程序和文檔中。目前典型的防病毒技術 就是對信息中的病毒特征代碼進行識別和查殺。 4 VPN加密通道 虛擬專用網(wǎng)VPN需要通過不可信的公用網(wǎng)絡來建立自己的安全 信道,因此加密技術是重要的選擇。 5 水印技術 水印技術是信息隱藏技術的一種。一般信息都是要隱藏在有一定 冗余量的媒體中,比如圖像、聲音、錄像等多媒體信息,在文本 中進行隱藏比較少。水印技術是可以替代一般密碼技術的保密方 法。

本文發(fā)布于:2023-05-24 10:41:31,感謝您對本站的認可!
本文鏈接:http://www.newhan.cn/zhishi/a/168489609152456.html
版權聲明:本站內容均來自互聯(lián)網(wǎng),僅供演示用,請勿用于商業(yè)和其他非法用途。如果侵犯了您的權益請與我們聯(lián)系,我們將在24小時內刪除。
本文word下載地址:數(shù)據(jù)安全解決方案.doc
本文 PDF 下載地址:數(shù)據(jù)安全解決方案.pdf
| 留言與評論(共有 0 條評論) |