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

 

第九章  安全性電子郵件

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

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 為例，介紹鑰匙分配及認證的技術。

翻轉工作室：粘添壽

 

資訊與網路安全技術

 

 

翻轉電子書系列：