第1卷-第2部分-移动终端支付应用软件安全规范解析

ICS Q/CUP 中国银联移动支付技术规范第1卷：基础规范第2部分 移动终端支付应用软件安全规范Mobile Payment SpecificationsVolume 1 Basic SpecificationsPart 2 Secure Specification of Payment Software in Mobile Terminal中国银联股份有限公司 发布目 次1 范围 . 12 规范性引用文件 . 13 支付应用软件的结构和定义 . 14 支付应用软件的安全要求 . 7前 言中国银联移动支付技术规范共分为四卷： 第1卷：基础规范 第2卷：智能卡支付技术规范 第3卷：移动互联网支付技术规范 第4卷：短信支付技术规范本部分为第1卷的第2部分。本部分包含了对移动终端支付应用软件安全功能方面的规定。本部分由中国银联股份有限公司提出。本部分起草单位： 中国银联股份有限公司、中国工商银行、中国农业银行、中国银行、中国建设银行、交通银行、邮政储蓄银行、招商银行、中信银行、中国光大银行、中国民生银行、兴业银行、浦东发展银行、深圳发展银行、广东发展银行、华夏银行、北京银行、上海银行、北京银联金卡科技有限公司、中国金融电子化公司、银联数据服务有限公司、上海柯斯软件有限公司、北京同方微电子有限公司、上海华虹集成电路有限责任公司、北京握奇数据系统有限公司、东信和平智能卡股份有限公司、金雅拓科技上海有限公司、北京华大智宝电子系统有限公司、成都中联信通科技有限公司、福建联迪商用设备有限公司、联通华建网络有限公司、上海翰鑫信息科技有限公司、亿达信息技术有限公司等。本部分主要起草人：柴洪峰、徐燕军、康建明、徐晋耀、单长胜、于晓滨、鲁志军、李伟、谭颖、李洁、吴水炯、齐宁、何朔、史大鹏、廖志江、周新衡、童益柱、李同勋、杨夏耘、申莉、曾诤、李竹、边罡、麦博奇、杨志勇、王超、钱菲、袁捷、郑元龙、李言平、唐邦富、陈明垓、卢文青、惠锦华、罗俊、梁万山、张晗、于卫国、李一凡、吴俊、罗雯、丁义民、王晓丹、邹重人、谢辉、张志茂、雷霆、陈波、张江涛、徐伟、郭伟、罗海云、李峰、李茁、陈跃、罗劲、赵亮、倪国荣、刘风军、肖波、嵇文俊、陈孜、诸中林。中国银联移动支付技术规范第1卷 基础规范第2部分 移动终端支付应用软件安全规范1 范围本部分适用于需要支持支付业务（包括处理订单）的移动终端支付应用软件，包括：手机客户端、支付控件、WAP 支付网站、智能卡程序等。对于仅支持商圈浏览等关联业务，不直接集成支付功能的应用软件，不属于本部分的规定范围。本部分适用于支付应用软件的设计、开发、集成、维护、运营单位，及为其提供支持或服务的相关单位（如为支付应用软件提供证书服务的安全认证机构）。2 规范性引用文件下列文件中的条款通过本标准的引用而成为本标准的条款。凡是注日期的引用文件，其随后所有的修改单（不包括勘误的内容）或修订版均不适用于本标准，然而，鼓励根据本标准达成协议的各方研究是否可使用这些文件的最新版本。凡是不注日期的引用文件，其最新版本适用于本标准。ETSI TS 131 102 Universal Mobile Telecommunications System (UMTS; Characteristics of the USIM application (3GPP TS 31.102 version 6.9.0 Release 6ETSI TS 102 223 Smart Cards; Card Application Toolkit (CAT (Release 7ETSI TS 101 181 Digital cellular telecommunications system (Phase 2+ Security mechanisms for SIM application toolkitISO/IEC 7816-4 Identification cards - Integrated circuit cards - Part 4：Organization, security and commands for interchangeGPCardSpec_v2.2: Global Platform3 支付应用软件的结构和定义3.1 概述基于移动终端的支付应用软件包括在移动终端上运行的客户端软件，以及在智能卡上运行的智能卡支付软件，两种软件在移动终端上可以共存。移动终端上的客户端支付软件可以独立使用，也可以结合智能卡一起使用，当结合智能卡一起使用时，应用所需的安全认证或加密/解密等功能由智能卡来完成。智能卡支付软件可以独立执行，交互展示界面在终端上实现。根据支付应用软件的运行环境不同区分为两类：基于移动终端操作系统的支付软件（以下简称客户端支付软件）和基于智能卡操作系统的支付软件（以下简称智能卡内嵌支付软件）。对于客户端支付软件，根据不同业务模式可以使用智能卡进行安全认证，也可以不使用智能卡进行安全认证，因此根据是否使用智能卡，可再划分为基于智能卡的客户端支付软件和无智能卡的客户端支付软件。图1是基于智能卡的客户端支付软件示意图。当支付应用存在SE 中时，客户端支付软件主要用于功能展示，提供人机界面和输入输出接口；当支付应用存在客户端软件中时，应用所需要的安全认证或签名的具体实现则由SE 提供支撑。图1 基于智能卡客户端支付软件示意图图2是无智能卡的客户端支付软件示意图。支付应用存在移动终端系统中，应用所需要的安全认证或签名的具体实现则由客户端软件提供支撑。 标识数据流向图2 无智能卡客户端支付软件示意图图3是智能卡内嵌支付软件示意图，智能卡本身作为SE 存在，所有的支付应用全部存在智能卡中，应用所要求的安全认证或签名也由智能卡支撑。 图3 基于智能卡内嵌支付软件示意图本章对上述三类支付应用软件的整体结构及各部分主要功能进行规定。 3.2 基于智能卡客户端支付软件架构移动终端支付应用软件运行在手机操作系统中，与智能卡进行交互、与后台系统建立通讯连接，整体架构如图4所示: 图4 整体架构 应用软件层应用软件层是最终用户直接使用的一层，其能够为用户提供各种形式的图形用户界面。应用层应支持客户端/服务器模式、浏览器/服务器模式的应用软件形式，并为最终用户提供移动支付/远程支付功能。 与应用相关的网络协议层与应用相关的网络协议层，主要根据应用层的调用，为上层提供与应用相关的网络服务。与应用相关的网络协议层可采用目前国际标准的网络服务协议如Web 、Wap 等，也可根据客户端软件的需求进行定制协议开发。 与应用无关的网络协议层与应用无关的网络协议层，主要为上层提供最基础的网络协议服务，包括各种安全通信协议SSL 、TLS 、WTLS 等，也可根据上层应用的需求提供定制性的专用网络协议。 安全协议层安全协议层是保障客户端提供移动支付安全的核心基础架构。其衔接应用层与设备层，将应用对安全的需求通过安全协议层进行实现。安全协议层接口的规范，应能够与符合PKCS15规范的安全设备进行无缝的对接，便于各安全软件及硬件的平滑接入。 硬件驱动层硬件驱动层负责对安全协议层屏蔽软硬件区别，并为其提供基础的设备访问及软硬件资源使用的功能。硬件驱动层中使用的安全硬件或软件，对于安全协议层应是透明不可见的。硬件驱动层还应满足设备资源稳定可靠的访问。 操作系统层操作系统层是客户端软件运行的基础平台。基于移动终端操作系统的客户端软件操作系统层，应支持主流的智能手机平台，包括Windows Phone 、iOS 、Symbian 、Android 等，在多种操作系统上接入安全硬件并向上层提供相关服务。 物理设备层物理设备层是安全移动支付的硬件基础服务层，为上层提供PKI 安全认证及加解密服务等多种功能。物理设备层设备的文件结构，应符合PKCS15规范，便于多种设备、多种应用的灵活接入。3.3 无智能卡客户端支付软件架构无智能卡的客户端软件支付主要包括WAP 支付和客户端软件支付。 3.3.1 基于移动终端浏览器的支付软件架构基于移动终端浏览器的支付方式是基于移动终端浏览器以网页方式实现支付功能，支付软件主体包括移动终端浏览器和服务端网站。移动终端浏览器运行在移动终端上并实现了相应网络协议，服务端网站是支付服务提供方开发并运营的提供支付业务的平台，整体架构如图5所示: 图5 整体架构 应用软件层应用软件层是最终用户直接使用的一层，其能够为用户提供各种形式的图形用户界面。应用层应支持浏览器/服务器模式的应用软件形式，并为最终用户提供移动支付/远程支付功能。 与应用相关的网络协议层与应用相关的网络协议层，主要根据应用层的调用，为上层提供与应用相关的网络服务。与应用相关的网络协议层可采用目前国际标准的网络服务协议如WAP 等，也可根据客户端软件的需求进行定制协议开发。 与应用无关的网络协议层 与应用无关的网络协议层，主要为上层提供最基础的网络协议服务，包括各种安全通信协议WTLS 、SSL 等，也可根据上层应用的需求提供定制性的专用网络协议。 操作系统层操作系统层是客户端软件运行的基础平台。基于移动终端操作系统的客户端软件操作系统层，应支持主流的智能手机平台，包括Windows Phone 、iOS 、Symbian 、Android 等，在多种操作系统上接入安全硬件并向上层提供相关服务。 3.3.2 客户端支付软件架构客户端支付软件运行在手机操作系统中，与移动支付接入平台系统建立通讯连接，整体架构如图6所示:图6 整体架构 应用软件层应用软件层是最终用户直接使用的一层，其能够为用户提供各种形式的图形用户界面。应用层应支持客户端/服务器模式、浏览器/服务器模式的应用软件形式，并为最终用户提供远程支付功能。 安全协议层安全协议层是保障客户端提供移动支付安全的核心基础架构，将应用对安全的需求通过安全协议层进行实现。 与应用相关的网络协议层与应用相关的网络协议层，主要根据应用层的调用，为上层提供与应用相关的网络服务。与应用相关的网络协议层可采用目前国际标准的网络服务协议如Web 等，也可根据客户端软件的需求进行定制协议开发。 与应用无关的网络协议层与应用无关的网络协议层，主要为上层提供最基础的网络协议服务，包括各种安全通信协议SSL 、TLS 、WTLS 等，也可根据上层应用的需求提供定制性的专用网络协议。 操作系统层操作系统层是客户端软件运行的基础平台。基于移动终端操作系统的客户端软件操作系统层，应支持主流的智能手机平台，包括Windows Phone 、iOS 、Symbian 、Android 等，在多种操作系统上接入安全硬件并向上层提供相关服务。 3.4 基于智能卡内嵌支付软件架构移动终端支付应用软件运行在智能卡操作系统中，通过移动终端操作系统对智能卡发送支持标准APDU 指令完成应用流程的交互。整体架构如图7所示：图7 整体架构 应用界面层应用界面层是与用户直接交互的功能层，基于客户端软件为用户以菜单的模式提供移动支付应用。根据用户需求，应用层可以支持OTA （Over the Air Technology ）技术实现应用软件空中下载及升级服务。 传输协议层传输协议层负责将应用界面层的菜单命名，转化成符合安全硬件通讯规范的数据命令，并打包传输给负责解析的卡片操作系统层。 卡片操作系统层卡片操作系统层是基于菜单模式客户端软件安全服务的核心软件架构，负责解析所有应用指令并进行处理，提供基础的安全服务。 安全硬件层安全硬件层是基于客户端软件安全服务的硬件基础，为上层应用提供基础的认证及加解密硬件资源。 智能卡设备层智能卡层，处于安全硬件下层，负责处理除安全应用之外的所有电信链路数据。 4 支付应用软件的安全要求 4.1 概述不同类型的支付应用软件载体不同，使用环境不同，对软件的安全要求也有不同，在整个软件的生命周期过程中需要确保各个环节的安全，对面临的各类威胁能采取相应的安全措施。4.2 基于智能卡客户端支付软件的安全要求客户端支付软件从开发、安装到运行以及失效过程中，整个生命周期涉及到各种各样的参与方，在复杂的情况下，需要确保不同的实体、实体与实体间的利益不受影响，安全不受威胁。 4.2.1 开发并维护安全的支付软件 确保所有的应用组件都安装了最新的安全补丁，相关补丁应在发布后的一个月之内被安装。 在业界最佳实践的基础上开发软件应用，并将信息安全与整个软件开发生命周期相结合。 对所有软件配置的修改，都必须按照变更控制过程进行。 对于所有的Web 应用开发需要基于安全编码指南，例如开放Web 应用安全项目（OWASP ）指南。复审订制的应用代码以识别编码漏洞, 软件开发流程中通常会出现的编码漏洞包括： 无效输入 失效访问控制（例如，用户ID 的恶意使用） 失效的身份认证和会话管理（对于账户凭据和会话Cookie 的使用） 跨站脚本攻击（XSS 或CSS ） 不安全存储拒绝服务攻击（DoS ） 不安全的配置管理适当的补丁指那些已经通过充分的评估和测试、被确定不会与现有的安全配置相冲突的补丁。对于内部开发的应用，采用标准的开发流程和安全编码技术可以减少大量的漏洞。 4.2.2 客户端支付软件的安装 确保安装最新版本的客户端支付软件，并在安装包完整、安全的前提下进行。 空中方式下载安装或更新客户端支付软件时需要采用安全报文，保证软件传输过程的机密性、完整性。4.2.3 后台系统的安全要求客户端支付软件应该采用技术手段与后台系统进行相互认证，确保后台系统的合法性。4.2.4 客户端支付软件的用户安全要求为每一个具有访问权限的用户分配唯一的ID ，以保证对于关键数据和支付软件的操作能够被追溯到已知的、被授权的用户。 使用唯一的用户名来鉴别用户，此后才允许他们访问应用组件或敏感数据； 除了分配唯一的ID ，至少采样下列方式的一种方法以鉴别所有合法用户： 口令 令牌设备 生物特征 针对高风险业务，采用双因子身份认证机制； 加密所有密码，无论是在传输过程中或存储在任何应用组件中； 采用适当的密码管理策略： 在执行口令重置前认证用户身份； 口令最小长度不低于六个字符； 如果一个会话空闲的时间超过一定时长，要求用户再次输入口令以重新激活终端应用； 采用一种或几种有效的方法防止密码的暴力猜解，合适的方法可以包括但不限于：设置密码验证次数的限制，指对登录失败次数设置合理上限，超限可以采取账号锁定等措施；提升密码复杂度，例如在设置密码过程中要求用户将密码设置为包含两类以上不同字符等。4.2.5 客户终端支付软件的数据安全要求4.2.5.1 数据录入输入认证/支付密码等敏感信息时，需采取技术措施防止密码盗取，并不得在移动终端界面上显示明文。4.2.5.2 数据访问根据业务需要限制对智能卡中敏感数据的访问。此项要求是为了保证敏感数据仅供授权用户或应用组件访问。4.2.5.3 数据存储 支付软件应保留最少的用户敏感数据，限制数据存储量和保留时间，达到恰好能满足业务、法律和管理规定需要的程度。 禁止在身份认证结束后存储敏感认证数据，如银行卡磁道信息、卡号、密码、CVN2等（即使经过加密）。 提交账户信息时，通过采用下列之一或多种方法，使PAN 不可读： 强壮的单向散列函数（散列索引） 截断（删除或省略字符串的头部或尾部） 密码本（密码本必须被安全保存） 强壮的加密机制，并结合相应的密钥管理流程和管理程序 显示PAN 时应参照银联卡POS 屏蔽相关管理规定，除对前6位和后4位予以显示外，其余所有卡号字段均予以屏蔽。4.2.5.4 数据传输在易被攻击者截获、篡改和重定向的网络上传输敏感信息时必须加密。使用强壮的加密算法和安全协议，例如安全套接字层（SSL ）/传输层安全（TLS ）和IP 安全协议（IPSEC ）来保护敏感数据在开放/公共的网络上的传输。开放/公共网络的例子包括Internet 、WiFi 、全球移动通信系统（GSM ）和通用分组无线业务（GPRS ）等。通过无线网络传输支付卡信息时，使用IPSEC VPN 或SSL/TLS进行传输加密。不要仅仅依赖WEP 保护无线网络的机密性和访问权限。客户端支付软件和本地其他实体间的数据传输需要采用数字签名和加密等安全方式，确保数据不被监听和篡改。4.2.6 客户端支付软件和智能卡的交互安全客户端支付软件和智能卡应采用技术手段进行双向认证, 确保客户端支付软件和智能卡的合法性。 客户端支付软件应确保与智能卡交互的安全性，防止对读取的智能卡数据的非授权访问。4.3 无智能卡客户端支付软件的安全要求4.3.1 WAP 支付软件的安全要求4.3.1.1 开发并维护安全的支付软件移动终端浏览器一般已安装在移动终端系统，无需支付服务方重新开发提供。支付服务方需要开发并维护服务端网站，服务端网站的开发应基于相关安全编码指南，避免通常会出现的编码漏洞，包括但不限于： 无效输入 失效访问控制（例如，用户ID 的恶意使用） 失效的身份认证和会话管理（对于账户凭据的使用） 跨站脚本攻击（XSS 或CSS ） 拒绝服务攻击（DoS ）4.3.1.2 后台系统的安全认证基于移动终端浏览器的支付软件应该采用技术手段与后台系统进行相互认证，确保后台系统的合法性。4.3.1.3 用户安全要求为每一个具有访问权限的用户分配唯一的ID ，以保证对于关键数据和支付软件的操作能够被追溯到已知的、被授权的用户。 使用唯一的用户名来鉴别用户，此后才允许他们访问应用组件或敏感数据； 除了分配唯一的ID ，至少采用下列方式的其中一种方法以鉴别所有合法用户： 口令 令牌设备 生物特征 针对高风险业务，采用双因子身份认证机制； 采用适当的密码管理策略： 在执行口令重置前认证用户身份； 口令最小长度不低于六位； 如果一个会话空闲的时间超过一定时长，要求用户再次输入口令； 采用一种或几种有效的方法防止密码的暴力猜解，合适的方法可以包括但不限于：设置密码验证次数的限制，指对登录失败次数设置合理上限，超限可以采取账号锁定等措施；提升密码复杂度，例如在设置密码过程中要求用户将密码设置为包含两类以上不同字符等。4.3.1.4 数据安全4.3.1.5.1明文。4.3.1.5.2问。4.3.1.5.3 数据存储 数据访问 数据录入 输入认证/支付密码等敏感信息时，需采取技术措施防止密码盗取，并不得在移动终端界面上显示根据业务需要限制对敏感数据的访问。此项要求是为了保证敏感数据仅供授权用户或应用组件访支付软件应保留最少的用户敏感数据，限制数据存储量和保留时间，达到恰好能满足业务、法律和管理规定需要的程度。4.3.1.5.4 数据传输在易被攻击者截获、篡改和重定向的网络上传输敏感信息时必须加密。使用安全协议，例如WTLS 协议来保护敏感数据在开放/公共的网络上的传输。开放/公共网络的例子包括Internet 、WiFi 、全球移动通信系统（GSM ）和通用分组无线业务（GPRS ）等。4.3.2 客户端支付软件的安全要求无智能卡客户端支付软件主要包括开发包和独立应用两种形式，其中开发包形式主要指以开发包软件的形式提供给商户或其他内容提供方并内嵌到其自有的客户端软件中，用户在这种类型的商户客户端中可以直接进行支付；独立应用形式主要指需要用户预先在终端中安装该客户端应用，在支付时激活该客户端应用进行支付。4.3.2.1 开发并维护安全的支付软件 在业界最佳实践的基础上开发软件应用，并将信息安全与整个软件开发生命周期相结合。 对所有软件配置的修改，都必须按照变更控制过程进行。 对于所有的Web 应用开发需要基于安全编码指南。例如开放Web 应用安全项目（OWASP ）指南。复审订制的应用代码以识别编码漏洞。软件开发流程中通常会出现的编码漏洞包括： 无效输入 失效访问控制（例如，用户ID 的恶意使用） 失效的身份认证和会话管理（对于账户凭据和会话Cookie 的使用） 跨站脚本攻击（XSS 或CSS ） 不安全存储 拒绝服务攻击（DoS ） 不安全的配置管理适当的补丁指那些已经通过充分的评估和测试、被确定不会与现有的安全配置相冲突的补丁。对于内部开发的应用，采用标准的开发流程和安全编码技术可以减少大量的漏洞。4.3.2.2 客户端软件的安装无智能卡客户支付软件的安装可以由移动设备自带，也可以由用户自行下载安装。4.3.2.3 客户端支付软件的分发 确保安装最新版本的客户端支付软件，并在安装包完整、安全的前提下进行。 空中方式下载安装或更新客户端支付软件时需要采用安全报文，保证软件传输过程的机密性、完整性。4.3.2.4 软件合法性验证和风险管理采取有效手段统一管理客户端软件及支付插件，在交易过程中对软件进行验证，保证支付软件调用的合法性。同时，对风险较高的交易，通过技术手段进行管理。验证和管理手段手段包括但不限于以下手段：为每个客户端软件设置一个合法的唯一编号，由其所属的后台系统统一分配，并设定其有效期。后台系统对发起交易的客户端软件进行合法性验证。对监控到有风险的交易或商户，后台系统应该对插件进行有效的风险控制，对有非法交易的支付插件应该通过设置禁止其交易。交易和商户的风险评估由业务风险规则另行规定。4.3.2.5 后台系统的安全要求客户端支付软件应该采用技术手段与后台系统进行相互认证，确保后台系统的合法性。4.3.2.6 客户端支付软件的用户安全要求为每一个具有访问权限的用户分配唯一的ID ，以保证对于关键数据和支付软件的操作能够被追溯到已知的、被授权的用户。 使用唯一的用户名来鉴别用户，此后才允许他们访问应用组件或敏感数据； 除了分配唯一的ID ，至少采用下列方式的一种方法以鉴别所有合法用户（相关业务规则规定的低风险场景除外，可不要求每笔交易都采用用户端强鉴别措施）： 口令 令牌设备 生物特征 针对高风险业务，采用双因子身份认证机制，包括但不限于短信验证码等方式，如采用验证码方式，需要对验证码有效时间进行设置，以保证验证码的安全认证效果； 加密所有密码，无论是在传输过程中或存储在任何应用组件中； 采用适当的密码管理策略： 在执行口令重置前认证用户身份； 口令最小长度不低于六个字符； 采用一种或几种有效的方法防止密码的暴力猜解，合适的方法可以包括但不限于：设置密码验证次数的限制，指对登录失败次数设置合理上限，超限可以采取账号锁定等措施；提升密码复杂度，例如在设置密码过程中要求用户将密码设置为包含两类以上不同字符等。 如果一个会话空闲的时间超过一定时长，要求用户再次输入口令以重新激活终端应用。4.3.2.7 客户端支付软件的数据安全要求4.3.2.7.1 数据录入输入认证/支付密码等敏感信息时，需采取技术措施防止密码盗取，技术手段可包括但不限于以下方式：用户所输入的客户端登陆密码、银行卡密码等敏感信息不得在移动终端界面上显示明文； 密码等敏感信息采用软键盘方式输入；敏感信息输入后需要立即采用健壮的算法加密；利用图形校验码等方式防止暴力攻击；对于反复尝试并输入错误密码超过一定次数的，进行软件登录和支付交易控制，必要时可根据业务规则予以交易阻断。4.3.2.7.2问。4.3.2.7.3 数据存储 数据访问 根据业务需要限制对敏感数据的访问。此项要求是为了保证敏感数据仅供授权用户或应用组件访 支付软件应保留最少的用户敏感数据，限制数据存储量和保留时间，达到恰好能满足业务、法律和管理规定需要的程度。 禁止在身份认证结束后存储支付密码等敏感数据，如银行卡磁道信息、卡号、密码、CVN2等（即使经过加密）。 提交账户信息时，通过采用下列任一途径，使PAN 不可读： 强壮的单向散列函数（散列索引） 截断（删除或省略字符串的头部或尾部） 密码本（密码本必须被安全保存） 强壮的加密机制，并结合相应的密钥管理流程和管理程序 显示PAN 时采用隐蔽措施（最多只显示最前6位和最后4位数字）。4.3.2.7.4 数据传输在易被攻击者截获、篡改和重定向的网络上传输敏感信息时必须加密。使用强壮的加密算法和安全协议，例如安全套接字层（SSL ）/传输层安全（TLS ）和IP 安全协议（IPSEC ）来保护敏感数据在开放/公共的网络上的传输。开放/公共网络的例子包括Internet 、WiFi 、全球移动通信系统（GSM ）和通用分组无线业务（GPRS ）。通过无线网络传输支付卡信息时，使用WiFi 保护访问（WPA 或WPA2）技术，IPSEC VPN 或SSL/TLS进行传输加密。不要仅仅依赖WEP 保护无线网络的机密性和访问权限。客户端支付软件和本地其他实体间的数据传输需要采用安全的方式，确保数据不被监听和篡改。Q/CUP 037.1.22011 4.4 基于智能卡内嵌支付软件安全要求 基于智能卡的支付软件从开发、安装到运行过程中，有各种各样的主体或实体参与到其中，因此基 于智能卡的支付软件的安全不仅局限于软件本身， 还涉及到支付软件的环境安全。 支付软件的安全是为 了将商业风险控制在可接受的范围内，维护各个实体的合法利益。 4.4.1 智能卡支付软件的开发 智能卡支