手机支付安全解决方案演进

 手机支付安全涉及内容很多,需要从终端侧、平台侧多个维度进行解决。涉及终端安全、web安全、框架安全、数据安全、风险控制等多方面。

本文主要围绕如何在终端侧构建手机支付安全解决方案。

以支付宝为例,微信也是类似。目前的安全机制是围绕短信认证展开的。为啥就得围绕短信验证码展开呢?原因很简单:

1)总比纯粹的用户名/密码好些吧。要是纯粹的用户名/密码,一方面可能是用户名/密码被盗,另一方面也容易被钓鱼。

2)在移动终端上可以发送和接受短信。

3)其实PC上有很多安全机制,比如专用otp、u盾等等,但大家用的比较多的也是手机校验码。面向智能终端的硬件设备目前也有,比如基于耳机孔、蓝牙的U盾,OTP设备等。

4)手机校验码虽然存在很多问题,但体验好啊!安全是服务于业务的,而不是凌驾于业务之上,成为业务推广的瓶颈。做安全的切记,安全是绿叶,是要衬托业务这朵红花的,切勿本末倒置,空谈绝对安全。

1、支付宝如何围绕短信认证构建:

手机支付安全解决方案演进_第1张图片

切勿hack这个号码,里面有近百万的巨资。支付宝里面涉及登陆密码和支付密码。

手机支付安全解决方案演进_第2张图片

如何找回登陆密码?还是短信验证码,后来又增加了身份证。

手机支付安全解决方案演进_第3张图片

如何找回支付密码呢?是一个webview指向的网站,还得去网页找回密码。这家伙可麻烦了,我经常会忘记密码。

手机支付安全解决方案演进_第4张图片

我看了一下网页找回支付密码的流程,和找回登陆密码类似,增加了银行卡校验,但手机客户端非把这玩意搞到网页来修改,是何道理?产品经理何在?

手机支付安全解决方案演进_第5张图片

2、支付宝围绕短信认证码构建存在哪些问题?

      1)看报道就知道了,丢了手机可能会找回登录密码(现在还需要身份证号码,有身份证和手机号对应的社工库吗?),找回支付密码(现在需要银行卡卡号)。

除了丢失手机,由于补办sim卡引起的漏洞,导致用户的sim卡被非法使用。 由于丢手机和补卡的风险,所以才产生了身份证、银行卡等额外的需求。

     2)目前找回密码都是通过短信认证码完成的, 登陆和支付主要靠静态密码校验,那么存在被钓鱼的风险。不过问题不大,通常支付宝客户端检测到新的账户后会要求短信检验码认证。

手机支付安全解决方案演进_第6张图片

但如果是一个定制版的支付宝客户端,钓鱼得到了静态密码,结果会咋样?

3)不管是静态密码还是短信认证码

    都是承担认证的作用,对业务数据没有起到保护作用。所以,单纯的认证远远不能解决问题。这儿建议读者理解一下银行二代U盾和一代U盾的差异性。

  除了钓鱼等手段,要想直接获取用户输入或者篡改用户输入以及自动模拟用户完成都需要root权限,现在android root的终端很多,但这类恶意软件比较少!

他们迟早回来的,这些事情完成起来很难吗?在iOS越狱的机器上很常见,iOS的安全体系很完备,但其攻击体系也很强大!

  微博上看到一张图,其实iOS的hook、注入都是现成的工具。据我了解,一些android底下组织已经有类似的工具了。

手机支付安全解决方案演进_第7张图片

4、手机有没有可信源啊?

     如果仅解决认证的问题,不考虑交易数据篡改、自动执行以及槽糕的用户体验(一大堆密码),基于短信构建如果设计完备的话,是可以的。      

但需要考虑交易数据篡改等威胁吗,那是肯定的。

那么在手机上有没有可信跟?真的有!手机的sim卡就是独立于AP还客观存在。网上搜一个智能终端的架构:

手机支付安全解决方案演进_第8张图片

从图上可以看到,sim卡长期潜伏在cp侧,承担网络鉴权的任务,sim只有不多的几条api如读取imsi可以提供给AP侧供android调用。

但sim卡这么多年了长进不大,一心一意做好鉴权!只有最近的nfc出来才带来一些变化。

那么sim卡对支付安全能有哪些价值?

1)sim既然已经是存在与终端的独立硬件,操作系统无法对他进行骚扰。那么他能不能扮演U盾的角色呢?

   这就是pki-sim卡。简单一点就是让定制一下sim卡,让其支持rsa等算法,支持证书。

网上继续搜:http://www.doc88.com/p-748553255043.html

手机支付安全解决方案演进_第9张图片

看到这个图,有个疑问,就是签名的时候为啥要走短信通道?

原因就是:机卡接口不支持终端直接调用sim签名。。。只有通过数据短信(一种和sim卡交互的特殊短信)直接抵达sim卡。

打开机卡接口这方面java曾经努力过:参照jsr177:

SATSA(JSR-177)API分为两个部分:
              智能卡通讯API:支持与智能卡应用程序的通讯,通讯协议包含APDU,(U)STA,JCRMI。
              签名服务和用户凭证API:支持格式化数字签名;支持用户凭证管理,包括用户证书申请,添加用户凭证,删除用户凭证。
JSR-177包含了四个程序可选包:
        SATSA-APDU通讯包:支持与使用APDU的智能卡应用程序的通信;支持与(U)SIM卡的(U)SAT应用程序的通讯。
       S ATSA-JCRMI通讯包:定义Java Card RMI客户端API以支持Java Card对象的远程方法调用。
       SATSA-PKI签名服务:支持应用层的数字签名和基本的用户凭证管理。
      SATSA-CRYPTO密码接口:提供了一些基本的密码操作,如消息摘要,签名验证,加密,解密。
手机支付安全解决方案演进_第10张图片

另外这两年热火朝天的NFC,可以参照前文:http://blog.csdn.net/u011069813/article/details/17143911

手机支付安全解决方案演进_第11张图片

不管是pki-sim或者nfc方案,都存在几个问题:

  a)运营商换卡成本很高,推广很难!虚拟运营商兴起了,他们可以吗?哈哈!

  b) NFC方案到现在迟迟没有确定!

  c)pki-sim解决了一个问题,那就是交易和sim卡完全绑定了,离开了这张卡,无法完成交易。神马钓鱼之类的无需担心。但交易数据还是可能被篡改。

   但比软证书的安全等级要高一些。

2)终端还有一个很特殊的功能,那就是手机号码无法伪造!

    因为手机号码完全是靠基带获取的imsi上传后通过HLR获取对应的手机号码。因而绕过了android等邪恶系统的拦截。

   举一个例子,如果终端发一条短信给平台,那么平台获得的终端手机号码是无法假冒的。

  a)以前运营商很多业务是通过CMWAP接入,直接在平台侧就可以获取手机号码。

  b)另一个就是目前基于SIM卡的WLAN认证,既然终端已有sim卡认证,为何WLAN认证还需要额外认证。大家可以去体验一下CMCC-AUTO

EAP-SIM/AKA是EAP认证方法的一种实现方式,其通过用户(U)SIM卡信息进行认证,与蜂窝认证方式相同,当用户使用SIM卡时,执行EAP-SIM认证流程,当用户使用USIM卡时,执行EAP-AKA认证流程,整个认证过程不需要用户介入任何手工操作,完全由终端自动完成。

手机支付安全解决方案演进_第12张图片

上述二者都可以利用运营商提供的接口实现认证。

5、SELinux带来的对android自身安全的提升

selinux引入了强制访问控制:

DAC(Discretionary Access Control 自主访问控制: 传统Unix/Linux安全管理模型;主体对它所属的对象和运行的程序拥有全部的控制权
MAC(Mandatory Access Control强制访问控制):SELinux基于的安全策略;管理员管理访问控制。管理员制定策略,用户不能改变它。策略定义了哪个主体能访问哪个对象。采用最小特权方式,默认情况下应用程序和用户没有任何权限。

DAC模式下,Web服务器进程具有ROOT权限,当恶意病毒攻击成功并注入Web服务器进程后,则可以利用Web服务器进程的ROOT权限,做任何事情。

手机支付安全解决方案演进_第13张图片


MAC模式下:Web服务器进程所能操作的对象和权限均在安全策略中明确列出,比如,只允许访问网络和访问特定文件等。即便Web服务器被恶意病毒攻击注入了,你仍然无法借由Web服务器进程为所欲为,所有安全策略上没有授权的行为仍然是不允许的。

手机支付安全解决方案演进_第14张图片

手机支付安全解决方案演进_第15张图片

android包括的策略文件很多:

手机支付安全解决方案演进_第16张图片

如何看懂selinux策略以及定义新策略:比如这是第三方app的缺省策略,你看看到底实施策略后,第三方app能干啥?

###
### Untrusted apps.
###
### This file defines the rules for untrusted apps. An "untrusted
### app" is an APP with UID between APP_AID (10000)
### and AID_ISOLATED_START (99000).
###
### untrusted_app includes all the appdomain rules, plus the
### additional following rules:
###


type untrusted_app, domain;
permissive_or_unconfined(untrusted_app)
app_domain(untrusted_app)
net_domain(untrusted_app)
bluetooth_domain(untrusted_app)


# Some apps ship with shared libraries and binaries that they write out
# to their sandbox directory and then execute.
allow untrusted_app app_data_file:file rx_file_perms;


allow untrusted_app tun_device:chr_file rw_file_perms;


# Internal SDCard rw access.
allow untrusted_app sdcard_internal:dir create_dir_perms;
allow untrusted_app sdcard_internal:file create_file_perms;


# External SDCard rw access.
allow untrusted_app sdcard_external:dir create_dir_perms;
allow untrusted_app sdcard_external:file create_file_perms;


# ASEC
allow untrusted_app asec_apk_file:dir { getattr };
allow untrusted_app asec_apk_file:file r_file_perms;
# Execute libs in asec containers.
allow untrusted_app asec_public_file:file execute;


# Create tcp/udp sockets
allow untrusted_app node_type:{ tcp_socket udp_socket } node_bind;
allow untrusted_app self:{ tcp_socket udp_socket } { create_socket_perms accept listen };
# Bind to a particular hostname/address/interface (e.g., localhost) instead of
# ANY. Normally, apps should not be listening on all interfaces.
allow untrusted_app port:{ tcp_socket udp_socket } name_bind;


# Allow the allocation and use of ptys
# Used by: https://play.google.com/store/apps/details?id=jackpal.androidterm
create_pty(untrusted_app)


# Used by Finsky / Android "Verify Apps" functionality when
# running "adb install foo.apk".
# TODO: Long term, we don't want apps probing into shell data files.
# Figure out a way to remove these rules.
allow untrusted_app shell_data_file:file r_file_perms;
allow untrusted_app shell_data_file:dir r_dir_perms;


那么SELinux对支付安全的价值何在?主要两方面:

1)对android的普适安全提升

2)构建多域安全,域之间隔离,域app来源控制。

手机支付安全解决方案演进_第17张图片

用于随心所欲,任意创建安全域。域里面的应用都是我精心审核过的,请大家放心使用。。。

手机支付安全解决方案演进_第18张图片

三星虽然产品化了,但too simple.

手机支付安全解决方案演进_第19张图片

手机支付安全解决方案演进_第20张图片

5+虚拟化

基于SEAndroid的终端会是标配(不包括iOS和WP),因为可以为app提供安全服务。另一种技术虚拟化,可以和SELinux结合提供更高等级的安全服务。

但虚拟化系统开销大,不管是短期还是长期我暂时不看好。但不妨看看其架构。

手机支付安全解决方案演进_第21张图片

5++ TPM

   不管是SELinux还是虚拟化,SELinux需要保证内核完整性,虚拟化需要确保vmm完整性。咋办?两种办法:

  1)Trustzone,这就是三星Knox的方案。

  2)TPM,这就是可信计算。

手机支付安全解决方案演进_第22张图片


6、Trustzone的价值

Demo:http://www.owasp.org.cn/OWASP_Events/download/SoCLevelSecuritySolutionforMobilePayment_v1.pdf

需要输入密码时进入安全模式。

手机支付安全解决方案演进_第23张图片

调用过程:

手机支付安全解决方案演进_第24张图片

下图是普适的TZ架构。

手机支付安全解决方案演进_第25张图片

更容易理解的架构:

手机支付安全解决方案演进_第26张图片

  TZ有安全问题吗?只要人实现的,就有!比如TZ software framework尤其TZ driver 的漏洞。


7、指纹识别的价值

      很多年前了,电视购物不厌其烦的宣传featurephone就有了指纹。。。不过一直没用起来。

      苹果推出来后,指纹识别的价值貌似彰显起来了,当然这也是智能机和移动互联网时代的时机。

手机支付安全解决方案演进_第27张图片

Touch ID既可以充当解锁设备密码的角色,它也可以授权用户在iTunes中购买。将来会扩展到更广阔的的支付领域。

针对指纹识别,苹果提出了Secure Enclave的概念,其实就是Trustzone。利用TZ也更高好的实现了原有的Data Protection key management。


8、大数据

       很多交易数据和行为都可以在后台观测到,通过这些行为可以发现很多异常情况,对提升账户安全有很大的价值。当然最好是终端可以提供一些有目的的数据,以便更好的进行大数据的挖掘。

      下列胶片来源:云中舞剑-大数据安全分析-阿里.pdf

手机支付安全解决方案演进_第28张图片

手机支付安全解决方案演进_第29张图片

手机支付安全解决方案演进_第30张图片

手机支付安全解决方案演进_第31张图片



9、110

     黑阔最怕的手段,也是最直接有效的手段。前提就是系统设计时考虑到取证。

10、建议和演进

       1)android的安全体系越来越完善。尤其是4.4以后。

            举个例子,拦截这个例子:

手机支付安全解决方案演进_第32张图片

4.4版本,只有被用户设置为缺省的短消息程序才能直接发短信、拦截短信。 让用户把第三方程序设置为缺省的短消息程序既需要勇气、也考验智商。

这样在一定程度上降低了短信验证码被拦截引起的风险。

     2)SELinux的实施。

           a)提升Root的难度,比如著名的GingerBreak,其中的多个步骤都无法通过policy MAC.

           /proc/pid/cmdline of other domains denied by policy

            Send netlink message to vold process. netlink socket create denied by policy

           b)提升Root后作恶的难度,比如无法Ptrace。

           c)进一步提升应用SandBox的强度。比如:如果实施了SE,则不能访问。

Skype app for Android.
● CVE-2011-1717
● Stores sensitive user data without encryption with world readable permissions.
– account balance, DOB, home address, contacts, chatlogs, ...
● Any other app on the phone could read the user data.

           

待续!!!!!!!!!!!!!!



你可能感兴趣的:(android)