Going Beyond Pollution Attacks: Forcing Byzantine Clients to Code Correctly

Going Bey ond P ollution A ttac ks: F orcing Byzan tine Clien ts to Co de Correctly Raluca Ada P opa ∗ MIT CSAIL Alessandro Chiesa † MIT CSAIL T ural Badirkhanli ‡ MIT CSAIL Muriel M ´ edard § MIT RLE July 29, 2011 Abstract Net work coding ac hieves optimal throughput in multicast net works. Ho wev er, throughput opti- malit y r elies on the netw ork no des or routers to co de c orr e ctly . A Byzantine no de may introduce junk pac kets in the net work (th us p olluting do wnstream pack ets and causing the sinks to receiv e the wrong data) or ma y choose co ding co efficien ts in a wa y that significantly reduces the throughput of the net w ork. Most prior w ork fo cused on the problem of Byzan tine no des p olluting pack ets. How ev er, even if a Byzan tine node does not p ollute pac kets, he can still affect significantly the throughput of the netw ork b y not co ding correctly . No previous work attempted to verify if a certain no de c o de d corr e ctly using r andom co efficients ov er al l of the pac kets he was supp osed to co de o ver. W e pro vide t wo no vel protocols (which w e call PIP and Log-PIP) for detecting whether a no de coded correctly ov er all the pack ets received (i.e., according to a random linear net work co ding algorithm). Our proto cols enable any no de in the net work to examine a pack et received from another no de by running a “verification test”. With our proto cols, the worst an adv ersary can do and still pass the pac ket verification test is in fact equiv alent to random linear netw ork co ding, which has b een shown to be optimal in m ulticast net works. Our protocols resist collusion among no des and are applicable to a v ariety of settings. Our top ology simulations show that the throughput in the w orst case for our proto col is tw o to three times larger than the throughput in v arious adversarial strategies allow ed b y prior work. W e implemen ted our proto cols in C/C++ and Jav a, as well as incorp orated them on the Android platform (Nexus One). Our ev aluation shows that our protocols impose mo dest o verhead. ∗ Email: raluca@csail.mit.edu . † Email: alexch@csail.mit.edu . ‡ Email: turalb@csail.mit.edu . § Email: medard@mit.edu . 1 Con ten ts 1 In tro duction 3 2 Related W ork 5 3 Mo del 6 3.1 Net work Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2 Threat Mo del . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.3 Solution Approach and Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4 Proto col 8 4.1 Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.2 Cryptographic to ols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.3 A Generic Proto col . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.4 Ho w to F orce Byzantine No des to Co de Ov er All Required P ack ets . . . . . . . . . . . . . . 10 4.5 Ho w to F orce Byzantine No des to Co de Pseudorandomly . . . . . . . . . . . . . . . . . . . . 12 4.6 Ho w to Preven t Replay Attac ks of Old Data . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.7 Ho w to Enable No des to Prov e Misb eha vior . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.8 Pro ofs of Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 5 Applications and Extensions 14 5.1 T yp es of Required Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 5.2 Applications and Required Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 5.3 Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 6 Implemen tation and Ev aluation 16 6.1 Sim ulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 6.2 Implemen tation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 6.3 P ack et Size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 7 Conclusions 18 2 1 In tro duction Net work co ding w as first prop osed by Ahlswede et al. [ A CL Y00 ], who demonstrated that, for certain net works, net work co ding can pro duce a higher throughput than the b est routing strategy . A subsequent line of work that includes the works of Ko etter et al. [ KM03 ], Li et al. [ L YC03 ], and Jaggi et al. [ JSC + 05 ] sho wed that random linear co ding reaches maximum throughput for multicast netw orks. Overall, netw ork co ding has pro ved b etter than routing for b oth wired and wireles s netw orks and for both multicast and broadcast [ NS08 ]; it has also found applications to increasing the robustness and throughput of p eer-to- p eer netw orks (e.g., [ GR05 ]) and to a v ariety of sensor wireless netw orks as survey ed by Narmaw ala and Sriv astav a [ NS08 ]. Throughput optimalit y requires diversit y . The throughput guaran tees of netw ork co ding, how ever, r ely on the assumption that al l the no des in the network c o de c orr e ctly , i.e., each node in the netw ork, when receiving pac kets, is assumed to transmit a pac ket that is a random linear combination of the incoming pac kets; informally , pac kets that are indeed linear combinations of the incoming pack ets are said to b e valid , and pack ets that are r andom linear combinations of the incoming pack ets are said to b e diverse . The assumption that each no de in the netw ork co des correctly may not hold b ecause the net work may con tain Byzantine no des , who are malicious or faulty no des. F or example, a Byzantine no de may change the payload or the co ding vector in a wa y that is not a linear com bination of the receiv ed pack ets, thereby transmitting an invalid (or p ol lute d ) pack et. The inv alid pac ket will mix with other pack ets and thus p ollute more pack ets, ultimately causing the deco ded information at the sinks to b e incorrect. In fact, a Byzan tine node can transmit a v alid pac ket (i.e., a linear combination of the received pack ets), but still manage to decrease the o verall throughput at the sinks. The Byzan tine no de could choose co efficien ts for the linear combination in a wa y that is not r andom : the no de could forward one of the pac kets (by simply routing), co de o ver only a subset of the pac kets, or, ev en worse, choose co efficients that do not contribute any new information to his receivers, thus, effe ctively sending nothing . While the net work is not p olluted by such a Byzan tine no de (and the deco ded information at the sinks is still v alid), the throughput of the net work is decreased. In Section 6 , as an example, w e show that such Byzantine no des can indeed reduce the throughput to as much as a half or a thir d in some sp ecific cases and as m uch as 20% on random top ologies. Figure 1 sho ws a simple example of 50% throughput reduction on the standard butterfly top ology . N 1 N 2 N 3 A A A B B B A + B A + B A + B A A B B N 1 N 2 N 3 A A A B B B A A B A A A (a) N 1 N 2 N 3 A A A B B B A + B A + B A + B A A B B N 1 N 2 N 3 A A A B B B A A B A A A (b) Figure 1: Example of throughput reduction caused by a Byzantine no de on a butterfly net work: (a) if no de N 1 is honest, he will send A + B , th us allowing b oth N 2 and N 3 to reco ver b oth A and B ; (b) if no de N 1 is Byzantine, he may choose to send only A , thus halving the throughput at N 2 , which can now recov er only A . Insufficiency of prior w ork to guaran tee correctness. A significant b o dy of previous w ork that includes [ KFM04 ], [ CJL06 ], [ GR06 ], [ GR06 ], [ ZKMH07 ], [ YWRG08 ], [ HLK + 08 ], [ JLK + 08 ], [ BFKW09 ], [ KTT09 ], [ AB09 ], [ DCNR09 ], [ ABBF10 ], [ LM10 ], [ YSJL10 ], and [ WVNK10 ] addressed the problem of defending against p ollution attacks, where the goal is to enforce or chec k that the pack ets sent by each no de to be some (not necessarily random) linear combination of the pac kets sen t by the source. Most prior w ork on enforcing v alidity of pack ets has fo cused on detecting p olluted pac kets right at the p oin t where a Byzantine no de injected them into the net work [ BFKW09 ], [ ZKMH07 ], [ KFM04 ], [ YWR G08 ], [ CJL06 ], and [ ABBF10 ]: when a Byzantine no de injects an inv alid pack et into the netw ork, the no de receiving the pac ket is able to detect if the pack et is inv alid by running a test, and can discard the in v alid pack et right a wa y . 3 Ho wev er, all such work do es not detect Byzantine no des that deviate from r andom linear co ding of the receiv ed pack ets, th us allowing suc h Byzantine nodes to reduce throughput as already discussed ab o ve. In particular, Byzantine no des are still allo wed to simply forward a receiv ed pack et (rather than to co de o ver multiple pac kets) or use co efficien ts that provide no new degrees of freedom to downstream no des, effectiv ely sending no data. Our result. Giv en that Byzantine no des may significantly affect the throughput of the netw ork, we b eliev e that it is imp ortan t to study the follo wing problem: Ho w to force a no de to co de c orr e ctly ? (That is, to co de both valid ly and r andomly , ov er al l the receiv ed pack ets.) Our main con tribution is a nov el proto col for enabling eac h child of a no de to detect whether the no de co ded correctly o v er all the pack ets he was supposed to co de ov er (i.e., according to a random linear net work co ding algorithm). In our proto col, a child node C of a no de N (where child means that C receiv es data from his p ar ent N ) can c heck, by running a verific ation test , that the data from N is the result of correctly co ding o ver the pack ets N receives from his paren ts. The no de C need only examine the pack et receiv ed from N and do es not need to know the precise pack et payloads used in coding at N . Let the r e quir e d set of N , denoted R N , b e the subset of the parents of N that N is exp ected to code o ver. As we will discuss in Section 5 , the exact definition of the required set dep ends on the application; the flexibility in defining it will enable our proto cols to b e applicable to a v ariet y of settings. F or example, some applications may require a no de to co de o ver the pac kets from all his parents; other applications, p erhaps due to unreliability of the communication c hannel, ma y require no des to co de ov er at least some minim um num b er of paren ts. Using our proto cols presen ted in Section 4 , the c hild no de C can ensure that: (i) the pack et from N is the result of co ding ov er the pac kets from all the no des in R N , and (ii) the co ding coefficients used b y N are pseudorandom. W e provide tw o algorithms, with tw o different kinds of guarantees: Pa yload-Indep enden t-Proto col (PIP) and Log-V erification PIP (Log-PIP). PIP alwa ys detects if N failed to co de ov er all the pac kets from paren ts in the required set, whereas Log-PIP detects suc h a violation with an adjustable probabilit y . In cases where no des can hav e many parents (say , more than 10), Log-PIP is faster and more bandwidth efficien t. While w e use pseudor andom co efficien ts instead of random ones, this do es not affect the throughput guaran tees of netw ork co ding (see Section 4.5 ); accordingly , we will use the t wo terms in terchangeably in this pap er. F urthermore, our proto cols are r esistant to c ol lusion among no des : ev en if the t wo Byzan tine no des N and C collude, the other honest c hildren of N can still chec k whether N co ded correctly o ver an y non- colluding paren ts. Finally , we assume that there exist p enalties for no des that are found to send incorrect pack ets, and we assume that they drive incentiv es against cheating in a detectable manner. A discussion of the exact form of such penalties of course lies outside of the scop e of this pap er, and one should choose the p enalty that is b est fit for one’s application. T o facilitate the use of a penalty system, though, our proto col enables no des to pr ove (and not only detect) that a paren t cheated (i.e., did not co de correctly); moreov er, Byzan tine no des cannot falsely accuse honest no des of not co ding correctly . Th us, we assume that Byzan tine no des will not cheat in a detectable wa y . W e therefore consider an adv ersarial mo del in whic h Byzantine no des p erform the worst p ossible action to p ass the verific ation test . In Section 4.8 , we pro ve that the worst an adversary can do and still pass our pack et verification tests is to c o de c orr e ctly (i.e., according to a random linear net work co ding scheme), which has b een shown to give optimal throughput in multicast netw orks. Implemen tation and ev aluation. Our simulations in Section 6 show that the throughput in the b est adv ersarial strategy for our proto col is tw o to three times larger than the throughput in several adv ersarial strategies allow ed by prior w ork. W e implemented our proto cols in C/C++. W e also wrote a Ja v a implementation for Ja v a-based P2P applications and an Android pack age for smartphone P2P file sharing. Our C/C++ ev aluations show that the proto cols are reasonably efficient: the running time at a no de to prepare for transmitting the data is less than 0 . 3 ms, and the time to p erform a verification test is 3 . 7 ms with PIP and 1 . 4 ms with Log-PIP. Compared to the ov erhead introduced b y a p ollution detection scheme that we analyzed [ BFKW09 ], the additional ov erheads in tro duced by our t wo proto cols are resp ectiv ely less than 2% for PIP and less than 0 . 5% for Log-PIP. This suggests that, if one is already using a p ollution detection sc heme, then additionally 4 enforcing div ersity of pac kets will not affect p erformance b y muc h. Moreov er, the o verhead of b oth of our proto cols is indep endent of how large the pac ket pa yload is. 2 Related W ork Ahlsw ede et al. [ A CL Y00 ] hav e pioneered the field of netw ork co ding. They sho wed the v alue of co ding at routers and provided theoretical b ounds on the capacity of suc h netw orks. W orks such as those of Ko etter et al. [ KM03 ], Li et al. [ L YC03 ], and Jaggi et al. [ JSC + 05 ] show that, for m ulticast traffic, linear co des achiev e maximum throughput, while co ding and decoding can be done in p olynomial time. Ho et al. [ HKM + 03 ] show that random netw ork coding can also achiev e maximum netw ork capacity . Netw ork co ding has b een shown to improv e throughput in a v ariety of netw orks: wireless [ LMK05 ], p eer-to-p eer con tent distribution [ GR05 ], energy [ WNE00 ], distributed storage [ Jia06 ], and others. Despite its throughput b enefits, ho wev er, netw ork co ding is susceptible to Byzan tine attac ks. A Byzan- tine no de can inject into the netw ork junk pack ets, which will mix with correct pac kets and generate more junk pac kets, th us resulting in junk data at the sink. A significant amount of research aims to preven t against or reco ver from pollution attacks [ KFM04 ], [ CJL06 ], [ GR06 ], [ GR06 ], [ ZKMH07 ], [ YWRG08 ], [ HLK + 08 ], [ JLK + 08 ], [ BFKW09 ], [ KTT09 ], [ AB09 ], [ DCNR09 ], [ ABBF10 ], [ LM10 ], [ YSJL10 ], and [ WVNK10 ]. Ho et al. [ HLK + 08 ] attempt to detect at the sinks if the pack ets hav e been mo dified by a Byzan tine no de. They do so by adding hash symbols that are obtained as a p olynomial function of the data sym b ols, and pollution is indicated b y an inconsistency b et w een the pack ets and the hashes. Jaggi et al. [ JLK + 08 ], for example, discuss rate-optimal proto cols that survive Byzantine attacks. Their idea is to app end extra parit y information to the source messages. Kosut et al. [ KTT09 ] provide non-linear proto cols for ac hieving capacity in the presence of Byzantine adversaries. There has also b een imp ortan t work in the problem of detecting p olluted pack ets when they are in- jected, see for example [ KFM04 ], [ CJL06 ], [ GR06 ], [ GR06 ], [ ZKMH07 ], [ YWR G08 ], [ BFKW09 ], [ DCNR09 ], [ ABBF10 ], and [ WVNK10 ]. These sc hemes are helpful b ecause they preven t p olluted pack ets from mixing with other pac kets. The most common approach has been the use of a homomorphic cryptographic sc heme (suc h as signature) [ BFKW09 ], [ ZKMH07 ], [ KFM04 ], [ YWRG08 ], [ CJL06 ], [ AB09 ], and [ ABBF10 ]. In a p eer-to-peer setting, Krohn et al. [ KFM04 ] prop ose a scheme based on homomorphic hashes to detect on the fly whether a received pack et is v alid. The homomorphic hashes are used to verify if the c heck blo c ks of downloaded files are indeed a linear combinations of the original file blo cks. Gk antsidis and Ro driguez [ GR06 ] further extend the approach of Krohn et al. to resist p ollution attacks in p eer-to-peer file distribution systems that use netw ork co ding. They also mention the en tropy attac k, which is similar to our diversit y attack. How ever, they do not solv e the problem of enforcing a Byzantine client to code div ersely . Their approac h is to hav e a no de download co ding co efficien ts from neighbors and decide from whic h neighbors to do wnload the data to get the most innov ative pack ets. How ev er, a Byzantine client can still not co de diversely , and for example, can choose not to co de o ver the data from a parent that he kno ws would pro vide innov ative information to his neighbors, thus reducing o verall throughput. W an et. al [ WVNK10 ] prop ose limiting p ollution attacks by iden tifying the malicious nodes, so that they can b e isolated, and Le and Markopoulou [ LM10 ] by iden tifying the precise lo cation of Byzantine attac kers using a homomorphic MA C scheme. Zhao et al. [ ZKMH07 ] provides a signatures sc heme for conten t distribution with netw ork co ding based on linear algebra and cryptograph y . The source provides all no des with an inv ariant v ector and public k ey information. With that information, all no des can c heck on the fly the v alidity of a pack et. [ YWRG08 ] pro vides homormorphic signatures sc hemes for prev enting suc h Byzan tine attac ks, but the pap er is v acuous due to a flaw. [ CJL06 ] and [ BFKW09 ] also provide homomorphic signatures schemes, with a construction based on elliptic curves. This scheme augments the pac ket size b y only one constan t of ab out 1024 bits. Another recent approach to detecting p olluted pac kets is the algebraic watc hdog [ KMB10 , LA V10 ] in whic h no des sniff on pack ets from other no des and try to establish if they are p olluted. Ho wev er, while all these schemes only chec k if a pack et is v alid, they c annot establish if a p acket is diverse . If Byzan tine no des are preven ted from sending junk pack ets, b ecause there are pack et v alidity c hecks, it is still the case that there are other wa ys in which a Byzantine no de can affect the throughput without violating any v alidity c hecks. F or example, a Byzantine no de can simply not send an y data, he can forw ard one of the received pack ets (without co ding), he can code with fixed co efficients, or he can c ho ose co efficients that minimize the netw ork throughput. In Section 6 , w e sho w that Byzantine b eha vior 5 of this kind do es indeed significantly decrease throughput. All these b ehaviors are not considered (and not prev ented) b y all previous work on pollution attac ks. 3 Mo del W e presen t the net work mo del and then form ulate the securit y problem that w e w ant to solve. In Section 5 , w e explain how our mo del and proto cols apply to a v ariety of problem domains. 3.1 Net w ork Mo del W e consider a netw ork where no des p erform random linear netw ork co ding [ HKM + 03 ] ov er some finite field. Roughly , each pack et is a pair consisting of a p aylo ad M and a c o ding ve ctor C ; no des “co de” b y c ho osing random co efficien ts and using them to compute linear com binations of the received pack ets. F or example: no de N receives t wo pac kets h M 1 , C 1 i and h M 2 , C 2 i ; to random linear net work co de these pac kets, N chooses tw o random co efficien ts α 1 and α 2 from a certain finite field and computes the resulting co ded pac ket as h α 1 M 1 + α 2 M 2 , α 1 C 1 + α 2 C 2 i , where the computations are also p erformed in the finite field. In Section 4.1 , we provide more details ab out the structure of a pack et. The netw ork is mo deled as a directed graph in the natural w ay: each no de in the netw ork corresponds to a vertex in the graph, and if a node N sends data to another no de N 0 then there is a directed edge in the graph from the vertex (corresp onding to the no de) N to the v ertex (corresponding to the no de) N 0 ; we then say that N is a p ar ent of N 0 and that N 0 is a child of N ; similarly , if there is a directed edge from N 0 to N 00 , w e say that N is a gr andp ar ent of N 00 and N 00 is a gr andchild of N . Each no de sends one pack et p er time p eriod to each of his children. W e alw ays denote a generic no de in the netw ork by N ; he has paren ts denoted by P i and children denoted by C j . W e denote by P N the set of parents of N . As discussed, the r e quir e d set of N , denoted b y R N , is the subset of P N indicating whic h parents the no de N should co de ov er. Ideally , the required set would b e equal to the parent set, but this may not b e p ossible in all settings or applications. (See Section 5 where we discuss v arious c hoices of the required set.) See Figure 2 for a diagram of a netw ork using our notation. . . . . . . . . . . . . . . . . . . S P 1 P 2 P 3 P 4 C 1 C 2 D 2 D 1 N C 3 P N R N Figure 2: A source no de S sends data to tw o destination no des D 1 and D 2 . A generic no de N somewhere in the graph has paren t no des P 1 , P 2 , P 3 , and P 4 (of whic h P 1 and P 2 form his required set R N ) and has children no des C 1 , C 2 , and C 3 . Eac h no de N has a public key pk N and a corresp onding secret key sk N . W e assume that each no de kno ws the public key pk S of the source S ; this is a reasonable assumption present in most previous w ork on p ollution attacks [ BFKW09 ], [ ZKMH07 ], [ KFM04 ], [ YWRG08 ], [ CJL06 ], and [ ABBF10 ]; for example, a no de may b e given this public k ey up on entering the system. In some settings ( Section 5 ), w e will need eac h no de N to hav e a certificate cert N that his public k ey is v alid and b elongs to it; cert N consists of a signature from the source or some other trusted part y: sig ( pk N , “this is the public key of N ”). A no de need only obtain such a signature once p er lifetime of the no de and it can b e p erformed, for example, when the no de joins the netw ork. In order for a child C j to chec k that his parent co ded correctly using the proto cols that we present in Section 4 , C j needs to know what is the required set R N of N and what are the public keys of the no des in this set. No des do not need to know the required set (or the set of grandparents) for their paren ts a priori; in fact, dynamically adjusting the required set is imp ortant for dynamic netw orks. In Section 5.2 , 6 w e explain how no des can acquire the required set for each of their parents dep ending on the application. W e also explain for which applications our proto cols are most fit and for whic h they are not fit. F or now, assume that each no des kno ws precisely the no des in the required set of each parent. 3.2 Threat Mo del No des in the netw ork ma y b e Byzantine (i.e., malicious or fault y): a no de can p ollute the data coming from the source by sending out a pack et that is inv alid or decrease the throughput by sending a pack et that is not a result of co ding o ver pac kets receiv ed from each paren t in the required set. In Section 6 , w e discuss several Byzantine b ehaviors and how they affect the throughput of the netw ork. Ev en worse, Byzantine no des can collude among each other. A no de can collude with his parents, c hildren or any other no de in the net work to pass the v erification tests at his honest children. W e consider the adv ersarial mo del in which Byzantine no des will use the b est adv ersarial strategy to decrease the throughput at the sinks while stil l p assing our verific ation tests . As already discussed, w e assume that there exist p enalties in place that create enough incen tives for not che ating dete ctably ; a discussion of what these p enalties should be (e.g., a fine, an inv estigation, remov al from the system, resource c hoking, reputation decrease, or making top ology adjustments) is out of the scop e of this pap er and one should choose what b est fits one’s application. 3.3 Solution Approac h and Goals Similarly to prior w ork on pollution signatures, we also take a “v erification test” solution approach. Our tec hnical goal is to design a proto col that pro v ably implements such a test for correctness: V erification test b y no de C j when receiving pac ket P from no de N . A pr o c e dur e run by child C j up on r e c eiving a p acket P fr om p ar ent N to verify that no de N gener ate d P by c o ding c orr e ctly (i.e., using pseudor andom c o efficients over a p acket fr om e ach p ar ent in the r e quir e d set R N of N ). If a Byzantine no de N passes the verification test p erformed by an honest child C j , the Byzan tine no de m ust hav e co ded correctly ov er the required data. Therefore, such a verification test w ould achiev e the goal of this pap er, b ecause each honest no de in the netw ork has the ability to enforce correct random linear netw ork co ding at each of his paren ts. Sp ecifically , the verification test should satisfy the follo wing prop erties: 1. A Byzan tine no de that do es not follo w the random linear co ding algorithm should b e detected with o verwhelming probabilit y . 2. The test must b e efficient with resp ect to computation and bandwidth. 3. The v erification test must b e collusion resistan t: an honest c hild should b e able to chec k if his paren t co ded o ver all the honest no des in his required set, regardless of whether other children or grandparen ts are Byzantine or not. 4. If the v erification test fails, it is p ossible to prov e it. In particular, this implies that a no de can, not only detect, but also prov e, when a parent cheats. W e require that the computational ov erhead that each no de incurs by running the verification test is reasonable and, moreov er, we also require that the increase in pack et size (due to the extra information sen t to later nodes in order to enable them to run the v erification test) do es not dep end on the p aylo ad of the pac ket. (Recall that netw ork co ding is particularly useful when the pac ket payload is large and the o verhead of the co efficien ts b ecomes negligible.) The proto cols we prop ose (and which are presen ted in Section 4 ) ac hieve the ab o v e four prop erties. W e remark that tackling collusion is challenging. F or example, a no de N could collude with a child C j : N could send a pack et to C j that is not the result of co ding ov er all the no des in the required set with pseudorandom co efficien ts, and C j w ould simply neglect running the v erification test on N . Still, w e wan t to ensure that the other, honest children of N can verify that they do receive correctly-co ded pac kets. This means that each c hild no de C j m ust b e able to indep enden tly c heck N and not rely on an y shared information that is required to sta y secret. Similarly , ideally , if some paren ts collude with N , N ’s c hildren should still b e able to chec k that N co ded o ver all the required paren ts that did not collude with 7 N . This means that the paren ts cannot ha ve some secret shared data in the proto col, all of this making the cryptographic proto col more c hallenging. Finally , while the net work mo del that we adopt is simple, w e show in Section 5 that it is expr essive : there w e explain how to use this mo del for a v ariety of netw ork settings and applications, either directly or with simple extensions. 4 Proto col W e describ e the proto cols a no de needs to run to p erform the verification test on each of his parents and to assemble pac kets to send to his children. F or clarity , we presen t the proto cols in an incremental fashion, b y successiv ely adding more security prop erties. But first we will need to introduce some basic notation and cryptographic to ols that w e use. 4.1 Notation A sequence (or tuple) of n comp onents x 1 , . . . , x n is denoted b y ( x 1 , . . . , x n ) or ( x i ) n i =1 ; for simplicit y , some- times we omit the starting and ending indices of the sequence, thus only writing ( x i ) i . The concatenation of tw o strings a and b is denoted by a || b . W e denote b y |R N | the num b er of (parent) no des in the required set R N of no de N ; by pk N and sk N the public and secret k eys of no de N ; and by sig N ( x ) a signature of a message x with respect to the k ey pair ( pk N , sk N ) of N , where the underlying signature sc heme is assumed to satisfy the usual notion of unforgeabilit y (i.e., existen tial unforgeability under chosen-message attac k). F or concreteness, we use the DSA algorithm [ NIS ], whose signatures are only 320 bits long. Let q b e the prime num b er used in an y of the p ollution signature schemes in [ BFKW09 ], [ ZKMH07 ], [ KFM04 ], [ YWR G08 ], [ CJL06 ], and [ ABBF10 ]. F or example, in [ BFKW09 ], q is a 160-bit prime. In netw ork co ding, as already mentioned, a pac ket has the form E = h M , C i , where M is the p aylo ad and C the c o ding ve ctor . (In our proto cols, w e will augment the pack et with additional tokens.) The payload M is an n -tuple ( m 1 , . . . , m n ) of chunks , where eac h c hunk m i is an elemen t of Z ∗ q , the m ultiplicative group of integers mo dulo the prime q . A co ding vector C is an m -tuple ( c 1 , . . . , c m ) of ch unks, where each ch unk is also an element of Z ∗ q . Hence, E consists of n + m c hunks e 1 , . . . , e n + m , where e i = m i for 1 ≤ i ≤ n and e i = c i − n for n < i ≤ n + m . In particular, w e can think of M , C , and E as vectors in some pro duct space of Z ∗ q . 4.2 Cryptographic to ols W e now briefly review the cryptographic to ols that w e employ in our proto cols: Pseudorandom functions. Informally , a pseudor andom function family is a family of polynomial- time computable functions { F s : { 0 , 1 } | s | → { 0 , 1 } | s | } s ∈{ 0 , 1 } ∗ with the prop ert y that, for a sufficiently large securit y parameter k and a random k -bit seed s , F s “lo oks like” a random function to an y efficient pro cedure. See [ GGM86 ] for more details. Merkle hashes. A Merkle hash [ Mer89 ] is a concise commitmen t to n elements. Supp ose that Alice has n elements and she gives Bob a Merkle hash of them. Later, when Bob asks to see some elements from Alice, the Merkle hash allows Bob to chec k that indeed the elements Alice giv es him are the same elements o ver which she had computed the Merkle hash. Lo osely , to compute the Merkle hash of n elemen ts, Alice places the elements at the lea ves of a full binary tree; she recursively computes eac h no de higher in the tree as the hash of the concatenation of the t wo children. The resulting hash at the ro ot is called the Merkle hash/c ommitment of the n elements. Given n elemen ts and their Merkle hash, Alice can reveal an elemen t, say elemen t i , to Bob b y revealing the lab el of every no de (and his sibling) along the path from the leaf no de containing element i to the ro ot; Bob verifies the correctness of element i by re-hashing the elemen ts b ottom-up and then v erifying that the resulting hash is equal to the claimed Merkle hash. The adv antage of the Merkle hash is that Bob only needs to ask O (log n ) elements from Alice to chec k that a elemen t out of n has b een c orrectly included in the Merkle hash. See [ Mer89 ] for more details. P ollution signatures. A p ol lution signatur e scheme (suc h as [ BFKW09 ], [ ZKMH07 ], [ KFM04 ], [ YWR G08 ], [ CJL06 ], and [ ABBF10 ]) is a signature sc heme consisting of the usual triplet of algorithms ( gen , sig , ver ) with a sp ecial homomorphic property that allows it to b e used to detect pollution attacks in netw ork co ding. 8 Sp ecifically , the source S runs the key generation algorithm gen to pro duce a secret key sk S , together with a corresp onding public key pk S that is published for every one to use. The source S augments each outgoing pac ket E with a sp ecial signature σ S ( E ), generated b y running the algorithm sig on input the secret key sk S and the pack et E ; we refer to this sp ecial signature as a validity signatur e of the pack et E with resp ect to the public key pk S . When a node receives a (signed) pack et h E , σ S ( E ) i , he verifies the signature on the pack et, by running the algorithm ver on input the public key pk S , the pack et E , and the signature σ S ( E ). P ollution signature schemes hav e the useful homomorphic prop ert y that, when given several pac kets together with their v alidity signatures, an y no de is able to compute a v alidity signature of any linear com bination of those pack ets, without communicating with the source S . F or example, if a no de N re- ceiv es t wo (signed) pack ets h E 1 , σ S ( E 1 ) i and h E 2 , σ S ( E 2 ) i , then, for an y t wo co efficien ts α and β , N can compute a v alidity signature of the pac ket E = αE 1 + β E 2 ; in some schemes, this is done by computing σ S ( αE 1 + β E 2 ) = σ S ( E 1 ) α · σ S ( E 2 ) β , where each of these computations are p erformed in a certain field and the equality holds due to homorphism. See [ BFKW09 ], [ ZKMH07 ], [ KFM04 ], [ YWRG08 ], [ CJL06 ], and [ ABBF10 ] for more details. 4.3 A Generic Proto col In order to av oid rep etition in the presentation of our proto cols, in this section we introduce the general structure that will be follo wed by eac h protocol v ersion that we present; later, in any given proto col v ersion, w e will replace an y unsp ecified quantities or pro cedures with concrete v alues or algorithms. First w e discuss the new pack et structure: ev ery pac k et E transmitted by a generic no de N is augmen ted with three cryptographic tokens; the first token has already b een used in prior w ork, while the last t wo tok ens are new to our proto cols: 1. A validity signatur e σ S ( E ), which is used to prev ent pollution attacks. Any (secure) pollution signature scheme [ BFKW09 ], [ ZKMH07 ], [ KFM04 ], [ YWR G08 ], [ CJL06 ], and [ ABBF10 ] ma y b e used to pro duce this signature (as w e rely only on the guaran tees it pro vides and not on details of its implementation). 2. A test token T N , which is used by each child C j of N to run the verification test on N , denoted VerifTest . 3. A help er token H N , which is used b y each child C j of N to pro duce his own test tok en T C j , using a pro cedure called Combine . Sp ecifically , the proto col that a generic no de N runs, after receiving pac kets from his paren ts, in order to pro duce a pack et for each of his children, tak es the general form of Algorithm 1 , where the pro cedures VerifTest , CheckHelper , and Combine , as well as the v alue of H N , will b e specified later: Algorithm 1 Proto col at a generic no de N 1: F rom each paren t no de P i ∈ P N , no de N receiv es a pack et h E P i , σ S ( E P i ) , T P i , H P i i . 2: F or each parent no de P i ∈ P N , no de N verifies that σ S ( E P i ) is a v alid signature of E P i using the public k ey pk S of the source S , verifies that VerifTest ( E P i , σ S ( E P i ) , T P i ) accepts, and that H P i is correct using CheckHelper ( E P i , σ S ( E P i ) , H P i ) . 3: No de N computes E N b y co ding ov er all E P i and σ S ( E N ), as describ ed at the end of Section 4.2 . 4: No de N computes T N = Combine  ( E P i , σ S ( E P i ) , H P i ) P i ∈P N  and H N . 5: No de N assem bles the pack et h E N , σ S ( E N ) , T N , H N i , and sends it to each child C j . In Step 2 , for each parent P i from whic h N receives a pack et: N chec ks the v alidity signature of the pac ket to establish whether P i sen t polluted data or not; then, N chec ks the test token T P i b y running the v erification test to establish that P i co ded correctly; next, N needs to make sure P i sen t a correct help er tok en (without which N could not compute a go od test token T N himself and would fail the verification test at his children). If any of the c hecks ab o ve fail, N will rep ort them and act in some wa y that is application-sp ecific. As w e will see in Section 4.7 , N can accompany his complaint with a pro of that his paren t cheated. In our protocol, eac h no de verifies his parents (if he is not the source) and is b eing verified b y his c hildren (if he is not a sink/destination). Th us, N verifiers P i , and C j v erifies N . 9 4.4 Ho w to F orce Byzantine No des to Co de Ov er All Required P ack ets As a first step, we design a verification test that enables any child C j of a no de N to chec k that N did indeed co de ov er all of the paren t no des in his required set R N , i.e., that the pack et sent b y N to C j is a linear combination of pack ets from parents in the required set with co efficien ts all of whic h are not equal to zero. A na ¨ ıv e solution. The no de N can simply forward to each of his c hildren all the pack ets receiv ed from paren ts in the required set. Of course, N ’s parents make sure to sign (using their own secret keys) the pac kets they send to N , so that C j can be sure that the pac kets forw arded b y N are indeed from N ’s parents. In other w ords, N forwards to each child C j the following data: E P i , σ S ( E P i ), and sig P i ( E P i || σ S ( E P i )), the co ding co efficien ts used for the pack ets from each parent, and the newly co ded pa yload E N with the new in tegrity signature σ S ( E N ). Each child C j can then establish whether N co ded correctly , because he now has access to all the information N receiv ed from his paren ts and can th us chec k that N did not use any zero co efficien ts. Clearly , this solution is bandwidth inefficient: the payload of the pack et can b e very large and N will send |R N | + 1 such payloads to his c hildren, reducing throughput |R N | + 1 times. P ayload-Independent Proto col (PIP). W e now impro ve on the na ¨ ıv e solution, by av oiding to in- clude the pack et payload in the test token sent for v erification, thus saving considerable bandwidth and throughput. Eac h parent P i sends a help er tok en consisting of a parent signature on the v alidity signature: H P i := sig P i  σ S ( E P i ) || “from P i to N ”  . The text in H P i prev ents a colluding N from giving this help er tok en to some other no de N 0 , which could otherwise falsely claim that he received the data from P i . The test token T N of no de N is computed by a simple concatenation; sp ecifically , Combine computes the followin g test tok en: T N =   α i , σ S ( E P i ) , H P i   P i ∈P N , where α i is the co ding coefficient that N used for the pack et from P i . The verification test for this version of the proto col is giv en in Algorithm 2 . Algorithm 2 VerifTest of no de N , by child C j 1: for each paren t P i ∈ P N do 2: C j c hecks that T N con tains an entry  c i , σ S ( E P i ) , H P i  for the current parent P i . 3: C j c hecks that H P i v erifies with pk P i as a signature of σ S ( E P i ). 4: C j c hecks that α i 6 = 0. 5: end for 6: C j v erifies that com bining all v alidity signatures σ S ( E P i ) and coefficients α i results in σ S ( E N ), according to the homomorphic prop ert y discussed in Section 4.2 . Step 2 verifies that N provided test data for parent P i . Step 3 chec ks that the data is authentic. Step 4 establishes that the co efficien t used in co ding ov er this parent is nonzero. Step 6 chec ks that the co ded data from N indeed corresp onds to co ded data ov er the information from the parents with the claimed co efficien ts α i . W e now giv e some in tuition for why Algorithm 2 is a go o d verification test, lea ving a formal pro of to Section 4.8 . If N do es not co de ov er the pac ket of some parent, say from parent P 1 , in order for N to pro duce a v alidit y signature σ S ( E N ) for E N that verifies successfully under the public key pk S , N needs to combine only those v alidity signatures from parents he coded o v er and not include σ S ( E P 1 ) in the computation; at Step 6 , how ev er, C j uses the v alidity signature from all required paren ts to c heck σ S ( E N ) (with a co efficien t α i that w as chec ked to b e nonzero in Step 4 ) and the c heck w ould fail. CheckHelper at C j consists of chec king that H N is indeed a signature on E N and is not a signature on zero. The length of the test token T N is now | T N | = |R N | ·  | σ S | + | sig |  , 10 A P 1 = σ S ( E P 1 ) || H P 1 || α P 1 A P 2 = σ S ( E P 2 ) || H P 2 || α P 2 . . . B 1 = ! h ( A P 1 ) , σ S ( α P 1 E P 1 ) " B 2 = ! h ( A P 2 ) , σ S ( α P 2 E P 2 ) " B 1 , 2 = ! h ( B 1 || B 2 ) , σ S ( α P 1 E P 1 + α P 2 E P 2 ) " B 1 , 2 , 3 , 4 = ! h ( B 1 , 2 || B 3 , 4 ) , σ S ( α P 1 E P 1 + α P 2 E P 2 + α P 3 E P 3 + α P 4 E P 4 ) " . . . . . . . . . B 1 ,..., |R N | = ! T N , σ S ( E N ) " Figure 3: Diagram representing the computation of the help er token T N : for each parent P i , define A P i = σ S ( E P i ) || H P i || α P i ; then recursiv ely apply the hash function h as indicated, and recursiv ely compute p ollution signatures with the indicated co efficien ts. where | σ S | denotes the size of the p ollution signature and | sig | the size of the signature scheme introduced in Section 4.1 . Indeed, the length of T N do es not dep end on the pa yload any more. Also, recall that the lengths of the signatures are constant. Note, though, that | T N | is linear in the num b er of parents; this may not b e a problem, but in applications where the pa yload is not that large or where there can b e many paren ts, it would b e desirable to hav e a smaller token. Moreov er, v erifying |R N | digital signatures in the v erification test ( Step 3 ab o ve) will b ecome exp ensiv e if the num b er of paren ts is not small. Logarithmic P ayload-Independent Proto col (Log-PIP). W e provide a second proto col in which the length of the help er tok en T N is significantly shorter: | T N | = | h | + | σ S | + | sig | + 2 · | σ S | · log( |R N | ) , where | h | is the size of a hash (e.g. 160 bits for SHA-1), thus replacing |R N | with the muc h smaller v alue log( |R N | ) (where the logarithm is base 2). The second protocol that w e presen t, how ever, is probabilistic in its guarantees: rather than enabling a c hild C j to test if a paren t N c heated (with ov erwhelming confidence), w e enable C j to detect misb eha vior of N with a certain (adjustable) probabilit y . Sp ecifically , after receiving the pac ket from N , no de C j pic ks a required parent of N at random and c hallenges N to prov e that he co ded correctly ov er that paren t. Of course, N do es not know ahead of time on what pack ets he will b e challenged. As shown in Section 6 , such probabilistic approach is still quite effective b ecause the chance that a Byzantine no de N is detected cheating gro ws exp onen tially in the n umber of times he attempts to cheat. In Section 6 , we provide recommendations for when we b eliev e it is more appropriate to use PIP or Log-PIP . The basic idea of Log-PIP is that N will send to C j a test tok en T N that is the ro ot of a Merkle hash tree constructed ov er the data of the test token used in PIP; namely , a Merkle hash tree where the elements at the leav es are the tuples  α i , σ S ( E P i ) , sig P i  σ S ( E P i ) || “from P i to N ”  ranging ov er the paren ts P i . Eac h C j will then challenge N by asking to see a certain path in the Merkle hash tree corresp onding to a parent of N . In this wa y , C j can chec k if N co ded ov er that parent (i.e., N used a non-zero co efficien t). Of course, N cannot provide arbitrary data to C j when replying the challenge of C j , as guaran teed by the securit y prop erties of a Merkle hash. Therefore, if N did not co de ov er a parent, C j will discov er this with a known probabilit y . Let h b e a hashing scheme. Figure 3 illustrates the Merkle tree that N has to compute and pro vides notation for our discussion. W e sligh tly mo dify the traditional Merkle hash, by adding data at internal no des and changing the recursion. Each leaf no de A P i in the Merkle tree consists of a “summary” of the data from a required paren t P i of N . Each internal no de consists of the v alidity signature obtained b y co ding o ver all the pack ets at the leav es of the subtree ro oted by the internal node and a hash of the tw o children. The ro ot no de will th us contain the test token T N as the ro ot hash and the v alidity signature ov er E N , namely σ S ( E N ). Thus, Combine consists of computing the Merkle hash to obtain the Merkle hash ro ot, so that T N = “Merkle hash ro ot”. H P i is the same as in PIP , that is, H P i = sig P i  σ S ( E P i ) || “from P i to N ”  . The v erification test VerifTest is ran in a different w ay than in PIP . Each no de C j receiv es the pac ket from N , chec ks the v alidity signature, and he can pro ceed to code and forward the pac ket. It 11 can then challenge no de N to chec k if N indeed co ded ov er all the pack ets. During a c hallenge, only log |R N | source signatures and hashes will b e retrieved, due to the Merkle tree prop erty . Moreov er, only one digital signature will b e verified, the one corresp onding to the parent from the challenge. F or the Merkle recursion, only hash verifications and homomorphic signature op erations (whic h typically consist of multiplying 1024-bit n umbers) will b e performed, so the ov erall cost is dominated by a single digital signature verifi cation. The num b er of challenges is selected based on the desired probability of detection. With t challenges, there is a probability of t/ |R N | of detecting that N did not co de o ver a parent. After r transmissions in whic h N cheats, the probability of detecting N is at least 1 − (1 − t/d ) r (this is achiev ed when N cheats minimally – by not co ding o ver one parent), which increases exp onen tially in r . Coupled with p enalties, suc h a probabilistic approac h offers incentiv es against cheating. No de N needs to remem b er the v alues that constituted the Merkle tree until the children finished c hallenging it. One c hallenge c hecks that the no de co ded correctly ov er a paren t; multiple c hallenges can b e sent at once and pro cessed together. Algorithm 3 Challenge on no de N by no de C j 1: C j pic ks a parent P i of N at random and informs N of the c hoice. 2: N m ust present A P i (defined in Figure 3 ) and all v alues of the no des in the Merkle tr ee that are siblings to no des on the path from A P i to the ro ot and their siblings. 3: C j runs VerifTest : i verifies that H P i is a correct signature ov er σ s ( E P i ) using pk P i and that α i 6 = 0 ii verifies that the v alidity signature in A P i com bined with α i is the same as the v alidity signature in B i , iii the v alidity signature at eac h in ternal node is a multiplication of the v alidity signatures at the c hildren of the no de, iv recomputes the Merkle hash based on the hashes pro vided by N and c hecks equalit y to T N , v chec ks that the v alidity signature, pro vided when N initially transmitted, verifies the v alidity signature at the top of the Merkle tree, vi chec ks H N to b e a signature using pk N on σ S ( E N ). As for CheckHelper , C j still needs to chec k that H N is indeed a signature on E N and is not a signature on zero to prev ent N from causing C j to fail the v erification test at C j ’s children. Pro ofs of securit y for this proto col are included in Section 4.8 . Collusion. Both PIP and Log-PIP are collusion resistan t: even if a child colludes with N , the other c hildren chec k N indep enden tly . Moreov er, if N colludes with a parent P 1 , N still needs to code correctly o ver the rest of the parents that he did not collude with b ecause he cannot forge these paren ts signatures if N has at least one honest child v erifying it. 4.5 Ho w to F orce Byzantine No des to Co de Pseudorandomly As a second step, we design a verification test that enables any child C j of a no de N to chec k, not only whether a pack et received from N is v alid and derived using non-zero co efficien ts ov er eac h parent in his required set (as was guaran teed by the solution presented in Section 4.4 ), but also whether the no de N co ded using (pseudo)random co efficien ts in Z ∗ q . The basic idea is to require no de N to generate the pseudorandom co efficien ts from a seed that is also kno wn to each child C j , so that each C j will b e able to generate these same co efficien ts and use them as part of his verification test on N . W e assume that each clien t knows a random seed s that is public; a trusted party drew the seed at random when the system started. F or example, a client can learn ab out the seed s when he joins the system. In a wireless setting with no mem b ership, a no de can either ha ve s already hardco ded, or he can obtain it from his neighbors ( s can b e accompanied by a signature from a trusted party to make sure that malicious neighbors cannot lie about its v alue). The seed can remain the same for the lifetime of the system. Using the seed s , the co efficien ts can then b e generated using a pseudorandom function F s (defined in Section 4.2 ). F or each parent P i in the paren t set P N , the no de N computes α ∗ i = F s ( P i || N ) (of course, mapp ed to the field of the co efficien ts) and uses α ∗ i as the co ding coefficient for the pack et from P i . 12 Observ e that, con trary to what the definition of the pseudorandomness prop ert y [ GGM86 ] prescrib es, the seed s is not kept priv ate, but is instead made public . Of course, in such a case, one cannot exp ect that the input-output relation induced by F s is unpredictable; indeed, it is deterministic, b ecause now F s ma y b e computed by any one (and is not an “oracle” anymore). Nonetheless, since in our setting the inputs to F s are not under the control of Byzantine no des, and are predetermined, it is easy to show that the outputs of F s on these inputs will still retain the statistical prop erties that w e are interested in, allo wing for the netw ork throughput to still b e maximal using these “pseudorandom” co efficien ts. If one wishes to enable N to use a differen t set of coding co efficien ts for each child C j , the computation of the co ding co efficien ts can be c hanged to α ∗ i,j = F s ( P i || N || C j ); thus N must use α ∗ i,j to code o ver the data from P i when preparing a pac ket for c hild C j . Intuitiv ely , using different co efficients increases throughput in some top ologies b ecause of more div ersity; this can be helpful in P2P netw orks, for example, but not so muc h in a wireless setting where transmitting different data to children will not take adv antage of the shared medium on which multiple c hildren can listen. The v erification tests in previous sections can no w b e easily modified to hav e each child C j c heck that N co ded ov er each paren t in the required set with this exact co ding co efficien ts α ∗ i (or α ∗ i,j ): in Step 4 of Algorithm 2 and in Step 3 i of Algorithm 3 , no de C j m ust c heck that α i equals α ∗ i (or α ∗ i,j ). With this c heck in place, Byzantine no des are forced to co de with pseudorandom co efficien ts. Section 4.8 shows that Byzan tine no des cannot co de with differen t co efficients and pass the verification test. 4.6 Ho w to Prev ent Repla y Attac ks of Old Data One problem is that a Byzan tine client may code correctly for one transmission, but may attempt to c heat on the next transmission by sending the old data he sent for the first transmission. In some cases, suc h a strategy reduces throughput, but in others, it even p ollutes pack ets downstream in the net work. Nev ertheless, the Byzantine client will pass any p ollution test b ecause the source uses the same k eys for signing in b oth transmissions; the node will also pass our div ersity tests abov e b ecause he co ded correctly o ver his paren ts in the first transmission. Therefore, w e need to preven t suc h replay attacks. In fact, the problem of replay attacks b elongs to the use of pollution schemes and is not introduced by our diversit y enforcement scheme. Any solution for that setting will suffice in our setting as w ell because of the wa y we build “on top” of v alidity signatures. Therefore, any ov erhead introduced by suc h a scheme already is in tro duced b y the use of pollution schemes and do es not come with diversit y enforcement. W e prop ose one such replay solution. The idea is to ha ve the source c hange the v alidity signature key with every transmission so that any attempt by a Byzantine clien t to use old data would b e detected when c hecking the v alidity signature. Let ( sk S,k , pk S,k ) denote the public key used b y the source in the k -th transmission. The source has one master signing key pair of which the public verification k ey is known to all users as b efore. T o inform no des of the public key used during a transmission, the source will send with every pac ket this public key accompanied by a signature of this public key using the master signing k ey . The source signs the public k ey to preven t malicious clients from forging public keys of their own and claiming they b elong to the source. F or our div ersity scheme, we make use of the public k ey corresponding to each transmission to add div er- sit y in the co ding co efficien ts across transmissions. Each node should now co de with α ∗ i = F s ( P i || N || pk S,k ) and their children will c heck the inclusion of pk S,k in the co ding co efficien ts along with the other tests they p erform; without pk S,k , the co ding coefficients will b e the same across differen t transmissions. 4.7 Ho w to Enable No des to Pro v e Misb eha vior W e discuss how any child C j of a node N can pr ove N ’s misb ehavior to a third party , when the verification test for N fails. Recall that the ability to convince a third party (suc h as the source, a membership service, or other authoritativ e agents in the system) that N did indeed misb ehav e is imp ortan t to allow for punitiv e measures to b e enacted. F urthermore, the ability to prov e misbehavior r einfor c es the deterr ent effe ct of verific ation tests . W e use signatures in a natural wa y to provide such pro ofs: Step 5 of Algorithm 1 is mo dified so that a no de N attaches an additional “attest” token to the pack et he sends to his children; the attest token consists of a signature of the whole pack et under his own secret key sk N . Each child C j of N will then v erify this signature (and ignore any data from N that do es not carry a v alid “attest” signature). If a child C j establishes that his paren t N did not code correctly based on the verification tests in Algorithm 2 or Algorithm 3 , he can provide the pack et from N together with his attest tok en as pro of to a 13 third party . An y other party kno wing the required set R N of no de N can run the VerifTest pro cedures to establish if N cheated. Of course, by the unforgeabilit y prop ert y of the signature sc heme, children of N cannot falsely accuse N of misb eha vior. 4.8 Pro ofs of Securit y Theorem 4.1 (Securit y of PIP) . In proto col PIP, if a generic no de N passes all chec ks at an honest c hild C j , it means that N co ded o ver the v alue from P 1 , E P 1 , with precisely co efficien t c 1 (as describ ed in Section 4.5 ), where P 1 is any generic parent from N ’s required set. Pr o of. Algorithm 2 gives VerifTest for the PIP proto col. If N passes the chec ks in Step 2, it means that N provided the triple  c 1 , σ ( E P 1 ) , H P 1  in T N ; if N passes the c hecks in tep 3 and Step 4, it means that P 1 indeed provided σ ( E P 1 ) and c 1 6 = 0; if N passes the chec k in Step 6, it means that N computed σ ( E N ) by including σ ( E P 1 ) with co efficien t c 1 in the homomorphic computation (describ ed in Section 4.2 ). In Step 2 of Algorithm 1 when run b y C j , the no de C j c hecks that σ ( E N ) verifies as a signature of N . By the theorem’s hypothesis, the p ollution signature verifies, so that, by the security of the p ollution sc heme (detailed in [ BFKW09 ]), it must b e the case that N included c 1 · E P 1 when computing E N . Theorem 4.2 (Securit y of Log-PIP) . In proto col Log-PIP , if a generic no de N did not co de ov er any giv en parent, say P 1 , from his required set with co efficient c 1 (as describ ed in Section 4.5 ), and an honest c hild C j c hallenges N on t random paren ts, the probability that N is detected (some chec k fails) is at least t/ |R N | . Pr o of. The strategy of the pro of is to present some exhaustive cases in whic h N could not hav e co ded o ver a parent, and show that in each such case the probability of detection is ≥ t/ |R N | . Consider the tree T ree N of v alues that N used when he computed the Merkle hash that he ga ve to C j . Because of the Merkle hash guarantees, N cannot come up with any other tree (that is not a subtree of T ree N ), that has the same Merkle ro ot hash. If any leaf i in this tree (if a leaf exists) do es not satisfy chec k (i) in Step 3 of Algorithm 3 , it will b e caught if C j c hallenges N on parent P i , whic h happ ens with probability t/ |R N | . Similarly , if any internal no des B i do not satisfy c heck (ii), C j will detect this with probability at least t/ |R N | . Therefore, w e can assume that the first lev el of in ternal nodes in the T ree N consists of the exp ected hashes and σ ( c i E P i ) where c i is the desired co efficient and σ ( E P i ) is indeed the v alidit y signature from parent P i . If an y internal no de in T ree N do es not satisfy chec k (iii), this will b e detected whenever N is c hallenged on a v alue i that in volv es a path through the Merkle tree passing through the brok en in ternal no de; this happ ens with probabilit y at least t/ |R N | . Therefore, assuming all internal no des pass c heck (iii), it means that the v alidity signature at the top of the tree must b e σ ( P i c i E P i ). If the v alidity signature at the top of T ree N do es not matc h the one initially pro vided by N (i.e., σ ( E N )), chec k (v) will fail with probability 1. Assuming, this chec k succeeds it must b e the case that the v alidity signature initially pro vided by N is a prop er v alidity signature after co ding with c i o ver all P i . Since the v alidity signature matc hed E N (c heck (2) of Algorithm 1 when run at child C j ), it means that N co ded ov er all parents with the righ t co efficients, b y the guarantees of the v alidity signature. Therefore, there are no more cases of p ossible cheating from N to consider and since all previous types of cheating were caught with c hance ≥ t/ |R N | , the pro of is complete. 5 Applications and Extensions In this section, we describ e applications and extensions of our proto col. 5.1 T yp es of Required Sets In our proto cols so far, we considered that a child of no de N p erforms the verification test on a sp ecific set of required parents for N . How ever, one can use different t yp es of verification tests, some b eing more useful for certain settings, as we will see. All these verifications, in fact, just map to v erifying a sp ecific required set as b efore. A child C j can p erform any of the following chec ks for no de N : (1) N c o de d over al l his p ar ents or over a sp e cific set of p ar ents. 14 (2) Thr eshold enfor c ement: N c o de d over at le ast d p ar ents. This chec k can b e enforced by ha ving N send an indication of which parents he co ded o ver with their public keys and certificates (defined in Section 3.2 ): C j c hecks that these are at least d in num b er, chec ks the certificate of each public key to make sure N did not falsify these keys, and that N indeed co ded o ver them. (3) N c o de d over at le ast some subset of p ar ents. This is a com bination of Item 1 and Item 2 . C j c hecks that N co ded o ver the subset of paren ts as in Item 1 and ov er some v alid parents as in Item 2 . (4) N c o de d over a set of p ar ents with some applic ation-level pr op erty. F or example, N must co de ov er at least tw o parents noted by some application as high priorit y and at least five parents in total. The priorit y of each no de P i can b e included in the certificate cert P i . N again indicates the no des he co ded o ver to C j along with their public keys and certificates, and C j c hecks that at least tw o certificates con tains high priority and there are at least fiv e in total. Other general application seman tics can b e supp orted by this v erification case. 5.2 Applications and Required Sets In this section, we describe the v arious settings to which our proto cols are applicable, and ho w the no des w ould learn of the required set of their parents. Our mo del applies to settings in which a no de can learn the required set of his paren ts, such as: 1) Systems with a memb ership servic e: the membership service can inform a node of his grandparen ts when the no de joins and when changes o ccur. Some p eer-to-p eer and con tent distribution systems fall in this category . 2) Systems having a r eliable yet p otential ly low c ap acity channel b esides the channel where the coding o ccurs (whic h may be less reliable, but has higher capacity): the reliable channel can b e used to comm u- nicate top ology c hanges b et ween no des. Some examples of applications are decentralized p eer-to-peer applications and conten t distribution, as well as some wireless netw orks. 3) Static top olo gies: these topologies do not change or c hange rarely . The top ology is mostly known to the no des (e.g., nodes can disco ver it when joining), so a node will kno w his grandparents. Wired as well as some wireless netw ork applications fall in this category . F or wired netw orks, since the top ology is more static and dela ys tend to b e low er, more aggressiv e v erification tests can b e implemented (e.g. the required set is most of the parents or all of the parents, dep ending on the particular system). 4) Mo der ately dynamic wir eless top olo gies: the set of grandparen ts for a node ma y c hange man y times, after eac h change, it remains the same for enough time allowing the node to disco ver the new grandparen ts. Let us discuss how a c hild can learn ab out his changing grandparen ts in dynamic top ologies. First of all, for such top ologies, we recommend no des use the threshold enforcement sc heme (describ ed in ( Item 2 ab o v e) b ecause the set of paren ts of a node c hanges dynamically . The threshold should b e adjusted based on some minimum num b er of links a no de is exp ected to hav e in order to code div ersely . Consider that paren ts of no de N hav e c hanged and child C j w ants to learn ab out this. W e use the same links used by pack et flow to inform C j of his grandparents. Each new parent P i sends N : his public key and the corresp onding certificate cert P i . N sends this information to C i . Let’s discuss the case when N is malicious and may try to inform C i of incorrect parent list. Note that N cannot lie that P i is a paren t when he is not b ecause, if N do es not hav e a link to P i , during transmission time, no des C i will v erify that N co ded ov er the data from P i whic h N could not hav e done b ecause he did not receiv e this data. Moreov er, N cannot create some public k eys of his o wn and claim that some parents with those public keys exist, b ecause each no de k ey has a certification as discussed. On the other hand, N ma y try to simply not rep ort an y of his parents so that he do es not hav e to forward or co de o ver any data. Ho wev er, eac h c hild C i will exp ect N to rep ort at least a threshold of parents; if N do es not do so, C i can b e suspicious and denounce N of p otentially b eing malicious, as discussed in Section 3.2 . Therefore, N c an cho ose which d p ar ents to c o de over fr om the set of p ar ents physic al ly linke d to it, but he c annot cho ose less than d such p ar ents . Ho wev er, our scheme would not w ork well for highly changing top ologies that also do not fall under an y of Item 1 or Item 2 . Such an example are military ad-ho c wireless netw orks where the no des are in constan t rapid mov ement; this would not allo w a c hild to discov er his grandparents effectively . 15 5.3 Extensions In this section, we describ e how our proto col could b e applied to other netw ork co ding scenarios. First, note that we did not mak e any assumption ab out what a link or a no de really is. A link can b e a physical link, a c hain of ph ysical links, or even a subnetw ork. F or example, in a p eer to p eer netw ork, a link can include an entire subnetw ork via which some p eers send data to a receiving p eer. In this case, our proto col can b e used to chec k that the receiving p eer co ded ov er all sender p eers when he forwards the pac kets to some other p eer. As another example, a link in a wired netw ork may represent a connection, while a link in a wireless net work ma y b e the ability to hear/communicate with another no de or b e an edge induced by the data transmission graph. Moreov er, a no de can b e a physical node (a router, a p eer in a P2P net work) or a subnetw ork; in fact, a few no des in our mo del can form one no de for a certain system. Using these observ ations, we can express constrain ts of real-world net works: Multiple pack ets ma y b e sent on some links. Consider that parent P i has a capacity of p pack ets on the link to no de N . In this case, in our proto col, P i will b e represen ted as p different no des, each with a different public key . With this transformation, our proto col can b e used unchanged. Broadcast links. Broadcast in wireless can b e mapp ed to our mo del by ha ving the parent hav e one link (the same link) to all his children (basically , viewing all c hildren as one c hild), and our proto cols can b e applied unc hanged. Multi-source net work co ding. In the multi-source netw ork co ding case, intermediate nodes combine pac kets for different files from differen t sources, but eac h source operates independently and may not comm unicate with the others. In suc h w ork, the metadata of the pack et is augmented with information ab out which source and whic h file iden tifiers the current pac ket contains. T o supp ort our proto cols in the multi-source case, note that PIP and Log-PIP dep end on source information only when c hecking v alidity signatures. Moreo ver, our proto cols are built modularly on top of a v alidity signature and do not depend on any particular scheme. This means that all we need is a multi- source v alidity signature and the rest of the algorithms will remain unchanged. Recent w ork [ ABBF10 ] prop oses such sc hemes: sources can send pack ets indep enden tly of each other, eac h pack et contains a v alidity signature, and these signatures can b e c heck ed at each intermediate no de by knowing the public k eys of eac h of these sources. Children will be able to chec k if their parents co ded ov er the appropriate grandparen ts as b efore. Async hronous netw orks and delay in tolerant net works. A c hild may receive data from his paren ts at different times. F or efficiency reasons, the child ma y hav e to co de ov er the data that he received already and send the data forw ard, and not wait until a piece arrived from ev ery parent. In this case, the child N can enforce the threshold verification ab ov e, thus chec king that the pac ket from N is co ded ov er at least a few parents. V arious levels of abstraction. Our proto col can b e used at v arious levels of abstraction. F or example, in p eer-to-peer netw orks, no des can p erform: • End-to-end che ck. A p eer can chec k that the data from another p eer is the result of co ding ov er the data of all of certain sources, even if those sources comm unicated with the tested peer via other no des or netw orks. • Individual no de che ck. A p eer can chec k that the data from another p eer is the result of co ding ov er all of certain peers to which this peer should be connected to according to the Peer-to-P eer algorithm they run or whatever application they run. A lot of P2P systems are taking adv antage of smartphones no wada ys. In Section 6 , w e sho w that our proto col is efficient ev en when run on a smart phone such as Android Nexus One. 6 Implemen tation and Ev aluation In this section, we ev aluate the usefulness and the p erformance of our proto col. 6.1 Sim ulation W e run a Python simulation to sho w that there is significant throughput loss due to Byzan tine behavior not detected in previous work, but detected in our proto cols. W e examined three types of node behavior: (Mo de 1) Byzantine no des c ho ose co ding co efficien ts such that their pack et do es not pro vide new information at 16 Figure 4: (a) One and (b) ten Byzan tine nodes on the mincut. their children; (Mo de 2) Byzantine no des simply forw ard one of the received pack ets (and do not co de); (Mo de 3) Byzantine no des are forced to co de with pseudorandom co efficients. W e can see that neither Mo de 1 nor Mode 2 are detected b y prior w ork on p ollution sc hemes, but both are detected by our proto cols. Mo de 3, whic h is the correct b eha vior, is enforced only by our protocols. The simulation constructs a graph b y assigning edges at random b et ween no des, but maintaining the giv en minimum cut. The Byzantine no des are placed on the minimum cut. W e ran the simulation for [50 no des, 1000 edges, 5 pack ets sent from the source, min-cut up to 10, 1 Byzantine no de] and [100 no des, 2000 edges, 20 pack ets send from the source, min-cut v alue up to 20, 10 Byzantine no des]. Figure 4 sho ws the throughput (i.e., the degrees of freedom) at the sink plotted against the min-cut v alue. W e can see that the throughput difference b etw een Mo des 1/2 and Mo de 3 is significant. Moreov er, when the min-cut v alue of the netw ork is small (e.g., 5), the throughput increase when using Mo de 3 can b e as large as t wice (see min-cut v alue of 3 in Figure 4 (a)). In Figure 4 (b), w e can see a more significant throughput difference. Mode 3 has a throughput of ab out 10 degrees of freedom more than Mo de 1 (which is 50% of the data sent by the source) and ab out 5 degrees of freedom more than Mo de 2 (whic h is 25% of the data sen t by the source). 6.2 Implemen tation W e implemen ted our proto col as a library (called Se cur eNetCo de ) in C/C++ and Ja v a, as well as em b edded it into the Android platform. The C/C++ implementation is useful for lo wer level co de that is mean t to b e fast: netw ork routers, v arious wireless settings, and other C/C++ programs. The Jav a implementation is useful for higher-lev el programs such as P2P applications. W e embedded the Jav a implementation in the Android platform and ran it on a Nexus One smartphone. The reason is that, with the growing popularity of smartphones, more P2P conten t distribution applications for smartphones are developed, some using net work coding ([ Har11 ], [ Fit08 ]). Our library implementation is av ailable at www.mit.edu/ ~ ralucap/netcode.html . It consists of the functions in proto cols PIP and Log-PIP. Our library in C/C++ consists of 290 lines and the one in Ja v a consists of 274 lines including comments and white lines, but excluding standard, n umber theory or cryptographic libraries. T o implement certain cryptographic op erations on large num b ers, we used NTL in C/C++ and BigIn teger in Jav a. As cryptographic algorithms, we used Op enSSL DSA and SHA. The size of the v alidit y signature used is 1024-bit. Results. Except for the Android results which were run on a standard Nexus One smartphone, the rest of the results were run on a dual-core pro cessor with 2 . 0 GHz and 1 GByte of RAM. There was observ able v ariability in the results (especially for Nexus One), so we ran the exp erimen ts up to 100 times to find an a verage time. Note that we only ev aluate the p erformance of our diversit y sc heme and do not ev aluate the p erformance of any p ollution signature protocol. The reason is that our proto col is not tied to any particular such sc heme and uses it mo dularly . T o enforce that no des code with co efficien ts of one ( Section 4.4 ), the most imp ortan t step for throughput, we inv ok e the p ollution scheme no more than it is inv oked without our div ersity c hecks. T o enforce our full proto col with pseudorandom co efficien ts, during verification, each no de computes one additional homomorphic op eration of the integrit y signature (p er parent for PIP and p er challenge for Log-PIP), typically an exp onen tiation in a certain group: sig S ( E P i ) α ∗ i . F ortunately , the co ding co efficien ts are typically relativ ely small, e.g., 64 bits (even though the in tegrity signature allows them to be as large as q as explained in Section 4.1 ). Note that the p ollution signature verification, which is exp ensiv e, is not called additionally . 17 C/C++ Jav a Android PIP Log-PIP PIP Log-PIP PIP Log-PIP 1 0.2/0.3 0.3/0.2 2.3/4.5 2.7/4.5 4.7/4.2 4.9/6.9 2 0.2/0.6 0.3/0.2 2.3/9 2.7/4.6 4.7/7.6 5.1/7.1 3 0.2/0.8 0.3/0.3 2.3/14 2.8/4.6 4.7/15.4 5.7/10.4 5 0.2/1.4 0.3/0.3 2.3/23 2.8/4.7 4.7/24.4 6.7/10.5 7 0.2/1.9 0.3/0.3 2.3/32 2.9/4.7 4.7/35.4 10.2/10.8 10 0.2/2.8 0.3/0.4 2.3/45 2.9/4.7 4.6/70.6 11.9/10.3 15 0.2/4.2 0.3/0.4 2.3/68 3.0/4.7 4.6/101 11.7/10.4 50 0.3/14 0.4/0.4 2.3/224 3.4/ 4.7 4.6/351 28.5/15.6 + 0.95 |R| 0.95 8.8 |R| 8.8 15.4 |R| 15.4 T able 1: Performance results of PIP and Log-PIP in milliseconds. The first 8 rows with v alues show results for PIP and Log-PIP when all co ding co efficien ts are one ( Section 4.4 ). The first column indicates the num b er of parents of a no de. Each data cell in the rest of the columns consists of tw o v alues: transmission time and verification time. The last ro w shows the additional cost (only for verification) when adding pseudorandom co efficien ts ( Section 4.5 ) due to the homomorphic operation of the v alidity signature. In T able 1 , w e present p erformance results of PIP and Log-PIP using one challenge. W e consider an in tegrity signature of size 1024 bits and co ding co efficien ts of size 64 bits. W e can see that, for v erification, as w e increase the num b er of parents, the o verhead of Log-PIP increases v ery slo wly (logarithmically) as compared to the linear p erformance of PIP . The same happ ens to pack et size, which we ev aluate later in this section. Therefore, we r e c ommend using L o g-PIP for sc enarios with mor e than thr e e p ar ents, and PIP for c ases with at most thr e e p ar ents. Alternatively , one could select a hybrid algorithm b y p erforming r > 1 challenges from Log-PIP . The performance of Log-PIP grows linearly in the num b er of challenges so one can tune the probability of detection (see Section 4 ) based on the desired tradeoff with p erformance o verhead. W e can see that the C/C++ proto cols imp ose mo dest ov erhead. F or 10 paren ts, which is a reasonably large v alue, the running time at a no de to prepare for transmitting the data is ≈ 0 . 25 ms and the time to verify a pac ket’s div ersity 1 . 4 ms in total for Log-PIP; for three parents, the time to verify div ersity is 3 . 7 ms for PIP . All these v alues are indep endent of how lar ge the p acket p aylo ad is . Let’s compare this to the cost of a p ollution scheme, for example [ BFKW09 ]. In this scheme, the v erification consists of tw o bilinear map computations and m + n mo dular exp onen tiations, resulting in at least 100 ms run time for v erification in C using the PBC library for bilinear maps for each parent. F or three paren ts, the relative o verhead of PIP is thus < 2% and of Log-PIP is < 0 . 5%. Due to this low additional o verhead, w e b eliev e that if one is already using a pollution scheme, one migh t as w ell also use our sc heme in addition to pro vide div ersity . The Jav a and Android implementations are slow er b ecause of the language and/or device limitations of the Nexus One. Nevertheless, we b eliev e these implementations still p erform well when used for higher lev el applications like P2P con tent distribution. 6.3 P ac ket Size F or PIP, the pack et size increase in PIP is |R N | · ( | σ S | + 320) + 320 bits and the sum of pack et increase and information sent during challenge phase in Log-PIPis 480 + | σ S | + 2 | σ S | log( |R N | ) bits, where |R N | is the n umber of paren ts to co de o ver. Recall that | σ S | is the size of the v alidity signature, and dep ends on the v alidity sc heme used. F or instance, if [ BFKW09 ] is used, we ha ve an increase in PIP of 480 · |R N | + 320 bits and in Log-PIP of 640 + 320 · log ( |R N | ) bits. As discussed in Section 4 , the pack et size do es not increase as the payload grows, so suc h ov erhead b ecomes insignifican t when transmitting large files. 7 Conclusions In this pap er, we presented t wo nov el proto cols, PIP and Log-PIP, for detecting whether a no de co ded correctly o ver all the pac kets receiv ed according to a random linear netw ork co ding algorithm. No previous w ork defends against suc h diversit y attacks by Byzantine no des. Our ev aluation sho ws that our proto cols are efficient and the ov erhead of b oth of our proto cols does not gro w with the size of the pack et pa yload. 18 References [AB09] Shw eta Agra wal and Dan Boneh. Homomorphic MA Cs: Mac-based in tegrity for net work co ding. ACNS, 2009. [ABBF10] Shw eta Agra wal, Dan Boneh, Xa vier Bo yen, and Da vid Mandell F reeman. Preven ting p ollution attac ks in multi-source netw ork co ding. In PKC ’10: Pr o c e e dings of the 13th International Confer enc e on Pr actic e and The ory in Public Key Crypto gr aphy , pages 161–176. Springer, 2010. [A CL Y00] Rudolf Ahlswede, Ning Cai, Sh uo-Y en Rob ert Li, and Ra ymond W. Y eung. Netw ork informa- tion flo w. IEEE T r ans. Inf. The ory , 2000. [BFKW09] Dan Boneh, David Mandell F reeman, Jonathan Katz, and Brent W aters. Signing a linear subspace: Signature schemes for netw ork co ding. In PKC ’09: Pr o c e e dings of the 12th In- ternational Confer enc e on Pr actic e and The ory in Public Key Crypto gr aphy , pages 68–87. Springer, 2009. [CJL06] Denis Charles, Kamal Jain, and Kristin Lauter. Signatures for netw ork co ding. In CISS ’06: Pr o c e e dings of the 40th Annual Confer enc e on Information Scienc es and Systems , pages 857– 863, 2006. [DCNR09] Jing Dong, Reza Curtmola, and Cristina Nita-Rotaru. Practical defenses against p ollution attac ks in intra-flo w netw ork co ding for wireless mesh netw orks. WiSec, 2009. [Fit08] F rans Fitzek. Netw ork co ding for mobile phones. Online at http://blogs.forum.nokia. com/blog/frank- fitzeks- forum- nokia- blog/2008/10/06/network- coding , 2008. [GGM86] Oded Goldreich, Shafi Goldw asser, and Silvio Micali. How to construct random functions. Journal of the A CM , 1986. [GR05] Christos Gk an tsidis and Pablo Rodriguez. Netw ork co ding for large scale conten t distribution. In INFOCOM , 2005. [GR06] Christos Gk antsidis and Pablo Ro driguez. Co op erativ e securit y for net work co ding file distri- bution. In INF OCOM , 2006. [Har11] Larry Hardesty . Secure, sync hronized, social tv. Online at http://web.mit.edu/newsoffice/ 2011/social- tv- network- coding- 0401.html , 2011. [HKM + 03] T racey Ho, Ralf Ko etter, Muriel M ´ edard, Da vid R. Karger, , and Michelle Effros. The benefits of co ding ov er routing in a randomized setting. In ISIT , 2003. [HLK + 08] T racey Ho, Ben Leong, Ralf Ko etter, Muriel M´ edard, Michelle Effros, and Da vid R. Karger. Byzan tine modification detection in m ulticast netw orks with random netw ork co ding. IEEE T r ansactions on Information The ory , 54(6):2798–2803, 2008. [Jia06] Anxiao Jiang. Net work co ding for joint storage and transmission with minimum cost. In ISIT 06: Pr o c e e dings of the 2006 IEEE International Symp osium on Information The ory , pages 1359–1363. IEEE, 2006. [JLK + 08] Sidharth Jaggi, Michael Langb erg, Sac hin Katti, T racey Ho, Dina Katabi, Muriel M´ edard, and Michelle Effros. Resilient netw ork co ding in the presence of Byzantine adversaries. IEEE T r ans. Inf. The ory , 2008. [JSC + 05] Sidharth Jaggi, Peter Sanders, Philip A. Chou, Mic helle Effros, Sebastian Egner, Kamal Jain, and Ludo M. G. M. T olh uizen. Polynomial time algorithms for m ulticast netw ork co de con- struction. IEEE T r ansactions on Information The ory , 51(6):1973–1982, 2005. [KFM04] Maxwell N. Krohn, Michael J. F reedman, and David Mazi` eres. On-the-fly v erification of rateless erasure co des for efficien t conten t distribution. In S&P ’00: Pr o c e e dings of the 2000 IEEE Symp osium on Se curity and Privacy , pages 226–240. IEEE Computer So ciet y , 2004. 19 [KM03] Ralf Koetter and Muriel M ´ edard. An algebraic approac h to net work co ding. IEEE/A CM T r ansactions on Networking , 11(5):782–795, 2003. [KMB10] MinJi Kim, Muriel M´ edard, and Joo Barros. A multi-hop multi-source algebraic watc hdog. CoRR , 2010. [KTT09] Oliver Kosut, Lang T ong, and David Tse. Nonlinear netw ork co ding is necessary to combat general byzan tine attacks. Allerton, 2009. [LA V10] Guanfeng Liang, Rachit Agarwal, and Nitin V aidya. When watc hdog meets co ding. INF O- COM, 2010. [LM10] Anh Le and A thina Markopoulou. Lo cating byzan tine attack ers in intra-session netw ork coding using spacemac. NetCo d , 2010. [LMK05] Desmond S. Lun, Muriel M´ edard, and Ralf Ko etter. Efficient operation of wireless pack et net- w orks using netw ork co ding. In IWCT ’05: Pr o c e e dings of the 2005: International Workshop on Conver gent T e chnolo gies , 2005. [L YC03] Shuo-Y en Rob ert Li, Ra ymond W. Y eung, and Ning Cai. Linear net work coding. IEEE T r ans. Inf. The ory , 49(2):371–381, F ebruary 2003. [Mer89] Ralph C. Merkle. A certified digital signature. In CR YPTO ’89: Pr o c e e dings of the 9th A nnual International Cryptolo gy Confer enc e , pages 218–238, New Y ork, NY, USA, 1989. Springer- V erlag New Y ork, Inc. [NIS] FIPS PUB 186-3: Digital Signature Standard (DSS). National Institute of Standards and T echnology , http://csrc.nist.gov/groups/ST/toolkit/digital_signatures.html . [NS08] Zunnun Narmaw ala and Sanja y Sriv astav a. Survey of applications of netw ork co ding in wired and wireless net works. In NCC ’08: Pr o c e e dings of the 14th Annual National Confer enc e on Communic ations , 2008. [WNE00] Jeffrey E. Wieselthier, Gam D. Nguyen, and An thony Ephremides. On the construction of energy-efficien t broadcast and multicast trees in wireless net works. In INFOCOM ’00: Pr o c e e dings of the 19th A nnual IEEE International Confer enc e on Computer Communic ations , pages 585–594. IEEE, 2000. [WVNK10] Qiyan W an, Long V u, Klara Nahrstedt, and Himansh u Khurana. Iden tifying malicious no des in netw ork-co ding- based p eer-to-peer streaming net works. IEEE INFOCOM , 2010. [YSJL10] Hongyi Y ao, Danilo Silv a, Sidharth Jaggi, and Michael Langb erg. Net work co des resilient to jamming and eav esdropping. CoRR , 2010. [YWR G08] Zhen Y u, Y aw en W ei, Bhuv aneswari Ramkumar, and Y ong Guan. An efficient signature-based sc heme for securing net work co ding against p ollution attac ks. In INFOCOM , 2008. [ZKMH07] F ang Zhao, T on Kalk er, Muriel M´ edard, and Keeso ok J. Han. Signatures for conten t distri- bution with netw ork co ding. In ISIT , 2007. 20