加载中…

加载中...

个人资料
atsec官博
atsec官博 新浪机构认证
  • 博客等级:
  • 博客积分:0
  • 博客访问:38,855
  • 关注人气:12
  • 获赠金笔:0支
  • 赠出金笔:0支
  • 荣誉徽章:
相关博文
推荐博文
正文 字体大小:

8位长度银行卡BIN码在PCI_DSS中的实践

(2021-10-29 16:36:09)
标签:

掩码

截断

bin码

pcidss

atsec

作者:atsec李迪

8位长度银行卡BIN码在PCI_DSS中的实践


8位长度银行卡BIN码在PCI_DSS中的实践
图1:ISO/IEC 7812标准中PAN编码格式的变化

各家卡品牌也在积极推进新标准的实施,目前VISA[2]、Mastercard[3]等卡品牌已经明确给出了迁移时间点,要求其接入机构在2022年4月前完成对8位BIN码的支持。

然而短短两位数字的变化,却可能对现有的卡片支付系统造成极大的影响,本文主要关注于8位BIN码对支付系统的支付卡产业数据安全标准(PCI DSS:Payment Card Industry Data Security Standard)合规可能造成的影响。


2 针对 PCI DSS 的合规考虑
PCI DSS 3.2.1标准中没有直接对BIN码进行要求,而是在要求3.3和要求3.4中,对PAN的掩码和截断做出了详细的规定[4]。其中“掩码(Mask)”指的是对于显示在屏幕上、或者打印在纸质收据或报表中的PAN的部分数字进行打码,不展示完整的PAN;而“截断(Truncate)”指的是对保存在磁盘、数据库或者日志中的PAN,永久性的删除部分数字,使其无法复原回原始的PAN[5]

标准条目如下:

要求3.3:Mask PAN when displayed (the first six and last four digits are the maximum number of digits to be displayed), such that only personnel with a legitimate business need can see more than the first six/last four digits of the PAN(显示 PAN 时予以掩码(最多显示前六位和后四位数字),以便仅限具有正当业务需要的工作人员查看除前六位/后四位以外的PAN)

图2分别展示了屏幕上的掩码PAN以及POS收据上的掩码PAN的例子:
8位长度银行卡BIN码在PCI_DSS中的实践
图 2:屏幕上的掩码PAN(左)以及POS收据上的掩码PAN(右)

要求3.4:Render PAN unreadable anywhere it is stored (including on portable digital media, backup media, and in logs) by using any of the following approaches(通过采取下列任一方法使所有位置(包括便携式数字媒介上、备份媒介上和日志中)存储的 PAN 均不可读)

- One-way hashes based on strong cryptography, (hash must be of the
entire PAN)(基于强效加密法的单向散列函数(散列必须要有完整的 PAN))

- Truncation (hashing cannot be used to replace the truncated segment of PAN)(截断(不能用散列代替 PAN被截断的部分))

 - Index tokens and pads (pads must be securely stored)(索引记号与索引簿(索引簿必须安全地存储))

 - Strong cryptography with associated key-management processes and

Procedures(具有相关密钥管理流程和程序的强效加密法)

Guidance:The intent of truncation is to permanently remove a segment of PAN data so that only a portion (generally not to exceed the first six and last four digits) of the PAN is stored.(指南:截断的目的在于永久删除某个 PAN 数据段,以便仅存储部分(通常不超过前六位和后四位数)的PAN)

图3展示了数据库存储的截断PAN的例子:
8位长度银行卡BIN码在PCI_DSS中的实践
图 3:在数据库中存储的截断PAN

2.1 掩码或截断安全性的考虑
从上述标准原文中我们可以看到,不论是对展示的PAN进行掩码,还是对存储的PAN进行截断,目前的要求都指出最多保留前六位和后四位数。究其原因,前6位数字作为BIN码,通常被用于进行判断发卡机构、交易路由、风控等目的,而后4位数字配合BIN码则可以供持卡人识别出卡片是否为自己所有,或在较大的系统范围内确认PAN的唯一性。中间掩码或截断的6位以上数字,则可以确保至少需要猜测1,000,000次才能获取原始PAN。

因此针对掩码或者截断,作为安全基线的最低要求是,在业务需要或者有明确使用目的的前提下,只有PAN的前六位和后四位可以进行展示或存储。

针对展示PAN的掩码,在明确的业务场景下,部分角色可以通过获得高层书面化的授权形式,展示PAN的全部内容而不用进行掩码。比如风控操作人员,在获得来自管理层的业务授权后,可以通过Web应用页面显示疑似风险交易的PAN;或者报表管理员,在获得来自管理层的授权后,可以在交易报表中打印PAN。

针对存储PAN的截断,在上述安全基线要求之外,考虑到BIN码升级为8位,以及其他业务必要性需要存储更多位PAN,应严格按照表1中的要求执行:

8位长度银行卡BIN码在PCI_DSS中的实践
表 1:可接受的PAN截断格式

针对除存储之外其他用途的截断长度、或者判断BIN码长度的方式,需要直接咨询对应的支付卡品牌。[6]

3 关于PAN截断的其他讨论
3.1 截断是否可以用作划分PCI DSS持卡人数据环境
如果系统在存储、传输、处理过程中只使用了截断之后PAN,且其中被截断的部分从该系统中永久删除并无法复原,那么该系统在可靠的网络隔离措施之下,可以被划分在CDE(持卡人数据环境)之外。

如果该系统被用来提供PAN截断功能,由于其一定会在截断过程中传输并处理原始的PAN,那么该系统将仍被视为CDE的一部分[7]

3.2 多种不同截断措施共存
如果系统中同时存在一个PAN的不同截断版本,例如针对同一个16位PAN:
•    系统1截断后保留前6位后4位
•    系统2截断后保留前4位和中间8到11位
我们可以看到上述系统的两个截断版本可以恢复出前6位、中间8到11位、后4位,和原始PAN只有两位数的差别,显著的增加恢复原始PAN的可能性。

在这种情况下,系统需要通过额外的设计和评估,确保不同的截断版本不能互相关联起来用于恢复原始PAN,或者这些关联性最多能够将截断版本恢复至表1第三列中要求的长度。否则的话该系统必须被纳入到CDE环境中,并对截断版本的PAN进行额外的保护,如使用强加密保护截断之后的PAN等。[7]

3.3 截断和散列共存
部分支付系统在设计时同时使用同一个PAN的截断形式以及散列形式,并将二者储存在相同位置,如同一个数据库的不同表中,甚至于同一张数据表中。在这种情况下,如果攻击者获取到了这个信息,那么它可以通过截断的帮助极大的缩减散列比对的时间,用来恢复原始的PAN。

以常见的16位PAN为例:
•    当系统中只储存前6位后4位截断,那么攻击者没有可比对的对象,无法恢复出原始PAN
•    如果系统中只储存PAN的散列值,攻击者需要执行1016次散列计算才能和散列值进行比对恢复出原始PAN
•    而当系统中同时存储前6位后4位截断,以及对应PAN的散列结果时,攻击者仅需要恢复出被截断的6位数字,再考虑到最后一位是校验位,可以通过Luhn算法排除明显不符合校验的结果,攻击者可能最多需要执行106次散列计算

因此在PCI DSS要求3.4中明确指出:“如果在实体环境中出现同一个PAN的散列版本和截断版本,则须采取额外控制措施,确保散列版本和截断版本不能被相互关联,用于重建原始PAN。”
可行的控制措施例如:


1. 将同一个PAN的散列版本和截断版本分开进行保存,并确保消除两者之间的关联性,使得攻击者无法同时获取散列版本和截断版本的数据,或者即使获取了数据也不能将其关联起来。例如分别存储在两个不同的数据库或者不同的系统,且针对性的设置强效访问控制策略等。

2. 在对PAN进行散列之前填充足够长度的盐值,并确保盐值和散列版本或截断版本的PAN保存在不同地方。如使用HSM生成并保存盐值,而将散列版本和截断版本的数据保存在数据库中。盐值的长度需要满足表1中第三列的要求,也就是通过填充盐值,使得散列之前的PAN恢复其原始长度。盐值的生成尽可能使用随机数据,在可行的情况下针对每一个PAN使用唯一盐值等。

以上补偿控制措施只是参考性信息。如果机构使用了补偿控制措施,需要评估人员(QSA)每年度参考实际的部署和环境情况,并结合系统需要应对的风险进行确定和验证。

各家机构在实施过程中如果有针对PCI DSS标准以及相关安全合规的问题和探讨,可以随时联系atsec。

参考文档:
1.    ISO/IEC 7812-1:2017(en)
2.    Preparing for the Eight-Digit BIN
3.    8-Digit BIN Expansion and PCI Standards
4.    8-digit BINs and PCI DSS: What You Need to Know
5.    What is the difference between masking and truncation?
6.    What are acceptable formats for truncation of primary account numbers?
7.    Are truncated Primary Account Numbers (PAN) required to be protected in accordance with PCI DSS?

0

阅读 评论 收藏 转载 喜欢 打印举报/Report
  • 评论加载中,请稍候...
发评论

    发评论

    以上网友发言只代表其个人观点,不代表新浪网的观点或立场。

      

    新浪BLOG意见反馈留言板 电话:4000520066 提示音后按1键(按当地市话标准计费) 欢迎批评指正

    新浪简介 | About Sina | 广告服务 | 联系我们 | 招聘信息 | 网站律师 | SINA English | 会员注册 | 产品答疑

    新浪公司 版权所有