GB/T 15843.3-1998 Information technology security techniques Entity authentication Part 3: Mechanisms using asymmetric signature techniques
Some standard content:
GB/T 15843. 3—1998
This standard is equivalent to the international standard ISO/IECDIS9798-3:1997 "Information technology security technology entity authentication Part 3: Mechanisms using asymmetric signature technology". The unilateral authentication and mutual authentication mechanisms specified in this standard are used to ensure the security of information exchange. This series of standards, under the general title "Information technology security technology entity authentication", consists of the following parts: Part 1: Overview
Part 2: Mechanisms using symmetric encryption algorithms Part 3: Mechanisms using asymmetric signature technology Part 4: Mechanisms using cryptographic check functions Part 5: Mechanisms using zero-knowledge technology
Future additions may follow.
Appendix A of this standard is a suggestive appendix.
This standard is 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. Drafting units of this standard: Standardization Institute of the Ministry of Electronics Industry, the 30th Institute of the Ministry of Electronics Industry. The main drafters of this standard are: Xiang Weiliang, Gong Qimin, Wu Shizong, Lei Limin, Tao Renji and Hao Weigang. 614
GB/T15843.3-1998
ISO/IEC Foreword
ISO (International Organization for Standardization) and IEC (International Electrotechnical Commission) together form a world standardization specialized system. National member bodies of ISO or IEC participate in the development of international standards through technical committees established by various organizations involved in special technical activities. The technical committees of ISO and IEC cooperate in areas of common interest, and other official and non-official international organizations in liaison with ISO and IEC also participate in this work.
In the field of information technology, ISO and IEC have established a joint technical committee ISO/IECJTCI. Draft international standards adopted by the joint technical committee are circulated to national member bodies for voting. At least 75% of the national member bodies participating in the voting must vote in favor of an international standard.
International Standard ISO/IEC DIS 9798-3 was prepared by Joint Technical Committee ISO/IEC JTCI "Information technology", Subcommittee SC 27 "IT security techniques".
This second edition replaces the first edition (ISO/IEC 9798-3:1993), which is technically revised. ISO/IEC 9798, under the general title "Information technology security techniques - Entity authentication", consists of the following parts: Part 1: Overview
Part 2: Mechanisms using symmetric encryption algorithms Part 3: Mechanisms using asymmetric signature techniques Part 4: Mechanisms using cryptographic check functions Part 5: Mechanisms using zero-knowledge techniques
Future additions may follow.
Annex A to this standard is provided for information only. 615
1 Scope
National Standard of the People's Republic of China
Information technology-Security techniquesEntity authentication--Part 3:Mechanisms using asymmetric signature techniquesGB/T 15843. 3 -- 1998
idtISO/IECDIS9798-3:1997
This standard specifies entity authentication mechanisms using asymmetric signature techniques. Two authentication mechanisms are for the authentication of a single entity (one-way), and the rest are for mutual authentication of two entities. Digital signatures are used to verify the identity of the entity, and may also involve a trusted third party. 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 time stamps or sequence numbers are used, one-way authentication requires only one pass, while mutual authentication requires two passes. If a challenge and response method with random numbers is used, one-way authentication requires two passes, while when mutual authentication is performed, three or four passes are required (depending on the mechanism used).
2 References
The following standards contain clauses that constitute clauses of this standard through reference in this standard. The versions shown are valid at the time of publication of this standard. All standards are subject to revision and parties using this standard should investigate the possibility of using the latest version of the following standards. ISO/IEC9798-1:1997 Information technology security techniques entity authentication Part 1: Overview 3 Definitions and notations
This standard adopts the definitions and notations described in ISO/IEC9798-1. 4 Requirements
In the authentication mechanism specified in this standard, the entity to be authenticated shall prove its identity by showing that it knows a secret signing key. This is done by the entity signing specific data using its secret signing key. The signature can be verified by any entity using the entity's public authentication key.
The authentication mechanism has the following requirements:
a) The verifier shall possess a valid public key of the claimant; b) The claimant shall possess a secret signing key known and used only by himself. If either of these two conditions is not met, the authentication process will be compromised or cannot be successfully completed. NOTE: One way to obtain a valid public key is to use a certificate (see Annex C of ISO/IEC 9798-11997). The generation, distribution and revocation of certificates are beyond the scope of this standard. For this purpose, a trusted third party may exist. Another way to obtain a valid public key is to use a trusted messenger.
Approved by the State Administration of Quality and Technical Supervision on December 14, 1998616
Implementation on August 1, 1999
5 Mechanism
GB/T15843.3—1998
The entity authentication mechanism specified in GB/T15843.3—1998 utilizes time-varying parameters such as time stamps, sequence numbers or random numbers (see Annex B of ISO/IEC9798-1:1997).
Assume that the token is defined as follows:
Token = X, I .... IX, II .Sa(Y, Il ..*. Il Y,)In this standard, "signed data" refers to "Y,!!·Y", which is used as the input of the digital signature scheme, and "unsigned data" refers to \X l II X,\.
If the information contained in the signed data of the token can be recovered from the signature, it need not be included in the unsigned data of the token (see GB 15851-1995).
If the information contained in the text field of the signed data of the token cannot be recovered from the signature, it should be included in the unsigned text field of the token.
If the information in the signed data of the token (such as a random number) is known to the verifier, it does not need to be included in the unsigned data of the token sent by the claimant.
All text fields specified in the following mechanism are valid for use in applications outside the scope of this standard (they can be empty). Their relationship and content depend on the specific application. For information on the use of text fields, see Appendix A. Note
The manipulation of the signature of a data block by one entity for the second entity can be prevented by including its own random number in the data block signed by the first entity. In this case, it is its unpredictability that prevents the signing of predefined data. 2 Since the distribution of certificates is outside the scope of this standard, the issuance of certificates is optional in all mechanisms. 5.1 One-way Mechanisms
A one-way mechanism means that only one of the two entities is authenticated. 5.1.1 One-time transfer mechanism
In this authentication mechanism, the process is initiated by the claimant A and authenticated by the verifier B. Uniqueness/timeliness is controlled by generating and verifying a time stamp or sequence number (see Annex B of ISO/IEC9798-1:1997). The authentication mechanism is illustrated in Figure 1.
(1)Cert A II Token AB
The token (Token AB) sent by the claimant A to the verifier B is of the form: TA I BII Text 2ll SA
TokenAB=NA
(TA BII Text )
Where: Claimant A uses the sequence number NA or the time stamp Ta as the time-varying parameter. This choice depends on the environment and the technical capabilities of the claimant and the verifier.
To prevent any entity other than the intended verifier from accepting the token, the identifier B must be included in the TokenAB signature data. 1
2In general, Text 2 is not authenticated by this process. 3 One application of this mechanism could be key distribution (see Annex A of ISO/IEC 9798-1:1997). (1) A sends Token AB to B. The sending of A's certificate is optional. (2) Upon receiving the message containing Token AB, B performs the following steps: (i) Ensure possession of A's valid public key by verifying A's certificate or by other means. (i) Verify Token AB by verifying A's signature contained in the token, verifying the timestamp or sequence number, and verifying that the value of the identifier field (B) in the signature data of Token AB is equal to the distinguishing identifier of entity B. 617
5.1.2 Two-pass mechanism
GB/T15843.3-1998
In this mechanism, the verifier B initiates the process and authenticates the claimant A. Uniqueness/timeliness is controlled by generating and verifying a random number Rp (see Annex B of ISO/IEC 9798-1:1997). The authentication mechanism is illustrated in Figure 2.
(1)Rg l Textl
(2)Cert AH Token AB)
The token (TokenAB) sent by claimant A to verifier B is of the form:3
TokenAB = Ra l R ll B ll Text 3 Il SA(Ra Il R ll B lI Text 2)The inclusion of identifier B in TokenAB is optional and depends on the circumstances in which the authentication mechanism is used. NOTE
The inclusion of the optional identifier B in the signature data of TokenAB prevents the token from being accepted by any entity other than the intended verifier (e.g., a man-in-the-middle attack).
2The random number RA is present in TokenAB to prevent B from obtaining A's signature on data chosen by B before the authentication mechanism is initiated. This precaution may be necessary, for example, when A uses the same key for purposes other than entity authentication. (1) B sends the random number Rε to A and optionally the text field Textl. (2) A sends TokenAB to B, and it is optional whether A's certificate is sent. (3) Upon receiving the message containing TokenAB, B performs the following steps: (i) Ensure that it has A's valid public key by verifying A's certificate or by other means. (ii) Verify TokenAB by: checking A's digital signature contained in the token; checking whether the random number Re sent to A in step (1) matches the random number contained in the signature data of TokenAB; and checking that the value of the identifier field (B) in the signature data of TokenAB, if any, is equal to B's distinguishing identifier. 5.2 Mutual Authentication
Mutual authentication is a method where two communicating entities authenticate each other. The two mechanisms described in 5.1.1 and 5.1.2 are extended to 5.2.1 and 5.2.2 respectively to achieve mutual authentication, which introduces two additional steps by sending one message. The steps specified in 5.2.3 use four messages, but these messages do not need to be sent in sequence. In this way, the authentication process can be accelerated.
5.2.1 Two-pass authentication
In this authentication mechanism, uniqueness/timeliness is controlled by generating and verifying time stamps or sequence numbers (see Annex B of ISO/IEC 9798-1:1997).
The authentication mechanism is illustrated in Figure 3.
(1) Cert All Token AB
(3) Cert B Token BA
The token (Token AB) sent by A to B is of the same form as specified in 5.1.1. TAB Text 2 HS(NA)
TokenAB =
(TA IBIIText I
The token (TokenBA) sent by B to A is in the form of:Te IAll Text 4 H,Ss(Ne)
TokenBA --
(TPAText3)
The choice of using a timestamp or a sequence number in this mechanism depends on the environment and the technical capabilities of the claimant and the verifier. 15843.3—1998
NOTE 1: The signature data of TokenAB and TokenBA must contain identifiers A and B, respectively, to prevent the token from being accepted by any entity other than the intended verifier.
Steps (1) and (2) are the same as in 5.1.1…-pass authentication. (3) B sends TokenBA to A, and it is optional for B’s certificate to be sent. (4) The message in step (3) is processed in a manner similar to 5.1.1, step (2). NOTE 2: The two messages of this mechanism are not constrained in any way other than the implicit timeliness constraint; the mechanism involves two independent passes using mechanism 5.1.1. Further constraints on these messages may be achieved through appropriate use of text fields. 5.2.2 Three-pass authentication
In this mechanism, uniqueness/timeliness is controlled by generating and checking random numbers (see Annex B of ISO/IEC 9798-1:1997).
The authentication mechanism is illustrated in Figure 4.
(1) Re l Text)
(2) Cert A Token AB
The token is of the following form:
(4) Cert Bll Token BA
TokenAB = RA Il R l B Il Text 3 ll sSA(RA Il R l B Il Text 2)TokenBA = R RA ll Al Text 5 S(R ll RA ll A l Text 4)The inclusion of parameter B in TokenAB and parameter A in TokenBA are both optional. They depend on the environment in which the mechanism is used.
Note: The random number RA should be present in TokenAB to prevent B from obtaining A's signature on data chosen by B before the authentication mechanism is initiated. This precaution may be necessary, for example, when A will use the same key for purposes other than entity authentication. For similar reasons, TokenBA also uses the random number RB. However, because R is known when R^ is chosen, A may know in advance the complete data signed in TokenBA. If this is undesirable, B can insert an additional random number R'B in the Text 4 and Text 5 fields of TokenBA. In addition, for security reasons, it is necessary to check whether the random number Rε in the first and third messages is the same. (1) B sends the random number R to A, and optionally the text field Text1. (2) A sends TokenAB to B, and optionally A's certificate. (3) Upon receiving the message containing TokenAB, B performs the following steps: (i) Ensure that it has A's valid public key by verifying A's certificate or by other means. (ii) TokenAB is verified by: checking A's signature contained in the token; checking that the random number R sent to A in step (1) matches the random number contained in the signature data of TokenAB; and checking that the value of the identifier field (B) in the signature data of TokenAB, if any, is equal to B's distinguishing identifier. (4) B sends TokenAB to A, and optionally B's certificate. (5) Upon receiving the message containing TokenBA, A similarly performs steps (i) and (ii) listed in (3). In addition, A checks that the random number RB contained in the signature data of TokenBA matches the random number received in step (1). 5.2.3 Two-pass parallel authentication
In this mechanism, authentication is performed in parallel, and uniqueness/timeliness is controlled by generating and verifying random numbers (see Annex B of ISO/IEC 97981:1997).
The authentication mechanism is illustrated in Figure 5.
The token is similar to that in 5.1.2:
GB/T 15843.3 -- 1998
(1)Cert Al RA |Text1
(')CertBlRslText2
(3)TokenBA
(3'）Token AB
RA II R II B II Text 4 II SA(RA Il R Il BII Text 3)TokenAB =
TokenBA =Rall RA llAl Text 6llS(R ll RA ll AI Text 5)The inclusion of parameter B in TokenAB and parameter A in TokenBA are optional. They depend on the circumstances in which the token is used.
NOTE 1: The random number should be present in TokenAB to prevent B from obtaining A's signature on data chosen by B before the authentication mechanism is initiated. This precaution may be necessary, for example, when A will use the same key for purposes other than entity authentication. TokenBA also uses a random number Rs for similar reasons. Depending on the relative time at which the messages sent in (1) and (1') are received, it may be possible for one party to know the other party's random number when it selects its random number. If this is undesirable, the two parties can insert additional random numbers R'A and R'B in the text fields Text3 and Text4 of TokenAB and in the text fields Text5 and Text6 of TokenBA, respectively. (1) A sends R^ to B, optionally with A's certificate and text field Text1. (1') B sends R to A, optionally with B's certificate and text field Text2. (2) A and B ensure that they possess the other entity's valid public key, either by verifying their respective certificates or in some other way.
(3) A sends TokenAB to B.
(3') B sends TokenBA to A.
(4) A and B perform the following steps:
They each verify the received token by checking the signature contained in the token and checking that the random number it had previously sent to the other entity matches the random number contained in the received token signature data. NOTE 2 An alternative to the mechanism of 5.2.3 is to run the mechanism of 5.1.2 in both directions. Including the certificate in the first message of mechanism 5.2.3 will allow earlier verification of the certificate, thereby speeding up the authentication process. 620
GB/T15843.3-1998
Annex A
(Informative Appendix)
Use of text fields
The tokens specified in clause 5 of this standard contain text fields. The actual use of the various text fields in a given transaction and the relationship between them is application dependent. Some examples are given below; see also Annex A of ISO/IEC 9798-1:1997. If a digital signature scheme without message recovery is used, and the signed text field is not empty, the verifier must have possession of the text before verifying the signature. In this annex, "signed text field" refers to a text field in the signed data, and "unsigned text field" refers to a text field in the unsigned data.
For example, if a digital signature scheme without message recovery is used, any information required for data origin authentication should be placed in the signed text field and (as part of) the unsigned text field in the token. If the token does not contain (sufficient) redundancy, the signed text field can be used to provide additional redundancy. The signed text field can be used to indicate that the token is valid only for the purpose of entity authentication. It should also be noted that a "degenerate" value may be chosen by another entity with malicious intent to sign it, and that the other entity may introduce a random number into the text field. If an algorithm is used in which an attack is possible due to a claimant using the same key for all verifiers with which it communicates, and if such an attack is considered a threat, the identity of the intended verifier should be included in both the signed text field and (if necessary) the unsigned text field.
The unsigned text field can also be used to provide information to the verifier to indicate the identity that the claimant is claiming (but not being authenticated). If public keys are not distributed using certificates, this information is required for the verifier to determine which public key to use to authenticate the claimant. 6213 -- 1998
(1)Cert Al RA |Text1
(')CertBlRslText2
(3)TokenBA
(3'）Token AB
RA II R II B II Text 4 II SA(RA Il R Il BII Text 3)TokenAB =
TokenBA =Rall RA llAl Text 6llS(R ll RA ll AI Text 5)The inclusion of parameter B in TokenAB and parameter A in TokenBA are optional. They depend on the circumstances in which the token is used.
NOTE 1: The random number Rs should be present in TokenAB to prevent B from obtaining A's signature on data chosen by B before the authentication mechanism is initiated. This precaution is needed, for example, when A will use the same key for purposes other than entity authentication. For similar reasons, the random number Rs is also used in TokenBA. Depending on the relative time at which the messages sent in (1) and (1') are received, it may be possible for one party to know the other party's random number when it selects its random number. If this is undesirable, the two parties may insert additional random numbers R'A and R'B in the text fields Text3 and Text4 of TokenAB and in the text fields Text5 and Text6 of TokenBA, respectively. (1) A sends R^ to B, optionally with A's certificate and text field Text1. (1') B sends R to A, optionally with B's certificate and text field Text2. (2) A and B ensure that they possess the other entity's valid public key, either by verifying their respective certificates or in some other way.
(3) A sends TokenAB to B.
(3') B sends TokenBA to A.
(4) A and B perform the following steps:
They each verify the received token by checking the signature contained in the token and checking that the random number it had previously sent to the other entity matches the random number contained in the received token signature data. NOTE 2 An alternative to the mechanism of 5.2.3 is to run the mechanism of 5.1.2 in both directions. Including the certificate in the first message of mechanism 5.2.3 will allow earlier verification of the certificate, thereby speeding up the authentication process. 620
GB/T15843.3-1998
Annex A
(Informative Appendix)
Use of text fields
The tokens specified in clause 5 of this standard contain text fields. The actual use of the various text fields in a given transaction and the relationship between them is application dependent. Some examples are given below; see also Annex A of ISO/IEC 9798-1:1997. If a digital signature scheme without message recovery is used, and the signed text field is not empty, the verifier must have possession of the text before verifying the signature. In this annex, "signed text field" refers to a text field in the signed data, and "unsigned text field" refers to a text field in the unsigned data.
For example, if a digital signature scheme without message recovery is used, any information required for data origin authentication should be placed in the signed text field and (as part of) the unsigned text field in the token. If the token does not contain (sufficient) redundancy, the signed text field can be used to provide additional redundancy. The signed text field can be used to indicate that the token is valid only for the purpose of entity authentication. It should also be noted that a "degenerate" value may be chosen by another entity with malicious intent to have it sign, and that the other entity may introduce a random number into the text field. If an algorithm is used in which an attack is possible due to a claimant using the same key for all verifiers with which it communicates, and if such an attack is considered a threat, the identity of the intended verifier should be included in both the signed text field and (if necessary) the unsigned text field.
The unsigned text field can also be used to provide information to the verifier to indicate the identity that the claimant is claiming (but not being authenticated). If public keys are not distributed using certificates, this information is required for the verifier to determine which public key to use to authenticate the claimant. 6213 -- 1998
(1)Cert Al RA |Text1
(')CertBlRslText2
(3)TokenBA
(3'）Token AB
RA II R II B II Text 4 II SA(RA Il R Il BII Text 3)TokenAB =
TokenBA =Rall RA llAl Text 6llS(R ll RA ll AI Text 5)The inclusion of parameter B in TokenAB and parameter A in TokenBA are optional. They depend on the circumstances in which the token is used.
NOTE 1: The random number Rs should be present in TokenAB to prevent B from obtaining A's signature on data chosen by B before the authentication mechanism is initiated. This precaution is needed, for example, when A will use the same key for purposes other than entity authentication. For similar reasons, the random number Rs is also used in TokenBA. Depending on the relative time at which the messages sent in (1) and (1') are received, it may be possible for one party to know the other party's random number when it selects its random number. If this is undesirable, the two parties may insert additional random numbers R'A and R'B in the text fields Text3 and Text4 of TokenAB and in the text fields Text5 and Text6 of TokenBA, respectively. (1) A sends R^ to B, optionally with A's certificate and text field Text1. (1') B sends R to A, optionally with B's certificate and text field Text2. (2) A and B ensure that they possess the other entity's valid public key, either by verifying their respective certificates or in some other way.
(3) A sends TokenAB to B. Www.bzxZ.net
(3') B sends TokenBA to A.
(4) A and B perform the following steps:
They each verify the received token by checking the signature contained in the token and checking that the random number it had previously sent to the other entity matches the random number contained in the received token signature data. NOTE 2 An alternative to the mechanism of 5.2.3 is to run the mechanism of 5.1.2 in both directions. Including the certificate in the first message of mechanism 5.2.3 will allow earlier verification of the certificate, thereby speeding up the authentication process. 620
GB/T15843.3-1998
Annex A
(Informative Appendix)
Use of text fields
The tokens specified in clause 5 of this standard contain text fields. The actual use of the various text fields in a given transaction and the relationship between them is application dependent. Some examples are given below; see also Annex A of ISO/IEC 9798-1:1997. If a digital signature scheme without message recovery is used, and the signed text field is not empty, the verifier must have possession of the text before verifying the signature. In this annex, "signed text field" refers to a text field in the signed data, and "unsigned text field" refers to a text field in the unsigned data.
For example, if a digital signature scheme without message recovery is used, any information required for data origin authentication should be placed in the signed text field and (as part of) the unsigned text field in the token. If the token does not contain (sufficient) redundancy, the signed text field can be used to provide additional redundancy. The signed text field can be used to indicate that the token is valid only for the purpose of entity authentication. It should also be noted that a "degenerate" value may be chosen by another entity with malicious intent to have it sign, and that the other entity may introduce a random number into the text field. If an algorithm is used in which an attack is possible due to a claimant using the same key for all verifiers with which it communicates, and if such an attack is considered a threat, the identity of the intended verifier should be included in both the signed text field and (if necessary) the unsigned text field.
The unsigned text field can also be used to provide information to the verifier to indicate the identity that the claimant is claiming (but not being authenticated). If public keys are not distributed using certificates, this information is required for the verifier to determine which public key to use to authenticate the claimant. 621
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.