数据隐私越来越受关注，一些数据就需要加密存储，但为了业务往来又需要将数据共享给相应人员使用，所以需要设计一套安全方案来解决这一场景问题。
个人思路：
1. 用户A确定一个对称加密key -- Akey；
2. 使用Akey对数据进行加密；
3. 对Akey和需要共享的其他用户做个时效表管理；
4. 需要用户A数据的用户通过时效表获取Akey，从而读取数据。
简单设计.png
这中间其实还有很多细节问题，比如
- 随便在table-1中增加一条数据就可以读取user-A的数据了。
- 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
