WO2004015918A1 - System and method for signing a document and verifying its authenticity - Google Patents

Abstract

A portable signature device (13) that operates in conjunction with signature application software (14) for signing a document and/or verifying the document’s authenticity. A memory (18, 19) stores a first digital signature of a document signed by the signature application software (14), and a communication module (16) receives data characteristic of a second digital signature of a document from a computer (11). A controller (17) coupled to the communication module (16) and to the memory (18, 19) compares the first digital signature with the second digital signature for verifying that the document corresponding to the second digital signature is authentic. A standalone and networked system for use with the device are also described as well as methods for use thereof.

Description

SYSTEM AND METHOD FOR SIGNING A DOCUMENT AND VERIFYING HIS AUTHENTICITY

FIELD OF THE INVENTION

This invention relates to smart cards for digitally signing transactions.

BACKGROUND OF THE INVENTION

The concept of digital signature is well known but its implementation is far

5 more complicated than using the old ink signature method. The human written signature can be accepted as a proof of authenticity either when accompanied by the physical presence of the concerned parties or when attested to by a lawyer or independent third party, who is present when the document is signed. This situation is completely different in the digital document and global communication age,

10 where concerned parties may never meet and do not have any trust relations. Moreover it is far easier to forge a digital document in such a way that it is impossible to detect. The implementation of digitally signing a document, securing the signatures, validating signed documents and securing the process in such way that its integrity can be controlled and trusted by all parties is difficult enough.

15 Having to perform these tasks over unsecured global networks such as the Internet is challenging and can prove to be a very expensive task. For these reasons the acceptance of digital signature in the market is very slow.

Digital signatures are applied to a document to subject the document to a one-way mathematical function that generates an irreversible hash code that is 0 characteristic of the document. This may then be used to verify the authenticity of - the document, in order to ensure that it has not been altered. This is often required for legal documents in order to establish that a power of attorney or a contract, for example, has not been altered after being signed by the executors. The use of smart cards to digitally sign transactions is well known. For example, US Patent No. 5,748,782 (Ferreira et al.) issued May 5, 1998 and entitled "Device for implementing a message signature system and chip card comprising such a device" describes a first device for implementing an RSA-type protected data exchange system for the signing of messages and the verification of the signed messages, and a second device for inhibiting the encryption anti decryption functions inherent of such systems so as to authorize only the signature and signature functions and public key authentication.

In effect, the smart cards used by known systems apply a function, or signature, to a document so as to generate a unique hash code that is then stored remotely in association with the document, thus allowing a copy of the document to be verified.

Thus, devices of the kind described in US Patent No. 5,748,782 typically operate in conjunction with a central repository. The smart card executes the signature or verification algorithm in respect of a document stored in the repository to which it is coupled. The resulting hash code, characteristic of the document, is then stored in the central repository. If subsequently it is required to determine whether a copy of the document conforms to the original, the copy is conveyed to the central repository, the smart cart is used to execute the signature or verification algorithm in respect of the document copy now stored in the repository and the resulting hash code is compared with the hash code that was generated in respect of the original document and was stored at the central repository. Only if the two hash codes are identical then the copy is a faithful copy of the original document.

Such an approach, using a central repository, is used by companies , which offer a subscription service for performing document signature and verification. Such companies must maintain a large database of original documents or their signatures that are identifiable so as to allow documents that purport to be faithful copies thereof to be compared. Moreover, the documents must be stored securely in a tamper-proof manner, all of which adds to the cost of the service. As a resulting such services are expensive. It would obviously be advantageous to be able to perform document verification without the need for a complicated infrastructure and without the need to access and pay for a remote service.

SUMMARY OF THE INVENTION It is therefore an object of the invention to provide a self contained integrated device for handling all document digital signature operations, such as signing documents, saving documents or their signatures on board and verifying documents' authenticity, all these operations being performed internally by the device in a highly secured manner. The device operates in conjunction with a document for verifying the authenticity of the document, without the need to store an original or master copy or signature remotely.

This object is realized in accordance with a broad aspect of the invention by a portable signature device that operates in conjunction with signature application software for signing a document and/or verifying the document's authenticity, said portable signature device comprising: a memory for storing a first digital signature of a document signed by the signature application software, a communication module for receiving data characteristic of a second digital signature of a document from a computer, and a controller coupled to the communication module and to the memory for comparing the first digital signature with the second digital signature for verifying that the document corresponding to the second digital signature is authentic.

Such a device differs essentially from hitherto-proposed devices in that the document signature code is stored on the device itself and so does not need to be accessed from a remote repository.

According to one embodiment, the signature device is a smart card. In such case, the smart card can be specific to a unique document so that a different smart card must be associated with each document, each smart card, in effect, uniquely identifying the document and storing the signature code characteristic thereof. If it is desired to verify a copy of the document, the correct smart card associated with that document must be used to generate the signature code with the document copy, this signature code then being compared with the signature code stored in the smart card's memory in order to establish whether the copy is faithful to the original. Alternatively, there may be stored in the memory respective identities of more than one document each in association with a respective signature code. In such case, in use the identity of a document copy is read by the smart card so as to determine which signature code in the smart card's memory to compare with the signature code generated by the smart card against the document copy. The smart card may in this manner be used to verify multiple documents. In such case, a suitable file management algorithm must be provided on the smart card so as to allow efficient extraction and comparison of the signature code associated with a document of interest.

The signature device may be used as part of a standalone system or as part of a networked system. The standalone system allows the creator of a document on a local workstation to sign and authenticate the document locally using his or her signature device in association with client software stored on and operated from the workstation. A full-scale network system allows for a multi-user inter-networked configuration comprising one or more authentication clients, each having a respective signature device and one or more servers allowing remote users to sign, save or check digital document signatures. Such remote users typically do not have hands-on access to a signature device but rather access the device indirectly through the network by communicating with one of the authentication clients. A downgraded network system operates in a peer-to-peer configuration where a remote client connects directly to the authentication client with no server in between.

In use, the signature functions and the digital signatures are all performed and saved by the portable signature device. This obviates the need to access a central repository to effect the security functions, thereby significantly reducing the cost and complexity of an overall system. Moreover, the signature device being portable and easy to handle, may easily be connected in networked and inter- networked configurations in a secure and trusted manner, thereby further enhancing system flexibility.

The signature device can be implemented in various forms but preferably complies with the following requirements:

• It is small enough to allow the user to keep it securely in his possession, the same way users deal with the security of their credit cards or Cell-Phones.

• It is equipped with the necessary means to handle and manage the security and integrity of the signature transactions and information. • It has flexible and.reliable communication capabilities.

• Preferably it should not require any additional equipment installation in order to operate.

• Its internal software and data memory is tamper-proof.

• It contains sufficient memory for storage of a bank of digital signatures. The signature device stores a private key that is unique to the specific signature device, and which is not revealed even to its owner and requires that the device itself must be part of the transaction in order to use its private key. This achieves higher security and integrity of the signature process. The device itself is additionally protected with a password or allows use of more secure personal biometric methods to prevent misuse. In serving as a vehicle for signing, verifying and safe signature storage, the device includes fixed and detachable memory banks, which are used for saving and securing the signatures.

Although in use the system around which the signature device is used involves human operators and owners, the algorithms are designed in such a way that any attempt to compromise the system's functions and security even by their owners and in a private environment will be exposed. The device can be used to_. extract a document's hash code or obtain it from an external application, create and save a signature based on the hash code, return a secret "one-time" acknowledge code along with an optional Signature Unique ID (SUTD). Subsequently, the device can be used to check and acknowledge the authenticity of one or more signed documents. The device uses client software that can be a standard Internet interface such as an HTML base web page with a very small footprint Java program, which can communicate with the device thus obviating the need for software installation on the client machine. Java is a registered trademark of Sun Microsystems, Inc. The signature device can be implemented as a dedicated device or it can be embedded into existing devices so as to provide additional functionality. For example, the device can be integrated with a cellular telephone or PDA by adding removable or fixed signature memory banks thereto in combination with the client software. It is also possible to maintain the signature bank and/or secured micro- controller on a separate unit accessible to and updated by the cellular telephone or PDA or similar portable appliances. Likewise, the device can be coupled to such appliances via their respective standard communication ports in order to enhance their functionality without requiring any modifications thereto.

The signature device includes a microcontroller having one or multiple com- munication interfaces, local and optional detachable memory modules, an optional fixed or detachable enhanced security module and an optional onboard LCD display.

The device can receive encrypted or regular messages, process the messages and return secured or regular acknowledge messages. The optional onboard or detachable large memory may be used for local storage of secured or unsecured parameters and information such as document signatures, signature IDs etc.

The communication interface in the device may be adapted for RGB optical input, enabling the device to receive a limited amount of information from any color display system with no additional hardware interface. Such a system and method is described in my co-pending Israeli patent application no. 141441 filed on February 15, 2001 (corresponding to PCT/IL02/00115 filed on February 14, 2002) and entitled "Smart card having an optical communication circuit and a method for use thereo ".

Likewise, there may be employed a visible-light or IR optical communication channel as described in above-referenced PCT/_L02/00115, requiring an optical receiver to be coupled to the workstation. Alternatively, standard serial/parallel ports may be employed, such as ^TSB/RS232/ 7816/Firewire as well as radio-frequency (RF) communications.

The device may be provided with a display device, such as a LCD display, for displaying one or more lines of alphanumeric characters. The display device can be used to show acknowledge security codes for signature authentication or ID.

The device can accept detachable memory units for additional non-volatile storage, as well as for saving digital signatures, and users' reference data. In order to enhance security, the device may be adapted for coupling a detachable (or fixed) module with its independent security controller, which manages all the authentication and encryption functions of the device.

BRIEF DESCRIPTION OF THE DRAWINGS

In order to understand the invention and to see how it may be carried out in practice, a preferred embodiment will now be described, by way of non-limiting example only, with reference to the accompanying drawings, in which:

Fig. 1 is a block diagram showing functionally a standalone system adapted for personal use of an owner of a signature device according to a first embodiment of the invention;

Figs. 2a, 2b, 2c, 2d and 2e are flow diagrams showing operational steps of the system of Fig. 1 for local generation of a document's digital signature;

Figs. 3a, 3b, 3c and 3d are flow diagrams showing operational steps of the system of Fig. 1 for local verification of a signed document's authenticity;

Fig. 4 is a block diagram showing functionally a network system for use with the signature device shown in Fig. 1 according to a second embodiment of the invention;

Figs. 5a, 5b, 5c, 5d and 5e are flow diagrams showing operational steps of the system of Fig.4 for remote generation of a document's digital signature; and

Figs. 6a, 6b and 6c are flow diagrams showing operational steps of the system of Fig. 4 for remote verification of a signed document's authenticity. DETAILED DESCRIPTION OF SPECIFIC EMBODIMENTS

Fig. 1 shows functionally a system depicted generally as 10 comprising a local workstation 11 on which there is loaded a third party software application 12 for creating a document file whose data may be authenticated using a signature device 13 according to the invention. The signature device 13 operates in conjunction with signature application software 14 loaded on the workstation 11 and is coupled to the workstation via corresponding communication modules 15 and 16 in the signature device 13 and the workstation 11, respectively. The signature device 13, which may be a smart card, includes an on-board micro- controller 17 having an internal memory 18 and operating in conjunction with a memory module 19 that is external thereto. Optionally, there may also be provided a display module 20 for displaying data stored in the memory module 19.

The signature device 13 is a self-contained personal digital signature tool that enables a user 21 of the workstation 11 to perform the following three functions:

• Sign a digital document.

• Verify/authenticate previously signed document.

• Manage a library of digital signatures.

Signing a document: With reference to Figs. 2a, 2b, 2c, 2d and 2e, there will now be explained the manner in which the system 10 is used for local generation of a document's digital signature.

In order to sign a document the user 21 activates the signature application software 14 at the workstation 11. This can be done from within the third party software application 12, for example using ActiveX controls, in which case the currently active document is automatically selected. Alternatively, the signature application software 14 prompts the user to select a document to be signed. The application software 14 processes the document and produces its hash code (constituting a first digital signature), which it then transmits (optionally with signature identification) to the signature device 13. When this process is successfully completed, the signature device 13 returns to the workstation 11 an acknowledge message optionally including additional signature ID information.

The application software 14 may optionally maintain a signature reference database 22 to allow the user 21 an easy way to relate signed documents to their signatures. This allows the signature device 13 to store multiple digital signatures each in respect of a different document and to authenticate a specific one of these documents when required. In order to do this, it must of course be able to identify the document and extract the respective digital signatures from memory. The external database 22 serves to identify a document and inform the signature device either of its digital signature (if stored external to the signature device 13); or to provide an index to the signature device 13 so as to enable it to access the correct digital signature from its internal memory 19.

This is not necessary if the signature device 13 is customized for a single document only. In such case, the signature device 13 is clearly less versatile but does not require the additional overhead of document signature management. In fact, such overhead may also be dispensed with even in the case that the signature device is adapted for use with multiple documents: but this requires a kind of "trial and error" process when authenticating documents as is explained below and can be time-consuming.

Document authentication:

With reference to Figs. 3a, 3b, 3c and 3d, there will now be explained the manner in which the system 10 is used for local verification of a signed document's authenticity. A signed document can be authenticated using two different methods. According to the first method the user may follow the operations: a. Activate the authentication application software, and select the document to be verified. b. The application software calculates the signature code of the document. This code constitutes a second digital signature, which may be compared to the first signature in order to verify the document's authenticity. c. The second digital signature is transferred to the signature device 13. d. The second digital signature is compared with all current signatures stored in the signature device. If a match is found, then the signature device 13 returns an approval message otherwise it returns a rejection message.

The drawbacks of this method are that the process can be slow if the signatures are saved encrypted, and each stored signature has to be extracted and decrypted in order to compare it with a given hash code. A reverse approach can be followed, in which the second signature is encrypted using the same encryption algorithm and the same encryption key used for the first signature stored in the signature device. The second (encrypted) signature may then be compared with the stored encrypted codes thereby obviating the need to decrypt each code. Moreover, since the document identity is not indexed, if the user has more than one signature device or more man one memory module 19, failure to match with any one device will require the user to repeat the whole procedure in respect of successive devices or memory modules until a match is found or they are all exhausted. According to the second method the user executes the following operations: a. Activate the authentication client software in database mode. b. Select from the database 22 the signed document to be verified. c. The application software 14 extracts from the database an index to the document location (or the document itself) and its signature ID including the ID of the signature device 13 and memory module 19 used to save the signature. d. The application software 14 recalculates the hash code of the document. This hash code constitutes a second signature, which may be compared to the first signature in order to verify the document's authenticity. e. The application software 14 transmits the second signature and the selected signature ID to the signature device 13. f. The signature device 13 tests the second signature against the saved signature of the indexed document and displays the approval or rejection message as appropriate.

If document approval is needed for a third party, the networked signature management version must be used as described below with reference to Figs. 4 to 6 of the drawings.

Bulk document verification: If the user needs to verify authenticity of bulk of documents he could repeat the authentication operation for each document one at a time. Possible drawbacks of this process are the need to transmit the hash code of each document, which may not be acceptable for the user in case of large number of documents, and a slow communication channel such as an optical RGB communication channel. This process can be rendered faster by sending the hash codes as a single composite code.

By way of example, the user produces the hash code for each of the documents to be verified. The resulting hash codes are appended to each other in known order to produce a new document, constituting a hash-document, containing for each document the respective hash code, constituting a component hash-code. The hash code of the hash-document is calculated and constitutes a composite hash code that is transmitted along with the ordered list of documents to be checked to the signature device. The signature device extracts the component hash codes of all the documents in the list, appends them in the list order so as to produce the new hash-document and calculates its hash code to be compared to the received composite hash code. If the composite hash codes of the "hash-documents" are identical, this means that all the component hash codes from which it derives are also identical. If the composite hash codes are not identical and the user wishes to identify the inauthentic document(s), the process must be successively repeated in respect of fewer documents so as to reveal the inauthentic document(s). By way of simple example, a binary search can be implemented- whereby the process is repeated with only half of the documents. If the composite hash codes match, then it is clear that the inauthentic documents) must reside in the second half of as yet unprocessed documents. By such means, the "faulty" remaining half of the processed document set is successively checked until an inauthentic document is revealed. This is then eliminated and the whole process repeated in order to reveal other inauthentic documents.

Management of document signatures: Document signatures are managed at two levels. The first level is on the signature device controller's memory 18. Each new generated signature is saved on the internal memory module 18 or the detachable module 19, both of which are nonvolatile. The signature is saved along with a unique signature ID, which may later be referenced to identify a specific signature. The full signature ID includes the ID of the memory module 19 and internal module index. The module can produce each index just once and never use it again even if the signature is deleted and the ID is not used any more. This ensures that a unique ID is generated for each signature. The second level is the optional signature ID database 22 managed by the application software 14 to let the user correlate a specific document to its signature. The signature device 13 can be used in a networked configuration allowing the following operations:

• Remotely sign a digital document by one or more non-trusting parties.

• Remotely verify a signed document.

• Manage a library of digital signatures. • Enable the signature and verification process without having to reveal the document content to the holder of the signature device.

Fig. 4 is a block diagram showing functionally a network system designated generally as 30 for use with the signature device 13 shown in Fig. 1 according to a second embodiment of the invention. Identical reference numerals are used to refer to those components that are common to both the standalone system 10 shown in Fig. 1 and the network system 30 shown in Fig.4.

The network system 30 enables the use of the self-contained and highly secure signature device 13 in a networked environment. The system 30 employs algorithms that cooperate with one or more signature devices 11 to make sure that non-trusting parties can work together and perform the complicated functions of remotely signing and verifying digital documents. Such document signature and verification is also facilitated in respect of remote client(s) who may or may not have access to a signature device. Thus, referring to Fig. 4, the network system 30 comprises a server 31 comprising a manager module 32, a document signature database 33 for maintaining a record of document signatures pertaining to identified documents and a client database 34 for maintaining a record of clients. A communications module 35 allows for communication between the server 31 and an authentication client 40 and, via a data communications network 41, such as the Internet, to a remote client 42. The authentication client 40 is constituted by a user 43 operating an authentication workstation 44 to communicate with a signature device 13 as described above with reference to Fig. 1 of the drawings. To this end, the authentication workstation 44 includes a communication module 45 for coupling to the communication module 16 of the signature device 13. The authentication workstation 44 may further include one or more software servers 46. The system 30 may also include an external/trusted certificate authority (not shown) for authentication of remote-clients and the signature device and its server.

In a minimum configuration, especially when there is only one authenti- cation client 40, the server 31 and the authentication client 40 may be integrated to form a single unit. The remote client 42 is the party that initiates document signature or verification operations.

The remote client 42 is constituted by a user 47 operating a remote workstation 48 provided with signature client application software 14 and having a communications module 50 for communicating with the signature device 13 of the authentication client 40. The remote client 42 is further provided with a third party software application 12, such as word-processing or spreadsheet software, for generating the document to be signed.

In order to sign the document and allow for the signature to be maintained in the signature device 13, the essential operations carried out by the remote client 42 are as follows. The remote client 42 signs the document using the signature client software 14, this being one of several well-known public algorithms producing the signature, such as a hash code produced by SHA-1 or MDD5 to name two well known algorithms, and transfers the signature to a designated signature device 13 via the communication network. The designated signature device 13 may be located at a specific authenticating client having a need to authenticate the document. For example, the document could be a power of attorney that is signed by a patentee to give his attorney the right of representation before the patent office. In such case, the signature device 13 might be located at the office of the attorney, allowing the patent office to verify that the signed power of attorney is authentic. The patentee and the patent office would then constitute remote client, both of which access the attorney to sign and/or authenticate the document. The attorney would then constitute the authenticating client. However, it is clear that the patent office could also serve as the authenticating client either in addition to or instead of the attorney. In either case, from the perspective of the patentee, he or she must know to which destination to convey the signature and the identity of the document in question. In practice, this is something which is fairly transparent to the remote client since document management is controlled by the server 31.

Thus, the server 31 stores an identity of the document in the document signature database 33 for mamtaining a record of document signatures pertaining to identified documents. In respect of each document, the server 31 stores the identity of a corresponding client in the client database 34 so as to cross-refer each document with the appropriate authentication client 40 to which the signature must be conveyed for authentication. The authentication client 40 receives the signature and stores it in an identified signature device 13, the identification also being associated with the document by the server 31 in the document signature database 33. This allows the signature client 40 to maintain several signature devices 13 and to know exactly which one to use to authenticate any given document. As explained above, it is not necessary if the signature client 40 has only a single signature device. In fact, as also explained above, it is not even strictly necessary when the signature client 40 maintain multiple signature devices, but obviates the need to attempt to authenticate a specified document by repeated trial and error matching of a target signature with the signatures stored in multiple signature devices. Regardless of the specific mechanism that is employed, the appropriate signature client obtains the signature of an identified or identifiable document from the remote client 42 and stores the signature and, if required, a code identifying the document. It then generates an acknowledge message to be returned to the remote client 42.

The above mechanism, as described, is sufficient where the remote client 42 and the signature client 40 trust one another. This might be the case where they can communicate only over an Intranet or protected line. However, when the remote client 42 and the signature client 40 do not have a relation of mutual trust, the remote client 42 must identify himself to the signature client 40. In practice, where communication between the two is mediated by the server 31, this requires that the remote client 42 have a digital certificate and a public key published by a certificate authority, such as Verisign, Inc. or be known in advance to the server 31. It also requires that the public key of the signature device be published with a certificate or conveyed in other trusted manner to the remote client(s).

In such case, the data sent to the server 31 is encrypted using the remote client's private key and is then decrypted by the server 31 using the remote client's public key. Likewise, data forwarded by the server 31 to the signature client 40 may be encrypted using the server's private key and then decrypted by the signature client 40 using the server's public key. Any data sent from the remote client to the signature device is encrypted using the remote client private key and the signature device's public key. A variation of this mechanism is to convey all data between the server 31 and the signature client 40 using secure socket layer (SSL).

In the case of document signing operations, the signature client 40 may also return information back to the server 31 and/or to the remote client 42 to construct a document signature reference entry in the document signature database 33 on the server 31 and/or reference on the remote client 42. This database is used to correlate the identity of signed documents to the documents' respective unique signature ID. As noted above, a document can be verified without its signature ID being known to the signature device 13 simply by searching for a match over all the signatures on the signature device 13. However, knowing the document's unique signature ID can dramatically reduce the authentication time since only a single entry in the document signature database of the signature device 13 need be compared with the signature code generated by the remote client 42.

The document signature database 33 does not hold any secret information but since it may serve to associate a document with its signature entry on the signature device 13, the database integrity is important and it must be kept secured against unauthorized modifications. The networked signature device 13 must be highly secure since it must be assumed that parties involved in the process of document signature and verification are not trusted by each other. The hardware and software elements co-operating in the process must make sure that any attempt by one or more parties to modify or interfere with the process will be detected and invalidate the process.

Security levels and configuration options:

To this end, the signature device 13 can have different configurations each having a respective security level, memory capacity and communication channels. Some of these will now be described.

• Read protected non-secured micro-controller: Minimal security is achieved by using the controller 17 of the signature device 13 as the only security element relying on its "Read Out Protection" capabilities and performing basic symmetric key encryption on its external memory modules.

• Detachable (or fixed) security controller: Security functions and/or system management functions are performed by an auxiliary security controller which holds all symmetric keys as well as the signature device's private key.

. • Secured signature memory: The signature device 13 can be provided with on-board flash memory to securely save signature information. This portion of the signature database will be the most secure since it is protected as part of the controller itself. • A detachable non-secured encrypted signature memory module: Signature information written by the controller 17 to the module is encrypted by the device's symmetric key securely saved on the controller itself. The module can be copied for backup purposes but cannot be read or written to, without the controller 17 of the signature device 13 which records the symmetric key used for the encryption.

• A detachable non-secured protected signature memory module: Signature information written by the controller 17 to the module is encrypted with the controller's private key. Only the controller 17 in the signature device 13 has access to its own private key so no one else can write valid signatures to the module. The module can be copied for backup purposes and can also be decrypted for signature verification by any other signature device having access to the public key of the controller 17.

Memory capacity configuration options:

The type of memory used to stored signatures clearly impacts on the number of signatures that may be authenticated by a signature device. Different memory types offer a range of capacities, as will now be discussed.

• On board non volatile memory bank: The controller 17 in the signature device 13 is provided with on board non-volatile programmable memory, part of which can be used for a limited number of signature banks storing signature codes representing digital signatures of signed documents.

• Security controller memory bank: When the configuration includes a security controller, the controller 17 may have on board non-volatile memory, part of which can be used for signature memory bank.

• Detachable non-volatile memory module: A detachable memory module that can be used as signature memory bank.

Signature memory modules protection and management:

The following considerations impact on the overall security of the signature and authentication methods. Maximum security allows remote, mutually untrusting clients to sign and authenticate documents over a public network, such as the

Internet, with an equivalent level of security as currently provided by signature authorities such as VeriSign, Inc. but without the overhead.

• The signature memory banks can reside on the onboard controller non- volatile memory pool or on external detachable (or fixed) memory modules.

In case of such external modules, care must be taken to enable the detection of any attempt to tamper with, modify or replace the original information with illegal information, which would enable the production of fraudulent authentications. • Every memory module for use with a signature device is signed by the manufacturer of the memory module with a Memory Unique ID (MUID) code encrypted by the manufacturer using its private key in the production process. A memory module not having the MUID will not be accessed by the signature device. • Memory modules can be read and written to by other third party equipment and applications since they have a standard interface such as I²C or other standard and protocol. The memory modules with their MUIDs can be copied, thereby generating multiple copies of any module. • A writing operation to a specific memory module by a signature device is limited to a specific signature device only since the signature data and ID written to the memory module are either encrypted with the symmetric key of the specific signature device (in case of an encrypted detachable module) or are encrypted with the private key of the specific signature device (in case of a protected detachable module).

• Reading operation is enabled for all signature devices.

• In order to manage possible multiple copies of the same memory module only one module (the last one written to, or its identical copies) can be written to. All other non-identical copies (previous versions, not updated copies) can only be read but not written to by the signature device. The copied memory modules can be used to authenticate a document positively but cannot invalidate a document since it is not updated.

• In order to be able to distinguish a previous version of a copied module from the original updated module, the signature device manages a library of its modules saved on its internal secured memory bank. For each module it may save the last time it was written, the number of entries, the number of deleted entries etc. If the connected memory module (which also has this information encrypted on it) does not match the updated recorded state it is assumed to be a copy.

Communication channels:

Communication between the signature device 13 and the workstation 46 of the signature client 40 may be effected in different ways. Some of these will now be discussed briefly. • RGB optical communication channel: This mechanism is described in detail in above-referenced co-pending PCT application no. PCT/IL02/00115. For personal or low volume use of the device, the RGB/LCD communication channel has the major benefit of not requiring any special hardware interface on the client workstation, and can operate securely on any PC system. Drawbacks of this communication channel are its limited communication speed and the fact that manual feedback by the operator is required. • USB communication channel: For high volume and automatic operations the signature device 13 may be connected to the client PC system by a USB 5 communication channel. Drawbacks of this configuration are the security breach in allowing the user to leave the signature device 13 connected to the USB port, the inconvenience of the location of USB port, and potential problems with the mechanical reliability of the USB connector in repeatedly connecting and removing the signature device. 10 Having described the network system 30, the manner in which a document is signed therewith will now be described with reference to Figs. 5a to 5e of the drawings.

Thus, by way of introduction, it is assumed that one or more parties wish to digitally sign a document, these parties being the remote clients 42 of the system

15 30. Each such remote client 42 has a copy of the document in digital form. It can be assumed that each remote client 42 received an identical copy although there can be no guarantee that any of the parties will not try to modify the document before signing it. For maximum security, as explained above, each remote client 42 must have a digital certificate issued by a recognized certificate authority or by the server

20 31 in case the server is trusted by all participating parties, each such certificate containing the public key of the respective remote client 42. It is assumed that at the time the transaction takes place the private key of each of the remote clients 42 is secure and uncompromised. In addition, each of the remote clients receives or is in possession of the ordered list of parties to sign the document.

25 The following description describes the most general mechanism where two mutually remote clients, referred to as Client A and Client B, need to sign a. document, via a mutually independent signature client. Thus, it is assumed that both

Clients A and B are in possession of what purport to be faithful copies of the same document and the document bearing both clients' signatures, or a corresponding

30 hash code, is to be stored in the signature device for subsequent authentication. In this description, for the sake of brevity, no distinction is made between the client and the user. Thus, whilst strictly the client is a workstation that is programmed to carry out specific tasks in response to a user input, it is clear that some operations are performed by the workstation, while others may be performed independently by the user.

1. Client A signs the document: a. This produces a hash code of a copy of the document using a mutually agreed hash gorithm. The resulting hash code will be referred to as hash-A. b. Optionally client A appends a "signing parties list", an ordered list of parties expected to sign the document. During the process each party extracts the list and verifies it against his list of parties. The signature device will accept the signature only if all parties on the list signed the document in the given order. c. Client A generates a one time acknowledge code that is to be appended to the hash code and returned by the signature device upon a successful operation. d. Prior to appending to the hash code, the acknowledge code is encrypted using the public key of the target signature device so that no one but the signature device itself can discover the required acknowledge code for confirming successful operation by the signature device to Client A. e. Hash-A and the now appended encrypted acknowledge code are encrypted using Client A's private key so as to prove Client A's authenticity as the sender and prevent anybody modifying the message or reproducing a fake message. This also assures that Client A will not be able later to deny his authorship of the document. The encrypted message forms a first level encrypted composite signature that will be referred to as Sign-A.

2. Client A sends the first level encrypted composite signature, Sign-A, to Client B. 3. Client B receives the first level encrypted composite signature from Client A and verifies it as follows: a. Client B uses the same hash algorithm as Client A to produce a hash code of the original document copy in his possession. This hash code will be referred to as hash-B. b. Client B then uses Client A's public key to decrypt the first level composite encrypted signature, Sign-A, and to extract Client A's hash code, "hash-A", and the "signing parties list" when included. c. Client B compares hash-A to hash-B. If they are identical, Client B is assured that both parties signed the same document and no party will be able subsequently to deny it after the transaction is acknowledged. d. If applicable, client B also checks the "signing parties list" to make sure it corresponds to his list.

4. Client B signs Client A's signed message Sign-A: a. Client B takes the first level composite encrypted signature, Sign-A, which nobody but client A could produce, b. He appends his own acknowledge code encrypted with the public key of the target signature device thus foπning a second level composite encrypted signature. c. He encrypts the whole message again using his private key, producing an encrypted second level composite encrypted signature referred to as Sign-AB, in order to assure that no-one can reproduce or modify the message and as a proof that he was the one produced it. d. The encrypted second level composite encrypted signature may, if necessary, be sent to successive co-authors for verification and signature in a similar manner until it reaches the last co-author. By such means, first, second and possibly successive levels of composite encrypted signatures are produced. e. Client-B as the last "Remote Client" signing party, further encrypts the encrypted second level composite encrypted signature Sign-AB with the signature device's public key producing an encrypted final level encrypted composite encrypted signature referred to as Sign-AB-O, in order to assure that only the signature device itself will be able to extract the information, produce the document signature out of the hash code and extract the acknowledge messages for Clients A and B.

5. Client B is the last of the Remote Clients, and sends the encrypted final level encrypted composite encrypted signature Sign-AB-O to the server.

6. The server sends the encrypted final level encrypted composite encrypted signature Sign-AB-O to the appropriate signature client for processing along with the Remote-Clients' public keys (if they are not already in the possession of the signature device) and waits for the results.

7. The signature client transfers the encrypted final level encrypted composite encrypted signature Sign-AB-O to the signature device. The signature device is the only entity that can decrypt and extract the data in the encrypted final level encrypted composite encrypted signature Sign-AB-O since it is the only one in the possession of the required private key.

8. The signature device decrypts the encrypted final level encrypted composite encrypted signature Sign-AB-O message, using its own secret private key and extracts the encrypted second level composite encrypted signature Sign- AB message.

9. The signature device uses the public key of remote Client B to decrypt the encrypted second level composite encrypted signature Sign-AB and extracts the first level composite encrypted signature Sign-A with the appended acknowledge code for Remote Client B. This code is decrypted again using the signature device's private key, thus preventing another user from extracting the code. The signature device now returns the valid acknowledge to Client B.

10. The signature device may check that the "signing parties list" matches the actual signing parties. 11. In the general case, where the document co-authored by multiple authors, me signature device uses the public key of each author in turn to decrypt the message thus extracting the acknowledge code for each author and the preceding level composite encrypted signature of all preceding co-authors.

5 The whole process is then repeated until the first level composite encrypted signature is reached.

12. The signature device likewise decrypts the first level composite encrypted signature Sign-A message using Client A's public key to extract hash-A and the appended encrypted acknowledge message.

10 13. The signature device decrypts the acknowledge code using its private key, the signature device being the only one who can extract the acknowledge code from the message. 14. The signature device is now in the possession of the document hash-A code and the two respective acknowledge codes of Remote Clients A and B. 15 15. The signature device prepares the hash-A message, which serves as the document signature for saving on its signature device memory banks: a. In case of the onboard controller internal secured bank, the signature is saved "as is" with no encryption. b. If the memory bank is a detachable module, the signature device can 20 save it either secured or protected. i. In protected mode the signature device protects the signature against modification by encrypting it using its own private key. ii. In secured mode the signature device encrypts the signature using a symmetric key saved in its internal memory. So no one but the 25 signature device itself can use the signature.

16. Together with the signature the signature device produces the memory bank portion of the signature unique ID (SUID) and saves it in the memory bank's signature database structure along with the signature itself. It may save additional parameters such as the "signing parties list", signing date and time

30 etc. 17. The document is signed and the signature device returns an acknowledge message to the signing parties, as follows. a. For each of the Remote Clients the signature device encrypts the acknowledge code using its own private key in order to make sure that no one else can return a fake answer or modify its answer. b. The resulting data is encrypted with the Remote Client's public key to make sure that only the respective Remote Client will be able to decrypt the message.

18. The signature device returns the acknowledge messages via the signature client to the server, which forwards them to the Remote Clients, or in a peer to peer configuration the signature client forward the acknowledge directly to the remote clients

19. When a Remote Client receives the message he can be sure that his original signature reached the signature device untouched, and only the signature device itself could decrypt it and produce the signature and the acknowledge message.

20. In addition the signature device can return the SUED code of the signature so the server can create a signature reference database,_, which can manage multiple signature clients each having multiple signature devices and multiple memory modules per device. Moreover the server can manage the user certificates and signature certificates. In particular, it can record which users public keys are already saved on the signature device and save the time of re-transmitting them.

The above algorithm can work also in a peer to peer configuration instead of client server, in such case the signature server functions are embedded in the signature client. The Remote Clients communicate directly with the signature client.

With reference to Figs. 6a to 6c, there will now be described a mechanism employed by the network system 30 for authenticating a previously signed document that has been signed by one or multiple remote clients. In the following description, the term "verifying client" refers to a remote client who is in possession of a digital document, which he wishes to authenticate. The Verifying Client must also know with which Server (or signature client in a peer to peer configuration) to check the document and preferably has the ability to identify the document to the signature device (usually via its Signature Unique ID (SUID) code, or any other information accepted by the signature device). As explained above, the document can also be authenticated without any ID information but this is a lengthy operation involving testing of the document against all existing signatures on the relevant signature device. The Verifying Client must also be in possession of a digital certificate with a public key in order to enable secured communication with the Server 31.

Verification is done as follows:

The Verifying Client signs his copy of the document as follows: a. He produces the hash code of his copy of the document to be authenticated. This hash code will be referred to as hash-A. b. He appends to hash-A a one time acknowledge code, which will be called ACK-A, to be returned to him as a proof of document authenticity. The resulting message constitutes a composite signature. c. He encrypts the composite signature using his own private key, producing an encrypted composite signature, in order to make sure that no one else can modify or reproduce his message. d. He then encrypts the encrypted composite signature using the signature device's public key, producing a doubly encrypted composite signature, in order to make sure that only the signature device itself is capable of extracting the information from the doubly encrypted composite signature. 1. The Verifying Client sends the doubly encrypted composite signature to the Server 31 along with its document signature identification information such as SUID. 2. The server sends the document authentication request (including the doubly encrypted composite signature and the SUID) to the relevant signature Client. The signature Client activates the signature device and transfers to it the received information. During the whole process no one could modify or replace the information sent by the Verifying Client, thus guaranteeing the integrity of the information to the Verifying Client and to the signature device.

3. The signature device decrypts the doubly encrypted composite signature using its own private key to extract the encrypted composite signature. No one else could decrypt the message and extract the acknowledge code ACK-

A apart the signature device itself.

4. The signature device decrypts the encrypted composite signature to produce the composite signature using the Verifying Client's public key, thus assuring that no one but the Verifying Client could produce the message. It extracts from the composite signature the hash-A and ACK-A codes.

5. The signature device compares the input hash-A code to the original signed document hash code saved according to the SUID identification code. If the two hash codes match, then the document is authentic and the signature device returns to the Verifying Client its ACK-A code. a. It first encrypts the ACK-A code using the signature device's private key, in order to assure the Verifying Client that the message originated from signature device. b. It then encrypts the resulting code with the Verifying Client's public key, thus making sure that only the Verifying Client can decrypt the message. It returns the encrypted code to the Verifying Client.

In both embodiments so far described, the document signature is generated by software that is separate to the signature device and is then communicated to the signature device for storage thereby and subsequent comparison with a hash code purporting to be that of a faithful copy of the document. However, it will be understood that the hash code, constituting the document signature, can be generated also by the signature device, providing that suitable software is stored therein. While to do so obviates the need to provide the signature application software on a host device, this is at the price of requiring sufficient memory in the signature device to store the complete document, at least temporarily for the purpose of generating the signature. Moreover, this requires that a complete copy of at least the original document be conveyed in computer legible form to the signature device. Alternatively the device may employ a hashing algorithm which can operate on-the-fly on a limited window of the input stream of data thus eliminating the need for large amount of on-board memory. There may be occasions when, owing to considerations of privacy, this is undesirable. For the sake of completeness, it should be noted that even in the case that hash codes can be generated by application software stored in the signature device, this still does not preclude the possibility of receiving hash codes of copies of a document from remote sources. In other words, an original document can be signed by the signature device using its own internal application software, whilst verification may be performed either by signing a document copy remotely and sending the hash code to the signature device; or by sending the document copy to the signature device for generating the hash code and comparing with that of the original document.

It will be appreciated that while in the preferred embodiments the digital signature is a hash code, any other suitable digital signature is equally suitable.

It should also be noted that the terms "original" and "copy" as used in the appended claims are used for clarity and ease of understanding. Thus, there may be occasions when it is necessary to authenticate an "original" document, being not merely a faithful copy of one that has previously been signed but, in fact, the ver same document. However, if this document is now conveyed to the signature device for generation of the hash code thereby, then clearly the signature device receives what amounts to a copy of the original. This is perhaps less overt when the hash code is generated remotely and only the hash code is conveyed to the signature device, since indeed the document can be the same. But even in such case, there is no way to distinguish between the raw data of an original document and a faithful copy thereof in that the data constituting both documents is identical; and if there is no question that the data corresponding to a document is, in fact, the original data then there is hardly any need to verify that its signature is authentic. Thus, in the context of the invention and the appended claims, the term "original" is used to refer to that document whose hash code is stored in the memory of the signature device for comparison with a copy of the hash code.

It will also be understood that the remote clients and the signature client according to the invention may be suitably programmed computers. Likewise, the invention contemplates a computer program being readable by a computer for executing the method of the invention by the remote clients and signature client. The invention further contemplates a machine-readable memory tangibly embodying a program of instructions executable by the machine for executing the method of the invention.

In the method claims that follow, alphabetic characters and Roman numerals used to designate claim operations are provided for convenience only and do not imply any particular order of perfoπning the operations.

Claims

CLAIMS:

1. A portable signature device (13) that operates in conjunction with signature application software (14) for signing a document and/or verifying the document's authenticity, said portable signature device comprising: a memory (18, 19) for storing a first digital signature of a document signed by the signature application software (14), a communication module (16) for receiving data characteristic of a second digital signature of a document from a computer (11), and a controller (17) coupled to the communication module (16) and to the memory (18, 19) for comparing the first digital signature with the second digital signature for verifying that the document corresponding to the second digital signature is authentic.

2. The portable signature device according to Claim 1, wherein: the signature application software (14) is stored in association with the computer (11), and the communication module (16) communicates with the computer (11) for receiving therefrom the first and second digital signatures.

3. The portable signature device according to Claim 1, wherein the signature application software (14) is stored in association with the portable signature device and the communication module (16) communicates with the computer for receiving at least an original document therefrom for generating the first digital signature.

4. The portable signature device according to any one of Claims 1 to 3, wherein the memory (18, 19) stores respective identities of more than one document each in association with a respective first digital signature.

5. The portable signature device (13) according to any one of Claims 1 to 4, being a smart card.

6. The portable signature device (13) according to any one of Claims 1 to 4, being a mobile telephone.

7. The portable signature device (13) according to Claims 1 to 4, being a PDA.

8. The portable signature device (13) according to any one of Claims 1 to 7, wherein said memory (19) is detachable.

9. The portable signature device (13) according to any one of Claims 1 to 7, wherein said memory (19) is detached from the signature device.

10. The portable signature device (13) according to Claim 8 or 9, wherein the memory (18) is a secured memory bank internal to the device and there is stored in the memory (18) a library identifying modules that have been used with the device for maintaining document signatures, said library containing information allowing the signature device to determine whether a connected memory module is an original or a copy.

11. A computer (11) for operating in conjunction with a portable signature device (13) for signing and/or verifying the authenticity of a document, said computer comprising: a signature application (14) for generating a digital signature of the document, a communication module (15) coupled to the signature application (14) for communicating with a communication module (16) of the portable signature device (13) so as to convey the digital signature to the portable signature device for storage or verification, thus obviating storage of the digital signature by the computer.

12. The computer according to Claim 11, wherein the portable signature device (13) is intended for use in signing and/or verifying multiple documents each having a respective identity and the communication module (15) is adapted to convey an identity of the document to the portable device for storage thereby in association with the digital signature.

13. The computer (11) according to Claim 11 or 12, wherein there is stored in the memory or on external security device such as smart card a characteristic PKI private key and the signature application (14) is responsive to the private key for encrypting the signature prior to conveying to the portable signature device (13).

14. A computer system (30) for signing and/or verifying the authenticity of a document, said computer system (30) comprising one or more remote client computers (42) coupled via a server (31) to a signature client computer (40), wherein: the signature client computer (40) comprises: a communication module (45) for communicating with the server (31) and with a portable signature device (13) and receiving from the server (31) data characteristic of a document for conveying to the portable signature device; the portable signature device (13) comprises: a memory (18, 19) for storing a first digital signature of a document signed by signature application software (14), a communication module (16) for communicating with the communication module (45) of the signature client computer (40) and receiving therefrom data characteristic of a second digital signature of a document, and a controller (17) coupled to the communication module (16) and to the memory (18, 19) for comparing the first digital signature with the second signature code for verifying that the document corresponding to the second digital signature is authentic; and each of the remote client computers (42) comprises: a communication module (50) coupled to the signature application (14) for communicating with a communication module (35) of the server (31) so as to convey data representative of a document or its signature to the server (31) for forwarding to the signature client (40).

15. The computer system according to Claim 14, wherein the signature device (13) includes a signature application (14) for generating the digital signature of the document.

16. The computer system according to Claim 14 or 15, wherein at least one of the remote client computers (42) includes a signature application (14) for generating the digital signature of the document.

17. The computer system according to any one of Claims 14 to 16, wherein the server (31) maintains a document signature database (33) for maintaining a record of digital signatures pertaining to identified documents.

18. The computer system according to any one of Claims 14 to 17, wherein the server (31) maintains a client database (34) for maintaining a record of clients so as to determination of an identity of a signature device storing a first digital signature of an original document.

19. A method for using the signature device of any one of Claims 1 to 8 for verifying the authenticity of a document having a first digital signature stored in the memory of the signature device, said method comprising: a) receiving either the second digital signature of a selected document or the selected document for calculation of the second digital signature , b) comparing the second signature with the first digital signature stored in the signature device, and c) returning a message indicative of whether or not a match is found.

20. The method according to Claim 19, wherein operation b) includes: i) comparing the second digital signature with all first digital signatures stored in the signature device so as to determine whether any of the first digital signatures stored in the signature device match the second digital signature .

21. The method according to Claim 19, further including: d) receiving an identity of the document to be verified, and e) deteπnining which first digital signature stored in the signature device, must be compared with the second digital signature .

22. The method according to any one of Claims 19 to 21, for use with a signature device wherein the memory (18) is a secured memory bank internal to the device: f) storing in the memory (18) a library identifying modules that have been used with the device for maintaining document signatures, said library containing information allowing the signature device to determine whether a connected memory module is an original or a copy, g) reading corresponding information from a connected memory module coupled to the device, and h) comparing said corresponding information with information in said library so as to determine whether the connected memory module is an original or a copy.

23. The method according to any one of Claims 19 to 22, for verifying the authenticity of multiple documents each having a respective first digital signature stored in the memory of the signature device, said method comprising: a) producing a corresponding component signature code for each of the documents to be verified, b) appending the corresponding component signature codes to each other in known order to produce a hash-document, containing for each document the respective component signature code, c) calculating a composite signature code of the hash-document, and d) transmitting the composite hash code with the ordered list of documents to be checked to the signature device.

24. The method according to any one of Claims 19 to 22, for verifying the authenticity of multiple documents each having a respective first digital signature stored in the memory of the signature device, said method comprising: a) extracting component signature codes of all the documents in an ordered list, b) appending the component signature codes in order as shown in the ordered list so as to produce a hash-document, c) calculating a signature code of the hash-document, and d) comparing said signature code to a received composite signature code.

25. The method according to Claim 24, further including: e) detecting a mismatch between said signature code and the received composite signature code indicative of at least one inauthentic document in said list, f) repeating a) to d) in respect of successive subsets of documents in said list so as to reveal an inauthentic document, g) eliminating the inauthentic document and repeating from a) as required in order to reveal other inauthentic documents.

26. A method for using the system of any one of Claims 14 to 18 in association with a signature device having a known public key for signing a document by multiple authors (Client-1, Client-2 ... Client-N) so as to generate a first digital signature for storing in the memory associated with the signature device, said method comprising the following operations carried out by a first one (Client-1) of said co-authors: a) producing a first digital signature (hash-1) of a copy of the document using a signature algorithm, b) generating a first one time acknowledge code that is to be appended to the first digital signature and returned by the signature device upon a successful operation, c) encrypting the first acknowledge code using the public key of the signature device and appending the encrypted first acknowledge code to the first digital signature (hash-1) to form a composite signature, and d) encrypting the composite signature using the first co-author's (Client-1) private key so as to generate a first level encrypted composite signature (Sign-1).

27. The method according to Claim 26, further including tihe following operations carried out by each successive co-author Client-/ upon receipt of encrypted data from a previous co-author, Client- k-l : e) producing a /t* digital signature (hash-k) of a copy of the document in his possession, using said signature algorithm used by the first co-author (Client-1) to produce the first digital signature (hash-1). f) generating a /c* one time acknowledge code that is to be appended to the previous author's (Client-/ -l) encrypted composite signature (Sign-/ -l), upon completion of a successful operation, g) testing first for a successful operation by, i) for each successive previous author decrypting the respective encrypted composite signature (sign- ) using the respective author's public key, and repeating the process backward to the first co-author (Client-1), thus extracting the digital signature (hash-1) from the first level encrypted composite signature (sign-1), ii) comparing the digital signature (hash-/c) created by Client-^ with the digital signature (hash-1) of the first co-author (Client-1), iii) if the respective digital signatures are not identical, then aborting the signature process with an error code indicating for non- identical copies of the document to be signed, h) if the respective digital signatures are identical signifying a successful operation, then encrypting the k one-time acknowledge code using the public key of the signature device and appending the encrypted / * one- time acknowledge code to the (k-l) encrypted composite signature, to form a level-/ composite signature, i) encrypting the level-/ composite signature using the co-author (Client- / )'s private key so as to generate a level-/c encrypted composite signature (Sign-/c), j) if there are any successive co-authors:

. i) sending the current level-/ encrypted composite signature (Sign-/c) to a successive co-author (Client k+l) for further processing; else k) if there are no successive co-authors: i) encrypting the current level encrypted composite signature with the public key of the signature device thus producing an encrypted final level encrypted composite signature (Sign-N-O), and

1) conveying the encrypted final level encrypted composite signature (Sign-N-O) to the server (31), or directly to the authentication client

(40).

28. The method according to Claim 26 or 27, wherein all of said co-authors receive or generate an identical "signing parties list" indicating an order in which authors sign the document in a manner that is accessible to all co-authors without decryption.

29. The method according to Claim 28, wherein the first co-author further conveys an encrypted version of the "signing parties list", using his private key, together with the digital signature so each successive co-author and the signature device can determine that the "signing parties list" is not corrupted and match its own list.

30. The method according to Claim 27, including the following operations carried out by the server (31): m) conveying the final level encrypted composite encrypted signature (Sign-N-O) to the authentication client (40) for forwarding to the signature device.

31. The method according to Claim 27 including the following operations carried out by the signature device (13): n) decrypting the final level encrypted composite encrypted signature (Sign-N-O) using its own secret private key and extracting the final level encrypted composite encrypted signature (Sign-N), o) using the public key of the final co-author (Client-N) to decrypt the final, level encrypted composite encrypted signature (Sign-N), p) extracting a preceding co-author's encrypted signature (Sign-N- 1) with the appended acknowledge code for the final co-author, q) decrypting the final co-author's acknowledge code using the signature device's private key, r) returning the valid acknowledge to the final co-author (Client-N), s) repeatedly extracting a preceding co-author's encrypted signature, as 5 required and decrypting using the respective the public key of preceding co-authors until the document's digital signature (hash-A) is extracted and the acknowledge message for each co-author is decrypted and acknowledged, and t) storing the document signature (hash-A). 10

32. The method according to Claim 31, wherein the signature device accumulates the co-authors' acknowledge codes without first sending them and verifies the signing list implanted by the first co-author (client- A) in the final level encrypted composite encrypted signature (Sign-N-O) against a perceived order of signing co-authors and returns the acknowledge codes only if a match is found. 15

33. The method according to Claim 31, wherein the operation t) of storing the document signature (hash-A) includes: i) storing the document signature (hash-A) in an onboard controller internal secured memory bank (18) with or without further encryption, or 20 ii) storing the document signature in its original received encrypted form without further decryption.

34. The method according to Claim 31, wherein the operation t) of storing the document signature (hash-A) includes: i) storing the document signature (hash-A) in a detachable memory 25 module in either secured or protected mode, ii) in protected mode, protecting the signature against modification by. encrypting it using the signature device's private key, and iii) in secured mode, encrypting the signature using a symmetric key.

35. The method according to any one of Claims 31 to 34, wherein the operation q) of decrypting the final co-author's acknowledge code includes: i) encrypting the acknowledge code using the signature device's private key, so as to generate an encrypted acknowledge code.

36. The method according to any one of Claims 31 to 34, wherein the operation q) of decrypting the final co-author's acknowledge code includes: i) encrypting the encrypted acknowledge code with the respective client's public key prior to conveying to the respective client.

37. The method according to any one of Claims 26 to 36, further including: u) generating a memory bank portion of a signature unique ID (SUID) for storing in the signature database (33).

38. A method for using the system of any one of Claims 14 to 18 in association with a signature device having a known public key for verifying a document having a digital signature stored in a memory associated with the signature device, said method comprising the following operations all carried out by a verifying client (Client A): a) generating the digital signature (hash-A) of a copy of the document to be authenticated, b) appending a one time acknowledge code (ACK-A) to be returned as proof of document authenticity so as to generate a composite signature, c) encrypting the composite signature using the verifying client's private key so as to produce an encrypted composite signature, d) encrypting the encrypted composite signature using the signature device's public key thus producing a doubly encrypted composite signature, e) conveying the doubly encrypted composite signature to the server (31)_. along with an identity (SUID) of the document for forwarding together with a document authentication request to an identified signature client for decrypting, extracting the digital signature and verifying and reftiπiing a message indicative of whether or not the signature code is valid, f) receivirig via the server the one time acknowledge code (ACK-A) encrypted using the signature device's private key and further encrypted with the public key of the verifying client, and g) decrypting to extract the one time acknowledge code (ACK-A).