今天和大家聊聊支付系统安全设计的图解一些核心知识点 。 进入正题前,支付继续先讲个小故事。系统 多年前国内还没有断直连,安全我当时负责对接银行通道
,设计因为银行对安全看得很重,精华部署了很多硬件加密机
,图解在接口上也要求我们使用硬件加密机。支付当时公司有上千名研发工程师 ,系统但都没有硬件加密机的安全使用经验,我是设计第一个 。当时还需要经常跑到机房去操作硬件加密机,精华因为硬件加密机的图解要求设计要求 ,源码下载很多管理操作是支付要多张IC卡加独立口令通过管理口登录才能进行,不能远程操作 。系统 记得第一次从加密机厂家提供的使用手册和技术规范读到主密钥 ,区域主密钥,工作密钥等概念,让我如同开了天眼 :原来密钥还分这么多种,一个密钥还需要另外一个密钥来保护 ! 对接完渠道后
,发现我们很多密钥都明文放在代码、配置或数据库中 ,其实是不安全的
,于是建站模板利用硬件加密机作为主密钥服务 ,设计了一套统一密钥存储与加解密系统 ,并推广到了全公司使用。 在设计统一密钥存储与加解密系统过程中,啃了好几本密码学和信息安全方面的大部头书,所以支付安全相关的知识储备还是可以的 。 在一些大型互联网公司或专业的支付公司,有专业的安全团队提供安全保障 ,但很多中小型公司其实是没有这方面的模板下载技术或人才储备的,那么可以根据这篇文章做一个初步的了解:支付安全如何做
。 以前发过一篇1万7千字的长文论述支付安全设计
,这里抽取出精华部分
,想了解更多细节的,可以去找那篇“一文搞懂支付安全”看看。 支付安全是支付系统最重要的根基之一,没有支付安全
,在线支付系统就无从谈起
。但是云计算安全又是一门很大的学科
,涉及密码学 ,网络设备,法律法规
,流程制度等方方面面。 这里只谈一些和软件研发比较紧密的一部分内容
,不涉及网络防火墙等网络设备安全。主要包括以下几点内容: 安全的范围很广,我们重点关注以下几点
: 制度是基础
,指导各项安全措施落地。 这里的传输安全主要指支付平台和外部的数据传输
,包括用户、商户、银行渠道等。 最简单的当然是加密后再传输
。但是所有数据全部经过加密后再传输比较麻烦,还有一个办法就是直接把传输的管道进行加密,然后传输明文数据。 SSL,TLS,HTTPS,VPN,专线等技术都是属于这类技术。 存储安全不是简单地加密后保存到数据库,这样的成本太高。通常数据的安全级别是不一样的,下面是一个不太严谨的分级及应对手段 : 需要留意的是
,敏感信息是不能打印明文到日志中的,这是大家经常容易忽略的地方。 交易安全涉及的范围比较广,甚至上面说的传输安全和存储安全也可以纳入到交易安全的范围。 严格意义上的交易安全通常指 :确保各交易方都是合法的(身份验证)
,交易内容是合法的(安全合规与防欺诈)
,交易数据是合法的(防篡改防抵赖)
。 身份验证
:证明你是你
。比如登录密码,支付密码,个人证书,手机验证码等 。 安全合规与防欺诈 :买卖的交易标的是合法的(安全合规) ,没有被盗刷(欺诈交易)等。比如买卖国家保护动物就是非法不合规交易;支付密码被盗后的交易就是欺诈交易。 防篡改防抵赖:通过数字签名技术,防止数据被篡改或事后抵赖
。比如商户发了一笔转账交易 ,事后说没有发过这笔交易 ,就是抵赖
。 只要涉及到安全,就一定绕不开密码学。上面提到的大部分问题在技术上的落地,基本上都是围绕密码学在打转
。 加解密算法的核心作用就是明文数据信息不被窃取
。 加密是将明文通过一定的算法和密钥转换成无法识别的密文的过程
。比如把明文“123”转成“aexyeffidfdfwsd”。 解密则是加密的逆向过程
,通过一定的算法和密钥将密文转换成明文的过程。比如把密文“aexyeffidfdfwsd”转成“123”。 对称加密是使用相同的密钥(称为对称密钥)进行加密和解密。双方须共享相同的密钥。好处是使用简单且高效,缺点是密钥分发和管理容易泄露。 常见的对称加密算法有: AES目前被认为是最安全和最常用的对称加密算法,推荐在支付行业使用
。密钥长度128比特当前够用,但推荐256比特。 AES在实际使用时,还需要有很参数要配置
,比如加密模式就有CBC,ECB
、CFB等。 非对称加密算法使用一对密钥(公钥和私钥)进行加密和解密。这种加密方式具有密钥分离的特点 ,即公钥可以公开分发
,而私钥则保密保存 。 公钥用于加密数据 ,私钥用于解密数据
,一定不能反过来。原因很简单,公钥大家都有,如果使用私钥加密
,公钥解密
,大家都可以解密
,就没有安全性可言
。 另外,非对称加密算法也用于签名验签 ,拿私钥签名 ,公钥验签(不能反过来)。 以下是一些常见的非对称加密算法
: RSA当前在支付行业应用非常广泛 ,推荐密钥长度为2048比特或以上。 数字信封加密算法组合了对称加密、非对称加密、数字签名和验签等多种加密技术。之所以经常被称为数字信封
,是因为传输的数据就像放在信封里面 ,只有收件人才能打开信封查看明文 。 比如经常看见的就是PGP(Pretty Good Privacy)。最开始用于保护电子邮件,后面被广泛用于保护文件传输,比如支付平台和银行之间的文件。 PGP通常推荐使用RSA 2048和AES 256
,前者用于加密对称密钥和签名 ,后面用于加密大数据块
。 它的原理是使用对称加密算法对要传输的数据进行加密,然后再使用接收方的公钥对对称密钥进行加密 ,再使用自己的私钥进行签名,最后将加密后的对称密钥和加密后的数据一起发送给接收方。接收方先使用对方的公钥进行验签,再使用私钥解密对称密钥 ,最后使用对称密钥解密数据 。 下图是数字信封加解密算法的完整过程
: 现在很多银行的打款文件要求使用PGP加密,因为文件里面有卡号等敏感数据 。 签名验签的核心作用就是防篡改和防抵赖。只要有篡改,验签就通不过。因为加签密钥是私钥
,只要用公钥验签通过,就说明是密钥持有人发出来的报文 。 签名 :发送者将数据通过特定算法和密钥转换成一串唯一的密文串 ,也称之为数字签名,和报文信息一起发给接收方
。 验签:接收者根据接收的数据
、数字签名进行验证,确认数据的完整性,以证明数据未被篡改,且确实来自声称的发送方 。如果验签成功,就可以确信数据是完好且合法的。 下面是一个极简的签名验签数学公式。 假设被签名的数据(m),签名串(Σ),散列函数(H),私钥(Pr),公钥(Pu),加密算法(S)
,解密算法(S^)
,判断相等(eq)。 简化后的数学公式如下 : 签名:Σ=S[H(m), Pr]。 验签 :f(v)=[H(m) eq S^(Σ, Pu)]。 流程图如下: 如果两个散列值相等 ,那么验签成功
,消息(m)被认为是完整的
,且确实来自声称的发送方
。如果不一致,就是验签失败
,消息可能被篡改,或者签名是伪造的 。 现实中的算法会复杂非常多,比如RSA,ECDSA等
,还涉及到填充方案,随机数生成
,数据编码等
。 常见的数字签名算法包括: 在普通在线支付场景来说,RSA使用最为广泛,密钥长度推荐2048比特
。 明文数据被加密安全存储,还需要考虑用于加密的密钥如何安全存储。 密钥的重要性,有一个不成文的公式是这样的
:密钥的价值 = 密文的价值
。比如你加密存储的密文价值10亿
,那对应的密钥价值也有10亿。 密钥的管理涉及4个方面:密钥存储 、更新、备份和恢复、废止和销毁。如果想要管好这些密钥
,就需要建设一个统一的密钥存储服务 ,否则密钥很容易被泄露
。 密钥存储需要满足2个条件
: 密钥分为主密钥和工作密钥,其中工作密钥用来加解密普通的业务数据
,而主密钥用来加解密工作密钥
。 一般来说主密钥应该存储在专门的硬件加密机中,官方也称硬件安全模块(HSM)中。特点是安全性极高,但是性能有限,且价格昂贵,管理复杂
。 工作密钥一般由主密钥加密后保存在DB中 ,在需要的时候调用主密钥解密后,缓存在内存中
,然后再去加解密普通的业务数据
。 以前在和银行对接时,工作密钥是合成的,支付平台生成一半,银行生成一半,各自输入到硬件加密机,生成一份工作密钥 ,受硬件加密机的主密钥保护。这样支付平台和银行都不知道工作密钥是什么。 密钥更新机制: 说明: 大数据块通常采用对称加密算法,一般是AE 128或AES 256。比如大段的报文 。 小数据块
,且涉及公开环境
,通常采用非对称算法 ,一般是RSA 2048或RSA 4096 。比如在前端把用户的密码使用公钥加密
,后端使用私钥转加密
。 文件类通常采用PGP,把整个文件加密后上传下载
,既防窃取又防篡改
。 普通支付场景一般是RSA 2048 或RSA 4096。安全足够 ,各家都支持。 如果交易规模大 ,建议使用硬件加密机用于加密工作密钥,否则出了安全问题,损失巨大。1. 序
2. 前言
3. 支付安全体系概要
3.1. 支付安全核心关注点

3.2. 支付安全体系大图
图片3.3. 传输安全
图片3.4. 存储安全
3.5. 交易安全
4. 密码学知识入门
4.1. 加解密算法
图片
图片
图片
图片4.2. 加验签算法
图片5. 统一密钥存储及加解密系统设计概要
5.1. 密钥安全理论基础
图片5.2. 设计概要
图片6. 常见工程问题
如何选择加密算法及密钥长度?