GB/T 43779-2024Cybersecurity technology - Technical specification for caller identity authentication using crypto tokens (English PDF)

1 Scope

The document lays down the technical requirements for transmitting, verifying and displaying the trusted identity of the calling user in communication on the basis of a crypto token, and describes the corresponding test and evaluation methods.

It applies to guiding the system design, the production and the testing of the transmission, verification and display of the trusted identity of the calling user.

2 Normative references

The documents cited are GB/T 15843.2, entity authentication using symmetric encipherment algorithms; GB/T 15843.3, entity authentication using digital signature techniques; GB/T 16262.1, abstract syntax notation one; GB/T 20518, public key infrastructure, digital certificate format; GB/T 32905, the SM3 cryptographic hash algorithm; GB/T 32907, the SM4 block cipher algorithm; and GB/T 32918.2, the SM2 elliptic curve public key cryptographic algorithm, Part 2, digital signature algorithm.

3 Terms and definitions

3.1 caller: originator of a call connection, or the intelligent terminal equipment of the originator of a call connection.

3.2 called: receiver of a call connection, or the intelligent terminal equipment of the receiver of a call connection.

3.3 carrier: network service provider of the caller or of the called party. A note adds that the carrier of the caller and the carrier of the called party may be the same or different.

3.4 crypto token: data message signed by a trusted user using cryptographic technology and submitted to the called user for verification, which serves to represent the identity of the signer. A note adds that the data message is also called the cryptographic identity token or the identity token.

3.5 identity ticket issuer: body that generates and issues trusted identity tickets for users.

3.6 identity ticket issuer authorization authority: authorizing party of the identity ticket issuer, which carries out authorization management by digitally signing the identity ticket issued to the identity ticket issuer.

3.7 identity ticket acquisition service: service that provides the called user with the means of querying the identity ticket of the caller. A note adds that the service is implemented in the form of a cloud service or of other network services and is accessed in the calling or the called network.

3.8 privilege credential: data obtained by a trusted user by computation with symmetric cryptographic technology, which shows that the user holds the right of use. A note adds that the privilege credential is valid only for the current use.

3.9 token message service: service that provides the delivery of token messages for the calls of trusted users. A note adds that the token message service is deployed on the Internet, in the calling network or in the called network.

3.10 trusted identity services system: system that provides trusted identity management and attestation or verification services.

3.11 trusted identity ticket: digital ticket issued by the trusted identity services system that contains the trusted identity information of a communicating party together with its public key.

3.12 trusted user: caller or called party that has applied for and obtained a trusted identity ticket. A note adds that a communicating party that can verify and display the caller trusted identity but does not necessarily hold a trusted identity ticket itself is called a user in the document.

3.13 trusted identity: identity that has been certified by a third party and that can be matched with the behaviour of the user.

4 Symbols and abbreviations

4.1 Symbols. ID with the index i is the identity identifier issued by the operating system to the i-th trusted user for authentication when the service is used; it is randomly generated data of 128 bit, so as to protect the personal information of the user. K with the index i is the symmetric key corresponding to that ID, transmitted securely by the carrier to the i-th trusted user. RK is a master key by which the carrier that manages trusted users manages the users.

4.2 Abbreviations. CA is the certificate authority; CHAKEN is caller identity authentication using crypto tokens; DER is the distinguished encoding rules; SIP is the session initiation protocol.

5 Overview

5.1 Basic principle. The CHAKEN technique laid down in the document aims to present the trusted identity of the caller securely to the called party. To present the trusted identity, a trusted identity ticket is first issued to the trusted user who has been vetted; that ticket contains the verified caller user information available for display, which may be text, a picture, an audio signal or video information. The called party then verifies the identity of the caller by means of the crypto token and the trusted identity ticket of the caller, so making sure that the caller is the holder of that trusted identity ticket.

5.2 Issuing architecture. In the CHAKEN technique the identity management of trusted users follows a two-layer pattern made up of the identity ticket issuer authorization authority and the identity ticket issuer. The authorization authority is the root of trust of the CHAKEN system; its self-signed identity ticket is pre-installed in the cryptographic module of the user by a trusted means, or a trusted download route is provided to the user. An identity ticket issuer needs the permission of the authorization authority and shall have obtained a valid identity ticket issued by it before it can issue identity tickets to ordinary users. Figure 1 shows the issuing architecture, with the authorization authority above, the identity ticket issuers below it, the trusted identity subscribers below those and the trusted identities at the bottom.

5.3 Issuing modes. Two modes are used. In the first, the identity ticket issuer vets the user information directly and issues the trusted identity ticket to the user. In the second, a subscriber of the identity ticket issuer, that is an organisational user or a group user, vets its own subordinate staff and the identity ticket issuer then issues the trusted identity ticket to that member of staff. The connecting lines in Figure 1 represent the issuing paths of the trusted identity ticket: for a given subscriber, the trusted vetting of the identity tickets of its staff may be carried out by the subscriber itself, but the organisation information in the identity information of the member of staff can only be the organisation information of the subscriber as vetted by the identity ticket issuer.

5.4 Verification of the trusted user. The CHAKEN technique verifies a trusted user in a pattern of two layers of ticket plus one token: the root ticket of the authorization authority verifies the identity ticket of the identity ticket issuer, the identity ticket of the issuer then verifies the trusted identity ticket of the calling user, and finally the trusted identity ticket of the calling user verifies the crypto token that the calling user has sent.

5.5 Basic flow. Figure 2 shows the basic flow of authenticating the calling user on an existing telephone call. As a precondition, marked 0, the calling terminal obtains, online or offline, the trusted identity ticket issued by the identity ticket issuer before it places the call. At step 1 the caller selects the called number and one of its own identities, of which it may have one or several; if that is a trusted identity, a crypto token is built and sent to the token message service. At step 2 the caller places the call to the called party through the calling network, and the calling network, having received the call, places the call to the called network through a transit network. At step 3 the called network sends the call request of the caller to the called terminal. At step 4 the called terminal, having received the call request, uses the index to query the token message service for the crypto token the caller has sent. At step 5, if the trusted identity ticket of the caller is not cached in the called terminal, the called terminal queries the identity ticket acquisition system by the caller number; once verification is correct, the trusted identity of the caller is displayed on the user interface, and the user, or a rule the user has defined, then decides whether to accept or reject the call.

5.5 Use with SIP. When the call uses the SIP protocol, the SIP call message can carry the query address and the query index of the caller identity token, or can carry the identity token directly, and can also carry both the token and the identity ticket.

6 Security requirements

6.1.1 Identity ticket issuer authorization authority. The authorization authority shall draw up its own certification practice statement, covering its responsibilities and obligations in the issuing and use of identity tickets, the process by which it issues identity tickets to subordinate identity ticket issuers, and the definition of the security policies bearing on the tickets. It shall issue itself a self-signed ticket in the format required by GB/T 20518, and that self-signed ticket shall be made available for users to download by at least two means. It should set the value of pathLenConstraint in the Basic constraints extension of its self-signed identity ticket to 1. The ticket issuing system it uses shall run offline and shall have no connection of any kind, wireless or wired, to any network. The identity ticket issued to an identity ticket issuer shall follow the format required by GB/T 20518 and be encoded by the DER method, and the content of the ticket issued shall satisfy the data content requirements of 6.3. The identity ticket issued to an identity ticket issuer shall carry the Basic constraints extension, whose meaning shall be set in accordance with GB/T 20518, and pathLenConstraint should be set to 0 so as to prevent identity ticket issuers from being nested.

6.1.2 Identity ticket issuer. The identity ticket issuer shall draw up and publish its own ticket issuing practice statement addressing the ticket security policy; the statement shall describe the risk response and compensation policy prepared for the legal and economic consequences of errors in the tickets it issues or of fraudulent conduct arising from those tickets. It may provide an online service over the Internet and may also provide an offline service. The trusted identity ticket it issues to a user shall follow the format required by GB/T 20518 and be encoded by the DER method, and the content and format of the ticket issued shall satisfy 6.3 and Annex A. It may issue identity tickets only to trusted users and shall not issue identity tickets to other ticket issuers. It should support the cloud tenant mode, that is the issuing service for subscribers: a subscriber may use its administrative account with the identity ticket issuer to enter and vet its own staff, and the identity ticket issuer may then, in accordance with its own security requirements, automatically issue to a user vetted by the subscriber administrator a staff identity ticket bearing the name of the subscriber. The practice statement shall make clear that the identity ticket issuer bears the same legal liability, under the statement it has published, whether the ticket is issued by it directly or is issued after vetting by a subscriber administrator.

6.1.3 Calling and called terminals. The terminal shall have installed a cryptographic module certified by the national cryptography authority that can generate the authentication key pair used by the algorithm of GB/T 32918.2 and can complete the application for, the download of and the destruction of the identity ticket. The calling terminal and the called terminal shall be able to download and store the self-signed identity ticket of the authorization authority by a secure means. The terminal shall be able to apply for and accept not fewer than five identity tickets.

6.2.1 Calling terminal. When a trusted user places a call, it shall build the crypto token according to the content requirements of 6.4 on the basis of the trusted identity ticket selected, and send it to the token message service; the data content and format of the crypto token shall conform to Annex B. A trusted user that needs to use the token message service shall obtain the randomly generated ID and the service key securely from the body that operates the token message service, and may apply to that body for a new ID and key according to some policy, so as to prevent the message service system or a network eavesdropper from tracking it by means of the ID. In a normal call the token shall be delivered to the token message service first and the voice call placed afterwards; when the call uses the SIP protocol, the crypto token format shall conform to Annex C and shall be combined in the INVITE message of the SIP call for delivery.

6.2.2 Called terminal. Having received the call, the called party shall compute two index values from the caller number, its own number and the current time, following the computation method of Annex B, and send those two index values to the token message service in order to query the crypto token the caller has sent. Once the crypto token of the caller has been obtained, the privilege credential in the token may be used, where needed, to query the identity ticket acquisition system for the trusted identity ticket of the calling user. The called party shall verify the trusted identity ticket of the calling user in accordance with the content laid down in GB/T 20518; verification shall start from the root ticket of the authorization authority and proceed through the trusted identity tickets in the ticket chain one by one, and once it is finished the verified caller identity ticket shall be used to verify the identity token signed by the caller. The called terminal may, according to a storage security policy defined by the user, cache the verified identity ticket of the identity ticket issuer in the cryptographic module, and may also cache the verified trusted identity ticket of the calling user in the address book; when a cached ticket is used, a different colour or different wording shall be used when the identity is displayed, to remind the user that a cached identity ticket is being used, and where necessary the user may be prompted to refresh the ticket query, or the user may set a time for automatic ticket refresh.

6.2.2 Called terminal, display. Once verification is finished, the called terminal shall display on the call home page at least the following information, the display method being given in Annex D for reference: the country name and the organisation name of the identity ticket issuer, marked as the issuer of the identity; the policy of the caller identity ticket, or, where the identity ticket carries no policy, an indication that the caller is an ordinary user; the basic information of the trusted identity ticket, comprising the country name, the organisation name, the organisational unit name and the user or role name; the video, graphic or audio information contained in the ticket, at least one of which shall be taken in order and displayed; and the product name and the certification certificate number of the cryptographic module that supports the cryptographic operations. The called party terminal shall provide a ticket viewing function through which the called user can view all the information in the caller identity ticket.

6.2.3 Token message service. The body that operates the token message service may set the rights of use of the service. It shall set its own operating master key RK in accordance with the algorithm requirements of GB/T 32907 and allocate to each trusted calling user it serves a random and distinct user ID of 128 bit; using the current operating master key RK and the algorithm of GB/T 32907 it encrypts the ID of the trusted user to obtain the service key of that user, and it shall deliver the ID and the key to the user terminal securely, optionally by encrypting that information with the public key held in the identity ticket of the user. The token message service may use the privilege credential to check the right of the caller to use the service: the ID in the credential is encrypted with the operating master key RK to obtain the key, that key is used to decrypt the last 128 bit of the credential, and the check is passed if the result is the integer representation, 32 bit long and in big-endian byte order, of the number of seconds of the time value in GeneralizedTime since 1 January 2020 at 00:00:00, concatenated with the string Mess and with a 64 bit random number.

6.2.3 Token message service, robustness and protocol. The token message service should raise its resistance to denial of service attacks by using load balancing so that the message service is not affected by ordinary denial of service attacks; by monitoring the data traffic from a single source address and refusing calls from one address in excess of the normal traffic, including abnormal calls from trusted users; and by using the identity ticket to carry out further identity verification for suspect addresses. When accepting token messages and query requests, the service shall support at least the connectionless UDP protocol: it shall support at least the upload of a crypto token by a message in the form of the string PUT followed by the Identity token sent over UDP, and the query by a message in the form of the string GET followed by the first token index, or the string OR followed by the second token index, sent over UDP. The token message service shall monitor query requests so as to prevent abnormal token queries.