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

 

9-4 Secure-MIME 安全郵件

內容:

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

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

  • 9-4-3 僅簽署郵件

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

所謂S/MIMESecure/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/MIMERFC 2633)只採用 Signed 區段,並另外制定 Application/pkcs7-mime 作為訊息加密與簽署使用,並且可選擇採用何種『內容傳輸編碼』將訊息轉換,一般都採用 Base64 編碼方式,其中 PKCS #7 RSA 加密套件標準(容後說明)。

【(AMultipart/Signed 型態】

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

  • MIME 型態名稱:Multipart

  • MIME 次型態名稱:Signed

  • 參數:boundaryprotocol、與 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 型態是希望將信件包裝成 CMSCryptographic Message SyntaxRFC 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 郵件上傳送;收信者再以反方向拆解信件。

主講人:粘添壽博士

 

資訊與網路安全技術