# Secure Electronic Commerce
# 數位憑證技術
## 簡介
所謂『數位憑證』(Digital Certificate)是一份電子性的文件,被用來證明持有人的身分證明,其中至少包含著持有人的姓名、郵政地址、電子郵件地址、以及公開鑰匙,並且必須經過具權威的單位證明其有效期限。如果沒有公正單位可證明公開鑰匙的合法性的話,任何人(譬如志明)皆可利用公開密碼演算法(如 RSA 演算法)產生一對公開鑰匙與私有鑰匙,並宣稱這把公開鑰匙可以代表自己的身份,且將之公佈在於網路上;同樣的道理,別人也可佯稱是志明,同樣將公開鑰匙公佈出來;由此可見,僅有公開鑰匙來證明身份是不夠的,而必須有一公正單位來證明這把公開鑰匙確是屬於該人所擁有。
數位憑證的環境裡,必須存在一個權威單位專門發給個人(或組織單位)一對公開鑰匙與私有鑰匙,並且可以對外宣稱某一把公開鑰匙確是代表某一個人(或法人)的身份。但對他人而言,為何這把鑰匙可以代表某一個人的身份?它的依據又在哪裡?譬如,為何這把公開鑰匙是志明先生的?而不是春嬌小姐所有?誰可以證明它?再說,全台灣有上千位志明先生,到底是哪一位志明?這也有爭執所在的地方。因此,我們需要一個具有權威的單位,專門發給個人公開鑰匙,並且必須詳盡敘述它的個人資料,這就是所謂『數位憑證』(Digital Certificate);而此具有權威的單位,便稱為『憑證授權』(Certificate Authority, CA)中心。以下將分別敘述其功能。
我們希望在網路的虛擬環境下,也能接近於實體環境。在實體環境,每個人(或組織單位)也許擁有許多證件,譬如,汽車駕駛執照。當您在高速公路上駕駛汽車,遇到警察檢查您的駕照時,您只要亮出您的駕照即可,至於您的駕照是真是假?這可要警察自己去判斷(當然,如果是造假的,可能會吃上官司)。又譬如,當您進出海關時,只要秀出您的護照即可,至於護照真假與否,這可要看海關人員的功力了。至於警察如何判斷汽車駕照的真假?除了這個駕照是政府(權威單位)所發外,在駕照上必須有政府單位的戳記,方便警察人員辨識。倘若這樣還是無法嚇止他人使用假駕照的話,警察人員可以透過網路向電腦查詢,這個駕照的來源、以及使用期限,使造假者無法遁形。
『數位憑證』就是讓個人或組織單位在網路的虛擬環境下,可以表示個人身分的依據。當個人需要在網路上進行任何交易,只需秀出個人的數位憑證,足以表明自己的身份;至於此數位憑證是真是假?如警察人員一樣,可向有關單位詢問是否有發出此數位憑證。由此可見,CA中心除了負責發行數位憑證外,也需隨時提供使用者查詢數位憑證真偽的責任;並且每一張數位憑證都有期限的限制,如何去判斷已過期或註銷的憑證,CA中心有需要提供一套完整的系統來處理。
另一方面,數位憑證可以達到直接仲裁與第三者仲裁的功能;當接收者收到憑證之後,可自行或透過其它管道確認這張憑證的真偽;當對方否認交易行為時,接收者亦可將他的憑證及傳送訊息,呈送給法院當作證物使用(目前已具有法律地位)。因此,數位憑證是時下電子商務或電子化管理環境,不可或缺的主要工具。
## 公開金鑰基礎建設(PKI)
雖然有數學理論或是長久的實務驗證說明公開金鑰密碼技術的各種演算法已達一定的安全性,然而如果無法確保「通訊雙方能夠正確地取得對方公開金鑰」,則縱使有完美的密碼演算法也是沒有用的。在實務上還需要建置一些管理機制、設施、或服務等,以確保可以達到「通訊雙方能夠正確地取得對方公開金鑰」這個重要重要前提。所謂 「公開金鑰基礎建設」(Public Key Infrastructure,PKI)是一種支持公開金鑰密碼技術正常運作的基礎建設,所謂Infrastructure包含了設備、設施、服務、人員、法律、政策、和規範等。PKI內含對稱及非對稱性密碼技術、軟體和網路服務的整合技術,主要是用來提供保障網路通訊和企業電子交易的安全。同時,PKI為一種支援憑證的軟體、標準和協定的安全性整合服務。
狹義上來說公開金鑰基礎建設是指建置憑證機構提供憑證管理服務,
而廣義的公開金鑰基礎建設則涵蓋任何有助於公開金鑰密碼技術運作的機制或設施,甚至於相關管理措施或法規制度都可以算是公開金鑰基礎建設的一環。常見的PKI服務有憑證機構提供的憑證管理服務、憑證路徑建構服務(Certification Path Construction Service)、憑證路徑驗證服務(Certification Path Validation Service)、數位時戳服務(Digital Timestamp Service )、資料驗證服務(Data Validation and Certification Service)等等。
## 憑證授權中心

發出憑證的單位(或公司),便稱為『憑證授權』(Certification Authority, CA)中心。CA 中心必須是個可信賴的公正單位(私人或政府),它會依據合法申請者的請求,發出數位憑證。數位憑證裡包含了申請人的辨識資料(姓名、地址、或身份字號)、申請人的公開鑰匙、序號與其他資料,並保證不會造假;並且 CA 中心利用自己的私有鑰匙向上述資料簽署,所得到的數位簽章亦存放於憑證裡。也就是說,每一張數位憑證必須有發行 CA 的數位簽章,而此數位簽章是利用 CA 中心的私有鑰匙簽署保證。任何人,如果懷疑某一張數位憑證的真實性,便可以利用 CA 的公開鑰匙來認證它的正確性。這裡又出現另一個問題,欲取得 CA 的公開鑰匙,必須先拿到該 CA 的數位憑證,再由它的數位憑證取得它的公開鑰匙,但這張數位憑證的真實性如何?亦無法保證;因此,需仰賴另一個較高權威的 CA 來證實它,這就是 CA 中心也需要憑證的理由。
目前台灣較具權威的認證中心有:
* 政府憑證管理中心 (gcp.nat.gov.tw):這是官方發行單位,可以針對個人(自然人)或公司行號(法人)發行數位憑證,所發行的憑證較具有權威性,它的用途也較為特殊。譬如,透過網路向政府單位承標各種工程或器材,便需要此 CA 中心所發行的憑證來證明自己的身份。
* 內政部憑證管理中心(moica.nat.gov.tw):官方發行單位,這是針對個人所發行的憑證,功能就如同個人身分證一樣,又稱為『電子身分證 IC 卡』。個人(或稱自然人)欲透過網路向政府機關申辦任何事項,便以此憑證來確認身份。
* 經濟部工商憑證管理中心(moeaca.nat.gov.tw):官方發行單位,其建置工商憑證管理中心核發事業主體的數位憑證,同時提供可靠、安全及快速的網路申辦系統,提高作業效率及服務品質。
* 台灣網路認證 (www.taica.com.tw):這是民間發行單位(主要是台灣證券交易所),主要用途是使用於透過網路來執行股票交易(下單買賣)時,認證下單者的真正身份、也發行電子錢包;但目前也有許多網路銀行,利用此 CA 所發行的憑證來確認客戶的身份。
* 網際威信 (www.hitrust.com.tw):這是民間發行公司,接受個人、公司行號、以及 SSL 伺服器憑證申請,主要是從事一般電子商務上的身份證明。
## CA 的架構
* 階層式架構(Hierarchical)
* 階層式架構就如同樹狀結構一般,其運作的方式是由一最高層級的Root CA對下一層的CA簽發憑證,再由這第二層CA對第三層CA或是其自身底下的使用者簽發憑證,一層一層的延續,以此類推。
* 最容易瞭解的CA架構,就是階層信任模型,簡單的說,就是下一層的CA須信任上一階層CA。
* CA之間必須信任其所簽署的使用者。
* 
* 網狀式架構(Web)
* PGP ( Pretty Good Privacy )
* Phil Zimmermann (1991)
* 自簽憑證
* 對於他人的憑證給信任程度
* 累積信任(數位簽章)
* OpenPGP
* 
* 網狀式架構則是由許多獨立的使用者互簽憑證所形成的一種架構,此架構下使用者一開始只相信自己,因此,若要驗證其他使用者的公開金鑰,則要自行尋找一條相對應的驗證路徑。
* 這個概念所表達的是說,每個使用者驗證自己的憑證,並將這憑證告訴所有與自己相關的人員。
* 認識憑證擁有人的相關人員,則可以自行選擇是否信任這份憑證。
* 
* 
## CA 的服務項目
當 CA 中心核准申請並產生鑰匙配對之後,便將私鑰與數位憑證儲存於 IC卡上,再交付給申請者。持有者可能會遺失 IC 卡、忘記通行碼、或者對鑰匙配對的安全性感到懷疑時,則可向 CA 中心提出相關的服務請求。CA 中心的服務項目如下圖所示,說明如下:
* 憑證簽發、更新與終止:CA 中心負責用戶身份的審核及憑證簽發、更新、以及終止用戶的憑證。
* 憑證保存:CA 中心必須紀錄所有的有效憑證、過期憑證、以及註銷憑證的清單,並提供相關憑證變動資料給用戶。
* 憑證查詢與分送:除了保存各種憑證資料外,還必須供應客戶的查詢,或者分送憑證給客戶。
* 公正仲裁:當交易發生爭執時,CA 必須提供如用戶的身份及公鑰等公正資料,給相關仲裁單位(如法院)。

## 憑證的產生與認證
如果想要在網路上從事各種交易(或電子商務),那就必須向一家較具有權威的 CA 中心申請數位憑證。但隨著交易行為不同,或許會有不同的數位憑證,這種現象就如同一個人(或組織)持有各種不同的證照一樣。譬如,志明想要透過網路申報綜合所得稅,因此他可以選擇向台灣網路認證中心(taica)申請數位憑證,其步驟如下:
* 志明向 taica 提出申請數位憑證的請求,並將個人相關資料傳送給(或親自辦理)taica。
* taica 查核志明的相關資料後,便製造志明個人的公鑰與私鑰配對;也製作志明的數位憑證,其中包含志明的個人資料(姓名、地址、E-mail 位址等等)、公鑰、以及 taica 公司的數位簽章;其中數位簽章是表示 taica 對這張憑證的證實資料(如同印章一樣)。並將志明的數位憑證登錄到資料庫系統內(LDAP 系統,第九章介紹)以供查詢。
* taica 公司將數位憑證與私有鑰匙分別傳送給志明,其可能儲存於不同的磁片上,或者一起燒錄於 IC 卡上。
* 志明便可利用 taica 公司所發行的數位憑證與私鑰,向稅捐處申報綜合所得稅。
* 稅捐處收到志明的數位憑證,由數位憑證的標頭上可以觀察出是出自 taica 公司所發行,便利用 taica 公司的公開鑰匙來認證此憑證的真偽。認證方法是,首先利用 taica 的公鑰來向憑證內的數位簽章解密,再利用憑證上所敘述的雜湊演算法來向憑證內的資料做計算,如果兩者結果相同的話,則表示憑證是正確的,而且內容也沒有被竄改過。

當 CA 中心收到客戶端的申請時,如何去過濾及查核申請人的資料,這真是一件繁複的工作。如果權威性較高的 CA,它期望所發出的憑證不會重複,亦是,針對每一個人(或法人)只能發給一張憑證;另外,也許會有冒名或相同名字的申請者,當然必須詳加調查清楚,通常查核的工作可能要 2 天到一個星期的時間。
## 憑證的註銷
每一張數位憑證都有一個有效期間的限制,即使有效期間內,憑證也有可能被註銷,註銷原因有:
* 用戶的私鑰遺失、或公鑰被破解,而需要修改私鑰與公鑰時。
* 用戶的私鑰被盜竊使用,而需要重新修改私鑰與公鑰。
* CA中心發現憑證發給錯誤的個人或團體、或發現原申請資料不正確。
* 用戶不再使用此憑證,而申請註銷。
CA 中心必須隨時備有這些已註銷的資料,讓一般客戶查詢。一般 CA 都會使用『憑證註銷序列』(Certificate Revocation List, CRL)來記錄所有已被註銷的憑證。當客戶收到某一張憑證之後,除了觀察憑證上所紀錄的有效期間是否過期外,也可以透過網路向 CA 中心查詢,該憑證是否過期。然而,當 CA 的申請者愈多時,可能的註銷憑證也會快速的成長;另一方面,為了安全起見,CA 中心還提供各種憑證資料的查詢,因此,CA 除了需要一個快速的資料庫系統來儲存,也需要有一個共通的通訊協定來制定查詢的運作程序與語法,這些都是 PKI 系統所需制定的標準。目前 PKI 大多採用 LDAP 協定來制定客戶端與伺服端之間的查詢動作,並以 X.509 標準來制定數位憑證的格式。
## 數位憑證的種類
到底有哪些數位憑證?這種觀念和實際環境(Real Environment)非常類似。在實際環境裡,每個人可能擁有許多證照,譬如,身分證、汽車駕照、機車駕照、護照、學生證等等,每一種證照都有其特殊功能;譬如,到政府機關申請資料,必須要身份證、在學校圖書館借書,需要學生證等等。以公司行號而言,各行各業都需要營業執照,證明其營業項目是否許可。
虛擬空間也是一樣,存在許多數位憑證,每一種數位憑證具備其特殊功能,使用者可依照需要向不同的 CA 中心申請憑證,一般網路上所使用的憑證可分為下列四種:
* 憑證授權(CA)中心憑證:雖然 CA 中心負責發行憑證給使用者,但 CA 中心也需要另一個較高權威單位授權給它,足以表示其信用度。
* 伺服器憑證:在網路的虛擬空間裡,無法確定通訊對方的身份,尤其存取某一伺服器時,也很難判斷這部伺服器是否偽裝的,因此,伺服器需向 CA 中心申請憑證,以確定自己真正的身份。這種情況非常類似實際環境裡的商家,有了商家的營利登記憑證,我們才能確定這家商店是否合法化。目前網路上,從事於電子商務的伺服器,大多需要申請 SSL 數位憑證,以確定伺服器本身的名稱及公鑰。
* 個人憑證:這是由自然人或法人向 CA 中心所申請的憑證。在個人憑證裡會詳細描述當事人身分,譬如,E-Mail 位址、郵政地址、身份證字號等等。但隨著個人憑證的使用時機不同,許多 CA 中心也發行以別名取代的憑證,但這種憑證大多祇能使用於某一特殊用途,並無法廣泛使用。
* 軟體發行憑證:這是確定軟體身份的憑證。當您購買某一套軟體(或執行某一軟體)時,如何證明這套軟體的真偽,可由軟體發行憑證來驗證它的身份。
無論何種憑證都擁有一把公開鑰匙、以及持有該憑證的身份資料。如果您對它的憑證有所疑問時,可向發行該憑證的 CA 中心查詢。至於數位憑證的格式為何?接下來我們介紹它。
## 數位憑證的格式
數位憑證是一個電子資料,將所有資料紀錄在某一個檔案上,以供其他應用系統查詢。為了使這個檔案能廣泛的被其他系統查詢,需要建立一個標準格式。目前網路上最廣泛的憑證格式標準為 X.509 v3(version 3),又稱為『X.509 數位憑證』(X.509 Digital Certificate)。下表為 X.509 的標準規範,每一張數位憑證至少包含有:憑證版本、序號、數位簽章演算法、憑證發行者、有效期間、主體、公鑰、數位簽章等等。其中數位簽章即是利用 CA 中心的私有鑰匙向上述資料簽署所得的值,其功能如同一般證照的鋼印一樣,表示發行者保證這張憑證的正確性;接收到憑證者之後,可利用 CA 的公開鑰匙,來驗證該憑證的真偽。

## 憑證與私鑰的儲存元件
既然數位憑證是由一串列的電子資料所表示,如何儲存這些電子資料並且能隨時攜帶於身上,正是儲存媒體(或元件)所考量的地方。儲存電子資料的媒體可由兩個方向來思考,一者僅具儲存資料的功能,此類大多屬於被動元件,必須透過讀取設備程式的管理及操控;另一者需具有管理功能的主動元件,大多有特殊的作業系統管理儲存媒體與讀取設備之間的通訊。我們用一個簡單的範例來說明兩者之間的差異點。譬如,磁卡(如信用卡)僅具有儲存卡號及簡單的數據,讀卡機讀取資料之後,再與主機通訊來判斷該磁卡上的訊息是否正確。由此可見,磁卡內所儲存的資料可任意被讀取,甚至偽造另一片磁卡。IC 卡(如 Smart Card)具有管理功能,當讀取設備需要取資料時,IC 卡會與讀取設備之間執行某些關鍵性的詢問與確認(如通行碼),可以確定讀取設備的身份之後,IC 卡才會將自己的資料傳送給讀取設備,如此一來,IC 卡上的資料便較不容易被詐騙取得,也較不容易被竄改偽造。另一方面,儲存媒體大多不僅存放數位憑證而已,通常會將私有鑰匙一併存放在裡面,否則私有鑰匙僅是一連串無意義的電子資料,無論要記憶或書寫它都有困難,因此,還是主動式的儲存媒體較為安全一點。
簡單的說,具有管理功能的儲存媒體才能達到持卡者與讀取設備之間的相互認證身份(容後介紹),然而僅具有儲存功能的媒體大多不具有這些功能。這方面對於數位憑證而言是非常重要的,我們希望在虛擬環境之下交易,至少必須能單向或相互認證對方身份,才不至於被冒名詐騙得逞。無論如何,我們還是將可能儲存數位憑證的媒體歸納如下:
* 磁碟片:這是早期所使用的儲存媒體,其具有較高的容量(1.44 MByte),但不具有管理功能是屬於被動式元件。磁碟片可以任意拷貝並讀取,因此容易被偽造竄改,目前已很少使用。
* 隨身碟:其功能大都與磁碟片相同,只是具有更大的儲存空間(32 Mbyte 以上)。目前電腦大多配備有 USB 介面,不需特殊軟體(Windows XP 以上)便可以讀取隨身碟上的資料,雖然方便但他的安全性同樣是有疑慮的。
* USB Token:其裝置大多與隨身碟相似,但在隨身碟上安裝有特殊管理功能(如 COS 作業系統,容後介紹),可以和讀取設備之間作符記(Token)協定的交談,如此便具有較高的安全效果。
* IC 卡:具有管理功能的 IC 卡又稱之為『智慧卡』(Smart Card),卡片上的 IC(Integrated Circuit)可包含著 CPU(如 8051)及相關記憶體單元。基本上,IC 卡就具有簡單電腦系統的功能,不但有獨立的處理單元、作業系統(COS)、輸入/輸出介面,它與讀取設備(讀卡機)之間可從於較嚴謹的通訊協定(如 PKCS #11),來管理並認證對方身份的工作,因此他的安全性可以說是最高的,也是目前最普遍採用的儲存元件。
## 智慧卡運作
既然數位憑證儲存於某一媒體上,而此媒體是一個獨立的元件(譬如 IC 卡),也許他人可以盜取此儲存媒體來從事網路交易。因此,最起碼必須有一個通行碼來作第一道關卡的保護;也就是說,當使用者想要由儲存媒體上讀出資料(如私有鑰匙)時,必須經過通行碼的認證,才可以讀出資料並從事網路交易,而且驗證通行碼的訊息必須儲存於媒體上(如 IC 卡),其運作下圖所示。

## 數位憑證的運作
利用 IC 卡儲存數位憑證(或稱為 Smart Card)是目前最普遍採用的元件,然而,當我們由 IC 卡取出憑證資料(X.509 憑證,主要是公開鑰匙),並傳送給對方時,對方如何判斷此憑證並非他人所冒用。記得前面討論過,我們希望數位憑證能像真實環境裡的各種證照的功能,並且能在網路上自由通行。譬如,當您遇到交通警察要求您出示駕駛執照時,警察最起碼由駕照的相片確認是您本人,或者是他人所偽造;另一方面,您也可以從攔截您停車之警察的警徽或相關警察證件,辨別其真偽。很不幸的,在虛擬環境裡並無法正確地觀察到出示憑證的本人面貌,因此必須有特殊的處理功能始可行,我們就單向認證與雙向的相互認證兩方面來探討。
## 憑證認證
#### 單向認證(One-way authentication)
* 這是最簡單的認證方式,用戶端只需提供訊息給伺服端作存取確認,伺服端確認後就允許用戶端的登入。
* 訊息中包含時戳(tA) 、臨時亂數(rA)、B的ID(IDB)及以B的公開金鑰加密後的通訊金鑰(Kab),除此之外,也可於這之中附加其他訊息(sgnData),以上所有訊息都必須以A的私密金鑰加密後傳送。

* 伺服端認證大都採用盤問/回應(challenge/ response)方式
* 認證內容可區分明文盤問、密文盤問及時間戳記盤問三種方式,如以下示意圖:

#### 雙向認證(Two-way authentication)
* 需要兩個訊息 (A->B, B->A) ,為一種雙方相互認證(mutual authentication)的方式,雙方都得提供認證資訊給對方,才能通過認證。
* B回應給A的訊息包括A原來的臨時亂數(rA)、ID(IDA)、時戳(tB)、B的臨時亂數(rB)及以A的公開金鑰加密的通訊金鑰(Kba)。
* 雙向認證方式,必須維護對方所對應的認證資訊。
* 身份鑑別協定透過交換通訊金鑰(session key)用來確認雙方ID。
* 身份鑑別主要的安全考量是:
* 保密性(confidentiality) – 保護通訊金鑰,防止外洩。
* 時效性(timeliness) – 預防重送攻擊(replay attack)。

#### 三向認證(Three-way authentication)
* 需要三個訊息 (A->B, B->A, A->B),藉此達成上述確認性,並且過程中不需時脈同步即可完成。
* 會多一個由A回傳給B的訊息,內容包含簽署過的B的臨時亂數(rB)。
* 因為雙方均傳回對方的亂數,故不需要依賴時戳,當雙方的時序無法同步時,此法就可派上用場。

## 數位憑證在應用程式中的應用
* SSL/TLS
* 提供資料通訊隱私和完整性的一種通訊協定。Web 伺服器會使用這種通訊協定來提供 Web 伺服器和 Web 瀏覽器之間的連線安全。SSL 和 TLS 都是加密協議,用於從客戶端到伺服器、電腦或應用程式數據傳輸的加密和驗證。SSL(Secure Socket Layer)是 TLS(Transport Layer Security)的前身,SSL 於1995年由 Netscape 開發,用於保障網路上數據傳輸的安全,不過有許多漏洞,因此一年後被 SSL v3.0 取代,但這個版本也不完美,所以1999年推出了 TLS,屬於 SSL v3.0 的後續版本。現在,大多數設備和瀏覽器都已支援 TLS v1.2。然而許多人習慣了 SSL 這個名詞,因此他們將 TLS 稱為 SSL。多數人現在使用 SSL/TLS 這個名詞作為代表。SSL/TSL 在金鑰交換、伺服器鑑定以及選用的用戶端鑑定中,使用數位憑證。
* 用戶端鑑定
* 用戶端鑑定是 SSL/TSL 中的一個選項, 伺服器在讓用戶端登入或存取特定資源之前,要先鑑定用戶端的數位憑證。 伺服器會在 SSL/TSL 訊息交換期間,要求及鑑定用戶端的數位憑證。 在那時,伺服器也可以決定它是否要信任發出數位憑證給用戶端的憑證管理中心。
* 安全電子郵件
* 許多電子郵件系統為了擁有安全的電子郵件,而使用 Privacy Enhanced Mail (PEM) 或 Secure/Multipurpose Internet Mail Extensions (S/MIME) 之類的標準,它們使用數位憑證進行數位簽章以及金鑰交換,以便加密及解密訊息。
* 虛擬私有網路 (VPN)
* 虛擬私有網路亦稱為安全通道,可以設定在防火牆之間,以便保護安全網路在透過不安全 通訊鏈結時的連線安全。 通往這些網路的所有流量都會在防火牆之間加密。通道傳輸使用的通訊協定是遵循 IP Security (IPsec) 標準。為了在對等防火牆之間交換金鑰, 已經定義「網際網路金鑰交換」(IKE) 標準,此標準以前稱為 ISAKMP/Oakley。此標準也可以在遠端用戶端(例如,員工在家工作)與安全主機或網路之間建立安全、加密連線。
* 安全電子交易 ( SET(TM) )
* SET 是一種設計用來在不安全網路(網際網路) 中進行安全信用卡付款的標準。 持卡人(電子信用卡)和商家都使用數位憑證。 在 SET 中使用數位憑證,可在持卡人、商家以及銀行之間建立安全、隱密的連線。 所建立的交易既安全且無爭議,也不能偽造。商家不會收到被濫用或竊用的信用卡資訊。
## S/MIME 郵件安全性的運作方式
* 透過數位憑證啟用公開金鑰加密
* 利用公開金鑰為加密數位簽章與郵件加密提供基本的安全性服務
下圖顯示簽章與加密作業搭配數位憑證的流程。

* 1.擷取郵件。
* 2.計算郵件的雜湊值。
* 3.從寄件者的數位憑證中,擷取寄件者的私密金鑰。
* 4.從收件者的數位憑證中,擷取收件者的公開金鑰。
* 5.使用寄件者的私密金鑰,對雜湊值進行加密。
* 6.將加密的雜湊值附加到郵件上,成為數位簽章。
* 7.產生執行一次的對稱式工作階段金鑰。
* 8.使用工作階段金鑰,對郵件進行加密。
* 9.使用收件者的公開金鑰,對工作階段金鑰進行加密。
* 10.將已加密的工作階段金鑰附加於加密的郵件中。
* 11.傳送郵件。
下圖顯示解密作業與數位簽章驗證作業搭配公開金鑰加密的流程。

* 1.接收郵件。
* 2.從郵件中擷取加密的郵件與加密的工作階段金鑰。
* 3.從收件者的數位憑證中,擷取收件者的私密金鑰。
* 4.使用來自於收件者數位憑證的收件者私密金鑰,對工作階段金鑰進行解密。
* 5.使用已解密的工作階段金鑰,對郵件進行解密。
* 6.從郵件中擷取含有加密雜湊值的數位簽章。
* 7.計算郵件的雜湊值。
* 8.從寄件者的數位憑證中,擷取寄件者的公開金鑰。
* 9.使用寄件者的公開金鑰,對已加密的雜湊值進行解密。
* 10.將解密完成的雜湊值與接收時所產生的雜湊值進行比較。
* 11.若兩個值相符,即為有效郵件。
* 12.將未加密的郵件傳回給收件者。
## SET - Secure Electronic Transaction
* schematic diagram:

* Dual Signature :
* The dual signature is a concept introduced with SET, which aims at connecting two information pieces meant for two different receivers :
* Order Information (OI) for merchant
* Payment Information (PI) for bank

```
PI stands for payment information
OI stands for order information
PIMD stands for Payment Information Message Digest
OIMD stands for Order Information Message Digest
POMD stands for Payment Order Message Digest
H stands for Hashing
E stands for public key encryption
KPc is customer's private key
|| stands for append operation
Dual signature, DS= E(KPc, [H(H(PI)||H(OI))])
```
* Purchase Request Generation :
* requires three inputs:
* Payment Information (PI)
* Dual Signature
* Order Information Message Digest (OIMD)

```
PI, OIMD, OI all have the same meanings as before.
The new things are :
EP which is symmetric key encryption
Ks is a temporary symmetric key
KUbank is public key of bank
CA is Cardholder or customer Certificate
Digital Envelope = E(KUbank, Ks)
```
* Purchase Request Validation on Merchant Side :
* The Merchant verifies by comparing POMD generated through PIMD hashing with POMD generated through decryption of Dual Signature as follows:
* Since we used Customer’s private key in encryption here we use KUC which is the public key of the customer or cardholder for decryption ‘D’.

* Payment Authorization and Payment Capture :
* Payment authorization as the name suggests is the authorization of payment information by the merchant which ensures payment will be received by the merchant. Payment capture is the process by which a merchant receives payment which includes again generating some request blocks to gateway and payment gateway in turn issues payment to the merchant.
# 簡報中同學提問
1. CA 要怎麼產生憑證,又怎麼確認是否為正確?
2. 請問我們如何去申請憑證,相關的流程是?
3. 是否可能會有憑證偽造的可能性?
4. 請問要如何分辨數位憑證是否為真或是偽造?
5. 請問審核發放憑證的過程是否可能有偽造或竄改的可能?
answer1-5 : CA產生憑證需要一定的流程,在書面報告中有較詳細的說明,最重要的是將憑證持有者與金鑰的關係確立。而產生之後可以透過憑證檢驗的方式確保正確性。
6. 請問法律效力是由哪一個組織保障?
7. 請問民間的CA會不會有公信力不足的問題?
answer6-7 : 簡報中指的法律效力為經由公信力單位簽發,像是自然人憑證可以作為個人的數位身分證就是具有法律效力的。至於民間的CA公司,是經過政府立案成立,在現行法規制約下執行,在申請憑證的審核資料方面應是足夠信任。
8. 台灣有哪些CA在進行憑證的發放,而其又歷屬於哪些單位?
answer : 台灣有不同的公部門與公司發行不同功能的憑證,在書面報告中有詳細說明。如內政部、經濟部、台灣網路認證公司、網際威信公司
9. CA階層是由誰定義?
answer : 是誰定義的不重要,重要的是這樣的架構可以很好的符合驗證需求。
10. 階層式驗證上層如果遭受攻擊,下層應如何處理?
11. 若階層式的上層被攻擊後下層該怎麼辦?
answer10-11 : 憑證的驗證主要是離線進行的,不用每次驗證都需要連線至伺服器;假如需要連線時正在被攻擊,這就不是數位憑證的領域,而是網路安全。
12. 自簽憑證可以用在小規模,但大規模不行,是因為自簽的憑證,沒有人可以驗證其合法性嗎?
answer : 主要是因為這樣的架構在大規模的時候不易管理,也有可能出現驗證孤島,更不用說法律效力。
13. PGP的信任程度是由哪些因素決定的?
answer : PGP中的信任來自自身對於他人的信任程度,有分為信賴者與陌生人,而信賴者的憑證與其完全信任的憑證為我方信任的憑證;多個信賴者部分信任的憑證 ( 如三個 ) 也可以為我方信任的憑證。
14. 為何階層式驗證在架構較小時成本會很高,在架構較小時PGP相較有何優勢?
answer : 階層式不管規模大小都需要建置基礎設備來因應驗證需求,而PGP可以不需要這些額外的成本。
15. 想請問CA的建立是否有規定?
answer : 目前沒有法律的要求,但是在建立CA的方面有許多建議可以參照。
16. 台灣未來有機會廣泛使用數位憑證的可能嗎?
answer : 可能需要更多的法律保障來提高使用意願。
17. 想請問憑證中pi和oi為何需要分開計算?
answer : 這設計主要是以安全性為出發點的,分開算的保護效果比串接在一起也在我們的意料範圍之外。
18. SET協定除了保障完整、保密性等,能否有附加服務?
answer : 除了上述2個性質,因SET會記錄下買賣雙方的資訊,這同時也代表了不否可認姓,其餘的服務則不是SET探討的重點。
19. 為何OI、PI要分開進行雜湊?
answer : 主要是為了安全性,根據資料顯示OI、PI分開先進行雜湊再串接的防護性比和在一起還要顯著。
20. 請問憑證交給非政府管理是否會有安全疑慮的問題?
answer : 不管將憑證集中給哪個大型組織都是會有風險的,只是相對來講國家政府會比較合理,但重要的還是大部分民眾要相信該組織有一定的社會公信力。
21. 請問要如何確保金鑰存放的安全?
answer : 基本上就跟以前學到的上網基本知識相差無幾,不要進入奇怪的連結、盡量使用有通過SSL/TLS認證的網站等等老生常談。
22. S/MIME郵件進行額外的加密驗證,相較一般電子郵件多了哪些安全的保證?
answer : S/MIME最大的特色就是在郵件系統上使用了公私鑰的非對稱加密,配合上數位憑證有相當不錯的保護能力。
23. 數位憑證註銷的作法
answer : 每一張數位憑證都有一個有效期間的限制,即使有效期間內,憑證也有可能被註銷。一般 CA 都會使用『憑證註銷序列』(Certificate Revocation List, CRL)來記錄所有已被註銷的憑證。
24. pi oi 分開送有什麼問題?
answer : PI、OI分開送的缺點是安全性較低,會產生一些資安上的風險。
26. 若憑證私鑰不慎洩漏,該怎麼防止被冒用的風險,或是及時撤銷的機制?
answer : 執行註銷流程。
27. 憑證註銷(X.509 v3)跟被破解公鑰註銷(X.509 v2)步驟有什麼差別?
answer : 前者為主動式的註銷,後者為金鑰被破解的被動式註銷,但是不管是哪種註銷,廢棄的憑證就同樣不會再使用
28. 請問註銷後的序列是否會重新使用?
answer : 不會。若重複使用註銷的序列,會有重複性的疑慮。若註銷後的序列可重複使用使用的話,我們可能會面臨不知道這張憑證是盜用亦或是註銷序列手續的失誤。
29. 憑證的驗證有單向驗證 雙向認證 三向驗證,什麼情況下使用那個驗證
answer : 單向驗證主要是單向的(即只有A對B),而雙向認證、三向認證其實都是雙向的(即A對B、B對A)。相較於雙向認證,因為雙方均傳回對方的亂數,三向驗證故不需要依賴時戳,當雙方的時序無法同步時,此方法就可以派上用場。
{"metaMigratedAt":"2023-06-16T21:59:15.172Z","metaMigratedFrom":"YAML","title":"Secure Electronic Commerce Report","breaks":true,"contributors":"[{\"id\":\"01caa8d7-d183-4b6c-b574-2f93a074e110\",\"add\":2071,\"del\":451},{\"id\":\"e3cfbba5-ec21-4df6-bbc1-cfafc97cb430\",\"add\":19075,\"del\":5109}]"}