CAPITULO IV: MARCO METOLODOLOGICO
4.5. TÉCNICAS DE PROCEDIMIENTO Y ANÁLISIS DE DATOS
3. Validate the existence of more than one root for key distribution management systems. Validate
Root CAs support subordinate CAs.
4. Validate procedures for compromise of a CA includes procedures to revoke subordinate certificates and to
notify affected entities.
5. Validate the CA’s key compromise procedures include the steps that it will cease issuance of certificates
if a compromise is known or suspected, and will perform a damage assessment, including a
documented analysis of how and why the event occurred, and that the CA will determine whether to recall
and reissue all signed certificates with a newly generated signing keys.
6. Validate that CAs have mechanisms to ensure that phony certificates cannot successfully be used.
7. Validate that compromised CAs will notify superior or subordinate CAs, and will ensure that
subordinate CAs and KDHs will have their certificates reissued and distributed to them or will be notified to
apply for new certificates.
8. Validate the minimum cryptographic strength for the CA will be for a Root to have a minimum RSA 2048
bits or equivalent, and subordinate CAs, EPP/PED devices and KDHs to have a minimum RSA 1024
bits or equivalent.
9.
Validate that the expiration of EPP/PED keys are within twelve months after the expected end- of-life of the
device, and that the expiration of KDH keys are every five years, unless another mechanism exists to
prevent the use of a compromised KDH private key.
10. If the key injection platform uses PC based software applications without SCDs for loading keys,
validate the compensating controls outlined in question 13 are implemented.
11. Validate RSA keys that are injected have a key modulus of at least 1024 bits.
12.
Validate that private keys used to sign certificates, certificate status lists, messages or secret key
protection only exist in one of the above outlined approved forms.
Page 57 of 76
Visa KIF Auditor Guide Last Updated: July 2012 ©2012 Visa Public
Key-Injection
Facility Security
Requirement
Testing Procedures
23. . Key variants must be used only in devices that possess the original key. Key variants must not be used at different levels of the key hierarchy e.g., a variant of a key-encipherment key used for key exchange must not be used as a working key or as a master file key for local storage.International/Industry Standard
A secret key used to encrypt a PIN for interchange must never be used for any other cryptographic purpose. A key used to protect the PIN-encrypting key must never be used for any other cryptographic purpose other than key encipherment. Variants of the same key may be used for different purposes. Any variant of the PEK or a key used to protect the PEK must be protected in the same manner—i.e., under the principles of dual control and split knowledge.
An MFK used by host processing systems for encipherment of keys for local storage, and variants of the MFK must not be used external to the (logical) configuration that houses the MFK itself.
Applicability–Question Scope
This applies to all cryptographic keys used for protection of PINs or establishment of those keys. Intent of Question
To ensure there is a separation of keys to minimize misuse (for example so that HSMs use a mechanism that ensures that the commands recognize the purpose of the keys and force the use of separate types of keys).
For example, some types of Hardware Security Modules (Atalla, Racal) do not encrypt other keys under the actual MFK, but under a variant. A variant of a key is the result of combining the key with a known value (typically done by the XOR process) to derive another key. Variants in HSMs are used to segregate cryptograms into groups based on the type of key being encrypted (Key Exchange Key, Working Key). It is a requirement that no variant of a key exist in any device that does not also contain the original key.
Testing Procedures
1. Interview responsible personnel to determine which host MFKs keys exist as variants.
Note: Some HSMs may automatically generate variants or control vectors for specific keys, but it is still up to the entity to
specify exact usage.
2. Review vendor documentation to determine support for key variants.
3. Examine the key creation and injection process to ensure that a unique key is generated and loaded into each PIN entry device and that it is not just a variant of an existing key and that variants of a key are not used as both working keys and key encipherment keys
Page 58 of 76
Visa KIF Auditor Guide Last Updated: July 2012 ©2012 Visa Public
Key-Injection Facility
Security
Requirement
Testing Procedures
24. . Secret and private keys and key components that are no longer used or have been replaced must be securely destroyed.International/Industry Standard
Instances of keys (including components or shares) that are no longer used or that have been replaced by a new key must be destroyed.
Clear-text key components or shares maintained on paper must be burned, pulped or shredded in a crosscut shredder. Keys on other storage-media types and in other permissible forms of a key instance (physically secured, enciphered, or components) must be destroyed following the procedures outlined in ISO-9564-1 or ISO-11568-2. In all cases, a third party—other than the custodian—must observe the destruction and sign an affidavit of destruction.
The procedures for destroying keys that are no longer used or that have been replaced by new keys must be documented.
Key-encipherment key components used for the conveyance of working keys must be destroyed after successful loading and validation as operational.
Applicability–Question Scope This questions applies to:
• All cryptographic keys used at all ATMs, PIN pads, PIN entry devices, Key generation devices and Key loading devices.
• Any keys used internally by the key injection platform.
• All Master Keys or hierarchy keys used by the Hardware Security Modules that are part of the key injection platform.
• All Master Keys or hierarchy keys used by a CA’s Host Security Module.
• All Public and Private key pairs used in the remote key establishment and distribution scheme. • Destruction of the components of secret and private keys.
Intent of Question
To prevent the misuse or mismanagement of the inactive key that could potentially lead to compromise of data and loss of integrity to the active system, and to minimize the damage to the active key hierarchy should the inactive key be compromised.
Page 59 of 76
Visa KIF Auditor Guide Last Updated: July 2012 ©2012
Visa Public