with reference to fig1 - 5 , a process for forming a digital certificate according to a first embodiment of the present invention will be described . a person wishing to obtain a certificate , hereinafter called the registrant , first visits a service provider to obtain a digitized representation of a biological characteristic of his or her body . this digitized characteristic will be referred to as a bio - blob . a bio - blob may be formed from , for example , a digitized image of the registrant &# 39 ; s fingerprint , iris or retina or a digital representation of a marker plate prepared from the registrant &# 39 ; s chromosomal dna . other physical characteristics may be used , depending on the degree of security desired . for example , an image of the registrant &# 39 ; s footprint , handprint , dental x - ray or other distinguishing characteristic of the registrant &# 39 ; s body may be used . the bio - blob may also be a combination of digitized images and other identifying indicia of the registrant and may include , for example , a password such as an alphanumeric string . the service provider may be a medical clinic equipped to handle and analyze biological samples . the service provider gives the registrant the bio - blob in digital form . the bio - blob may be provided on any of a number of digital media including a magnetic tape or disk , an optical disk , or a digital memory . a preferred medium for storing the bio - blob is a non - volatile solid - state memory incorporated in a so - called smart card for convenience and portability . note that in the figures “ cylinders ” illustrate data elements and “ boxes ” illustrate process functions . the data elements may be stored , for example , on magnetic or optical disk drives or in solid state memory devices . the process functions may be implemented by a general - purpose computer , for example , a personal computer , workstation , or mainframe computer , under the control of a software program . the functions described herein may also be performed by special purpose computing devices designed to perform specific data processing tasks , or by a combination of general purpose and special purpose processors . fig1 shows a terminal 1 owned by or associated with the registrant . alternatively , the terminal 1 may be a device owned by a third party which is provided for the registrant &# 39 ; s exclusive use in a manner explained below . the terminal 1 may be , for example , a computer workstation . the terminal 1 is connected with a reader 3 . a data 2 containing the bio - blob 5 produced by the service provider is inserted into the reader 3 and the bio - blob data 5 is transferred to the terminal 1 . the data 2 is preferably a smart card and the reader 3 is preferably a smart card reader , each of which is conventional in design and use . a hash function 7 receives the bio - blob data 5 and calculates a hashed bio - blob 9 . the hashed bio - blob 9 is a fixed length string which is a compressed version of the original bio - blob data 5 . the hash function 7 is selected so that the bio - blob 5 is efficiently converted to the hashed bio - blob 9 , but it is infeasible to generate a bio - blob that hashes to a given value . if the integrity of the hashed bio - blob 9 is violated , because of transmission errors or intentional manipulation , a receiving device can detect the violation using known error detection techniques . a public / private key function 11 calculates a private 13 and public 15 key pair for the registrant . the key pair 13 , 15 is designed to function with a so - called public - key algorithm . messages encrypted with the private key 13 may be decrypted with the public key 15 . however , knowledge of the public key 15 does not allow efficient calculation of the private key 13 . for example , the key pair 13 , 15 may be generated to work in the so - called rsa algorithm . the hashed bio - blob 9 and the private key 13 are received by the signature function 17 . the signature function 17 signs the hashed bio - blob 9 by encrypting it with the private key 13 to generate the signature 19 . the registrant enters identifying information into a registration form 16 . the registration form 16 is an electronic document which queries the registrant for identifying information such as the registrant &# 39 ; s name , social security number , mother &# 39 ; s maiden name , address , and telephone number . the registration form 16 may be a so - called hypertext mark - up language ( html ) page . the public key 15 is combined with the registration form 16 to create a message 18 . the message 18 and the signature 19 are formatted by the browser function 21 for transmission across a communication network 23 via a modem 22 . the modem 22 formats the transmitted signal in a form which is compatible with the communication network . the communication network 23 may be , for example , an intranet , an internet or an extranet . the communication network 23 may be implemented , for example , using a public data network ( pdn ) or a private communication link , such as wide area network , a local area network , or a dedicated telephone line . the communication network 23 allows communication between and among the terminal 1 , a public directory 4 , a certificate authority 25 , a registration manager 43 , and a receiving terminal 83 . the certificate authority 25 includes a registration process 24 and a validation process 26 . fig2 shows the registrant &# 39 ; s terminal 1 connected with the communication network 23 . the message 18 and signature 19 are transmitted from the terminal 1 to the certificate authority 25 . fig3 shows the registration process 24 of the certificate authority 25 in detail . digital signals are received from the communication network 23 by the modem 28 which sends the message 18 and signature 19 to the user input registration process 27 . the user input registration process 27 parses the message 18 and signature 19 from the communication network 23 . the public key 15 , registration form 16 , and signature 19 are stored in the input queue 29 . the decryption process 31 retrieves the signature 19 and public key 15 from the input queue 29 . the decryption process 31 decrypts the signature 19 using the public key 15 to recover the hashed bio - blob 9 . the hashed bio - blob 9 is then de - hashed by the de - hashing function 33 to recover the bio - blob 5 . the bio - blob 5 is stored as a flat file in the bio - blob queue 35 . the compare function 37 retrieves the bio - blob 5 from the bio - blob queue 35 and compares it with bio - blobs stored in the registered bio - blob database 39 . the registered bio - blob database 39 contains bio - blobs from persons who have completed the registration process , as will be described later . because the registrant has not yet completed the registration process , no match will be found by the compare function 37 . the compare function 37 sends a command to the rejection process 41 which sends a message to the terminal 1 via the communication network 23 instructing the registrant to complete the registration process . the bio - blob 5 remains in the bio - blob queue 35 . the registrant goes to a remote registration terminal 43 with the smart card 2 containing the digitized bio - blob 5 and physical identification which confirm the information entered in the registration form 16 . the physical identification may be , for example , the registrants driver &# 39 ; s license , passport , or other government - issued identification card . preferably , the physical identification includes a photograph of the registrant . the remote registration terminal 43 is located at a service provider and the registrant must be physically present to be registered . an operator at the remote registration terminal 43 enters identifying information from the physical identification into a verification form 18 . the verification form 18 may be an html page which queries the operator of the remote registration terminal for the same information requested by the registration form 16 . fig4 shows the remote registration terminal 43 in detail . the bio - blob 5 stored on the smart card 2 is read by a reader 45 and sent to the registration input process 47 . the operator enters information to the verification form 18 using an input device 49 . the input device 49 may be a keyboard or a pointing device coupled to a graphical user interface . the registration input process 47 combines the bio - blob 5 with the verification form 18 to generate a registration request 51 . the registration request 51 is formatted by the communication manager 53 , transmitted by the modem 54 and sent to the registration process 24 of the certificate authority 25 across the communication network 23 . referring again to fig3 modem 28 receives the registration request 51 and sends it to the registration manager input process 55 . the registration request 51 is stored in the registration queue 57 . the registration process 59 retrieves the registration request 51 from the registration queue 57 and extracts the bio - blob 5 . the bio - blob 5 is stored in the registered bio - blob database 39 along with the verification form 18 . the compare function 37 compares each newly registered bio - blob in the registered bio - blob database 39 with the bio - blobs stored in the bio - blob queue 35 . when the registrant &# 39 ; s bio - blob 5 is found in both the bio - blob queue 35 and registered bio - blob database 39 , the compare function 37 sends a message to the certification process 61 indicating that a match has been found . the compare function 37 also compares the registration form 16 with the verification form 18 submitted from the remote registration terminal 43 to verify the identity of the registrant . the certification process 61 is shown in detail in fig5 . when a message is received from the compare function 37 indicating a match between the bio - blob queue 35 and the registered bio - blob database 39 , the registration form 16 , public key 15 , and signature 19 are retrieved from the input queue 29 . a key function 63 generates a certificate signing key 65 and a certificate public key 67 . the certification process 69 encrypts the signature 19 using the certificate authority &# 39 ; s signing key 65 . the encryption process 69 appends certificate authority identity information 70 to the encrypted signature 19 . the identity information 70 may be contained on an html page capable of supporting active links across the communication network 23 . the encrypted signature 19 and identity information 70 form the certificate 71 . the certificate 71 is sent to the registrant &# 39 ; s terminal 1 via the communication network 23 . the certificate 71 is also stored in certificate archive 73 along with the certificate authority &# 39 ; s public key 67 . the certificate 71 is sent to a public directory 4 via the communication network 23 . according to a preferred embodiment , any terminal connected to the communication network 23 may read the public directory 4 . alternatively , access to the directory 4 may be limited to certain authorized persons . the public directory 4 contains all the valid certificates for each registrant on the communication network 23 . the public directory 4 also contains a list of certificates that are no longer valid . parties can compare certificates received with electronic documents against the certificates stored in the public directory 4 via the communication network 23 to determine if a document includes a valid certificate . the identity information 70 in each certificate may include an active link to the public directory 4 allowing a party to access the valid certificates and list of invalid certificates conveniently . there is an advantage in having the digital signature 19 prepared at the registrant &# 39 ; s terminal 1 and then having the registrant register in person at the remote registration terminal 43 using his bio - blob 5 . the registrant maintains control over the key pair 13 , 15 , as well as his bio - blob 5 stored on the smart card 2 , which were used to prepare the signature 19 that forms the basis for the certificate 71 . the registrant cannot later claim that a certificate 71 was prepared without his authorization . if the key pair 13 , 15 or the smart card 2 are disclosed to others , the registrant must inform the public directory 4 to add the certificate 71 to the list of invalid certificates . a new certificate will have to be prepared . if another party receives an electronic document signed using the now invalid certificate , that party will know that the document cannot be relied upon . fig6 , and 8 show an apparatus for sending signed electronic messages via the communication network 23 according to a second embodiment of the present invention . fig6 shows the process of sending a message from the registrant &# 39 ; s terminal 1 using the certificate 71 . a transaction message 75 is formed including , for example , a contract the user wishes to execute with the operator of the receiving terminal 83 . the encryption process 77 joins the transaction message 75 with the certificate 71 and encrypts the result using the registrant &# 39 ; s private key 13 to form the signed message 79 . the signed message 79 is transmitted by the modem 80 and sent via the communication network 23 to a receiving terminal 83 . fig7 shows the authentication of the signed message 79 by the receiving terminal 83 . the signed message 79 is received by the modem 76 and is decrypted by the decryption process 85 using the registrant &# 39 ; s public key 15 thereby recovering the transaction message 75 and the certificate 71 . an authentication process 87 inspects the identity information 70 which is part of the certificate 71 . the authentication process 87 accesses the public directory 4 via the communication network 23 to verify that the certificate 71 is valid . according to a preferred embodiment an active link to the public directory 4 embedded in the identity information 70 simplifies this process . for transactions where there is little risk that a message is fraudulent , simply verifying that the sender has a valid certificate 71 from a reputable certificate authority 25 is sufficient to proceed with the transaction . an additional level of security can be obtained by recovering the bio - blob 5 from the certificate 71 and comparing it with the bio - blob 5 encrypted within the certificate 71 stored in the public directory 4 . fig8 shows a validation process 26 performed by the certificate authority 25 . the certificate authority public key 67 is retrieved from the certificate archive 73 and is used by the decryption process 72 to decrypt the certificate 71 to extract the digital signature 19 . the registrant &# 39 ; s public key 15 is then used by the decryption process 74 to decrypt the signature 19 to extract the hashed bio - blob 9 . the hashed bio - blob 9 is dehashed by the dehash process 76 a to extract the bio - blob 5 . the compare function 37 retrieves the bio - blob 5 that was stored in the registered bio - blob database 39 during the registration process and compares it with the bio - blob 5 extracted from the certificate 71 . the identity of the person sending the message may be positively confirmed by comparing the bio - blob 5 extracted from the certificate 71 to an actual biological feature of the person alleged to have sent the message . for example , if the bio - blob 5 were a digital representation of a dna marker plate prepared from the registrant &# 39 ; s tissue , then a similar marker plate could be prepared from tissue taken from the alleged sender &# 39 ; s body . if the bio - blob 5 matches the alleged sender &# 39 ; s marker plate then it is virtually certain that the sender is the registrant . the digital certificate 71 described above may be used to authenticate electronic document 75 transmitted between remote parties via a communication network 23 . however , the invention is not limited to this type of communication . the digital certificate 71 according to the present invention is applicable to any type of digital message where non - repudiation and positive identification are required . fig9 illustrates a third embodiment of the present invention where the digital certificate 71 , formed according to the first embodiment , is incorporated into a key access card 91 to be used , for example , by an employee to gain access to a restricted area of an employer &# 39 ; s building . the digital certificate 71 is stored in a memory on the card 91 along with conventional identifying information such as the employee &# 39 ; s name 92 . the memory may be a solid - state device , a magnetic strip , a pattern of marks or another known technique for storing digital data . the registrant , for example , an employee seeking access to a restricted area , presents the card 91 to a card reader 93 . the reader 93 retrieves the certificate 71 and name 92 from the card 91 and communicates them to a processor 97 via an internal network 95 . the processor 97 compares the certificate 71 with a database of valid certificates 101 and if a match is found , the employee is allowed access . the employee name 92 and certificate 71 are stored in an access database 99 by the processor 97 . routine reports of access activity can be generated based on the employee name 92 alone . if positive proof that a particular employee entered the restricted area , for example where a crime has been committed , the digital certificate 71 can be retrieved from the access database 99 and the bio - blob 5 encoded therein can be compared with the biological indicia of the employee . the above embodiments are illustrative of the present invention . while these are presently considered the most practical and preferred embodiments , it is to be understood that the invention is not limited by this disclosure . this invention is intended to cover various modifications and equivalent arrangements included within the spirit and scope of the invention , as will be apparent to a person of ordinary skill in the art .