今天和大家聊聊支付系统安全设计的图解一些核心知识点
。 进入正题前
,支付继续先讲个小故事。系统 多年前国内还没有断直连,安全我当时负责对接银行通道
,设计因为银行对安全看得很重 ,精华部署了很多硬件加密机 ,图解在接口上也要求我们使用硬件加密机。支付当时公司有上千名研发工程师 ,系统但都没有硬件加密机的安全使用经验,我是设计第一个 。当时还需要经常跑到机房去操作硬件加密机 ,精华因为硬件加密机的图解要求设计要求,建站模板很多管理操作是支付要多张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. 常见工程问题
如何选择加密算法及密钥长度?