最近一直在思考交易鑑權以及對於交易有效性舉證的問題，記下來對此的一些知識點與思考，希望能拋磚引玉。其中涉及到《電子簽名法》的部分內容，雖然我的大學專業中也帶了一個“法”字，但是畢竟是“法語”不是“法律”。也和幾位做法務領域的朋友交流過，但是《電子簽名法》相對小眾且新潮，歡迎各位有《電子簽名法》實操經驗的法務大神吐槽。
一、目前的交易鑑權模式
其實這一段純碎是為了湊字數，我想任何一個做 PM 的同學都會說上絕大多目前市面上廣泛使用的交易鑑權方式。
1. 賬號+密碼
賬號+密碼是目前最普遍的驗證方式，還有的業務會增加交易密碼二次驗證。方案很成熟，也很基礎。借用在討論交易安全時，我們的一個資深開發小哥哥的一句話來證明：（在我們說了問題之後，小哥哥默默的來了一句）我對我的編程生涯第一次產生了懷疑，難道我連登陸系統都寫不了了麼？賬號+密碼的方案用戶接受程度最高，可以作為登陸等非關鍵操作的驗證方式。
對於這一塊，我曾經在《互金產品基礎知識（三）作為 P2P 產品經理，你要知道的融資端風控問題》[1]寫到一些。
2. 密碼控件
作為上一種鑑權方式的加強版，通過使用密碼控件來在保證密碼輸入框安全，保證密碼不被竊取：軟鍵盤防止鍵盤監聽、星號顯示防止被偷看；加密傳輸防止網絡竊取。目前主要的廠商有科籃、飛天等。
但是安全控件兼容性差，必須用 windows+IE 瀏覽器，且無法應對鍵盤記錄器等木馬（當然，有一些安全控件還有軟鍵盤功能），隨著目前賬號風控體系的完善，已經很少有系統在使用了。先不考慮。
3. 生物識別
主要利用指紋、人臉、虹膜等不可變的生物特徵進行識別。目前比較廣泛的是指紋和人臉識別。
隨著各種生物識別設備的普及被竊概率不斷增加，且生物特徵不可變更，識別準確率不高。之前有過通過三張照片，小視頻之類的突破銀行存管開戶的案例。不過作為一個發展中的技術，我相信生物識別的能力會越來越強。
4. 圖形驗證碼
圖形驗證碼並不是一個狹義的交易鑑權方案，它只能算是人機對抗、過濾機器人（虛假用戶）的一個方案。
圖形驗證碼存在著一個天然的悖論：太簡單會被機器破解起不到過濾作用，太複雜則會給真實用戶帶來影響；另外隨著現在機器學習圖片識別技術的發展，圖形驗證碼（包括其變種模式）已經越來越難起到作用。還有就是現在的打碼平臺，本質就是個人在輸入驗證碼，單純依靠圖形驗證碼（不考慮其他輔助措施，比如ip風控、機器指紋識別等）怎麼來過濾。
5. 手機驗證碼
手機驗證碼是目前比較廣泛的鑑權方案，但是手機病毒、偽基站、盜換/複製 SIM 卡等辦法都可以進行攻擊。當然隨著 GSM 網絡的退網，偽基站和複製 SIM 卡的方法可能會絕技，但是手機病毒多半估計無法徹底滅絕。
人民銀行辦公廳曾經在2016年專門下發過《金融業信息安全風險提示》，提示手機驗證碼短信被黑客攔截的手段、風險和後果。
6. 動態密碼鎖
就是將軍令那種東西， HOTP 事件同步或 TOTP 事件同步，一次性口令生成。我曾經寫過《給產品經理講技術-Google驗證的原理及應用場景》[2]，有興趣的可以去看看。
但是問題也很明顯：需要多攜帶一個設備（口令工具）或多安裝一個 app，另外目前眾多算法已經被公開，安全性較差。
7. 動態口令卡
就是一張卡片，每張動態口令卡覆蓋有若干個不同的密碼。在啟用動態口令卡後，進行交易時，需按順序輸入動態口令卡上的密碼。
這東西絕對是逆歷史潮流的，每張口令卡覆蓋的密碼有限，每個密碼只可以使用一次。用盡後需要重新更換，侷限性大。除非你家公司可以在全國任何一個縣鄉都有點（比如國有大銀行爸爸們），否則你還是不要想了。另外密碼都在口令卡上以明文方式存在，容易洩漏。
8. 數字證書
數字證書是用於公開祕鑰基礎建設（PKI 體系）的電子文件，用來證明公開密鑰擁有者的身份。此文件包含了公鑰信息、擁有者身份信息（主體）、以及數字證書認證機構（發行者）對這份文件的數字簽名，以保證這個文件的整體內容正確無誤。擁有者憑著此文件，可向計算機系統或其他用戶表明身份，從而對方獲得信任並授權訪問或使用某些敏感的計算機服務。
計算機系統或其他用戶可以透過一定的程序核實證書上的內容，包括證書有否過期、數字簽名是否有效，如果你信任簽發的機構，就可以信任證書上的密鑰，憑公鑰加密與擁有者進行可靠的通信。
數字證書的其中一個最主要好處是在認證擁有者身份期間，擁有者的敏感個人數據（如出生日期、身份證號碼等）並不會傳輸至索取數據者的計算機系統上。透過這種數據交換模式，擁有者既可證實自己的身份，亦不用過度披露個人數據，對保障計算機服務訪問雙方皆有好處。
數字證書必須存儲在指定的安全位置中，比如註冊表、本地或遠程計算機、磁盤文件、數據庫、目錄服務、智能設備或其他位置。
二、關於數字證書
在以上幾種鑑權的方式中，認證效力最高、最安全的應該數字證書了。那數字證書是怎麼來的呢？和我們文章標題所說的軟證書和硬 key 又有什麼關係呢？
我從網上找到一張圖來說明數字證書的產生：
用戶向 RA 申請證書；RA 對用戶提交的信息進行核實後向 CA 提出註冊請求。CA建立對於該用戶的註冊，並將註冊建立結果返回給RA。
RA將註冊結果通知用戶，註冊結果中包含了兩組數字，分別稱為“參考號”和“授權碼”。（兩碼）
用戶方的軟件生成一對公鑰和私鑰。用戶向CA提出證書請求，這個請求信息中還包含了用戶的公鑰和用戶的可甄別名等信息，這些信息在CA創建證書時要用到。
CA創建該用戶的數字證書。通過適當方式將證書分發給用戶，適當的方式包括：Out-of-band Distribution帶外分發、In-band distribution帶內分發等多種概念，就不展開了，有興趣的可以私聊。
——（來源：《CFCA 數字證書的存儲和USBKey的安全性》[3]）
數字證書是在PKI體系框架下公鑰的表現形式。那麼數字證書和私鑰到底存儲在哪裡呢？這就引出了我們今天的題目：軟證書和硬 key 。
我們所說的軟證書和硬 key 其實指的是我們數字證書和私鑰存儲在哪裡的問題。
軟證書一般是將文件存放在電腦/移動設備的指定位置裡，比如 Windows 會將數字證書存儲在註冊表（HKLM(HKCC)SoftwareMicrosoftSystemCertificates）和用戶配置文件（%USERPROFILE%Application DataMicrosoftSystemCertificatesMy）中。而對應的私鑰存處在用戶配置文件（計算機：%ALLUSERSPROFILE%Application DataMicrosoftCryptoRSA(DSS)Machine Keys；用戶：%USERPROFILE%Application DataMicrosoftCryptoRSA(DSS)）中。 大家有興趣可以去找找。
而硬 key 則是將私鑰和數字證書導入到設備中。這個設備內置單片機或智能卡芯片，可以存儲用戶的密鑰或數字證書。
這兩種存儲方式只要是安全性的差別：
軟證書是以文件形式保存的，並且可以標記允許再次導出，極易受到木馬等攻擊。另外，軟證書不強制用戶設置證書使用口令，其他人登錄同一臺電腦就可以直接使用。曾經出現過銀行軟證書被攻破的案例，大部分銀行在 2008 年以後逐步取消了軟證書的網上支付功能。
硬證書則是以UKey移動設備為載體，通過 PIN 碼保護 key，且密鑰一旦導入 USB-KEY 中，及不可被導出。（甚至無法刪除，我和 CFCA 的技術支持確認過這件事，除非我使用專用軟件格式化掉這個 Ukey。）
在推薦國標 GB/T 25065-2010 《信息安全技術公鑰基礎設施簽名生成應用程序的安全要求》中也提到安全簽名生成設備 SSCD（用來存放簽名人的電子簽名製作數據，驗證簽名人鑑別數據，使用電子簽名製作數據產生電子簽名）需要是：
- 智能卡
- USB 令牌
- PCMCIA 令牌
- 並應符合國家密碼主管部門的相關要求。
另外，目前第三方電子合同平臺大部分採用的是雲託管證書的方案，祕鑰在雲端存儲，不需要任何介質，只需要通過口令（比如密碼或者短信驗證碼）就可以隨時隨地的進行簽名。（說實話，考慮到頭部公司的技術實力，我覺得這種方案都比軟證書安全，畢竟祕鑰是存在一個有著相應技術能力維護的服務器上，而不是存在一些完全不懂電腦的普通人的電腦裡。）
我們知道基於密碼或短信驗證碼屬於弱身份認證手段，攻擊門檻低，容易發生祕鑰洩露的事件。同時第三方電子合同平臺作為託管方理論上（不考慮內控、法律和道德）在一定利益的驅使下是有條件冒充用戶替客戶簽名的。
從國密局至今只為一家雲託管方案發放了商用密碼產品型號證書來看，這個行業還無法滿足可靠電子簽名的一些條件。（當然我們也應該看到這些第三方電子合同廠商做的努力，通過完善證據鏈來修補可靠數字簽名的瑕疵，不加這句話我是不是會被電子合同廠商的朋友們罵死……）
另外，國密算法證書標註啟用後，國家密碼局強制要求不再提供軟證書哦。（現在很多金融領域已經被監管要求將加密方式轉向國密標準，主要是為了自主可控，這可不是為了什麼特色，而是真的有必要。詳見 NSA 在 RSA 加密算法中安置了後門——RSA BSAFE[4]。）
關於安全性還有個一個例子從側面來印證：某家 CA 廠商（就是你們知道的最牛B 的那個），在一次交流中說我們給我們發的軟證書上了保險，出現意外保XX；給 XX 項目上來保險，出現問題保 XX。
我問說你們的硬件 key 賠多少？小哥回答我說，我們沒上保險，因為ukey 理論上只有可能因為用戶的保管原因造成損失……
三、講完技術講法律
理論上說，數字證書的基本原理是基於非對稱密碼機制的 PKI 體系，這個體系和算法（RSA）都是公開的技術並不複雜。Adobe Acrobat 可以很方便的為你的 PDF 增加簽名。
但是！在我國有一部法律叫做《電子簽名法》（其實包括美國、歐盟等國家和地區都有相關的理髮），估計做互金的小夥伴前段時間會被電子合同服務商的商務同時刷屏一波，對就是最近剛剛修正過的《電子簽名法》。
《電子簽名法》規定對於從事電子認證服務的機構採取「資質許可」的形式來確保 CA 機構的權威、公正和可信賴（《電子簽名法》第十八條）。截止2018年4月22日，在工信部網站上公示的電子認證服務機構一共37家。
數據來源：工信部-數據資料庫-電子認證服務機構設立審批[5]
同時，它還對可靠的電子簽名做出了規定，其中提到：（二）簽署時電子簽名製作數據僅由電子簽名人控制。（《電子簽名法》第十三條）
同時《電子簽名法》第二十八條：電子簽名人或者電子簽名依賴方因依據電子認證服務提供者提供的電子簽名認證服務從事民事活動遭受損失，電子認證服務提供者不能證明自己無過錯的，承擔賠償責任。也就是說，電子認證服務提供者需要承擔的推定過錯責任。
在舉證過程中，電子認證服務者舉證一個 U 盤大小的 key 介質似乎要比舉證數據文件的所有權容易也直觀多了。
另外，還有人一直在和我討論自建 CA 是否有效的問題。比如四大行的 CA 體系（中行除外，他們用的 CFCA 的）。《電子簽名法》第十八條明確指出：從事電子認證服務，應當向國務院信息產業主管部門提出申請……予以許可的，頒發電子認證許可證書……
不過很顯然，他們並沒有工信部的認可。那是不是是不合法的呢？
也不盡然，《電子簽名法》第十三條：當事人也可以選擇使用符合其約定的可靠條件的電子簽名。第十六條：電子簽名需要第三方認證的，由依法設立的電子認證服務提供者提供認證服務。
針對這兩條，我發現不同人的解釋不太一樣，我更傾向於：在雙方認可前提下且不需要第三方認證的，可以使用自建 CA。更像是一種擦邊球行為，因為有人認為自建 CA 只能在自己系統內部，不如小璋 CA 在小璋集團內部作為文件簽署使用，而不能向社會第三方提供服務。不過咱也不知道，咱也不敢問。《電子簽名法》任重而道遠啊。
關於數字簽名及電子合同，我還有一篇文章，有興趣的可以去看看：【小璋的筆記】電子合同是個啥[6]
相關閱讀
[1]《互金產品基礎知識（三）作為 P2P 產品經理，你要知道的融資端風控問題》：http://www.woshipm.com/pmd/696772.html
[2]《給產品經理講技術-Google驗證的原理及應用場景》：http://t.cn/AiN4vEwy
[3]《CFCA 數字證書的存儲和USBKey的安全性》：http://t.cn/AiN4P7rs
[4] RSA BSAFE：http://t.cn/AiN4P7dv
[5] 工信部-數據資料庫-電子認證服務機構設立審批：http://t.cn/RnMdgKm
[6]【小璋的筆記】電子合同是個啥：http://www.woshipm.com/pmd/1036833.html
#專欄作家#
張小璋，公眾號：張小璋的碎碎念（ID：SylvainZhang），人人都是產品經理專欄作家。野蠻生長的產品經理，專注於互聯網金融領域。
本文原創發佈於人人都是產品經理。未經許可，禁止轉載。
題圖來自 Pexels，基於 CC0 協議