请选择 进入手机版 | 继续访问电脑版

比特币论坛-人人比特币中国官方网站-比特币论坛-bitcoin-btc

QQ登录

只需一步,快速开始

查看: 1607|回复: 1

分片重加密实现区块链可分享型隐私

[复制链接]

Rank: 1

该用户从未签到

Rank: 1

19

主题

19

帖子

8

积分

新手上路

积分
8
发表于 2020-5-18 08:46:39 | 显示全部楼层 |阅读模式


复杂美南京研发部彭军

1. 现状

我们习惯把数据都存储在各种云服务器上,带来方便的同时也存在很多数据隐私泄露的隐患,绝大多数的云服务供应商并不完全值得信任,他们完全可以在未经用户允许的情况下擅自泄露用户的数据,用户甚至毫不知情。

解决这个问题最直接的方法是存储之前将隐私数据加密,只要保管好加密密钥不泄露,就不会存在问题。然而这种情况下,数据也只能由用户自己通过私钥解密,如果需要共享数据给其他用户的话,就只能在可信的环境将密钥也共享,这就给数据分享带来了很大的风险。所以还需要一个更好的解决方案,在不暴露私钥的同时能将加密数据共享给特定用户,且该用户在没有密钥的情况也能解密。代理重加密就解决了这个问题。

2. 基本概念

代理重加密(Proxy Re-Encryption, PRE)是一种密钥转换算法,可以将数据所有人(owner)公钥加密的密文可以被转换为另一种密文,被转换后的密文可以由被授权人(recipient)的私钥进行解密。密文转换过程由一个半可信的代理服务器(proxy)执行,在执行该过程前,代理节点需要持有一个由授权人到被授权人的转换密钥,一般授权人提前生成并发送给代理节点。通过转换密钥无法直接解析密文,最终还需要被授权人的私钥才能解密,所以代理节点没办法获取到明文信息。

3. 算法流程

假设Alice要通过代理重加密节点给Bob共享数据,Alice作为sender,Bob作为Receiver

3.1数据加密

  • Alice生成一个随机数dek,作为对称加密密钥:dek = random
  • 使用对称加密密钥dek加密待分享的数据d:c = encryptSym(dek, d)
  • 使用Alice的非对称公钥加密对称加密密钥dek:edek = encryptPke(pkA, dek)
  • 加密数据c+加密的密钥edek上传到云服务器

3.2 重加密密钥

  • Alice使用自己的私钥和Bob的公钥为Bob生成对应的重加密密钥:re = reKey(skA, pkB)
  • 将重加密密钥分发到重加密节点

3.3 数据解密

  • Bob在云服务器下载加密数据c+加密的密钥edek
  • 向重加密节点申请重加密
  • 重加密节点密钥转换:edek'=reEncrypt(reS->R, edek)
  • 使用Bob私钥解密对称密钥:dek=decryptPke(skB, edek')
  • 使用对称加密密钥解密数据:d=decryptSym(dek, c)

4. 密钥分片

代理重加密节点虽然无法通过转换密钥解析密文,但也可能会出现由于故障,宕机,网络连接等问题导致被授权人解密失败,或者可能出现代理节点作恶,不转换或者错误转换,同样会导致被授权人解密失败。Shamir门限密钥共享方案正好解决这个问题。

Shamir门限密钥共享方案也称为(k,n)门限密钥共享方案,假设有n个成员,算法把密钥拆分成n个密钥分片,只有收集大于等于k个分片才能将原始的密钥重构,k就是门限值(k < n)。

数据所有人将转换密钥使用Shamir门限密钥共享方案拆分成n个密钥分片,分别发送给n个代理重加密节点。被授权人需要向至少k个节点申请密钥转换,然后再使用Shamir门限密钥共享方案重构转换密钥。

被授权人只需要申请k个密钥分片就可以解密,降低了单个节点异常的风险,也降低了节点作恶的成功率。

5. 代理重加密和传统DH加密的区别

区别一

传统的DH加密原理是发送方和接受方选择独自的随机数,经过一定计算之后交换计算结果,然后双方生成同样的数作为对称加密共享密钥。

DH加密结合云服务器存储也能解决隐私数据上链的问题,在共享用户数量,加密文件和密钥稳定性不变的时候,两者区别不大,重加密甚至复杂度会相对高一点。

在共享用户数量不定,加密文件数量不定,或者对称密钥频繁更新的场景,DH加密会增加客户端的加密工作量,而代理重加密则把这部分工作转化为重加密转移到云服务器完成。

区别二

传统加密方式没有密钥管理,一次分享之后除非更换对称加密密钥,否则被分享人一直具有解密权限

代理重加密有密钥管理机制,分享者可以通过重加密节点可以对分享用户的访问时限和权限做控制

6. 代理重加密和区块链

代理重加密节点相对比较中心化,如果使用在不信任的去中心化的场景中,就需要考虑到节点作恶的风险,即使使用密钥分片到多个节点也只能降低节点作恶的可能性,节点还是有可能会联合作恶。使用区块链智能合约来管理节点,可以使用相应的奖惩措施来惩罚作恶的节点。同时,区块链也可以存储隐私数据的哈希,以确保云端存储的数据的一致性。

  • 节点成为代理节点之前需要在区块链质押一定的代币,才能注册成为节点;代币在节点取消注册后解冻,在节点作恶时会被扣除一定的代币
  • 节点通过正常的密钥转换赚取一定的酬劳
  • 被委托人如果通过节点申请重加密之后解密失败,可以通过智能合约校验是否为节点作恶,如果是则对作恶节点扣除一定的代币作为惩罚

7. 总结

  • 代理重加密解决了隐私数据的加密和无交互共享,以及共享权限管理
  • 密钥分片降低了代理节点作恶和宕机导致的解密失败的风险
  • 代理重加密结合区块链智能合约可以使用在不信任的去中心化网络中

8. 应用案例

现实生活中的医疗健康数据针对于个人来说属于隐私数据,比如病例信息,体检结果等,这些信息一般存储在医疗机构的数据库中,用户并没有自身医疗健康数据的所有权,机构可以将数据共享给一些其他的研究机构,医药公司等等,完全泄露了用户的个人隐私。

结合区块链+代理重加密,用户的个人健康数据可以加密存储在区块链或者是云服务器上,也可以是医疗机构的服务器上,密钥由用户自己保管。如果有其他研究机构或者医药公司需要收集用户的健康数据,用户可以通过评估之后,使用代理重加密共享给对应的机构和公司,并获取一定的酬劳。通过区块链+代理重加密的解决方案,用户自己的医疗健康数据的所有权在自己手中,且由于是加密存储,也无需担心泄露个人隐私,并且区块链不可篡改的特性,同时也能保证数据的真实性。

参考:

[1]

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有帐号?立即注册

x

帖子的最近访客

楼主热帖



上一篇:比特币第三次减半 牛市还在后头?
下一篇:创链(CCM)基于区块链技术的社交数字经济孵化Dapp平台 ...
回复

使用道具 举报

Rank: 1

  • TA的每日心情
    开心
    2020-5-18 09:12
  • 签到天数: 1 天

    [LV.1]初来乍到

    28

    主题

    53

    帖子

    -1832

    积分

    限制会员

    积分
    -1832
    发表于 2020-5-18 10:01:37 | 显示全部楼层

    导读:鞠婧祎同框郭敬明,一个是159,一个是155,4厘米差距却不大!

    今天小编给你们说的这两位艺人,相信大家都不陌生,一位是四千年美女鞠婧祎,一位是知名作家郭敬明,我们先说说鞠婧祎吧,无论是在S僧伽吒经快念网NH4楞严咒拼音全文8团体里,还是毕业之后,鞠婧祎的人气都弥勒佛心咒全文网是很高的,无论是唱歌还是演戏,鞠婧祎都可以,真是全能的小姐姐啊。

    鞠婧祎有着“四千年美女”之称,曾与于朦胧合作了《新白娘子传奇》,要知道这可是一部经典之作,两位新人再次演绎白素贞与许仙,可以说是很大的挑战了,不过即使是出道没多久的新人,两人的表现也没让观众失望,演技颜值都在线。

    我们再说说另一位,相信不少人都看过郭敬明的书吧,从《夏至未至》到《幻城》,无论是电视剧还是小说,热度都是非常高普门品解说网的,郭敬明作为一名优秀了凡四训是佛经吗 的作家佛经十小咒,从写书拍电影到开公司,人生简直像开了挂似的,商业头脑十分了得。

    无论是鞠婧祎还是郭敬明,两人的身高,一直是大家讨论的点,作为男性的郭敬明,官方身高是155厘米,其实这在女生里面,个子也算是偏矮的了,更何况是男性了,不过身高这种东西是不可逆的,爸妈给的也没办法,虽然个子不高,但郭敬明的气场很足,无论是上节目还是出席活动,郭敬明都能很好的hold住场面,让许多人对他刮目相看。

    而小鞠的官方身高是159,其实这地藏经常识:可以躺着听地藏经吗个身高,作为楞严咒梵文网女生完全是够了,曾经鞠婧祎就与郭敬明同框过,当时的小鞠还穿着消灾吉祥神咒注音增高鞋,不过两人站在一起却好像差不多,虽然两人身高都不高,但毕竟相差4厘米,站在一起还是很明显的,不过从这张照片看,这4厘米的差距好像没表现出来,你们觉得是哪里出了问题?

    回复 支持 反对

    使用道具 举报

    guest
    welcomelogin
    您需要登录后才可以回帖 登录 | 立即注册

    本版积分规则

    关闭Powered by ©科大讯飞语音云

    QQ|关于我们|Archiver|手机版|小黑屋| 比特币论坛-人人比特币中国官方网站-比特币论坛比特币论坛-比特币8818中国官方网站-比特币论坛-bitcoin-btc  |网站地图   

    GMT+8, 2020-5-26 15:21 , Processed in 0.355109 second(s), 72 queries .

    快速回复 返回顶部 返回列表