Соответствие требованиям

Куда я попал?

SECURITM это SGRC система, автоматизирующая процессы в службах информационной безопасности. SECURITM помогает построить и управлять ИСПДн, КИИ, ГИС, СМИБ/СУИБ, банковскими системами защиты.
А еще SECURITM это место для обмена опытом и наработками для служб безопасности.

Подробнее

Наш канал

Payment Card Industry 3-D Secure (PCI 3DS)

Стандарт

Security Objective 3: Use Cryptography Appropriately and Correctly

Для проведения оценки соответствия по документу войдите в систему.

Список требований

3DS SDK Security Requirements and Assessment Procedures
Security Objective 3: Use Cryptography Appropriately and Correctly
The proper implementation of cryptographic algorithms and appropriate key-management techniques is critical to ensuring the integrity and confidentiality of the 3DS SDK and the information it handles. If cryptographic algorithms and key-management techniques are not implemented properly or appropriately, the value they provide from a security perspective is significantly reduced⎯if not eliminated altogether. Only industry-recognized algorithms and key-management techniques must be used. Proprietary algorithms are not allowed.
Requirement 3: The 3DS SDK only utilizes strong cryptography and ensures that cryptographic methods are properly and appropriately implemented.
Requirements:
3.1 Approved Algorithms and Modes of Operation
Only approved cryptographic algorithms and methods are used. Approved cryptographic algorithms and methods are those specified within the EMV® 3-D Secure SDK Specification. Approved cryptographic algorithms and methods are also recognized by industry-accepted standards bodies⎯for example: NIST, ANSI, ISO, EMVCo, etc. Cryptographic algorithms and parameters that are known to be vulnerable are not used.
Assessment Procedures:
T.3.1.1 The tester shall examine vendor materials and other evidence, including source code, to determine what cryptographic algorithms and methods are used and all cryptographic keys used in the system that are relied upon for the security of the 3DS SDK.
T.3.1.2 The tester shall examine vendor materials and other evidence, including source code, to identify modes of operation available for each key, including determining how any additional values (such as initial vectors) may be generated for that mode of operation.
T.3.1.3 Where the mode of operation may be open to exploitation⎯e.g., relocation or data analysis attacks on Electronic Code Book (ECB) mode⎯the tester shall confirm that this sort of attack is not feasible for this implementation. This testing must always be performed for keys that allow for ECB as a mode of operation.
T.3.1.4 Where the mode of operation requires the use of another value, such as an Initialization Vector (IV) or counter, the tester shall confirm that the implementation ensures that this value is correct and secure.
T.3.1.5 The tester shall examine vendor materials and other evidence, including source code, to determine all key generation or key agreement processes that are used by the system, and to confirm that they ensure keys are generated with full entropy (e.g., a 128-bit key is generated with 128 bits of entropy input).
T.3.1.6 The tester shall confirm that no reversible key-calculation modes (such as key variants) are used to directly create new keys from an existing key. All key-generation functions must implement one-way functions or other irreversible key-generation processes.
T.3.1.7 The tester shall confirm that any key signature or fingerprint values returned by the system do not reveal any details about the key itself. Key checksum values (KCVs) must be limited to five bytes or less than half of the algorithm block size, whichever is smaller, and hash algorithms used for key fingerprints (on secret or private keys) must implement SHA256 or above.
T.3.1.8 The tester shall confirm that a cryptoperiod is defined for each key, and that update procedures are also defined to replace each key at the end of this cryptoperiod.
T.3.1.9 The tester shall confirm that security is not provided to any key by a key of lesser strength⎯e.g., by encrypting a 256-bit AES key with a 128-bit AES key.
T.3.1.10 For any public keys used by the system, the tester shall confirm that the authenticity of each public key is maintained. Use of public keys that are not signed or MAC’d or are maintained in self-signed certificates, is prohibited unless the authenticity of the key is ensured through use of a secure cryptographic module. Self-signed certificates that exist as part of the base platform on which the 3DS SDK is executed are excluded from this requirement.
T.3.1.11 The tester shall confirm that key purpose and integrity is ensured for all keys used in the system, preventing a key of one purpose (e.g., key encryption) from being replaced with a key of another purpose (e.g., general data encryption).
T.3.1.12 The tester shall confirm that each key has a single unique purpose, and that no keys are used for multiple purposes (such as both signing and encrypting data), and that keys used to encrypt Cardholder Verification Method (CVM) data are not used for any other operation (such as general-purpose data encryption, monitor message encryption, etc.).
T.3.1.13 The tester shall confirm that keys used to validate the authenticity of a datagram are unique to each endpoint, so that a (H)MAC or signature generated at one end would always be different if generated by the other end point.
Guidance:
To protect sensitive information, the 3DS SDK should utilize only recognized cryptographic implementations based on the EMV® 3-D Secure SDK Specification and industry-accepted standards. For a list of approved cryptographic algorithms and methods, please refer to the EMV® 3-D Secure SDK Specification and the EMV® 3-D Secure Protocol and Core Functions Specification.
Requirements:
3.2 Random Number Generator(s)
All random numbers used by the 3DS SDK are generated using only approved random number generation (RNG) algorithms or libraries. Approved RNG algorithms or libraries are those meeting industry standards for sufficient unpredictability (e.g., NIST Special Publication 800-22).
Note: Proof that RNG algorithms or libraries meet industry standards may include recognition by industry bodies, or evidence to show where those RNG algorithms or libraries were assessed to ensure that the random numbers generated are sufficiently unpredictable.
Assessment Procedures:
T.3.2.1 The tester shall examine vendor materials and other evidence, including source code, to determine the implementation of all random number generation functions used in the 3DS SDK implementation.
T.3.2.2 The tester shall examine vendor materials and other evidence, including source code, to determine all functions of the 3DS SDK that rely upon the on-device generation of random numbers. This should include uses such as random values required in secure communications channels (such as TLS).
T.3.2.3 The tester shall confirm that the 3DS SDK does not rely solely on any on-device random number generators and always uses an RNG provided by or within the 3DS SDK for the purposes of generating random values that are relied upon for the secure functionality of the 3DS SDK. The tester shall reference the random values required by the 3DS SDK listed in T.3.2.2. Where any values are generated without the use of the 3DS SDK RNG, the tester shall confirm the use of the RNG is prevented by the platform targeted by the 3DS SDK, and that the use of the on-platform RNG does not violate the security of the 3DS operations.
T.3.2.4 The tester shall confirm that values provided by the RNG are sufficiently random in accordance with Requirement 3.3, “Random Number Entropy.”
T.3.2.5 The tester shall examine vendor materials and other evidence to determine any requirements for the developer integrating the 3DS SDK to ensure that the random numbers are sufficiently random. The tester shall confirm that there is clear and sufficient guidance outlining these requirements made available to stakeholders in accordance with Requirement 5.1, “Availability of Stakeholder Guidance.”
Guidance:
Random numbers are used in numerous software applications, including cryptography, to protect sensitive information. Encryption keys, initialization values (seeds), and 3DS SDK transaction IDs are examples of random numbers used in the 3DS SDK. It is not a trivial endeavor to design and implement a secure random number generator. 3DS SDK Vendors are required to use only approved random number generation algorithms and libraries, or provide evidence to illustrate how the random number generation algorithms and libraries were tested to confirm that random numbers generated are sufficiently unpredictable. The implementation may rely on either a validated cryptographic library or module (for example, Validated FIPS 140-2 Cryptographic Modules). The Vendor should have a good understanding of the installation, initialization, configuration and usage⎯for example, initial seeding of the random function⎯of the RNG mechanisms to ensure that the implementation can meet the effective security strength required for the intended use. The calls to these libraries should also be protected from being hooked.
Requirements:
3.3 Random Number Entropy
Random values have entropy that meets the minimum effective security strength requirements of the cryptographic primitives and keys that rely on them.
Assessment Procedures:
T.3.3.1 The tester shall examine vendor materials and other evidence, including source code, and the results of testing performed in Requirement 3.2, “Random Number Generator(s),” to determine how the RNG within the 3DS SDK is implemented and how the entropy for the RNG is generated.
T.3.3.2 Where the 3DS SDK relies upon an RNG that has been approved under the NIST Cryptographic Algorithm Validation Program (CAVP), the tester shall confirm from the approval and/or security policy of the RNG, whether the RNG requires the initial entropy to be seeded externally.
T.3.3.3 Where the 3DS SDK is required to generate entropy through use of its own RNG or a RNG that requires external seeding, the tester shall confirm that there is sufficient entropy generated⎯e.g., through confirmation that the entropy generation involves inputs that cannot be predicted within the domain of the random values produced by the RNG.
T.3.3.4 The tester shall confirm that the RNG is seeded with a random value of at least 256 bits for use during all operations.
T.3.3.5 The tester shall obtain at least two sets of 64MB of random data from each of the RNG implementations used in the system, generated during separate installs and initial executions on the same device. This data may be supplied directly by the vendor, but the tester must detail the method used to generate this data, and justify why this sufficiently replicates the way in which the RNG will be used by the system after two similar installations. The tester shall combine the two sets of data and pass this 128MB of data through the NIST STS test program, and detail the results, indicating pass and fail results and how these demonstrate compliance to this requirement. In some situations, it is necessary to repeat such tests using additionally obtained data to confirm final results.
Guidance:
Note that a non-deterministic random number generator (NDRG) may produce an output string that contains less entropy than implied by the length of the output. A deterministic random number generator (DRNG) is dependent on the entropy of its seed value. Vendors are encouraged to use as many sources of seed material as possible to ensure random number values are sufficiently random.

Мы используем cookie-файлы, чтобы получить статистику, которая помогает нам улучшить сервис для вас с целью персонализации сервисов и предложений. Вы может прочитать подробнее о cookie-файлах или изменить настройки браузера. Продолжая пользоваться сайтом, вы даёте согласие на использование ваших cookie-файлов и соглашаетесь с Политикой обработки персональных данных.