資訊與網路安全技術 第 九章 安全性電子郵件      下一頁

 

第九章  安全性電子郵件

 無論『公文交換』或『伊媚兒』都是安全性電子郵件的範疇,是電子化政府、電子化辦公室不可或缺的工具。

9-1 安全性電子郵件簡介

安全性電子郵件』(Secure Electronic Mail, Secure E-Mail S/E-Mail)無論在電子商務或辦公室自動化環境裡,皆扮演非常重要的角色,從網路上的『伊媚兒』到公文交換,都屬於這個範疇,惟本章較偏重於電子郵件方面的介紹,其相關技術多半也能運用於公文交換上。

只要提到安全性就離不開兩大主題:認證與加密,建構 S/E-Mail 也不例外,但其運作程序與一般應用系統存在很大的差異。一般電子商務(如 Secure Web)多半在建立連線後,再協議出雙方可以接受的安全機制與會議鑰匙,最後就依協議的結果建立安全連線( 線上 On-line。至於安全性電子郵件則不然,它的運作方式比較接近於離線Off-line處理,也就是發信者與收信者不一定同時在線上,甚至收信者多半不知道已有信件到達,更不用說同時在線上協議安全機制與會議鑰匙。為克服此困難,發信者通常先利用鑰匙加密訊息之後,並將加密信息與相關安全機制一併傳送給收信者;待收信者收到信件之後,會先由信件內的訊息了解對方採用何種安全機制,再利用自己擁有的鑰匙解開信件。

為了達到『離線』的安全機制協議,大多需仰賴公開鑰匙系統機制。即是參與通訊者必須擁有公開鑰匙,而且利用數位憑證散佈,如此較容易達成。但許多企業內的公文交換系統,也有可能採用 Kerberos 系統認證身分與分配鑰匙。無論採用何種機制,皆有下列問題有待考慮並解決:

  • 加密/認證演算法問題:各種加密或認證演算法都有其專屬鑰匙,不同演算法之間的鑰匙也無法交替使用。譬如,一把使用於 3DES 演算法的鑰匙,就不能使用於 RSA 或其他演算法。縱然發信者告知對方採用何種演算法加密或認證,對方若無該演算法的鑰匙,亦無法解開訊息。因此,S/E-Mail 系統有其必要制定標準的加密或認證演算法,亦即任一套 S/E-mail 系統皆需指定使用何種加密演算法(如 3DES)或數位簽章演算法(如 DSS)。

  • 鑰匙分配問題:倘若收信人擁有多把鑰匙,每一把鑰匙也針對不同的通訊對象,發信者又如何通知收信者應該使用那一把鑰匙來解密。因此,所有採用 S/E-Mail 系統者,都必須維護一個『鑰匙鏈』的資料庫,其中記錄每一個通訊對象的鑰匙配對。

  • 鑰匙認證問題:如何確認對方的鑰匙是正確的。一般對於公開鑰匙認證問題都是歸類數位憑證的問題,這方面除了 X.509 憑證之外,PGP 憑證也已廣泛被使用於 S/E-Mail 系統上。

  • 訊息亂碼問題:加密後的訊息必定產生雜亂無章的亂碼。任何一封郵件多半經由許多郵件伺服器(如 SMTP 伺服器)的轉送,才會到達目的地。另外,Internet 網路上各種伺服器大多採用 NVT ASCII 碼作為控制字元(請參考 [3] 第十二章說明),所以郵件必須避開這些控制字元。然而加密後的亂碼極有可能和這些字元相衝突,因此,加密後的訊息不可以直接傳送,需經特殊處理始可;目前 S/E-Mail 大多將密文經過 Base-64 編碼後,再附加於信件上傳送。

  • 郵件格式:一般郵件除了訊息內容之外,通常還包含一些控制訊息,如認證訊息、加密後密文等等。這些都必須制定標準格式,收信者才可以明瞭信件內的含意;目前 S/E-Mail S/MIME OpenPGP 兩大系統,他們分別制定自己的標準郵件格式。

上述的問題分別有其解決方案,本章首先介紹 S/E-Mail 的安全性功能,與其相關技術,接著再介紹 S/E-Mail 的標準格式,最後以 PGP 為例,介紹鑰匙分配及認證的技術。

主講人:粘添壽博士

 

資訊與網路安全技術