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

 

9-4 Secure-MIME 安全郵件

內容：

  • 9-4-1 S/MIME 安全郵件型態

  • 9-4-2 僅信封包裝郵件

  • 9-4-3 僅簽署郵件

  • 9-4-4 簽署並加密郵件

所謂S/MIME（Secure/Multipurpose Internet Mail Extension）係指 MIME 郵件再增加安全性的功能，其安全機制是以 RSA 演算法為基礎。由此可見，S/MIME 似乎最能接近目前的郵件系統環境，因此有人大膽預測它極有可能成為未來的標準；另外，S/MIME 認證方式是採用 X.509 v3，亦能結合目前 Internet 上的電子商務環境。也就是說，S/MIME 憑證認證乃是沿用 PKIX 系統。本

只要瞭解 MIME 郵件系統，欲將安全機制嵌入 MIME 其中成為 S/MIME 就不會很困難，但我們還是先來討論 S/MIME 提供那些安全機制。基本上，S/MIME 是由 RSA 公司所發展出來，所以公開鑰匙系統方面大多採用 RSA 演算法，我們依照 S/E-Mail 的安全措施，將 S/MIME 所採用的演算法歸納如下：

  • 訊息摘要：欲產生數位簽章之前，必須將訊息經過某一種雜湊演算法，計算出訊息摘要，再簽署訊息摘要來得到數位簽章。S/MIME 規範中（RFC 2633）有 SHA-1 與 MD5 兩種演算法（第五章介紹），但大多採用產生 160 位元訊息摘要的 SHA-1 演算法。

  • 數位簽章：即是簽署訊息摘要產生數位簽章的演算法。S/MIME 規定傳送端與接收端必須提供 DSS 演算法（第七章介紹），並且傳送端至少必須提供 RSA 加密法，接收端至少應支援 RSA 簽章確認方式。簽署鑰匙的長度可以從 512 位元到 1024 位元。

  • 訊息加密：S/MIME 規範有 RC2/40 與 3DES 加密演算法，但大多採用 3DES 演算法（第三章介紹）。

  • 會議鑰匙加密：即是將會議鑰匙加密後，與密文一併傳送出去的郵件，其中針對會議鑰匙加密的演算法。S/MIME 規定必須採用 Diffie-Hellman 演算法（RFC 2631，即是 ElGamal 演算法）。

瞭解 S/MIME 所採用的安全機制之後，接著來探討如何將這些安全機制嵌入 MIME 郵件之內。

9-4-1 S/MIME 安全郵件型態

S/MIME 係利用 MIME 郵件分段（Multipart）與擴充訊息型態（Application）兩種內文型態（Content Type），將所加密或簽署的訊息嵌入郵件之中，嵌入方法如同 9-3 節所介紹。S/MIME 所定義的內文型態，如表 9-4 所示。

表9-4 S/MIME 所定義的內文型態

內文型態

次型態

S/MIME 參數

說明

Multipart

signed

 

訊息主體分為：訊息與簽章兩部份。

Application

pkcs7-mime

signedData

已簽署的 S/MIME 物件。

pkcs7-mime

envelopedData

已加密的 S/MIME 物件。

pkcs7-mime

degenerate

只包含數位憑證的物件。

pkcs7-signature

signedData

已簽署的 multipart 訊息。

kcs10-mime

signedData

要求登錄憑證訊息。

在 RFC 1847 規範中，定義有 Multipart/Signed 與 Multipart/Encrypted 兩種內文型態，前者為簽署區段、後者為加密區段。但這兩種內文型態所傳輸訊息都必須是為經過轉換的原文，亦即無論加密或簽署後的亂碼，都直接將其放置於郵件區段之內傳送。然而 S/MIME（RFC 2633）只採用 Signed 區段，並另外制定 Application/pkcs7-mime 作為訊息加密與簽署使用，並且可選擇採用何種『內容傳輸編碼』將訊息轉換，一般都採用 Base64 編碼方式，其中 PKCS #7 為 RSA 加密套件標準（容後說明）。

【（A）Multipart/Signed 型態】

如郵件採用 Multipart/Signed 型態則包含兩個區段，第一個區段包含原 MIME 標頭及訊息主體，第二個區段則為數位簽章，並包含下列定義及參數值：

  • MIME 型態名稱：Multipart

  • MIME 次型態名稱：Signed

  • 參數：boundary、protocol、與 micalog

  • 選項參數：無

  • 安全考量：傳輸訊息未經過特殊標碼。

其中 micalog 表示採用何種『訊息完整性檢查』（Message Integrity Check, MIC）的演算法，protocol 表示訊息的表示方式。範例如下：（取自 RFC 1847）

Content-Type: multipart/signed; protocol="TYPE/STYPE";
            micalg="MICALG"; boundary="Signed Boundary"
 
--Signed Boundary
Content-Type: text/plain; charset="us-ascii"
    This is some text to be signed although it could be
    any type of data, labeled accordingly, of course.
 
--Signed Boundary
Content-Type: TYPE/STYPE
    CONTROL INFORMATION for protocol "TYPE/STYPE" would 
 
--Signed Boundary--

【（B） Application/pkcs7-mime 型態】

Application/pcks7-mime 型態是希望將信件包裝成 CMS（Cryptographic Message Syntax，RFC 2630）的標準格式，其中並使用 PKCS #7 公開鑰匙系統之安全套件。它的郵件操作可區分為 Enveloped-data（密文或明文）、Signed-data（數位簽章）、以及 Certs-only（憑證要求）等三種，然而此三種操作可以在同一郵件上混合使用。為了增加發信者與收信者之間處理信件的方便，郵件內可以利用參數說明應採用何種安全套件，為了區分不同的郵件操作，可用不同的參數檔案型態來區分，如表 12-5 所示。

表 12-5 Application/pcks-7-mime 參數與檔案型態

MIME 型態

smime-type

參數檔案型態

Application/pcks7-mime

signedData

.p7m

envelopedData

Application/pcks7-mime

signedData (Certs-only)

.p7c

Application/pcks7-signature

signedData

.p7s

利用參數檔案有許多優點，接收端可將各種參數檔案儲存磁碟機內。當收到信件時，便可以搜尋磁碟機是否有該型態的參數檔案，如果找不到合適的參數檔案，也可以要求發送者傳送該檔案給接收者，接收者再依此來認證或解密郵件。

【（C） PKCS #7 安全套件】

PKCS #7 是 RSA 公司所制定的安全套件（RFC 2315），包含訊息加密與簽署的功能。更重要的是，它將訊息經由安全處理之後，所產生的密文、數位簽章、會議鑰匙加密、或鑰匙訊息等等訊息，重新包裝成另一個特殊的資料結構；之後再將此資料結構填入郵件中傳送。因此，採用 Application/pkcs7-mime 型態時，郵件主體內只有一個區段，並且無法由主體區段觀察出所傳輸的內容，該資料結構又稱為『數位信封』（Digital Envelope）。

我們以 EnvelopedData 型態來觀察，PKCS #7 的郵件處理過程，該型態僅有加密處理（或許沒有），並沒有包含簽署功能。假設發信者發送一封信件給多個接收者，處理步驟如下：

  • 發信者依照加密演算法（如 3DES），選擇一個亂數作為會議鑰匙，並向訊息加密。

  • 利用收信者公開鑰匙，分別向會議鑰匙加密。

  • 分別將加密後的會議鑰匙填入收信者的 RecipientInfo 參數內，其中包含收信者其他資料。

  • 將每一收信者 RecipientInfo 與密文，組合成一個『數位信封』。

  • 再將此『數位信封』嵌入於 Application/pcks7-mime 郵件之內。

至於EnvelopedData 數位信封的資料結構如下：（ANS.1 宣告格式）

EnvelopedData ::= SEQUENCE {
     version Version,
     recipientInfos RecipientInfos,
     encryptedContentInfo EncryptedContentInfo }
 
RecipientInfos ::= SET OF RecipientInfo
EncryptedContentInfo ::= SEQUENCE {
     contentType ContentType,
     contentEncryptionAlgorithm
     ContentEncryptionAlgorithmIdentifier,
     encryptedContent
       [0] IMPLICIT EncryptedContent OPTIONAL }
 

EncryptedContent ::= OCTET STRING

由上述可以觀察出，無論密文、鑰匙訊息、加密演算法都包含在此資料結構內。接著，再將此資料結構以某一種編碼（如 Base64），轉換成可傳輸的數碼。其他數位信封（如 Signed）作者不再贅述，有興趣讀者請參考 RFC 2315。接下來將介紹各種 S/MIME 封裝格式。

9-4-2 僅信封包裝郵件

『僅信封包裝』（Enveloped-only）表示僅將所欲傳輸的訊息包裝成『數位信封』（即是 PCKS #7 格式），所傳輸的訊息可能經過加密處理或沒有，但必須是沒有經過數位簽章處理。S/MIME 郵件格式如下：（取自 RFC 2633，未包含 MIME 標頭）

Content-Type: application/pkcs7-mime; smime-type=enveloped-data;
            name=smime.p7m
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7m
 
       rfvbnj756tbBghyHhHUujhJhjH77n8HHGT9HG4VQpfyF467GhIGfHfYT6
       7n8HHGghyHhHUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H
       f8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
       0GhIGfHfQbnj756YT64V

上述郵件主體是 PKCS #7 資料結構，已經過 Base64 編碼，因此，無法觀察出它的內容。

9-4-3 僅簽署郵件

簽署信件的運作程序如 12-2-3 節介紹。但在 S/MIME 郵件中可以選擇 Multipart 與 Application 兩種信件格式，如下介紹。

【（A）採用 Application 型態】

採用 Application/pcks7-mime 型態是將訊息包裝成『數位信封』，唯一不同的地方是 smime-type 參數指明是簽署資料（signed-data），範例如下：

Content-Type: application/pkcs7-mime; smime-type=signed-data;
            name=smime.p7m
Content-Transfer-Encoding: base64

Content-Disposition: attachment; filename=smime.p7m

567GhIGfHfYT6ghyHhHUujpfyF4f8HHGTrfvhJhjH776tbB9HG4VQbnj7
77n8HHGT9HG4VQpfyF467GhIGfHfYT6rfvbnj756tbBghyHhHUujhJhjH
HUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H7n8HHGghyHh
6YT64V0GhIGfHfQbnj75

【（B）採用 Multipart 型態】

採用 Multipart/signed 型態並沒有重新包裝訊息，因此，信封內包含兩個主體區段，一區段為原訊息資料，另一區段為簽署的數位簽章。另外，簽署區段內的數位簽章是採用 PKCS #7 封裝格式（Application/pcks7-signature）。這種做法是希望訊息部份可以不經處理便可閱讀得到，除非需要認證訊息來源時才處理數位簽章，一般公告公文或廣播訊息都採用這種方式。範例如下：

Content-Type: multipart/signed;
          protocol="application/pkcs7-signature"; micalg=sha1; boundary=boundary42
 
--boundary42
Content-Type: text/plain
 
       This is a clear-signed message.
 
--boundary42
Content-Type: application/pkcs7-signature; name=smime.p7s
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7s
 
       ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6
       4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj
       n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
       7GhIGfHfYT64VQbnj756
--boundary42--

此範例是採用 SHA-1 雜湊演算法與 DSS 數位簽章演算法，其中前區段為訊息明文、後區段為數位簽章。

9-4-4 簽署並加密郵件

兼具簽署與加密郵件的運作程序如 9-2-3 節介紹，郵件包裝是採用巢狀方式，即利用 signed-only 與 encrypted-only 兩種型態交替處理。一般是先計算出雜湊值，並經過簽署後得到一個數位簽章，再包裝成『數位信封』的資料結構（signed-only 處理）。接下來，將此數位信封當作傳輸訊息，再經過加密處理，並包裝成另一個『數位信封』（encrypted-only 處理），完成之後，再嵌入 S/MIME 郵件上傳送；收信者再以反方向拆解信件。

翻轉工作室：粘添壽

 

資訊與網路安全技術

 

 

翻轉電子書系列：