DE19515613A1 - Authentication and electronic signing method esp for telecommunication system - Google Patents

Abstract

The method uses a signing or signature process and a verification process, running in the secure surroundings of two modules. One module is for the subscriber A and the other for subscriber B, and takes the form of a processing chip or I.C. card. However it is not a personalised module. Alternatively the signature and verification processes are provided in a personalised security module (SM-A,SM-B) given to each subscriber.

Description

The invention relates to a method in the upper Concept of claim 1 described in more detail. Procedures of this kind involve mathematical asymmetry under names such as RSA, DSS, EL Gamal, FS, etc. well known.

On the other hand, a number of symmetrical crypto Known procedures that are easier and less expensive in of the technical implementation, but are essential for this need much more effort for key management.

The object of the invention is mathematically symmetrical To design procedures so that they with respect to the key management and security features how to have asymmetric processes without the technical The effort of mathematical asymmetry.

This task is carried out with that in the characterizing part of the patent Proceed 1 described procedure.

Advantageous developments of the method are in the Characteristics of subclaims 2 to 4 described.

The essence of the procedure is that the for Authentication and electronic signature required Asymmetry not on "mathematical", i.e. H. cryptographic path, but through the combination Conventional symmetric cryptographic method with asymmetri processing processes in a distributed, but  secure implementation environment.

In all areas of application where a safe Hardware environment such as security modules so z. Belly Processor chip cards are issued to users can use this procedure to use asymmetric crypto method can be omitted.

The application possibility covers all areas in which Authentication procedures and electronic signatures be used and therefore not only those in the following the exemplary embodiments described in more detail. The latter are only for illustration and representative of many variants detailed. In the associated Drawings are two more and two less different variants shown. They show

Fig. 1, the variant I,

Fig. 2, the variant Ia,

Fig. 3, the variant II and

Fig. 4 shows the variant IIa.

This variant I shown in Fig. 1 can be used to generate an electronic signature and for authentication purposes.

The process: SIGN = signature process and VERIFY = Verifi ornamentation process runs in the safe environment of the non-personalized security module SM, e.g. B. Processor chip card, from.

The processes shown therein run in the security module personalized by the trust center and in the security module SM-B of the issuing point, whereby
CAs = the secret symmetric key of the issuing office,
A = the identity of user A,
B = the identity of user B,
SM-A = the security module SM of user A and
SM-B = the security module SM of the user.

A signs message "data":

SIGN: CAs [A, data]

in the security module SM-A of user A. This process runs in the secure hardware environment of the security module SM of user A.

In the security module SM-A of user A, instead of "data" its hash value h (data) can also be used. In addition can "timestamps", serial numbers, according to CCITT X 509 u. a. be used.

A sends the signed message to B:

A → A, data, CAs [A, data] → B or z. B.
A, data, CAs [A, h (data)]

The plain text of "A, data" can also be sent.

B verifies the message received by A:

in the security module SM-B of user B.

All process steps are always closely related with each other. The security module SM-B specifies the Outside world only the result of the 3rd overall data-data process known.

The advantage of this variant I is, besides avoiding one asymmetric cryptographic process that for the signature  practically all processor chip cards are suitable as SM are not. In contrast, for asymmetric procedures special controller required. Signature procedures are thus no longer from just one or very few (asymme trical) cryptographic process. However, it can some arbitrary symmetric crypto methods at belie use the other key lengths.

Due to the usability of symmetric cryptographic methods the computing times for signature and verification pro Processes significantly reduced.

With a successful attack on a once used Other (symmetrical) substitute procedures are available for cryptographic procedures available immediately.

It can be considerably more asymmetrical than that simpler key generation processes can be applied.

This variant I also has the advantage that entire system works with just a single key; their special disadvantage is: chosen plain text - attack simplified possible.

The special characteristics of an asymmetrical procedure rens are made using a considerably less com complex, simulated any symmetrical method through the permanent integration of two different "asymmetrical" processes, here "SIGN" and "VERIFI" are mentioned in the safe environment of a security module SM.

The authentication of A's identity no longer takes place in the issuing office. Rather is the secret authentication key CAs of the issuing office cannot be read out in the secure environment of all SMs. He is only in  SIGN process and in the VERIFY process internally in the security module SM used. The "authentication" of the issuing agency takes place thus new every time to create an individual signature.

The variant Ia shown in FIG. 2 is a variant of the variant I. However, it is not used for generating and verifying a signature, but rather for agreeing an authentic session key "Ks" between two users A and B, which enables confidential communication with third parties ( Want to set up encryption of messages).

In Fig. 2 are:
SEAL Ks = process for encrypting an authentic session key and
RETRIEVE Ks = Process for verifying and decrypting an authentic session key.

A creates an authentic, confidential session key: (here 1-way token according to CCITT X.509)

SEAL Ks: CAs [A, B, rA, Ks]

in security module SM-A of user A.

A sends session key to B:

A → CAs [A, B, rA, Ks] → B

The plain text of "A, B, rA" can also be sent.

B verifies and decrypts session keys:

The session key Ks can now be used for encryption purposes inside and possibly outside of security module SM can be used.

Other variants e.g. B. with 2-way or 3-way tokens, too with additional parameters (plain text, time stamps etc., according to CCITT X.509, are also part of the Invention provided.

The advantages and properties of variant Ia correspond those of variant I.

The main difference of variant II is that these variants also use user-specific keys As and Bs to generate a signature. This measure brings the characteristics of the authentication and signature procedure described here even more closely into line with the well-known procedures based on asymmetric procedures (e.g. CCITT X.509) and complicates or prevents what is possible in procedure I " chosen plain text - attack ". This advantage is purchased with a significantly higher number of keys (one for each user). Otherwise, the properties of variant II shown in FIG. 3 are identical to those of variant I.

The process: SIGN = signature process and VERIFY = verification process runs again in the safe environment of the non-personalized security module SM, z. B. Processor chip card, from:
SIGN - signature process
VERIFY - verification process
SM - security module

In the further procedures shown in FIG. 3 of the security modules SM-A and SM-B personalized by the trust center (issuing point) mean:
CAs = Secret, symmetrical key of the issuing office,
A = identity of user A,
B = identity of user B,
SM-A = security module SM of user A,
SM-B = security module SM of user B,
As = secret key of user A,
Bs = secret key of user B,
CA⟨⟨A⟩⟩ = certificate of A = CAs [A, As], A,
CA⟨⟨B⟩⟩ = certificate from B = CAs [B, Bs], B.

Time stamps can also be used to define a limited period of validity for certificates and serial numbers men and women a. (e.g. according to CCITT X.509) can be used.

A signs message "data":

SIGN: CAs [data]

The process runs in the secure environment of security module SM-A. Instead of "data", hash value h (data) "Timestamps" can also be used, Serial numbers corresponding to CCITT X.509 can be used.

A sends a signed message to B:

A → CA⟨⟨A⟩⟩, As [data] → B; or z. B .:
CAs⟨⟨A⟩⟩, As [h (data)]

the process "h (data)" outside the security module SM can be done. The plain text of "data" can also be used be sent.

B verifies the message received by A in SM-B:

All process steps always run in direct order. The SM only gives the outside world the result of Overall process known.

The VERIFY process can also be divided into 2 processes "VERIFY certificate "and" VERIFY signature "are split.

In addition to avoiding asymmetry, this variant II the following advantages of variant I:

• - Virtually all are pro for the signature process processor chip cards suitable as SM. In contrast, for asymmetric process special controller needed.
• - The signature process is no longer just one or very few (asymmetrical) cryptographic methods dependent. Rather, any symmetric can be used (Cryptographic procedure with any key length deploy.
• - Due to the usability of symmetrical Crypto processes are the computing times for signature and verification processes significantly reduced.
• - With a successful attack at once other cryptographic methods are used (Symmetrical) replacement procedures available immediately.
• - It can be compared to asymmetrical processes much simpler key generation process be applied.

The variant II also has the advantage that System works with only one key (disadvantage: chosen plain text - simplified attack possible).

The special properties of an asymmetrical ver driving will be using a lot less  complex, arbitrary symmetrical procedure nachgebil det by integrating two different, "asymmetrical" processes, here: "SIGN" and "VERIFY" called, in the safe environment of an SM.

The authentication of A's identity no longer takes place in the issuing office. Rather is the secret authentication key CAs of the issuing office cannot be read out in the secure environment of all SMs. He is only in SIGN process and used internally in SM in the VERIFY process. The "authentication" of the issuing agency takes place every time new to create an individual Signature instead.

Variant IIa shown in FIG. 4 is a variant of variant II. Like variant Ia, it is not used for generating and verifying a signature, but for agreeing an authentic session key "Ks" between two users A and B, one opposite Want to establish confidential communication (encryption of messages) to third parties.

In FIG. 4 are:
Ks = session-specific secret session key,
SEAL Ks = process for encrypting an authentic session key,
RETRIEVE Ks = Process for verifying and decrypting an authentic session key.

A encrypts session key Ks for B in SM-A:
(here: 1-way token)
SIGN Ks: As [B, rA, Ks]
rA = session number (challenge "A"),
Ks = session key, can also be loaded into the SM from outside or permanently stored in the SM or generated by a random generator in the SM.
B, n, Ks ↔ "data" from variant II.

A sends authentic opening token to B:

A → CA⟨⟨A⟩⟩, As [B, rA, Ks]

The plain text of "B, rA" can also be sent.

B verifies the message received from A in SM-B:

Ks can now be used for encryption purposes within and be used outside the SM.

Other variants e.g. B. with 2-way or 3-way tokens, too with additional parameters (time stamps etc.) z. B. according to CCITT X.509 are also part of the Invention possible.

The advantages and effects of variant IIa correspond to those variant Ia.

Reference list

SIGN = signature process;
VERIFY = verification process;
SM = security module, e.g. B. processor chip card;
CAs = Secret, symmetrical key of the issuing office;
A = identity of user A;
B = identity of user B;
SM-A = SM of user A;
SM-B = SM of user B;
Ks = session-specific secret session key, which can also be loaded from outside into the SM or stored permanently in the SM or generated by a random generator in the SM;
SEAL Ks = process for encrypting an authentic session key;
RETRIEVE Ks = Process for verifying and decrypting an authentic session key;
As = secret key of user A;
Bs = secret key of user B;
CA⟨⟨A⟩⟩ = certificate of A = CAs [A, As], A;
CA⟨⟨B⟩⟩ = certificate of B = CAs [B, Bs], B;

Claims (4)

1 method for authentication and electronic signature for communication connections in which cryptographic methods in connection with hardware-side security modules are used by the users, characterized in that mathematically symmetrical cryptographic methods in connection with at least two fixed and manipulation-safe in the hardware-distributed implementation Environment of the security modules are used before the output of integrated asymmetrical processing processes. 2 The method according to claim 1, characterized in that the security modules with a user before they are issued identity and be authenticated. 3 The method according to claim 1, characterized in that all security modules with a secret before issuing Certification key CAs of the issuing office hen and that this only internally in the security mo dul during the at least two asymmetrical processes processing processes is used. 4 The method according to claim 1 to 3, characterized in that between the users an additional authentic Session key is generated and used.