US 20060136728 A1 Abstract Methods, components, and systems for efficient authentication, either through a digital signature or message authentication codes, and verification of a digital stream sent from a source to a receiver via zero or more intermediaries, such that the source or intermediary (or both) can remove certain portions of the data stream without inhibiting the ability of the ultimate receiver to verify the authenticity and integrity of the data received. According to the invention, a source may sign an entire data stream once, but may permit either itself or an intermediary to efficiently remove certain portions of the stream before transmitting the stream to the ultimate recipient, without having to re-sign the entire stream. Applications may include the signing of media streams which often need to be further processed to accommodate the resource requirements of a particular environment. Another application allows an intermediary to choose an advertisement to include in a given slot.
Claims(82) 1. A method for communicating data between a server and a receiver, said method comprising:
signing at least one original data stream which includes a plurality of blocks; generating an intermediate data stream for the signed data stream, with arbitrary blocks adaptively removed without censoring the blocks of the original data stream; communicating the intermediate data stream to the receiver; and authenticating the intermediate data stream at the receiver. 2. The method according to ^{2}, or sixteen 3. The method according to 4. The method according to data stream blocks to be sent to the receiver; and auxiliary hash values for the blocks to be removed. 5. The method according to 6. The method according to 7. The method according to 8. The method according to 9. The method according to 10. The method according to Merkle tree values for the receiver to recompute the root of the Merkle tree; and data stream blocks. 11. The method according to determining a set of vertices corresponding to leaves in the Merkle tree associated with the blocks to be removed; if any pair of vertices are siblings in the Merkle tree, replacing these two vertices with their parent; and otherwise, computing the Merkle tree values associated with vertices. 12. The method according to 13. The method according to 14. The method according to 15. The method according to 16. The method according to 17. The method according to 18. The method according to 19. The method according to 20. The method according to generating a Merkle tree for each of the original data streams; computing a value associated with a root of each of the Merkle trees; and generating a final root value by hashing the values of the roots of the Merkle trees. 21. The method according to data stream blocks; and Merkle tree values for the receiver to recompute the root of the Merkle tree. 22. The method according to determining, for each signed data stream, a set of vertices corresponding to leaves in the Merkle tree associated with the blocks to be removed; if any pair of vertices are siblings in the Merkle tree, replacing these two vertices with their parent; and otherwise, computing the Merkle tree values associated with vertices. 23. The method according to 24. The method according to 25. The method according to 26. The method according to 27. The method according to 28. The method according to 29. The method according to 30. The method according to 31. The method according to 32. The method according to 33. The method according to 34. The method according to 35. The method according to 36. The method according to 37. The method according to 38. The method according to 39. The method according to 40. The method according to 41. The method according to 42. The method according to 43. The method according to 44. The method according to 45. The method according to 46. A system for communicating data between a server and a receiver, comprising:
a signer signing at least one original data stream which includes a plurality of blocks; a data stream generator generating an intermediate data stream for the signed data stream, with arbitrary blocks adaptively removed without censoring the blocks of the original data stream; a receiver authenticating the intermediate data stream. 47. The system according to 48. The system according to 49. The system according to 50. The system according to 51. The system according to 52. The system according to receives the signed data stream; determines a set of vertices corresponding to leaves in the Merkle tree associated with the blocks to be removed; if any pair of vertices are siblings in the Merkle tree, replaces these two vertices with their parent; and otherwise, computes the Merkle tree values associated with vertices. 53. The method according to 54. The system according to 55. The system according to 56. The system according to 57. The system according to 58. The system according to generates a Merkle tree for each of the original data streams; computes a value associated with a root of each of the Merkle trees; and generates a final root value by hashing the values of the roots of the Merkle trees. 59. The system according to receives the signed data stream; determines, for each signed data stream, a set of vertices corresponding to leaves in the Merkle tree associated with the blocks to be removed; if any-pair of vertices are siblings in the Merkle tree, replaces these two vertices with their parent; and otherwise, computes the Merkle tree values associated with vertices. 60. The method according to 61. The system according to 62. A computer program product containing program code for performing a method of signing an original data stream, the method comprising:
decomposing at least one original data stream into a plurality of blocks; computing ancillary information selected from the group consisting of partial hash values of blocks of the signed data stream, values associated with a root of a Merkle tree generated for the original data stream, a multi-layer hash chain computed from partial hash values of each block of each data stream, and a final root value computed by hashing values of roots of Merkle trees, each of which corresponds to an original data stream; computing authentication information for each block based on the ancillary information; generating a signed data stream comprising the original data stream and the authentication information; and generating an intermediate data stream by adaptively removing arbitrary blocks without censoring the original data stream, wherein the intermediate data stream can be authenticated by a receiver. 63. The computer program product according to 64. The method according to 65. The computer program product according to 66. The method according to 67. The method according to 68. The method according to 69. A computer program product containing program code for performing a method of adaptively removing arbitrary blocks from a signed data stream for an original data stream, the method comprising:
determining to-be-sent data stream blocks in the signed data stream without censoring the original data stream; adaptively removing other blocks in the signed data stream by generating an intermediate data stream; and sending the intermediate data stream to a receiver for authentication. 70. The computer program product according to 71. The computer program product according to 72. The method according to 73. The computer program product according to determining a set of vertices corresponding to leaves in the Merkle tree associated with the blocks to be removed; if any pair of vertices are siblings in the Merkle tree, replacing these two vertices with their parent; and otherwise, computing the Merkle tree values associated with vertices. 74. The computer program product according to 75. The method according to 76. The computer program product according to 77. A computer program product containing program code for performing a method of authenticating an intermediate data stream, the method comprising:
distinguishing data stream blocks in the intermediate data stream, which is derived from an original data stream, but has some data removed from it; computing ancillary information for blocks in the intermediate data stream, the ancillary information being selected from the group consisting of partial hash values of blocks of the intermediate data stream, values associated with a root of a Merkle tree generated for the original data stream, a multi-layer hash chain, and a final root value computed by hashing values of roots of Merkle trees generated for original data streams; and verifying authentication information. 78. The computer program product according to 79. The computer program product according to 80. A server in a data communication network, comprising a processor and the computer program product according to 81. An intermediate node in a data communication network, comprising a processor and the computer program product according to 82. A receiver in a data communication network, comprising a processor and the computer program product according to Description This application claims the benefit of Provisional Application No. 60/495,787, filed Aug. 15, 2003. The present application incorporates the disclosure of this provisional application by reference. 1. Field of the Invention The present invention relates to data stream authentication, and more specifically to authentication schemes with adaptively controlled packet loss. 2. Description of the Related Art In many cases, it is desirable to append authentication information to a stream of data to assure a recipient that the data came from a specific source and was not modified en-route. For example, if the data is being provided to an application, then it would be important for the application that the data has not been corrupted either maliciously or by accident. In cryptography, there are two traditional mechanisms for permitting such authentication: 1. Message Authentication Codes (MAC) 2. Digital Signatures With a MAC, both the original source and the ultimate receiver must possess knowledge of a shared secret key. The sender applies a mathematical transformation involving the original data and secret key, and produces a tag. The receiver can then apply a similar transformation with the data, the tag, and the secret key to verify the origin and the integrity of the data. With Digital Signatures, the key is split into two parts: a secret signing key and a public verification key. The public verification key can be used to verify anything signed using the secret signing key. The key is split in such a way that it is not possible to derive the private portion from the public portion. The sender applies a mathematical transformation involving the original data and secret signing key, and produces a signature. The recipient can then apply a similar transformation with the data, the signature, and the public verification key to ascertain the identity of the sender and the integrity of the data. Digital signatures have a non-repudiation property that MACs do not. Namely, the signer cannot later deny having signed the document since the signing key is secret and was in the signer's possession. Of course, the signature owner can always claim that the secret signing key was stolen by some adversary. Because of their nature, traditional authentication schemes do not tolerate any transformations to the data made by the source or by an intermediate. If a document is modified after it is signed, the verification step will so indicate, and will fail. But for many applications, it is not only convenient, but sometimes necessary, to permit some specific types of modifications. For example, scalable video coding schemes, a high-level picture of the principle of which is shown in Now, in an environment that is resource constrained, one might want to strip the enhancement layers and only send the base layers. If the entire stream has been digitally signed or authenticated in conventional ways, then by removing the enhancement layers, the original tag or signature becomes invalid. Thus the entire stream would have to be reauthenticated. Alternatively, one may want to splice several streams of different qualities as in a simulcast situation. There may be one high-quality version of the stream, one medium-quality version of the stream, and one low-quality version of the stream. If network resources are available, then the high-quality stream may be sent, but if the network congestion goes up, then one may want to shift to the medium or low quality streams. In an alternate scenario, it could be the case that the receiver is mobile and is leaving one network environment and entering another that has different resource restrictions. The splicing situation can be considered a special case of a lossy situation where the quality of signal transmission is poor or otherwise is degraded, for example, by viewing the three data streams as one huge layered stream and imagining that two out of three frames are being discarded. Yet another application is dynamic advertising. A source may include in a given slot a number of advertisements that can be displayed. An intermediary can then choose from among these choices which advertisement it would like to display. The choice can, for example, be based upon what the intermediary thinks will be the best advertisement for the target audience. The advertisements themselves can be created by an intermediary or some other party, and can be provided to the source either in their original form or may be hashed. The source would then include them when signing the stream. Thus, signature schemes that can handle these types of losses in a secure manner are needed. Here, “secure” means that the ultimate end receiver can determine with overwhelmingly high confidence that the data it receives comes from a stream that was originally signed validly, but for which certain portions were removed. In addition, there is also a need for an intermediary that can adaptively and intelligently decide which blocks to drop. One conventional solution to the controlled loss authentication problem is to authenticate each packet individually. This solution has two substantial drawbacks. First, in the case of using digital signatures, a fairly expensive computation must be performed for each packet. Second, in both the digital signature and MAC case, authentication information must be appended to each packet, which may not be feasible in consideration of efforts to remove portions of the stream stem to meet bandwidth constraints. levels. Then, the decoder In R. Johnson, D. Molnar, D. Song, and D. Wagner, Homomorphic Signature Schemes—RSA 2002, Cryptographer's Track, the authors propose a redactable signature scheme. It permits certain specific transformations on the data while still allowing the receiver to verify. It also allows arbitrary deletion of substrings in a signed document and has applications for censoring. Suppose n message blocks m=m Accordingly, there has been a need for a secure authentication scheme that permits controlled removal of certain blocks in a stream without weakening the receiver's ability to verify the authentication information, and without requiring confidentiality of censored data. In view of the foregoing, it is an object of the present invention to provide schemes for secure authentication under adaptive data loss both in the symmetric setting (with MAC) or in the asymmetric setting (with digital signatures), which are efficient with respect to the computation requirements of the sender, receiver, and intermediary, as well as the bandwidth requirements of the channels over which these parties communicate. Briefly, the present invention addresses the following problems: 1. adaptive loss (subsequence) authentication, wherein data chunks are removed arbitrarily; 2. simulcast authentication, wherein several data streams are intertwined and only one data chunk is taken at a time from a given stream, and the data from the other streams is dropped; and 3. adaptively lossy simulcast authentication, wherein sometimes the entire data chunk is dropped altogether. The present invention provides the following schemes: 1. Linear Scheme for Subsequence Authentication; 2. Linear Scheme for Simulcast Authentication; 3. Tree Scheme for Subsequence Authentication; and 4. Tree Scheme for Simulcast Authentication. Each of the above schemes may incorporate either a digital signature or a MAC. Therefore, the present invention implicitly provides 8 (=4×2) schemes. The schemes use cryptographic hash functions to process the blocks of the original stream and create a short digest. A digital signature or MAC is then applied to the digest, thereby providing authentication information. If the receiver is given the entire stream, then it can recompute the digest and verify the signature. When specific portions of the stream need to be removed, the remover sends information that allows the receiver to efficiently compute the digest. The amount of information provided to the receiver in this setting is related to the output size of the cryptographic hash function and is otherwise independent of the actual data stream. According to one aspect of this invention, Linear Scheme for Subsequence Authentication, the intermediary or source can remove arbitrary blocks (irrespective of their location) while still permitting the receiver to authenticate information. The scheme involves computing a two-layer hash chain and providing the recipient with various values in this chain. The scheme is online for the receiver in the sense that the receiver does not have to incur any delay in verifying the authentication information. In an optimization and generalization to this scheme, one second layer-hash is computed for every bundle of r first-layer hashes. When r=1, the scheme is the original linear scheme for subsequence authentication. In an improvement to this scheme, several first-layer hashes are aggregated before performing the second-layer hash. Consequently, fewer second-layer hashes need to be performed. According to a second aspect of this invention, Linear Scheme for Simulcast Authentication, the intermediary or source is provided with multiple streams and can arbitrarily switch among which stream it transmits while still permitting the receiver to authenticate information. The scheme involves computing a multi-layer hash chain and providing the recipient with various values in this chain. The scheme is online for the tone power source lines by ½, ¼, ⅛, . . . . Then, the area occupied by the authentication information. According to a third aspect of this invention, Tree Scheme for Subsequence Authentication, the intermediary or source can remove arbitrary blocks (irrespective of their location) while still permitting the receiver to authenticate information. The scheme involves computing a hash tree and providing the recipient with various values in this tree. In the case that some subset (of size greater than one) of dropped blocks constitute a subtree of the hash tree, the hashed scheme is more efficient with respect to bandwidth than the corresponding linear scheme. The scheme is not online for the receiver in the sense that the receiver must wait for all blocks before being able to verify the authentication information. According to a fourth aspect of this invention, Tree Scheme for Simulcast Authentication, the intermediary or source is provided with multiple streams and can arbitrarily switch among which stream it transmits while still permitting the receiver to authenticate information. The scheme involves computing a hash tree and providing the receiver with various values in this tree. The scheme is not online for the receiver in the sense that the receiver must wait for all blocks before being able to verify the authentication information. In all aspects of this invention, it is assumed that the sender has possession of all data to be signed at the onset. In most cases, such as when media is pre-recorded, this will not be a concern. In the case of a live stream, the present invention breaks the stream into smaller chunks and applies the schemes specified herein. Those skilled in the art will recognize that variations and modifications can be made without departing from the spirit of the invention. The present invention permits a situation in which an intermediary may adaptively and intelligently decide which blocks are to be dropped. The schemes of the present invention readily adapt to any model for dropping blocks. Moreover, the intermediary is not required to know of any cryptographic keying material. Furthermore, if the source provides the intermediary with various hash values, then the intermediary can avoid having to do any cryptographic related computation. Instead, it just has to forward the blocks it desired together with the hash information for those blocks that are dropped. All of the inventive schemes have the property that, given knowledge ahead of time that a given block will not be dropped, then the first layer hash on that block will not be performed. That is, the first layer hash for just that block can be replaced with the identity function (h(x)=x). Both the linear and tree-based schemes can take advantage of correlation among blocks of data. For example, in the tree-based scheme, if a given subset of blocks has the behavior that all will be dropped or all will be kept, then these blocks can be placed as all the leaves of the same subtree. In the event that all packets in the given subset are dropped, only the root has to be transmitted. However, this concept applies even if the correlation is probabilistic. For example, if a given block being dropped makes it more likely that another block will be dropped, then these blocks should also be clustered. Likewise, in the linear schemes, if a given sequence of frames are to be all kept or dropped, these frames can be treated as a single block unit to be hashed. Then, if the entire sequence of frames is dropped only a single hash value needs to be sent. The present invention is described herein with reference to the accompanying drawings, similar reference numbers being used to indicate functionally similar elements. In the schemes of the present invention, an initial sender A communications network The above-mentioned transformations involve removing certain portions of the data. If an intermediary modifies the data stream, it will determine what information, if any, is required by the receiver to verify the authentication information associated with the stream. M denotes a media stream that can be broken up into it blocks of length b: M=M Examples of such cryptographic compression functions are found in SHA-1 or MD5. The compression function in SHA-1 has an output and IV size of 160-bits whereas the compression function in MD5 works with 128-bit values. Both allow for a 512-bit payload size. When it is necessary to operate on data blocks that are larger than the payload size, application of the compression function is repeated. Functions that operate as such while still retaining the collision resistance property are termed cryptographic hash functions. For simplicity, this term is used below even if a data block that fits within the payload is dealt with. For the schemes involving digital signatures, it is assumed that a public-key infrastructure exists, and that the sender has a key pair (Pk, Sk). Sk is the sender's private signing key—which can be used for appending a digital signature to a message, and Pk is the sender's public verification key which can be used to verify the authenticity of any signature issued using Pk. σ(Sk, M) denotes the digital signature algorithm on message M under signing key Sk, and v(Pk, M, σ) denotes the verification algorithm. The intermediate does not need to know either the signing or the verification key. For the schemes involving MAC, it is assumed that both the initial sender S and the ultimate receiver R share knowledge of a symmetric key, which need not be known by the intermediaries. The schemes of the present invention make use of conventional constructs involving cryptographic compression functions. One such construct is an iterated hash function which is built from cryptographic compression functions as follows. Suppose a message M can be broken up into n blocks of length b, and H is a cryptographic compression function with a b-bit payload and a v-bit output. The iterated hash function defined by H is the value x Assuming that it is hard to find collisions in the compression function H, it is then hard to find collisions in the iterated hash. Typically, when one wants to digitally sign a message, an iterated hash is applied to the message, and the resulting output is signed. The methods, systems, and components of the present invention will involve similar constructions, but intermediate values will be provided to aid in verification. Another conventional construct involving cryptographic compression functions is a Merkle tree. the selection circuit receives as input first through m-th (=2 The present invention also makes use of the notion of the co-nodes for a given vertex in a Merkle tree. The co-nodes of a vertex v consist of the direct siblings of the vertices on the path from v to the root. Given a vertex v and its co-nodes, one can compute the sequence of hash functions that lead from v to the root. 1. Subsequence Authentication The linear subsequence authentication scheme of the present invention allows stream authentication even when arbitrary blocks from the message are removed. As long as the blocks sent by an intermediate node are a proper subsequence of the original message, the receiver can authenticate the stream. 1.1 Signing Given a message M=M In the process of computing h Alternatively, the sender S may decide to transmit the hash values h _{1}, h_{n−1}, σ_{Sk}(h_{n})), (M_{2}, h_{n−2}) . . . (M_{n},h_{0}).
1.2 Signature Update If an intermediate node wants to strip off k arbitrarily located message blocks, the node generates a resulting “message” M′, identical to M but where k blocks have been removed. The receiver needs to be able to authenticate M′. Given the received n-block message M, the intermediate node computes “new” blocks M Depending on whether the block will be forwarded or dropped, the intermediate node computes
Let t be the index of the last message block that the intermediate node wants to send to the receiver, such that M _{1}′, . . . M_{n}′σ_{Sk}(h_{n}), h_{n−t})
Some standard encoding is applied to the block contents to facilitate distinguishing between “message blocks” and “hashes”. Skilled artisans would appreciate that there are numerous ways to perform this encoding. Alternatively, to enable on-line verification, the intermediate node transmits (M_{1}′,h_{n−1},σ_{Sk}(h_{n})), (M_{2}′,h_{n−2}), . . . (M_{n}′, h_{0})
1.3 Verification The receiver can verify the signature by computing h M′ _{n−i+1 }is a “hash” (4)
The receiver can then verify the signature on h The alternative on-line verification proceeds as follows: the receiver computes the partial hash h 1.4 Security As mentioned above, the iterated hash construction is collision resistant so long as the underlying hash function H is as well. In particular, if one finds a collision in the iterated construction, then at some point there is an internal collision, which means one can find a collision on the hash function H. If an adversary can come up with a non-subsequence forgery (that is, a message/signature pair that is not obtained by merely taking a subsequence of the original message), then it is possible to show that one can demonstrate either a collision in the hash function or a forgery on the underlying signature scheme. Therefore, as long as the signature scheme is not easily susceptible to forgery and the hash function is not easily susceptible to collisions, the scheme presented above is secure. 1.5 Performance When the intermediary removes blocks, it only needs to compute the hash of the block being removed. This computation does not involve any public-key steps and is fairly efficient. In fact, the throughput of algorithms like SHA-1 is on the order of a few hundred megabits per second. Moreover, if the intermediate nodes are resource bounded with respect to computation, the source can follow the alternative approach and include the intermediate h A tradeoff between bandwidth usage and buffering/computation is possible by sending some intermediate h The computations of this embodiment do not require storing the entire stream in memory since only a single input block to the hash function is needed at any given time. The scheme of the first embodiment permits the role of an intermediary which can adaptively and intelligently choose to remove any number of blocks without requiring knowledge of any cryptographic keying material. Moreover, the intermediary can be proximate to the receiver and can control the loss (and therefore the amount of hash information) dynamically. Furthermore, the authentication information can be verified in an online manner by the receiver. That is, the receiver can verify the authentication information as it receives the stream, and will not be required to do any form of extensive buffering. Also, the first layer hash computations are not required for any block that will not be dropped. For example, an MPEG I-frame or the base layer of a scalable coding scheme will not be intentionally dropped. For these blocks, only the second layer is required. In this instance, the first layer hash function for that block can be replaced with the identity function h(x)=x. In a similar spirit, if a given sequence of frames will either all be dropped or all be kept, then the above scheme is even more advantageous since it can cluster these as a single block before hashing. 2. An Efficiency Improvement to the Subsequence Authentication The second embodiment of the present invention provides an efficiency improvement to the basic linear subsequence authentication, by aggregating several first layer hashes before performing the second layer hashes. As a result, the method according to the second embodiment performs fewer second layer hashes. For a typical compression function, such as the one accompanying SHA-1, the payload size is 64 bytes whereas the digest size is 20 bytes. As a result, in this situation, three digests can be concatenated together before the second layer function is called. In the second embodiment, it is assumed that r hashes are aggregated. In addition, for any decimal number a, └a┘ denotes the smallest integer greater or equal than a, and ┌a┐ denotes the largest integer less or equal than a. 2.1 Signing For a message M, signature generation according to the second embodiment follows a similar paradigm to the scheme of the first embodiment, and uses “two hashing layers”. However, the scheme of the second embodiment involves fewer hashes than that of the first embodiment. Similarly to the scheme of the first embodiment, in the process of computing h Alternatively, the sender may decide to transmit the hash value h _{1},σ_{Sk}(h_{m})),(M_{2}), . . . ,(M_{r}, h_{m−1}),(M_{r+1}), . . . , (M_{2r},h_{m−2}), . . . (M_{n},h_{0}).
2.2 Signature Update Now, suppose an intermediate node wants to strip off n−k arbitrarily located message blocks. It generates a resulting “message” M′, identical to M but where n−k blocks have been removed. The receiver needs to be able to authenticate M′. Given the received n-block message M, the intermediate node computes “new” blocks M′ Depending on whether the block will be forwarded or dropped, the intermediate node computes
The hash values h _{1}′ . . . M_{n}′k,σ_{Sk}(h_{m}).
The above transmission requires buffering r packets to perform verification. In practice r will be quite small. For a SHA-1 based scheme r=3 and for an MD-5 based scheme, r=4. Alternatively, the intermediary may transmit the hash values hi along with the “new” message blocks (M_{1}′,σ_{Sk}(h_{m})),(M_{2}′), . . . ,(M_{r}′, h_{m−1}),(M_{r+1}′), . . . , (M_{2r}′,h_{m−2}), . . . , (M_{n}′,h_{0}).
2.3 Verification The receiver can verify the signature by computing h Finally, the receiver computes h The receiver can then verify the signature on h To perform online verification, the receiver needs to be able to compute the intermediate hash h 2.4 Security Similarly to the first embodiment, so long as the signature scheme is not easily susceptible to forgery and the hash function is not easily susceptible to collisions, the scheme of the second embodiment is secure. 2.5 Performance Similarly to the first embodiment, when the intermediary removes blocks, it only needs to compute the hash of the block being removed. It takes less time for the subsequence scheme of the second embodiment to both compute and verify the signature compared to the subsequence scheme of the first embodiment, since only one second-layer hash is performed for every r first layer hashes. If r is chosen carefully (for example, setting r=3 for SHA-1 or r=4 for MD-5), then each second-layer hash only requires a single call to the compression function. So, in the second embodiment, only
In addition to the advantages of the first embodiment, the receiver of the second embodiment can verify the authentication information after receiving every r blocks. In practice, r will be fairly small—on the order of 2 or 3, thus reducing the number of the second layer hashes. 3. Simulcast Authentication: the Multiplex Scheme Now, assume the original sender S transmits k different streams M 3.1 Signing Given messages M The initial sender transmits σ 3.2 Signature Update Suppose an intermediate node wants to select a possibly different stream (message) for each message block received. For instance, if each message encodes a video stream of different quality, the intermediate node may want to select a lower or higher quality depending on network congestion. It generates a “resulting message” M′, comprising “chunks” (consecutive message blocks) of the different streams. The intermediate node may pick a single stream (message) at each moment. It should be understood that the present invention allows for the possibility of layered streams. The receiver needs to be able to authenticate M′. Given the received n-block messages M Then if stream l is chosen, 1≦l≦k, it computes
The intermediate node finally transmits M′_{1 }. . . M′_{n},σ_{Sk}(h_{n}).
Alternatively, to enable on-line verification, the intermediate node transmits
_{1},h_{n−1},σ_{Sk}(h_{n})),(M′_{2},h_{n−2}), . . . , (M′_{n},h_{0}) (13)
3.3 Verification The receiver can verify the signature by computing h then, the receiver computes
The receiver can then verify the signature on h The alternative on-line verification procedure is straightforward. The receiver computes the partial hash h 3.4 Performance In addition to the advantages of the scheme of the first embodiment, the hash step of the scheme of the third embodiment can be iterated using a compression function with either the linear chaining scheme or a Merkle scheme. By using a Merkle tree-like construction to hash down each sequence of blocks M 4. Tree Scheme for Subsequence Authentication The fourth embodiment of the present invention is a scheme for authenticating subsequences using Merkle Trees. Like the linear subsequence authentication scheme, the tree-based scheme allows stream authentication even when arbitrary blocks from the message are removed. As long as the blocks sent by the intermediate node are a proper subsequence of the original message, the receiver can authenticate the stream. By exploiting certain aspects of the tree structure, the tree scheme is more efficient with respect to bandwidth than the linear scheme. 4.1 Signing 4.2 Signature Update If an intermediary wants to strip off k arbitrarily located message blocks, the intermediary generates a resulting “message” M′, identical to M, but with k blocks removed. The receiver needs to be able to authenticate M′. Let d 1) For all blocks M 2) If any pair of vertices are siblings in the Merkle tree, the intermediary replaces these two vertices both with their parent. 3) The intermediary keeps repeating the above process until no two vertices in the set are siblings. 4) The intermediary takes this set of vertices, and computes the Merkle tree values x fifth and sixth switches ( The intermediate node finally transmits
_{s} _{ 1 }. . . M_{s} _{ n−k },σ_{Sk}(x),x_{1}, . . . x_{r} (15)
Similarly to other embodiments of the present invention, applying standard encoding to the block contents facilitates distinguishing between “message blocks” and “hashes”. 4.3 Verification The receiver verifies the signature by computing the value of the root of the Merkle tree, using the following algorithm: 1) For every actual message block M 2) Consider the set of all hashes y 3) For each pair of values, if they correspond to vertices who are siblings, then replace the pair with their hash (which corresponds to the parent node). 4) Repeat the above step until only one value remains—this value is the root. If one has all the initial message blocks, then the above algorithm constitutes the standard algorithm for computing the root of a Merkle tree. Whenever the receiver receives some hashes x With the value of the Merkle root, the receiver can verify the signature it receives. 4.4 Security The Merkle hash construction is collision resistant so long as the underlying hash function H is collision resistant. In particular, if one finds a collision in the Merkle tree, then at some point there is a collision at an internal node, which means one can find a collision on the hash function H. If an adversary can come up with a non-subsequence forgery (that is, come up with a message/signature pair that is not obtained by merely taking a subsequence of the original message), then one can demonstrate either a collision in the hash function or a forgery on the underlying signature scheme. Therefore, as long as the signature scheme is not easily susceptible to forgery and the hash function is not easily susceptible to collisions, the scheme of the fourth embodiment is secure. 4.5 Performance When the intermediary removes blocks, it needs to provide the receiver with a sufficient number of internal hashes to compute the Merkle root of the tree without those message blocks. The intermediary will require k hashes for each of the blocks to be dropped and then at most k−1 hashes when replacing pairs of hashes with a single hash (since a single hash results in replacing two values with a single one, thereby reducing the net number by one). The total computation is therefore at most 2k−1 hashes. The total hashes computed by a single common switch (the number of switching elements is 12) to be shared. When the receiver receives the stream, it needs to compute the root. If it has all the message blocks, this would require 2n−1 hashes−n to initially hash each block, and then n−1 additional hashes when replacing pairs of hash values with a single hash (since a single function computation results in replacing two values with a single one, and at the end only one value is remaining). However, t of these hashes are computed by the intermediary. Therefore the receiver only has to compute 2n−1−t hashes. The total work in this scheme between the intermediary and the receiver is at most 2n−1 hashes. In the previous linear schemes 2n hashes were required. In terms of bandwidth, the tree based scheme may be much more efficient. Only r≦k hashes are finally sent. In the best case, if all k blocks to be dropped entirely constitute all leaves of a subtree in the Merkle tree, then only the single value corresponding to the root of this subtree is sent, that is r=1. In the worst case, if no pair of blocks are siblings, then the bandwidth requirements are the exact same as in the linear case, and k hash values need to be sent. 5. Tree Scheme for Simulcast Authentication The fifth embodiment of the present invention is a tree-based scheme for authenticating multiple parallel streams in which one data block is selected from one stream at each step of the transmission. As in the linear multiplex setting of the third embodiment, it is assumed that the original sender S transmits k different streams M 5.1 Signing Given k different streams M 1) The signer first generates a separate Merkle tree for each stream. Let v 2) The signer then computes x=H(IV, x 3) Finally, the signer transmits (M, σ 5.2 Signature Update Now, suppose an intermediate node wants to select a possibly different stream (message) for each message block received. For instance, if each message encodes a video stream of different quality, the intermediate node may want to select a lower or higher quality depending on network congestion. It generates a resulting “message” M′, comprising “chunks” (consecutive message blocks) of the different streams. The receiver needs to be able to authenticate M′. If the receiver can accurately compute each of the x Specifically, for each i with 1≦i≦k, let ks(i) denote the number of blocks that will actually be sent from stream M As to the indices of blocks that are to be dropped, for each i with 1≦i≦k, let kd(i) denote the number of blocks that will actually be dropped from stream M As in the tree scheme of the fourth embodiment, for each stream M 1) For all blocks
2) Now, if any pair of vertices are siblings in the Merkle tree, the intermediary replaces these two vertices both with their parent, i.e., the hash of concatenation of the values associated with the siblings. 3) The intermediary keeps repeating the above process until no two vertices in the set are siblings. 4) The intermediary takes this set of vertices, and computes the Merkle tree values X The intermediate node finally transmits the following information:
^{(1)}, . . . , M′^{(n)}}, σ_{Sk }(x), X^{(1)}, . . . , X^{(k)} (17)
The stream is sent in the proper order, that is, blocks from each of the M′ 5.3 Verification The receiver verifies the signature by first computing the values of the roots of each of the Merkle trees—after that it hashes these values and verifies the signature. It achieves this goal using the following algorithm which is run for each i: 1) First, for every actual message block M 2) Consider the set of all hashes computed above in the previous step as well the hash values contained in sets X 3) For each pair of values, if the pair corresponds to vertices who are siblings, then replace the pair with their hash (which corresponds to the parent node in the Merkle tree). 4) Repeat the above step until only one value remains—this value is the root x If one has all the initial message blocks, then the above algorithm constitutes the standard algorithm for computing the root of a Merkle tree. Whenever the receiver receives some hashes x With the values of the Merkle roots, x Also, because the Merkle roots are themselves hashed in a Merkle-like construction, there is room for further optimization. In particular, suppose that all blocks are dropped for two entire subtrees whose Merkle roots are siblings in the even larger tree. Then, instead of sending the two Merkle roots, their hash could be sent. 5.4 Security Similarly to the fourth embodiment, the fifth embodiment is secure as long as the signature scheme is not easily susceptible to forgery, and the hash function is not easily susceptible to collisions. Thus the invention presented above is secure. 5.5 Performance The performance of the fifth embodiment can be analyzed by extending the analysis for the tree-based subsequence scheme and the linear simulcast scheme. In all embodiments above, a hash function with a specific payload size and a specific IV is used. The chaining constructions tend to take some existing output and use that as the IV of the next block. In a further embodiment, instead of loading the current output as an IV, the current output can be concatenated to the next payload. The linear and tree schemes of the present invention can be combined to obtain hybrid solutions, giving rise to useful tradeoffs. In a further embodiment, a scheme starts by splitting each stream M In a further embodiment, a linear scheme is applied to each stream, and then a Merkle tree is computed on the results. Although the embodiments described above use binary Merkle trees, the constructions can be applied to general trees. It may be more advantageous to group certain blocks together if they have similar behavior; i.e., they either all will be dropped or all will be kept. If there are correlations among blocks, then it makes sense to cluster these blocks together in the tree-based schemes. For example, if a group of blocks will either all be dropped or all be kept, it is advantageous to have these blocks constitute all the leaves of a subtree. Then, if the packets are dropped, only the root of the subtree must be sent. In addition, the Merkle tree construction could be optimized. In one embodiment, if one of the streams will more likely be used than the others, it is advantageous to use a lopsided Merkle tree in which the priority stream is close to the root (e.g., perhaps right below it). In conjunction with the hybrid scheme mentioned previously, the streams are prioritized, so that the high priority streams are closer to the final value in the chain. This ordering particularly makes sense when layered streams are used. In such cases, the voltage difference between V(T There are blocks that should never be dropped, such as, an I frame in an MPEG stream, or the base layer in a scalably coded stream. The signer can avoid directly computing the initial first-layer hash on a block that will not be dropped. In the linear schemes, there are two hash layers. If a block will not be dropped, then there is no need to compute the hash in the first layer; instead only the second layer needs to be computed. The schemes of the present invention can be interpreted as having two phases. In the first phase, it finds a convenient way to hash each data block. In the second phase, it signs the hashes. The reason for doing so is that if a block is dropped, it is not necessary to retransmit it in its entirety. Instead, only the hash computed in the first phase is transmitted. This information is sufficient to allow the receiver to verify, since the signature can be viewed as being performed on the hashes. dividing the voltage difference between V(T By applying Forward Error Correction (FEC) techniques such as Erasure Codes to the hashes of the present invention, it is possible to deal with the uncontrolled loss situation without having to replicate. This approach might be especially useful in a multicast setting where different receivers have lost different packets but can be provided with identical error-correcting information. One consideration of this approach is that the receiver must perform a decoding step so may have to compromise the ability to verify authentication information in an online manner. Moreover, schemes of the present invention involve an intermediary which can adaptively choose the amount of forward error correction to the authentication information (i.e., hash outputs). In other words, rather than having a source estimate how much loss will occur and include sufficient authentication forward error correction information to accommodate that, the source can choose not to include authentication forward error correction information at all, and instead allow an intermediary to include the authentication forward error correction information dynamically to further increase the probability that the stream can be authenticated. The intermediary becomes an integral part of a scheme which considers both uncontrolled losses handled through forward error correction as well as adaptive and intelligent controlled losses. For example, in the Merkle tree constructions, it may suffice for the recipient to recover intermediate nodes (as opposed to just leaf nodes). In such a case, the intermediary can choose to supply forward error correction information to allow recovery of the (possibly interior) nodes necessary to authenticate, thus requiring possibly less forward error correction information. If the intermediary is sending different versions of the same stream to multiple receivers, because, for example, each has a different resource constraint with respect to the quality they view, the intermediary can recycle the work effort. In particular, the between the terminals T Along these lines, work can be recycled between the source and the intermediary. That is, the source can provide the intermediary with any necessary hash computations for assisting with authentication. Then, the intermediary is not required to perform any work of a cryptographic nature. Instead, it can choose which blocks to drop and select the corresponding authentication information to be transmitted. Another application of the present invention is insertion and selection of advertisements in a stream. The intermediary or some other party provides advertisements or a hash of advertisements, for example hashed using a Merkle tree, to the source. The source then includes the Merkle hash in its stream as a placeholder, allowing the intermediary to choose which advertisement it would like to use. Of course, this concept is not necessarily limited to advertisers. Although the focus of the present invention is on authenticating information, the above scheme can also be used in conjunction with an encryption scheme provided that the scheme is designed to permit the recipient to decrypt a given block without requiring the decryption of or presence of many other blocks. Two block cipher encryption modes facilitate this approach. One is counter-mode encryption and the other is electronic code book (ECB) encryption. Alternatively, it is possible to use a stream cipher, though a caveat is that the receiver may need to perform work that is proportional to the size of the original stream as opposed to the portion of it that he receives. One may be able to use chaining or feedback modes (cipher block chaining (CBC), output feed back (OFB), etc) provided that the receiver receives any intermediate information to decrypt. Such information may include intermediate IVs or actual ciphertext blocks. Yet another approach is to mix the modes, i.e., for large segments which will not be dropped, a chaining or feedback mode can be used; whereas for other blocks, a counter mode or ECB mode can be used. For example, in an MPEG stream, I-frames are never dropped intentionally, so they can be treated differently and encrypted using CBC mode. A similar remark applies to the base layer of any scalable coding scheme. While the invention has been described in detail above with respect to various embodiments, the ordinarily skilled artisan will appreciate that variations of these embodiments are possible without departing from the scope and spirit of the invention. Therefore, the invention should be considered as limited only by the scope of the appended claims. Referenced by
Classifications
Legal Events
Rotate |