Microsoft Word C039666e doc Reference number ISO 11568 4 2007(E) © ISO 2007 INTERNATIONAL STANDARD ISO 11568 4 Second edition 2007 07 01 Banking — Key management (retail) — Part 4 Asymmetric cryptosys[.]
General
Asymmetric cryptosystems include asymmetric ciphers, digital signature systems and key agreement systems
In financial services systems, asymmetric cryptosystems play a crucial role in key management, primarily for handling symmetric cipher keys and managing the keys of the cryptosystems themselves These applications ensure secure generation, distribution, and storage of cryptographic keys Clause 5 details the techniques used to support key management and certificate management services, enhancing overall system security Additionally, Clause 6 explains how these methods address security and implementation requirements throughout the entire key pair lifecycle, ensuring robust management from key creation to retirement.
Establishment and storage of symmetric keys
Symmetric cipher keys can be established through key transport or key agreement methods, as detailed in ISO/IEC 11770-3 These mechanisms must guarantee the authenticity of the communicating parties to ensure secure communication.
Symmetric keys shall be stored as described in ISO 11568-2.
Storage and distribution of asymmetric public keys
Public keys from an asymmetric key pair must be distributed and stored securely by authorized users for encrypting data, verifying signatures, or facilitating key exchange While the public key does not require confidentiality, the distribution and storage processes must preserve its authenticity and integrity, as outlined in section 5.6.1, to ensure reliable and secure cryptographic operations.
Mechanisms for the distribution of asymmetric public keys are described in ISO/IEC 11770-3.
Storage and transfer of asymmetric private keys
The private key of an asymmetric key pair does not always need to be shared with others; it can be securely stored solely within the cryptographic device that generated it This approach enhances security by minimizing the risk of the private key being compromised during transmission or storage Using a secure cryptographic device (SCD) to protect private keys is a best practice in safeguarding sensitive cryptographic operations.
To protect data output from the SCD intended for transfer or backup purposes, it must be secured against compromise using at least one of the specified techniques, ensuring data integrity and security throughout its lifecycle.
⎯ encipherment with another cryptographic key as defined in 5.2;
⎯ if non-encrypted and outside an SCD, as key shares using an acceptable key segmentation algorithm
When outputting into another SCD—whether it is the target device or a secure key transfer device—the transfer should only occur within a secure environment if the communication path is not fully protected Ensuring secure communication during key transfer is essential for maintaining the integrity and confidentiality of sensitive data.
The integrity of the private key shall be ensured using one of the techniques defined in 5.6.2
5 Techniques for the provision of key management services
Introduction
This clause describes the techniques that may be used, individually or in combination, to provide the key management services introduced in ISO 11568-1 Some techniques provide multiple key management services
Asymmetric key pairs should not be used for multiple purposes; however, if they are used for both digital signatures and encipherment, specialized key separation techniques must be employed These techniques ensure the system remains secure against attacks that exploit transformations using the key pair Implementing these key separation techniques within a Secure Cryptographic Device (SCD) is essential, and the device's functionality must guarantee that each technique effectively achieves its specific purpose, maintaining overall cryptographic security.
The characteristics and management requirements for an SCD are defined in ISO 13491-1.
Key encipherment
Key encipherment is a security technique in which one key is encrypted using another key, ensuring its confidentiality The encrypted key can then be stored securely outside of a Secure Cryptographic Device (SCD) The key used to perform this process is known as a Key Encipherment Key (KEK), playing a critical role in protecting cryptographic keys during storage and transmission This method enhances the security of key management by safeguarding keys through robust encryption techniques.
ISO 11568-4:2007(E) © ISO 2007 – All rights reserved 5
This article explores two key encipherment scenarios involving asymmetric keys and cryptographic ciphers First, it discusses the process of encrypting a symmetric key with an asymmetric cipher, enhancing security during key exchange Second, it examines the encryption of an asymmetric key itself using a symmetric cipher, which can optimize performance and streamline secure communications Understanding these two distinct methods is essential for implementing robust cryptographic protocols and ensuring data confidentiality.
5.2.2 Encipherment of a symmetric key using an asymmetric cipher
Encrypting a symmetric key with an asymmetric public key enables secure key distribution over insecure channels, ensuring confidentiality The encrypted key can serve as a working key or function as a Key Encryption Key (KEK), enhancing security protocols This process facilitates the creation of mixed key hierarchies, as outlined in ISO 11568-2, integrating both symmetric and asymmetric keys for robust cryptographic systems.
The symmetric key must be formatted into a data block suitable for the encryption process, ensuring proper alignment with the operation requirements Since asymmetric cipher block sizes are generally larger than symmetric key sizes, multiple symmetric keys can often be included within a single data block for encryption efficiency Additionally, the data block should contain formatting information, random padding, and redundancy characters to enhance security and ensure proper decryption, as specified in ISO/IEC 18033-2.
5.2.3 Encipherment of an asymmetric key using a symmetric cipher
Asymmetric keys may be enciphered using a symmetric cipher
Asymmetric cryptosystems typically utilize larger keys that exceed the block size of symmetric ciphers, requiring the key to be split into multiple data blocks for encryption To ensure secure and effective encryption of these larger keys, cipher block chaining (CBC) mode, as specified in ISO/IEC 10116, or an equivalent operation, should be used for encipherment This approach guarantees proper handling of large asymmetric keys and enhances overall cryptographic security.
When evaluating the strength of cryptographic algorithms, it is essential to consider known attack methods An algorithm’s security level is typically measured in bits, where an s-bit strength indicates that the best-known attack requires approximately 2^(s−1) times the effort of performing a single encryption and comparison The parameter T represents the time needed to encrypt a plaintext and verify it against the ciphertext, forming the basis for estimating an algorithm’s resistance to cryptanalytic attacks.
For example in ISO/IEC 10116, an attack against 112-bit TDEA is presented that requires O(k) space and
The security of the cryptographic system is influenced by the number of known plaintext-ciphertext pairs, with the complexity estimated at 2^{120−log k} operations, where k represents these pairs As highlighted in reference [11], possessing 2^40 known plaintext-ciphertext pairs effectively reduces the strength of a two-key 112-bit TDEA encryption to an equivalent of 80 bits Recommended key sizes at the time of publication are summarized in Table 1, emphasizing the importance of considering ongoing advancements in cryptanalysis, factorization techniques, and computing power when evaluating these security parameters.
In the current retail banking environment, 112-bit TDEA is considered to provide adequate security for protecting 168-bit TDEA keys, as it is designed to prevent the collection of enough plaintext/ciphertext pairs that could significantly weaken the underlying cipher.
Table 1 — Encryption algorithms — Equivalent strengths
Effective strength Symmetric RSA Elliptic curve
80 112-bit TDEA (with 2 40 known pairs) 1 024 160
112-bit TDEA (with no known pairs)
Public key certification
Key certification, according to ISO 15782-1, is a vital technique for verifying the authenticity of a public key through digital signatures It enhances security by creating a digital signature for the key and related validation data, ensuring trustworthiness Before using a public key, recipients must verify its authenticity by checking the digital signature, thereby preventing impersonation and ensuring secure communications This process is essential for establishing secure digital identities and maintaining data integrity in cryptographic systems.
Owner's credentials consist of the public key and related validity data, including owner identification, key identification, and expiry date A key certificate, issued by a trusted Certification Authority, verifies the owner's credentials and is created by signing these credentials with the CA's private key This process ensures the authenticity and integrity of the key certificate, establishing trust between parties.
An independent communication method should be employed to verify the accuracy and authorization of the key and its owner This verification process may involve confirming information through a separate channel from the one used to initially gather the data, ensuring secure and reliable authentication.
During distribution to authorized recipients, or during storage in a key database, the authenticity of the public key shall be ensured.
Key separation techniques
To ensure that stored keys are only used for their intended purpose, key separation must be implemented through methods such as physical segregation of keys based on their purpose, storing keys encrypted under a dedicated key encipherment key for specific key types, or modifying or appending information—such as key tagging—to a key before its encryption and storage, thereby maintaining proper key management and security.
Key tagging is a crucial technique for identifying and categorizing keys outside secure cryptographic environments, enabling precise control over their intended uses This method securely binds the key's value with its specific privileges, ensuring that any modifications are easily detectable By implementing key tagging, organizations enhance their key management security, reducing the risk of unauthorized access or manipulation Proper key tagging practices are essential for maintaining the integrity and security of cryptographic systems.
Explicit key tagging is essential for defining access privileges by utilizing a dedicated field that specifies the limits of a key's permissions This field is securely linked with the key value, ensuring that any modifications are detectable and preventing unauthorized changes Implementing explicit key tagging enhances security by clearly delineating user and system access rights, making it a vital component in access control mechanisms Properly managing this tagging process ensures the integrity of privilege boundaries and safeguards sensitive information.
Implicit key tagging enhances security by not relying on explicit privilege fields; instead, it determines access rights based on system characteristics such as the key's position within records or its associated functions This approach simplifies privilege management by leveraging inherent system properties to define key rights and limitations Implementing implicit key tagging can improve security and streamline key management processes in various systems.
Key verification
Key verification is a technique that allows the value of a key to be checked and verified, without exposing any secret values and without using public key certificates The technique utilizes a key verification code (KVC) that is cryptographically related to the key via a collision-resistant one-way function For example, the reference KVC may be computed as the hash of the public or private key and associated data using an algorithm defined in ISO/IEC 10118
ISO 11568-4:2007(E) © ISO 2007 – All rights reserved 7
After the initial generation of the Key Verification Code (KVC), the key can be re-input into the one-way function at any time If the resulting KVC matches the original, it indicates that the key's value remains unchanged This process helps verify the integrity and consistency of the key over time.
Key verification is essential for confirming that a cryptographic key has been correctly entered into a device, accurately received over a secure communication channel, and remains unaltered or substituted This process ensures the integrity and authenticity of cryptographic keys, which are vital for secure communications and data protection Proper key verification helps prevent unauthorized access and maintains the overall security of cryptographic systems.
Public keys can be securely distributed through non-secure channels as long as the Key Verification Code (KVC) is transmitted via an integrity-assured channel Before using a public key, users must verify its authenticity by recomputing the KVC and comparing it with the reference KVC to ensure it has not been tampered with This process guarantees the integrity and authenticity of the public key, maintaining secure communication.
Modifying or substituting the reference KVC and public key (including associated data) in a way that the recomputed KVC of the altered public key matches the reference KVC is infeasible This security feature ensures the integrity and authenticity of cryptographic keys, preventing unauthorized changes Such robustness can be maintained through mechanisms that make it impossible for the recomputed KVC to equal the modified or substituted reference KVC, thereby safeguarding the key validation process and ensuring system security.
⎯ by ensuring the integrity of the KVC (see ISO 16609); or
To enhance security, the reference KVC should be stored and distributed separately from the public key and its associated data This separation prevents coordinated modifications or substitutions, such as through dual controls, ensuring the integrity of each component remains independently protected Implementing this approach reduces risk by ensuring that changes to the reference KVC cannot be directly linked or synchronized with alterations to the public key, thereby strengthening overall system security.
Key integrity techniques
One or more of the following techniques shall be used to ensure public key integrity:
A digital signature system is used to sign the public key and associated data, resulting in the creation of a public key certificate The management of key certificates and the keys used for creating and verifying these certificates are detailed in section 5.3 and Clause 6, ensuring secure and reliable cryptographic operations.
⎯ create a MAC for the public key and associated data, using an algorithm defined by ISO 16609 and a key used only for this purpose;
⎯ store the public key in an SCD (see ISO 13491-1 and ISO 13491-2);
Distribute the public key over an unprotected channel while ensuring the key verification code and associated data are transmitted via an integrity-assured channel, such as an authenticated channel with dual controls This process of key verification, detailed in section 5.5, ensures the authenticity and integrity of the public key within secure communication protocols.
One or more of the following techniques shall be used to ensure private key integrity:
⎯ create a MAC for the private key and associated data, using an algorithm defined by ISO 16609 and a key used only for this purpose;
⎯ store the private key in an SCD (see ISO 13491-1 and ISO 13491-2);
⎯ store as integrity protected key shares;
To verify a valid key pair, first apply a transformation on arbitrary data using the private key, then perform the complementary transformation with the public key, and confirm that the final result matches the expected outcome This process should be carried out entirely within a Secure Cloud Device (SCD), with all intermediate and final transformation results securely destroyed afterward to ensure data security.
Key life cycle phases
The key life cycle comprises three essential phases: pre-use, where the key pair is generated and may be transferred; use, during which the public key is distributed to authorized parties while the private key remains securely stored in an SCD; and post-use, which involves archiving the public key and securely terminating the private key to ensure ongoing security and proper key management.
The article provides a schematic overview of the private key (S) and public key (P) life cycles, illustrated in Figures 1 and 2, respectively, highlighting how each key's state changes during various operations Additionally, the life cycle of public key certificates is detailed in the ISO 15782-1 standard, emphasizing the importance of managing key states throughout their lifecycle for secure cryptographic practices.
A cryptographic key is considered to be a single object of which multiple instances may exist at different locations and in different forms A clear distinction is made between the following operations:
⎯ distribution of the public key to a communicating party (see 6.4);
⎯ transfer of a key pair to its owner in an implementation where the party does not have the capacity to generate key pairs (see 6.5)
And also a clear distinction is made between:
⎯ destruction of a single private key instance (see 6.11);
⎯ deletion of a private key from a given location which implies destruction of all instances of this key at that location (see 6.12);
⎯ termination of a private key, which implies deletion of the key from all locations (see 6.14)
Every operation performed on a key changes its state This clause specifies the requirements for obtaining a given state or performing a given operation
Requirements applying to specific life cycle stages are specified in 6.2
The requirements for archiving private keys to enable subsequent data decipherment—specifically for data encrypted with the corresponding public key—are considered outside the typical scope of this section of ISO 11568.
Note 2: The requirements may vary depending on the method of key pair generation Specifically, different considerations apply if a third-party asymmetric key pair generator is used versus when the owner generates and securely stores their own key pair.
ISO 11568-4:2007(E) © ISO 2007 – All rights reserved 9
Key life cycle stages — Generation
Asymmetric key pair generation involves creating a matching private key and public key for use in secure cryptographic systems These keys are mathematically related according to the specific design of the cryptosystem, ensuring robust security Importantly, it is computationally infeasible to derive the private key from the public key, providing strong protection for encrypted data This process is fundamental to asymmetric cryptography, enabling secure communication and data protection.
The key pair generation process is achieved by or on behalf of a single party This party becomes the owner of the key pair
Private keys and their components must be generated using secure methods that prevent prediction and reduce the likelihood of certain keys being more probable than others, ensuring strong cryptographic security The key generation process should incorporate high-quality random or pseudo-random values to maintain unpredictability and protect against potential attacks (See Bibliography [4] for detailed guidelines.)
An asymmetric key pair must be generated to ensure the secrecy of the private key and the integrity of the public key For non-repudiation services, it is essential that the integrity of the public key and the secrecy of the private key are verifiable by a third party, establishing trust and accountability.
The private key shall not be available in human-comprehensible form
If the key pair is generated by a system that will not use it:
⎯ the private key and all related secret seed elements shall be deleted immediately after the transfer has been ensured;
⎯ the integrity of the private key shall be ensured
Asymmetric key pairs, when generated, should have a replacement date to establish their life cycle
The size of the asymmetric key pair shall be chosen to be sufficiently large to render attacks computationally infeasible
The generation of an asymmetric key pair must be carried out by a certification authority (CA), the key pair owner, or an authorized third party The roles and responsibilities of the entity responsible for key pair generation are detailed in sections 6.2.2 to 6.2.4 Ensuring proper key pair generation is crucial for maintaining security and trust within the cryptographic system.
The Certification Authority (CA) is responsible for generating an asymmetric key pair within a Secure Cryptographic Device (SCD) It securely transfers the private key to the key pair owner in accordance with the requirements outlined in section 6.5 Additionally, the CA issues a certificate containing the public key, ensuring proper validation and trust.
The CA shall neither record nor retain the private key or any other information that could possibly compromise the private key or allow it to be recreated
The key pair owner shall generate the asymmetric key pair in an SCD and shall either:
⎯ generate the key pair in the same cryptographic device in which it will be used; or
⎯ securely transfer the private key from the device where it was generated into the device(s) in which it will be used
The key pair owner shall retain as few copies of the private key as is operationally feasible
NOTE The fewer the instances of the private key, the stronger the claim of non-repudiation, as there is a lower probability of compromise
Figure 1 — Private key life cycle
ISO 11568-4:2007(E) © ISO 2007 – All rights reserved 11
Figure 2 — Public key life cycle
The third party shall generate the asymmetric key pair in an SCD and shall transfer the private key to the key pair owner in accordance with the requirements in 6.5
The third party shall transfer the public key to the key pair owner in accordance with the requirements in 6.5.2
The third party shall neither record nor retain the private key or any other information that could possibly compromise the private key or allow it to be recreated.
Key storage
During storage, keys shall be protected against unauthorized disclosure and substitution, and key separation shall be provided
Storage of the private key requires that secrecy and integrity are ensured Storage of the public key requires that authenticity and integrity are ensured
6.3.2 Permissible forms for private keys
Effective private key storage techniques include: storing a plaintext key safely within a Secure Cryptographic Device (SCD); distributing key shares across at least two separate shares to prevent any single individual from accessing the entire key, ensuring security through quorum management; and encrypting keys using a key encipherment key, adding an extra layer of protection against unauthorized access.
A plaintext private key shall exist only within an SCD An SCD shall comply with the requirements as stated in
A private key existing in the form of at least two separate key shares shall be protected by the principles of split knowledge and dual control
Access to fewer than the required number of shares provides no information about the private key, ensuring its security Each key share should only be accessible to authorized individuals or groups and only for the minimum necessary duration Additionally, possessing one share of the key does not grant access to any other shares, maintaining strict separation and confidentiality of key components.
Key shares must be stored in a manner that enables the detection of unauthorized access, ensuring high security When key shares are stored in encrypted form, all relevant requirements for encrypted keys must be met to maintain confidentiality Additionally, key shares can be stored in a designated key transfer device, as outlined in ISO 13491-2, to enhance security and secure management.
A key share should be securely conveyed to authorized individuals using a key mailer or transfer device If a key mailer is employed, it must be printed to prevent visibility of the key share until the serialized envelope is opened The envelope should display only the essential data needed for delivery to ensure security Additionally, a key mailer must be designed to make any accidental or fraudulent opening easily detectable, and such compromised key shares must not be used.
ISO 11568-4:2007(E) © ISO 2007 – All rights reserved 13
A key share stored in an insecure token, such as a plaintext mailer, must be accessible to only one authorized individual at a time Access should be strictly limited to the duration necessary for the share to be entered into a Secure Cryptographic Device (SCD) Ensuring this minimizes security risks and maintains the integrity of the key management process.
Encipherment of a key using a key encipherment key shall take place within an SCD
The encipherment of a private key shall be implemented as specified in 5.2.3
6.3.3 Permissible forms for public keys
In an asymmetric cryptosystem there is no secrecy requirement for the storage of the public key, but authenticity and integrity of this key shall be ensured
It shall not be possible to substitute or alter any public key or associated information without detection
A public key shall be stored either in plaintext or enciphered forms as detailed in 6.3.3.2 and 6.3.3.3 respectively
When the public key is stored in plaintext as a certificate, the techniques described in Clause 5 shall apply for the production of this certificate
To ensure the integrity and security of the public key when it is not presented as a certificate, it must be stored with adequate protection This includes methods such as storing the key in plain text within a Secure Storage Device (SCD) designed to detect unauthorized key replacements, or utilizing key verification techniques outlined in section 5.5 to prevent undetected modifications.
Ensuring the authenticity and integrity of a public key can be achieved through encipherment techniques, such as including check values within the encrypted data This method helps verify the validity of the public key and maintain its integrity, adhering to the standards outlined in section 5.2 Proper encipherment practices are essential for secure public key management and trust establishment in digital communications.
6.3.4 Protection against substitution during storage
When plaintext public keys are stored without being in certificate format or after their certificate has been verified and they are used without revalidation, their integrity and authenticity can be ensured through the methods outlined in Section 6.3.3 and the techniques specified in Clause 5 Ensuring proper secure handling of public keys is critical for maintaining the trustworthiness of cryptographic communications.
Protection against substitution of the public key during storage is essential For example, the substitution of a public key used for encipherment may result in a threat to data secrecy
To protect a public key against substitution, it is essential to implement security techniques similar to those used for private keys Additionally, storing the public key in a digital certificate ensures its integrity and authenticity can be verified prior to use, enhancing overall security.
The unauthorized substitution of stored public keys shall be prevented by one or more of the following means
To ensure secure key management, it is essential to physically and procedurally prevent unauthorized access to the key storage area Additionally, keys should be stored in an encrypted format, with encryption tailored to their intended use, ensuring that it is impossible to determine both the plaintext key and its corresponding ciphertext Furthermore, storing certificates that contain public keys and verifying their authenticity before use are critical; the integrity and authenticity of the public key used for certificate verification must also be maintained.
If unauthorized key substitution is known or suspected, the public key shall be updated with the correct public key
To ensure each key in an asymmetric key pair is used solely for its intended purpose, key separation methods should be implemented These methods include physically segregating stored keys based on their purpose, storing keys encrypted under a dedicated encipherment key specific to their use, modifying or adding information to keys prior to their encrypted storage to indicate their purpose, and using certificates for public keys that specify their intended usage Implementing these measures enhances key security and enforces proper key utilization in cryptographic systems.
Key back-up is the storage of a copy for the purpose of reinstating a key that is accidentally destroyed but the compromise of which is not suspected
Backup copies of keys must be stored in approved secure formats, ensuring they are protected with at least the same level of security controls as active keys Proper management of backup keys is essential to maintain overall security integrity Implementing strict security measures for backup copies helps prevent unauthorized access and potential security breaches.
Key back-up is ensured using the same principles and techniques as for key storage.
Public key distribution
Key distribution is the process by which a public key is conveyed to the party intended to use it
To ensure the security of public key distribution, it is essential that any method, whether manual or automated, maintains the integrity and authenticity of the public key Preventing the substitution of a public key during distribution is crucial, which can be achieved by securely maintaining the public key in the specified formats outlined in section 6.3.3.
Asymmetric key pair transfer
The transfer of an asymmetric key pair involves securely delivering the key pair and the associated public key certificate to the key owner This process is essential when the individual does not have the ability to generate their own key pair, ensuring their secure access to cryptographic functions Proper key pair transfer is a critical component of public key infrastructure (PKI), supporting secure communications and data protection.
The owner shall be authenticated prior to being given their key pair
The techniques used for public key distribution are described in 4.3
ISO 11568-4:2007(E) © ISO 2007 – All rights reserved 15
The techniques used for protection against substitution during distribution are described in Clause 5
The transfer of the public and private keys of an asymmetric key pair shall use one of the techniques described in this clause and summarized in Table 2
Suitable techniques for transferring private and public keys are provided in ISO/IEC 11770-3
Table 2 — Permissible asymmetric key pair transfer techniques
To ensure the secure transfer and loading of plaintext private keys, the process must maintain confidentiality and integrity, adhering to principles of dual control and split knowledge An SCD should only transfer a plaintext private key when at least two authorized individuals are authenticated, such as through passwords Keys must be loaded into an SCD only if the device has not been tampered with, preventing potential disclosures of sensitive data Transfers between SCDs should occur only in secure environments where eavesdropping or tapping interfaces is prevented When transferring keys from the generation device to the usage device, an SCD must be used to avoid exposing key information; after loading, the transfer device must not retain any key data Additionally, during transfer, the key and its identifier should move from the generating device to a portable key transfer device, which is then physically transported to the cryptographic device responsible for usage, ensuring secure handling throughout the process.
Proper custody of the key transfer device is essential to ensure the private key is only transferred to the authorized key-using device The key and its identifier should be securely transferred from the key transfer device to the designated key-using device, maintaining the integrity and security of the cryptographic process.
Key shares must be entered into the device either manually or via a key transfer device, ensuring secure handling throughout the process The transfer and loading of private key shares must prevent disclosure to unauthorized individuals, only occur when the device is verified to be untampered, and be protected against active or passive tapping mechanisms at the interface Additionally, the process should adhere to principles of dual control and split knowledge, with each key share holder entering their share individually to maintain security and confidentiality.
Key verification methods outlined in section 5.5 are essential for ensuring the correct entry of key shares Once the final share has been entered, the cryptographic device performs the necessary operations to reconstruct the key, confirming its integrity and accuracy These verification processes enhance security by guaranteeing that the key is correctly assembled before use.
Enciphered keys can be securely transferred and loaded electronically through communication channels The encryption of a key using a key encipherment key must occur within a Secure Cryptographic Device (SCD), ensuring proper security measures are maintained In such cases, the specific requirements outlined in section 5.2.3 are to be followed to ensure compliance and security.
The process of transferring enciphered private keys shall protect against key substitution and modification Key identifier and related data shall be transferred together with the private key
Public key transfer techniques shall ensure the authenticity of the key
Before distributing a public key, it is essential to verify the correct transfer of the key pair if it was not generated by the key owner This verification involves applying a transformation on arbitrary data with one key, then using the complementary key to reverse the transformation, and confirming that the final result matches the expected outcome All of these operations must be conducted entirely within the Secure Cryptographic Device (SCD), with all intermediate and final transformation results securely destroyed to ensure key integrity and security.
Authenticity prior to use
To ensure security, the authenticity and integrity of the public key must be verified before each use or maintained continuously to guarantee their integrity during operation.
Certification may be used to provide this assurance (see 5.3) Alternatively, the methods described in 5.5 may be used
ISO 11568-4:2007(E) © ISO 2007 – All rights reserved 17
Use
The use of asymmetric private and public keys is described in Clause 4
In an asymmetric cryptosystem, each key of a key pair serves distinct functions, with strict requirements to ensure security Unauthorized use of a private key must be prevented, and each key should only be used for a specific purpose, such as authenticity or confidentiality, unless otherwise specified Keys are to be used solely in their designated roles and locations, with private keys stored in the minimal number of secure locations necessary for effective operation When a key's cryptoperiod ends or if its compromise is suspected, it must no longer be used Public keys require verification of their authenticity and integrity before use, and the secrecy of private keys must be maintained by confining their use within secure cryptographic devices (SCD) and implementing robust physical and logical controls Ensuring the validation of public key integrity before use is essential to maintain trust and security in the system.
Clause 5 contains a list of techniques that should be used to obtain proper key separation and to verify integrity and authenticity of a public key
Subsequent use of a key suspected of compromise shall be prevented by either: a) deleting the key from all operational locations; b) blocking the means used to obtain the key.
Public key revocation
Public key revocation is the process whereby the use of a public key is terminated for one of the following reasons:
When a private key compromise is suspected or identified, it is essential to promptly revoke the associated public key to prevent unauthorized access If the compromised key pair functions as a key encipherment key, all subordinate keys within its hierarchy must also be terminated to ensure comprehensive security This proactive approach helps mitigate potential security breaches and maintains the integrity of cryptographic systems.
For business reasons, authorized entities may rescind the use of an asymmetric key pair In this case, the public key shall be revoked
Public key users must be promptly notified when a public key has been revoked to ensure security Upon receiving such notification—whether through active means like broadcasting the revocation to all users or passive methods such as posting it on an accessible database—they must immediately cease using the revoked public key This process is essential for maintaining trust and integrity within public key infrastructures.
Revoked public keys may still be necessary for verifying previously signed information or fulfilling legal requirements, and therefore can be retrieved from archived records Ensuring access to revoked keys is essential for maintaining data integrity and compliance with legal standards in digital security Archiving revoked public keys helps organizations verify past transactions and uphold accountability in cryptographic processes.
Replacement
Key pair replacement is the process whereby a new key pair replaces a revoked or expired key pair
Key replacement shall be implemented by repeating the appropriate key generation, transfer, distribution and loading procedures
If the key pair has expired or is revoked due to business reasons, e.g., change of SCD ownership, replacement of the key pair may not be necessary or appropriate
During key pair replacement, the key pair owner shall adhere to all of the requirements for key pair generation
During key pair replacement, the key pair owner shall adhere to all of the requirements for public key registration
Key replacement shall occur: a) at the end of the cryptoperiod; or b) when compromise of the private key is known or suspected; or c) as required to address business needs
In the case of key replacement, both the public and the private key of a key pair shall be replaced
A cryptographic key must be replaced within a timeframe that ensures protection against known attack methods, such as attempts to compromise data encrypted with the key or to determine the private key through cryptanalytic techniques The appropriate key replacement period depends on the specific implementation and the technological capabilities available at the time of potential attack This approach ensures robust data security by adapting to evolving threats and cryptanalytic methods.
Replacement of a key pair shall take place in all operational locations where the keys exist
Keys that have been replaced shall not be returned to active use
Key replacement requires that the old private key shall be destroyed.
Public key expiration
Public keys are generated with an associated expiry date that defines their lifecycle It is essential to adhere to these expiry dates, as public keys must not be used beyond their designated validity period to ensure security and compliance Proper management of key expiration helps maintain the integrity of cryptographic systems and prevents unauthorized access.
Private key destruction
A private key must be permanently destroyed when it is no longer needed for active use to maintain security Electronic private keys should be erased completely to prevent unauthorized access However, residual information may remain at the operational location, allowing the key to potentially be restored for future active use if necessary.
Public keys should not be redistributed to communicating parties once issued If public keys are stored at the parties' locations, they must be promptly informed once the associated private key has been destroyed to maintain security and ensure proper key management.
ISO 11568-4:2007(E) © ISO 2007 – All rights reserved 19
When an SCD is permanently removed from service, all private keys stored within the device shall be destroyed
Private key destruction must be carried out by either fully overwriting the key with a new, non-secret value to ensure no trace of the original key remains, or by physically destroying the key storage media in accordance with ISO 9564-1 standards, ensuring secure removal and preventing unauthorized access.
Private key deletion
Key deletion occurs when all instances of the private key have been destroyed at a given location
Private key deletion involves completely erasing all forms of the key at the operational location, including physical security measures, encrypted formats, or key components, to ensure secure removal and prevent unauthorized access.
When a key component stored in a human-readable format must be deleted, the associated media should be destroyed through burning or an equally effective method to ensure complete removal This process guarantees that sensitive information is securely eliminated, maintaining data security standards Proper destruction of the media prevents unauthorized access and preserves confidentiality, adhering to best practices in data protection.
Public key archive
Public key archives store public keys to verify signatures made before key revocation Once verification is complete, the relevant key instance should be securely destroyed to maintain security This process ensures the integrity of digital signatures while safeguarding sensitive cryptographic information Proper archiving and key destruction are essential for maintaining trust in secure communications.
An archived public key shall be securely stored in order to ensure its integrity as long as data verifiable by this key still exists
Public key archive shall be protected with the same level of security as for public key storage (see 6.3)
Implementing proper key management involves separating archived keys from active keys and preventing the substitution of active keys with archived ones This can be achieved by utilizing suitable techniques outlined in ISO 11568-2 and section 5.4, ensuring robust security and compliance.
The key encipherment key used for the archival process shall not intentionally be the same as any of the key encipherment keys used to encipher active keys.
Private key termination
Private key termination happens when the private key is completely deleted from all locations where it was previously stored Once the private key has been terminated, no remaining information should exist that could allow its reconstruction This process ensures that the private key is irrecoverable, enhancing security and preventing unauthorized access Proper private key termination is essential for maintaining cryptographic integrity and safeguarding sensitive data.
NOTE Archiving of private keys is unnecessary
Private key termination shall be effected by destroying all instances of the key at all locations according to the requirements and methods described in 6.12
Erasure summary
Instance of a key Information for reconstruction
Destruction Single Single instance erased —
Deletion Single All instances erased erased
Termination All All instances erased erased
Optional life cycle processes
Public key certification is a crucial process in digital security, where a trusted third party, known as a certification authority, verifies and establishes a trust link between a public key and its owner This process involves the certification authority providing proof that associates the public key with relevant identifying information, ensuring the authenticity and integrity of secure communications Implementing public key certification enhances cybersecurity by enabling users to verify the legitimacy of public keys, thereby preventing impersonation and ensuring data confidentiality As a fundamental component of cryptographic infrastructure, public key certification underpins secure online transactions and digital identities.
Key certification and the certification authority are described in 5.3
The public key of the certification authority that is used to verify the public key in a certificate should be transferred to the user in an authenticated way
Retrieval of a public key from back-up shall be implemented by one of the methods described for public key distribution and loading in 6.4
Retrieval of a private key from back-up shall be implemented by one of the methods described for private key storage in 6.3
ISO 11568-4:2007(E) © ISO 2007 – All rights reserved 21
This annex outlines the approved algorithms for key management using public key cryptography, ensuring secure and reliable key exchange The process for gaining approval for additional algorithms is detailed in ISO 11568-1, providing a standardized method for algorithm evaluation Symmetric key algorithms authorized for use under ISO 11568 are specified in ISO 11568-2, supporting robust cryptographic practices in security implementations.
A.2.1 Algorithms approved for public key transport systems
ECIES-KEM (Key Encapsulation Method) Ref: ISO/IEC 18033-2
A.2.2 Algorithms approved for public key agreement systems
EC-DH Ref: ISO/IEC 15946-3
EC-MQV Ref: ISO/IEC 15946-3
A.2.3 Algorithms approved for digital signatures
[1] ISO/IEC 9797-1, Information technology — Security techniques — Message Authentication Codes (MACs) — Part 1: Mechanisms using a block cipher
[2] ISO/IEC 9797-2, Information technology — Security techniques — Message Authentication Codes (MACs) — Part 2: Mechanisms using a dedicated hash-function
[3] ISO/IEC 11770-1:1996, Information technology — Security techniques — Key management — Part 1: Framework
[4] ISO/IEC 11770-2:1996, Information technology — Security techniques — Key management — Part 2: Mechanisms using symmetric techniques
[5] ISO/IEC 18032, Information technology — Security techniques — Prime number generation
[6] ISO 21188, Public key infrastructure for financial services — Practices and policy framework
[7] ANSI X9.57, Public Key Cryptography for the Financial Services Industry: Certificate Management
[8] SHAMIR, A How to share a secret, Communications of the ACM, November 1979
[9] ISO/IEC 18033-3, Information technology — Security techniques — Encryption algorithms — Part 3: Block ciphers
[10] MENEZES, A., VAN OORSCHOT, P and VANSTONE, S Handbook of Applied Cryptography, CRC Press,
[11] Special Publication 800-57 Recommendation for Key Management — Part 1: General (Revised),
National Institute of Standards and Technology
[12] ISO/IEC 9796-3, Information technology — Security techniques — Digital signature schemes giving message recovery — Part 3: Discrete logarithm based mechanisms
[13] ISO 9807, Banking and related financial services — Requirements for message authentication (retail)
[14] ANSI X9.30-1, Public Key Cryptography for the Financial Services Industry — Part 1: The Digital Signature Algorithm (DSA)
[15] BSR X9.102-200x 1) , Symmetric Key Cryptography for the Financial Services Industry: Wrapping of Keys and Associated Data
[16] AS 2805 5.3, Electronic funds transfer — Requirements for interfaces — Ciphers — Data encipherment algorithm 2 (DEA 2)