基于国密算法的秘密文件的加、解密方法及保护系统

1.本发明涉及数据保护技术领域，特别是涉及一种基于国密算法的秘密文件的加、解密方法及自主可控保护系统。


背景技术：

2.随着电子商务的不断推行，涉及隐私信息的秘密文件如电子合同，也需要通过电子信息系统进行传输、存储和管理。但是合同作为具有法律效力的文本，往往承载着大量的隐私信息，如劳动合同中包含有劳动者的姓名、住址和居民身份证或者其他有效身份证件号码，以及工作内容等日常生活信息，合同的内容一旦被非法访问，隐私信息也将随之泄漏。对于保密的商业合同，其中还可能包含公司的商业机密，并且承载着大量的现金流，对于合同内容的保密性要求更高。因此，必须保证用户上传的合同内容、合同处理结果、合同相关人员身份信息，不得以任何形式被除合约涉及人员及授权管理员外的其他用户访问。基于此，亟需一种能够对秘密文件进行加密和访问控制的技术。


技术实现要素：

3.本发明的目的是提供一种基于国密算法的秘密文件的加、解密方法及保护系统，能够对秘密文件进行加密和访问控制，避免用户上传的秘密文件被不具有访问权限的用户访问。
4.为实现上述目的，本发明提供了如下方案：
5.一种基于国密算法的秘密文件的加密方法，所述加密方法包括：
6.获取第一用户上传的秘密文件和所述第一用户生成的重加密密钥；所述重加密密钥根据所述第一用户的私钥和有权限查阅所述秘密文件的所有第二用户的公钥生成；
7.利用sm4算法对所述秘密文件进行加密，得到第一密文；利用所述第一用户的公钥对所述sm4算法在对所述秘密文件进行加密时所用的sm4密钥进行加密，得到第二密文；对所述重加密密钥和所述第二密文进行代理重加密运算，得到第三密文；所述第一密文和所述第三密文组成重加密密文；
8.将所述重加密密文进行存储。
9.一种基于国密算法的秘密文件的解密方法，所述解密方法包括：
10.判断提出查阅请求的第三用户是否属于有权限查阅秘密文件的第二用户；
11.若是，则获取所述第三用户生成的对称密钥；所述对称密钥利用所述第三用户的私钥对重加密密文中的第三密文进行解密所得到；
12.利用所述对称密钥对所述重加密密文中的第一密文进行解密，得到所述秘密文件。
13.一种基于国密算法的秘密文件的保护系统，所述保护系统包括：准入模块、查询模块、密钥传输模块、sm4加解密模块和分布式数据库；
14.所述准入模块用于验证用户的权限；当用户具有权限时，允许用户进行秘密文件
的上传和查阅；
15.所述查询模块用于接收用户输入的查阅请求，并向用户返回所述秘密文件；
16.所述密钥传输模块用于生成每一用户的公私钥对；
17.所述sm4加解密模块用于对用户上传的秘密文件进行加密，得到重加密密文；还用于对所述重加密密文进行解密，得到原始的秘密文件；
18.所述分布式数据库用于存储所述重加密密文。
19.根据本发明提供的具体实施例，本发明公开了以下技术效果：
20.本发明用于提供一种基于国密算法的秘密文件的加、解密方法及保护系统，获取第一用户上传的秘密文件和重加密密钥，利用sm4算法对秘密文件进行加密，得到第一密文，利用第一用户的公钥对sm4算法在对秘密文件进行加密时所用的sm4密钥进行加密，得到第二密文，对重加密密钥和第二密文进行代理重加密运算，得到第三密文，第一密文和第三密文组成重加密密文进行存储，利用具有查阅权限的用户的公钥参与加密过程，保证只有具有查阅权限的用户可以进行秘密文件的查阅和调用，大大提高了秘密文件的安全性。同时，仅对sm4密钥进行代理重加密，能够提高加密速度，同时达到与对秘密文件进行代理重加密的相同的效果。
附图说明
21.为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
22.图1为本发明实施例1所提供的加密方法的方法流程图；
23.图2为本发明实施例1所提供的用户加入组织的审核流程示意图；
24.图3为本发明实施例1所提供的三级管理体系的示意图；
25.图4为本发明实施例1所提供的代理重加密算法的示意图；
26.图5为本发明实施例2所提供的解密方法的方法流程图；
27.图6为本发明实施例3所提供的保护系统的整体结构示意图；
28.图7为本发明实施例3所提供的数据传输与链上同步示意图；
29.图8为本发明实施例3所提供的文件上传的模块流转图；
30.图9为本发明实施例3所提供的文件读取的模块流转图；
31.图10为本发明实施例3所提供的签名过程的模块流转图。
具体实施方式
32.下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
33.本发明的目的是提供一种基于国密算法的秘密文件的加、解密方法及保护系统，能够对秘密文件进行加密和访问控制，避免用户上传的秘密文件被不具有访问权限的用户
访问。
34.为使本发明的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本发明作进一步详细的说明。
35.实施例1：
36.本实施例用于提供一种基于国密算法的秘密文件的加密方法，如图1所示，所述加密方法包括：
37.s1：获取第一用户上传的秘密文件和所述第一用户生成的重加密密钥；所述重加密密钥根据所述第一用户的私钥和有权限查阅所述秘密文件的所有第二用户的公钥生成；
38.本实施例还可对第一用户的权限进行验证，判断第一用户是否具有上传秘密文件的权限，则在s1之前，本实施例的加密方法还包括：获取第一用户输入的第一登录信息，第一登录信息包括第一用户的账号和密码；判断第一登录信息是否正确；若正确，则第一用户登录成功，根据第一登录信息确定第一用户是否具有上传秘密文件的权限；若有，则获取第一用户上传的秘密文件；若没有，则不允许第一用户上传秘密文件。
39.为了能够完成根据第一登录信息确定第一用户是否具有上传秘密文件的权限的功能，本实施例给出了一种优选的实现方式，在根据第一登录信息确定第一用户是否具有上传秘密文件的权限之前，本实施例的加密方法还包括：在第一用户完成注册，以获得第一登录信息后，对第一用户提出的加入组织的申请进行审核，并在审核通过后，生成第一用户的第一用户信息，将第一登录信息和第一用户信息进行对应，以根据第一登录信息获取第一用户信息，进一步根据第一用户信息确定第一用户是否具有上传秘密文件的权限。需要说明的是，注册可用现有的注册过程，第一用户可通过手机号等方式进行注册。
40.其中，如图2所示，对第一用户提出的加入组织的申请进行审核，并在审核通过后，生成第一用户的第一用户信息可以包括：
41.(1)利用ca私钥和sm2签名算法对第一用户的员工id、所申请部门和员工角色信息进行签名，得到授权码，并将授权码发送至第一用户，员工角色信息包括第一用户的用户类型和所具有的权限。如图3所示，用户类型包括普通用户、普通管理员和组织管理员。
42.(2)获取第一用户输入的所要加入组织的组织id和授权码；
43.每一个授权码是唯一的，使用后即作废。
44.(3)利用ca公钥和sm2验证算法对授权码进行验证；若验证通过，则由第一用户的高一级用户节点进行审核；若审核通过，则第一用户加入组织，并生成第一用户的第一用户信息；若第一用户为普通用户，则其高一级用户节点为普通管理员；若第一用户为普通管理员，则其高一级用户节点为组织管理员；若第一用户为组织管理员，则其高一级用户节点为超级管理员；第一用户信息包括员工id、加入组织时间、审核人、所属部门和员工角色信息。
45.具体的，利用ca公钥和sm2验证算法对授权码进行验证可以包括：使用ca公钥和sm2验证算法对授权码进行解签，得到第一用户的员工id、所申请部门和员工角色信息，将解签得到的第一用户的员工id、所申请部门和员工角色信息与签名所用的第一用户的员工id、所申请部门和员工角色信息进行对比，若完全相同，则输入的授权码正确，验证通过，将第一用户提出的加入组织的申请上传至第一用户的高一级用户节点；否则，则输入的授权码错误，验证失败，第一用户提出的加入组织的申请作废。
46.如图3所示，本实施例存在三种用户类型，即存在三大类角色：组织管理员、普通管
理员与普通用户，每类角色都对应着不同类型的授权码，在第一用户加入组织时，会根据不同类型的授权码将第一用户的加入申请分发给不同的角色进行审核：(1)普通用户的加入申请由普通管理员审核；(2)普通管理员的加入申请由组织管理员审核；(3)组织管理员由于权力大，必须保证其可靠性、真实性，因此组织管理员的加入申请由超级管理员进行认证、授权，并且为了限制组织管理员的权力、分担其事务，一个组织会同时存在多个组织管理员。
47.在第一用户提出的加入组织的申请审核通过后，后续第一用户进行登录操作时，可以根据登录之后的员工id自动调出第一用户所属部门和员工角色信息，以确定第一用户所拥有的权限，便可确定第一用户是否具有上传秘密文件的权限。各个用户的权限是可以自定义的。
48.上述加入组织的申请审核过程可由ca机构完成，ca机构是每个组织内的组成部分，主要负责公私钥的生成和证书颁布。
49.作为一种可选的方式，用户有权限查阅自己参与的秘密文件，此处的参与是指：(1)由自己发起；(2)参与审批；(3)参与签字；(4)参与确认。普通管理员可以查阅自己所管理部门的所有秘密文件，组织管理员可以查阅本组织的所有秘密文件。若有用户想要查阅自己没有权限查阅的秘密文件，可分为如下几种情况来处理：(1)普通用户想要查阅同部门的秘密文件，可以向管理该部门的普通管理员申请；(2)普通用户、普通管理员想要查阅另一个部门的秘密文件，可以向另一个部门的普通管理员申请，申请通过后即获得查阅权限。故本实施例所述的有权限查阅秘密文件的所有第二用户是指参与该秘密文件的普通用户、秘密文件所属部门的普通管理员、组织管理员和经秘密文件所属部门的普通管理员赋予查阅权限的普通用户和普通管理员。
50.s2：利用sm4算法对所述秘密文件进行加密，得到第一密文；利用所述第一用户的公钥对所述sm4算法在对所述秘密文件进行加密时所用的sm4密钥进行加密，得到第二密文；对所述重加密密钥和所述第二密文进行代理重加密运算，得到第三密文；所述第一密文和所述第三密文组成重加密密文；
51.考虑用户数据的隐私性，用户存放在服务器的隐私数据都是以加密形式存在的，由于数据拥有者对云服务提供商并不完全信任，不能将解密密文的密钥发送给云端，由云端来解密并分享出去。代理重加密算法可以在不泄漏数据拥有者解密密钥的情况下，实现云端密文数据共享，因此本实施例采用这一机制实现授权用户的密文共享。
52.以alice为秘密文件发送方、bob为秘密文件接收方，代理重加密算法如图4所示，具体描述如下：
53.1.1：alice向密钥分发服务器请求生成自己的公私钥对。
54.1.2：密钥分发服务器生成alice的公私钥对并返回给alice。
55.1.3：bob向密钥分发服务器请求生成自己的公私钥对。
56.1.4：密钥分发服务器生成bob的公私钥对并返回给bob。
57.2.1：alice利用sm4算法加密数据m生成密文c1，用自己的公钥加密sm4密钥生成密文c2。
58.2.2：alice将密文c1和c2上传到系统服务器上。
59.3.1：alice向密钥分发服务器请求bob的公钥。
60.3.2：密钥分发服务器将bob的公钥返回给alice。
61.3.3：alice利用bob的公钥和自己的私钥生成重加密密钥ka→b。
62.3.4：alice把生成的重加密密钥ka→b上传到系统服务器上。
63.4：重加密算法reenc(params,cti,rki→j):给定针对公钥pki和第二层密文cti，该算法利用重加密密钥rki→j生成一个针对公钥rkj的第一层密文ctj。基于此，系统服务器利用重加密密钥ka→b和之前alice上传的密文c2做代理重加密运算生成新的密文c3。
64.5.1：bob向系统服务器请求解密数据m对应的密文c1。
65.5.2：系统服务器把重加密后的密文c3和c1发送给bob。
66.5.3：bob利用自己的私钥解密密文c3得到对称密钥，并用该对称密钥解密c1得到原始的明文数据m。
67.通过以上交互流程，系统服务器将一个用户的密文转换为另一个用户可以解密的密文，且不泄露用户的私钥和明文信息。这种方法主要是端到端的，保证了相关的敏感信息不被泄漏。
68.本实施例则基于上述代理重加密算法进行秘密文件的加密过程，获取第一用户根据第一用户的私钥和有权限查阅秘密文件的所有第二用户的公钥生成的重加密密钥，利用sm4算法对秘密文件进行加密，得到第一密文；利用第一用户的公钥对sm4密钥进行加密，得到第二密文；对重加密密钥和第二密文进行代理重加密运算，得到第三密文；第一密文和第三密文组成重加密密文。
69.s3：将所述重加密密文进行存储。
70.本实施例可将其存储到分布式服务器中。
71.秘密文件，比如合同的用词和文本细节对于合同是否生效、有何效应具有极大影响，用户必须确保自己上传的合同在经过系统传输后内容和格式没有发生变化，因此，需要为合同内容提供可靠的完整性检查，以保证合同内容被准确传达。基于此，在生成重加密密钥之后，本实施例的加密方法还包括：对秘密文件进行哈希运算，得到秘密文件的第一哈希值；将第一哈希值上传到区块链上。可选的，本实施例还可获取由第一用户利用第一用户的私钥和sm2签名算法对业务数据进行签名所得到的数字签名，业务数据包括表示签名二维码的前缀、秘密文件的id号、第一用户的用户名和签名的时间，同时将秘密文件的id号、生效时间、发起人、签署人、第一用户的数字签名、文件类型和第一哈希值上传到区块链上，便于后续进行完整性检查。经此操作，区块链可记录每一次业务操作后，第一用户所上传的秘密文件的关键信息，便于后续追溯。
72.作为一种可选的实施方式，本实施例的秘密文件需要由若干个签署人进行签名，得到每一签署人的手写签名；在得到每一签署人的手写签名后，本实施例的加密方法还包括：对于每一签署人，获取签署人利用其自己的私钥和sm2签名算法对业务数据进行签名所得到的签署人的数字签名；基于业务数据和数字签名生成签名二维码；业务数据包括表示签名二维码的前缀、秘密文件的id号、签署人的用户名和签名的时间；合成秘密文件以及每一签署人的手写签名和签名二维码，得到已签名文件；对已签名文件进行哈希计算，得到已签名文件的文件哈希值；将秘密文件的id号、生效时间、发起人、签署人、所有签署人的数字签名、文件类型和文件哈希值上传到区块链上。
73.本实施例将秘密文件进行加密后再存储，且利用具有查阅权限的用户的公钥参与
加密过程，保证只有具有查阅权限的用户可以进行秘密文件的查阅和调用，能够对秘密文件进行加密和访问控制，避免用户上传的秘密文件被不具有访问权限的用户访问，大大提高了秘密文件的安全性。
74.实施例2：
75.本实施例用于提供一种基于国密算法的秘密文件的解密方法，如图5所示，所述解密方法包括：
76.t1：判断提出查阅请求的第三用户是否属于有权限查阅秘密文件的第二用户；
77.本实施例也可利用第三用户的登录信息来获取第三用户的用户信息，进一步依据第三用户的用户信息来判断第三用户是否有权限查阅秘密文件。
78.t2：若是，则获取所述第三用户生成的对称密钥；所述对称密钥利用所述第三用户的私钥对重加密密文中的第三密文进行解密所得到；
79.t3：利用所述对称密钥对所述重加密密文中的第一密文进行解密，得到所述秘密文件。
80.本实施例也基于代理重加密算法进行解密过程，获取第三用户利用第三用户的私钥对重加密密文中的第三密文进行解密所得到的对称密钥，再利用对称密钥对重加密密文中的第一密文进行解密，得到秘密文件。本实施例设计与实施例1的加密方法配合使用的解密方法，由于利用具有查阅权限的用户的公钥参与加密过程，导致只有具有查阅权限的用户的私钥才能够对重加密密文进行解密，保证只有具有查阅权限的用户可以进行秘密文件的查阅和调用，能够对秘密文件进行访问控制，避免用户上传的秘密文件被不具有访问权限的用户访问，大大提高了秘密文件的安全性。
81.为了实现秘密文件的可靠的完整性检查，在得到秘密文件后，本实施例的解密方法还包括：计算秘密文件的哈希值，得到第二哈希值；从区块链中获取秘密文件的第一哈希值；对第一哈希值和第二哈希值进行比较；若第一哈希值和第二哈希值相同，则秘密文件未被篡改；若第一哈希值和第二哈希值不同，则秘密文件被篡改，丢弃秘密文件。
82.实施例3：
83.电子文件保护系统的安全性由诸多密码算法和安全协议共同保证，用户对保护系统的信任也是基于对算法和协议的信任之上的机器信任，故保护系统需要保证其所使用的算法是在实践中被证明安全、可靠的。sm2算法和sm4算法的安全性已经经过理论和实践上的双重验证，能够保证自主可控，使用sm2算法和sm4算法进行数字签名和非对称加密可以保证秘密文件的保密性、完整性和认证性，可以满足用户对秘密文件的安全性需求。基于这一考虑，本实施例以合同业务处理系统为载体，设计了一种基于国密算法的秘密文件的保护系统，结合代理重加密算法、数字签名、区块链等安全技术，为用户秘密文件提供安全性保护。
84.本实施例用于提供一种基于国密算法的秘密文件的保护系统，如图6所示，所述保护系统包括：数据传输模块、准入模块、查询模块、密钥传输模块、sm4加解密模块、sm2签名模块、文件生成模块、链上同步模块和分布式数据库(sqlite数据库)。
85.准入模块用于验证用户的权限，当用户具有权限时，允许用户进行秘密文件的上传和查阅。查询模块用于接收用户输入的查阅请求，并向用户返回秘密文件。密钥传输模块用于生成每一用户的公私钥对。sm4加解密模块用于对用户上传的秘密文件进行加密，得到
重加密密文，还用于对重加密密文进行解密，得到原始的秘密文件。分布式数据库用于存储重加密密文。sm2签名模块用于利用sm2签名算法对业务数据进行签名，得到数字签名。文件生成模块用于利用数字签名生成签名二维码，并将手写签名、签名二维码和秘密文件进行合成，得到已签名文件。链上同步模块用于将数字签名和对秘密文件或已签名文件进行哈希运算所得到的哈希值上传到区块链上。
86.更为具体的，本实施例的各个模块的功能如下：
87.(1)准入模块
88.每位用户在注册后，还需要加入组织才能使用本保护系统的完整的功能。申请加入组织的审核过程由准入模块完成，其流程如图2所示，组织的ca机构首先依据员工id号、所申请部门和员工角色信息{uid，department，status}(status包括三种用户类型，还包括每一用户具有的具体权限，具体权限可以自定义)，使用ca私钥，通过sm2签名算法产生授权码，授权码由ca机构管理和分发。用户首次使用该保护系统时，需要输入自己要加入组织的组织id号以及授权码{organizationid，authorizationcode}，每一个授权码是唯一的，使用后即作废。使用ca公钥，通过sm2验证算法对授权码进行解签，判断授权码是否正确，当输入的授权码错误时，直接将本次申请作废，不上传至更高一级用户节点；当授权码正确时，将本次申请上传至更高一级用户节点供审核，审核通过后，用户即成功加入组织，并生成用户的用户信息：员工id、加入组织时间、审核人、所属部门、员工角色信息{uid，jointime，reviewer，department，status}，该用户信息会自动保存在准入模块中。此后，每次用户进行登录操作时，准入模块都会根据uid自动调出department和status信息，对用户的访问权限进行管理和分配。
89.如图3所示，在本保护系统中，存在三大类角色：组织管理员、普通管理员与普通用户，每类角色都对应着不同类型的授权码，在加入组织时，保护系统会根据不同类型的授权码将加入申请分发给不同的角色进行审核：(1)普通用户的申请由普通管理员审核；(2)普通管理员的申请由组织管理员审核；(3)而组织管理员由于权力大，必须保证其可靠性、真实性，因此由超级管理员进行认证、授权；并且为了限制组织管理员的权力、分担其事务，保护系统中会同时存在多个组织管理员。
90.组织的创建过程可由超级管理员进行审核，具体的，超级管理员是负责运维保护系统服务器的程序员，在创建保护系统的时候就已经进行了赋权。组织管理员在创建组织的时候需要向保护系统提交该组织的相关信息(比如公司的地址、注册号等真实信息)，由超级管理员对该组织的真实性进行审核，审核通过后才能在保护系统中创建该组织。超级管理员没有权限访问每个组织内部的信息，保证了每个组织的内部信息不会被第三方获得。
91.(2)查询模块
92.在系统业务进行时，用户可以在前端网页通过可视化应用看到业务当前的流程以及基本信息，包括合同进行到了哪一步、合同名称、发起人、发起时间、有效期、合同类型、签署人{contractstep，contractname，initiator，initiationtime，validtime，contracttype，[signer]}。对于未完成签章的参与者，用户可以去提醒对方按时完成。
[0093]
本实施例的查询模块用于确定用户是否具有查阅权限，用户可以查阅自己参与的合同文件，这里的参与是指：(1)由自己发起；(2)参与审批；(3)参与签字；(4)参与确认。除
此之外，普通管理员可以查阅自己所管理部门的所有的合同，组织管理员可以查阅本组织的所有合同。若有用户想要查阅自己没有权限查阅的合同，可分为如下几种情况来处理：(1)普通用户想要查阅同部门的合同，可以向管理该部门的普通管理员申请；(2)普通用户、普通管理员想要查阅另一个部门的合同，可以向该部门的管理员申请，申请通过后获得查阅权限。故有权限查阅秘密文件的所有第二用户是指参与该秘密文件的普通用户、秘密文件所属部门的普通管理员、组织管理员和经秘密文件所属部门的普通管理员赋予查阅权限的普通用户和普通管理员。
[0094]
(3)密钥传输模块
[0095]
该模块需要承担密钥生成、密钥分发和密文共享等管理功能，其内部设有sm2密钥生成算法，可根据需要扩展aes、ecc等其他算法。sm2密钥生成算法在用户、组织乃至印章设备建立时生成对应的公私钥对，并记录对应信息，用于后续的签名以及会话服务，密钥传输模块对公钥进行保管，私钥在分配给对应用户后便销毁不留存，故在需要用到私钥来生成其他数据时，都需要由用户进行操作，再向保护系统提供该数据，比如，重加密密钥、对称密钥等。
[0096]
(4)文件存储与传输模块
[0097]
存储过程如图7所示，链上同步模块和分布式数据库共同组成文件存储与传输模块，加密文件存储在分布式数据库中，并且置备有相应的备份。秘密文件(比如合同)的关键信息如合同id、合同生效时间、发起人、签署人、参与者的数字签名、合同类型、文件哈希值{contractid，sxtime，initiator，[signer]，[participantsig]，contenttype，hash(contract)}会在区块链上同步。当用户查阅合同时，使用密钥传输模块提供的重加密密钥将合同解密，解密后发送给用户，用户收到合同后，计算合同的哈希值，然后将求得的值与链上的值对比，相等则保留合同，不等则丢弃。传输中采用https安全协议，并对敏感信息进行加密处理。
[0098]
(5)sm2签名模块
[0099]
系统应用中，密钥交换协议在用户注册时由平台调用，生成用户唯一密钥对，并将其与用户信息绑定，在平台终端秘密存储。签名模块在用户执行业务操作时调用，对合同签署或签章盖印等行为信息进行电子签名，以实现身份认证并将操作信息上链存储，保障了电子签名的法律有效性。验签模块在以下情景下调用：平台合同有效性审核、用户行为有效性审核、用户身份检验等。
[0100]
(6)sm4加解密模块
[0101]
实际应用中，sm4常用于平台文件的加密存储与传输。调用sm4算法对秘密文件进行加密存储，用户发起查阅秘密文件的申请时，确认身份后调用解密算法从分布式数据库中提取相应的秘密文件，建立会话并将秘密文件通过安全通道发送给用户，用户收到秘密文件后，先将文件hash与链上信息对比，验证无更改后可接收查阅。
[0102]
表1需加密隐私数据
[0103]
usr_id申请人id信息manager_id负责人id信息seal_data用印结果信息contract_data合成签名后的电子合同文件
[0104]
(7)文件生成模块
[0105]
涉及链上业务需要生成已签名文件时，将利用sm2签名模块得到的数字签名传入文件生成模块生成签名二维码，结合前端的合同内容、手写签名图片信息进行签名文件合成，该已签名文件传递给数据传输模块，上传到前端网页应用供用户下载。
[0106]
签名二维码包含的内容为[sig，cid，username，stime，esig]。其中，sig字符串作为前缀，表明这是一个签名二维码；cid为合同的id号；username代表签署人的用户名，在系统中没有重复的用户名；stime代表签名的时间；esig为签署人对[sig，cid，username，stime]的sm2数字签名，使用签署人的私钥签名、公钥验证，用以保证本次签署的真实性。合同文件、用户的手写签名以及签名二维码被聚合到一个pdf中作为已签名文件。
[0107]
基于上述各个模块的功能，在此给出保护系统所包括的各个模块之间的数据流动方式，具体如下：
[0108]
(1)文件上传&业务创建
[0109]
如图8所示，用户在创建新业务或者上传秘密文件的同时通过前端网页应用将秘密文件传递给数据传输模块，由数据传输模块将登录信息传递给准入模块，准入模块通过登录信息验证用户身份，判断其是否有创建新业务或者上传秘密文件的权限，若判断用户具有相应权限，则通过密钥传输模块将该用户的重加密密钥传递给sm4加解密模块，同时将秘密文件传输至sm4加解密模块，在sm4加解密模块进行代理重加密，并将重加密密文传递给分布式数据库进行存储。同时，将包括秘密文件在内的业务数据传递给链上同步模块求出哈希值，生成一个交易区块进行链上存储。
[0110]
(2)文件读取
[0111]
具有秘密文件查阅权限的用户需要通过以下流程进行秘密文件的读取，如图9所示，首先由数据传输模块将请求数据和登录信息传递给准入模块。准入模块对该用户的权限进行验证，若判断该用户具有所请求秘密文件的查阅权限，则通过密钥传输模块传递重加密密钥给查询模块，由查询模块从分布式数据库中查找重加密密文并一同传递给sm4加解密模块进行解密，将得到的原始的秘密文件回传给数据传输模块，显示在前端网页应用上供用户读取。
[0112]
(3)签名过程
[0113]
用户对文件进行签名时的流程如图10所示：首先由数据传输模块将前端网页应用获得的手写签名图片和登录信息传递给准入模块，准入模块对该用户的身份和权限进行验证，若判断该用户是该业务的负责人，则通过密钥传输模块传递重加密密钥给查询模块进行该合同文件的读取，同时将该用户的私钥和相关业务数据传递给sm2签名模块进行签名，将生成的数字签名和业务数据传递给文件生成模块进行签名二维码的生成和已签名文件的合成，最后将包括数字签名、已签名电子文件在内的业务数据传递给链上同步模块，求出哈希值并生成一个交易区块进行链上存证。
[0114]
数字签名在已签名文件中以二维码图片形式存在的，可以方便查证的时候读取签名，将文件内容上链可以保护数据完整性，签名则保证了不可抵赖。
[0115]
本实施例所提供的保护系统，用户的敏感合同或文件等资料使用国密算法的端对端加密存储与传输，通过秘钥授权与分发机制，支持授权用户对敏感文件的阅读和共享，避免了中心化平台下系统管理员被腐化或系统被黑客入侵造成的敏感数据泄露风险。涉及隐
私的业务数据均用组织管理员的密钥经sm4加解密模块进行加密后存储于数据库，只有管理员和参与该合同的用户可以用该密钥进行查阅和调用。用户经准入模块验证后，才可由密钥传输模块将密钥传递给sm4模块进行解密。这一过程在系统服务器内部完成，保证组织密钥不会泄漏到普通用户手中，保证了隐私信息的可控和密钥的安全性。
[0116]
目前的文件管理系统多使用中心化服务器的单一数据库对明文进行直接存储，并且对于用户的访问权限管理通常建立在系统管理层面，而没有基于密码技术对其可靠性进行保护。本保护系统使用自主可控的国密算法，设计了一套完备的敏感文件保护系统，不仅使用密码技术对敏感文件的存储进行了保护，同时对关键摘要信息进行链上同步，保证数据的可追溯性和完整性。本系统应用代理重加密进行秘密文件共享，使得双方用户对于整个信息交互过程保密性的信任不再基于第三方系统的可靠性，而是可验证的机器信任，是对文件管理系统的一个技术革新。
[0117]
本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。
[0118]
本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处。综上所述，本说明书内容不应理解为对本发明的限制。