WO1999034551A1

WO1999034551A1 - Method for safe communications

Info

Publication number: WO1999034551A1
Application number: PCT/IL1997/000435
Authority: WO
Inventors: Mordhai Barkan
Original assignee: Mordhai Barkan
Priority date: 1997-12-29
Filing date: 1997-12-29
Publication date: 1999-07-08
Also published as: AU4119399A; EP1173950A1

Abstract

A method for generating certificates for secure distribution of encryption keys, to establish a secure communication link, comprising the following steps: (a) a key distribution center waits for calls by users (28); (b) a user creates a communications key pair (11); (c) the user calls the center, sends the public key and requests certificate (12); (d) the center verifies that an ID is new. If positive, a certificate is prepared and sent to user (22). The certificate includes the ID together with the public key for that user, and optional additional information; (e) if a certificate was generated in step (d), then the records at center are updated, to include the new certificate (23); (f) if a certificate was generated in step (d), then the user's records are updated (14).

Description

Method for Safe Communications

Technical Field

This invention concerns methods for achieving secure communications with encryption using encryption keys.

The invention relates in particular to such methods which facilitate the secure distribution of the encryption keys, to establish a secure communication link between users who are located at separate locations and had no previous secure communications therebetween.

Background Art

At present, various methods are used in secure voice and/ or data communication for public use, using either analog or digital encryption means. Common to the various encryption methods is the use of an encryption key, which provides a higher level of protection together with flexibility and standardization. Public key encryption, by using separate encryption and decryption keys, offers better protection for encrypted messages. A public key cryptographic system and method was disclosed in Merkle- Hellman U.S. Patent No. 4,218,582; the RSA (Rivest- Shamir- Adleman) encryption system and method was disclosed in U.S. Patent No. 4,405,829.

With the proliferation of encryption machines in commerce and for private use, a situation arises wherein a user desires to establish a secure communication link with another user having an encryption machine. The user poses a problem: How to exchange the encryption keys in a secure way, to establish the secure link. If the key is compromised, then the whole communication is compromised, and the encryption is useless. This is a vicious circle, since a secure link is required to transmit the key to begin with; but, since the other party doesn't have yet the key, the secure link cannot be used to transmit the key itself.

Furthermore, data communication systems face the dangers of eavesdropping and impersonation, with the associated risks of the key being intercepted or a false key being transmitted by an impersonator. Accordingly, means are required for secure key distribution, this being an essential requirement for the widespread use of encryption machines, that is for establishing a secure link between parties which had no previous secure communications therebetween.

The security of the encryption process depends on the security of the encryption key, which depends on the security of the key distribution means; therefore, special means are required to provide a higher level of protection for the key distribution means itself. A directory of public keys could be used, but a fixed list cannot cope with the fast changing situation in this area, with new users joining continuously, users changing address and users changing keys for better protection.

Various attempts at solving the key dissemination problem were devised, for example PGP maintains a public server containing a list of public keys. PGP server accepts and maintains a file with a collection of identification packages (KeylD) . Each identification package includes the name and details of a key holder, together with his/her public key, which are signed (authenticated) by a third party which encrypts the package with his/her private key.

Another party desiring to communicate with such a key holder searches for an identification package signed by someone known/ accepted by them, thus "ensuring" that that is the true key, which truly belongs to the person as claimed; the third party is "known/accepted" in the sense that the caller believes that its encryption key pair are as claimed and are not compromised. Since any single third party may be unknown to the other party, said key holder submits a plurality of identification packages to the PGP server, each signed by a different third party; another party looking for a reliable encryption key has to desiring to communicate with search all the packages belonging to that key holder, until he finds one signed by a third party known to him. Thus, the PGP server maintains a file with a collection of identification packages for a multitude of users, and with a plurality of packages for each user. Thus it may be difficult to keep this vast quantity of information to disseminate it to users.

Another key dissemination method is employed by VeriSign, which distributes digital "certificates" valid for a long time period, for example 5 years.

A certificate includes the name and additional information for a user, together with the public key for that user and the expiry date of the certificate, all encrypted with the private key of the issuing authority. Another certificate is issued to that first issuing authority by a higher second authority, and so on. This is a hierarchical authorization structure, with a user bringing signatures from persons/ entities at several levels, until a level high enough is reached which is also part of the hierarchy of the calling party.

A great effort was invested into ensuring the identity of a user before issuing a certificate, and in keeping the certificates; however, a certificate once issued may be compromised during its long lifetime, in which case it is difficult to replace. The center has no control over the use of an issued certificate while the certificate is still valid, during the long period as set at issue time; only the "black list" at the center may give a warning to that effect, but that can only prevent communications. A reliable key has yet to be exchanged between the parties, which is difficult in this case.

RSA Data Security Inc. offers another system including a center which issues certificates, that is digital documents containing the name and details for a user, together with his/her public key and an expiration date, all encrypted with the private key of the center. The expiration date is a weak link for this system since, as the key approaches its expiry date, the chance of its being compromised increases, and more verification requests will be placed with the center.

If a key is compromised, it is practically impossible to remove it from the server; PGP and RSA only keep a second list (the black list) of disabled or canceled keys, but this is a cumbersome and inefficient method.

If the private key of the RSA or other similar centers is compromised, this results in a "catastrophe" , since anyone can impersonate other users.

Another user of public key encryption is the PC Fax program package offered by Microsoft for the transmission of FAX messages. The FAX may be encrypted using a password or a digital key. Again, they face the same problem of reliable key dissemination. Microsoft advises to exchange diskettes containing the key, clearly a difficult to use method between users located at separate locations. A public key can be exchanged by communication means, and again there is the problem of identifying the other party- how one is to know that the answering party is truly the person it claims to be.

Caller identification is a problem encountered in various situations in the modern period of widespread use of global communications and information exchange.

Another problem with present systems and methods is the "trusted" status of the key distribution center. That is, present systems assume that the center is absolutely reliable and should be trusted unconditionally. However, in real life this may not be true. It is impossible in prior art to verify the center itself during its operation, to test the reliability and dependability of the center. What happens if and when the center's key becomes compromised, certificates are corrupted and users get false answers? There is no answer to these situations in prior art systems.

Still another problem in prior art systems and methods is the random, uncontrolled issuance of user's names. Several users may have the same name, and it may be confusing at times when one tries to find the correspondence between a certificate and a specific person. Suppose, for example, that there are two hundred users named "Smith" and a thousand users named "Baker" , how one is to know with certainty which certificate belongs to each of the above users?

In many applications, it is important to define precisely which certificate corresponds to each user. This may be important, for example, when the certificates are to be used for personal identification, access control, payments or other applications.

It is an objective of the present invention to provide for a method for the secure distribution of encryption keys between users who had no previous secure communications therebetween, with means for overcoming the abovedetailed deficiencies.

Disclosure of Invention

it is an object of the present invention to provide a method for transferring encryption keys between users, to establish a secure communication link between users who had no previous secure communications therebetween.

This object is achieved by a method for safe communications as disclosed in claim 1. In accordance with the invention, the object is basically accomplished by using certificates as a means for transferring public keys between users. Certificates may also be used as means of identification, that is a certificate points to a specific person. Certificates may include additional optional information.

It is another object of the invention to disclose a method for certificate generation. The object is accomplished with a key distribution center. The present disclosure details procedures to be performed by center and users, to generate certificates.

Another object of the invention is to disclose a method for the management of information relating to keys and users and related certificates, at center and by users. The method includes means to enable users to change certificates in a secure way, any time a user desires to do so. This enhances the level of protection against hackers and intruders.

Still another object of the invention is to maintain an unambiguous correspondence between certificates and users, to allow each certificate to identify a specific person. Each user is assigned an unique ID in the system. This may be a user's name or pseudonym or an alphanumeric string. An alphanumeric string may contain a random combination of letters and numbers. The method is flexible, in allowing a person to have a plurality of certificates. The object is achieved with a method for preventing duplicate IDs and for allocating unique IDs (names or pseudonyms or alphanumeric strings) on a "first came, first served" basis.

The invention discloses a method for using certificates and a key distribution center to establish secure communications between users who had no previous communications therebetween.

The invention discloses a method for recovery in case the center's key was compromised, to ensure each user retains their rights in the name/pseudonym/alphanumeric string assigned thereto. This may be important, as a user may be known worldwide under a specific ID or pseudonym, which may serve as a trade name or means of identification, to allow business transactions and communications between users at different locations.

The invention allows to verify the center, to ensure no false information is provided by the center, and that the information is not corrupted. Thus, the center need not be "trusted" unconditionally anymore.

An implementation of a wide-scale, distribution network of key distribution centers is disclosed. The distributed network preserves the special properties of issuing an unique name/pseudonym to each user, and of allowing users to verify the integrity of the centers network. A certificate in the present invention is defined as a document backed by a center, which attests for the existence of an unique ID (like a name or pseudonym or alphanumeric string) and a public key attached thereto. This gives a novel meaning to the term "certificate", allowing for a different use with different benefits than certificates now in use.

For example, an unique ID may be attached to just one person and can identify that person in various transactions. This ensures repeatability of identification in various relationships, without the need for absolute authentication of the user. One benefit is to allow repeat business and relationships while preserving the privacy of each person.

Further objects, advantages and other features of the present invention will become obvious to those skilled in the art upon reading the disclosure set forth hereinafter.

Brief Description of Drawings

The invention will now be described by way of example and with reference to the accompanying drawings in which:

Fig. 1 illustrates a method of certificate generation, performed between a user and a key distribution center. Fig. 2 details the information stored in records for the user and the key distribution center. Fig. 2(A) details the records prior to the certificate issuance, and Fig. 2(B) details the records after the certificate issuance.

Fig. 3 illustrates a method for the use of certificates to prove one's public key, to establish a secure communication link with another user.

Fig. 4 illustrates a method for interaction with a key distribution center, to request certificate information and/or test the center.

Fig. 5 details the structure of a network of distributed key distribution centers.

Modes for Carrying out the Invention

A preferred embodiment of the present invention will now be described by way of example and with reference to the accompanying drawings.

To establish a secure link with other users, each user has to have

(not shown) computer means with display means and input means, digital communication means and encryption/decryption means. These are devices as known in the art and will not be detailed here.

A certificate is a digital document which includes information to identify a user, together with the public key for that user, all signed or encrypted with the private key of a key distribution center. By using certificates with keys therein, it is possible to establish a secure communication link between users who had no previous secure communications therebetween.

Note: Throughout the present disclosure, the terms "name" or "pseudonym" for use in certificates are used as examples of embodiment of the invention, and it is to be meant that any other type of ID may be used instead. That is, a specific name or pseudonym or alphanumeric string may be used. An alphanumeric string may contain any combination of letters and/or numbers.

According to the invention, each user is assigned an unique ID in the system. This may be a user's name or pseudonym or an alphanumeric string. An alphanumeric string may contain a random combination of letters and numbers. An automatic method is disclosed for certificate generation, comprising the following steps:

a. a user connects to a key distribution center, asking for a certificate. The user transmits to center his/her public key;

b. the center compiles an ID in the system, including a name or an alphanumeric string that is unique in the system;

c. the center compiles a certificate, including the ID, the public key for that user and additional optional information, all encrypted or signed with the private key for that center;

d. the center sends the certificate to the user who asked for it.

Fig. 1 illustrates a more detailed method of certificate generation, performed between a user and a key distribution center. Each user has his/her certificate which includes a public encryption key and additional information, as detailed below. The certificate are then used as a means for transferring public keys between users. Method for certificate generation

a. Key Distribution Center waits for calls by users, asking for certificates or other services provided by center (step 21 );

b. user A chooses an ID comprising a name or pseudonym or alphanumeric string. They also create a communications key pair, including a public and a corresponding private key (step 11);

c. user A calls a Key Distribution Center, sends information pertaining to user A, and asks for a certificate (step 12).

The information sent may include the chosen ID ( like a name or pseudonym) and the public communications key generated in (step 11 ).

d. Key Distribution Center receives the request from user. It verifies that the requested ID is new, that is it does not appear in the records kept at the center (step 22). If the ID is new, then a certificate is prepared and sent to the user requesting it.

If an identical ID was found in the records at center, then the user will be informed accordingly. A certificate will not be prepared in this case;

e. user A creates key cancellation pair (step 13), sends the public cancellation key to center together with an optional indication of the certificate it belongs to; f. Key Distribution Center updates records, to include new certificate and cancellation key (public), (step 23). The records at center may include a database of certificates (including the cancellation code for each) and an ID index. The index is optional and may be useful for fast searches, to allow the center to locate other IDs already in the database, in real time. Otherwise, only a certificates database is maintained at center. IDs search may be performed in the certificates database.

g. user A keeps updated records (step 14), including the certificate issued by the key distribution center, the communication key pair and the cancellation key pair.

In another embodiment, in step (c) the user will not ask for a single ID, but will send to center a list of several possible IDs (like names or pseudonyms). The center will investigate each ID in step (d), and will issue a certificate for the first ID which was not found in the existing certificates database. This ensures that each user will receive an unique, different ID.

In yet another embodiment, in step (c) the user will not ask for an ID, but the center will assign in step (d) an ID for each user asking for a certificate. In this case, the center will ensure that each user will receive an unique, different ID. A random generator may be used to create new IDs at center. Each ID thus generated will be verified for duplicates, before it is accepted by the center and is sent to the user.

In another implementation, a user creates a key cancellation pair in (step 12), sends the public key to center together with the other information relating to the requested certificate.

The cancellation code may be a private/public key method, or just a simple password to be presented later by the user. The advantage of a private/public key is that the center needs not be trusted. The center cannot impersonate the user or disclose the key to an unauthorized person, since the center only knows the public key used to open the user's request, and the public key cannot be used to generate a user's request. Therefore, this method is more secure.

A disadvantage of the method, however, is that the user may have difficulty in remembering the cancellation code. The code may be stored in a computer, for example, however the computer may be stolen or the data erased. If that happens, then the user loses his/her capability to make changes in the certificate. This is a most undesired situation.

An alternative is that the cancellation code is just a password, like a name or an alphanumeric string. This is stored in the center and used to identify the user when he/she requests a change at a later time. Thus, the knowledge of the password by the user is proof that he/she is indeed the owner of that certificate and authorized to change it. The advantage is that it may be easier for the user to remember the password, so that the password becomes in effect part of that person.

The certificate generated at the center may be encrypted or signed. It may be signed using a CRC or a hash of the certificate, encrypted with the private key of center.

Each certificate includes the public key for a user, together with identification information for that user (like an ID) and the issue date, all signed or encrypted with the private key of the key distribution center.

The encryption algorithm may be based on a public key algorithm which is symmetrical with respect to the encryption and decryption keys, using a digital signature or encryption with the private (decryption) key of the key distribution center.

Unlike other key distribution methods, in the present invention there is no need for each user to keep local lists of other users' keys; during the link setup transaction, each party sends its certificate to the other. This allows to immediately and reliably establish the identity and the public encryption key of each party. Thus, it is only necessary for each user to keep his/her certificate and to present it to others.

A copy of each certificate is also kept at a key distribution center, which is an authority recognized by all the users of the system, in case a verification is necessary.

Anyone can ask for a certificate. In a preferred embodiment, no severe identification/certification of the user is required, since the certificate identifies a specific person, not a formal name. The person is the one who asked for the certificate. That is, each user receives a certificate that indicates that it was that user who first asked for that name/pseudonym.

In other words, the distribution center ensures that each digital certificate indicates a different, unique name or pseudonym. Each certificate thus issued may uniquely identify a person or entity, that is the person to whom the certificate was issued.

According to the specific application, a center may ask for user identification and may use various verification means, to achieve a desired level of security.

The information in the certificate is attested by a known, recognized authority - a key distribution center. Fig. 2 details one example of a method for storing information in records for the user and the key distribution center, during a certificate issuance process.

A method for certificate generation and update is disclosed. Each new user may be issued a certificate using a simple method. Certificates may be updated using a cancellation code and using a public key encryption method. The novel method is illustrated with the description of the records before and after a new certificate issuance.

Fig. 2(A) details the records prior to the certificate issuance.

Record 15 at user-5 includes the information prepared prior to the issuing of the certificate:

1. an ID like a name or pseudonym to be included in the certificate

2. a communication key pair, including a public key and a corresponding private key. The public key will be sent to the center and will be included in the certificate, whereas the private key will be kept secret by user-5

3. a cancellation key pair, including a public key and a corresponding private key. The public key will be sent to the center, to be used in subsequent changes to the certificate with the center. The private key will be kept secret by user-5. Record 24 at the Key Distribution Center includes a certificates list, for example including certificates No. #1 to No. #N .

This is a list or database or digital file (or files) with certificates for users of the system. Each certificate may include:

* an ID, like a name or pseudonym

* a communications public key

* issuing date/time (not shown), this is the date when the certificate was issued by the center. Optionally, time is indicated as well, to establish a precise issuing moment for priority purposes.

* a cancellation public key. This information is optional and is preferably not included in the certificate, since is usually will not be presented to other users, but is only intended for transactions with the center.

* additional optional information

* encryption or signature of the above with the private key of the center.

Record 25 at the Key Distribution Center is optional, since it includes information already in record 24. It may be helpful, however, to speed up searches for names in the database at the center. Alternatively, a database may include its own indexes, for the same purpose, in which case record 25 is not required. Record 25 may include a list of IDs, names and/or pseudonyms corresponding to the users in the system.

Note: throughout the present disclosure, CRC and hash are used interchangeably. In the actual implementation, each of the two may be used, according to design consideration like the computational effort required, response time, safety required etc.

Fig. 2(B) details the records after the certificate issuance.

Record 16 at user-5 includes the certificate issued by center, together with the encryption keys prepared by user-5. Both key pairs may be kept, or at least the private keys have to be stored, to allow secure communications and cancellation/update of certificates.

The certificate for user-5 may include:

* the ID, name or pseudonym for user-5 * -he communications public key

* issuing date/time (not shown)

* the cancellation public key (optional). This information is preferably not included in the certificate, but in a separate list (not shown). The list is only kept at the center and will be used only when a user requests a change in the certificate * additional optional information

* encrypted or signed of the above with the private key of the key distribution center. Encryption refers to an encryption process with the private key of the center, applied to the certificate. Signature refers to the encryption of a CRC or hash of the certificate, with the private key of the center.

Record 24 at the Key Distribution Center is now updated to also include, in addition to certificates #1 to #N, the certificate for the new user-5, that is certificate number #N+1 .

Optional record 25 at the Key Distribution Center is also updated, to also include, in addition to entries #1 to #N, an entry for the new user-5, that is entry number #N+1.

By using a cancellation code to update certificate or the cancellation code itself, a flexible system is achieved, which allows frequent changes in the certificates.

This provides an additional level of defense against hackers or intruders. Each user is assigned an unique name or pseudonym in their certificate. Thus, the certificate unambiguously identifies each user. A user may have several certificates, for different uses, each with a different ID or name. Each certificate, however, points to that specific user.

To prove their right in the ID/name/pseudonym, a user may use his/her secret key, to prove the relationship between the certificate with the public key therein, and their private key. Thus, a special knowledge (the private key) allows the user to prove their identity and the rights to a specific name in the system.

In another embodiment of the invention, the method includes a step where the center issues a hard copy (printed) announcement of the certificate, and sends it to the user by mail for example. The user may keep the envelope sealed, and use it at a later date to prove priority rights to the assigned name/pseudonym. This may be required if and when the center's key is compromised, and the information in the center is no longer reliable. In that case, users cannot rely anymore on the records stored at the key distribution center to establish priority rights on a specific name or pseudonym. It may happen that several users may claim rights in a specific unique name.

This problem is solved in the present invention with the certificate generation method including the issuance of a hard copy document attesting to the certificate thus generated. The printed document is kept by each user and may be used to prove the priority rights of the legitimate user. Even though a hacker may attack the center, he/she cannot attack all the users in that system. Thus, the system according to the present invention is more secure and it is more difficult to break it down. Even in case the center's key is compromised, the system can recover, while preserving the rights of the users of the system.

A printed document may be issued and sent to user each time a certificate is created or changed.

Method for recovery in case center's key was compromised

a. The key distribution center generates a new encryption key pair, including a public (known) key and a private (secret) key;

b. all the certificates in the system are computed anew, using encryption or signature with the new private key of the center;

c. users can verify the certificates, to ensure the information therein is correct. In case the information is incorrect, the user may request an update or correction accordingly. When a center's key is compromised, it may be expected that certificates were changed, since this may be one of the illegitimate attacker's goals. In case that a user's information at center was corrupted, then that user can again send the relevant information to center and receive a new certificate;

d. each user has a capability to prove his/her priority or rights in a specific name/pseudonym. In case two users claim rights to the same name, then an interference procedure may be used to clarify the user's rights. A method of proof of priority rights for a specific, unique name or pseudonym is implemented using physical means. A printed or copy of a certificate, in a sealed envelope, may be used to prove priority rights on that certificate and the name therein.

A method for secure update of a certificate by the legitimate user is disclosed. There is a need to update certificates, when for example a user suspects or knows that the private key corresponding to that certificate was compromised. Otherwise, it may be a good idea to change the encryption keys from time to time, since one cannot be sure whether the keys are still secure.

As the key is used for longer and longer time periods, the chance of its being compromised increase.

The certificate update method, however, should be secure, to prevent hackers or other unauthorized persons to change other's certificates. Thus, the system should allow only the legitimate user to perform a change in a certificate. The simplest way would be for the user to come to center, be identified and then allowed to change the certificate. This may be difficult, however, if users are located far away from the center, or do not have the spare time to do it.

According to the present invention, a cancellation key pair is created by the user while asking for a certificate. The public key is transferred to center and is stored there as part of the information relating to that certificate. The private key is kept secret by the user.

When the user desires to change the certificate, a request is sent to center, encrypted or signed with that private key. The center can verify the request is legitimate, using the cancellation public key corresponding to that certificate. If the result of the verification is positive, then the center will perform the requested change, otherwise no change will be done in the certificate.

A possible change in a certificate may include the encryption key or the cancellation key itself.

A user may also require the change of their name/pseudonym. In that case, a check will be made by center to ensure there is no name duplicity in the system. If the requested new name is unique, then the request will be accepted and the certificate updated accordingly. Thus, the novel method includes means to enable users to change certificates in a secure way, any time a user desires to do so, while users may be at remote locations.

The invention also discloses a method for the exchange of encryption keys using certificates.

Fig. 3 illustrates a method for the use of certificates to prove one's public key, to establish a secure communication link with another user. It illustrates the use of certificates and center to establish secure communications between User A and User B. A certificate is used to prove one's public key, to establish secure communication link between users who had no prior secure communications therebetween.

According to the invention, in a method of certificate presentation and acceptance, the other party can accept certificate as is, or may decide to verify it with a center. The method allows to establish secure link without center's intervention.

Users may contact a key distribution center occasionally, however this is not absolutely necessary and thus the center will not be overloaded, since it does not have to support each transaction between users. Method for establishing a secure link with certificates

a. User A, the user who initiates a call to establish a secure link with a user B, connects to user B and sends his certificate (step 17);

b. User B decides whether to accept the certificate "as is" or to check it (step 31 ).

Various criteria may be used for that purpose, for example the issuing date of the certificate - if the certificate is older than a year, maybe it is time to check it. Or, if it was known that the center changed their key at a date later than that of the issuing of the certificate, it stands to reason that the certificate may be obsolete. These and/or other criteria may be programmed into the computer of user B and used to evaluate the certificate from user A.

If user B decides to accept the certificate from user A as is, then go to step (f);

c. User B connects to the key distribution center, asking for the certificate for User A (in step 31);

d. The key distribution center answer the inquiry by unconditionally sending the certificate for user A. This is the most updated certificate available; e. User B compares the certificates received from user A and from the key distribution center. If the two correspond, that is are identical in their essential parts, then continue the process, to establish a secure link with the first user; go to step (f). If the certificates do not correspond, then use the key and additional optional parameters from the certificate from center and continue the communication with user A;

f. At this stage, the certificate of user A is accepted by user B.

Now user B presents his/her certificate to user A, and a similar process takes place, only now user A decides whether to accept the certificate as presented by user B, or to verify it with the center (not shown), in (step 18), (step 32);

g. If the certificates from users A and B, each is accepted by the other user, then a secure link is established between the users, with the public keys contained in the certificates and the private key kept secret by each user.

Note: in step (e) above, user B compares only the essential parts in the certificates, that is the parameters which are to be fixed, like the user ID and the encryption key. There are temporary parameters, which are expected to change and should not affect the comparison, like the issuance date and time of the certificate. In any case, the method to be used by users will designate which parts of a certificate are considered essential and should be taken into account during a certificate comparison.

The present invention discloses a method for center verification by users. In prior art, the center was considered secure and could not be verified in real time, that is during its daily operation. In these systems, a compromise of the center's key could be catastrophic to the whole system. Since the center is just one location or facility, it may be possible to compromise that center.

A key distribution center 26 answers any user or non-user who inquires about a certificate of any other user or their own certificate. Center 26 answers unconditionally to each inquiry, without requiring for the identity of the user who made the inquiry.

For example, User-1 41 makes an inquiry about his own certificate, and receives the Certificate-User-1 51 . That inquiry may be made to verify the center 2, that the center functions correctly. Another user User-3 may verify the center 2 by asking for her certificate, and will receive the Certificate-User-3 53.

Other users may ask certificates to establish a link to User-1 , like for example User-6 42 and User-11 44, who asked for such a certificate and received from center 2 the Certificate-User-1 52 and certificate-User-1 54, respectively.

Center 2 cannot know when an inquiry is for establishing a secure link, or to verify the center. Thus no attack by center 2 can be directed toward a specific user

In the present invention, there is no need anymore to unconditionally trust the key distribution center. The center need not be believed to be absolutely secure, at a security level above the users. Actually this may not be so. Users are given the power or capability to test the key distribution center. The center thus becomes highly visible. Users may verify the center anytime, to ensure its correct operation. If incorrect operation was detected, then actions may be taken to correct the situation and thus recover from a dangerous situation.

This provision also prevents the center from mounting an attack directed against a specific user. For example, a nonhonest operator may decide to mislead a specific company for which he/she may have a personal interest in, or dislike for. The method is achieved with a center programmed to answer to any inquiry regarding a certificate, without requiring identification of the inquirer. Thus, anyone can call the key distribution center and ask anonymously about the certificate for any desired user.

This can be used to verify the center, as follows: each user may ask about their own certificate. If the information is not correct, the user will detect that, since each user knows his/her certificate. The center cannot know whether a specific inquiry is a request for information, or a verification by a user, since the inquirer is anonymous.

This allows the center to be interrogated and verified by the users, all the time. Moreover, since the center is being accessed anonymously, this helps prevent a directed attack, towards a specific user. The center cannot recognize a specific user, since the inquiry is anonymous. Anyone may present questions, not only recognized users.

Method for verification of the key distribution center

a. a key distribution center stores certificates for a plurality of users in the system. The center is programmed to answer inquiries regarding these certificates unconditionally. That is, anyone can ask about any certificate in the system, and the center will answer that inquiry;

b. the center waits continuously for inquiries from callers;

c. a caller connects the center and asks for his/her own certificate. The inquiry refers to the unique ID (like a name or pseudonym) in that certificate. This is based on the fact that each certificate is issued with an unique name or pseudonym. The same person may ask for several certificates, however the name in each certificate will be different.

The caller asks for the certificate without identifying himself/herself in any way;

d. the center answers the inquiry by sending to caller the requested certificate;

e. the caller compares the received certificate with the true information relating to his/her certificate, to check whether the answer from the center is true.

In step (e) above, a caller may ask for his/her own certificate, which is known to them. The answer from center can be evaluated, to check whether it contains the required data. In still another embodiment, in step (d) the center's answers includes additional information. The additional information may include the ID in the certificate, the center identification, time and date of the transaction, all encrypted or signed with the private key of the center.

The additional information may be used to track an error to source. Thus, if an erroneous answer was received, then a user has proof (the center's signature) that that transaction took place. The details of the transaction may be used to find the operator who was in charge, and/or the computer used, or the software package operating at that time. The transaction details may be compared with a transaction log kept at the center, to find the source of the error. The center identification may be useful in a distributed system with a plurality of centers. This allows to find the center responsible for the error, even in a large network. This would be a very difficult task without the present method.

The method includes a hierarchical key dissemination center network.

The invention also discloses a method for the implementation of a wide-scale, distribution network of key distribution centers. This allows the issuance of an unique name/pseudonym to each user, in a wide-scale system with many, interlinked key distribution centers.

Various users may connect to any of many centers in the net, in a distributed system.

Thus, users 71 , 74 or 75 may connect to center A 61 to ask for the certificate of another user, or to obtain a certificate for themselves as detailed above. When asking for a certificate, center A 61 can assign an unique ID/name/pseudonym to each user, for example by adding a prefix "A" to each name, and verifying that no such name is in center A 61 . Other centers will add a different prefix, so the total name will be different for each user in the system, without having to verify each name for each user with all the centers.

Thus, for example, all the names/pseudonyms issued by center A 61 will have the prefix "A", whereas all the names issued by center AB 62 will have the prefix "AB" which is different. Thus, the names issued by each of the centers 61 , 62, 63, 64, 65 is guaranteed to be different from the names issued by any other center in the network.

Similarly, users 72 and 72 may connect to center ABM 63 to ask for a certificate there or to issue a new certificate. Users 76 and 77 may connect to a local center AAD 65 for that purpose. In another implementation, the names from each center may have a different suffix or other distinguishing feature, unique to each of the centers.

In still another embodiment, each user may ask for any ID, name or pseudonym, and then the local center will connect to the other centers to ensure the name requested is unique on the whole network.

Otherwise, the link between the centers may be used to update a list in each center, including the names of all the users in the whole system. In that case, there is no need to connect to the other centers to verify each name, since a complete list is included with each center.

Each center may compile an ID so that the ID includes unique characters to identify that issuing center. These characters may comprise one letter or number or a combination thereof. This method ensures that, in an environment with a plurality of centers, there will be no duplicate ID names, that is each ID is unique in the whole system. Using the above method, unique IDs are issued by the various centers, even if there is no communication and coordination between the centers.

In one embodiment, the first letters (the prefix) in the ID are used to identify the issuing center. In another embodiment, the suffix identifies the center. The unique characters may be located anywhere in the ID string, in any location as long as that location is agreed upon between the certificate issuing centers.

Another advantage of IDs with center identification is that the method allows for better center verification by users. A problem in prior art key issuing centers was that the center had to be trusted, and users could not verify it. In the present method, means are provided to allow users to verify the center, as detailed elsewhere in the present disclosure. There is a difficulty, however, to verify the center during a new certificate issuance, since the user has no prior knowledge regarding existing IDs, and the ID compilation may involve many centers. How can a user verify all the centers to ensure the process was OK? The ID verification may involve a plurality of centers as well as the communications therebetween.

The novel method in the present invention provides a solution to this problem, with the inclusion of a string in the ID which identifies the issuing center. Thus, a user has only to verify a specific center, a much easier and practical task.

A user may ask for several certificates, with related names or IDs.

For example, suppose a user was given the unique ID or name X456MB. The user may ask for additional certificates with IDs of X456MB2, X456MB3,

X456MB5, X456MB17 etc. To implement this scheme, a novel method of strings comparison is defined. In prior art, two strings are considered different if at least one character is different among them. This allows one user to receive, for example, the ID string X456MB and the other - the string X456MB17. In such prior art systems, the related names certificate could not be implemented, since the related names could be assigned at random to unrelated users.

The new method for string comparison defines two strings to be different if they differ in at least one character, AND none of the strings is included in its entirety in the other string. This prevents two related strings to be assigned to various users. For a specific user, only the usual string comparison method is applied between IDs for that user. The same user, therefore, may ask for several certificates with related IDs.

The above methods for secure distribution of encryption keys may be used in any case where at least one of the users does not have the updated encryption key of the other. One application was illustrated above, that is in case the users had no prior communications therebetween, so they had no prior opportunity to exchange keys. Another case is when one of the users (or both) changed their certificate since the last communication. Then the other user may have a certificate and a key, but they are obsolete. The method may be used for encryption keys update.

A certificate in the present invention is a document backed by a center, which attests for the existence of an unique ID (like a name or pseudonym or alphanumeric string) and a public key attached thereto.

This gives a novel meaning to the term "certificate", providing for a different use with different benefits than certificates now in use. Thus, an unique ID is attached to just one person and can identify that person in various transactions. Others know that the bearer of the certificate is the same person all the time, no matter their location, communication server or other circumstances. This ensures repeatability of identification in various relationships.

The repeatability is achieved, however, without the need for that person's absolute identification and authentication, as required in prior art systems and methods. The ID owner may prove their ownership with the secret key corresponding to the public key in the certificate, and may control the certificate, to change it for example, using the cancellation key.

An example of the problem in prior art systems is a person who contacts a database, pays for the use and is known there as a customer. That person may desire that his identity not be know publicly. He may desire that others not know of his use of the database and his specific questions in that database. In prior art systems, the database operator always knows the identity of the user. That information may be made available to others as well.

Another example is a person who deposits cash in a bank account, and desires to withdraw it at a later time. Banks now demand user's identification. This may not be necessary, since the user has the right to deposit money and take it back, no matter her identity.

With the contemporary proliferation of databases and fast computers with fast communications therebetween, the people may find it difficult to protect their privacy. All their payments, travel information and other activities are visible to others. The present method allows for users to anonymously use various services, while allowing for repeatability in relationships, in that their partners can recognize them in any transaction.

In the novel method, the ID is a privilege of the user, who may present it in a certificate whenever the user desires to do so. It cannot be used, however, by others to intrude the user's privacy or for other illegitimate ends.

The prior art E-mail address has some similarity to the novel ID, in that an unique address is given to each user in the Internet, and a user may have several E-mail addresses. The similarity ends here, however. E-mail address is attached to a specific server or Internet provider, and a user cannot take it to another server. The novel ID is the property of the user, and the user can take it with him anywhere, can use it from any location and platform.

An E-mail address is given to a specific, identified person, so the anonymity of the user is not preserved. In the present method, however, an ID name cannot be related to a specific person, so the privacy of that person is preserved.

Moreover, there is no relationship between E-mail address and a public key corresponding to that user.

Certificates in prior art include a pseudonym (or digital ID) and a public key, however there is a predefined relationship between the two. For example, the pseudonym may be the hash of the public key. Other fixed relationships may be used. This does not allow a user to keep her pseudonym while changing the public key, since a new public key will automatically result in a new pseudonym or ID.

The disadvantage is that a user may desire to keep their ID (by which he is know by others) but change the encryption keys (for security reasons for example) This is not possible in prior art systems.

In the novel method of certificates, a user may change his private/public keys and ask for a new certificate, while using the same ID or name/pseudonym. This ensures others that it is the same person who is presenting the new certificate.

The center attests that the user who has that ID or name/pseudonym, declared that their updated public key is as stated in that certificate.

In the novel method, no one has to be trusted. The center can be verified, and in any case has no knowledge of the user's identity, so the center cannot disclose it. Each user discloses only as much information as he desires.

Another embodiment of the invention is the attachment of unique numbers or IDs to various devices. These may include laptop computers, telephones, fax machines and more. Any time the device is used, it transmits its unique ID to the other party.

A user may take that device anywhere, with the benefit that unique identification is provided. The other side knows that that a specific device is being used, which belongs to a specific user.

A complete certificate may be included in the device as well. This ensures the repeatability of relationships, without the need to disclose the actual identity of each user.

It will be recognized that the foregoing is but one example of an apparatus and method within the scope of the present invention and that various modifications will occur to those skilled in the art upon reading the disclosure set forth hereinbefore.

Claims

1 . A method for generating certificates to be used in secure distribution of encryption keys, to establish a secure communication link between users, comprising the following steps:

a. a key distribution center waits for calls by users, asking for certificates or other services provided by center;

b. a user creates a communications key pair, including a public and a corresponding private key;

c. the user calls the key distribution center, sends the public key and requests a certificate ;

d. the key distribution center receives the request from the user, and verifies that a tentative ID comprising a name or pseudonym or alphanumeric string is new, that is it does not appear in the records kept at the center and, if the ID is new, then a certificate is prepared and sent to the user requesting it, and wherein the certificate includes the ID together with the public key for that user, and optional additional information;

e. if a certificate was generated in step (d), then the records at center are updated, to include the new certificate; f. if a certificate was generated in step (d), then the user's records are updated, to include the new certificate together with the private key generated in step (b).

2. The method for generating certificates according to claim 1 , wherein the tentative ID comprising a name or pseudonym or alphanumeric string is defined by the user and is sent to the center.

3. The method for generating certificates according to claim 1 , wherein a list of tentative ID names and/or pseudonyms and/or alphanumeric strings is defined by the user and is sent to the center, and wherein the center verifies each ID and accepts an ID which has no duplicates in records at center.

4. The method for generating certificates according to claim 1 , wherein the tentative ID is automatically generated by the key distribution center.

5. The method for generating certificates according to claim 1 , wherein the user further generates a cancellation password and sends it to the center, to be used to identify the user when the user requests future changes in the certificate.

6. The method for generating certificates according to claim 1 , wherein the certificate further includes the issuing date and/or time.

7. The method for generating certificates according to claim 1 , wherein the certificate is encrypted or signed with the private key of the center.

8. A method for secure distribution of encryption keys using certificates, to establish a secure communication link between users, comprising the following steps:

a. A first user, the user who initiates a call to establish a secure link with a second user, connects to a second user and sends his certificate;

b. the second user decides whether to accept the certificate "as is" or to check it.

If the second user decides to accept the certificate from the first user as is, then go to step (f);

c. the second user connects to a key distribution center, asking for the certificate for the first user; d. the key distribution center answers the inquiry by sending the certificate for the first user. This is the most up-to-date certificate available;

e. the second user compares the certificates received from the first user and from the key distribution center. If the two correspond, that is are identical in their essential parts, then continue the process, to establish a secure link with the first user; go to step (f).

If the certificates do not correspond, then use the key and additional optional parameters from the certificate from center and continue the communication with the first user.

f. at this stage, the certificate of the first user is accepted by the second user.

Now the second user presents his/her certificate to the first user;

g. the first user decides whether to accept the certificate "as is" or to check it.

If the first user decides to accept the certificate from the second user as is, then go to step (x);

h. the first user connects to a key distribution center, asking for the certificate for the second user; i. the key distribution center answers the inquiry by sending the certificate for the second user. This is the most up-to-date certificate available;

j. the first user compares the certificates received from the second user and from the key distribution center. If the two correspond, that is are identical in their essential parts, then continue the process, to establish a secure link with the first user; go to step (x). If the certificates do not correspond, then use the key and additional optional parameters from the certificate from center and continue the communication with the second user;

x. establish secure communications between the first and second users, using the public keys in the certificates exchanged between the users.

9. The method for secure distribution of encryption keys according to claim 8, wherein each certificate is identified with the user's ID comprising a name or pseudonym or alphanumeric string in that certificate, further each ID is unique in the system and each inquirer may ask for a specific certificate by indicating the ID contained in that certificate.

10. The method for secure distribution of encryption keys according to claim 8, wherein the key distribution center is programmed to answer any inquiry by unconditionally sending the certificate requested, without asking for the identity of or information pertaining to the inquirer.

11. A method for verification of a key distribution center by users, comprising the following steps:

a. the key distribution center stores certificates for a plurality of users in the system. The center is programmed to answer inquiries regarding these certificates unconditionally, That is, anyone can ask about any certificate in the system, and the center will answer that inquiry;

b. the center waits continuously for inquiries from callers;

c. a caller connects the center and asks for a certificate for a specific user, wherein the caller asks for the certificate without identifying himself/herself in any way;

e. the caller compares the received certificate with other information available to them, to check whether the answer from the center is true.

12. The center verification method according to claim 11 , wherein a caller asks for his/her own certificate at different times, stores the results and compares the various answers to detect inconsistency, and wherein a center error is declared if at least one of the certificates received are not as required.

13. The center verification method according to claim 11 , wherein each certificate is identified with the user's ID comprising a name or pseudonym or alphanumeric string in that certificate, further each ID is unique in the system and each inquirer may ask for a specific certificate by indicating the ID contained in that certificate.

14. The center verification method according to claim 11 , wherein the center answers with the required certificate and additional information, with the additional information being encrypted or signed with the private key of the center.

15. The center verification method according to claim 14, wherein the additional information includes the time and/or date of the inquiry and response.

16. The center verification method according to claim 14, wherein the additional information includes the identification of the key distribution center.