CN116016302B - 基于https的智能卡数据加解密测试方法和系统 - Google Patents

Abstract

本发明公开了一种基于HTTPS的智能卡数据加解密测试方法、基于HTTPS的智能卡数据加解密测试系统、控制器及计算机存储介质，方法包括：智能卡端向服务器端发送第一随机数和多个支持加密方法，服务器端向智能卡端发送第二随机数和目标加密方法，智能卡端将第一整体校验值加密传输至服务器端，以使服务器端根据解密的第一验证数据得到第一验证结果；服务器端将第二整体校验值加密传输至智能卡端，以使智能卡端根据解密的第二验证数据得到第二验证结果，本申请运用于对交互数据进行测试验证的过程中，根据第一和第二验证结果确定智能卡端与服务器端之间是否握手协商成功，进而实现自动测试，提升测试效率和测试覆盖面。

Description

基于HTTPS的智能卡数据加解密测试方法和系统

技术领域

本申请涉及智能卡测试技术领域，具体涉及一种基于HTTPS的智能卡数据加解密测试方法和基于HTTPS的智能卡数据加解密测试系统。

背景技术

HTTPS(超文本传输安全协议):它是由 HTTP + TLS/SSL 协议（也就是在 HTTP 上又加了一层处理加密信息的模块。服务端和客户端的信息传输都会通过 TLS 进行加密）构建的可进行加密传输、身份认证的网络协议，主要通过数字证书、加密方法、非对称密钥等技术完成互联网数据传输加密，实现互联网传输安全保护；

然而现有技术中，随着数据传输安全需求的普及，通过PRF(伪随机数方法)、哈希sha256/sha1、AES等方法组合计算解析智能卡端与服务器交互之间数据传输的明文和密文，期间计算验证过程繁琐，因此迫切需要一种通用的用于对交互数据进行测试验证的方法及系统。

发明内容

本申请实施例提供一种基于HTTPS的智能卡数据加解密测试方法和基于HTTPS的智能卡数据加解密测试系统，至少能保证，本申请方案通过自动化测试套件，自动模仿所述服务器端指令与智能卡端进行交互，得到验证结果，实现自动测试，提升测试效率。

第一方面，本申请实施例提供了一种基于HTTPS的智能卡数据加解密测试方法，应用于基于HTTPS的智能卡数据加解密测试系统，所述测试系统包括测试模块，所述测试模块包括智能卡端和服务器端，所述测试方法包括：

所述智能卡端向所述服务器端发送第一随机数和多个支持加密方法；

所述服务器端向所述智能卡端发送第二随机数，并发送从多个所述支持加密方法中确定的目标加密方法；

所述智能卡端向所述服务器端发送密钥交换数据，并将与所述服务器端的连接状态转从明文状态转换到加密状态；

所述智能卡端根据所述第一随机数、所述第二随机数、所述密钥交换数据和所述目标加密方法，将第一整体校验值加密传输至所述服务器端，以使所述服务器端根据解密的第一验证数据得到第一验证结果；

所述服务器端将与所述智能卡端的连接状态转从明文状态转换到加密状态，所述服务器端根据所述第一随机数、所述第二随机数、所述密钥交换数据和所述目标加密方法，将第二整体校验值加密传输至所述智能卡端，以使所述智能卡端根据解密的第二验证数据得到第二验证结果。

在一些实施例中，所述测试系统还包括数据加解密模块，所述智能卡端向所述服务器端发送第一随机数和多个支持加密方法之前，还包括：

所述数据加解密模块设置生成多种密钥方法、第一整体校验值加密成智能卡端TLS信息方法、解密智能卡端TLS信息方法、第二整体校验值加密成服务器端TLS信息方法、解密服务器端TLS信息方法和HTTPS内容打包方法。

在一些实施例中，所述测试系统还包括读卡器模块，所述智能卡端向所述服务器端发送第一随机数和多个支持加密方法，包括：

在所述读卡器模块检测到所述智能卡端通过所述读卡器模块与所述服务器端连接的情况下，所述智能卡端向所述服务器端发送第一随机数和多个支持加密方法。

在一些实施例中，所述将第一整体校验值加密传输至所述服务器端，以使所述服务器端根据解密的第一验证数据得到第一验证结果，包括：

所述智能卡端通过对明文状态的握手信息进行拼接处理，得到第一整体校验值，并将所述第一整体校验值加密传输至所述服务器端；

所述服务器端对接收到的加密的所述第一整体校验值进行解密处理，得到第一验证数据；

所述服务器端在所述第一验证数据与所述第一整体校验值一致的情况下，得到第一验证结果为验证通过。

在一些实施例中，所述将第二整体校验值加密传输至所述智能卡端，以使所述智能卡端根据解密的第二验证数据得到第二验证结果，包括：

所述服务器端通过对明文状态的握手信息和所述第一整体校验值进行拼接处理，得到第二整体校验值，并将所述第二整体校验值加密传输至所述智能卡端；

所述智能卡端对接收到的加密的所述第二整体校验值进行解密处理，得到第二验证数据；

所述智能卡端在所述第二验证数据与所述第二整体校验值一致的情况下，得到第二验证结果为验证通过。

在一些实施例中，所述智能卡端根据解密的第二验证数据得到第二验证结果之后，包括：

在所述第一验证结果和所述第二验证结果均为验证通过的情况下，确定所述智能卡端和所述服务器端之间的加密通信状态为握手协商成功。

在一些实施例中，所述确定所述智能卡端和所述服务器端之间的加密通信状态为握手协商成功之后，还包括：

根据所述HTTPS内容打包方法对目标传输内容进行转码打包下发处理，以使所述目标传输内容在所述智能卡端和所述服务器端之间进行加密传输；

所述服务器端向所述智能卡端加密传输APDU应用协议数据单元，所述智能卡端在接收到APDU后向所述服务器加密传输响应数据。

第二方面，本申请实施例提供了一种基于HTTPS的智能卡数据加解密测试系统，所述测试系统包括测试模块，所述测试模块包括智能卡端和服务器端；

所述智能卡端用于向所述服务器端发送第一随机数和多个支持加密方法，向所述服务器端发送密钥交换数据，并将与所述服务器端的连接状态转从明文状态转换到加密状态，根据所述第一随机数、第二随机数、所述密钥交换数据和目标加密方法，将第一整体校验值加密传输至所述服务器端，以使所述服务器端根据解密的第一验证数据得到第一验证结果；

所述服务器端用于向所述智能卡端发送所述第二随机数，并发送从多个所述支持加密方法中确定的所述目标加密方法，将与所述智能卡端的连接状态转从明文状态转换到加密状态，所述服务器端根据所述第一随机数、所述第二随机数、所述密钥交换数据和所述目标加密方法，将第二整体校验值加密传输至所述智能卡端，以使所述智能卡端根据解密的第二验证数据得到第二验证结果。

第三方面，本申请实施例提供了一种控制器，包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如第一方面中任意一项实施例所述的基于HTTPS的智能卡数据加解密测试方法。

第四方面，本申请实施例提供了一种计算机可读存储介质，存储有计算机可执行指令，计算机可执行指令用于执行如第一方面中任意一项实施例所述的基于HTTPS的智能卡数据加解密测试方法。

本申请至少具有以下有益效果：所述基于HTTPS的智能卡数据加解密测试方法应用于基于HTTPS的智能卡数据加解密测试系统，所述测试系统包括测试模块，所述测试模块包括智能卡端和服务器端，所述测试方法包括：所述智能卡端向所述服务器端发送第一随机数和多个支持加密方法；所述服务器端向所述智能卡端发送第二随机数，并发送从多个所述支持加密方法中确定的目标加密方法；所述智能卡端向所述服务器端发送密钥交换数据，并将与所述服务器端的连接状态转从明文状态转换到加密状态；所述智能卡端根据所述第一随机数、所述第二随机数、所述密钥交换数据和所述目标加密方法，将第一整体校验值加密传输至所述服务器端，以使所述服务器端根据解密的第一验证数据得到第一验证结果；所述服务器端将与所述智能卡端的连接状态转从明文状态转换到加密状态，所述服务器端根据所述第一随机数、所述第二随机数、所述密钥交换数据和所述目标加密方法，将第二整体校验值加密传输至所述智能卡端，以使所述智能卡端根据解密的第二验证数据得到第二验证结果，其中，本申请能通用的运用于对交互数据进行测试验证的过程中，根据第一和第二验证结果确定智能卡端与服务器端之间是否握手协商成功，进而实现自动测试，提升测试效率和测试覆盖面。

附图说明

图1为本申请一实施例提出的基于HTTPS的智能卡数据加解密测试方法的流程图；

图2为本申请一实施例提出的基于HTTPS的智能卡数据加解密测试方法的另一流程图；

图3为本申请一实施例提出的基于HTTPS的智能卡数据加解密测试方法的另一流程图

图4为本申请一实施例提出的基于HTTPS的智能卡数据加解密测试方法的另一流程图；

图5为服务器端和智能卡端之间进行HTTPS交互的示意图；

图6为服务器端和智能卡端之间进行HTTPS交互的步骤流程图；

图7为服务器端和智能卡端之间进行HTTPS交互的指令流向图；

图8为智能卡端和服务器端之间信息交互的示意图；

图9为本申请另一实施例提出的控制器的结构图。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本申请，并不用于限定本申请。

在一些实施例中，虽然在系统示意图中进行了功能模块划分，在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于系统中的模块划分，或流程图中的顺序执行所示出或描述的步骤。说明书和权利要求书及上述附图中的术语第一、第二等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。

HTTPS(超文本传输安全协议):它是由 HTTP + TLS/SSL 协议（也就是在 HTTP 上又加了一层处理加密信息的模块。服务端和客户端的信息传输都会通过 TLS 进行加密）构建的可进行加密传输、身份认证的网络协议，主要通过数字证书、加密方法、非对称密钥等技术完成互联网数据传输加密，实现互联网传输安全保护；然而现有技术中，随着数据传输安全需求的普及，通过PRF(伪随机数方法)、哈希sha256/sha1、AES等方法组合计算解析智能卡端与服务器交互之间数据传输的明文和密文，期间计算验证过程繁琐，因此迫切需要一种通用的用于对交互数据进行测试验证的方法及系统。

为至少解决上述问题，本申请公开了一种基于HTTPS的智能卡数据加解密测试方法、基于HTTPS的智能卡数据加解密测试系统、控制器及计算机存储介质，其中，基于HTTPS的智能卡数据加解密测试方法应用于基于HTTPS的智能卡数据加解密测试系统，测试系统包括测试模块，测试模块包括智能卡端和服务器端，测试方法包括：智能卡端向服务器端发送第一随机数和多个支持加密方法；服务器端向智能卡端发送第二随机数，并发送从多个支持加密方法中确定的目标加密方法；智能卡端向服务器端发送密钥交换数据，并将与服务器端的连接状态转从明文状态转换到加密状态；智能卡端根据第一随机数、第二随机数、密钥交换数据和目标加密方法，将第一整体校验值加密传输至服务器端，以使服务器端根据解密的第一验证数据得到第一验证结果；服务器端将与智能卡端的连接状态转从明文状态转换到加密状态，服务器端根据第一随机数、第二随机数、密钥交换数据和目标加密方法，将第二整体校验值加密传输至智能卡端，以使智能卡端根据解密的第二验证数据得到第二验证结果，其中，本申请能通用的运用于对交互数据进行测试验证的过程中，根据第一和第二验证结果确定智能卡端与服务器端之间是否握手协商成功，进而实现自动测试，提升测试效率和测试覆盖面。

下面结合附图，对本申请实施例作进一步描述。

参考图1，图1为本申请第一方面的提出的基于HTTPS的智能卡数据加解密测试方法的流程图，在一些实施例中，本申请实施例提供了一种基于HTTPS的智能卡数据加解密测试方法，应用于基于HTTPS的智能卡数据加解密测试系统，测试系统包括测试模块，测试模块包括智能卡端和服务器端，测试方法包括但不限于有以下步骤S110、步骤S120、步骤S130、步骤S140和步骤S150；

步骤S110，智能卡端向服务器端发送第一随机数和多个支持加密方法；

在一些实施例中，第一随机数即为智能卡端随机数，测试系统还包括数据加解密模块，智能卡端向服务器端发送第一随机数和多个支持加密方法之前，还包括：数据加解密模块设置生成多种密钥方法、第一整体校验值加密成智能卡端TLS信息方法、解密智能卡端TLS信息方法、第二整体校验值加密成服务器端TLS信息方法、解密服务器端TLS信息方法和HTTPS内容打包方法。其中，数据加解密模块用于在智能卡端和服务器端之间进行加密通信前设计好所需要的密钥方法、加解密方法和打包下发方法，密钥方法具体包括如下：用于设计生成Pre Master Secret（预主密钥）的方法、Master Secret（主密钥）的方法和keyBlock（密钥块）的方法，参与预主密钥方法的关键数据为：PSK（pre shared key共享密钥）；参与主密钥的关键数据为：Pre Master Secret, 固定字段"master secret", 客户端（以下简称智能卡端）随机数，服务器随机数以及所需要生成Master Secret的长度；参与密钥块方法的关键数据为：Master Secret,固定字段 "key expansion", 服务器随机数，智能卡端随机数以及所需要生成key Block（密钥块）的长度。

在一些实施例中密钥块通过衍生分为以下六把密钥：CLIENT_WRITE_MAC，SERVER_WRITE_MAC，CLIENT_WRITE_KEY ，SERVER_WRITE_KEY ，CLIENT_WRITE_IV ，SERVER_WRITE_IV，上述密钥对应本申请中的密钥交换数据，用于进行传输数据的加密。

在一些实施例中，数据加解密模块的加解密方法设计过程包括：

设计解密智能卡端TLS(Transport Layer Security传输层安全协议)信息的方法，该方法用于得到第一整体校验值，参与该方法的关键数据为：智能卡端产生的密文（即当前传输给服务器端的TLS信息），CLIENT_WRITE_KEY, CLIENT_WRITE_IV，解密得到智能卡端数据的Verify data（校验值）以及MAC值；

设计第一整体校验值加密成智能卡端TLS信息方法，该方法用于加密第一整体校验值，参与该方法的关键数据为：智能卡端SN（Serial number序列号），智能卡端Verifydata，以上两个明文数据拼接好后，通过哈希方法以及CLIENT_WRITE_MAC密钥生成mac值，再通过拼接智能卡端Verify data、mac值，用上CLIENT_WRITE_KEY，CLIENT_WRITE_IV置入最开始所协商好的加密方法算出密文，其中，智能卡端SN默认为0，每传输一条TLS信息，智能卡端SN加1；

上述两个方法是验证解密智能卡端TLS信息过程中产生的数据反过来加密成密文是否和智能卡端产生的密文（即当前传输给服务器端的TLS信息）一致，即相互验证。

在一些实施例中，数据加解密模块的加解密方法设计过程包括：

设计解密服务器端TLS信息的方法，该方法用于得到第二整体校验值，参与该方法的关键数据为：服务器端产生的密文（即当前传输给智能卡端的TLS信息），SERVER_WRITE_KEY, SERVER_WRITE_IV，解密得到服务器端数据的Verify data以及mac值；

设计第二整体校验值加密成服务器端TLS信息方法，该方法用于加密第二整体校验值，参与该方法的关键数据为：服务器端SN，服务器端Verify data，以上两个明文数据拼接好后，通过哈希算法以及SERVER_WRITE_MAC密钥生成mac值，再通过拼接服务器端Verifydata、mac值，用上SERVER_WRITE_KEY，SERVER_WRITE_IV置入最开始所协商好的加密算法算出密文；其中，服务器端SN默认为0，每传输一条TLS信息，服务器端SN加1；

上述两个方法是验证解密服务器端TLS信息过程中产生的数据反过来加密成密文是否和服务器端产生的密文（即当前传输给智能卡端的TLS信息）一致，即相互验证。

在一些实施例中，智能卡端向服务器端发送Client Hello，该中包括智能卡端随机数和多个支持加密方法。

步骤S120，服务器端向智能卡端发送第二随机数，并发送从多个支持加密方法中确定的目标加密方法；

在一些实施例中，第二随机数即为服务器随机数，服务器端在接收到ClientHello后，向智能卡端发送 Server Hello，该生成过程如下：根据相应HTTPS规范设计一条正常的Server Hello，关键参数包括服务器随机数，以及服务器选择的目标加密方法（即此次进行握手选择哪种加密算法传输（密钥协商））。

步骤S130，智能卡端向服务器端发送密钥交换数据，并将与服务器端的连接状态转从明文状态转换到加密状态；

在一些实施例中，智能卡端向服务器端发送Server Hello Done，该根据相应HTTPS规范正常设计，然后智能卡端再向服务器端发送Client Key Exchange，该包括智能卡端需要为密钥交换提供的数据，例如包含PSK或者智能卡端ICCID等信息（根据不同OS平台设计不同的便于识别的信息），上述信息发送完毕后，智能卡端再向服务器端发送ChangeCipher Spec（client to server），根据相应HTTPS规范正常设计此条协议转换信息，通知服务器此后的通信按照协商好的方式进行加密通信，作用是将连接状态从先前智能卡端的明文状态转换到后续加密状态，进而进行后续加解密测试过程。

步骤S140，智能卡端根据第一随机数、第二随机数、密钥交换数据和目标加密方法，将第一整体校验值加密传输至服务器端，以使服务器端根据解密的第一验证数据得到第一验证结果；

在一些实施例中，S140步骤对应智能卡端在Change Cipher Spec（client toserver）进行协议转换，将连接状态从明文状态转换到加密状态后，智能卡端通过Finished（client to server），将包含连接至今全部信息的第一整体校验值（智能卡端verify-data）,加密之后发送给服务器端，并在服务器端进行验证，这次验证是否成功, 要以服务器是否能够正确解密该密文作为判定标准；具体的，第一整体校验值生成方法如下，将ClientHello、ServerHello、ServerHelloDone、Client Key Exchange四条信息进行拼接，并通过封装好的目标加密方法（如PRF(伪随机数方法)、哈希算法方法组合）根据拼接信息计算出的第一整体校验值（智能卡端verify-data）。

步骤S150，服务器端将与智能卡端的连接状态转从明文状态转换到加密状态，服务器端根据第一随机数、第二随机数、密钥交换数据和目标加密方法，将第二整体校验值加密传输至智能卡端，以使智能卡端根据解密的第二验证数据得到第二验证结果。

在一些实施例中，步骤S150中，服务器端通过发送Change Cipher Spec（serverto client），进行协议转换，将连接状态从明文状态转换到加密状态，通过发送Finished（server to client），将包含连接至今全部信息的第二整体校验值（服务器端verify-data）, 加密之后发送给智能卡端，并在智能卡端进行验证 这次验证是否成功, 要以智能卡端是否能够正确解密该密文作为判定标准；具体的，第二整体校验值生成方法如下，将ClientHello、ServerHello、ServerHelloDone、Client Key Exchange四条信息再加上智能卡端verify-data（第一整体校验值）进行拼接，并通过封装好的目标加密方法（如PRF(伪随机数方法)、哈希算法方法组合）根据拼接信息计算出第二整体校验值（服务器端verify-data）。

在一些实施例中，步骤S140和步骤S150得到第一验证结果和第二验证结果，根据第一和第二验证结果确定智能卡端与服务器端之间是否握手协商成功的同时，还会保留测试日志，解决手动测试没有测试日志的问题，其中，测试日志进行格式化，记录每一步测试，提升测试的正确性。正确验证结果和错误验证结果都有相应的测试日志显示，减少手动测试排错的时间，也利于后期产品质量审计，其中，正确验证结果代表第一验证结果和第二验证结果均为验证通过，错误验证结果代表第一验证结果和第二验证结果中任意一次验证结果错误，进而导致交互终止。

在一些实施例中，测试系统还包括读卡器模块，智能卡端向服务器端发送第一随机数和多个支持加密方法，包括：在读卡器模块检测到智能卡端通过读卡器模块与服务器端连接的情况下，智能卡端向服务器端发送第一随机数和多个支持加密方法，其中，读卡器模块用于判断智能卡端是否通过连接读卡器连接服务器端，读卡器模式是否为接触式，判断当前服务器端是否正常连接智能卡端，如果正常连接，执行后续步骤，如果不存在智能卡端与读卡器连接则报错，中止测试。

在一些实施例中，在数据加解密模块设计完方法，读卡器模块进行完检测之后，本申请的测试模块进行握手协商，通过智能卡端的Open Channel（打开通道，一种APDU指令）开启交互，进行如步骤S110至步骤S150中方法步骤，实现自动化组合加密算法，快速运算得到预期输出值。本申请通过自动化测试套件，自动模仿不同服务器指令与智能卡端进行交互，根据第一和第二验证结果确定智能卡端与服务器端之间是否握手协商成功，解决了手动测试容易出现错误且效率低的问题，实现自动测试，进而提升了测试效率和测试覆盖面；且本申请能有效保留测试日志，解决了手动测试没有测试日志的问题。

参考图2，图2为本申请一实施例提出的基于HTTPS的智能卡数据加解密测试方法的流程图，在一些实施例中，将第一整体校验值加密传输至服务器端，以使服务器端根据解密的第一验证数据得到第一验证结果，测试方法包括但不限于有以下步骤S210、步骤S220和步骤S230；

步骤S210，智能卡端通过对明文状态的握手信息进行拼接处理，得到第一整体校验值，并将第一整体校验值加密传输至服务器端；

步骤S220，服务器端对接收到的加密的第一整体校验值进行解密处理，得到第一验证数据；

步骤S230，服务器端在第一验证数据与第一整体校验值一致的情况下，得到第一验证结果为验证通过。

在一些实施例中，服务器端接收 Finished （client to server）信息（此条信息包含加密后的智能卡端校验值），调用解密智能卡端TLS信息的方法，解密后能得到第一验证数据。为验证是否正确解密，此时需要额外验证完整的握手信息，其中分别为：上述实施例中提到的Client Hello、Server Hello、Server Hello Done、Client Key Exchange四条信息拼接，然后并通过封装好的目标加密方法（如PRF(伪随机数方法)、哈希算法方法组合）根据拼接信息计算出的第一整体校验值。这次验证是否成功, 要以服务器端是否能够正确解密该密文得到相同的智能卡端verify-data（第一整体校验值）作为判定标准。即相互验证，在第一验证数据与第一整体校验值一致的情况下，得到第一验证结果为验证通过。

在一些实施例中，服务器端在上述基础上调用加密第一整体校验值的方法进行加密看是否得到对应的正确密文（是否与解密智能卡端TLS信息时智能卡端产生的密文一致），在得到正确密文的情况下，确定第一验证结果为验证通过。

参考图3，图3为本申请一实施例提出的基于HTTPS的智能卡数据加解密测试方法的流程图，在一些实施例中，将第二整体校验值加密传输至智能卡端，以使智能卡端根据解密的第二验证数据得到第二验证结果，测试方法包括但不限于有以下步骤S310、步骤S320和步骤S330；

步骤S310，服务器端通过对明文状态的握手信息和第一整体校验值进行拼接处理，得到第二整体校验值，并将第二整体校验值加密传输至智能卡端；

步骤S320，智能卡端对接收到的加密的第二整体校验值进行解密处理，得到第二验证数据；

步骤S330，智能卡端在第二验证数据与第二整体校验值一致的情况下，得到第二验证结果为验证通过。

在一些实施例中，智能卡端接收Finished （server to client）信息（此条信息包含加密后的服务器端校验值），调用解密服务器端TLS信息的方法解密后能得到第二验证数据。为验证是否正确解密，此时需要额外验证完整的握手信息，其中分别为：上述实施例中提到的Client Hello、Server Hello、Server Hello Done、Client Key Exchange以及第一整体校验值五条信息拼接，并通过封装好的目标加密方法（如PRF(伪随机数方法)、哈希算法方法组合）根据拼接信息计算出的第一整体校验值; 这次验证是否成功, 要以智能卡端是否能够正确解密该密文得到相同的服务器端verify-data（第二整体校验值）作为判定标准。即相互验证，在第二验证数据与第二整体校验值一致的情况下，得到第二验证结果为验证通过，同时，在智能卡端和服务器端握手协商完成后，后续智能卡端和服务器端之间可以根据用户需求进行应用层面交互，并通过上述实施例中提到的协商密钥来加密传输。

在一些实施例中，智能卡端在上述基础上调用加密第二整体校验值的方法进行加密看是否得到对应的正确密文（是否与解密服务器端TLS信息时服务器端产生的密文一致），在得到正确密文的情况下，确定第二验证结果为验证通过。

在一些实施例中，智能卡端根据解密的第二验证数据得到第二验证结果之后，包括：在第一验证结果和第二验证结果均验证通过的情况下，确定智能卡端和服务器端之间的加密通信状态为握手协商成功,进而实现自动测试，提升测试效率和测试覆盖面。

参考图4，图4为本申请一实施例提出的基于HTTPS的智能卡数据加解密测试方法的流程图，在一些实施例中，确定智能卡端和服务器端之间的加密通信状态为握手协商成功之后，测试方法包括但不限于有以下步骤S410和步骤S420；

步骤S410，根据HTTPS内容打包方法对目标传输内容进行转码打包下发处理，以使目标传输内容在智能卡端和服务器端之间进行加密传输；

步骤S420，服务器端向智能卡端加密传输APDU应用协议数据单元，智能卡端在接收到APDU后向服务器加密传输响应数据。

在一些实施例中，数据加解密模块的打包下发方法包括，设计不同HTTPS CONTENT打包的方法，其中打包方式可选择原始数据或者经过不同方式比如数据扩展或压缩之类的处理后的数据；HTTPS请求头部分属性选择RAM（Remote Application Management远程应用管理）还是RFM（Remote File Management远程文件管理）方式；HTTPS请求头部分属性选择Transfer-Encoding还是Content-Length等各种不同方式。

在一些实施例中，在上述实施例中确定智能卡端和服务器端之间的加密通信状态为握手协商成功之后，测试模块进行传输应用数据，将想要传输的目标传输内容通过转码以及打包后加密传输（通过数据加解密模块的打包下发方法）；在成功加密下发的基础上，运用数据加解密模块设计好的算法进行相应的加解密，服务器发送APDU给智能卡端，智能卡端解密后响应数据，并加密响应数据返回给服务器端，从而进行HTTPS交互。

在一些实施例中，参考图5至图7，图5至图7均来自于标准规范文档，图5为服务器端和智能卡端之间进行HTTPS交互的示意图，图6为服务器端和智能卡端之间进行HTTPS交互的步骤流程图，图7为服务器端和智能卡端之间进行HTTPS交互的指令流向图，其中HTTPS交互的具体过程如下：

1）打开连接/会话，远程管理服务器(SCWS_RemoteAdminServer)以TCP客户端模式打开BIP通道建立连接（智能卡通过拿到客户端如IPV4等信息打包后通过Triggering事件打开通道，具体表现为OPEN CHANNEL这个主动式命令，ts_131111规范对这个命令进行描述）；

2）启动PSK-TLS会话，在这个通道上进行TLS握手，使用PSK-TLS来实现相互认证、机密性和完整性（即握手协商握手）；

3）超文本传送请求（第一个），在TLS通信通道建立后（握手协商成功之后），卡管理代理（SCWS_AdminiClient）会发送一个HTTP POST request命令给远程管理服务器；

4）超文本传送请求响应（管理命令），当从卡管理代理接收到POST Request时，远程管理服务器应该发送一个HTTP POST response响应，该响应封装了一个专用于SCWS本身的HTTP管理请求(admin request)命令；

5）当收到上述HTTP POST response命令的HTTP响应时，卡管理代理应将其转发给SCWS_Server；

6） SCWS_Server应认为该通道已由卡管理代理认证。如果卡管理代理被允许访问命令中涉及的URI，它将处理所传递的管理命令；

7）在处理完发送的管理命令后，SCWS_Server应将HTTP响应（admin response）返回给卡管理代理；

8）卡管理代理应通过TLS安全通道将来自SCWS_Server的HTTP响应作为新的请求（POST requset）提交给远程管理服务器；

9）远程管理服务器应该通过TLS安全通道向卡片管理代理发送下一个管理命令，或者在POST response中发送如“HTTP/1.1 204 No Content”的响应内容以此作为结束远程管理会话的最终响应；

10）如果卡管理代理收到来自远程管理服务器的最终响应，它应该关闭TLS通道，然后关闭BIP通道。具体表现为Close Channel（ts_131111规范描述）这个主动式命令。

通过上述具体步骤，本申请能有效的在服务器端和智能卡端之间进行HTTPS交互。

在一些实施例中，参考上述实施例中提到的HTTPS交互的具体过程，当智能卡端接收到没有包含内容的信息后，会询问服务器端是否有新的内容需要发送，此时服务器端信息将会在请求行部分包括结束标志，然后下发给智能卡端，具体的，远程管理服务器能通过TLS安全通道向卡片管理代理发送下一个管理命令，或者在POST response中发送如“HTTP/1.1 204 No Content”的响应内容以此作为结束远程管理会话的最终响应；同时，智能卡端会响应最后一条Close Channel指令结束整个流程，具体的，如果卡管理代理收到来自远程管理服务器的最终响应，它应该关闭TLS通道，然后关闭BIP通道，具体表现为CloseChannel（ts_131111规范描述）这个主动式命令，进而提高系统稳定性。

在一些实施例中，参考图8，图8为智能卡端和服务器端之间信息交互的示意图，交互的握手信息无需包括现有技术中的Server Key Exchange信息；交互的握手信息包括：Client Hello信息（客户端握手信息）、 Server Hello信息（服务器端握手信息）、ServerHello Done信息（服务器端握手完成信息）、 Client Key Exchange信息（客户端密钥交换信息）、Change Cipher Spec（client to server）信息（客户端到服务器端的更改密码规范信息）、Finished （client to server）信息（客户端到服务器端的完成信息）、ChangeCipher Spec（server to client）信息（服务器端到客户端的更改密码规范信息）和Finished （server to client）信息（服务器端到客户端的完成信息），上述握手信息能解决测试过程复杂，手动测试容易出错误且效率低的问题，实现自动测试，提升测试效率和测试覆盖面。

在一些实施例中，本申请一种基于HTTPS的智能卡数据加解密测试系统，测试系统包括测试模块，测试模块包括智能卡端和服务器端；

智能卡端用于向服务器端发送第一随机数和多个支持加密方法，向服务器端发送密钥交换数据，并将与服务器端的连接状态转从明文状态转换到加密状态，根据第一随机数、第二随机数、密钥交换数据和目标加密方法，将第一整体校验值加密传输至服务器端，以使服务器端根据解密的第一验证数据得到第一验证结果；

服务器端用于向智能卡端发送第二随机数，并发送从多个支持加密方法中确定的目标加密方法，将与智能卡端的连接状态转从明文状态转换到加密状态，服务器端根据第一随机数、第二随机数、密钥交换数据和目标加密方法，将第二整体校验值加密传输至智能卡端，以使智能卡端根据解密的第二验证数据得到第二验证结果。

参考图9,图9是本发明实施例提供的控制器的结构示意图。

本发明的一些实施例提供了一种控制器，控制器包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器执行计算机程序时实现上述任意一项实施例的基于HTTPS的智能卡数据加解密测试方法，例如，执行以上描述的图1中的方法步骤S110至步骤S150、图2中的方法步骤S210至步骤S230、图3中的方法步骤S310至步骤S330、图4中的方法步骤S410至步骤S420。

本发明实施例的控制器900包括一个或多个处理器910和存储器920，图9中以一个处理器910及一个存储器920为例。

处理器910和存储器920可以通过总线或者其他方式连接，图9中以通过总线连接为例。

存储器920作为一种非暂态计算机可读存储介质，可用于存储非暂态软件程序以及非暂态性计算机可执行程序。此外，存储器920可以包括高速随机存取存储器，还可以包括非暂态存储器，例如至少一个磁盘存储器件、闪存器件、或其他非暂态固态存储器件。

在一些实施方式中，存储器920可选包括相对于处理器910远程设置的存储器920，这些远程存储器可以通过网络连接至控制器900，同时，上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

在一些实施例中，处理器执行计算机程序时按照预设间隔时间执行上述任意一项实施例的基于HTTPS的智能卡数据加解密测试方法。

本领域技术人员可以理解，图9中示出的系统结构并不构成对控制器900的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

在图9所示的控制器900中，处理器910可以用于调用存储器920中储存的基于HTTPS的智能卡数据加解密测试方法，从而实现基于HTTPS的智能卡数据加解密测试方法。

基于上述控制器900的硬件结构，提出本发明的基于HTTPS的智能卡数据加解密测试系统的各个实施例，同时，实现上述实施例的基于HTTPS的智能卡数据加解密测试方法所需的非暂态软件程序以及指令存储在存储器中，当被处理器执行时，执行上述实施例的基于HTTPS的智能卡数据加解密测试方法。

此外，本发明实施例的还提供了一种基于HTTPS的智能卡数据加解密测试系统，该基于HTTPS的智能卡数据加解密测试系统包括由上述的控制器。

在一些实施例中，由于本发明实施例的基于HTTPS的智能卡数据加解密测试系统具有上述实施例的控制器，并且上述实施例的控制器能够执行上述实施例的基于HTTPS的智能卡数据加解密测试方法，因此，本发明实施例的基于HTTPS的智能卡数据加解密测试系统的具体实施方式和技术效果，可以参照上述任一实施例的基于HTTPS的智能卡数据加解密测试方法的具体实施方式和技术效果。

本发明实施例的还提供了一种计算机可读存储介质，该计算机可读存储介质存储有计算机可执行指令，计算机可执行指令用于执行上述的基于HTTPS的智能卡数据加解密测试方法，例如，可使得上述一个或多个处理器执行上述方法实施例中的基于HTTPS的智能卡数据加解密测试方法，例如，执行以上描述的图1中的方法步骤S110至步骤S150、图2中的方法步骤S210至步骤S230、图3中的方法步骤S310至步骤S330、图4中的方法步骤S410至步骤S420。

以上所描述的系统实施例仅仅是示意性的，其中作为分离部件说明的单元可以是或者也可以不是物理上分开的，即可以位于一个地方，或者也可以分布到多个网络节点上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。

本领域普通技术人员可以理解，上文中所公开方法中的全部或某些步骤、系统可以被实施为软件、固件、硬件及其适当的组合。某些物理组件或所有物理组件可以被实施为由处理器，如中央处理器、数字信号处理器或微处理器执行的软件，或者被实施为硬件，或者被实施为集成电路，如专用集成电路。这样的软件可以分布在计算机可读介质上，计算机可读介质可以包括计算机可读存储介质（或非暂时性介质）和通信介质（或暂时性介质）。如本领域普通技术人员公知的，术语计算机可读存储介质包括在用于存储信息（诸如计算机可读指令、数据结构、程序模块或其他数据）的任何方法或技术中实施的易失性和非易失性、可移除和不可移除介质。计算机可读存储介质包括但不限于RAM、ROM、EEPROM、闪存或其他存储器技术、CD-ROM、数字多功能盘（DVD）或其他光盘存储、磁盒、磁带、磁盘存储或其他磁存储系统、或者可以用于存储期望的信息并且可以被计算机访问的任何其他的介质。此外，本领域普通技术人员公知的是，通信介质通常包含计算机可读指令、数据结构、程序模块或者诸如载波或其他传输机制之类的调制数据信号中的其他数据，并且可包括任何信息递送介质。

以上是对本申请的较佳实施进行了具体说明，但本申请并不局限于上述实施方式，熟悉本领域的技术人员在不违背本申请精神的前提下还可作出种种等同变形或替换，这些等同的变形或替换均包含在本申请权利要求所限定的范围内。

Claims (8)

1.一种基于HTTPS的智能卡数据加解密测试方法，应用于基于HTTPS的智能卡数据加解密测试系统，其特征在于，所述测试系统包括测试模块，所述测试模块包括智能卡端和服务器端，所述测试方法包括：

所述智能卡端向所述服务器端发送第一随机数和多个支持加密方法；

所述服务器端向所述智能卡端发送第二随机数，并发送从多个所述支持加密方法中确定的目标加密方法；

所述智能卡端向所述服务器端发送密钥交换数据，并将与所述服务器端的连接状态从明文状态转换到加密状态；

所述智能卡端根据所述第一随机数、所述第二随机数、所述密钥交换数据和所述目标加密方法，将第一整体校验值加密传输至所述服务器端，以使所述服务器端根据解密的第一验证数据得到第一验证结果；

所述服务器端将与所述智能卡端的连接状态从明文状态转换到加密状态，所述服务器端根据所述第一随机数、所述第二随机数、所述密钥交换数据和所述目标加密方法，将第二整体校验值加密传输至所述智能卡端，以使所述智能卡端根据解密的第二验证数据得到第二验证结果；

其中，所述服务器端通过对明文状态的握手信息和所述第一整体校验值进行拼接处理，得到第二整体校验值，并将所述第二整体校验值加密传输至所述智能卡端；所述智能卡端对接收到的加密的所述第二整体校验值进行解密处理，得到第二验证数据；所述智能卡端在所述第二验证数据与所述第二整体校验值一致的情况下，得到第二验证结果为验证通过；

在所述第一验证结果和所述第二验证结果均为验证通过的情况下，确定所述智能卡端和所述服务器端之间的加密通信状态为握手协商成功。

2.根据权利要求1所述的基于HTTPS的智能卡数据加解密测试方法，其特征在于，所述测试系统还包括数据加解密模块，所述智能卡端向所述服务器端发送第一随机数和多个支持加密方法之前，还包括：

所述数据加解密模块设置生成多种密钥方法、第一整体校验值加密成智能卡端TLS信息方法、解密智能卡端TLS信息方法、第二整体校验值加密成服务器端TLS信息方法、解密服务器端TLS信息方法和HTTPS内容打包方法。

3.根据权利要求1所述的基于HTTPS的智能卡数据加解密测试方法，其特征在于，所述测试系统还包括读卡器模块，所述智能卡端向所述服务器端发送第一随机数和多个支持加密方法，包括：

在所述读卡器模块检测到所述智能卡端通过所述读卡器模块与所述服务器端连接的情况下，所述智能卡端向所述服务器端发送第一随机数和多个支持加密方法。

4.根据权利要求1所述的基于HTTPS的智能卡数据加解密测试方法，其特征在于，所述将第一整体校验值加密传输至所述服务器端，以使所述服务器端根据解密的第一验证数据得到第一验证结果，包括：

所述智能卡端通过对明文状态的握手信息进行拼接处理，得到第一整体校验值，并将所述第一整体校验值加密传输至所述服务器端；

所述服务器端对接收到的加密的所述第一整体校验值进行解密处理，得到第一验证数据；

所述服务器端在所述第一验证数据与所述第一整体校验值一致的情况下，得到第一验证结果为验证通过。

5.根据权利要求1所述的基于HTTPS的智能卡数据加解密测试方法，其特征在于，所述确定所述智能卡端和所述服务器端之间的加密通信状态为握手协商成功之后，还包括：

根据所述HTTPS内容打包方法对目标传输内容进行转码打包下发处理，以使所述目标传输内容在所述智能卡端和所述服务器端之间进行加密传输；

所述服务器端向所述智能卡端加密传输APDU应用协议数据单元，所述智能卡端在接收到APDU后向所述服务器端加密传输响应数据。

6.一种基于HTTPS的智能卡数据加解密测试系统，其特征在于，所述测试系统包括测试模块，所述测试模块包括智能卡端和服务器端；

所述智能卡端用于向所述服务器端发送第一随机数和多个支持加密方法，向所述服务器端发送密钥交换数据，并将与所述服务器端的连接状态从明文状态转换到加密状态，根据所述第一随机数、第二随机数、所述密钥交换数据和目标加密方法，将第一整体校验值加密传输至所述服务器端，以使所述服务器端根据解密的第一验证数据得到第一验证结果；

所述服务器端用于向所述智能卡端发送所述第二随机数，并发送从多个所述支持加密方法中确定的所述目标加密方法，将与所述智能卡端的连接状态从明文状态转换到加密状态，所述服务器端根据所述第一随机数、所述第二随机数、所述密钥交换数据和所述目标加密方法，将第二整体校验值加密传输至所述智能卡端，以使所述智能卡端根据解密的第二验证数据得到第二验证结果；

其中，所述服务器端用于通过对明文状态的握手信息和所述第一整体校验值进行拼接处理，得到第二整体校验值，并将所述第二整体校验值加密传输至所述智能卡端；所述智能卡端用于对接收到的加密的所述第二整体校验值进行解密处理，得到第二验证数据；所述智能卡端用于在所述第二验证数据与所述第二整体校验值一致的情况下，得到第二验证结果为验证通过，以在所述第一验证结果和所述第二验证结果均为验证通过的情况下，确定所述智能卡端和所述服务器端之间的加密通信状态为握手协商成功。

7.一种控制器，其特征在于，包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如权利要求1至5中任意一项所述的基于HTTPS的智能卡数据加解密测试方法。

8.一种计算机可读存储介质，存储有计算机可执行指令，计算机可执行指令用于执行如权利要求1至5中任意一项所述的基于HTTPS的智能卡数据加解密测试方法。

Images