存证方法、取证方法及存证***
技术领域
本申请涉及数据处理技术领域,尤其涉及存证方法、取证方法及存证***。
背景技术
在电子商务中,存在大量电子形式的数据信息,如电子合同、电子协议、资产总额、收益证明等重要文件。在产生互联网争端时,这些电子文件可以作为电子证据使用。因而,电子证据有着重要的作用和意义。
通常情况下,电子证据以备份的形式存放在存证用户自己机构或租赁的服务器上,在业务需要提起仲裁时,由存证方将保存的电子证据提交给仲裁机构进行仲裁裁决。但由于存放在自己机构或租赁的服务器上的电子数据容易被篡改,且存证方本身的公信力不高,所以电子证据的可信度不高。
因此,如何提高电子证据的可信度是亟需解决的问题。
发明内容
有鉴于此,本申请的目的在于提供一种存证方法、取证方法及存证***,以解决电子证据可信度低的问题。
为实现上述目的,一方面,本申请提供了一种存证方法,包括:
存证子***接收用户端设备通过应用子***提供的证据文件以及所述证据文件的电子签名;
所述存证子***调用密码子***对所述证据文件的电子签名进行验证;
在所述证据文件的电子签名通过验证后,所述存证子***调用密码子***对所述证据文件进行哈希运算,得到所述证据文件的哈希值;
所述存证子***将得到的所述证据文件的哈希值保存至分布于不同地点的多个节点上。
优选地,所述证据文件为加密文件;
在所述对所述证据文件进行哈希运算之前还包括:
存证子***调用密码子***对所述证据文件进行解密。
优选地,所述方法还包括:
所述存证子***获取所述证据文件的操作日志信息;
将所述证据文件的操作日志信息保存至所述分布于不同地点的多个节点上。
优选地,所述方法还包括:
所述存证子***获取所述证据文件的属性信息;所述证据文件的属性信息包括如下一种或者多种的组合:证据文件的摘要特征值、存证类型、获证渠道、获证时间、存证地点、存证时间、存证用户标识;
将所述证据文件的属性信息保存至所述分布于不同地点的多个节点上。
优选地,所述存证子***调用密码子***对所述证据文件的电子签名进行验证,包括:
所述存证子***获取所述密码子***为所述用户端设备分配的密钥;其中,所述密码子***基于所述用户端设备的属性信息、所述证据文件的标识和请求分配密钥的时间生成密钥;
基于所述密钥对所述证据文件的电子签名进行验证。
优选地,所述存证子***将得到的所述证据文件的哈希值保存至分布于不同地点的多个节点上,包括:
向分布于不同地点的多个节点广播保存所述证据文件的哈希值的消息;
接收所述多个节点反馈的信息;
基于所述多个节点反馈的信息确定所述多个节点是否达成共识;
在所述多个节点达成共识时,将所述证据文件的哈希值保存至所述多个节点上。
又一方面,本申请提供了一种取证方法,包括:
用于保存证据文件的节点获取目标证据文件;
所述节点通过应用子***得到所述目标证据文件的哈希值;其中,所述应用子***调用密码子***对所述目标证据文件进行哈希运算,得到目标证据文件的哈希值;
所述节点确定本地是否保存有与所述目标证据文件的哈希值一致的哈希值,如果有,则将所述目标证据文件发送给仲裁机构。
优选地,所述方法还包括:
所述节点在本地查找所述目标证据文件的操作日志信息;
将所述目标证据文件的操作日志信息发送给仲裁机构。
优选地,所述方法还包括:
所述节点在本地查找所述目标证据文件的属性信息;
将所述目标证据文件的属性信息发送给仲裁机构。
又一方面,本申请还提供了一种存证***,包括:密码子***、应用子***和存证子***;
其中,所述密码子***,用于对所述证据文件的电子签名进行验证以及对所述证据文件进行哈希运算;
所述应用子***,用于接收用户端设备提供的证据文件,并将所述证据文件发送至所述存证子***;
存证子***,包括:
第一获取模块,用于接收所述应用子***发送的所述证据文件以及所述证据文件的电子签名;
第一处理模块,用于调用所述密码子***对所述第一获取模块接收到的证据文件的电子签名进行验证;
第二处理模块,用于在所述第一处理模块得到证据文件的电子签名通过验证的结果后,调用所述密码子***对证据文件进行哈希运算,得到证据文件的哈希值;
保存模块,用于将所述第二处理模块得到的证据文件的哈希值保存至分布于不同地点的多个节点上。
由以上方案可知,本申请实施例中,将经过电子签名的证据文件保存在分布于不同地点的多个节点上,多个节点分布于不同地点,本质上实现了电子证据的分布式存储,这种多节点存储的方式能够避免黑客对单节点的攻击,安全性更高,保证了数据不容易被篡改。且保存证据文件的节点可以是高可信机构对应的服务器,公信力高,从而提升了电子证据的可信度,解决了电子证据难以被采信的问题。
附图说明
为了更清楚地说明本申请实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本申请的实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据提供的附图获得其他的附图。
图1是本申请实施例的存证方法的一种流程示意图;
图2是本申请实施例的存证方法的又一种流程示意图;
图3是本申请实施例的存证方法的又一种流程示意图;
图4是本申请实施例的存证方法的又一种流程示意图;
图5是本申请实施例的取证方法的一种流程示意图;
图6是本申请实施例的存证***的一种组成示意图。
具体实施方式
下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本申请保护的范围。
实施例一
如,参见图1,其示出了本申请实施例的存证方法的一种流程示意图。该方法包括:
S101,存证子***接收用户端设备通过应用子***提供的证据文件以及该证据文件的电子签名。
其中,证据文件是用户想要保存的、作为证据使用的文件,该文件可以是电子商务、金融服务、司法服务过程中的电子证据,还可以是电子合同,如利用合同业务***签署的电子合同。
当用户想要存证时,可以利用存证***中的应用子***将待存证文件提供给存证子***。如,用户先通过用户端设备在应用子***上注册,在成为***用户之后,以***用户的身份登录至应用子***上,然后将证据文件通过应用子***发送至存证子***,以便存证子***完成该存证业务。
为了提高证据文件的可信度,可以先对提供该证据文件的用户的身份进行验证,只有通过身份验证的用户才允许执行存证业务。如,用户请求登录应用子***时,应用子***可以对用户身份进行验证,只有***用户才能成功登录至该***,执行后续的存证业务。应用子***进行用户身份验证的方式可以有多种,如用户名和密码验证、人脸验证、指纹验证、声纹验证、实名认证等等。
其中,证据文件的电子签名,指的是通过密码技术实现的电子形式的签名,类似于手写签名或***,用于识别签名人身份并表明签名人认可所签名文件中内容的数据。
对文件进行电子签名的具体实现,如,应用子***向密码子***为用户申请密钥,基于得到的密钥对证据文件实施电子签名。
为了进一步提高证据文件的安全性,可以先对证据文件的内容进行加密,然后再将加密后的证据文件提供给存证子***。在一种可能的实现中,如,应用子***向密码子***为用户申请密钥,基于得到的密钥对证据文件的内容进行加密,得到加密后的证据文件。
S102,存证子***调用密码子***对证据文件的电子签名进行验证。
其中,密码子***基于用户端设备的属性信息、证据文件的标识和请求分配密钥的时间生成密钥;密钥包括私钥和公钥,用户端设备利用私钥对证据文件进行电子签名,存证子***利用公钥对电子签名进行验证。如存证子***获取密码子***为用户端设备分配的密钥,基于该密钥对证据文件的电子签名进行验证。
其中,在证据文件是经过内容加密的文件的情况下,首先要对接收到的证据文件进行解密。在具体实现时,存证子***可以调用密码子***对证据文件进行解密。
S103,在证据文件的电子签名通过验证后,存证子***调用密码子***对证据文件进行哈希运算,得到证据文件的哈希值。
其中,哈希运算是将一个大文件映射成一个小串字符,得到的哈希值与指纹一样,以较短的信息来保证文件的唯一性的标志,这种标志与文件的每一个字节都相关,而且难以找到逆向规律。保存证据文件的哈希值,不但能够保证证据文件不容易被篡改,还能降低存储量,节省存储空间。
其中,在证据文件的电子签名未通过验证时,说明该证据文件不符合存证用户本人的意愿,或者存证用户并非证据文件的签名用户,存证子***不会将该证据文件保存,流程结束。
S104,存证子***将得到的证据文件的哈希值保存至分布于不同地点的多个节点上。
其中,保存证据的节点非存证方自己的服务器,具体可以是高可信机构对应的服务器,如互联网平台、司法机构等对应的服务器。
其中,在保存数据至分布于不同地点的多个节点时,可以根据待保存数据生成用于在每个节点上存储的数据区块,然后将数据区块写入对应的节点。其中,针对每个节点生成的数据区块不同,但是,每个数据区块的区块体中数据相同。更具体地,根据待保存数据创建当前数据区块,将当前数据区块写入第一节点,根据当前数据区块生成下一数据区块,写入下一节点,以此类推,直至针对每个节点生成了数据区块,以完成待保存数据在多个节点的共享。
本申请实施例中,在存证子***完成存证之后,会将存证编号返回至执行存证的用户端设备。其中,存证编码可以基于证据文件的存证时间、存证顺序等信息生成,也可以仅根据证据文件的存证顺序生成。举例来讲,证据文件的存证时间为2019-1-1 12:22:30,存证顺序为231,则该证据文件的存证编码可以为20190101-122230-231。
本申请实施例中,用户端设备通过应用子***向存证子***提供证据文件以及证据文件的电子签名,存证子***调用密码子***对该证据文件的电子签名进行验证,并在证据文件的电子签名通过验证后,对所述证据文件进行哈希运算,得到该证据文件的哈希值,然后将该证据文件的哈希值保存至分布于不同地点的多个节点上。可见,通过本申请实施例,将经过电子签名的证据文件保存在分布于不同地点的多个节点上,多个节点分布于不同地点,本质上实现了电子证据的分布式存储,这种多节点存储的方式能够避免黑客对单节点的攻击,安全性更高,保证了数据不容易被篡改。且保存证据文件的节点可以是高可信机构对应的服务器,公信力高,从而提升了电子证据的可信度,解决了电子证据难以被采信的问题。
为了便于理解,下面对上述实施例中步骤104中保存证据文件的哈希值的方式进行具体介绍。
存证子***采用数据共享机制将得到的证据文件的哈希值保存至分布于不同地点的多个节点上。具体实现可以包括:
S1041,向分布于不同地点的多个节点广播保存证据文件的哈希值的消息;
广播保存证据文件的哈希值的消息,以将保存证据文件的哈希值这一事件通知给分布于不同地点的多个节点。
S1042,接收多个节点反馈的信息;
其中,节点反馈的信息可以是表明该节点同意保存该证据文件的哈希值的信息,也可以是表明该节点不同意保存该证据文件的哈希值的信息。
S1043,基于多个节点反馈的信息确定多个节点是否达成共识;
S1044,在多个节点达成共识时,将证据文件的哈希值保存至多个节点上。
为了进一步提高证据文件的可信度,本申请还提供了另外一个具体实施例。
实施例二
如,参见图2,其示出了本申请实施例的存证方法的又一种流程示意图,该方法包括:
S201,存证子***接收用户端设备通过应用子***提供的证据文件以及该证据文件的电子签名。
S202,存证子***调用密码子***对证据文件的电子签名进行验证。
S203,在证据文件的电子签名通过验证后,存证子***调用密码子***对证据文件进行哈希运算,得到证据文件的哈希值。
S204,存证子***将得到的证据文件的哈希值保存至分布于不同地点的多个节点上。
其中,步骤S201~S204可以参见上面实施例的介绍,此处不再赘述。
S205,存证子***获取证据文件的操作日志信息。
其中,证据文件的操作日志信息包括:用户端设备在存证***上执行的与证据文件相关的操作时产生的日志信息。其中,与证据文件相关的操作可以包括登录***、对证据文件进行电子签名、存证。在对证据文件进行电子签名时包括请求密钥、实施签名等环节,存证时包括证据文件上传、证据文件的电子签名验证、证据文件的解密等环节。相应地操作日志信息包括:操作人身份信息、操作时间、操作地点以及操作结果(如,用户身份、密钥、电子签名)等。
S206,将证据文件的操作日志信息保存至分布于不同地点的多个节点上。
其中,保存证据文件的操作日志信息时可以按照上述与保存证据文件的哈希值类似的方式实现。
可以理解的是,一个证据文件的各项信息关联存储在各个节点上,如将证据文件的哈希值、日志操作信息存储在一个文件夹中。
本申请实施例中,将证据文件的操作日志信息保存至分布于不同地点的多个节点上,实现了采用分布式节点,跟踪文件上传、密钥请求、签名申请、签名实施、解密验签等存证全过程,存证行为在分布于不同地点的多个节点上公开,可监督、可追溯,提升了存证环节的可信度,使得通过该存证方式存储的证据文件的可信度更高。
为了进一步提高证据文件的可信度,本申请还提供了另外一个具体实施例。
实施例三
如,参见图3,其示出了本申请实施例的存证方法的又一种流程示意图,该方法包括:
S301,存证子***接收用户端设备通过应用子***提供的证据文件以及该证据文件的电子签名。
S302,存证子***调用密码子***对证据文件的电子签名进行验证。
S303,在证据文件的电子签名通过验证后,存证子***调用密码子***对证据文件进行哈希运算,得到证据文件的哈希值。
S304,存证子***将得到的证据文件的哈希值保存至分布于不同地点的多个节点上。
其中,步骤S301~S304可以参见上面实施例的介绍,此处不再赘述。
S305,存证子***获取证据文件的属性信息。
其中,证据文件的属性信息包括如下一种或者多种的组合:证据文件的摘要特征值、存证类型、获证渠道、获证时间、存证地点、存证时间、存证用户标识等。
S306,将证据文件的属性信息保存至分布于不同地点的多个节点上。
其中,保存证据文件的属性信息时可以按照上述与保存证据文件的哈希值类似的方式实现。
可以理解的是,一个证据文件的各项信息关联存储在各个节点上,如将证据文件的哈希值、属性信息存储在一个文件夹中。
本申请实施例中,将存证类型、获证渠道、获证时间、存证地点、存证时间、存证用户标识等证据文件的属性信息保存至分布于不同地点的多个节点上,形成了一条完整的证据链,提升了证据文件的可信度。
可以理解的是,在其他实施例中,还可以将实施例二中的证据文件的日志操作信息和实施例三中的证据文件的属性信息都保存至分布于不同地点的多个节点上。
为了便于理解,下面以具体示例对本申请实施例中的存证方法进行介绍。
如,参见图4,其示出了本申请实施例的存证方法的又一种流程示意图。
该方法包括:
S401,用户端设备通过应用子***请求登录存证***。
S402,应用子***调用密码子***对用户端设备的用户身份进行校验。
S403,用户端设备请求应用子***生成电子合同。
S404,应用子***响应电子合同生成请求,生成电子合同。
S405,用户端设备请求应用子***对电子合同进行电子签名。
S406,应用子***响应电子签名请求,向密码子***为用户申请密钥,并利用得到的密钥私钥对电子合同进行电子签名。
S407,用户端设备请求应用子***对经过电子签名的电子合同进行存证。
S408,应用子***响应存证请求,将电子合同及其电子签名发送至存证子***。
S409,存证子***利用密码子***生成的密钥公钥对接收到的电子合同进行电子签名验证。
S410,存证子***在电子签名验证通过后,调用密码子***对电子合同进行哈希运算,并将电子合同的哈希值保存至分布于不同地点的多个节点上。
S411,存证子***获取证据文件的属性信息和证据文件的操作日志信息。
S412,存证子***将获取到的证据文件的属性信息和证据文件的操作日志信息保存至分布于不同地点的多个节点上。
本申请实施例中,用户在应用子***上签署了电子合同之后,该合同可以立即被保存在分布于不同地点的多个节点上,实现了对原始合同的存证。不需要公证机构出具公证书来证明原始合同的真实性,降低了建立多方信任的成本。
下面对本申请实施例中的取证方法进行介绍。取证过程主要是利用节点上存储的证据文件的哈希值对目标证据文件进行核验。
如,参见图5,其示出了本申请实施例中取证方法的一种流程示意图,该方法包括:
S501,用于保存证据文件的节点获取目标证据文件。
其中,用于保存证据文件的节点可以是上面实施例中分布于不同地点的多个节点中的一个,具体可以为某个高可信机构对应的服务器,如互联网平台、司法机构等对应的服务器。
目标证据文件是与保存在用于保存证据文件的节点上的证据文件(为了方便介绍,下面将保存在用于保存证据文件的节点上的证据文件称为源证据文件)相对应的文件。其中,目标证据文件与源证据文件的内容可能相同,也可能不同。如果目标证据文件与源证据文件的内容相同,则表明目标证据文件与源证据文件是同一份证据文件。如果目标证据文件与源证据文件的内容不同,则表明目标证据文件是被篡改后的源证据文件。
S502,用于保存证据文件的节点通过应用子***得到该目标证据文件的哈希值。
其中,应用子***调用密码子***对目标证据文件进行哈希运算,得到目标证据文件的哈希值。
S503,用于保存证据文件的节点确定本地是否保存有与该目标证据文件的哈希值一致的哈希值,如果有,则将该目标证据文件发送给仲裁机构。
可以理解的是,确定用于保存证据文件的节点本地保存的哈希值中是否存在与该目标证据文件的哈希值一致的哈希值,如果存在,则确定该目标证据文件为没有被篡改的证据文件,核验结果为通过;否则,确定目标证据文件为基于源证据文件篡改后的文件,核验结果为不通过。在目标证据文件的核验结果为通过时,可以将该目标证据文件发送给仲裁机构。
同时,用于保存证据文件的节点还可以在本地查找该目标证据文件的操作日志信息;将目标证据文件的操作日志信息发送给仲裁机构。和/或,用于保存证据文件的节点在本地查找目标证据文件的属性信息;将目标证据文件的属性信息发送给仲裁机构。
其中,目标证据文件的操作日志信息指的是与目标证据文件对应的源证据文件的操作日志信息,也就是存证时与证据文件的哈希值关联存储的操作日志信息,包括:用户端设备在存证***上执行的与证据文件相关的操作时产生的日志信息。其中,与证据文件相关的操作可以包括登录***、对证据文件进行电子签名、存证。在对证据文件进行电子签名时包括请求密钥、实施签名等环节,存证时包括证据文件上传、证据文件的电子签名验证、证据文件的解密等环节。相应地操作日志信息包括:操作人身份信息、操作时间、操作地点以及操作结果(如,用户身份、密钥、电子签名)等。
其中,目标证据文件的属性信息指的是与目标证据文件对应的源证据文件的属性信息,也就是存证时与证据文件的哈希值关联存储的属性信息,包括如下一种或者多种的组合:证据文件的摘要特征值、存证类型、获证渠道、获证时间、存证地点、存证时间、存证用户标识等。
对应于本申请实施例的存证、取证方法,本申请实施例还提供了一种存证***,如,参见图6,其示出了本申请实施例中一种存证***的一种组成架构示意图。该***包括密码子***601、应用子***602以及存证子***603。
其中,密码子***601,用于对证据文件的电子签名进行验证以及对证据文件进行哈希运算。
应用子***602,用于接收用户端设备提供的证据文件,并将该证据文件发送至存证子***603。
存证子***603,包括:第一获取模块、第一处理模块、第二处理模块和保存模块。
其中,第一获取模块,用于接收应用子***发送的证据文件以及证据文件的电子签名;
第一处理模块,用于调用密码子***对第一获取模块接收到的证据文件的电子签名进行验证;
第二处理模块,用于在第一处理模块得到证据文件的电子签名通过验证的结果后,调用密码子***对证据文件进行哈希运算,得到证据文件的哈希值;
保存模块,用于将第二处理模块得到的证据文件的哈希值保存至分布于不同地点的多个节点上。
在另一种可能的实现中,密码子***601可以包括:密钥分配模块、验证模块、签名模块、第一运算模块和第二运算模块;
其中,密钥分配模块,用于为用户端设备分配密钥,以便用户端设备利用密钥私钥对证据文件进行电子签名,存证子***利用密钥公钥对证据文件进行电子签名的验证。其中,密钥分配模块中构建有密钥生成模型,用于为生成密钥,在一种可能的实现中,用户私钥生成模型为“用户属性信息+文件标识+时间戳”三元素模型。其中,时间戳可以是用户请求分配密钥的时间,该模型中加入了请求时间,为密钥请求、发布、签名应用引入时效机制,保证了电子签名的可行性和用户本人的主动意愿。对于生成的密钥私钥,可以利用用户的手机作为私钥介质,这种实现方式安全级别高,还实现了免介质效果。
验证模块,用于对证据文件的电子签名进行验证;
签名模块,用于对证据文件进行电子签名。
第一运算模块,用于对证据文件进行哈希运算,得到证据文件的哈希值。
第二运算模块,用于对证据文件进行加解密运算。
在另一种可能的实现中,应用子***602可以包括:用户交互模块,用于接收用户端设备提供的证据文件,并为用户端设备提供电子合同生成、合同签署、合同存证取证等业务服务。
在另一种可能的实现中,存证子***还包括:第三处理模块,用于调用密码子***对证据文件进行解密。
在另一种可能的实现中,存证子***还包括:第二获取模块,用于获取证据文件的操作日志信息。相应地,保存模块还用于将将证据文件的操作日志信息保存至分布于不同地点的多个节点上。
在另一种可能的实现中,存证子***还包括:第三获取模块,用于获取证据文件的属性信息;其中,证据文件的属性信息包括如下一种或者多种的组合:证据文件的摘要特征值、存证类型、获证渠道、获证时间、存证地点、存证时间、存证用户标识。相应地,保存模块还用于将证据文件的属性信息保存至分布于不同地点的多个节点上。
在另一种可能的实现中,存证子***还包括:第二获取模块和第三获取模块,其中,第二获取模块,用于获取证据文件的操作日志信息。第三获取模块,用于获取证据文件的属性信息;其中,证据文件的属性信息包括如下一种或者多种的组合:证据文件的摘要特征值、存证类型、获证渠道、获证时间、存证地点、存证时间、存证用户标识。相应地,保存模块还用于将证据文件的属性信息和所述证据文件的操作日志信息保存至分布于不同地点的多个节点上。
在另一种可能的实现中,保存模块,具体包括:
广播子模块,用于向分布于不同地点的多个节点广播保存证据文件的哈希值的消息;
反馈子模块,用于接收多个节点反馈的信息;
共识子模块,用于基于多个节点反馈的信息确定多个节点是否达成共识;
保存子模块,用于在多个节点达成共识时,将证据文件的哈希值保存至所述多个节点上。
上述存证***,在具体实现时,应用子***可以通过调用存证子***和密码子***为上层应用提供的API接口,实现相应的业务。如,调用存证子***提供的存证接口、取证接口实现存证和取证;又如,调用密码子***提供的用户密钥申请实现用户密钥申请等。其中,存证子***提供的API接口,可以包括应用API接口,如存证子***存证、取证接口等,用于实现业务应用与存证底层平台的交互;还包括:数据共享API接口,用于实现将证据文件保存至分布式节点上,各个分布式节点基于约定共享数据。密码子***提供的API接口,可以包括签名服务密钥管理类接口、密码运算类接口等,用于用户密钥申请、存证文件签名、合同验证、存证文件加密保护、取证解密等功能实现。
上述整个存证***的技术架构设计遵循大型应用总体框架设计的分层设计思想,从顶层服务到底层环境将总体框架划分为五个层次。
(1)第一基础层
第一基础层承载存证***的云计算物理环境,包括各类主机服务器、存储设备、路由设备、交换设备以及安全***、配套的***软件等。
(2)第二基础层
第二基础层提供存证子***的基础设施以及密码子***的基础设施。
其中,存证子***的基础设施,如,数据共享、分布式保存等。
密码子***的基础设施,如,为业务应用提供密码算法的密钥生成和密码运算支撑。提供密钥全生命周期管理包括密码算法的密钥生成、密钥存储、密钥销毁、密钥备份、密钥恢复和密钥发行等密钥全生命周期管理服务。提供密钥生成、合同签署所需要的可信时间源。提供移动终端密码算法应用的安全支撑,实现密钥分片管理等。提供密码应用态势感知、日志管理和可视化运维等。
(3)第一中间层
第一中间层提供数据共享以及密码运算。其中,数据共享为文件存证、取证提供运算支撑。
密码运算包括非对称加解密、对称加解密、数字签名与验证、数字信封封包与解封、哈希运算和随机数生成、时间戳签发等。为身份认证、密钥申请、电子合同签署提供密码运算支撑。
(4)第二中间层
第二中间层提供与业务对接的多种形态的应用接口。通过调用这些应用接口可快速实现身份认证、电子合同加解密、非对称加解密、对称加解密、数字签名与验证、数字信封封包与解封、哈希运算和随机数生成、存证取证等。
(5)顶层展示层
顶层展示层提供呈现在用户终端上的服务的最终形态。其中,用户终端,如支持安卓、iOS的智能终端和支持Windows的个人计算机。
对于本申请实施例的存证***而言,由于其与上面实施例中的存证方法相对应,所以描述的比较简单,相关相似之处请参见上面实施例中部分的说明即可,此处不再详述。
需要说明的是,本说明书中的各个实施例均采用递进的方式描述,每个实施例重点说明的都是与其他实施例的不同之处,各个实施例之间相同相似的部分互相参见即可。
为了描述的方便,描述以上***或装置时以功能分为各种模块或单元分别描述。当然,在实施本申请时可以把各单元的功能在同一个或多个软件和/或硬件中实现。
通过以上的实施方式的描述可知,本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解,本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来,该计算机软件产品可以存储在存储介质中,如ROM/RAM、磁碟、光盘等,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。
最后,还需要说明的是,在本文中,诸如第一、第二、第三和第四等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来,而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
以上所述仅是本申请的优选实施方式,应当指出,对于本技术领域的普通技术人员来说,在不脱离本申请原理的前提下,还可以做出若干改进和润饰,这些改进和润饰也应视为本申请的保护范围。