This standard specifies the entity authentication mechanism using symmetric encryption algorithms. GB 15843.2-1997 Information technology security techniques Entity authentication Part 2: Mechanisms using symmetric encryption algorithms GB15843.2-1997 Standard download decompression password: www.bzxz.net

GB 15843. 2—1997
This standard is equivalent to the international standard ISO/IEC9798-2:1994 "Information Technology Security Technology Entity Authentication Part 2: Mechanisms using symmetric encryption algorithms".
This standard specifies the entity authentication mechanism implemented by symmetric encryption algorithms, which is suitable for use in my country. GB15843 consists of the following parts under the general title "Information Technology Security Technology Entity Authentication Mechanism": - Part 1: General model
GB15843 also consists of the following parts under the general title "Information Technology Security Technology Entity Authentication": - Part 2: Mechanisms using symmetric encryption algorithms - Part 3: Entity authentication using public key algorithms - Part 4: Mechanisms using cryptographic check functions - Part 5: Mechanisms using zero-knowledge technology Appendix A, Appendix B, and Appendix C in this standard are all informative appendices. This standard was proposed by the Ministry of Electronics Industry of the People's Republic of China. This standard is under the jurisdiction of the Standardization Institute of the Ministry of Electronics Industry. The drafting units of this standard are the 30th Institute of the Ministry of Electronics Industry and the Standardization Institute of the Ministry of Electronics Industry. Who are the main drafters of this standard: Gong Qimin, Fang Shumei, Du Mingyu, Li Guiru, Xiang Weiliang. 603
GB 15843. 2 -- 1997
ISO/IEC Foreword
ISO (International Organization for Standardization) and IEC (International Electrotechnical Commission) are specialized organizations for standardization worldwide. National member bodies (which are all members of ISO or IEC) participate in the formulation of international standards for specific technical ranges through various technical committees established by international organizations. The technical committees of ISO and IEC cooperate in areas of common interest. Other official and non-official international organizations in contact with ISO and IEC can also participate in the formulation of international standards. For information technology, ISO and IEC have established a joint technical committee, namely ISO/IECJTC1. The draft international standard proposed by the joint technical committee needs to be circulated to national member bodies for voting. To publish an international standard, at least 75% of the national member bodies participating in the voting need to vote in favor.
International Standard ISO/IEC 9798-2 was prepared by Subcommittee SC 27 (IT Security Techniques) of Joint Technical Committee ISO/IEC JTC 1 (Information Technology).
ISO/IEC 9798 consists of the following parts under the general title "Information Technology Security Techniques Entity Authentication Mechanisms": Part 1: General Model
Part 3: Entity Authentication Using Public Key Algorithms ISO/IEC 9798 also consists of the following parts under the general title "Information Technology Security Techniques Entity Authentication": Part 2: Mechanisms Using Symmetric Encryption Algorithms Part 4: Mechanisms Using Cryptographic Check Functions Part 5: Mechanisms Using Zero-Knowledge Techniques Note: The general titles before Parts 1 and 3 above will be adjusted to the general titles before Parts 2, 4 and 5 in the next revision. Other parts may follow. Annexes A, B and C of this standard are provided for information only. 60.
National Standard of the People's Republic of China
Information technology-Security techniques--Entity authentication-Part 2: Mechanismsusing symmetric encipherment algorithmsGB15843.2—1997
idtISO/IEC9798-2:1994bzxZ.net
This standard specifies entity authentication mechanisms using symmetric encipherment algorithms. Four of them are authentication mechanisms between two entities without the participation of a trusted third party, while two of these four mechanisms are single entity authentication (one-way authentication) and the other two are mutual authentication between two entities. The remaining mechanisms require the participation of a trusted third party in order to establish a public secret key to achieve mutual or one-way entity authentication. The mechanisms specified in this standard use time-varying parameters such as time stamps, sequence numbers or random numbers to prevent previously valid authentication information from being accepted later.
If there is no trusted third party involved and time stamps or sequence numbers are used, only one message needs to be sent for one-way authentication, while two messages are required for mutual authentication. If there is no trusted third party involved and a challenge-response method using random numbers is used, two messages are required for one-way authentication, while three messages are required for mutual authentication. If a trusted third party is involved, any additional communication between an entity and the trusted third party requires two additional transmissions in the communication exchange. 2 Referenced standards
The provisions contained in the following standards constitute the provisions of this standard through reference in this standard. At the time of publication of this standard, the versions shown are valid. All standards are subject to revision, and parties using this standard should explore the possibility of using the latest versions of the following standards. GB15843.11995 Information technology security technology Entity authentication mechanism Part 1: General model (idtISO/IEC9798-1:1991
3 Definitions and notations
This standard uses the definitions and notations in GB15843.1. 4 Requirements
In the authentication mechanism specified in this standard, the entity to be authenticated proves its identity by indicating that it possesses a secret authentication key. This can be achieved by the entity encrypting specific data with its secret key. Any entity that shares its secret authentication key can decrypt the encrypted data. These authentication mechanisms have the following requirements. If any of them is not met, the authentication process will be compromised or cannot be achieved at all. a) The claimant who confirms his identity to the verifier should share a secret authentication key with the verifier when applying the mechanism of Chapter 5. When applying the mechanism of Chapter 6, each entity and a public trusted third party share a secret authentication key respectively. These keys should be known to the relevant parties before the authentication mechanism is officially launched. The method used to achieve this is beyond the scope of this standard. b) If a trusted third party is involved, it should be trusted by both the claimant and the verifier. c) The secret authentication key shared by the claimant and the verifier, or the secret authentication key shared by the entity and the trusted third party, should be known only to the two parties or other parties trusted by both parties. GB 15843. 2 -1997
Note 1: The selection of encryption algorithm and key lifetime should satisfy the requirement that it is computationally infeasible to deduce the key during its lifetime. In addition, the selection of key lifetime should also prevent attacks from known plaintext and chosen plaintext. d) One of the assumptions d1) or d2) must be met. d1) The encryption algorithm and working mode used in the authentication mechanism should provide the receiver with a method to detect whether the data has been forged or tampered with. This requires that the data has sufficient margin and that any modification of the plaintext will result in unpredictable modification of a large number of ciphertext bits. One possible way to provide sufficient redundancy is to append a hash code to the data before encryption. Note 2: Hash functions are standardized in ISO/IEC 10118. If encryption uses a block cipher algorithm and the block length is smaller than the length of the data being encrypted, then any change in a block should be detectable.
d2) The integrity of the encrypted data should be ensured by an independent data integrity mechanism. Note 3: The data integrity mechanism is standardized in GB 15852. 5 Mechanisms not involving a trusted third party
In these authentication mechanisms, entities A and B should share a common secret authentication key KABe before starting the specific operation of the authentication mechanism
These mechanisms require the use of time-varying parameters such as time stamps, sequence numbers or random numbers. The properties of these parameters, especially their difficulty in repeating within the lifetime of the authentication key, are very important for the security of these mechanisms. Additional information is given in Annex B. All text fields specified in the following mechanisms are also applicable to applications outside the scope of this standard (they may be empty). Their relationship and content depend on the specific application. Information on the use of text fields is given in Annex A (informative annex). 5.1 One-way authentication
One-way authentication means that only one of the two entities is authenticated when using this mechanism. 5.1.1-transfer authentication
In this authentication mechanism, the claimant A initiates the process and is authenticated by the verifier B. Uniqueness/timeliness is controlled by generating and verifying a timestamp or sequence number (see Appendix B (Suggested Appendix)). The authentication mechanism is shown in Figure 1.
TokenAB
The token (TokenAB) sent by claimant A to verifier B is in the form of: B
(TAIBHText1)
TokenAB = Text leKAb(NA
Here, claimant A uses either sequence number NA or time stamp TA as the time-varying parameter. The specific choice depends on the technical capabilities and environment of the claimant and verifier. Whether to include the distinguishing identifier B in TokenAB is optional. Note: The inclusion of distinguishing identifier B in TokenAB is to prevent the enemy from impersonating entity B and reusing entity A's TokenAB. This inclusion is made optional because the identifier can be omitted in an environment where such attacks will not occur. If entities A and B share a secret key K'AB and K'AB is only used for B to authenticate A, then identifier B can also be omitted. The token becomes: TokenAB = Text l eK'ns(N
Il Texti)
In Figure 1: (1) A sends TokenAB to B. (2) Upon receiving the message containing TokenAB, B decrypts the encrypted part and verifies the correctness of the distinguishing identifier B (if any) and the time stamp or sequence number, thereby verifying TokenAB. 5.1.2 Double-transmission authentication
In this authentication mechanism, the verifier B initiates this process and authenticates the claimant A. Uniqueness/timeliness is controlled by generating and verifying a random number RB (see Appendix B).
The authentication mechanism is shown in Figure 2.
(1) RTextl
(2) TokenAB
The token (TokenAB) sent by the claimant A to the verifier B is in the form of: TokenAB = Text3 Il eKa(R ll B JI Text2) The inclusion of the distinguishing identifier B in TokenAB is optional. Note: The inclusion of the distinguishing identifier B in TokenAB is to prevent the so-called reflection attack, which is characterized by an intruder pretending to be A and "reflecting" the query Re to B. The inclusion of the distinguishing identifier is made optional because the identifier can be omitted in an environment where such attacks do not occur. If entities A and B share a secret key K'AB, and K'An is only used by B to authenticate A, then the distinguishing identifier B can also be omitted. The token becomes:
TokenAB =- Text3 ll eK'A(R ll Text2) In Figure 2: (1) B sends a random number Rg to A and optionally sends a text field Textl. (2) A sends TokenAB to B.
(3) Upon receiving the message containing TokenAB, B decrypts the encrypted part and verifies the correctness of the distinguishing identifier B (if any) and whether the random number R: sent to A in step (1) matches the random number contained in TokenAB, thereby verifying TokenAB.
5.2 Mutual Authentication
Mutual authentication refers to the mechanism by which two communicating entities are authenticated. 5.2.1 and 5.2.2 use the two mechanisms described in 5.1.1 and 5.1.2 respectively to achieve mutual authentication. Both cases require an additional transmission, thereby adding two operational steps. NOTE: A third mechanism for mutual authentication can be composed of two cases of the mechanism specified in 5.1.2, one initiated by entity A and the other by entity B. 5.2.1 Two-transmission authentication
In this authentication mechanism, uniqueness/timeliness is controlled by generating and verifying a time stamp or sequence number (see Appendix B). The authentication mechanism is shown in Figure 3.
(1) TokenAB
3) TokenBA
The format of the token (TokenAB) sent by A to B is the same as that specified in 5.1.1 (2)
BllText1)
TokenAB - Text2 Il eKAB(
The format of the token (TokenBA) sent by B to A is: TokenBA Text leKas(N
TeAText3)
GB15843.2-1997
Whether to include the distinguishing identifier B in TakenAB and whether to include the distinguishing identifier A in TokenBA is (independently) optional.
Note 1: The distinguishing identifier B in TokenAB is to prevent an adversary from impersonating entity B and reusing entity A's TokenAB. For the same reason, TokenBA includes the distinguishing identifier A. The inclusion of the distinguishing identifiers is made optional because one or both of them can be omitted without the possibility of such an attack. If entities A and B share two secret keys K'AB and KBA, which are used for B's authentication of A and A's authentication of B respectively, then the distinguishing identifiers A and B can be omitted. The token becomes: TokenAB = Text2 leR'ANA
(Tx il Textl)
TokenBA = Text4 leK'na(N)
llText3)
In this mechanism, the choice of time stamp or sequence number depends on the capabilities and environment of the claimant and verifier. In Figure 3: Steps (1) and (2) are the same as the one-time transmission authentication specified in 5.1.1. (3) B sends TokenBA to A.
(4) The message processing in step (3) is similar to step (2) of 5.1.1. Note 2: There is no connection between the two messages in this mechanism except for the implicit relationship in time; this mechanism uses mechanism 5.1.1 twice independently. If you want to further connect the two messages, you can use the text field (see Appendix A) as appropriate. 5.2.2 Three-way authentication
In this authentication mechanism, uniqueness/timeliness is controlled by generating and checking random numbers (see Appendix B). The authentication mechanism is shown in Figure 4.
(1) Rll TextI
The token is in the following form:
(2) TokenAB
(4) TokenBA
(3)
TokenAB - Text3 ll eKab(RA il R ll B Text2)TokenBA - Text5 lf eKar(Re ll RA ll Text4)Note 1: The inclusion of R in TokenBA is to prevent the derivation of TakenBA from TokenAB. The inclusion of the distinguishing identifier B in TokenAB is optional. Note 2: The inclusion of the distinguishing identifier B in TokenAB is to prevent so-called reflection attacks. The characteristic of this attack is that an intruder impersonates A and "reflects" the challenge Rs to B. The inclusion of the distinguishing identifier B is made optional because it can be omitted in environments where such attacks are not likely to occur. If entities A and B share two secret keys K'B and K'BA, which are used by B to authenticate A and A to authenticate B respectively, the distinguishing identifier B can be omitted. The token is then:
TokenAB - Text3 l eK'ar(RA ll R ll Text2)TokenBA Text5 ll eK'BA(Rell Ra ll Text4) In Figure 4: (1) B sends a random number Rε and optionally a text field Text1 to A. (2) A sends TokenAB to B.
(3) Upon receiving the message containing TokenAB, B decrypts the encrypted part and verifies the correctness of the distinguishing identifier B (if any) and whether the random number R sent to A in step (1) matches the random number contained in TokenAB, thereby verifying TokenAB.
(4) B sends TokenBA to A.
(5) Upon receiving the message containing TokenBA, A decrypts the encrypted part and verifies whether the random number R from B in step (1) matches the random number in TokenBA and whether the random number RA sent to B in step (2) matches the random number in TokenBA
6 Mechanisms involving trusted third parties
GB15843.2—1997
None of these authentication mechanisms requires the two entities to share a secret key before the authentication process, but rather uses a trusted third party (with a distinguishing identifier TP) that shares secret keys KAr and KBT with entities A and B, respectively. In each mechanism, an entity first applies to the trusted third party for the key KAB. Thereafter, the mechanisms described in 5.2.1 and 5.2.2 are used, respectively. According to the following description, if only one-way authentication is required, some of the transmissions in each mechanism can be omitted. Note: These mechanisms do not provide any assurance to the trusted third party about the identity of entities A and B. In addition, if authentication fails, there is no information indicating which exchange was modified or generated by an intruder. These mechanisms require the use of time-varying parameters such as timestamps, sequence numbers or random numbers. The properties of these parameters, in particular their extreme difficulty in repeating over the lifetime of the authentication key, are important to the security of these mechanisms. See Annex B for additional information. All text fields specified in the following mechanisms are available for use in applications outside the scope of this standard (they may be empty). Their relationship and content depend on the specific application. Information on the use of text fields is given in Annex A. 6.1 Four-way authentication
In this mutual authentication mechanism, uniqueness/temporality is controlled by using time-varying parameters (see Annex B). The authentication mechanism is shown in Figure 5.
(1) TVPAll
BllTexti
(2) TokenTA
(4) TokenAB
(6)TokenBA
The format of the token (TokenTA) sent by TP to A is: (5)
TokenTA = Text4 l eKAr(TVP ll Kall I Text3) eKr(NmTTP
Il KAb ll A ll Text2)
The format of the token (TokenAB) sent by A to B is: (Tm KapAl Text2) leKas(NA
TokenAB = Text6 l eke(Nm
(TA HBIText5)
The format of the token (TokenBA) sent by B to A is: TokenBA = Text8 leKA(N
AIlText7）
The choice of time stamp or sequence number in this mechanism depends on the capabilities and environment of the entities involved. The use of the time-varying parameter TVPA specified in steps (1) to (3) of Figure 5 is different from the usual one. It allows A to link the response message (2) with the request message (1). The important feature of the time-varying parameter here is its non-repeatability to limit the possible reuse of previously used TokenTA.
In Figure 5: (1) A sends a time-varying parameter TVPA to the trusted third party TP to distinguish the identifier B and optionally send a text word Segment Textl.
(2) The trusted third party TP sends TokenTA to A. (3) Upon receiving the message containing TokenTA, A decrypts the data encrypted under KAr and verifies the correctness of the distinguishing identifier B and whether the time-varying parameters sent to TP in step (1) are consistent with the time-varying parameters in TokenTA, thereby verifying 609
GB15843.2—1997
TokenTA. In addition, A extracts the secret authentication key KAB, and then takes out TTP
eK(NTP
PKABlA from TokenTA. Text2) and construct TokenAB. (4) A sends TokenAB to B.
(5) Upon receiving the message containing TokenAB, B decrypts the encrypted part and verifies the correctness of the identifiers A and B and the time stamp or sequence number, thereby verifying TokenAB. In addition, B extracts the secret authentication key KAB. (6) B sends TokenBA to A.
(7) Upon receiving the message containing TokenBA, A decrypts the encrypted part and verifies the correctness of the identifier A and the time stamp or sequence number, thereby verifying TokenBA. If only one-way authentication of A by B is required, steps (6) and (7) can be omitted. 6.2 Five-transfer authentication
In this mutual authentication mechanism, uniqueness/timeliness is controlled by using random numbers (see Appendix B). The authentication mechanism is shown in Figure 6.
(2) RA I RBl
BIlText2
(3)TokenTA
(1)R Bll TextI
（5)TokenAB
(7) Token BA
The format of the token (TokenTA) sent by TP to A is: TokenTA- Text5 I eKAr(R'A I KAB I BII Text4) JIeKBr(Rg ll Ka Il A ll Text3)The format of the token (TokenAB) sent by A to B is: TokenAB = Text7 l eKr(R Il KAb Il A Il Text3) Il eKAb(RA ll R ll Text6)The format of the token (TokenBA) sent by B to A is: TokenBA=Text9 ll eKAb(R iRa ll Text8)In Figure 6: (1) B sends a random number R and optionally a text field Textl to A. (2) A sends the random numbers R and RA, the distinguishing identifier B and, optionally, a text field Text2 to the trusted third party TP.
(3) The trusted third party TP sends TokenTA to A. (4) Upon receiving the message containing TokenTA, A decrypts the data encrypted under KAr and verifies the correctness of the distinguishing identifier B and whether the random number R'A sent to TP in step (2) matches the random number in TokenTA, thereby verifying TokenTA. In addition, A extracts the secret authentication key KAB, then extracts eKr (RKABllAlText3) from TokenTB and constructs TokenAB.
(5) A sends TokenAB to B.
(6) Upon receiving the message containing TokenAB, B decrypts the encrypted part and verifies the correctness of the distinguishing identifier A and whether the random number RB sent to A in step (1) matches the two copies of the random number in TokenAB, thereby verifying TokenAB. In addition, B extracts the secret authentication key KAB (7) B sends TokenBA to A.
(8) Upon receipt of the message containing TokenBA, A decrypts the encrypted part and verifies whether the random number 610
GB15843.2-1997
Re received from B in step (1) matches the random number contained in TokenBA, and whether the random number RA sent to B in step (5) matches the random number contained in TokenBA. If only one-way authentication of A by B is required, steps (7) and (8) can be omitted. 6
GB 15843.2—1997
Appendix A
(Informative Appendix)
Use of text fields
The tokens specified in Chapters 5 and 6 of this standard contain text fields. The actual use of the different text fields and the relationship between the text fields in a given transmission depends on the specific application. Some examples are given below. If the token does not contain (sufficient) hole margin, the encrypted text field can be used to provide additional margin. Any information required for confidentiality or data origin authentication should be placed in the encrypted part of the token. The text field may contain additional time-varying parameters. For example, in mechanism 5.1.1, if sequence numbers are used, the text field of TokenAB may contain a timestamp. This allows detection of artificial delays by requiring the recipient of the message to verify that any timestamps in the message are within a predefined time window (see Annex B). If more than one key is available, the plaintext field shall contain the key identifier; if more than one trusted third party is available, the text field may be used to include the distinguishing identifier of the trusted third party involved. The text field may also be used for key distribution (see ISO/IEC 11770-2). If any of the mechanisms specified in this standard are embedded in an application that allows an entity to initiate authentication using additional messages before the mechanism is initiated, then some intrusion attacks may become possible. To counter such attacks, the text field may be used to indicate which entity requires authentication. The characteristic of this type of attack is that the intruder may reuse an illegally obtained token. Appendix B
(Suggestive Appendix)
Time-varying parameters
Time-varying parameters are used to control uniqueness/timeliness. They enable previously sent messages to be detected when they are reused. To achieve this, the authentication information should be different each time the mechanism is used. The verifier should control its changes directly or indirectly. Some types of time-varying parameters also allow the detection of "artificial delays" (delays introduced into the communication medium by the adversary). In mechanisms involving more than one transmission, artificial delays can be detected by other methods (such as using "timeout timing" to enforce the maximum time gap allowed between specific messages).
The three types of time-varying parameters used in this standard are time stamps, sequence numbers, and random numbers. In different applications, the most desirable time-varying parameter can be selected according to the implementation needs, and sometimes it is appropriate to select more than one time-varying parameter (such as selecting both time stamps and sequence numbers). The details of the selection of parameters are beyond the scope of this standard. B1Time Stamp
The mechanism involving time stamp uses the same time base that logically links the two communicating parties. The recommended reference clock is the Universal Coordinated Time (UTC). The verifier uses a fixed-size receiving window. The verifier controls the time by calculating the difference between the time stamp in the received verified token and the time when the verifier receives the token. If the difference falls within the window, the message is received. The uniqueness is verified by logging all messages in the current window and rejecting the second and subsequent messages that appear in the same window. A mechanism should be used to ensure that the clocks of the communicating parties are synchronized so that the time base is under the (indirect) control of the verifier. Moreover, the clock synchronization performance should be good enough to make the possibility of impersonation through reuse small to an acceptable level. It should also be ensured that all information related to the verification time stamp, especially the clocks of the communicating parties, will not be tampered with. Time stamps can be used to detect artificial delays. 612
B2Sequence number
GB15843.2—1997
Sequence numbers can be used to control for inconsistency because they allow the verifier to detect reuse of messages. The claimant and the verifier agree in advance on a policy for how to number messages in a particular way, with the basic idea being that a message with a particular number should only be accepted once (or once within a specified time period). The verifier then checks the received message against the policy to see if the sequence number in the message is acceptable. The sequence number is then under the (indirect) control of the verifier. If the sequence number does not conform to the policy, the message is rejected. The use of sequence numbers may require additional "bookkeeping". The claimant should maintain a record of previously used sequence numbers and/or valid sequence numbers that may be available in the future. The claimant should keep this record for all potential verifiers with whom he wishes to communicate. Likewise, the verifier should keep this record for all possible claimants. When conditions occur (such as system failures) where positive ordering is violated, special procedures are required to re-enter and/or restart the sequence number counters.
The claimant's use of sequence numbers does not guarantee that the verifier will be able to detect artificial delays. For mechanisms involving two or more messages, artificial delays can be detected if the sender of a message can detect the time interval between the sending of a message and the receipt of an expected reply, and reject the message if the delay exceeds a predetermined time interval. 3 Random Numbers
The random numbers used by the various mechanisms specified in this standard can prevent reuse attacks or interleaving attacks. The random numbers described in this standard also include unpredictable pseudo-random numbers.
To prevent reuse or interleaving attacks, the verifier obtains a random number that is sent to the claimant. The claimant in turn responds with the random number in the encrypted portion of the returned token (this is usually called a challenge-response). This process links the two messages containing a particular random number. If the same random number is used again by the verifier, a third party who records the original signature exchange can send the recorded token to the verifier, thereby making it possible to pretend to be the claimant. To prevent this type of attack, the probability that the random number will not repeat must be high. By definition, random numbers are unpredictable, and if the random numbers are taken from a large range, their probability of non-repetition can be considered high.
The claimant's use of random numbers does not guarantee that the verifier can detect artificial delays. Appendix C
(Suggested Appendix)
References
［1]GB15852—1995 Information technology security techniques - Data integrity mechanisms using block cipher algorithms as cryptographic check functions (idt ISO/IEC 9797: 1994)
[2]IS0/1FC10118-119941
Information technology security techniques - Hash functions Part 1: Overview[3]IS0/IEC10118-2:19941
Information technology security techniques - Hash functions Part 2: Functions using symmetric block cipher algorithms
［47IS0/IEC11770-2:1995 Information technology security techniques - Mechanisms using symmetric techniques613
Tip: This standard content only shows part of the intercepted content of the complete standard. If you need the complete standard, please go to the top to download the complete standard document for free.