支付卡行业(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

相关文章

从基础到高级详解Go语言中错误处理的实践指南

《从基础到高级详解Go语言中错误处理的实践指南》Go语言采用了一种独特而明确的错误处理哲学,与其他主流编程语言形成鲜明对比,本文将为大家详细介绍Go语言中错误处理详细方法,希望对大家有所帮助... 目录1 Go 错误处理哲学与核心机制1.1 错误接口设计1.2 错误与异常的区别2 错误创建与检查2.1 基础

springboot依靠security实现digest认证的实践

《springboot依靠security实现digest认证的实践》HTTP摘要认证通过加密参数(如nonce、response)验证身份,避免明文传输,但存在密码存储风险,相比基本认证更安全,却因... 目录概述参数Demopom.XML依赖Digest1Application.JavaMyPasswo

Spring的基础事务注解@Transactional作用解读

《Spring的基础事务注解@Transactional作用解读》文章介绍了Spring框架中的事务管理,核心注解@Transactional用于声明事务,支持传播机制、隔离级别等配置,结合@Tran... 目录一、事务管理基础1.1 Spring事务的核心注解1.2 注解属性详解1.3 实现原理二、事务事

Java JUC并发集合详解之线程安全容器完全攻略

《JavaJUC并发集合详解之线程安全容器完全攻略》Java通过java.util.concurrent(JUC)包提供了一整套线程安全的并发容器,它们不仅是简单的同步包装,更是基于精妙并发算法构建... 目录一、为什么需要JUC并发集合?二、核心并发集合分类与详解三、选型指南:如何选择合适的并发容器?在多

Java中最全最基础的IO流概述和简介案例分析

《Java中最全最基础的IO流概述和简介案例分析》JavaIO流用于程序与外部设备的数据交互,分为字节流(InputStream/OutputStream)和字符流(Reader/Writer),处理... 目录IO流简介IO是什么应用场景IO流的分类流的超类类型字节文件流应用简介核心API文件输出流应用文

SpringBoot中@Value注入静态变量方式

《SpringBoot中@Value注入静态变量方式》SpringBoot中静态变量无法直接用@Value注入,需通过setter方法,@Value(${})从属性文件获取值,@Value(#{})用... 目录项目场景解决方案注解说明1、@Value("${}")使用示例2、@Value("#{}"php

深入浅出Spring中的@Autowired自动注入的工作原理及实践应用

《深入浅出Spring中的@Autowired自动注入的工作原理及实践应用》在Spring框架的学习旅程中,@Autowired无疑是一个高频出现却又让初学者头疼的注解,它看似简单,却蕴含着Sprin... 目录深入浅出Spring中的@Autowired:自动注入的奥秘什么是依赖注入?@Autowired

Spring 依赖注入与循环依赖总结

《Spring依赖注入与循环依赖总结》这篇文章给大家介绍Spring依赖注入与循环依赖总结篇,本文通过实例代码给大家介绍的非常详细,对大家的学习或工作具有一定的参考借鉴价值,需要的朋友参考下吧... 目录1. Spring 三级缓存解决循环依赖1. 创建UserService原始对象2. 将原始对象包装成工

从基础到高级详解Python数值格式化输出的完全指南

《从基础到高级详解Python数值格式化输出的完全指南》在数据分析、金融计算和科学报告领域,数值格式化是提升可读性和专业性的关键技术,本文将深入解析Python中数值格式化输出的相关方法,感兴趣的小伙... 目录引言:数值格式化的核心价值一、基础格式化方法1.1 三种核心格式化方式对比1.2 基础格式化示例

redis-sentinel基础概念及部署流程

《redis-sentinel基础概念及部署流程》RedisSentinel是Redis的高可用解决方案,通过监控主从节点、自动故障转移、通知机制及配置提供,实现集群故障恢复与服务持续可用,核心组件包... 目录一. 引言二. 核心功能三. 核心组件四. 故障转移流程五. 服务部署六. sentinel部署