Valid

WS/T 543.3-2017Resident health card technical specifications - Part 3: Application specification of the user card (English PDF)

Preview PDF

This is a limited preview

Buy now to download the full PDF (32 pages)

Need quotation for your management?

Get a formal quotation for WS/T 543.3-2017 in 30 minutes.

Issued by

National Health and Family Planning Commission of the People's Republic of China

Level / Type

National · Recommended

Issue date

July 25, 2017

Implementation date

December 1, 2017

Scope

WS/T 543.3-2017 (Resident health card technical specifications - Part 3: Application specification of the user card) is available as an English-translated PDF.

WS/T 543.3-2017 — This 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.

Found what you need?

Document preview — WS/T 543.3-2017

National Standard of the People's Republic of China

ICS
11.020
Classification
C 07

Issued by: National Health and Family Planning Commission of the People's Republic of China

Contents

  • Foreword
  • 1 Scope of application
  • 2 Normative references
  • 3 Terms and abbreviations
  • 3.1 Terms and definitions
  • 3.2 Abbreviations
  • 4 List of files, data items, and data objects
  • 4.1 File structure
  • 4.2 Application Data File (ADF)
  • 4.3 Application Basic File (AEF)
  • 4.4 File structure mapping
  • 4.5 File references
  • 5 Card operation
  • 5.1 Overall operation
  • 5.2 Internal certification
  • 5.3 External certification
  • 5.4 App lock
  • 5.5 App unlock
  • 5.6 Card lock
  • 5.7 Application maintenance
  • 6 Card business applications
  • 6.1 Card recognition application (corresponding to MF\\DDF1 data area)
  • 6.2 Identity recognition application (corresponding to DDF1\\DF01 data area)
  • 6.3 Application of basic health data (corresponding to DDF1\\DF02 data area)
  • 6.4 Management business application (corresponding to DDF1\\DF03 data area)

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 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.

1 Scope of application

This 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 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 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 operation

5.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 applications

6.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 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;

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), 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.2.3.3 Flow chart

The processing flowchart of writing DF01 application data is shown in Figure 8.

Figure 8 Data processing flowchart for writing DF01 application

6.3 Application of basic health data (corresponding to DDF1\\DF02 data area)

6.3.1 Basic health data area

The basic health data area includes EF05, EF06, EF07 and EF08 files.

6.3.2 Read DF02 application data
6.3.2.1 Overview

Read the DF02 application data in the user card.

6.3.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 the external file according to the execution of the application and the reading control key of the corresponding file defined in WS 543.2.

Internal authentication (refer to WS/T 543.2 for the read control key, and refer to the corresponding chapter of this document for the processing of external authentication commands);

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.3.2.3 Flow chart

The flow chart of reading DF02 application data processing is shown in Figure 9.

Figure 9 Reading DF02 application data processing flowchart

6.3.3 Write DF02 application data
6.3.3.1 Overview

Update the DF02 application data in the user card.

6.3.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. (For the situation of writing the control key, please refer to WS/T 543.2.For the processing of external authentication commands, please refer to the corresponding chapter);

d) The terminal sends an UPDATE RECORD command with a ciphertext MAC security message to update the specified record;

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), 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.3.3.3 Flow chart

The processing flowchart of writing DF02 application data is shown in Figure 10.

Figure 10 Process flow chart of writing DF02 application data

6.4 Management business application (corresponding to DDF1\\DF03 data area)

6.4.1 Manage business data area

The management business data area includes the hospitalization information index file (DF03\\EF05) and hospitalization information (DF03\\EE01-03) in the user card.

Outpatient information index file (DF03\\EF06) and outpatient information (DF03\\ED01-05). Refer to WS/T 543.2 for the calculation method and steps of MAC Described in.

6.4.2 Record hospitalization information
6.4.2.1 Overview

Read and write the hospitalization information index file (DF03\\EF05) and hospitalization information (DF03\\EE01-03) in the user card.

6.4.2.2 Process of recording hospitalization information

The specific process is as follows.

a) The terminal obtai...

......
This preview omits tables, figures, formulas and parts of the technical clauses. The complete document — 32 pages — is available in the English PDF.

How to Download WS/T 543.3-2017

  1. 1

    Add to cart

    Click "Download PDF" on this page and choose "Buy this standard". You can add more standards before checkout.

  2. 2

    Checkout

    Enter your email and billing details. Payment is processed securely by Stripe (cards or bank transfer). Prefer bank details? Request a quotation (min. order $300).

  3. 3

    Instant delivery (0–9 sec)

    Delivery is automatic: within seconds of payment you'll receive an email with a secure download link. The link stays valid for 72 hours.

  4. 4

    Invoice included

    A tax invoice is attached to the confirmation email. Need a custom invoice? Contact us.

Related Standards

English PDF
32 pages
Instant delivery (0–9 sec)
Invoice included
View Cart

Secure payment via Stripe

Payments accepted

VisaMastercardAmerican ExpressApple PayGoogle PayStripe

WS/T 543.3-2017

$1,174.00