• 沒有找到結果。

序言

在文檔中 安全規約分析系統 (頁 8-11)

在此章節中,我們首先介紹我們的研究動機為何,然後說明本篇論文的目標 為何,在最後一節中,我們描述此論文的架構。

1.1 研究動機

在現今的社會中,電腦網路的發明不僅帶來生活上的方便,對各產業行為模 式上的改變也是不可忽視的,甚至產生新興行業,如E-Commerce,但電腦網路 的世界是數位虛擬的世界,也就是說,在這樣一個虛擬世界中,人與人的溝通不 像現實世界中以面對面的模式出現,然而這也是電腦網路的特性之一,再說,任 何在網路世界裡傳送的資料都可以任意被截取或複製,且在網路規約協定裡,無 法明確地辨識訊息發送者的特性使任何人都可以輕易地偽造訊息欺騙它人,因此 如何在虛擬網路世界中認證彼此的分身已成為現今不可或缺的。一個認證規約是 提供認證機制,當一個認證規約不安全時,它可能被蓄意欺騙它人的組識拿來當 作欺騙工具,因此造成反效果,所以一個認證規約的安全性是非常重要的。

1.2 研究目標

在過去幾年內,很多人花了很多時間設計出很多認證規約,可是大多數在事 後被證實出有弱點存在,改進的版本也是如此,而這些出現在認證規約裡的弱點 通常是因為設計者不知道一個安全認證規約應有的要素為何,因此就有人提出如 何設計一個安全認證規約或一個安全認證規約應有的特性,但是他們所提的方法 通常只對有經驗的人才有幫助;相反地,有人就提出安全認證規約的分析方法,

這些方法大多以邏輯系統的方式呈現,如BAN logic[1]和 Floyd-Hoare style logic [10, 17],利用邏輯分析推導認證規約的安全性,但這樣一個邏輯系統推導過程 需要人的介入,且對一個沒有經驗的人就沒辦法正確地定義所提出認證規約的邏 輯假設,並且在[13]中,Nessett 指出 BAN logic 能力的限制,BAN logic 並不是 適用於每個認證規約,如 Neumann 和 Stubblebine 在[14]中所提出的認證規約就 以BAN logic 證明所提的認證規約是安全的,但它卻有弱點存在,Nessett 也指出 BAN logic 並不是一個認證規約,而是一個 Key distributed authentication protocol 的邏輯系統,所以他就用安全規約來總稱認證規約和提供其它服務的規約 (如金

鑰建立規約),因此我們就用安全規約來總稱任何規約。如果要用程式設計出像 BAN logic 那樣的系統,是不容易的,因為那樣邏輯系統都以抽象為主,並且如 果使用者邏輯假設錯誤,就會使分析錯誤,因此我們的目標是設計出一個可以在 電腦跑的一個安全規約分析系統。

我們知道許許多多的安全規約被發現有弱點存在,然而當我們不考慮那些以 密碼學角度分析時(如Chiphertext only, Known plaintext, Chosen plaintext, Chosen chiphertext and Chosen text attacks),一般攻擊的分類有 Man in the middle attack,

Parallel session attack, Type flaw attack,Duplicate session attack 和 Reflection attack 等等,我們仔細的想想,在這些攻擊的過程中,所有攻擊者傳給所要攻擊 對象的訊息都是符合攻擊對象在一個規約中所期待的一連串訊息,而我們也知道 當要認證一個人時,我們需要他提出一個證據是我們相信只有他所宣稱的人才擁 有的,例如某甲向某乙說:"我是甲",乙就說:"那你可以提出一個我相信只有 甲知道的事或物嗎?",這樣的事或物可能是一種暗號或證件,而在一個安全規 約中就以安全金鑰的擁有性來表示一個人的身分,如私人的加密金鑰,因此認證 一個人就可能用雙方之前就建立的安全金鑰(如暗號),或者是藉由雙方都信任的 第三者(如認證機關),所以一個安全規約通常都在交換訊息中用這樣一個安全金 鑰來加密某些訊息來表示自己為所宣稱的人。在上面所提的攻擊分類中,一個攻 擊者並不知道任何安全金鑰除了自己的安全金鑰以外,如果一個安全規約有弱 點,那表示攻擊者就可能需要用所宣稱那個人的安全金鑰來欺騙攻擊對象,如何 做到呢?其實仔細看看上述每一個攻擊分類的實例,不難發現當需要偽造攻擊者 自己沒辦法產生的加密訊息時,其實都是用之前收到相似的訊息或執行另一次規 約所得到相似的訊息,而這是規約設計者沒有預料到的事(訊息相似度是以接收 者的角度看兩個訊息格式是否一樣),再進一步地想想看,那些攻擊者自己沒辦 法產生的加密訊息其實都是經過規約中的某些步驟得到的,而這些步驟就是說明 在規約中,當經過某些訊息傳送後,就會產生相對應的加密訊息,因此我們可以 歸納出一個特性:攻擊的方式通常利用規約中相似的訊息相互取代或利用他人 (包括攻擊對象本身)產生想要的相似訊息。相似訊息的取代通常是利用比較“容 易”產生的相似訊息取代“不容易”產生的相似訊息(容易或不容易是以攻擊者所 擁有的資訊決定,也就是是否知道加密的金鑰),除此之外,相似訊息也可以藉 由其它runs 中得到的(一個 run 表示執行一次安全規約)。在此我們先定義何為相 似訊息:

兩個訊息是否為相似訊息是必需以接收者的觀點來看,也就是說,根據接 收者目前所擁有的資訊,當這兩個訊息都能符合接收者所預期要收到的訊 息時,兩個訊息為相似訊息。

在定義中,“接收者所預期”是指當接收者在規約中的某一步驟時,他期待收 到一個符合規約中規定的訊息出現,而此訊息可能要有幾個元素或在某一個元素 是必需是接收者之前產生的Nonce 等等。接著我們把剛才所提的特性稱為“相似 訊息攻擊方式”,其定義如下:

如果一個安全規約存在一個弱點,而在此弱點的攻擊方式中所有攻擊者沒 辦法自行產生的加密訊息(使用攻擊者不知道的金鑰加密之加密訊息)都是 從規約訊息交換中的相似訊息取得(可能為之前的相似訊息,或是執行其它 runs 時得到的相似訊息),我們稱這樣的攻擊方式為相似訊息攻擊方式。

所以我們的安全規約分析系統主要是建立一個安全規約中加密訊息的產生 方式,然後分析者可藉由這個系統詢問是否可得到一個想要的加密訊息(如當攻 擊時,攻擊者沒辦法自行產生的加密訊息),如果系統回答 true 的話且發現產生 此加密訊息並不是如規約中所規定的步驟得到,這表示此加密訊息可藉由其它步 驟獲得,因此並不如設計者所預期的,所以就可能有弱點存在,進而分析,就能 推導出攻擊的步驟,在4.1 中,我們會紹介如何找出一個相似訊息攻擊。

1.3 論文架構

在第二章中,我們將介紹從觀察安全規約中所得到的結果,然後推導出我們 的安全規約分析系統,並且介紹系統的架構,接著用一個範例說明,最後討論所 提的系統能力範圍為何。在第三章中,我們說明如何在 Prolog 的環境中實作所 提出的安全規約分析系統,在此之前我們也簡單地介紹Prolog Logic Language。

第四章中,我們用三個安全規約測試所提出的安全規約分析系統,進而分析系統 的能力,最後,我們在第五章做個結論和提出日後的目標。

在文檔中 安全規約分析系統 (頁 8-11)

相關文件