安全性分析

此小節我們針對「非對稱加解密金鑰產生」與「加密流程」做安全性相關 的分析。SecCap使用修改過後的OpenSSL程式庫「myOpenSSL」做為金鑰 產生模組，其相關介紹與金鑰安裝流程於3.4.3。另外我們使用EFS做為主要的 檔案加密工具，相關介紹於1.3.3.1。

為 了 在 不 同 電 腦 上 產 生 相 同 的 非 對 稱 加 解 密 金 鑰 ， 我 們 使 用 myRSA_generate_key_ex 函 式 產 生 金 鑰 ， 它 與 OpenSSL 的 RSA_generate_key_ex函式的不同，主要為我們移除了所有因外在環境因素 (時間、設備訊息等) 的而變動的敘述刪除，進而修改為常數版本。非對稱加密 金鑰的資料結構中，重要的成員如Fig. 43。myRSA_generate_key_ex函式初

始化區域變數後，首先產生大質數p和q，再計算n (值為pq) 與d，其中d滿足 de≡1 mod (p-1)(q-1) ，e為函式參數之一，通常為 65537、17 或 3，最後計 算dmp1 (值為d mod (p-1) ) 、dmq1 (值為d mod (q-2) ) 與iqmp (值為q^-1 mod p) 。

struct rsa_st {

因此，我們同樣地實作 myRAND_meth 系列函數做為亂數產生器、

myBN_rand 系列函數做為大數亂數產生器、myBN_generate_prime_ex 系列 函數做為大數質數產生器。以上系列亂數產生器 (Pseudo-random number generator, PRNG) 皆移除了時間、CPU 時鐘、設備資訊、EGD (entropy gathering daemon) 等等參考，我們僅參考智慧卡內憑証之主體名稱、SecCap 秘密字串之雜湊值、與使用者自訂之密碼 (通關密語) 之雜湊值等等，做為產 生亂數之依據，用以在不同電腦上產生相同的非對稱加解密金鑰，以及解決更 換卡片的問題。

根據現今非對稱加解密技術的應用如此發達 (如 PKI) ，我們相信此技術

對於目前的科學而言具有一定的安全程度。SecCap 對於此部分，較於不同的 是「加解密金鑰的產生」其中的亂數產生器。若攻擊者可同時取得憑証之主體 名稱 (SubjectDN) 、SecCap 秘密字串 (SecCap secret value) 、使用者自訂 之通關密語 (Passphrase) 、以及我們所使用的雜湊方法 (Hash method) 等 數 項 資 訊 ， 則 我 們 產 生 出 來 的 非 對 稱 加 解 密 金 鑰 便 為 可 預 期 的 (Predictable) ，此則為不可靠、有安全疑慮的方法。但我們認為攻擊者或一般 使用者，不易於同時取得上述全部的資訊，並且為了解決不同電腦上金鑰產生 的問題，SecCap 選擇此擇中辦法。

EFS加密流程簡圖如Fig. 5，其中「Plaintext File」即為欲加密之明文檔 案，「FEK」為隨機產生的對稱式金鑰，用於加密檔案，「User’s public key」

為使用者之非對稱公開金鑰，「Encryption」為對稱式加密方法，以FEK為金 鑰，對Plaintext File做加密動作，「DDF generation」為Data decrypting field (EFS屬性之其中一欄位，如Fig. 44所示) ，其中包含了以User’s public key為 非對稱金鑰，對FEK加密的資料。 Key Entry 1

DDF Key Entry 2

Container Name Provider Name EFS Certificate Hash

Subject DN

首先需使用MKEK (Master key encryption key，由使用者密碼與其它資訊等 雜湊而成) 對已加密的 MK (Master key，位於%APPDATA% / Microsoft /

Protect / SID) 做解密動作，再以 MK 對已加密的使用者私密金鑰 (位於

上述產生一系列金鑰之源頭為使用者密碼與MKEK。所幸，Microsoft 並 未說明 MKEK 之產生方法，或其所參考的相關資料與雜湊函數。攻擊者在未 知其MKEK 產生方法的情況下，應難以取得使用者私密金鑰。