Patent Application
20120324229
This invention relates generally to the creation of digital signatures. More particularly, the present invention relates to a system and method of generating keyless digital multi-signatures for digital data.
Digital signatures are often used to authenticate digital data such as documents, messages, financial information, and other data. When a piece of data is digitally signed, a recipient of the data can verify that the data is from a particular sender, known as a signer, and that the data has not been altered since it was signed. A digital signature may also certify when data was created or when the data was sent. Existing digital signature schemes utilize public-key cryptography in which a signer uses a private key to create a digital signature, and a public key that is paired with the private key is used to verify the digital signature. The public key is bound to the identity of the signer using public key certificates that are issued by a trusted Certificate Authority in this public-key infrastructure scheme. A recipient uses the public key certificate to verify the digital signature.
However, there are drawbacks to these existing digital signature schemes. A signer can produce an unlimited number of digital signatures using the private key once it is issued. More importantly, if the private key is stolen, an unauthorized entity can appear as the signer to generate and distribute legitimate digital signatures. In such a case, the legitimate signer can attempt to revoke the private key, but it becomes difficult to determine if any forged signatures were created in the time between the loss of the private key and when the private key was revoked. It also becomes more complicated to verify whether previously created signatures are valid because the private key associated with those signatures has been revoked. Furthermore, existing digital signature schemes rely on the trustworthiness of the Certificate Authority because the creation of the private key is out of the control of the signer. If the Certificate Authority is compromised, the digital signatures that have been created based on the private keys the Certificate Authority has issued would come under suspicion. Accordingly, the signer must place unconditional trust in the Certificate Authority.
Other digital signature schemes attempt to reduce the risk of an unauthorized entity producing digital signatures if the private key is stolen by sharing the private key between the legitimate signer and a server. However, public-key cryptography is still involved in such server-supported digital signature schemes and the private key can still be compromised by an unauthorized entity. Still other digital signature schemes utilize a time-stamping service that attempts to mitigate risk in the time between the loss of a private key and when the private key is revoked. However, this type of scheme only supports public-key infrastructure and its associated risks detailed above. Also, because it may not be known when the private key was lost or stolen, forged signatures may still have been generated before the private key is revoked.
Furthermore, some existing digital signature schemes do not rely on public and/or private keys but utilize signature generation servers that are able to support a single signature request at a time from a client computer. In one scheme, a keyless digital signature service provider operates a top-level signature generation server that is in communication with lower level servers that may be operated by other entities, such as customers of the service provider. The service provider may want to charge the operators of the lower level servers for the signatures generated at the top-level signature generation server. The number of keyless signatures generated at one time may not be easily tracked or limited in this scheme. Checking the total length of a hash chain when verifying a generated signature could be performed to track the number of generated signatures, but would require all customers to have the same maximum limit on the number of generated signatures. The needs of different customers could not be accommodated in this scenario.
Another way to limit the number of signatures generated by the top-level generation server is to include a numerical tag at each step in the hash chain when verifying a generated signature. The limit on the number of generated signatures could be set differently for each customer so that not all customers must have the same maximum limit. When a signature is verified in this scheme, the numerical tags would be checked to ensure that they are in strongly increasing order, i.e., each numerical tag must be greater than the numerical tag from the previous step in the hash chain, in order to verify the signature successfully. However, the customer server may bypass checking the numerical tags in this method to avoid the limitation on the number of generated signatures, while the remainder of the signature would still verify successfully.
The present invention is provided to generate a keyless digital multi-signature based on receiving a plurality of signature generation requests from one or more client computers. By handling multiple signature requests simultaneously, the present invention allows for more efficient and quicker generation of keyless digital signatures. Moreover, the present invention allows limits on the number of signatures that can be generated at a time as a way to track and/or cap the signatures a client computer requests for billing or other purposes. In one embodiment of the present invention, a system and method for generating a keyless digital multi-signature is disclosed in which a plurality of signature generation requests is received at a service provider computer from a client computer. A search tree including a subtree from each of the client computers is constructed. The leaf nodes of the search tree correspond to each of the signature generation requests. The search tree is balanced by assigning explicit length tags to leaf nodes of the search tree as needed. A hash value is computed for each of the nodes in the search tree by applying a hash function to the nodes. The hash value of the root node of the search tree and a search tree height tag make up an aggregate signature request. The aggregate signature request causes an aggregate signature to be created and received at the service provider computer. The aggregate signature is only created if the search tree height tag does not exceed a height limitation. The keyless digital multi-signature for the signature generation requests is generated based on the aggregate signature. An implicit length tag that is empty in the aggregate signature is filled when the keyless digital multi-signature is generated and verified so that the number of signature generation requests is limited. Other features and advantages are provided by the following description and drawings.
While this invention is susceptible of embodiments in many different forms, there is shown in the drawings and will herein be described in detail preferred embodiments of the invention with the understanding that the present disclosure is to be considered as an exemplification of the principles of the invention and is not intended to limit the broad aspect of the invention to the embodiments illustrated.
The server(s) may include a suitable processor, as are known to those of skill in the art. The processor is operably connected to at least one memory storage device, such as a hard-drive or flash-drive or other suitable memory storage device, that can include any one or a combination of volatile memory elements (e.g., random access memory (RAM, such as DRAM, SRAM, SDRAM, etc.)) and nonvolatile memory elements (e.g., ROM, hard drive, tape, CDROM, etc.). Moreover, the memory storage device may incorporate electronic, magnetic, optical, and/or other types of storage media. The memory storage device can have a distributed architecture where various components are situated remote from one another, but are still accessed by the processor.
Steps and/or elements, and/or portions thereof of the present invention may be implemented using a source program, executable program (object code), script, or any other entity comprising a set of instructions to be performed. When a source program, the program needs to be translated via a compiler, assembler, interpreter, or the like, which may or may not be included within the memory, so as to operate properly in connection with the operating system (O/S). Furthermore, the software embodying the present invention can be written as (a) an object oriented programming language, which has classes of data and methods, or (b) a procedural programming language, which has routines, subroutines, and/or functions, for example but not limited to, C, C++, Pascal, Basic, Fortran, Cobol, Perl, Java, and Ada.
When the server is in operation, the processor is configured to execute software stored within the memory storage device, to communicate data to and from the memory storage device, and to generally control operations of the server pursuant to the software. The software aspects of the present invention and the O/S, in whole or in part, but typically the latter, are read by processor, perhaps buffered within the processor, and then executed.
When the present invention or aspects thereof are implemented in software, it should be noted that the software can be stored on any computer readable medium for use by or in connection with any computer related system or method. In the context of this document, a computer readable medium is an electronic, magnetic, optical, or other physical device or means that can contain or store a computer program for use by or in connection with a computer related system or method. The present invention can be embodied in any computer-readable medium for use by or in connection with an instruction execution system, apparatus, or device, such as a computer-based system, processor-containing system, or other system that can fetch the instructions from the instruction execution system, apparatus, or device and execute the instructions. In the context of this document, a “computer-readable medium” can be any means that can store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device. The computer readable medium can be for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, device, or propagation medium. More specific examples (a non-exhaustive list) of the computer-readable medium would include the following: an electrical connection (electronic) having one or more wires, a portable computer diskette (magnetic), a random access memory (RAM) (electronic), a read-only memory (ROM) (electronic), an erasable programmable read-only memory (EPROM, EEPROM, or Flash memory) (electronic), an optical fiber (optical), and a portable compact disc read-only memory (CDROM) (optical). Note that the computer-readable medium could even be paper or another suitable medium upon which the program is printed, as the program can be electronically captured, via, for instance, optical scanning of the paper or other medium, then compiled, interpreted or otherwise processed in a suitable manner if necessary, and then stored in a computer memory.
For communication between servers and/or between a server and a client computer, the servers are equipped with network communication equipment and circuitry. In a preferred embodiment, the network communication equipment includes a network card such as an Ethernet card. In a preferred network environment, each of the server(s) is configured to use the TCP/IP protocol to communicate via the network 301. It will be understood, however, that a variety of network protocols could also be employed, such as IPX/SPX, Netware, PPP and others. Wireless network connections are also contemplated, such as wireless Ethernet, satellite, infrared and radio frequency networks.
Referring back to
At step 104, the signature generation requests 502 can be grouped by their respective client computer identifiers 508. The signature generation requests 502 may be stored in a sorted database, in a preferred embodiment. There are three client computer identifiers 508 shown in the example of
A subtree for each client computer can be built at step 106. The subtrees can be built based on the groupings of the signature generation requests 502 performed at step 104. In particular, the leaf nodes of each subtree can each be assigned a signature generation request 502. As seen in the example of
A search tree skeleton 522 can be created and the subtrees can be assigned to the search tree skeleton 522 to create a search tree 524 at step 108, as in the example shown in
At step 110, an explicit length tag 526 can be assigned to each leaf node 516 to balance the constructed search tree 524. The process 100 iterates through steps 110 and 112 until all leaf nodes have been assigned an explicit length tag 526. The explicit length tag 526 may be zero or non-zero. The search tree 524 may be unbalanced due to the tree height tags 506 in the signature generation requests 502 and/or due to the length of the individual hash chains contained within the search tree 524. The tree height tags 506 contribute to the height of the search tree 524 due to the trees contained within each of the signature generation requests 502.
As seen in the example shown in
Hash values for all nodes of the search tree 524 can be computed at step. 114, which is further detailed with regards to
Ultimately, the root hash value 530r for the root node 520 of the search tree 524 can be computed once all the other nodes in the search tree have had their hash value computed. The root hash value 530r represents and includes the hash values of all the other nodes in the search tree 524. At step 116, the aggregate signature request 528 can be computed and includes the root hash value 530r and a search tree height tag 532. In the example shown in
The aggregate signature request 528 may be processed at the service provider computer or may be transmitted to a parent server in communication with the service provider computer. At step 118 of the process 100, the aggregate signature 700 can be generated and received, based on the aggregate signature request 528, as further detailed with regards to
If the search tree height tag 532 exceeds the predetermined height limit at step 304, then the aggregate signature request 530 can be ignored and dropped at step 310. In this case, the aggregate signature 700 and the keyless digital multi-signature 800 will not be generated. However, if the search tree height tag 532 is less than or equal to the predetermined height limit at step 304, then the aggregate signature 700 can be created at step 306. The search tree height tag 532 may also be included in the search tree 524 at step 306. The aggregate signature 700 is transmitted at step 308, either within the service provider computer, or from the parent server to the service provider computer, depending on which computer processed the aggregate signature request 530.
In some embodiments, the aggregate signature 700 may have the same hash tree structure as the search tree 524. However, a hash function has been applied to the hash values of the nodes of the search tree 524, including the root hash value 530rand search tree height tag 532, to generate the aggregate signature 700. The aggregate signature 700 may also include shorter hash chains than the hash chains that will be present in the keyless digital multi-signature 800. The hash function used to create the aggregate signature 700 may be the same or a different deterministic function than the hash function used to create the hash values in the search tree 524. A timestamp can also be hashed into the aggregate signature 700 to indicate the date and time when the aggregate signature 700 was generated. The aggregate signature 700 can be digitally signed in response to receiving the aggregate signature request 530. The digital signature applied to the aggregate signature request 528 may be based on a public key encryption scheme, a public/private key encryption scheme, or any other scheme that authenticates the identity of the issuer of the signature. A unique serial number may be included in the aggregate signature 700. An implicit length tag 732 may further be included in the aggregate signature 700 and may initially be left blank when the aggregate signature 700 is generated. The implicit length tag 732 can be filled when counting the number of hash computational steps when the keyless digital multi-signature 800 is generated and/or verified. The value of the filled-in implicit length tag 732 can be compared to the search tree height tag 532 to ensure that the number of signature generations requests that were transmitted by the client computer is within limitations. In other embodiments, the aggregate signature 700 may include a published hash value with timestamp and location information about when and where the hash value was published. The timestamp and location information may be hashed into the published hash value, for example. The published hash value may be added to the keyless digital multi-signature 800 as an additional data structure to allow for easy extractability from the keyless digital multi-signature 800.
If a client computer tries to transmit a signature generation request 502 that has a tree height tag 506 that is smaller than the actual height of the tree in the signature generation request 502, the use of an implicit length tag 732 that must be filled in helps ensure that the signature generation limitations on a client computer are followed. For example, if the client computer attempts to add an external data structure to the tree with a false height, this would be evidence that there was an intentional abuse of the signature generation service.
Generation of the keyless digital multi-signature 800 is performed at step 120, and is detailed further with regards to
In the example shown in
At step 406, a node of the hash chain 850 can be examined, and it can be determined at step 408 whether the examined node corresponds to a leaf node 716. If the node corresponds to a leaf node 716, then at step 410, a hash function 802 is applied to the data 704, tree height tag 706, client computer identifier 708, and explicit length tag 726 in the signature generation request 702. The resulting hash value is assigned to the node at step 412. If the node does not correspond to a leaf node at step 408, then at step 418, the hash function 802 is applied to the search key identifiers 804 (“=AB”, “BB”, and “AB”) of the search key nodes 718 and the hash values of the left child node and right child node connected to the non-leaf node, followed by assigning the resulting hash value to the non-leaf node at step 412. If additional nodes remain in the hash chain 850 at step 414, then the process 120 returns to step 406 to compute the hash values for the remaining nodes. The hash function 802 may be the same or a different deterministic function than the hash function used to create the hash values in the search tree 524 and/or the aggregate signature 700. If no nodes remain in the hash chain 850 at step 414, then the keyless digital multi-signature 800 is computed at step 416. The final node that is processed is the root node 720, and the resulting root node hash value 730y, the implicit length tag 732, and the hash chain 850 comprise the keyless digital multi-signature 800. The implicit length tag 732 can be calculated by counting the number of steps in the hash chain 850.
In the example shown in
In some embodiments, the hash chain computation is performed during a verification of the keyless digital signature 800. At each computation step in the hash chain 850 shown in
Any process descriptions or blocks in figures should be understood as representing modules, segments, or portions of code which include one or more executable instructions for implementing specific logical functions or steps in the process, and alternate implementations are included within the scope of the embodiments of the present invention in which functions may be executed out of order from that shown or discussed, including substantially concurrently or in reverse order, depending on the functionality involved, as would be understood by those having ordinary skill in the art.
It should be emphasized that the above-described embodiments of the present invention, particularly, any “preferred” embodiments, are possible examples of implementations, merely set forth for a clear understanding of the principles of the invention. Many variations and modifications may be made to the above-described embodiment(s) of the invention without substantially departing from the spirit and principles of the invention. All such modifications are intended to be included herein within the scope of this disclosure and the present invention and protected by the following claims.
