WO2001029730A1

WO2001029730A1 - Algorithm-independent encryption method

Info

Publication number: WO2001029730A1
Application number: PCT/US2000/028263
Authority: WO
Inventors: Patrick Zuili
Original assignee: Net I Trust Corporation
Priority date: 1999-10-15
Filing date: 2000-10-12
Publication date: 2001-04-26
Also published as: AU1332001A

Abstract

A system and method for providing remote encryption services over a distributed network.

Description

ALGORITHM-INDEPENDENT ENCRYPTION METHOD

Field of the Invention This invention relates generally to encryption of the type used in conjunction with computer networks and, in particular, to an encryption method which allows two parties to exchange an encrypted file independent of the particular encryption algorithm implemented or information exchanged.

Background of the Invention Encryption is a commonly used method to protect sensitive information in computer systems. It is especially useful for protecting files while they are being transmitted over unsecure networks with many potential eavesdroppers. One problem that has arisen with the growing popularity of this type of communication is that the number of different algorithms used to encrypt data have grown significantly. Popular examples include DES, 3DES, IDEA, Blowfish, RC4, and many others.

In order for two parties to successfully exchange an encrypted file, they must both agree on the algorithm to be used and on any additional information (such as a secret key) that is needed to perform the encryption. This problem is complicated by varying standards in different countries, and also by varying legal restrictions on encryption software.

Summary of the Invention This invention solves this problem by allowing two parties to exchange an encrypted file without regard to the particular encryption algorithm or encryption information needed. It transparently supplies any required encryption software to both parties, and handles the exchange of the encryption information needed to actually encrypt and decrypt the file, taking into account any local restrictions and standards that may affect either party. Broadly, the process of sending an encrypted file from a client A to a client B through a computer network using certification server C includes the step of sending A an encrypted message from C containing the address of a site on the network having an encryption algorithm to be used by A in encrypting the file. The message is decrypted at A, and the encryption algorithm is used to encrypt the file and send it to B. B is sent an encrypted message from C containing the address of a site on the network having a decryption algorithm to be used by B in decrypting the file, enabling the message to be decrypted at B using the decryption algorithm.

Of course, the same basic algorithm maybe used to encryption and decryption purposes, though the encryption and decryption algorithms may be held at different sites on the network. The messages from C may be encrypted using any available mechanism, including public or private key cryptography. In the preferred embodiment, the method further includes the step of registering A and B at C prior to sending the encrypted messages. Such registration preferably includes comparing decrypted and cleartext versions of the e-mail addresses of A and B. The registration process also preferably includes the step of providing A and B with the ability to determine the actual address of C from a translated address, which may be statically or dynamically generated. For enhanced security, the step of registering A and B may also include verifying some or all of the following information at C: user's first name, last name, birthdate, postal or zip code, mother's maiden name, password, current time, and a hardware serial number. The password may be a hieroglyphic password according to disclosed techniques.

The method preferably further includes the step of decrypting and responding to an "ENCRYPTION REQUEST" message from A at C prior to sending A the encrypted message used to locate the file encryption algorithm, as well as decrypting and responding to a "DECRYPTION REQUEST" message from B at C prior to sending B the encrypted message used to locate the file decryption algorithm. One or more back-up certification servers may optionally be provided in the event that the primary server is down or congested.

Brief Description of the Drawings

FIGURE 1 is a diagram which depicts a basic flow of information according to a preferred embodiment of the invention;

FIGURE 2 is a drawing which shows how a system according to the invention is initialized prior to use; FIGURE 3 is flow diagram which illustrates how a client A registers;

FIGURE 4 is a drawing which shows how a client B registers; FIGURE 5 is a flow diagram which shows how a message from client A is encrypted;

FIGURE 6 is a flow diagram which illustrates how an encrypted file is sent from client A via electronic mail; and

FIGURE 7 shows how client B decrypts the file from client A once it is received. Detailed Description of the Invention Reference is made to Figure 1, wherein the invention will now be described with reference to the components depicted in boxes 102-124.

102. Third Server. This is a certification server which stores a certification database as described herein below. The certification server consists of a computer having an IP address which can be assigned dynamically (at run-time) or statically (permanently assigned). In this description, the IP address of the certification server will be referred to as "IP Number 1 ". As with the servers depicted with boxes 104 and 106, the certification server communicates using a private or public TCP/IP network.

104. Third Server TA (Certification Backup Server TA). This is another certification server which serves as a backup for the main server in box 102. It has an identical copy of the same certification database described in box 102. It also comprises a single computer which has either a statically or dynamically assigned IP address. In this description, the IP address of this server will be called "IP Number 2." It communicates using a private or public TCP/IP network.

106. Third Server TB (Certification Backup Server TB). This is another certification server which serves as a backup to the primary server in box 102, and has an identical copy of the same certification database described in box 102 and 104. It also consists of a single computer which has either a statically or dynamically assigned IP address. It will be called "IP Number 3," and it also communicates using a private or public TCP/IP network. There can be an unlimited number of backup certification servers, which in the report are called TA, TB, TC, etc. There can be only one certification database, however, which is shared between all certification servers.

108. Client A. This box represents a typical client computer interfaced to the system. The computer preferably uses encryption software including an executable file (the program), and three OCX files: siscom.ocx used for communication, siscomp.ocx used for compression, and gatea.ocx, which handles the encryption. The latter OCX file is initially resident in the computer's memory, and is initially blank (i.e. it contains no code). Client A communicates with the servers using standard TCP/IP. It also has access to email through an Internet Service Provider (ISP), which is depicted in box 1 10.

1 10. Client A's e-mail access. Client A can access its email using any standard email protocol, including POP, 1MAP, POP 3, etc.

1 12. This box represents removable media support, such as CD-R's, floppy disks, etc., that can be used later to transfer encrypted files between client A and client B.

1 14. Client B's e-mail. This box is identical to box 1 10, and indicates the e- mail used by Client B (box 1 16). As with box 1 10, Client B can use any standard e- mail protocol, including POP, IMAP, POP3, etc. 1 16. Client B. This box is identical to box 108, and represents another client computer interfaced to the system. As with Client A, this client runs encryption software including an exe (executable) file, and 3 OCX files: siscom.ocx which handles communication, siscomp.ocx which handles compression, and gatea.ocx which handles encryption. Gatea.ocx is initially loaded in the computer's memory, and is empty (with no code).

118. Web 1. This is a web server accessed by the clients. It contains a web page which the clients may view, and three translated IP addresses (Translated IP Number 1, Translated IP Number 2, and Translated IP Number 3). These addresses are translated versions of IP addresses 1-3 from boxes 102-106. The way in which an IP address is translated is described in further detail below. The web server also contains encryption OCX controls, similar to the clients', and some advertising which will be sent to client which use the system. This box is identical to boxes 120, 122, and 124.

120. Web 2. This box is identical to boxes 1 18, 122, and 124, and represents another web server that can be accessed by the clients. It contains the same software, translated IP addresses, and OCX controls as Web 1. It also optionally contains advertising which may be sent to clients. 122. Web 3. This box is identical to boxes 1 18, 120, and 124, and represents another web server that can be accessed by the clients. It contains the same software, translated IP addresses, and OCX controls as the other servers. It also optionally contains advertising which may be sent to clients.

124. Web 4. This box is identical to boxes 118, 120, and 122, and represents another web server that can be accessed by the clients. It contains the same software and OCX controls as the other servers. It also optionally contains advertising which may be sent to clients.

There are several distinct phases of operation of the software. Each phase is described in detail in the following sections. Phase 1: Setup and Initialization

A. Certification Server Setup:

Figure 2 shows how the system is initialized prior to use. Boxes 126-148 are exact copies of boxes 102-124. To initialize the system, the certification server (boxes 102 and 126) translates the IP addresses of all certification servers (TA, TB, etc., boxes 102-106 and 126-130), and sends the translated IP addresses to all of the web servers (boxes 1 18-124 and 142-148). To translate each IP address, the certification server selects a random IP address from a translation table. A translation table is a static (i.e. predefined or pre-generated) table of IP addresses. All clients and all certification servers have identical copies of the translation tables used. This prevents an eavesdropper from directly learning the address of the certification server. As an example, if the IP address of the certification server is 127.255.67.35, the translated address sent to the web servers might be 205.132.34.55.

B. Client A Registration: Figure 3 depicts important steps associated with Client A registration, as follows:

Box 152. Third Server (Certification Server). This is the same certification server as described originally in box 102. This box also indicates that the certification server also contains a database of user certification rights. Box 154. Third (TA) (Certification Backup Server TA). This is the same server as described originally in box 104. This box also indicates that this server is a backup for use in case the certification server (box 102, 126, and 152) fails. Box 156. Third (TB) (Certification Backup Server TB). This is the same server as described originally in box 106. This box also indicates that this server is a backup for use in case the certification server (box 102, 126, and 152) fails.

Boxes 158-174: These boxes are identical to boxes 108-124 and 132-148. The arrows numbered 1-4 drawn between boxes 152-174 depict communication taking place between those parts of the system. In every case, there are multiple copies of each number. The arrows and circles which are solid and bold indicate the primary (initial) transmission. The arrows and circles which are dashed represent backup transmissions, which are exact copies of the primary transmission but sent to a different server if the primary transmission's destination server is down or unreachable.

Client registration takes place according to the following communication steps:

1. The client (in this case Client A) first needs to find the IP address of the Certification server. To do this, it goes to a web server (in this case web server 1) to get the translated IP address. (If the primary transmission fails, a backup request is made to web server 2, then web server 3, and so on, until the client receives the translated IP address. Since all web servers have a copy of the translated IP addresses, any server can answer the query.) The client then looks up the translated IP address in its translation table to find the real IP address of the certification server.

2. The client generates its registration information, which contains the following data:

First Name Last Name Birthdate Zip code Mother's maiden name

Password

Current time (also called a timestamp) The client also generates a unique ID based on the computer's hardware serial numbers.

Note that the password is preferably hieroglyphic. It is generated by clicking on small pictures on the screen, as opposed to typing it in using normal letters and punctuation. To enter the password, the user is presented with a grid of hieroglyphs. The actual position of hieroglyphs may be different each time the password is entered, but by clicking on the same sequence of hieroglyphs, the same password can be entered each time. This prevents malicious programs which can read the keyboard or mouse click locations from being able to determine the password, since these programs will not be able to tell which glyph the user is actually clicking on based on the click location.

After generating this information, the client sends a New User Registration message to the certification server. The new user registration contains the registration information listed above, the client's IP address, client's email address, server email address, and the ID. This message is encrypted using any standard encryption method, such as public-key encryption. The client's email address is stored in both cleartext (unencrypted) and encrypted form for verification.

Upon receiving the New User Registration message, the certification server decrypts it. The server verifies that the client email address which was encrypted (and presumably unmodified by malicious third parties), and matches the e-mail address stored in cleartext. If it matches, the third server then checks the following: a) That the client attempting to register is not on the access denied list. If so, reject the registration. b) If the user is already registered. If so, send back error message 1 , "1) Email already registered". Cancel the registration. c) That the ID is not already registered in another email. If so, send back error message 2, "2) Email already registered". d) Registration is accepted. Generate a registration answer message "3) OK FOR REGISTRATION" with the ID, email address, and timestamp of the client's registration request. e) Store the new user registration data in a user table. f) Encrypt the registration answer message using the same method that was used for the New User Registration message.

2. The Certification server sends the registration answer to the client. The client decrypts the registration answer. 3. After the registration process is complete, the client may receive the advertising from the web server.

4. If registration is OK, the ID and e-mail are stored by the client. If the registration was rejected, the client must restart this process and perform a new registration if it wishes to use the system. C. Client B Registration:

Figure 4 depicts important steps associated with Client B registration as follows:

Boxes 176-198: These boxes are identical to boxes 152-174. Client B registration is performed exactly the same way as client A registration. Phase 2: Encryption

Now making reference to Figure 5, boxes 200-222 are identical to boxes 176- 198 and 152-174. This section describes how a registered client (in this case Client A) can use the system to encrypt a file. This action takes place using five steps. These steps correspond to the numbered arrows drawn in the diagram for boxes 200- 222. As above, the solid circles and arrows represent the primary (initial) transmission, and the dashed circles and arrows represent backup transmissions which are only made if the primary transmission fails for some reason.

1. To encrypt the data, Client A will need to communicate with a certification server. To do this, it needs to look up the server's IP address, just as it did in step 1 of the client registration procedure above. It sends a request to a web server (in this example web server 1), which returns the translated IP address. The client then looks up the translated IP address in its translation table to find the actual IP address of the certification server.

2. The client next sends an "ENCRYPTION REQUEST" message to the certification server. This message contains the following information: client A's e- mail address, the certification server's e-mail address, the IP address of Client A, the e-mail address of Client B, Client A's ID (from Client A's Registration step 2 above), hieroglyphic password, and current timestamp. The message is encrypted as in Client A registration, step 2. As before, Client A's e-mail address is stored in both encrypted and cleartext forms for verification. When the certification server receives the ENCRYPTION REQUEST message, it decrypts it and verifies that client A's encrypted email address matches the cleartext e-mail address. If so, the server performs the following steps: a) It verifies that this client is not on the export denied list. b) It next verifies that Client A's email address is already registered. If it is not, it sends back error message 1 : "1) User not registered." c) It then verifies that the ID and password are valid. If not, it sends back error message 2: "2) Access denied." d) If the message passes all of these tests, it must be a real user who is properly registered. Based on the indicated destination (in this case client B), the certification server selects an appropriate encryption algorithm to use. The certification server then generates an answer, "4) OK FOR ENCRYPTION," which contains client A's ID, email, the timestamp, any additional information needed to perform the encryption, and the web address to use to download the OCX control which contains the encryption code to be used for the file. e) The server stores the data from the answer in a transaction table.

3. The server sends the answer to the client, which then decrypts it. It then accesses the web address given in the message to retrieve the OCX control for the encryption. (This communication is not shown in the diagram.) 4. One of the web servers may send some form of advertising to the client. The encryption code (OCX file) to be used is also included. The client then loads the encryption algorithm into the initially empty gatea.ocx (first described in box 108). Gatea.ocx can now be used to encrypt the file. 5. Client A encrypts the file using the parameters and algorithm received. Once the encryption is done, the encryption algorithm is unloaded from memory and is replaced by the empty gatea.ocx. If a private key is needed for the encryption, client A's ID is used, supplemented as necessary by additional parameters received from the certification server in the OK FOR ENCRYPTION message. Phase 3: Client A sends the encrypted file via e-mail

Now making reference to Figure 6, boxes 224-246 are identical to boxes 102- 124. This section describes how the file which was encrypted in phase 2 can now be transferred to client B. There are two methods that can be used. The file can be sent using normal e-mail (from Client A through boxes 232 and 236 to Client B), or it can be stored on some type of removable media, such as a CD-R or floppy disk (box 234). The removable media is then carried to Client B, which reads the encrypted file from it. Phase 4: Client B Decryption Figure 7 shows how Client B decrypts the file once it has received it. As before, the numbered arrows represent communication. Boxes 248-272. These boxes are identical to boxes 200-222, with the exception that the positions of Client A and client B in the diagram have been reversed. The solid arrows represent the primary (initial) transmission, and the dashed arrows represent backup transmissions which are made if the primary transmission fails.

This procedure is performed in several steps. Client B uses the ID, e-mail, and hardware serial information generated during the registration process (section II) and which was stored in the Windows registry for later use. Once this information is retrieved, client B performs the following communication steps: 1. Client B first needs to look up the IP address of the certification server. As before, client B sends a query to a web server (in this case Webl) to get the certification server's translated IP address. It then looks up the true IP address using the translation table. 2. Client B sends a "DECRYPTION REQUEST" message to the certification server. This message contains Client B's email address, the IP address of client A, Client B's ID, Client A's e-mail address, Client B's hieroglyphic password, and a timestamp. This message is encrypted as before, and Client B's e-mail address is stored in both encrypted and cleartext form for verification by the server. Upon receiving the message, the certification server decrypts it, and verifies that the encrypted and cleartext email addresses are the same. It then performs the following actions: a) It verifies that this client is not on the access denied list. b) It verifies that Client B is already registered. If not it returns error message 1 : "1) User not registered." c) It verifies that the ID, serial numbers, and password are valid. If not, it returns error message 2: "2) Access denied." d) If it passes these checks, it generates an answer, "5) OK FOR DECRYPTION," containing client A's ID, Client B's email address, timestamp, any additional information needed for the decryption, and a web address where client B can download the decryption OCX.. e) The server stores this answer in a transaction table. f) The answer is encrypted. 2. The server sends the answer to Client B, which then decrypts the message. Client B then accesses the web server to download the OCX (this communication is not shown in the diagram).

3. The web server sends an advertising message to Client B, along with the code for the decryption algorithm. Client B loads the decryption code into its initially empty gatea.ocx.

4. Client B now decrypts the file using the specified decryption algorithm. When it is done, it unloads the decryption code in gatea.ocx and replaces it with the empty version of gatea.ocx. Additional Details

This section describes some additional aspects of this invention.

1. The Hieroglyphic password and security:

• Each time the software is executed, the position of the hieroglyphic symbols is preferably changed. The same images are present, however, so the user can reenter an existing password.

• Whenever the software is executed, standard windows cut, paste, and print screen functions are disabled

2. File decryption.

• Once client B has received the decryption algorithm, the certification server sends an e-mail to client A saying that B has decrypted the file.

• The certification server also sends email to B stating that A was informed that it had decrypted the file.

• The certification server sends email to both clients when the encryption transaction expires (i.e. it has been too long since the timestamp.) • The certification server sends email to both clients if someone besides B attempts to decrypt the file (by sending a decryption request to the server).

• The certification server sends email to A if B's access is denied (in phase 4, step 2). • B preferably gets three attempts to send its password. If it does not succeed, appropriate measures can be taken, such as disabling the account for 24 hours. The certification server sends an email to B to inform it when this situation occurs.

3. Additional information about siscom.ocx, siscomp.ocx, gatea.ocx. • Access to these OCX controls are allowed only from within the client software

• There is an acknowledgement protocol which is run between the software and the OCX controls.

• Each time the software accesses an OCX control function, a 288-bit key is generated and the OCX control attempts to validate it. No information is given to the software about whether the key was valid or not.

• If the key was valid, the OCX will execute that function for the software one time. A new key must be used for future executions of that or any other function. If the key was invalid, a false operation will be performed.

4. Additional information about the Certification Servers • There is one master certification server

• Certification servers TA and TB are backups only. There can be an unlimited number of backups.

• The master certification server can be relocated to any geographic location.

• For added security, certification servers can use a dynamic IP address. • A process running in the background on each certification server verifies that that server is valid.

• If an error occurs, one of the backup certification servers takes over for the master certification server. This is accomplished by dynamically re-assigning the IP address to be that of the original master server, or it can require the client to retrieve its email address from the web servers again.

• Java communication software is preferably used to automatically redirect client communication to an available certification server without requiring the client to know the server's IP address. In this way, the certification servers do not need to publish their IP addresses.

5. Additional information on Certification server functionality.

• There can only be one certification database which is shared among the certification servers.

• There can be an unlimited number of backup certification servers, located on either an intranet or the Internet.

• There can be an unlimited number of web sites. I claim:

Claims

1. An algorithm-independent method of sending an encrypted file from a client A for decryption by a client B C through a computer network using certification server, comprising the steps of: sending A an encrypted message from C containing the address of a site on the network having an encryption algorithm to be used by A in encrypting the file; decrypting the message at A, and using the encryption algorithm to encrypt the file and send it to B; sending B an encrypted message from C containing the address of a site on the network having a decryption algorithm to be used by B in decrypting the file; and decrypting the message at B, and using the decryption algorithm to decrypt the file.

2. The method of claim 1, wherein the messages from C are encrypted using public or private key cryptography.

3. The method of claim 1, wherein the encryption and decryption algorithms are contained at different sites on the network.

4. The method of claim 1, further including the step of registering A and B at C prior to sending the encrypted messages.

5. The method of claim 4, wherein the step of registering A and B includes comparing decrypted and cleartext versions of the e-mail addresses of A and

B.

6. The method of claim 4, wherein the step of registering A and B includes the step of providing A and B with the ability to determine the actual address of C from a translated address.

7. The method of claim 6, wherein the address of C is statically or dynamically translated.

8. The method of claim 4, wherein the step of registering A and B includes verifying some or all of the following information at C: user's first name, last name, birthdate, postal or zip code, mother's maiden name, password, current time, and a hardware serial number.

9. The method of claim 7, wherein the password is a hieroglyphic password.

10. The method of claim 1, further including the step of decrypting and responding to an "ENCRYPTION REQUEST" message from A at C prior to sending

A the encrypted message used to locate the file encryption algorithm.

1 1. The method of claim 1, further including the step of decrypting and responding to a "DECRYPTION REQUEST" message from B at C prior to sending B the encrypted message used to locate the file decryption algorithm.

12. The method of claim 1, further including the step of providing one or more back-up certification servers.

13. An algorithm-independent method of sending an encrypted file from a client A for decryption by a client B using certification server C through a computer network, comprising the steps of: registering A and B by decrypting encrypted messages from A and B at C; decrypting an encrypted "ENCRYPTION REQUEST" message from A at C and, in response, decrypting an encrypted "PROCEED WITH ENCRYPTION" message from C at A, wherein the decrypted PROCEED WITH ENCRYPTION message includes the address of a site containing the algorithm to be used in encrypting the file; encrypting the file at A using the algorithm, and sending the encrypted file to B; decrypting an encrypted "DECRYPTION REQUEST" message from B at C and, in response, decrypting an encrypted "PROCEED WITH DECRYPTION" message from C at B, wherein the decrypted PROCEED WITH DECRYPTION message includes the address of a site containing the algorithm to be used in decrypting the file; and decrypting the file at B using the algorithm.

14. The method of claim 13, wherein the messages from C are encrypted using public or private key cryptography.

15. The method of claim 13, wherein the encryption and decryption algorithms are contained at different sites on the network.

16. The method of claim 13, wherein the step of registering A and B includes comparing decrypted and cleartext versions of the e-mail addresses of A and

B.

17. The method of claim 13, wherein the step of registering A and B includes the step of providing A and B with the ability to determine the actual address of C from a translated address.

18. The method of claim 17, wherein the address of C is statically or dynamically translated.

19. The method of claim 13, wherein the step of registering A and B includes verifying some or all of the following information at C: user's first name, last name, birthdate, postal or zip code, mother's maiden name, password, current time, and a hardware serial number.

20. The method of claim 19, wherein the password is a hieroglyphic password.

21. The method of claim 1, further including the step of providing one or more back-up certification servers.

22. An algorithm-independent method of sending an encrypted file from a client A for decryption by a client B using certification server C through a computer network, each client and server having an IP address, the method comprising the steps of: initializing C by translating its actual IP address into a translated IP address, and sending the translated IP address to at least one web server; registering A and B by performing the follow steps: a) accessing the web server and downloading the translated IP address of C to A and B, b) determining the actual IP address of C at A and B from the translated address, c) encrypting registration information at least including the IP address and e-mail address of A and B, and sending a message with the information from A and B to C, d) decrypting the registration information of A and B at C, and comparing the decrypted e-mail address of A and B to their unencrypted or cleartext e-mail addresses, and e) if the decrypted e-mail addresses matches the cleartext versions, storing the registration information of A and B and sending both a decrypted answer; sending an encrypted message from A to B as follows: a) encrypting an "ENCRYPTION REQUEST" message at A using the same process used to encrypt A's registration information, and sending the message from A to C, the ENCRYPTION REQUEST message at least containing A's IP and e-mail addresses, B's e-mail address, C's e-mail address, A's password, and a current timestamp, b) decrypting the ENCRYPTION REQUEST message at C, and verifying that A's encrypted e-mail address matches the cleartext version, c) sending an encrypted "PROCEED WITH ENCRYPTION" message from C to A, the message at least including the address of a site containing the algorithm and parameters to be used for encrypting the file, d) decrypting the "PROCEED WITH ENCRYPTION" message at

A, e) encrypting the file at A using the algorithm and parameters, f) sending the encrypted file to B, and decrypting the message from A at B as follows: a) encrypting an "DECRYPTION REQUEST" message at B using the same process used to encrypt B's registration information, and sending the message from B to C, the DECRYPTION REQUEST message at least containing A's IP and e-mail addresses, B's e-mail address, C's e-mail address, B's password, and a current timestamp, b) decrypting the DECRYPTION REQUEST message at C, and verifying that B's encrypted e-mail address matches the cleartext version, c) sending an encrypted "PROCEED WITH DECRYPTION" message from C to B, the message at least including the address of a site containing the algorithm and parameters to be used to decrypt the file, d) decrypting the "PROCEED WITH DECRYPTION" message at B, and e) decrypting the file at B using the algorithm and parameters.

23. The method of claim 22, wherein the messages from C are encrypted using public or private key cryptography.

24. The method of claim 22, wherein the encryption and decryption algorithms are contained at different sites on the network.

25. The method of claim 22, wherein the step of registering A and B includes verifying some or all of the following additional information at C: user's first name, last name, birthdate, postal or zip code, mother's maiden name, and a hardware serial number.

26. The method of claim 22, wherein the password is a hieroglyphic password.

27. The method of claim 1, further including the step of providing one or more back-up certification servers.