安全报文的目的是为了确保数据的机密性,完整性和对数据发送方的认证。通过报文认证码(MAC)来保障数据的完整性和对发卡行的认证,通过对数据域的加密来保障数据的机密性。
安全报文必须符合以下两种格式的一种。
l 格式一:符合ISO/IEC 7816-4中5.6节的规定的安全报文的格式。这里涉及到的命令的数据域使用BER-TLV编码并严格遵守ASN.1/ISO 8825的编码规则。这是通过将命令的类型字节的低半字节设置为‘C’明确指定的。这也暗示命令头总是和MAC计算相结合的。
l 格式二:所涉及的命令的数据域没有将BER-TLV编码用于安全报文,但可能将其用于其它目的的安全报文的格式。在这种情况下,使用安全报文的命令的发送者及当前被选择的应用必须知道数据域中包含的数据对象以及这些数据对象的长度。根据ISO/IEC 7816-4,符合格式二的安全报文是通过将命令的类型字节的低半字节设置为‘4’明确指定的。
命令的数据域由图三所示的以下TLV数据对象组成。
l 用于签名的命令数据(如果有)。
如果命令的数据域是用BER-TLV编码的,它必须要么不属于上下文相关的类(标签必须不在‘80’到‘BF’之间)要么有一个奇数的标签(注意这可能是一个结构数据对象)。
如果命令的数据域不是用BER-TLV编码的,它必须包含在模板‘81’中。
l 第二个数据对象是MAC。它的标签为‘8E’,它的长度必须在4到8个字节之间。
标签1 |
长度1 |
值1 |
标签2 |
长度2 |
值2 |
T |
L |
值 (L个字节) |
‘8E’ |
‘04’-‘08’ |
MAC(4-8字节) |
图3 – 以完整性和认证为目的的安全报文的命令数据域格式一
使用安全报文的命令的发送者以及当前被选择的应用必须知道包含在数据域中的数据元素(包括MAC)及其相应的数据长度。MAC不是BER-TLV编码且总是数据域中的最后一个数据元素,并且它的长度总是在4到8个字节之间。(见图4)
值1 |
值2 |
命令数据(如果有) |
MAC(4-8字节) |
图4 - 以完整性和认证为目的的安全报文的命令数据域格式二
以完整性和认证为目的的安全报文的MAC生成的第一步包括从IC卡的唯一的16字节MAC主密钥和2字节ATC发散得到一个唯一的16字节MAC 过程密钥。在附录A 1.3中详细说明了一种这样的方法。
MAC是通过使用按照9.2.2节中描述的方法发散得到的MAC过程密钥并将附录A 1.2中描述的机制应用在所要保护的报文上计算得到的。
如果安全报文符合格式一,要保护的报文必须按照ISO/IEC 7816-4中5.6节指明的规则从命令APDU(CLA INS P1 P2)的头部直到命令数据(如果有)来构建。
如果安全报文符合格式二,要保护的报文必须按照支付系统的专有规范来构建。但总是包含了命令APDU(CLA INS P1 P2)的头部以及命令数据(如果有)。
在任何情况下,如果安全报文的MAC的长度被指定小于8个字节,在按上面描述的方法计算得到8个字节的结果后,取其中最左面(最高位)的那些字节来得到MAC。
命令数据域中的加密的数据对象的格式如图5所示。
标签 |
长度 |
值 |
T |
L |
密文(加密的数据) |
图5 - 命令数据域中的加密数据对象格式一
依赖于要加密的明文数据,ISO/IEC 7816-4指定了分配给结果密文的标签。如果该对象与MAC计算相结合,使用奇数的标签,否则使用偶数的标签。
在命令数据域中除了MAC以外,其它明文数据域都被加密(见图6)。
值1 |
值2 |
密文(加密的数据) |
MAC( 如果有) |
图6 - 以机密性为目的的安全报文的命令数据域格式二
以机密性为目的的安全报文的加/解密的第一步包括从IC卡的唯一的16字节加密主密钥和2字节ATC发散得到一个唯一的16字节加密过程密钥。在附录A 1.3中详细说明了一种这样的方法。
对明文/加密命令数据域的加/解密是通过使用按照9.3.2节中描述的方法发散得到的加密过程密钥并应用附录A 1.1中描述的机制进行的。
安全报文机制要求发卡行管理唯一的IC卡MAC和加密主密钥。附录A1.4中描述了一种从PAN和PAN序号发散得到IC卡MAC和加密主密钥的方法。