3.5 批式EDI安全规则
3.5.1 批式EDI的安全头段组和安全尾段组的使用规则
3.5.1.1 报文/包级安全-集成报文/包安全
为了保证EDI的安全，UN/CEFACT的开发人员通过使用安全头段组和安全尾段组来实现这个目的，并且为该技术手段制定了规则。这里描述了EDIFACT报文/包级安全的结构。
这里所描述的安全服务，对于任一现有的报文，应通过在UNH段后紧跟安全头段组和在UNT段前加入安全尾段组来提供；对于任一现有的包，应通过在UNO段后紧跟安全头段组和在UNP段前加入安全尾段组来提供。
1）安全头段组和安全尾段组
图3-14描述了表示报文级安全的一个交换。
图3-14 表示报文级安全的一个交换（示意图）
图3-15给出了表示包级安全的一个交换。
图3-15 表示包级安全的一个交换（示意图）
2）安全头段组和安全尾段组的结构
表3-3给出了安全头段组和安全尾段组的段表（报文级安全）。
表3-3 安全头段组和安全尾段组的段表（报文级安全）
表3-4给出了安全头段组和安全尾段组的段表（包级安全）。
表3-4 安全头段组和安全尾段组的段表（包级安全）
3）数据段说明
段组1：USH-USA-SG2 （安全头段组）
本段组标识了所采用的安全服务和安全机制，并包含了执行确认计算所需的数据。
如果对报文/包采用不同的安全服务（如完整性和源抗抵赖性）或几个参与方采用了相同的安全服务，则在同一报文/包中可以有几个不同的安全头段组。
USH，安全头
本段规定了适用于包含本段在内的报文/包的安全服务。
与该安全服务有关的各参与方（即安全数据元发起方和安全数据元接收方）可在本段中标识，除非在采用非对称算法时，它们被无歧义地用证书（即USC段）标识。
在下述情况之一出现时，应在USH段中使用复合数据元安全标识细目（S500）：
● 采用对称算法；
● 采用非对称算法时为区别安全发起方证书和安全接收方证书而提交两个证书。
在后一种情况下，S500中的参与方标识（数据元S500/0511、S500/0513、S500/0515、S500/0586中的任一个）应与在段组2的USC段中出现的某个S500中被限定为“证书持有者”的参与方标识相同。同时，数据元S500/0577应标识所涉及的参与方的功能（即发起方或接收方）。
复合数据元安全标识细目中的数据元密钥名称（S500/0538）可用来在发送方和接收方之间建立密钥关系。
该密钥关系也可通过使用段组1的USA段中的复合数据元算法参数中的数据元密钥标识（S503/0554）来建立。
如果不需要传送段组1中的USA段（因为加密机制已事先在参与方间商定），可使用USH段中的S500/0538。
然而，在同一安全头段组中，本部分推荐使用USH中的S500/0538或USA中带有限定符的S503/0554中的一个，而不是两个都使用。
USH段可规定用于段组1中USA段以及相应的安全尾组中的USR段的二进制区的过滤函数。
USH段可包含一个用于提供顺序完整性的安全顺序号和安全元素的创建日期。
USA，安全算法
本段标识了安全算法及该算法的用法，并包含了所需的技术参数。该算法应直接应用于报文/包的算法，该算法可以是对称算法、哈希函数或压缩算法。例如，对数字签名而言，该算法指明所使用的与报文相关的哈希函数。
非对称算法不应直接在段组1中的USA段内引用，只可在由USC段触发的段组2中出现。
USA段允许出现三次。一次用于提供USH段中规定的安全服务所需的对称算法或哈希函数，其余两次在GB/T 14805.7中描述。
必要时可以使用番丁（Padding）算法。
段组2: USC-USA-USR（证书组）
当使用非对称算法时，本段组包含了用来验证应用于报文/包的安全方法所需的数据。当采用非对称算法来标识所使用的非对称密钥对时，即使不使用证书，也应使用证书段组。
在USC段中，应给出整个证书段组（包括USR段）或只用于无歧义地标识所使用的非对称密钥对所需的数据元。如果两个参与方已经交换了证书或如果证书可从数据库中获得，则可避免整个证书的出现。
当决定引用非EDIFACT证书（诸如X.509）时，应在USC段的数据元0545中标识该证书的语法和版本。这样的证书可在EDIFACT包中传送。
本段组允许出现两次。一次用于报文/包的发送方证书（报文/包的接收方将用它来验证发送方的签名），另一次则是在发送方为了对称密钥的保密性而使用接收方公开密钥的情况下，用于报文/包的接收方证书（只用证书参考引用）。
如果在同一个安全头段组中该段组出现两次，则可用复合数据元安全标识细目（S500）和数据元证书参考（0536）将它们区分开来。
如果不使用非对称算法，该段组应被省略。
USC，证书
本段包含证书持有者的凭证，并标识生成该证书的认证机构。代码型数据元过滤函数（0505）应标识用于段组2的USA段和USR段的二进制区的过滤函数。
USC段中的S500可以出现两次，一次用于证书持有者（识别使用包含于本证书内的公开密钥相对应的私有密钥进行签名的那一方），另一次用于证书发布者（认证机构CA）。
USA，安全算法
本段标识了安全算法及该算法的用法，并包括所需的技术参数。在段组2中，USA段可出现三次，分别标识：
（1）证书发布者用于计算证书的哈希值的算法（哈希函数）；
（2）证书发布者用于生成证书（即签署根据证书内容计算出的哈希函数的结果）的算法（非对称算法）；
（3）发送方用于签署报文/包（即签署根据证书内容计算出的哈希函数的结果）的算法（非对称算法），或发送方使用的接收方非对称算法（非对称算法），该算法用来加密应用于报文/包内容的对称算法所需的密钥，并且这个密钥在由USH段触发的段组1中被引用。
需要时，可使用番丁算法指示。
USR，安全结果
本段包含了认证机构应用于证书的安全功能的结果，该结果应是由认证机构通过签署根据凭证数据计算出的哈希结果而得出的证书的签名。
对证书而言，签名计算始于USC段的第一个字符（即“U”），终止于最后一个USA段的最后一个字符（包括紧随该USA段的分隔符）。
段组 n：UST-USR （安全尾组）
本段组包含与安全头段组的链接和应用于报文/包的安全功能的结果。
UST，安全尾
本段在安全头段组与安全尾段组间建立一个链接，并说明了包含在这些组中安全段的数目。
USR，安全结果
本段包含应用于报文/包的安全功能的结果，这些安全功能是在被链接的安全头段组中规定的。根据在被链接的安全头段组中规定的安全机制，该结果应为下列两种结果之一：（1）根据在安全头段组的段组1中的USA段中指明的算法直接对报文/包进行计算得而出的结果；
（2）通过用非对称算法签署哈希结果而计算出来的结果，其中非对称算法在安全头段组的段组2中的USA段中指明，哈希结果是根据在安全头段组的段组1中的USA段中指明的算法对报文/包进行计算而得出的。
4）安全应用的范围
安全应用的范围有两种可能性。
第一种可能性是每个完整性值、鉴别值及数字签名的计算始于当前的安全头段组，并包含当前的安全头段组和报文体/对象本身。在这种情况下，安全应用的范围不应包括其他的安全头段组或安全尾段组。
安全头段组始于第一个字母“U”，终止于结束该安全头段组的分隔符；报文体/对象始于结束最后一个安全头段组的分隔符之后的第一个字符，终止于第一个安全尾段组的第一个字符前的分隔符。
因此，以这种方式集成的安全服务的执行顺序未作规定。它们彼此间完全独立。
图3-16描述了上述这种情况（在安全头段组2中定义的安全服务的应用范围用阴影框表示）。
图3-16 应用范围：仅为安全头段组和报文体/包（示意图）
第二种可能性是计算始于当前的安全头段组，并包含当前的安全头段组和有关的安全尾段组。在这种情况下，安全应用的范围应包括当前的安全头段组、报文体/对象以及其他所有被嵌入的安全头段组和安全尾段组。
该范围应包括从当前的安全头段组的第一个字符“U”到有关的安全尾段组的第一个字符之前的分隔符的每一个字符。
图3-17描述了上述这种情况（在安全头段组2中定义的安全服务的应用范围用阴影框表示）。
图3-17 应用范围：从安全头段组到安全尾段组（示意图）
对于每个新增的安全服务，可选择上述两种范围中的一个。在上述两种情况中，安全头段组和有关的安全尾段组之间的关系应由USH和UST段中的数据元安全参考号提供。
3.5.1.2 使用原则
1）服务的选择
安全头段组可包含下列通用信息：
● 所应用的安全服务；
● 有关的参与方的标识；
● 所使用的安全机制；
● “唯一”值（顺序号和/或时戳）；
● 接收的抗抵赖性请求。
如果在同一EDIFACT结构中需要多种安全服务时，则安全头段组可以出现多次。这就是涉及多对参与方的情况。但是，当同一对参与方需要多个安全服务时，这些服务可以含于一对安全头段组和安全尾段组之中，就好象某个服务隐含于其他服务中一样。
2）真实性
如果EDIFACT结构要求源鉴别服务，则应使用一对适当的安全头段组和安全尾段组并根据GB/T 18794.2规定的原则提供该项服务。
源鉴别安全服务应在段组1的USH段中规定，算法则在该段组的USA段中标识。
安全发起方应计算在安全尾段组中的USR段中传送的真实性值，安全接收方应查证该真实性值。
该服务可以包括完整性服务，并且作为一个“源抗抵赖性”服务的副产品的形式获得。
如果基于防拆硬件或可信第三方实施适当的“源鉴别”服务，则可把它当成一个“源抗抵赖性”服务的实例。这样的做法应在交换协定中予以明确。
3）完整性
如果EDIFACT结构要求内容完整性服务，则应使用一对适当的安全头段组和安全尾段组并根据GB/T 18794.6—2003规定的原则提供该项服务。
完整性安全服务应在段组1的USH段中规定，算法则在段组1的USA段中标识。该算法应是哈希函数或对称算法。
安全发起方应计算在安全尾段组中的USR段中传送的完整性值，安全接收方应查证该完整性值。
完整性服务可以通过源鉴别服务或源抗抵赖性服务的副产品的形式获得。
如果需要顺序完整性服务，则应在安全头段组中或者包含安全顺序号和安全时戳的两者之一，或者包含这两者；同时还应使用内容完整性服务、源鉴别服务和源抗抵赖性服务中的一个。
4）源抗抵赖性
如果EDIFACT结构要求源抗抵赖性服务，则应使用一对适当的安全头段组和安全尾段组并根据GB/T 18794.4—2003规定的原则提供该项服务。
源抗抵赖性安全服务应在段组1的USH段中规定，哈希算法则在段组1中的USA段中标识，如果使用证书，还应在段组2的USA段中标识用于签名的非对称算法。
如果证书不在报文/包中传送，接收方应知晓所采用的算法为非对称算法。在这种情况下，该非对称算法应在交换协定中明确。
安全服务发起方应计算在安全尾段组的USR中传送的数字签名，安全服务接收方应查证该数字签名值。
源抗抵赖性服务还能提供内容完整性和源鉴别服务。
3.5.1.3 符合EDIFACT语法的内部表示法和过滤器
采用数学算法计算完整性数值和数字签名带来了两个问题。
第一个问题是计算结果依赖于字符集的内部表示。这样，发送方数字签名的计算及接收方对该签名的验证就应使用同一字符集编码来完成。因此，发送方可以指明用于生成原始的安全确认结果的表示法。
第二个问题是安全的计算结果类似随机的位模式。这可能会导致在传输期间和使用翻译软件时出现问题。为避免这些问题，利用过滤函数将位模式可逆地映射到所使用的字符集的特定表示法上。为简单起见，每个安全服务只使用一个过滤函数。这个映射的结果中所出现的异常终止符通过加入一个转义序列来处理。
3.5.2 批式EDI的交换和组的安全头段组与安全尾段组的使用规则
3.5.2.1 组级和交换级的安全——集成的报文安全
与报文/包传送相关的安全威胁及针对这些威胁的安全服务也适用于组级和交换级。
在第2章描述的用于报文/包的安全技术，也可用于交换级和组级。
就组级和交换级安全而言，应采用与报文/包级安全中相同的安全头段组和安全尾段组，即使安全应用于多个以上的级上，头尾交叉引用应总是应用于同一级。
在报文/包级应用安全时，被保护的结构是报文体或对象；在组级时，是该组中包括所有报文/包的头和尾在内的所有报文/包的集合；在交换级时，是该交换中包括所有报文/包或组的头和尾在内的所有报文/包或交换的集合。
3.5.2.2 安全头段组和安全尾段组
图3-18描述了同时含有交换级安全和组级安全的一个交换。
图3-18 同时含有交换级安全和组级安全的一个交换（示意图）
3.5.2.3 安全头段组和安全尾段组的结构
仅为交换级安全头段组和安全尾段组段表见表3-5，仅为组级安全头段组和安全尾段组段表见表3-6。
表3-5 安全头段组和安全尾段组段表（仅为交换级安全）
表3-6 安全头段组和安全尾段组段表（仅为组级安全）
3.5.2.4 安全应用的范围
安全应用的范围有两种可能性。
第一种可能性是每个完整性值、鉴别值及数字签名的计算始于当前的安全头段组，并包含当前的安全头段组和组/包本身。在这种情况下，安全应用的范围不应包括其他的安全头段组或安全尾段组。
安全头段组始于第一个字母“U”，终止于结束该安全头段组的分隔符；组或报文/包始于结束最后一个安全头段组的分隔符之后的第一个字符，终止于第一个安全段组的第一个字符前的分隔符。
因此，以这种方式集成的安全服务的执行顺序未做规定，它们彼此间完全独立。
图3-19和图3-20描述了上述这种情况（在安全头段组2中定义的安全服务的应用范围用阴影框表示）。
图3-19 应用范围：仅为安全头段组和组或报文/包（示意图）
图3-20 应用范围：仅为安全头段组和报文/包（示意图）
第二种可能性是计算始于并包含当前的安全头段组，终止于有关的安全尾段组。在这种情况下，安全应用的范围应包括当前的安全头段组、组或报文/包以及其他所有被嵌入的安全头段组和安全尾段组。
该范围应包括从当前的安全头段组的第一个字符“U”到有关的安全尾段组的第一个字符之前的分隔符的每一个字符。
图3-21和图3-22描述了上述这种情况（在安全头段组2中定义的安全服务的应用范围用阴影框表示）。
图3-21 应用范围：从安全头段组到安全尾段组（示意图）
图3-22 应用范围：从安全头段组到安全尾段组（示意图）
对每个新增的安全服务，可选择上述两种范围中的一个。在上述两种情况中，安全头段组和有关的安全尾段组之间的关系应由USH和UST段中的数据元安全参考号提供。