11.07.2015 Views

Authentication for Multicast Communication Christophe Tartary

Authentication for Multicast Communication Christophe Tartary

Authentication for Multicast Communication Christophe Tartary

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

Dedicated to my parents


ContentsThesis Synopsis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vPublications related to this Thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiNote to the Reader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xiii1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12. Mathematical Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.1 Cryptographic Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.1.1 Digital Signatures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.1.2 Hash Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.1.2.1 Signing with Hash Functions . . . . . . . . . . . . . . . . . . . . 92.1.2.2 Merkle Hash Trees . . . . . . . . . . . . . . . . . . . . . . . . . . 102.1.3 Pseudorandom Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.2 Complexity Theory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.3 Polynomial Reconstruction Problem . . . . . . . . . . . . . . . . . . . . . . . . . . 122.3.1 Algebraic Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.3.2 Reconstructing Polynomials . . . . . . . . . . . . . . . . . . . . . . . . . . 133. A Taxonomy of <strong>Multicast</strong> <strong>Authentication</strong> Schemes . . . . . . . . . . . . . . . . . . . . 153.1 Protocols without Non-repudiation of Origin . . . . . . . . . . . . . . . . . . . . . . 163.1.1 Unconditionally Secure Protocols . . . . . . . . . . . . . . . . . . . . . . . 163.1.2 Conditionally Secure Protocols . . . . . . . . . . . . . . . . . . . . . . . . 173.1.2.1 Key Distribution based Schemes . . . . . . . . . . . . . . . . . . 173.1.2.2 Time Synchronization based Schemes . . . . . . . . . . . . . . . 183.2 Protocols with Non-repudiation of Origin . . . . . . . . . . . . . . . . . . . . . . . 233.2.1 Design of <strong>Multicast</strong> Signature Schemes . . . . . . . . . . . . . . . . . . . . 233.2.2 Signature Packet based Schemes . . . . . . . . . . . . . . . . . . . . . . . . 28i


Contents3.2.2.1 Protocols <strong>for</strong> Networks with Reliable Distribution of Data . . . . . 283.2.2.2 Erasure Tolerant <strong>Authentication</strong> Protocols . . . . . . . . . . . . . 293.2.3 Signature Dispersion based Schemes . . . . . . . . . . . . . . . . . . . . . . 343.2.3.1 Protocols Vulnerable to DoS Attacks . . . . . . . . . . . . . . . . 353.2.3.2 DoS Resistant <strong>Authentication</strong> Protocols . . . . . . . . . . . . . . 374. A Coding Approach to <strong>Multicast</strong> <strong>Authentication</strong> . . . . . . . . . . . . . . . . . . . . . . 434.1 Preliminaries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454.1.1 Network Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454.1.2 Code Construction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464.2 Overview of the Constructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484.3 LT Codes <strong>for</strong> <strong>Multicast</strong> Stream <strong>Authentication</strong> . . . . . . . . . . . . . . . . . . . . . 504.3.1 Our <strong>Authentication</strong> Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 504.3.2 Security and Recovery of the Scheme . . . . . . . . . . . . . . . . . . . . . 524.3.3 Other Families of Rateless Codes . . . . . . . . . . . . . . . . . . . . . . . 564.4 MDS Codes <strong>for</strong> <strong>Multicast</strong> Stream <strong>Authentication</strong> . . . . . . . . . . . . . . . . . . . 584.4.1 Our <strong>Authentication</strong> Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 594.4.2 Security and Recovery of the Scheme . . . . . . . . . . . . . . . . . . . . . 604.4.3 Coding Complexity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 644.5 Comparison of Schemes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 654.5.1 Signature Complexity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 654.5.2 Packet Overhead . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 674.5.3 Coding Efficiency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 704.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 705. Multiple Block Constructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 735.1 Overview of the Constructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 745.2 A Multiple Block <strong>Authentication</strong> Scheme . . . . . . . . . . . . . . . . . . . . . . . 785.2.1 Our <strong>Authentication</strong> Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 785.2.2 Security and Recovery of the Scheme . . . . . . . . . . . . . . . . . . . . . 795.2.3 Efficiency Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 865.3 A Multiple Block <strong>Authentication</strong> Scheme with Filtering . . . . . . . . . . . . . . . . 905.3.1 Our <strong>Authentication</strong> Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 905.3.2 Security and Recovery of the Scheme . . . . . . . . . . . . . . . . . . . . . 935.3.3 Comparison of <strong>Authentication</strong> Protocols . . . . . . . . . . . . . . . . . . . . 935.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95ii


Contents6. Reducing the Receiver <strong>Authentication</strong> Time . . . . . . . . . . . . . . . . . . . . . . . . 976.1 Overview of the Construction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 986.2 An Hybrid Construction <strong>for</strong> Stream <strong>Authentication</strong> . . . . . . . . . . . . . . . . . . 996.2.1 Our <strong>Authentication</strong> Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 996.2.2 Security and Recovery Analysis . . . . . . . . . . . . . . . . . . . . . . . . 1016.2.3 Efficiency Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1026.3 Trapdoor Hash Functions <strong>for</strong> Stream <strong>Authentication</strong> . . . . . . . . . . . . . . . . . . 1046.3.1 Our <strong>Authentication</strong> Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 1046.3.2 Security and Recovery Analysis . . . . . . . . . . . . . . . . . . . . . . . . 1056.3.3 Trapdoor Hash Function versus Digital Signature . . . . . . . . . . . . . . . 1066.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1087. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111Appendix 115A. Security Proofs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117A.1 MDS Code-based <strong>Authentication</strong> Scheme . . . . . . . . . . . . . . . . . . . . . . . 117A.2 Multiple Block <strong>Authentication</strong> Scheme with Filtering . . . . . . . . . . . . . . . . . 120A.3 Hybrid Stream <strong>Authentication</strong> Scheme . . . . . . . . . . . . . . . . . . . . . . . . . 124B. Pad Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127B.1 LT Code-based <strong>Authentication</strong> Scheme . . . . . . . . . . . . . . . . . . . . . . . . 127B.2 MDS Code-based <strong>Authentication</strong> Scheme . . . . . . . . . . . . . . . . . . . . . . . 128B.3 Multiple Block <strong>Authentication</strong> Scheme . . . . . . . . . . . . . . . . . . . . . . . . . 129B.4 Multiple Block <strong>Authentication</strong> Scheme with Filtering . . . . . . . . . . . . . . . . . 130B.5 Hybrid <strong>Authentication</strong> Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130C. Asymptotic Behavior of the Ratio N n . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133D. Recovery Proof . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137List of Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151List of Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153List of Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155iii


ContentsIndex of Notations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157Index of Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159General Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161iv


Thesis Synopsis<strong>Multicast</strong> communication enables the distribution of digital content from a single source to a largeaudience via a public channel such as the Internet. Broadcasting has applications in sensor networks,pay-TV, software updates and military defense systems to name a few. As these applications willdistribute private or sensitive in<strong>for</strong>mation, multicast protocols must provide data origin authenticationas well as data confidentiality. In this thesis, we focus our investigations on ensuring authenticationof the data source.Large-scale broadcasts normally do not repeat lost contents since the loss of any piece of datacould generate a prohibitive number of redistribution requests at the sender. In addition, the communicationchannel can be under the control of adversaries per<strong>for</strong>ming malicious actions on the datastream. Thus, the security of authentication protocols relies on two aspects: the opponents’ computationalpowers and the network properties. Cryptographic protocols without a security proof cannotbe considered as secure in practice as many constructions originally thought secure were successfullybroken. Several unconditionally secure schemes were designed in [15, 41, 132]. Un<strong>for</strong>tunately theiroptimal security is at the cost of a large storage requirement or a one-time use which makes theseconstructions unsuitable <strong>for</strong> practical applications. In this work, we assume that the adversaries havepolynomially bounded computational powers.The purpose of this thesis is to design provable secure protocols providing non-repudiation ofthe origin of a data stream over an unsecured communication channel. We will emphasize that ourconstructions provide practical solutions to the stream authentication problem, i.e. the requirementsof provable security are compatible with the settings of broadcasting.v


Statement of CandidateThis thesis is submitted in fulfillment of the requirements of the degree of Doctor of Philosophy atMacquarie University and has not been submitted <strong>for</strong> a higher degree to any other university or institution.This thesis represents my original work and contributions. I certify that to the best of myknowledge, all source and assistance received in the preparation of this thesis have been acknowledged.<strong>Christophe</strong> <strong>Tartary</strong>vii


AcknowledgmentsMy first and <strong>for</strong>emost acknowledgment is dedicated to my supervisor Huaxiong Wang. Our collaborationhas been a tremendous time of my life. His teachings and care have been priceless to me andI am <strong>for</strong>ever indebted to him. I would like to thank my associate supervisor, Josef Pieprzyk, <strong>for</strong> hisguidance, advice and fruitful discussions during my PhD studies. I would not have been able to obtainsuch outcomes without the help <strong>for</strong> these two dedicated researchers.It has been a pleasure to work within the Centre <strong>for</strong> Advanced Computing, Algorithm and Cryptography.In particular, I am thankful to Krystian Matusiewicz <strong>for</strong> our conversations and his friendship.I would also like to thank Scott Contini and Ron Steinfeld <strong>for</strong> valuable discussions on hashfunctions.I would like to acknowledge Louella Almeida, Agnieszka Baginska, Melina Chan and MichelleKang <strong>for</strong> their help related to administrative matter throughout these three and a half years at MacquarieUniversity. I am also grateful to the team of the Computer Technical Services who providedme with assistance a countless number of times on computer related issues.I would also like to thank the School of Physical and Mathematical Sciences at Nanyang TechnologicalUniversity which welcomed me <strong>for</strong> two months in Singapore during my candidature atMacquarie University.My most deeply thanks go to my parents <strong>for</strong> their encouragement and support during all theseyears of studies.North Ryde, AustraliaOctober 2007<strong>Christophe</strong> <strong>Tartary</strong>My research was supported by Macquarie University via an international Macquarie Universityix


AcknowledgmentsResearch Scholarship as well as the Australian Research Council under ARC Discovery ProjectsDP0344444, DP0558773, DP0665035 and DP0663452.x


Publications related to this ThesisWe present the published papers related to this dissertation as well as their location within this thesis.Chapter 4C. <strong>Tartary</strong> and H. Wang. Rateless Codes <strong>for</strong> the <strong>Multicast</strong> Stream <strong>Authentication</strong>Problem. Proceedings of the 1st International Workshop on Security (IWSEC 2006).Lecture Notes in Computer Science, vol. 4266, pp 136 - 151. Springer - Verlag.C. <strong>Tartary</strong> and H. Wang. Achieving <strong>Multicast</strong> Stream <strong>Authentication</strong> using MDSCodes. Proceedings of the 5th International Conference on Cryptology and NetworkSecurity (CANS 2006). Lecture Notes in Computer Science, vol. 4301, pp 108 -Chapter 5125. Springer - Verlag.C. <strong>Tartary</strong> and H. Wang. Efficient <strong>Multicast</strong> Stream <strong>Authentication</strong> <strong>for</strong> the FullyAdversarial Network. Proceedings of the 6th International Workshop on In<strong>for</strong>mationSecurity Applications (WISA 2005). Lecture Notes in Computer Science, vol. 3786,pp 108 - 125. Springer - Verlag, 2006.C. <strong>Tartary</strong> and H. Wang. Combining Prediction Hashing and MDS Codes <strong>for</strong> Efficient<strong>Multicast</strong> Stream <strong>Authentication</strong>. Proceedings of the 12th Australasian Conferenceon In<strong>for</strong>mation Security and Privacy (ACISP 2007). Lecture Notes in ComputerChapter 6Science, vol. 4586, pp 293 - 307. Springer - Verlag.C. <strong>Tartary</strong> and H. Wang. Efficient <strong>Multicast</strong> Stream <strong>Authentication</strong> <strong>for</strong> the FullyAdversarial Network. International Journal of Security and Network (Special Issueon Cryptography in Networks), vol. 2, nos. 3/4, pp 175 - 191, 2007. Inderscience.C. <strong>Tartary</strong>, H. Wang and J. Pieprzyk. An Hybrid Approach <strong>for</strong> Efficient <strong>Multicast</strong>Stream <strong>Authentication</strong> over Unsecured Channels. Proceedings of the 1st InternationalConference on Provable Security (ProvSec 2007). Lecture Notes in ComputerScience. Springer - Verlag, to appear.xi


Note to the ReaderAs noted by Perrig and Tygar in [118], broadcast communication is a generic term denoting the transmissionof in<strong>for</strong>mation to multiple receivers. An example of such a process is the Internet Protocol(IP) multicast. Despite the term multicast is to be used when the communication channel is the Internet,it is, however, employed in the literature as a synonymous of the word broadcast. The reader cancheck this fact by looking at the scope of applications of papers using the term multicast as a part oftheir title referenced in the bibliography of this thesis <strong>for</strong> instance. In this thesis, we will commit thesame abuse of vocabulary as we will use the word multicast as a synonymous to broadcast.xiii


1IntroductionWith the expansion of communication networks, broadcasting has become a major way of distributingdigital content to large audiences. <strong>Multicast</strong> have found many applications ranging from video conferences,pay-TV, digital radio, software updates, GPS signals, stock quotes to military defense systems.As broadcast protocols diffuse private or sensitive in<strong>for</strong>mation, they must provide both confidentialityof content and authentication of the data stream origin. In this work, we restrict our investigationsto data origin authentication only (the confidentiality of in<strong>for</strong>mation is beyond the scope of this work).Unicast protocols were developed <strong>for</strong> data transmission between two parties. Un<strong>for</strong>tunately, mostof these protocols do not scale well <strong>for</strong> the multi-party case. A good example that illustrates thispoint is the Guy Fawkes protocol [6] which provides data authentication via permanent interactionsbetween the sender and the receiver. Indeed, broadcasting exhibits the following challenges.• Receiver Heterogeneity: If the communication group is large, it is likely that there are discrepanciesbetween the computational power and the storage capacity of the different receivers.Indeed, some users may run high power workstations while others will possess limited resources.1


1. INTRODUCTION• Group Dynamics: Applications like pay-TV show that members can join and leave the communicationgroup at any time. Thus, any multicast authentication scheme has to take the dynamicsof the group into account. In particular, it must allow members to authenticate data evenif they joined the communication group after the beginning of streaming.• Network Bandwidth Availability: A communication medium such as the Internet illustrateshow heterogeneous the bandwidth can be. Some users can have a high speed connection whileother members of the communication group download in<strong>for</strong>mation via a low bandwidth one.• Data Transmission Reliability: Most multicast protocols provide a best ef<strong>for</strong>t delivery of dataonly. An example is the User Datagram Protocol (UDP) over the Internet. Indeed, the sizeof the communication group prevents lost content from being redistributed since the loss of asingle piece of data can cause a flood of retransmission requests at the sender. In addition, anapplication such as satellite pay-TV shows that a feedback channel <strong>for</strong> retransmission requestsdoes not always exist.• Adversarial Activity: The larger the network is, the higher the probability a node is corruptedgets. Over the Internet, it is likely to have opponents trying to per<strong>for</strong>m Denial of Service(DoS) attacks by injecting bogus data packets to exhaust computational or storage capacitiesof the receivers. In addition, some network nodes between the sender and the receivers maymalfunction and thus fail to accurately retransmit in<strong>for</strong>mation.• Live Streaming: <strong>Multicast</strong> is widely used to distribute real-time content. There<strong>for</strong>e, the senderdoes not have any prior knowledge of the data stream to be processed. In addition, applicationslike stock quotes or GPS signals require the data to be authenticated at the receiver within ashort period of time upon reception.In order to meet the common requirements, one expects an authentication protocol to have the followingproperties:• low computation overhead <strong>for</strong> the generation and verification of the authentication in<strong>for</strong>mation,• low communication overhead,• resistance against erasures of in<strong>for</strong>mation and injection of bogus pieces of data,• scalability to a large number of receivers and flexibility <strong>for</strong> group management allowing joiningand leaving by members of the group,• fast processing at both ends of the communication channel of the real-time data stream.Due to the diversity of communication networks, finding a generic mathematical model <strong>for</strong> unsecuredchannels is not simple. There<strong>for</strong>e, most schemes found in the literature are either heuristically secure2


(i.e. their security and efficiency are claimed from implementation results) or secure under a particularadversarial behavior model such as bursty erasures <strong>for</strong> instance (see Chapter 3). It is clear thatthese approaches only offer partial solutions to the stream authentication problem. The first mathematicalmodel that was addressing the problem of broadcast authentication <strong>for</strong> its general aspect wasdeveloped in 2003 by A. Lysyanskaya, R. Tamassia and N. Triandopoulos in [87]. As said above, twoimportant parameters are to be taken into account <strong>for</strong> such authentication schemes: computationalcomplexity and packet (communication) overhead.Authenticity and non-repudiation of the sender are provided via digital signatures whose verificationalgorithm can be time consuming. Lysyanskaya et al. split the data stream into blocks of packetsand process them independently from each other. They run an algorithm proposed by V. Guruswamiand M. Sudan in [62], which outputs a list of candidates <strong>for</strong> signature verification. In their paper,Lysyanskaya et al. only studied the asymptotic behavior of the size of this list. We will prove, inChapter 4, a non-asymptotic bound on this size, which happens to be small. This means that thisalgorithm provides an efficient way to deal with both DoS attacks and erasures over unsecured channels.In addition, the communication overhead required in this technique is amortized over the wholeblock of packets.A common drawback of all existing authentication schemes is that the lost content cannot berecovered (see Chapter 3). There<strong>for</strong>e, we propose two constructions to deal with this problem. Thefirst one is based on rateless codes and allows probabilistic recovery of the data stream. The secondconstruction relies on Maximum Distance Separable (MDS) codes and guarantees total recovery ofthe stream. The main difference between these two constructions relies on the correcting code applied.Despite rateless codes provide probabilistic recovery only, their encoding/decoding algorithmsrequire XORs of packets only and thus are an appropriate choice <strong>for</strong> receivers with limited computationalabilities. On the other hand, the underlying field structure of MDS codes has to be updatedevery time the adversary model changes requiring the appropriate computing resources (see Chapter4). A study of the complexity of encoding/decoding algorithms <strong>for</strong> existing rateless and MDScodes will lead us to choices minimizing the computational cost <strong>for</strong> each family of codes.We will see that, if the sender can buffer several consecutive blocks of the data stream, we cangeneralize Lysyanskaya et al.’s construction so that a unique list of candidates <strong>for</strong> signature verificationneeds to be built <strong>for</strong> the whole set of blocks reducing significantly the time spent by the receiversto authenticate packets. When combining this technique with hash chaining, we will demonstrate thatthe elements can be filtered efficiently upon reception. That is to say that only genuine packets arebuffered, which significantly reduces the time needed to recover the whole data stream with respect3


1. INTRODUCTIONto existing protocols while having smaller memory requirements.Finally, we will show that combining Lysyankaya et al.’s approach along with a suitable hash treeenables us to reduce both the packet overhead and the authentication delay at the receiver. The runningtime can be improved even further using a trapdoor hash function instead of a digital signatureto provide non-repudiation of the sender.To summarize the contributions of this thesis, we present provably secure protocols allowing therecovery of the whole data stream with small packet overhead <strong>for</strong> the multicast stream authenticationproblem over unsecured channels. The use of the Lysyanskaya et al.’s adversary model makes thosesolutions generic, i.e. these constructions are not limited by any particular adversary behavior. To thebest of our knowledge, there does not exist any other construction solving this general instance withthe three previous properties (provable security, recovery of data, small communication overhead) ata time. In addition, we provide computational bounds <strong>for</strong> the different constructions which can beused to approximate the running time and the memory requirements of these protocols. Finally, westudy different coding techniques in order to provide solutions tailored according to the computationalpower of the receivers via the tradeoff rateless/MDS codes, <strong>for</strong> instance.This thesis is organized as follows:• In Chapter 2, we present the mathematical tools that we will employ to provide security of ourschemes and evaluate their efficiency.• In Chapter 3, we review the existing protocols ensuring data origin authentication <strong>for</strong> multicast.• In Chapter 4, we present two constructions based on coding theory that enable the recovery ofthe data stream over unsecured channels. We also undertake an analysis of the size of the listoutput given by the Guruswami and Sudan’s algorithm and deduce a non-asymptotic bound onthe number of signature verifications that need to be per<strong>for</strong>med per block at the receiver.• In Chapter 5, we show how to save memory and reduce computation overhead even furtherwhen the sender can buffer several consecutive blocks of the stream.• In Chapter 6, we present an hybrid construction based on hash trees as well as on the Guruswamiand Sudan’s algorithm in order to simultaneously reduce both the packet and therunning time overheads at the receiver. We will also see that the use of a trapdoor hash functioncan speed-up the running time at the receiver even further.• In Chapter 7, we will summarize the contribution of this thesis to the theory of multicast streamauthentication and present future research directions in this field.4


2Mathematical BackgroundIn this chapter, we review the tools that we use to ensure the security and to analyze the efficiency ofour constructions. We also give an overview of the Guruswami-Sudan algorithm [62] that we applyas an important subroutine in our constructions.2.1 Cryptographic PrimitivesAs said in Chapter 1, this thesis presents provably secure multicast protocols that provide the nonrepudiationof the source of streaming. In this section, we introduce the necessary cryptographicprimitives. We first introduce the following definition:Definition 2.1 ([55]) A function f : N → R + is said to be negligible if <strong>for</strong> every positive polynomialp(·) there exists an integer N such that <strong>for</strong> all n > N, we have:f(n) < 1p(n)The non-repudiation of the sender will be provided using digital signatures while the integrity ofthe data stream will be checked by applying hash functions.5


2. MATHEMATICAL BACKGROUND2.1.1 Digital SignaturesDefinition 2.2 ([142]) A signature scheme (or digital signature) is a five-tuple of sets (P,A,K,S,V)where the following conditions are satisfied:1. P is a finite set of possible messages2. A is a finite set of possible signatures3. K, the keyspace, is a finite set of possible keys4. For each (SK,PK) ∈ K, there is a signing algorithm Sign SK ∈ S and a corresponding verificationalgorithm Verify PK ∈ V. Each Sign SK : P → A and Verify PK : P × A →{TRUE, FALSE} are functions such that the following equation is satisfied <strong>for</strong> every messagex ∈ P and <strong>for</strong> every signature y ∈ A:⎧⎨ TRUEVerify PK (x,y) =⎩ FALSEif y = Sign SK (x)if y ≠ Sign SK (x)A pair (x,y) with x ∈ P and y ∈ A is called a signed message.Notice that <strong>for</strong> every (SK,PK) ∈ K, the functions Sign SK and Verify PK should be polynomial-timefunctions. Verify PK will be a public function while Sign SK will remain private. For concision in theremaining of this thesis, we denote a signature scheme as a triple (KeyGen, Sign SK , Verify PK ) whereKeyGen is the key generation algorithm taking as input the security parameter S representing the bitlength of the signature and outputting a pair of elements (SK, PK) such that SK is the signer secretkey while PK is the public key to be used by the verifier. We now present the security property werequire <strong>for</strong> the digital signatures.Definition 2.3 ([142]) A digital signature (KeyGen, Sign SK , Verify PK ) is said to be secure againstchosen message attack if no Probabilistic Polynomial-Time (PPT) opponent O can win with nonnegligibleprobability (as a function of the signature length S) the following game:1. O is given an oracle simulating Sign SK (but O does not have access to SK).2. O chooses a polynomial number of messages m 1 ,...,m ξ (ξ = Poly(S)) and queries the signingoracle to obtain their signature. The messages are constructed adaptively, i.e. O choosesm i+1 after receiving the signature on m i .3. O constructs a pair (m,σ) such that: ∀i ∈ {1,...,ξ}m ≠ m i .The opponent O wins if: Verify PK (m,σ) = TRUE.6


2.1. CRYPTOGRAPHIC PRIMITIVESIn most situations, security against known message attacks (i.e. O does not choose the messagesto be signed by the oracle) is sufficient as O is only a channel eavesdropper. Nevertheless in somecases, O has the ability to choose those messages. Consider the case of two TV stations emittingprograms through the same satellite TV provider. Each station may try to use its own data to attackits rival. Thus, in our constructions, we will assume that our digital signature is secure accordingto Definition 2.3. In our implementations, we will mainly use the signature introduced by Rivest,Shamir and Adelman (RSA) [128]. Note that the original version of RSA is not secure against knownmessage attacks as O can always output (0,0) as a successful message/signature <strong>for</strong>gery. In [146],several methods are proposed to overcome this drawback. As this issue is beyond the scope of thisthesis, we assume that the RSA signature schemes we employ follow these modifications and thus aresecure under the opponent model from Definition 2.3.2.1.2 Hash FunctionsHash functions can be classified into two groups depending on whether they require a key or not.Note that a keyed hash function whose purpose is message authentication is called a Message <strong>Authentication</strong>Code (MAC) [90]. Unless specified, we work with unkeyed hash functions.Definition 2.4 ([90]) A hash function is a function h which has, as a minimum, the following twoproperties:1. Compression: h maps an input m of arbitrary finite bit length, to an output h(m) of fixed bitlength H.2. Ease of computation: Given h and an input m, h(m) can be computed in polynomial-time as afunction of H.The output h(m) is called hash or digest of the message m.We now present some properties related to the study of hash functions.Definition 2.5 ([90]) A hash function h as defined above is said to be:1. second preimage resistant if no PPT opponent O who is given a message m 1 can construct adifferent message m 2 such that h(m 1 ) = h(m 2 ) with non-negligible probability as a functionof H.2. collision resistant if no PPT opponent O can construct two different messages m 1 and m 2 suchthat h(m 1 ) = h(m 2 ) with non-negligible probability as a function of H.Note that if a hash function is collision resistant then it is also second preimage resistant. Inour implementations, we will mainly use functions from the Secure Hash Algorithm (SHA) and the7


2. MATHEMATICAL BACKGROUNDRACE Integrity Primitives Evaluation Message Digest (RIPEMD) families called SHA-256 [98] andRIPEMD-160 [46] respectively. Note that most hash functions used in commercial applications areheuristically collision resistant. As a consequence, their security is not guaranteed. Recently, thecollision resistance of several hash functions has been broken [37, 148, 149, 150, 151]. Notice thatthe security of our authentication schemes will be based on the collision resistance property. We donot require the function to be one-way as we will not use it as a generator of commitment values. Asurvey of hash function definitions can be found in the recent article by Contini et al.[31]. We nowpresent a class of keyed hash functions called trapdoor hash families.Definition 2.6 ([136]) A trapdoor hash family consist of a pair (KeyGen,H) such that:1. KeyGen is a PPT algorithm key generator that, on input 1 H , generates a pair (PK,SK) the sizeof which are polynomial in H.2. H is a family of randomized hash functions. Each element of H is associated with a hash keyPK, and is applied to a message from a space M PK and a random element from a finite spaceR PK . The output of the function H PK (·, ·) does not depend on SK.A trapdoor hash family has the following properties:1. Ease of computation: Given PK and a pair (m,r) ∈ M × R, the value H PK (m,r) is computablein polynomial time as a function of the output bit length H.2. Collision resistant: There is no probabilistic PPT algorithm that, on input PK, outputs, witha non-negligible probability, two pairs (m 1 ,r 1 ),(m 2 ,r 2 ) of elements of M × R such that:m 1 ≠ m 2 and H PK (m 1 ,r 1 ) = H PK (m 2 ,r 2 ).3. Trapdoor collisions: There exists a probabilistic PPT algorithm that, given a pair (PK,SK), apair (m 1 ,r 1 ) ∈ M × R and an additional message m 2 ∈ M, outputs a value r 2 ∈ R suchthat (a) H PK (m 1 ,r 1 ) = H PK (m 2 ,r 2 ) and (b) if r 1 is uni<strong>for</strong>mly distributed over R then thedistribution of r 2 is computationally indistinguishable from the uni<strong>for</strong>m distribution over R.Every element of a trapdoor hash family is called a Trapdoor Hash Function (THF).As noticed in [119], a collision resistant hash function must have the one-wayness property asdefined below where {0,1} ∗ denotes the set of all binary strings.Definition 2.7 ([55]) A function f : {0,1} ∗ → {0,1} ∗ is called (strongly) one-way if the followingtwo conditions hold:1. Ease of computation: There exists a (deterministic) polynomial-time algorithm A such that oninput x it returns f(x) (i.e. A(x) = f(x)).8


2.1. CRYPTOGRAPHIC PRIMITIVES2. Hard to invert: For every PPT algorithm A ′ , every positive polynomial p(·) and all sufficientlylarge n’s we have:Prob[A ′ (f(U n ),1 n ) ∈ f −1 (f(U n ))] < 1p(n)where U n denotes a random variable uni<strong>for</strong>mly distributed over {0,1} n .We now present another family of keyed hash functions called universal one-way hash functionswhich have been introduced by Naor and Yung in [96].Let {n 0,k } k∈Nand {n 1,k } k∈Nbetwo increasing sequences of integers. We assume that there exists a polynomial Q(X) such that:∀k ∈ N n 0,k ≤ n 1,k ≤ Q(n 0,k ). Let H k be a set of functions from {0,1} n 1,kto {0,1} n 0,k. Wedefine the family F as ⋃ kH k .Definition 2.8 ([96]) The family F defined above is a family of Universal One-Way Hash Functions(UOWHF) if <strong>for</strong> all positive polynomials p(·) and <strong>for</strong> all PPT algorithms A the following holds <strong>for</strong>sufficiently large k:1. Ease of sampling: There exists a polynomial time algorithm G such that G on input k generatesuni<strong>for</strong>mly at random a description of h ∈ H k .2. Ease of computation: For each h from H k , there is a description of h of length polynomial inn 1,k such that given h’s description and x, h(x) is computable in polynomial time.3. Collision resistant <strong>for</strong> a given input: If x ∈ {0,1} n 1,kis A’s initial value thenProb(A(h,x) = y,h(x) = h(y),y ≠ x)


2. MATHEMATICAL BACKGROUND2.1.2.2 Merkle Hash TreesIn this thesis, we will see graphs called Merkle hash trees [91]. These are binary trees based on hashfunctions. They take as input n leaves and their internal nodes are defined as digests of the concatenationof their two children computed via a collision resistant hash function h. By definition the treeroot as depth 0 while each leaf has depth ⌈log 2 n⌉. The depth of the tree is defined as the depth ofits leaves, i.e. ⌈log 2 n⌉. Without loss of generality (w.l.o.g.), one can assume that n is a power of 2.Otherwise, it is sufficient to add some dummy leaves so that the total number of elements is a powerof 2. Figure 2.1 describes such a tree when n = 8.h 18 := h(h 14 ‖h 58 )h 14 := h(h 12 ‖h 34 )h 58 := h(h 56 ‖h 78 )h 12 := h(L 1 ‖L 2 ) h 34 := h(L 3 ‖L 4 )h 56 := h(L 5 ‖L 6 ) h 78 := h(L 7 ‖L 8 )L 1 L 2 L 3 L 4L 5L 6 L 7 L 8Fig. 2.1: A Merkle hash tree having 8 leavesWe define path(i) the concatenation of the ⌈log 2 n⌉ hashes needed to reconstruct the path fromleaf L i to the root of the tree. In the remaining of this thesis, we denote x‖y the concatenation of thestrings x and y. On Figure 2.1, we have:path(2) := L 1 ‖h 34 ‖h 58When using path(2) and L 2 , one can recover the tree root h 18 as h 18 = h(h(h(L 1 ‖L 2 )‖h 34 )‖h 58 ).2.1.3 Pseudorandom FunctionsHere, we briefly discuss the notion of PseudoRandom Function (PRF). They are used to simulatethe uni<strong>for</strong>m distribution and thus have applications in many cryptographic constructions. We mainlyfocus on length-preserving functions, i.e. functions whose output length is equal to the input’s. Amore general definition as well as construction techniques can be found in [55].10


2.2. COMPLEXITY THEORYDefinition 2.9 ([55]) Let l : N → N (e.g. l(n) = n). An l-bit function ensemble is a sequenceF := {F n } n ∈ Nof random variables such that the random variable F n assumes values in the set offunctions mapping l(n)-bit-long strings to l(n)-bit-long strings. The uni<strong>for</strong>m l-bit function ensemble,denoted H := {H n } n ∈ N, has H n uni<strong>for</strong>mly distributed over the set of all functions mapping l(n)-bit-long strings to l(n)-bit-long-strings.Definition 2.10 ([55]) An l-bit function ensemble F := {F n } n ∈ Nis called pseudorandom if <strong>for</strong>every PPT oracle machine M, every positive polynomial p(·) and all sufficiently large n’s we have:|Prob(M Fn (1 n ) = 1) − Prob(M Hn (1 n ) = 1)| < 1p(n)where H = {H n } n ∈ Nis the uni<strong>for</strong>m l-bit function ensemble.As noticed in [146], pseudorandomness is a stronger requirement than one-wayness. As <strong>for</strong> hashfunctions presented in Section 2.1.2, we require that PRFs are efficiently computable <strong>for</strong> practicalapplications.Definition 2.11 ([55]) An l-bit function ensemble F := {F n } n ∈ Nis called efficiently computableif the following two conditions hold:1. Efficient indexing: There exists a PPT algorithm I and a mapping from strings to functions, φ,such that φ(I(1 n )) and F n are identically distributed.We denote by f i the function assigned to the string i (i.e. f i := φ(i)).2. Efficient evaluation: There exists a PPT algorithm V such that <strong>for</strong> every i in the range of I(1 n )and x ∈ {0,1} l(n) we have: V (i,x) = f i (x).As noticed in [20], one should be aware that hash functions are sometimes used as PRFs even ifthis property is not their primary goal.2.2 Complexity TheoryIn this work, we design provably secure protocols <strong>for</strong> stream authentication. In order to be suitable<strong>for</strong> multicast, our schemes have to be compatible with the requirements of broadcasting as presentedin Chapter 1. As a consequence, we need to quantify the cost of our constructions. In this section,we introduce the notations to be used to evaluate the cost of our algorithms. In the remaining of thissection we assume that we have two functions t and f from N to R + .11


2. MATHEMATICAL BACKGROUNDDefinition 2.12 ([17]) We denote by O(f(n)) the set of all functions t such that:∃c ≥ 0 ∃n 0 ∈ N : ∀n ≥ n 0t(n) ≤ cf(n)Each function t(n) ∈ O(f(n)) is said to be in order of f(n).The previous definition is related to an upper bound on the function t. Similarly, we have:Definition 2.13 ([17]) We denote by Ω(f(n)) the set of all functions t such that:∃d ≥ 0 ∃n 0 ∈ N : ∀n ≥ n 0t(n) ≥ df(n)As noticed in [17], we have the duality rule: t(n) ∈ Ω(f(n)) if and only if f(n) ∈ O(t(n)).Finally we present the following complexity class.Definition 2.14 ([17]) We denote by Θ(f(n)) the set of all functions t such that:∃c ≥ 0 ∃d ≥ 0 ∃n 0 ∈ N / ∀n ≥ n 0df(n) ≤ t(n) ≤ cf(n)In other words:Θ(f(n)) := O(f(n)) ∩ Ω(f(n))Each function t(n) ∈ Θ(f(n)) is said to be in exact order of f(n).Proposition 2.1 We have the following properties:1. The three classes O(f(n)),Ω(f(n)) and Θ(f(n)) are stable under addition as well as multiplicationby a positive constant.t(n)2. If limn→+∞ f(n) ∈ R+∗ then t(n) ∈ Θ(f(n)).t(n)3. If lim = 0 then t(n) ∈ O(f(n)) but t(n) /∈ Ω(f(n)).n→+∞ f(n)t(n)4. If lim = +∞ then t(n) ∈ Ω(f(n)) but t(n) /∈ O(f(n)).n→+∞ f(n)2.3 Polynomial Reconstruction ProblemIn this section, we present a mathematical problem which will be related to our network opponentmodel as well as an algorithm to solve it. Note that this algorithm was initially developed in thecontext of list decoding <strong>for</strong> error correcting codes. We refer the reader to [59] <strong>for</strong> details on this area.12


2.3. POLYNOMIAL RECONSTRUCTION PROBLEM2.3.1 Algebraic StructuresWe need to define the different algebraic structures to be used in this thesis.Definition 2.15 ([130]) A non-empty set G, together with a binary operation + on G (that is, + is amap from G × G to G), is said to be a group if the following properties are satisfied:1. (Associativity) ∀x,y,z ∈ G (x + y) + z = x + (y + z)2. (Identity) ∃ǫ ∈ G/∀x ∈ G ǫ + x = x + ǫ = x3. (Inverse) ∀x ∈ G ∃y ∈ G/x + y = y + x = ǫIn addition, if we have (∀x,y ∈ Gx + y = y + x) then G is said to be abelian.Definition 2.16 ([130]) A non-empty set R, together with two binary operations + (addition) and ×(multiplication) on R, is said to be a ring if the following properties are satisfied:1. R is an abelian group under the operation +.2. (Associativity) ∀x,y,z ∈ R (x × y) × z = x × (y × z)3. (Distributivity) ∀x,y,z ∈ R (x+y) ×z = x ×z +y ×z and z ×(x+y) = z ×x+z ×yDefinition 2.17 ([130]) Let R be a ring. Denote ǫ the identity element of +.1. R is called ring with identity if: ∃η ∈ R / ∀x ∈ R x × η = η × x = x2. R is called a field if η ≠ ǫ and the nonzero elements of R <strong>for</strong>m an abelian group undermultiplication ×.Definition 2.18 Let S be a set. We denote S[X] the set of all polynomials of unknown X havingcoefficients in S:S[X] :=i∈N{s ⋃ 0 + s 1 X + · · · + s i X i /s 0 ,...,s i ∈ S}Proposition 2.2 ([79]) If R is a ring then R[X] is also a ring.2.3.2 Reconstructing PolynomialsPolynomial Reconstruction Problem (PRP)INPUT: Integers k,t and n points {(x i ,y i )} i∈{1,...,n}where x i ,y i ∈ F <strong>for</strong> a field F .OUTPUT: All univariate polynomials P(X) ∈ F[X] of degree at most k such that y i = P(x i ) <strong>for</strong> atleast t values of i ∈ {1,...,n}.In 1999, Guruswami and Sudan developed an algorithm called Poly-Reconstruct to solve the PRP[62]. This algorithm exhibits the following characteristics:13


2. MATHEMATICAL BACKGROUNDTheorem 2.1 ([58]) The algorithm Poly-Reconstruct can solve the PRP in polynomial-time in n <strong>for</strong>any field F provided: t > √ k n. In addition, the size of the output list is upper bounded by ⌊l/k⌋where:r := 1 +⌊l := r t − 1k n + √ ⌋k 2 n 2 + 4(t 2 − k n)2(t 2 − k n)Guruswami demonstrated that Poly-Reconstruct runs in time quadratic in n while the size of the list isat most quadratic in n (see Theorem 6.12 and Lemma 6.13 from [58]). Algorithms <strong>for</strong> implementingPoly-Reconstruct and improvements can be found in [94, 104].14


3A Taxonomy of <strong>Multicast</strong> <strong>Authentication</strong>SchemesIn this chapter, we per<strong>for</strong>m a state of the art review of constructions providing data source authentication.These protocols can be classified into two categories depending on whether they provide anon-repudiable proof of the stream origin or not.As said in Chapter 1, some applications <strong>for</strong> television or financial markets will diffuse a longstream of data. Thus, to be processed in real-time, the stream is divided into fixed size chunks calledpackets. These elements are generally gathered into fixed size sets called blocks which are processedindependently from each other. We call augmented packets the elements sent into the network. Theygenerally consist of the original data packets with some redundancy used to provide the authenticityof the element. We have the following channel models.Definition 3.1 ([90]) An unsecured channel is one from which parties other than those <strong>for</strong> which thein<strong>for</strong>mation is intended can reorder, delete, insert or read. A secure channel is one from which anopponent does not have the ability to reorder, delete, insert or read.15


3. A TAXONOMY OF MULTICAST AUTHENTICATION SCHEMESGiven the characteristics of multicast discussed in Chapter 1, protocols <strong>for</strong> authentication of dataorigin have to be secure <strong>for</strong> the unsecured communication channel model. Note that we do not assumethat the receivers are honest. That is, there may exist a group of colluding receivers working together- possibly in collaboration with an external eavesdropper - in order to fool other participants.3.1 Protocols without Non-repudiation of Origin3.1.1 Unconditionally Secure ProtocolsUnconditional security is important when the opponent’s computational abilities are unknown as itis the case in military applications since armed <strong>for</strong>ces keep their capacities secret. Studying suchconstructions was suggested by Simmons [138]. In [41], Desmedt et al. introduced the notion of unconditionallysecure MultiReceiver <strong>Authentication</strong> Code (MRAC). We need the following definition:Definition 3.2 ([119]) An impersonation attack occurs when an opponent O, knowing the authenticationalgorithm, wants to construct a genuine authentication tag in order to have it accepted asvalid by the receiver. A substitution attack occurs when an opponent O, knowing the authenticationalgorithm, intercepts an original authentication tag and replaces it by a genuine element in order tohave it accepted as valid by the receiver.The level of security of MRACs is characterized by the number of colluding receivers.Definition 3.3 ([41]) We say that an authentication scheme is a t out of l MRAC when any t out of lreceivers can successfully launch neither a substitution attack nor an impersonation one against evena single receiver.Desmedt et al.’s approach is similar to the Shamir secret sharing scheme [135] as their constructionapplies polynomial interpolation to achieve security as well. For each data packet P , the senderchooses two polynomials Q 0 (X) and Q 1 (X) of degree t as well as a prime number p at least as largeas the number of possible data packets. If we denote P the bit size of a data packet then the previousrequirement means: p ≥ 2 P . The transmitter distributes the couple (Q 0 (i),Q 1 (i)) to the receiveri (where i ∈ {1,...,l}) over a secure channel and builds the authenticator polynomial A P (X) as:A P (X) := Q 0 (X)+P ·Q 1 (X), which is broadcast to all receivers. Upon reception of P , the receiveri checks its authenticity by testing if: A P (i) = Q 0 (i) + P · Q 1 (i).In this construction, each receiver needs to store 2 ⌈log 2 p⌉ bits and the sender 2(t + 1) ⌈log 2 p⌉bits. Each packet P has an authentication tag of size (t + 1) ⌈log 2 p⌉ bits which corresponds to thebroadcast of A p (X). In [76, 102], Obana and Kurusawa determined lower bounds on the probabilitiesof successful impersonation and substitution attacks as well as the sizes of the keys <strong>for</strong> t out of l16


3.1. PROTOCOLS WITHOUT NON-REPUDIATION OF ORIGINMRACs and showed that Desmedt et al.’s scheme reaches them. Nevertheless, this construction canbe used one time only as new polynomials Q 0 (X) and Q 1 (X) have to be computed (and new sharesto be distributed) <strong>for</strong> each data packet P which limits the practicality of this solution <strong>for</strong> streaming.In [132, 133], Safavi-Naini and Wang generalized the previous construction so that the same polynomialcan be used to authenticate several data packets. The first of their two schemes is based on thenotion of Cover-Free Family (CFF) [143]. It requires the maximum number of colluders t to be smallin comparison to the group size l which is unlikely to happen <strong>for</strong> a channel such as the Internet, <strong>for</strong>instance. Notice that Fujii et al. designed a protocol which is a special case of the Safavi-Naini andWang approach in [52]. The Safavi-Naini and Wang second scheme is a generalization of Desmedt etal.’s algorithm to the case of multiple senders and relies on symmetric polynomials [34].The previous constructions suffer from the following two problems. Firstly, the size of the authenticationtag is linear in the number of colluders which may become prohibitive <strong>for</strong> some bandwidthlimited users. Secondly, their security relies on the existence of a secure channel between the senderand each receiver. It is clear that this requirement limits the applications of those constructions asmost large scale broadcasts, as satellite television <strong>for</strong> instance, do not provide such channels. Toovercome this problem, Jakimoski developped erasure tolerant authentication codes (η-code) basedon covering designs [141] and Reed-Solomon (RS) codes [124] <strong>for</strong> lossy channels [66]. Neverthelesshis model is weaker than the unsecured channel model as his opponent is not allowed to inject datainto the network.3.1.2 Conditionally Secure ProtocolsA growing area <strong>for</strong> broadcasting is the domain of sensor networks. In this domain, achieving securityis more complex than <strong>for</strong> traditional computers as sensors have limited processing power, storageand energy. In particular, the arithmetics used <strong>for</strong> the verification algorithm of digital signatures isgenerally computationally too expensive to be per<strong>for</strong>med by such devices. As a consequence, dataorigin authentication is provided by symmetric key primitives such as MACs as they typically requireless computational power than digital signatures. On the other hand, those constructions cannot providenon-repudiation of the stream origin as the sender’s key is shared with the receivers. Additionalin<strong>for</strong>mation concerning the implementation of cryptographic primitives <strong>for</strong> wireless communicationcan be found in [139].3.1.2.1 Key Distribution based SchemesIn [19], Canetti et al. proposed to use multiple MACs to achieve authentication. In their construction,the sender chooses u distinct keys K 1 ,...,K u and distributes to each of the l receivers i a subset K i17


3. A TAXONOMY OF MULTICAST AUTHENTICATION SCHEMESof {K 1 ,...,K u }. For each data packet P , its corresponding augmented packet is:AP := P ‖MAC(K 1 ,P)‖ · · · ‖MAC(K u ,P)Upon reception of AP, each receiver i checks the consistency of the MACs related to his subset ofkeys K i and accepts P as genuine if all these MACs verifications are successful. It is clear that ifu = l and each receiver is given a unique MAC key (K i = {K i }), then the scheme provides secureauthentication. Nevertheless, this approach generates a prohibitive overhead as the number of MACsto be appended to each packet P is equal to the size of the communication group.Canetti et al. propose to use u < l keys. Contrary to [132, 133], where the number of keys to bedistributed to each receiver followed a deterministic process based on CFFs, Canetti et al. suggestedto give each participant i each key K j with probability 1t+1 . If the sender uses u = 4et ln 1/q keysthen the probability a group of t colluders can recover the subset K i of another group member is upperbounded by q.In order to decrease the packet overhead, Canetti et al. used one-bit output MACs [95] so thatthe overhead is reduced to u bits. They also provided an algorithm <strong>for</strong> removing a receiver from thecommunication group without weakening the security of the construction. Note that Canetti et al.’sscheme allows multiple group members to send data as [132, 133].The main drawback of this approach is that the number of keys as well as the packet overhead isexponential in the size t of the colluding group which is likely to limit the use of such a construction<strong>for</strong> channels such as the Internet, where the number of adversaries can be large and is a prioriunknown.3.1.2.2 Time Synchronization based SchemesIn [116], Perrig et al. designed the Timed Efficient Stream Loss-Tolerant <strong>Authentication</strong> (TESLA)protocol. Denote P 1 ,P 2 ,P 3 ,... the stream of packets to be sent into the network and F and F ′ twoPRFs. The function F ′ is used to generate MAC keys while F serves as a generator of commitmentvalues. For each packet P i , we generate its augmented packet AP i as follows:AP i := P i ‖F(K i+1 )‖K i−1 ‖ MAC(K ′ i,P i ‖F(K i+1 )‖K i−1 )where K ′ i := F ′ (K i ) with K i being a random number.For any i, the content of AP i is authenticated upon reception of AP i+1 in the following way. The18


3.1. PROTOCOLS WITHOUT NON-REPUDIATION OF ORIGINreceiver first verifies the consistency of K i disclosed in AP i+1 using the commitment value F(K i )from AP i−1 . Second, he uses F to recover K i ′ as K′ i = F ′ (K i ). Finally, he verifies the integrityof the MAC from AP i . If all verifications are successful, then P i is considered as authentic whileF(K i+1 ) is buffered in order to authenticate AP i+1 upon reception of AP i+2 . Figure 3.1 illustratesthis process.AP i−1AP iAP i+1P i−1F(K i )K i−2} {{ }D i−1P iF(K i+1 )K i−1} {{ }D iP i+1F(K i+2 )} {{ }K iD i+1MAC(K ′ i−1 ,D i−1)} {{ }authenticatedMAC(K i ′,D i)} {{ }authenticated afterreception of AP i+1Fig. 3.1: TESLA: original schemeMAC(K ′ i+1 ,D i+1)} {{ }not yet authenticatedThis simple scheme has two major drawbacks. First, if AP i+1 is sent into the network be<strong>for</strong>e AP ihas reached the receiver, then an opponent O eavesdropping the channel can impersonate the senderas he obtains the value K i used to compute the MAC in AP i . In addition, he can use this weaknessto set up a parallel stream, undetectable by the receiver, substituting the commitment F(K i+1 ) bya value of his choice. In order to prevent this kind of attack, the sending rate must be slower thanthe network delay from the sender to the receiver which limits the throughput of the transmission.Second, to authenticate the content of AP i , the receiver has to collect AP 1 , AP 2 ,...,AP i−1 . Indeed,if AP i−1 is lost then he cannot authenticate AP i even if he gets AP i+1 as he ignores the commitmentvalue F(K i ) used to check the consistency of K i contained in AP i+1 . This phenomenon propagates,that is to say, the receiver cannot authenticate any of AP i+1 , AP i+2 ,.... Such a scheme is said to havethe get-all-be<strong>for</strong>e requirement which is a serious problem as the transmission channel is assumed tobe unreliable (see Chapter 1).In order to overcome this latter drawback, Perrig et al. suggested to change the way MAC keyswere computed. If we denote v consecutive applications of F as F v (x) := F (v−1) (F(x)) with theconvention, F 0 (x) := x then the key generation is as follows:• the sender chooses an integer n.• the sender picks a random number K n .19


3. A TAXONOMY OF MULTICAST AUTHENTICATION SCHEMES• the sender pre-computes a sequence of n key values K n−1 ,...,K 0 where K i = F n−i (K n )<strong>for</strong> i ∈ {0,...,n − 1}.This sequence of values is called a key chain. Notice that n is the number of keys generated backwardsfrom the seed K n . Figure 3.2 shows an example of the modified TESLA scheme based on thiskey generation technique.✛FFK i−1✛K i✛K i+1✛❄F ′ ❄F ′ F ′❄K ′ i−1 K ′ iK ′ i+1AP i−1AP iAP i+1P i−1K i−2} {{ }D i−1P iK i−1} {{ }D iP i+1} {{ }K iD i+1MAC(K ′ i−1 ,D i−1)} {{ }authenticatedMAC(K i ′,D i)} {{ }authenticatedreception of AP i+1MAC(K ′ i+1 ,D i+1)} {{ }authenticatedFig. 3.2: TESLA: tolerance to packet lossIt is clear that any K i can be used to check the integrity of K j as soon as j < i since K j =F i−j (K i ) = F n−j (K n ). Thus using such a key chain enables to deal with an arbitrary number ofpacket losses. Since F is a PRF, it is a one-way function that is, no PPT opponent O can computeK i from F(K i ) = K i+1 with non-negligible probability. In addition, it prevents O from creating aparallel stream as the value K n bootstraps the whole key chain.In order to deal with the key disclosure problem, Perrig et al. proposed to include K i into theaugmented packet AP i+d instead of AP i+1 where the value d is based on the packet rate and thenetwork delay. In addition, to amortize the cost of the key chain, they proposed to compute MACsbased on time periods instead of a packet basis. This means that the communication is split into timeperiods T 1 ,T 2 ,.... Each key K i is used to compute the MACs of all augmented packets sent duringtime period T i and is disclosed during time period T i+d where d is computed as be<strong>for</strong>e. This alsoenables to process more packets with the same key chain than the packet-based approach. Nevertheless,this introduces an even larger authentication delay at the receiver resulting in an increase in thereceiver buffering requirements. Bergadano et al. built their Chained Stream <strong>Authentication</strong> (CSA)20


3.1. PROTOCOLS WITHOUT NON-REPUDIATION OF ORIGINprotocol in a similar way [13]. Nevertheless, CSA does not encounter the previous storage problemat the receiver as it only sends a single packet per time period T i . If we assume that an identicalnumber of augmented packets v is sent during each time interval then it is clear that CSA will requirev times as much time as TESLA to process the data stream when both protocols are used over thesame communication channel.In [114], Perrig et al. modified TESLA so that it provides instant verification of augmented packets.Their idea is to substitute the receiver buffering by the sender’s one. Indeed, if the sender canstore packets during d periods of time then he can include the hash of a latter packet into the currentaugmented packet. Let h be a collision resistant hash function. In order to build AP i from P i (sentduring time interval T j ), one appends the digest h(P i+v d ) along with the MAC of P i ‖h(P i+v d ) andthe interval key K j−d (see Figure 3.3).AP ih(P i+v d )AP i+v dD i} {{ }P i✯P i+v dh(P i+2 v d )} {{ }D i+v dMAC(K ′ j ,D i)❨MAC(K ′ j+d ,D i+v d)K j−dK jFig. 3.3: TESLA: immediate authentication of dataThus, upon reception of AP i+v d , packet P i+v d can be authenticated using its digest contained inAP i . In addition, if AP i is dropped, P i+v d can still be validated during time interval T j+2 d whenK j+d is included within each augmented packet sent during that time period. Nevertheless, Wong andChan showed that this new approach was vulnerable to random substitution attacks [152]. Indeed, anopponent O substituting the original AP i byP i ‖r 1 ‖r 2 ‖K j−d where r 1 and r 2 are random} {{ }˜D iwill have it temporary accepted by the receiver (i.e. the receiver will buffer it) as, at the time of reception,he ignores the correct key and cannot distinguish r 2 from the correct MAC value resultinginto a successful DoS attack against the storage capacity of the receiver. Wong and Chan proposed tointroduce additional digests within D i to avoid this problem. These hashes are built using a recursiveprocess and we refer the reader to [152] <strong>for</strong> the details of this construction.21


3. A TAXONOMY OF MULTICAST AUTHENTICATION SCHEMESIn [114], Perrig et al. also considered different TESLA instances to be sent in parallel. Each ofthem uses a different key chain so that the receiver can choose which iteration suits his computationaland bandwidth capacities best.Despite these improvements, TESLA requires the first packet of the stream to be digitally signedin order to guarantee that K 0 has been issued by the designated sender. As said earlier, this constitutesa major issue when using sensor networks. In order to overcome this problem, Perrig et al. designedMicro-TESLA (µTESLA) as a subroutine of their Security Protocols <strong>for</strong> Sensor Networks (SPINS)[117] where they suggested to use point-to-point authentication to bootstrap the key chain. Noticethat the recent construction by Jakimoski and Desmedt can be used in this context [68]. Nevertheless,relying on unicast-based approaches to bootstrap new members is not practical in a multicast context.In [82], Liu and Ning proposed to predetermine and broadcast the key chain commitments so thatone does not require either a digital signature or point-to-point communication any longer. Usingseveral key chains, they designed a multilevel µTESLA protocol requiring less storage capacities <strong>for</strong>the participants than the original version of µTESLA. This approach was extended in [83] where Liuet al. used a Merkle hash tree to deal with DoS attacks on the underlying µTESLA parameters.Nonetheless, a common weakness of TESLA and its variants is that their security relies on timesynchronization between the sender and the receivers. Thus, DoS attacks on time synchronizationprotocols will result in successful DoS attacks against those stream origin authentication schemes.One of the requirements is to have long enough key chains so that the whole stream can be processedbe<strong>for</strong>e the chains are exhausted. One possibility is to pick n large enough but this requires a lotof computations to be per<strong>for</strong>med be<strong>for</strong>e processing the first data packet with K 1 = F n−1 (K n ) andimportant storage capacities to buffer K 2 ,...,K n . However, this problem can be overcome using theapproach by Di Pietro et al. [44] as they managed to developed very long chains based on Chameleonhashing [75] having constant storage and computational requirements.It should be noticed that Jakimoski recently demonstrated that the security assumptions of thebuilding blocks of TESLA could lead to insecure implementations and proposed solutions to this issue[67]. He also emphasized that the original version of TESLA used the Hash based MAC (HMAC)construction [11] with MD5 [127] to simulate the PRF F ′ . The recent attacks on hash functions [148,149, 150] demonstrate that such an implementation <strong>for</strong> TESLA is not secure as these weaknesses canbe used to attack the HMAC algorithm as in [32]. Other attacks against HMAC using MD5 can befound in [123].22


3.2. PROTOCOLS WITH NON-REPUDIATION OF ORIGIN3.2 Protocols with Non-repudiation of OriginIn this section, we present authentication protocols exhibiting a non-repudiable proof of the originof streaming. The non-repudiation property will be provided using computationally secure digitalsignatures.As in Section 3.1.2.2, we represent the data stream as a sequence of packets P 1 ,P 2 ,P 3 ,.... Some redundancy will be appended to them to <strong>for</strong>m the augmented packets AP 1 , AP 2 , AP 3 ,...which will be sent into the network.In order to ensure non-repudiation of the sender, the simplest idea is to sign each data packet P iand to construct AP i as AP i := i‖P i ‖Sign SK (P i ). Un<strong>for</strong>tunately, this basic approach is impracticalas digital signatures are generally expensive to generate and/or verify. In addition, an opponent O canper<strong>for</strong>m successful DoS attacks against the computational power of the receivers by injecting bogusÃP i ’s and having the algorithm Verify PK to be queried <strong>for</strong> each of them. As a consequence, alternativetechniques have been developed [24]. They can be categorized into three major classes which will bepresented in the remaining of this section.3.2.1 Design of <strong>Multicast</strong> Signature SchemesThe first class of techniques is related to the design of digital signatures <strong>for</strong> broadcast. The purpose ofthis approach is to obtain faster generation and verification and smaller overhead than using traditionaldigital signatures. Note that Boneh et al. constructed short signatures in [16]. Nevertheless, this improvementis an example of construction non-compatible with broadcasting as implementations donein [10, 134] showed that these new signatures had a verification time which was prohibitive to be apractical solution <strong>for</strong> streaming.In [115], Perrig designed the Bins and Balls (BiBa) signature scheme. It requires a collision resistanthash function h as well as a family of keyed hash functions {G d } dproducing digests over{0,...,n − 1}. The signer chooses t SElf Authenticated vaLues (SEALs) S 1 ,...,S t . It is assumedthat the sender can distribute to the verifier a commitment value <strong>for</strong> each SEAL so that the verifiercan check that no tempering has occurred on the SEALs when verifying signatures.To sign a message m, the signer computes the digest d := h(m‖c) where c is a counter value tobe incremented if no collision of SEALs can be found. The signer tries to find two distinct SEALs S i1and S i2 such as: G d (S i1 ) = G d (S i2 ). When such a collision occurs, the signature σ of the message23


3. A TAXONOMY OF MULTICAST AUTHENTICATION SCHEMESm is defined as:σ := S i1 ‖S i2 ‖cUpon reception of the pair (m,σ) the verifier checks the authenticity of the two distinct SEALs usingthe commitment values. Then, he computes the digest d = h(m‖c) and checks if G d (S i1 ) = G d (S i2 )holds.In this construction, the SEALs represent the balls while {0,...,n − 1} is the numbering of thebins (see Figure 3.4).❄❫S 2 S 1 S 4 · · · S t S 3G d❄❄❄} {{ }signatureFig. 3.4: BiBa: an example of two-collisionIn order to strengthen the security of his signature, Perrig suggested to look at k-collisions ofSEALs, that is finding k distinct SEALs S i1 ,...,S ik such as:G d (S i1 ) = · · · = G d (S ik )It should be noticed that verifying the signature of message m requires k + 1 hash computations.The secret key of BiBa is the set of t SEALs. As part of this key is revealed when signing a message,BiBa is to be used as a one-time signature. In order to employ such a construction <strong>for</strong> multicast,Perrig suggested to build t one-way chains of SEALs using a PRF and to divide the communicationinto time intervals T 1 ,T 2 ,.... This approach is similar to TESLA except that one BiBa signature willbe computed per time interval while several MACs are computed with TESLA. This new multicastsignature works as follows.As <strong>for</strong> TESLA, we need two PRFs denoted F and F ′ . The function F is defined over {0,1} m2 ×{0,1} m1 and takes values in {0,1} m2 while F ′ is defined over {0,1} m1 × {0,1} m1 and takes valuesin {0,1} m1 <strong>for</strong> security parameters m 1 and m 2 . The sender generates a one-way key chain of length24


3.2. PROTOCOLS WITH NON-REPUDIATION OF ORIGINn by picking uni<strong>for</strong>mly K n from {0,1} m1 and computes the values K n−1 ,...,K 1 recursively as:∀i ∈ {1,...,n − 1} K i := F ′ (K i+1 ,0)Then, the sender constructs t SEAL chains in two steps. First, he uni<strong>for</strong>mly chooses t seed chainsS 1,n ,...,S t,n over {0,1} m2 . Second, he computes the t chains as:∀j ∈ {1,...,t} ∀i ∈ {1,...,n − 1} S j,i := F(S j,i+1 ,K i+1 )The family {S 1,i ,...,S t,i } of t SEALs is used to compute the unique signature occurring duringtime interval T i <strong>for</strong> i ∈ {1,...,n}. The values S 1,1 ,...,S t,1 are commitment values <strong>for</strong> the t SEALchains and K 1 is the commitment <strong>for</strong> the key chain (see Figure 3.5).S 1,1 S 2,1 · · · S t−1,1 S t,1K 1T 1✻ F✻ F✻ F✻ F✻ F✻F′.......✻ F✻ F✻ F✻ F✻ F✻F′S 1,i S 2,i · · · S t−1,i S t,i✻ F✻ F✻ F✻ F✻ FK i✻F′T iTime intervals.......✻ F✻ F✻ F✻ F✻ F✻F′S 1,n S 2,n · · · S t−1,n S t,n K n❄T nFig. 3.5: BiBa: generation of SEAL chainsUpon reception of the signature, the receiver verifies the authenticity of the SEALs using the keyK i (authenticated from K 1 ) and the commitment values S 1,1 ,...,S t,1 .When BiBa is used in conjunction with TESLA then the resulting authentication protocol providesnon-repudiation of the sender and enables new participants to join the communication groupafter the beginning of streaming. Un<strong>for</strong>tunately, like TESLA, BiBa relies on the reception of the t+1commitment values and requires the knowledge of an upper bound on the stream size as each chain25


3. A TAXONOMY OF MULTICAST AUTHENTICATION SCHEMEScontains n elements. As said earlier, this latter drawback can be dealt with using the techniques from[44].Several improvements to BiBa have been developed. In [93], Mitzenmacher and Perrig designedthe Powerball signature speeding-up BiBa verifier’s process while Reyzin and Reyzin’s Hash to ObtainRandom Subset (HORS) construction provides faster verification than the one <strong>for</strong> BiBa. [125].In addition, HORS and Powerball signatures are shorter than BiBa’s which is an advantage in oursettings as packet overhead is limited.Another approach to the design of faster signature schemes was proposed by Even et al. in [50].They introduced online/offline signatures to reduce the latency associated with the computation ofregular digital signatures. This new primitive was used by Rohatgi along with UOWHFs to obtainfaster and shorter signatures <strong>for</strong> multicast [129]. Nevertheless, Rohatgi’s keys can only be used tosign a small number of messages which involves to refresh the private and public keys throughoutthe communication. In [136], Shamir and Tauman used THFs to reduce the length of Even et al.’ssignatures. Their approach was improved by Gao and Yao who managed to approximately half thecomputational cost and the overhead of Shamir and Tauman’s signatures in [53]. This latter constructionworks as follows.Denote H PK (·, ·) a THF and h a collision resistant hash function. We assume that the stream isdivided into λ blocks of n packets P b,1 ,...,P b,n <strong>for</strong> b ∈ {1,...,λ}. As Gao and Yao’s approachrelies on online/offline signatures, the sender proceeds in two phases.During the offline phase, he uni<strong>for</strong>mly picks λ pairs (m 1 ,r 1 ),...,(m λ ,r λ ) and computes thedigests θ b := H PK (m b ,r b ) <strong>for</strong> b ∈ {1,...,λ}. He stores the λ triples (m 1 ,r 1 ,θ 1 ),...,(m λ ,r λ ,θ λ )and distributes θ 1 ,...,θ λ to each receiver over a secure channel.During the online phase, the sender processes the λ blocks independently from each other in asimilar way. Consider the b th block P b,1 ,...,P b,n . The sender computes the following n digests:⎧D n := h(P b,n ‖0 · · · 0)⎪⎨D n−1 := h(P b,n−1 ‖D n ‖0 · · · 0)⎪⎩ D i := h(P b,i ‖D i+1 ‖D i+2 ) <strong>for</strong> i from n − 2 to 126


3.2. PROTOCOLS WITH NON-REPUDIATION OF ORIGINThen, he uses the THF secret key SK and (m b ,r b ) to compute r b such as:H PK (h(D 1 ‖θ b ),r b ) = H PK (m b ,r b )Finally, he builds the n augmented packets of the block as:⎧AP n := b‖n‖P b,n⎪⎨⎪⎩AP n−1 := b‖n − 1‖P b,n−1 ‖D nAP i := b‖i‖P b,i ‖D i+1 ‖D i+2 <strong>for</strong> i from 1 to n − 2Note that the sender also constructs a header packet <strong>for</strong> the block b as: r b ‖D 1 . The receiver proceedsas follows:• On the reception of the header packet, he checks whetherH PK (h(D 1 ‖θ b ),r b ) = θ b (3.1)holds.• On the reception of AP i (<strong>for</strong> i ∈ {1,...,n − 2}), he checks whetherh(P b,i ‖D i+1 ‖D i+2 ) = D iholds.• On the reception of AP n−1 , he checks whetherh(P b,n−1 ‖D n ‖0 · · · 0) = D n−1holds.• On the reception of AP n , he checks whetherh(P b,n ‖0 · · · 0) = D nholds.Un<strong>for</strong>tunately, this authentication protocol has four drawbacks limiting its application <strong>for</strong> broadcasting.First, the length of the data stream must be known in advance to the sender as λ is neededto set up the scheme. Second, the sender needs a secure channel to each receiver in order to transmitthe θ b ’s during the offline phase. Not only this is too restrictive <strong>for</strong> multicast but it also prevents27


3. A TAXONOMY OF MULTICAST AUTHENTICATION SCHEMESnew participants from joining the communication group after starting streaming. Third, despite nonrepudiationof the sender is provided via Equation (3.1), it relies on reliable reception of the headerpacket which cannot be guaranteed <strong>for</strong> unsecured channels. Fourth, despite this approach toleratesisolated erasures (since each augmented packet contains two consecutive digests), it is vulnerable tosubstitution attack. Indeed, if an opponent O substitutes AP i by AP ′ i (<strong>for</strong> any i ∈ {2,...,n − 2})then the receiver cannot authenticate either AP i+1 or AP i+2 even if he receives them. In addition,such a substitution also prevents the remaining of the block AP i+2 ,...,AP n to be authenticated bypropagation.Definition 3.4 A data origin authentication scheme is said to be non-degrading if any receiver canauthenticate all the original augmented packets he collected. In the opposite case, the scheme is saidto be degrading.Based on the previous definition, the fourth drawback of Gao and Yao’s construction is that theirscheme is degrading <strong>for</strong> unsecured channels. In particular, authentication stops at the first injectionof data by O.3.2.2 Signature Packet based SchemesThe second class of techniques to be presented in this section is related to signature packet basedprotocols. The non-repudiation of the sender is guaranteed by the reception of a packet containinga digital signature. Its overhead and computation cost are amortized over several packets using hashfunctions. These constructions can be sorted into two families depending on whether they toleratepacket loss or not.3.2.2.1 Protocols <strong>for</strong> Networks with Reliable Distribution of DataIn [54], Gennaro and Rohatgi proposed two authentication schemes to treat the cases of delayedstreaming and live broadcast. Their constructions make use of a collision resistant hash function h.Their first approach requires the sender to know the n packets P 1 ,...,P n representing the wholestream as each augmented packet AP i contains the digests of its follower AP i+1 . The construction ofthe augmented packets works backwards as follows:⎧AP n := n‖P n ‖0 · · · 0⎪⎨AP i := i‖P i ‖h(AP i+1 ) <strong>for</strong> i from n − 1 to 1⎪⎩ AP 0 := 0‖h(AP 1 )‖Sign SK (h(AP 1 )) (signature packet)It is clear that this recursive construction allows propagation of authenticity from the signature28


3.2. PROTOCOLS WITH NON-REPUDIATION OF ORIGINpacket AP 0 to AP n through all other augmented packets AP i (<strong>for</strong> i ∈ {1,...,n − 1}).Gennaro and Rohatgi’s second scheme does not require the knowledge of the whole stream anylonger and thus it can be used <strong>for</strong> real-time broadcast. This approach uses one-time signatures(KeyGen i , Sign SKi , Verify PKi ) as well a traditional digital signature (KeyGen, Sign SK , Verify PK ). Ifthe data stream is represented by the sequence of packets P 1 ,P 2 ,P 3 ,..., then the correspondingaugmented packets are built as follows:∀i ≥ 1 AP i := i‖P i ‖PK i ‖Sign SKi−1(h(P i ‖PK i )),where (SK i , PK i ) denotes the key pair of the one-time signature (KeyGen i , Sign SKi , Verify PKi ). Thesignature packet is constructed as:AP 0 := 0‖PK 0 ‖Sign SK (PK 0 ),where (SK, PK) is the key pair <strong>for</strong> the digital signature (KeyGen, Sign SK , Verify PK ).Note that none of the previous two constructions tolerates a single packet drop, that is, theyhave the get-all-be<strong>for</strong>e requirement like the original version of TESLA. Thus, their applications <strong>for</strong>multicast are extremely narrow.3.2.2.2 Erasure Tolerant <strong>Authentication</strong> ProtocolsIn this section, we review schemes that provide authentication over lossy (or erasure) channels. Assaid earlier, the Internet is a major network <strong>for</strong> multicast distribution of digital content. In [113, 155],Paxson and Yajnik et al. showed that erasures over the Internet are likely to occur as bursts which canbe modeled using k-state Markov chains [51].In [116], Perrig et al. introduced the Efficient Multi-chained Stream Signature (EMSS) protocol.In this scheme, each augmented packet contains the hash of some of his predecessors. In order toprovide non-repudiation of the sender, a signature packet containing the signature of a few digestsis sent from time to time. Figure 3.6 illustrates the case where each augmented packet contains thedigests of its two predecessors.Such a construction can be seen as a directed graph where the vertices are the augmented packetsand the signature packet. A directed edge is drawn from AP i to AP j if AP j contains the hash of AP i .An augmented packet AP i is authenticated at the receiver if there exists a directed path from AP i to29


3. A TAXONOMY OF MULTICAST AUTHENTICATION SCHEMESAP iAP i+1AP i+2P ih(AP i−1 )h(AP i−2 )} {{ }✲P i+1h(AP i )h(AP i−1 )} {{ }✲P i+2h(AP i+1 )h(AP i )✕} {{ }❫ h(AP i+1 )h(AP i+2 ) ✛signature} {{ }signature packetFig. 3.6: EMSS: a simple examplethe signature packet only going through received augmented packets. As not every augmented packetis received over lossy channels, it is possible that some augmented packets reaching the receiver cannotbe authenticated. Thus, such constructions are a priori degrading. There<strong>for</strong>e, the general approachto this problem is to append sufficiently many digests to each augmented packet so that the probabilityof not authenticating at least one of the received elements is small without having too large anoverhead.In [116], Perrig et al. showed in the case of EMSS that, when the number of digests per augmentedpacket increased, the probability of non-authenticating a genuine element at the receiver decreased.Nevertheless, the numbering of the positions where digests had to be appended in EMSS followed adeterministic pattern. In [118], Perrig and Tygar randomized this distribution of hashes in their protocolcalled MESS. They showed that such a randomization process was to be recommended as MESSprovided better implementation results than EMSS. This approach was further improved by Challalet al. in [22, 23, 25, 26] where they proposed two similar protocols called Adaptive source <strong>Authentication</strong>protocol <strong>for</strong> multiCAST stream (A 2 CAST) and Hybrid Hash-chaining scheme <strong>for</strong> Adaptivesource authentication (H 2 A) . These two constructions mix deterministic and random hash distributionto obtain a smaller overhead and a better authentication probability than EMSS. Nevertheless,this is at the expense of a feedback channel between the sender and each receiver as the hash distribution(done by the sender) <strong>for</strong> A 2 CAST and H 2 A is modified in function of the current receiverspacket loss. This drawback was removed in [27] where the Receiver driven Layer Hash-chaining(RLH) protocol was presented. Indeed, RLH uses several chains of packets and each receiver chooses30


3.2. PROTOCOLS WITH NON-REPUDIATION OF ORIGINof channels. The block of n packets P 1 ,...,P n is partitioned into r equal-sized priority classesS 0 ,...,S r−1 . Each class can be written as {s i,1 ,...,s i,nr } <strong>for</strong> i ∈ {0,...,r − 1}. The class S 0 isassumed to have the highest priority and its packets are evenly spread throughout the block. In orderto tolerate x i bursts of length b i where i ∈ {0,...,r−1}, the graph construction of the authenticationscheme is as follows.1. Construct edges originating at nodes of S 0 as:(a) For each j ∈ {2,...,x 0 k 0 + 1}, add an edge from s 0,j to s 0,1 .(b) For each j ∈ {x 0 k 0 + 2,..., n r }, add an edge from s 0,j to s 0,j−1 ,s 0,j−1−k0 ,...,s 0,j−1−x0 k 0.2. Construct edges originating at nodes from other classes as:(a) For each i ∈ {1,...,r − 1} and each j ∈ {1,...,x i k i }, add an edge from s i,j to s 0,j .(b) For each i ∈ {1,...,r − 1} and each j ∈ {x i k i + 1,..., n r }, add an edge from s i,j tos 0,j ,s 0,j−ki ,...,s 0,j−xi k i.Based on the analysis made in [92], the communication overhead of the Piggybacking scheme issignificantly smaller than randomized constructions like MESS and p-random graphs when transmissionlosses are bursty.The main drawback of the constructions presented in this section is that each of them guaranteesauthenticity and non-repudiation of the sender only when the signature packet is received. This requirementis incompatible with the unsecured communication channel model as the opponent O onlyneeds to discard those particular packets to make the previous authentication schemes useless.In [2], Abuein and Shibusawa suggested to link each augmented packet AP i to several signaturepackets so that even if some of them are lost, AP i can still be authenticated at a later time. Thisapproach, however, generates an important authentication delay at the receiver.In [156], Yoon et al. proposed a protocol called Robust <strong>Authentication</strong> of Multimedia Stream(RMAS). They assumed that t out of the n augmented packets could be lost. They represented thepacket digests using a polynomial R(X) of degree n − t + 1 such as:R(X) :=n−t+1∑i=0r i X i where r 0 ‖ · · · ‖r n−t+1 := h(P 1 )‖ · · · ‖h(P n )Each augmented packet AP i contains i‖P i ‖R(i). In addition, t + 1 of them contain the block signature.Thus, if at most t erasures happen then at least one of the received augmented packets includes33


3. A TAXONOMY OF MULTICAST AUTHENTICATION SCHEMESthe signature. Furthermore, the polynomial R(X) can be reconstructed from any n − t subset of{R(1),...,R(n)}. There<strong>for</strong>e, the receiver recovers the n digests h(P 1 ),...,h(P n ) which provesthat RMAS is non-degrading over lossy channels <strong>for</strong> loss ratio at most t n .The scheme designed by Ueda et al. in [145] provides recovery of the block signature whateverthe packet loss pattern is since the signature is inserted within each augmented packet. Un<strong>for</strong>tunately,this creates an overhead which can be prohibitive <strong>for</strong> low bandwidth users. In addition, the authenticityof packets relies on the hash distribution and there<strong>for</strong>e this construction is a priori degrading.In [153], Wong and Lam used a Merkle hash tree to overcome this drawback. The n packetsP 1 ,...,P n constitute the leaves of the tree (see Figure 2.1). The tree root r is signed and the naugmented packets are built as:∀i ∈ {1,...,n}AP i := i‖P i ‖Sign SK (r)‖path(i)where path(i) are the ⌈log 2 n⌉ hashes needed to reconstruct the path from P i to the root of the tree (seeSection 2.1.2). This approach has an even bigger overhead than Ueda et al.’s scheme. Nonetheless,each augmented packet is self-authenticating. Thus, Wong and Lam’s construction is non-degrading.Furthermore, this property is also valid over unsecured channels as an opponent O injecting a bogusaugmented packet AP ′ i will have it rejected by the receiver since h is collision resistant and the signaturescheme is secure.Note that Park et al. also proposed a tree based scheme in [112]. Despite their approach haslower overhead than Wong and Lam’s protocol, Park et al.’s scheme is degrading over lossy channels.However, Park et al.’s approach has higher authentication probability than EMSS and Golle andModadugu’s scheme.3.2.3 Signature Dispersion based SchemesThe data origin protocols presented in Section 3.2.2 either rely on the reliable distribution of signaturepackets or include the signature into many augmented packets. None of these solutions, however,is fully compatible with the settings of multicast exposed in Chapter 1. Indeed, reliability of datatransmission is not possible and packet overhead is limited. The third class of authentication schemesto be presented is based on the dispersion of signatures. For these constructions, the data stream isdivided into blocks of n packets P 1 ,...,P n . Each block is processed independently from the others.In this case, we use the term block signature to refer to the signature of the block P 1 ,...,P n . Themajor idea behind these protocols is to split the block signature σ into k smaller parts where onlyl of them (l < k) are enough to guarantee the recovery of σ. These authentication schemes can34


3.2. PROTOCOLS WITH NON-REPUDIATION OF ORIGINbe classified into two families depending on whether they resist to DoS attacks per<strong>for</strong>med by theopponent O or not.3.2.3.1 Protocols Vulnerable to DoS AttacksThe scheme proposed by Al-Ibrahim and Pieprzyk in [4] is a basic improvement of RMAS in thesense that the block signature σ = Sign SK (h(h(P 1 )‖ · · · ‖h(P n ))) is incorporated into the polynomialcoefficients as:R(X) :=n−t+1∑i=0r i X i where r 0 ‖ · · · ‖r n−t+1 := h(P 1 )‖ · · · ‖h(P n )‖σThus, when reconstructing R(X), the receiver recovers the n packet digests as well as the block signature.Another way to distribute the signature is to use the In<strong>for</strong>mation Dispersal Algorithm (IDA) byRabin [121]. This algorithm was employed as a subroutine by Park et al. when they designed theirSignature Amortization using IDA (SAIDA) protocol in [109, 110]. The sender processes each streamblock as follows.1. Form the string F := h(P 1 )‖ · · · ‖h(P n ). Let m be a divisor of the size of F denoted |F |.Write F as:F = f 1 ‖ · · · ‖f m} {{ } ‖f m+1‖ · · · ‖f 2 m} {{ } ‖ · · · ‖f nH−m+1‖ · · · ‖f nH} {{ }where H is the bit length of a digest computed by h. Define n H m vectors S 1,...,S n HmS i := (f (i−1) m+1 · · · f i m ) <strong>for</strong> i ∈ {1,..., n H m }.such as2. Choose n vectors v i := (v i,1 · · · v i,m ) <strong>for</strong> i ∈ {1,...,n} such that the n × m matrix⎛C := ⎜⎝⎞v 1. ⎟⎠v nis a Cauchy matrix [74].3. Split F into n parts F 1 ,...,F n as:∀i ∈ {1,...,n}F i := 〈a i ,S 1 〉‖ · · · ‖〈a i ,S n Hm〉where 〈a i ,S j 〉 denotes the scalar product of vectors a i and S j [78].35


3. A TAXONOMY OF MULTICAST AUTHENTICATION SCHEMES4. Compute the block signature σ as σ := Sign SK (h(F)) and split it into σ 1 ,...,σ n using thesame vectors v 1 ,...,v n as in Steps 2 and 3.5. Build the augmented packets as:∀i ∈ {1,...,n}AP i := i‖σ i ‖F i ‖P iWith this technique, the packet overhead is the size of σ i ‖F i , that is S+n Hmthe bit size of the signature.bits where S denotesAssume the receiver collects m augmented packets. W.l.o.g., we can assume these packets areAP 1 ,...,AP m . He works as follows:1. The receiver reconstructs the string F as:∀i ∈{1, · · · , n H m}⎛S i = V −1 ⎜⎝〈a 1 ,S i 〉.〈a m ,S i 〉⎞⎟⎠where V is the m × m matrix having v 1 ,...,v m as rows.2. He reconstructs the signature σ from σ 1 ,...,σ m as in Step 1.3. He checks which received elements are consistent with σ and h(P 1 ),...,h(P n ).Note that this approach requires the Cauchy matrix C to be known by the receivers. The matrixV −1 , however, needs to be computed only once. This can be done in O(m 2 ) field operations as explainedin [121].It is clear that SAIDA is non-degrading <strong>for</strong> lossy channel having a loss ratio at most n−mn. In [35],Cucinotta et al. compared EMSS, augmented chains, piggybacking and SAIDA. Their implementationresults showed that, <strong>for</strong> the same authentication probability, computational cost at the receiverwas higher due to the use of IDA.It should be noticed that Pannetrat and Molva proposed a similar approach in [107, 108], wherethey used an erasure code instead of IDA. Their construction was combined with piggybacking todevelop three authentication schemes tailored to different sender buffering capacities. The bit lengthof the packet overhead <strong>for</strong> those three protocols is:36R ⌊(1−p) n⌋ (S + ⌈pn⌉ H)⌊(1 − p)n⌋


3.2. PROTOCOLS WITH NON-REPUDIATION OF ORIGINwhere p is the maximum expected loss rate and R λ (µ) is the lowest multiple of λ greater or equal toµ. Pannetrat and Molva compared their construction to EMSS and showed that their packet overheadwas significantly smaller based on the same implementation examples as in [116].Several improvements of SAIDA have been developed. In [111], Park and Cho designed enhancedSAIDA (eSAIDA). They proved that <strong>for</strong> the same packet overhead, the probability of authenticatinga packet was higher using eSAIDA. They also showed that the running time of eSAIDA could bebetween 18% and 38% smaller than SAIDA’s. In [144], Ueda et al. presented their Stream <strong>Authentication</strong>scheme <strong>for</strong> Videos (SAVe). They considered that, in video streaming, you have different levelsof importance <strong>for</strong> data packets and they distributed to each frame an amount of redundancy correspondingto the frame’s importance within the stream. Their implementation results showed that, whenthe packet loss ratio was 20%, this frame based approach enabled to use 50% more authenticated packetsat the receiver than SAIDA. Another improvement to SAIDA is due to Jeong et al. in [69]. Thetwo constructions studied in that paper have low overhead. Un<strong>for</strong>tunately, their first scheme requirestime synchronization between the sender and each receiver as the protocol relies on MAC key disclosurelike TESLA. In addition, contrary to what is claimed in [69], none of those schemes is resistantagainst DoS attacks. Indeed, the security of both constructions operates by propagation. Nonetheless,the first verification the receiver has to undertake is similar to SAIDA’s except that Jeong et al. use anerasure correcting code instead of IDA. There<strong>for</strong>e, if the opponent O per<strong>for</strong>ms a substitution attackthen the receiver can never initialize the authentication chain as the erasure code will systematicallyfail at recovering the original signature.For each scheme presented so far, the authentication of packet P i is done thanks to the digestor a MAC value of AP i . This means that authenticating the block P 1 ,...,P n requires at least nhash/MAC values to be computed at the sender. As each of these elements has to be appended to atleast one augmented packet, this approach may generate redundant overhead. In [42], Desmedt andJakimoski proposed to use CFFs to reduce the number of tags to be computed and thus they decreasedthe general overhead of the construction. Each tag is computed over a subset of {P 1 ,...,P n } andthe CFF ensures that the authentication scheme is non-degrading <strong>for</strong> lossy channels. The tags areconstructed as in [3]. The block signature is dispersed using a CFF to resist erasures as well.3.2.3.2 DoS Resistant <strong>Authentication</strong> ProtocolsIn the unsecured channel model, the opponent O can delete packets and inject bogus pieces of data.His purpose is to exhaust either the receiver computational powers or his storage capacity. It is clearthat the signature packet based schemes presented in Section 3.2.2 are vulnerable against such attacksas O only needs to erase the original signature packet and flood the receiver with bogus signature37


3. A TAXONOMY OF MULTICAST AUTHENTICATION SCHEMESpackets to exhaust both computational and storage resources of the participants.Note that the schemes from Section 3.2.3.1 are not secure <strong>for</strong> an unsecured channel also <strong>for</strong> adifferent reason. Indeed, O can prevent any packet from being authenticated by substituting someAP i by AP ′ i and make the signature reconstruction fail as σ ′ ≠ σ will be recovered by the receivers.The idea presented by Karlof et al. in [70, 71] enables to treat both erasures and malicious injectionsof data. Their Pollution Resistant Authenticated Block Stream (PRABS) protocol combines anerasure code to deal with erasures and a Merkle hash tree to resist against injections of bogus elements.Assume that each block is represented within the stream by an identification value BID. Thesender uses Algorithm 3.1 to process the block P 1 ,...,P n .Algorithm 3.1 AuthenticatorPRABSInput: The secret key SK, the block number BID, the maximum number of erasures t and n datapackets P 1 ,...,P n .1. Compute the digests h(P 1 ),...,h(P n ) and <strong>for</strong>m the string D := BID‖h(P 1 )‖ · · · ‖h(P n ).Compute the block signature as: σ := Sign SK (h(D)).2. Encode the string D‖σ into (s ′ 1 · · · s ′ n) using an (n,t) erasure code.3. Build a Merkle hash tree having s ′ 1,...,s ′ n as leaves and construct the augmented packets as:∀i ∈ {1,...,n}AP i := BID‖i‖P i ‖s ′ i‖path(i),where path(i) denotes the hashes needed to reconstruct the path from s ′ i to the tree root.Output: {AP 1 ,...,AP n }: set of augmented packets.Note that the Merkle hash tree is used as a one-way accumulator [9, 12, 99, 100]. The accumulatedvalue is the tree root while the witness of s ′ i is path(i). The receiver uses Algorithm 3.2 toauthenticate data packets.The collision resistance of h and the security of the digital signature involve that PRABS is anon-degrading authentication scheme <strong>for</strong> a loss rate at most t n. Un<strong>for</strong>tunately, the packet overhead ofPRABS is Θ(log 2 n) bits like Wong and Lam’s scheme [153].Observe that each tree node - except the root - appears 2 ⌈log 2 n⌉−j times in the n strings path(1),...,path(n) where j denotes the depth of the node. The Computationally Efficient Countermeasure<strong>for</strong> Injection Attacks (CECInA) protocol by Di Pietro et al. [43] ensures that each digest only appearst + 1 times over the n strings path(1),...,path(n) reducing the overhead from PRABS. Un<strong>for</strong>tunately,the size of augmented packets of CECInA is extremely irregular as some of them carry a few38


3.2. PROTOCOLS WITH NON-REPUDIATION OF ORIGINAlgorithm 3.2 DecoderPRABSInput: The public key PK, the block number BID, the maximum number of erasures t and a set ofreceived packets RP.1. For each received packet ÃP i = BID‖i‖ ˜P i ‖˜s ′ i ‖˜path(i), compute the root value ˜r i using˜s ′ i ‖˜path(i) and stack ÃP i into the list L˜ri .2. For each list L˜rj having at least n − t elements, per<strong>for</strong>m an erasure decoding and parse thecorresponding message as BID‖˜h 1 ‖ · · · ‖˜h n ‖˜σ. If Verify PK (h(BID‖˜h 1 ‖ · · · ‖˜h n ), ˜σ) = TRUE thenset h ′ i = ˜h i <strong>for</strong> i ∈ {1,...,n}.3. Set P i ′ = ∅ <strong>for</strong> i ∈ {1,...,n}. Identify amongst RP the elements which are consistent withh ′ 1,...,h ′ n and update the corresponding P i ′’s.Output: {P ′ 1,...,P ′ n}: set of authenticated packets.digests while others have the whole path of ⌈log 2 n⌉ hashes. Even if a network like the Internet cancope with irregular flows of in<strong>for</strong>mation, CECInA’s overhead exhibits important discrepancies whichmay not be easy manage since, at its peak, it reaches Θ(log 2 n) bits like PRABS.In [28], Choi combined Prediction Hashing (PH) along with one-way key chain to design a fasterauthentication scheme having smaller overhead than PRABS. In this construction, Choi assumes thatthe sender can buffer two consecutive blocks of n packets. The augmented packets <strong>for</strong> block BID areconstructed as:∀i{1,...,n}AP i := BID‖i‖P i ‖K BID−1‖s ′ BID+1,i‖MAC KBID (s ′ BID+1,i)‖path(i)where (s ′ BID+1,1 · · · s ′ BID+1,n) is the codeword obtained from the signature of block BID + 1 (Step 2of Algorithm 3.1), K BID−1 is the key used to compute MAC values <strong>for</strong> block BID − 1 and path(i)represents the ⌈log 2 n⌉ hashes used to reconstruct the path from s ′ BID+1,i ‖MAC K BID(s ′ BID+1,i ) to theroot of the tree whose leaves are the n concatenations:s ′ BID+1,1‖MAC KBID (s ′ BID+1,1),...,s ′ BID+1,n‖MAC KBID (s ′ BID+1,n)The problem with such an approach is that the receiver has to wait one extra block to process dataas K BID is disclosed within block BID + 1 which makes this construction vulnerable to DoS attacksagainst the receiver storage capacity.In [81], Lin et al. designed the Pollution Attack Resistant <strong>Multicast</strong> authentication scheme (PARM)based on SAIDA. They showed that PARM had a smaller overhead and computational cost thanPRABS. Un<strong>for</strong>tunately, PARM requires the sender to generate several hash chains in parallel whichhave to be frequently refreshed. This requirement is impractical <strong>for</strong> broadcasting.39


3. A TAXONOMY OF MULTICAST AUTHENTICATION SCHEMESIn [87], Lysyanskaya, Tamassia and Triandopoulos presented a provably secure protocol <strong>for</strong> multicaststream authentication over unsecured channels denoted LTT in this thesis. Instead of employinga one-way accumulator like PRABS, LLT represents the packet digests and the block signature aspolynomial coefficients and uses the algorithm Poly-Reconstruct by Guruswami and Sudan to solvePRP (see Section 2.3).The unsecured communication channel model is represented by two parameters:• α: the survival rate. When n packets are sent into the network, at least ⌈α n⌉ of them arrive atthe receiver intact.• β: the flood rate. When n packets are sent into the network, the receiver collects at most ⌊β n⌋packets.By construction, we have: 0 < α ≤ 1 ≤ β. For LTT, the sender processes the block P 1 ,...,P nas in Algorithm 3.3. LTT relies on RS codes which represent a class of linear codes. A linear codeof length N, dimension K and minimum distance D is generally denoted as [N,K,D]. As in Section3.2.3.1, H denotes the bit length of a digest produced by h and S is the signature bit length.Algorithm 3.3 AuthenticatorLTTInput: The secret key SK, the block number BID, the rates α and β, a coefficient ǫ as well as n datapackets P 1 ,...,P n .1. Compute the n digests h(P 1 ),...,h(P n ) and compute the block signature as: σ :=Sign SK (h(BID‖h(P 1 )‖ · · · ‖h(P n ))).2. Compute the value ρ := α2β (1+ǫ) and pad h(P 1)‖ · · · ‖h(P n )‖σ with l zeros where l := n H +S mod ρn.⌈3. Parse the string h(P 1 )‖ · · · ‖h(P n )‖σ‖0 l as M 1 ‖ · · · ‖M ρ n+1 where each M i is⌉n H+Sρ n+1bitslong. Encode the message (M 1 · · · M ρ n+1 ) into the codeword (C 1 · · · C n ) using a [n,ρn+1,n−ρn] RS code.4. Construct the augmented packets as:∀i ∈ {1,...,n}AP i := BID‖i‖P i ‖C iOutput: {AP 1 ,...,AP n }: set of augmented packets.Poly-Reconstruct has been developed by Guruswami and Sudan to per<strong>for</strong>m list decoding of RScodes [62]. In order to use Poly-Reconstruct in the stream authentication context, Lysyanskaya etal. developed Modified Poly-Reconstruct (MPR) depicted as Algorithm 3.4. Note that F 2 q denotesthe finite field with |F 2 q| = 2 q elements. Every element of F 2 q can be represented as a polynomialof degree at most q − 1 over F 2 (see [80]). Operations in F 2 q are per<strong>for</strong>med modulo a polynomial40


3.2. PROTOCOLS WITH NON-REPUDIATION OF ORIGINQ(X) of degree q which is irreducible over F 2 . Each receiver authenticates the stream packets usingAlgorithm 3.5 which employs MPR as a subroutine.Algorithm 3.4 Modified Poly-Reconstruct (MPR)Input: The maximal degree K of the polynomial Q(X), the minimal number N of agreeable points,T points {(x i ,y i ),1 ≤ i ≤ T } and the polynomial Q(X) of degree q.1. If there are no more than √ K N distinct points then the algorithm stops.2. Using Q(X), run Poly-Reconstruct on the T points to get the list of all polynomials of degreeat most K over F 2 q passing through at least N of the points.3. Given the list {L 1 (X),...,L µ (X)} obtained at Step 2. For each polynomial L i (X) := L i,0 +... + L i,K X K where ∀i ∈ {0,...,K}L i,j ∈ F 2 q, <strong>for</strong>m the elements: L i := L i,0 ‖ · · · ‖L i,K .Output: {L 1 ,...,L µ }: list of candidatesAlgorithm 3.5 DecoderLTTInput: The public key PK, the block number BID, the rates α and β, the coefficient ǫ and the set ofreceived packets RP.1. Write the packets as BID i ‖j i ‖ ˜P ji ‖B ji and discard those having BID i ≠ BID or j i /∈ {1,...,n}.Denote N the number of remaining elements. If (N < ⌈α n⌉ or N > ⌊β n⌋) then the algorithmstops.2. Rename the remaining elements as {ÃP 1 ,...,ÃP N } and write each element as: ÃP i =BID‖j i ‖ ˜P α ji ‖B ji where j i ∈ {1,...,n}. Compute ρ = 2β (1+ǫ)and run MPR on the set{(j i ,B ji ),1 ≤ i ≤ N } to get a list L := {C 1 ,...,C µ } of candidates <strong>for</strong> signature verification. IfMPR rejects that set then the algorithm stops.3. Set h ′ j = ∅ <strong>for</strong> j ∈ {1,...,n}. While the signature has not been verified and the list L hasnot been exhausted, pick a new candidate ˜h 1 ‖ · · · ‖˜h n ‖˜σ after removing the pad of length l. IfVerify PK (h(BID‖˜h 1 ‖ · · · ‖˜h n ), ˜σ) = TRUE then ˜σ is considered as the authentic block signatureand we set h ′ j = ˜h j <strong>for</strong> j ∈ {1,...,n}. If L is exhausted be<strong>for</strong>e the signature is verified then thealgorithm stops.4. Set P ′ i = ∅ <strong>for</strong> i ∈ {1,...,n}. For each of the N remaining packets, BID‖j i ‖ ˜P ji ‖B ji , ifh( ˜P ji ) = h ′ k then set P ′ i = ˜P ji .Output: {P ′ 1,...,P ′ n}: set of authenticated packets.In [87], Lysyanskaya et al. demonstrated that their scheme was non-degrading and the number ofsignature verifications per block was O(1) as a function of the block length n despite injections per<strong>for</strong>medby O. Only PRABS had these two properties be<strong>for</strong>e as the number of signature verificationsto be per<strong>for</strong>med by the other schemes is Θ(n) when injections occur. We will see later in this thesisthat LTT’s overhead is less than PRABS’ but it is not O(1) bit long contrary to what Lysyanskaya etal. claimed in [87].41


4A Coding Approach to <strong>Multicast</strong> <strong>Authentication</strong>The purpose of this thesis is to develop non-degrading data origin authentication schemes <strong>for</strong> multicastdistribution of digital content over unsecured communication channels. Note that every authenticationscheme presented in Chapter 3 requires the reception of AP i to recover the corresponding packetP i (at the receiver) as the augmented packet AP i is the only one containing in<strong>for</strong>mation about P i - infact, AP i contains the whole P i . If AP i is dropped during transmission then P i is definitely lost. Wepropose to use erasure correcting codes to overcome this problem. As the previous techniques, wewill process the data stream per block of n packets P 1 ,...,P n independently from each other. Thetwo constructions presented in this chapter can be seen as extensions of LTT and PRABS enablingany receiver to recover all data packets P 1 ,...,P n despite losses and injections incurred during thetransmission. This feature constitutes a major improvement compared to the existing approaches inthe way that receivers not only authenticate what they receive - i.e. the authentication schemes arenon-degrading - but they also reconstruct what has been lost. This is particularly beneficial whenP 1 ,...,P n represent audio or video data where our techniques prevent frozen images and audio gapsto happen.In both constructions, a digital signature will be used to ensure non-repudiation of the sender and43


4. A CODING APPROACH TO MULTICAST AUTHENTICATIONto enable new members to join the communication group at every block boundary.Our first protocol uses Luby Trans<strong>for</strong>m (LT) codes to encode blocks of n data packets P 1 ,...,P ninto N symbols E 1 ,...,E N (the value of N is specified in Section 4.3). LT codes were introduced byLuby [84] as the first practical realization of rateless codes to illustrate the Digital Fountain concept[18]. These codes are constructed in such a way that there exists a threshold value m (depending onn) such that any subset of {E 1 ,...,E N } having at least m distinct elements can be used to recoverall n original packets P 1 ,...,P n with a good probability. By representing E 1 ,...,E N as coefficientsof a particular polynomial and carefully choosing N , the receiver will be able to use MPR to recoverthat polynomial despite potential data injections per<strong>for</strong>med by malicious users. Such a coding techniquewill enable us to achieve a minimal lower bound on the packet recovery probability which canbe chosen arbitrarily close to 1. Since the security of our construction depends on the consistencyof the LT decoding (while LTT relies on the correctness of RS codes), we will compare LT codes toother families of rateless codes including Online and Raptor codes [89, 137]. We will show that itis possible to achieve reasonable packet overhead by using a modified version of LT codes. We willalso emphasize that Raptor codes can provide good practical implementations <strong>for</strong> our scheme if theyare used instead of LT codes. Note that Raptor codes have recently been used in many applicationsrelated to the distribution of digital content [1, 154].As we will see, rateless codes only require XOR operations to encode and decode data, which issuitable <strong>for</strong> devices with a limited computational power. Nevertheless, when receivers have hardwareallowing more complex arithmetic operations (such as field operations <strong>for</strong> instance), one may thinkabout using an approach similar to PRABS. Our second protocol will allow complete recovery ofthe whole data stream (i.e. total recovery with probability 1) using a Maximum Distance Separable(MDS) code construction developed by Lacan and Fimes in 2004. Based on their work [77], wewill argue that applying their code construction results in a better encoding/decoding complexity thanusing most other MDS codes. When compared to RS codes (as used <strong>for</strong> LTT) our technique willgenerate a slight increase of computing complexity at the sender (which can be compensated by hislarger computational power) whereas the complexity at the receivers will be reduced. We will alsosee that our packet overhead is smaller than PRABS <strong>for</strong> practical applications.Contrary to [87] where only an asymptotic study of LTT was per<strong>for</strong>med, we will derive an upperbound on the number of signature verifications per block <strong>for</strong> both schemes. This bound will be valid<strong>for</strong> any block length and will turn out to be O(1) as <strong>for</strong> LTT and PRABS. Such a bound is valuableas the block length is never asymptotic <strong>for</strong> practical applications. It allows receivers to get an upper44


4.1. PRELIMINARIESbound on the time spent to verify signatures and there<strong>for</strong>e on the delay 1 between reception of in<strong>for</strong>mationand authentication of correct packets.model.Like LTT and PRABS, our two protocols will be proved to be secure <strong>for</strong> the unsecured channel4.1 PreliminariesWe now introduce the terminology and assumptions we will use in this thesis. First, we need to definethe network model <strong>for</strong> unsecured channels. Then, we will describe the two code constructions byLuby and Lacan and Fimes.4.1.1 Network ModelAs said in Chapter 3, we consider that the communication channel is under control of an opponent Owho can drop and rearrange packets. He is also allowed to inject bogus data into the network. Sinceour primary concern is the multicast authentication problem, we can assume that a reasonable numberof original augmented packets reaches the receivers and not too many incorrect elements are injectedby O. Indeed, if too many original packets are dropped then strengthening data transmission is themain issue as it is likely that the few packets successfully received and authenticated are going to beuseless anyway. On the other hand, if O injects a large number of <strong>for</strong>ged packets then the main problemis making the communication channel more resistant against DoS attacks. Indeed, if O injectstoo many packets, then the receiver’s buffer will fill in much faster than the receiver authenticates in<strong>for</strong>mationresulting in a saturation of his storage capacity. In order to build our signature amortizationschemes, we split the data stream into blocks of n packets: P 1 ,...,P n .We define two parameters: α (0 < α ≤ 1) (the survival rate) and β (β ≥ 1) (the flood rate). It isassumed that at least a fraction α and no more than a multiple β of the number of augmented packetsare received. This means that, when A augmented packets are sent into the network, at least ⌈αA⌉ ofthem are received amongst a total which does not exceed ⌊βA⌋ elements. This can be summarized asfollows:Definition 4.1 We say that a pair (α,β) of survival and flood rates is accurate to the network <strong>for</strong> aflow of A symbols if:1. Data are sent per block of A elements through the network.1 This delay is called authentication delay of the scheme.45


4. A CODING APPROACH TO MULTICAST AUTHENTICATION2. For any block of A elements {E 1 ,...,E A } emitted by the sender, the set of received packets{Ẽ1,...,Ẽµ} verifies µ ≤ ⌊βA⌋ and |{E 1 ,...,E A } ∩ {Ẽ1,...,Ẽµ}| ≥ ⌈αA⌉.The second condition must be true <strong>for</strong> each receiver belonging to the communication group.For the remaining of this thesis, we assume that the rates α and β are accurate <strong>for</strong> the flow A.Notice that we will have A = n <strong>for</strong> our MDS code-based scheme while A > n using LT codes.4.1.2 Code ConstructionLT Codes. We briefly describe how to generate outputs <strong>for</strong> LT codes and how to decode data. Acomplete description of both processes can be found in [84].Encoding. We have a fixed number of input symbols denoted by I 1 ,...,I K . In order to generate anew encoding symbol E, we use a probabilistic distribution called the Robust Soliton distribution tochoose the degree 2 d of the symbol E. We randomly pick d elements amongst the input symbols:I i1 ,...,I 3 id . We generate E as the XOR of I i1 ,...,I id . Using this process we can generate as manyencoding symbols as we want since we only need to run the Robust Soliton distribution to get a newone.Decoding. As noted by Shokrollahi in [137], decoding LT codes is similar to decoding Low DensityParity Check codes [14] over an erasure channel. When the receiver gets N encoding symbolsE 1 ,...,E N he first builds the bipartite graph used to compute E 1 ,...,E N 4 . We would like to pointout that it can happen that not every I i is on the left hand side. This is true in particular if N is smalland the encoding symbols have small degrees. At the beginning of the decoding process no I j ’s havebeen covered 5 . They are initialized with 0’s. We first release 6 all E l ’s with a single adjacent vertex tocover their unique neighbor. The set of covered input symbols not yet processed is called the rippleand denoted R. All previous covered symbols belong to R. At each step, one element I j is processedas follows:1. Each neighbor N l j of I j has its value XOR-ed with I j ’s.2. I j is removed as a neighbor of these elements Nj l . That is, the corresponding edges are removedfrom the graph.3. For each Nj l having one remaining neighbor in the new graph, Nl j is released from the graph and2 Any LT code can be represented as a bipartite graph [45] with I 1 , . . . , I K as the left hand side vertices and all encodingsymbols as right hand side vertices. An edge is drawn between I j and the encoding symbol E if I j has been used to computeE. I j is said to be a neighbor of E (and vice versa). We use the term degree to denote the number of neighbors a symbol has.3 This is how we build the bipartite graph representing the LT code.4 The positions of the input symbols XOR-ed to build an encoding symbol E i are sent along with E i .5 An input symbol I j is said to be covered when it is the only adjacent vertex of an encoding symbol E l . The coveringoperation is a XOR of the current value of I j with E l .6 A symbol is said to be released when we remove its representing vertex from the graph.46


4.1. PRELIMINARIEScovers its remaining neighbors which are added to R (<strong>for</strong> those which were not already in).4. I j is released from R (because it has no neighbors any longer).Steps 3 and 4 make the size of R vary. The decoding process ends when R is empty. It issuccessful when I 1 ,...,I K have been released from R. We will use the following theorem to dealwith packet loss occurring during data transfer.Theorem 4.1 ([84]) For δ ∈ (0,1), the decoding process fails with probability at most δ from anyset of N := K + (R + R 2 + · · · + RK−R )ln ( ) (Rδ encoding symbols where R := c ln K) √δ K <strong>for</strong> apositive constant c determined within the Robust Soliton distribution.In [21], it is proved that c has to be chosen as:In this thesis, we consider1K − 1 ·1K − 1 ·√Kln(K/δ) ≤ c ≤ 1 2 ·√Kln(K/δ) ≤ c ≤ 1 2 ·√Kln(K/δ)K ηln(K/δ)<strong>for</strong> some constant (independent from K) value η in ( 0, 1 2)so that our packet overhead remains reasonable(see Appendix C).MDS Codes. The Singleton bound states that any [N,K,D] code satisfies: D − 1 ≤ N − K [88].It is known that any [N,K,D] code can correct up to D − 1 erasures [158]. Thus, a [N,K,D] codecannot correct more than N − K erasures. In order to maximize the efficiency of our authenticationscheme, we are interested in codes correcting exactly N − K erasures. These codes are called MaximumDistance Separable (MDS) codes [88].Now, we describe the MDS code construction developed in [77]. We will work over the field F 2 q.As explained in Section 3.2.3.2, every element of F 2 q can be represented as a polynomial of degreeat most q − 1 over F 2 and operations in F 2 q are per<strong>for</strong>med modulo a polynomial Q(X) of degree qwhich is irreducible over F 2 . From [77], we have:Theorem 4.2 Let V (a 1 ,...,a K ) be a non-singular K × K Vandermonde matrix [74] and let( ) j=1,...,KV (b 1 ,...,b N−K ) be a K ×(N −K) matrix(with convention 0 0 = 1). Considerb j−1ii=1,...,N−Kthe K × K identity matrix I K . Then, the linear code defined by the generator matrix:G := [I K |V (a 1 ,...,a K ) −1 V (b 1 ,...,b N−K )]47


4. A CODING APPROACH TO MULTICAST AUTHENTICATIONis MDS if and only if the a i , b j are N pairwise distinct elements.Notice that due to the presence of the identity matrix I K , each message to be encoded will appearas a part of its corresponding codeword. This means that this MDS code is in a systematic <strong>for</strong>m. Wenow introduce the algorithms EncodeMDS and DecodeMDS which will be used as subroutines in ourwork. We will encode K symbols S 1 ,...,S K into N modified symbols Ŝ1,...,ŜN . Each S i and Ŝjbelongs to (F 2 q) r . The choice of the efficiency parameter r will be explained in Section 4.4.Algorithm 4.1 EncodeMDSInput: The code length and dimension N and K, the polynomial Q(X) of degree q, the generatingmatrix G, K symbols S 1 ,...,S K and the efficiency parameter r.1. Parse each symbol S i into r field elements as: S i := Si 1‖ · · · ‖Sr i . Build r messages as:∀j ∈ {1,...,r} m j := (S j 1 · · · Sj K ).2. Encode the r messages into r codewords as: ∀j ∈ {1,...,r} c j := m j G.3. Write each codeword as: c j := (c j 1 · · · cj N) and build the N modified symbols as:∀j ∈ {1,...,N} Ŝj := c j 1 ‖ · · · ‖cj r.Output: N modified symbols: Ŝ1,...,ŜN .Algorithm 4.2 DecodeMDSInput: The code length and dimension N and K, the polynomial Q(X) of degree q, the generatingmatrix G, T(≥ K) elements {(j i ,Ŝj i),1 ≤ i ≤ T } and the efficiency parameter r.1. Reorder the T elements to have j 1 < ... < j T and pick the first K elements. Parse the Ŝj i’s as:∀i ∈ {1,...,K} Ŝj i= c ji1 ‖ · · · ‖cji r and write: ∀i ∈ {1,...,r} c ′ i := (cj1 i · · · c jKi ).2. Build G ′ as the restriction of G to columns j 1 ,...,j K and compute r messages as:∀i ∈ {1,...,r} m i := c ′ i G′ −1 .3. Write each message as: m j := (m 1 i · · · mK i ) where each mj i is deg(Q(X)) bits long. Recoverthe K symbols as: ∀i ∈ {1,...,K} S i = m i 1‖ · · · ‖m i r.Output: K symbols: S 1 ,...,S K .Notice that the polynomial Q(X) is used at Step 2 of Algorithm 4.1 and Algorithm 4.2 whenper<strong>for</strong>ming field operations.4.2 Overview of the ConstructionsIn this section, we give a general overview of our two protocols. As in [71, 87], we need a collisionresistant hash function h and an un<strong>for</strong>geable digital signature scheme (Sign SK , Verify PK ) whose keypair (SK,PK) is generated by the algorithm KeyGen.48


4.2. OVERVIEW OF THE CONSTRUCTIONSLT Code-based Construction. From the n data packets P 1 ,...,P n , we want to generate A = Naugmented packets AP 1 ,...,AP N such that if at most N − ⌈αN ⌉ of them are lost during transmissionthen the receiver can still recover all the P i ’s with probability at least 1 − δ (with δ close to0). Thus, to deal with erasures, we need to generate at least N := ⌈ m α ⌉ symbols E 1,...,E N fromP 1 ,...,P n using the LT code where m := n + (R + R 2 + · · · + Rn−R )ln ( ) (Rδ and R := c ln n) √δ n(see Theorem 4.1). In order to provide non-repudiation and to deal with bogus injections, we hash thesymbols along with the positions of their neighbors (necessary to rebuild the graph when decoding)and sign h 1 ‖ · · · ‖h N . As in [87], we build a polynomial A(X) of degree at most ρN (<strong>for</strong> some rationalconstant ρ), the coefficients of which represent h 1 ‖ · · · ‖h N ‖σ where σ is the block signature. Webuild the N augmented packets as: ∀i ∈ {1,...,N } AP i := BID‖i‖E i ‖N 1 i ‖ · · · ‖Ndi i ‖A(i) whereBID represents the position of the block P 1 ,...,P n in the whole data stream and d i is the degree ofE i .Upon reception of data, the receiver checks the signature by reconstructing the polynomial A(X)using MPR. Once the signature σ is verified, the receiver knows the original hashes h 1 ,...,h N . Thus,he can identify the correct E i ’s and their corresponding neighbors’ positions N 1 i ,...,Ndi ifrom thelist of elements he has got. According to the definition of α and N , there must be at least m correctsymbols from E 1 ,...,E N in his list. Finally, he corrects the erasures using the LT code and recoversthe n data packets P 1 ,...,P n with probability at least 1 − δ.MDS Code-based Construction. From the n data packets P 1 ,...,P n , we will construct A = naugmented packets AP 1 ,...,AP n such that if at most n − ⌈αn⌉ of them are lost during transmissionthen the receiver can still recover all the P i ’s. Thus, we need to encode these n packets using a[n, ⌈αn⌉,n − ⌈αn⌉ + 1] code. To per<strong>for</strong>m this encoding, the size of elements <strong>for</strong>ming the code’salphabet will be larger than the size of a data packet. In order to provide non-repudiation and todeal with bogus injections, we hash the modified symbols Ŝ1,...,Ŝn (generated by the MDS code)and sign the concatenation h 1 ‖ · · · ‖h n . As be<strong>for</strong>e, we build a polynomial A(X) of degree at mostρn, the coefficients of which represent h 1 ‖ · · · ‖h n ‖σ where σ is the block signature. We build theaugmented packets as: ∀i ∈ {1,...,n} AP i := BID‖i‖Ŝi‖A(i).As previously, upon reception of data, the receiver checks the signature by reconstructing thepolynomial A(X) using MPR. Once the signature σ is verified, the receiver knows the original hashesh 1 ,...,h n . Thus, he can identify the correct Ŝi’s amongst the list of elements he has got. Accordingto the definition of α there must be at least ⌈αn⌉ symbols from Ŝ1,...,Ŝn in his list. Finally, hecorrects the erasures using the MDS code and recovers the n data packets P 1 ,...,P n .49


4. A CODING APPROACH TO MULTICAST AUTHENTICATION4.3 LT Codes <strong>for</strong> <strong>Multicast</strong> Stream <strong>Authentication</strong>In this section, we will describe a multicast authentication protocol using LT codes which is robustagainst packet loss and data injection. Our technique also allows any new user to join the communicationgroup at any block boundary. We will demonstrate its security, exhibit a minimal bound <strong>for</strong>the packet recovery probability and show that the number of signature verifications per block at thereceiver is O(1) as a function of the block length n. Finally, we compare LT codes to other familiesof rateless codes to be used in our context.4.3.1 Our <strong>Authentication</strong> ProtocolAs said be<strong>for</strong>e, data are processed per block of n packets: P 1 ,...,P n . For our construction, weassume that α,β and δ are rational numbers. Thus, we can represent them over a finite number of bitsusing their numerator and denominator. In order to run Poly-Reconstruct as a subroutine of MPR, we( )have to choose ρ ∈ 0, α2β. Notice that ρ has to be rational since ρN is an integer. Since c is a fixedvalue of the Robust Soliton distribution, N only depends on n,δ and α. There<strong>for</strong>e, w.l.o.g., one canconsider that the value ρ is uniquely determined when n,α,β and δ are known. Table 4.1 summarizesthe scheme parameters which are assumed to be publicly known.n: Block length δ: Decoding failure probabilityα: Survival rate β: Flood rateA list of irreducible polynomials over F 2Tab. 4.1: Public parameters <strong>for</strong> our LT code-based schemeThe hash function h as well as Verify and PK are also assumed to be publicly known. We didnot include them in Table 4.1 since they can be considered as general parameters. For instance, hcan be SHA-256 while the digital signature can be a 1024-bit RSA signature. We denote H the digestbit length and S the bit length of a signature. Since h and the digital signature are publiclyknown, so are H and S. We denote τ par the tag representing the communication parameters, namely:τ par := n‖α‖β‖δ. It is assumed that the list of polynomials contains a single polynomial Q(X) perdegree value deg(Q(X)). The sender uses Algorithm 4.3 to construct the augmented packets.We first notice that, even when the channel rates α,β change, the structure of the LT code does notneed to be modified since we keep working with the same inputs P 1 ,...,P n and the same value c <strong>for</strong>the Robust Soliton distribution. Only the number N of encoding symbols to be generated increases.This is an advantage over LTT and PRABS since the size of their field as well as the rate of theircode have to be updated in case of modifications of network rates. In addition, it can be shown thatthe ratio N n(as a function of n) is asymptotically bounded by a constant (see Appendix C). Noticethat the list of irreducible polynomials over F 2 is used at Step 3 when per<strong>for</strong>ming polynomial eval-50


4.3. LT CODES FOR MULTICAST STREAM AUTHENTICATIONAlgorithm 4.3 AuthenticatorLTschemeInput: The secret key SK, the block number BID, Table 4.1 and n data packets P 1 ,...,P n .1. Compute N := ⌈ m α⌉ where m is defined in Section 4.2. Consider the n packets as input symbols<strong>for</strong> the LT code and build N encoding symbols: E 1 ,...,E N . Each symbol E i is associatedwith the positions of its d i neighbors Ni 1,...,Ndii . Compute the hashes: ∀i ∈ {1,...N }h i :=h(E i ‖Ni 1‖ · · · ‖Ndi i ).2. Compute the block signature σ as: σ = Sign SK (h(BID‖τ par ‖h 1 ‖ · · · ‖h N )) and <strong>for</strong>m the authenticationtag τ = h 1 ‖ · · · ‖h N ‖σ.3. Denote ξ the smallest element of N such that:⌈ ⌉HN + S + ξ≥ ⌈logρ N + 1 2 N ⌉ (4.1)Denote q the left hand side of Inequality (4.1). Write τ as the concatenation a 0 ‖ · · · ‖a ρ N of (ρ N +1) elements of F 2 q after suitable padding. Form the polynomial A(X) := a 0 + · · · + a ρ N X ρ Nand evaluate it in the first N points of F 2 q: ∀i ∈ {1,...,N } y i := A(i).4. Construct the augmented packets as:∀i ∈ {1,...,N }AP i := BID‖i‖E i ‖N 1 i ‖ · · · ‖N dii ‖y iOutput: {AP 1 ,...,AP N }: set of augmented packets.uations over F 2 q. Those evaluations work as follows. Since any element of F 2 q can be representedas λ 0 Y 0 + λ 1 Y 1 + ... + λ q−1 Y q−1 where each λ i belongs to F 2 , we define the first N elements as(0,...,0) , (1,0,...,0) , (0,1,0,...,0) , (1,1,0,...,0) and so on until the binary decompositionof (N − 1).The justification <strong>for</strong> the choice of q and the length of the pad of τ can be found in Appendix B.1.It should be noticed that the public values in Table 4.1 are sufficient to compute q and the pad length.The receivers use Algorithm 4.4 to authenticate data they collected. Note that when DecoderLTschemestops then the whole content of block BID is lost. Nevertheless, the definitions of α and βensure that this will never happen (see Theorem 4.4). From a practical point of view, one can chooseα small and β large enough so that the real threat of the opponent is bounded by those values. Nevertheless,inaccurate values, such as α = 10 −10 and β = 10 10 <strong>for</strong> instance, will lead to excessivecommunication overhead and computation. So, the values α and β set by the sender should accuratelyreflect the opponent actual ability. Developing techniques allowing the determination of such valuesare beyond the scope of this thesis.51


4. A CODING APPROACH TO MULTICAST AUTHENTICATIONAlgorithm 4.4 DecoderLTschemeInput: The public key PK, the block number BID, Table 4.1 and the set of received packets RP.1. Compute N . Write the received elements as BID i ‖j i ‖Ẽj ‖Ñ1 i j i‖ · · · ‖Ñ ˜d jij i‖ỹ ji and discardthose having BID i ≠ BID or j i /∈ {1,...,N }. Denote N the number of remaining packets. If(N < ⌈α n⌉ or N > ⌊β n⌋) then the algorithm stops.2. Rename the set of received packets {ÃP 1 ,...,ÃP N } and write each element as: ÃP i =BID‖j i ‖Ẽj ‖Ñ1 i j i‖ · · · ‖Ñ ˜d jij i‖ỹ ji where j i ∈ {1,...,N }. Compute q as in Step 3 of AuthenticatorLTscheme.Get the irreducible polynomial of degree q from the sender’s public list and runMPR on the set {(j i ,ỹ ji ),1 ≤ i ≤ N} to get a list {c 1 ,...,c µ } of candidates <strong>for</strong> signature verification.If MPR rejects that set then the algorithm stops.3. Initialize h ′ j := ∅ <strong>for</strong> j ∈ {1,...,N } and i := 1. While the list has not been exhausted (and thesignature not verified yet), pick c i and write it as h i 1‖ · · · ‖h i N ‖σi after removing the pad where eachh i k is H bits long. If Verify PK (h(BID‖τ par‖h i 1‖ · · · ‖h i N ),σi ) = TRUE then we set h ′ j = hi j <strong>for</strong>j ∈ {1,...,N } and break out the loop. Otherwise, increment i by 1 and start again the while loop.4. If (h ′ 1,...,h ′ N ) = (∅,...,∅) then the algorithm stops. Otherwise, set E′ λ:= ∅ <strong>for</strong> λ ∈{1,...,N }. For each ÃP i written as at Step 2, if h(Ẽj i ‖Ñ1 j i‖ · · · ‖Ñ ˜d jij i) = h λ then E ′ λ = Ẽj i,d ′ λ = ˜d ji and ∀ξ ∈ {1,..., ˜d ji }N ′ λξ = Ñξ j i.5. Pick the first ⌈αN ⌉ non-empty elements E ′ µ and decode the LT code using the E ′ µ’s as encodingsymbols with degree d µ and adjacent vertices positions N ′ µ1 ,...,N ′ µd µ. Get n input symbols{P ′ 1,...,P ′ n} (where some of them can be empty).Output: {P ′ 1,...,P ′ n}: set of authenticated packets.4.3.2 Security and Recovery of the SchemeSecurity of the Scheme. We will now analyze the security of our authentication scheme. We wantthe receivers to authenticate data despite malicious actions per<strong>for</strong>med by O. Similarly to [87], wegive the following definition:Definition 4.2 The collection of algorithms (KeyGen,AuthenticatorLTscheme,DecoderLTscheme)constitutes a secure and (α,β)-correct probabilistic multicast authentication scheme if no PPT opponentO can win with a non-negligible probability the following game:i) A key pair (SK,PK) is generated by KeyGen.ii) O is given: (a) The public key PK and (b) Oracle access to AuthenticatorLTscheme (but Ocan only issue at most one query with the same block identification tag BID).iii) O outputs (BID,n,α,β,ρ,δ, RP).O wins if one of the following happens:a) (violation of the correctness property) O succeeds to construct RP such that, even if it contains⌈α N ⌉ packets (amongst a total not exceeding ⌊β N ⌋ elements) of some authenticated52


4.3. LT CODES FOR MULTICAST STREAM AUTHENTICATIONpacket set AP <strong>for</strong> block identification tag BID, decoding failure probability δ and parametersn,α,β,ρ, the decoder authenticates some incorrect packets.b) (violation of the security property) O succeeds to construct RP such that the decoder outputs{P 1,...,P ′ n} ′ which is non-empty and was never authenticated by AuthenticatorLTscheme <strong>for</strong>the value BID, the probability δ and parameters n,α,β,ρ.The difference from the definition given in [87] is that the packets are authenticated by the receiverwith certain probability. In short, even if the receiver gets a set RP having at least ⌈αN ⌉ originalelements, the whole original set {P 1 ,...,P n } is recovered with some probability. Nevertheless,Definition 4.2 involves that no incorrect packets can be authenticated. That is: ∀i ∈ {1,...,n}P i ′ ∈{∅,P i } where P i ′ denotes the ith packet output by DecoderLTscheme. Lysyanskaya et al.showed thatLTT was secure and (α,β)-correct. Following their arguments, we obtain the following result.Theorem 4.3 The scheme (KeyGen, AuthenticatorLTscheme, DecoderLTscheme) is secure and(α,β)-correct.Proof.Assume that the scheme is either insecure or not (α,β)-correct. By definition, a PPT opponent Ocan break the scheme security or correctness with a non-negligible probability π(k) where k is thesecurity parameter setting up the digital signature and the hash function. As a probability is a measure[8, 122], we must have either cases:(1) With probability at least π(k)/2, O breaks the scheme correctness.(2) With probability at least π(k)/2, O breaks the scheme security.It should be noticed that since π(k) is a non-negligible function of k, so is π(k)/2.Point (1). We will demonstrate by contradiction that if O can break the scheme correctness in polynomialtime then either he can <strong>for</strong>ge the digital signature or he can find a collision <strong>for</strong> the hash functionin polynomial time as well.This will be proved by turning an attack breaking the (α,β)-correctness of our construction into asuccessful attack against either the digital signature or the hash function.For this attack, O will have access to the signing algorithm Sign SK (but O will not have access toSK itself). He can use the public key PK as well as the collision resistant hash function h. O willbe allowed to run AuthenticatorLTscheme whose queries are written as (BID i ,n i ,α i ,β i ,ρ i ,δ i , DP i )where DP i is the set of n i data packets to be authenticated. In order to get the corresponding output,53


4. A CODING APPROACH TO MULTICAST AUTHENTICATIONthe signature is obtained by querying Sign SK as a black-box at Step 2 of AuthenticatorLTscheme.According to our hypothesis, O broke the correctness of the construction. This means that, followingthe previous process, O managed to obtain values BID,n,α,β,ρ,δ and a set of received packets RPsuch that:• ∃i : (BID,n,α,β,ρ,δ) = (BID i ,n i ,α i ,β i ,ρ i ,δ i ).Denote DP = {P 1 ,...,P n }(= DP i ) the n data packets associated with this query and APthe response given to O. In particular, we denote σ the signature corresponding to DP andgenerated as in Step 2 of AuthenticatorLTscheme.• |RP ∩ AP| ≥ ⌈α N ⌉ and |RP| ≤ ⌊β N ⌋.• {P 1,...,P ′ n} ′ = DecoderLTscheme(PK, BID,n,α,β,ρ,δ, List, RP) where P j ′ /∈ {∅,P j} <strong>for</strong>some j ∈ {1,...,n}.In the previous statement, List designates the list of irreducible polynomials from Table 4.1. As saidin Section 4.3.1, it is assumed that List contains only one polynomial Q(X) per degree value and theelements N and q as well as the pad length l can be determined from the content of that table.Assume that the digital signature is un<strong>for</strong>geable and the hash function is collision resistant.Since |RP ∩ AP| ≥ ⌈α N ⌉ and |RP| ≤ ⌊β N ⌋, Step 1 of DecoderLTscheme ends successfully. Theconsistency of Poly-Reconstruct involves that the list returned by MPR at Step 2 contains the elementh 1 ‖ · · · ‖h N ‖σ corresponding to DP after removing the pad of length l.As the digital signature is un<strong>for</strong>geable and the hash function is collision resistant, the pair message/signaturegoing through the verification process at Step 3 correspond to DP. There<strong>for</strong>e, at theend of that step, we have:∀i ∈ {1,...,N }h ′ i = h(E i ‖N 1 i ‖ · · · ‖N dii )For the same reason as be<strong>for</strong>e, at the end of Step 4, either E i ′ = ∅ or we have:E i ′ = E i and d ′ i = d i and ∀ξ ∈ {1,...,d i } N i′ ξ = NξiThere are at least ⌈αN ⌉ ≤ m non-empty elements. So, at Step 5, either the LT decoder output the noriginal packets P 1 ,...,P n (which happens with probability at least 1−δ) or output χ elements alongwith n − χ empty symbols. Nevertheless, when looking at the LT decoding process [84], we notice54


4.3. LT CODES FOR MULTICAST STREAM AUTHENTICATIONthat the χ non-empty elements must belong to {P 1 ,...,P n } since they represent the data packetswhich were released from the ripple when it vanished (in other words, the decoding process of LTcodes is consistent). There<strong>for</strong>e, we get:∀i ∈ {1,...,n} P ′ i ∈ {∅,P i }We obtain a contradiction with our original hypothesis which stipulated:∃j ∈ {1,...,n} P ′ j /∈ {∅,P j }As a consequence, we deduce that either the hash function is not collision resistant or the digital signatureis not secure.Point (2). We will demonstrate by contradiction that if O can break the scheme correctness in polynomialtime then either he can <strong>for</strong>ge the digital signature or he can find a collision <strong>for</strong> the hash functionin polynomial time as well.We consider the same kind of reduction as in Point (1). The opponent O breaks the security of thescheme if one of the following holds:I. AuthenticatorLTscheme was never queried on input BID,n,α,β,ρ,δ and the decoding algorithmDecoderLTscheme does not reject RP, i.e. {P 1,...,P ′ n} ′ ≠ ∅ where:{P 1,...,P ′ n} ′ = DecoderLTscheme(PK, BID,n,α,β,ρ,δ, List, RP).II. AuthenticatorLTscheme was queried on input BID,n,α,β,ρ,δ <strong>for</strong> some data packets DP ={P 1 ,...,P n }. Nevertheless, the output of DecoderLTscheme verifies P j ′ /∈ {∅,P j} <strong>for</strong> somej ∈ {1,...,n}.Case I. Since DecoderLTscheme output some non-empty packets, Step 3 had to terminate successfully.Thus, it has been found a pair (h(BID‖n‖α‖β‖δ‖h 1 ‖ · · · ‖h N ),σ) such that:Verify PK (h(BID‖n‖α‖β‖δ‖h 1 ‖ · · · ‖h N ),σ) = TRUEIf O never queried AuthenticatorLTscheme <strong>for</strong> block tag BID then the previous pair is a <strong>for</strong>gery ofthe digital signature.If O queried AuthenticatorLTscheme <strong>for</strong> block tag BID then denote (BID, ˆn, ˆα, ˆβ, ˆρ, ˆδ) his query. Byhypothesis, we have:(BID, ˆn, ˆα, ˆβ, ˆρ, ˆδ) ≠ (BID,n,α,β,ρ,δ)55


4. A CODING APPROACH TO MULTICAST AUTHENTICATIONAs ρ is uniquely determined when n,α and β are given, we get:(BID, ˆn, ˆα, ˆβ, ˆδ) ≠ (BID,n,α,β,δ)There<strong>for</strong>e, the previous pair is a <strong>for</strong>gery of the signature scheme.Case II. We have the same situation as Point (1).□Thus, our authentication scheme is as secure and correct as LTT. In addition, the proof of Theorem4.3 shows that it is non-degrading as the receiver authenticates all the elements from |RP ∩ AP|.We will now study the packet authentication probability of our protocol.Recovery Property. We will now demonstrate that our scheme enables any receiver to recover then data packets with a good probability and the number of signature verifications to be per<strong>for</strong>med perblock is O(1) (as <strong>for</strong> LTT and PRABS). We also provide a non-asymptotic bound on this number ofverifications. We now present our main theorem <strong>for</strong> this construction.Theorem 4.4 Given the scheme (KeyGen, AuthenticatorLTscheme, DecoderLTscheme), <strong>for</strong> any BID,each receiver recovers the n original data packets P 1 ,...,P n with probability at least 1 − δ. In addition,the number of signature verifications to be per<strong>for</strong>med is upper bounded by:U(N) := min(⌊U 1 (N)⌋, ⌊U 2 (N)⌋)where: ⎧⎪ ⎨⎪ ⎩U 1(N) = 1ρ NU 2(N) =which is O(1) as a function of the block length n.( )1√α2 − βρ − 1 β+α 2 − βρ + 1 ρ√β2(α 2 − βρ) + 1 β 2 + 4 (1 − ρα)ρ + ρ 2 N 2 − 12(α 2 − βρ) ρ NThe proof of this theorem is a consequence of Appendix C and Theorem 4.6. We refer to thereader to the latter <strong>for</strong> details.4.3.3 Other Families of Rateless CodesIn this section, we compare the complexity of encoding/decoding LT, Online and Raptor codes. Indeed,the security, correctness and recovery property of our scheme only depend on the fact that theLT decoding algorithm is consistent which is also the case <strong>for</strong> Online and Raptor codes. In addition,we will also compare these families to the modified LT codes introduced by Harrelson et al.[63, 64].56


4.3. LT CODES FOR MULTICAST STREAM AUTHENTICATIONIn their work, they changed the construction of LT codes given by Luby [84] to fit them to their practicalimplementations without altering their optimality (i.e. if we generate enough symbols then we canhave δ ≃ 0). Their technique consists of modifying the way the neighbors of each encoding symbolE are chosen. As in [84], the degree d is chosen using the Robust Soliton distribution. Instead ofuni<strong>for</strong>mly choosing the d neighbors, Harrelson et al.proposed to uni<strong>for</strong>mly choose two integers a andb and to generate the positions of the d neighbors as ai + b <strong>for</strong> i ∈ {1,...,d}. Thus, it is useless toappend the neighbors to the encoding symbol <strong>for</strong> transmission since only E‖a‖b‖d needs to be sent.This means that the overhead per encoding symbol has a fixed and much smaller size than in [84].This is of particular interest in our case (Step 4 of AuthenticatorLTscheme) since our overhead perpacket is particularly limited and such a fixed size helps to avoid data congestion due to irregular flowof in<strong>for</strong>mation within the network.Contrary to block codes which use finite field operations to encode and decode data, these familiesof rateless codes rely on XOR operations over packets. Based on the work done in [63, 84, 89, 137],we built Table 4.2. Both Raptor and Online codes require preprocessing of data be<strong>for</strong>e encoding. In[89], Maymounkov proposed two different ways to do so <strong>for</strong> Online codes. The complexities shownin Table 4.2 correspond to the second method since the first technique involves a dependence betweenthe packet authentication probability and the number of packets per block. The notation ǫ δ means thatthe element depends on the decoding failure probability δ but is independent from n.Average number Number of encoding Decoding EncodingXOR operations symbols generated failure symbol<strong>for</strong> decoding probability overheadLT codes O(nlog(n/δ)) n + O( √ n log 2 (n/δ)) δ variableLT codes O(nlog(n/δ)) n + O(n 5/6 polylog(n,1/δ)) δ constant(modified)Online O(nlog(1/ǫ δ )) (1 + ǫ δ )n O(δ η ) variablecodes (fixed ǫ δ > 0) (fixed η > 0)Raptor O(nlog(1/ǫ δ )) (1 + ǫ δ )n δ variablecodes (fixed ǫ δ > 0)Tab. 4.2: Complexity comparison <strong>for</strong> different classes of rateless codesAccording to Table 4.2, Online and Raptor codes seem to have better encoding and decoding complexitiesthan LT codes. Nevertheless, Raptor codes were designed <strong>for</strong> the Binary Erasure channel(BEC) [47] since the efficiency of their preprocessing part relies on the existence on good pre-codesto achieve linear time <strong>for</strong> both encoding and decoding process. This is the property which is achievedby Tornado codes on BEC [86, 137]. Given our opponent model it is unlikely that BEC accuratelyrepresents the actions per<strong>for</strong>med by O. Nevertheless, a recent work by Palanki and Yedidia [105, 106]57


4. A CODING APPROACH TO MULTICAST AUTHENTICATIONsuggests that Raptor codes can still be practically more efficient than LT codes <strong>for</strong> our authenticationscheme. Indeed, they implemented both classes of codes on Additive White Gaussian Noise Channelsand Binary Symmetric Channels [33] and noticed that, even on these channels, Raptor codes outper<strong>for</strong>medLT codes <strong>for</strong> decoding. Etesami et al.[48] per<strong>for</strong>med analoguous implementations and theirresults exhibited the same behavior. They also showed that Raptor codes could per<strong>for</strong>m quite well onany arbitrary symmetric channel. This behavior was confirmed in [49, 73, 85]. The per<strong>for</strong>mance ofRaptor codes over other communication channels has been studied in [120, 147]. A recent survey byDemir and Aktaş showed that Raptor codes also outper<strong>for</strong>med RS codes (as used in LTT) <strong>for</strong> somemultimedia applications [40].As suggested by Harrelson et al.[63], it is possible to reduce the size of in<strong>for</strong>mation to be transmittedand achieve a regular packet overhead at the cost of extra symbols <strong>for</strong> decoding (see Table 4.2).Since achieving a uni<strong>for</strong>m throughput within the communication channel avoids data congestion, substitutingoriginal LT codes by their modifications in our authentication protocol is recommended (thevalue of N in Theorem 4.1 has to be updated consequently). Since Raptor codes are the concatenationof an erasure code (as Tornado codes <strong>for</strong> instance) and a LT code, these modifications can alsobe applied to these codes. There<strong>for</strong>e, we believe that practical implementations of the authenticationscheme described in Section 4.3 will be even more efficient when substituting LT codes by Raptorcodes (exhibiting the same modifications <strong>for</strong> their internal LT coding).Nevertheless, these threshold values enabling recovery of the n data packets can still be too important<strong>for</strong> some applications. Karp et al.[72] gave a <strong>for</strong>mula expressing the probability of non-decodingu packets amongst n after receiving a fixed value of encoding symbols which can be chosen by thesender. This can be useful if the application which will run the received packets has a tolerance rate<strong>for</strong> loss of content. The sender computes the number of packets he has to transmit in order to achieveat most this rate of non-recovered packets.4.4 MDS Codes <strong>for</strong> <strong>Multicast</strong> Stream <strong>Authentication</strong>In this section, we describe a multicast authentication protocol using MDS codes which is robustagainst packet loss and data injection. As in Section 4.3, our technique allows any new user to jointhe communication group at any block boundary. We will demonstrate its security, recovery propertyand show that the number of signature verifications per block at the receiver is O(1) as a function ofthe block length n. Finally, we justify our choice <strong>for</strong> Lacan and Fimes’ construction.58


4.4. MDS CODES FOR MULTICAST STREAM AUTHENTICATION4.4.1 Our <strong>Authentication</strong> ProtocolThe values n,α,β and ρ are the same as in Section 4.3.1. In particular, we assume that ρ is uniquelydetermined when n,α and β are known. In order to have ⌈α n⌉ symbols of equal length (<strong>for</strong> encoding)we must pad P 1 ‖ · · · ‖P n with ˜l zeros appropriately (see Step 1 of Algorithm 4.5). Then,we can split P 1 ‖ · · · ‖P n ‖0˜l into n symbols S 1 ,...,S ⌈α n⌉ where each S i is ˜q bits long with ˜q :=⌈ ⌉. The efficiency parameter r is chosen by the sender as a divisor of ˜q such that the receiversn P⌈αn⌉can efficiently per<strong>for</strong>m computations over the field F 2 s where s := ˜q r. Notice that the smaller r is,the larger the number of messages to be encoded at Step 2 of EncodeMDS is. Table 4.3 summarizesthe scheme parameters which are assumed to be publicly known. We denote τ par the tag representingthe communication parameters, namely: τ par := n‖α‖β‖P.n: Block length r: Efficiency parameter of the MDS codeα: Survival rate β: Flood rateP: Packet size (in bits) G: Generating matrix of the MDS codeA list of irreducible polynomials over F 2Tab. 4.3: Public parameters <strong>for</strong> our MDS code-based schemeAlgorithm 4.5 AuthenticatorMDSschemeInput: The secret key SK, the block number BID, Table 4.3 and n data packets P 1 ,...,P n .1. Compute: ˜b = nP mod ⌈α n⌉. Denote ˜l as ˜l := (0 if⌈˜b = 0) ⌉ or (⌈α n⌉ − ˜b otherwise). WriteP 1 ‖ · · · ‖P n ‖0˜l as S 1 ‖ · · · ‖S ⌈α n⌉ where each S i is ˜q := bits long.nP⌈α n⌉2. Pick the polynomial ˜Q(X) of degree s = ˜qr from the list. Compute (Ŝ1, · · · ,Ŝn) =EncodeMDS(n, ⌈αn⌉, ˜Q(X),G,S 1 ,...,S ⌈α n⌉ ,r).3. Compute: ∀i ∈ {1,...,n}h i = h(Ŝi) and <strong>for</strong>m the authentication tag τ := h 1 ‖ · · · ‖h n ‖σwhere σ is computed as: σ = Sign SK (h(BID‖τ par ‖h 1 ‖ · · · ‖h n )).4. Denote ξ the smallest element of N such that:⌈ ⌉H n + S + ξ≥ ⌈logρn + 1 2 n⌉ (4.2)Denote q the left hand side of Inequality (4.2). Write τ as the concatenation a 0 ‖ · · · ‖a ρ N of (ρ N +1) elements of F 2 q after suitable padding. Form the polynomial A(X) := a 0 + · · ·+a ρ n X ρ n andevaluate it in the first n points of F 2 q: ∀i ∈ {1,...,n} y i := A(i).5. Construct the augmented packets as:∀i ∈ {1,...,n}AP i := BID‖i‖Ŝi‖y iOutput: {AP 1 ,...,AP n }: set of augmented packets.The value of q as well as the pad occurring at Step 4 can be found in Appendix B.2. For ourconstruction, we can assume, w.l.o.g., that, when the field, length and dimension of the MDS codeare known then the couple (G,r) is unique so that knowing (n,α,β, P) (representing τ par ) is enough59


4. A CODING APPROACH TO MULTICAST AUTHENTICATIONto determine each step of AuthenticatorMDSscheme.The receivers process in<strong>for</strong>mation using Algorithm 4.6.Algorithm 4.6 DecoderMDSschemeInput: The public key PK, the block number BID, Table 4.3 and the set of received packets RP.1. Write the packets as BID i ‖j i ‖˜S ji ‖ỹ ji and discard those having BID i ≠ BID or j i /∈ {1,...,n}.Denote N the number of remaining elements. If (N < ⌈α n⌉ or N > ⌊β n⌋) then the algorithmstops.2. Rename the remaining elements as {ÃP 1 ,...,ÃP N } and write each element as: ÃP i =BID‖j i ‖˜S ji ‖ỹ ji where j i ∈ {1,...,n}. Compute q as in Step 3 of AuthenticatorMDSscheme.Get the irreducible polynomial of degree q from the sender’s public list and run MPR on the set{(j i ,ỹ ji ),1 ≤ i ≤ N} to get a list {c 1 ,...,c µ } of candidates <strong>for</strong> signature verification. If MPRrejects that set then the algorithm stops.3. Initialize h ′ j = ∅ <strong>for</strong> j ∈ {1,...,n}. While the list has not been exhausted (and the signaturenot verified yet), pick c i and write it as: h i 1‖ · · · ‖h i n‖σ i after removing the pad where each h i k is Hbits long. If Verify PK (h(BID‖τ par ‖h i 1‖ · · · ‖h i n),σ i ) = TRUE then set h ′ j = hi j <strong>for</strong> j ∈ {1,...,n}and break out the loop. Otherwise, increment i by 1 and start again the while loop.4. If (h ′ 1,...,h ′ n) = (∅,...,∅) then the algorithm stops. Otherwise, set Ŝ′ k:= ∅ <strong>for</strong> all k ∈{1,...,n}. For each ÃP i written as at Step 2, if h(˜S ji ) = h λ then Ŝ′ λ = ˜S ji .5. If we have less than ⌈α n⌉ non-empty symbols then the algorithm stops. Otherwise,denote Ŝ′ p 1 ,...,Ŝ′ p γthe non-empty elements. Decode them as: (S ′ 1,...,S ′ ⌈α n⌉ ) =DecodeMDS(n, ⌈α n⌉, ˜Q(X),G,(p 1 ,Ŝ′ p 1),...,(p γ ,Ŝ′ p γ),r) after computing ˜q and choosing˜Q(X) as in AuthenticatorMDSscheme.6. Remove the pad from S 1‖ ′ · · · ‖S⌈α ′ n⌉ and write the remaining string as P 1‖ ′ · · · ‖P n ′ where eachP i ′ is P bits long.Output: {P ′ 1,...,P ′ n}: set of authenticated packets.4.4.2 Security and Recovery of the SchemeSecurity of the Scheme. Similarly to [87], we give the following definition:Definition 4.3 The collection of algorithms (KeyGen, AuthenticatorMDSscheme, DecoderMDSscheme)constitutes a secure and (α,β)-correct probabilistic multicast authentication scheme if no PPTopponent O can win with a non-negligible probability the following game:i) A key pair (SK,PK) is generated by KeyGen.ii) O is given: (a) the public key PK and (b) oracle access to AuthenticatorMDSscheme (but Ocan only issue at most one query with the same block identification tag BID).iii) O outputs (BID,n,α,β,ρ, P, RP).60


4.4. MDS CODES FOR MULTICAST STREAM AUTHENTICATIONO wins if one of the following happens:a) (violation of the correctness property) O succeeds to construct RP such that even if it contains⌈α n⌉ packets (amongst a total not exceeding ⌊β n⌋ elements) of some authenticated packet setAP <strong>for</strong> block identification tag BID and parameters n,α,β,ρ, P, the decoder fails to authenticateall the correct packets.b) (violation of the security property) O succeeds to construct RP such that the decoder outputs{P 1,...,P ′ n} ′ that was never authenticated by AuthenticatorMDSscheme <strong>for</strong> the value BIDand parameters n,α,β,ρ, P.The difference between Definition 4.2 and Definition 4.3 is that the latter requires total recoveryof all data elements. In Definition 4.2, Points a) and b) mean that the decoder cannot output packetsP j ′ such that P j ′ /∈ {∅,P j }. This is the same definition as <strong>for</strong> LTT. Our new definition stipulatesthat it cannot output packets P j ′ ≠ P j. This is due to the fact that we use an erasure correctingcode allowing complete recovery of the stream. Definition 4.3 can be seen as the generalization ofDefinition 4.2 when the decoding failure probability δ is 0. As a consequence, if an authenticationscheme (KeyGen,Authenticator,Decoder) is secure and correct as specified by Definition 4.3 then itis also secure and correct according to Definition 4.2. We have the following result <strong>for</strong> our MDScode-based protocol.Theorem 4.5 Our scheme (KeyGen, AuthenticatorMDSscheme, DecoderMDSscheme) is secure and(α,β)-correct.The proof is analogous to the proof of Theorem 4.3 and can be found in Appendix A.1.Recovery Property. We will now demonstrate that our scheme enables any receiver to recover the ndata packets (as in [71]) and the number of signature verifications to be per<strong>for</strong>med per block is O(1)(as in [71, 87]). As in Section 4.3.2, we provide a non-asymptotic bound on the number of signatureverification queries.Theorem 4.6 Given the scheme (KeyGen, AuthenticatorMDSscheme, DecoderMDSscheme), <strong>for</strong> anyBID, each receiver recovers the n original data packets P 1 ,...,P n . In addition, the number of signatureverifications to be per<strong>for</strong>med is upper bounded by U(n) (where the function U(·) is defined inTheorem 4.4) which is O(1) as a function of the block length n.Proof.We decompose this proof into three parts. In the first one, we will demonstrate the recovery propertyof our scheme. In the second one, we will prove that U(n) is an upper bound on the number ofsignature verifications to be per<strong>for</strong>med per block <strong>for</strong> our construction. Finally, we will show that this61


4. A CODING APPROACH TO MULTICAST AUTHENTICATIONbound is O(1) as a function of the block length n. Since our results have to be valid <strong>for</strong> any valueBID, we start our proof by picking a value BID which will remain fixed throughout this proof.Packet Recovery: By definition of the rates, at least ⌈α n⌉ of the original elements {AP 1 ,...,AP n }are received by the receiver amongst a total of no-more than ⌊β n⌋ elements. Thus, the demonstrationof Theorem 4.5 shows that DecoderMDSscheme returns P 1 ,...,P n since the digital signature isun<strong>for</strong>geable and the hash function is collision resistant.The difference <strong>for</strong> our LT code-based construction is that, at Step 5, DecoderLTscheme recoversall n packets P 1 ,...,P n with probability at least 1 − δ as decoding is probabilistic.Signature Verifications: Since at most one signature verification is per<strong>for</strong>med per element of the listoutput by MPR, it is sufficient to prove that U(n) is an upper bound on the size of that list since MPRis queried only once.Denote N the number of points on which Poly-Reconstruct is run and T the number of originalelements in this list. By definition of α and β, we have: T ≥ ⌈α n⌉ and N ≤ ⌊β n⌋. As noticedbe<strong>for</strong>e, we have: T > √ (ρn)N which guarantees Poly-Reconstruct to be run successfully. DenoteL(N,T) the size of the list output by Poly-Reconstruct. We want to prove: L(T,N) ≤ U(n).According to the proof of Proposition 6.15 in Guruswami’s thesis [58], we have: L(T,N) ≤ ⌊ l k ⌋where: ⎧⎪ ⎨ l = r T − 1⌊k N + √ ⌋k⎪ ⎩ r = 1 +2 N 2 + 4(T 2 − k N)2(T 2 − k N)In our case, k = ρn. There<strong>for</strong>e, an upper on L(T,N) is given by:Tρn(1 + (ρn)N + √ (ρn) 2 N 2 + 4(T 2 − (ρn)N)2(T 2 − (ρn)N))− 1ρn(4.3)1 st bound: We have: ∀(a,b) ∈ R + × R + √ a + b ≤ √ a + √ b. We deduce that L(T,N) is upperbounded by:62Tρn(1 + (ρn)NT 2 − (ρn)N + 1√T2− (ρn)N)− 1ρn


4.4. MDS CODES FOR MULTICAST STREAM AUTHENTICATIONUsing T ≥ ⌈α n⌉, we deduce that T 2 − (ρn)N is lower bounded by n 2 (α 2 − β ρ). This element ispositive since ρ < α2β . Thus:L(T,N) ≤ Tρn(1 +)ρNn(α 2 − β ρ) + 1n √ − 1α 2 − β ρ ρnSince T ≤ n and N ≤ ⌊β n⌋, U 1 (n) is an upper bound of the right hand side of the previous inequality.Since L(T,N) is an integer we get: L(T,N) ≤ ⌊U 1 (n)⌋.2 nd Tbound: We start again from (4.3). Since T ≤ n we have:ρ n ≤ 1 ρ. The numerator of the fraction√is upper bounded by β ρn+ (β ρn 2 ) 2 + 4(n 2 − ραn 2 ). As be<strong>for</strong>e, T 2 −(ρn)N is lower boundedby n 2 (α 2 − β ρ). There<strong>for</strong>e:L(T,N) ≤ 1 ρ⎛ √⎝1 + β ρ +⎞(β ρ) 2 + 4 n(1 − ρα) 22(α 2 − β ρ)⎠ − 1ρnThe right hand side of the previous inequality is equal to U 2 (n). There<strong>for</strong>e, we have: L(T,N) ≤⌊U 2 (n)⌋.Finally, we obtain: L(T,N) ≤ min(⌊U 1 (n)⌋, ⌊U 2 (n)⌋) which means L(T,N) ≤ U(n).Concerning our LT code-based scheme, it is easy to see that U(N) is an upper bound on L(T,N) inthat case by substituting n by N in the above proof.Asymptotic Analysis: As in [87], we consider that ρ is a constant when studying the asymptoticbehavior of U(n). Nevertheless, ρn must be an integer. There<strong>for</strong>e, the limit of U(n) can only bestudied <strong>for</strong> values n in I := {n/ρn ∈ N}. A necessary and sufficient condition to study the limitin +∞ is to have an infinite number of elements in I since I is a subset of N. Remember that ρ isa (positive) rational number. Thus, we can write ρ = uρv ρwhere u ρ and v ρ are elements of N. If weconsider Nv ρ , the subset of N representing the multiples of v ρ , then: Nv ρ ⊂ I. Since Nv ρ is infinite,so is I. There<strong>for</strong>e, we can study the asymptotic behavior of U(n) as soon as ρ is a rational number.We have:limn→+∞n∈Ilimn→+∞n∈I( ) 1= 0ρn(√β 2 + 4 )ρ 2 n 2 (1 − ρα) = βThese two equations involve that U 2 (n) has a finite limit when n tends to +∞ (and n ∈ I). Thus, weget U 2 (n) ∈ O(1) and then ⌊U 2 (n)⌋ ∈ O(1).63


4. A CODING APPROACH TO MULTICAST AUTHENTICATIONThe left hand side equality involves that U 1 (n) has a finite limit when n tends to +∞ (and n ∈ I).As be<strong>for</strong>e we obtain: ⌊U 1 (n)⌋ ∈ O(1).Since U(n) = min(⌊U 1 (n)⌋, ⌊U 2 (n)⌋) we finally deduce: U(n) ∈ O(1) as a function of n.Concerning the LT code-based scheme, we could similarly demonstrate that U(N) ∈ O(1) as a functionof N . By construction, we have N ≥ n. In Appendix C, we showed that the ratio N nwas O(1) asa function of n. This involves that N ∈ O(n). There<strong>for</strong>e, N and n have the same order as functionsof n (i.e. N ∈ Θ(n)). As a consequence U(N) ∈ O(1) as a function of n as well which demonstratesTheorem 4.4.□It should be noticed that the bound U(n) is also valid <strong>for</strong> LTT.4.4.3 Coding ComplexityThe field used by the MDS code is F 2 s where s is defined as in Section 4.4.1. Our results are basedon the analysis done in [77]. Encoding a single message m i requires O(nlog 2 n) field operations.There<strong>for</strong>e, encoding the r messages needs O(r nlog 2 n) field operations. Similarly, decoding a singlec ′ i requires O(nlog2 2 n) field operations. Since r of them must be decoded, we get O(r nlog 2 2 n)as total decoding complexity. It is clear that r ∈ O(1) as a function of n. So, the previous twocomplexities become O(nlog 2 n) and O(nlog 2 2 n), respectively.In [71], it was suggested to use RS codes as erasure codes <strong>for</strong> PRABS. Since RS codes are MDS[88], it is natural to compare their efficiency to our MDS code’s one. Notice that the messages processedby PRABS’s code have the same number of symbols than ours but these symbols are takenfrom a smaller field than <strong>for</strong> our construction. In our survey, however, we focus on the number of fieldoperations to encode/decode data as it is the standard tool in coding theory to compare the efficiencyof two coding techniques since a fair comparison presumes that both codes are used over the samefield.In their work, Karlof et al. referred to the original paper by Reed and Solomon [124] to encode/decodedata. Based on this consideration, encoding/decoding a single m i /c ′ j requires O(n2 )field operations. Then, it is clear that our complexity <strong>for</strong> encoding/decoding are better. However,RS codes can be processed in a more efficient way than in [124] using the technique developed byGuruswami and Sudan in [62]. This technique which was used in [87] enables any message m i to beencoded in O(nlog 2 2 n) field operations and any codeword c ′ j to be decoded using O(n2 ) field operations.If their technique is to be used to encode/decode data in PRABS then the encoding complexity64


4.5. COMPARISON OF SCHEMESof our protocol increases by factor log 2 n (<strong>for</strong> the whole set of r messages) whereas the decodingcomplexity is reduced by a factor log2 2 nn(<strong>for</strong> the whole set of r codewords). We claim that, even inthis case, the code we have employed still gives more benefits than PRABS’s one. Indeed, in our networkmodel the sender is assumed to be more computationally powerful than the receivers. There<strong>for</strong>e,he can cope with the small increasing factor log 2 n since n will be roughly 1000 in practical applications.At the same time, the receivers take advantage of the complexity reduction from quadratic(using RS codes) to sub-quadratic (with our technique).After treating the case of RS codes, it remains to argue that our MDS code construction givesbetter complexity <strong>for</strong> encoding/decoding than other MDS codes used in practical implementations.In [77], Lacan and Fimes pointed out that in computer communication, erasure codes were used insystematic <strong>for</strong>m. They also emphasized that systematic MDS codes employed in practical applicationsrelied on either Cauchy or Vandermonde matrices to generate the redundancy symbols. Theyproved that their code construction exhibited better complexity <strong>for</strong> both encoding and decoding thanany other systematic MDS code relying on either matrix construction.Based on these observations, we claim that using Lacan and Fimes’ codes <strong>for</strong> our authenticationscheme gives us an optimal erasure correcting technique <strong>for</strong> data streaming over a multicast network.4.5 Comparison of SchemesIn this section, we compare our two authentication schemes. We survey three critical points: thesignature complexity, the packet overhead and the computational cost of our erasure correcting codes.4.5.1 Signature ComplexityAs said in Section 4.4.2, U(n) is also a bound <strong>for</strong> LTT. According to Theorem 3 from [71], the number⌋ ⌋of signature verifications <strong>for</strong> PRABS is upper bounded by V (n) := + 1 = .⌊⌊β n⌋−⌈α n⌉⌈α n⌉⌊⌊β n⌋⌈α n⌉Since V (n) ≤ β α , it is clear that V (n) is O(1) and V (n) ≤ ⌊U 1(n)⌋. We compare the uppers boundson the number of signature verifications to be per<strong>for</strong>med per block in Table 4.4. As in [118], wechose n = 1000. We considered ρ equal to 10%,30%,50%,70% and 90% of the threshold α2β <strong>for</strong>each couple (α,β). The reader may notice that some values 1000ρ are not integers (as it should be<strong>for</strong> our scheme). We committed this abuse because our main goal was to exhibit the behavior of U(n)<strong>for</strong> a realistic value n. If we had been to be consistent with the fact that ρn is an integer then thesmallest integer n valid <strong>for</strong> all couples (α,β) in our table should have been 132,000 which is nota realistic assumption <strong>for</strong> the block length n. In addition, we set the value c <strong>for</strong> the LT code as the65


4. A CODING APPROACH TO MULTICAST AUTHENTICATIONmiddle of the allowed interval, i.e.:and picked δ = 0.1 and η = 1 4 .c =12 ln(n/δ)( √ ) nη n2 + n − 1Notice that, as claimed in Section 4.1.2, c is independent of both rates α and β. Thus, it is notaffected by variations of those values which provides stability <strong>for</strong> the code structure throughout thecommunication process.(α,β)(0.5,1.1) (0.5,1.25) (0.5,1.5) (0.5,2)10% 48|48|2 55|55|2 66|66|3 88|88|430% 20|20|2 23|23|2 28|28|3 38|38|450% 17|17|2 19|19|2 23|23|3 31|31|470% 20|20|2 23|23|2 28|28|3 38|38|490% 48|48|2 55|55|2 66|66|3 88|88|4(α,β)(0.75,1.1) (0.75,1.25) (0.75,1.5) (0.75,2)10% 21|21|1 24|24|1 29|29|2 39|39|230% 9|9|1 10|10|1 12|12|2 16|16|250% 7|7|1 8|8|1 10|10|2 14|14|270% 9|9|1 10|10|1 12|12|2 16|16|290% 21|21|1 24|24|1 28|28|2 36|36|2(α,β)(0.8,1.1) (0.8,1.25) (0.8,1.5) (0.8,2)10% 19|19|1 21|21|1 26|26|1 34|34|230% 8|8|1 9|9|1 11|11|1 14|14|250% 6|6|1 7|7|1 9|9|1 12|12|270% 8|8|1 9|9|1 10|10|1 14|14|290% 19|19|1 21|21|1 26|26|1 34|34|2(α,β)(0.9,1.1) (0.9,1.25) (0.9,1.5) (0.9,2)10% 15|15|1 17|17|1 20|20|1 27|27|230% 6|6|1 7|7|1 8|8|1 11|11|250% 5|5|1 6|6|1 7|7|1 9|9|270% 6|6|1 7|7|1 8|8|1 11|11|290% 15|15|1 17|17|1 20|20|1 27|27|2Tab. 4.4: Upper bounds <strong>for</strong> our LT code-based and MDS code-based schemes and PRABSWe first notice that U(N) and U(n) are identical <strong>for</strong> our choice of parameters. This can be explainedby the fact that N and n only interfere via denominators. There<strong>for</strong>e, the behavior of U 1 (N)and U 1 (n) is controlled byβα 2 −βρ + 1 ρ while U β2(N) and U 2 (n) mainly depend on2(α 2 −βρ) + 1 ρ . Table4.4 also clearly shows that V (n) is much smaller than U(n) (and U(N)). Nevertheless, this lowvalue of V (n) is precisely due to the fact that each augmented packet carries ⌈log 2 n⌉ hashes since66


4.5. COMPARISON OF SCHEMESthe hashes are used to partition the received elements into (at most) V (n) sets. Thus, a logarithmicnumber of hashes per augmented packet is the price paid by Karlof et al.to achieve low number ofsignature verifications. As noted earlier, this is impractical since such large packets can cause congestionin the network throughput. Table 4.4 results suggest that U(n) is minimal when ρ is roughlyhalf the threshold value α2β .Notice that if ρ is too small then the size of the field used <strong>for</strong> polynomial evaluations gets largerwhich can result in a prohibitive computational cost <strong>for</strong> some of the receivers. There<strong>for</strong>e, the sendermust pay attention to the choice of ρ when setting up the scheme in order to have a balanced trade-offbetween the efficiency of field operations and a reasonable number of signature verifications to per<strong>for</strong>m.In Table 4.5, we computed the ratio U(n)nwhich represents an upper bound on the average numberof signature verifications to be per<strong>for</strong>med at the receiver per data packet. In this table, we considered:ρ = α22 β . 4.5.2 Packet OverheadThe packet overhead is the length of the extra tag of in<strong>for</strong>mation used to provide authentication. Noticethat an augmented packet without a tag is assumed to be written as: BID‖i‖P i . Remember thatthe bit size of each data packet P i is P.LT Code-based Scheme. Its augmented packets are written as BID‖i‖E i ‖N 1 i ‖ · · · ‖Ndi i ‖y i , whereE i has the same length as the original packets, each N j i ∈ {1,...,n} and y i ∈ F 2 q. So, our packetoverhead is:⌈ ⌉H N + S + ξd i (⌊log 2 n⌋ + 1) +ρ N + 1As d i varies from symbol to symbol, this yields to an irregular overhead. However, if we usethe modified version of LT codes proposed by Harrelson et al. [63], then the augmented packets arewritten as BID‖i‖E i ‖a‖b‖d i ‖y i , where a,b,d i ∈ {1,...,n} (see Section 4.3.3). In that case, the bitsize of the overhead is:⌈ H N ′ + S + ξ ′ ⌉3(⌊log 2 n⌋ + 1) +ρ N ′ ,+ 1where N ′ := ⌈ m′α ⌉ with m′ (> m) being the new bound guaranteeing decoding failure with probabilityat most δ and ξ ′ is the smallest element of N such that:⌈ H N ′ + S + ξ ′ ⌉ρ N ′ ≥ ⌈log+ 1 2 N ′ ⌉67


4. A CODING APPROACH TO MULTICAST AUTHENTICATION(α,β)(0.5,1.1) (0.5,1.25) (0.5,1.5) (0.5,2)50 0.34 0.40 0.48 0.64100 0.17 0.19 0.23 0.31200 0.09 0.10 0.12 0.16n 500 0.04 0.04 0.05 0.071000 0.02 0.02 0.03 0.041500 0.02 0.02 0.02 0.03(α,β)(0.75,1.1) (0.75,1.25) (0.75,1.5) (0.75,2)50 0.15 0.16 0.20 0.29100 0.08 0.08 0.10 0.15200 0.04 0.04 0.05 0.08n 500 0.02 0.02 0.02 0.031000 0.01 0.01 0.01 0.021500 0.01 0.01 0.01 0.01(α,β)(0.8,1.1) (0.8,1.25) (0.8,1.5) (0.8,2)50 0.12 0.15 0.18 0.24100 0.06 0.08 0.09 0.12200 0.03 0.04 0.05 0.06n 500 0.02 0.02 0.02 0.031000 0.01 0.01 0.01 0.021500 0.01 0.01 0.01 0.01(α,β)(0.9,1.1) (0.9,1.25) (0.9,1.5) (0.9,2)50 0.10 0.12 0.15 0.18100 0.05 0.06 0.08 0.09200 0.03 0.03 0.04 0.05n 500 0.01 0.02 0.02 0.021000 0.01 0.01 0.01 0.011500 0.01 0.01 0.01 0.01Tab. 4.5: Evaluations of the ratio U(n)nBased on the work by Harrelson et al., we deduce that m ′ is equal to:⌈⌉A log 2 (n/δ)+ M (log 2 n) 3 n 2n 36A 3 B 2 + n 9−M/2 + 4B ,where:M := max(20,2(8 − log 2 (δ/6))/log 2 n)A := C A n 5/6 (log 2 n) 1/2 (log 2 (n/δ)) −1/2 M 1/6B := C B n −1/6 (log 2 n) 1/2 (log 2 (n/δ)) 1/2 M 1/668


provided that the elements C A and C B verify that:4.5. COMPARISON OF SCHEMESC B


4. A CODING APPROACH TO MULTICAST AUTHENTICATIONα0.5 0.75 0.8 0.91.1 2266|2755|3075 1032|1173|2903 912|1009|2882 728|754|2846β 1.25 2566|3057|3075 1167|1309|2903 1031|1129|2882 823|848|28461.5 3063|3560|3075 1391|1535|2903 1228|1328|2882 979|1006|28462 4048|4560|3075 1837|1986|2903 1621|1725|2882 1291|1321|2846Tab. 4.6: Bit size of the packet overhead <strong>for</strong> our LT code-based and MDS code-based schemes and PRABS4.5.3 Coding EfficiencyIn Section 4.4.3, we saw that the MDS code construction by Lacan and Fimes required O(n log 2 n)field operations <strong>for</strong> encoding and O(n log 2 2 n) field operations <strong>for</strong> decoding. The field of computationsis F 2 s where s ∈ O(˜q). As any field operation over F 2 s can be implemented in O(s 2 ) bitoperations [90], the complexity of encoding is O(ns 2 log 2 n) bit operations while decoding can beachieved in O(ns 2 log 2 2 n) bit operations.Harrelson et al. showed that the average number of packet XOR-ings was O(N log 2 (N/δ)) <strong>for</strong>both encoding and decoding. Notice that this value is also valid <strong>for</strong> the original LT codes designed byLuby [84]. Since each XOR-ing requires P bit operations, the total number of bit operations <strong>for</strong> ourrateless code based scheme is O(N log 2 (N/δ) P).The main difference between these two approaches rely on the bit complexity of basic operationswhich is linear in the input size <strong>for</strong> the rateless code construction while it becomes quadratic <strong>for</strong>the MDS code scheme. There<strong>for</strong>e, if the receivers have limited computational power then the firstapproach is to be privileged.4.6 ConclusionIn this chapter, we presented two multicast stream authentication protocols which can be consideredas extensions of LTT and PRABS. Our constructions provide non-repudiation of the sender and enablenew members to join the communication group at any block boundary. Unlike LTT and PRABS,our technique allows recovery of the original data packets. In addition, only O(1) signature verificationsare per<strong>for</strong>med per block. At the same time, our packet overheads are lower than PRABS’sin most situations which reduces the risk of network congestion. When per<strong>for</strong>ming video or audiostreaming <strong>for</strong> instance, the recovery property can be used to prevent audio gaps or frozen imageswhen playing the stream content. We also derived a non-asymptotic upper bound on the number ofsignature verifications to be per<strong>for</strong>med which can be used in practice to obtain an upper bound on theauthentication delay our schemes exhibit.70


4.6. CONCLUSIONWe proposed to use two different classes of codes. Our first approach, relying on rateless codes,exhibits a low complexity arithmetic while keeping reasonable overhead and thus represents an interestingsolution <strong>for</strong> end-users with limited computational power. Our second construction is based onblock codes with the following advantages. First, MDS codes, by definition, are redundancy optimal<strong>for</strong> correcting erasures. Second, the MDS code construction by Lacan and Fimes was proved in [77]to have a better complexity than most MDS codes used in practice. When compared to RS codes (asused in [87]), our erasure code encoding exhibited a slightly larger complexity which can however becompensated by the computational capacities of the sender. At the same time, the decoding complexityis much smaller than RS codes’ one which benefits to all receivers. We would like to point out thatthe discovery of faster encoding/decoding codes could improve the per<strong>for</strong>mance of our schemes.We are aware of the existence of linear time encoding/decoding (non-linear) codes [5, 60, 61, 65,131]. We did not use them <strong>for</strong> our protocol because their construction parameters were not flexibleenough to fit our network parameters. In addition, these codes are not MDS which involves extragenerationof symbols to achieve the same capacity of correction.71


5Multiple Block ConstructionsIn the previous chapter, we studied the case where the transmitter of in<strong>for</strong>mation processed data perblock of n packets to achieve real-time diffusion of digital content. However, in some situations, thesender may know several blocks of the data stream in advance. This is the case <strong>for</strong> delayed broadcastsuch as software updates or video-on-demand <strong>for</strong> instance. In this scenario, the sender is assumed tohave enough memory resources to store λ blocks of n packets.In this chapter, we present two data authentication schemes which generalize our MDS codebasedauthentication protocol presented in Chapter 4. As digital signatures generally take time to beverified, a single signature will be generated per family of λ blocks in our scheme. As a consequence,the receiver will only query MPR <strong>for</strong> signature verifications a single time <strong>for</strong> the whole family of λnpackets. In such a situation, our MDS code-based scheme would have required λ calls to MPR (one<strong>for</strong> each of block) leading to at most λU(n) signature verifications. Nevertheless, this benefit comesat the cost of extra hashes. There<strong>for</strong>e, we will also study the smallest value Λ(n) of the parameter λ<strong>for</strong> which our new protocol is faster than Λ(n) iterations of the MDS code-based construction. Wewill see that this value Λ(n) is small. For instance, we have Λ(n) = 2 up to n = 2000 when using a1024-bit RSA signature and SHA-256. This value <strong>for</strong> n is much larger than what Perrig et al.used to73


5. MULTIPLE BLOCK CONSTRUCTIONSimplement EMSS (n = 1000).Our second protocol will use Prediction Hashing (PH) to improve the computation time at thereceiver. This hashing approach will also enable to filter data packets upon reception and thus tosave memory as only genuine elements will be put into the receiver’s buffer while the others will bediscarded immediately. In addition, this improved construction will only require two queries to MPRper family of λ blocks which is much smaller than our previous approach using λ + 1 such calls (1<strong>for</strong> signature verifications and λ <strong>for</strong> recovering the hashes of each block).Despite data are processed by the sender per family of λ blocks, the augmented packets are stillsent into the network per block of n elements as in Chapter 4. This enables to maintain the joinabilityto the communication group at block boundaries while the use of the MDS code provides totalrecovery of the data stream. Even if our two protocols work with any MDS code, we suggest to usethe construction by Lacan and Fimes <strong>for</strong> the reasons explained in Section 4.4.3. As in the previouschapter, our two authentication protocols will be proved to be secure over the unsecured channelmodel.5.1 Overview of the ConstructionsIn this section, we give a general overview of our two protocols. As in Chapter 4, we need a collisionresistant hash function h and an un<strong>for</strong>geable digital signature scheme (Sign SK , Verify PK ) whose keypair (SK,PK) is generated by the algorithm KeyGen. As said above, we assume that the sender canbuffer λ blocks of n packets denoted B i := {P i,1 ,...,P i,n } <strong>for</strong> i ∈ {1,...,λ}.Multiple Block Scheme. We encode each block B i using a [n, ⌈α n⌉,n − ⌈α n⌉ + 1] code into thecodeword (Ŝi,1,...,Ŝi,n) <strong>for</strong> i ∈ {1,...,λ}. Then, we compute the corresponding λ block hashesh i := h(h(Ŝi,1)‖ · · · ‖h(Ŝi,n)) and sign h(h 1 ‖ · · · ‖h λ ) into σ. We build the family polynomialF(X) of degree at most ρn (<strong>for</strong> some constant ρ) the coefficients of which represent h 1 ‖ · · · ‖h n ‖σ.In order to allow new members to join the communication group at block boundaries, we build λblock polynomials B 1 (X),...,B λ (X) of degree at most ρn such as the coefficients of each B i (X)represent h(Ŝi,1)‖ · · · ‖h(Ŝi,n). The augmented packets of the family of λ blocks are such as:∀i ∈ {1,...,λ} ∀j ∈ {1,...,n} AP i,j := FID‖i‖j‖Ŝi,j‖B i (j)‖F(j),where FID represents the position of the family P 1,1 ,...,P λ,n within the whole stream. Figure 5.1illustrates the processing of data at the sender <strong>for</strong> this multiple block authentication scheme.74


5.1. OVERVIEW OF THE CONSTRUCTIONSB 1B λP 1,1 · · · P 1,n · · · P λ,1 · · · P λ,n❄ MDS ❄ ❄ MDS ❄Ŝ 1,1 · · · Ŝ 1,n · · · Ŝ λ,1 · · · Ŝ λ,n❄h 1 = h(h(Ŝ1,1)‖ · · · ‖h(Ŝ1,n))❄h λ = h(h(Ŝλ,1)‖ · · · ‖h(Ŝλ,n))B 1 (X)❄B 1 (1),...,B 1 (n)· · ·❘ ✠σ = Sign SK (h(FID‖τ par ‖h 1 ‖ · · · ‖h λ ))❄τ := h 1 ‖ · · · ‖h λ ‖σF(X)❄F(1),...,F(n)B λ (X)❄B λ (1),...,B λ (n)❄✙AP 1,j := FID‖1‖j‖Ŝ1,j‖B 1 (j)‖F(j)· · ·· · ·❥❄AP λ,j := FID‖λ‖j‖Ŝλ,j‖B λ (j)‖F(j)Fig. 5.1: Sender processing of data <strong>for</strong> our multiple block schemeUpon reception of data <strong>for</strong> the i th block, the receiver adapts his reaction depending on whether he hasalready verified the family signature or not.• If the signature is unknown then he uses MPR to reconstruct F(X) and thus to recover the λblock hashes h 1 ,...,h λ . Then, he runs MPR to reconstruct the block polynomial B i (X) correspondingto the n code coordinates digests h(Ŝi,1),...,h(Ŝi,n). Those hashes are identifiedusing h i . Then, the receiver browses the list of received packets to identify the code coordinatesconsistent with those hashes and he reconstructs {P i,1 ,...,P i,n } as <strong>for</strong> our MDS code-basedscheme.• If the signature is known then he only needs to use MPR to reconstruct the block polynomialB i (X) and he recovers {P i,1 ,...,P i,n } as above.Figure 5.2 illustrates the decoding algorithm <strong>for</strong> this multiple block authentication scheme.75


5. MULTIPLE BLOCK CONSTRUCTIONSÃP BID,j 1· · ·ÃP BID,j m· · · ✰Signature KnownNo✲List Decoding on F(j)’sYes❄List Decoding on B BID (j)’s✛Success❄ SuccessSignature VerificationFailureSuccess✰Ŝ BID,i 1· · ·· · ·Ŝ BID,i kFailure3Failure❄✮Reject❄P BID,1MDS· · ·❄P BID,nFig. 5.2: Receiver processing of data <strong>for</strong> block BID of our multiple block schemePH-based Scheme. We have λ blocks of packets {P i,1 ,...,P i,n } i=1,...,λ. In order to use PH, weproceed backwards. We encode the last block using the [n, ⌈α n⌉,n − ⌈α n⌉ + 1] code into thecodeword (Ŝλ,1,...,Ŝλ,n). Then, we append the hashes h(Ŝλ,1),...,h(Ŝλ,n) to the packets of blockλ − 1 and encode the resulting n elements into (Ŝλ−1,1,...,Ŝλ−1,n). We repeat this process to thefirst block of packets. We generate the family signature as <strong>for</strong> the multiple block authenticationscheme presented be<strong>for</strong>e. That is, we compute the λ block hashes h i := h(h(Ŝi,1)‖ · · · ‖h(Ŝi,n)) andsign h(h 1 ‖ · · · ‖h λ ) into σ. We build the family polynomial F(X) of degree at most ρn (<strong>for</strong> someconstant ρ) the coefficients of which represent h 1 ‖ · · · ‖h n ‖σ. In order to allow new members to jointhe communication group at block boundaries, we build λ block polynomials B 1 (X),...,B λ (X)of degree at most ρn such as the coefficients of each B i (X) represent h(Ŝi,1)‖ · · · ‖h(Ŝi,n). Theaugmented packets of the family of λ blocks are such as:∀i ∈ {1,...,λ} ∀j ∈ {1,...,n} AP i,j := FID‖i‖j‖Ŝi,j‖B i (j)‖F(j)where FID represents the position of the family P 1,1 ,...,P λ,n within the whole stream.Upon reception of data <strong>for</strong> the i th block, the receiver adapts his reaction whether he already knows itsdigests or not.76


5.1. OVERVIEW OF THE CONSTRUCTIONS• If the hashes are known (via PH) then he only needs to filter the received elements and dropthose which are inconsistent with those digests. Finally, he corrects erasures using the MDScode to recover the n data packets {P i,1 ,...,P i,n } as well as the n hashes corresponding toblock i + 1 which updates the values <strong>for</strong> PH.• If the hashes are unknown then he proceeds as in the multiple block scheme presented above.That is, he first checks whether the family signature corresponding to data he obtained is validby reconstructing F(X). If so, he checks whether the block in<strong>for</strong>mation is consistent with theprevious signature by reconstructing B i (X). Then, he sorts the received pieces of data anddrops those which are inconsistent with B i (X). Finally, he corrects erasures using the MDScode to recover the n data packets {P i,1 ,...,P i,n } as well as the n hashes corresponding toblock i + 1 which updates the values <strong>for</strong> PH.Figure 5.3 illustrates the decoding algorithm <strong>for</strong> the multiple block authentication scheme withfiltering. It uses as subroutines FilterElements and DecoderBlock. The latter is the decoding algorithmfrom the multiple block and is represented as Figure 5.2. Within the filtering scheme, however, it willquery once per family of λ blocks while FilterElements will be run λ − 1 times. This will create aspeed-up at the receiver as he will only per<strong>for</strong>m hash computations and erasure corrections as well asmemory savings since the buffered elements will be consistent with the original codewords (see proofof Theorem 5.1).ÃP BID,j 1· · ·ÃP BID,j m❥✙✲Hashes Known✛UpdateYes ✙❥ NoUpdateBrowse CoordinatesDecoderBlock✙RejectSuccessP BID,1❥· · ·✙P BID,nSuccess❥RejectFig. 5.3: Receiver processing of data <strong>for</strong> block BID of our filtering scheme77


5. MULTIPLE BLOCK CONSTRUCTIONS5.2 A Multiple Block <strong>Authentication</strong> SchemeThe multicast authentication scheme presented in this section is an extension of our MDS code-basedconstruction. Despite the sender processes the data stream per family of λ blocks, our techniquestill allows new users to join the communication group at any block boundary. We will demonstrateits security, recovery property and show that the number of signature verifications per block at thereceiver is O(1) as a function of both the block length n and the number of blocks λ.5.2.1 Our <strong>Authentication</strong> ProtocolWe adopt the same network model as in Chapter 4 and keep the same definitions <strong>for</strong> n,α,β and ρ.In particular, we assume that ρ is uniquely determined when n,λ,α and β are known. Each familyP 1,1 ,...,P λ,n of λn packets of the stream has an identification tag FID representing its positionwithin the whole stream. Each one of its blocks of n packets also has a tag BID. Thus, a packet isnow identified within the stream by its position i within a block BID belonging to the family FID, i.e.its identification number is (FID, BID,i). Algorithm 5.1 describes the family authenticator AuthenticatorFamilywhich outputs the augmented packets per block of n elements. For this construction,the tag τ par representing the communication parameters is defined as: τ par := n‖λ‖α‖β‖P. Table 5.1summarizes the parameters which are assumed to be publicly known <strong>for</strong> our multiple block scheme.n: Block length r: Efficiency parameter of the MDS codeα: Survival rate β: Flood rateP: Packet size (in bits) G: Generating matrix of the MDS codeλ: number of blocks per family A list of irreducible polynomials over F 2Tab. 5.1: Public parameters <strong>for</strong> our multiple block schemeIt should be noticed that we use the same pad as in Algorithm 4.5 <strong>for</strong> the erasure correcting code.The value of q as well as the pad occurring at Steps 3.1 and 5 can be found in Appendix B.3. Notethat the elements of Table 5.1 are enough to determine each step of AuthenticatorFamily.Since each block carries the signature, it is sufficient to run the signature verification process <strong>for</strong>family FID until one of its blocks makes the authentication process successful. There<strong>for</strong>e, when anew block of packets is received, the receiver must react differently depending on whether the familysignature has already been verified or not. We first design the signature verification routine VerifySignatureFamilydepicted as Algorithm 5.2.Now, we describe our block decoder DecoderBlock as Algorithm 5.3. The definition of theboolean TestSignature is necessary as we only check the family signature until it is verified by one78


5.2. A MULTIPLE BLOCK AUTHENTICATION SCHEMEAlgorithm 5.1 AuthenticatorFamilyInput: The secret key SK, the family number FID, Table 4.3 and λn data packets P 1,1 ,...,P λ,n ./* Packet Encoding */1. Encode each block {P i,1 ,...,P i,n } into the codeword (Ŝi,1 · · · Ŝi,n) as in Algorithm 4.5./* Block Identification */3. For i from 1 to λ do3.1. Parse h(Ŝi,1)‖ · · · ‖h(Ŝi,n) as b i,0 ‖ · · · ‖b i,ρ n where each b i ∈ F 2 q after padding and computethe block hash h i as h i := h(h(Ŝi,1)‖ · · · ‖h(Ŝi,n)).3.2. Construct the block polynomial B i (X) := b i,0 + b i,1 X + · · · + b i,ρ n X ρ n and evaluate it atthe first n points of F 2 q./* Signature Generation */4. Compute the family signature σ as σ := Sign SK (h(FID‖τ par ‖h 1 ‖ · · · ‖h λ )) and build the authenticationtag τ := h 1 ‖ · · · ‖h λ ‖σ.5. Denote ξ the smallest element of N such that:⌈ ⌉ H n + ξ≥ ⌈logρn + 1 2 n⌉ andDenote q the integer such that: q = max(⌈ ⌉H n+ξρ n+1,⌈ ⌉H λ + S + ξ≥ ⌈logρn + 1 2 n⌉⌈ ⌉)H λ+S+ξρ n+1. Write τ as the concatenationf 0 ‖ · · · ‖f ρ N of (ρ N + 1) elements of F 2 q after suitable padding. Form the family polynomialF(X) := f 0 + · · · + f ρ n X ρ n and evaluate it in the first n points of F 2 q./* Construction of Augmented Packets */6. Build the augmented packet AP i,j as AP i,j := FID‖i‖j‖Ŝi,j‖B i (j)‖F(j) <strong>for</strong> i ∈ {1,...λ} and<strong>for</strong> j ∈ {1,...,n}.Output: The λn augmented packets {AP 1,1 ,...,AP λ,n } which are sent to the network per block ofn elements {AP i,1 ,...,AP i,n } i=1,...,λ.block within the family FID. Once this has been done, the λ block hashes h 1 ,...,h λ are stored intoHashBlock and only block authentications are per<strong>for</strong>med. We assume that the boolean value TestSignatureis set to FALSE when a receiver joins the communication group and re-initialized to FALSEwhen the receiver processes the first received block of a new family FID ′ (> FID).Since a single signature is created per family of λ blocks, one might think that our scheme is onlyjoinable at a family boundary. Nevertheless, the elements F(1),...,F(n) are included within eachof the λ blocks of augmented packets. Thus, any receiver can join the communication group at anyblock boundary as <strong>for</strong> LTT, PRABS and our constructions from Chapter 4.5.2.2 Security and Recovery of the SchemeSecurity of the Scheme. Since the families of λ blocks are independent from each other, the securityof our scheme relies on the security of a family of λ blocks. We need to adapt Definition 4.3 to our79


5. MULTIPLE BLOCK CONSTRUCTIONSAlgorithm 5.2 VerifySignatureFamilyInput: The public key PK, the family number FID, Table 5.1 and a set of pairs of field elements{(x i ,y i ),1 ≤ i ≤ m}.1. Run MPR on {(x i ,y i ),1 ≤ i ≤ m} to get a list {c 1 ,...,c µ } of candidates <strong>for</strong> signatureverification. If MPR rejects this input then the algorithm stops.2. Initialize HashBlock = (∅,...,∅). While the list has not been exhausted (and the signaturenot verified yet), pick c i and write it as: h i 1‖ · · · ‖h i λ ‖σi after removing the pad where each h i k isH bits long. If Verify PK (h(FID‖τ par ‖h i 1‖ · · · ‖h i λ ),σi ) = TRUE then set HashBlock(j) = h i j <strong>for</strong>j ∈ {1,...,λ}.3. If the signature has not been verified then our algorithm stops.Output: HashBlock: the λ block hashes.family approach.Definition 5.1 The collection of algorithms (KeyGen, AuthenticatorFamily, DecoderBlock) constitutesa secure and (α,β)-correct multi-block multicast authentication scheme if no PPT opponent Ocan win with a non-negligible probability the following game:i) A key pair (SK, PK) is generated by KeyGen.ii) O is given: (a) the public key PK and (b) oracle access to Authenticator (but O can only issueat most one query with the same family identification tag FID).iii) O outputs (FID, BID,λ,n,α,β,ρ, P, RP).O wins if one of the following happens:a) (violation of the correctness property) O succeeds to construct RP such that even if it contains⌈α n⌉ packets (amongst a total not exceeding ⌊β n⌋ elements) of some authenticated packet setAP <strong>for</strong> family identification tag FID, block identification tag BID and parameters n,α,β,ρ, P,the decoder fails to authenticate all the correct packets.b) (violation of the security property) O succeeds to construct RP such that the decoder outputs{P BID,1,...,P ′ BID,n} ′ (<strong>for</strong> some BID ∈ {1,...,λ}) that was never authenticated by AuthenticatorFamilyas a part of a family of λ blocks <strong>for</strong> the family tag FID, the block value BID andparameters λ,n,α,β,ρ, P.We now demonstrate that the generalization of our MDS code-based authentication scheme satisfiesDefinition 5.1.Theorem 5.1 The multi-block authentication scheme (KeyGen, AuthenticatorFamily, DecoderBlock)is secure and (α,β)-correct.80


5.2. A MULTIPLE BLOCK AUTHENTICATION SCHEMEAlgorithm 5.3 DecoderBlockInput: The family number FID, the block number BID, Table 5.1, a boolean TestSignature, a tableHashBlock and a set of received packets RP.1. Write the packets as FID i ‖BID i ‖j i ‖˜S BIDi,j i‖B BIDi,j i‖F BIDi,j iand discard those having FID i ≠FID, BID i ≠ BID or j i /∈ {1,...,n}. Denote N the number of remaining packets. If(N < ⌈α n⌉ or N > ⌊β n⌋) then the algorithm stops.2. Rename the remaining elements as {ÃP 1 ,...,ÃP N } and write each of them as AP i =FID‖BID‖j i ‖˜S BIDi,j i‖B BIDi,j i‖F BIDi,j iwhere j i ∈ {1...,n}./* Signature Verification */3. If TestSignature = FALSE then run VerifySignatureFamily on the N points {(j i , F BID,j i),1 ≤ i ≤ N}. If it rejects the input then the algorithm stops. Otherwise, set TestSignature = TRUE./* Block Hashes Verification */4. Run MPR on the set {(j i , B BID,j i),1 ≤ i ≤ N} and get a list {c 1 ,...,c µ } of candidates <strong>for</strong>block hash verification. If MPR rejects that set then the algorithm stops.5. Initialize h ′ j = ∅ <strong>for</strong> j ∈ {1,...,n}. While the list has not been exhausted (and the hash<strong>for</strong> block BID has not been verified), pick c i and write it as: h i 1‖ · · · ‖h i n after removing the padwhere each h i k is H bits long. If (h(hi 1‖ · · · ‖h i n) = HashBlock(BID)) then set h ′ BID,j = hi j <strong>for</strong>j ∈ {1,...,n} and break out the loop. Otherwise, increment i by 1 and start again the while loop./* Packet Decoding */6. If (h ′ BID,1,...,h ′ BID,n) = (∅,...,∅) then the algorithm stops. Otherwise, set Ŝ′ k:= ∅ <strong>for</strong> allk ∈ {1,...,n}. For each ÃP i written as at Step 2, if h(˜S ji ) = h ′ BID,λ then Ŝ′ λ = ˜S ji .7. If we have less than ⌈α n⌉ non-empty symbols then the algorithm stops. Otherwise, denoteŜ ′ p 1 ,...,Ŝ′ p γthe non-empty elements. Decode them as in Algorithm 4.6 and denote the correspondingmessage (S ′ 1 · · · S ′ ⌈α n⌉ ).8. Remove the pad from S 1‖ ′ · · · ‖S⌈α ′ n⌉ and write the remaining string as P BID,1,...,P ′ BID,n ′ whereeach PBID,i ′ is P bits long.Output: {P ′ BID,1,...,P ′ BID,n}: set of authenticated packets <strong>for</strong> block BID.Proof.Assume that the scheme is either insecure or not (α,β)-correct. By definition, an opponent O canbreak the scheme security or correctness with a non-negligible probability π(k) where k is the securityparameter setting up the digital signature and the hash function. There<strong>for</strong>e, we must have either cases:(1) With probability at least π(k)/2, O breaks the scheme correctness.(2) With probability at least π(k)/2, O breaks the scheme security.As π(k) is a non-negligible function of k, so is π(k)/2.Point (1). We will demonstrate by contradiction that if O can break the scheme correctness in polynomialtime then either he can <strong>for</strong>ge the digital signature or he can find a collision <strong>for</strong> the hash functionin polynomial time as well.81


5. MULTIPLE BLOCK CONSTRUCTIONSThis will be proved by turning an attack breaking the (α,β)-correctness of our construction into asuccessful attack against either primitive.For this attack, O will have access to the signing algorithm Sign SK (but O will not have access toSK itself). He can use the public key PK as well as the collision resistant hash function h. O willbe allowed to run AuthenticatorFamily whose queries are written as (FID i ,λ i ,n i ,α i ,β i ,ρ i , P i , DP i )where DP i is the set of λ i n i data packets to be authenticated. In order to get the corresponding output,the signature is obtained by querying Sign SK as a black-box at Step 4 of AuthenticatorFamily.According to our hypothesis, O broke the correctness of the construction. This means that, followingthe previous process, O managed to obtain values FID,λ,n,α,β,ρ, P and a set of received packetsRP BID (<strong>for</strong> some BID ∈ {1,...,λ}) such that:• ∃i : (FID,λ,n,α,β,ρ, P) = (FID i ,λ i ,n i ,α i ,β i ,ρ i , P i )Denote DP = {P 1,1 ,...,P λ,n }(= DP i ) the λn data packets associated with this query andAP the response given to O. In particular, we denote σ the signature corresponding to DP andgenerated as in Step 4 of AuthenticatorFamily.• |RP BID ∩ AP BID | ≥ ⌈α n⌉ and |RP BID | ≤ ⌊β n⌋.• {P BID,1,...,P ′ BID,n} ′ = DecoderBlock(PK, FID, BID,n,α,β,ρ, P, TestSignature, HashBlock,RP BID ) where PBID,j ′ ≠ P BID,j <strong>for</strong> some j ∈ {1,...,n}.In the previous statement, AP BID denotes the subfamily of AP related to block number BID. We wouldalso like to draw the reader’s attention to the fact that O does not have any influence either on theboolean value TestSignature or the content of HashBlock as these two elements are updated by thereceiver personally. Thus, O must succeed in both following cases:A. the value of TestSignature is FALSE,B. the value of TestSignature is TRUE.Case A. Since |RP BID ∩ AP BID | ≥ ⌈α n⌉ and |RP BID | ≤ ⌊β n⌋, Step 1 ends successfully. Assume thatthe digital signature is un<strong>for</strong>geable and the hash function is collision resistant.In this situation, Step 3 terminates successfully <strong>for</strong> the same reasons as given in the proof of Theorem4.5. There<strong>for</strong>e, the content of HashBlock is consistent with AP BID , that is:∀i ∈ {1,...,n}HashBlock(i) = h i = h(h(Ŝi,1)‖ · · · ‖h(Ŝi,n))82


5.2. A MULTIPLE BLOCK AUTHENTICATION SCHEMEFor the same reason, the list output by MPR at Step 4 contains the element h(Ŝi,1)‖ · · · ‖h(Ŝi,n) (afterremoving the pad). The collision resistance of h involves that we have∀i ∈ {1,...,n} Ŝ ′ i = ∅ or Ŝ ′ i = ŜBID,iat the end of Step 6.Since |RP BID ∩ AP BID | ≥ ⌈α n⌉, the message recovered at the end of Step 7 is the original message(S 1 · · · S ⌈α n⌉ ). There<strong>for</strong>e, after removing the pad, the receiver recovers the n data packets correspondingto the block BID at the end of Step 8, that is:∀i ∈ {1,...,n}P ′ BID,i= P BID,iWe get a contradiction with our hypothesis which stipulated that:∃j ∈ {1,...,n}P ′ BID,j≠ P BID,jThere<strong>for</strong>e, either the hash function is not collision resistant or the digital signature is not secure.Case B. Since the boolean TestSignature is reinitialized to FALSE each time the first block of a newfamily is to be processed, we deduce that DecoderBlock was already successfully queried <strong>for</strong> familytag FID. Denote ˜BID the last block tag such that VerifySignatureFamily was successfully run.Due to our result from Case A, at the end of the query on block ˜BID, HashBlock contains the originaldigests h 1 ,...,h λ . Due to the design of DecoderBlock, the content of HashBlock is updatedwithin VerifySignatureFamily which is only queried while the family signature has not been verified.By definition of ˜BID, we know that VerifySignatureFamily is never queried <strong>for</strong> block number˜BID + 1,...,BID − 1. There<strong>for</strong>e, the content of HashBlock at the beginning of the query on blockBID (which is under attack by O) is still h 1 ,...,h λ .Using the same arguments as in Case A, it is easy to see that we have:∀i ∈ {1,...,n} Ŝ ′ i = ∅ or Ŝ ′ i = ŜBID,iat the end of Step 6 and thus the receiver recovers the n original data packets as output of BlockDecoder,that is:∀i ∈ {1,...,n} PBID,i ′ = P BID,i83


5. MULTIPLE BLOCK CONSTRUCTIONSAs be<strong>for</strong>e, we get a contradiction with our attack hypothesis and there<strong>for</strong>e we deduce that either thehash function is not collision resistant or the digital signature is not secure.Point (2). We will demonstrate by contradiction that if O can break the scheme correctness in polynomialtime then either he can <strong>for</strong>ge the digital signature or he can find a collision <strong>for</strong> the hash functionin polynomial time as well.We consider the same kind of reduction as in Point (1). The opponent O will succeed if one of thefollowing holds:I. AuthenticatorFamily was never queried on input FID,λ,n,α,β,ρ, P and the decoding algorithmDecoderBlock does not reject RP BID , i.e. {P BID,1,...,P ′ BID,n} ′ ≠ ∅ where:{P BID,1,...,P ′ BID,n} ′ = DecoderBlock(PK, FID, BID,n,α,β,ρ, P, TestSignature, HashBlock,RP BID ).II. AuthenticatorFamily was queried on input FID,λ,n,α,β,ρ, P <strong>for</strong> some data packets DP ={P 1,1 ,...,P λ,n }. Nevertheless, the output of DecoderBlock verifies P ′ BID,j ≠ P BID,j <strong>for</strong> someBID ∈ {1,...,λ} and some j ∈ {1,...,n}.Case I. As in Point (1), we have two cases to consider according to the value of TestSignature at thebeginning of the query on block BID.• Sub-case I.A. If the value of TestSignature is FALSE then DecoderBlock output a non-emptyset {P BID,1,...,P ′ BID,n} ′ after successfully querying VerifySignatureFamily at Step 3 as a subroutine.Thus, this algorithm was able to output a pair (h(FID‖λ‖n‖α‖β‖P‖h 1 ‖ · · · ‖h λ ),σ) (after removingthe pad) such that:Verify PK (h(FID‖n‖λ‖α‖β‖P‖h 1 ‖ · · · ‖h λ ),σ) = TRUEIf O never queried Authenticator <strong>for</strong> family tag FID then the previous pair is a <strong>for</strong>gery of the digitalsignature.If O queried Authenticator <strong>for</strong> family tag FID then denote (FID, ˜λ,ñ, ˜α, ˜β, ˜ρ, ˜P) his query. By hypothesis,we have:(FID, ˜λ,ñ, ˜α, ˜β, ˜ρ, ˜P) ≠ (FID,λ,n,α,β,ρ, P)84


5.2. A MULTIPLE BLOCK AUTHENTICATION SCHEMEAs in Chapter 4, we assumed that ρ was uniquely determined when n,λ,α,β were known. Thus, theprevious relation is equivalent to:(˜λ,ñ, ˜α, ˜β, ˜P) ≠ (λ,n,α,β, P)There<strong>for</strong>e, the pair output by VerifySignatureFamily is a <strong>for</strong>gery of the signature scheme.• Sub-case I.B. If the value of TestSignature is TRUE then it means that there exists an earlierblock (numbered ˜BID < BID) which was used to successfully verify a signature <strong>for</strong> parametersFID,λ,n,α,β,ρ, P. In this case, we can per<strong>for</strong>m on that earlier block the same reasoning as in theprevious case to obtain a contradiction with the security of either the signature scheme or the hashfunction.Case II. We have the same situation as Point (1) - Case A.□Thus, our multiple block construction is as secure and correct as the construction presented inChapter 4. As those two protocols, our scheme is non-degrading as the receiver recover all the elementsfrom RP BID ∩ AP BID .Recovery Property. We have the following result <strong>for</strong> our new construction.Theorem 5.2 For any FID, <strong>for</strong> any BID, each receiver recovers the n original data packets P BID,1,...,P BID,n. In addition, the number of signature verifications to be per<strong>for</strong>med <strong>for</strong> the whole family of λblocks is upper bounded by U(n) where U(·) is defined as in Theorem 4.4. Furthermore, U(n) isO(1) as a function of the block length n and the number of block λ.Proof.We first show that our scheme allows recovery of all data packets as part of this demonstration willbe used to deduce the bound on the number of signature verifications to be per<strong>for</strong>med <strong>for</strong> the wholefamily.Packet Recovery. Let FID be fixed. Due to the definition of the rates α and β, <strong>for</strong> each BID, thereceiver obtains, as set of received packets RP BID , at least ⌈α n⌉ original elements amongst a total notexceeding ⌊β n⌋ pieces of data.• We start focusing on the first block (i.e. BID = 1). As it is the first block of a new family,DecoderBlock queries VerifySignatureFamily as a subroutine. Based on the demonstration of The-85


5. MULTIPLE BLOCK CONSTRUCTIONSorem 5.1 (Point (1) - Case A), we deduce that the receiver recovers P 1,1 ,...,P 1,n and Hashblockcontains h 1 ,...,h λ .• We consider the second block (i.e. BID = 2). Since TestSignature is TRUE, DecoderBlock doesnot query VerifySignatureFamily as a subroutine. Based on the demonstration of Theorem 5.1 (Point(1) - Case B), we deduce that the receiver recovers P 2,1 ,...,P 2,n while the content of HashBlock isnot modified.• We see that when iterating this process we obtain total recovery of data <strong>for</strong> blocks 3,...,λ as wellsince HashBlock is not updated <strong>for</strong> this family any longer.Signature Verification. The previous proof showed that VerifySignatureFamily is only queried onceper family of λ blocks. There<strong>for</strong>e, the number of signature verifications is upper bounded by the sizeof the list constructed by VerifySignatureFamily. We are in the same situation as in Theorem 4.4. So,we get:• the list size is upper bounded by U(n).• U(n) ∈ O(1) as a function of the block length n.Since U(n) is independent from the family length λ, we deduce that U(n) ∈ O(1) as a function of λas well.□5.2.3 Efficiency ComparisonHash and Signature Computation. Our scheme relies on signature dispersion so we will compareit to SAIDA, eSAIDA, the linear equation-based construction, PRABS and LTT. The results of Table5.2 are based on the definitions found in [4, 71, 87, 109, 110, 111] where SAIDA, eSAIDA, thelinear equation-based scheme, PRABS and LTT are iterated λ times. They represent the worst casesituation at the receiver.We notice that LTT and our MDS code-based construction from Chapter 4 have the same costwhich is smaller than SAIDA, eSAIDA, PRABS and the linear equations-based protocol. Thus, ourfocus is to compare our MDS code-based approach (when iterated λ times) to our multiple block technique.At the receiver, the complexity <strong>for</strong> the number of signature verification queries is better <strong>for</strong>our new scheme while the number of hashes has the same complexity in both constructions. In fact,it is easy to see by looking at DecoderMDS and DecoderBlock that the exact numbers of digests willalso be equal. Note that the average number of signature verifications to be per<strong>for</strong>med at the receiver86


5.2. A MULTIPLE BLOCK AUTHENTICATION SCHEMESenderReceiverHash Signature Hash Signature DoSGeneration Verifications TolerantSAIDA λ (n + 1) λ Θ(λn) λ NoeSAIDA λ ( 3n 2+ 1) λ Θ(λn) λ NoLinear λ(n + 1) λ Θ(λn) λ NoEquationsPRABS λ (2 ⌈log 2 n⌉ + 1) λ Θ(λn log 2 n) O(λ) YesLTT λ (n + 1) λ Θ(λn) O(λ) YesMDS codebased λ (n + 1) λ Θ(λn) O(λ) YesSchemeMultipleBlock λ (n + 1) + 1 1 Θ(λn) O(1) YesSchemeTab. 5.2: Cost <strong>for</strong> signature dispersion-based schemesper data packet is upper bounded by the values contained in Table 4.5 divided by λ. At the sender,our new approach only requires a single signature <strong>for</strong> the whole family whereas the MDS code-basedscheme generates λ of them. This is at the cost of one additional hash computation. As said be<strong>for</strong>e,generating a digital signature is more time expensive than computing a hash. Since a hash functiontakes inputs of any length, the time spent hashing the extra element generated by our multiple blockscheme will be more relevant to get an approximation of the gain provided by this new approach.Threshold Values. As be<strong>for</strong>e, we denote H the bit size of a digest produced by h, S the bit size of asignature and P the bit size of data packets P i,j . We also denote t h is time needed to hash one bit andt s the time needed to produce one signature (both t h and t s must be expressed in the same time unity).The number of bits hashed <strong>for</strong> our MDS code-based scheme is:n |Ŝi| + |BID| + |n| + |α| + |β| + |P| + n HThere<strong>for</strong>e, when this scheme is iterated λ times, the total number of bit S MDS to be processed by h is:S MDS := λ( ⌈ ⌉)n Pn + |BID| + |n| + |α| + |β| + |P| + n H⌈α n⌉As we used the same MDS code construction <strong>for</strong> our multiple block protocol, the number of bits S MBhashed <strong>for</strong> this new scheme (representing a family of λ block) is:S MB := λ( ⌈ ⌉ ) n Pn + n H + |FID| + |n| + |α| + |β| + |P| + |λ| + λ H⌈α n⌉87


5. MULTIPLE BLOCK CONSTRUCTIONSThus, the difference ∆(λ) between these two approaches is:∆(λ) := S MB − S MDS = λ H + (|FID| − λ |BID|) + (1 − λ)(|n| + |α| + |β| + |P|) + |λ|Since our multiple block scheme requires λ − 1 less signature generations, we deduce that it is fasterthat λ iterations of the MDS code-based protocol if and only if:∆(λ)t h ≤ (λ − 1)t sThis is equivalent to:1λ − 1 (λ H + |FID| − λ |BID| + |λ|) − (|n| + |α| + |β| + |P|) ≤ t st h(5.1)W.l.o.g., one can assume that the number of blocks per family λ does not exceed the number ofpackets per block n. As a consequence, Inequality (5.1) is verified as soon as we have:1λ − 1 (λ H + |FID| − λ |BID| + |n|) ≤ t ( )s ts⇐⇒ λ + |BID| − H ≥ |FID| + |n| + t s(5.2)t h t h t hAssume that we have:Denote Λ(n) the integer:t st h+ |BID| − H > 0 (5.3)Λ(n) :=⌈ ⌉|FID| + |n| +t st ht st h+ |BID| − HWe deduce that our multiple block authentication protocol is faster than λ iterations of our MDScode-based scheme as soon as λ ≥ Λ(n) and provided Inequality (5.3) is satisfied. Note that Λ(n) isindependent from the packet bit size P.We implemented the mapping n ↦→ Λ(n) with different hash functions (SHA-256 and RIPEMD-160) and signature schemes (RSA, DSS [97] and ESIGN [103]). The signature schemes produced1024-bit signatures <strong>for</strong> RSA and DSA and 1023-bit signatures <strong>for</strong> ESIGN. As already explained inChapter 2, we would like to point out that the hash functions used to illustrate our construction areheuristically collision resistant despite widely used. As a consequence, it may happen in the futurethat some (or all) of them get broken as it occurred <strong>for</strong> the Message Digest (MD) family membersMD4 [126] and MD5 [127] in [150] or more recently <strong>for</strong> PANAMA [36] in [37].When Perrig et al.implemented EMSS [116, 118], one signature packet was sent every 1000 ones.88


5.2. A MULTIPLE BLOCK AUTHENTICATION SCHEMEPark and Cho [111] used n = 200 and n = 512 to implement both SAIDA and eSAIDA. Thus, in ourimplementations, whose results are depicted as Figure 5.4, we browsed values of n up to 2000. Notethat n should not be taken too large as efficiently constructing codes of large length n can becomedifficult in practice. In [116], it is assumed that there are about 500 packets sent per second in thenetwork in the case of video broadcast. As n = 1000 in that experiment, we buffer roughly 2 secondsof video per block in such settings. So, if BID is represented over 30 bits, then it provides a streamwhich can last at least 68 years in this situation. We keep the same value <strong>for</strong> our implementationsand we assumed that FID was also represented over 30 bits <strong>for</strong> simplicity. It should be noticed thatthe results from Figure 5.4 were obtained using the benchmarks by Dai [39] and Inequality (5.3) isverified based on those benchmarks.3332.82.82.82.62.62.62.42.42.42.22.22.2Λ(n)2Λ(n)2Λ(n)21.81.81.81.61.61.61.41.41.41.21.21.210 500 1000 1500 2000n10 500 1000 1500 2000n10 500 1000 1500 2000n(a) SHA-256 and RSA(b) SHA-256 and DSS(c) SHA-256 and ESIGN3332.82.82.82.62.62.62.42.42.42.22.22.2Λ(n)2Λ(n)2Λ(n)21.81.81.81.61.61.61.41.41.41.21.21.210 500 1000 1500 2000n10 500 1000 1500 2000n10 500 1000 1500 2000n(d) SHA-512 and RSA(e) SHA-512 and DSS(f) SHA-512 and ESIGN3332.82.82.82.62.62.62.42.42.42.22.22.2Λ(n)2Λ(n)2Λ(n)21.81.81.81.61.61.61.41.41.41.21.21.210 500 1000 1500 2000n10 500 1000 1500 2000n10 500 1000 1500 2000n(g) RIPEMD-160 and RSA(h) RIPEMD-160 and DSS(i) RIPEMD-160 and ESIGNFig. 5.4: Evaluation of Λ(n) <strong>for</strong> our different signature schemes and hash functionsFigure 5.4 shows that Λ(n) = 2 <strong>for</strong> our choices of hash functions and signature schemes which is89


5. MULTIPLE BLOCK CONSTRUCTIONSthe smallest minimal bound one can expect.5.3 A Multiple Block <strong>Authentication</strong> Scheme with FilteringThe main drawback of the previous multiple block construction is that the receiver still needs to runPoly-Reconstruct once per block in order to recover the block polynomial B i (X). The idea of PHis that each block of n packets conveys in<strong>for</strong>mation which will be used to authenticate (or predict)the following block of packets. Using PH, the scheme presented in this section will enable to filterelements upon reception and thus the receiver will exclusively buffer elements consistent with theoriginal data stream. The first benefit is that the previous filtering process will also reduce the numberof queries to Poly-Reconstruct (through MPR) to 2 per family of λ blocks which will speed up theauthentication process at the receiver considerably. The second advantage is that memory is notwasted by storing irrelevant pieces of data contrary to [28, 71, 87] and our previous constructions.The number of signature verifications to be per<strong>for</strong>med per family of λ blocks will still bounded byU(n) as <strong>for</strong> the scheme from Section 5.2.5.3.1 Our <strong>Authentication</strong> ProtocolWe consider the same network model as in Chapter 4 and keep the same definitions <strong>for</strong> n,λ,α,β andρ as in Section 5.2.1. Remember that each family P 1,1 ,...,P λ,n of λn packets has an identificationtag FID representing its position within the whole stream. Each one of its blocks of n packets alsohas a tag BID. Algorithm 5.4 describes the family authenticator AuthenticatorFiltering which outputsthe augmented packets per block of n elements. For this construction, the tag τ par representing thecommunication parameters is the same as in Section 5.2.1: τ par := n‖λ‖α‖β‖P. Thus, Table 5.1 alsosummarizes the parameters which are assumed to be publicly known <strong>for</strong> our multiple block schemewith filtering.Note that the value q used <strong>for</strong> polynomial interpolation is the same as in Section 5.2.1. Nonetheless,the size of the field used F 2˜q <strong>for</strong> the MDS code is modified. The new value ˜q can be found inAppendix B.4.We depicted our decoding algorithm as Figure 5.3. It uses as subroutines FilterElements andDecoderBlock. In this new construction, however, DecoderBlock will queried once per family of λblocks while FilterElements will be run λ − 1 times. This will create a speed-up at the receiver ashe will only per<strong>for</strong>m hash computations and erasure corrections as well as memory savings since thebuffered elements will be consistent with the original codewords (see proof of Theorem 5.4). In orderto verify the correctness of the family signature, the receiver will use the algorithm VerifySignature-90


5.3. A MULTIPLE BLOCK AUTHENTICATION SCHEME WITH FILTERINGAlgorithm 5.4 AuthenticatorFilteringInput: The secret key SK, the family number FID, Table 5.1 and λn data packets P 1,1 ,...,P λ,n ./* Packet Encoding */1. Parse P λ,1 ‖ · · · ‖P λ,n as M λ,1 ‖ · · · ‖M λ,⌈α n⌉ after padding. Encode the message(M λ,1 · · · M λ,⌈α n⌉ ) into the codeword⌉(Ŝλ,1 · · · Ŝλ,n) using the MDS code as in Algorithm 4.5with the field F 2˜q where ˜q = .⌈n (P+H)⌈α n⌉2. For i from λ − 1 to 1 do2.1. Compute the hashes h(Ŝi+1,j) <strong>for</strong> j ∈ {1,...,n} and append them to packets of block i as:.˜P i,j := P i,j ‖h(Ŝi+1,j)2.2. Parse ˜P i,1 ‖ · · · ‖ ˜P i,n as M i,1 ‖ · · · ‖M i,⌈αn⌉ after padding. Encode the message(M i,1 · · · M i,⌈α n⌉ ) into the codeword (Ŝi,1 · · · Ŝi,n) using the MDS code as in Step 1./* Block Identification */3. For i from 1 to λ do3.1. Parse h(Ŝi,1)‖ · · · ‖h(Ŝi,n) as b i,0 ‖ · · · ‖b i,ρ n where each b i ∈ F 2 q after padding and computethe block hash h i as h i := h(h(Ŝi,1)‖ · · · ‖h(Ŝi,n)).3.2. Construct the block polynomial B i (X) := b i,0 + b i,1 X + · · · + b i,ρ n X ρ n and evaluate it atthe first n points of F 2 q./* Signature Generation */4. Compute the family signature σ as σ := Sign SK (h(FID‖τ par ‖h 1 ‖ · · · ‖h λ )) and build the authenticationtag τ := h 1 ‖ · · · ‖h λ ‖σ.5. Write τ as the concatenation f 0 ‖ · · · ‖f ρ N of (ρ N + 1) elements of F 2 q after suitable padding.Form the family polynomial F(X) := f 0 + · · · + f ρ n X ρ n and evaluate it in the first n points ofF 2 q./* Construction of Augmented Packets */6. Build the augmented packet AP i,j as AP i,j := FID‖i‖j‖Ŝi,j‖B i (j)‖F(j) <strong>for</strong> i ∈ {1,...λ} and<strong>for</strong> j ∈ {1,...,n}.Output: The λn augmented packets {AP 1,1 ,...,AP λ,n } which are sent to the network per block ofn elements {AP i,1 ,...,AP i,n } i=1,...,λ.Family as in Section 5.2.1. Our scheme embeds the digests of the codeword related to block i+1 intoblock i. This will enable each receiver to filter data in order to speed up authentication and reduce thenumber of elements to be buffered. Algorithm 5.5, representing FilterElements, provides on-the-flyverification of received elements.It should be noticed that the boolean value KnownHashes indicates if the table of digests Hash-Codeword has been updated. This enables the receiver to switch between buffering all incoming dataelements and on-the-fly validation of in<strong>for</strong>mation.The reader may notice that we only verified the consistency of the substring FID i ‖BID i ‖j i ‖˜S BIDi,j ito our parameters FID, BID, n and HashCodeword. Since we did not check any condition onB BIDi,j i‖F BIDi,j i, one may think that an opponent can submit an incorrect element making our decoding91


5. MULTIPLE BLOCK CONSTRUCTIONSAlgorithm 5.5 FilterElementsInput: The family number FID, the block number BID, Table 5.1, a table HashCodeword and a flowof packets.1. Set T(i) := 0 <strong>for</strong> i ∈ {1,...,n}, set Ŝ′ k:= ∅ <strong>for</strong> all k ∈ {1,...,n} and KnownHashes =FALSE.2. Upon reception of a new data packet do2.1. Write it as FID i ‖BID i ‖j i ‖˜S BIDi,j i‖B BIDi,j i‖F BIDi,j i. If FID i ≠ FID or BID i ≠ BID orj i /∈ {1,...,n} or T(j i ) = 1 then discard the packet.2.2 If h(˜S BID,j i) = HashCodeword(j i ) then set T(j i ) = 1 and Ŝ′ j i= ˜S BID,j i./* After Reception of all Packets <strong>for</strong> Values (FID, BID) */3. If we have less than ⌈α n⌉ non-empty symbols then the algorithm stops.Else3.1. Correct the erasures as in Algorithm 4.6 and denote the corresponding message(S ′ 1 · · · S ′ ⌈α n⌉ ).3.2. Remove the pad from S 1‖ ′ · · · ‖S⌈α ′ n⌉and write the resulting string as{P′BID,1‖h ′ BID+1,1‖ · · · ‖PBID,n‖h ′ ′ BID+1,nPBID,1‖ ′ · · · ‖PBID,n′if BID ≠ λotherwisewhere each PBID,i ′ is P bits long and each h′ BID+1,j is H bits long.3.3. If BID ≠ λ then set HashCodeword(i) = h ′ BID+1,i <strong>for</strong> i ∈ {1,...,n} and setKnownHashes = TRUE.Output: {P BID,1,...,P ′ BID,n}: ′ set of authenticated packets <strong>for</strong> block BID; KnownHashes: a booleanvalue; HashCodeword: the n digests of the next block’s codeword.process fail. We would like to emphasize that it is not the case. As just noticed, the elements goingsuccessfully through this process are written as FID‖BID‖θ‖ŜBID,θ‖x‖y <strong>for</strong> some θ ∈ {1,...,n}.Nevertheless, the substring x‖y does not play any role in our algorithm since we only use ŜBID,θ torecover the original data packets. There<strong>for</strong>e, even if x‖y is a bogus string (i.e. x‖y ≠ B BID (θ)‖F(θ))then it has no influence whatsoever on the output of FilterElements which makes the attack by theadversary pointless. Note that this attack is similar to the random substitution attack per<strong>for</strong>med byWong and Chan against TESLA in Section 3.1.2.2.The array T is used to dodge duplication attacks by an opponent who would submit several stringsFID‖BID‖θ‖ŜBID,θ‖x‖y (<strong>for</strong> different values of x‖y) in order to exhaust the receiver computationalpower by recomputing h(ŜBID,θ) whereas the original coordinate ŜBID,θ has already been recovered.Finally, we build our dynamic decoder run by the receivers to authenticate data. We assume thatthe boolean value KnownHashes is set to FALSE when a receiver joins the communication groupand re-initialized to FALSE when the receiver processes the first received block of a new familyFID ′ (> FID). It is represented as Algorithm 5.6.92


5.3. A MULTIPLE BLOCK AUTHENTICATION SCHEME WITH FILTERINGAlgorithm 5.6 DynamicDecoderInput: The family number FID, the block number BID, the public key PK, Table 5.1, a booleanKnownHashes, a table HashCodeword and a set of received packets RP.If KnownHashes = FALSE thenElseDecoderBlock on input (PK, FID, BID,λ,n,α,β,ρ, P, RP).Query FilterElements on input (FID, BID,λ,n,α,β,ρ, P, HashCodeword, RP).Output: The set of identified packets {P BID,1 ′ ,...,P BID,n ′ }, the updated boolean value KnownHashesand the updated table HashCodeword as output of either DecoderBlock or FilterElements.5.3.2 Security and Recovery of the SchemeSecurity of the Scheme. Our security definition is the same as in Section 5.2.2. We have the followingresult regarding the security and correctness of our new construction whose proof can be found inAppendix A.2.Theorem 5.3 Our scheme (KeyGen,AuthenticatorFiltering,DynamicDecoder) is secure and (α,β)-correct.Recovery Property. We now prove that our scheme enables any receiver to recover the n data packets<strong>for</strong> any of the λ blocks and the number of signature verifications to be per<strong>for</strong>med per family is O(1)as a function of both n and λ. We have the following result whose proof can be found in Appendix D.Theorem 5.4 The recovery property of our authentication scheme (KeyGen,AuthenticatorFiltering,DynamicDecoder) verifies Theorem 5.2.5.3.3 Comparison of <strong>Authentication</strong> ProtocolsIn this section, we will compare our filtering approach to PRABS, our MDS code-based scheme fromChapter 4 and our multiple block scheme describe earlier in this chapter. As underlined in Chapter 3,the computing efficiency and the packet overhead are two important factors to determine the practicalityof a stream authentication protocol. Our comparison focuses on these two points.Computing Efficiency. In the proof of Theorem 5.4 described as Appendix D, it is shown thatDecoderBlock is queried only once <strong>for</strong> the whole family of λ blocks. Thus, Poly-Reconstruct is runonly twice per family (once within VerifySignatureFamily and once at Step 3 of DecoderBlock). Atthe same time, the receiver can filter elements <strong>for</strong> the remaining λ −1 blocks. Using PH, our filteringprocess allows efficient buffering and faster authentication as the receiver:(1) treats elements upon reception (on-the-fly verification),93


5. MULTIPLE BLOCK CONSTRUCTIONS(2) memorizes only the correct code coordinates.Table 5.3 summarizes the benefits provided by the different authentication schemes. In order to havea fair comparison, we assumed that PRABS and our MDS code-based scheme were iterated λ times.⌋(see Section 4.5.1).The value V (n) is equal to⌊⌊β n⌋⌈α n⌉Signature Complexity Calls to Filtering TotalVerification Poly-Reconstruct RecoveryPRABS λV (n) O(λ) N/A No NoMDS codebased λU(n) O(λ) λ No YesSchemeMultipleBlock U(n) O(1) λ + 1 No YesSchemeFiltering U(n) O(1) 2 Yes YesSchemeTab. 5.3: Efficiency comparison <strong>for</strong> multicast stream protocolsPacket Overhead. For our filtering authentication scheme, augmented packets sent through the networkare written as: FID‖i‖j‖Ŝi,j‖B i (j)‖F(j). As said in Section 4.5.2, the packet overhead is thelength of the extra tag of in<strong>for</strong>mation used to provide authentication. Remember that an augmentedpacket without a tag is assumed to be written as: FID‖i‖j‖P i,j and the bit size of packets P i,j is P.Our scheme overhead is:|Ŝi,j| + |B i (j)| + |F(j)| − PThe element Ŝi,j belongs to the field used <strong>for</strong> the MDS code. Thus, it is ˜q bits long. In addition, B i (j)and F(j) are q bits long. There<strong>for</strong>e, our packet overhead is:⌈ n(P + H)⌈αn⌉⌉ (⌈ ⌉ H n + ξ+ 2 max ,ρn + 1⌈ H λ + S + ξρn + 1⌉)− PTable 5.4 summarizes the overhead comparison of the different authentication schemes. The elementξ ′ is the smallest integer verifying Inequality (4.2).⌉ ) (⌈Notice that the values− P and(⌈n (P+H)⌈αn⌉n P⌈αn⌉⌉ )− P correspond to a stretching coefficientroughly equal to 1 α− 1. This is the price to pay in order to use the MDS code which guarantees totalrecovery of all data packets. Remark that when the survival rate α is close to 1 (i.e. the channel has agood delivery rate), the previous values get close to H and 0 respectively.If we compare the filtering multiple block authentication scheme to our MDS code-based protocolthen the packet overhead of the <strong>for</strong>mer is one field element plus, roughly,Hαbits longer. Notice,however, that the field elements used in our multiple block scheme with filtering are smaller than94


PRABSMDS codebasedSchemeMultipleBlockSchemeFilteringScheme(⌈n P⌈αn⌉(⌈⌈n P⌈αn⌉n H+S⌈αn⌉Bit⌉Size+ log 2 (n) H⌉ )− P +⌉ )− P + 2 max(⌈ ⌉ )n (P+H)⌈αn⌉− P + 2 max⌈H n+S+ξ′ρ n+1(⌈ ⌉H n+ξρ n+1,(⌈ ⌉H n+ξρ n+1,⌉⌈ ⌉)H λ+S+ξρ n+15.4. CONCLUSION⌈ ⌉)H λ+S+ξρ n+1Tab. 5.4: Overhead comparison <strong>for</strong> multicast stream protocolsthose employed with our MDS code-based construction since λ can be seen as small in comparisonto the block length n.5.4 ConclusionIn this chapter, we extended our construction based on MDS codes to the case where the sender knowsa longer piece of the data stream to be transmitted as it is the case <strong>for</strong> delayed broadcasts. Our purposewas to generate less signatures in this situation as these cryptographic primitives are resourceexpensive to create and verify. For both constructions presented in this chapter, we considered that thesender could buffer λ block of n packets. Our first scheme was shown to have a better computationalefficiency at the receiver than λ iterations of LTT, PRABS as well as our MDS code-based approachfrom Chapter 4. In addition, the minimal value of λ, denoted Λ(n), such that our extended scheme isfaster than λ iterations of our MDS code-based protocol is small. In our examples, we got Λ(n) = 2<strong>for</strong> many choices of hash functions and digital signatures. Thus, the extra requirement consisting ofbuffering λn packets is quickly amortized.The main drawback of this construction is that Poly-Reconstruct still has to be queried λ+1 timesper family. In our second protocol, we used PH to reduce the number of such queries to 2. This techniquealso enables the receiver to filter data packets upon arrival and to buffer only those which areconsistent with the original data stream saving memory storage and reducing the computational costof authentication as only erasure corrections and hash calculations need to be executed by the receiver.It should be noticed that the general speed-up of these two schemes comes from the fact that thenumber of signature verifications to be per<strong>for</strong>med at the receiver is O(1) as a function of both theblock length n and the family size λ contrary to PRABS, LTT and our MDS code-based constructionwhere it is linear in λ. Our two authentication protocols only require a single signature to be gene-95


5. MULTIPLE BLOCK CONSTRUCTIONSrated by the sender per family of λ blocks. Nonetheless, as this signature is distributed within eachblock, our protocols still enable new members to join the communication group at block boundariespreserving the dynamics of the groups of receivers.96


6Reducing the Receiver <strong>Authentication</strong> TimeAs said earlier in this thesis, both the packet overhead and the speed of authentication at the receiverare major concerns <strong>for</strong> multicast stream authentication. In Chapter 5, we proposed to decrease thetime spent <strong>for</strong> signature generation and verification by creating a single signature per family of λblocks where each of them consisted of n packets. In this chapter, we present an hybrid constructionbased on Merkle hash trees and MDS codes which will exhibit a smaller overhead and a much fasterauthentication process than our MDS code-based approach from Chapter 4 making our new schememore suitable <strong>for</strong> broadcast applications. This new approach will also enable the whole data packetsto be recovered at the receiver despite erasures and injections and will allow new members to join thecommunication group at any block boundary.In Chapter 3, we saw that a possibility to obtain a faster authentication scheme was to designfaster digital signatures. In [53], Gao and Yao used a THF instead of a digital signature to ensurenon-repudiation of data. This fact is not new but it can create speed-up <strong>for</strong> multicast authenticationprotocols. We will illustrate the benefit of such a primitive <strong>for</strong> authentication over unsecured channelsby using a recently developed hash function called Very Smooth Hash (VSH) which can be employedto build a THF [30]. We will see that the combination of a Merkle hash tree along with VSH accele-97


6. REDUCING THE RECEIVER AUTHENTICATION TIMErates the receiver authentication process even further.As in Chapter 4, the sender processes the data stream per block of n data packets P 1 ,...,P n .Each block is represented within the whole stream by an identification value BID. Note that theconstructions proposed in this chapter can be generalized as in Chapter 5 when the sender has theability to memorize λ consecutive blocks of the stream.6.1 Overview of the ConstructionAs in Chapter 4, we need a collision resistant hash function h and an un<strong>for</strong>geable digital signaturescheme (Sign SK , Verify PK ) whose key pair (SK,PK) is generated by the algorithm KeyGen. Our algorithmAuthenticatorHybrid will apply two steps.The first step works as follows. Due to our network model, we want to generate n augmentedpackets AP 1 ,...,AP n such that we can reconstruct the sequence of packets P 1 ,...,P n from any⌈α n⌉-subset of {AP 1 ,...,AP n }. As in Chapter 4, we need to encode P 1 ,...,P n into the codeword(Ŝ1 · · · Ŝn) using a [n, ⌈α n⌉,n − ⌈α n⌉ + 1] code.The second step of our algorithm consists of building Merkle hash trees. We partition the digestsh(Ŝ1),...,h(Ŝn) into g groups of ⌈ n g⌉ elements where g is an efficiency parameter (see Section6.2.3). Remark that if g does not divide n then the last group will be completed with dummypackets (consisting of zeros <strong>for</strong> simplicity). This group padding has no effect on the number of augmentedpackets sent into the network as those dummy elements will only be used to construct the lastgroup tree. Since g and n will be public, each receiver knows how many dummy packets to add <strong>for</strong>the last group. For each group G j := {h(Ŝ(j−1)⌈ ⌉ ng+1 ),...,h(Ŝj ⌈ ⌉ n )} (<strong>for</strong> j ∈ {1,...,g}), wegbuild the Merkle hash tree whose leaves are the elements of G j (see Figure 6.1 <strong>for</strong> an example).To provide authentication and non-repudiation of the stream source and to allow new members tojoin the communication group at block boundaries, we sign the digest h(r 1 ‖ · · · ‖r g ) where r 1 ,...,r gare the g tree roots. As in Chapter 4, we construct a polynomial A(X) of degree at most ρn (<strong>for</strong> somerational constant ρ), whose coefficients represent r 1 ‖ · · · ‖r g ‖σ where σ is the block signature. Webuild the augmented packets as:∀i ∈ {1,...,n}AP i := BID‖i‖Ŝi‖A(i)‖ path(i)where path(i) denotes the ⌈log 2 ⌈ n g ⌉⌉ hashes needed to reconstruct the path from h(Ŝi) to the root of98


6.2. AN HYBRID CONSTRUCTION FOR STREAM AUTHENTICATIONr 1 := h(H 14 ‖H 58 )(Root)H 14 := h(H 12 ‖H 34 )H 58 := h(H 56 ‖H 78 )H 12 := H 34 := H 56 := H 78 :=h(h(Ŝ1)‖h(Ŝ2)) h(h(Ŝ3)‖h(Ŝ4)) h(h(Ŝ5)‖h(Ŝ6)) h(h(Ŝ7)‖h(Ŝ8))h(Ŝ1) h(Ŝ2) h(Ŝ3) h(Ŝ4)h(Ŝ5)h(Ŝ6) h(Ŝ7)h(Ŝ8)(Leaves)Fig. 6.1: The Merkle hash tree of G 1 when ⌈ n g ⌉ = 8.his group tree. For instance on Figure 6.1, we have: path(2) = h(Ŝ1)‖H 34 ‖H 58 .Upon reception of data, the receiver checks the signature by reconstructing A(X) using MPR.Once the signature σ is verified, the receiver knows the original tree roots r 1 ,...,r g . Thus, he canidentify the correct Ŝi’s amongst the list of elements he got by checking which paths are correctwithin the g trees. According to the definition of α, there must be at least ⌈α n⌉ symbols fromŜ 1 ,...,Ŝn in his list. Finally, he corrects the erasures using the MDS code and recovers the datapackets P 1 ,...,P n .6.2 An Hybrid Construction <strong>for</strong> Stream <strong>Authentication</strong>The multicast authentication scheme presented in this section is an hybrid approach mixing Merklehash trees and MDS codes. As our previous techniques, it will allow new users to join the communicationgroup at any block boundary. We will demonstrate its security, recovery property and showthat the number of signature verifications per block at the receiver is upper bounded by the same valueas our MDS code-based protocol.6.2.1 Our <strong>Authentication</strong> ProtocolWe use the same network model as in Chapter 4 and keep the same definitions <strong>for</strong> n,α,β andρ. In particular, we assume that ρ is uniquely determined when n,g,α and β are known. Eachblock P 1 ,...,P n is processed independently from the others and is located within the whole streamby an identification value BID. Algorithm 6.1 describes the block authenticator AuthenticatorHybrid.For this construction, the tag τ par representing the communication parameters is defined as:τ par := n‖g‖α‖β‖P. Table 6.1 summarizes the parameters which are assumed to be publicly known99


6. REDUCING THE RECEIVER AUTHENTICATION TIME<strong>for</strong> our hybrid scheme.n: Block length r: Efficiency parameter of the MDS codeα: Survival rate β: Flood rateP: Packet size (in bits) G: Generating matrix of the MDS codeg: number of groups per block A list of irreducible polynomials over F 2Tab. 6.1: Public parameters <strong>for</strong> our hybrid authentication schemeAlgorithm 6.1 AuthenticatorHybridInput: The secret key SK, the block number BID, Table 6.1 and n data packets P 1 ,...,P n ./* Packet Encoding */1. Encode each block {P 1 ,...,P n } into the codeword (Ŝ1 · · · Ŝn) as in Algorithm 4.5./* Tree Construction */2. For j from 1 to g doCompute the digests h(Ŝ(j−1)⌈ ⌉ ng+1 ),...,h(Ŝj ⌈ ⌉ n ) and build the Merkle hash tree having thegprevious digests as leaves (as said earlier some padding with zeros values may be needed whenj = g). Denote r j its root./* Signature Generation */3. Compute the block signature σ as σ := Sign SK (h(BID‖τ par ‖r 1 ‖ · · · ‖r g )) and build the authenticationtag τ := r 1 ‖ · · · ‖r g ‖σ.4. Denote ξ the smallest element of N such that:⌈ ⌉H g + S + ξ≥ ⌈logρn + 1 2 n⌉ (6.1)Denote q the left hand side of Inequality (6.1). Write τ as the concatenation a 0 ‖ · · · ‖a ρ n of (ρn+1) elements of F 2 q after suitable padding. Form the block polynomial A(X) := a 0 +· · ·+a ρ n X ρ nand evaluate it in the first n points of F 2 q: ∀i ∈ {1,...,n} y i = A(i)./* Construction of Augmented Packets */5. Build the augmented packet as:∀i ∈ {1,...,n}AP i := BID‖i‖Ŝi‖y i ‖ path(i)Output: {AP 1 ,...,AP n }: set of augmented packets.It should be noticed that we use the same pad as in Algorithm 4.5 <strong>for</strong> the erasure correcting code.The value of q as well as the pad applied at Step 4 can be found in Appendix B.5. Note that theelements of Table 6.1 are enough to determine each step of AuthenticatorHybrid. As be<strong>for</strong>e, we canassume, w.l.o.g., that when n,g,α,β, P are known the parameter ρ is uniquely determined.The receivers authenticate data using DecoderHybrid described as Algorithm 6.2.100


6.2. AN HYBRID CONSTRUCTION FOR STREAM AUTHENTICATIONAlgorithm 6.2 DecoderHybridInput: The public key PK, the block number BID, Table 6.1 and the set of received packets RP./* Signature Verification and Root Recovery */1. Write the packets as BID i ‖j i ‖˜S ji ‖ỹ ji ‖ ˜path jiand discard those having BID i ≠ BID orj i /∈ {1,...,n}. Denote N the number of remaining elements. If (N < ⌈α n⌉ or N > ⌊β n⌋) thenthe algorithm stops.2. Rename the remaining elements as {ÃP 1 ,...,ÃP N } and write each element as: ÃP i =BID‖j i ‖˜S ji ‖ỹ ji ‖ ˜path jiwhere j i ∈ {1,...,n}. Run MPR on the set {(j i ,ỹ ji ),1 ≤ i ≤ N}to get a list {c 1 ,...,c µ } of candidates <strong>for</strong> signature verification. If MPR rejects that set then thealgorithm stops.3. Set rk ′ = ∅ <strong>for</strong> k ∈ {1,...,g}. While the signature has not been verified and thelist has not been exhausted, pick a new candidate ˜r 1 ‖ · · · ‖˜r g ‖˜σ after removing the pad. IfVerify PK (h(BID‖τ par ‖˜r 1 ‖ · · · ‖˜r g ), ˜σ) = TRUE then set rk ′ = ˜r k <strong>for</strong> k ∈ {1,...,g} and breakout the loop. Otherwise, increment i by 1 and start again the while loop./* Packet Decoding */4. If (r 1,...,r ′ g) ′ = (∅,...,∅) then the algorithm stops. Otherwise, set Ŝk ′ := ∅ <strong>for</strong> allk ∈ {1,...,n}. For each of the N remaining packets, BID‖j i ‖˜S ji ‖ỹ ji ‖ ˜path ji, we first computeits group number l ji as l ji := . Second, if the path from h(Ŝ′ j i⌉) to the value rl ′ jican⌈ji⌈n/g⌉be reconstructed using ˜path jithen set Ŝ′ j i= ˜S ji .5. If we have less than ⌈α n⌉ non-empty symbols then the algorithm stops. Otherwise, denoteŜ ′ p 1 ,...,Ŝ′ p γthe non-empty elements. Decode them as in Algorithm 4.6 and denote the correspondingmessage (S ′ 1 · · · S ′ ⌈α n⌉ ).6. Remove the pad from S 1‖ ′ · · · ‖S⌈α ′ n⌉ and write the remaining string as P 1,...,P ′ n ′ where eachP i ′ is P bits long.Output: {P ′ 1,...,P ′ n}: set of authenticated packets.6.2.2 Security and Recovery AnalysisSecurity of the Scheme. The security definition <strong>for</strong> our construction is given in Chapter 4 as Definition4.3 since we built a single block authentication scheme. We have the following result <strong>for</strong> ourprotocol whose proof can be found in Appendix A.3.Theorem 6.1 Our scheme (KeyGen,AuthenticatorHybrid,DecoderHybrid) is secure and (α,β)-correct.Recovery Property. We now show that our scheme enables any receiver to recover the n data packetsand the number of signature verifications to be per<strong>for</strong>med per block is upper bounded by the samevalue as <strong>for</strong> our MDS code-based scheme. The proof of the following theorem is straight<strong>for</strong>wardfrom the demonstration of Theorem 4.6.Theorem 6.2 The recovery property of our authentication scheme (KeyGen,AuthenticatorHybrid,DecoderHybrid)verifies Theorem 4.6.101


6. REDUCING THE RECEIVER AUTHENTICATION TIME6.2.3 Efficiency AnalysisIn this section, we compare our hybrid protocol to our MDS code-based authentication scheme fromChapter 4. In particular, we will see that, <strong>for</strong> a suitable choice of g, our new construction can achievesmaller overhead while exhibiting a much faster authentication at the receiver.Packet Overhead. Our augmented packets are written as BID‖i‖Ŝi‖y i ‖ path(i). Based on the analysisdone in Appendix B.5, the packet overhead ω of our new protocol is equal to:⌈ω :=n P⌈α n⌉⌉− P +⌈ g H + S + ξρn + 1⌉+⌈log 2⌈where ξ is the smallest positive integer verifying Inequality (6.1).ng⌉⌉H bitsThe overhead of the augmented packets <strong>for</strong> our MDS code-based scheme is:ω MDS :=(⌈ ⌉ ) n P− P +⌈αn⌉⌈ ⌉H n + S + ξ′ρn + 1bitswhere ξ ′ is the smallest positive integer verifying Inequality (4.2).To illustrate the benefits of our new approach, we will compute the ratioωω MDS<strong>for</strong> different choicesof P,α,β. We choose the same network rates as in Chapter 4 and the packet size to 512 and 4096bits as in [118]. We pick n = 1000 and set ρ to α22 βas suggested be<strong>for</strong>e. We used SHA-256 as ahash function and a 1024-bit RSA signature scheme. The first step is to compute g minimizing ouroverhead ω. These optimal values are shown in Table 6.2.P = 512 P = 4096αα0.5 0.75 0.8 0.9 0.5 0.75 0.8 0.91.1 125 500 500 500 125 500 500 500β 1.25 125 250 500 500 125 250 500 5001.5 125 250 250 500 125 250 250 5002 125 250 250 250 125 250 250 250Tab. 6.2: Number of groups g minimizing ω when n = 1000The overhead corresponding to the values g from Table 6.2 is represented in Table 6.3.Our overhead comparison between the two schemes is depicted in Table 6.4. It clearly showsthat our hybrid scheme exhibits a smaller overhead. The benefits get larger over networks with smallreliability (i.e. α is small) or highly polluted by O (i.e. β is large). This construction also seems to102


6.2. AN HYBRID CONSTRUCTION FOR STREAM AUTHENTICATIONP = 512 P = 4096αα0.5 0.75 0.8 0.9 0.5 0.75 0.8 0.91.1 1569 930 827 663 5153 2125 1723 1062β 1.25 1607 971 887 710 5191 2166 1783 11091.5 1672 1028 944 790 5256 2223 1840 11892 1801 1143 1044 889 5385 2338 1940 1288Tab. 6.3: Overhead of our construction ω when g is chosen as in Table 6.2 and n = 1000per<strong>for</strong>m even better when the data packets are small.P = 512 P = 4096αα0.5 0.75 0.8 0.9 0.5 0.75 0.8 0.91.1 56.95% 79.28% 81.96% 87.93% 81.29% 89.74% 90.45% 92.11%β 1.25 52.57% 74.18% 78.57% 83.73% 78.17% 86.50% 88.05% 88.93%1.5 46.97% 66.97% 71.08% 78.53% 73.57% 81.43% 82.73% 84.63%2 39.50% 57.55% 60.52% 67.30% 66.12% 73.50% 74.02% 74.88%Tab. 6.4: Ratioωω MDSwhen n = 1000<strong>Authentication</strong> Efficiency. We now compare the authentication delay at the receiver between our twoconstructions. It should be noticed that the authentication part of DecoderHybrid consists of Steps 1to 4. Indeed, Step 5 is dedicated to erasure correction which is a non-authentication related feature.In those four steps, two points matter: the number of signature verification queries and the quantityof in<strong>for</strong>mation to be processed by h. In our comparison, we focus on the worst case, i.e. we assumethat the number of signature verification is U(n). In this situation, the number of bits processed by his:h 1 := U(n)(|BID|+g H + |g|+⌊log 2 n⌋+|α|+|β|+⌊log 2 P⌋+2)+⌊β n⌋ (P +2⌈log 2 ⌈ n g⌉⌉ H)As g ≤ n, we can assume that |g| = |n| = ⌊log 2 n⌋ + 1 bits. Considering our MDS code-basedscheme, the number of bits processed by the hash function is:h 2 := U(n)(|BID| + n P + ⌊log 2 n⌋ + |α| + |β| + ⌊log 2 P⌋ + 2) + ⌊β n⌋ PTable 6.5 represents the ratio T := U(n)t s + h 1 t hU(n)t s + h 2 t hwhere t s denotes the number of seconds requiredto per<strong>for</strong>m one signature verification and t h is the number of seconds to hash one bit. As inSection 5.2.3, we choose n = 1000 and |BID| = 30 bits. It is also realistic to assume that |α| and |β|are smaller than |BID|, H, ⌊log 2 n⌋ and ⌊log 2 P⌋. So, in our comparisons, we set: |α| = |β| = 5 bits.Our results are based on Dai’s benchmarks [39].103


6. REDUCING THE RECEIVER AUTHENTICATION TIMEP = 512 P = 4096αα0.5 0.75 0.8 0.9 0.5 0.75 0.8 0.91.1 35.79% 52.57% 55.60% 59.63% 10.07% 18.79% 20.84% 23.57%β 1.25 36.13% 54.97% 55.06% 58.37% 10.20% 19.05% 20.48% 22.72%1.5 35.95% 53.74% 57.00% 59.02% 10.13% 18.48% 19.99% 23.16%2 35.73% 52.31% 57.00% 67.26% 10.04% 17.82% 19.99% 24.72%Tab. 6.5: Ratio T when n = 1000Table 6.5 shows that our hybrid construction is much faster than the MDS code-based scheme.Note that we deliberately removed the query to Poly-Reconstruct happening at Step 2 of DecoderHybrid.Nevertheless, both authentication protocols per<strong>for</strong>m such a request. So, if the time needed torun Poly-Reconstruct is added to both numerator and denominator of T then the values of Table 6.5will be flattened but the hybrid approach will remain faster.6.3 Trapdoor Hash Functions <strong>for</strong> Stream <strong>Authentication</strong>So far, we used digital signatures to provide a non-repudiable proof of the origin of the data stream.In this section, we will see that THFs can also be used in our constructions. In addition, we will seethat, when using the THF version of VSH, one can speed up the running time at the receiver evenfurther than in Section 6.2 while having a slightly increased overhead.6.3.1 Our <strong>Authentication</strong> ProtocolWe use the same settings as in Section 6.3.1. Table 6.6 summarizes the parameters which are assumedto be publicly known <strong>for</strong> our hybrid scheme. It should be noticed that the sender should refreshed thepublic target value T from time to time to prevent attacks on the THF collision resistance.n: Block length r: Efficiency parameter of the MDS codeα: Survival rate β: Flood rateP: Packet size (in bits) G: Generating matrix of the MDS codeg: number of groups per block A list of irreducible polynomials over F 2T : target value <strong>for</strong> the THFTab. 6.6: Public parameters <strong>for</strong> the hybrid authentication scheme using a THFThe sender processes data as in Algorithm 6.3. Based on Definition 2.6, we denote the THF asH PK (·, ·) where the key pair (PK,SK) is issued by the key generator KeyGen. We note the bit size ofthe randomizer c as R.We use the same pad as in Algorithm 6.1 <strong>for</strong> the erasure correcting code. The value of q can becomputed in a straight<strong>for</strong>ward way using Appendix B.5 and substituting the signature bit size S by104


6.3. TRAPDOOR HASH FUNCTIONS FOR STREAM AUTHENTICATIONAlgorithm 6.3 AuthenticatorHybridTHFInput: The secret key SK, the block number BID, Table 6.6 and n data packets P 1 ,...,P n ./* Packet Encoding */1. Encode each block {P 1 ,...,P n } into the codeword (Ŝ1 · · · Ŝn) as in Algorithm 4.5./* Tree Construction */2. For j from 1 to g doCompute the digests h(Ŝ(j−1)⌈ ⌉ ng+1 ),...,h(Ŝj ⌈ ⌉ n ) and build the Merkle hash tree having thegprevious digests as leaves (as said earlier some padding with zeros values may be needed whenj = g). Denote r j its root./* Randomizer Generation */3. Using the collision finding algorithm along with SK, get a randomizer c such thatH PK (h(BID‖τ par ‖r 1 ‖ · · · ‖r g ),c) = T . Build the authentication tag τ := r 1 ‖ · · · ‖r g ‖c.4. Denote ξ the smallest element of N such that:⌈ ⌉H g + R + ξ≥ ⌈logρn + 1 2 n⌉ (6.2)Denote q the left hand side of Inequality (6.2). Write τ as the concatenation a 0 ‖ · · · ‖a ρ n of (ρn+1) elements of F 2 q after suitable padding. Form the block polynomial A(X) := a 0 +· · ·+a ρ n X ρ nand evaluate it in the first n points of F 2 q: ∀i ∈ {1,...,n} y i = A(i)./* Construction of Augmented Packets */5. Build the augmented packet as:∀i ∈ {1,...,n}AP i := BID‖i‖Ŝi‖y i ‖ path(i)Output: {AP 1 ,...,AP n }: set of augmented packets.the randomizer length R.The receivers authenticate data using DecoderHybridTHF described as Algorithm 6.4.The THF enables non-repudiation of data due to its collision resistance property (remember thatthe target T is public). In addition, this use of a THF allows any entity to join the communicationgroup at any time by only per<strong>for</strong>ming one hash computation via the THF. It is generally slowerthan computing one hash with a non-trapdoor hash function but much faster than verifying a digitalsignature as we will see in Section 6.3.3.6.3.2 Security and Recovery AnalysisThe security and recovery properties of our construction based on a THF trivially follow what wasdone in Section 6.2.2.105


6. REDUCING THE RECEIVER AUTHENTICATION TIMEAlgorithm 6.4 DecoderHybridTHFInput: The public key PK, the block number BID, Table 6.1 and the set of received packets RP./* Randomizer Verification and Root Recovery */1. Write the packets as BID i ‖j i ‖˜S ji ‖ỹ ji ‖ ˜path jiand discard those having BID i ≠ BID orj i /∈ {1,...,n}. Denote N the number of remaining elements. If (N < ⌈α n⌉ or N > ⌊β n⌋) thenthe algorithm stops.2. Rename the remaining elements as {ÃP 1 ,...,ÃP N } and write each element as: ÃP i =BID‖j i ‖˜S ji ‖ỹ ji ‖ ˜path jiwhere j i ∈ {1,...,n}. Run MPR on the set {(j i ,ỹ ji ),1 ≤ i ≤ N}to get a list {c 1 ,...,c µ } of candidates <strong>for</strong> randomizer verification. If MPR rejects that set then thealgorithm stops.3. Set rk ′ = ∅ <strong>for</strong> k ∈ {1,...,g}. While the randomizer has not been verified and thelist has not been exhausted, pick a new candidate ˜r 1 ‖ · · · ‖˜r g ‖˜c after removing the pad. IfH PK ((h(BID‖τ par ‖˜r 1 ‖ · · · ‖˜r g ), ˜c) = TRUE then set rk ′ = ˜r k <strong>for</strong> k ∈ {1,...,g} and break outthe loop. Otherwise, increment i by 1 and start again the while loop./* Packet Decoding */4. If (r 1,...,r ′ g) ′ = (∅,...,∅) then the algorithm stops. Otherwise, set Ŝk ′ := ∅ <strong>for</strong> allk ∈ {1,...,n}. For each of the N remaining packets, BID‖j i ‖˜S ji ‖ỹ ji ‖ ˜path ji, we first computeits group number l ji as l ji := . Second, if the path from h(Ŝ′ j i⌉) to the value rl ′ jican⌈ji⌈n/g⌉be reconstructed using ˜path jithen set Ŝ′ j i= ˜S ji .5. If we have less than ⌈α n⌉ non-empty symbols then the algorithm stops. Otherwise, denoteŜ ′ p 1 ,...,Ŝ′ p γthe non-empty elements. Decode them as in Algorithm 4.6 and denote the correspondingmessage (S ′ 1 · · · S ′ ⌈α n⌉ ).6. Remove the pad from S 1‖ ′ · · · ‖S⌈α ′ n⌉ and write the remaining string as P 1,...,P ′ n ′ where eachP i ′ is P bits long.Output: {P ′ 1,...,P ′ n}: set of authenticated packets.6.3.3 Trapdoor Hash Function versus Digital SignatureWe now justify our choice of using a THF rather than a digital signature to ensure non repudiation ofthe transmitter of data. We will see that this suggestion is based on the speed-up of the verificationprocess that the THF we chose exhibits compared to digital signatures.We choose to use the hash function VSH as it can be turned into a THF to illustrate the gainprovided by our updated hybrid protocol. The collision resistance of VSH was proved under the computationalVery Smooth number nontrivial modular Square Root (VSSR) assumption meaning thatsolving the VSSR problem is as hard as factoring a hard to factor modulus [30]. In fact we workedwith a faster version of VSH (but still as secure) called Fast-VSH. According to [30], Fast-VSH isabout 25 times slower than SHA-1. Nonetheless, they used the earlier benchmarks by Dai from [38]as references <strong>for</strong> their comparisons. We keep the ratio 25 <strong>for</strong> our comparison based on the updatedbenchmarks [39] despite we hope this ratio to be smaller when Fast-VSH is implemented on the same106


6.3. TRAPDOOR HASH FUNCTIONS FOR STREAM AUTHENTICATIONhardware as in [39]. Fast-VSH is a hash function which can be turned into a THF. This trans<strong>for</strong>mationis very simple. On the input message m, we first compute its Fast-VSH value which is squaredmodulo an integer χ (which is a parameter of Fast-VSH). The output of the THF is the reduction ofthat square. Thus, we can approximate the time needed to compute a value via the THF by the timeneeded to compute a hash via Fast-VSH and neglect the last squaring-reduction. Using new Dai’sbenchmarks [39], we compared the speed of the signature verification process of several digital signatures(RSA, DSS, Nyberg-Rueppel [101], LUC [140]) to Fast-VSH when the latter produces hashesof the same size as the signature. The results are shown in Table 6.7.RSA DSA Nyberg-Rueppel LUC1024 2048 1024 1024 2048 1024 2048Micro-seconds per 70 150 520 500 2350 70 170operation (µs/op)Fast-VSH (µs/op) 38 75 38 38 75 38 75signatureRatio:Fast-VSH1.84 2.00 13.68 13.15 31.33 1.84 2.26Tab. 6.7: Comparison of speed between Fast-VSH and the verification process of some digital signaturesWe see that Fast-VSH (or its THF <strong>for</strong>m) is faster than the verification process of these signaturesschemes. This will have a critical impact on the time spent to exhaust the list of candidates <strong>for</strong> randomizerverification as shown in Table 6.8 where we computed the time to exhaust the list of sizeU(n) when n = 1000. Note that we only compare Fast-VSH to the RSA digital signature as the ratiosbetween the hash function and DSA and Nyberg-Rueppel signature schemes are too prohibitive.Note that we would get a similar result using LUC digital signatures. Table 6.8 clearly shows theadvantage at the receiver of using the THF version of VSH instead of a digital signature.Based on Contini et al.’s work, VSH requires to use a 1516-bit modulus to achieve the same securitylevel as a 1024-bit RSA signature modulus. Table 6.9 describes the overhead <strong>for</strong> the hybridauthentication scheme when using VSH with a 1516-bit modulus. Table 6.10 depicts the ratioand Table 6.11 represents the speed ratio T when VSH is used instead of RSA.ωω MDSOne notices that using VSH slightly increases the overhead with respect to the digital signatureapproach but it reduces the authentication time at the receiver even further.107


6. REDUCING THE RECEIVER AUTHENTICATION TIMEα β U(1000) Fast-VSH RSA(milliseconds) (milliseconds)0.5 1.1 17 0.62 1.191.25 19 0.69 1.331.5 23 0.84 1.612 31 1.14 2.170.75 1.1 7 0.25 0.491.25 8 0.29 0.561.5 10 0.36 0.702 14 0.51 0.980.8 1.1 6 0.22 0.421.25 7 0.25 0.491.5 9 0.33 0.632 12 0.44 0.840.9 1.1 5 0.18 0.351.25 6 0.22 0.421.5 7 0.25 0.492 9 0.33 0.63Tab. 6.8: Time needed to exhaust a list of size U(1000)P = 512 P = 4096αα0.5 0.75 0.8 0.9 0.5 0.75 0.8 0.91.1 1573 932 828 664 5157 2127 1724 1063β 1.25 1612 973 888 712 5196 2168 1784 11111.5 1678 1031 946 791 5262 2226 1842 11902 1808 1146 1047 891 5392 2341 1943 1290Tab. 6.9: Minimal overhead ω of our hybrid construction <strong>for</strong> n = 1000 when using VSH6.4 ConclusionIn this chapter, we presented an hybrid construction based on Merkle hash trees and MDS codes inorder to decrease the time spent at the receiver to authenticate data. Our new scheme is provablysecure under the random oracle model and enables new participants to join the communication groupat every block boundary. As our previous constructions, this protocol allows the whole data packetsto be recovered at the receiver. The tradeoff between overhead and authentication speed limits the applicationof many constructions. Our implementation results showed that when the number of groupsg is suitably chosen, our packet overhead and authentication speed are much smaller than <strong>for</strong> MDScode-based scheme. Indeed, when using 512-bit packets, our overhead is between 39% and 88% ofour previous authentication scheme while the authentication speed is between 35% and 68%. Whenusing larger packets, the benefits of our hybrid construction increase even further as the authenticationspeed is between 10% and 25%. The advantages of our scheme are particularly important when thereliability of the network is small and the pollution due to the attacker is large.108


6.4. CONCLUSIONP = 512 P = 4096αα0.5 0.75 0.8 0.9 0.5 0.75 0.8 0.91.1 57.10% 79.45% 82.06% 88.06% 81.35% 89.82% 90.50% 92.19%β 1.25 52.73% 74.33% 78.65% 83.96% 78.24% 86.58% 88.10% 89.09%1.5 47.13% 67.17% 71.23% 78.63% 73.66% 81.54% 82.82% 84.70%2 39.65% 57.70% 60.70% 67.45% 66.21% 73.59% 74.13% 75.00%Tab. 6.10: Ratioωω MDS<strong>for</strong> n = 1000 when using VSHP = 512 P = 4096αα0.5 0.75 0.8 0.9 0.5 0.75 0.8 0.91.1 27.77% 45.15% 48.32% 52.56% 8.99% 17.80% 19.87% 22.63%β 1.25 28.11% 47.54% 47.76% 51.24% 9.12% 18.06% 19.50% 21.77%1.5 27.93% 46.27% 49.63% 51.92% 9.05% 17.48% 19.00% 22.21%2 27.70% 44.80% 49.63% 60.20% 8.97% 16.82% 19.00% 23.78%Tab. 6.11: Ratio T <strong>for</strong> n = 1000 when using VSHFollowing Gao and Yao’s approach [53], we show that we could use a THF instead of a digitalsignature without weakening the security of the construction. We also saw that when we employedVSH as a THF then the benefit in term of authentication speed increased even further.109


7ConclusionStreaming media, online gaming, satellite transmission and military defense systems are a few examplesof applications that are based on broadcast communication. Broadcasting exhibits requirementswhich prevent point-to-point communication protocols to be directly utilized.The purpose of this thesis was to design provably secure protocols <strong>for</strong> data origin authenticationover channels where opponents could delete, reorder or inject bogus elements. In multicast communication,bandwidth availability and computational power of the participants are the core concerns.We first presented two constructions based on erasure correcting codes in order to enable originauthentication as well as total recovery of the data stream despite packet losses and the opponent’sinjections. The coding techniques studied in this thesis provide solutions tailored according to thecomputational power of the receivers via the tradeoff rateless/MDS codes. Second, we studied thecase of delayed broadcast where the receiver has knowledge of a larger portion of the data stream. Inthis case, we design two stream authentication schemes reducing the number of signature verificationqueries to be per<strong>for</strong>med at the receiver. Furthermore, our second construction based on PH enabledthe receivers to filter elements upon reception achieving memory savings. Finally, we show how111


7. CONCLUSIONto reduce the receiver authentication time combing MDS codes and Merkle hash trees. This newconstruction also exhibits a smaller packet overhead than the previous MDS code-based scheme. Inaddition, the use of a THF like VSH can improve the running time of this approach even further if itis used instead of a digital signature to ensure non-repudiation of the source of streaming. Note thatthe use of Poly-Reconstruct makes the protocols developed in this thesis generic, i.e. those schemesare not restricted to any particular adversary behavior (such as bursty erasures <strong>for</strong> instance) but solvethe problem <strong>for</strong> the general instance.Note that the security of our constructions relies on collision resistant hash functions. This requirementis to prevent a dishonest sender from building two parallel streams having the same digestsand fooling the receivers by having them accepting one stream <strong>for</strong> the other. Nevertheless, in mostsituations, the opponent O will be an external party trying to alter the stream between the sender’stransmission station and the receiver’s reception base. As a consequence, O has no control on thechoice of data packets P 1 ,...,P n . When looking at the security proofs contained in Appendix A,we see that O fools a receiver if he can construct ˜S j such that h(˜S j ) = h(Ŝj) while ˜S j ≠ Ŝj or agenuine message m such that h(m) = h(BID‖τ par ‖h 1 ‖ · · · ‖h n ) when verifying the signature. Thismeans that h only needs to be second preimage resistant. Nonetheless, in such a situation, we do notrecommend to use a hash function whose collision resistance has been broken since this weaknessmay lead to a more efficient algorithm to attack its second preimage resistance as it was the case <strong>for</strong>MD4 in [126, 157].As said earlier, computational efficiency is an important parameter <strong>for</strong> authentication protocols.As digital signatures can be time expensive to verify, one must try to minimize the number of signatureverifications each receiver has to per<strong>for</strong>m. The use of a Merkle hash tree as a one-way accumulator byKarlof et al.exhibits a small number of signature verification queries V (n) to be per<strong>for</strong>med at the receiver.The problem with this construction is the large overhead due to the size of witnesses. It shouldbe noticed that V (n) is independent of the accumulator structure. A possibility of improvement wouldbe to design a cryptographic accumulator whose witness size is reduced while maintaining the speedof computation. Notice that such a primitive would have a large area of applications since accumulatorsare used <strong>for</strong> time-stamping, fail-stop signatures and key escrow schemes <strong>for</strong> instance. It shouldbe noticed that the accumulator designed by Nguyen [99] is efficient in an overhead point of view asthe witnesses are as large as the accumulated elements. The problem of this elliptic curve-based approachis that verifying that an element has been accumulated requires one pairing computation [29]and Scott et al.showed that such a process can be more expensive than a RSA signature verificationquery [134]. Given this verification process has to be done <strong>for</strong> each received augmented packet, sucha construction is not more efficient than the sign-each approach at the receiver.112


Another problem <strong>for</strong> future research is to obtain unconditional security while maintaining efficiencysince the few unconditionally secure constructions have requirements which make them unsuitable<strong>for</strong> practical applications as seen in Chapter 3.113


APPENDIX


ASecurity ProofsThis appendix contains the security proofs omitted in the main part of this thesis.A.1 MDS Code-based <strong>Authentication</strong> SchemeAssume that the scheme is either insecure or not (α,β)-correct. By definition, a PPT opponent Ocan break the scheme security or correctness with a non-negligible probability π(k) where k is thesecurity parameter setting up the digital signature and the hash function. There<strong>for</strong>e, we must haveeither cases:(1) With probability at least π(k)/2, O breaks the scheme correctness.(2) With probability at least π(k)/2, O breaks the scheme security.It should be noticed that since π(k) is a non-negligible function of k, so is π(k)/2.Point (1). We will demonstrate by contradiction that if O can break the scheme correctness in polynomialtime then either he can <strong>for</strong>ge the digital signature or he can find a collision <strong>for</strong> the hash function117


A. SECURITY PROOFSin polynomial time as well.This will be proved by turning an attack breaking the (α,β)-correctness of our construction into asuccessful attack against either primitive.For this attack, O will have access to the signing algorithm Sign SK (but O will not have access to SKitself). He can use the public key PK as well as the collision resistant hash function h. O will beallowed to run AuthenticatorMDSscheme whose queries are written as (BID i ,n i ,α i ,β i ,ρ i , P i , DP i )where DP i is the set of n i data packets of bit length P i to be authenticated. In order to get thecorresponding output, the signature is obtained by querying Sign SK as a black-box at Step 3 of AuthenticatorMDSscheme.According to our hypothesis, O broke the correctness of the construction. This means that, followingthe previous process, O managed to obtain values BID,n,α,β,ρ, P and a set of received packets RPsuch that:• ∃i : (BID,n,α,β,ρ, P) = (BID i ,n i ,α i ,β i ,ρ i , P i ).Denote DP = {P 1 ,...,P n }(= DP i ) the n data packets associated with this query and APthe response given to O. In particular, we denote σ the signature corresponding to DP andgenerated as in Step 3 of AuthenticatorMDSscheme.• |RP ∩ AP| ≥ ⌈α n⌉ and |RP| ≤ ⌊β n⌋.• {P 1,...,P ′ n} ′ = DecoderMDSscheme(PK, BID,n,α,β,ρ, P, List, RP) where P j ′ ≠ P j <strong>for</strong>some j ∈ {1,...,n}.In the previous statement, List designates the list of irreducible polynomials from Table 4.3. As saidin Section 4.4.1, it is assumed that List contains only one polynomial Q(X) per degree value and thevalue q as well as the pad length l can be determined from the content of that table.Assume that the digital signature is un<strong>for</strong>geable and the hash function is collision resistant.Since |RP ∩ AP| ≥ ⌈α n⌉ and |RP| ≤ ⌊β n⌋, Step 1 of DecoderMDSscheme ends successfully. Theconsistency of Poly-Reconstruct involves that the list returned by MPR at Step 2 contains the elementh 1 ‖ · · · ‖h n ‖σ corresponding to DP after removing the pad of length l.As the digital signature is un<strong>for</strong>geable and the hash function is collision resistant, the pair message/signaturegoing through the verification process at Step 3 correspond to DP. There<strong>for</strong>e, at the118


end of that step, we have:A.1. MDS CODE-BASED AUTHENTICATION SCHEME∀i ∈ {1,...,n}h ′ i = h i (= h(Ŝi))For the same reason as be<strong>for</strong>e, at the end of Step 4, we have:∀i ∈ {1,...,n} Ŝ ′ i = ∅ or Ŝ ′ i = ŜiSince |RP ∩ AP| ≥ ⌈α n⌉, the MDS decoder output the ⌈α n⌉ original symbols S 1 ,...,S ⌈α n⌉ duringStep 5. Thus, at the end of Step 6, DecoderMDSscheme returns to the receiver the n original datapackets, i.e.:∀i ∈ {1,...,n} P i ′ = P iWe obtain a contradiction with our original hypothesis which stipulated:∃j ∈ {1,...,n}P ′ j ≠ P jAs a consequence, we deduce that either the hash function is not collision resistant or the digital signatureis not secure.Point (2). We will demonstrate by contradiction that if O can break the scheme correctness in polynomialtime then either he can <strong>for</strong>ge the digital signature or he can find a collision <strong>for</strong> the hash functionin polynomial time as well.We consider the same kind of reduction as in Point (1). The opponent O breaks the security of thescheme if one of the following holds:I. AuthenticatorMDSscheme was never queried on input BID,n,α,β,ρ, P and the decoding algorithmDecoderMDSscheme does not reject RP, i.e. {P ′ 1,...,P ′ n} ≠ ∅ where {P ′ 1,...,P ′ n} =DecoderMDSscheme(PK, BID,n,α,β,ρ, P, List, RP).II. AuthenticatorMDSscheme was queried on input BID,n,α,β,ρ, P <strong>for</strong> some data packets DP ={P 1 ,...,P n }. Nevertheless, the output of DecoderMDSscheme verifies P ′ j ≠ P j <strong>for</strong> somej ∈ {1,...,n}.Case I. Since DecoderMDSscheme output some non-empty packets, Step 3 had to terminate successfully.Thus, it has been found a pair (h(BID‖n‖α‖β‖P‖h 1 ‖ · · · ‖h n ),σ) such that:Verify PK (h(BID‖n‖α‖β‖P‖h 1 ‖ · · · ‖h n ),σ) = TRUE119


A. SECURITY PROOFSIf O never queried AuthenticatorMDSscheme <strong>for</strong> block tag BID then the previous pair is a <strong>for</strong>gery ofthe digital signature.If O queried AuthenticatorMDSscheme <strong>for</strong> block tag BID then denote (BID, ˆn, ˆα, ˆβ, ˆρ, ˆP) his query.By hypothesis, we have:(BID, ˆn, ˆα, ˆβ, ˆρ, ˆP) ≠ (BID,n,α,β,ρ, P)As ρ is uniquely determined when n,α and β are given, we get:(BID, ˆn, ˆα, ˆβ, ˆP) ≠ (BID,n,α,β, P)There<strong>for</strong>e, the previous pair is a <strong>for</strong>gery of the signature scheme.Case II. We have the same situation as Point (1).A.2 Multiple Block <strong>Authentication</strong> Scheme with FilteringAssume that the scheme is either insecure or not (α,β)-correct. By definition, a PPT opponent Ocan break the scheme security or correctness with a non-negligible probability π(k) where k is thesecurity parameter setting up the digital signature and the hash function. There<strong>for</strong>e, we must haveeither cases:(1) With probability at least π(k)/2, O breaks the scheme correctness.(2) With probability at least π(k)/2, O breaks the scheme security.As π(k) is a non-negligible function of k, so is π(k)/2.Point (1). We will demonstrate by contradiction that if O can break the scheme correctness in polynomialtime then either he can <strong>for</strong>ge the digital signature or he can find a collision <strong>for</strong> the hash functionin polynomial time as well.This will be proved by turning an attack breaking the (α,β)-correctness of our construction into asuccessful attack against either primitive.For this attack, O will have access to the signing algorithm Sign SK (but O will not have access to SKitself). He can use the public key PK as well as the collision resistant hash function h. O will beallowed to run AuthenticatorFiltering whose queries are written as (FID i ,λ i ,n i ,α i ,β i ,ρ i , P i , DP i )120


A.2. MULTIPLE BLOCK AUTHENTICATION SCHEME WITH FILTERINGwhere DP i is the set of λ i n i data packets to be authenticated. In order to get the corresponding output,the signature is obtained by querying Sign SK as a black-box at Step 4 of AuthenticatorFiltering.According to our hypothesis, O broke the correctness of the construction. This means that, followingthe previous process, O managed to obtain values FID,λ,n,α,β,ρ, P and a set of received packetsRP BID (<strong>for</strong> some BID ∈ {1,...,λ}) such that:• ∃i : (FID,λ,n,α,β,ρ, P) = (FID i ,λ i ,n i ,α i ,β i ,ρ i , P i )Denote DP = {P 1,1 ,...,P λ,n }(= DP i ) the λn data packets associated with this query andAP the response given to O. In particular, we denote σ the signature corresponding to DP andgenerated as in Step 4 of AuthenticatorFiltering.• |RP BID ∩ AP BID | ≥ ⌈α n⌉ and |RP BID | ≤ ⌊⌊β n⌋.• {P BID,1,...,P ′ BID,n} ′ = DynamicDecoder(PK, FID, BID,n,α,β,ρ, P, List, KnownHashes,HashCodeword, RP BID ) where PBID,j ′ ≠ P BID,j <strong>for</strong> some j ∈ {1,...,n}.In the previous statement, AP BID denotes the subfamily of AP related to block number BID. We wouldalso like to draw the reader’s attention to the fact that O does not have any influence either on theboolean value KnownHashes or the content of HashCodeword as these two elements are updated bythe receiver personally. Thus O must succeed in both following cases:A. The value of KnownHashes is FALSEB. The value of KnownHashes is TRUECase A. Due to the design of DynamicDecoder, the family {P BID,1,...,P ′ BID,n} ′ has been returned asan output of DecoderBlock. Since |RP BID ∩ AP BID | ≥ ⌈α n⌉ and |RP BID | ≤ ⌊β n⌋, we can apply thesame reasoning as in the proof of Theorem 5.1 (Point (1) - Case A). Thus, we would deduce that,after this query, KnownHashes is TRUE while the content of HashCodeword is consistent with AP BID ,that is:∀i ∈ {1,...,n} HashCodeword(i) = h(ŜBID+1,i) (when BID < λ)Case B. The family {P BID,1,...,P ′ BID,n} ′ has been returned after a query to FilterElements. Since theboolean KnownHashes is reinitialized to FALSE each time the first block of a new family is to be processed,we deduce that DynamicDecoder successfully queried DecoderBlock <strong>for</strong> family tag FID. Denote˜BID the last block tag such that DecoderBlock was successfully run. We have: ˜BID = BID − µ<strong>for</strong> some µ ≥ 1.For ease of explanation, we assume µ = 1. Due to our result from Case A, at the end of the query onblock ˜BID = BID − 1, KnownHashes is TRUE and HashCodeword contains the original digests <strong>for</strong>121


A. SECURITY PROOFSthe codeword of block (BID − 1) + 1 = BID: h(ŜBID,1),...,h(ŜBID,n).Now, we study the case of block BID which is under attack by O. Assume that some elements ofthe output {P ′ BID,1,...,P ′ BID,n} are empty. Due to the design of FilterElements this happens if andonly if the decoding process at Step 3.1 did not occur. This means that we have collected less than⌈α n⌉ elements at the end of Step 2.2. Nevertheless, |RP BID ∩ AP BID | ≥ ⌈α n⌉ and HashCodeword =(h(ŜBID,1),...,h(ŜBID,n)). There<strong>for</strong>e, we must have at least ⌈α n⌉ values. We obtain a contradiction.There<strong>for</strong>e, none of the packets {P ′ BID,1,...,P ′ BID,n} is empty. As a consequence, they were obtainedby removing the pad from some message (SBID,1 ′ · · · SBID,⌈α ′ n⌉ ) at Step 3.2. Since P BID,j ′ is an incorrectnon-empty packet, we have PBID,j ′ ≠ P BID,j. Thus, the message (SBID,1 ′ · · · SBID,⌈α ′ n⌉) is differentfrom the original message (S BID,1 · · · S BID,⌈α n⌉). It follows that at least one of the non-erased coordinatesof the codeword (Ŝ′ BID,1· · · Ŝ′ BID,n) at Step 3 is different from the corresponding coordinate of(ŜBID,1 · · · ŜBID,n). That is:⎧⎨∃θ ∈ {1,...,n}/FID‖BID‖θ‖Ŝ′ BID,θ ‖B θ‖F θ ∈ RP BID⎩ ŜBID,θ ′ ≠ ŜBID,θ<strong>for</strong> some B θ and F θNevertheless, Ŝ′ BID,θ has been selected at Step 2.2. There<strong>for</strong>e: h(Ŝ′ BID,θ) = HashCodeword(θ). Nonetheless,we previously showed that HashCodeword contained the original digests of block BID. Inparticular: HashCodeword(θ) = h(ŜBID,θ). So: h(Ŝ′ BID,θ ) = h(ŜBID,θ) while Ŝ′ BID,θ ≠ ŜBID,θ. Thiscontradicts the collision resistance of h.Now, we would like to argue about the case ˜BID = BID − µ when µ > 1. This means that DynamicDecoderonly queried (successfully) FilterElements <strong>for</strong> blocks BID − µ + 1,...,BID − 1. Inthis case, it is easy to see, by recursion on the block tag value, that the different updates of Hash-Codeword are consistent with the original block hashes of DP. That is, at the end of query on blocktag ˜BID, HashCodeword contains the digests <strong>for</strong> block ˜BID + 1 (see above); at the end of queryon block tag ˜BID + 1, HashCodeword contains the digests <strong>for</strong> block ˜BID + 2 and so on. Thus, atthe beginning of the query on the block tag BID attacked by O, HashCodeword contains the originalhashes h(ŜBID,1),...,h(ŜBID,n). There<strong>for</strong>e, we obtain a collision <strong>for</strong> the hash function as previously.Point (2). We will demonstrate by contradiction that if O can break the scheme correctness in polynomialtime then either he can <strong>for</strong>ge the digital signature or he can find a collision <strong>for</strong> the hash functionin polynomial time as well.We consider the same kind of reduction as in Point (1). The opponent O will succeed if one of thefollowing holds:122


A.2. MULTIPLE BLOCK AUTHENTICATION SCHEME WITH FILTERINGI. AuthenticatorFiltering was never queried on input FID,λ,n,α,β,ρ, P and the decoding algorithmDecoderBlock does not reject RP BID , i.e. {P BID,1,...,P ′ BID,n} ′ ≠ ∅ where:{P BID,1,...,P ′ BID,n} ′ = DynamicDecoder(PK, FID, BID,n,α,β,ρ, P, KnownHashes, HashCo--deword, RP BID ).II. AuthenticatorFiltering was queried on input FID,λ,n,α,β,ρ, P <strong>for</strong> some data packets DP ={P 1,1 ,...,P λ,n }. Nevertheless, the output of DynamicDecoder verifies P ′ BID,j ≠ P BID,j <strong>for</strong>some BID ∈ {1,...,λ} and some j ∈ {1,...,n}.Case I. As in Point (1), we have two cases to consider according to the value of KnownHashes at thebeginning of the query on block BID.• Sub-case IA. If the value of KnownHashes is FALSE then DynamicDecoder output a non-empty set{P BID,1,...,P ′ BID,n} ′ after successfully querying DecoderBlock. Since Step 2 of the latteralgorithm had to terminate successfully, VerifySignatureFamily output a pair(h(FID‖n‖λ‖α‖β‖P‖h 1 ‖ · · · ‖h λ ),σ) such that:Verify PK (h(FID‖n‖λ‖α‖β‖P‖h 1 ‖ · · · ‖h λ ),σ) = TRUEIf O never queried Authenticator <strong>for</strong> family tag FID then the previous pair is a <strong>for</strong>gery of the digitalsignature.If O queried Authenticator <strong>for</strong> family tag FID then denote (FID, ˜λ,ñ, ˜α, ˜β, ˜ρ, ˜P) his query. By hypothesis,we have:(FID, ˜λ,ñ, ˜α, ˜β, ˜ρ, ˜P) ≠ (FID,λ,n,α,β,ρ, P)As in Chapter 4, we assumed that ρ was uniquely determined when n,λ,α,β were known. Thus, theprevious relation is equivalent to:(˜λ,ñ, ˜α, ˜β, ˜P) ≠ (λ,n,α,β, P)There<strong>for</strong>e, the pair output by VerifySignatureFamily is a <strong>for</strong>gery of the signature scheme.• Sub-case IB. If the value of KnownHashes is TRUE then it means that there exists an earlierblock (numbered ˜BID < BID) which was used to successfully verify a signature <strong>for</strong> parametersFID,λ,n,α,β,ρ, P. In this case, we can per<strong>for</strong>m on that earlier block the same reasoning as in theprevious case to obtain a contradiction with the security of either the signature scheme or the hashfunction.123


A. SECURITY PROOFSCase II. We have the same situation as Point (1) - Case A.A.3 Hybrid Stream <strong>Authentication</strong> SchemeAssume that the scheme is either insecure or not (α,β)-correct. By definition, a PPT opponent Ocan break the scheme security or correctness with a non-negligible probability π(k) where k is thesecurity parameter setting up the digital signature and the hash function. There<strong>for</strong>e, we must haveeither cases:(1) With probability at least π(k)/2, O breaks the scheme correctness.(2) With probability at least π(k)/2, O breaks the scheme security.As π(k) is a non-negligible function of k, so is π(k)/2.Point (1). We will demonstrate by contradiction that if O can break the scheme correctness in polynomialtime then either he can <strong>for</strong>ge the digital signature or he can find a collision <strong>for</strong> the hash functionin polynomial time as well.This will be proved by turning an attack breaking the (α,β)-correctness of our construction into asuccessful attack against either primitive.For this attack, O will have access to the signing algorithm Sign SK (but O will not have access toSK itself). He can use the public key PK as well as the collision resistant hash function h. O willbe allowed to run AuthenticatorHybrid whose queries are written as (BID i ,g i ,n i ,α i ,β i ,ρ i , P i , DP i )where DP i is the set of n i data packets to be authenticated. In order to get the corresponding output,the signature is obtained by querying Sign SK as a black-box at Step 3 of AuthenticatorHybrid.According to our hypothesis, O broke the correctness of the construction. This means that, followingthe previous process, O managed to obtain values BID,g,n,α,β,ρ, P and a set of received packetsRP such that:• ∃i : (BID,g,n,α,β,ρ, P) = (BID i ,g i ,n i ,α i ,β i ,ρ i , P i ).Denote DP = {P 1 ,...,P n }(= DP i ) the n data packets associated with this query and APthe response given to O. In particular, we denote σ the signature corresponding to DP andgenerated as in Step 3 of AuthenticatorHybrid.• |RP ∩ AP| ≥ ⌈α n⌉ and |RP| ≤ ⌊β n⌋.124


A.3. HYBRID STREAM AUTHENTICATION SCHEME• {P 1,...,P ′ n} ′ = DecoderHybrid(PK, BID,g,n,α,β,ρ, P, List, RP) where P j ′ ≠ P j <strong>for</strong> somej ∈ {1,...,n}.Assume that the digital signature is un<strong>for</strong>geable and the hash function is collision resistant.Since |RP ∩ AP| ≥ ⌈α n⌉ and |RP| ≤ ⌊β n⌋, Step 1 of DecoderHybrid ends successfully. The consistencyof Poly-Reconstruct involves that the list returned by MPR at Step 2 contains the elementr 1 ‖ · · · ‖r g ‖σ corresponding to DP once the pad is removed.As the digital signature is un<strong>for</strong>geable and the hash function is collision resistant, the pair message/signaturegoing through the verification process at Step 3 correspond to DP. There<strong>for</strong>e, at theend of that step, we have:∀i ∈ {1,...,g} r i ′ = r iAs the receiver has recovered the g original tree roots, it follows that, at the end of Step 4, we have:∀i ∈ {1,...,n} Ŝ ′ i = ∅ or Ŝ ′ i = Ŝias using the tree paths corresponds to the use of the Merkle hash trees as collision resistant accumulatorslike Karlof et al.[71]. Since |RP ∩ AP| ≥ ⌈α n⌉, at Step 5, the MDS decoder output the ⌈α n⌉original symbols S 1 ,...,S ⌈α n⌉ . Thus, at the end of Step 6, DecoderHybrid returns to the receiverthe n original data packets, i.e.:∀i ∈ {1,...,n} P i ′ = P iWe obtain a contradiction with our original hypothesis which stipulated:∃j ∈ {1,...,n}P ′ j ≠ P jAs a consequence, we deduce that either the hash function is not collision resistant or the digital signatureis not secure.Point (2). We will demonstrate by contradiction that if O can break the scheme correctness in polynomialtime then either he can <strong>for</strong>ge the digital signature or he can find a collision <strong>for</strong> the hash functionin polynomial time as well.We consider the same kind of reduction as in Point (1). The opponent O breaks the security of thescheme if one of the following holds:I. AuthenticatorHybrid was never queried on input BID,g,n,α,β,ρ, P and the decoding al-125


A. SECURITY PROOFSgorithm DecoderHybrid does not reject RP, i.e. {P 1,...,P ′ n} ′ ≠ ∅ where {P 1,...,P ′ n} ′ =DecoderHybrid(BID,g,n,α,β,ρ, P, List, RP).II. AuthenticatorHybrid was queried on input BID,g,n,α,β,ρ, P <strong>for</strong> some data packets DP ={P 1 ,...,P n }. Nevertheless, the output of Decoder verifies P j ′ ≠ P j <strong>for</strong> some j ∈ {1,...,n}.Case I. Since DecoderHybrid output some non-empty packets, Step 3 had to terminate successfully.In particular, it has been found a pair (h(BID‖n‖g‖α‖β‖P‖r 1 ‖ · · · ‖r g ),σ) (after removing the pad)such that:Verify PK (h(BID‖n‖g‖α‖β‖P‖r 1 ‖ · · · ‖r g ),σ) = TRUEIf O never queried AuthenticatorHybrid <strong>for</strong> block tag BID then the previous pair is a <strong>for</strong>gery of thedigital signature.If O queried AuthenticatorHybrid <strong>for</strong> block tag BID then denote (BID,g i ,n i ,α i ,β i ,ρ i , P i ) his query.By hypothesis we have:(BID,g i ,n i ,α i ,β i ,ρ i , P i ) ≠ (BID,g,n,α,β,ρ, P)As said in Section 6.2.1, when n,g,α,β, P are given, ρ is uniquely determined. Thus, the previousrelation is equivalent to:(BID,g i ,n i ,α i ,β i , P i ) ≠ (BID,g,n,α,β, P)There<strong>for</strong>e, the previous pair is a <strong>for</strong>gery of the signature scheme.Case II. We have the same situation as Point (1).126


BPad DesignThis appendix contains the construction of the pads used in our stream authentication protocols. Asin the main body of this thesis, we denote P the bit size of any packet P i , H the bit size of digestsproduced by h and S the bit size of signatures.B.1 LT Code-based <strong>Authentication</strong> SchemeWe describe the length of the pad occurring at Step 3 of Algorithm 4.3 as well as the size of thecorresponding field F 2 q <strong>for</strong> polynomial evaluation.At Step 3, one has to represent τ := h 1 ‖ · · · ‖h N ‖σ over ρ N + 1 field elements. So, we have:q ≥⌈ ⌉ H N + Sρ N + 1It should be noticed that A(X) is evaluated at N distinct points of F 2 q. Thus, we must have:q ≥ ⌈log 2 N ⌉127


B. PAD DESIGNThere<strong>for</strong>e, we need to have:⌈ ⌉ H N + S≥ ⌈logρ N + 1 2 N ⌉(B.1)The previous equation represents a constructibility requirement <strong>for</strong> our scheme. Even if Inequality(B.1) is verified in most practical situations, we need to ensure the constructibility of our approach<strong>for</strong> any case. The solution to this problem is simple. Indeed, one needs to pre-pad τ with ξ zeros asτ‖0 ξ where ξ is the smallest element in N such that:⌈ ⌉H N + S + ξ≥ ⌈logρ N + 1 2 N ⌉(B.2)Note that Inequality (B.1) corresponds to the case ξ = 0 in Inequality (B.2). Notice that Inequality(B.2) is the same as Inequality (4.1) appearing at Step 3 of Algorithm 4.3. Denote b := H N + S +ξ mod (ρ N + 1). Thus, the length of the pad to be appended to τ at Step 3 is l bits where:⎧⎨ 0 if b = 0l :=⎩ ρ N + 1 − b otherwiseSo, we get:⌈ ⌉H N + S + ξq =ρ N + 1Important Remark. We can notice that in<strong>for</strong>mation stored in the public Table 4.1 is sufficient tocompute of the previous pad of length l and q.B.2 MDS Code-based <strong>Authentication</strong> SchemeWe describe the length of the pad occurring at Step 3 of Algorithm 4.5 as well as the size of thecorresponding field F 2 q <strong>for</strong> polynomial evaluation.At Step 3, one has to represent τ := h 1 ‖ · · · ‖h n ‖σ over ρn + 1 field elements and per<strong>for</strong>m nevaluations of the polynomial A(X). Applying the same reasoning as in Appendix B.1, we needs topre-pad τ with ξ zeros as τ‖0 ξ where ξ is the smallest element in N such that:⌈ ⌉H n + S + ξ≥ ⌈logρn + 1 2 n⌉(B.3)The above inequality is the same as Inequality (4.2) appearing at Step 3 of Algorithm 4.5. Denoteb := H n + S + ξ mod (ρn + 1). Thus, the length of the pad to be appended to τ at Step 3 is l bitswhere:128


B.3. MULTIPLE BLOCK AUTHENTICATION SCHEME⎧⎨ 0 if b = 0l :=⎩ ρn + 1 − b otherwiseSo, we get:⌈ ⌉H n + S + ξq =ρn + 1As <strong>for</strong> the LT code-based authentication scheme, the in<strong>for</strong>mation stored in the public Table 4.3 issufficient to compute of the previous pad of length l and q.B.3 Multiple Block <strong>Authentication</strong> SchemeWe describe the length of the pad occurring at Steps 3.1 and 5 of Algorithm 5.1 as well as the size ofthe corresponding field F 2 q <strong>for</strong> polynomial evaluation.At Step 3.1, one has to represent h(Ŝi,1)‖ · · · ‖h(Ŝi,n) over ρn + 1 field elements and per<strong>for</strong>m nevaluations of the polynomial B i (X). Applying the same reasoning as in Appendix B.1, we needs topre-pad h(Ŝi,1)‖ · · · ‖h(Ŝi,n) with ξ 1 zeros where ξ 1 is the smallest element in N such that:⌈ ⌉ H n + ξ1≥ ⌈logρn + 1 2 n⌉Remark that Inequality (B.4) does not depend on the block number i.(B.4)At Step 5, one has to represent τ := h 1 ‖ · · · ‖h λ ‖σ over ρn + 1 field elements and per<strong>for</strong>m nevaluations of the polynomial F(X). Applying the same reasoning as above, we needs to pre-pad τwith ξ 2 zeros where ξ 2 is the smallest element in N such that:⌈ ⌉H λ + S + ξ2≥ ⌈logρn + 1 2 n⌉(B.5)In order to use the same field F 2 q in both cases, one needs to set ξ as:ξ = max(ξ 1 ,ξ 2 )Thus, appending ξ zeros to h(Ŝi,1)‖ · · · ‖h(Ŝi,n) and τ guarantees that both Inequality (B.4) andInequality (B.5) are verified. As a consequence, the value of q is:(⌈ ⌉ ⌈ ⌉)H n + ξ H λ + S + ξq = max ,ρn + 1 ρn + 1Thus, the length l 1 (respectively l 2 ) of the pad to be appended to h(Ŝi,1)‖ · · · ‖h(Ŝi,n) (respectively129


B. PAD DESIGNτ) at Step 3.1 (respectively 5) is defined as:l 1 := (ρn + 1)q − H nl 2 := (ρn + 1)q − (H λ + S)As <strong>for</strong> the LT code-based and the MDS code-based authentication schemes, the in<strong>for</strong>mation stored inthe public Table 5.1 is sufficient to compute of the previous pads and q.B.4 Multiple Block <strong>Authentication</strong> Scheme with FilteringWe describe the length of the pad occurring at Steps 1 and 2.2 of Algorithm 5.4 when using the MDScode.The elements encoded at Step 1 represent a (n P)-bit long string while those encoded at Step 2.2constitute a (n(P + H))-bit long string. We want to use the same MDS code in both cases and werequire it to correct up to n − ⌈α n⌉ erasures. Thus, the field F 2˜q is such as:⌈ ⌉ n(P + H)˜q :=⌈α n⌉Thus, the length l 1 (respectively l 2 ) of the pad to be appended to P λ,1 ‖ · · · ‖P λ,n (respectively˜P i,1 ‖ · · · ‖ ˜P i,n ) at Step 1 (respectively 2.2) is defined as:l 1 := ⌈α n⌉ ˜q − n Pl 2 := ⌈α n⌉ ˜q − n(P + H)As <strong>for</strong> the previous authentication schemes, the in<strong>for</strong>mation stored in the public Table 5.1 is sufficientto compute of the previous pads.B.5 Hybrid <strong>Authentication</strong> SchemeWe describe the length of the pad occurring at Step 4 of Algorithm 6.1 as well as the size of thecorresponding field F 2 q <strong>for</strong> polynomial evaluation.At Step 4, one has to represent τ := r 1 ‖ · · · ‖r g ‖σ over ρn + 1 field elements and per<strong>for</strong>m n evaluationsof the polynomial A(X). Applying the same reasoning as in Appendix B.1, we needs to pre-pad130


τ with ξ zeros as τ‖0 ξ where ξ is the smallest element in N such that:⌈ ⌉H g + S + ξ≥ ⌈logρn + 1 2 n⌉B.5. HYBRID AUTHENTICATION SCHEME(B.6)The above inequality is the same as Inequality (6.1) appearing at Step 4 of Algorithm 6.1. Denoteb := H g + S + ξ mod (ρn + 1). Thus, the length of the pad to be appended to τ at Step 4 is l bitswhere:⎧⎨ 0 if b = 0l :=⎩ ρn + 1 − b otherwiseSo, we get:⌈ ⌉H g + S + ξq =ρn + 1As <strong>for</strong> our other schemes, the in<strong>for</strong>mation stored in the public Table 6.1 is sufficient to compute ofthe previous pad of length l and q.131


CAsymptotic Behavior of the Ratio N nIn this appendix, we demonstrate that the ratio <strong>for</strong> our rateless code construction from Section 4.3.1turns out to be O(1) as a function of the block length n.Due to the definition of N , we have:Thus, it is sufficient to prove that m nNn ≤ 1 + 1 mα nis O(1) as a function of n. We have:mn = 1 + 1√ n(c ln ( nδ( () c ln n) √ )) ( n−R)lnδ n ∑ 1δii=1We can find an upper bound on the sum as follows:n−R∑i=11i ≤n∑i=1∫1 ni ≤ 1 + 12 x dx ≤ 1 − ln 2 + lnn 133


C. ASYMPTOTIC BEHAVIOR OF THE RATIO N NThere<strong>for</strong>e, when n is large, we get:mn ≤ 1 + 2c lnn( ln ( ))n 2δ√ n≤ 1 + 2c(ln( nδ)) 3√ nDue to our choice of c in Section 4.1.2, we get:( (m ln n)) 2n ≤ 1 + δAs η < 1 2and δ is a constant, we obtain our result.n 1 2 −η134


DRecovery ProofThe demonstration of Theorem 5.4 presented in this appendix will be similar to the proof of Theorem5.2.We first show that our scheme allows recovery of all data packets as part of this demonstration willbe used to deduce the bound on the number of signature verifications to be per<strong>for</strong>med <strong>for</strong> the wholefamily.Packet Recovery. Let FID be fixed. Due to the definition of the rates α and β, <strong>for</strong> each BID, thereceiver obtains, as set of received packets RP BID , at least ⌈α n⌉ original elements amongst a total notexceeding ⌊β n⌋ pieces of data.• We start focusing on the first block (i.e. BID = 1). As it is the first block of a new family, DynamicDecoderqueries DecoderBlock as a subroutine. Based on the demonstration of Theorem 5.3(Point (1) - Case A), we deduce that the receiver recovers P 1,1 ,...,P 1,n and HashCodeword containsh(Ŝ2,1),...,h(Ŝ2,n).135


D. RECOVERY PROOF• We consider the second block (i.e. BID = 2). Since KnownHashes is TRUE, DynamicDecoderqueries FilterElements as a subroutine. Based on the demonstration of Theorem 5.3 (Point (1) - CaseB), we deduce that the receiver recovers P 2,1 ,...,P 2,n while the content of HashCodeword is updatedto h(Ŝ3,1),...,h(Ŝ3,n).• We see that when iterating this process we obtain total recovery of data <strong>for</strong> blocks 3,...,λ as well.Signature Verification. The previous proof showed that VerifySignatureFamily is only queried onceper family of λ blocks. There<strong>for</strong>e, the number of signature verifications is upper bounded by the sizeof the list constructed by VerifySignatureFamily. We are in the same situation as in Theorem 4.4 soU(n) is an upper bound on that list size. The complexity results follow from the proof of Theorem 5.2.136


Bibliography[1] 3GPP TS 26.346 V7.2.0. Technical specification group services and system aspects; MultimediaBroadcast/Multimedia Service (MBMS); protocols and codecs. Available online at:http://www.3gpp.org/ftp/Specs/html-info/26346.htm, December 2006.[2] Qusai Abuein and Susumu Shibusawa. Efficient loss resistance multicast stream authentication.In Proceedings of the 2004 Internet Conference (IC 2004), Tsukuba, Japan, October 2004.[3] Valentine Afanassiev, Christian Gehrmann, and Ben Smeets. Fast message authentication usingefficient polynomial evaluation. In FSE’97, volume 1267 of Lecture Notes in ComputerScience, pages 190 – 204, Haifa, Israel, January 1997. Springer - Verlag.[4] Mohamed Al-Ibrahim and Josef Pieprzyk. Authenticating multicast streams in lossy channelsusing threshold techniques. In ICN 2001, volume 2094 of Lecture Notes in Computer Science,pages 239 – 249, Colmar - France, July 2001. Springer - Verlag.[5] Noga Alon, Jeff Edmonds, and Michael Luby. Linear time erasure codes with nearly optimalrecovery (extended abstract). In FOCS’95, pages 512 – 519, Milwaukee - USA, October 1995.[6] Ross Anderson, Franscesco Bergadano, Bruno Crispo, Jong-Hyeon Lee, Charalampos Manifavas,and Roger Needham. A new family <strong>for</strong> authentication protocols. Operating Systemreview, 32(4):9 – 20, October 1998.[7] Heba K. Aslan. A hybrid scheme <strong>for</strong> multicast authentication over lossy networks. Computers& Security, 23(8):705 – 713, December 2004.[8] Krishna B. Athreya and Soumendra N. Lahiri. Measure Theory and Probability Theory.Springer, 2006.[9] Niko Barić and Birgit Pfitzmann. Collision-free accumulators and fail-stop signature schemeswithout trees. In Advances in Cryptology - Eurocrypt’97, volume 1233 of Lecture Notes inComputer Science, pages 480 – 494, Konstanz - Germany, May 1997. Springer - Verlag.137


Bibliography[10] Paulo S.L.M. Barreto, Hae Y. Kim, Ben Lynn, and Michael Scott. Efficient algorithms <strong>for</strong>pairing-based cryptosystems. In Advances in Cryptology - Crypto’02, volume 2442 of LectureNotes in Computer Science, pages 354 – 369, Santa Barbara, USA, August 2002. Springer -Verlag.[11] Mihir Bellare, Ran Canetti, and Hugo Krawczyk. Keying hash functions <strong>for</strong> message authentication.In Advances in Cryptology - Crypto’96, volume 1109 of Lecture Notes in ComputerScience, pages 1 – 15, Santa Barbara, USA, August 1996. Springer - Verlag.[12] Josh Benaloh and Michael de Mare. One-way accumulators: A decentralized alternative todigital signatures. In Advances in Cryptology - Eurocrypt’93, volume 765 of Lecture Notes inComputer Science, pages 274 – 285, Lofthus, Norway, May 1993. Springer - Verlag.[13] Francesco Bergadano, Davide Cavagnino, and Bruno Crispo. Individual single source authenticationon the MBONE. In ICME 2000, volume 1, pages 541 – 544, New York, USA, July2000. IEEE Signal Processing Society.[14] Claude Berrou. Codes et Turbocodes. Springer, March 2007.[15] Carlo Blundo, Alfredo De Santis, Amir Herzberg, Shay Kutten, Ugo Vaccaro, and MotiYung. Perfectly-secure key distribution <strong>for</strong> dynamic conferences. In Advances in Cryptology- Crypto’92, volume 740 of Lecture Notes in Computer Science, pages 471 – 486, SantaBarbara, USA, August 1992. Springer - Verlag.[16] Dan Boneh, Ben Lynn, and Hovav Shacham. Short signatures from the Weil pairing. InAdvances in Cryptology - Asiacrypt’01, volume 2248 of Lecture Notes in Computer Science,pages 514 – 532, Gold Coast, Australia, December 2001. Springer - Verlag.[17] Gilles Brassard and Paul Bradley. Fundamentals of Algorithmics. Prentice Hall, 1996.[18] John W. Byers, Michael Luby, and Michael Mitzenmacher. A digital fountain approach to asynchronousreliable multicast. IEEE Journal on Selected Areas in <strong>Communication</strong>s, 20(8):1528– 1540, October 2002.[19] Ran Canetti, Juan Garay, Gene Itkis, Daniele Micciancio, Moni Naor, and Benny Pinkas. <strong>Multicast</strong>security: A taxonomy and efficient constructions. In IEEE Conference on Computer<strong>Communication</strong>s, volume 1, pages 708–716, New York, USA, March 1999. IEEE Press.[20] Dario Catalano, Ronald Cramer, Ivan Damgård, Giovanni Di Crescenzo, David Poincheval,138and Tsuyoshi Takagi. Contemporary Cryptology. Birkhäuser Verlag, July 2005.


Bibliography[21] Pasquale Cataldi, Miquel Pedròs Shatarski, Marco Grangetto, and Enrico Magli. Implementationand per<strong>for</strong>mance evaluation of LT and Raptor codes <strong>for</strong> multimedia applications. InIIH-MSP’06, pages 263 – 266, Pasadena, USA, December 2006. IEEE Computer Society.[22] Yacine Challal, Hatem Bettahar, and Abdelmadjid Bouabdallah. Hybrid and adaptive hashchainingscheme <strong>for</strong> data-streaming source authentication. In High Speed Networks and Multimedia<strong>Communication</strong>s, volume 3079 of Lecture Notes in Computer Science, pages 1056 –1067, Toulouse, France, June 2004. Springer - Verlag.[23] Yacine Challal, Hatem Bettahar, and Abdelmadjid Bouabdallah. A 2 Cast: an Adaptive source<strong>Authentication</strong> protocol <strong>for</strong> multiCast streams. In ISCC 2004, volume 1, pages 363 – 368,Alexandria, Egypt, June 2004. IEEE Press.[24] Yacine Challal, Hatem Bettahar, and Abdelmajid Bouabdallah. A taxonomy of multicast dataorigin authentication: Issues and solutions. IEEE <strong>Communication</strong>s Surveys and Tutorials,6(3):34 – 57, October 2004.[25] Yacine Challal and Abdelmadjid Bouabdallah. Authenticast: a source authentication protocol<strong>for</strong> multicast flows and streams. In International Conference on In<strong>for</strong>mation Security, volume 6of Transaction on Engineering, Computing and Technology, pages 175 – 178, Istanbul, Turkey,June 2005. World En<strong>for</strong>matika Society.[26] Yacine Challal, Abdelmadjid Bouabdallah, and Hatem Bettahar. H 2 A: Hybrid hash-chainingscheme <strong>for</strong> adaptive multicast source authentication of media-streaming. Computer & Security,24(1):57 – 68, February 2005.[27] Yacine Challal, Abdelmadjid Bouabdallah, and Yoann Hinard. RLH: Receiver driven layerhash-chaining <strong>for</strong> multicast data origin authentication. Computer <strong>Communication</strong>s, 28(7):726–740, May 2005.[28] Seonho Choi. Denial of service resistant multicast authentication protocol with predictionhashing and one-way key chain. In ISM 2005, pages 701 – 706, Irvine, USA, December 2005.IEEE Press.[29] Henri Cohen, Gerhard Frey, Roberto Avanzi, <strong>Christophe</strong> Doche, Tanja Lange, Kim Nguyen,and Frederik Vercauteren. Handbook of Elliptic and Hyperelliptic Curve Cryptography, volume34 of Discrete Mathematics and Its Applications. CRC Press, July 2005.[30] Scott Contini, Arjen K. Lenstra, and Ron Steinfeld. VSH: an efficient and provable collisionresistant hash function. In Advances in Cryptology - Eurocrypt’06, volume 4004 of LectureNotes in Computer Science, pages 165 – 182, Saint Petersburg, Russia, May 2006. Springer -Verlag.139


Bibliography[31] Scott Contini, Ron Steinfeld, Josef Pieprzyk, and Krystian Matusiewicz. Acritical look at cryptographic hash function literature. Available online at:http://events.iaik.tugraz.at/HashWorkshop07/papers/Pieprzyk_CriticalLook.pdf, May 2007.[32] Scott Contini and Yiqun Lisa Yin. Forgery and partial key-recovery attacks on HMAC andNMAC using hash collisions. In Advances in Cryptology - Asiacrypt’06, volume 4284 ofLecture Notes in Computer Science, pages 37 – 53, Shanghai, China, December 2006. Springer- Verlag.[33] Thomas M. Cover. Broadcast channels. IEEE Transactions on In<strong>for</strong>mation Theory, IT-18(1):2– 14, January 1972.[34] David Cox, John Little, and Donal O’Shea. Ideals, Varieties and Algorithms: An introductionto Computational Algebraic Geometry and Commutative Algebra (Second Edition). Springer,1997.[35] Tommaso Cucinotta, G. Cecchetti, and G.Ferraro. Adopting redundancy techniques <strong>for</strong> multicaststream authentication. In FTDCS 2003, pages 183– 189, San Juan, Puerto Rico, May2003. IEEE Computer Society.[36] Joan Daemen and Craig S. K. Clapp. Fast hashing and stream encryption with PANAMA. InFSE’98, volume 1372 of Lecture Notes in Computer Science, pages 60 – 74, Paris, France,March 1998. Springer - Verlag.[37] Joan Daemen and Gilles Van Assche. Producing collisions <strong>for</strong> PANAMA, instantaneously. InFSE’07, Lecture Notes in Computer Science, Luxembourg, March 2007. Springer Verlag.[38] Wei Dai. Crypto++ 5.2.1 benchmarks, July 2004.[39] Wei Dai. Crypto++ 5.5 benchmarks. Available online at:http://www.cryptopp.com/benchmarks.html, May 2007.[40] Ufuk Demir and Ozlem Aktaş. Raptor versus Reed Solomon <strong>for</strong>ward error correction codes.In ISCN’06, pages 264 – 269, Istanbul, Turkey, June 2006. IEEE.[41] Yvo Desmedt, Yair Frankel, and Moti Yung. Multi-receiver/multi-sender network security:Efficient authenticated multicast/feedback. In IEEE INFOCOM 1992, volume 3, pages 2045 –2054, Florence, Italy, May 1992. IEEE Press.[42] Yvo Desmedt and Goce Jakimoski. Non-degrading erasure-tolerant in<strong>for</strong>mation authenticationwith an application to multicast stream authentication over lossy channels. In Topics in Cryptology- CT-RSA 2007, volume 4377 of Lecture Notes in Computer Science, pages 324 – 338,San Francisco, USA, February 2007. Springer - Verlag.140


Bibliography[43] Roberto Di Pietro, Stefano Chessa, and Piero Maestrini. Computation memory and bandwidthefficient distillation codes to mitigate dos in multicast. In SecureComm 2005, pages 13 – 22,Athens, Greece, September 2005. IEEE Press.[44] Roberto Di Pietro, Antonio Durante, Luigi V. Mancini, and Vishwas Patil. Addressing theshortcomings of one-way chains. In ASIACCS’06, pages 289 – 296, Taipei, Taiwan, March2006. ACM Press.[45] Reinhard Diestel. Graph Theory (Second Edition). Graduate Texts in Mathematics. Springer,second edition edition, 2000.[46] Hans Dobbertin, Antoon Bosselaers, and Bart Preneel. RIPEMD-160: A strengthened versionof RIPEMD. In Fast Software Encryption, volume 1096 of Lecture Notes in Computer Science,pages 71–82, Cambridge, UK, February 1996. Springer - Verlag.[47] Peter Elias. Coding <strong>for</strong> two noisy channels. In Proceedings of the 3rd London Symposium onIn<strong>for</strong>mation Theory, pages 61 – 76, London, UK, 1955.[48] Omid Etesami, Mehdi Molkaraie, and Amin Shokrollahi. Raptor codes on symmetric channels.Available online at: http://www.cs.berkeley.edu/∼etesami/raptor.pdf, preprint 2003.[49] Omid Etesami and Amin Shokrollahi. Raptor codes on binary memoryless symmetric channels.IEEE Transactions on In<strong>for</strong>mation Theory, 52(5):2033 – 2051, May 2006.[50] Shimon Even, Oded Goldreich, and Silvio Micali. On-line/off-line digital signatures. Journalof Cryptology, 9(1):35 – 67, March 1996.[51] James Chuan Fu and W. Y. Wendy Lou. Distribution Theory of Runs and Patterns and itsApplications. World Scientific Publishing, 2003.[52] Hiroshi Fujii, Wattanawong Kachen, and Kaoru Kurosawa. Combinatorial bounds and designof broadcast authentication. IEICE Transactions, E 79-A(4):502 – 506, 1996.[53] Chong-zhi Gao and Zheng-an Yao. How to authenticate real time streams using improvedonline/offline signatures. In 4th International Conference on Cryptology and Network Security,volume 3810 of Lecture Notes in Computer Science, pages 134 – 146, Xiamen, China,December 2005. Springer-Verlag.[54] Rosario Gennaro and Pankaj Rohatgi. How to sign digital streams. In Advances in Cryptology -Crypto’97, volume 1294 of Lecture Notes in Computer Science, pages 180–197, Santa Barbara,USA, August 1997. Springer-Verlag.141


Bibliography[55] Oded Goldreich. Foundations of Cryptography: Volume I - Basic Tools. Cambridge UniversityPress, 2001.[56] Oded Goldreich. Foundations of Cryptography: Volume II - Basic Applications. CambridgeUniversity Press, 2004.[57] Phillippe Golle and Nagendra Modadugu. Authenticating streamed data in the presence ofrandom packet loss. In Symposium on Network and Distributed Systems Security, pages 13 –22, San Diego, USA, February 2001. Internet Society.[58] Venkatesan Guruswami. List Decoding of Error-Correcting Codes. Springer-Verlag, 2004.[59] Venkatesan Guruswami. Algorithmic Results in List Decoding, volume 2 of Foundations andTrends R○ in Theoretical Computer Science. now Publishers, 2006.[60] Venkatesan Guruswami and Piotr Indyk. Linear-time decoding in error-free settings (extendedabstract). In ICALP, volume 3142 of Lecture Notes in Computer Science, pages 695 – 707,Turku, Finland, July 2004. Springer - Verlag.[61] Venkatesan Guruswami and Atri Rudra. Explicit capacity-achieving list-decodable codes.Technical Report TR05-133, Electronic Colloquium on Computational Complexity, November2005.[62] Venkatesan Guruswami and Madhu Sudan. Improved decoding of Reed-Solomon andalgebraic-geometric codes. IEEE Transactions on In<strong>for</strong>mation Theory, 45(6):1757 – 1767,September 1999.[63] Chris Harrelson, Lawrence Ip, and Wei Wang. Limited randomness LT codes. In 41st AnnualAllerton Conference on <strong>Communication</strong>, Control and Computing, Urbana-Champaign, USA,October 2003.[64] Chris Harrelson, Lawrence Ip, and Wei Wang. LT codes with limited randomness. Availableonline at: http://www.eecs.berkeley.edu/ lip/projects/ltcodes.ps, May 2003.[65] Piotr Indyk. List-decoding in linear time. Technical Report TR02-024, Electronic Colloquiumon Computational Complexity, April 2002.[66] Goce Jakimoski. Unconditionally secure in<strong>for</strong>mation authentication in presence of erasures.In Cryptography and Coding 2005, volume 3796 of Lecture Notes in Computer Science, pages304–321, Cirencester, UK, December 2005. Springer - Verlag.[67] Goce Jakimoski. Primitives and Schemes <strong>for</strong> Non-Atomic In<strong>for</strong>mation <strong>Authentication</strong>. PhDthesis, The Florida State University College of Arts and Sciences, Spring Semester 2006.142


Bibliography[68] Goce Jakimoski and Yvo Desmedt. A tree-based model of unicast stream authentication.Cryptology ePrint Archive, Report 2006/089, March 2006. Available online at:http://eprint.iacr.org/2006/089.pdf.[69] JeaYong Jeong, Yongsu Park, and Yookun Cho. Efficient DoS resistant multicast authenticationschemes. In ICCSA, volume 3481 of Lecture Notes in Computer Science, pages 353 – 362,Singapore, May 2005. Springer - Verlag.[70] Chris Karlof, Yaping Li, and Naveen Sastry. Authenticated block streams using error detectingerasure codes. Manuscript. Available from: http//www.cs.berkeley.edu/ nks/edec/bcastclass.pdf,2003.[71] Chris Karlof, Naveen Sastry, Yaping Li, Adrian Perrig, and J. D. Tygar. Distillation codesand applications to DoS resistant multicast authentication. In 11th Network and DistributedSystems Security Symposium (NDSS), San Diego, USA, February 2004.[72] Richard Karp, Michael Luby, and Amin Shokrollahi. Finite length analysis of LT codes. InInternational Symposium on In<strong>for</strong>mation Theory, page 39, Chicago, USA, June 2004. IEEEPress.[73] Richard Karp, Michael Luby, and Amin Shokrollahi. Verification decoding of Raptor codes.In ISIT 2005, pages 1310 – 1314, Adelaide, Australia, September 2005. IEEE.[74] Donald E. Knuth. The Art of Computer Programming: Volume I - Fundamental Algorithms(Third Edition). Addison - Wesley, 1997.[75] Hugo Mario Krawczyk and Tal D. Rabin. Chameleon hashing and signatures. In NDSS 2000,pages 143 – 154, San Diego, USA, February 2000. Internet Society.[76] Kaoru Kurosawa and Satoshi Obana. Characterization of (k,n) multireceiver authentication.In ACISP 1997, volume 435 of Lecture Notes in Computer Science, pages 204 – 215, Sydney,Australia, July 1997. Springer - Verlag.[77] Jérome Lacan and Jérome Fimes. Systematic MDS erasure codes based on Vandermondematrices. IEEE <strong>Communication</strong>s Letters, 8(9):570 – 572, September 2004.[78] Serge Lang. Linear Algebra (Third Edition). Springer, 1987.[79] Serge Lang. Algebra (Revised Third Edition). Springer, November 2002.[80] Rudolf Lidl and Harald Niederreiter. Introduction to Finite Fields and their Applications (RevisedEdition). Cambridge University Press, 2000.143


Bibliography[81] Ya-Jeng Lin, Shiuhpyng Shieh, and Warren W. Lin. Lightweight, pollution-attack resistantmulticast authentication scheme. In ACM Symposium on In<strong>for</strong>mation, Computer and <strong>Communication</strong>sSecurity, pages 148 – 156, Taipei, Taiwan, March 2006. ACM Press.[82] Donggang Liu and Peng Ning. Multi-level µTESLA: Broadcast authentication <strong>for</strong> distributedsensor networks. ACM Transactions in Embedded Computing Systems, 3(4):800 – 836,November 2004.[83] Donggang Liu, Peng Ning, Sencun Zhu, and Sushil Jajodia. Practical broadcast authenticationin sensor networks. In MobiQuitous 2005, pages 118 – 129, San Diego, USA, July 2005. IEEEPress.[84] Michael Luby. LT codes. In 43rd Annual IEEE Symposium on Foundations of ComputerScience (FOCS’02), pages 271 – 282, Vancouver, Canada, November 2002. IEEE ComputerSociety.[85] Michael Luby, Mark Watson, Tiago Gasiba, Thomas Stockhammer, and Wen Xu. Raptor codes<strong>for</strong> reliable download delivery in wireless broadcast systems. In CCNC 2006, pages 192 – 197,Las Vegas, USA, January 2006. IEEE.[86] Michael G. Luby, Michael Mitzenmacher, M. Amin Shokrollahi, and Daniel A. Spielman.Efficient erasure correcting codes. IEEE Transactions on In<strong>for</strong>mation Theory, 47(2):569 –584, February 2001.[87] Anna Lysyanskaya, Roberto Tamassia, and Nikos Triandopoulos. <strong>Multicast</strong> authentication infully adversarial networks. In IEEE Symposium on Security and Privacy, pages 241 – 253,Oakland, USA, May 2003. IEEE Press.[88] Florence Jessiem MacWilliams and Neil James Alexander Sloane. The Theory of Error-Correcting Codes. North-Holland, 1977.[89] Petar Maymounkov. Online codes. Technical report, New York University, November 2002.[90] Alfred J. Menezes, Paul C. van Oorschot, and Scott A. Vanstone. Handbook of Applied Cryptography.CRC Press, 1996.[91] Ralph Merkle. A certified digital signature. In Advances in Cryptology - Crypto’89, volume435 of Lecture Notes in Computer Science, pages 218–238, Santa Barbara, USA, August 1989.Springer - Verlag.[92] Sarah Miner and Jessica Staddon. Graph-based authentication of digital streams. In IEEESymposium on Security and Privacy, pages 232 – 246, Oakland, USA, May 2001. IEEE Press.144


Bibliography[93] Michael Mitzenmacher and Adrian Perrig. Bounds and improvements <strong>for</strong> BiBa signatureschemes. Technical Report TR-02-02, Harvard University, 2002.[94] Todd K. Moon. Error Correction Coding: Mathematical Methods and Algorithms. Wiley -Interscience, 2005.[95] Moni Naor and Omer Reingold. From unpredictability to indistinguishability: A simple constructionof pseudo-random functions from MACs. In Advances in Cryptology - Crypto’98,volume 1462 of Lecture Notes in Computer Science, pages 267 – 282, Santa Barbara, USA,August 1998. Springer-Verlag.[96] Moni Naor and Moti Yung. Universal one-way hash functions and their cryptographic applications.In 21 st Annual ACM Symposium on Theory of Computing, pages 33 – 43, Seattle, USA,May 1989. ACM Press.[97] National Institute of Standards and Technology. FIPS PUB 186: Digital Signature Standard(DSS). Available online at: http://www.itl.nist.gov/fipspubs/fip186.htm, May 1994.[98] National Institute of Standards and Technology. FIPS 180-2: Secure Hash Standard(SHS). Available online at: http://csrc.nist.gov/publications/fips/fips180-2/fips180-2withchangenotice.pdf, August 2002. Amended 25 February 2004.[99] Lan Nguyen. Accumulators from bilinear pairings and applications. In Topics in CryptologyCT-RSA 2005, volume 3376 of Lecture Notes in Computer Science, pages 275 – 292, SanFrancisco, USA, February 2005. Springer - Verlag.[100] Kaisa Nyberg. Fast accumulated hashing. In Fast Software Encryption - Third InternationalWorkshop, volume 1039 of Lecture Notes in Computer Science, pages 83 – 87, Cambridge,United Kingdom, February 1996. Springer.[101] Kaisa Nyberg and Rainer A. Rueppel. A new signature scheme based on the DSA givingmessage recovery. In ACM CCS, pages 58 – 61, Fairfax, USA, November 1993. ACM Press.[102] Satoshi Obana and Kaoru Kurosawa. Bounds and combinatorial structure of (k,n) multireceiverA-codes. Designs, Codes and Cryptography, 22(1):47 – 63, January 2001.[103] Tatsuaki Okamoto and Akira Shiraishi. A fast signature scheme based on quadratic inequalities.In IEEE Symposium on Security and Privacy, pages 123 – 132, 1985.[104] Henry O’Keeffe and Patrick Fitzpatrick. Gröbner basis solutions of constrained interpolationproblems. Linear Algebra and its Applications, 351 - 352:533 – 551, August 2002.145


Bibliography[105] Ravi Palanki and Jonathan S. Yedidia. Rateless codes on noisy channels. In 38th AnnualConference on In<strong>for</strong>mation Sciences and Systems, Princeton, USA, March 2004.[106] Ravi Palanki and Jonathan S. Yedidia. Rateless codes on noisy channels (extended version).Technical Report TR-2003-124, Mitsubishi Electric Research Laboratories, April 2004.[107] Alain Pannetrat and Rafik Molva. Authenticating real time packet streams and multicasts. In7th International Symposium on Computers and <strong>Communication</strong>s, Taormina, Italy, July 2002.IEEE Computer Society.[108] Alain Pannetrat and Rafik Molva. Efficient multicast packet authentication. In Network andDistributed System Security Symposium (NDSS), San Diego, USA, February 2003. InternetSociety.[109] Jung Min Park, Edwin K. P. Chong, and Howard Jay Siegel. Efficient multicast packet authenticationusing signature amortization. In IEEE Symposium on Security and Privacy, pages 227–240, Oakland, USA, May 2002. IEEE Press.[110] Jung Min Park, Edwin K. P. Chong, and Howard Jay Siegel. Efficient multicast stream authenticationusing erasure codes. ACM Transactions on In<strong>for</strong>mation and System Security, 6(2):258– 285, May 2003.[111] Yongsu Park and Yookun Cho. The eSAIDA stream authentication scheme. In ICCSA, volume3046 of Lecture Notes in Computer Science, pages 799 – 807, San Diego, USA, April 2004.Springer - Verlag.[112] Yongsu Park, Tae-Sun Chung, and Yookun Cho. An efficient stream authentication schemeusing tree chaining. In<strong>for</strong>mation Processing Letters, 86(1):1 – 8, April 2003.[113] Vern Paxson. End-to-end Internet packet dynamics. IEEE/ACM Transactions on Networking,7(3):277 – 292, June 1999.[114] Adrain Perrig, Ran Canetti, Dawn Song, and J. D. Tygar. Efficient and secure source authentication<strong>for</strong> multicast. In NDSS 2001, pages 35 – 46, San Diego, USA, February 2001. InternetSociety.[115] Adrian Perrig. The BiBa one-time signature and broadcast authentication protocol. In 8thACM Conference on Computer and <strong>Communication</strong>s Security, pages 56 – 73, Philadelphia,USA, November 2001. ACM Press.[116] Adrian Perrig, Ran Canetti, J.D. Tygar, and Dawn Song. Efficient authentication and signingof multicast streams over lossy channels. In IEEE Symposium on Security and Privacy, pages56 – 73, Oakland, USA, May 2000. IEEE Press.146


Bibliography[117] Adrian Perrig, Robert Szewczyk, J. D. Tygar, Victor Wen, and David E. Culler. SPINS: Securityprotocols <strong>for</strong> sensor networks. Wireless Networks, 8(5):521 – 534, September 2002.[118] Adrian Perrig and J. D. Tygar. Secure Broadcast <strong>Communication</strong> in Wired and Wireless Networks.Kluwer Academic Publishers, 2003.[119] Josef Pieprzyk, Thomas Hardjono, and Jennifer Seberry. Fundamentals of Computer Security.Springer, 2003.[120] Hossein Pishro-Nik and Faramarz Fekri. On Raptor codes. In 2006 IEEE International Conferenceon <strong>Communication</strong>s, pages 1137 – 1141, Istanbul, Turkey, June 2006. IEEE.[121] Michael O. Rabin. Efficient dispersal of in<strong>for</strong>mation <strong>for</strong> security, load balancing, and faulttolerance. Journal of the Association <strong>for</strong> Computing Machinery, 36(2):335 – 348, April 1989.[122] Malempati Madhusudana Rao. Conditional Measures and Applications (Second Edition). CRCPress, 2005.[123] Christian Rechberger and Vincent Rijmen. On authentication with HMAC and non-randomproperties. In Financial Cryptography 2007, Lecture Notes in Computer Science, to appear,Trinidad and Tobago, February 2007. Springer - Verlag.[124] Irving S. Reed and Gustave Solomon. Polynomial codes over certain finite fields. Journal ofSociety <strong>for</strong> Industrial and Applied Mathematics, 8(2):300 – 304, June 1960.[125] Leonid Reyzin and Natan Reyzin. Better than BiBa: Short one-time signatures with fast signingand verifying. In ACISP’02, volume 2384 of Lecture Notes in Computer Science, pages 144 –153, Melbourne, Australia, July 2002. Springer - Verlag.[126] Ronald L. Rivest. The MD4 Message Digest Algorithm. In Advances in Cryptology -Crypto’90, volume 537 of Lecture Notes in Computer Science, pages 303 – 311, Santa Barbara,USA, 1991. Springer - Verlag.[127] Ronald L. Rivest. The MD5 Message Digest Algorithm. Technical Report RFC 1321, IETFNetwork Working Group, April 1992.[128] Ronald L. Rivest, Adi Shamir, and Len Adelman. A method <strong>for</strong> obtaining digital signaturesand public key cryptosystems. <strong>Communication</strong> of the ACM, 21(2):120 – 126, February 1978.[129] Pankaj Rohatgi. A compact and fast hybrid signature scheme <strong>for</strong> multicast packet authentication.In 6th ACM Conference on Computer and <strong>Communication</strong>s Security, pages 93 – 100,Singapore, November 1999. ACM Press.[130] Steven Roman. Field Theory (Second Edition). Springer, 2006.147


Bibliography[131] Ron M. Roth and Vitaly Skachek. Improved nearly-MDS expander codes. Available online at:http://arxiv.org/PS_cache/cs/pdf/0601/0601090.pdf, January 2005.[132] Rei Safavi-Naini and Huaxiong Wang. New results on multi-receiver authentication code. InAdvances in Cryptology - Eurocrypt’98, volume 1403 of Lecture Notes in Computer Science,pages 527 – 541, Espoo, Finland, June 1998. Springer - Verlag.[133] Rei Safavi-Naini and Huaxiong Wang. Multireceiver authentication codes: Models, bounds,constructions, and extensions. In<strong>for</strong>mation and Computation, 151(1-2):148 – 172, May 1999.[134] Michael Scott, Neil Costigan, and Wesam Abdulwahab. Implementing cryptographic pairingson smartcards. In CHES 2006, volume 4249 of Lecture Notes in Computer Science, pages 134– 147, Yokohama, Japan, October 2006. Springer - Verlag.[135] Adi Shamir. How to share a secret. <strong>Communication</strong> of the ACM, 22(11):612 – 613, November1979.[136] Adi Shamir and Yael Tauman. Improved online/offline signature schemes. In Advances inCryptology - Crypto’01, volume 2139 of Lecture Notes in Computer Science, pages 355 – 367,Santa Barbara, USA, August 2001. Springer - Verlag.[137] Amin Shokrollahi. Raptor codes. IEEE Transactions on In<strong>for</strong>mation Theory, 52(6):2551 –2567, June 2006.[138] Gustavus J. Simmons. A survey of in<strong>for</strong>mation authentication. Proceedings of the IEEE,76(5):603 – 620, May 1988.[139] Nicolas Sklavos and Xinmiao Zhang. Wireless Security and Cryptography: Specifications andImplementations. CRC Press, 2007.[140] Peter J. Smith and Michael J. J. Lennon. LUC: A new public key system. In Ninth IFIPSymposium on Computer Security, pages 97 – 110, Toronto, Canada, May 1993.[141] Douglas R. Stinson. Combinatorial Designs: Construction and Analysis. Springer, 2003.[142] Douglas R. Stinson. Cryptography: Theory and Practice (Third Edition). Chapman &Hall/CRC, 2006.[143] Douglas R. Stinson and Ruizhong Wei. Some new bounds <strong>for</strong> cover-free families. Journal ofCombinatorial Theory, Series A, 90(1):224 – 234, April 2000.[144] Shintaro Ueda, Shin-Ichiro Kaneko, Nobutaka Kawaguchi, Hiroshi Shigeno, and Ken-IchiOkada. A real-time stream authentication scheme <strong>for</strong> video streams. IPSJ Digital Courrier,2:70 – 80, February 2006.148


Bibliography[145] Shintaro Ueda, Nobutaka Kawaguchi, Hiroshi Shigeno, and Ken ichi Okada. Stream authenticationscheme <strong>for</strong> the use over the ip telephony. In 18th International Conference on AdvancedIn<strong>for</strong>mation Networking and Application, volume 2, Fukuoka, Japan, March 2004. IEEE ComputerSociety.[146] Henk C. A. van Tilborg. Encyclopedia of Cryptography and Security. Springer, 2005.[147] Dejan Vukobratovic and Miroslav Despotovic. On the packet lengths of rateless codes. InEUROCON 2005, pages 672 – 675, Belgrade, Serbia & Montenegro, November 2005. IEEE.[148] Xiaoyun Wang, Xuejia Lai, Dengguo Feng, Hui Chen, and Xiuyuan Yu. Cryptanalysis of thehash functions MD4 and RIPEMD. In Advances in Cryptology - Eurocrypt’05, volume 3494of Lecture Notes in Computer Science, pages 1 – 18, Aarhus, Denmark, May 2005. Springer -Verlag.[149] Xiaoyun Wang, Yiqun Lisa Yin, and Hongbo Yu. Finding collisions in the full SHA-1. InAdvances in Cryptology - Crypto’05, volume 3621 of Lecture Notes in Computer Science,pages 17 – 36, Santa Barbara, USA, August 2005. Springer - Verlag.[150] Xiaoyun Wang and Hongbo Yu. How to break MD5 and other hash functions. In Advancesin Cryptology - Eurocrypt’05, volume 3494 of Lecture Notes in Computer Science, pages 19 –35, Aarhus, Denmark, May 2005. Springer - Verlag.[151] Xiaoyun Wang, Hongbo Yu, and Yiqun Lisa Yin. Efficient collision search attacks on SHA-0.In Advances in Cryptology - Crypto’05, volume 3621 of Lecture Notes in Computer Science,pages 1 – 16, Santa Barbara, USA, August 2005. Springer - Verlag.[152] C. K. Wong and Agnes Chan. Immediate data authentication <strong>for</strong> multicast resource constrainednetworks. In 10th Australasian Conference In<strong>for</strong>mation Security and Privacy, volume 3574 ofLecture Notes in Computer Science, pages 113 – 121, Brisbane, Australia, July 2005. Springer- Verlag.[153] Chung Kei Wong and Simon S. Lam. Digital signatures <strong>for</strong> flows and multicasts. IEEE/ACMTransactions on Networking, 7(4):502 – 513, August 1999.[154] Qian Xu, Vladimirm Stanković, and Zixiang Xiong. Distributed joint source-channel codingof video using Raptor codes. In DCC 2005, page 491, Snowbird, USA, March 2005. IEEEComputer Society.[155] Maya Yajnik, Sue Moon, Jim Kurose, and Don Towsley. Measurement and modeling of thetemporal dependence in packet loss. In IEEE INFOCOM 1999, volume 1, pages 345 – 352,New York, USA, March 1999. IEEE Press.149


Bibliography[156] Miyoun Yoon, Kiyoung Kim, and Yongtae Shin. Robust authentication of multimedia streamover multicast network. In HSI, volume 2713 of Lecture Notes in Computer Science, pages632 – 637, Seoul, Korea, August 2003. Springer - Verlag.[157] Hongbo Yu, Gaoli Wang, Guoyan Zhang, and Xiaoyun Wang. The second-preimage attackon MD4. In CANS 2005, volume 3810 of Lecture Notes in Computer Science, pages 1 – 12,Xiamen, China, December 2005. Springer - Verlag.[158] Jean-Pierre Zanotti. Le code correcteur C.I.R.C. Available online at: http://zanotti.univtln.fr/enseignement/divers/chapter3.html.150


List of Tables4.1 Public parameters <strong>for</strong> our LT code-based scheme . . . . . . . . . . . . . . . . . . . 504.2 Complexity comparison <strong>for</strong> different classes of rateless codes . . . . . . . . . . . . . 574.3 Public parameters <strong>for</strong> our MDS code-based scheme . . . . . . . . . . . . . . . . . . 594.4 Upper bounds <strong>for</strong> our LT code-based and MDS code-based schemes and PRABS . . 664.5 Evaluations of the ratio U(n)n. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 684.6 Bit size of the packet overhead <strong>for</strong> our LT code-based and MDS code-based schemesand PRABS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 705.1 Public parameters <strong>for</strong> our multiple block scheme . . . . . . . . . . . . . . . . . . . 785.2 Cost <strong>for</strong> signature dispersion-based schemes . . . . . . . . . . . . . . . . . . . . . . 875.3 Efficiency comparison <strong>for</strong> multicast stream protocols . . . . . . . . . . . . . . . . . 945.4 Overhead comparison <strong>for</strong> multicast stream protocols . . . . . . . . . . . . . . . . . 956.1 Public parameters <strong>for</strong> our hybrid authentication scheme . . . . . . . . . . . . . . . . 1006.2 Number of groups g minimizing ω when n = 1000 . . . . . . . . . . . . . . . . . . 1026.3 Overhead of our construction ω when g is chosen as in Table 6.2 and n = 1000 . . . 1036.4 Ratio ωω MDSwhen n = 1000 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1036.5 Ratio T when n = 1000 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1046.6 Public parameters <strong>for</strong> the hybrid authentication scheme using a THF . . . . . . . . . 1046.7 Comparison of speed between Fast-VSH and the verification process of some digitalsignatures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1076.8 Time needed to exhaust a list of size U(1000) . . . . . . . . . . . . . . . . . . . . . 1086.9 Minimal overhead ω of our hybrid construction <strong>for</strong> n = 1000 when using VSH . . . 1086.10 Ratio ωω MDS<strong>for</strong> n = 1000 when using VSH . . . . . . . . . . . . . . . . . . . . . . . 1096.11 Ratio T <strong>for</strong> n = 1000 when using VSH . . . . . . . . . . . . . . . . . . . . . . . . 109151


List of Figures2.1 A Merkle hash tree having 8 leaves . . . . . . . . . . . . . . . . . . . . . . . . . . . 103.1 TESLA: original scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.2 TESLA: tolerance to packet loss . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.3 TESLA: immediate authentication of data . . . . . . . . . . . . . . . . . . . . . . . 213.4 BiBa: an example of two-collision . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.5 BiBa: generation of SEAL chains . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.6 EMSS: a simple example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.7 The authentication chain C 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.8 The augmented chain C 3,b <strong>for</strong> b ∈ {2,3} . . . . . . . . . . . . . . . . . . . . . . . . 313.9 p-random graph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325.1 Sender processing of data <strong>for</strong> our multiple block scheme . . . . . . . . . . . . . . . 755.2 Receiver processing of data <strong>for</strong> block BID of our multiple block scheme . . . . . . . 765.3 Receiver processing of data <strong>for</strong> block BID of our filtering scheme . . . . . . . . . . 775.4 Evaluation of Λ(n) <strong>for</strong> our different signature schemes and hash functions . . . . . . 896.1 The Merkle hash tree of G 1 when ⌈ n g⌉ = 8. . . . . . . . . . . . . . . . . . . . . . . 99153


List of Algorithms3.1 AuthenticatorPRABS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383.2 DecoderPRABS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393.3 AuthenticatorLTT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403.4 Modified Poly-Reconstruct (MPR) . . . . . . . . . . . . . . . . . . . . . . . . . . . 413.5 DecoderLTT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.1 EncodeMDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484.2 DecodeMDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484.3 AuthenticatorLTscheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514.4 DecoderLTscheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524.5 AuthenticatorMDSscheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594.6 DecoderMDSscheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 605.1 AuthenticatorFamily . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 795.2 VerifySignatureFamily . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 805.3 DecoderBlock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 815.4 AuthenticatorFiltering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 915.5 FilterElements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 925.6 DynamicDecoder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 936.1 AuthenticatorHybrid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1006.2 DecoderHybrid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1016.3 AuthenticatorHybridTHF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1056.4 DecoderHybridTHF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106155


Index of NotationsN Set of natural integers, 5R Set of real numbers, 5R +Set of non-negative real numbers,5R +∗ Set of positive real numbers, 12F r Finite field of cardinality r, 40O Big-Oh complexity notation, 12Ω Omega complexity notation, 12Θ Theta complexity notation, 12|X| Cardinality of the set X, 40log 2 Logarithm of basis 2, 16〈u,v〉 Scalar product of vectors u andv, 35H Bit length of a digest, 7S Bit length of a signature, 6P Bit length of a data packet, 16O Opponent, 6‖ String concatenation operator,10|s| Bit length of the string s, 35{0,1} ∗ Set of all binary strings, 8{0,1} n Set of all binary strings oflength n, 9[N,K,D] Linear code of length n, dimensionK and minimum distanceD, 40⌊x⌋ Floor value of x, 14⌈x⌉ Ceiling value of x, 10ln Neperian logarithm, 18e x Exponential of x, 18157


Index of Acronymsη-codeerasure tolerant authentication code, 17µTESLAMicro-TESLA, 22A 2 CASTAdaptive source <strong>Authentication</strong> protocol<strong>for</strong> multiCAST stream, 30BECBinary Erasure Channel, 57BiBaBins and Balls, 23CECInAComputationally Efficient Countermeasure<strong>for</strong> Injection Attacks, 38CFFCover-Free Family, 17CSAChained Stream <strong>Authentication</strong>, 20DoSDenial of Service, 2DSSDigital Signature Standard, 88EMSSEfficient Multi-chained Stream Signature,29eSAIDAenhanced SAIDA, 37H 2 AHybrid Hash-chaining scheme <strong>for</strong> Adaptivesource authentication, 30HMACHash based MAC, 22HORSHash to Obtain Random Subset, 26i.e.id est, 21IDAIn<strong>for</strong>mation Dispersal Algorithm, 35IPInternet Protocol, xiiiLTLuby Trans<strong>for</strong>m, 44LTTLysyanskaya, Tamassia, Triandopoulos, 40MACMessage <strong>Authentication</strong> Code, 7MDMessage Digest, 88MDSMaximum Distance Separable, 44MPRModified Poly-Reconstruct, 40MRACMultiReceiver <strong>Authentication</strong> Code, 16159


Index of AcronymsPARMPollution Attack Resistant <strong>Multicast</strong> authenticationscheme, 39PHPrediction Hashing, 39PPTProbabilistic Polynomial-Time, 6PRABSPollution Resistant Authenticated BlockStream, 38PRFPseudoRandom Function, 10PRPPolynomial Reconstruction Problem, 13RIPEMDRACE Integrity Primitives Evaluation MessageDigest, 8RLHReceiver driven Layer Hash-chaining, 30RMASRobust <strong>Authentication</strong> of Multimedia Stream,33RSReed-Solomon, 17RSARivest, Shamir, Adelman, 7SPINSSecurity Protocols <strong>for</strong> Sensor Networks,22TESLATimed Efficient Stream Loss-Tolerant <strong>Authentication</strong>,18THFTrapdoor Hash Function, 8UDPUser Datagram Protocol, 2UOWHFUniversal One-Way Hash Function, 9VSHVery Smooth Hash, 97VSSRVery Smooth number nontrivial modularSquare Root, 106w.l.o.g.without loss of generality, 10SAIDASignature Amortization using IDA, 35SAVeStream <strong>Authentication</strong> scheme <strong>for</strong> Videos,37SEALSElf Authenticated vaLue, 23SHASecure Hash Algorithm, 7160


General Indexη-code, 17A 2 CAST, 30Accumulatoraccumulated value, 38one-way, 38witness, 38Attackimpersonation, 16substitution, 16random, 21<strong>Authentication</strong>degrading, 28delay, 20non-degrading, 28BiBa, 23Burst, 29CECInA, 38Chaink-state Markov, 29augmented, 31key, 20seed, 20Channeladditive white Gaussian noise, 58binary erasure, 57binary symmetric, 58erasure, see Lossy channelfeedback, 2lossy, 29secure, 15unsecured, 15Codelinear, 40dimension, 40length, 40minimum distance, 40Luby Trans<strong>for</strong>m, 44Maximum Distance Separable, 44Online, 44Raptor, 44rateless, 44Reed-Solomon, 17systematic, 48Tornado, 57EMSS, 29eSAIDA, 37Field, 13finite, 40Functionensemble, 11efficiently computable, 11pseudorandom, 11negligible, 5one-way, 8order, 12exact, 12161


General IndexGroup, 13abelian, 13H 2 A, 30Hash function, 7collision resistant, 7digest, see hashhash, 7MD, 88PANAMA, 88RIPEMD, 8second preimage resistant, 7SHA, 7trapdoor, 8universal one-way, 9VSH, 97HORS, 26IDA, 35LTT, 40MESS, 30Message authentication code, 17MPR, 40Non-repudiation, 3Packet, 15augmented, 15block, 15signature, 34header, 27overhead, 67signature, 28PARM, 39PH, 39Piggybacking, 32Powerball, 26PRABS, 38Rateaccurate, 45flood, 40survival, 40Requirementget-all-be<strong>for</strong>e, 19Ring, 13RLH, 30RMAS, 33SAIDA, 35SAVe, 37SEAL, 23Signaturedigital, see Signature schemeDSS, 88LUC, 107Nyberg-Rueppel, 107RSA, 7scheme, 6hash and sign paradigm, 9one-time, 24online/offline, 26SPINS, 22Stream, 1TESLA, 18µTESLA, 22multilevel, 22Tree, 34depth, 10leaf, 10Merkle hash, 10node, 10root, 10162


Unicast, 1General Index163

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!