KEY DISTRIBUTION SYSTEM

Abstract: Key distribution system for public key certificates. By a user A, registered at a server SV1, the public key of a user Y, registered at a server SV3, can be calculated from a public key of user Y signed with the secret key of SV3 ({Pky}SKsv3), a number of cross-certificates ({PKsv3}SKsv2, {PKsv2}SKsv1), and the public key (PKsv1) of server SV1. If the user must perform such a calculation himself, that would impose a substantial load on the processing capacity of his terminal. As an improvement, it is suggested, as a service to the users, to let the servers generate key certificates of external users not registered at the same server. The key certificates are thereto recertified into certificates which are digitally signed with the aid of the SK of the own server SV1 ({PKx}SKsv1) and are made available to the local users on request.

Description: Title: Key distribution system. A. BACKGROUND OF THE INVENTION The invention relates to a key distribution system. Two cryptographic techniques exist for securing electronic communication: secret key systems and public/private (secret) key (PSK) systems. PSK systems are used in particular when the communication partners do not know each other beforehand. In PSK systems, each user has a private (secret) key (SK) and a thereto related public key (PK) . The PKs of the different users are available at a Trusted Third Party (TTP) , incorporated in a TTP server (SV). The SK is known only to the user. Assume that a user A and a user B are registered at a server SVl. User A has a secret code, SKa, his public key, PKa, being stored in the server SVl. User B also has a secret key, SKb , his public key also being stored in the server SVl. The server makes certificates of the public user keys PKa, PKb , etc. available to users who ask for them. The certificate of a PK comprises the PK, provided with a digital signature, making use of the SK of the server; such key certificates are hereinafter represented as {PKa} SKsvl, {PKb)SKsvl, etc., where SKsvl represents the secret key of server SVl. In this way, users can avail themselves of PKs which are certified by means of the digital signature of the TTP server where they are registered, whereby their integrity is guaranteed. By means of the public key of the server, PKsvl, which is made available to every user registered at SVl, user A, for example, can extract PKb from the received key certificate {PKb}SKsvl (PKb = { {PKb} SKsvl)PKsvl) in order to subsequently encrypt with PKb a message which is to be sent to user B. Users who are registered at the same TTP server can make use of key certificates which are certified by means of the SK of that same TTP server, for example {PKa} SKsvl, {PKb} SKsvl, {PKc} SKsvl, etc. All users can extract reliable keys, PKa, PKb, PKc, from the received certificates, namely by means of the PK of the server where they are registered. It is different if there are more servers and users whoare not registered at the same server. For example, user A is registered at server SVl and user X at server SV2. In order to send an encrypted message to X which can be deciphered by X with the aid of his SK, SKx, A requires PKx. That is administered by his SV2. A, however, does not have a relationship with SV2. User A requests his own server, SVl, to send him a certificate of PKx. SVl routes said request to server SV2 , which thereupon sends a certificate of PKx, {PKx}SKsv2, to SVl. Said certificate is thus certified by means of the SK of SV2. SVl sends the certificate, {PKx}SKsv2, to user A. User A, however, does not have the PK of SV2 at its disposal, and therefore can not extract PKx from {PKx)SKsv2. SVl therefore also sends to A a cross-certificate of SVl and SV2: { PKsv2 } SKsvl . A then uses that, together with PKsvl, to extract PKx from {PKx}SKsv2: PKx = { { {PKx} SKsv2 } {PKsv2}SKsvl PKsvl. The more servers which need to be accessed to obtain the PK of an "external" user X not registered at the same TTP server, the greater the computational capacity that will required of A to extract (calculate) PKx before being able to communicate with X. For n servers, the PKx is calculated from: PKx - {{ ... {{{PKx}SKsvn}PKsvn}SKsvn-l}PKsvn-l}SKsvn-2)PKsvn- 2} ... }SKsvl}PKsvl. It is clear that such a process can require a considerable amount of time. B. SUMMARY OF THE INVENTION The invention seeks to bring about an improvement in the above , whereby the speed of communication can be increased considerably, and whereby the computational capacity of the user terminals can be restricted. Further, the application software (and application hardware) of the user can be less sophisticated. According to the invention, it is provided that in one or more local servers, for example batch-wise, that is, at set times, locally useable certificates are created and stored of public keys of external users not registered at that same local server: re-certification of the PKs of external users. The PKs re-certified in this way are formed by the PKs of said external users , but certified with the SK of the own server SVl: {PKx} SKsvl. Said certificates can then, just as the certificates of the local users, be made available to the local users registered at the SV upon request. From such a certificate, {PKx)SKsvl, the local user can extract the key of an external user X, making use of the public key of his own server, PKsvl. Hereby the user does not need to perform a complex calculation, in the form of PKx = {{...{{ (PKx}SKsvn}PKsvn}SKsvn-l}PKsvn-l}SKsvn-2}PKsvn- 2} ... } SKsvl } PKsvl , but can suffice with the calculation PKx = { {PKx} SKsvl} PKsvl, the same as the calculation for extracting keys of local users. C. EXEMPLARY EMBODIMENT FIG. 1 shows a network with a number of TTP servers SVl, SV2 and SV3. Users A, B, X and Y are connected to the servers. A has a secret key SKa, his public key, PKa, being stored in the server SVl. B has a secret key SKb, his public key also being stored in the server SVl. X has a secret key SKx, his public key PKx being stored in server SV2. Finally, Y has a secret key SKy, his public key, PKy, being stored in server SV3. Certificates of the public user keys PKa and PKb are made available by server SVl, certificates of PKx by server SV2 , and certificates of PKy by server SV3. The servers themselves respectively have secret keys SKsvl, SKsv2 and SKsv3 , and public keys PKsvl, PKsv2 and PKsv3. If user A wishes to send a message to user B, user A requires key PKb, so that user B can decipher the received message, which is encrypted with PKb , with the aid of his own private key SKb . A therefore requests the key certificate {PKb} SKsvl at server SVl. A calculates PKb from the received certificate with the aid of PKsvl: PKb = {{PKb} SKsvl}PKsvl. According to the prior art, the communication between A and X would take place as follows : In order to be able to communicate with X, A requires PKx. The certificate thereof, {PKx}SKsv2, is registered in SV2. A requests his own local server SVl to send him {PKx}SKsv2. SVl requests said certificate {PKx}SKsv2 from SV2 , and sends said certificate on to user A. Since A does not have PKsv2 at its disposal, SVl also sends a cross-certificate {PKsv2 } SKsvl , present in said server, to A. Initially, A already has PKsvl (i) at its disposal and can now, with the aid of the cross-certificate {PKsv2} SKsvl (ii) received from SVl, extract PKx from the certificate {PKx}SKsv2 (iii) received via SVl from SV2: PKx = { { {PKx}SKsv2} (iii) {PKsv2 } SKsvl } (ii) PKsvl(i) . The more servers which need to be accessed for obtaining the PK of an external user, the greater the computational capacity which will be required of A. Thus, in communication between user A and user Y, connected to server SV3 (via server SV2) , the public key of Y, PKy, must be calculated from: PKy = { { { {PKy}SKsv3} (iv) { PKsv3 } SKsv2 } (iii) {PKsv2} SKsvl}(ii) PKsvl(i) . Herein, part (iv) is the certificate of the public key PKy of user Y supplied by server SV3 to server SV2 , certified by the secret key of SV3 , SKsv3. In this case, two cross-certificates are required in order to enable user A to calculate PKy from {PKy}SKsv3, namely the cross - certificate {PKsv3}SKsv2 (iii) and the cross-certificate (PKsv2)SKsvl (ii), together with the public key PKsvl (i) already present at A of its own server SVl. It is clear that such a calculation can require a considerable amount of time. Furthermore, the user software and hardware must be relatively complex. The invention is based on the insight that re-certifying nonlocal key certificates by means of cross -certificates can be more expediently performed by the key distribution system, that is to say by the servers , than by the users . According to the invention, it is provided for that the user does not need to calculate the public key of an external (non-local) user from a series of cross-certificates, but that the key certificates of non-local users also are made available in the same form, namely certified with the same digital signature of the local server, as the key certificates of the local users. It is suggested that making key certificates of non-local users available to local users be offered as service. Such a service allows users to save substantially on the processing possibilities of their local terminals. Further, the administration of the certificates also becomes easier, partly because key changing becomes easier. In the implementation of the suggested service, two options are possible: 1. periodically, locally useable key certificates, re-certified with the SK of the local TTP server, are made batch-wise of the external users or a relevant group thereof; 2. the moment the local user requests it, a locally useable key certificate of the desired external PK, re-certified with the SK of the local server, is generated by the local server. The advantage of option 1 is that, provided a key certificate has been made of the desired external user, said certificate no longer needs to be generated the moment there is a demand for it. A disadvantage is that many certificates are generated for which there is no or only little demand, while nevertheless storage capacity on the local server is necessary thereto. Further, such files present on the servers must be kept up to date. The advantage of the second option is that the certificates are always " fresh" and that no storage capacity is required for large numbers of certificates . A disadvantage is that the server will only start calculating a requested certificate the moment there is demand for it.

Claims: D . CLAIMS 1. Key distribution system for distributing public keys via servers (SVl, ...), where users (A, ...) are registered; where key certificates ({PKa} SKsvl, ...) are made available by the servers, that is to say, public keys (PKa, ...) which are digitally signed with the aid of the secret key (SKsvl) of the server, characterised in that a local server (SVl) makes available to its own users (A, B) recertified key certificates ({PKxJSKsvl) of users (X, Y) not registered at said local server, that is to say, public keys (PKx) of non-own users (X, Y) , being digitally signed with the aid of the secret key (SKsvl) of the local server (SVl) . 2. System according to Claim 1, characterised in that the local server (SVl) generates the key certificates ({PKx} SKsvl, {PKy} SKsvl) of users (X, Y) , not registered at said server (SVl), at moments which are independent of the moments at which users (A, B, ...) registered at said local server (SVl), request such key certificates. 3. System according to Claim 1, characterised in that the local server (SVl) generates the key certificate ({PKx} SKsvl) of a user (X) not registered at said server (SVl) as soon as an own user (A, B, ...) requests said key certificate.

Inventors: DE BOER MARTEN, KLEINHUIS GEERT, QUAK JACOBUS THEODORES WILLEM, DE BOER, MARTEN, KLEINHUIS, GEERT, QUAK, JACOBUS, THEODORES, WILLEM
Applicants: BOER MARTEN DE, KLEINHUIS GEERT, NEDERLAND PTT, QUAK JACOBUS THEODORES WILLEM, DE BOER, MARTEN, KLEINHUIS, GEERT, KONINKLIJKE PTT NEDERLAND N.V., QUAK, JACOBUS, THEODORES, WILLEM
Application year: 1998
Main classification: H04L9
IPC codes: H04L9