工程師的靈魂拷問:你的密鑰安全嗎?

阿里妹導讀:密鑰管理是密碼學應用的核心問題之一。任何涉及加密/簽名的應用,不管算法自己機制多麼安全,最終都會受到靈魂拷問:你密鑰存在哪兒?本文實現了一種安全的密鑰管理方案,基於安全多方計算技術,避免了客戶端、服務器端內存中的密鑰泄露風險,並已經在阿里集團內的密鑰管理系統上線。算法

背景介紹:密鑰管理

提問:你密鑰存在哪兒?數據庫

對這一問的回答基本可歸納爲2類:安全

a. 本地加解密:密鑰保存在某些介質(如配置文件、數據庫,也能夠是某個遠程服務器)中,用戶在須要進行加密/簽名時,從這些介質拉取密鑰(可能拉取的只是密鑰密文,須要再解密出密鑰明文),而後本地進行加密/簽名。服務器

b. 服務器加解密:用戶在須要進行加密/簽名時,把數據請求發給某個服務器,服務器代爲完成加密/簽名工做,將加密/簽名結果發回用戶。架構

通常的密鑰管理系統均可歸到這兩類模式,可是他們都存在各自的問題:app

  1. 前者因爲密鑰是被拉到了用戶本地,暴露在用戶內存中,而用戶本機的安全性是沒法作任何假設的,可能存在各類漏洞/木馬等,所以密鑰面臨着各種泄露風險;在客戶端引入 TEE 能夠提高這個安全門檻,可是須要配置額外的硬件,並且沒有100%杜絕泄露風險(如側信道等);
  2. 後者的密鑰是徹底交給了服務器,萬一服務器存在漏洞/服務器被入侵/服務器管理員做惡,那麼用戶隱私便在服務器面前盡收眼底。

可能有些同窗以爲這2類風險不夠高,可是對於高價值數據,這些風險是不可忽視的。舉個例子,假設你是中本聰,那麼你的比特幣創世塊地址對應的私鑰放哪才能不忘掉,同時不泄露呢?是否是好像這兩種方法都沒法知足需求了?函數

基於安全多方計算的密鑰管理(MPC KMS),也稱門限簽名/門限加密,便是爲了解決這一對矛盾。簡而言之,MPC KMS 將用戶密鑰分爲 M 份"碎片"(例如 M=2,密鑰是100,能夠拆成兩份30和70),存儲在 M 個不一樣的服務器中(例如一份存在A雲服務商,一份存在B雲服務商),任何一個服務器都沒法獨立根據本身的"碎片"恢復出用戶密鑰原文。當用戶須要進行加密/簽名時,則在這 M 個服務器之間運行一個 MPC 協議,產生加密/簽名的結果,且整個過程當中不須要復原用戶密鑰。區塊鏈

若是最少只須要 n 個服務器參與便可完成協議,則稱之爲 n of M 的門限簽名/加密。字體

可見,在 MPC KMS 中,上述兩種風險都可以獲得有效的規避:首先,用戶本地環境的安全問題不會致使密鑰泄露;其次,即便某個服務器出問題,攻擊者也沒法獲得用戶的密鑰,必須同時攻陷 n 個服務器,或是 n 個服務器管理員一塊兒合謀(若是咱們把服務器部署在多個獨立的雲服務系統上,這種同時出問題的機率幾乎能夠忽略)。加密

MPC KMS 這種去中心化密鑰管理的特色和區塊鏈的共識機制具備很是好的兼容性:除了直接用於保管用戶私鑰、節點密鑰以外,用戶還能夠把私鑰託管分紅 M 片,託管在區塊鏈的 M 個節點,而後設定僅當知足必定門限的節點(例如1/4的節點)產生共識時才能動用他的某筆數字貨幣財產;或是設定某個軟件包的發佈必須通過必定門限的節點簽名等等。

安全多方計算 MPC 介紹

安全多方計算( Secure Multi-Party Computation,MPC)在80年代由姚期智院士提出。安全多方計算協議容許多個數據全部者進行數據協同計算,輸出計算結果,並保證任何一方均沒法獲得除應得的計算結果以外的其餘任何信息

這裏的黑色加粗字體的文字是格外須要注意的:不只僅是沒法獲取原始數據,而是沒法得到其餘任何信息。以百萬富翁問題爲例:兩個百萬富翁比誰的錢數更多,最後雙方得到的惟一信息只能是「大於、等於或小於」;只要泄露了任何的其餘額外信息(譬如對方錢數的最高位是1仍是2),不管這個額外信息多麼少,都不能算 MPC。

MPC 還有不少潛在應用場景,如基於融合數據的聯合風控、聯合廣告推薦等,它可以真正實現「數據可用不可見」,在這個數據爲王的時代有着美妙的前景。

安全多方計算+密鑰管理MPC KMS介紹

技術架構

MPC KMS 便是安全多方計算 MPC 的一種特殊場景:各方分別持有密鑰的一部分,協同計算的目的是加解密/簽名,同時除了加解密/簽名結果以外,不泄露任何其餘信息。

咱們研讀了多篇最新論文[1,2,3],在這些論文的理論基礎之上,實現了安全兩方 ECDSA 簽名系統。系統的粗粒度交互過程以下,詳細算法能夠參閱論文。

1.密鑰生成:用戶發起生成請求,兩臺服務器 A 和 B 分別各自獨立的產生隨機數 a 和隨機數 b,a+b 便是簽名時使用的私鑰。

2.簽名:用戶首先從 A 服務器拉取 a,而後調用 B 的服務,把須要簽名的消息message 和 message、a 的加密計算結果發送給 B,和 B 之間運行一個安全兩方簽名協議,獲得最終的簽名值。在整個過程當中,私鑰a+b沒有在任何一方的內存中復原,任何一方都沒法瞭解到私鑰 a+b 的內容。

操做流程

最終系統暴露給用戶的是兩個接口 getPK() 和 sign(),接口以阿里內部經常使用的HSF(High-speed Service Framework) 方式提供,接入很是方便。

Step 1. 用戶首先在密鑰管理服務器上新建一個密鑰,後臺的兩臺服務器會自動的產生各自的密鑰份量;

Step 2.用戶調用 getPK() 獲取該密鑰對應的公鑰;

Step 3.用戶在密鑰管理服務器上新建一個 SHA256WithECDSA 類型的公鑰,選擇手工輸入,輸入 Step 2獲得的內容;

Step 4.用戶此後就能夠經過 sign() 來調用安全兩方簽名,經過密鑰管理服務器提供的ECDSA verifier 函數,輸入公鑰來驗證簽名的正確性了。

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.



本文做者:鴻程

閱讀原文

本文來自雲棲社區合做夥伴「阿里技術」,如需轉載請聯繫原做者。

相關文章
相關標籤/搜索