翻轉電子書系列:資訊與網路安全概論  

翻轉工作室:粘添壽

第九章  安全性電子郵件

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

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

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

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

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

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

9-2 Secure E-mail 安全性郵件

9-2-1 Secure E-mail 郵件結構

在網路通訊上,S/E-Mail 最能表現出資訊安全技術的特性,因為一般電子郵件就安全性的考量包含有:

由上述可以看出,S/E-Mail 幾乎包含所有資訊安全的基本技術。其實建構安全性郵件並非想像中那麼很複雜,其基本概念是將處理後的訊息與安全機制資料一併植入於郵件內,植入的方法如圖 9-1 所示。圖 9-1 為一般安全郵件的典型格式,它將郵件劃分若干個區段,每個區段承載著各種安全訊息,且每一區段都有一個區段『標頭』,記載著該區段內所攜帶訊息的特性,稱為『內文型態』(Content Type)。至於將郵件分割為若干個區段是 MIME 郵件的主要功能,因此,安全郵件多半都建立在 MIME 郵件上。接下來,我們就依照圖 9-1 的模式,來討論建構 S/E-Mail 安全性功能的方法,之後再來探討如何將這些安全功能嵌入於 MIME 郵件上。

9-1 安全性郵件之典型格式

9-2-2 Secure E-mal 安全性功能

(1) 隱密性功能

一封被發送的郵件,通常經過多個 SMTP 伺服器轉送才能到達收信人的郵件伺服器內,且需經由收信人下載或開啟信件後,才算真正完成郵件的傳送。在傳送過程當中,郵件每經過一個轉送器,多半以『儲存後再前送』(Store-and-Forward的方式處理,因此,有心人士欲窺視郵件內容並不困難;甚至,郵件到達收件人的郵件伺服器之後,在收件者還未開啟或下載之前,也很容易被他人盜取或窺視,有此可見,隱密性功能對安全郵件而言是很重要的。簡單的方法是訊息經過加密後再傳輸,收件者再利用鑰匙解密,只要能解決鑰匙分配的問題,即能達到隱密性功能;但鑰匙分配方法牽涉到加密系統的機制,基本上,S/E-Mail 有公開鑰匙與秘密鑰匙兩種加密方法,如下所述。

【(A)公開鑰匙加密】

如果收信者有公開鑰匙配對的話,則發信者可利用收信者的公開鑰匙對郵件加密,收信者再利用自己的私有鑰匙解密,如此便能達到隱密性的功能。譬如,Bob 傳送一封信件給 Alice,假設 Alice 的公開鑰匙配對是 {KUa, KRa},其中前者為公開鑰匙、後者為私有鑰匙,則 Bob 的運作程序如下:

傳送訊息:M

加密系統:E(如 3DES

訊息加密:EKUa [M]

最後Bob 所建構的郵件內容為:

信件標頭

內文型態:encrypted; public-key

EKUa [M]

收件者由『內文型態』欄位中了解所傳送的訊息是經過公開鑰匙加密,因此,只要使用自己的私有鑰匙就可以解開該加密訊息。

【(B)會議鑰匙加密】

因為公開鑰匙加密的傳輸效益遠比秘密鑰匙來得低,尤其對大量傳輸訊息更為明顯。就整體而言,並不鼓勵常常使用公開鑰匙配對處理訊息加密,過度增加鑰匙的曝光率,易導致遭破解的危機。最好還是利用會議鑰匙加密較妥當,只要發信者選擇一個亂數作為加密鑰匙,先對訊息加密後,再利用對方的公開鑰匙對會議鑰匙加密,一併傳送給對方。譬如,Bob 傳送一封信件給 Alice{KUa, KRa}),其運作程序如下:

傳送訊息:M

會議鑰匙:K(發信者選取亂數)

加密系統:E(如 3DES 演算法)

訊息加密:EK [M]

會議鑰匙加密:EKUa [K]

則信件的內容為:

信件標頭

內文型態:encrypted; session key

Key-infoEKUa [K]

EK [M]

對方收到信件後,首先利用自己的私有鑰匙解開會議鑰匙的加密,再利用會議鑰匙解開訊息的加密,如此一來,除了可以達成隱密性功能,又可降低公開鑰匙系統低效率的加/解密處理。

【(C)主密鑰加密】

一般辦公室自動化系統裡,大多利用 Kerberos 系統來發給傳送者通往對方的『通行票』,發信者便可以利用通行票內的主密鑰向訊息加密,收信者亦同樣由通行票中取出主密鑰來解密,這是一般公文交換的基本運作模式。另外,其他安全性公文交換也大多採用此模式,以下的介紹不再另述。

(2) 完整性功能

完整性功能是要檢視資料是否遭受竄改,看起來似乎沒有其他安全功能重要,但許多地方仍會使用到它。譬如,利用網路公佈訊息或公告公文,基本上這些訊息無需隱密,並且希望所有人都能觀看其訊息內容。如不幸遭攻擊者竄改公佈的訊息,其傷害不容忽視,因此,公佈訊息者必須將該訊息作完整性的處理,任何人都可以在不受任何限制之下,隨意檢視該訊息的完整性。最簡單的做法只要將訊息經過雜湊函數計算出一個雜湊值,再將訊息與雜湊值一併放置在信件內傳送,通常郵件系統都會指定使用一種雜湊函數(如 SHA-1 演算法)。譬如,Bob 發送一封具有完整性功能的信件給 Alice,其運作程序如下:

傳送訊息:M

雜湊函數:H(如 SHA-1 演算法)

雜湊值:H [M]

則信件的內容為:

信件標頭

內文型態:text

M(明文訊息)

內文型態:MICsha-1

H [M]

其中MICMessage Integrity Code表示該內文所儲存的訊息完整碼。

(3) 確認性功能

確認性是確定信件並非他人偽造與訊息內容未遭受竄改;簡單的說,即是發信者向該郵件簽署保證該信件是自己所發送的,並保證信件內容是自己所寫的。確認性功能大多採用數位簽章技術來達成,它的做法是首先發信者將訊息經過雜湊演算法,計算出一個雜湊值,再利用發信者的私有鑰匙向該雜湊值簽署得到一個簽署碼,之後簽署碼連同訊息一併傳送給收信者,收信者收到信件之後,利用對方的公開鑰匙向簽署碼解密,得到發信者的雜湊值,再使用同樣湊演算法計算所收到的訊息,得到另一個雜湊值;如果兩個雜湊值相同的話,則能確定信件內容與發信者身份無誤;否則不是訊息有誤,就是該信件是他人偽造的。一般確認性含兩個層次:僅確認性功能與確認性功能附加隱密性功能,以下說明之。

【(A)僅確認性功能】

僅確認性功能是以明文方式傳送訊息,但有附加簽署碼。假設 Bob{KUb, KRb})傳送一封自己所簽署的信件給 Alice,其中 KUb Bob 的公開鑰匙、KRb 為私有鑰匙。運作程序如下:

傳送訊息:M

雜湊函數:H

雜湊值:H[M]

簽章函數:SIG(如 DSS 演算法)

簽章碼:SIGKRb [H[M]];利用 Bob 私有鑰匙簽署雜湊值。

則信件的內容為:

信件標頭

內文型態:text

M(明文訊息)

內文型態:signed

SIGKRb [H[M]]

【(B)確認性附加隱密性功能】

兼具確認性與隱密性功能的郵件有兩種做法,一者為訊息加密後從事簽署處理;另一者為訊息簽署後,簽署碼再連同訊息一併加密的處理。目前一般安全性郵件較傾向於後者的做法。假設 Bob{KUb, KRb})傳送一封自己所簽署並加密的信件給 Alice{KUa, KRa}),運作程序如下:

傳送訊息:M

雜湊函數:H(如 SHA-1 演算法)

雜湊值:H[M](訊息經過雜湊函數計算所得)

簽章函數:SIG(如 DSS 演算法)

簽章碼:SIGKRb [H[M]](利用 Bob 私有鑰匙簽署雜湊值)

加密系統:E(如 3DES 演算法)

會議鑰匙:KBob 選取亂數而成)

密文:EK [M || SIGKRb [H[M]]](利用會議鑰匙向訊息及簽章碼加密)

會議鑰匙加密:EKUa [K](利用 Alice 公開鑰匙向會議鑰匙加密)

則信件的內容為:

信件標頭

內文型態:encryped; session key

Key-infoEKUa [K]

EK [M || SIGKRb [H[M]]](密文)

Alice 收到信件之後,首先利用私有鑰匙(KRa)解開會議鑰匙的加密,再利用會議鑰匙向密文解密,便可得到訊息的明文與簽章值,最後再利用 Bob 的公開鑰匙(KRb)解開簽章值,並得到原訊息的雜湊碼。Alice 以同樣的雜湊演算法計算所收到的訊息,亦得到另一個雜湊碼,如果兩個雜湊碼相同的話,則表示訊息內容與發信者(Bob)身份都是正確的;否則可能訊息已遭受竄改,或是該信件是冒名發送的。

(4) 不可否認性功能

如果某一信件經由發送者以它的私有鑰匙簽署的話,則此信件除了具有確認性功能之外,還具有不可否認性功能。收信者可以持有原來信件(經過簽署過的)向公正單位(如法院),提出發信者發出此信件的證明。

9-3 MIME 郵件標準

之前我們介紹所謂安全郵件,即是將安全措施嵌入於分段郵件上,而此分段機制就是 MIMEMultipurpose Internet Mail Extension)的主要特性。早期制定 MIME 目的是欲將多媒體功能植入於死板的文字郵件裡(RFC 822),它的做法是分別將聲音、影像、視訊植入於各個區段郵件裡,每一區段由一個區段標頭描述所承載的訊息型態(聲音或影像),再由另一個實體(Body)承載該訊息。欲瞭解 MIME 郵件格式還是必須先由 RFC 822 郵件開始,以下分別介紹之。

9-3-1 RFC 822 封裝格式

1982 年制定 RFC 822 標準時,網路上信件內容非常單純,大多僅傳送文字而已。因此,RFC 822 所制定的文件格式非常簡單,只包含『標頭』(Header『主體』(Body兩部份,兩者之間是利用一列空白列來區隔。訊息內容是由 ASCII 文字所構成,第一行空白列之前的文字列都被當成標頭列,當郵件被轉送時,就是利用這些標頭列所標示的內容被轉送,標頭列也是採用 ASCII 文字表示。

一封信件的標頭可能包含多個『標頭列』(Header Column,每一標頭列代表文件的控制訊息。至於一個標頭列則是由一個關鍵字、一個冒號,以及所攜帶參數所構成,較常用的關鍵字為 From(發信者地址)To(收信者地址)Subject(信件主旨)Cc(副本收信者)以及 Data(發信日期時間) 等等。另外,信件主體(Boby可利用 SACII 表示任何文字,並以 <LF> <CR> 表示主體的結束。以下為簡單 RFC 822 的信件範例:

From: 志明 <bob@cc.cma.edu.tw>

To:春嬌 <alice@pchome.com.tw>

Subject: See you tomorrow

Date: Fri. 26 Dec 2003 10:12:37 – 0400

 

    Please come to meet me at tomorrow.

<LF>&<CR>

9-3-2 MIME 延伸功能

直到 1993 年,僅文字傳輸的郵件系統,已不能滿足環境需求,『多目的網際郵件擴充』(MIME)郵件格式因而誕生。吾人所期望的郵件豈是文字模式所能滿足,沒有聲音與影像根本不符時代潮流。基本上,MIME RFC 822 版本的延伸其延伸功能如下:

接下來,我們來介紹 MIME 所增加的功能。

9-3-3 MIME 標頭列

MIME 所定義的 5 個標頭列,說明如下:

基本上,後面兩個標頭列(Content-ID Content-Description)甚少使用,只要的重點在 Content-Type 標頭內如何增加其他訊息的傳輸。

9-3-4 MIME 內文型態

MIME 郵件如何達到『多用途』(Multipurpose,這完全視『內文型態』(Content Type的變化。其實它的道理非常簡單,發信者只要利用 Content-Type 表示目前訊息是何種格式(如 Jepg 圖片);收信者由 Content-Type 知道所接收訊息是何種格式,再利用該格式來觀閱訊息(如 Jpeg 顯示器)即可。也就是說,Content-Type 是用來通知雙方採用何種格式來存放訊息的意思。表 12-2 MIME 所制定的 Content-Type,每一種 Content-Type 又包含若干個次型態(Subtype),說明如下:(RFC 10

9-2 MIME 內文型態

型態

次型態

功能說明

Text

Plain

不具格式的文字,如 ASC II

Enrich

較有彈性的文字格式。

Multipart

Mixed

區段之間為獨立的,但需依照次序。

Parallel

區段之間為獨立的,不需依照次序。

Alternative

各區段皆表示同一訊息,但格式不同。

Digest

Mixed 相同,但採用 rfc822 格式。

Message

rfc822

訊息經由 rfc822 格式包裝。

Partial

訊息是經過切割包裝而成。

External-body

訊息內容再另一個指定位置。

Image

Jpeg

訊息為 JPEG 影像格式。

Gif

訊息為 GIF 影像格式。

Video

Mpeg

訊息為 MPEG 視訊格式。

Audio

Basic

訊息為 Basic 聲音格式。

Application

PostScript

訊息為 PostScript 格式。

Octet-stream

訊息為 8 位元二進位格式。

From: Nathaniel Borenstein 
To: Ned Freed 
Date: Sun, 21 Mar 1993 23:56:48 -0800 (PST)
Subject: Sample message
MIME-Version: 1.0
Content-type: multipart/mixed; boundary="simple boundary"
 
     This is the preamble.  It is to be ignored, though it
     is a handy place for composition agents to include an
     explanatory note to non-MIME conformant readers.
 
--simple boundary
 
     This is implicitly typed plain US-ASCII text.
     It does NOT end with a linebreak.
--simple boundary
Content-type: text/plain; charset=us-ascii
 
     This is explicitly typed plain US-ASCII text.
     It DOES end with a linebreak.
 
--simple boundary--
 
     This is the epilogue.  It is also to be ignored.
From: Nathaniel Borenstein 
To: Ned Freed 
Date: Mon, 22 Mar 1993 09:41:09 -0800 (PST)
Subject: Formatted text mail
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary=boundary42
 
--boundary42
Content-Type: text/plain; charset=us-ascii
 
       ... plain text version of message goes here ...
--boundary42
Content-Type: text/enriched
 
       ... RFC 1896 text/enriched version of same message
           goes here ...
--boundary42
Content-Type: application/x-whatever
 
       ... fanciest version of same message goes here ...

--boundary42--

Content-Type: Message/Partial; number=2; total=3;
                   id="oc=jpbe0M2Yt4s@thumper.bellcore.com" 
Content-type: message/external-body;
           access-type=local-file;
           name="/u/nsb/Me.jpeg"
Content-type: image/jpeg
Content-ID: <id42@guppylake.bellcore.com>
Content-Transfer-Encoding: binary
 
     THIS IS NOT REALLY THE BODY! 

至於其他影像檔由 RFC 2048 規定。

上述中,與安全郵件較有關係的是 Multipart Application 型態,S/E-Mail 就是將它的安全機制嵌入於這兩個內文型態之中。

9-3-5 MIME 內容轉換編碼

『內容轉換編碼』(Content Transfer Encoding MIME 另一重要的規範,其功能是指定何種編碼技巧將訊息內容轉換成可傳輸的數碼,MIME 的規範有下列編碼技巧:

指定內容傳輸編碼的控制與法如下:

Content-Type: text/plain; charset=ISO-8859-1

Content-transfer-encoding: base64

上述編碼技巧中,與 S/E-mail 較有關係的是 Base64(即是 radix-64 編碼法)。訊息經過加密或簽署處理之後,會產生一連串的亂碼,這些亂碼並不適合儲存或傳輸,若希望將這些亂碼轉換成可閱讀的字串,需仰賴 Base64 編碼來轉換。Base64 編碼是將一連串的亂碼,以每 6 個位元為單位,連續將它轉換成可閱讀的字元(ASC II 碼),其轉換編碼如表 12-3 所示。

9-3 Base64 編碼轉換表

6 位元

輸入

編碼輸出

6 位元

輸入

編碼輸出

6 位元

輸入

編碼輸出

6 位元

輸入

編碼輸出

0

A

16

Q

32

g

48

w

1

B

17

R

33

h

49

x

2

C

18

S

34

i

50

y

3

D

19

T

35

j

51

z

4

E

20

U

36

k

52

0

5

F

21

V

37

l

53

1

6

G

22

W

38

m

54

2

7

H

23

X

39

n

55

3

8

I

24

Y

40

o

56

4

9

J

25

Z

41

p

57

5

10

L

26

a

42

q

58

6

11

K

27

b

43

r

59

7

12

M

28

c

44

s

60

8

13

N

29

d

45

t

61

9

14

O

30

e

46

u

62

+

15

P

31

f

47

v

63

-

 

 

 

 

 

 

(pad)

=

9-4 Secure-MIME 安全郵件

所謂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 所採用的安全機制之後,接著來探討如何將這些安全機制嵌入 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 標頭及訊息主體,第二個區段則為數位簽章,並包含下列定義及參數值:

其中 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 be here
 
--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 的郵件處理過程,該型態僅有加密處理(或許沒有),並沒有包含簽署功能。假設發信者發送一封信件給多個接收者,處理步驟如下:

至於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 郵件上傳送;收信者再以反方向拆解信件。