### Examples of AUTHENTICATE functions by GENERAL AUTHENTICATE commands

#### C.1 Introduction

Two or more GENERAL AUTHENTICATE command-response pairs implement an AUTHENTICATE function.

If chaining is used, then CLA is set to 0xx1 xxxx in the first command of the chain up to the penultimate one and to 0xx0 xxxx in the last one: the other six bits shall remain constant within the chain.

INS P1 P2 is set to either ’86 00 00′, or ’87 00 00′.

The value of the Lc field depends upon the data objects in the command data field. Depending upon whether a response data field is expected or not, the Le field is either set to ’00′, or absent.

This annex illustrates data fields of GENERAL AUTHENTICATE commands implementing mechanisms such as specified in ISO/IEC 9798-5^{[8]}, i.e., mechanisms using zero-knowledge techniques.

A verifier knows a public problem and a claimant knows a secret solution to the public problem.

As a result of the zero-knowledge protocol, the verifier is convinced that the claimant knows a solution to the public problem. Moreover, the solution remains secret.

NOTE ISO/IEC 9798-5^{[8]} specifies two GQ techniques.

Being given a public RSA key where the exponent v is prime such as 257 = 2^{8}+1, 65537 = 2^{16}+1 or 2^{36}+2^{13}+1, the GQ1 technique allows verifying an RSA signature without taking knowledge of its value, or alternately, proving knowledge of an RSA signature without revealing its value. As specified by the RSA signature standard in use (e.g., see ISO/IEC 14888-2^{[16]}), a format mechanism converts the claimant’s identification data (a template) into a public number G. The corresponding private number Q is the RSA signature of the identification data. The claimant and the verifier know the public RSA key. The GQ1 protocol proves that the claimant knows the RSA signature of his identification data.

Being given a public modulus n, product of two prime factors, the GQ2 technique allows verifying the factors without taking knowledge of them, or alternately, proving knowledge of the factors without revealing them. The mechanism involves a security parameter k > 0 and the first m prime numbers, named the m basic numbers, such that k×m is from 8 to 36. Each public number is the square of a basic number: G = g^{2}. The corresponding private number Q is a modular 2^{k+1}th root of G. If there is at least one basic number g such that the Jacobi symbol of g with respect to n is –1 and if n is congruent to 1 mod 4, then the GQ2 protocol proves that n is composite and that the claimant knows the factors.

The protocol typically exchanges three numbers, namely a witness, a challenge and a response.

The claimant works in two steps: as a first step, the claimant privately selects a fresh random number and converts it into a witness according to a “witness formula”; as a second step, having received a challenge, the claimant gets the response to the challenge from the fresh random number and the private number, according to a “response formula”, and then erases the fresh random number.

The verifier reconstructs a witness from the challenge and the response, according to a “verification formula”.

By definition, a triple consists of three numbers, namely, a witness, a challenge and a response, verifying the verification formula. Any entity may randomly produce triples in “public mode”, from any challenge and response. A judge or an observer cannot distinguish random triples produced in public mode, i.e., by an entity not knowing the secret, and random triples produced in “private mode”, i.e., by an entity knowing the secret.

This annex illustrates three AUTHENTICATE functions.

INTERNAL AUTHENTICATE function — A verifier in the outside world authenticates a claimant in the card.

EXTERNAL AUTHENTICATE function — A verifier in the card authenticates a claimant in the outside world.

MUTUAL AUTHENTICATE function — Both entities authenticate each other.

**C.2 INTERNAL AUTHENTICATE function **

If the first data field conveys a witness request, namely, either an empty witness (’80 00′), or an empty authentication code (’84 00′), then the function is INTERNAL AUTHENTICATE.

**Basic protocol **(two command-response pairs) **Witness from the card **

Command data field {’7C’-’02′-{’80′-’00′}}

Response data field {’7C’-L1 (=2+L2)-{’80′-L2-Witness}}

**Challenge from the outside world and response from the card **

Command data field {’7C’-L1 (=4+L2)-{’81′-L2-Challenge}-{’82′-’00′}}

Response data field {’7C’-L1 (=2+L2)-{’82′-L2-Response}}

**Committed challenge **(two command-response pairs) **Witness from the card **

Command data field {’7C’-L1 (=4+L2)-{’83′-L2-Committed Challenge}-{’80′-’00′}}

Response data field {’7C’-L1 (=2+L2)-{’80′-L2-Witness}}

NOTE The committed challenge ensures that the challenge and the witness are independently selected.

**Challenge from the outside world and response from the card **

Command data field {’7C’-L1 (=4+L2)-{’81′-L2-Challenge}-{’82′-’00′}}

Response data field {’7C’-L1 (=2+L2)-{’82′-L2-Response} if the challenge is correct Absent if the challenge is incorrect

**Extension to data field authentication **(two command-response pairs)

The card has hashed previously exchanged data fields: the result is a current hash-code. The card includes its witness data object for getting an authentication code and transmits it with tag ’84′.

**Witness from the card **

Command data field {’7C’-’04′-{’84′-’00′}}

Response data field {’7C’-L1 (=2+L2)-{’84′-L2-Authentication code}}

**Challenge from the outside world and response from the card **

Command data field {’7C’-L1 (=4+L2)-{’81′-L2-Challenge}-{’82′-’00′}}

Response data field {’7C’-L1 (=2+L2)-{’82′-L2-Response}}

**C.3 EXTERNAL AUTHENTICATE function **

If the first data field conveys a challenge request, namely, either an empty challenge (’81 00′), or an empty committed challenge (’83 00′), then the function is EXTERNAL AUTHENTICATE.

**Basic protocol **(two command-response pairs) **Witness from the outside world and challenge from the card **

Command data field {’7C’-L1 (=4+L2)-{’80′-L2-Witness}-{’81′-’00′}}

Response data field {’7C’-L1 (=2+L2)-{’81′-L2-Challenge}}

Response from the outside world and verification by the card

Command data field {’7C’-L1 (=2+L2)-{’82′-L2-Response}}

Response data field Absent

Committed challenge (three command-response pairs) Committed challenge from the card

Command data field {’7C’-’02′-{’83′-’00′}}

Response data field {’7C’-L1 (=4+L2)-{’83′-L2-Committed challenge}-{’80′-’00′}}

Witness from the outside world and challenge from the card

Command data field {’7C’-L1 (=4+L2)-{’80′-L2-Witness}-{’81′-’00′}}

Response data field {’7C’-L1 (=2+L2)-{’81′-L2-Challenge}}

Response from the outside world and verification by the card

Command data field {’7C’-L1 (=2+L2)-{’82′-L2-Response}}