JT-T-765.5-2016长江电子航道图制作规范第5部分：数据保护

Ⅱ7.8核查单元许可证文件的程序 7.9核实单元许可证ENC校验和的程序 7.10解密单元许可证中单元密钥的程序 8.4数字证书的创建程序 9数字签名 10.6使用基本许可证文件选择单元密钥的程序 10.7使用元许可证文件选择单元密钥 Ⅲ/«长江电子航道图制作规范»分为五个部分:等)ꎮ本部分所代替标准的历次版本发布情况为:/.５—ꎮ1JT/T765.5—2016长江电子航道图制作规范第5部分:数据保护JT/T765的本部分规定了长江电子航道图数据保护总体框架、各参与方的交互程序、用户许可证、单元许可证、数字证书、数字签名、加密等要求ꎮ本部分适用于长江电子航道图制作、系统开发、设计和应用ꎬ其他内河电子航道图系统也可参照使用ꎮ2规范性引用文件下列文件对于本文件的应用是必不可少的ꎮ凡是注日期的引用文件ꎬ仅注日期的版本适用于本文件ꎮ凡是不注日期的引用文件ꎬ其最新版本(包括所有的修改单)适用于本文件ꎮJT/T765.1长江电子航道图制作规范第1部分:术语3术语和定义JT/T765.1界定的术语和定义适用于本文件ꎮ4长江电子航道图数据保护总体框架4.1.1长江电子航道图数据保护方案规定了四类参与方ꎬ分别为系统管理员、数据服务商、设备制造商、数据用户ꎮ4.1.2系统管理员为任何加入长江电子航道图数据保护方案的设备制造商分配一对唯一的制造商标的M__KEY将其加密后形成用户许可证ꎬ随产品一同提供给数据用户ꎮ的M__KEY将其加密后形成用户许可证ꎬ随产品一同提供给数据用户ꎮ4.1.3对于任何加入长江电子航道图数据保护方案的数据服务商ꎬ系统管理员向其提供设备制造商信息表ꎬ并保证表内容的及时更新ꎮ4.1.4数据用户需要购买数据服务商的电子航道图时ꎬ向其提供自己的用户许可证ꎬ数据服务商用单户许可证中的HW_ID对单元许可证解密ꎬ得到单元密钥ꎬ并用单元密钥对电子航道图进行解密ꎮ4.1.5为在上述保护过程中实现身份认证ꎬ采用数字证书的方式来进行签名认证ꎮ系统管理员创建自己的系统管理员数字证书ꎬ并将该证书发布给设备制造商、数据服务商和数据用户ꎮ数据服务商创建自己的数据服务商自我签名密钥文件(SSK)并提交给系统管理员ꎬ系统管理员核实SSK文件后ꎬ用自己的私有密钥对数据服务商公开密钥进行签名ꎬ生成数据服务商数字证书户许可证中的HW_ID对单元许可证解密ꎬ得到单元密钥ꎬ并用单元密钥对电子航道图进行解密ꎮJT/T765.5—2016书结合ꎬ形成电子航道图的签名文件ꎬ随电子航道图一起提供给数据用户ꎮ数据用户收到电子航道图签名文件后ꎬ利用系统管理员数字证书中的公开密钥来核实数据服务商证书ꎬ再利用数据服务商证书中的公开密钥来核实电子航道图的签名ꎬ如果正确ꎬ则电子航道图可以使用ꎬ否则因不能确认来源而拒绝使用ꎮ4.2各参与方的职责4.2.1系统管理员系统管理员(SA)应根据需要维护策略的正常运行ꎬ制作并发布方案根证书ꎬ接受设备制造商字证书ꎬ在电子航道图发布过程中实现身份认证ꎮSA的主要职责是:(OEM)的申请ꎬ并为符合要求的OEM创建M__ID和M_KEY字证书ꎬ在电子航道图发布过程中实现身份认证ꎮSA的主要职责是:b)确认DS发送的数据服务商申请表格ꎻc)与OEM签订协议书b)确认DS发送的数据服务商申请表格ꎻc)与OEM签订协议书ꎻd)与DS签订协议书ꎻf)为每个DS创建数据服务商证书ꎻe)为每个OEM创建一一对应的M__IDf)为每个DS创建数据服务商证书ꎻg)创建系统管理员数字证书以提供给电子航道图显示与信息系统(ECDIS)用户ꎻh)负责管理各种文档ꎬ并将系统成员所需文档发送给成员ꎮ4.2.2数据服务商数据服务商(DS)应负责加密和签署电子航道图(ENC)信息ꎬ通过网络或者数据光盘的形式为用户提供更新ENC服务ꎮ每个长江电子航道图数据提供商应符合国家相关的资质规定ꎬ并经SA认证通过ꎬ具有向用户发布数据的资格ꎮDS的主要职责是:a)向SA申请发布ENC数据的资格ꎻc)创建自己的SSK证书文件ꎻb)与SA签署协议ꎬ由SA向其分配M__c)创建自己的SSK证书文件ꎻd)鉴定ENC请求用户的合法性ꎻe)创建加密ENC文件所需的单元密钥ꎻf)创建单元许可证文件和元数据文件ꎻg)压缩、加密以及签署ENC并发送给用户ꎻh)产生单元许可证文件和元数据文件ꎬ发送给请求用户ꎻi)管理加密ENC的密钥以及其他用户资料等文档文件ꎮ4.2.3设备制造商设备制造商(OEM)主要负责开发一套电子航道图处理系统(EPS)ꎬ该系统按照本规范要求具备对ENC数据的保护功能ꎮ同时ꎬ还具备处理保护的ENC数据ꎬ以便在ECDIS平台显示正确的电子航道图数据信息的能力ꎮ为了加入长江电子航道图数据保护方案ꎬ相应的OEM应完成方案的要求ꎬ取得资格舶导航产品ꎮOEM的主要职责是:a)申请制造商资格ꎻ认证后才能加入本保护方案舶导航产品ꎮOEM的主要职责是:a)申请制造商资格ꎻb)与SA签署协议ꎻc)为每台设备创建HW_IDꎻ23JT/T765.5—2016e)开发符合本规范要求的EPS系统ꎻf)为电子航道图显示与信息系统(ECDIS)创建用户许可证文件ꎮ4.e)开发符合本规范要求的EPS系统ꎻf)为电子航道图显示与信息系统(ECDIS)创建用户许可证文件ꎮ4.2.4数据用户数据用户(DC)是电子航道图信息的使用者ꎬ从DS那里接收加以保护的ENC信息ꎮECDIS用户负责鉴别ENC的数字签名和按照保护方案定义的程序对ENC进行解密ꎮDC的主要职责是:a)从SA网站下载系统管理员数字证书ꎬ用以鉴别DS的合法性ꎻb)向DS提供用户许可证文件ꎬ以获得新的ENC文件ꎻc)管理多个DS各自的用户许可证文件ꎮ5各参与方的交互程序5.1SA创建自己的数字证书SA创建自己的私有密钥和公有密钥ꎬ使用私有密钥对公有密钥进行签名ꎬ将签名算法的返回值与公有密钥结合ꎬ创建SA数字证书ꎮ5.2DS加入数据保护体系的基本程序DS加入数据保护体系的基本程序如下:a)DS创建自己的公开密钥、私钥对ꎻb)DS创建SSK文件ꎻc)DS填写“长江电子航道图数据保护系统数据服务商证书请求表”ꎻd)DS将申请表、SSK文件以及数据服务商公开密钥文件发送给SAꎻe)SA通过电话、电子邮件等方式对申请表格和SSK文件的来源等进行确认ꎻf)SA核实SSK文件的格式是否符合本规范要求ꎻg)SA利用DS发送的公开密钥文件核实SSK文件ꎻh)如果对SSK文件的鉴别合法ꎬ且该DS符合国家相关资质要求ꎬSA创建DS证书ꎬ否则ꎬ给请求的DS发出错误信息ꎮ5.3OEM加入数据保护体系的基本程序OEM加入数据保护体系的基本程序如下:b)SA核实M__ID/M__KEY表格第一部分(主要核实设备制造商对表格的填写是否完整)ꎻc)SAb)SA核实M__ID/M__KEY表格第一部分(主要核实设备制造商对表格的填写是否完整)ꎻc)SA核实OEM是否签署“长江电子航道图数据保护协议书”ꎻd)SA核实OEM开发的系统是否符合本规范标准ꎻe)_/M__KEY对(主要确认该申请的OEM未曾有过M__ID/M__KEYꎬ即表g)SA将M__ID/M__KEY发送给OEMꎬ同时也将这个新的M__ID/M__KEYg)SA将M__ID/M__KEY发送给OEMꎬ同时也将这个新的M__ID/M__KEY发送给系统内所有的DSꎮ5.4DC向OEM购买新设备的程序DC按如下程序向OEM购买设备:a)DC向OEM递交标识身份的用户许可证文件(主要是申请ENC文件)ꎻ4JT/T765.5—2016b)OEM生成一份包含DC硬件设备标识HW_ID和M__b)OEM生成一份包含DC硬件设备标识HW_ID和M__ID信息的用户许可证文件ꎻc)OEM将研制生产的EPS系统和新生成的用户许可证文件以及ECDIS系统一起发送给DCꎮ5.5SA与DC的交互程序DC按如下程序从SA处获得并验证数字证书:a)DC从SA获取SA数字证书ꎻb)对SA数字证书格式进行核对ꎻc)利用SA公开密钥鉴别SA数字证书(比较数字证书ꎬ包括SA公开密钥与从SA网站获得的公开密钥是否一致)ꎮDC购买并使用DS提供的电子航道图的程序如下:a)DC向DS递交用户许可证以申请电子航道图文件ꎻM__ID对应的M__KEYꎻd)DS生成单元许可证文件ꎻb)DS从用户许可证中获得M__IDꎬ并查对从SAM__ID对应的M__KEYꎻd)DS生成单元许可证文件ꎻc)DS使用M__KEY解密用户许可证ꎬ获得DC的HW_IDꎬ用来加密单元密钥ꎻe)DS用zip算法压缩电子航道图单元数据ꎬ并用单元密钥加密压缩后的数据ꎻf)DS利用自己的私有密钥对加密后的电子航道图单元数据进行数字签名ꎻg)DS将加密后的电子航道图单元数据、单元许可证文件和数字签名文件一起发送给DCꎻh)DC核对DS发送的相关文件(主要包括签名文件是否包含签名和证书对ꎬ核实签名文件是否符合本规范要求的格式)ꎻi)DC鉴别签名文件中的DS证书是否合法ꎮ如果合法ꎬ从签名文件中提取DS公开密钥ꎻj)DC鉴别电子航道图单元数据的签名文件ꎻ单元密钥ꎬ利用系统解密数据并使用ꎮk)DC通过系统软件提取自己机器上的HW_ID单元密钥ꎬ利用系统解密数据并使用ꎮ6用户许可证6.1M_ID的格式M__ID是4位长度的M__ID是4位长度的16进制数字(两字节)ꎬ以ASCII码表示ꎮSA应向每个加入长江电子航道图数6.2M_KEY的格式M__KEY是10位长度的16进制数字(五字节)ꎮ6.3HW__ID的格式5JT/T765.5—20166.4用户许可证的格式用户许可证为28字符长度ꎬ用ASCII文本书写ꎬ其格式和字段长度要求见表1ꎮ加密后的HW_ID校验和M__ID表1中每个字段中的16进制数均以ASCII码表示ꎬ其中任何字母字符应大写ꎮ用户许可证中的校验和是:RC32算法对加密后的HW_ID进行散列计算后得到ꎮ该散列计算结果被转化为8位16进制数ꎮ用户许可证的最终表现形式为:73871727080876A07E450C043031ꎮ6.5用户许可证的创建程序用户许可证的创建程序由系统或者应用程序提供商执行ꎬ生成的用户许可证发送给DCꎬ用作DC请求单元许可证时的自身标识ꎮ用户许可证和系统一起交给终端用户ꎮ用户许可证的创建过程如下:b)将结果转换成16位16进制字符串ꎬ每一个字母都应大写表示ꎻc)利用CRC32算法散列上面的16b)将结果转换成16位16进制字符串ꎬ每一个字母都应大写表示ꎻc)利用CRC32算法散列上面的16位16进制字符串ꎻe)将d)输出的结果附加在b)的输出结果ꎻg)将f)的输出结果附加到e)的输出结果的后面ꎬ即用户许可证ꎮ示例:g)将f)的输出结果附加到e)的输出结果的后面ꎬ即用户许可证ꎮ示例:用户许可证的标识符及内容参见表2ꎬ创建程序见表3ꎮ标识符备注HW_ID16进制表示的HW_ID___16进制表示的M__KEYMID16进制表示的MID步骤备注步骤a)的输入16进制表示的HW_ID和M__KEY步骤a)的输出八字节不可打印步骤c)的输入73871727080876A0这是步骤a)输出的16进制字符串表现形式ꎮ这个字符串从左到右输入给散列算法ꎬ例如73、87、17……步骤c)的输出7E450C04用16进制表示的CRC32散列结果步骤e)的输出73871727080876A07E450C04ID后将CRC32散列结果附加在加密后的ID后用户许可证73871727080876A07E450C0430316JT/T765.5—20166.6用户许可证的解密程序用户许可证的解密程序由DS的系统运行ꎮ用户许可证的结构在6.4中定义ꎮ用户许可证的解密程序如下:b)从用户许可证中提取校验和(CheckSumꎬ为8位16进制字符)b)从用户许可证中提取校验和(CheckSumꎬ为8位16进制字符)ꎻd)比较b)和c)的输出ꎬ如果相同ꎬ则该用户许可证是合法的ꎮ如果不同ꎬ则该用户许可证是不d)比较b)和c)的输出ꎬ如果相同ꎬ则该用户许可证是合法的ꎮ如果不同ꎬ则该用户许可证是不合法的ꎬ从而不能获得相应的HW_IDꎻe)如果用户许可证是合法的ꎬ把这个加密的HW_ID转换成八字节ꎻ:将M__KEY作为解密密钥ꎬ利用Blowfish算法解密这个加密的e)如果用户许可证是合法的ꎬ把这个加密的HW_ID转换成八字节ꎻ用户许可证的解密程序参见表4和表5ꎮ____标识符备注用户许可证73871727080876A07E450C043031MKEY16进制的MKEY步骤备注步骤a)的输出提取的M__ID步骤b)的输出7E450C04提取出来的校验和步骤c)的输入73871727080876A0步骤c)的输出7E450C04从加密的HW_ID中提取出来的校验和步骤f)的输出16进制表示的HW_ID7单元许可证7.1.1电子航道图单元数据在发布前应由DS使用单元密钥进行加密ꎬ该单元密钥是与该电子航道图单元数据唯一对应的ꎮDC应获得这个密钥才能解密数据ꎮ这个单元密钥由DS以加密表格的形式—单元许可证提供给DCꎮ一个单元许可证文件可以包括一个或者多个电子航道图的单元密钥ꎮ.._IDꎬ在安装系统之间是不可转换的ꎮ加密方案支持能在所可证进行解密ꎬ以便获得解密电子航道图所需的单元密钥ꎮ7.1.4发布单元许可证需要两个文件:可证进行解密ꎬ以便获得解密电子航道图所需的单元密钥ꎮ7.1.4发布单元许可证需要两个文件:a)包含解密电子航道图所需本质信息的基本许可证文件ꎬ在7.5中定义ꎻ７另一个的电子航道图ꎮ()ꎬ以及用作下一版本电子航道图单元的解密密钥ꎮ单元许可证里面的使得能周期性地改变用于电子航道图下一版本的单元密钥ꎬ而无须对其他发布新的单元许可证ꎮ７.１.７除了这些密钥以外ꎬ单元许可证还包括过期日期(这个日期之后的更新文件不能使用)和单元标识(便于用户在有好几个单元和权证文件的情况下ꎬ系统能够将两者相匹配)ꎮ终端用户将单元许可证里面的过期日期与需要解密的电子航道图单元进行比较ꎬ如果需要解密的电子航道图单元或者更新文件的生产日期在许可证的过期日期之后ꎬ系统将不会使用单元许可证来解密数据ꎬ以防止用户使用过期的电子航道图单元文件或者更新文件ꎮ子字段里ꎮ这些数据文件总是加密的ꎬ除非已经解密子字段里ꎮ这些数据文件总是加密的ꎬ除非已经解密ꎬ否则无法得到发布日期ꎮ为了提供一种获得示例:７.１.单元许可证以文本的形式书写ꎬ任何字母字符都应大写表示ꎬ其格式和字段长度见表６航道图单元名称过期日期加密后的加密后的加密后的校验和位进制数位进制数位进制数示例:单元许可证中各字段数据参见表７ꎮ表７航道图单元名称过期日期加密后的单元密钥１()加密后的单元密钥２()加密校验和单元许可证最终的表现形式为:ꎮ命名规则ꎮ示例:过期日期的格式应为:年月日()ꎮ示例:8JT/T765.5—20167.3加密后的单元密钥(ECK1ꎬECK2)格式7.3.1单元密钥是五字节随机数字ꎬ使用从用户许可证中获得的数据用户的HW__ID进行Blowfish加密ꎬ然后转化成16进制ꎮBlowfish7.3.1单元密钥是五字节随机数字ꎬ使用从用户许可证中获得的数据用户的HW__ID进行Blowfish加密ꎬ然后转化成16进制ꎮBlowfish加密算法将需要加密的数据长度填充成八字节的倍数ꎬ加密后单元密钥从五字节长度(10个16进制字符)变为八字节长度(16个16进制字符)ꎮ7.3.2ECK1包括电子航道图单元的当前版本的单元密钥ꎮECK2包括用于下一版本电子航道图的单元密钥ꎮ7.3.3ECK1用于可从DS获得的电子航道图的当前版本ꎮ如果电子航道图不能正确解密ꎬ应用ECK2解密ꎮ如果ECK2也不能正确解密ꎬ则应从DS获得更新的单元许可证ꎮ示例:如表7所示ꎬ加密后的ECK1、ECK2为:a)ECK1:BEB9BFE3C7C6CE68ꎻb)ECK2:B16411FD09F96982ꎮ7.4加密校验和的格式对单元许可证中加密校验和之前的所有字段用CRC32算法进行散列计算ꎬ然后用HW__ID对散列计算的结果进行加密ꎬ就得到了加密校验和ꎮ加密校验和是16位的16进制数字ꎮ示例:如表7所示ꎬ加密校验和为:795C77B204F54D48ꎮ7.5单元许可证的传输单元许可证应存储在名称为ENC.PMT的文件里面ꎮENC.PMT文件包括一个或多个作为连续记录存储在该文件中的单元许可证ꎮ示例:ENC.PMT文件包括2个单元许可证:7.6元许可证文件的定义7.6.1元许可证文件总体格式元许可证文件(PERMIT.TXT)是针对终端用户开发者的ꎬ用来通知DC的征订状态ꎬ以及帮助开发者理解哪些基于客户征订结束日期和电子航道图版本日期的航道图单元需要解密ꎮ在元许可证文件中任何字母的字符都应大写ꎮDS应提供如何从存储介质或网络中获得元许可证文件的方法ꎮ元许可证文件中各部分的内容和格式见7.6.2~7.6.6ꎮ示例:元许可证文件(PERMIT.TXT)的格式为::DATE2000013111:11:VERSION1:ENCGB30401020010110797C4CB45C5B4B7B0BC8A74680E798F2910351530D1FF963ꎬ0ꎬ2ꎬGB40401S200101100D0CC631D5B07B04252DAC4A7EC568BFD2C08583E26FF27Eꎬ0ꎬ3ꎬGB50401S200101100C9EAA1802FD92628086CE08A71125104F9FDFBE6C9656B5ꎬ0ꎬ3ꎬ:ECS９日期格式:ꎮ时间格式::ꎬ使用制ꎮ示例:版本数字是一个整数ꎬ用来定义元许可证文件的格式版本数字ꎮ字段名称与版本数字用空格字符分隔ꎮ示例:字段包含来自的发布证书中的可用元许可证的定义ꎮ单元许可证记录的字段组成见表８ꎮ表８单元许可证记录的字段备注单元许可证服务级别指示单次购买的许可证单次购买的许可证为将来应用保留的参数字段用于注释的文本字段字段包含来自的电子航道图系统的发布证书中的可用元许可证的定义ꎮ创建单元许可证的程序通常由执行ꎬ用于给特定创建单元许可证ꎮａ)移除电子文件名称中的文件扩展名ꎬ剩下８个字符是单元许可证中的单元名称ꎻ就是所创建的用于加密单元密钥的一个位密钥ꎻｃ)将的第一个字节附加到的后面形成六字节的(就是所创建的用于加密单元密钥的一个位密钥ꎻｈ)将转换为位进制字符ꎬ任何字母字符都应以大写表示ꎻｈ)将转换为位进制字符ꎬ任何字母字符都应以大写表示ꎻｊ)利用算法对ｉ)的输出结果进行散列计算ꎬ注意这里的散列计算是在转化为进制字符之后ꎬ而用户许可证的散列计算是针对原始的二进制数据ꎻ示例:创建单元许可证的程序参见表９和表ꎮ表９标识符备注五字节的进制字符五字节的进制字符五字节的进制字符过期日期步骤备注电子航道图单元名称电子航道图单元名称＋过期日期进制字符表示的进制字符表示的电子航道图单元名称＋过期日期进制字符表示的步骤ｉ)输出的值ꎬ这些字节从左到散列计算的结果八字节的不可打印值加密后的计算结果进制字符表示的计算结果单元许可证JT/T765.5—20167.8核查单元许可证文件的程序核查单元许可证文件的程序通常在DC系统内执行ꎬ由以下步骤组成:a)单元许可证在文件ENC.PMT和PERMIT.TXT里面提供ꎻb)DC应用程序可以将单元许可证文件存储在任何适当位置ꎮ应确保应用于同一个ENC数据的许可证文件由同一个DC提供ꎻc)单元许可证中的前8个字符代表相关的ENC单元的单元名称(去掉扩展名字)ꎻd)ENC.PMT或PERMIT.TXT文件可以包含几个许可证文件ꎮ7.9核实单元许可证ENC校验和的程序核实单元许可证ENC校验和的程序通常由DC系统执行ꎬ由以下步骤组成:a)从单元许可证提取最后的16位16进制字符(ENC校验和)ꎻb)将上面的16位16进制字符转化为八字节ꎻc)利用CRC32算法散列执行a)以后所剩下的字符串ꎻe)以HW_ID6为密钥ꎬ利用Blowfish算法加密c)中的散列结果ꎻd)将HW_ID的第一个字节附加到HW_e)以HW_ID6为密钥ꎬ利用Blowfish算法加密c)中的散列结果ꎻf)f)比较b)和e)的结果ꎮ如果相同ꎬ则此单元许可证是合法的ꎮ如果不相同ꎬ则此单元许可证非示例:核实单元许可证ENC校验和的程序参见表11和表12ꎮ表11标识符备注HW_ID16进制字符表示的HW_ID单元许可证NO4D061320000830BEB9BFE3C7C6CE68B16411FD09F96982795C77B204F54D48步骤备注步骤a)的输出795C77B204F54D4816进制字符步骤b)的输出八字节的不可打印值加密后的CRC32步骤c)的输入NO4D061320000830BEB9BFE3C7C6CE68B16411FD09F96982去掉CRC32值后的单元许可证步骤c)的输出CRC32散列计算结果步骤d)的输出HW_ID6步骤e)的输出八字节的不可打印字符加密后的CRC327.10解密单元许可证中单元密钥的程序这个程序通常由DC执行ꎬ以提取用以解密电子航道图的单元密钥ꎬ由下面的几个步骤组成:b)从单元许可证中提取出来ECK1ꎬ并且将之从16位16进制字符转化为八字节ꎻa)将HW_ID的第一个字节附加到HW_ID的后面ꎬb)从单元许可证中提取出来ECK1ꎬ并且将之从16位16进制字符转化为八字节ꎻｃ)作为密钥ꎬ利用算法对ｂ)的输出结果进行解密ꎬ形成单元密钥１()ꎻｄ)从单元许可证中提取出来ꎬ并且将之从位进制字符转化为八字节ꎻｅ)作为密钥ꎬ利用算法对ｄ)的输出结果进行解密ꎬ形成单元密钥２()ꎮ示例:解密单元许可证中单元密钥的程序参见表和表ꎮ标识符备注进制字符表示的单元许可证步骤备注八字节不可打印值ａ加密后的八字节不可打印值加密后的ａ没有经过加密的单元密钥是五字节长度ꎬ但经过加密以后的单元密钥在长度上是八字节ꎮ这是因为在加密时ꎬ将单元密钥填充到八字节长度ꎬ而当对其解密时对之进行减充ꎮ公开密钥和公开密钥都应以适当的文件格式提供ꎮ公开密钥(文件)采用文本格式ꎬ并按照规定的结构和次序表示ꎮ文件应包括下面４个数据字符串:每一个数据字符串应遵守下述格式:ｅ)每一个数据字符最后有一个行分割符(为了增加可读性ꎬ一些数据被分成两行)ꎮ示例:∥∥∥.∥.自我签名密钥由创建ꎬ然后提交给以获得证书ꎮ自我签名密钥的格式与证书的格式密钥(文件)采用文本格式ꎬ并按照规定的结构和次序表示ꎮ自我签名密钥文件应包括下面６个数据字符串:每一个数据字符串应遵守下述格式:ａ)前面有一个标题行ꎮ标题航在开始处用“∥”表示ꎬ后跟一个空格字符和文本标题字符ꎻｅ)每一个数据字符最后有一个行分割符(回车)(为了增加可读性ꎬ一些数据被分成两行)ꎮ示例:∥:∥:∥∥∥∥.使用字节的数字签名算法公开密钥ꎮ证书(文件)采用文本格式ꎬ并按照规定的结构和次序表示ꎮ文件应包括下面６个数据字符串:元素ꎻ元素ꎻ元素ꎻ元素ꎮ每一个数据字符串应遵守下述格式:ａ)前面有一个标题行ꎮ标题行在开始处用“∥”表示ꎬ后跟一个空格字符和文本标题字符ꎻｅ)每一个数据字符最后有一个行分割符(回车)(为了增加可读性ꎬ一些数据被分成两行)ꎮ示例:∥:∥:∥∥∥.∥.生成的程序通常由数据服务商执行一次ꎬ以便创建其自身的ꎬ然后发送到ꎬ由根据该创建证书ꎮ程序如下:ｂ)利用数字签名算法通过私有密钥ꎬ公开密钥的文件的散列和一个随机字符串实现对公开ｂ)利用数字签名算法通过私有密钥ꎬ公开密钥的文件的散列和一个随机字符串实现对公开自我签名密钥文件ꎮ鉴别的程序通常由在创建和发布证书之前执行ꎮ程序如下:ｃ)将ａ)中提取的签名元素ꎬ与公开密钥文件及ｂ)中获得的公开密钥文件的散列值一起传递给进行核实ｃ)将ａ)中提取的签名元素ꎬ与公开密钥文件及ｂ)中获得的公开密钥文件的散列值一起传递给进行核实ꎬ并返回签名正确与否ꎮ注:如果签名验证正确ꎬ将产生证书ꎮ创建证书的程序通常由在鉴别以后创建证书时执行ꎮ程序如下:ａ)从自我签名密钥文件中舍弃签名元素(即前两个元素以及它们的行头)ꎬ剩余为公开密钥文件ꎻｃ)利用数字签名算法通过私有密钥、公开密钥的文件的散列和一个随机字符串实现对ｃ)利用数字签名算法通过私有密钥、公开密钥的文件的散列和一个随机字符串实现对鉴别证书的程序通常是从获得的证书在使用之前执行ꎮ程序如下:ｂ)提取证书中的头两个数据字符串ꎬ剩下的就是公开密钥文件ꎻ进行核实ꎬ并返回签名正确与否ꎮ从签名文件中鉴别证书的程序通常由执行ꎬ在数据服务公开密钥被提取用于鉴别签名之前ꎬ使用公开密钥鉴别存储在签名中的证书时使用ꎮ鉴定程序如下:ａ)从签名文件中提取所期望的签名和证书ꎻｂ)舍弃第一个签名部分(前两个数据字符串和其相应标题ꎬ这是数据的数据服务签名)ꎬ留下部分是证书ꎻｃ)提取剩下的签名部分ꎬ即从ｂ)中获得的剩下的文件中的前两个数据字符串ꎬ形成公开密钥文件ꎻ值一起传递给进行核实ꎬ并返回签名正确与否ꎮａ)核实公开密钥时ꎬ该公开密钥用于鉴别证书ꎻｂ)核实公开密钥时ꎬ该公开密钥用于鉴别数据的数字签名ꎮａ)手动比较独立安装的数字证书中的公开密钥和从网站上获得的公开密钥ꎻｂ)如果上面的检查失败ꎬ将不接受数字证书ꎻ如果数字证书合法ꎬ其所包含的数据服务公开密钥可以用于核实签名文件ꎮ在下列情况下ꎬ将会出版和提供一个新的数字证书:ａ)当数字证书过期时ꎬ证书不应包括已经变化的公开密钥ꎻｂ)当私有密钥出现安全问题时ꎬ数字证书应包括一个新的公开密钥ꎮ将出版新的数字证书ꎬ并在网站上公布公开密钥ꎮ所有和会立即得到通知ꎬ并收到新的数字证书的复制品ꎮ和共同负责将新的数字证书以及新的公开密钥通知给ꎮ当一个新的数字证书或者公开密钥发布时ꎬ通常由该保护方案的所有用户执行该程序ꎮ按如下程序执行:ａ)从网站上获得新的数字证书以及可印刷的公开密钥ꎻｂ)应用程序应下载新的数字证书ꎬ核对公开密钥是否与印刷的公开密钥一致ꎮ只有完成这些操作后ꎬ应用程序才认为该公开密钥是正确的ꎻｃ)使用新发布的证书替代存在的数字证书ꎮ创建签名参数()的程序通常由和在创建公开和私有密钥对的时候执行ꎮ尽管由创建的参数不必与包含在公开密钥和数字证书中的一致ꎬ但是使用的密钥长度应一致ꎮ数字签名文件的格式与数字证书文件相同ꎮ数字签名(文件)采用文本格式ꎬ并按照规定的结构和次序表示ꎮ数字签名文件应包含下面的６个数据字符串:每一个数据字符串应遵守下述格式:ａ)前面有一个标题行ꎮ标题行在开始处用“∥”表示ꎬ后跟一个空格字符和文本标题字符ꎻｅ)每一个数据字符最后有一个行分割符(回车)(为了增加可读性ꎬ一些数据被分成两行)ꎮ示例:∥:∥.∥∥.∥.发布信息的总是在数字签名文件中创建签名/证书对ꎮ需要核实签名文件中的签名/证书对ꎮ签名文件应包括签名和证书对ꎮ仅有签名的文件不能证明的身份ꎬ因此是非法的ꎮ数字签名文件采用文本格式ꎬ并按照规定的结构和次序表示ꎮ文件以下面的次序包含数据字符串:ｃ)第三个数据字符串“Ｒ”ꎬ包括块区域(每区域含４个字符每个数据字符串应遵守下述格式:ａ)前面有一个标题行ꎮ标题航在开始处用“∥”表示ꎬ后跟一个空格字符和文本标题字符ꎻｅ)每一个数据字符最后有一个行分割符(回车)(为了增加可读性ꎬ一些数据被分成两行)ꎮ数字证书ꎬ提取公开密钥ꎬ核实数据的数字签名ꎮ示例:∥:∥:∥:∥:∥.∥∥.∥.签名电子航道图文件的程序由执行ꎬ以对其数据文件进行数字签名ꎮ在签名前ꎬ文件应被压缩和加密ꎮ程序如下:压缩和加密ꎮ文件里面的所有字节都应被散列ꎻａ)使用￣１算法散列所需的文件(基本和更新文件)压缩和加密ꎮ文件里面的所有字节都应被散列ꎻｃ)写在签名文件里面作为头两个数据的字符串应符合９.２所定义的格式ꎮ文件的剩下部分由证书组成ꎬ证书包