GA/T 1549-2019Information security technology - Security technical requirements for dual-interface authentication card (English PDF)

6.1 General safety function requirements

6.1.1 Application Interface Restrictions

All data of contactless applications can only communicate with external entities through contactless interfaces; all data of contactless applications can only pass the contact interface communicates with external entities.

6.1.2 Application isolation

The code or data of any application must not be accessed and manipulated by other applications unless the application has been explicitly authorized to access Ask for the corresponding code or data.

6.1.3 Identity authentication

6.1.3.1 Handling of authentication failure

When the number of failed user authentication attempts reaches the specified number, the product shall be able to terminate the authentication session process.

6.1.3.2 Reuse of authentication information

The product should prevent the reuse of authentication information related to the authentication mechanism.

6.1.3.3 Re-identification

The product shall re-identify the user under the following conditions.

a) Termination of the smart card session;

b) Smart card reset.

6.1.4 Security Management

6.1.4.1 Security function management

The product should be limited to authorized users to manage the following security features.

a) application software management;

b) Smart card life cycle management;

c) key management;

d) PIN code management.

6.1.4.2 Management of security attributes

The product should only allow authorized users to update the smart card lifecycle status one-way, modify application software lifecycle status, user permissions, PIN status and other security attributes.

6.1.4.3 Initialization of static attributes

The product should provide a limited default value for security attributes and allow only authorized users to modify these default values.

6.1.4.4 Security roles

The product should be able to maintain security roles such as cardholder, issuer, and runtime context.

6.1.5 User data protection

6.1.5.1 Access control policy

The product shall ensure that all operations involved in the security function are covered by the access control policy, and the subject shall be able to follow the predefined access control Strategic access objects.

6.1.5.2 Access Control Based on Security Attributes

Products should provide clear access assurance capabilities and denial of access capabilities based on the security attributes of the subject and object.

6.1.5.3 Data confidentiality

Product security functions should perform confidentiality processing of user data.

6.1.5.4 Data integrity

Product security functions should perform integrity checks on user data.

6.1.6 Self-protection capability

6.1.6.1 Safety function test

When the product is initialized, it should run a self-test procedure to prove the correct operation of the product.

6.1.6.2 Fail-safe

The product should automatically return to a safe state when the following failure conditions occur.

a) identification of data integrity violations;

b) buffer overflow;

c) resources are unavailable;

d) violations of product security policies;

e) The smart card is accidentally removed from the CAD;

f) abnormal environmental conditions (frequency, voltage, temperature);

g) Safety function detects failure.

6.1.6.3 Bypass attack resistance

The product should be able to resist bypass attacks initiated by attackers through time-consuming instructions, power consumption, and electromagnetic radiation.

6.1.6.4 Resistance to disturbance attacks

The product should be able to resist perturbation attacks initiated by attackers through lasers, clock glitches, and voltage glitches.

6.1.6.5 Resistance to physical attacks

The product should be able to resist physical attacks launched by attackers through reverse analysis, physical tampering, physical probes, etc.

6.1.7 Password support

6.1.7.1 Key generation

The key generation of the product shall comply with the relevant regulations of national password management.

6.1.7.2 Key destruction

For keys that are no longer used, the product should provide key destruction.

6.1.7.3 Cryptographic Algorithm

The cryptographic algorithms such as encryption, decryption, signature, and signature verification performed by the product shall comply with the relevant regulations of national password management.

6.2 Requirements for contact safety functions

6.2.1 Cardholder authentication

6.2.1.1 Identification timing

Authentication should be performed before accessing the product's protected resources, and users should be allowed to perform the following actions.

a) establish logical channels;

b) select the contact application software in the smart card;

c) Establish a secure channel.

6.2.1.2 Authentication mechanism

The PIN code-based identification of the cardholder should be used. After the cardholder's PIN code is successfully authenticated, other authorization operations are allowed.

6.2.2 Timeliness and authenticity of authentication

The product shall be able to verify the timeliness and authenticity of the verification process during identity verification, and shall have the following capabilities.

a) the ability to test the timeliness and authenticity of the PIN verification process;

b) The ability to verify the timeliness and authenticity of authorized messages and verify evidence

6.3 Requirements for non-contact safety functions

6.3.1 Identification timing

Authentication should be performed before accessing the product's protected resources, and users should be allowed to perform the following actions.

a) establish logical channels;

b) select the contactless application software in the smart card;

c) Establish a secure channel.

6.3.2 Identity authentication

The product should be able to adopt an authorization agreement mechanism to complete identity authentication.

7.1 Development

7.1.1 Security Architecture

The developer should provide a description of the security architecture of the product's security functions. The description of the security architecture should meet the following requirements.

a) Consistent with the level of abstract description of security functions implemented in the product design document;

b) describe the security domain of the product security function consistent with the requirements of the security function;

c) describe why the product safety function initialization process is safe;

d) confirm that product safety functions can be prevented from being compromised;

e) Verify that product safety functions prevent safety features from being bypassed.

7.1.2 Functional Specifications

Developers should provide complete functional specifications, which should meet the following requirements.

a) fully describe the safety functions of the product;

b) describe the purpose and use of all safety function interfaces;

c) identify and describe all parameters related to each safety function interface;

d) describe the safety function implementation behavior related to the safety function interface;

e) describe direct error messages caused by the behavioral processing of safety functions;

f) confirm that the safety function requires traceability to the safety function interface;

g) describe all actions related to the safety function interface during the implementation of the safety function;

h) Describe all direct error messages that may be caused by the call of the safety function interface.

7.1.3 Implementation Representation

Developers should provide implementation representations for all security functions. Implementation representations should meet the following requirements.

a) Provide a mapping between product design descriptions and implementation representation examples and prove their consistency;

b) Define product safety functions according to the level of detail, to a level of detail that can be generated without further design;

c) Provided in the form used by developers.

7.1.4 Product Design

Developers should provide product design documents, which should meet the following requirements.

a) describe the product structure in terms of subsystems;

b) identify and describe all subsystems of product safety functions;

c) describe the interaction between all subsystems of the safety function;

d) the mapping relationship provided can verify that all the behaviors described in the design can be mapped to the security function interface that calls it;

e) describe safety functions according to the module;

f) Provide the mapping relationship between the safety function subsystem and the module;

g) describe all safety function implementation modules, including their purpose and interaction with other modules;

h) Describe the relevant interfaces required by all modules to implement the security functions, return values from other interfaces, interactions with other modules, and Called interface

i) Describe the supporting or related modules of all safety functions, including their purpose and interaction with other modules.

7.2 Guidance documents

7.2.1 Operation User Guide

Developers should provide clear and reasonable operating user guides, which are kept in line with all other documents provided for evaluation Sincerely, the description of each user role should meet the following requirements.

a) describe the functions and privileges accessible to users controlled in a secure processing environment, including appropriate alert information;

b) describe how to use the available interfaces provided by the product in a secure manner;

c) describe available functions and interfaces, especially all safety parameters controlled by the user, and indicate safety values where appropriate;

d) clearly state each security-related event related to the user-accessible function that needs to be performed, including changes to the control of the security function Security features of the entity;

e) identify all possible states of operation of the product (including failures or operational errors caused by operations), and their relevance to maintaining safety Causality and connection between operations;

f) Security policies implemented to fully achieve security purposes.

7.2.2 Preparation procedures

The developer shall provide the product and its preparation procedures. The preparation procedure description shall meet the following requirements.

a) describe all steps necessary to securely receive the delivered product in accordance with the developer delivery process;

b) Describe all steps necessary to safely install the product and its operating environment.

7.3 Life cycle support

7.3.1 Configuration Management Capability

Developer configuration management capabilities should meet the following requirements.

a) provide unique identification for different versions of the product;

b) use a configuration management system to maintain all configuration items that make up the product and uniquely identify configuration items;

c) Provide configuration management documents, which describe the method used to uniquely identify configuration items;

d) The configuration management system provides an automatic way to support the generation of products, by which it is ensured that only the implementation of the products can be expressed Authorized changes;

e) The configuration management document includes a configuration management plan, which describes how to develop products using a configuration management system. real the implementation of the configuration management is consistent with the configuration management plan;

f) The configuration management plan describes the procedures used to accept modified or newly created configuration items as part of the product.

7.3.2 Configuration Management Scope

The developer should provide a list of product configuration items and describe the developer of the configuration item. The configuration item list should include the following.

a) Evaluation evidence of products, safety assurance requirements and components of products;

b) Implementation indication, security defect report and resolution status.

7.3.3 Delivery Procedure

Developers should use a certain delivery procedure to deliver the product and document the delivery process. When delivering versions of the product to the user, the delivery documentation should describe all procedures necessary to maintain security.

7.3.4 Development Security

Developers should provide development security documentation. The development security documentation should describe the design and implementation all physical, procedural, personal and other security measures necessary for confidentiality and integrity.

7.3.5 Life Cycle Definition

The developer should establish a life cycle model to control the development and maintenance of the product, and provide a description of the life cycle definition document.

Describe the models used to develop and maintain products.

7.3.6 Tools and Techniques

Developers should clearly define the tools used to develop the product, and provide development tool documentation to unambiguously define the meaning of each statement in the implementation and the meaning of all implementation-dependent options.

7.4 Test

7.4.1 Test coverage

The developer should provide a test coverage document, and the test coverage description should meet the following requirements.

a) indicate the correspondence between the tests identified in the test documentation and the safety functions of the product described in the functional specification;

b) Show that the above correspondence is complete and confirm that all safety function interfaces in the functional specification have been tested.

7.4.2 Test depth

Developers should provide test depth analysis. The test in-depth analysis description should meet the following requirements.

a) confirm the consistency between the tests in the test documentation and the safety function subsystem and implementation modules in the product design;

b) Verify that all safety function subsystems and implementation modules in the product design have been tested.

7.4.3 Functional test

Developers should test product security features, document results and provide test documentation. The test documentation should include the following.

a) A test plan that identifies the tests to be performed and describes the scenarios for each test, including those for other test results any order dependency;

b) the expected test results, indicating the expected output after a successful test;

c) Consistency of actual test results and expectations.

7.4.4 Independent testing

Developers should provide a set of resources equivalent to those used for self-testing security features for sample testing of security features.

7.5 Vulnerability assessment

Based on the identified potential vulnerabilities, the product is resistant to attacks by attackers with enhanced basic attack potential.

references

[1] Machine Readable Traval Document Platform Protection Profile, Version 1.00, HMGovernment, UK, 2009. UNKT-DO-0002 [2] GB/T 20276-2016 Information security technology IC card embedded software security technology requirements with central processor [3] GB/T 22186-2016 Information security technology IC card chip security technology requirements with central processor