電子簽章程式設計

手機版選單

下方連結

back to top

:::

電子簽章程式設計

卷期：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）演算法」，這種演算法可以將大量的資料以極少的位元組來表示，且無法預知在何種資料的情況下會產生同樣的「雜湊值」，以達成「資料完整性」。

憑證（Certificate）

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

檢查憑證是否過期（或未開始）；
憑證的有效性：檢查憑證是否被列於CRL（憑證廢止表列）或透過OCSP（Online Certificate Status Protocol）查詢憑證狀態；
憑證鍊（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的系統分成三個部分：

Token API (Application Program Interface)；
Certificate API (Application Program Interface)；
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」這項好用的工具可以使用，此時程式開發者可能需要找尋不同的工具相互配合使用。