EMV Issuer Authenticate in second generate AC

Question

我是 EMV 支付行业的新手，目前正在做一些 EMV 支付开发，希望有人能对我所看到的有所了解。我正在运行适用于我们解决方案的万事达卡 M-TIP 测试，我看到了一些意想不到的结果。运行 M-TIP06 测试 02 时，我收到颁发者身份验证失败的错误。我们的解决方案是在线终端，所有交易都必须在线并由主机批准。在我们的测试中，主机批准的交易（返回一个颁发者身份验证代码和授权代码（00 - 已批准））。然而，该卡倾向于在第二次生成中使用 AAC 回答响应，并指示发行者身份验证失败。测试卡的 AIP 表明不需要外部身份验证，因此我假设发行者身份验证数据应包含在第二个生成 AC 中。我附上了第一个和第二个生成 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 - Symbol 81: Issuer Authentication failed, denied transaction。如果有人可以提供有关正在发生的事情或出了什么问题的见解，我将不胜感激。

Answer 1

我认为您与 MAS 的界面有问题。

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

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

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

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