支付卡行业(PCI)PIN安全要求和测试程序 7个控制目标、33个要求及规范性附录ABC 密钥注入-PCI认证-安全行业基础篇4

本文主要是介绍支付卡行业(PCI)PIN安全要求和测试程序 7个控制目标、33个要求及规范性附录ABC 密钥注入-PCI认证-安全行业基础篇4,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

概述

用于在ATM和POS终端进行在线和离线支付卡交易处理期间,对个人身份号码(PIN)数据进行安全管理、处理和传输。

该标准具体包括 7 个控制目标和 33 个安全要求, 标准的结构分为标准主体部分,标准附录(Normative Annex)A,B,C,以及一个补充附录Appendix A。

7个控制目标,旨在供所有负责支付卡行业参与者指定账户PIN交易处理的收单机构和代理人(如密钥注入设施和证书处理机构)使用,并应与其他适用的行业标准结合使用。
 确定基于PIN的交换交易的最低安全要求。
 概述了保护PIN和加密密钥的最低可接受要求。
 协助所有零售电子支付系统参与者确保持卡人的PIN不会被泄露。

PIN 安全要求 ‒ 技术参考

具体标准:ANSI、EMV、ISO、FIPS、NIST 和 PCI 标准

交易处理操作

控制目标1: pin用于交易管理这些要求是处理使用的设备和方法, 以确保他们保持安全。

要求1: 所有持卡⼈输⼊的 PIN 必须在符合安全加密设备 (SCD) 要求的设备中进⾏处理。 PIN 绝不能以明⽂形式出现在 SCD 之外。

要求2: 持卡人PIN应按照批准的标准进行处理。
a) 所有在线处理的持卡人PIN必须使用经批准的加密技术进行加密和解密,该技术提供符合国际和行业标准的安全级别。实现的任何加密技术都满足或超过使用双倍长度密钥的TDEA的加密强度。
b) 所有使用IC卡技术离线处理的持卡人PIN必须根据EMV支付系统IC卡规范第2册和ISO 9654的要求进行保护。

要求3:对于在线交换交易,PIN必须仅使用ISO 9564–1 PIN块格式0、1、3或4进行加密。格式2必须用于从IC卡读卡器提交到IC卡的PIN。

要求4: PIN码不得存储,除非作为存储转发交易的一部分,并且仅在必要的最短时间内存储。如果记录了交易,则在记录之前,必须屏蔽加密的PIN块或将其从记录中删除。

控制目标2:: 用于PIN加密/解密和相关密钥管理的加密密钥是使用过程创建的,该过程确保不可能预测任何密钥或确定某些密钥比其他密钥更可能

要求5: 所有密钥、关键组件和密钥共享必须使用批准的随机或伪随机过程生成。

要求6: 除非至少两个受信任的个体共谋,否则不可能妥协密钥生成过程。

要求7: 文件化程序必须存在,并可证明用于所有关键生成过程。

控制目标3: 以安全的方式传送或传输密钥。

要求9: 在任何两个地点或组织实体之间传输、传输或移动过程中,任何未加密的秘密或私钥组件或共享必须始终受到保护。

要求10: 用于传输或传递其他加密密钥的所有密钥加密密钥必须至少与传输或传递的任何密钥一样强。

要求11: 文件化程序必须存在,并可证明用于所有关键传输和传输处理。

控制目标4: 密钥加载到hsm和POI PIN-接受设备以安全方式处理

要求12:必须以安全的方式将密钥和私钥输入到硬件(主机)安全模块(HSM)和POI PIN接受设备中。

要求13: 必须保护用于加载密钥和私钥的机制,如终端、外部PIN垫、密钥枪或类似设备和方法,以防止任何类型的监控导致任何组件的未经授权披露。

要求14: 用于密钥加载的所有硬件和访问/验证机制(如密码/验证码)必须在双重控制原则下进行管理。

要求15: 密钥或关键组件的加载必须包含一个验证机制,以确保密钥的真实性,并且可以确定它们没有被篡改、替换或泄露。

要求16: 文件化程序必须存在,并可用于所有关键装载活动(包括审计跟踪)。

控制目标5: 以防止或检测密钥的未授权使用的方式使用密钥

要求17: 两个组织之间的主机系统或同一组织内逻辑上独立的系统之间的每个可识别链接必须使用唯一的秘密密码密钥。

要求18: 必须有程序 来防止或检测未经授权将一个密钥替换为另一个密钥(未经授权的密钥替换和密钥滥用),或在没有合法密钥的情况下操作任何加密设备。

要求19: 加密密钥只能用于其唯一的预期目的,并且不得在生产系统和测试系统之间共享。

要求20: 处理 PIN的交易发起终端(如PED)曾经存在并用于任何功能(如密钥加密或PIN加密)的所有秘密和私人密码密钥必须是该设备唯一的(除非偶然)。

控制目标6: 密钥管理安全

要求21: 用于对PIN加密密钥进行加密或PIN加密的密钥,或用于远程密钥分发实施的私钥,不得存在于SCD之外,除非使用双重控制和分离知识的原则进行加密或安全存储和管理。
要求22: 程序必须存在,并且必须明显使用,以将任何确定被泄露的密钥、其附属密钥(用泄露的密钥加密的密钥)和从泄露的密钥派生的密钥替换为与原始密钥不可行的值。
要求23: 使用可逆密钥计算方法生成的密钥,如密钥变体,只能在拥有原始密钥的SCD中使用。
要求24: 不再使用或已更换的 密钥和私钥以及关键部件必须安全销毁。
要求25: 访问秘密和私人密码密钥以及密钥材料必须:
• 仅限于需要知道的基础上,以便尽可能少的关键保管人能够有效使用;
• 受到保护,使其他人(未同样委托该组件)无法观察或以其他方式获得该组件。
要求26: 钥匙、关键部件或相关材料从仓库中取出或装载到SCD时,必须保存日志。
要求27: 密钥和私钥的备份必须仅用于恢复意外损坏或无法访问的密钥。备份必须仅存在于该密钥允许的存储形式之一中。
要求28: 文件化程序必须存在,并且必须明显用于所有关键管理操作。

控制目标7: 以安全的方式管理用于处理pin和密钥的设备

要求29: PIN处理设备(如POI设备和HSM)必须投入使用,前提是确保在设备部署之前(在加载密钥之前和之后),设备未被替换或受到未经授权的修改或篡改,并且采取了预防措施,以最大限度地减少泄露的威胁一旦部署。
要求30:必须为部署的POI设备提供 物理和逻辑保护
要求31: 必须制定并实施程序,以保护任何SCD,并确保销毁此类设备中的任何加密密钥或密钥材料。
要求32: 任何能够加密密钥并产生该密钥的密码(即HSM或密钥注入/加载设备)的SCD都必须受到保护,以防未经授权使用来加密已知密钥或已知密钥组件。这种保护采取以下一种或多种形式:
要求33: 文件化程序必须存在并可证明使用,以确保投入使用、初始化、部署、使用和退役的PIN处理设备(例如,支持PIN和HSM的POI设备)的安全性和完整性。

规范性附录 A ‒ 使⽤⾮对称密钥的对称密钥分发

远程密钥分发方案应仅用于初始密钥加载,即建立TDEA密钥层次结构,如终端主密钥。标准对称密钥交换机制应用于后续TMK、PEK或其他对称密钥交换,除非设备由于现有TMK的意外丢失而需要新的密钥初始化。涵盖的两个不同领域。

A1–使用非对称技术操作的远程密钥分发

特点:这些要求适用于使用非对称技术实现远程密钥分发的所有实体,该非对称技术用于将收单方密钥分发到交易发起设备(POI),以与PIN加密结合使用,无论收单方钥匙的实际分发是从交易处理主机发布还是由供应商直接分发。
• ANSI TR 34提出了一种符合这些要求的方法。TR 34描述了一种用于通过不受控制的信道将对称密钥从一个SCD传输到另一SCD的方法。TR 34的典型示例用法将是将单个初始对称传输密钥从密钥分发主机加载到PED群体。TR 34利用非对称密码学来保护该密钥传输,这意味着密钥分发主机和密钥接收设备(例如PED)都必须具有证书、公钥和私钥形式的适当证书,并且必须与证书颁发机构(CA)具有共同关系。CA可以是独立于KRD供应商和KDH的一方,或者KRD供应商可以是CA。

A2–认证和注册机构操作

特点:这些要求仅适用于经营认证和/或注册机构的实体。
•	证书颁发机构的要求适用于所有签署公钥的实体(收单机构、制造商和其他第三方),这些公钥将用于远程分发加密密钥,无论是在基于X.509证书的方案还是其他设计中,以允许对这些签署的公钥进行所需的身份验证。就这些要求而言,证书是任何包含公钥的数字签名值,其中“数字签名”一词是指通过使用私钥对数据块进行加密处理来加强数据块的完整性和真实性的加密方法。CA要求仅适用于允许向多个系统分发和使用此类签名公钥的方法,因此不适用于对密钥应用对称密码进行身份验证(例如通过使用MAC)的系统。
•	证书颁发机构的要求不适用于签署自己密钥的设备,也不适用于密钥加载不是远程执行的密钥加载系统,并且通过另一种方法提供身份验证,例如正确实现的双重控制和密钥加载设备,即使这些系统涉及证书的使用。
对相关的控制目标还有其它要求。略。

规范性附录 B ‒ 钥匙注⼊设施

包含适用于密钥注入设施的特定要求,用于加载收单方密钥。

  1. 使用非对称技术向事务发起设备远程分发对称密钥。这些标准与所实施的实际密钥分发方法的特点有关。如果密钥加载不是远程执行的,并且通过另一种方法提供身份验证,例如正确实现的双重控制和密钥加载设备,即使这些系统涉及证书的使用,附录A也不适用。“远程”是指钥匙加载设备和POI设备既不在同一位置,也不通过电缆等直接机制连接。

规范性附录C-最小和等效密钥大小和强度批准的算法

与本文件要求相关的批准算法基于NIST SP 800-57第1部分第4版第4节中列出的批准算法;
在这里插入图片描述

33个要求:

要求1: 所有持卡人输入的PIN必须在符合安全加密设备(SCD)要求的设备中进行处理。PIN绝对不能出现在SCD的透明外部。
要求2: 持卡人PIN应按照批准的标准进行处理。
要求3: 对于在线交换交易,PIN必须仅使用ISO 9564–1 PIN块格式0、1、3或4进行加密。格式2必须用于从IC卡读卡器提交到IC卡的PIN。
要求4: PIN码不得存储,除非作为存储转发交易的一部分,并且仅在必要的最短时间内存储。如果记录了交易,则在记录之前,必须屏蔽加密的PIN块或将其从记录中删除。
要求5: 所有密钥、关键组件和密钥共享必须使用批准的随机或伪随机过程生成。
要求6: 如果没有至少两个受信任的个人之间的勾结,密钥生成过程就不可能 妥协。
要求7: 文件化程序必须存在,并可证明用于所有关键生成过程。
要求8: 密钥或私钥应通过以下方式传输:
要求9: 在任何两个地点或组织实体之间传输、传输或移动过程中,任何未加密的秘密或私钥组件或共享必须始终受到保护。
要求10: 用于传输或传递其他加密密钥的所有密钥加密密钥必须至少与传输或传递的任何密钥一样强。
要求11: 文件化程序必须存在,并可证明用于所有关键传输和传输处理。
要求12: 必须以安全的方式将密钥和私钥输入到硬件(主机)安全模块(HSM)和POI PIN接受设备中。
要求13: 必须保护用于加载密钥和私钥的机制,如终端、外部PIN垫、密钥枪或类似设备和方法,以防止任何类型的监控导致任何组件的未经授权披露。
要求14: 用于密钥加载的所有硬件和访问/验证机制(如密码/验证码)必须在双重控制原则下进行管理。
要求15: 密钥或关键组件的加载必须包含一个验证机制,以确保密钥的真实性,并且可以确定它们没有被篡改、替换或泄露。
要求16: 文件化程序必须存在,并可用于所有关键装载活动(包括审计跟踪)。
要求17: 两个组织之间的主机系统或同一组织内逻辑上独立的系统之间的每个可识别链接必须使用唯一的秘密密码密钥。
要求18: 必须有程序 来防止或检测未经授权将一个密钥替换为另一个密钥(未经授权的密钥替换和密钥滥用),或在没有合法密钥的情况下操作任何加密设备。
要求19: 加密密钥只能用于其唯一的预期目的,并且不得在生产系统和测试系统之间共享。
要求20: 处理 PIN的交易发起终端(如PED)曾经存在并用于任何功能(如密钥加密或PIN加密)的所有秘密和私人密码密钥必须是该设备唯一的(除非偶然)。
要求21: 用于对PIN加密密钥进行加密或PIN加密的密钥,或用于远程密钥分发实施的私钥,不得存在于SCD之外,除非使用双重控制和分离知识的原则进行加密或安全存储和管理。
要求22: 程序必须存在,并且必须明显使用,以将任何确定被泄露的密钥、其附属密钥(用泄露的密钥加密的密钥)和从泄露的密钥派生的密钥替换为与原始密钥不可行的值。
要求23: 使用可逆密钥计算方法生成的密钥,如密钥变体,只能在拥有原始密钥的SCD中使用。
要求24: 不再使用或已更换的 密钥和私钥以及关键部件必须安全销毁。
要求25: 访问秘密和私人密码密钥以及密钥材料必须: • 仅限于需要知道的基础上,以便尽可能少的关键保管人能够有效使用;
• 受到保护,使其他人(未同样委托该组件)无法观察或以其他方式获得该组件。
要求26: 钥匙、关键部件或相关材料从仓库中取出或装载到SCD时,必须保存日志。
要求27: 密钥和私钥的备份必须仅用于恢复意外损坏或无法访问的密钥。备份必须仅存在于该密钥允许的存储形式之一中。
要求28: 文件化程序必须存在,并且必须明显用于所有关键管理操作。
要求29: PIN处理设备(如POI设备和HSM)必须投入使用,前提是确保在设备部署之前(在加载密钥之前和之后),设备未被替换或受到未经授权的修改或篡改,并且采取了预防措施,以最大限度地减少泄露的威胁一旦部署。
要求30:必须为部署的POI设备提供 物理和逻辑保护
要求31: 必须制定并实施程序,以保护任何SCD,并确保销毁此类设备中的任何加密密钥或密钥材料。
要求32: 任何能够加密密钥并产生该密钥的密码(即HSM或密钥注入/加载设备)的SCD都必须受到保护,以防未经授权使用来加密已知密钥或已知密钥组件。这种保护采取以下一种或多种形式:
要求33: 文件化程序必须存在并可证明使用,以确保投入使用、初始化、部署、使用和退役的PIN处理设备(例如,支持PIN和HSM的POI设备)的安全性和完整性。

这篇关于支付卡行业(PCI)PIN安全要求和测试程序 7个控制目标、33个要求及规范性附录ABC 密钥注入-PCI认证-安全行业基础篇4的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/356797

相关文章

springboot security使用jwt认证方式

《springbootsecurity使用jwt认证方式》:本文主要介绍springbootsecurity使用jwt认证方式,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地... 目录前言代码示例依赖定义mapper定义用户信息的实体beansecurity相关的类提供登录接口测试提供一

C#基础之委托详解(Delegate)

《C#基础之委托详解(Delegate)》:本文主要介绍C#基础之委托(Delegate),具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教... 目录1. 委托定义2. 委托实例化3. 多播委托(Multicast Delegates)4. 委托的用途事件处理回调函数LINQ

最新Spring Security实战教程之Spring Security安全框架指南

《最新SpringSecurity实战教程之SpringSecurity安全框架指南》SpringSecurity是Spring生态系统中的核心组件,提供认证、授权和防护机制,以保护应用免受各种安... 目录前言什么是Spring Security?同类框架对比Spring Security典型应用场景传统

SpringSecurity 认证、注销、权限控制功能(注销、记住密码、自定义登入页)

《SpringSecurity认证、注销、权限控制功能(注销、记住密码、自定义登入页)》SpringSecurity是一个强大的Java框架,用于保护应用程序的安全性,它提供了一套全面的安全解决方案... 目录简介认识Spring Security“认证”(Authentication)“授权” (Auth

一文详解kafka开启kerberos认证的完整步骤

《一文详解kafka开启kerberos认证的完整步骤》这篇文章主要为大家详细介绍了kafka开启kerberos认证的完整步骤,文中的示例代码讲解详细,感兴趣的小伙伴可以跟随小编一起学习一下... 目录一、kerberos安装部署二、准备机器三、Kerberos Server 安装1、配置krb5.con

SpringBoot项目注入 traceId 追踪整个请求的日志链路(过程详解)

《SpringBoot项目注入traceId追踪整个请求的日志链路(过程详解)》本文介绍了如何在单体SpringBoot项目中通过手动实现过滤器或拦截器来注入traceId,以追踪整个请求的日志链... SpringBoot项目注入 traceId 来追踪整个请求的日志链路,有了 traceId, 我们在排

0基础租个硬件玩deepseek,蓝耘元生代智算云|本地部署DeepSeek R1模型的操作流程

《0基础租个硬件玩deepseek,蓝耘元生代智算云|本地部署DeepSeekR1模型的操作流程》DeepSeekR1模型凭借其强大的自然语言处理能力,在未来具有广阔的应用前景,有望在多个领域发... 目录0基础租个硬件玩deepseek,蓝耘元生代智算云|本地部署DeepSeek R1模型,3步搞定一个应

java如何通过Kerberos认证方式连接hive

《java如何通过Kerberos认证方式连接hive》该文主要介绍了如何在数据源管理功能中适配不同数据源(如MySQL、PostgreSQL和Hive),特别是如何在SpringBoot3框架下通过... 目录Java实现Kerberos认证主要方法依赖示例续期连接hive遇到的问题分析解决方式扩展思考总

浅析Rust多线程中如何安全的使用变量

《浅析Rust多线程中如何安全的使用变量》这篇文章主要为大家详细介绍了Rust如何在线程的闭包中安全的使用变量,包括共享变量和修改变量,文中的示例代码讲解详细,有需要的小伙伴可以参考下... 目录1. 向线程传递变量2. 多线程共享变量引用3. 多线程中修改变量4. 总结在Rust语言中,一个既引人入胜又可

SQL注入漏洞扫描之sqlmap详解

《SQL注入漏洞扫描之sqlmap详解》SQLMap是一款自动执行SQL注入的审计工具,支持多种SQL注入技术,包括布尔型盲注、时间型盲注、报错型注入、联合查询注入和堆叠查询注入... 目录what支持类型how---less-1为例1.检测网站是否存在sql注入漏洞的注入点2.列举可用数据库3.列举数据库