作者:法律资料网 时间:2024-07-03 09:08:34  浏览:9388   来源:法律资料网

建设银行


中国人民建设银行业务网间交易报文验证代码（ＭＡＣ）的算法（试行）
建设银行



本算法等同采用ＩＳＯ9807和ＩＳＯ8731－1。
一、主题内容
报文验证代码字段是在报文发送者和接收者之间，对报文始发源和内容的有效性进行验证的字段。由所有位元表的最后位元，即比特位第64位或128位表示。建设银行业务网间交易中报文验证代码（ＭＡＣ），遵照ＩＳＯ9807《银行业务及其相关金融服务——报文验证要求》
的要求，采用ＩＳＯ8731－1《银行业务——已核准的报文验证算法第一部分ＤＥＡ》产生。
二、应用指南
根据ＩＳＯ8731－1中4．2认证元的要求和建设银行网间交易格式的定义，建设银行业务网间交易格式中参加ＭＡＣ验证的数据应包括ＩＳＯ9807附录Ｄ“认证元选择指南”所确定的内容。
三、ＩＳＯ9807《银行业务及其相关金融服务——报文验证要求》
0．简介
报文验证码（ＭＡＣ）可用于认证在发送者和接受者之间传递的报文的出处和内容。发送者产生ＭＡＣ并将其与相关报文一同传输。
该国际标准使那些希望在零售银行业环境中实现报文认证的机构能够以安全的方式进行，并且对不同的实现方法之间提供便利的相互协作。
报文验证码是一个数据域，可用于验证报文的真实性。它或者由整条报文产生，或者由报文中那些需要保护以防偶然或故意篡改的特定数据元产生。
本国际标准属于描述零售银行业务环境中安全要求的系列标准。与之相关的另一系列标准描述了批发银行业务环境中的安全要求。
本标准的要求与ＩＳＯ8730相兼容，并均与ＩＳＯ8731有着紧密的联系，ＩＳＯ8731描述了已批准的用于报文认证的算法。
1．适用范围
该标准描述了用于保护零售银行业务报文完整性和用于证实报文来源的一系列规程，并且描述了已批准的用于零售银行业务报文认证算法。
尽管通信双方有必要采用同一数据表示方法，标准中并未定义数据表示规则，而且认证过程也与传输过程相互独立。
附录Ａ给出了已批准的报文验证码（ＭＡＣ）算法清单，附录Ｂ则描述了算法加入标准的核准过程，附录Ｃ提供关于防止穷举法确定密钥的方法。
附录Ｄ在如何挑选认证元上给予指导，附录Ｅ提供有关防止由发方或收方引起的内部欺骗（例如收方伪造报文验证码）的一般信息，附录Ｆ描述了产生伪随机密钥的方法，附录Ｇ提供一些参考书目。
本国际标准不提供：
ａ）为防止报文非授权泄露而进行的加密；以及
ｂ）有意或无意的报文丢失或重复的防范。
该标准适用于负责实现零售银行业务环境中报文认证的机构。
2．规范参考
以下标准包含的条款通过本国际标准的引用，构成本国际标准的条款。在其发布之时，所注明的版本有效。所有标准都可能再修订，所以鼓励基于本国际标准达成协议的各方，调查应用以下标准的最新版本的可能性。ＩＥＣ和ＩＳＯ的成员保持对当前有效的国际标准的注册。
ＩＳＯ8730：1990，银行业务——报文认证要求（批发）。
ＩＳＯ8731——1：1987，银行业务——已核准的报文认证算法——第一部分：ＤＥＡ。
ＩＳＯ8731——2：1997，银行业务——已核准的报文认证算法——第二部分：报文认证器算法。
3．术语
本国际标准采用以下术语及定义：
3．1 算法（ａｌｇｏｒｉｔｈｍ）：一个用于计算的特定数学过程。
3．2 认证（ａｕｔｈｅｎｔｉｃａｔｉｏｎ）：为了确保数据完整性并提供数据来源认证而在收发双方间使用的一个过程。
3．3 认证算法（ａｕｔｈｅｎｔｉｃａｔｉｏｎ ａｌｇｏｒｉｔｈｍ）：使用认证密钥、一个或多个认证元完成认证的算法。
3．4 认证元（ａｕｔｈｅｎｔｉｃａｔｉｏｎ ｅｌｅｍｅｎｔ）：将由认证保护的一个报文元。
3．5 认证密钥（ａｕｔｈｅｎｔｉｃａｔｉｏｎ ｋｅｙ）：用于认证的加密密钥。
3．6 加密密钥（ｃｒｙｐｔｏｇｒａｐｈｉｃ ｋｅｙ）：完成证实、认证、加密或解密并被某一算法使用的一个参数。
3．7 密钥有效期（ｃｒｙｐｔｏｐｅｒｉｏｄ）：某一特定密钥被授权可用的一段时间，或给定系统密钥保持有效的一段时间。
3．8 加密（ｅｎｃｉｐｈｅｒｍｅｎｔ）：将可读的明文转换为不可读的密文的过程，以确保安全性或私有性。
3．9 报文认证码（MAC）（Message Authentication Code）：在收发方之间传递的报文中，用于证实报文源和部分或全部报文内容。该码为一个协定计算结果。
3．10 报文元（ｍｅｓｓａｇｅ ｅｌｅｍｅｎｔ）：为特定目的而指定的一串连续字符。
3．11 接收者（ｒｅｃｅｉｖｅｒ）：接收报文的一方。
3．12 发送者（ｓｅｎｄｅｒ）：负责且有权发送报文的一方。
4．报文认证过程
4．1 认证密钥
认证密钥是供认证算法使用、保密的加密密钥，发方和收方应事先互相交换并确定。密钥必须是随机或伪随机产生的（见附录Ｆ）。用于报文认证的密钥不能用于其他目的，而且应加以保护，以防泄漏给非授权方。
4．2 认证元
收发双方协定应包括在ＭＡＣ的运算中的报文元，以防欺骗性更改。
注：
1．建议所有报文元加入ＭＡＣ计算；
2．ＭＡＣ计算中可包括不发送元素。
ＭＡＣ的计算中应忽略用于传输目的的头、尾报文信息。
4．3 ＭＡＣ长度
ＭＡＣ的长度应为32比特。
4．4 ＭＡＣ生成
认证算法使用认证密钥和认证元，应依照收发双方协定的某一已批准认证算法的要求生成ＭＡＣ。
注：
3．已批准认证算法清单见附录Ａ。
4．生成ＭＡＣ后，若改变认证元或其表示的序列顺序，将导致认证失败。
4．5 ＭＡＣ的放置
ＭＡＣ应放于：
ａ）报文中为ＭＡＣ指定的域；或者
ｂ）如果没有ＭＡＣ指定域，附加在报文的数据部分的尾部。
若为了传输目的，分配的域大于32比特，则ＭＡＣ应在该域内以左对齐放置。
5．ＭＡＣ的验证
为了验证含有ＭＡＣ报文的完整性，接收者采用4．4中指定的计算方法计算出一个ＭＡＣ（参考ＭＡＣ），计算时应以与发方相同的顺序使用相同数据、相同认证密钥和相同的认证算法。收到的ＭＡＣ域不应包括在参考ＭＡＣ的计算中。
将参考ＭＡＣ与收到的ＭＡＣ进行比较，若完全相同，则认证元的完整性以及报文来源的正确性得到证实。
6．认证算法的核准过程
在一个认证算法被批准加入附录Ａ以前，该算法应满足以下两个基本要求：
ａ）该算法应提供附录Ａ中已有算法所没有的功能。例如，适用于一个不同的操作环境，或可显著减少实现或操作费用，或可提供更高级别的保护。
ｂ）对所宣称功能有足够的把握。
附录略。



1995年8月16日