|
US$979.00 · In stock
Delivery: <= 6 days. True-PDF full-copy in English will be manually translated and delivered via email.
WS/T 543.2-2017: Resident health card technical specifications - Part 2: Technical specification of the user card
Status: Valid
| Standard ID | Contents [version] | USD | STEP2 | [PDF] delivered in | Standard Title (Description) | Status | PDF |
| WS/T 543.2-2017 | English | 979 |
Add to Cart
|
6 days [Need to translate]
|
Resident health card technical specifications - Part 2: Technical specification of the user card
| Valid |
WS/T 543.2-2017
|
PDF similar to WS/T 543.2-2017
Basic data | Standard ID | WS/T 543.2-2017 (WS/T543.2-2017) | | Description (Translated English) | Resident health card technical specifications - Part 2: Technical specification of the user card | | Sector / Industry | Health Industry Standard (Recommended) | | Classification of Chinese Standard | C07 | | Word Count Estimation | 39,327 | | Date of Issue | 2017-07-25 | | Date of Implementation | 2017-12-01 | | Regulation (derived from) | State-Health-Communication (2017) 8 | | Issuing agency(ies) | National Health and Family Planning Commission of the People's Republic of China | WS/T 543.2-2017: Resident health card technical specifications - Part 2: Technical specification of the user card
---This is a DRAFT version for illustration, not a final translation. Full copy of true-PDF in English version (including equations, symbols, images, flow-chart, tables, and figures etc.) will be manually/carefully translated upon your order.
Resident health card technical specifications-Part 2.Technical specification of the user card
CS 11.020
C 07
WS
People's Republic of China Health Industry Standard
Technical Specifications for Resident Health Card
Part 2.User Card Technical Specifications
2017-07-25 released
2017-12-01 implementation
Issued by the National Health and Family Planning Commission of the People's Republic of China
Foreword
This standard was drafted in accordance with the rules given in GB/T 1.1-2009.
WS/T 543 "Technical Specifications for Resident Health Cards" is divided into 6 parts.
--Part 1.General provisions;
--Part 2.Technical Specifications of User Card;
--Part 3.User Card Application Specification;
--Part 4.User card command set;
--Part 5.Terminal technical specifications;
--Part 6.User card and terminal product testing specifications;
This part is part 2 of WS/T 543.
Drafting organizations of this section. National Health and Family Planning Commission Statistical Information Center, Henan Provincial Health and Family Planning Commission Information Center, Liaoning Provincial Health and Family Planning Commission
Information Center, Jiangsu Provincial Health and Family Planning Commission, Foshan Municipal Health and Family Planning Bureau, Hubei Provincial Health and Family Planning Commission Information Center, China
Tongji Hospital Affiliated to Tongji Medical College of University of Science and Technology of China, First Affiliated Hospital of China Medical University, China-Japan Friendship Hospital.
The main drafters of this section. Hu Jianping, Hao Huiying, Tang Xuejun, Wang Cunku, Hu Wensheng, Chen Yizhou, Yang Zuosen, Guan Zhengtao, Yang Bo,
Xiao Xingzheng, Zhang Xiaoxiang, Shao Wei, Zhang Tieshan, Xu Fenglong, Li Yan, Liu Qingwen, Meng Qingyun.
Resident Health Card Technical Specifications Part 2.User Card Technical Specifications
1 Scope
This part of WS/T 543 stipulates the national unified resident health card user card number coding rules, card medium, card surface, terminal connection
Requirements, card data standards, data security and applications.
This section is applicable to the joint issuance of health administrative departments, medical and health institutions, and third parties that produce, issue, and use resident health cards
Institutions and production enterprises.
2 Normative references
The following documents are indispensable for the application of this document. For dated reference documents, only the dated version applies to this document.
For undated references, the latest version (including all amendments) applies to this document.
3 Terms and abbreviations
3.1 Terms and definitions
The following terms and definitions defined in WS/T 543.1 apply to this document.
3.1.1
Symmetric key
The key used in the symmetric encryption algorithm.
3.1.2
Asymmetric key
The keys used in asymmetric encryption algorithms include public and private keys.
3.1.3
Public key
A key that can be used by the public in an asymmetric key pair used by an entity. In a digital signature scheme, the public key is used for verification.
3.1.4
Private key
The key used only by the entity in the asymmetric key pair used by an entity. In a digital signature scheme, the private key is used for signing.
3.1.5
Digital signature
An asymmetric encryption transformation of data. This transformation allows the data receiver to confirm the source and integrity of the data and protect the data sent
The data sent by the party and the data received by the receiver are not tampered with by a third party, and the data sent by the data sender is protected from tampering by the receiver.
3.1.6
Biomarker
Some specific biological characteristics of humans are hereditary and lifelong, such as blood type.
3.1.7
Medical alert
Information that the patient needs to remind the doctor’s attention during medical treatment, emergency or rescue, including disease history, internal devices, history of drug allergy,
History of intolerance to certain substances, etc.
3.2 Abbreviations
Abbreviations and symbols indicate applicable to this document, see Table 1.
4 Card number coding rules
The card number of the resident health card is the resident ID number, see GB 11643.
5 Card media
5.1 Card media selection
The resident health card is a high-security CPU card, adopts a non-contact communication mode, conforms to the ISO /IEC 14443 communication protocol, and can write data
The memory capacity is not less than 32K bytes, which is an encrypted non-volatile memory.
5.2 Card body material
The card body material uses ordinary PVC.
5.3 Card making requirements
The resident health card manufacturing institution shall meet the following conditions.
a) Resident health card chips and card manufacturing institutions should have the registration identification number and registration certificate assigned by the National IC Card Registration Center;
b) The resident health card chip should pass the EAL4 mandatory safety certification of China National Information Security Certification Center;
c) The resident health card manufacturing institution shall obtain the ICCR registration certificate of the National Integrated Circuit Center and the national IC card production license;
d) The Resident Health Card Operating System (COS) shall pass the EAL4 mandatory safety certification of China National Information Security Certification Center;
e) The resident health card should be tested for compliance by the relevant testing agency designated by the National Health and Family Planning Commission, and obtain product inspection
Test qualification report;
f) If the resident health card adds financial applications, the financial application part should follow the relevant requirements of the People's Bank of China.
6 card surface
6.1 Card appearance specifications
The shape of the resident health card is a rectangle with rounded corners, and the shape and dimensions are shown in Table 2 and Figure 1 respectively.
6.2 Chip location
The placement of the resident's health card chip should not affect the use of the card.
6.3 Printing style
6.3.1 The back style of the card without financial function
The back of the card should include the following elements. cardholder’s photo, cardholder’s name, gender, ethnicity, resident health card number, resident health card
Number bar code, name of the issuer, and official seal of the issuer. The reference layout on the back of the card is shown in Figure 2, and the parameters are shown in Table 3.
Unit. mm
Figure 2 Reference layout on the back of the card
6.3.2 The back style of the card in the reserved financial function area
The back of the card should include the following elements. cardholder’s photo, cardholder’s name, gender, ethnicity, resident health card number, resident health card
No. barcode, name of the issuing institution, and official seal of the issuing institution. The layout of the back of the card is shown in Figure 3, and the parameters are shown in Table 4.
6.3.3 Card front style
The front of the card should include the following elements. resident health card logo pattern, card name (resident health card) and resident health card supervision department (national
Supervised by the administrative department of household health and family planning). The front layout of the card is shown in Figure 4, and the parameters are shown in Table 5.
6.3.4 The back style of the resident health card co-branded card
6.3.5 The front of the resident health card co-branded card
The background color, pattern, "resident health card and logo" on the front of the card shall be subject to the vector file provided by the National Health and Family Planning Commission.
The face should include the identification and name of the resident health card (resident health card). The front layout of the card is shown in Figure 6, and the parameters are shown in Table 6..
Unit. mm
6.3.6 Card surface color standard and pattern
See Table 7 for chromaticity difference and tolerance.
7 Card Data Standard
7.1 Data Frame
7.1.1 Health card data classification
Resident health card data is divided into four categories. identification data, card identification data, basic health data, and management data. The framework is shown in Figure 7.
Show.
Figure 7 Schematic diagram of the data framework of residents' health card
7.1.2 Cardholder identification data
Identification data refers to the unique identification of the cardholder, including ID, demography, contact information, etc.
7.1.3 Card identification data
Card identification data refers to basic data related to residents' health cards and card issuers, including basic card information, card issuer information, etc.
7.1.4 Basic health data
Basic health data refers to static data related to cardholder emergency and first aid, including biometric identification, immunization, medical warnings, etc.
7.1.5 Management data
Management data refers to the dynamic data related to the cardholder's basic diagnosis and treatment activities, including outpatient summary, medical record homepage, expense settlement information, etc.
7.2 Data Standard
Resident health card data standards should follow the WS 363, WS 364, and WS 365 regulations, and meet the relevant requirements of WS 537.
7.3 Data format
The data format of the resident health card should follow the WS 363, WS 364, and WS 365 regulations, and the data element attributes and code requirements should follow WS 537
According to the relevant provisions in the relevant regulations, the corresponding relationship between data items and data element names is shown in Table 8.
8 Data security
8.1 Algorithm
8.1.1 Resident health card adoption algorithm
The resident health card adopts the symmetric algorithm SM1 algorithm, the asymmetric algorithm SM2 algorithm and the hash algorithm SM3 issued by the State Cryptography Administration
algorithm.
8.1.2 SM1 Algorithm
The packet length of the SM1 algorithm is 128 bits, and the key length is 128 bits.
8.1.3 SM2 Algorithm
The SM2 algorithm in this specification is used for the generation and verification of certificates, and the generation and verification of signature data. This specification uses 256-bit Fp (prime
Number field) on the elliptic curve parameters. The parameters involved include.
8.1.4 SM3 Algorithm
SM3 algorithm generates a 32-byte hash value for message input of any length.
8.2 Basic safety requirements
8.2.1 Coexisting Applications
Each application on the resident health card should be placed in a separate DF, that is, a "firewall" should be designed between applications to prevent
Prevent illegal access across applications.
8.2.2 Independence of keys
The encryption/decryption key used for a specific function (such as reading data) cannot be used by any other functions, including those stored in residents
The keys in the health card and the keys used to generate, derive and transmit these keys.
8.3 Storage of keys and personal passwords
The resident health card should be able to ensure that the asymmetric private key or symmetric encryption key used for the selected encryption (decryption) algorithm is not authorized
Will not be leaked out.
If a personal password is used, it should be stored safely in the resident's health card and will not be leaked under any circumstances.
8.4 Secure messaging
8.4.1 Purpose of Secure Message Transmission
The purpose of secure message transmission is to ensure the reliability, integrity and authentication of the sender. Data integrity and recognition of the sender
The authentication is realized by using MAC. The reliability of the data is guaranteed by encrypting the data domain.
8.4.2 Security message transmission format
The format of the secure message transmission shall follow the provisions of GB/T 16649.4.When the second nibble of the CLA byte is equal to the hexadecimal number 4'
When it is time, it indicates that the sender's command data should be transmitted in a secure message.
8.4.3 Message integrity and verification
8.4.3.1 MAC
MAC is generated using all elements of the command (including the command header). The integrity of a command, including the command data field (if
If it exists, the data elements in) can be guaranteed by secure message transmission.
8.4.3.2 Location of MAC
MAC is the last data element in the command data field.
8.4.3.3 MAC length
The length of MAC is 4 bytes.
8.4.3.4 MAC key generation
The MAC process key used in the security information processing is generated according to the process key generation process described in 9.6.application
The maintenance key is used to generate the MAC process key.
8.4.3.5 MAC calculation
Use SM1 algorithm CBC group encryption to generate MAC, the steps are as follows.
a) Take the 16-byte hexadecimal number 00' as the initial variable;
b) Connect the following data together in order to form a data block.
c) Divide the data block into 16-byte data blocks, labeled D1, D2, D3, D4, etc. The final data block may be
1-16 bytes;
8.4.4 Data reliability
8.4.4.1 Calculation of data encryption key
To ensure the confidentiality of the plaintext data in the command, the system encrypts the data.
The data encryption process key used in the security message processing is generated in the manner described in 9.6.Application maintenance key is used to generate
Data encryption process key.
8.4.4.2 Structure of encrypted data
When the plaintext data required in the command needs to be encrypted, it must first be formatted as a data block of the following form, and then the entire data block is used
Data encryption technology is used for encryption.
--The length of the plaintext data, excluding fill characters (LD);
- Plaintext data;
-Fill characters.
8.4.4.3 Data encryption calculation
Data encryption calculation, as shown in Figure 9, the steps are as follows.
8.4.4.4 Data decryption calculation
The data decryption calculation is shown in Figure 10.The steps are as follows.
a) Decompose the data block in the command data field into 16-byte data blocks, labeled D1, D2, D3, D4, etc. Each number
The data block is decrypted using the data encryption process key generated by the method described in 9.6;
b) After the calculation, all decrypted data blocks are linked together in the order (O1, O2, etc.). The data block consists of LD, Ming
Composition of text data and filling characters;
8.5 Sub-key decentralization
As shown in Figure 11, the dispersion factor of the subkey is 8 bytes. Use the specified dispersion factor to splice the inverse value of the dispersion factor as input data, and add
Secret calculation, the 16-byte result is used as the subkey.
Figure 11 Subkey calculation method
8.6 Generation of process key
As shown in Figure 12, the process key for MAC and data encryption is a key generated with variable data. After the process key is generated, it can only be in a certain process
Use it once. The input data is an 8-byte random number spliced with 8-byte all 00'.
Figure 12 Process key generation
8.7 Authentication of operation authority
8.7.1 Purpose of operation authority authentication
The purpose of operation authority authentication is to verify the legitimacy of the terminal's read and write operations on the data in the card.
8.7.2 Length of authentication data
In this section, the length of authentication data is specified as 8 bytes.
8.7.3 Key generation during operation authorization authentication
The operation authorization authentication process key used in the operation authorization authentication process is the key generated with variable data in the authentication process, according to
Produced by the method described in 9.6.
The authentication key of the operation authority authentication encryption algorithm key is used to generate the operation authority authentication process key.
After the process key is generated, it can only be used once in the authentication process.
The input data is the variable data (such as a random number) referenced by the authentication command.
8.7.4 Calculation of authentication data
As shown in Figure 13, the original data is encrypted using the key of the operation authorization authentication process described in 9.6, and the left and right 8 bytes of the encryption result are XORed.
To the authentication data.
Figure 13 Discrimination data calculation
8.8 Digital signature generation and verification
The steps of digital signature generation and MSG signature for a message composed of arbitrary long data are as follows.
8.9 Security planning
The data on the card is divided into read-only data area, write-only data area, and readable and writable data area according to application safety requirements. Distribution of authority of each user organization,
According to different application requirements, configure the SAM card for secure data access.
The SAM card is embedded in the resident health card terminal equipment to provide high-level security protection for the system. SAM card and terminal can be regarded as one
body. The SAM card stores multiple sets of master keys with different versions and different indexes. All master keys must usually be
Download to the SAM card. If the master key needs to be modified during the use of the terminal, a secure message must be used. The implementation of this operation must
Completed under special authorization. To avoid spurious operations, the different types of master keys stored in the SAM card must be compatible with different specific applications.
Use in combination with operation. The SAM card is required for security protection when operating the resident health card application on the terminal. Different institutions
The type of key loaded in the issued SAM card is determined by the type of application supported by the institution.
8.10 Key mechanism
8.10.1 Symmetric key
For the symmetric key used by the system, use a specific dispersion factor as input data, do encryption calculations, and use the result as a subkey.
The key generation mechanism in the system is shown in Figure 14.
8.10.2 Asymmetric key
8.10.2.1 Secondary Asymmetric Key System of Resident Health Card
The asymmetric key system of the resident health card adopts a secondary structure, as shown in Figure 15.
Figure 15 Asymmetric key system
The resident health card root key management institution is responsible for issuing the public key certificate of the card issuing institution. Root key management authority private key
Keep and ensure its privacy and security.
The card issuer is responsible for issuing the public key certificate of the terminal SAM, and the card issuer’s private key is kept by the card issuer to ensure its privacy and security.
The issuing certificate of the card issuing institution is generated using the signature of the root private key of the resident health card root key management institution.
The certificate of the terminal SAM card is generated by the issuing institution using the private key to sign the terminal public key and certificate information.
8.10.2.2 Use of certificate key
The certificate key is used as shown in Figure 16.The settlement agency terminal locates the root public key through the root public key index, and uses the root public key to verify the issuer’s card
The certificate and obtain the public key value of the card issuer, and then use the public key of the card issuer to verify the terminal SAM card certificate and obtain the public key of the SAM card.
After the settlement agency terminal obtains the public key of the SAM card, it can use the public key to verify the signature data in the card.
Figure 16 Certificate key usage
8.10.2.3 Types of public keys used by residents' health cards
Three types of public-private key pairs are used in the public key authentication system of resident health cards. root public-private key pair, card issuer public-private key pair and terminal SAM
The card public and private key pairs have their functions as shown in Table 9.
8.10.2.4 Root certificate file
8.10.2.5 Card issuer public key input file
a) In order to obtain the production-type public key certificate or test-type public key certificate of the issuing institution, the card issuer needs to submit the card issuer to the root key management agency
To apply for a public key certificate, the issuing institution’s public key input file must be submitted when applying.
8.10.2.6 Public key output file of the issuer
The public key certificate file of the card issuer.
9.4 Application process
All applications require that the terminal must be equipped with a resident health card SAM card, and the terminal and the SAM card communicate in a secure manner. application
The process follows the regulations of WS/T 543.3.
Tips & Frequently Asked Questions:Question 1: How long will the true-PDF of WS/T 543.2-2017_English be delivered?Answer: Upon your order, we will start to translate WS/T 543.2-2017_English as soon as possible, and keep you informed of the progress. The lead time is typically 4 ~ 6 working days. The lengthier the document the longer the lead time. Question 2: Can I share the purchased PDF of WS/T 543.2-2017_English with my colleagues?Answer: Yes. The purchased PDF of WS/T 543.2-2017_English will be deemed to be sold to your employer/organization who actually pays for it, including your colleagues and your employer's intranet. Question 3: Does the price include tax/VAT?Answer: Yes. Our tax invoice, downloaded/delivered in 9 seconds, includes all tax/VAT and complies with 100+ countries' tax regulations (tax exempted in 100+ countries) -- See Avoidance of Double Taxation Agreements (DTAs): List of DTAs signed between Singapore and 100+ countriesQuestion 4: Do you accept my currency other than USD?Answer: Yes. If you need your currency to be printed on the invoice, please write an email to [email protected]. In 2 working-hours, we will create a special link for you to pay in any currencies. Otherwise, follow the normal steps: Add to Cart -- Checkout -- Select your currency to pay.
|