美文网首页
数据加密共享与签名

数据加密共享与签名

作者: 李孝伟 | 来源:发表于2018-06-14 17:27 被阅读19次

    数据隐私越来越受关注,一些数据就需要加密存储,但为了业务往来又需要将数据共享给相应人员使用,所以需要设计一套安全方案来解决这一场景问题。
    个人思路:

    1. 用户A确定一个对称加密key --  Akey;
    2. 使用Akey对数据进行加密;
    3. 对Akey和需要共享的其他用户做个时效表管理;
    4. 需要用户A数据的用户通过时效表获取Akey,从而读取数据。
    
    简单设计.png

    这中间其实还有很多细节问题,比如

    1. 随便在table-1中增加一条数据就可以读取user-A的数据了。
    2. Akey的存储问题!

    那接下来借鉴下合同数字加密与签名:
    原文:http://www.cnblogs.com/studyzy/p/8824383.html

    以下是整理并增加了原文没有的内容(动态共享数据给用户、增加合同内容补充协议等),当然也可以直接去看原文。
    业务场景:

    1. 电子合同,合同具有保密性,且不可篡改特性;
    2. 数据存证,同样不可篡改,保密性;
    3. 敏感数据共享,机密与不可篡改。
    

    既然要加密就需要认识下密码学:

    1. 对称加密
    明文数据通过密钥加密生成加密文件,再使用同样的密钥对密文解密,常见的算法3des;
    2. 非对称加密
    非对称加密有两个密钥:私钥private-key和公钥public-key,使用私钥加密的数据只能使用公钥解密,使用公钥加密的数据只能使用私钥解密,常见场景就是web的https;常见的算法:RSA,ECC(椭圆曲线加密);区块链fabric中用的就是ecc算法;基于大整数因子分解问题(IFP)的RSA算法和基于椭圆曲线上离散对数计算问题(ECDLP)的ECC算法,ECC计算难度高于RSA,所以ECC安全性要高于RSA;
    3. 哈希
    哈希是一种摘要算法,对任意长度的输入得到的结果长度都是一样的;而且对输入具有敏感性,任何细微的输入改变都会导致结果不一致;当然哈希要解决碰撞问题,即不同的输入有相同的结果;常见的算法md5、sha256;
    

    先说一个典型应用数字签名:

    a. 签名的目的就是为了证明这句话是我说的或这个文件是我签署的;
    b. 数据安全的世界密钥是非常关键的,相当于自己的印章;
    c. 主要是用哈希和非对称加密算法;
    d. 过程:对于一条明文信息M,先对其哈希计算出摘要H(M),然后对摘要H(M)使用私钥进行非对称加密得到签名;私钥是个人私有,但是公钥是公开的,别人得到消息M和签名后,先使用公钥解密出这个H(M) 然后再对消息M进行哈希,对这两个串进行对比,如果一致则可以证实消息M是真实的。
    

    也就是说这三个算法组合可以做很多事情,重点要理解三个算法的特性;
    互联网安全的世界,密钥至关重要!

    电子合同方案:(这里做了小改动)
    场景:

    1. 用户A要与用户B签署一个重要合同,除了中介C外其他人都不能查看;
    2. 用户ABC都有自己的公私钥作为身份的证明,也就是说只有验证身份的人才能看的合同的内容;
    3. 合同签署完后,用户D等也想动态加入,即查看文件内容;
    4. 合同签署完后,有用户C会退出,即无权再查看合同内容;
    5. 合同签署完后,中途增加补充协议;
    

    过程:

    1. 合同加密
    a. 能够还原的算法只有对称加密和非对称加密,但非对称加密特性要么大家都能看到,要么只能自己看到,所以合同只能使用对称加密;
    b. 这里就需要创建一个随机密钥R-Key,对文件进行加密得到密文M。
    c. 然后使用用户A、用户B和用户C的公钥对这个随机密钥R-Key进行加密,得到三分密文:密文A、密文B、密文C;
    d. 这样用户ABC都可以拿自己的私钥解密出随机密钥R-key,然后对数据进行解密查看,其他人则无法解密。
    公开的文件:密文M、密文A、密文B、密文C;
    
    2. 签名合同
    目前为止用户ABC都能用自己的私钥看合同了,也很好做了权限隔离;
    还需要一个步骤保证合同是否是用户A签署的:
    因为合同的密文M是公开的,鉴于数字签名场景,用户A需要对密文M进行数字签名,签名过程见数字签名环节(先取哈希摘要,在对摘要进行非对称加密);得到用户A的数字签名A;
    公开的文件:密文M、密文A、密文B、密文C、数字签名A;
    
    3. 合同解密
    a. 目前公开的数据有:合同密文M、密文A、密文B、密文C、数字签名A;
    b. 用户B首先通过数字签名A和密文M验证合同的真实性;
    c. 用户B使用自己的私钥解密密文B得到随机密钥R-key;
    d. 再使用随机密钥R-key对密文M进行解密得到合同明文。
    
    4. 加签合同
    如果用户B也许签名的话,跟用户A一样,进行一次数字签名就好了,这样又多一个数字签名B公开文件。
    公开的文件:密文M、密文A、密文B、密文C、数字签名A、数字签名B;
    
    5. 合同共享/授权
    a. 用户D也想加入合作,所以数据也要给用户D查看;
    b. 随机密码R-key是不存储的,后续加入的不可能直接拿到R-key
    c. 这就需要有权限的人用自己的私钥解密出R-key,然后再使用用户D的公钥加密生成一个密文D;
    d. 用户D使用密文D和自己的私钥就可以读取合同明文了;
    公开的文件:密文M、密文A、密文B、密文C、密文D、数字签名A、数字签名B;
    
    6. 授权时效管理
    用户查看合同的关键是自己公钥加密的密文,所以对这些密文进行一个有效期管理,就可以解决合作过程中有人退出问题;
    
    7. 合同增加补充协议
    a. 增加补充协议与增加用户类似,不需要重新再整一套密文;
    b. 有权限的用户使用自己的私钥解密出R-key,然后对补充协议进行加密生成补充协议密文N
    c. 用户就可以像查看合同文件一样的方式查看补充协议了。
    公开的文件:密文M、密文A、密文B、密文C、密文D、数字签名A、数字签名B、密文N;
    

    以上就是整个签名过程,公开的数据都是加密的,只有有权限的私钥用户才能查看。

    原文的两个图也比较有意思:

    合同生成.png 合同查看.png合同查看.png

    相关文章

      网友评论

          本文标题:数据加密共享与签名

          本文链接:https://www.haomeiwen.com/subject/hpiyeftx.html