开发网站如何选需要,wordpress 数据库ip,外贸企业网站优化,网站怎么做关键词怎么优化阿里妹导读#xff1a;密钥管理是密码学应用的核心问题之一。任何涉及加密/签名的应用#xff0c;无论算法本身机制多么安全#xff0c;最终都会受到灵魂拷问#xff1a;你密钥存在哪儿#xff1f;本文实现了一种安全的密钥管理方案#xff0c;基于安全多方计算技术…
阿里妹导读密钥管理是密码学应用的核心问题之一。任何涉及加密/签名的应用无论算法本身机制多么安全最终都会受到灵魂拷问你密钥存在哪儿本文实现了一种安全的密钥管理方案基于安全多方计算技术避免了客户端、服务器端内存中的密钥泄露风险并已经在阿里集团内的密钥管理系统上线。
背景介绍密钥管理
提问你密钥存在哪儿
对这一问的回答基本可概括为2类
a. 本地加解密密钥保存在某些介质如配置文件、数据库也可以是某个远程服务器中用户在需要进行加密/签名时从这些介质拉取密钥可能拉取的只是密钥密文需要再解密出密钥明文然后本地进行加密/签名。 b. 服务器加解密用户在需要进行加密/签名时把数据请求发给某个服务器服务器代为完成加密/签名工作将加密/签名结果发回用户。 一般的密钥管理系统都可归到这两类模式但是他们都存在各自的问题
前者由于密钥是被拉到了用户本地暴露在用户内存中而用户本机的安全性是无法做任何假设的可能存在各种漏洞/木马等因此密钥面临着各类泄露风险在客户端引入 TEE 可以提升这个安全门槛但是需要配置额外的硬件而且没有100%杜绝泄露风险如侧信道等后者的密钥是完全交给了服务器万一服务器存在漏洞/服务器被入侵/服务器管理员作恶那么用户隐私便在服务器面前一览无余。
可能有些同学觉得这2类风险不够高但是对于高价值数据这些风险是不可忽视的。举个例子假设你是中本聪那么你的比特币创世块地址对应的私钥放哪才能不忘掉同时不泄露呢是不是好像这两种方法都无法满足需求了
基于安全多方计算的密钥管理(MPC KMS)也称门限签名/门限加密即是为了解决这一对矛盾。简而言之MPC KMS 将用户密钥分为 M 份碎片例如 M2密钥是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 ComputationMPC在80年代由姚期智院士提出。安全多方计算协议允许多个数据所有者进行数据协同计算输出计算结果并保证任何一方均无法得到除应得的计算结果之外的其他任何信息。
这里的黑色加粗字体的文字是格外需要注意的不仅仅是无法获取原始数据而是无法获得其他任何信息。以百万富翁问题为例两个百万富翁比谁的钱数更多最后双方获得的唯一信息只能是“大于、等于或小于”只要泄露了任何的其他额外信息譬如对方钱数的最高位是1还是2无论这个额外信息多么少都不能算 MPC。
MPC 还有很多潜在应用场景如基于融合数据的联合风控、联合广告推荐等它能够真正实现“数据可用不可见”在这个数据为王的时代有着美妙的前景。
安全多方计算密钥管理MPC KMS介绍
技术架构
MPC KMS 即是安全多方计算 MPC 的一种特殊场景各方分别持有密钥的一部分协同计算的目的是加解密/签名同时除了加解密/签名结果之外不泄露任何其他信息。
我们研读了多篇最新论文[1,2,3]在这些论文的理论基础之上实现了安全两方 ECDSA 签名系统。系统的粗粒度交互过程如下详细算法可以参阅论文。
1.密钥生成用户发起生成请求两台服务器 A 和 B 分别各自独立的产生随机数 a 和随机数 bab 即是签名时使用的私钥。
2.签名用户首先从 A 服务器拉取 a然后调用 B 的服务把需要签名的消息message 和 message、a 的加密计算结果发送给 B和 B 之间运行一个安全两方签名协议得到最终的签名值。在整个过程中私钥ab没有在任何一方的内存中复原任何一方都无法了解到私钥 ab 的内容。
操作流程
最终系统暴露给用户的是两个接口 getPK() 和 sign()接口以阿里内部常用的HSF(High-speed Service Framework) 方式提供接入非常方便。
Step 1. 用户首先在密钥管理服务器上新建一个密钥后台的两台服务器会自动的产生各自的密钥分量
Step 2.用户调用 getPK() 获取该密钥对应的公钥
Step 3.用户在密钥管理服务器上新建一个 SHA256WithECDSA 类型的公钥选择手工输入输入 Step 2得到的内容
Step 4.用户此后就可以通过 sign() 来调用安全两方签名通过密钥管理服务器提供的ECDSA verifier 函数输入公钥来验证签名的正确性了。
Step 5. 这下安全性超有保障连管理员都得两个服务器的管理员一起码代码才能知道你的私钥到底是啥了
原文链接 本文为云栖社区原创内容未经允许不得转载。
