《一种移动支付单元支付系统和安全支付方法.pdf》由会员分享,可在线阅读,更多相关《一种移动支付单元支付系统和安全支付方法.pdf(10页完整版)》请在专利查询网上搜索。
1、(10)申请公布号 CN 104143142 A (43)申请公布日 2014.11.12 CN 104143142 A (21)申请号 201410341832.X (22)申请日 2014.07.17 G06Q 20/40(2012.01) G06Q 20/32(2012.01) (71)申请人 马洁韵 地址 518000 广东省深圳市龙岗区爱联永昌 隆工业区创业一路 9 号 申请人 唐毅 (72)发明人 马洁韵 唐毅 (74)专利代理机构 深圳市兴科达知识产权代理 有限公司 44260 代理人 王翀 (54) 发明名称 一种移动支付单元支付系统和安全支付方法 (57) 摘要 本发明公开一。
2、种移动支付单元支付系统和安 全支付方法, 安装于移动智能通讯终端的应用程 序 APP, 设置于移动智能通讯终端的移动支付单 元, 接受或者拒绝支付请求的支付服务器, 移动支 付单元包含移动身份识别模块和加密模块, 移动 支付单元、 APP、 支付服务器分别对发出或接收的 移动支付请求的相关信息进行加密和解密, 所述 的支付服务器鉴别移动支付单元及 APP 的身份合 法性, 并对支付请求发出接收或者拒绝的命令。 可 以满足人们随时随地安全的移动支付的需求, 其 安全性可以超过 UKEY 电脑支付的安全性, 使人们 不必带着电脑就可以随时随地安全移动支付。 (51)Int.Cl. 权利要求书 2 。
3、页 说明书 5 页 附图 2 页 (19)中华人民共和国国家知识产权局 (12)发明专利申请 权利要求书2页 说明书5页 附图2页 (10)申请公布号 CN 104143142 A CN 104143142 A 1/2 页 2 1. 一种移动支付单元, 其特征在于 : 包含移动身份识别模块和加密模块, 所述的加密 模块包括 OTA 加密单元和至少一组的基于 PKI 的加密单元 ; 所述的移动身份识别模块登陆 GSM 网络确定移动支付用户的唯一身份, 并通过 GSM 网络为移动支付用户建立支付信息上 传或下载的管道, 所述的加密模块用于加密移动支付用户请求的支付信息。 2. 根据权利要求 1 所。
4、述的移动支付单元, 其特征在于 : 所述的 PKI 加密单元通过授权 方写入 PKI 信息。 3. 根据权利要求 2 所述的移动支付单元, 其特征在于 : 所述的授权方为决定或者拒绝 支付的一个或者多个支付服务器。 4. 一种基于权利要求 1 所述的移动支付单元的移动支付系统, 包含安装于移动智能通 讯终端的应用程序 APP, 设置于移动智能通讯终端内的移动支付单元, 接受或者拒绝支付请 求的支付服务器, 所述的移动支付用户通过 APP 发起支付请求, 所述的支付请求通过无线 网络发送给支付服务器, 在此过程中, 移动支付单元、 APP、 支付服务器分别对发出或接收的 移动支付请求的相关信息进。
5、行加密和解密, 所述的支付服务器通过 OTA/SMS 管道和无线网 络管道分别鉴别移动支付单元和 APP 的身份合法性, 并对支付请求发出接收或者拒绝的命 令。 5. 根据权利要求 4 所述的移动支付单元的移动支付系统, 其特征在于 : 在初始化条件 下, 所述的支付服务器获取并保存移动支付单元的唯一身份信息, 并将相应的 PKI 信息写 入移动支付单元中一组空白的 PKI 加密单元 ; 在移动支付条件下, 所述的支付服务器建立 一对双向鉴权数据, 通过 OTA/SMS 及无线网络分别发给移动支付单元和 App ; 所述 App 通过 无线网络从所述支付服务器接收相应的一组鉴权数据, 处理后发。
6、给所述移动支付单元请求 鉴权 ; 所述移动支付单元将数据对比 OTA/SMS 管道收到的鉴权数据, 鉴权通过后使能对应 的 PKI 加密单元签发相应 PKI 移动支付数据给 App, 并由 App 转发给支付服务器完成该次 移动支付。 6. 根据权利要求 5 所述的移动支付单元的移动支付系统, 其特征在于 : 所述 App 从所 述支付服务器接收相应的一组鉴权数据, 处理后发给所述移动支付单元请求鉴权 ; 所述移 动支付单元将数据对比OTA/SMS管道收到的鉴权数据, 鉴权未通过, 则PKI加密单元拒绝签 发PKI移动支付数据, 支付请求被决绝, 并将错误信息通过OTA/SMS管道发回给支付服。
7、务器 报备。 7. 根据权利要求 4-6 任意权利要求所述的移动支付系统, 其特征在于 : 所述的无线网 络为 WIFI 无线网络或者 GSM 无线网络。 8. 一种基于根据权利要求 4 所述的移动支付系统的安全支付方法, 包含以下步骤 : S1, 由 App 通过无线网络向支付服务器发送交易请求, 所述交易请求包含交易号, 交易 额度 ; S2, 支付服务器收到所述的交易请求后, 产生一个随机的鉴权号, 连同交易请求信息的 部分或者全部信息生成一对鉴权数据 B1 和数据 B2, 其中数据 B1 由 OTA/SMS 途径打包加密 后发送给移动支付单元, 数据 B2 加密后发给 App ; S3。
8、, APP收到数据B2后进行相应的处理产生数据A1然后将数据A1发给移动支付单元 ; S4, 移动支付单元收到所述的从支付服务器发来的数据 B1 以及从 APP 发来的数据 A1 后, 对数据 B1 处理生成数据 C1, 对数据 A1 处理后生成数据 C2 ; 权 利 要 求 书 CN 104143142 A 2 2/2 页 3 S5, 比对数据 C1 与数据 C2 是否符合鉴权要求 ; 如果符合, 则使能对应的 PKI 单元对数 据 C1 和数据 C2 中的相关数据进行 PKI 加密和签名, 产生数据 C3, 并将数据 C3 发回给 App, 由 APP 继续完成支付。 9. 根据权利要求 。
9、8 所述安全支付方法, 其特征在于 : 所述的步骤 S5 中, 如果数据 C1 与 数据 C2 对比失败, 则相应的 PKI 单元将处于关闭 / 失效状态, 同时将数据 C1 和数据 C2 中 的相关数据从 OTA 或 SMS 途径上传至支付服务器进行错误报备, 方便支付服务器进行伪造 支付数据的侦测。 10. 根据权利要求 8 所述安全支付方法, 其特征在于 : 所述的步骤 S5 中, 如果在规定时 间内, 数据C1或数据C2中的任意一方缺失, 则该次移动支付归零, 并将相关信息经OTA/SMS 上传至支付服务器报备。 11. 根据权利要求 8 所述安全支付方法, 其特征在于 : 所述的支付。
10、服务器为一个或者多 个, 所述的支付服务器为银行服务器或者第三方支付服务器。 12. 根据权利要求 11 所述安全支付方法, 其特征在于 : 所述的多个银行服务器之间, 或 者银行服务器与第三方支付服务器之间在移动支付中互相进行鉴权。 13. 根据权利要求 8 所述安全支付方法, 其特征在于 : 所述的交易信息包含交易号、 交 易额度、 交易时间、 请求打包时间中的一个或者多个信息。 14. 根据权利要求 8 所述安全支付方法, 其特征在于 : 所述的加密模块包含 OTA 加密单 元和 PKI 加密单元。 15. 根据权利要求 8 所述安全支付方法, 其特征在于 : 所述的数据处理为数据加 /。
11、 解 密, 或者是对数据新增或减少部分数据形成新的数据的过程, 或者是对原数据的组成部分 进行新的排列组合。 16. 根据权利要求 8 所述安全支付方法, 其特征在于 : 所述的无线网络为 WIFi 无线网 络或者 GSM 无线网络。 权 利 要 求 书 CN 104143142 A 3 1/5 页 4 一种移动支付单元支付系统和安全支付方法 技术领域 0001 本发明涉及移动支付领域, 特别是一种移动支付单元、 以及基于移动支付单元的 支付系统和安全支付方法。 背景技术 0002 随着智能手机的普及以及移动支付需求的日益增加, 人们需要一种更加方便简洁 的方式来完成日常的 ATM 机银行服务。
12、、 网上银行的功能和移动支付的功能。现有的移动支 付有大约三种基本被认可的方案 : (1) 利用 SWP+NFC 技术实现小额离线支付。(2) 直接利用 App 进行银行转账或支付。(3)TSM(Trusted Service Management) 技术。 0003 移动支付的以上三种方法存在如下弊端 : 0004 (1)SWP 主要是解决近程小额下线支付, 但解决不了安全的在线支付或银行转账的 服务。(2) 而 App 存在着非常严重的安全漏洞, 特别是在安卓系统上, 即使是增加短信发送 密码的增强功能。(3)TSM 技术是想通过特定的下载中心来授权下载 App, 再加上手机上安 装特别的。
13、安全保密芯片 (SE 芯片 ) 的方法实现一个安全的运行环境。但安卓系统是一个开 放的平台, 实现不了所谓安全的运行环境。即使是 Apple 手机的不开放的 iOS 平台, 刚发布 几天, 就一次次被人破解越狱一样, 总有一天会被人攻破。而且 TSM 方案需要建设额外的 Infrastructure, 需要额外的在手机上安装 SE 芯片, 成本很高, 以及存量手机无法兼容 TSM 的问题。 0005 目前比较认可的在电脑上的网银转账购物等活动是通过 UKey 或者令牌的方式来 实现, 在各银行的实践中, 也基本认可了 UKey 或者令牌的安全性。Ukey 已经有一代和二代 key 的发展了。二。
14、代 Key 的产生主要是解决一代 Key 在使用中的安全隐患。一代 Key 的问 题本质上是 : 一代 Key 是一个开环, 缺乏安全的双向鉴权, 无法根除 “man-in-the-middle” 的攻击手段, 因此产生不安全的问题。该攻击手段的描述于 1995 年首先被 Mr Gavin Lowe 在论文中提出。攻击程序处于 UKEY 和银行之间, 模拟出伪造的交易需求和交易数据向银行 和 UKEY 分别提交, 从而获得合法的 PKI 签名。 0006 二代 Key 是通过两种方法来解决一代 Key 的安全隐患的 : (1) 利用客户自己的眼 睛和大脑再次确认交易及交易数据的合法性 (2) 。
15、客户必须按一下 Key 上的按键确认, UKEY 才对交易数据签名, 这是个物理操作, 利用物理隔离使得黑客软件无法何获得 PKI 签名。 0007 综上所述 UKEY 缺陷是 : 保证了密钥和交易数据具有身份认证、 完整性、 机密性、 不 可否认性等功能, 但不能保证交易本身具有合法授权。 0008 UKEY 的方式一定程度上大大方便了人们的生活, 不需任何事情都到银行柜台排队 办理, 但是随着电子商务的发展以及快节奏生活成为主流, 人们有随时随地安全转账或者 交易付款的需求, 但是不会随时随地都带着电脑和 UKEY, 从而目前的移动支付手段在不能 满足高水平的安全保障下无法满足人们随时随时。
16、实现支付。 发明内容 说 明 书 CN 104143142 A 4 2/5 页 5 0009 本发明提供一种新的移动支付的解决方案, 可以满足人们随时随地安全的移动支 付的需求, 其安全性可以超过 UKEY 电脑支付的安全性, 使人们不必带着电脑就可以随时随 地安全移动支付。 0010 本发明通过以下技术手段实现 : 0011 一种移动支付单元, 包含移动身份识别模块和加密模块, 所述的加密模块包括 OTA 加密单元和至少一组的基于 PKI 的加密单元 ; 所述的移动身份识别模块登陆 GSM 网络确定 移动支付用户的唯一身份, 并通过 GSM 网络为移动支付用户建立支付信息上传或下载的管 道,。
17、 所述的加密模块用于加密移动支付用户请求的支付信息。 0012 进一步的, 所述的 PKI 加密单元通过授权方写入 PKI 信息。 0013 进一步的, 所述的授权方为决定或者拒绝支付的一个或者多个支付服务器。 0014 一种基于移动支付单元的移动支付系统, 包含安装于移动智能通讯终端的应用程 序 APP, 设置于移动智能通讯终端内的移动支付单元, 接受或者拒绝支付请求的支付服务 器, 所述的移动支付用户通过 APP 发起支付请求, 所述的支付请求通过无线网络发送给支 付服务器, 在此过程中, 移动支付单元、 APP、 支付服务器分别对发出或接收的移动支付请求 的相关信息进行加密和解密, 所述。
18、的支付服务器鉴别移动支付单元和 APP 的身份合法性, 并对支付请求发出接收或者拒绝的命令。 0015 进一步的, 在初始化条件下, 所述的支付服务器获取并保存移动支付单元的唯一 身份信息, 并将相应的PKI信息写入移动支付单元中一组空白的PKI加密单元 ; 在移动支付 条件下, 所述的支付服务器建立一对双向鉴权数据, 通过 OTA/SMS 及无线网络通信管道分 别发给移动支付单元和 App ; 所述 App 从所述支付服务器接收相应的一组鉴权数据, 处理后 发给所述移动支付单元请求鉴权 ; 所述移动支付单元将数据对比 OTA/SMS 管道收到的鉴权 数据, 鉴权通过后使能对应的 PKI加密单。
19、元签发相应 PKI 移动支付数据给 App, 并由 App 转 发给支付服务器完成该次移动支付。 0016 进一步的, 所述 App 从所述支付服务器接收相应的一组鉴权数据, 处理后发给所 述移动支付单元请求鉴权 ; 所述移动支付单元将数据对比 OTA/SMS 管道收到的鉴权数据, 鉴权未通过, 则 PKI 加密单元拒绝签发 PKI 移动支付数据, 支付请求被决绝, 并将错误信息 通过 OTA/SMS 管道发回给支付服务器报备。 0017 所述的无线网络为 WIFI 无线网络或者 GSM 无线网络。 0018 一种基于移动支付系统的安全支付方法, 由 App 通过无线网络向支付服务器发送 交易。
20、请求, 所述交易请求包含交易号, 交易额度 ; 支付服务器收到所述的交易请求后, 产生 一个随机的鉴权号, 连同交易请求信息的部分或者全部信息生成一对鉴权数据 B1 和数据 B2, 其中数据 B1 由 OTA 途径打包加密后发送给移动支付单元, 数据 B2 加密后发给 App ; APP 收到数据B2后进行相应的处理产生数据A1然后将数据A1发给移动支付单元 ; 移动支付单 元收到所述的从支付服务器发来的数据 B1 以及从 APP 发来的数据 A1 后, 对数据 B1 处理生 成数据 C1, 对数据 A1 处理后生成数据 C2 ; 比对数据 C1 与数据 C2 是否符合鉴权要求 ; 如果 符合。
21、, 则使能对应的 PKI 单元对数据 C1 和数据 C2 中的相关数据进行 PKI 加密和签名, 产生 数据 C3, 并将数据 C3 发回给 App, 由 APP 继续完成支付。 0019 进一步的, 如果数据 C1 与数据 C2 对比失败, 则相应的 PKI 单元将处于关闭 / 失效 状态, 同时将数据 C1 和数据 C2 中的相关数据从 OTA 或 SMS 途径上传至支付服务器进行错 说 明 书 CN 104143142 A 5 3/5 页 6 误报备, 方便支付服务器进行伪造支付数据的侦测。 0020 进一步的, 如果在规定时间内, 数据 C1 或数据 C2 中的任意一方缺失, 则该次移。
22、动 支付归零, 并将相关信息经 OTA/SMS 上传至支付服务器报备。 0021 更进一步的, 所述的支付服务器为一个或者多个, 所述的支付服务器为银行服务 器或者其他非银行类金融支付服务器。所述的多个银行服务器之间, 或者银行服务器与第 三方支付服务器之间在移动支付中互相进行鉴权。 0022 更进一步的, 所述的交易信息包含交易号、 交易额度、 交易时间、 请求打包时间中 的一个或者多个信息。 0023 更进一步的, 所述的加密模块包含 OTA 加密单元和 PKI 加密单元。 0024 进一步的, 所述的数据处理为数据加 / 解密, 或者是对数据新增或减少部分数据 形成新的数据的过程, 或者。
23、是对原数据的组成部分进行新的排列组合。 0025 最后, 所述的无线网络为 WIFI 无线网络或者 GSM 无线网络。 0026 本发明通过设置在移动智能通讯终端的安全的移动支付单元使用户实现在移动 智能终端随时随地的支付、 转账需求, 且安全程度高。 附图说明 0027 图 1 为三方鉴权闭环示意图 ; 0028 图 2 为多支付服务器的三方鉴权闭环示意图。 具体实施方式 0029 以下将详细描述本发明的实施方式。 0030 一种移动支付单元, 包含移动身份识别模块和加密模块, 所述的加密模块包括 OTA 加密单元和至少一组的基于 PKI 的加密单元 ; 所述的移动身份识别模块登陆 GSM 。
24、网络确定 移动支付用户的唯一身份, 并通过 GSM 网络为移动支付用户建立支付信息上传或下载的管 道, 所述的加密模块用于加密移动支付用户请求的支付信息。 0031 具体来说, 所述的移动支付单元兼具现有技术SIM卡的功能与UKEY等银行支付设 备的功能, 通过在移动智能通讯终端的插槽与移动智能通讯终端电连接, 或者作为移动智 能终端的一个内在结构设置在移动智能通讯终端内。所述的移动支付单元构建了 GSM 通讯 管道和物理上安全的支付硬件。 0032 所述的 PKI 加密单元为一组或者多组, 每组存放一个支付服务器的授权信息, 这 里的移动支付服务器, 可以为各大银行的服务器, 也可以为类似支。
25、付宝、 财付通等非银行类 第三方服务机构的支付服务器。使用时, 需先由授权的银行 / 或单位将授权信息下载到申 请用户移动支付单元的一组空白 PKI 加密单元。 0033 为了更方便的实现移动支付, 本发明还构建了基于所述的移动支付单元的移动支 付系统, 即安装于移动智能通讯终端的银行或第三方金融机构的 APP, 设置于所述的移动智 能终端的移动支付单元, 以及接受或者拒绝支付请求的银行或第三方支付服务器。 0034 具体来说, 以手机为例作为移动智能通讯终端, 以银行作为支付服务器, 在初始化 条件下, 银行获取并保存移动支付单元的唯一身份信息, 并将相应的 PKI 信息写入移动支 付单元中。
26、一组空白的 PKI 加密单元 ; 所述的移动支付用户通过所持手机端的 APP 发起支付 说 明 书 CN 104143142 A 6 4/5 页 7 请求, 支付请求通过无线网络与银行建立联系, 所述的无线网络可以为 WIFI 无线网络或者 GSM 无线网络, 而 App 与所述的移动支付单元之间的通信可以利用 ISO7816 的管道, 或着利 用 SWP 的通信管道, 或者利用 USB 的通信管道, 实现 APP 与移动支付单元之间的信息交互。 在此过程中, 移动支付单元、 APP、 银行分别对发出或接收的移动支付请求的相关信息进行 加密和解密, 银行鉴别移动支付单元及 APP 的身份合法性。
27、, 并对支付请求发出接收或者拒 绝的命令, 即在 APP、 银行、 移动支付单元之间形成支付闭环。 0035 所述的支付闭环简单来说是 : 分别利用手机上网的网络通道和 GSM 所固有的 OTA/ SMS 通道建立两套独立的、 各自不同安全机制的通信管道, 鉴权信息分别在两个独立管道中 流通, 并交互对比, 从而杜绝黑客针对单个管道或单体对象的攻击, 当鉴权失败时, 可以将 失败信息通过独立的 OTA/SMS 通道发送给服务器建立预警机制。具体来说是, 银行建立一 对双向鉴权数据, 通过 OTA/SMS 及无线网络通信管道分别发给移动支付单元和 App, App 接 收到银行发来的相应的一组鉴。
28、权数据, 处理后发给移动支付单元请求鉴权 ; 所述移动支付 单元将此数据对比 OTA/SMS 管道收到的鉴权数据, 鉴权通过后使能对应的 PKI 加密单元签 发相应 PKI 移动支付数据给 App, 并由 App 转发给银行并完成该次移动支付。 0036 举例来说, 由 App 向支付服务器发送交易请求, 所述交易请求包含交易号, 交易额 度, 也可以包含交易请求时间, 交易地点、 数据打包时间等多项信息, 形成数据包 A, 然后银 行收到所述的含有交易请求数据的数据包 A 后, 产生一个随机的鉴权号, 连同交易请求信 息的部分或者全部信息生成一对鉴权数据B1和B2,这里的鉴权号是附件的信息之。
29、一, 也可 以是根据需求进一步附加的其他信息, 所述的数据 B1 和数据 B2 可以是包含由 APP 发来的 请求数据的全部, 也可以是 APP 发来的请求数据的一部分, 也可以是对原数据重新排列组 合后的数据 ; 接着其中数据B1由OTA/SMS途径打包加密后发送给移动支付单元, 数据B2加 密后通过无线网络发给 App ; APP 收到数据 B2 后进行相应的处理后产生数据 A1, 然后将数 据 A1 发给移动支付单元 ; 移动支付单元收到所述的从银行发来的数据 B1 以及从 APP 发来 的数据 A1 后, 对数据 B1 处理生成数据 C1, 对数据 A1 处理后生成数据 C2 ; 最后。
30、比对数据 C1 与数据 C2 是否符合鉴权要求 ; 如果符合, 则使能对应的 PKI 单元, 对数据 C1 和数据 C2 中的 相关数据进行 PKI 加密和签名, 产生数据 C3, 并将 C3 发回给 App, 由 APP 继续完成支付。如 果数据 C1 与数据 C2 对比失败, 则相应的 PKI 单元将处于关闭或失效状态, 同时将数据 C1 和数据 C2 中的相关数据从 OTA 或 SMS 途径上传至银行服务器进行错误报备, 方便相关机构 对伪造支付数据的来源进行侦测。如果在规定时间内, 数据 C1 或数据 C2 中的任意一方缺 失, 则该次移动支付归零, 也将相关信息经 OTA 上传至银行。
31、服务器报备。 0037 如果支付需要通过多个支付服务器, 比如支付需要经过支付宝、 银行两个支付服 务器才能完成, 则支付过程中, 银行与支付宝也需要进行相互鉴权, 鉴权的方式可以是图 1 所示的 : A B C A, 也可以是图 2 所示的 A B C A, B D ; 其中 A 代表 App ; B 代表一个或多个银行或者第三方支付机构, C 代表移动支付单元, D 代表银行 或第三方支付机构。即移动支付所涉及的各个单元之间形成串联式鉴权闭环, 也可以是在 多个支付服务器之间互相鉴权, 然后产生一个鉴权代表与 App 和移动支付单元再组成鉴权 闭环。 0038 使用时, 为了更安全, 可以。
32、建议用户在银行指定的安全环境下下载手机银行的 App, 并进行如下的绑定 : 将 App 和手机绑定 ; 将银行和智能手机中的移动支付单元绑定, 说 明 书 CN 104143142 A 7 5/5 页 8 即绑定移动支付单元的身份号码及密钥。密钥的绑定有很多种方法, 例如用三组密钥 : Key0( 上传数据密钥 ) ; Key1( 下传数据密钥 ) ; Key2(App 转发数据密钥 ) ; 0039 进行交易时, 由 App 向银行发送请求, 包括交易号, 款额等。银行收到后, 产生一个 随机的鉴权号, 将交易号、 款额、 鉴权号, 时间范围等用Key1(下行数据密钥)打包加密并数 字签名。
33、后, 由 OTA 或 SMS 管道发给移动支付单元。银行同时将鉴权号利用服务器和 App 的 安全协议进行处理, 然后通过网络发给 App, 其中 Key2 可以用数字信封方式一起发给 App。 App收到后将交易号、 款额再加上这个加密信息合在一起形成数据2, 然后用key2签名后发 给移动支付单元。移动支付单元收到 OTA 或 SMS 短信后解密, 然后移动支付单元收到 App 发来的信息, 用 Key2 对加密信息解密和验证签名。然后将 OTA/SMS 信息和 App 信息进行比 对。如果对比成功, 则签发数字签名, 并将数据发回给 App。同时将比对结果用 Key0 加密及 签名后用 。
34、SMS 发给银行, 支付可以安全的进行了。 0040 通过以上实现的移动支付单元, 以及在移动支付单元上形成的支付系统和安全支 付方法, 相比现有的移动支付在安全性方面有以下特点 : 0041 1、 可以充分利用现有的基础设施和技术规范, 将目前SIM和UKEY的优点有机的结 合在一起实现安全的三方双向鉴权, 使只要在有 GSM 网络或者无线 WIFI 网络的地方, 就可 以安全的进行线上支付或者银行转账。 0042 2、 移动支付单元安全的加密 / 解密类似在黑箱中进行, 移动支付单元物理上独立 于电脑或手机的操作系统, 很难被拆解, 防止了从移动支付单元内部监控的运行, 密钥存在 于移动支。
35、付单元中, 并且不可读。 0043 3、 移动支付单元独立的 OTA 短信管道只发 OTA/SMS 给该用户, 并有自己的一套安 全机制, 给黑客的破解带来极大的困难。 0044 4、 当手机丢失或被窃取时, 用户只需报失, 只要该移动支付单元登录 GSM 网络, 就 可以立即通过 OTA 短信将该 SIM 内部敏感信息全部删除。 0045 5、 GSM 网络鉴权系统的保护。因为 UKEY 只有在移动支付单元正常上网的情况下 才能被激活, 因此黑客首先需要破解 GSM 网络的系统, 才有可能进行移动支付单元的破解。 0046 对本发明进行简单变化所得的方案也在本发明保护的范围之内, 在此不一一列 举。 说 明 书 CN 104143142 A 8 1/2 页 9 图 1 说 明 书 附 图 CN 104143142 A 9 2/2 页 10 图 2 说 明 书 附 图 CN 104143142 A 10 。