工程師的靈魂拷問：你的密鑰安全嗎？
密鑰管理是密碼學應用的核心問題之一。任何涉及加密/簽名的應用，無論算法本身機制多么安全，最終都會受到靈魂拷問：你密鑰存在哪兒?本文實現(xiàn)了一種安全的密鑰管理方案，基于安全多方計算技術，避免了客戶端、服務器端內存中的密鑰泄露風險，并已經(jīng)在阿里集團內的密鑰管理系統(tǒng)上線。
背景介紹：密鑰管理
提問：你密鑰存在哪兒?
對這一問的回答基本可概括為2類：
a. 本地加解密：密鑰保存在某些介質(如配置文件、數(shù)據(jù)庫，也可以是某個遠程服務器)中，用戶在需要進行加密/簽名時，從這些介質拉取密鑰(可能拉取的只是密鑰密文，需要再解密出密鑰明文)，然后本地進行加密/簽名。
b. 服務器加解密：用戶在需要進行加密/簽名時，把數(shù)據(jù)請求發(fā)給某個服務器，服務器代為完成加密/簽名工作，將加密/簽名結果發(fā)回用戶。
一般的密鑰管理系統(tǒng)都可歸到這兩類模式，但是他們都存在各自的問題：
1. 前者由于密鑰是被拉到了用戶本地，暴露在用戶內存中，而用戶本機的安全性是無法做任何假設的，可能存在各種漏洞/木馬等，因此密鑰面臨著各類泄露風險;在客戶端引入 TEE 可以提升這個安全門檻，但是需要配置額外的硬件，而且沒有100%杜絕泄露風險(如側信道等);
2. 后者的密鑰是完全交給了服務器，萬一服務器存在漏洞/服務器被入侵/服務器管理員作惡，那么用戶隱私便在服務器面前一覽無余。
可能有些同學覺得這2類風險不夠高，但是對于高價值數(shù)據(jù)，這些風險是不可忽視的。舉個例子，假設你是中本聰，那么你的比特幣創(chuàng)世塊地址對應的私鑰放哪才能不忘掉，同時不泄露呢?是不是好像這兩種方法都無法滿足需求了?
基于安全多方計算的密鑰管理(MPC KMS)，也稱門限簽名/門限加密，即是為了解決這一對矛盾。簡而言之，MPC KMS 將用戶密鑰分為 M 份"碎片"(例如 M=2，密鑰是100，可以拆成兩份30和70)，存儲在 M 個不同的服務器中(例如一份存在A云服務商，一份存在B云服務商)，任何一個服務器都無法獨立根據(jù)自己的"碎片"恢復出用戶密鑰原文。當用戶需要進行加密/簽名時，則在這 M 個服務器之間運行一個 MPC 協(xié)議，產(chǎn)生加密/簽名的結果，且整個過程中不需要復原用戶密鑰。
如果最少只需要 n 個服務器參與即可完成協(xié)議，則稱之為 n of M 的門限簽名/加密。
可見，在 MPC KMS 中，上述兩種風險均可以得到有效的規(guī)避：首先，用戶本地環(huán)境的安全問題不會導致密鑰泄露;其次，即使某個服務器出問題，攻擊者也無法得到用戶的密鑰，必須同時攻陷 n 個服務器，或是 n 個服務器管理員一起合謀(如果我們把服務器部署在多個獨立的云服務系統(tǒng)上，這種同時出問題的概率幾乎可以忽略)。
MPC KMS 這種去中心化密鑰管理的特點和區(qū)塊鏈的共識機制具有非常好的兼容性：除了直接用于保管用戶私鑰、節(jié)點密鑰之外，用戶還可以把私鑰托管分成 M 片，托管在區(qū)塊鏈的 M 個節(jié)點，然后設定僅當滿足一定門限的節(jié)點(例如1/4的節(jié)點)產(chǎn)生共識時才能動用他的某筆數(shù)字貨幣財產(chǎn);或是設定某個軟件包的發(fā)布必須經(jīng)過一定門限的節(jié)點簽名等等。
安全多方計算 MPC 介紹
安全多方計算( Secure Multi-Party Computation，MPC)在80年代由姚期智院士提出。安全多方計算協(xié)議允許多個數(shù)據(jù)所有者進行數(shù)據(jù)協(xié)同計算，輸出計算結果，并保證任何一方均無法得到除應得的計算結果之外的其他任何信息。
這里的黑色加粗字體的文字是格外需要注意的：不僅僅是無法獲取原始數(shù)據(jù)，而是無法獲得其他任何信息。以百萬富翁問題為例：兩個百萬富翁比誰的錢數(shù)更多，最后雙方獲得的唯一信息只能是“大于、等于或小于”;只要泄露了任何的其他額外信息(譬如對方錢數(shù)的最高位是1還是2)，無論這個額外信息多么少，都不能算 MPC。
MPC 還有很多潛在應用場景，如基于融合數(shù)據(jù)的聯(lián)合風控、聯(lián)合廣告推薦等，它能夠真正實現(xiàn)“數(shù)據(jù)可用不可見”，在這個數(shù)據(jù)為王的時代有著美妙的前景。
安全多方計算+密鑰管理MPC KMS介紹
技術架構
MPC KMS 即是安全多方計算 MPC 的一種特殊場景：各方分別持有密鑰的一部分，協(xié)同計算的目的是加解密/簽名，同時除了加解密/簽名結果之外，不泄露任何其他信息。
我們研讀了多篇最新論文[1,2,3]，在這些論文的理論基礎之上，實現(xiàn)了安全兩方 ECDSA 簽名系統(tǒng)。系統(tǒng)的粗粒度交互過程如下，詳細算法可以參閱論文。
1.密鑰生成：用戶發(fā)起生成請求，兩臺服務器 A 和 B 分別各自獨立的產(chǎn)生隨機數(shù) a 和隨機數(shù) b，a+b 即是簽名時使用的私鑰。
2.簽名：用戶首先從 A 服務器拉取 a，然后調用 B 的服務，把需要簽名的消息message 和 message、a 的加密計算結果發(fā)送給 B，和 B 之間運行一個安全兩方簽名協(xié)議，得到最終的簽名值
。在整個過程中，私鑰a+b沒有在任何一方的內存中復原，任何一方都無法了解到私鑰 a+b 的內容。
操作流程
最終系統(tǒng)暴露給用戶的是兩個接口 getPK() 和 sign()，接口以阿里內部常用的HSF(High-speed Service Framework) 方式提供，接入非常方便。
Step 1. 用戶首先在密鑰管理服務器上新建一個密鑰，后臺的兩臺服務器會自動的產(chǎn)生各自的密鑰分量;
Step 2.用戶調用 getPK() 獲取該密鑰對應的公鑰;
Step 3.用戶在密鑰管理服務器上新建一個 SHA256WithECDSA 類型的公鑰，選擇手工輸入，輸入 Step 2得到的內容;
Step 4.用戶此后就可以通過 sign() 來調用安全兩方簽名，通過密鑰管理服務器提供的ECDSA verifier 函數(shù)，輸入公鑰來驗證簽名的正確性了。
Step 5. 這下安全性超有保障，連管理員都得兩個服務器的管理員一起碼代碼才能知道你的私鑰到底是啥了!
參考文獻：
[1] Lindell Y. Fast secure two-party ECDSA signing[C]//Annual International Cryptology Conference (CRYPTO). Springer, Cham, 2017: 613-644.
[2] Doerner J, Kondi Y, Lee E, et al. Secure Two-party Threshold ECDSA from ECDSA Assumptions[C]//2018 IEEE Symposium on Security and Privacy (SP). IEEE, 2018: 980-997.
[3] Lindell Y, Nof A. Fast secure multiparty ecdsa with practical distributed key generation and applications to cryptocurrency custody[C]//Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security (CCS). ACM, 2018: 1837-1854.
【本文為51CTO專欄作者“阿里巴巴官方技術”原創(chuàng)稿件，轉載請聯(lián)系原作者】
