WS/T 543.3-2017 English PDFUS$1199.00 · In stock
Delivery: <= 6 days. True-PDF full-copy in English will be manually translated and delivered via email. WS/T 543.3-2017: Resident health card technical specifications - Part 3: Application specification of the user card Status: Valid
Basic dataStandard ID: WS/T 543.3-2017 (WS/T543.3-2017)Description (Translated English): Resident health card technical specifications - Part 3: Application specification of the user card Sector / Industry: Health Industry Standard (Recommended) Classification of Chinese Standard: C07 Word Count Estimation: 48,419 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.3-2017: Resident health card technical specifications - Part 3: Application 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 3.Application specification of the user card ICS 11.020 C 07 WS People's Republic of China Health Industry Standard Technical Specifications for Resident Health Card Part 3.User Card Application Specification 2017-07-25 released 2017-12-01 implementation Issued by the National Health and Family Planning Commission of the People's Republic of China ForewordThis 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 3 of WS/T 543. Drafting organizations of this section. National Health and Family Planning Commission Statistical Information Center, Jiangsu Provincial Health and Family Planning Commission Information Center, Hunan Province Health and Family Planning Commission Information Center, Shijiazhuang Municipal Health and Family Planning Commission, Beijing Municipal Public Health Information Center, Peking Association And hospitals. The main drafters of this section. Meng Qun, Hu Jianping, Hao Huiying, Zhou Hong, Liu Xiaoqiang, Tang Kai, Lei Yonggui, Zhang Jun, Bai Hejian, Zhang Wen Zhong, Zhu Weiguo, Ren Jie, Zuo Yun. Resident Health Card Technical Specifications Part 3.User Card Application Specifications1 Scope of applicationThis part of WS/T 543 specifies the files, data items and data object list of the resident health card, and describes the various items of the resident health card. The operation process clarifies the process of data exchange, information transmission, and data signature and verification in different application scenarios. This section applies to medical and health institutions, third-party joint card issuers, and manufacturing companies that make, issue, and use resident health cards. And units and departments such as the development and maintenance of the resident health card application system.2 Normative referencesThe 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 abbreviations3.1 Terms and definitions The following terms and definitions defined in WS/T 543.1 and WS/T 543.2 apply to this document. 3.1.1 Application Application protocol and related data sets between IC card and terminal. 3.1.2 Command A message sent from the terminal to the IC card, which initiates an operation or requests a response. 3.1.3 Interface device The part of the terminal where the IC card is inserted, including the mechanical and electrical parts. 3.1.4 Response After the IC card processes the received command message, it returns the message to the terminal. 3.2 Abbreviations 4 List of files, data items, and data objects 4.1 File structure The document organization structure in this standard follows the relevant requirements of GB/T 16649.4.The document structure defines the various aspects of the resident health card in the medical field. This is a proprietary application, DDF1 is the application environment for residents’ health cards, and DDF2 is other reserved application environments. From the perspective of the terminal, the file on the IC card is a tree structure. Each branch of the tree is an application data file (ADF) Or a directory definition file (DDF). An ADF is the entry point for one or more application elementary files (AEF). An ADF And its related data files are on the same branch of the tree. A DDF is the entry point of other ADFs or DDFs. 4.2 Application Data File (ADF) From the perspective of the terminal, an ADF is a file that only contains data objects encapsulated in its file control information (FCI). ADF tree The structural requirements are as follows. a) Ability to associate data files with applications; b) Ensure the independence between applications; c) Access to its logical structure can be achieved through application selection. 4.3 Application Basic File (AEF) In this document, an AEF contains one or more original BER-TLV data objects, or an unstructured pure data element. After choosing After a certain application, AEF makes an inquiry through its file identifier. 4.4 File structure mapping Use the following mapping to GB/T 16649.4. a) A special document (DF) defined in GB/T 16649.4 is mapped to an ADF or a DDF. You can access the basic File and DF. The DF at the highest level in the IC card is called the master file (MF); b) An elementary document (EF) defined in GB/T 16649.4 corresponds to an AEF. EF will never be the entry point of another file. 4.5 File references Depending on the type of file, the file can be referenced by file name. Any ADF or DDF in the IC card can be referenced by its DF name. ADF The DF name corresponds to its AID or AID is the beginning of the DF name. Each DF name in an IC card is unique in the card.5 card operation5.1 Overall operation 5.1.1 Overall operation process Including resident health card user card search, power-on initialization, identification of card authenticity, validity period, external authentication read and write permissions, and access Corresponding read and write operations and other services. a) The user card is powered on and reset, and the card is located under the MF; b) Send the SELECT command to select the application environment DDF1 of the resident health card; c) Carry out the internal certification process and conduct internal certification on the card; d) Send the SELECT command and select EF05; e) Send the READ RECORD command to read the card validity period; f) Send the SELECT command to each application file; g) Choose whether to perform external authentication according to the read and write control authority of each application file; h) Read and write operations on corresponding files; i) The process ends. 5.1.2 Flow chart The overall application flow chart is shown in Figure 2. Figure 2 Overall application flow chart 5.2 Internal certification 5.2.1 Internal certification process The internal certification process is as follows. a) The terminal obtains an 8-byte random number from the SAM card; b) Define the original information required for authentication with a length of 8 bytes, such as 1122334455667788; c) The random number is used as the data for the user card process key calculation, and at the same time as the SAM card process key generation factor; d) The terminal prepares the data required for internal authentication. The first to eighth bytes are random numbers, and the ninth to 16th bytes are original information. The 17th byte is the key version; e) The terminal sends a DELIVERY SESSION KEY command to the SAM card to disperse the specified key and generate a process key; f) The terminal sends a CIPHER DATA command to the SAM card to encrypt the original information; g) The terminal will XOR the left and right 8 bytes of the encryption result returned by the SAM card to obtain authentication data A; h) The terminal sends the INTERNAL AUTHENTICTION command to the user card and gets the return value B; i) The terminal compares whether the values of A and B are the same, if the same internal authentication succeeds, otherwise the internal authentication fails; j) The process ends. 5.2.2 Flow chart The internal authentication flow chart is shown in Figure 3. Figure 3 Flow chart of internal certification 5.3 External certification 5.3.1 External certification process The user card can read and write the corresponding file only after passing the external authentication of the corresponding control key. a) Define the original information required for authentication with a length of 8 bytes, such as 1122334455667788; b) The terminal sends a GET CHALLENGE command to the user card to obtain an 8-byte random number; c) The random number is used as the key generation factor of the SAM card process; d) The terminal sends the DELIVERY SESSION KEY command to the SAM card to disperse the specified key and generate the process key; e) The terminal sends a CIPHER DATA command to the SAM card to encrypt the original information; f) The terminal will XOR the left and right 8 bytes of the encryption result returned by the SAM card to obtain the authentication data; g) The terminal prepares the data required for external authentication, where the first to eighth bytes are authentication data, and the ninth to 16th bytes are the original information Information, the 17th byte is the key version; h) The terminal sends an EXTERNAL AUTHENTICATION command to the user card; i) If the status code returned by the user card is '9000', the external authentication is successful, otherwise the external authentication fails; j) The process ends. 5.3.2 Flow chart The external authentication flow chart is shown in Figure 4. Figure 4 Flow chart of external authentication 5.4 App lock 5.4.1 Overview Sending an application lock command to the user card can lock the card temporarily or permanently. After temporarily locking, you can use the app to unlock the life Order to unlock, it cannot be unlocked after permanent locking. In addition, when using the verification method to update the record file or binary file, if the MAC If the number of wrong attempts exceeds the limit, COS will automatically temporarily lock the current application. 5.4.2 Application Locking Process The application lock process is. a) The terminal sends a SELECT command to the user card to select the application area (DF) to be locked; b) The terminal executes an external authentication process, and externally authenticates the LK key under the DF; c) The terminal sends a GET CHALLENGE command to the user card to obtain an 8-byte random number; d) The random number is used as the key generation factor of the SAM card process; e) The terminal sends a DELIVERY SESSION KEY command to the SAM card to disperse the specified STK key and generate a process key key; f) The terminal sends the CIPHER DATA command to the SAM card to perform MAC calculation on the application block (APPLICATION BLOCK) command header. Count g) The terminal sends the MAC value of the APPLICATION BLOCK command to the user card to lock the DF. 5.5 App unlock The application unlocking process is. a) The terminal sends a SELECT command to the user card to select the temporarily locked application area (DF); b) The terminal executes an external authentication process, and externally authenticates the LK key under the DF; c) The terminal sends a GET CHALLENGE command to the user card to obtain an 8-byte random number; d) The random number is used as the key generation factor of the SAM card process; e) The terminal sends a DELIVERY SESSION KEY command to the SAM card to disperse the specified STK key and generate a process key key; f) The terminal sends the CIPHER DATA command to the SAM card to perform MAC on the application unlock (APPLICATION UNBLOCK) command header Calculation g) The terminal sends the MAC value of the APPLICATION UNBLOCK command to the user card to unlock the DF. 5.6 Card lock 5.6.1 Overview When the user card is not allowed to be used again, the card lock command can be executed to permanently lock the user card, and the card cannot be unlocked after being locked. 5.6.2 Card lock process The card lock process is as follows. a) The terminal sends a SELECT command to the user card to select the card root directory (MF) to be locked; b) The terminal executes an external authentication process, and externally authenticates the BK key under the MF; c) The terminal sends a GET CHALLENGE command to the user card to obtain an 8-byte random number; d) The random number is used as the key generation factor of the SAM card process; e) The terminal sends a DELIVERY SESSION KEY command to the SAM card to disperse the specified STK key and generate a process key key; f) The terminal sends a CIPHER DATA command to the SAM card to perform MAC calculation on the card lock (CARD BLOCK) command header; g) The terminal sends the CARD BLOCK command MAC value to the user card to lock the user card. 5.7 Application maintenance Application maintenance includes card lock, application lock, application unlock, data with MAC update. These processes must have the corresponding operating rights Perform the following steps on terminals with limited control keys. a) Pass external certification to meet the safe state of operation; b) The terminal applies for a random number from the user card; c) Send the corresponding application maintenance command, and the card performs the following operations after receiving the command. 1) Use the random number generated in the previous step to generate the process key using the method described in WS/T 543.2 (check the chapter Whether the section is correct); 2) Use the process key to generate MAC and compare it with the MAC in the command message. If the result is consistent, the corresponding function Can be realized, otherwise error status information is sent back. The MAC generation method is described in WS/T 543.2.6 card business applications6.1 Card recognition application (corresponding to MF\\DDF1 data area) 6.1.1 Card identification data area The card identification data area includes EF05, EF06, EF07 and EF08 files. 6.1.2 Reading card to identify data area information 6.1.2.1 Overview Read the basic file (ie EF05, EF06, EF07 and EF08) data in MF\\DDF1 in the user card. 6.1.2.2 Processing flow The specific process is as follows. a) The terminal decides which records to read from the user card according to the execution of the application; b) The terminal selects the DF file where the corresponding record is located, and then selects the corresponding EF file; c) The terminal decides whether to execute according to the execution of the application and the reading control key of the corresponding file defined in WS/T 543.1 External authentication (refer to WS/T 543.1 for reading the control key, and refer to the corresponding chapter of this document for the processing of external authentication commands Section); d) The terminal sends the READ RECORD command to read the specified record, and reads the photo information, then sends the READ BINARY command to read the data; e) The user card judges whether the conditions for command execution are met according to the read control authority required for reading the record, and if not, it returns an error Code to the terminal; if it is satisfied, the user card will read the recorded data, if the reading is successful, the recorded data will be returned to the terminal, otherwise an error will be returned Code to terminal f) The terminal decides whether to continue reading the records in the corresponding EF file according to the result returned by the user card. 6.1.2.3 Flow chart The flow chart of the card reading identification data is shown in Figure 5. Figure 5 Flow chart of card reading recognition data 6.1.3 Write card to identify data area information 6.1.3.1 Overview Update the basic file (ie EF07 and EF08) data in MF\\DDF1 in the user card. 6.1.3.2 Processing flow The specific process is as follows. a) The terminal decides which records in the user card to update according to the execution of the application; b) The terminal selects the DF file where the corresponding record is located, and then selects the corresponding EF file; c) The terminal decides whether to execute according to the execution of the application and the writing control key of the corresponding file defined in WS/T 543.2 External authentication (refer to WS/T 543.2 for writing control keys, and refer to the corresponding chapter of this document for the processing of external authentication commands Section); d) The terminal sends an UPDATE RECORD command with a ciphertext MAC security message to update the specified record. In this process, use Use STKDDF1 to calculate the ciphertext and MAC; the terminal sends an UPDATE BINARY command to update the EF07 data; e) The user card judges whether the conditions for command execution are satisfied according to the write control authority required for writing records, and if not, it returns an error Code to the terminal; if it is satisfied, verify that the ciphertext and MAC are correct (see WS/T for the calculation methods and steps of ciphertext and MAC 543.2 description), if it is correct, write the decrypted plaintext data into the card, otherwise return an error code to the terminal; f) The terminal decides whether to continue to update the records in the corresponding EF file according to the result returned by the user card. 6.1.3.3 Flow chart The flow chart of card writing recognition data processing is shown in Figure 6. Figure 6 Process flow chart of card write recognition data 6.2 Identity recognition application (corresponding to DDF1\\DF01 data area) 6.2.1 Identification data area The identification data area includes EF05, EF06, EF07 and EF08 files. 6.2.2 Read DF01 application data 6.2.2.1 Overview Read the DF01 application data in the user card. 6.2.2.2 Processing flow The specific process is as follows. a) The terminal decides which records to read from the user card according to the execution of the application; b) The terminal selects the DF file where the corresponding record is located, and then selects the corresponding EF file; c) The terminal decides whether to execute according to the execution of the application and the reading control key of the corresponding file defined in WS/T 543.2 External authentication (refer to WS/T 543.2 for reading the control key, and refer to the corresponding chapter of this document for the processing of external authentication commands Section); d) The terminal sends the READ RECORD command to read the specified record; e) The user card judges whether the conditions for command execution are met according to the read control authority required for reading the record, and if not, it returns an error Code to the terminal; if it is satisfied, the user card will read the recorded data, if the reading is successful, the recorded data will be returned to the terminal, otherwise an error will be returned Code to terminal f) The terminal decides whether to continue reading the records in the corresponding EF file according to the result returned by the user card. 6.2.2.3 Flow chart The flow chart of reading DF01 application data processing is shown in Figure 7. Figure 7 Reading DF01 application data processing flowchart 6.2.3 Write DF01 application data 6.2.3.1 Overview Update the DF01 application data in the user card. 6.2.3.2 Processing flow The specific process is as follows. a) The terminal decides which records in the user card to update according to the execution of the application; b) The terminal selects the DF file where the corresponding record is located, and then selects the corresponding EF file; c) The terminal decides whether to execute according to the execution of the applic......Tips & Frequently Asked Questions:Question 1: How long will the true-PDF of WS/T 543.3-2017_English be delivered?Answer: Upon your order, we will start to translate WS/T 543.3-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.3-2017_English with my colleagues?Answer: Yes. The purchased PDF of WS/T 543.3-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 Sales@ChineseStandard.net. 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. |