• 發行項

安全性

使用數位憑證保護電子郵件的安全

Matt Clapham and Blake Hutchinson

 

簡介:

  • 建立可驗證的身分識別
  • 更新憑證狀態
  • 取得和交換憑證
  • 疑難排解 S/MIME 系統

千年來，人們採用各種不同的方法來隱藏傳輸的資訊、驗證寄件者，以及驗證訊息。隨著文明的演變，開發出了兼顧這三項任務的方法，而且這套方法已逐漸受到廣泛採納。「安全多用途網際網路郵件延伸」

(S/MIME) 是一套使用加密和數位簽章安全地傳送電子郵件的系統。

目前的加密 (隱藏) 技術分成兩大類：對稱 (秘密) 金鑰演算法，諸如資料加密標準 (DES) 或進階加密標準 (AES)，以及非對稱 (公開/私密) 金鑰演算法，例如 RSA 或 Elliptical Curve Cryptography (ECC)。現代的寄件者驗證工具是單向的算術函數，稱做雜湊，它會產生獨特的簽章。訊息摘要演算法 5 (MD5) 和安全雜湊演算法 (SHA) 是兩大常用的雜湊方法。電腦可以使用這些演算法來產生與個別來源文字 (相同的來源文字會雜湊成相同的值) 相對應的唯一雜湊或數字。為了建置公開金鑰基礎結構 (PKI) 系統，運用和結合了這些簡單的工具。

可驗證的身分識別

憑證授權單位資源

PKI 系統裡面的身分識別是使用數位憑證進行管哩，這跟大多數人在國際間攜帶的政府身分識別 — 護照 — 並沒有什麼兩樣。數位憑證世界的護照標準是 X.509 格式，這種格式廣泛用於各種簽署和加密技術，例如 S/MIME、網際網路通訊協定安全性 (IPsec)、安全殼層 (SSH)、無線網路安全性、虛擬私人網路 (VPN)，甚至安全伺服器通訊 (例如 SSL 網站) 也包括在內。

憑證是以非對稱加密和雜湊為基礎建置而成。若要建立憑證，要求者 (需要某些較高授權單位簽署金鑰的實體) 會產生一個私密金鑰。該金鑰會被鎖定起來，以確保它的真實性永遠不會受到質疑。隨同私密金鑰，另外還會產生一個相對應的公開金鑰。顧名思義，金鑰組的公開部分並不是秘密，而且會公開發佈，但在某些程度上還是會確保它的真實性。

這個金鑰組可進行兩項基本的作業。首先，任何人都可以使用公開金鑰來加密只有私密金鑰可以解密的內容，其次，公開金鑰可用來解密以私密金鑰加密的內容。這對於驗證只有私密金鑰才可能建立的簽章是很重要的。

對憑證授權單位提出的要求包括各種詳細資料，例如適用金鑰的人員或電腦的身分識別、演算法類型和強度，以及金鑰組的公開部分。憑證授權單位 (CA) 會使用雜湊演算法接收及驗證要求當中的資訊，並且建立與該項資訊相對應的唯一識別碼。

CA 會使用它的私密金鑰加密資訊的雜湊，並把它組合成標準格式 (例如 X.509)，然後建立與原始要求相對應的憑證。X.509 憑證將包含一份宣告清單，包括憑證 (主體) 的身分識別、有效期限、公開金鑰，以及可使用憑證進行的作業等。憑證接下來會傳回給要求者，它事實上是個權杖，表明：「我，CA，擔保這個公開金鑰，以及與它相對應的私密部分，作為此處所述的全部用途」。

對於根 CA (位於信任鏈結的最高層級)，憑證會自我簽署。大部分可接受的根 CA 都會預先安裝在基本作業系統或應用程式中，但可透過套件或企業設定加以更新或更改。在根 CA 和分葉節點 (通常是指個人或系統) 之間，可以有一或多個中繼 CA。

鏈結包括所有節點及當中內嵌的所有前置憑證，由 CA 在該層級簽署。嘗試驗證憑證的協力廠商可以檢查本機計算的雜湊，並與針對使用該特定 CA 或個體的對應公開金鑰來解密的雜湊進行比較。就是這樣 — 從分葉到根的完整驗證鏈結 — 當然前提是根是受到信任的。

更新憑證狀態

每個良好的 CA 都有管道可以發佈一份不該再信任的憑證清單。這份憑證撤銷清單 (CRL) 會說明哪些發行項目已特別被 CA 取消。為了方便起見，CRL 的位置通常是 CA 憑證的屬性。

CA 會根據兩種情況定期發行 CRL：排程 (也許是每兩個禮拜) 或事件 (某些情況指出發行的憑證不應該再受到信任)。CA 會在發佈 CRL 時簽署它發行的 CRL。當接收系統評估鏈結的有效性時，它通常會嘗試取得鏈結中每個發行 CA 的 CRL (藉由憑證本身內嵌的詳細資料，或是透過一些預先定義的可信任發佈機制)。如果沒有任何 CRL 可用，用戶端可能會改用最近成功快取的複本，只要此複本不超過指定的 CRL 更新期間就行了。若連這樣都辦不到的話，用戶端系統通常會顯示某種錯誤，指明憑證看似有效但無法確認撤銷狀態。

許多應用程式若是無法驗證鏈結或鏈結中每個節點的 CRL，就會花上比較長的時間載入憑證。視憑證所保護的內容而定，使用者不一定要信任它。每個 CA 一定要有定期更新、廣泛可用的 CRL 發佈點，尤其是對那些公開根的 CA 來說更是如此。

根 CA 是憑證鏈結的基礎，而鏈結則是所有憑證階層的基石。大部分用戶端系統或應用程式只會在分葉節點鏈結回信任的根 CA 時，才會將分葉節點憑證視為有效。這可以是企業 CA，由特定公司所擁有或經營的 CA，或是公開根 CA (例如 VeriSign)。

對於公開根 CA，為了確保完整性，必須具備豐富的操作專業知識。企業對於內部營運也當努力達成相同的等級，因為根 CA 的安全性在此環境下也一樣重要。根 CA 實際上應該保持離線，而且僅作為發行憑證和更新 CRL 之用，以獲得最佳的保護。如需有關 CA 操作最佳作法的詳細資訊，請參閱「憑證授權單位資源」資訊看板中所列的文章。

金鑰修復是需要考量的重要層面之一。為了使調查作業更具效率，並確保資料不會被使用者鎖定而無法復原，企業應該將所有使用者發行的金鑰備份起來。而且這些備份複本應該存放在安全的儲存機制中。如此一來，若是使用者的金鑰不見了，譬如說智慧卡被遺留在計程車裡面，還是有辦法存取金鑰所保護的任何內容。

最後，每個良好的密碼編譯系統都包含生命週期管理的概念。隨著電腦的速度越來越快，演算法也變得越來越薄弱。每個良好的加密系統都必須能夠自行更新，並隨著時間轉換到新演算法和金鑰大小。在識別出密碼編譯弱點，以及分階段加入或去除特定功能時，應該適當地更新 CA。

實作 S/MIME

使用 S/MIME 啟動載入、撰寫、傳送和接收已簽署或已加密電子郵件分成好幾個階段。我們會在介紹典型的 S/MIME 案例時，涵蓋相關細節、問題和可能的解決方案，此案例是：兩名使用者從兩個不同的 Active Directory® 樹系和不同的憑證授權單位鏈結 (也就是從個別的操作實體，無論是否位於相同的公司)，使用 Microsoft® Office Outlook® 2007 傳送已簽署和/或已加密的電子郵件給彼此。

我們將假設必要的基礎結構已經就定位，以著手我們即將說明的作業。在我們的案例中，使用的是整合 Active Directory 的企業憑證伺服器。

取得憑證

第一項工作是取得適當的憑證。要這麼做，您開啟 [憑證管理員] MMC (certmgr.msc)，在 [Personal] 資料夾上按一下滑鼠右鍵，在快顯清單上選取 [所有工作]，然後從清單中選取 [要求新憑證]。

這將啟動「憑證註冊」精靈，如 [圖 1] 所示。根據預設，將顯示幾個以企業為中心的選項，但重要的是 [使用者憑證]。稍後會用它來啟用簽署和加密程序。憑證必須能夠用於：

[圖 1] 要求憑證

[圖 1]** 要求憑證 **(按一下影像可放大檢視)

  • 數位簽章 (使用建立者的驗證封印建立訊息)
  • 金鑰加密 (針對加密檔案系統等技術，使用一個金鑰保護另一個金鑰)
  • 保全郵件 (只能由握有相對應私密金鑰之指定收件者讀取的加密訊息)

傳送 S/MIME 簽署的電子郵件時並不需要金鑰加密屬性。不過在傳送或接收加密郵件時，就需要這個屬性，但不需要簽章屬性。在預設的情況下，Windows® 憑證服務內的範本會啟用這三個屬性。如果不准使用者要求新憑證，則精靈啟動時三個屬性都不會顯示。如果沒有任何企業 CA 可用，會向使用者顯示「註冊錯誤」，指明無法連絡網域或 CA。針對這個逐步說明，我們將假設單一憑證同時允許簽章和加密。

交換憑證

讓兩名使用者開始傳送加密的電子郵件最簡單的方法，就是直接傳送已簽署的郵件給彼此。撰寫好郵件之後，使用者可按一下 [簽章] 按鈕 (這個按鈕在 Outlook 中有時候預設會隱藏起來，除非至少用過一次。依序一下新訊息的 [選項] 設定、[安全性設定] 按鈕，然後在 [安全性內容] 對話方塊上勾選 [新增數位簽章至此郵件] 方塊，就可以找到這個按鈕)。簽章按鈕 (黃色的小信封上有條紅色的緞帶，註明 [簽章]) 會在郵件中加入數位簽章，以建立它的來源真實性。

在按下 [傳送] 按鈕之後，可能會提示使用者提供另外持有的金鑰權杖，例如插入智慧卡或輸入 PIN。這會視組織內所安排的特定金鑰保護方法而定。

收到 S/MIME 簽署郵件的使用者必須檢視並以滑鼠右鍵按一下寄件者的名稱 (在 [寄件者:] 之後)，接著從內容功能表選取 [新增至 Outlook 連絡人]，這會新增新的連絡人項目或更新現有的項目。憑證隨後會與該特定的連絡人項目建立關聯。請注意，在常見的 Active Directory 環境內 (兩名使用者位於相同的樹系或公司裡)，公開使用者憑證發佈是透過使用者的 Active Directory 物件內的屬性自動完成的。

交換憑證的另外一種方法，就是讓每名使用者以附件的形式傳送他們的 S/MIME 憑證。若要這麼做，雙方都必須將他們的憑證匯出成 CER 檔案。使用者必須檢視憑證，並遵循我們即將討論到的匯出程序，小心不要一併匯出私密金鑰，如 [圖 2] 所示。

[圖 2] 交換憑證時， 不要匯出私密金鑰

[圖 2]** 交換憑證時， 不要匯出私密金鑰 **(按一下影像可放大檢視)

每名收件者接下來會在 Outlook 中手動建立連絡人項目，然後將憑證加入寄件者的項目中。兩名使用者一交換好憑證，就能夠彼此交換加密的電子郵件了。

疑難排解

有時候收件者會無法開啟加密的訊息。我們在這個領域當中看過的三個最可能的問題肇因，分別是根 CA 不受信任、中繼 CA 無法驗證，以及 CRL 無法使用。

不信任的根 CA 通常會在 Outlook 中顯示成與簽章相關聯的錯誤訊息：「簽章發生錯誤。請按一下簽章按鈕，以取得詳細資訊」。若要解決問題，請從 Outlook 內開啟憑證，再按一下快顯對話方塊中的 [檢視憑證授權] 按鈕。在 [憑證內容] 對話方塊的 [一般] 索引標籤上，檢查一下訊息。如果訊息指出 CA 根憑證不受信任，而且需要安裝，請前往 [詳細資料] 索引標籤。按一下 [複製到檔案...] 按鈕，並遵循精靈，接受所有預設值，然後在收到提示時提供檔案名稱和資料夾。

現在以電腦的系統管理員身分開啟一個全新的 Microsoft Management Console (MMC)。前往 [檔案]|[新增/移除嵌入式管理單元] (Ctrl+M)，選取 [憑證]，並為電腦帳戶新增它，在收到提示時選取 [本機電腦]。接下來，在左邊的樹狀目錄中展開 [憑證] 節點，然後對信任的根憑證授權單位進行相同的動作。在快顯功能表上以滑鼠右鍵按一下並選取 [所有工作]|[匯入]。將前述匯出的憑證檔案匯入到信任的根憑證授權單位，再按一下 [完成]。然後讓受影響的使用者重新啟動 Outlook。

這些指示應該只能用於新增您知道可以信任的根 CA。並非所有根 CA 都生而平等。請先審慎考量是誰擁有和操作根 CA，再使用這套方法新增根 CA 到整個系統的存放區。如果您的企業是透過群組原則控制信任的根 CA 清單，那麼設定值將往下推送到用戶端系統。在這種情況下，上述的指示可能就不管用。如果真的不能用，您可能需要另尋他法，例如保全網站或伺服器以交換資料，因為使用電子郵件的體驗既不會順暢也不會受到保護。

上面提出的第二個問題，無法驗證中繼 CA，通常是發生在兩種情況下：嘗試驗證憑證的用戶端無法取得憑證中所定義的授權資訊存取 (AIA) 位置，或是用戶端所擁有的中繼 CA 憑證版本與 CA 所發行的版本不符 (用戶端通常是晚一兩個版本)。這些狀況在 Outlook 使用者介面中看起來十分類似。我們只在非常特定的情形下看過，就是當鏈結中的中層 CA 已過期，並在它發行的其他下層憑證到期之前重新發行的時候。

基本上，這個問題是發生在鏈結裡面有差距的時候。有些父憑證可能缺乏完善的詳細資料，或是沒有適當內嵌在分葉節點內，進而使整個情況更加複雜。

若要解決這個問題，寄件者必須開啟新郵件，並依序按一下新郵件的 [選項]、[安全性設定] 按鈕，以及 [變更設定] 按鈕。現在按一下 [選取] 按鈕選擇簽署憑證，然後在快顯對話方塊上按一下 [檢視憑證] 按鈕。前往 [憑證路徑] 索引標籤，選取分葉節點的發行者 (也就是在鏈結中往上一層)，再按一下 [檢視憑證] 按鈕。依序按一下 [詳細資料] 索引標籤、[複製到檔案...] 按鈕，然後完成匯出精靈，選擇 PKCS #7 (.P7B)。確定已勾選 [包含憑證路徑中的所有憑證] 選項，如 [圖 3] 所示。最後，傳送匯出的鏈結檔案給所需的收件者。

[圖 3] 修補憑證鏈結中的差距

[圖 3]** 修補憑證鏈結中的差距 **(按一下影像可放大檢視)

取得匯出的憑證鏈結後，收件者必須開啟和匯入憑證鏈結，做法跟我們之前匯入根憑證雷同。其中一項差異是選取的存放資料夾應該是 [中繼憑證授權]。如果郵件開啟，而且憑證在 Outlook 中顯示為有效，那麼一切會正常運作。

至於第三個問題，無法使用 CRL，修正的方法非常簡單。Outlook 的起初回應看起來跟前一個問題非常像。不過，即使根 CA 或中繼簽章 CA 受到信任，還是會顯示錯誤。對於分葉以上的每個憑證鏈層級，請依序開啟憑證的內容、[詳細資料] 索引標籤，再查看稱為 [CRL 發佈點] 的欄位。

對於列出的每個 CRL 發佈點 (尤其是網際網路可以存取的發佈點)，確認 CRL 檔案 URL 可以開啟。隨著每個層級進行驗證時，往鏈結的上一層移動。如果有任何無法取得的 CRL，可能就是問題的根源。若要解決問題，您應該確認區域網路原則並未封鎖您的存取。否則的話，請試著連絡擁有 CA 的公司，或等待 CA 的 CRL 發佈點恢復可運作狀態。

發佈憑證

發佈作業很簡單。基本上，已簽署的郵件是傳輸到郵件伺服器，這部伺服器接著會透過查驗的方法，即 SMTP，將郵件從一個位置傳送到另外一個位置。我們發現傳輸中的已簽署或已加密郵件有一個問題，就是有些郵件系統會拒絕或中斷通過它們的已簽署或已加密郵件。修正方法是與系統的 IT 管理員合作來允許郵件類型。當然，您可能還是必須忍受有些郵件類型就是會被封鎖。接收方可能有正當的理由不在特定的操作環境下允許加密的郵件。

加密回覆

若要建立加密的回覆 (假設上述的啟動載入程序已完成)，寄件者只需要建立郵件，然後在郵件撰寫視窗中按一下 [加密] 按鈕 (黃色小信封上有個藍色鎖，註明 [加密]) 就行了。如果 [加密] 按鈕無法使用，請遵循傳送已簽署郵件的步驟，不過在最後一個步驟中，請改勾選 [加密郵件內容與附件] 核取方塊。

傳送加密郵件給收件者並不需要 S/MIME 簽署，但是搭配使用兩者也無妨，因為簽署可讓讀者驗證寄件者 (加密功能並不會表明寄件者)。加密程序將嘗試使用所有收件者已知的公開金鑰來加密郵件。如果系統找不到某些指定收件者的憑證，會在快顯對話方塊中將它們標示出來，建議不加密來傳送郵件，如 [圖 4] 所示。

[圖 4] 如果您 使用憑證遇到問題，可決定傳送未加密的郵件

[圖 4]** 如果您 使用憑證遇到問題，可決定傳送未加密的郵件 **(按一下影像可放大檢視)

根據預設，簽署和加密作業應該與其他同等設定的用戶端系統搭配運作，但是如果雜湊或加密演算法不支援下層的話，有時候跨版本加密或簽署的郵件可能會產生問題。我們在將簽署的電子郵件 (使用 SHA-512 的雜湊演算法) 傳送給執行 Windows XP SP2 的使用者時，就碰過這樣的問題。因為接收系統並不支援雜湊，所以使用者無法驗證簽章或是讀取郵件。然而，除非 Outlook 預設值有所變更，否則使用者不太可能在這個階段遇到太多問題。

收到郵件後，假如與公開憑證相關聯的私密金鑰可以使用的話，指定的收件者應該就能夠開啟郵件。再次強調，使用者可能必須提供額外的權杖以證明持有私密金鑰，這要看私密金鑰的部署方式而定。其他已完成類似啟動載入程序的使用者可與寄件者進行類似的簽署和加密通訊。如果使用者在某些情況下 (也許是因為電腦遺失) 變更了他的私密金鑰，他必須要重新要求憑證，然後重新發佈已簽署的郵件或憑證檔案給其他想要交換加密郵件的人。

結論

讓兩種不同目錄或組織內的兩名使用者之間能夠進行簽署和加密的 S/MIME，所牽涉的通常不比我們剛剛討論的情況複雜到哪裡去。簽署在運用得當的時候非常實用，因為它可提高郵件的真實性。對於機密的詳細資料，加密郵件為傳輸中的資料提供另一層保密性。兩者結合可達成來源的真實性和資料的秘密性。而透過我們在本文所說明的程序，大多數的使用者應該都能順利運用這些功能。

Matt Clapham是 CISSP，並在 Microsoft IT 擔任安全性工程師。他白天對 LOB 應用程式進行安全性評量，晚上則涉獵技術、遊戲、電腦音樂，或是安全性。他偶爾會在 Puget Sound IT 安全性社群發表演說。您可以透過電子郵件與他連絡：matt.clapham@microsoft.com。

Blake Hutchinson 在 Microsoft 的商務線上服務小組 (Business Online Services Group，BOSG) 擔任支援分析師。他的職責包括為 BOSG 的企業客戶內部建立的 LOB 工具，提供作業支援和專案評量。Blake 享受攝影、滑雪和電腦遊戲。您可以透過電子郵件與他連絡：blakeh@microsoft.com。

© 2008 Microsoft Corporation 和 CMP Media, LLC.保留所有權利；未經允許，嚴禁部分或全部複製.