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