CN104135368A - 一种电子海图的数据保护方法 - Google Patents
一种电子海图的数据保护方法 Download PDFInfo
- Publication number
- CN104135368A CN104135368A CN201410234812.2A CN201410234812A CN104135368A CN 104135368 A CN104135368 A CN 104135368A CN 201410234812 A CN201410234812 A CN 201410234812A CN 104135368 A CN104135368 A CN 104135368A
- Authority
- CN
- China
- Prior art keywords
- data
- oem
- pki
- equipment manufacturers
- key
- 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
Abstract
本发明涉及一种电子海图的数据保护方法,策略管理者SA向设备制造商OEM签发OEM数字证书和颁发身份标识M_ID;设备制造商OEM和数据服务商DS之间的建立连接,数据服务方DS获得设备制造商OEM的公钥M_PKEY,获得数据服务方DS的公钥;设备制造商OEM为数据客户端颁发硬件标示符HW_ID,并制作用户许可证;数据客户端将用户许可证通过数据服务方DS的公钥进行加密后递交数据服务方DS;数据服务方DS利用自己的私钥解密用户许可证,根据获得的M_ID查找对应的设备制造商OEM的公钥M_PKEY,用公钥M_PKEY解密用户许可证中硬件标识符HW_ID部分,从而得到数据客户端的硬件标识符HW_ID,通过硬件标识符HW_ID加密单元密钥,为数据客户端生成单元许可,从而向数据客户端提供电子海图数据服务。
Description
技术领域
本发明涉及一种电子海图的数据保护方法。
背景技术
随着航海技术现代化程度的日益提高和计算机技术的逐渐成熟,ECDIS在航海中得到了广泛应用。由于ENC(电子海图)数据是ECDIS平台显示的基础,所以确保ENC数据的时效性以及安全性成为ECDIS在应用过程中的首要问题。数据服务方为了确保发送给用户数据的安全性和完整性,都采取了相应的保护措施,但由于这些措施各不相同,降低了ENC数据的更新速度,影响了船舶航行安全,为了解决这个问题,国际海道测量组织(IHO)制定了保护ENC数据的国际标准即S63数据保护标准,该标准是基于密码技术的数据安全服务。数据安全服务是一系列的机制,过程以及其他的控制措施,它们的实施有助于减少有关数据丢失或损害的风险。该标准不仅能保护ENC数据生产商的利益和合法权益,而且能够大大的提高航海安全。
IHO S63数据保护策略规定了各方参与者在对ENC基础图元和更新图元进行保护的时候,应具备的职责和功能,从保密性、完整性、可认证性和不可否认性四个方面,提高了对于ENC的传播以及使用的安全性。整个S63数据保护方案的组成和工作流程,如图1所示。
方案的流程分析:
(1)策略管理者(Schema Administrator,SA)由IHO的IHB(InternationalHydrographic Bureau,国际海道测量局)担任,是整个保护策略的最高层权威机构,负责整个保护策略的维护和协调,认证并为所有的数据服务方颁发证书,认证并为所有的设备制造商颁发标识(M_ID)和密钥(M_KEY)。
(2)数据服务方(Data Server,DS)由各国或地方的海事局担任,由SA认证并持有SA颁发的证书,负责海道测量和ENC制作工作,数据服务方从数据客户方获得用户许可,解密获取HW_ID用来加密单元密钥为数据客户方生成单位许可,向数据客户提供ENC服务。
(3)设备制造商(Original Equipment Manufacturer,OEM)是ENC系统设备的生成厂商,由SA认证,管理员SA提供给各制造商唯一的制造商密钥M_KEY和标识符M_ID,同时制造商必须在其软件里安装唯一的硬件标识符HW_ID来唯一识别出每个最终用户,即在软件系统中提供安全机制,向数据客户提供ENC系统设备和应用许可。
(4)数据客户方(Data Client,DC)是ECS或ECDIS的使用方,向OEM购买ENC系统设备和应用许可证书,通过应用许可向DS申请ENC服务。
从上述的流程分析中可知,M_ID用于公开标识设备制造商OEM的身份,M_KEY用于加密硬件标示符HW_ID并在解密时有标识身份的作用,M_ID和M_KEY均由管理员SA创建并记录。纵观整个保护方案,管理员SA,数据服务方DS,设备制造商OEM,均能得到M_KEY的明文信息,如果M_KEY从其中任何一方泄漏,攻击者就可以利用M_KEY伪造用户许可证,从数据服务方处骗取加密的ENC数据,由于SA采用公钥密码体制,这样攻击者就可以利用SA的公钥顺利的获得ENC明文数据,使得方案面临着授权侵犯,窃听,信息泄露,否认等安全威胁。另外如果有恶意攻击者,利用M_KEY频繁的向特定的数据服务方发送用户许可证,将会造成了数据服务方系统的阻塞,从而使得合法的数据客户方无法获取ENC服务,对数据保护方案造成重放攻击和拒绝服务攻击。在这些情况之下,整个数据保护方案也就从理论上失效了,所以说M_KEY是整个IHO S-63数据保护方案中的关键安全因素。
发明内容
本发明目的在于提供一种电子海图的数据保护方法,能够在不可靠的数据存储和网络通信上实现设备制造商OEM密钥的安全保护,有效提高了IHO S63数据保护策略的安全性。
实现本发明目的技术方案:
一种电子海图的数据保护方法,基于IHO S63电子海图数据保护策略,包括策略管理者SA、数据服务方DS、设备制造商OEM和数据客户端,其特征在于:
步骤1:策略管理者SA向设备制造商OEM签发OEM数字证书和颁发身份标识M_ID;
步骤2:设备制造商OEM向数据服务方DS递交自己的OEM数字证书和身份标识M_ID,数据服务方DS利用策略管理者SA的公钥解密OEM数字证书,获得设备制造商OEM的公钥M_PKEY;数据服务方DS向设备制造商OEM发送自己的DS数字证书,设备制造商OEM利用策略管理者SA的公钥解密DS数字证书,获得数据服务方DS的公钥;
步骤3:设备制造商OEM为数据客户端颁发硬件标示符HW_ID,并制作用户许可证;数据客户端将用户许可证通过数据服务方DS的公钥进行加密后递交数据服务方DS;数据服务方DS利用自己的私钥解密用户许可证,根据获得的M_ID查找对应的设备制造商OEM的公钥M_PKEY,用公钥M_PKEY解密用户许可证中硬件标识符HW_ID部分,得到数据客户端的硬件标识符HW_ID,数据服务方DS通过硬件标识符HW_ID加密单元密钥,为数据客户端生成单元许可,从而向数据客户端提供电子海图数据服务。
步骤1中,策略管理者SA向设备制造商OEM签发OEM数字证书通过如下方法实现,
设备制造商OEM向策略管理者SA递交自签名密钥SSK;策略管理者SA首先验证设备制造商OEM递交的自签名密钥SSK是否正确,然后通过如下步骤签发OEM数字证书:
步骤1.1:剔除自签名密钥中的R和S部分,包括说明标题和内容,剩下的称为公钥文件;
步骤1.2:使用SHA-1安全散列算法求取公钥文件的哈希值;
步骤1.3:将策略管理者SA的私钥、步骤2中获得的公钥文件的哈希值和一随机的字符串作为参数传递给DSA数字签名算法,DSA的数字签名算法会产生数字签名R和S;
步骤1.4:将数字签名的R和S部分写在公钥文件中公钥的前面。
策略管理者SA为设备制造商OEM签发完OEM数字证书后,还要用自己的公钥验证自己对设备制造商的签名是否正确。
步骤3中,用户许可证通过如下方法制作,
步骤3.1:用Blowfish加密算法将设备制造商OEM的公钥M_SKEY作为密钥对硬件标示符HW_ID加密;
步骤3.2:将加密后的结果转换为十六进制表示;
步骤3.3:用CRC32循环校验方法求取步骤2.2结果的哈希值,即校验和;
步骤3.4:将校验和转换为十六进制表示并附加在步骤2.2中求取的结果后;
步骤3.5:将设备制造商OEM的身份标识M_ID转换为十六进制表示,并附加在步骤3.4中求取的结果后,得到用户许可证。
本发明具有的有益效果:
本发明结合非对称加密技术的加密模型和认证模型以及数字证书技术,增加通信协议等管理机制,在不可靠的数据存储和网络通信上实现设备制造商OEM密钥的安全保护,从而提高了IHO S63数据保护方案的安全性。在安全保密中,可通过密钥加密技术和管理机制来保证网络信息的安全。加密技术主要分为对称加密和非对称加密。对称加密的加密密钥和解密密钥是一样的,非对称加密算法需要两个密钥,公开密钥和私有密钥,包含两种模型,加密模型和认证模型,如图2、图3所示。本发明通过非对称加密技术的两种模型,改变设备制造商OEM的对称加密,可以实现OEM密钥的保护。伴随而来的问题,就是设备制造商OEM公钥的传输问题。由于IHO S63数据保护方案中OEM和DS的不唯一性,需要公开所有的设备制造商OEM的公钥,则不便于SA对于方案的管理,而且数据服务方也必须根据设备制造商OEM的变动时时进行更新,本发明可通过采用数字证书技术来实现避免公开设备制造商OEM公钥。数字证书是数据保护方案中各方身份信息的一系列数据,它是由策略管理者SA发行,方案参与者可以在网上用它来相互识别对方身份。SA可以采用数据服务方的数字证书方式,给OEM颁发数字证书。
本发明设备制造商OEM的密钥由对称式变为对称式和非对称式相结合的方式,减少了密钥泄露的攻击点,增强了密钥攻击的难度,从而提高了密钥保护的安全系数。本发明通过设备制造商OEM的数字证书,实现设备制造商身份的标示,使得数据服务方对于设备制造商身份的认证更加可靠。本发明从方案参与者的角度,按照四个模块进行分析,使得在改变OEM密钥管理方式从而极大提高数据保护方案整体的安全性能的同时,不会影响整体方案的设计规划。
附图说明
图1是原方案的方案流程图;
图2是公钥密码体制的加密模型图;
图3是公钥密码体制的认证模型图;
图4是本发明改进之后的方案流程图;
图5是本发明改进之后策略管理者的职能图;
图6是本发明改进之后数据服务方的职能图;
图7是本发明改进之后设备制造商的职能图;
图8是本发明改进之后的策略管理者颁发的SA证书;
图9是本发明改进之后的策略管理者SA处理数据服务方的申请流程图;
图10是本发明改进之后的策略管理者SA设备制造商的申请流程图;
图11是本发明改进之后方案的数据服务方和设备制造商的连接建立过程图;
图12是ENC单元许可文件的解析流程图;
图13是ENC单元文件的解密流程图。
具体实施方式
如图4所示,数据保护方案的参与者包括四种:
策略管理者SA:
数据保护方案的管理员SA仅有一个,由国际海道测量局(IHB)担当,全权负责此方案的维护和协调。SA负责维护顶层加密密钥,用于操作完整的数据保护方案。管理员SA的主要职能为:控制数据保护方案中的成员资格,确保参与者按照既定程序操作,维护顶层密钥,发放证书,维护文档等。管理员SA是IHO S63数据保护方案中最为关键的一方,也是有权发行证书的唯一实体,如图5所示。
数据服务方DS:
数据保护方案的数据服务方DS有多个,海道测量局和区域电子海图协调中心(RENC)是典型的数据服务方,数据服务方负责按照数据保护方案的既定程序对ENC信息进行加密和签名,数据服务方从数据客户方获得用户许可,解密获取HW_ID用来加密单元密钥为数据客户方生成单位许可,如图6所示。
设备制造商OEM:
数据保护方案的设备制造商OEM有多个,OEM负责制造电子海图设备,同时构建相应的软件程序(通过S63提供的测试数据来兼容标准)来支持该数据保护方案。制造商必须在其软件里安装唯一的硬件标识符HW_ID来唯一识别出每个最终用户,即在软件系统中提供安全机制,如图7所示。
数据客户方:
在S63数据保护方案中,数据客户端有多个,指的就是ECDIS用户终端,数据客户端是电子海图信息的最终使用者。数据客户端凭借设备制造商为其提供的用户权证User Permit向数据服务方申请数据,设备制造商负责制造出符合S63数据保护方案标准的设备终端负责验证数字签名、解密解压缩电子海图数据等等。
如图4所示,本发明电子海图的数据保护方法具体实现如下:
步骤一:策略管理者SA向设备制造商OEM签发OEM数字证书和颁发身份标识M_ID。
1.策略管理者SA颁布SA证书
策略管理者拥有最高级别的公钥私钥对,其中私钥用于对数据服务方和设备制造商的自签名密钥进行签名,公钥用于验证对于数据服务方和设备制造商的签名。策略管理者会在IHO的官方网站上公布自己的数字证书文件,IHO的数字证书符合X509v3标准并以IHO.CRT作为名称。另外,和IHO的数字证书一起公布的还有txt格式的策略管理者的公钥。当策略管理者的数字证书过期或者是策略管理者的私钥泄密的时候,策略管理者会及时在网站上发布新的数字证书和txt格式的公钥,数据服务方和设备制造商应及时通知数据客户端,如图8所示。
2.策略管理者SA处理数据服务方的申请
设备制造商OEM通过递交OEM申请表格,以及申请系统管理员指定的海道组织对其开发的EPS系统进行审核,测试,如果审核符合S63标准的要求,则通过审核。当数据服务方向策略管理者申请加入S63数据保护方案的时候,会向方案管理者递交自签名密钥,方案管理者在为数据服务方签发数字证书前首先要确认数据服务方的自签名密钥是否正确,并且用数据服务方的公钥验证数据服务方对自己的签名,具体的方法为:
(1)提取出自签名密钥中的R和S部分,包括说明标题和内容,剩下的称为公钥文件;
(2)使用SHA-1安全散列算法求取公钥文件的哈希值
(3)将签名R和S公钥文件和公钥文件的哈希值作为参数传递给DSA数字签名算法。
若数据服务方提交的自签名密钥通过了方案管理者的验证之后,策略管理者便会为数据服务方签名,具体的方法为:
(1)剔除自签名密钥中的R和S部分,包括说明标题和内容,剩下的称为公钥文件;
(2)使用SHA-1安全散列算法求取公钥文件的哈希值
(3)将策略管理者的私钥,公钥文件的哈希值和一随机的字符串作为参数传递给DSA数字签名算法,DSA的数字签名算法会产生数字签名R和S。
(4)将数字签名的R和S部分写在公钥文件中公钥的前面。
策略管理者为数据服务方签发完证书后还要用自己的公钥验证自己对数据服务方的签名是否正确,再确认无误之后再将签发的证书颁发给数据服务方。(见附图9)。
3.策略管理者SA处理设备制造商的申请
当设备制造商向策略管理者申请加入S63数据保护方案的时候,会向方案管理者递交自签名密钥,方案管理者在位设备制造商签发证书前首先要确认设备制造商的自签名密钥是否正确,并且用设备制造商的公钥验证设备制造商对自己的签名,具体的方法为:
(1)提取出自签名密钥中的R和S部分,包括说明标题和内容,剩下的称为公钥文件;
(2)使用SHA-1安全散列算法求取公钥文件的哈希值
(3)将签名R和S,公钥文件和公钥文件的哈希值作为参数传递给DSA数字签名算法。
若设备制造商提交的自签名密钥通过了方案管理者的验证之后,策略管理者变会为设备制造商签名,具体的方法为:
(1)剔除自签名密钥中的R和S部分,包括说明标题和内容,剩下的称为公钥文件;
(2)使用SHA-1安全散列算法求取公钥文件的哈希值
(3)将策略管理者的私钥,公钥文件的哈希值和一随机的字符串作为参数传递给DSA数字签名算法,DSA的数字签名算法会产生数字签名R和S。
(4)将数字签名的R和S部分写在公钥文件中公钥的前面。
策略管理者为设备制造商签发完证书后还要用自己的公钥验证自己对设备制造商的签名是否正确,再确认无误之后再将签发的证书以及M_ID颁发给设备制造商,如图10所示。
步骤二:设备制造商OEM向数据服务方DS递交自己的OEM数字证书和身份标识M_ID,数据服务方DS利用策略管理者SA的公钥解密OEM数字证书,获得设备制造商OEM的公钥M_PKEY;数据服务方DS向设备制造商OEM发送自己的DS数字证书,设备制造商OEM利用策略管理者SA的公钥解密DS数字证书,获得数据服务方DS的公钥。
1.数据服务方DS创建自签名密钥SSK
数据服务方创建自签名密钥SSK,并提交给管理员SA以获得数据服务方证书,数据服务方创建自身的密钥对,并将公钥和对公钥的签名样本结合在自签名密钥SSK中,写成ASCII文本格式:
//Signature part R:
752A8E5C3AF56CCD7395B52E F672E404554F AAB6
//Signature part S:
1756E5C0F4B6BC904EC65F94DF933ADF68B886C4
//BIG p
D0A02D76D21058DA4D91BBC730AC91865CB4036C CDA46B494650
16BB69312F12DF14A0CC F38E B77C AD84E6A12F2A A0D0441A734B
1D2B E9445D10BA87609B75E3
//BIG q
8E0082E3C046DFE6C422F44C C111DBF6ADEE9467
//BIG g
B08D786D0ED34E397C6B3ACF8843C3BF BAB1A44D0846BB2A
C3EE D432B270E710E083B239AF0E A5B8693B F2FC A03B6A73E289
84FF8623
1394996F62630845AA94
//BIG y
444B BA1717580DAF71AB52A56CCA8EAB4C51E9700E37B17B BB46
C0B94A36F73F02447FBD AE5B7CA938705AB9E9EE471C E7B01004
6DF1350542B30332AE6769C6
p,q,g,y构成数据服务方的公钥文件,其中y元素为数据服务方的公钥,512比特元素p,q,g为数据服务方的全局公钥,分别为512,160,512比特元素R和S是数据服务方对其公钥文件签名后的输出,均为160比特。
创建自签名密钥SSK的步骤如下:
(1)采用SHA-1算法对公钥文件进行散列运算;
(2)采用DSA算法签署公钥文件返回两个签名元素R和S(DSA算法的输入为数据服务方的私钥x随机数k第一步的公钥文件散列结果);
(3)按照格式将签名元素及公钥文件写入到自签名密钥文件中去。
2.设备制造商OEM创建自签名密钥SSK
设备制造商创建自签名密钥SSK,并提交给管理员SA以获得设备制造商证书,设备制造商创建自身的密钥对,并将公钥和对公钥的签名样本结合在自签名密钥SSK中,写成ASCII文本格式:
//Signature part R:
752A8E5C3AF56CCD7395B52E F672E404554F AAB6
//Signature part S:
1756E5C0F4B6BC904EC65F94DF933ADF68B886C4
//BIG p
D0A02D76D21058DA4D91BBC730AC91865CB4036C CDA46B494650
16BB69312F12DF14A0CC F38E B77C AD84E6A12F2A A0D0441A734B
1D2B E9445D10BA87609B75E3
//BIG q
8E0082E3C046DFE6C422F44C C111DBF6ADEE9467
//BIG g
B08D786D0ED34E397C6B3ACF8843C3BF BAB1A44D0846BB2A
C3EE D432B270E710E083B239AF0E A5B8693B F2FC A03B6A73E289
84FF8623
1394996F62630845AA94
//BIG y
444B BA1717580DAF71AB52A56CCA8EAB4C51E9700E37B17B BB46
C0B94A36F73F02447FBD AE5B7CA938705AB9E9EE471C E7B01004
6DF1350542B30332AE6769C6
p,q,g,y构成设备制造商的公钥文件,其中y元素为设备制造商的公钥,512比特元素p,q,g为设备制造商的全局公钥,分别为512,160,512比特元素R和S是设备制造商对其公钥文件签名后的输出,均为160比特。
创建自签名密钥SSK的步骤如下:
(1)采用SHA-1算法对公钥文件进行散列运算;
(2)采用DSA算法签署公钥文件返回两个签名元素R和S(DSA算法的输入为设备制造商的私钥x,随机数k和第(1)步的公钥文件散列结果);
(3)按照格式将签名元素及公钥文件写入到自签名密钥文件中去。
3.设备制造商OEM和数据服务方DS之间的连接建立
在数据客户方向数据服务方递交用户许可证之前,设备制造商OEM和数据服务方DS之间需要建立连接,为接下来的用户许可证的加密解密以及传输过程做准备。
首先,设备制造商向数据服务方递交自己的OEM数字证书以及M_ID。
然后,在数据服务方收到设备制造商OEM的数字证书之后,用SA的公钥解密设备制造商的数字证书,一方面验证设备制造商OEM的合法身份,另一方面也可以得到设备制造商的公钥M_PKEY。数据服务方需要保存M_ID和公钥M_PKEY,为接下来的用户许可证的解密服务。
最后,数据服务方向设备制造商OEM发送自己的数字证书,此时设备制造商OEM一方面验证数据服务方的合法身份,另一方面设备制造商OEM用SA的公钥解密数据服务方的数字证书,就可以得到数据服务方的公钥,为接下来用户许可证的加密服务,如图11所示。
步骤三:设备制造商OEM为数据客户端颁发硬件标示符HW_ID,并制作用户许可证;数据客户端将用户许可证通过数据服务方DS的公钥进行加密后递交数据服务方DS;数据服务方DS利用自己的私钥解密用户许可证,根据获得的M_ID查找对应的设备制造商OEM的公钥M_PKEY,用公钥M_PKEY解密用户许可证中硬件标识符HW_ID部分,得到数据客户端的硬件标识符HW_ID,数据服务方DS通过硬件标识符HW_ID加密单元密钥,为数据客户端生成单元许可,从而向数据客户端提供电子海图数据服务。
1.1用户许可证的制作
当数据用户客户端向设备制造商购买电子海图现实与信息系统ECDIS设备时,设备制造商会为数据客户端分配一个唯一的硬件标示符HW_ID并为其制作用户许可User Permit交付数据客户端。当数据客户端向数据服务方申请数据时需要向数据服务方提供用户许可,数据服务方从用户许可中解密出HW_ID用来加密单元密钥。假设策略管理者为设备制造商分配的M_ID为SK,设备制造商自身私钥M_SKEY为19900,设备制造商为数据客户端分配的HW_ID为ZSK90,用户许可的产生办法为:
(1)用Blowfish加密算法将M_SKEY作为密钥对HW_ID加密;
(2)将加密后的结果转换为十六进制表示;
(3)用CRC32循环校验方法求取(2)中的哈希值,即校验和;
(4)将校验和转换为十六进制表示并附加在(2)中求取的结果后;
(5)将M_ID转换为十六进制表示并附加在(4)中求取的结果后,得到用户许可。
表1用户许可的制作
1.2设备制造商OEM向数据服务方DS传输用户许可证过程
设备制造商用自己的私钥M_SKEY签署数据客户方的硬件标示符HW_ID,然后经过CRC校验得到校验和,接着设备制造商OEM附加上自己的M_ID,从而生成用户许可证书。最后使用数据服务方的公钥对生成的户许可证用加密,通过可靠方式传送给数据服务方。
数据服务方在收到设备制造商OEM加密的用户许可之后,首先数据服务方使用自己的私钥解密许可证文件,得到未加密的用户许可证,在通过经过CRC校验合格之后,数据服务方根据自己保存过的M_ID找到对应的设备制造商OEM的公钥,用该公钥解密用户许可证中加密数据客户方硬件标示符HW_ID部分,便可得到数据客户方的硬件标示符HW_ID。
2.数据服务方DS对于电子海图数据的压缩,加密与签名。
2.1数据服务方DS对于ENC的压缩
电子海图数据由于其格式的原因包含很多重复的信息,例如连续的同一类型物标等。为了减少电子海图数据所占的空间,同时也加快了传输的速度,所有的电子海图数据在使用Blowfish分组加密前都要经过数据压缩。经过压缩过的电子海图数据所占的空间可减少百分之三十到百分之六十,可见数据压缩在电子海图数据中的作用。数据压缩采用Zip算法。S63数据保护方案只压缩电子海图的000文件和其对应的更新文件,其他的文件并不进行压缩。
2.2数据服务方DS对于ENC的加密
为了防止电子海图数据的非授权使用,电子海图在发布前进行了加密,类似于数据压缩,数据加密只针对电子海图的000文件及其更新文件,其他的文本文件,图像文件等没有经过加密。S63数据保护方案只用到了Blowfish一种加密算法,用来加密电子海图的密钥称为单元密钥CK,密钥的长度为40bit。
2.3数据服务方在ENC单元上签名的步骤如下:
(1)采用SHA-1算法对压缩加密后的ENC文件进行散列运算;
(2)采用DSA算法签署公钥文件返回两个签名元素R和S(DSA算法的输入为数据服务方的私钥x,随机数k,第一步的文件散列结果);
(3)按照格式将第二步输出的签名元素作为前两个数据串写到ENC的签名文件里去,剩余部分等同于数据服务方证书的内容。
3.数据用户在得到DS的电子海图数据
3.1认证数据服务方DS的数字证书
设备制造商制作的软件可以验证数字签名确保数据来源的权威性和数据的完整性,在S63数据保护方案中依靠策略管理者对数据服务方,数据服务方对电子海图数据的二级数字签名验证来实现。
在进行数字签名验证时首先要验证策略管理者的数字证书,验证方法为从IHO官网下载公钥文件,手动对比和策略管理者数字证书中的公钥是否一致。
在确保策略管理者的数字证书格式和有效日期后便可以验证策略管理者对数据服务方的数字签名,具体步骤如下:
(1)从电子海图的数字签名文件中剔除第一个R和S签名部分,这是数据服务方对电子海图的数字签名;
(2)提取出第二个R和S签名部分,这是策略管理者对数据服务方的签名,剩下的为数据服务方的签名文件;
(3)将公钥文件作为参数传入SHA-1安全散列函数求取公钥文件的哈希值;
(4)将签名部分,策略管理者的公钥和(3)中求取的公钥文件的哈希值作为参数传递给DSA数字签名。DSA数字签名算法将返回验证结果是否正确。
若返回验证结果正确,同样的道理去验证数据服务方对电子海图文件的签名。若不正确,则说明策略管理者签名的数据服务方证书无效,可能是策略管理者更换了数字证书或者电子海图数据是从别的数据服务方那里得来的,那么电子海图数据就不能用于解密和解压缩
3.2解析单元许可文件
在S63数据保护策略中,DS发送的ENC数据包的结构按照规范化的格式组织,单元许可文件“PERMIT.TXT”中单元许可文件解析流程包含所有ENC单元的许可,每个ENC单元对应一条单元许可记录,解析得到该单元的单元密钥CK1和CK2,相应的解析流程,如图12所示。
3.3验证ENC单元的签名
设备制造商制作的软件可以验证数字签名确保数据来源的权威性和数据的完整性,在S63数据保护方案中依靠策略管理者对数据服务方,数据服务方对电子海图数据的二级数字签名验证来实现。
在进行数字签名验证时首先要验证策略管理者的数字证书,验证方法为从IHO官网下载公钥文件,手动对比和策略管理者数字证书中的公钥是否一致。
在确保策略管理者的数字证书格式和有效日期后便可以验证策略管理者对数据服务方的数字签名,具体步骤如下:
(1)从电子海图的数字签名文件中剔除第一个R和S签名部分,这是数据服务方对电子海图的数字签名;
(2)提取出第二个R和S签名部分,这是策略管理者对数据服务方的签名,剩下的为数据服务方的签名文件;
(3)将公钥文件作为参数传入SHA-1安全散列函数求取公钥文件的哈希值;
(4)将签名部分,策略管理者的公钥和(3)中求取的公钥文件的哈希值作为参数传递给DSA数字签名。DSA数字签名算法将返回验证结果是否正确。
若返回验证结果正确,同样的道理去验证数据服务方对电子海图文件的签名。若不正确,则说明策略管理者签名的数据服务方证书无效,可能是策略管理者更换了数字证书或者电子海图数据是从别的数据服务方那里得来的,那么电子海图数据就不能用于解密和解压缩
3.4解密ENC单元文件
当确保加密后的ENC单元文件和签名无误后,依次使用单元密钥CK1和CK2对该单元文件解密,并将解密后的文件使用ZIP算法解压缩,在解压缩成功后,对得到的文件执行CRC32校验,如果校验通过,将得到符合IHO S-57标准的ENC文件对应流程,如图13所示。
Claims (3)
1.一种电子海图的数据保护方法,基于IHO S63电子海图数据保护策略,包括策略管理者SA、数据服务方DS、设备制造商OEM和数据客户方DC,其特征在于:
步骤1:策略管理者SA向设备制造商OEM签发OEM数字证书和颁发身份标识M_ID;
步骤2:设备制造商OEM向数据服务方DS递交自己的OEM数字证书和身份标识M_ID,数据服务方DS利用策略管理者SA的公钥解密OEM数字证书,获得设备制造商OEM的公钥M_PKEY;数据服务方DS向设备制造商OEM发送自己的DS数字证书,设备制造商OEM利用策略管理者SA的公钥解密DS数字证书,获得数据服务方DS的公钥;
步骤3:设备制造商OEM为数据客户端颁发硬件标示符HW_ID,并制作用户许可证;数据客户端将用户许可证通过数据服务方DS的公钥进行加密后递交数据服务方DS;数据服务方DS利用自己的私钥解密用户许可证,根据获得的M_ID查找对应的设备制造商OEM的公钥M_PKEY,用公钥M_PKEY解密用户许可证中硬件标识符HW_ID部分,得到数据客户端的硬件标识符HW_ID,数据服务方DS通过硬件标识符HW_ID加密单元密钥,为数据客户端生成单元许可,从而向数据客户端提供电子海图数据服务。
2.根据权利要求1所述的电子海图的数据保护方法,其特征在于:步骤1中,策略管理者SA向设备制造商OEM签发OEM数字证书,通过如下方法实现,
设备制造商OEM向策略管理者SA递交自签名密钥SSK;策略管理者SA首先验证设备制造商OEM递交的自签名密钥SSK是否正确,然后通过如下步骤签发OEM数字证书:
步骤1.1:剔除自签名密钥中的R和S部分,包括说明标题和内容,剩下的称为公钥文件;
步骤1.2:使用SHA-1安全散列算法求取公钥文件的哈希值;
步骤1.3:将策略管理者SA的私钥、步骤2中获得的公钥文件的哈希值和一随机的字符串作为参数传递给DSA数字签名算法,DSA的数字签名算法会产生数字签名R和S;
步骤1.4:将数字签名的R和S部分写在公钥文件中公钥的前面。
策略管理者SA为设备制造商OEM签发完OEM数字证书后,还要用自己的公钥验证自己对设备制造商的签名是否正确。
3.根据权利要求2所述的电子海图的数据保护方法,其特征在于:步骤3中,用户许可证通过如下方法制作,
步骤3.1:用Blowfish加密算法将设备制造商OEM的公钥M_SKEY作为密钥对硬件标示符HW_ID加密;
步骤3.2:将加密后的结果转换为十六进制表示;
步骤3.3:用CRC32循环校验方法求取步骤2.2结果的哈希值,即校验和;
步骤3.4:将校验和转换为十六进制表示并附加在步骤2.2中求取的结果后;
步骤3.5:将设备制造商OEM的身份标识M_ID转换为十六进制表示,并附加在步骤2.4中求取的结果后,得到用户许可证。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201410234812.2A CN104135368B (zh) | 2014-05-30 | 2014-05-30 | 一种电子海图的数据保护方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201410234812.2A CN104135368B (zh) | 2014-05-30 | 2014-05-30 | 一种电子海图的数据保护方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN104135368A true CN104135368A (zh) | 2014-11-05 |
CN104135368B CN104135368B (zh) | 2017-10-03 |
Family
ID=51807903
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201410234812.2A Active CN104135368B (zh) | 2014-05-30 | 2014-05-30 | 一种电子海图的数据保护方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN104135368B (zh) |
Cited By (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN105610456A (zh) * | 2015-12-31 | 2016-05-25 | 福建伊斯普电子科技有限公司 | 一种利用北斗导航的海图仪 |
CN106656502A (zh) * | 2016-09-26 | 2017-05-10 | 上海兆芯集成电路有限公司 | 计算机系统及安全执行的方法 |
CN106997296A (zh) * | 2017-03-31 | 2017-08-01 | 新华三技术有限公司 | 设备标识匹配方法和网络设备 |
WO2017197974A1 (zh) * | 2016-05-20 | 2017-11-23 | 中国银联股份有限公司 | 一种基于生物特征的安全认证方法、装置及电子设备 |
CN108595940A (zh) * | 2018-03-29 | 2018-09-28 | 深圳市风云实业有限公司 | 设备的认证授权装置、方法和系统 |
CN110166224A (zh) * | 2019-06-20 | 2019-08-23 | 大连海事大学 | 一种vdes电子海图数据在线更新与保护方法 |
CN111291369A (zh) * | 2020-01-20 | 2020-06-16 | 北京无限光场科技有限公司 | 一种信息检测方法和电子设备 |
CN114745195A (zh) * | 2022-04-25 | 2022-07-12 | 上海海阳气象导航技术有限公司 | 一种气象导航数据交换方法、系统、存储介质及终端 |
Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102095425A (zh) * | 2011-02-17 | 2011-06-15 | 长江南京航道局 | 一种基于长江标准的电子航道图生产方法 |
-
2014
- 2014-05-30 CN CN201410234812.2A patent/CN104135368B/zh active Active
Patent Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102095425A (zh) * | 2011-02-17 | 2011-06-15 | 长江南京航道局 | 一种基于长江标准的电子航道图生产方法 |
Non-Patent Citations (2)
Title |
---|
周晶: ""IHO S-63数据保护方案的安全性分析及改进"", 《中国优秀硕士学位论文全文数据库信息科技辑》 * |
李春法: ""基于S-63标准的电子海图数据保护系统的研究与实现"", 《中国优秀硕士学位论文全文数据库工程科技Ⅱ辑》 * |
Cited By (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN105610456A (zh) * | 2015-12-31 | 2016-05-25 | 福建伊斯普电子科技有限公司 | 一种利用北斗导航的海图仪 |
WO2017197974A1 (zh) * | 2016-05-20 | 2017-11-23 | 中国银联股份有限公司 | 一种基于生物特征的安全认证方法、装置及电子设备 |
CN106656502A (zh) * | 2016-09-26 | 2017-05-10 | 上海兆芯集成电路有限公司 | 计算机系统及安全执行的方法 |
CN106997296A (zh) * | 2017-03-31 | 2017-08-01 | 新华三技术有限公司 | 设备标识匹配方法和网络设备 |
CN106997296B (zh) * | 2017-03-31 | 2021-01-15 | 新华三技术有限公司 | 设备标识匹配方法和网络设备 |
CN108595940A (zh) * | 2018-03-29 | 2018-09-28 | 深圳市风云实业有限公司 | 设备的认证授权装置、方法和系统 |
CN110166224A (zh) * | 2019-06-20 | 2019-08-23 | 大连海事大学 | 一种vdes电子海图数据在线更新与保护方法 |
CN110166224B (zh) * | 2019-06-20 | 2022-03-29 | 大连海事大学 | 一种vdes电子海图数据在线更新与保护方法 |
CN111291369A (zh) * | 2020-01-20 | 2020-06-16 | 北京无限光场科技有限公司 | 一种信息检测方法和电子设备 |
CN111291369B (zh) * | 2020-01-20 | 2022-05-20 | 北京无限光场科技有限公司 | 一种信息检测方法和电子设备 |
CN114745195A (zh) * | 2022-04-25 | 2022-07-12 | 上海海阳气象导航技术有限公司 | 一种气象导航数据交换方法、系统、存储介质及终端 |
Also Published As
Publication number | Publication date |
---|---|
CN104135368B (zh) | 2017-10-03 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20240007308A1 (en) | Confidential authentication and provisioning | |
US10944575B2 (en) | Implicitly certified digital signatures | |
Barker et al. | Nist special publication 800-57 part 1, revision 4 | |
US10142107B2 (en) | Token binding using trust module protected keys | |
CN102594558B (zh) | 一种可信计算环境的匿名数字证书系统及验证方法 | |
CN104135368A (zh) | 一种电子海图的数据保护方法 | |
CA2838322C (en) | Secure implicit certificate chaining | |
CN109687965B (zh) | 一种保护网络中用户身份信息的实名认证方法 | |
US11874935B2 (en) | Protecting data from brute force attack | |
US20030233542A1 (en) | Selectively disclosable digital certificates | |
CN108551435B (zh) | 一种具有匿名性的可验证加密群签名方法 | |
JP5324813B2 (ja) | 鍵生成装置、証明書生成装置、サービス提供システム、鍵生成方法、証明書生成方法、サービス提供方法およびプログラム | |
Backes et al. | Using mobile device communication to strengthen e-voting protocols | |
WO2022024182A1 (ja) | 知識証明方法、知識証明プログラム、および情報処理装置 | |
CN113630238A (zh) | 一种基于密码混淆的用户请求许可方法及装置 | |
CN116318696B (zh) | 一种双方无初始信任情况下代理重加密数字资产授权方法 | |
Hussien et al. | Scheme for ensuring data security on cloud data storage in a semi-trusted third party auditor | |
Surya et al. | Single sign on mechanism using attribute based encryption in distributed computer networks | |
US20040064690A1 (en) | Methods for applying for crypto-keys from a network system | |
CN116192380A (zh) | 一种基于国密算法的数据加密共享系统的系统设计与实现方法 | |
Azhar-Ibrahim | Secure Socket Layer: Fundamentals and certificate verification | |
WO2023043793A1 (en) | System and method of creating symmetric keys using elliptic curve cryptography | |
CN117335989A (zh) | 基于国密算法在互联网系统中安全应用方法 | |
CN117692227A (zh) | 一种基于区块链的隐私数据安全共享方法 | |
CN117375851A (zh) | 一种基于数字信封技术和sm2算法的两方安全协同签名验签方法 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |