Multicast Security: A Taxonomy and Some Efficient ConstructionsMuliticast CommunicationMulticast IssuesMulticast Security IssuesMulticast Security Issues: Contd.Performance IssuesGeneral Solution Impossible!Single source bcast: IssuesIssues in Single source bcastVirtual ConferencingEfficient Authentication SchemesMAC AttacksQ-per message unforgeableAuthentication scheme for single sourcePerformance Analysis of the schemeSecurity of schemeProof: ContdMultiple Dynamic SourcesDynamic Secrecy: User RevocationTree based schemeGraphic View of Initial KeysDeleting a memberGraphical View for DeletionImproved SchemeGraphical view of improved schemeConclusionsThank You!Multicast Security: A Taxonomy and Some Efficient Constructions By Cannetti et al, appeared in INFOCOMM 99. Presenter:Ankur GuptaMuliticast CommunicationExamples: Internet video transmissions, news feed, stock quotes, live broadcast, on-line video games, etc.Challenges: 1. Security: Authentication, secrecy, anonymity, etc.2. Efficiency: the overhead associated in providing security must be minimized: communication cost, authentication/verification time.Multicast IssuesMember characteristics: similar computing power or some more powerful than others? Membership static or dynamic? Key revocation is an issue for dynamic scenes.Number and type of senders? Single or multiple? Can non-members send data?Volume and type of traffic? Is communication in real-time?Multicast Security IssuesSecrecy1. Ephemeral: Avoid easy access to non-members. Ok if non-members receive after a delay.2. Long-term: protecting confidentiality of data for a long duration.Authenticity:1. Group authenticity: each member can recognize if a message was sent by a group member.2. Source authenticity: each member can identify the particular sender in the group.Multicast Security Issues: Contd.Anonymity: keeping identity of group members secret from non-members and/or from other group members. Non-repudiation: ability of receivers of data to prove to 3rd parties that data was received from a particular entity. Contradicts anonymity.Access control: only registered and legitimate users have access to group communication. Requires authentication of users.Service Availability: keeping service available in presence of clogging attacks.Performance IssuesLatencyWork overhead per sendingBandwidth overheadGroup management activity should be minimized:1. Member initialization2. Member addition/deletionGeneral Solution Impossible!Impossible to find a general solution that address all the above issues.Identify scenes representative of practical multicast communication.1. Single source broadcast.2. Virtual Conference.Single source bcast: Issues1. Source: high-end machine, expensive computation ok at server end.2. Recipients low-end. Efficiency at recipients is a concern.3. Membership is dynamic and changes rapidly.4. High volume of sign-in/sign-off possible.5. Ephemeral secrecy generally suffices.6. Authenticity of data critical (e.g. stock quotes).Issues in Single source bcastEphemeral secrecy: solved by having a group management center that handles access control and key management. How to authenticate messages?How to make sure that a leaving member loses the capability to decrypt?Virtual ConferencingOnline meeting of executives, interactive lectures and classes, multiparty video games.Membership usually static. No. of receivers far less than single source bcast.Authenticity of data and sender is critical. Sender and receiver of similar computation power.Efficient Authentication SchemesPublic key cryptography signatures is very expensive.Instead, we will use message authentication codes (MAC), MAC(k,M)= secure hashMACs are computationally much more efficient than digital signatures.MAC AttacksPer-Message unforgeability of MAC scheme1. Complete attack: an attacker can break any message of its choice. 2. Probabilistic attack: an attacker can forge a random message with some fixed but small probability.Q-per message unforgeable A MAC scheme is q-per message unforgeable if an adversary can guess its MAC value with probability at most q.Assumption: we will assume there are at most w corrupted users.Authentication scheme for single sourceSource knows l=e(w+1)log(1/q) keys, R=hK1,…,Kli.Each recipient u knows a subset of keys Ru ½ R. Every key Ki is included in Ru with probability 1/(w+1), independently for every i and u.Message M is authenticated by S with each key Ki using MAC and hMAC(K1,M),…,MAC(Kl,M)i is transmitted.Each recipient u verifies the all MACs which were created with keys in Ru. If any of them is incorrect then rejects the message.Performance Analysis of the schemeSource holds MS = l = e(w+1) log(1/q) keys.Each receiver holds MV = e log(1/q) keys.Communication overhead per message C= e(w+1)log(1/q) MACs.Running time overhead TS = e(w+1)log(1/q) MAC computations for source and TV = e log(1/q) per receiver.Security of schemeTheorem: Assume probability of computing MAC without knowing key is q’. Then probability that a coalition of w users can falsely authenticate a message to a user is at most q+q’. Proof: Probability that key is good (contained in user u’s subset but not in any of colluders set) is:Proof: ContdTherefore probability that Ru is completely covered by subsets held by colluders is (1-g)l < q. If Ru is not covered completely, then there is a key Ki not known to any colluder. Therefore, its corresponding MAC can be guessed with probability at most q’. By union bound, we get guessing probability as q+q’. QED.Multiple Dynamic SourcesAssumption: Pseudo-random one-way hash functions {fk}Distinguishes between set of senders and receivers. Only a coalition of w or more receivers can falsely authenticate a message to a receiver.l primary keys hK1,…, Kli where l is as in single source scheme.Receiver initialization: each receiver v obtains a subset Rv of primary keys where each key Ki is included with probability 1/(w+1) in RvSender Initialization: every u receives a secondary set of keys hfk1(u), …, fkl(u)i. Can be sent whenever a sender joins.Message authentication: each receiver verifies all MACs whose key its has.Dynamic Secrecy: User RevocationHow to manage keys when a user leaves a group? We want that the old user is not able to decrypt the current communication in the
View Full Document