In case you missed it, you can watch the webinar recording below, in case you missed it.
For transparency and to preserve the original spirit of the questions, we have not edited any of them. The questions were answered by Andrew McKenna, Principal Consultant, and I, Paolo Basilio, Global Head of Practice.
Question 1: I've seen Covid-19 guidance on the PCI SCC's website relating to specific HSM/crypto PCI standards assessments (P2PE, PCI PIN) being given on-request grace periods. Aside from those, is there any official guidance, on how to deal with the risk (and indeed compliance implications) of having to consciously violate some of the security measures of current (non-Cloud) crypto processes, due to Covid-19.
As a specific example; if a Key Ritual stipulates 3 people, performing different roles in the ritual, is it acceptable for this to be suspended and have one person perform all 3 roles, due to offices/DCs largely being closed/unstaffed?
The PCI SSC and the card brands have not announced any dispensations or allowances for the violation of compliance requirements at this point. As such, the principles of dual control and split knowledge for key operations is still required.
Question 2: I have a question about public key transfers. How and where would the component be encrypted with the public key avoiding capturing the component on multi-purpose computing platforms?
Any key component intended to be transferred between 2 organisations would need to be encrypted within an HSM before transfer. There should be a mechanism that will allow the import/loading of the public key, the generation of a key component within the HSM, as well as encryption of the component under the public key within the HSM. This prevents the component ever existing in clear text outside the HSM.
Question 3: If transferring a key to another team member using the method you suggest, would this not mean 2 copies of the key will exist? How can you control single key existence in this scenario?
Typically, an organisation will have multiple instances of a given key. The key will exist on various HSMs, potentially as a cryptogram in a database table and as key components in custodian (and third party) safes. Similarly, when transferring an encrypted component to a third party using some electronic mechanism, any number of copies can exist of that particular key. As it has been encrypted within an HSM with a key of equal or greater strength, this is allowed according to industry standards. Processes can be implemented to ensure key components are securely destroyed after loading following key transfers
Question 4: Andy described a model in 'An Ideal Future' that makes a lot of sense and certainly something we should strive for. Is the reality *today* still that almost all organisations are relying wholly on secure couriers/sending staff in person to get a key from Organisation A's HSM->Organisation B's HSM? … Or is Andy's proposed 'An Ideal Future' a reality today in some cutting-edge organisations?
Sadly, yes, the reality is still that almost all organisations will still use a courier for sending key components. Depending on the frequency that this needs to be performed, some organisations will establish a common KEK via courier and perform all future key exchanges by encrypting keys under that KEK. But the KEK needs to be changed every so often and thus the manual courier key exchange process continues to be used. Those ‘cutting edge’ organisations would still support this method due to the third parties that only support this method.
Question 5: Should we be worried/ be preparing for when Quantum Cryptography becomes prevelant? I am specifically refering to Quantum Key Distribution, for which equipment is already being sold, and the ability to quickly get the two prime numbers used to generate assymetric encryption keys given the public key (using which 829 bit keys have already been broken).
The short answer is; yes, you should be preparing for Quantum. Consideration should be given to the data that you are encrypting and how long you intend to keep that data. For example, if you have some long term plans for encryption of certain data, you should consider how the introduction of Quantum processing systems could impact that data and potentially look at using Quantum resistant algorithms instead. Note: this is particularly relevant for RSA keys or Elliptic-curve Cryptography. Symmetric encryption using AES is currently considered quantum resistant.
Question 6: When do you think there will be a PTS approved HSM for use with a Cloud P2PE solution?
PTS approval pertains to physical cryptographic devices and therefore these devices can already be used in cloud environments. In terms of P2PE Solutions, there are already some service providers such as Futurex's 'VirtuCrypt' who have a P2PE certified decryption environment listing with a service offered through AWS and Azure.
Question 7: How would an entity work with legacy organisations that still require paper based components to be sent to them?
The components would be sent to the corresponding key custodians. The key custodians would, under dual control, remotely load each component to the HSM, verifying the KCVs of the components and the resultant key. The custodians would then destroy the paper component.
When remotely loading the component, the custodian should be using a validated PTS device with a PIN pad with mutual authentication from the device to the HSM using PKI.
Question 8: If the key custodians are to be working from home. Would they not need some special hardware to handle security at their home office?
Key custodians would potentially require some sort of SCD that could safely store key components or certificates used for authentication for when these custodians connect to HSMs in the cloud. Without such a device, it would be difficult, if not impossible, to satisfy industry standards around HSM authentication control requirements and security around key storage. The custodian would be provided guidance on securely storing the SCD - e.g. in a home safe. This could be verified through teleconference. We would expect these devices to be part of a ‘customer security world’ with dedicated PKI.
Question 9: In highly regulated industries such as banking, how do we evolve our key management process if the regulators are mostly lagging behind considering the pace of technology? Are there discussions to address this gap?
There are a number of forums, interest groups, and task forces mobilised by the PCI SSC to discuss the evolving technologies and how standards focused on cryptography should be adapted to cater for these changes. Participating organisations and Assessor companies have been included in these. Unfortunately, things progress slowly when it comes to regulations and standards, so not much has come from these yet. We believe further initiatives and involvement by our customers and manufacturers may help move things along quicker, hence starting this series of webinars.
Question 10: Many of the banks are asking for FIPS 140 Level 3 HSM devices, is there a particular standard that’s driving this requirement? Also is there any technologies that you recommend for FIPS level 3.
When it comes to cryptographic key management and performing cryptographic operations in banking and payments, the PCI Security Standards Council have defined the PCI PIN Security, 3D Secure Core Security Standards and PCI P2PE standards which require the use of these devices. A device certified against FIPS 140-2 Level 3 (or PTS validated HSM) is the minimum requirement for these standards. There are a number of vendors offering such devices, and advice would really depend on the type of technology you are using and the specific use case.
Question 11: When will the regulators and PCI council be ready to accommodate our new ways of working. More specifically payments in the cloud specifically. How can we do BYOK for Payment HSM's in a compliant (PCI compliant) way.
The PCI SSC review standards in a 3-year cycle so any changes to standards that have a significant impact are likely only to appear after each review cycle. That being said, the new way of working described in the webinar may be achievable even with the standards as they currently are. A lot depends on the implementation and the hardware and software capability.
Note: For PCI DSS, as opposed to P2PE, PIN and 3DS, it is possible to use Key Management Services from the main Cloud Security Providers. Each of those entities have PCI compliance for key management and this includes customer provided keys. PCI DSS does not mandate the use of HSMs for key management or for cryptographic operations.
Question 12: How do you maintain the Dual Access on the Cloud HSM's? With the physical HSM you can ensure that 2 people are present.
Dual-access control on the physical devices will need to be enforced by cloud service providers. Logical dual-access control could be enforced using cryptographic devices loaded with keys that can mutually authenticate to the HSMs in the cloud. There will have to be a mechanism to register each user and corresponding device -- i.e. device with serial number 12345 is registered to user Alice; device with serial number 23456 is registered to user Bob. Cloud Identity and Access Management would also need to include the concept of enforcing dual control based on group membership. i.e. authorization to perform management tasks on resource X requires authentication by at least one person from custodianGroupA and one person from custodianGroupB.
Question 13: Are there any plans for remote access to HSM's in the future of the P2PE standard?
The current P2PE standard does allow remote access using an PTS approved Remote Access Platform (RAP) or a secure cryptographic device (SCD). However, not all HSM manufacturers support remote administration capability for all processes.
Question 14: Will HSMs that store card PINs entered by end- cardholders for payment cards (Sensitive data under PCI-DSS and related supplementary guidance) be allowed to be hosted ‘in the cloud’ not ‘on-premises’?
Yes, Provided all the applicable PIN Security requirements are satisfied by the Cloud Service Provider (CSP). However, this is often where the challenge lies, as an Auditor would need to be able to evaluate this and the CSP would have to be able and willing to demonstrate this.
Question 15: If both Key Custodians need to be logged on to the virtual HSM for dual control, how do you prevent both from seeing a key component generated by one of the Custodians and guarantee that this control is working?
The custodian would need to have an SCD which will establish an encrypted channel to the HSM in the cloud. Something like a PED with a screen that can potentially display and print the key component if needed, but also something that the other custodian will not have access to. No clear text key or key component would ever be displayed on the HSM console.
The ideal situation would be to move away from clear text components all together ensuring all exported keys are encrypted under a KEK of equivalent strength to the target key. Both symmetric and asymmetric mechanisms can be used for this.
We hope the answers to the questions above have helped you learn more about cryptographic architectures. For more information download our Crypto Practice datasheet.
If you have any other questions or would like to have a conversation feel free to email us at email@example.com.