跳到主要內容區塊

計資中心電子報C&INC E-paper

技術論壇

電子簽章程式設計
  • 卷期:v0001
  • 出版日期:2007-06-20

作者:陳振寰 / 臺灣大學計算機及資訊網路中心程式設計組


當全世界瘋狂跌入「Internet」時,生活中的點點滴滴開始與「數位」朝夕相處,不論是每年五月份的網路報稅,甚至是以後刷信用卡或簽合約時需要的簽章,將可仰賴「電子簽章」,漸漸進入「數位生活時代」。

 

前言

自1977年由羅納德·李維斯特(Ron Rivest)、阿迪·薩莫爾(Adi Shamir)和倫納德·阿德曼(Leonard Adleman)一起提出「RSA」演算法之後,以PKI(Public Key Infrastructure)技術為基礎的電子簽章,已經滲透到我們的生活當中,如網路報稅、網路銀行、網路買賣股票或基金等,漸漸改變了我們的生活形態。在本文中,將概略描述一些簡單的電子簽章相關理論與使用的演算法或工具,最後描述撰寫電子簽章系統程式的概念。

 

何謂電子簽章

傳統的簽章是以墨水式簽名或蓋章方式滲透到紙張文件上,以達到簽署者「不可否認」之目的;電子簽章則是要在「電子文件」上產生「電子印記」,亦達到簽署者「不可否認」的結果。依據行政院所頒佈之電子簽章法,對電子簽章與數位簽章的定義如下:「電子簽章—指依附於電子文件並與其相關連,用以辨識及確認電子文件簽署人身分、資格及電子文件真偽者;數位簽章—指將電子文件以數學演算法或其他方式運算為一定長度之數位資料,以簽署人之私密金鑰對其加密,形成電子簽章,並得以公開金鑰加以驗證者」[1]。

 

數位簽章理論基礎

我們目前最常使用的電子文件簽章方式是以PKI(Public Key Infrastructure)技術為基礎的「數位簽章」方式。包含了「非對稱演算法、雜湊演算法、時戳」等…,才算事一個完整的電子簽章。

常用的非對稱演算法是以「RSA」演算法最為代表。這種演算法在一開始的時候產生兩個極大的數字(512bit~或更大),我們稱之為「金鑰對」,這組「金鑰對」無法由單一把金鑰導出另外一把金鑰的內容,而是使用第一把金鑰對資料加密,且只能使用第二把資料來解密,反之亦同。基於這樣的特性,我們把這對金鑰分別定義為「公鑰」與「私鑰」。私鑰由使用者保存,公鑰由第三人機構留存或由特定第三者簽署憑證,當簽署者以「私鑰」對電子文件作「加密(簽署)」後,可透過第三者機構所留存的「公鑰」對文件上的「簽章」加以驗證,以確認是由簽署者所簽署,達到「不可否認性」。

除了使用非對稱演算法之外,還會使用到「雜湊(Hash)演算法」,這種演算法可以將大量的資料以極少的位元組來表示,且無法預知在何種資料的情況下會產生同樣的「雜湊值」,以達成「資料完整性」。

20070620011001.jpg

 

憑證(Certificate)

為了方便簽章驗證,由第三者機構所扮演的憑證中心(CA)為每位使用者簽署一張包含使用者基本資料、使用者公開金鑰、憑證有效日期、憑證產生製造日期等資料之數位憑證,用來驗證使用者所簽署之簽章。放置使用者公鑰之憑證,可隨時流通在外,任何人都可以取用驗證簽署者的簽章。在這樣的架構下,要檢驗一個簽章是否「有效」,除了驗證簽章為該憑證所有人所簽署外,還需要驗證憑證的有效性,包含檢驗憑證是否為「合法」憑證、憑證是否過期、憑證是否有效等。因此,憑證驗證的過程包含了:

  1. 檢查憑證是否過期(或未開始);
  2. 憑證的有效性:檢查憑證是否被列於CRL(憑證廢止表列)或透過OCSP(Online Certificate Status Protocol)查詢憑證狀態;
  3. 憑證鍊(Certificate Chain)檢驗:檢查憑證是否為CA所簽署,如果CA不是Root CA,則需層層檢驗每一張憑證中的憑證是否有效。

 

電子簽章文件格式

在簽署者的簽章動作結束後,需要將原始資料與簽章資料產生一份特殊格式的文件,以供流通之用。目前最常用的為「RSA組織」所定義的「PKCS#7」格式與「W3C」所定義的「XML Signature」格式。由於「PKCS #7」是較早被發行的安全文件格式,因此「PKCS#7」也是目前最常被使用的格式。

「PKCS#7」是以「ASN.1 DER」格式來放置資料,可支援多人簽署,支援數種不同的模式,可同時支援資料簽章與加密;缺點是該格式不支援部分簽署的功能,而且資料內容需使用程式解析才能看到資料的內容,無法直接以人工方式檢視資料內容。

XML Signature是較新的文件格式,其資料格式是以XML為基礎,最大的特色是支援部分區段簽章與多人簽章,更適合作為目前的組織製作電子簽核系統開發之用。

 

電子簽章系統程式設計

通常我們把稱為Cryptographic的系統分成三個部分:

  1. Token API (Application Program Interface);
  2. Certificate API (Application Program Interface);
  3. Document Format API (Application Program Interface)。

 

我們把放置個人私鑰的儲存體稱之為「Token」,舉凡智慧卡、安全拇指碟、磁片、HSM等都是。每一種「Token」裝置都有不同的操作,如操作智慧卡稱為「ADPU」的指令,向智慧卡提出「服務請求」-讀取檔案、讀取憑證、簽章、加密等,因此在操作各種裝置需要撰寫不同的軟體。為了避免這個問題,軟體巨擘微軟提出了「CSP」(Cryptographic Service Provider)的程式介面,「RSA」組織則提出了「PKCS#11」 的標準界面,用來統一各項設備操作的歧異。因此我們在使用自然人憑證時,需安裝廠商所提供的Safe CSP軟體,以提供標準化的「PKCS#11」介面,供高階的密碼學軟體API使用。簡單來說就是讓使用的應用程式呼叫此介面來作加解密的應用,而不需要知道這些密碼功能的演算法。而因為應用程式和「CSP」是分別獨立的個體,當密碼演算法更新時,我們只需要以新的「 CSP」替換,而不用重新改寫或編譯應用程式,減少開發程式的成本。[2]

「Certificate API」負責操作憑證相關的操作,包含了驗證憑證的有效性(驗證憑證鍊、查詢憑證廢止、OCSP等)。「Document Format API」整合了「Token API」與「Certificate API」,以製作出所需的電子簽章文件格式。

查詢「.NET』開發文件,找尋「namespace」為「System.Security.Cryptography」的類別庫,即提供密碼編譯的基礎函式(包含『ASN.1」格式、對稱加密演算法、雜湊演算法等);若找尋「namespace」為「System.Security.Cryptography.Xml」的類別庫,則提供了「Xml Signature」的相關類別庫,幸運的是微軟的類別庫提供了簡單的程式「呼叫流程」(初始化CSPà執行簽章),使得程式師在撰寫電子簽章程式並不是那麼的困難。但是,不幸的是我們時常必須提供Web Base的簽章程式,在這個環境上,我們可能沒有「.NET」這項好用的工具可以使用,此時程式開發者可能需要找尋不同的工具相互配合使用。

 

參考資料

[1] 電子簽章法,第二條本法用詞定義,民國90年11月14日。
[2]MOICA內政部憑證管理中心 http://moica.nat.gov.tw/download/File/html/SafeSign-CSP.htm