DKMS架构评审文档
目录
1. 文档概述
1.1 项目背景及目标
1.2 名词解释
1.3 文档版本信息
2. 系统架构
2.1 DKMS架构图
2.2 功能模块
3. 性能评估
3.1 加解密SDK性能
3.2 DKMS接口性能
4. 产品形态及未来规划
4.1 产品形态
4.2 未来规划
5. 应用场景
5.1 智能设备与家财险
5.2 个人数据私密分享
5.3 基于三方云存储的数据授权共享
1 文档概述
1.1 项目背景及目标
由于密码学门槛高、客户端重、密钥管理复杂等原因，数据加解密和签名服务对C端用户不具备普适性。通常，与密码学相关的操作在B端进行，对普通用户透明。然而随着用户隐私的发声，现有的安全和加密做法受到质疑。痛点罗列如下：
1.用户的所有数据由企业掌握（如视频、照片、业务数据等）
2.企业用唯一的对称密钥加密数据，存储（此密钥丢失或泄漏，影响所有的数据）
3.密钥不具有容错性（一把密钥决定所有）
4.用户分享数据时，必须基于企业提供的解密和共享服务
5.明文数据容易被篡改，不具备公信力
项目提供一种分布式的密钥管理系统，为每个用户提供唯一的公私钥，使其能够以授权的方式指定可访问者，并具备时效特征。基于非对称的加密方式，其上传的密文绝对安全，不能被任何人静默访问。通过代理重加密，可以实现在不泄漏用户私钥的情况下，授权企业或三方进行解密。
1.2 名词解释
DKMS ( Distributed key manage system) 分布式密钥管理系统
PRE (Proxy re-encryption) 代理重加密，对密文的一种转化方式，用于特定授权访问
SS (Secret sharing) 秘密共享，通常使用Shamir’ SS，实现 (t, n) 门限共享
1.3 文档版本信息
DKMS DOC V1.0 裴新 2019-08-29
2 整体架构
2.1 DKMS架构图
2.2 功能模块
DKMS 核心功能
DKMS 衍生业务功能
3 性能测试
第二次：重加密解密 t, n (1,1) : 第一个参数 ———>[13988, 17138, 12738, 17704, 14367, 13351]
第三次：重加密解密 t, n (1,1) : 第一个参数 ———>[61698, 52675, 52644, 51773, 54663, 66243]
4 产品形态及未来规划
4.1 产品形态
4.1.1 产品形态/部署方式
•DKMS以SaaS模式提供产品服务，支持私有化部署；
•以独立产品形态挂载到Locket上，产品层级与UDPP并行；
•Anlink作为DKMS的用户，私有化部署为底层基件，为Anlink user提供数据加解密服务；
•DKMS提供密钥管理、代理重加密计算、门限分片等服务，不提供文件存储；
•DKMS由SDK + API服务构成，包括：
i. SDK包括jsSDK(页面安全控件、流媒体播放控件等)，pySDK（加密、解密程序，内部调用C++ cryptolib实现ECC和AES）
ii. API服务密钥生成、密钥门限共享、代理重加密、密钥分布式存储及恢复等。
4.1.2 收费模式
Total = 用户量 (X) + 加密参数 (Y) + 计算频次 (Z)
用户量：按实际用户量评定需要生成和管理的密钥对数。
如，100-1000人 1元/人； 1000-5000人 8毛/人； 5000以 6毛/人
X = HC * p
加密参数：密钥的门限分配方案(t, n)， t与每次取数相关，n与存储相关。
Y = HC * rate(t + n)
计算频次: 用户更新密钥、授权操作、代理重加密等。
Z = Calculatetypei * pi
4.2 未来规划
i. 多跳DKMS。目前实现的是单跳DKMS，即，重加密只支持单次。owner不能重加密给B，再重加密给C。（比如，在更新密钥的时候，不能用自身的新密钥重加密完成）
ii. 结合轻客户端加密组件，如TEA（QQ使用的），优化客户端到服务端的数据安全（对于服务端不需要碰明文的场景）
iii. 整合现有安全KMS系统，适配更多应用场景
iv. 使用FPGA提升性能和稳定性
v. 结合IPFS，打包部署私有化安全数据服务
5 应用场景
5.1 智能监控设备与保险取证（家财险）
目前的智能摄像头场景：用户————厂商Server—————摄像头
即，用户所有对摄像头的配置（包括密钥）都经过厂商的Server，且大多是弱密码设置。
采用PRE方案，用户配置自己的公钥，摄像头可以在本地实时加密视频流。用户通过dkms授权进行视频的查看和分享。结合保险公司的家财险，用户可以基于dkms的pre，授权保险公司在一定的时间段内访问取证视频。
5.2 个人数据私密分享
APP端的报告、文档、视频、发票等，以文件形式分享给特定的人或特定的组。
比如，患者控制的电子健康记录（EHR）可以创建患者控制的EHR，患者拥有自己的数据和密钥。而且，数据可以集中存储或分布式存储。当病人想要与医院或保险公司分享他们的加密数据时，他们会发出一个重加密授权密钥，授予第三方临时访问权限。
5.3 基于云存储的工作分档授权分享
白板通过权限设置进行分享，白板的管理员可以更改和查看所有文档及其权限。个人的业务文档写好后，通过自己的公钥加密，上传OSS。
1.自己需要访问时，从OSS上拿密文，利用自己的私钥可以解密，编辑、查看；
2.想分享给同事或同组人时（协同编辑），授权同事或组内成员；