NFC-HCE近场支付解决方案 基于HCE的近场支付新业务模式.

Presentation on theme: "NFC-HCE近场支付解决方案 基于HCE的近场支付新业务模式."— Presentation transcript:

1 NFC-HCE近场支付解决方案 基于HCE的近场支付新业务模式

2 目录 1 什么是HCE？ 2 HCE业务模式 3 HCE云端支付技术方案 4 HCE前端支付技术方案

3 HCE HCE( Host-based Card Emulation)是Google在刚刚发布的Android 4.4 KitKat中新增的一种系统服务API。 HCE使得NFC手机可以在没有硬件SE的情况下采用卡模拟模式进行NFC支付。任意APP都可以模拟一张SE直接和Reader进行通信。 APP APP B：HCE架构：由NFC主控芯片收集的数据，直接经CPU传送到APP A:传统的NFC SE 架构

4 HCE 迅速受到业界广泛欢迎 Visa has introduced a new standard that uses host card emulation (HCE) to enable financial institutions to securely host Visa accounts in the cloud.  The HCE-based NFC payments solution to be deployed by Spain's Bankinter this year has been demonstrated by the bank's Alberto Perez Lafuente and technology provider Seglan's Imanol Garcia in a video interview filmed by Visa Europe at MWC 2014. Ukraine's PrivatBank is to launch a cloud-based NFC payments service using host card emulation (HCE). Transaction technology provider Carta Worldwide has added support for host card emulation (HCE) to its mobile payments platform — and is currently "supporting market trials in Europe and North America" that are expected to lead to large scale HCE deployments in late 2014. NXP has updated its PN547 NFC controller‘s firmware and middleware to provide enhanced support for host card emulation (HCE) transactions.

5 HCE和全终端eSE方案的区别 NFC全终端手机将NFC芯片和SE都集成于手机中，手机客户端通过基带处理器与安全芯片SE进行交互，可以通过客户端方式对SE进行应用加载个人化等操作。 全终端方案仍需在手机中内置硬件SE安全芯片。这是和HCE最大的区别。

6 HCE支持的协议和访问机制 支持APDU协议；可兼容现有的借贷记、电子现金、电子钱包卡 每个APP有唯一的AID
根据AID路由到指定APP进行数据处理

7 HCE的安全机制 后台 APP和后台安全：由APP和后台自定义安全协议 密钥安全：由APP自定义密钥安全 APP
APP安全：Android沙箱（SandBox）确保APP运行和数据安全。 通道安全：Android系统确保APP和NFC之间的APDU传输安全；确保APP和NFC之间数据传输的唯一性。

8 HCE两种认证模式 A：前端模式 B：云端模式 优点：快速交易 优点：密钥更安全 缺点：密钥可能被泄漏 缺点：需要实时联网
后台 密钥 APP 密钥 APP A：前端模式 优点：快速交易 缺点：密钥可能被泄漏 适用于：小额快速脱机交易 B：云端模式 优点：密钥更安全 缺点：需要实时联网 适用于：大额联机交易

9 两种认证模式的比较 前端模式 云端模式 卡数据存储位置 存储在前端； 密钥保存在软件APP中 存储在后台 交易速度 较快
稍慢；依赖于网络速度 适用场景 小额快速脱机交易 大额联机交易 建议适用的业务类型 电子钱包； 电子现金； 有限额的预付费卡； 定额卡； 会员ID卡； 门禁、考勤等 借/贷记卡； 额度较大的预付费卡 安全体系需求 需要设计具有较高强度的数据安全存储机制，确保卡数据存储和调用安全 需要设计较为完整的APP认证机制，确保对APP进行认证和鉴权后才能调用后台卡数据

10 目录 1 什么是HCE？ 2 HCE业务模式 3 HCE云端支付技术方案 4 HCE前端支付技术方案

11 HCE是线上线下业务的连接点 HCE使得商业银行可以发行“软卡”，摆脱对实体硬件的依赖。这能够将原有的线下卡业务整合到线上，建立起实时可达的卡用户交互通道，形成革命性的变革。 结合大数据精准分析，将能够进一步打造智能会员分析体系。 线上发卡：APP业务入口 空中发卡 在线充值：形成以银行卡账户为核心的消费模式。 数据分析、消费引导 online 线下刷卡：形成O2O消费闭环 银联POS、自有POS、合作POS…… 手机当POS用，直接刷银行卡消费 offline

12 HCE云端支付业务模型 云端支付平台 APP APP 交易验证 卡1数据托管 卡2数据托管 交易验证 AID1 AID2 NFC手机终端
空中发卡 卡片验证/交易处理 发卡行系统 POS密钥 交易请求 交易请求 收单行/ 清结算网络

13 HCE前端脱机支付业务模型 云端支付平台 APP 用户认证 卡数据 空中发卡 NFC手机终端 空中发卡 脱机卡片验证/脱机交易处理
发卡行系统 POS密钥 日结/批上送 清结算 收单行/ 清结算网络

14 目录 1 什么是HCE？ 2 HCE业务模式 3 HCE云端支付技术方案 4 HCE前端支付技术方案

15 HCE云端支付系统框架 云端支付平台 银行TSM-A 运营商SE-TSM 银行金融IC卡系统 卡密钥托管 空中发卡 密钥运算 空中充值
密钥系统 密钥运算 空中充值 个人化系统 数据准备系统 APP认证鉴权 SE-TSM对接 银行HCE-APP 银行 手机钱包 APP 运营商 手机钱包 APP

16 空中发卡流程 发卡前，用户需安装APP应用程序，并注册登录。 在登录之后，用户在APP上点击申请新卡片。此时，APP将启动空中发卡流程。
1、发卡请求 云端支付平台 卡数据托管 4、返回结果 APP AID1 NFC手机终端 2、发卡请求 3、下发卡数据 发卡行系统 发卡前，用户需安装APP应用程序，并注册登录。 在登录之后，用户在APP上点击申请新卡片。此时，APP将启动空中发卡流程。 由云端支付平台生成卡数据，并托管在后台。 3、用户身份验证

17 云端支付交易流程 云端支付平台 APP 2、APDU验证请求 卡数据托管 4、返回结果 AID1 3、APP认证鉴权/ APDU处理
NFC手机终端 1、应用选择/初始化/SDA 5、返回结果 发卡行系统 POS密钥 6、联机处理 6、联机处理 收单行/ 清结算网络

18 HCE-APP应用认证机制 采用数字证书、用户PIN码、终端验证的三重验证机制。
云端支付平台 应用认证/PIN验证/终端验证 空中安全信道（SSL） APP认证鉴权 APP APP私钥 数字证书签发/验证 NFC手机终端 发卡行CA 采用数字证书、用户PIN码、终端验证的三重验证机制。 在登录之后，用户在APP上点击申请新卡片。此时，APP将启动空中发卡流程。

19 HCE-APP安全威胁与防守方案 HCE-APP 后台攻击 应用仿冒 重放攻击 伪装应用 用户仿冒 非授权的远程接口调用 截屏 恶意分发
恶意复制 后台攻击 重放攻击 非授权的远程接口调用 用户仿冒 截屏 多机重复登录 破解 反编译，重新打包； 攻击方法 HCE-APP 云端支付平台 攻击目标 强认证 用户身份证书绑定 数字签名证书认证 用户密钥保护 应用、终端、用户唯一性绑定 抗仿冒 代码签名应用认证； 数字证书 抵御后台攻击 SID防重放攻击 ； 远程接口调用者应用身份认证； 防破解 代码签名验证 混淆 NDK 防守方案

20 目录 1 什么是HCE？ 2 HCE业务模式 3 HCE云端支付技术方案 4 HCE前端支付技术方案

21 HCE前端脱机支付安全需求 核心安全需求 密钥数据安全保护 密钥数据访问控制
采用数字证书技术来解决卡密钥数据存在的安全威胁，是目前最好的解决方案和途径。 但是由于在手机上不能像在PC上采用U盾来存储私钥和进行签名运算，存在以下关键技术问题需要解决： 核心安全需求 如何保证用户私钥在普通手机上的安全存储和使用，保证私钥在使用时不能被跟踪？ 密钥数据安全保护 如何保证调用用户私钥的APP是经过认证的，是没有被篡改的，抗击非法调用？ 密钥数据访问控制 对用户在移动终端上的密钥数据进行安全保护，密钥不能被导出、窃听，确保用户私钥安全。 对用户私钥建立起访问控制机制，确保手机客户端经过认证和授权之后才能访问私钥，防止非法应用对私钥的非法访问。 21

22 HCE前端支付密钥安全机制 用户私钥（SM2）： DEK（3DES）： 卡密钥（依应用而定）： APP 以非对称密码算法的私钥作为信任基点。
采用多因子分散的方法进行私钥组装运算。不需要存储私钥。 DEK（3DES）： 采用对称密钥DEK作为工作密钥。 DEK由用户公钥加密，私钥解密。DEK加密后存储在手机端。 卡密钥（依应用而定）： 卡密钥由DEK进行加密，加密后存储在手机端。 卡密钥组 消费密钥 MAC密钥 …… 1、加密 2、解密 数据加密密钥DEK 2、解密 1、加密 用户公钥PubKey 用户私钥PrivKey IMEI 随机数 用户PIN

23 用户私钥保护机制 密钥算法：采用基于ECC的国产非对称密码算法SM2。SM2的私钥可以在创建时指定。
IMEI 用户PIN 随机数 …… 用户私钥PrivKey 密钥算法：采用基于ECC的国产非对称密码算法SM2。SM2的私钥可以在创建时指定。 密钥分散：由多个互不相关的因子组装形成私钥。 设备信息：采用手机唯一的IMEI作为设备信息参与运算。运算时从系统接口中读取，不需要存储。 用户信息：采用用户设置的PIN码作为用户信息。运算时由用户输入，不需要存储。 随机因子：采用软件随机数作为随机因子。在生成密钥时创建，保存在手机中。 密钥因子相关性：密钥因子之间无相关性。最大程度提升保密强度。 密钥分段运算：各段因子在进行运算时分别运算，不需要组装成完整私钥再运算。这是SM2算法的特性。 密钥存储与运行数据安全：因为是分段运算，因此手机上永远不会存储完整私钥，在运算过程中内存数据中也不会出现私钥临时数据。可以抵抗内存分析攻击。

24 空中发卡过程

25 刷卡交易过程

26 方案总结 方案要点： 基于HCE技术，以软件APP代替普通IC卡，实现空中发卡的新业务模式。
支持云端支付和前端支付两种模式。分别适用于不同的业务场景。 卡数据托管在云端，最大程度确保数据安全可靠。 设计完整的安全信任体系，确保APP、云端、数据、通道的端到端安全机制，确保核心数据安全。 兼容现有卡支付体系，平滑过渡升级。

27 谢 谢！ Q & A 27