EMV 发行人在第二次生成 AC

问题描述

我是 EMV 支付行业的新手，目前正在做一些 EMV 支付开发，希望有人能对我所看到的有所了解。我正在运行适用于我们解决方案的万事达卡 M-TIP 测试，我看到了一些意想不到的结果。运行 M-TIP06 测试 02 时，我收到了 Issuer Authentication Failed 错误。我们的解决方案是纯在线终端，所有交易都必须上线并由主机批准。在我们的测试中，交易由主机批准（返回发行人身份验证代码和授权代码（00 - 已批准））。然而，该卡倾向于在第二次生成中用 AAC 回答响应，并表明发行人身份验证失败。测试卡的 AIP 表明不需要外部身份验证，因此我假设发行人身份验证数据应包含在第二次生成 AC 中。我已附上第 1 次和第 2 次生成 AC 请求和响应。

    1st Generate AC (ARQC)
        Request : 80 AE 80 00 25 00 00 00 00 40 00 00 00 00 00 00 00 07 64 80 00 00 80 00 07 64 21 03 01 00 4A DC F0 6E 21 00 00 1E 03 00 58 00
            Class    :80
            Ins      :AE
            P1       :80
            P2       :00
            Lc       :25
            Data     :00 00 00 00 40 00 00 00 00 00 00 00 07 64 80 00 00 80 00 07 64 21 03 01 00 4A DC F0 6E 21 00 00 1E 03 00 58 00
                Tag 9F 02: Transaction Amount                                             : 00 00 00 00 40 00
                Tag 9F 03: Cashback Amount                                                : 00 00 00 00 00 00
                Tag 9F 1A: Terminal Country Code                                          : 07 64
                Tag 95   : Terminal Verification Results (TVR)                            : 80 00 00 80 00
                Tag 5F 2A: Transaction Currency Code                                      : 07 64
                Tag 9A   : Transaction Date                                               : 21 03 01
                Tag 9C   : Transaction Type                                               : 00
                Tag 9F 37: Unpredictable Number                                           : 4A DC F0 6E
                Tag 9F 35: Terminal Type                                                  : 21
                Tag 9F 45: Data Authentication Code                                       : 00 00
                Tag 9F 34: Cardholder Verification Method (CVM) Results                   : 1E 03 00
                Tag 9B   : Transaction Status information(TSI)                            : 58 00

        Response: C0 77 29 9F 27 01 80 9F 36 02 02 01 9F 26 08 3B 84 CB F3 33 26 6E A6 9F 10 12 02 10 A0 00 0F 24 00 00 00 00 00 00 00 00 00 00 00 FF 90 00
            Ack Byte : C0
            Data     : 77 29 9F 27 01 80 9F 36 02 02 01 9F 26 08 3B 84 CB F3 33 26 6E A6 9F 10 12 02 10 A0 00 0F 24 00 00 00 00 00 00 00 00 00 00 00 FF
                Tag 77   : Response Message Template Format 2                             
                    Tag 9F 27: Cryptogram information Data (CID)                              : 80
                    Tag 9F 36: Application Transaction Counter (ATC)                          : 02 01
                    Tag 9F 26: Application Cryptogram (AC)                                    : 3B 84 CB F3 33 26 6E A6
                    Tag 9F 10: Issuer Application Data [M/Chip 4]                             : 02 10 A0 00 0F 24 00 00 00 00 00 00 00 00 00 00 00 FF
            SW1 SW2  : 90 00 (SW_OK)

    2nd Generate AC (TC)
        Request : 80 AE 40 00 13 60 2D D5 A6 14 D6 00 00 00 12 30 30 80 00 00 80 00 58 00
            Class    :80
            Ins      :AE
            P1       :40
            P2       :00
            Lc       :13
            Data     :60 2D D5 A6 14 D6 00 00 00 12 30 30 80 00 00 80 00 58 00
                Tag 91   : Issuer Authentication Data [M/Chip]                            : 60 2D D5 A6 14 D6 00 00 00 12
                Tag 8A   : Authorization Response Code                                    : 30 30
                Tag 95   : Terminal Verification Results (TVR)                            : 80 00 00 80 00
                Tag 9B   : Transaction Status information(TSI)                            : 58 00
        MChip4 - Symbol 81: Issuer Authentication Failed,declining transaction

    Get Response
        Request : 00 C0 00 00 2B
        Response: C0 77 29 9F 27 01 00 9F 36 02 02 01 9F 26 08 54 A4 CD EF 87 20 FE B1 9F 10 12 02 10 20 10 0F 24 04 00 00 00 00 00 00 00 00 00 00 FF 90 00
            Ack Byte : C0
            Data     : 77 29 9F 27 01 00 9F 36 02 02 01 9F 26 08 54 A4 CD EF 87 20 FE B1 9F 10 12 02 10 20 10 0F 24 04 00 00 00 00 00 00 00 00 00 00 FF
                Tag 77   : Response Message Template Format 2                             
                    Tag 9F 27: Cryptogram information Data (CID)                              : 00
                        Byte 1 bit 8-7 = 00     AAC
                               bit 6-5 = 00     Payment System specific cryptogram
                               bit 4   = 0      No advice required
                               bit 3-1 = 000    No information given
                    Tag 9F 36: Application Transaction Counter (ATC)                          : 02 01
                        Decimal value = 513
                    Tag 9F 26: Application Cryptogram (AC)                                    : 54 A4 CD EF 87 20 FE B1
                    Tag 9F 10: Issuer Application Data [M/Chip 4]                             : 02 10 20 10 0F 24 04 00 00 00 00 00 00 00 00 00 00 FF
                        Key Derivation Index      = 02
                        Cryptogram Version Number = 10
                        Card Verification Results (CVR)  = 20 10 0F 24 04 00
                        DAC                       = 00 00
                        Counters                  = 00 00 00 00 00 00 00 FF
            SW1 SW2  : 90 00 (SW_OK)

如您所见，当第二次生成 AC 时，它显示 MChip4 - 符号 81：颁发者身份验证失败，拒绝交易。如果有人能够提供有关正在发生的事情或出了什么问题的见解，我将不胜感激。

解决方法

我认为您与 MAS 的接口有问题。

除了发行人身份验证问题之外，您还有另一个发行人脚本问题 - 您的发行人脚本不包含 MAC 并且不是正确的命令。奇怪的是您没有尝试发送它们，但是您会收到错误，导致在 TVR 中设置位。

我建议检查您的 MAS 日志以查看您的 ARQC 验证是否通过 - 我认为它没有通过。它要么是您的 MAS 配置错误且配置文件未正确检测（但它生成了脚本，因此情况并非如此，但仍然有人可能修改了 IMK-AC 密钥值），或者您提供的用于身份验证的数据与卡不完整-终端界面。

您应该检查是否所有内容都完全按照卡片传递，但我首先要检查 PSN（映射到字段 23 的标记 5F34）-省略它是一个常见的错误，因为它用于会话密钥派生进程缺少此元素会导致非零值卡的密码验证失败（当我检查日志时，此 MTIP 卡配置文件将其设置为 03）。这是一个常见的错误，不会立即引起注意，因为许多卡片（没有 PSN 或零值 PSN）都在工作。

请不要在测试环境中被响应代码提示，因为它是默认响应，即使数据完全错误但测试脚本没有明确要求在线拒绝交易。

emv smartcard