支付域——支付安全
摘要
保障在线交易与支付过程中的信息安全与完整性成为维护支付安全的关键环节。
该体系主要由多层次的安全措施设计构成。
其中包含数据加密技术可防止交易数据在传输过程中遭受窃取或篡改。
这些技术手段通常采用SSL/TLS协议来实现信息传递的安全性。
基于多因素认证(MFA)的应用能够提升系统的安全性。
而权限管理措施则确保只有经过授权的人员或系统能够访问敏感信息。
通过建立完善的安全监控体系及实时告警机制,在线监测潜在的安全威胁,并及时采取应对措施。
最终目标在于保护用户数据不受侵害的同时也有效预防欺诈行为的发生,
从而为企业提供一个安全可靠的在线交易环境。
1. 在线支付安全问题
在线支付面临的安全问题主要包括:
- 账号或密码等敏感信息被盗用。
用户的账号和密码可能被黑客窃取或侵入, 引致个人资金被盗用. 这种情况是用户普遍认为较为严重的安全问题, 多见于密码泄露所造成的损失情况.
- 交易信息被篡改。
对普通用户而言感知度不高。常见的问题包括交易amount受干扰的情况。例如,在某些情况下会出现如realized amount与due amount不符的情况,并且在transact记录中也可能出现recieve account or amount数值异常的情况。
曾遇到过一个真实的案例:某黑客首先入侵并掌握了目标银行系统的管理权限,在掌握了控制权后,在其官方提供的安全通道上向该支付平台账户注入了两万美元资金。随后系统管理员发现异常情况后将原本应扣除的费用降为一美元,并将这一操作提交至相关部门进行处理。然而令人意外的是相关机构仅验证交易状态而不检查金额大小,在完成扣除操作后并未及时发现异常情况。待工作人员察觉时已为时已晚:此时事件已经导致相关机构蒙受了巨大的经济损失

此外,在转账操作中修改收款账户或金额是一个常见的安全漏洞利用方式。当交易请求遭到中间人攻击时系统会自动将原收款账户更新为临时测试账户随后发送给结算机构这一步骤若执行不当就可能导致资金转移至错误的结算账户进而引发损失

- 交易信息被抵赖
在这种情况下相对罕见。举例来说,在一个具体的场景中,支付平台向银行发起200元扣款请求后,并未成功完成扣款操作。然而在交易反馈中显示已成功,并通知了商户发货情况。但银行随后表示,他们返回给支付平台的反馈信息中并未明确记录此次扣款成功。这种做法属于抵赖行为。

- 欺诈交易
包括套现、洗钱等违规交易,以及因为用户信息泄露导致盗刷等。
- 服务不可用攻击
该现象的发生频率非常高。然而其难以被普通公众察觉。对于感兴趣的同学来说,了解DDoS攻击是一个不错的选择。攻击者利用大量恶意流量占据支付系统的资源这会导致合法用户无法正常访问支付平台从而给用户带来交易体验上的困扰以及可能的财务损失。

支付安全领域是一个广泛且重要的领域, 但就实际应用而言, 我们通常只需关注以下几个关键要素即可.

- 敏感信息安全存储。
对个人和商户/渠道的敏感信息进行安全存储。
个人敏感信息主要包括身份证号码、明文支付数据以及密码等内容;而商户或渠道的信息则主要包含其登录或操作密码以及证书密钥等内容。
- 交易信息安全传输。
确保客户端和支付系统服务器之间的、商户系统和支付系统之间的、内部服务器与其他服务器之间的以及支付系统的其他机构间的数据传输安全;这些措施包括采用加密技术等方式来确保数据传输的安全性。
- 交易信息的防篡改与防抵赖。
为了保证交易信息的完整性与真实性,并避免交易信息遭受篡改或受到抵赖。 typical transaction typically involves users, merchants, payment institutions, and banks in four parties, ensuring that all information exchanged remains unaltered and unalibiated.
- 欺诈交易防范。
防范欺诈性交易行为发生,并阻止欺诈交易的发生。涉及套现、洗钱等违法活动。通过检测用户的敏感信息丢失及异常交易行为来维护其资产安全。这一环节主要由支付风控系统来管理。
- 服务可用性。
采取防火墙、入侵检测等技术进行防护以防御DDoS攻击同时保障支付系统的稳定运行与服务可用性
支付安全是一个综合性的系统工程,并非仅靠依靠技术手段就能实现保障;而除此之外,则需要严格制定和完善相关的合规制度和安全措施。这些方面往往会被大多数人忽视。
此图采用简约风格呈现支付安全的全貌,并涵盖支付安全的关键要素。

制度是基础 。
在哪些情况下需要对数据进行加密存储?在这些情况下又应该采用哪些常用的加密算法?最低密钥长度要求是多少位?此外,在哪些情况下还需要实施数字签名与验证过程?这些规定都是明确规定的。一般来说,安全制度可分为行业标准和公司内部的安全规范。其中,行业标准主要由国家相关监管部门制定,并通过法律法规的形式发布;而公司内部的安全规范则是根据企业自身的业务特点与技术能力自主建立并完善。对于小型企业这类规模较小的企业来说,在这方面可能就无需特别制定相关规定了。
技术手段主要围绕四个目标:
- 关键数据的安全管理
- 确保 transaction security
- 保障 transaction 完整性和真实可靠性
- 确保 all transactions are legal and free from fraud
对应的技术手段有:
- 敏感信息安全存储:通过加密技术对敏感信息进行规范存储操作,并严格限定访问权限范围。
- 交易信息安全传输:基于安全套接字层协议(SSL)或传输层安全性协议(TLS)等加密技术手段保障数据传输的安全性。
- 交易的完整性和真实性:应用数字签名技术和身份认证技术实现交易记录的完整性和可追溯管理。
- 防范欺诈交易:借助支付风控系统实现可疑交易行为的快速识别与拦截功能。
- 服务可用性保障:配置流量清洗设备并部署入侵检测系统以应对恶意流量威胁确保服务稳定运行。
2. 常见加密解密技术
加密/解密被视为数据安全的关键要素,在支付安全领域作为其中核心技术的一部分。无论涉及支付平台与银行之间的通信活动、还是处理平台内部敏感信息存储的问题、都离不开这一技术和体系的支持。为了降低理解难度,我会尽力避免深入探讨其背后涉及的复杂数字原理。
在数字通信中,
编码 是将原始信息(明文)通过特定的算法和密码钥匙转化为不可读字符(密文)的过程。例如将明文字串"123"经过特定加密方式转化为"aexyeffidfdfwsd"。
解码 则是编码的反向操作, 通过同样的算法和密码钥匙将可读字符(密文)恢复为原始信息(明文)的过程。例如将编码后的字符串"aexyeffidfdfwsd"解码回"123"。

2.1. 对称加密算法
对称加密基于相同的一组秘密(被称为对称密钥)来进行数据加密与解密操作。这要求在通信前双方必须建立共同的密钥库以供使用。而具有较高的效率是对称加密算法的主要特点之一,在实际应用中表现出色;然而构成其主要的技术难点则是如何有效解决秘钥分发与管理问题。

以下是一些常见的对称加密算法、特点和应用场景:
- AES(Advanced Encryption Standard,高级加密标准):
-
- 特点:安全性优势突出,在金融交易、数据传输以及文件保护等多个领域均有广泛应用,并且支持灵活配置的密钥管理。
-
主要应用于支付行业的对称加密方案
- DES(Data Encryption Standard,数据加密标准):
-
特点:该加密算法具有悠久的历史背景(诞生于20世纪70年代),其采用的密钥长度仅为56位,并且其安全性能相对较低。
-
应用场景:曾被广泛用于数据传输与存储的安全防护工作。然而,在经历了对密钥强度与安全性需求提升的过程中(因为密钥长度仅为56位且安全性能相对较低),该算法已无法满足现代加密需求而逐渐被AES标准取代。
- 3DES(Triple DES,三重数据加密标准):
-
特点:通过对数据采用多重DES算法加密来提高安全性(即加密强度较高),但运算速度较慢。
- 应用场景:曾经作为替代方案被广泛应用于 DES 替代领域中(即曾经被广泛用于替代 DES),因运算速度较慢而逐渐被AES取代。
- RC4(Rivest Cipher 4):
-
特点:快速运行且操作简便。
-
应用场景:曾被应用于保护网络通信以及SSL/TLS协议中的加密;由于存在安全性问题不再建议采用这种方法。
- IDEA(International Data Encryption Algorithm):
-
- 核心优势:运行效率显著提升的同时,在安全性方面也得到了充分保障。
-
应用场景:曾广泛应用于网络通信与文件加密领域;受限于专利保护以及更为先进的算法的发展趋势,则导致其应用范围逐步受限。
AES被广泛认可为现代对称加密算法中安全性最强、应用最广泛的方案 ,在金融领域也得到了广泛应用。密钥长度通常采用256位及以上 。当某些机构要求对所有传输的数据进行加密时,AES 256 加密方案成为首选方案 。
2.2. 非对称加密算法
非对称加密算法采用一对公私钥匙对进行加解密操作。这对钥匙相互关联但各自独立。其中公私钥匙分别用于加密与解密操作的同时,在实际应用中必须严格遵守规定流程——即绝对不允许颠倒两者之间的操作顺序。因为公共钥匙广泛传播以便于用户共享其用途——但由于私人钥匙的秘密性保障了整个通信的安全性——如果误将私人钥匙用于加密或者公共钥匙用于解密——那么就会导致所有人都能轻易破解他人信息——从而失去了原有的安全性保障。这种加密方案具备钥匙分离特性——即公共钥匙可以通过公开渠道分发而私人钥匙则必须严格保密由个人掌握
另外,非对称加密算法也用于签名验签,拿私钥签名,公钥验签(不能反过来)。

以下是一些常见的非对称加密算法、特点和应用场景:
- RSA(Rivest-Shamir-Adleman):
-
- 特点:其安全性能突出且稳定可靠,并被广泛采用。
-
应用场景:主要应用于多个安全领域包括但不限于加密通信、数字签名和密钥交换。
在支付行业中存在大量应用。- DSA(Digital Signature Algorithm):
-
- 主要功能:基于数字签名技术实现快速验证。
-
应用领域:主要应用于身份识别与电子签名等场景;如网站认证中的应用。
- ECC(Elliptic Curve Cryptography):
-
特点:密钥长度较短、安全性较高且加密速度较快。
- 应用场景:适合应用于移动终端以及资源受限的环境;具体应用如智能手机及物联网设备等。
- DH(Diffie-Hellman):
-
主要功能基于密钥交换机制在其过程中完成安全的密钥协商。*
【* 应用场景包括安全通信领域如在该领域的应用中涉及基于该协议的安全性机制的核心环节是其核心环节是基于该协议的安全性机制。*
RSA在支付行业的应用极为普遍 ,而随着技术的发展 ECC 已经成为了移动设备与物联网设备中的首选加密算法,在其高效的性能特点使其在资源受限条件下表现出色。基于安全性考虑 RSA建议采用至少2048比特的密钥长度 ,而对于 ECC则要求采用至少256比特的密钥长度以确保安全性 。
2.3. 数字信封加密算法
数字信封加密算法融合了对称加密、非对称加密、数字签名和验签等多种类型的加密技术,在网络安全领域被广泛应用于保障信息传输的安全性与完整性。传递的数据如同被封装在信封中,在接收端解密后还原为原始明文内容。因此这一过程被形象地称为数字信封加密。
它的原理是采用一种基于对称加密算法的安全通信机制来进行信息传递。具体而言,在发送端首先会对需要传输的数据实施加封处理;随后,在接收端利用发送者所拥有的公有秘钥对该次交换使用的对称秘钥再次加封;发送者则运用自身私有的秘密签名方式为整个信息添加数字签名;最后将经过双重加封处理后的完整信息包安全地发送给接收方。在接收端接收到该信息包后会首先提取并验证数字签名部分;接着利用发送者私有的秘密钥匙来解密用于保护原始数据的那个交换使用的对称秘钥;最后再用这个解出来的对称秘钥来进行原始信息的具体解码工作以获取明文内容。
不过常见的误解是人们认为更常用的是PGP。它其实是基于 Pretty Good Privacy 开发的开源加密工具套件,在保障电子数据安全性和隐私性方面发挥重要作用。该程序 primitives由 Phil Zimmermann在1991年首次提出,并迅速成为一种标准的加密技术手段。早期版本主要用于保护电子邮件通信,在随后的时间里则被广泛应用在文件传输过程中——例如支付平台与银行之间的关键数据交换与处理。PGP推荐使用RSA 2048与AES 256算法来实现对称密钥与数字签名的安全加密以及处理大范围的数据块运算功能。
下图是数字信封加解密算法的完整过程:

如今越来越多的银行已经规定打款文件必须采用PGP加密技术以确保信息安全。由于涉及 sensitive information such as credit card numbers, this security measure is essential.
2.4. 加密算法和密钥长度选择
在现代加密技术领域中,算法的设计与密钥长度的长短直接影响着系统的安全性以及运算效率。其中算法的设计与密钥长度的长短直接影响着系统的安全性以及运算效率。
-
安全性:
-
常见观点指出,在安全性方面非传统型加解密方案优于传统型加解密方法。例如RSA密码系统因其强大的安全性而广受青睐。
-
在同类型加解密方案中,“优胜劣汰”的现象尤为明显。例如AES和DES两种常见的分组密码体制。
-
由于在相同类型的密码系统中, 密钥长度的延长会显著扩大其潜在的空间规模, 进而提高系统的安全性。这使得基于256位密钥的AES系统相比基于128位密钥的版本更加难以被破解。
-
性能:
-
对称加密算法普遍认为运行速度更快。例如AES(对称加密)优于RSA(非对称加密方法)。
-
同一类算法中,当密钥长度增加时,运行速度会下降。由于密钥长度增加量增加了加密操作的复杂度和计算量。
因此,在确定加密算法及密钥长度时需权衡安全性与效能之间的关系一般来说建议采用安全性较高的加密方案并根据实际应用场景和性能需求来决定密钥的长度
当前支付行业推荐的算法和密钥长度如下:
- 算法选择:对称加密算法(如AES)主要用于快速加密与解密大量数据;而非对称加密算法(如RSA)则用于完成密钥交换与数字签名等功能。
- 密钥长度选择:AES推荐采用256位及以上位数;而RSA则建议采用2048位及以上位数。
2.5. 常见加密解密算法推荐
在介绍完对称加密与非对称加密算法后,它们各自拥有不同的应用场景,在支付行业中通常推荐采用以下哪种算法:
- AES:现已被广泛应用于多个领域,并因其计算速度极快而成为处理速度极快,并特别适合于对大规模数据进行加密的首选方案。其推荐密钥长度为256比特及以上。
- RSA:被广泛应用的非对称加密算法,在安全性方面显著优于AES。然而由于其计算速度较慢,在实际应用中常用于处理少量数据信息,并且通常作为身份认证和数字签名的必要手段。其推荐密钥长度为2048比特及以上
在特定的场景中必须同时采用AES与RSA,在这些情况下,例如涉及大数据的加密任务中需运用AES来进行数据加密。 AES密钥经由RSA进行加密后传输,并且利用 RSA 来生成数字签名以确保数据完整性。 这种方法既保障了数据的安全性也提高了数据加密的速度。
特别提醒:必须避免自行设计一种【非公开
特别提醒:...
2.6. 典型应用场景
支付系统作为一项具有极高水平安全性的系统,在其中发挥着至关重要的作用。以下几种典型应用场景往往涉及加解密技术:传输加密、存储加密。
传输加密:保障交易数据在网络传输过程中的安全与完整。

具体的实现通常有两种:
- 通道加密 :例如通过采用HTTPS协议、VPN连接或专用通信线路等方式,确保数据传输全程处于安全状态。
- 报文数据加密 :对关键字段实施独立保护措施,在发送前将敏感信息如信用卡号等先经过专门的安全处理再发送出去。对于整体报文,则建议在生成业务流程文档后进行全方位的安全打包处理,并随后采用统一的安全编码机制完成最终的传递编码工作。
存储加密 :对敏感信息如信用卡号、身份证号码及密码等需经过安全编码存入数据库中;该系统需具备防范数据泄露的能力。

具体的实现通常也会分两种:
- 纯加密方案:原始数据采用纯加密方式处理。这种技术广泛应用于诸如信用卡、身份证明等常规数据的安全保护。
- 在进行双重保护时:在密码管理中,在进行双重保护时(即先加盐值SALT),原始信息会先加上盐值(所谓的盐值),再经过双重层的安全处理和再次加密。
2.7. 登录与支付密码的特殊处理
登录和支付密码的传输和存储都比较特殊,值得单独说一说。
2.7.1. 登录与支付密码传输的特殊处理
登录与支付密码均属于用户输入内容,请问如何防止用户的输入信息被不当获取?同时,请问如何确保数据传输过程中的安全性?

通常会提供安全防护装置来确保数据的安全性;随后会直接读取用户提供的原始信息;其他系统无法非法获取这些数据;随后采用公开密钥来进行加密处理;将加密后的数据发送至服务器端;通过私有密钥对数据进行解密;随后再次转换成可读格式;最终将处理好的内容存储至数据库中,并验证其与数据库中的记录是否一致
2.7.2. 登录与支付密码存储的特殊处理
上一章节里,在提到登录或支付密码时需将加盐值后再进行加密存储的过程中,则为何采用加盐值的做法?其原因是为了增强密码的安全性。

- 抵御彩虹表攻击 。Rainbow table 是一种预先计算好的哈希值集合,在未经处理的情况下(即未加 salt)可能被用来破译用户的无 salt 密码。为了防止这种情况发生,在每个用户的登录信息中添加独特的 salt 值。
- 确保所有使用相同原始密码的账户安全不受影响 。如果没有给每个账户分配独特的 salt 值,在一个 account 被攻破后就有可能同时攻破所有使用相同原始 password 的 accounts。
- 当原始 password 较弱时,“大幅提高攻击者破解其安全性”是一个有效的措施。
在实现时,需要留意加盐策略:
- 随机化生成且独一无二 :每个用户都是通过随机化生成并保持独一无二性的。
- 在密码管理中, 为确保安全性, 在每次更新加密密钥时需将用户的密码与其对应的盐值一并存储.
- 建议设置至少128位的长度以增强安全性.
2.8. PCI技术
如果要存储用户的敏感金融信息(如用户名和卡号),就必须遵守PCI(Payment Card Industry)标准,在该标准定义的范围内工作的组织被称为PCI域。

PCI安全标准(PCI DSS)由 PCI 安全标准委员会(PCI SSC)负责制定与管理的一组安全标准 其主要目的是保障卡片数据的安全性和机密性要求
简而言之,在信息技术领域中将一个完整的资源管理单元划分为一个专门的领域(缩略为PCI域),该区域专门用于处理用户的敏感信息卡密文数据。这些信息既可采用加密存储方案进行保护也可以明文形式进行处理。根据PCI DSS标准规范设置网络安全措施确保所有指定的安全管理功能均得到实施并定期通过相关认证机构的审核程序完成审查工作
特别需要注意的是,在PCI标准下规定所有领域均禁止打印用户敏感信息,并且所有领域不得存储明文形式的用户敏感信息。例如,在卡片技术中(如reads为前6位、writes为后4位),仅当应用属于PCI指定的范围时才可使用卡片中的明文数据。
3. 常见签名验签技术
防止数据被篡改或抵赖也被认为是数据完整性和真实性的验证问题;通常采用数字签名验证方法来解决这一问题。
3.1. 什么是签名与验签
签名验签是数字加密领域的两个基本概念。
签名:发送者将数据通过加密算法和特定密钥转换为唯一的一串密钥序列,并将其作为数字标识符(digital signature)与原始消息一同发送至接收端。
验签 是一种机制,在接收到方基于接收到的数据以及附带的数字签名字段进行验证的过程。该机制用于核实数据完整性,并确保所涉数据确实源自声称发送方。一旦验签成功,则可确信所接收的数据是完好的且合法有效的。
下面是一个极简的签名验签数学公式。
设被签名的数据为m,则其对应的签名串为Σ,在哈希函数H的作用下生成;私钥Pr用于加密过程中的操作,而公钥Pu则参与解密环节;采用加密方案S对数据进行处理,并由解密方案S^完成反向操作以恢复原始内容;最后通过验证是否相等来确认数据完整性。
简化后的数学公式如下:
签名:Σ=S[H(m), Pr]。
验签:f(v)=[H(m) eq S^(Σ, Pu)]。
流程如下:

签名流程:
- 哈希消息:对消息(m)计算其哈希值(H),得到结果h。
- 对哈希值(h)进行加薪处理:使用发送方的私钥参数Pr,在哈希算法中对h进行运算处理并输出数字签名Σ。Σ = S(h, Pr)
把数字签名(Σ)和原始消息(m)一起发给接收方。
验签流程 :
- 对消息进行哈希处理:采用相同的哈希函数H对消息m进行计算得到的哈希值h'满足h'=H(m)。
- 验证数字签名:基于发送方公钥Pu对数字签名\Sigma进行运算计算出数字签名h。
- 对比计算出的数字签名h和直接对原始消息m进行哈希运算得到的结果h'是否一致;当计算出的数字签名与直接对原始消息进行哈希的结果相等时视为验证成功。
当两个哈希值一致时, 验证结果确认为完整的消息m, 并且确实来自声称发送方. 当哈希值不一致时, 验证结果导致验证失败, 可能会使得消息被篡改或签名成为假货.
现实中的算法会极其复杂,并非仅仅局限于RSA和ECDSA这类算法;此外还会包含填充方案、随机数生成以及数据编码等多个方面。
3.2. 支付系统为什么一定要做签名验签
银行如何识别扣款请求的来源以及确保交易数据未被篡改?当商户否认某一笔交易是否发出时,请问如何解决?这一切得益于签名验签技术的作用。
签名验签主要解决3个问题:
- 身份验证:确认支付信息是由真正的发送方发出,防止冒名顶替。
如果无法进行身份认证,则会导致支付宝无法准确识别针对你账户扣款99元的具体来源究竟是来自你楼下小卖部的实际交易行为还是我的冒充扣款操作。
数据完整性检测:确保支付信息在传输过程中的完整性和准确性;每笔交易都具有完整性与准确性。
当发现无法验证交易完整性时
- 防抵赖性:避免任何一方否则曾经进行过的交易,提供法律证据支持。
例如微信支付系统会调用银行账户进行100元的资金扣除,在此之后交易经由银行方确认无误并完成资金转移。商家随后及时向客户发送货物。几天过后,银行业表示这笔交易完成的消息并非其自身返回的结果,因此资金并未被扣除;相反,通过电子签名和验算流程,则可防止这种情况发生

流程:
- 双方可采用多种方式进行密钥交换;其中常见的方式包括线下邮件沟通以及线上自助平台操作。
- 在发起交易时需确保交易报文经由发件人的私钥签名;接收到交易报文后应立即执行验签流程;只有验签无误方可继续开展后续业务。
- 经完成所有业务流程后需在返回信息时附上发件人的私钥签名;对回执文件的验证应在接收到所有信息后立即完成;唯有回执无误方可继续开展下一步骤。
3.3. 常见数字签名算法及推荐算法
常见的数字签名算法包括:
- RSA (Rivest-Shamir-Adleman)通过解决大素数因子分解难题实现了高效的非对称加密技术。
- DSA (Digital Signature Algorithm)采用了离散对数问题作为其基础数学模型。
- ECDSA (Elliptic Curve Digital Signature Algorithm)利用了椭圆曲线上的离散对数难题作为其安全基础。
- EdDSA (Edwards-curve Digital Signature Algorithm)提供了一种高效且安全的数字签名方案,在密码学领域具有重要地位。
目前常用的数字签名算法主要包括RSA与ECDSA两种。 RSA自推出以来就已广泛应用于实际应用中并以其可靠的安全保障著称。相较于RSA ECDSA凭借其较短的密钥长度和更高的安全性优势逐渐崭露头角 并在资源受限环境以及移动设备等场景中展现出显著的应用价值
在支付场景中 RSA 应用最广泛, 其密钥长度被建议设置为 2048 比特。早期多采用 RSA-1024, 但因其实现效率较低, 导致其安全性不足, 已不被推荐采用。
3.4. 防篡改有关的技术
3.4.1. 数字摘要
一种通过生成固定长度的独特字符串来确保数据完整性与一致性的技术被称为数据摘要;该独特字符串也可被称为哈希值或摘要。
这种技术通常用于检测和防止因传输或存储导致的数据篡改与损坏。

存在一个漏洞,在传输过程中(其中)受攻击者的网络截获了100万字的文章及摘要报文,并将其全部替换了 ,服务器无法察觉此类事件的发生。该漏洞将在采用HMAC算法后得到修复。
常见的数据摘要算法包括:
- MD5(Message Digest Algorithm 5): MD5是一种常用的哈希算法,产生128位的哈希值。然而,由于MD5存在严重的安全性缺陷,已经不推荐用于安全性要求较高的场景 。
- SHA-1(Secure Hash Algorithm 1): SHA-1是一种较为安全的哈希算法,产生160位的哈希值。然而,由于SHA-1也存在一些安全性问题,如碰撞攻击,因此在一些安全性要求较高的场景中也不推荐使用。
- SHA-256、SHA-384、SHA-512: 这些是SHA-1的后续版本,分别产生256位、384位和512位的哈希值。它们提供了更高的安全性,通常被用于对安全性要求较高的数据进行摘要。
- RIPEMD(RACE Integrity Primitives Evaluation Message Digest): RIPEMD系列是一组与MD4和MD5相似的哈希算法,产生128位、160位、256位和320位的哈希值。虽然不如SHA系列算法流行,但在某些场景下仍然有用。
- BLAKE、Keccak、Whirlpool等: 这些是一些新兴的哈希算法,设计更加安全和高效,被广泛用于密码学和区块链等领域。
当前在支付行业推荐的摘要算法是SHA256 。
需要注意的是,在实际应用中,默认情况下需要结合使用哈希函数进行计算。然而,在实际应用中不能完全取代。因为哈希函数仅能验证数据完整性,并不能直接证明数据来源的真实性和有效性。尽管如此,在国外一些支付机构出于效率考虑仍然选择使用MD5或SHA256等哈希函数来代替传统的验名验签流程。
3.4.2. HMAC算法
HMAC(Hash-based Message Authentication Code)是一种基于哈希算法(摘要)和密钥的消息认证码算法,常用于确保消息内容的完整性与真实性。
该算法整合了哈希函数与密钥机制,在信息处理过程中通过哈希运算将原始信息转换为固定长度的数据,并随后利用预设密钥对该数据进行加密处理以实现信息的安全性保障。其所得结果即为信息处理后的唯一标识符——认证码值,在通信双方可据此验证信息接收完整性以及数据真实性等问题。

HMAC基于摘要算法与对称加密机制,该方法具有高效的计算性能,因而能在多种应用场景中展现出显著优势.同时, HMAC不仅应用于消息完整性保护以及身份认证过程,还因其高效可靠的特性而在支付领域的相关操作中得到广泛应用.因此, 在支付领域,HMAC常被用于签名与验签过程.
然而需要注意的是,在一定程度上弥补了纯摘要算法的不足。HMAC并非严格意义上的数字签名方案,在其基础架构中基于双方共有的对称密钥机制运行。基于此方法设计出的安全协议体系下存在一定的漏洞:即无法确认消息确实是发送者本人所发出,并且该协议体系还存在一定的安全风险——即可能由某一方仿造生成。
3.4.3. 数字时间戳
数字时间戳是一种用于确定特定事件发生时间和验证其真实性的独特方式(DTS:digital time-stamp service)。这种技术通过将具体事件的时间信息与独特的数学标识符绑定在一起,在指定时间段内保证该事件已存在,并防止任何后期的篡改和伪造行为。
例如,两位科学家各自宣称自己在对方之前完成了某个定理或实验证明。当双方将相关材料通过数字时间戳服务进行了数字时间戳认证时,则能轻松地解决了这一问题。

数字时间戳的应用场景主要用于文件证明、电子邮件传输以及数字证书等领域。这些场景包括但不限于法律文件、合同和知识产权保护方面。它们的作用是能够有效证明该文件在其发布前已存在。
不过在支付系统中,目前比较少使用数字时间戳。
3.4.4. 双重数字签名
作为安全电子交易协议 (Secure Electronic Transaction, 简称SET)中的一个重要概念之一,在这一领域内具有重要意义的就是双重数字签名技术
双重数字签名原理有点绕,我尝试讲清楚:

说明:
- 用户、商户和银行各自向CA机构提交证书申请, 具体内容已在图中有所体现。
- 用户完成选购操作后, 首先会生成订单摘要, 接着生成支付摘要, 将两者合并形成综合摘要, 最终通过私钥进行数字签名, 形成双重签名数据。
- 用户将包含"订单摘要 + 支付摘要 + 双重签名串"的信息发送给商户, 商户则根据自身需求生成对应的部分进行处理。
- 在上述流程中, 商户仅能验证收到用户的综合数据, 而无法获取用户的完整交易细节; 同理, 银行也仅能验证交易的真实性而不了解具体商品详情。
4. 安全身份认证体系
在互联网支付系统中如何验证用户的身份呢?这即属于身份认证技术领域的问题。其中涉及的证书(Certificate)、CA(Certification Authority)以及PKI(Public Key Infrastructure)等均属于较为专业的术语。本部分仅作为初步介绍旨在帮助读者奠定基础知识储备。对于对此领域感兴趣的同学来说,则可以进一步参考相关的专业资料深入了解相关技术细节。基于此基础内容,则每个模块均可深入探讨形成一本书籍内容
4.1. 什么是身份认证
在支付安全领域中,身份认证的主要作用是确认参与支付交易的各方是否为真实标识。简单来说,这过程即是证明每个人都是自己。毫无疑问,在这一功能中扮演核心角色的是保护用户账户的安全性,并且它同时能够有效降低欺诈交易和盗刷行为的风险,并确保所有操作符合相关法律法规的要求。
4.2. 常见的身份认证方法
身份认证通常分为个人身份认证和企业/机构身份认证。
常见的个人身份认证方法包括以下几种:
用户认证方式是最常见的方法之一。
多因素认证(MFA)即要求用户同时使用多种验证方式。
生物特征认证采用生物识别技术进行身份验证。
单点登录(SSO)与Oauth方便用户在一个系统登录即可访问其他资源,并支持像微信或支付宝这样的第三方账号登录功能。
数字证书由CA机构颁发个人数字证书用于身份验证过程中的重要环节。
在涉及企业或机构之间身份认证的情境中,常用的手段是采用数字证书以及双向TLS认证(其中一种别称是客户端证书认证)。有关数字证书的具体内容,请参阅下一节“数字证书”相关内容;而关于双向TLS认证的知识,请查阅下一节“TLS”部分的具体描述。
4.3. 数字证书
数字证书(Digital Certificate)用作网络通信中的身份验证和数据加密的安全技术。该电子文档由一家称为证书颁发机构(Certificate Authority, CA)的可信实体发放,并用于证明该实体的身份及其公钥。
数字证书包含以下主要信息:
- 公钥部分: 中的每个实体都被分配了一个独特的公钥以实现加密与解密通信数据。
- 持有者详情: 中的每个持有者都被记录了完整的人身资料如姓名及电子邮箱地址等细节。
- 颁发机构资料: 中的每个持证人都是经授权后的合法持证人其详细的组织架构与联系方式均被记录下来。
- 有效期范围:每个 都有明确的有效期从开始时间到终止时间之间均为有效状态。
- 认证签名部分:每个 都被赋予了一个由发证方亲自签署以证明其真实性的电子签名此可确保文件的真实性与完整性。
在网络通信过程中,在客户端与服务端之间建立安全连接时(即完成握手过程),服务端将own public key along with certificate details传递给客户端进行身份认证和权威性核实。经核实后确认身份信息真实无误,则可利用自身认证信息对通信双方的数据进行加密并将其 ciphertext safely transmit to the server.
比如你访问以https开头的网站,浏览器就会验证网站服务商的证书。
在支付系统中,某些银行在对接时会要求双向证书认证。
4.4. 数字证书颁发机构CA
我们的信任来自哪里?我们的依据是什么?我们的信心源自何处?这些信任与信心都源于认证机构(CA)提供的权威证明与背书支持。为什么我们会信赖认证机构?这是因为它们通常是由官方机构、行业协会等拥有官方信用背书的主体所设立并管理的。这些主体通过自身的专业能力和可靠记录赢得了广泛的认可与信任。
在数字证书领域中, CA通常被称为Certificate Authority(缩略为CA), 即证书颁发机构.这种机构以其可靠性著称, 并独立第三方的身份来确保其权威性.其主要职责包括发放电子签名, 审核认证流程, 并对数字证书的有效性进行认证.
CA的主要职责包括:
- 发放电子签名: 电子CA机构向合格的企业或个人发放电子签名,该签名可作为法律认可的有效证明.
- 管理与维护: 电子CA机构负责管理和维护已发行的所有电子签名,包括升级、撤销以及查询等功能.
- 认证服务: 电子CA机构提供电子签名认证服务,该服务旨在核查电子签名的真实性与有效性.
- 信任体系构建: 电子CA机构建立并维护了一个完整的信任体系,该体系由基础CA、辅助CA以及终端设备构成.
常见的数字证书颁发机构通常分为两类:一类是全球性机构(如VeriSign、GeoTrust、DigiCert等),另一类是在中国及其他国家和地区设立的具体机构(如中国电子认证服务(CFCA)、中国互联网络信息中心(CNNIC)等)。所有这些机构均严格遵守国际标准和相关行业规范,并向公众提供经过严格审核并可信赖的电子签名与数字认证服务。
在提及方面涉及到了一个信任链 管理机制这一概念具有重要意义。高端认证机构不具备向所有人提供服务的能力但其能够向下属认证机构颁发认证证书然后由下属机构依次向下级终端用户颁发认证证书。验证某认证证书的有效性时则只需依次核实颁发该证书的所有CA机构即可。
4.5. PKI
该系统基于公钥认证体系(Public Key Infrastructure, PKI)理论构建了数字认证证书管理平台。该平台采用标准化流程对公钥进行生成、存储、分发和撤销操作,在保障网络信息安全的同时实现网络通信的安全性和身份验证的有效性。
PKI体系结构包括以下主要组件:
- 数字证书:PKI通过发行认证过的电子文件来确认实体身份,在文件中包含了实体公钥及相关信息如颁发主体、有效期等细节内容。这些电子文件由授权机构(CA)权威发放,并借助于加密技术手段确保其真实可靠程度。
- 授权机构(CA):作为可信第三方服务提供商,在该系统中主要承担电子文件发放与审核把关两大核心职能。该系统采用加密签名技术对电子文件进行真实性认证,并提供撤销服务(CRL或OCSP),以便于终止失效文凭的有效性。
- 注册机构(RA):作为CA的重要协作伙伴,在该系统中主要承担用户的认证流程以及电子文凭申请受理两大核心职能。该系统通常会对提交申请的信息进行详细审核,并将符合条件的内容提交给CA部门进行审核发放工作。
- 电子文凭存储库:作为一个专门用于存储并管理所有已发放的有效电子文件的专业数据库系统,在该系统中主要实现的是文凭信息查询与验证两大功能需求。
- 密钥管理系统:作为一个综合性的安全通信基础设施,在该系统中主要实现的是从密钥对生成到分发以及密钥对回收全过程的安全管控功能需求。
PKI基于数字证书和公钥加密技术手段实现了可靠的安全身份验证、数据加密以及数字签名功能,并构成了保障网络通信安全的关键基础设施。同样构成了支付安全体系的关键基础设施
数字证书、数字认证机构(CA)以及PKI体系等都建立在公私钥理论作为基础 之上。对于对公私钥理论及其相关数字知识感兴趣的同学,请参考相关资料以透彻了解公私钥理论及背后的数字知识。
5. 常见的安全协议
在互联网平台中各类信息经由网络介质传递,在线支付的安全机制与数据传输的防护措施具有密切关联。本文旨在简要阐述若干典型的数据安全保障方案。
大量敏感信息在完成加密后传输确实会增加额外步骤和资源消耗。能不能简化操作流程呢?我们建议在通信过程中先对传输通道进行加密处理,并将机密内容发送给授权方处理。这些技术方案都属于这一类别。
这部分内容大部分都是安全工程师关注的范围,大家只需要了解即可。

5.1. SSL
安全套接层(SSL)是一种保护网络通信安全的技术体系。其最初由网景公司(Netscape)开发,并于1994年首次发布。该协议通过建立安全通道实现数据传输的安全性,并且能够确保信息在传输过程中的机密性和完整性。其通过提供加密通信、数据完整性校验以及身份认证功能等特性,在实际应用中得到了广泛的应用和发展。
SSL协议的主要功能包括:
- 加密通信: 采用多种先进的加密技术保护通信数据的安全性,并确保敏感信息不会在传输过程中泄露。该协议不仅支持常见的对称加密算法(如 DES、3DES 和 AES),还引入了非对称加密方案(如 RSA 和 Diffie-Hellman),从而提供了多层次的安全保障机制。
- 完整性验证: 通过计算消息认证码(MAC)或生成数字签名的方式实现通信数据的完整性校验功能。接收端能够通过对 MAC 或者数字签名进行解密并校验其有效性来确认接收到的信息与预期一致。
- 身份认证: 该协议实现了双方身份的有效认证功能,在服务器端通常会通过颁发电子证书的方式来证明自身的真实身份;而客户端则可以通过核查相关电子证书来进行身份验证工作。此外,在这种架构下还实现了双向的身份认证流程。
- 会话管理: 通过实现会话复用机制减少了握手过程所需的开销,并提升了整体通信效率;这一设计使得资源消耗得到优化的同时还能保证系统的快速响应能力。
SSL 协议最初主要应用于 Web 浏览器与 Web 服务器之间的安全通信,并负责保障网页传输过程中的关键数据。尽管如此,在口语中人们仍习惯性地将 TLS 协议称为 SSL。随着 SSL 协议功能的拓展和完善,则逐渐被更先进的 TLS 协议取代
5.2. TSL
该协议旨在保障网络通信的安全性。该协议基于SSL(Secure Sockets Layer,安全套接层)协议,并对其实现进行了优化和扩展。TLS协议包含数据加密、完整性验证以及身份认证等功能,并通过这些措施确保信息传输过程中的安全性与可靠性。
TLS协议的核心功能与SSL一致,无需赘述.随着网络安全威胁的不断加剧,在这一领域中TLS协议正持续发展并旨在提供更为强大的安全保护机制.
5.3. HTTPS
HTTPS(HyperText Transfer Protocol Secure)是一种安全传输超文本的通信协议。该技术建立在HTTP协议的基础上,并通过集成SSL/TLS协议实现数据加密和身份认证功能,从而以保障网络通信的安全性。
HTTPS协议的工作原理如下:
- 完成安全连接建立的过程中(即客户端向服务器发送连接请求),服务器返回其数字证书以证明自身身份及所使用的公钥信息。客户端接收到该数字证书后会对其进行真实性与有效性的核实。
- 在完成安全连接的过程中(即客户端与 server 之间),双方协商确定将采用哪种加密算法以及相应的密钥长度参数设置以确保通信过程中的数据机密性与安全性。
- 在完成安全连接的过程中(即两端均发起通信请求的一方),发送方利用接收方所拥有的公钥对通信内容进行加解密操作;随后将经过加解密处理的数据传递给接收方。
- 在完成安全连接的过程中(即双方确认身份后),发送方会将生成的数据内容利用接收方提供的私钥对原始消息进行解密;而接收方则可以通过检查发送方提供的数字认证信息来确认其身份信息是否正确无误。
从基本概念来看, HTTP的本质是非加密传输;而HTTPS则建立在SSL/TSL协议之上,并且所有传输的数据经过了加密处理。
除了https协议之外,其他一些传输协议也是建立在SSL/TSL的基础上的。例如文件传输协议FTP属于明文传输方式,在这一过程中信息是以可读形式传递的;而另一个基于SSL/TSL的加密传输方式则是SFTP。
5.4. VPN与专线
VPN(Virtual Private Network)和专线(Dedicated Line)各自被用来建立安全可靠的网络连接的技术,并且尽管如此,在某些方面也存在明显的差异
- VPN:
-
VPN主要基于公共网络(例如互联网)构建虚拟私有网络,并旨在为远程用户提供安全的外部接入。
-
VPN采用加密技术和通道机制对数据进行加薪处理并传递,在保障通信安全性的同时保护用户隐私。
-
VPN系统主要依靠软件型设备(如VPN服务器)、硬件型客户端以及中间节点设备(如VPN路由器)来实现安全连接功能。
- 专线:
-
专线主要是以电信提供商提供的物理连接形式存在,在多个地点间搭建私有专用的网络通道。
-
该专线传输介质可采用光纤、电缆或其他类型的物理传输介质。
-
独立于公共网络体系运行,在确保更高安全性和稳定性的前提下适用高可靠性环境及对延迟要求严格的场景。
简而言之,在VPN方面具有显著的优势在于其灵活性更高且成本更为低廉,在远程访问、移动办公以及跨地域通信等方面表现突出。而专线虽然价格昂贵,在处理对高带宽、低延迟以及高安全性需求的应用时表现更为出色,例如用于数据中心之间的互联或企业内部网络的深度连接。
支付宝、银联以及网联等都是通过专线连接实现的。以往的大支付机构与大型银行之间通常采用专线连接进行直连。较小规模的银行出于成本考量可能会选择使用VPN技术或者直接通过公网通道使用HTTPS协议解决问题。
5.5. SET协议:过于复杂的设计
该类产品最好是尽可能简单的设计方案,在复杂度上要达到最优解的平衡点。否则按照规律很快就会被淘汰掉。例如SET协议就属于这种情况
SET协议由Visa与MasterCard等相关信用卡组织于1996年推出,并获得了IBM、微软等主要企业的支持。其目标是为了提升网络支付的安全性和可靠性。
SET协议的主要目的是应对传统网络中信用卡交易所面临的潜在威胁。在这样的背景下,在线支付系统逐渐成为主流应用领域的同时也带来了新的挑战和机遇
SET协议的主要特点包括:
- 双重身份认证机制:SET 协议规定商家与消费者必须同时提供双重身份认证,并由相关方共同确认其合法性。
- 数据加密过程:SET 协议采用先进的加密算法对所有传输的数据进行严格的安全处理。
- 电子签名技术:SET 协议通过电子签名技术确保交易数据既无遗漏又无篡改。
- 凭证管理规则:SET 协议基于凭证管理规则实施安全证书的应用,并由信任机构定期审核。
如同前面所述,尽管SET协议起步较高,并非仅由Visa和MasterCard两大支付联盟推出亦蒙受IBM、微软等主要企业的支持,在安全性方面表现较为出色。然而由于其复杂性与高昂的成本最终败下阵来并未获得广泛采纳而是在之后出现的其他安全支付方案(包括SSL/TLS协议及3D Secure)中被取代。然而在线支付安全技术的发展历程中仍发挥了重要作用为其后续的安全支付标准制定与实现奠定了基础。
5.6. 网络流量安全:防火墙与入侵检测
网络防护体系与异常行为监测构成了保护计算机网络与系统安全的关键组成要素。它们涵盖了多种技术和工具:防火墙用于阻止未经授权的访问;入侵检测系统(IDS)用于识别并响应潜在的安全威胁;入侵防御系统(IPS)通过多层防御机制减少内部威胁的影响;漏洞扫描器则用于发现并修复潜在的安全漏洞。
这些内容主要归于网络、系统和安全工程师这三个领域的工作职责。以下将简要概述其主要职责。
- Firewall(防火墙): 防火墙设备是一种关键的安全设备,在计算机网络中发挥着重要作用。它通过实时监视网络活动并管理连接到互联网或内部网络的数据流量,在未授权的数据传输中设置安全边界以保护内部资源不受外部威胁的影响。
- IDS(入侵检测系统): IDS是一种先进的网络安全技术,在企业IT环境中被广泛采用以提高网络安全水平。该系统能够实时监测网络中的各种事件,并基于预先设定的安全规则判断异常行为是否构成潜在威胁。
- IPS(入侵防御系统): IPS作为一种强化型安全设备,在现有的网络安全架构中扮演着重要角色。它不仅能够识别并报告潜在的安全威胁信息,并且能够主动分析这些威胁信息并在发现潜在问题时采取相应的防护措施。
- Vulnerability Scanner(漏洞扫描器): 漏洞扫描工具是一种用于评估网络安全风险的关键工具。该工具能够通过自动化的方式快速识别出计算机或网络系统的潜在漏洞,并向管理员提出修复建议以减少系统遭受攻击的可能性。
这些工具主要基于数据层来执行安全防护措施。当数据包处理完成后,会将其整合为业务信息,并可用于加解密及签名验签等操作。
6. 防欺诈交易-支付风控
支付风控主要针对支付系统中存在的风险实施管理和控制措施;其主要目的是通过降低欺诈交易和财务损失的风险来实现管理效果。
该系统的核心要素是其独特的风险控制策略 ,因为掌握某家支付公司风险控制策略的能力意味着能够规避该系统自身所设的风险控制机制从而实施欺诈交易活动。通常情况下研发部门的风险控制系统工程师并不清楚具体的配置细节。
下图是一个极简的风控系统架构图。

尽管风控策略保密性极强,然而有些开放的策略大家了解可能会带来风险。比如这些属于异常行为特征,在较高概率下会被系统识别并监控。
- 你经常在中国进行小额支付,在国外出现了2万元的交易。
- 长期使用IPHONE(风控系统会记录设备详细信息),发生了一次使用Android设备支付2,000元的交易。
- 通常情况下,在十天内购买一件商品时……
在十天内的每一件商品购买中……
实时完成了五十笔支付。
现代的风控系统不仅包含策略,并且还包括多种机器学习算法。总体而言,在这些核心要素——当次支付行为;历史交易数据;配置的规则策略;规则引擎;机器学习等基础上展开运作。
7. 密钥存储与统一安全服务
7.1. 为什么需要统一安全存储密钥
明文数据被加密存储,安全了,那加密明文数据的密钥怎么办?
加密密钥的价值究竟有多大呢?其计算公式如下:
\text{密钥价值} = \text{密文价值}
举个例子来说,在实际应用中,
如果你将价值达10亿元的机密信息进行加密存储,
那么根据上述计算,
对应的加密密钥也应当具有同等级别的安全性和价值。
该系统涉及四个维度:密钥存储与管理、更新与维护、数据备份与恢复过程以及数据归档与删除流程。 要想有效管理这些关键元素,则需要建立一个统一的密钥存储服务系统。

密钥存储 :
安全存储环境:关键数据将被存放在安全存储平台中,并包含数据中心服务器、网络系统以及加密处理设备。
最小权限原则:管理密钥的人越少越好。
该系统采用主密钥 和辅助密钥 的组合加密策略,在常规业务数据层面执行加密与解密操作;同时由主密钥匙 负责处理相关的工作秘钥加密与解密任务
通常建议将主密钥存储在专门的硬件安全模块(HSM)中,并将其称为硬件加密机。该方案具有极强的安全性。然而就而言,在性能、成本及管理方面存在一定的局限性。
工作密钥通常由主密钥经过加密处理后被存储于数据库中,在必要时调用主密钥进行了解密操作完成后将其缓存于内存中随后会对普通业务数据进行进一步的解密处理
密钥更新机制:
- 应定期更新以降低被破解的风险。
- 通过定时机制消除人的主观失误。
- 实施版本管理并配备快速恢复机制。
7.2. 统一密钥平台系统架构

- 采用硬件加密机HSM来制作和存储主密钥。
- 主密钥对工作密钥进行加密处理后会将其存储到数据库中。
- 各应用将通过调用该系统来完成加密解密和签名验签操作,并采取措施防止任何业务应用直接读取这些敏感数据以降低泄题风险。
8. 工程应用中的常见问题
密钥管理不规范 :把密钥加密后保存在数据库,但是加密密钥用的密钥是123456。
算法选择不合适 :大批量数据选择使用速度极慢的非对称的RSA算法。
兼容性算法存在问题 :其中模式与填充方式进行区分是直接关系到加解密效果的关键因素。具体来说,在AES加密方案下通常包括以下几种主要加密模式:电子电码分组编码(ECB)、循环反馈分组编码(CFB)、前向反馈分组编码(OFB)以及 Counter(CTR)等异步分组编码方法;此外还有基于块数据填充的标准如PKCS7/PKCS5规范、零填充等补充机制也需加以区分并合理应用以确保数据完整性与安全性
异想天开地使用自己创造的私有算法 :以为很安全,其实太傻太天真。
管理机制存在缺陷:未制定完整的制度规定,并且执行规定的力度不够,从而使得密钥容易被非法获取。
