阿里妹导读：密钥管理是密码学应用的核心问题之一。任何涉及加密/签名的应用，无论算法本身机制多么安全，最终都会受到灵魂拷问：你密钥存在哪儿？本文实现了一种安全的密钥管理方案，基于安全多方计算技术，避免了客户端、服务器端内存中的密钥泄露风险，并已经在阿里集团内的密钥管理系统上线。

背景介绍：密钥管理

提问：你密钥存在哪儿？

对这一问的回答基本可概括为2类：

a. 本地加解密：密钥保存在某些介质（如配置文件、数据库，也可以是某个远程服务器）中，用户在需要进行加密/签名时，从这些介质拉取密钥（可能拉取的只是密钥密文，需要再解密出密钥明文），然后本地进行加密/签名。

b. 服务器加解密：用户在需要进行加密/签名时，把数据请求发给某个服务器，服务器代为完成加密/签名工作，将加密/签名结果发回用户。

一般的密钥管理系统都可归到这两类模式，但是他们都存在各自的问题：

前者由于密钥是被拉到了用户本地，暴露在用户内存中，而用户本机的安全性是无法做任何假设的，可能存在各种漏洞/木马等，因此密钥面临着各类泄露风险；在客户端引入 TEE 可以提升这个安全门槛，但是需要配置额外的硬件，而且没有100%杜绝泄露风险（如侧信道等）；
后者的密钥是完全交给了服务器，万一服务器存在漏洞/服务器被入侵/服务器管理员作恶，那么用户隐私便在服务器面前一览无余。

可能有些同学觉得这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. 这下安全性超有保障，连管理员都得两个服务器的管理员一起码代码才能知道你的私钥到底是啥了！

原文链接
本文为云栖社区原创内容，未经允许不得转载。

工程师的灵魂拷问：你的密钥安全吗？相关推荐

人工智能工程师需具备的技能_2020年软件测试工程师需要具备的技能--需要学什么--面试题有哪些（灵魂拷问）...
一.2020年软件测试行业的现状 2020年开年,一不小心,[新冠]黑天鹅从头上飘过,持续影响全国乃至全球的经济,软件行业公司也迎来了不少的冲击,那么一直打算入行软件测试行业,或者已经在软件测试行业耕 ...
算法工程师如何应对业务方和老板的灵魂拷问？
文章作者:姚凯飞编辑整理:Hoh 内容来源:作者授权出品平台:DataFunTalk 导读:你是否有过来自用户.业务和老板们的 badcase "灵魂拷问": 我运营的首页频道 ...
灵魂拷问：你看过Xgboost原文吗？
Datawhale 作者:小雨姑娘,Datawhale成员事情的源头是这样的,某日我分享了一篇阿里机器学习工程师面试失败经历,其中提到了我回答关于Xgboost的部分,评论区的老哥就开始了灵魂拷问: ...
灵魂拷问：Java的可变参数究竟是怎么一回事？
这是 Java 极客技术的第 276 篇原创文章在逛 programcreek 的时候,我发现了一些专注基础但不容忽视的主题.比如说:Java 的可变参数究竟是怎么一回事?像这类灵魂拷问的主题,非常 ...
【面试利器】原生JS灵魂拷问，你能答上多少(一)
前言目前的前端世界,三大框架横行,原生JavaScript所用越来越少.但我认为JavaScript作为每一个前端工程师的立身之本,学再多遍都不为过. 因此我决定整理JavaScript中容易忽视或 ...
Java面试系列之并发编程专题-Java线程池灵魂拷问
金三银四跳槽季即将来临,想必有些猿友已经蠢蠢欲动在做相关的准备了!在接下来的日子里,笔者将坚持写作.分享Java工程师在面试求职期间的方方面面,包括简历制作.面试场景复现.面试题解答.谈薪技巧以及 ...
TCP 协议面试灵魂拷问，可以参考！！！
TCP 协议面试灵魂拷问 001. 能不能说一说 TCP 和 UDP 的区别? 002: 说说 TCP 三次握手的过程?为什 ...
github 吐血整理：如何应对 HR 的灵魂拷问？
本文首发于小程序:编程面试题库 ,转载请保留出处. 最近趁着有时间,整理了一下关于 HR 的灵魂拷问系列,并新建了一个 github 仓库,欢迎持续关注.本文为节选部分内容,点击阅读原文可直达项目. ...
旷视唐文斌：你到底给谁创造了什么样的价值？AI产品灵魂拷问
落地,是2019年AI行业的共同话题,创造价值.降本增效,成为行业共识. 作为AI头雁公司.也即将成为AI创业第一股的旷视,又是怎样看待落地这个话题的? 而作为一位技术领袖,旷视联合创始人兼CTO唐文 ...

工程师的灵魂拷问：你的密钥安全吗？

背景介绍：密钥管理

安全多方计算 MPC 介绍

安全多方计算+密钥管理MPC KMS介绍

工程师的灵魂拷问：你的密钥安全吗？相关推荐

最新文章

热门文章