GB/T 36644-2018Information security technology—Methods for obtaining security attestations for digital signature applications (English PDF)

5.2 Acquisition of attestation of private key possession

5.2.3 The process of obtaining the attestation of private key possession

Then the owner of the private key signs the message; this signature is called a attestation signature. The attestation message shall include the following information:

a) The identity of the signer;

b) The identity of the potential verifier;

c) Time stamp token TST: the TST is generated by a trusted time stamp authority (TTSA) trusted by all relying parties. TST can be obtained from TTSA by the signer, or from TTSA by potential verifiers, then passed to the signer. All relying parties shall recognize the strength of TTSA's signature security;

d) A nonce value provided by a verifier. If a nonce is selected, the randomness of the nonce value must be equal to or exceed the randomness of the private key to be certified. If the attestation message does not contain TST, whilst the relying party requires that the attestation time be recorded when verifying the attestation signature, the nonce value needs to include a timestamp provided by the verifier, to indicate the time when the nonce value was provided to the attestation message.

It is not necessary to prove that the public key corresponding to the private key in the message is displayed. However, the inclusion of the public key display information must be determined strictly according to the following description:

-If the signer who generated the attestation signature can successfully display the public key before obtaining the attestation message, the public key information can be removed from the attestation message;

-If the attestation message contains TST, the public key display shall be before the time marked by TST. If there is no TST, the public key shall be displayed before the time included in the nonce value; if there is no TST and the nonce value does not include time, evidence that can be trusted by all parties shall be shown to prove that the public key is displayed before the attestation signature is generated;

-The public key can be displayed as an attestation with a time stamp;

-The public key can also be displayed as a signature previously issued by the signer. The private key used for signing the signature shall be the same as the private key for obtaining the attestation, that is, the same public key can be used for verification. The signature is issued earlier than the time when the attestation message is sent to the signer;

The relying party selects the most credible time source from the above t1 assignment candidates for t1 assignment. In the case of equal credibility, the latest time shall be selected first for the assignment of t1.

As described in 5.2.2, t2 is a time point lagging behind or equal to the time when the attestation signature is generated. Several possible assignments of t2 are as follows:

-If the attestation signature's generation time is included in a TST issued by a TTSA trusted by all relying parties, the time included in the TST can be used as a candidate for the assignment of t2;

-If the verifier records the time of receipt of the attestation signature, the recorded time can be used as a candidate for the assignment of t2;

- If the verifier records the time at which the attestation signature was verified, the recorded time can be used as a candidate for the assignment of t2.

The relying party selects the most credible time source from the above t2 assignment candidates for t2 assignment. In the case of equal credibility, the earliest time shall be selected first for the assignment of t2.

If the attestation signature has been successfully verified, meanwhile the relying party has determined the error accuracy d of the attestation time, the attestation time tA can be estimated as follows:

- If t2 - t1 <= d, meanwhile the credibility of t1 is not less than t2, t1 shall be selected as the attestation time tA;

- If t2 - t1 <= d, meanwhile the credibility of t1 is less than t2, t2 shall be selected as the attestation time tA;

- If t2 - t1 > d, then it does not obtain the attestation of the private key possession, there is no need to assign the attestation time tA.

If the attestation signature cannot be verified, then it does not obtain the attestation of the private key possession, there is no need to assign the attestation time tA.

The generation time of the ordinary message signature is represented by ts.

The ts may have a certain value, or a range of values, or a completely uncertain value. If ts has a value with sufficient precision, meanwhile the attestation of the private key possession corresponding to the private key has obtained, then it may follow the timeliness model in 5.1.1 and use the following method to determine the level of the security attestation of this ordinary message signature:

a) If (tA - (a - d)) <= ts <= (tA + (b - d)), then the security attestation level of the ordinary message signature is equal to the initial attestation level of the acquired attestation of the private key possession;

b) If (tA - (a - d)) <= ts <= (tA + (b - d) +c), then the security attestation level of the ordinary message signature will gradually decrease from the initial state to a low level;

c) ts > (tA + (b - d) + c), then the security attestation level of the ordinary message signature is low.

If ts does not have a certain value, the security attestation level of the ordinary message signature is determined to be low.

5.2.3.1 General

The attestation of private key possession can be obtained by one or more of the following methods:

a) The owner of the private key uses the private key to sign a new digital signature; then uses its corresponding public key to verify;

b) Regenerate the public-private key pair; […]

5.2.3.2.3 Specify the initial attestation level

After the attestation signature is verified and the attestation time is specified, the initial level of the attestation needs to be specified. The initial level of attestation is specified as follows: […]

5.2.4 Specific acquisition flow of attestation of private key possession

5.2.4.1 Public-private key pair owner obtaining the attestation of private key possession

The owner of a public-private key pair can use one or more of the following methods to obtain attestation of private key possession:

a) The public-private key owner adopts the attestation signature to obtain the attestation of private key possession: The public-private key pair owner needs to complete the following:

1) Determine the appropriate value of d, for example, it can determine the value of d after determining the appropriate values of a, b, c according to the timeliness model in 5.2.2.

2) Determine a credible t1 value;

3) Generate a new attestation message for obtaining the attestation of private key possession;

4) Use the private key to obtain the certificate to sign the certificate

c) The owner of the public-private key pair obtains the attestation of private key possession through key regeneration: The public-private key pair owner needs to complete the following:

1) Determine the appropriate value of d, for example, it can determine the value of d after determining the appropriate values of a, b, c according to the timeliness model in 5.2.2.

2) Determine a credible t1 value;

3) Choose one of the following operations:

-Regenerate the key pair corresponding to the private key to be certified;

-Regenerate a key in the key pair corresponding to the private key to be certified.

4) Compare the value of the regenerated key pair (key) with the value of the key currently owned;

5) If the match is successful: -Determine a credible value for t2;

-If t1 <= t2 <= t1 + d, specify and record the attestation time; specify the initial attestation level.

d) The owner of the public-private key pair obtains the attestation of the private key possession from the TTP through key regeneration:

1) The owner of the public-private key must determine the appropriate value of d. For example, according to the timeliness model in 5.2.2, the value of d can be determined on the basis of determining the appropriate values of a, b, c; if the TTP is responsible for specifying the attestation time, the value of d must be known to TTP;

2) The public-private key pair owner and/or TTP must determine a t1 value, which must be trusted by the public-private key pair owner;

3) The owner of the public-private key pair shall provide the key held by it […]

5.3 Obtain the security attestation of public key validity

5.3.2 Obtaining the attestation of public key validity

The owner of a public-private key pair can obtain a security attestation of public key validity through the following five methods:

a) It is generated by public-private key pair owner: The owner uses the identified method to generate the public-private key pair;

b) It is generated by public-private key pair owner in cooperation with TTP: The owner, with the help of TTP, adopts the identified method to generate the public-private key pair;

c) The owner adopts a clear process to verify public key validity: The owner obtains a security attestation of public key validity by performing a clear verification process, see 5.3.4 for the specific verification process;

d) TTP uses a clear process to verify public key validity: The owner needs to receive the attestation that proves that TTP has indeed obtained a security attestation of public key validity through a clear verification process. For the specific verification process, see 5.3.4. TTP verification results must be provided to the owner;

e) The public-private key pair is generated by TTP: TTP generates a public-private key pair and provides it to the owner. If this method is adopted, a public key validity verification process shall be adopted. The verification process can be carried out by the owner according to the above method c), or TTP according to the above method d).

Among them, the combination of method a) or b) and method c) or d) can obtain more effective security attestation.

The owner or its agent needs to know which method is used to obtain the security attestation of public key validity to determine whether the obtained security attestation of public key validity meets the requirements of the owner.

5.3.3 Verifier obtains a security attestation of public key validity

The verifier of the signature obtains the security attestation of public key validity in the public-private key pair used by the issuer when signing, by using the following three methods:

a) The verifier uses a clear process to verify public key validity: the verifier obtains a security attestation of public key validity by performing a clear verification process, see 5.3.4 for the specific verification process.

b) TTP uses a clear process to verify public key validity: the verifier must receive a certificate that proves that the TTP has indeed obtained a […]

5.4 Obtain security attestation of the generation time of digital signature

5.4.2 Obtain attestation of signature timeliness from TTSA

The format of TSP is described as follows:

Among them, the comma is used to separate different data, not part of the data format.

a) TSP = timestamped_data,timestamp_signatureTTSA TSP is composed of time stamp data and its digital signature. The digital signature is the signature of the time stamp data by the TTSA's private key.

b) timestamp_signatureTTSA = SIGTTSA(timestamped_data)

The digital signature algorithm SIGTTSA is a digital signature operation used on time stamp data. The signature private key is the digital signature private key of TTSA. The private key is only used to generate digital signatures on time stamp data.

c) timestamped_data = user_supplied_info,TTSA_supplied_info,timestamp Among them:

1) user_supplied_info: User-supplied information, which is the information provided by an entity when requesting a timestamp from TTSA; user_supplied_info can be empty in actual applications. If this information is provided, this information will be used by TTSA when generating the time stamp signature, without the need to be returned to the requester when transmitting the time stamp packet. If this information is used, it shall be ensured that the information is visible when an entity wants to verify timestamp_signatureTTSA;

2) TTSA_supplied_info: Information provided by TTSA, which is the additional information used by TTSA when generating timestamp_signatureTTSA. TTSA_supplied_info may be empty in actual applications. As long as this part of the information can be regenerated when verifying the timestamp_signatureTTSA signature, any part of it can be deleted from the timestamp packet;

3) The timestamp contains time and (possibly) other information.

Therefore, the general TSP format generated by TTSA is as follows: Among them, user_supplied_info and TTSA_supplied_info may be empty.

c) Entity A signs (M, TSP), assembles data D, sends it to entity B: D = M, TSP, SIGA (M, TSP)

Among them, TSP is the same as specified in 5.4.2.1; the assembly data D is divided into the following two situations:

1) If any part of the user-supplied information is deleted from the TSP from TTSA, then the entire user-supplied information must be backfilled into the TSP when data D is formed, unless there is a mutual agreement between entity A and entity B, which makes the deleted part be known by entity B or regenerated. In the case of partial information deletion, the entire user-supplied information user_supplied_info shall be included in the timestamped_data used to generate/verify the digital signature timestamp_signatureTTSA and SIGA (M, TSP);

2) If any part of the information TTSA_supplied_info provided by TTSA is deleted from the TSP from TTSA, then the entire information provided by TTSA must be backfilled into the TSP when forming D, unless there is a mutual agreement between entity A and entity B. B can determine this information. In this case, if entity B knows or can determine that TTSA provides information, then any part of its information can be deleted from the TSP data transmitted by entity A. However, the entire information TTSA_supplied_info as provided by the TTSA shall be included in the timestamped_data used to generate/verify the digital signature and the time stamp data timestamp_signatureTTSA as sued for SIGA (M, TSP).

d) Upon receiving D, entity B follows the following steps:

1) Use the TTSA public key to verify the digital signature timestamp_signatureTTSA;

2) Use A's public key to verify the digital signature SIGA (M, TSP).

The order of execution of the above two steps is irrelevant, however, it is necessary to ensure that the two verifications are successful.

After completing the verification in step 4, entity B obtains the following […]