用于金融终端设备的程序测试系统及装置

技术领域

本发明涉及程序测试技术领域，具体地，涉及一种用于金融终端设备的程序测试系统及装置。

背景技术

新开发的IZF200新型POS不带键盘功能，设备的测试不能直接在该POS上操作执行，为了高效测试该类POS设备，设计了一种新型的测试方法，在待测金融终端设备上运行测试程序，设备测试程序等待接收上位机测试工具的指令，并将测试结果反馈给上位机，上位机显示各功能项的测试结果。

专利文献CN103577313A(申请号：CN201210264014.5)公开了一种移动终端应用程序测试方法及装置，本发明移动终端应用程序测试方法包括：设置测试工具的参数；通过测试工具运行测试命令，向被测试程序发送随机事件；保存被测试程序的执行日志，获取保存的执行日志进行分析。

发明内容

针对现有技术中的缺陷，本发明的目的是提供一种用于金融终端设备的程序测试系统及装置。

根据本发明提供的用于金融终端设备的程序测试系统，包括：

测试模块：在待测金融终端设备上运行测试程序，并将测试结果反馈给上位机；

管理模块：对所有POS机应用进行管理和通讯，包括启动、终止和应用间通讯；

显示模块：将测试结果显示在上位机上；

更新模块：与PC端SMT软件配合实现软件下装与更新；

控制模块：负责输入和输出的安全控制，应用层只能通过该模块来获取输入事件，并输出相关信息。

优选的，还包括安全模块：初始化安全相关的硬件功能和执行存储区域内的代码检查，如果指定区域内的代码验证失败，则不启动外部存储器上的代码，根据这个原理验证外部Flash上u-boot程序的安全性，生成的u-boot的bin文件需要加上DCD信息及RSA签名信息并一同下载到flash中，DCD信息放置在u-boot文件之前指定的位置，从DCD信息中读取u-boot的bin文件存放的位置、签名信息及对应公钥证书。

优选的，为防止通过串口调试终端以命令的形式修改设备存储器的数据，在u-boot里面屏蔽掉该功能，u-boot里面不支持kernel或文件系统的更新，程序的更新只能通过设备管理程序更新。

优选的，u-boot、内核映像及文件系统在安全环境下烧录到设备的Nandflash中，u-boot启动内核时会将内核映像文件从Nandflash加载到RAM中，并对内核映像进行校验，若校验通过，则启动内核，否则启动失败；

用于验证内核的证书与u-boot文件一同打包，由安全模块验证，防止用于验证内核的证书被篡改。

优选的，设备中应用程序以app权限运行，仅管理程程序具有root权限，设备里运行的应用仅能访问自身目录下的数据，不能访问其他应用的数据。

优选的，设备的公钥证书采用PKI密钥树的形式，密钥长度采用2048位，将用于设备身份认证的公钥用Root key私钥签名，并与u-boot的代码一同通过烧录器烧录在flash中，设备启动时用Root key验证该公钥的有效性。

优选的，设备状态转换时，系统接收PC端与身份认证公钥匹配私钥签名后的授权数据，用身份认证公钥验证该签名数据的有效性，验证通过后即可进行所请求的状态转换；

设备在出厂投入使用前用该工具转换到安全态，确保设备使用的安全性。

根据本发明提供的一种金融终端装置，其特征在于，运用上述的用于金融终端设备的程序测试系统进行金融交易。

与现有技术相比，本发明具有如下的有益效果：

本发明通过待测金融终端在运行该待测试程序时的反馈，便能够实现对金融终端各项功能的测试，不需要人工去操作金融终端，节约了时间、精力和人力，并降低了开发周期和开发成本。

附图说明

通过阅读参照以下附图对非限制性实施例所作的详细描述，本发明的其它特征、目的和优点将会变得更明显：

图1为IZF200测试工具图；

图2为被测试设备程序处理流程图；

图3为HAB内部rsa密钥结构示意图；

图4为HAB启动流程图；

图5为u-boot启动kernel流程图；

图6为设备系统框架图；

图7为设备系统框架图；

图8为u-boot的空间分布图。

具体实施方式

下面结合具体实施例对本发明进行详细说明。以下实施例将有助于本领域的技术人员进一步理解本发明，但不以任何形式限制本发明。应当指出的是，对本领域的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干变化和改进。这些都属于本发明的保护范围。

实施例：

如图1所示，为上位机测试工具图，使用该测试工具时，PC仅需要串口与被测试设备进行通讯连接，测试开始前需配置好通讯用的串口，然后点击每个测试项目即可实现IZF200设备的各项功能测试。在测试过程中，被测试设备的应用程序始终处于命令接收→命令处理→返回处理结果→命令接收的循环中，如图2，上位机将要测试的每项测试功能的指令代码和测试参数发送给POS设备，POS设备校验接收到的指令，校验通过后方可执行该条指令。例如在执行非接卡测试指令时，被测设备将会执行读写非接卡的各种功能操作，保存各测试的执行结果，并将读写结果返回给上位机，上位机在界面上显示非接卡的读写测试数据和结果。在该测试过程中，测试人员仅操作PC端的功能界面即可清楚明了被测试设备内部数据的交互。

测试结果一类是自动判定，一类是人工判定，如声音测试，测试程序可判定声音功能模块驱动运行是否正常，但音效效果需要人工辅助判定是否符合测试要求，对于屏幕显示模块和二维码的测试也是同样的需要人工辅助判定测试结果。而对于非接卡、串口、TF卡、SAM卡等，被测试设备的测试程序和PC端的工具配合，PC端的工具上能够自动比对测试结果，用户只需要看最终的结果是pass还是fail，节省了人工和测试时间。

该测试方法还带有设备安全认证的功能，由于POS设备涉及金融交易，需要满足金融终端安全要求，正常使用时需要处于安全状态，在该状态下，设备处于最小权限模式，设备不能输出敏感信息，设备上的应用不能获取到敏感信息，未经授权的应用不能在设备上运行，并且设备不能开盖，否则设备上的密钥会自毁且设备不能再使用。但在生产或维修时或程序开发时，需要将设备转换到生产状态或者开发者模式，以解除硬件安全防护和方便软件下载和调试输出，切换状态时必须是经过授权的，否则设备会易受到攻击。

为了保障设备的状态的转换是经过安全认证授权的，需要设计一种安全认证授权机制，确保设备的固件运行的安全性。

设备固件包含：imx258内部安全固件HAB，secure u-boot，linux kernel，filesystem，prompts，libs以及具有root权限的管理进程，所有固件安全性符合PCI 5.x的要求。

如图4，为HAB启动流程图，HAB(HighAssurance Boot)是imx258内部的安全固件，能够执行安全的启动过程，包括初始化安全相关的硬件功能和执行一定存储区域内的代码检查，如果指定区域内的代码验证失败，HAB将不会启动芯片外部存储器上的代码。利用这一点，HAB可用于验证外部Flash上u-boot程序的安全性，生成的u-boot的bin文件需要加上DCD信息(配置信息)及RSA签名信息并一同下载到flash中，DCD信息放置在u-boot文件之前指定的位置，HAB可从DCD信息中读取u-boot的bin文件存放的位置，u-bootbin文件的签名信息及其对应公钥证书。HAB内部采用三级RSA的PKI结构如图3，分别是super root key，CSF key和APP key，图中的APP对应u-boot。设备内部采用逐级恢复的机制，这就要求CSF公钥证书要root key签名，APP的公钥证书需要CSF key签名。super root t key的公钥exponent和modulus的hash值需要烧到熔丝中以防止root key被替换。CSF key和APP key的证书在CSF文件中，super root key(SRK)相关的bin文件与csf文件会跟uboot一起烧到flash并在启动时拷贝到ram中，HAB将代码拷贝到ram中后会先安装super root key(通过比较熔丝位里面的super root key的hash值与super root key文件的密钥信息)，然后处理CSF文件信息，在处理CSF文件信息的过程中可恢复出CSF key和APPkey，验证CSF文件的签名和APP(u-boot)文件签名是否正确。HAB内部可用公钥证书及指定的完整性验证算法对签名信息进行验证，以确保u-boot的bin文件是经过授权的。如果上述验证失败，HAB内部将不会启动u-boot程序，设备不可运行。其中文件完整性算法采用SHA256的方式，RSA密钥长度为2048bits。

为防止通过串口调试终端以命令的形式修改设备存储器的数据，u-boot里面屏蔽掉该功能，u-boot里面不支持kernel或文件系统的更新，程序的更新只能通过设备管理程序更新。

如图5，为u-boot启动kernel流程图，u-boot、kernel Image及文件系统在厂内的安全环境下烧录到设备的Nandflash中，u-boot启动kernel时会将kernel image文件从Nandflash加载到RAM中，并对kernel Image进行校验，若校验通过，则启动kernel，否则启动失败。其中用于验证kernel的证书与u-boot文件一同打包，由内核HAB固件验证，防止用于验证kernel的证书被篡改。验证Kernel的证书及uboot文件以及CSF文件的存放位置以及相互关系可参考HAB启动阶段的工作。

IZF200设备linux系统包括linux kernel，linux drivers，File system，libs，daemons(守护进程)以及app(应用)。linux系统框架如图6所示。

Drivers即我们平时说的驱动程序，它们是一个个独立的“黑盒子”，是某个特定硬件响应一个定义良好的内部编程接口，这些接口完全隐藏了设备的工作细节。

驱动程序一般都是通过一组标准化的调用执行，并由驱动将这些调用映射到作用于实际硬件的设备特有操作上。

API(Application Programming Interface，应用程序编程接口)是一些预先定义的函数，目的是提供应用程序与开发人员基于某软件或硬件以访问一组例程的能力，而又无需访问源码，或理解内部工作机制的细节。

Kernel和Linux文件系统启动后，rc启动脚本会进行相关的驱动加载，启动应用进程。应用层主要有以下进程和守护进程：

Linuxpos负责所有POS机应用的管理和通讯，包括启动和终止，应用间通讯等。

LcdDaemon负责与显示相关功能的实现。

UpdateService负责和PC端SMT软件配合实现软件下装与更新。

pciDaemon负责输入和输出的安全控制，应用层只能通过它来获取输入事件，并输出相关信息。

这些root进程在/daemon目录下，除对此目录下的配置文件setting.ini,conf.ini有读写操作外，没有对任何其他文件有读写操作。

设备中应用程序以app权限运行，仅管理程程序具有root权限，如管理设备中运行的各应用的进程linuxpos，进行程序更新服务的进程UpdateService，进行驱动设备节点访问控制的进程pciDaemon，LcdDaemon虽然具有管理权限，但是仅用于传递显示信息，不操作、读写敏感设备。除上述具有管理权限的进程外，设备里运行的应用仅能访问自身目录下的数据，不能访问其他应用的数据，如密钥及交易记录信息等。

设备应用系统框架如图7所示。

SECURE LINUX系统设计

Secure linux实现方式是基于对权限的管理，设备中运行的应用以app权限运行，每个应用之间做到相互隔离，仅能访问属于自身的目录中的文件或数据，仅管理进程具有root权限，但管理进程不对其他文件进行读写操作。

文件系统权限设置，文件系统的权限控制是基于linux的用户权限控制的一种控制方式，它将各服务以及应用的权责划分清楚以后，各自不能访问其他应用以及系统组件的区域，以保证系统安全。

系统用户及分组：

用户(app_00001，app_00002...app_...*)会在其装载进设备时由updateservice创建。

文件系统树型结构及相关文件或文件夹的权限设置如下：

The tree offiles is as bellow:

设备的公钥证书采用PKI密钥树的形式，密钥长度采用2048位，将用于设备身份认证的公钥(如图8中用于验证kernel和文件的公钥)用Root key私钥签名，并与uboot的代码一同通过烧录器烧录在flash中，设备启动时会用Root key验证该公钥的有效性。用于设备状态转换时，进程UpdateService会接收PC端与身份认证公钥匹配私钥签名后的授权数据，用身份认证公钥验证该签名数据的有效性，验证通过后即可进行所请求的状态转换。设备在出厂投入使用前需要用该工具转换到安全态，确保设备使用的安全性。

综上，该测试方法即能提高测试效率，节省时间和人力，又能保证测试质量和设备安全，降低了开发生产周期和开发生产成本。

本领域技术人员知道，除了以纯计算机可读程序代码方式实现本发明提供的系统、装置及其各个模块以外，完全可以通过将方法步骤进行逻辑编程来使得本发明提供的系统、装置及其各个模块以逻辑门、开关、专用集成电路、可编程逻辑控制器以及嵌入式微控制器等的形式来实现相同程序。所以，本发明提供的系统、装置及其各个模块可以被认为是一种硬件部件，而对其内包括的用于实现各种程序的模块也可以视为硬件部件内的结构；也可以将用于实现各种功能的模块视为既可以是实现方法的软件程序又可以是硬件部件内的结构。

以上对本发明的具体实施例进行了描述。需要理解的是，本发明并不局限于上述特定实施方式，本领域技术人员可以在权利要求的范围内做出各种变化或修改，这并不影响本发明的实质内容。在不冲突的情况下，本申请的实施例和实施例中的特征可以任意相互组合。