CN115664867A - 基于第三方认证的电子合约签署装置和方法 - Google Patents
基于第三方认证的电子合约签署装置和方法 Download PDFInfo
- Publication number
- CN115664867A CN115664867A CN202211682570.4A CN202211682570A CN115664867A CN 115664867 A CN115664867 A CN 115664867A CN 202211682570 A CN202211682570 A CN 202211682570A CN 115664867 A CN115664867 A CN 115664867A
- Authority
- CN
- China
- Prior art keywords
- signing
- platform
- contract
- request
- file
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Landscapes
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
本申请公开了一种基于第三方认证的电子合约签署装置和方法,属于电子合约技术领域,一种基于第三方认证的电子合约签署装置,其特征在于,包括:签约平台、监管平台、签约终端,以及信息储存平台;其中,签约平台和签约终端信号连接,监管平台和签约平台信号连接,签约平台与信息储存平台信号连接,签约终端与信息储存平台信号连接;签约终端向签约平台发送签约请求,签约平台生成合约签署请求,并将合约签署请求发送至监管平台,监管平台生成合约文件,监管平台利用合约文件生成电子合约,然后将电子合约分别发送至监管平台和签约终端。本申请提供了一种能够引入第三方进行监管的基于第三方认证的电子合约签署装置和方法。
Description
技术领域
本申请涉及电子合约认证技术领域,具体而言,涉及一种基于第三方认证的电子合约签署装置和方法。
背景技术
在现有的互联网经济模式中,很多签约平台和其签约平台下辖的用户所签订的各种电子合约都没有得到有效监管。签约平台相较于平台下辖的商户占据了过于强势的地位,其主要原因在于,签约平台和其下辖的用户所签订的电子合约、电子合同并不能够及时的送达至相关部门或者公证处进行备份,导致对这方面的监管处于缺位的状态,所以用户在与平台签订电子合约时,普遍会怀疑电子合约的有效性和真实性。
综上所述,目前市面上缺乏一款能够引入第三方进行监管的基于第三方认证的电子合约签署装置和方法。
发明内容
本申请的内容部分用于以简要的形式介绍构思,这些构思将在后面的具体实施方式部分被详细描述。本申请的内容部分并不旨在标识要求保护的技术方案的关键特征或必要特征,也不旨在用于限制所要求的保护的技术方案的范围。
作为本申请的第一个方面,为了解决以上背景技术部分提到的技术问题,本申请的一些实施例提供了一种基于第三方认证的电子合约签署装置,包括:签约平台、监管平台、签约终端,以及信息储存平台;其中,签约平台和签约终端信号连接,监管平台和签约平台信号连接,签约平台与信息储存平台信号连接,签约终端与信息储存平台信号连接;
签约终端向签约平台发送包括身份信息的签约请求,签约平台验证签约请求并生成合约签署请求,并将合约签署请求发送至监管平台,监管平台在对合约签署请求核对之后,生成合约文件,并将合约文件发送至签约平台,签约平台将合约文件发送至信息储存平台;同时,签约平台利用合约文件生成电子合约,然后将电子合约分别发送至监管平台和签约终端,签约终端下载信息储存平台上的合约文件,以验证电子合约的真实性。
本申请所提供的技术方案中,当签约人需要和签约平台签订电子合约时,需要签约平台根据签约人的签约请求向监管平台发送合约签署请求,监管平台在核对合约签署请求之后,才会向签约平台发送合约文件。所以,签约人和签约平台签署的电子合约,至少需要经过签约平台和监管平台的双重认证,避免了签约平台不能够受到监管的问题。同时,储存合约文件的平台为信息储存平台,所以签约终端在信息储存平台上借助合约文件验证电子合约的信息时,不用担心签约平台随意更改信息储存平台上的信息,导致自身在后续的争议中处于劣势地位。由此,借助引入第三方机构对电子合约的签署提供监管,极大地增加了签约人对于签约平台的信任度,在进行各种商业活动时,签约人和签约平台之间相互信任的程度将会更高。除此之外,本申请所提供的技术方案,除开可以用于签约人和签约平台签订合约之外,还可以借助签约平台实现签约人和签约人之间电子合约的签订,在运用于该方面时,也能够让签约双方,具有良好的信任度。
签约请求还包括合约编码,每种合约编码对应一种类型的电子合约模板。设置合约编码,能够减少签约请求、合约签署请求,以及合约文件的大小,不需要一次性传输完整的电子合约,避免了在进行加密运算时,需要加密的信息太多,而导致加密和解密过程复杂,进而使得签约活动更加高效。
预设加密算法,签约平台根据加密算法预设一对秘钥(Eu,Ee),Eu为公钥,Ee为私钥,Eu广播至签约终端、监管平台以及信息储存平台;监管平台根据加密算法预设一对秘钥(Hu,He),Hu为公钥,He为私钥,Hu广播至签约终端、签约平台以及信息储存平台。设置加密算法,并且签约平台和监管平台分别设置密钥对,能够让监管平台和签约平台都有着自己独特的数字签名,进而签约平台或者监管平台用自身的私钥加密一次文件,就能够留下其特殊的标记,从而在检查信息储存平台上储存的合约文件时,签约人能够凭借签约平台和监管平台的数字签名,确定合约文件的真实性和合法性,所以能够增加签约平台所领导的签约活动的公信力。
签约终端在发送签约请求时,根据加密算法自动生成秘钥对(Pu,Pe),Pu为公钥,Pe为私钥。签约终端在签约请求发送时所生成的密钥对,进而在核对合约文件时,能够核对里面的密钥对是否为初始生成的密钥对。
作为本申请的第二个方面,本申请的一些实施例还提供如下技术方案:一种基于第三方认证的电子合约签署方法,其特征在于:包括如下步骤:
步骤1:签约终端向签约平台发送包括身份信息的签约请求;
步骤2:签约平台验证签约请求并生成合约签署请求,并将合约签署请求发送至监管平台;
步骤3:监管平台在对合约签署请求核对之后,生成合约文件,并将合约文件发送至签约平台;
步骤4:签约平台将合约文件发送至信息储存平台;同时,签约平台利用合约文件生成电子合约,然后将电子合约分别发送至监管平台和签约终端;
步骤5:签约终端下载信息储存平台上的合约文件,将合约文件和电子合约进行对比,以证明电子合约的真实性。
步骤1包括:
步骤101:预设加密算法,并将加密算法分别储存至签约终端、签约平台、监管平台,以及信息储存平台;
步骤102:签约平台根据加密算法预设一对秘钥(Eu,Ee),Eu为公钥,Ee为私钥;Eu广播至签约终端、监管平台以及信息储存平台;
监管平台根据加密算法预设一对秘钥(Hu,He),Hu为公钥,He为私钥,Hu广播至签约终端、签约平台以及信息储存平台;
步骤103:签约终端向签约平台发送签约请求Reg,签约终端在发送签约请求时,根据加密算法自动生成秘钥对(Pu,Pe),Pu为公钥,Pe为私钥;
Reg=Ei(Pe,ID,t,Spe)
其中Ei表示以Eu作为加密参数的加密算法,ID表示合约编码,t表示签约请求发送的时间戳,Spe表示以Pu作为加密参数的加密算法,Spe加密的信息为身份信息。采用加密算法自动生成密钥对到签约请求内,进而可以在核对合约文件时,判断提出签约请求时的密钥和下载的合约文件中的密钥是否对应,来核对合约文件的真实性,进而对于签约人而言,能够在核对合约文件时,具有自身预审的对应关系,来进一步验证电子合约的真实性,增加了签约人在签订电子合约时的地位。
步骤2具体包括如下步骤:
步骤201:签约平台采用私钥Ee解密签约请求Reg得到Pe,ID,t,Spe,然后再使用Pe解密Spe,得到签约请求中的身份信息,并且签约平台储存私钥Pe;;
步骤202:签约平台依据签约请求生成合约签署请求Heg;签约平台向监管平台发送合约签署请求Heg;
Heg=Hi(Pe,ID,t,Spe,Eep),Hi表示以Hu作为加密参数的加密算法,Eep表示以Ee作为加密参数的加密算法,Eep解密后的信息为签约平台的数字签名。
签约平台在确认签约人信息无误之后,再发送签约签署请求,可以避免向监管平台发送过多无效的签约签署请求;同时,采用监管平台的公钥加密文件,可以保证只有监管平台才能够查阅文件,增加了数据的安全性,避免非法人员获取合约签署请求而破译其中的信息。
步骤3具体包括如下步骤:
步骤301:监管平台采用He解密合约签署请求Heg得到Pe,ID,t,Spe,Eep,然后再使用Eu解密Eep,以验证信息来源的身份,信息核验正确之后,监管平台根据合约签署请求Heg生成合约文件Jeg。
步骤302:监管平台向签约平台发送合约文件Jeg;
Jeg=Hep(Pe,ID,t,Spe,Eep,Hs),Hep表示以He作为加密参数的加密算法,签约平台采用公钥Hu解密合约文件Jeg得到Pe,ID,t,Spe,Eep,Hs,其中Hs表示监管平台的数字签名。
监管平台在解密合约签署请求Heg时,还会进一步验证数据签名,保证了数据来源的真实性。同时,监管平台采用私钥加密合约文件Jeg,进而能够证明合约文件是来源与监管平台,所以生成的合约文件内就具有了监管平台与签约平台数字签名。
步骤4具体包括如下步骤:
步骤41:签约平台采用Hu解密合约文件Jeg,得到ID,t,Spe,Eep,并用前面保存的私钥Pe解密Spe以再一次验证合约文件和签约请求的对应关系,并核对合约文件Jeg的内容,核对无误之后,将合约文件Jeg发送至信息储存平台;
步骤42:签约平台依据合约文件Jeg的内容,自动生成完整的电子合约;
步骤43:签约平台将完整的电子合约分别发送至签约终端和监管平台;
步骤44:监管平台根据合约编码ID 将不同的电子合约储存至不同的数据库中。
根据合约编码ID,将电子合约储存到不同的数据库中,便于对不同类型的电子合约进行分类管理,以让相关监管机构快速获取需要的电子合约,所以在引入第三方监管机构时,能够准确高效的引入相关部门进行监管。同时,信息储存平台上不储存完整的电子合约,所以电子合约只在监管平台、签约平台以及签约终端三个地方存在备份,避免了信息储存平台这一储存信息的平台在信息泄露之后,大量完整的电子合约泄露。
步骤5具体为:
签约终端在信息储存平台上下载相应的合约文件Jeg并采用Hu解密Jeg,以得到ID,t,Spe,Eep,Hs,然后对这些数据进行验证,以确定电子合约的真实性。在验证这些数据时,需要采用预设的私钥来解密身份信息Spe,所以避免外界人员非法获取信息储存平台的信息,而导致用户信息大量泄露,增加了数据的安全性。
本申请的有益效果在于提供了一种能够引入第三方进行监管的基于第三方认证的电子合约签署装置和方法。
附图说明
构成本申请的一部分的附图用来提供对本申请的进一步理解,使得本申请的其它特征、目的和优点变得更明显。本申请的示意性实施例附图及其说明用于解释本申请,并不构成对本申请的不当限定。
另外,贯穿附图中,相同或相似的附图标记表示相同或相似的元素。应当理解附图是示意性的,元件和元素不一定按照比例绘制。
在附图中:
图1为本申请的一些实施例中提供的基于第三方认证的电子合约签署装置的结构示意图。
图2为基于第三方认证的电子合约签署装置内数据传输方向的示意图。
图3为本申请的一些实施例中提供的基于第三方认证的电子合约签署放大的流程图。
图4为签约终端发送签约请求的流程图。
图5为签约平台验证签约请求并发送合约签署请求的流程图。
图6为监管平台验证合约签署请求并发送合约文件的流程图。
图7为签约平台根据合约文件生成电子合约并分化电子合约和合约文件的流程图。
具体实施方式
下面将参照附图更详细地描述本公开的实施例。虽然附图中显示了本公开的某些实施例,然而应当理解的是,本公开可以通过各种形式来实现, 而且不应该被解释为限于这里阐述的实施例。相反,提供这些实施例是为了更加透彻和完整地理解本公开。应当理解的是,本公开的附图及实施例仅用于示例性作用,并非用于限制本公开的保护范围。
另外还需要说明的是,为了便于描述,附图中仅示出了与有关发明相关的部分。在不冲突的情况下,本公开中的实施例及实施例中的特征可以相互组合。
下面将参考附图并结合实施例来详细说明本公开。
参照图1~7,基于第三方认证的电子合约签署装置包括签约平台、监管平台、签约终端,以及信息储存平台。其中,签约平台和签约终端信号连接,监管平台和签约平台信号连接,签约平台与信息储存平台信号连接,签约终端与信息储存平台信号连接。
签约终端向签约平台发送包括身份信息的签约请求,签约平台验证签约请求并生成合约签署请求,并将合约签署请求发送至监管平台,监管平台在对合约签署请求核对之后,生成合约文件,并将合约文件发送至签约平台,签约平台将合约文件发送至信息储存平台;同时,签约平台利用合约文件生成电子合约,然后将电子合约分别发送至监管平台和签约终端,签约终端下载信息储存平台上的合约文件,以验证电子合约的真实性。
本申请所提供的技术方案中,签约平台广播到信息储存平台中的合约文件除开需要签约平台自身进行验证和核对之外,还需要发送至监管平台,在取得监管平台授权之后,签约平台才能够发布合约文件,所以通过签约终端与签约平台签订的合约文件能够很好的引入第三方的监管机构对合约文件的真实性进行监管,避免签约平台占据优势地位而影响签约人的合法权益。
签约人通过签约终端输入身份信息以在签约终端形成签约请求,然后将签约请求发送至签约平台。身份信息为表征签约人信息的证明信息,如果是自然人与签约平台签订合约,则身份信息至少需要包括自然人的身份证扫描件信息、生物特征信息(如指纹、虹膜、面容等),如果不是自然人与签约平台签订信息,则身份信息需要包括社会信用代码以及公章扫描件等信息。
因为签约平台和用户需要签订的合约通常具有多种,所以签约请求还需要包括合约编码,每种合约编码对应一种类型的电子合约。例如签约人通过签约终端和签约平台签订零售合作的电子合约,签约人和签约平台签订劳务合作的电子合约。
电子合约签署装置预设加密算法,加密算法在签约平台、签约终端、监管平台以及信息储存平台均有储存。加密算法可以为任意一种用于数据加密的算法。例如,椭圆加密算法。
签约平台根据加密算法预设一对秘钥(Eu,Ee),Eu为公钥,Ee为私钥,Eu广播至签约终端、监管平台以及信息储存平台。
监管平台根据加密算法预设一对秘钥(Hu,He),Hu为公钥,He为私钥,Hu广播至签约终端、签约平台以及信息储存平台。
签约终端在发送签约请求时,根据加密算法自动生成秘钥对(Pu,Pe),Pu为公钥,Pe为私钥;签约终端向签约平台发送签约请求Reg。
Reg=Ei(Pe,ID,t,Spe)
其中Ei表示以公钥Eu作为加密参数的加密算法,ID表示合约编码,t表示签约请求发送的时间戳,Spe表示以Pu作为加密参数的加密算法,Spe加密的信息为身份信息。
更进一步的,为了便于管理签约请求,签约请求在生成时,还会自动生成一串签约编码,签约编码并没有进行加密,而是用于标记签约请求。
签约终端发送至签约平台的签约请求为如下表格:
签约编码 | 签约请求 |
H00XX1 | Reg(1) |
H00XX2 | Reg(2) |
…… | …… |
签约平台在接收到签约请求Reg之后,采用私钥Ee解密签约请求Reg得到Pe,ID,t,Spe,然后再使用私钥Pe解密Spe,得到签约请求中的身份信息。签约平台和签约终端均储存此次签约平台的私钥Pe。
签约平台依据签约请求生成合约签署请求Heg,签约平台向签约终端发送合约签署请求Heg。
Heg=Hi(Pe,ID,t,Spe,Eep),Hi表示以公钥Hu作为加密参数的加密算法,Eep表示以私钥Ee作为加密参数的加密算法,Eep解密后的信息为签约平台的数字签名。相应的签署请求也通过上述的签约编码进行标记。
签约平台发送至监管平台的签约请求为如下表格:
签约编码 | 签约请求 |
H00XX1 | Heg(1) |
H00XX2 | Heg(2) |
…… | …… |
监管平台采用He解密合约签署请求Heg得到Pe,ID,t,Spe,Eep,然后再使用公钥Eu解密Eep验证信息来源的身份,在信息核对完毕之后,监管平台生成合约文件Jeg,然后监管平台向签约平台发送合约文件Jeg。
Jeg=Hep(ID,t,Spe,Eep,Hs),Hep表示以私钥He作为加密参数的加密算法,签约平台采用公钥Hu解密合约文件Jeg得到ID,t,Spe,Eep,Hs,其中Hs表示监管平台的数字签名。签约平台采用该数字签名Hs能够确认信息的来源。
相应的合约文件也通过上述的签约编码进行标记。
监管平台发送至签约平台的签约请求为如下表格:
签约编码 | 签约请求 |
H00XX1 | Jeg(1) |
H00XX2 | Jeg(2) |
…… | …… |
签约平台采用公钥Hu解密合约文件Jeg,得到ID,t,Spe,Eep,并用前面保存的私钥Pe解密Spe以再一次验证合约文件和签约请求的对应关系。核对无误之后,将合约文件Jeg发送至信息储存平台。同时,签约平台依据合约文件Jeg的内容,自动生成完整的电子合约,然后将完整的电子合约分别发送至签约终端和监管平台。完整的电子合约是指,将签约人的身份信息填写到合约模板内之后,所形成的电子文件。
签约终端在接收电子合约之后,在信息储存平台上下载相应的合约文件Jeg,并采用公钥Hu解密合约文件Jeg,以得到ID,t,Spe,Eep,Hs,然后对这些数据进行验证,以确定电子合约的真实性。
在下载合约文件时,可以通过初始过程中生成的签约编码查找。并且,在查询合约文件时,除开可以核对签约平台与电子平台的数字签名,还可以通过采用自身的私钥Pe解密合约文件中的文件Spe以进一步验证身份信息是否和自己的对应。并且合约文件中没有私钥Pe,所以可以避免其余的签约人恶意获取签约平台上的储存数据,导致签约人身份信息大规模泄露。
本实施例提供的电子合约签署装置,在实际使用中,引入了第三方机构对合约的真实性进行监管,增加了对于签约平台的监管力度,保障了签约人的合法权益。
但是在对电子合约的监管中,不同的监管机构需要监管的合约内容并不一致。例如,签约平台和签约人签订的是劳动合约,则该电子合约应当需要到管理劳务部门的机构监管;如果签约平台和签约人签订的是零售合约,则必然需要工商部门对该电子合约进行监管。
监管平台设置有多个数据储存库,每个数据储存库储存一种类型的电子合约。电子合约的类型通过合约编码ID进行分类,相同合约编码ID的电子合约作为一类。例如,某零售电子合约,其合约编码为0527,则所有的合约编码为0527的电子合约都储存在同一个数据库内。所以,监管平台在采用该方式对数据进行分类和整理时,能够让不同的机构接入至监管平台中数据库的信息时,查询和监管效率更高,并且还避免了电子合约无法及时备份的问题。
本申请所提供技术方案,除开可以运用于签约人和签约平台签订电子合约之外,还可以让签约平台作为第三方的电子合约。也就是两个需要签订合约的签约人均通过签约终端向签约平台发送签约请求。签约平台在接收到两个签约人的签约请求之后,同样可以生成合约签署请求,合约签署请求内只需要再包含两个签约人加密的信息既可。因为在签约人和签约平台签订电子合约时,默认将合同的甲方或者乙方设置为了签约平台,但实际上,可以在签约终端上传两个签约人的身份信息,以实现借助签约终端的两方自然人签订电子合约。
例如,合约签署请求Heg=Hi(Pe,ID,t,Spe,Eep,Pe’,Spe’),其中Pe和Spe为甲方的私钥和身份信息,Pe’和Spe’为乙方的私钥和身份信息。以此类推,采用签署的方式,也能够让两个签约人借助签约平台自动签订电子合约。所以,签约平台在经营中,能够开发出更多的经营合作模式,一方面和平台下辖的用户签订合约,另一方面还可以让平台之间的用户提供足够信任的合同签订平台。
本申请还提供了一种基于第三方认证的电子合约签署方法,使用上述的基于第三方认证的电子合约签署装置。所述的基于第三方认证的电子合约签署方法包括如下步骤:
步骤1:签约终端向签约平台发送包括身份信息的签约请求。
步骤1具体包括如下步骤:
步骤101:预设加密算法,并将加密算法分别储存至签约终端、签约平台、监管平台,以及信息储存平台。
步骤101中,加密算法可以为椭圆算法。
步骤102:签约平台根据加密算法预设一对秘钥(Eu,Ee),Eu为公钥,Ee为私钥;Eu广播至签约终端、监管平台以及信息储存平台。
监管平台根据加密算法预设一对秘钥(Hu,He),Hu为公钥,He为私钥,Hu广播至签约终端、签约平台以及信息储存平台。
步骤103:签约终端向签约平台发送签约请求Reg,签约终端在发送签约请求时,根据加密算法自动生成秘钥对(Pu,Pe),Pu为公钥,Pe为私钥;
Reg=Ei(Pe,ID,t,Spe)
其中Ei表示以Eu作为加密参数的加密算法,ID表示合约编码,t表示签约请求发送的时间戳,Spe表示以Pu作为加密参数的加密算法,Spe加密的信息为身份信息。
步骤103中,签约终端在发送签约请求时还自动生成用于标记签约请求的签约编码,并且签约编码连同签约请求发送至签约平台。
步骤2:签约平台验证签约请求并生成合约签署请求,并将合约签署请求发送至监管平台。
步骤2具体包括如下步骤:
步骤201:签约平台采用私钥Ee解密签约请求Reg得到Pe,ID,t,Spe,然后再使用Pe解密Spe,得到签约请求中的身份信息,并且签约平台储存私钥Pe。
步骤202:签约平台依据签约请求生成合约签署请求Heg;签约平台向监管平台发送合约签署请求Heg;
Heg=Hi(Pe,ID,t,Spe,Eep),Hi表示以Hu作为加密参数的加密算法,Eep表示以Ee作为加密参数的加密算法,Eep解密后的信息为签约平台的数字签名。
步骤3:监管平台在对合约签署请求核对之后,生成合约文件,并将合约文件发送至签约平台。
步骤3具体包括如下步骤:
步骤301:监管平台采用He解密合约签署请求Heg得到Pe,ID,t,Spe,Eep,然后再使用Eu解密Eep,以验证信息来源的身份,信息核验正确之后,监管平台根据合约签署请求Heg生成合约文件Jeg。
步骤302:监管平台向签约平台发送合约文件Jeg;
Jeg=Hep(ID,t,Spe,Eep,Hs),Hep表示以He作为加密参数的加密算法,签约平台采用公钥Hu解密合约文件Jeg得到ID,t,Spe,Eep,Hs,其中Hs表示监管平台的数字签名。
步骤4:签约平台将合约文件发送至信息储存平台;同时,签约平台利用合约文件生成电子合约,然后将电子合约分别发送至监管平台和签约终端。
步骤4具体包括如下步骤:
步骤41:签约平台采用Hu解密合约文件Jeg,得到ID,t,Spe,Eep,并用前面保存的私钥Pe解密Spe以再一次验证合约文件和签约请求的对应关系,核对无误之后,将合约文件Jeg发送至信息储存平台。
步骤42:签约平台依据合约文件Jeg的内容,自动生成完整的电子合约。
完整的电子合约是指,将签约人的身份信息填写到合约模板内之后,所形成的电子文件。
步骤43:签约平台将完整的电子合约分别发送至签约终端和监管平台。
步骤44:监管平台根据合约编码ID 将不同的电子合约储存至不同的数据库中。
步骤5:签约终端下载信息储存平台上的合约文件,将合约文件和电子合约进行对比,以证明电子合约的真实性。
步骤5具体为:
签约终端在信息储存平台上下载相应的合约文件Jeg并采用Hu解密合约文件Jeg,以得到ID,t,Spe,Eep,Hs,然后对这些数据进行验证。并且,通过采用自身的私钥Pe解密合约文件中的文件Spe以进一步验证身份信息是否和自己的对应。
步骤1~5中,采用签约编码区分不同签约请求生成的合约签署请求、合约文件,以及电子合约,所以在步骤51中,只需要采用合约编码就能够找到相互对应的合约文件。
以上描述仅为本公开的一些较佳实施例以及对所运用技术原理的说明。本领域技术人员应当理解,本公开的实施例中所涉及的发明范围,并不限于上述技术特征的特定组合而成的技术方案,同时也应涵盖在不脱离上述发明构思的情况下,由上述技术特征或其等同特征进行任意组合而形成的其它技术方案。例如上述特征与本公开的实施例中公开的(但不限于)具有类似功能的技术特征进行互相替换而形成的技术方案。
Claims (10)
1.一种基于第三方认证的电子合约签署装置,其特征在于,包括:签约平台、监管平台、签约终端,以及信息储存平台;其中,签约平台和签约终端信号连接,监管平台和签约平台信号连接,签约平台与信息储存平台信号连接,签约终端与信息储存平台信号连接;
签约终端向签约平台发送包括身份信息的签约请求,签约平台验证签约请求并生成合约签署请求,并将合约签署请求发送至监管平台,监管平台在对合约签署请求核对之后,生成合约文件,并将合约文件发送至签约平台,签约平台将合约文件发送至信息储存平台;同时,签约平台利用合约文件生成电子合约,然后将电子合约分别发送至监管平台和签约终端,签约终端下载信息储存平台上的合约文件,以验证电子合约的真实性。
2.根据权利要求1所述的基于第三方认证的电子合约签署装置,其特征在于:签约请求还包括合约编码,每种合约编码对应一种类型的电子合约模板。
3.根据权利要求1所述的基于第三方认证的电子合约签署装置,其特征在于:预设加密算法,签约平台根据加密算法预设一对秘钥(Eu,Ee),Eu为公钥,Ee为私钥,Eu广播至签约终端、监管平台以及信息储存平台;监管平台根据加密算法预设一对秘钥(Hu,He),Hu为公钥,He为私钥,Hu广播至签约终端、签约平台以及信息储存平台。
4.根据权利要求1所述的基于第三方认证的电子合约签署装置,其特征在于:签约终端在发送签约请求时,根据加密算法自动生成秘钥对(Pu,Pe),Pu为公钥,Pe为私钥。
5.一种基于第三方认证的电子合约签署方法,其特征在于:包括如下步骤:
步骤1:签约终端向签约平台发送包括身份信息的签约请求;
步骤2:签约平台验证签约请求并生成合约签署请求,并将合约签署请求发送至监管平台;
步骤3:监管平台在对合约签署请求核对之后,生成合约文件,并将合约文件发送至签约平台;
步骤4:签约平台将合约文件发送至信息储存平台;同时,签约平台利用合约文件生成电子合约,然后将电子合约分别发送至监管平台和签约终端;
步骤5:签约终端下载信息储存平台上的合约文件,将合约文件和电子合约进行对比,以证明电子合约的真实性。
6.根据权利要求5所述的基于第三方认证的电子合约签署方法,其特征在于:步骤1包括:
步骤101:预设加密算法,并将加密算法分别储存至签约终端、签约平台、监管平台,以及信息储存平台;
步骤102:签约平台根据加密算法预设一对秘钥(Eu,Ee),Eu为公钥,Ee为私钥;Eu广播至签约终端、监管平台以及信息储存平台;
监管平台根据加密算法预设一对秘钥(Hu,He),Hu为公钥,He为私钥,Hu广播至签约终端、签约平台以及信息储存平台;
步骤103:签约终端向签约平台发送签约请求Reg,签约终端在发送签约请求时,根据加密算法自动生成秘钥对(Pu,Pe),Pu为公钥,Pe为私钥;
Reg=Ei(Pe,ID,t,Spe)
其中Ei表示以Eu作为加密参数的加密算法,ID表示合约编码,t表示签约请求发送的时间戳,Spe表示以Pu作为加密参数的加密算法,Spe加密的信息为身份信息。
7.根据权利要求6所述的基于第三方认证的电子合约签署方法,其特征在于:步骤2具体包括如下步骤:
步骤201:签约平台采用私钥Ee解密签约请求Reg得到Pe,ID,t,Spe,然后再使用Pe解密Spe,得到签约请求中的身份信息,并且签约平台储存私钥Pe;
步骤202:签约平台依据签约请求生成合约签署请求Heg;签约平台向监管平台发送合约签署请求Heg;
Heg=Hi(Pe,ID,t,Spe,Eep),Hi表示以Hu作为加密参数的加密算法,Eep表示以Ee作为加密参数的加密算法,Eep解密后的信息为签约平台的数字签名。
8.根据权利要求7所述的基于第三方认证的电子合约签署方法,其特征在于:步骤3具体包括如下步骤:
步骤301:监管平台采用He解密合约签署请求Heg得到Pe,ID,t,Spe,Eep,然后再使用Eu解密Eep,以验证信息来源的身份,信息核验正确之后,监管平台根据合约签署请求Heg生成合约文件Jeg;
步骤302:监管平台向签约平台发送合约文件Jeg;
Jeg=Hep(ID,t,Spe,Eep,Hs),Hep表示以He作为加密参数的加密算法,签约平台采用公钥Hu解密合约文件Jeg得到ID,t,Spe,Eep,Hs,其中Hs表示监管平台的数字签名。
9.根据权利要求8所述的基于第三方认证的电子合约签署方法,其特征在于:步骤4具体包括如下步骤:
步骤41:签约平台采用Hu解密合约文件Jeg,得到ID,t,Spe,Eep,并用前面保存的私钥Pe解密Spe以再一次验证合约文件和签约请求的对应关系,并核对合约文件Jeg的内容,核对无误之后,将合约文件Jeg发送至信息储存平台;
步骤42:签约平台依据合约文件Jeg的内容,自动生成完整的电子合约;
步骤43:签约平台将完整的电子合约分别发送至签约终端和监管平台;
步骤44:监管平台根据合约编码ID 将不同的电子合约储存至不同的数据库中。
10.根据权利要求9所述的基于第三方认证的电子合约签署方法,其特征在于:步骤5具体为:
签约终端在信息储存平台上下载相应的合约文件Jeg并采用Hu解密合约文件Jeg,以得到ID,t,Spe,Eep,Hs,然后对这些数据进行验证,以确定电子合约的真实性。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202211682570.4A CN115664867B (zh) | 2022-12-27 | 2022-12-27 | 基于第三方认证的电子合约签署装置和方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202211682570.4A CN115664867B (zh) | 2022-12-27 | 2022-12-27 | 基于第三方认证的电子合约签署装置和方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN115664867A true CN115664867A (zh) | 2023-01-31 |
CN115664867B CN115664867B (zh) | 2023-04-07 |
Family
ID=85022371
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202211682570.4A Active CN115664867B (zh) | 2022-12-27 | 2022-12-27 | 基于第三方认证的电子合约签署装置和方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN115664867B (zh) |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN117336099A (zh) * | 2023-11-22 | 2024-01-02 | 成都天府通数字科技有限公司 | 基于区块链技术的智能合约的签署方法和签署系统 |
CN117372050A (zh) * | 2023-12-07 | 2024-01-09 | 成都天府通数字科技有限公司 | 多平台的订单核销验证的方法和系统 |
TWI835652B (zh) * | 2023-05-17 | 2024-03-11 | 中華電信股份有限公司 | 電子文件授權簽署系統、方法及其電腦可讀媒介 |
Citations (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN105635169A (zh) * | 2016-01-26 | 2016-06-01 | 葛峰 | 一种基于互联网的电子合同签署方法 |
CN106850233A (zh) * | 2017-03-09 | 2017-06-13 | 江苏慧世联网络科技有限公司 | 一种多机构可外包的电子合同签署和管理方法 |
EP3316162A1 (en) * | 2016-10-25 | 2018-05-02 | INFOCERT S.p.A. | Metodo e sistema di creazione di una firma elettronica di un documento associata ad una persona mediante l'impronta vocale della persona stessa e relativo metodo di verifica della firma elettronica |
CN109919579A (zh) * | 2019-02-27 | 2019-06-21 | 上海棕榈电脑系统有限公司 | 电子文书签约方法、装置、存储介质和设备 |
CN110674523A (zh) * | 2019-09-30 | 2020-01-10 | 民生科技有限责任公司 | 一种数字签名结合手写签名确认电子合同签署人的方法 |
CN111651521A (zh) * | 2020-05-27 | 2020-09-11 | 山大地纬软件股份有限公司 | 一种电子合同区块链结构、电子合同签署装置及方法 |
CN113824564A (zh) * | 2021-09-17 | 2021-12-21 | 江苏通付盾科技有限公司 | 一种基于区块链的线上签约方法及系统 |
CN115065480A (zh) * | 2022-06-08 | 2022-09-16 | 策拉控股云南有限公司 | 一种基于区块链存证的电子合同系统及签约方法 |
CN115361233A (zh) * | 2022-10-20 | 2022-11-18 | 中国信息通信研究院 | 基于区块链的电子文件签署方法、装置、设备和介质 |
-
2022
- 2022-12-27 CN CN202211682570.4A patent/CN115664867B/zh active Active
Patent Citations (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN105635169A (zh) * | 2016-01-26 | 2016-06-01 | 葛峰 | 一种基于互联网的电子合同签署方法 |
EP3316162A1 (en) * | 2016-10-25 | 2018-05-02 | INFOCERT S.p.A. | Metodo e sistema di creazione di una firma elettronica di un documento associata ad una persona mediante l'impronta vocale della persona stessa e relativo metodo di verifica della firma elettronica |
CN106850233A (zh) * | 2017-03-09 | 2017-06-13 | 江苏慧世联网络科技有限公司 | 一种多机构可外包的电子合同签署和管理方法 |
CN109919579A (zh) * | 2019-02-27 | 2019-06-21 | 上海棕榈电脑系统有限公司 | 电子文书签约方法、装置、存储介质和设备 |
CN110674523A (zh) * | 2019-09-30 | 2020-01-10 | 民生科技有限责任公司 | 一种数字签名结合手写签名确认电子合同签署人的方法 |
CN111651521A (zh) * | 2020-05-27 | 2020-09-11 | 山大地纬软件股份有限公司 | 一种电子合同区块链结构、电子合同签署装置及方法 |
CN113824564A (zh) * | 2021-09-17 | 2021-12-21 | 江苏通付盾科技有限公司 | 一种基于区块链的线上签约方法及系统 |
CN115065480A (zh) * | 2022-06-08 | 2022-09-16 | 策拉控股云南有限公司 | 一种基于区块链存证的电子合同系统及签约方法 |
CN115361233A (zh) * | 2022-10-20 | 2022-11-18 | 中国信息通信研究院 | 基于区块链的电子文件签署方法、装置、设备和介质 |
Non-Patent Citations (1)
Title |
---|
徐睿;孟祥君;马锋;赵希超;游佳;张子谦;: "基于防篡改技术的电子签约服务平台" * |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
TWI835652B (zh) * | 2023-05-17 | 2024-03-11 | 中華電信股份有限公司 | 電子文件授權簽署系統、方法及其電腦可讀媒介 |
CN117336099A (zh) * | 2023-11-22 | 2024-01-02 | 成都天府通数字科技有限公司 | 基于区块链技术的智能合约的签署方法和签署系统 |
CN117336099B (zh) * | 2023-11-22 | 2024-02-09 | 成都天府通数字科技有限公司 | 基于区块链技术的智能合约的签署方法和签署系统 |
CN117372050A (zh) * | 2023-12-07 | 2024-01-09 | 成都天府通数字科技有限公司 | 多平台的订单核销验证的方法和系统 |
CN117372050B (zh) * | 2023-12-07 | 2024-02-20 | 成都天府通数字科技有限公司 | 多平台的订单核销验证的方法和系统 |
Also Published As
Publication number | Publication date |
---|---|
CN115664867B (zh) | 2023-04-07 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN115664867B (zh) | 基于第三方认证的电子合约签署装置和方法 | |
US10404455B2 (en) | Multiple-phase rewritable blockchain | |
US10348707B2 (en) | Rewritable blockchain | |
CN109858262B (zh) | 基于区块链系统的流程审批方法、装置、系统及存储介质 | |
CN101535845B (zh) | 认证射频识别及其密钥分配系统 | |
CN108933667B (zh) | 一种基于区块链的公钥证书的管理方法及管理系统 | |
CN113034128B (zh) | 一种基于区块链的数据交易及确权的方法 | |
CN112565265B (zh) | 物联网终端设备间的认证方法、认证系统及通讯方法 | |
CN113676332B (zh) | 二维码认证方法、通信设备及存储介质 | |
CN114780923B (zh) | 一种电子印章的管控方法及系统 | |
CN111539496A (zh) | 车辆信息二维码生成方法、二维码车牌、认证方法及系统 | |
CN112398920A (zh) | 一种基于区块链技术的医疗隐私数据保护方法 | |
CN110457928B (zh) | 基于区块链的医企协作互联网医院数据安全保障方法 | |
CN115225346B (zh) | 一种面向征信大数据领域的数据存证系统 | |
CN108322311B (zh) | 数字证书的生成方法及装置 | |
CN113312640B (zh) | 一种基于可信计算的软件数据完整性多方共识方法 | |
CN114491591A (zh) | 一种匿踪查询的数据使用授权方法、设备、存储介质 | |
CN110880969B (zh) | 基于联盟链和隐式证书的qkd网络认证密钥生成方法及系统 | |
CN110113152B (zh) | 基于非对称密钥池对和数字签名的量子通信服务站密钥协商方法和系统 | |
CN112634307A (zh) | 一种基于区块链的数据分发方法及装置 | |
JP3583987B2 (ja) | 電子認証方法及び電子認証装置 | |
CN112528237B (zh) | 一种基于共识机制的软件版本状态保护方法 | |
CN117373599B (zh) | 基于区块链的医疗信息共享系统及方法 | |
CN114385987A (zh) | 一种动态多因子身份鉴权和认证的方法及存储介质 | |
CN118115112A (zh) | 线上签约方法、装置及设备 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |