Multicast encryption: Difference between revisions

Revision as of 00:05, 5 May 2011

Latest revision as of 21:16, 4 May 2025

(36 intermediate revisions by 26 users not shown)

Line 1:

{{mi|{{Update|date=April 2025}}

{{User Sandbox}}

{{Notability|date=April 2025}}

{{Unreliable sources|date=April 2025}}}}

'''Multicast''' '''encryption''' is the use of [[encryption]] to ensure that only the chosen recipient(s) has access to multicast data.<ref name="r1" />

{{User LSU WikiProject USPP}}

== Multicasting ==

[[Multicast]] is what enables a node on a network to address one unit of data to a specific group of receivers.<ref name="r1">Micciancio, Daniele and Saurabh Panjwani. [http://cseweb.ucsd.edu/~spanjwan/multicast.html “Multicast Encryption: How to maintain secrecy in large, dynamic groups?”]</ref> In interactive multicast at the [[Data link layer|data link]] or [[network layer]], such as [[IP multicast]], Ethernet multicast or [[MBMS]] service over [[cellular network]], receivers may join and leave the group using an interaction channel. Only one copy of the data is sent from the source, and while copies are created and sent to the desired recipients by network infrastructure nodes.<ref name="r1" /> In for example IP multicast, a multicast group is identified by a class D [[IP address]]. A [[Host (network)|host]] enters or exits a group using IGMP ([[Internet Group Management Protocol]]).<ref name="r5" /> A message sent via multicast is sent to all nodes on the network, but only the intended nodes accept the multicast frames.<ref name="r3">Pessi, Pekka. Department of Computer Science, Helsinki University Of Technology. [http://www.tml.tkk.fi/Opinnot/Tik-110.501/1995/multicast.html “Secure Multicast”].</ref> Multicasting is useful in situations such as [[video conferencing]] and [[Online game|online gaming]].<ref name="r1" /> Multicast was used originally in [[LAN]]s, with [[Ethernet]] as the best example.<ref name="r3" /> A problem with multicast communication is that it is difficult to guarantee that only designated receivers receive the data. This is largely because multicast groups are dynamic; users come and go at any time.<ref name="r1" />

==Protocols==

One encryption protocol gives each member of a group a key that changes upon the entrance or exit of a member of the group.<ref name=r1/> Another proposes a primary key subsidized by additional keys belonging to legitimate group members.<ref name=r1/> The [[UFTP]] (encrypted UDP based FTP over multicast) protocol uses three phases: announce/register, file transfer, and completion/confirmation. The latest version 5.0 was released on 4/22/2020.<ref name="r2">{{Cite web |title=UFTP - Encrypted UDP based FTP with multicast |url=https://uftp-multicast.sourceforge.net/ |access-date=2025-05-04 |website=uftp-multicast.sourceforge.net}}</ref>

Today,Another oneprotocol alternativeuses in multicast encryption involves the use of[[Symmetric-key algorithm|symmetric key encryption]] where data is decoded by intended receivers using a [[Session key|traffic encryption key]] (TEK). The TEK is changed any time a member joins or leaves the group. This is not feasible for large groups. Users must be continuously connected to obtain the new keys. Yet Anotheranother moreprotocol commoninvolves method involves[[Public-key cryptography|asymmetric keys]]. Here, a private key is shared and those shares are given out asymmetrically. The initial member is given a number of shares, one of which is passed to each group member. Members If a member haswith a valid share of the key, he can view the message.<ref name=r5>Duan, Yitao and John Canny. Computer Science Division, UC Berkeley. [http://www.cs.berkeley.edu/~jfc/papers/06/CT-RSA06.pdf “How to Construct Multicast Cryptosystems Provably Secure Against Adaptive Chosen Ciphertext Attack”]. http://www.cs.berkeley.edu/~jfc/papers/06/CT-RSA06.pdf</ref>

== ISO ==

=Multicast Encryption=

The ISO ([[International Organization for Standardization]] (ISO) states that confidentiality, integrity, authentication, access control, and non-repudiation should all be considered when creating anya secure system.<ref>Pessi, Pekka.name="r3" Department of Computer Science, Helsinki University Of Technology. “Secure Multicast”. http://www.tml.tkk.fi/Opinnot/Tik-110.501/1995/multicast.html</ref>

* Confidentiality: No untrustedunauthorized party can access appropriate messages.

* Integrity: Messages cannot be changed during transit without being discovered.

* Authentication: The message needs to be sent by the person/machine who claims to have sent it.

* Access control: Only those users enabled can access the data.

* Non-repudiation: The receiver can prove that the sender actually sent the message.<ref name="r3" />

To be secure, members who are just being added to the group must be restricted from viewing past data.<ref>Pannetrat, Alain and Refik Molva. “Multiple Layer Encryption for Multicast Groups”. http://www.eurecom.fr/util/publidownload.fr.htm?id=1069</ref> Also, members removed from a group may not access future data.<ref name="r4">Pannetrat, Alain and Refik Molva. “Multiple Layer Encryption for Multicast Groups”. [http://www.eurecom.fr/util/publidownload.fr.htm?id=1069 “Multiple Layer Encryption for Multicast Groups”].</ref>

===Introduction===

[[Multicast]] is what enables a node on a network to send one unit of data to a special set of receivers.<ref>Micciancio, Daniele and Saurabh Panjwani. “Multicast Encryption: How to maintain secrecy in large, dynamic groups?” http://cseweb.ucsd.edu/~spanjwan/multicast.html</ref>

One copy of the data is sent, and multiple copies are created and then sent to the desired recipient.<ref>Micciancio, Daniele and Saurabh Panjwani. “Multicast Encryption: How to maintain secrecy in large, dynamic groups?” http://cseweb.ucsd.edu/~spanjwan/multicast.html</ref> A multicast group is identified by a class D [[IP address]].<ref>Duan, Yitao and John Canny. Computer Science Division, UC Berkeley. “How to Construct Multicast Cryptosystems Provably Secure Against Adaptive Chosen Ciphertext Attack”. http://www.cs.berkeley.edu/~jfc/papers/06/CT-RSA06.pdf</ref> A user enters or exits a group using IGMP ([[Internet Group Management Protocol]]).<ref>Duan, Yitao and John Canny. Computer Science Division, UC Berkeley. “How to Construct Multicast Cryptosystems Provably Secure Against Adaptive Chosen Ciphertext Attack”. http://www.cs.berkeley.edu/~jfc/papers/06/CT-RSA06.pdf</ref> A message sent via multicast is sent to all nodes on the network, but only the intended nodes accept the multicast frames.<ref>Pessi, Pekka. Department of Computer Science, Helsinki University Of Technology. “Secure Multicast”. http://www.tml.tkk.fi/Opinnot/Tik-110.501/1995/multicast.html</ref> Multicasting is useful in situations such as video conferencing and online gaming.<ref>Micciancio, Daniele and Saurabh Panjwani. “Multicast Encryption: How to maintain secrecy in large, dynamic groups?” http://cseweb.ucsd.edu/~spanjwan/multicast.html</ref> Multicast was used originally in [[LAN]]s, with [[Ethernet]] being the best example.<ref>Pessi, Pekka. Department of Computer Science, Helsinki University Of Technology. “Secure Multicast”. http://www.tml.tkk.fi/Opinnot/Tik-110.501/1995/multicast.html</ref> A problem with multicast communication is that it is difficult to guarantee that only designated receivers receive the data being sent.<ref>Micciancio, Daniele and Saurabh Panjwani. “Multicast Encryption: How to maintain secrecy in large, dynamic groups?” http://cseweb.ucsd.edu/~spanjwan/multicast.html</ref> This is largely due to the fact that multicast groups are always changing; users come and go at any time.<ref>Micciancio, Daniele and Saurabh Panjwani. “Multicast Encryption: How to maintain secrecy in large, dynamic groups?” http://cseweb.ucsd.edu/~spanjwan/multicast.html</ref> The problem of ensuring that only the chosen recipient obtains the data is known as multicast encryption.<ref>Micciancio, Daniele and Saurabh Panjwani. “Multicast Encryption: How to maintain secrecy in large, dynamic groups?” http://cseweb.ucsd.edu/~spanjwan/multicast.html</ref>

===ISO Standards=See also ==

* [[Broadcast encryption]]

The ISO ([[International Organization for Standardization]]) states that confidentiality, integrity, authentication, access control, and non-repudiation should all be considered when creating any secure system.<ref>Pessi, Pekka. Department of Computer Science, Helsinki University Of Technology. “Secure Multicast”. http://www.tml.tkk.fi/Opinnot/Tik-110.501/1995/multicast.html</ref>

===References===

*Confidentiality: No untrusted party can access appropriate messages.

{{Reflist}}

*Integrity: Messages cannot be changed during transit without being discovered.

*Authentication: The message needs to be sent by the person/machine who claims to have sent it.

*Access control: Only those users enabled can access the data.

*Non-repudiation: The receiver can prove that the sender actually sent the message.<ref>Pessi, Pekka. Department of Computer Science, Helsinki University Of Technology. “Secure Multicast”. http://www.tml.tkk.fi/Opinnot/Tik-110.501/1995/multicast.html</ref>

[[Category:Multicast encryption| ]]

To be secure, members who are just being added to the group must be restricted from viewing past data.<ref>Pannetrat, Alain and Refik Molva. “Multiple Layer Encryption for Multicast Groups”. http://www.eurecom.fr/util/publidownload.fr.htm?id=1069</ref> Also, members removed from a group may not access future data.<ref>Pannetrat, Alain and Refik Molva. “Multiple Layer Encryption for Multicast Groups”. http://www.eurecom.fr/util/publidownload.fr.htm?id=1069</ref>

===Theories===

One theory for the creation of an encryption protocol explains that ideally, each member of a group should have a key which changes upon the entrance or exit of a member of the group.<ref>Micciancio, Daniele and Saurabh Panjwani. “Multicast Encryption: How to maintain secrecy in large, dynamic groups?” http://cseweb.ucsd.edu/~spanjwan/multicast.html</ref> Another theory suggests a primary key subsidized by additional keys belonging to legitimate group members.<ref>Micciancio, Daniele and Saurabh Panjwani. “Multicast Encryption: How to maintain secrecy in large, dynamic groups?” http://cseweb.ucsd.edu/~spanjwan/multicast.html</ref> One protocol found on The College of New Jersey website called UFTP (encrypted UDP based FTP over multicast) was created in an attempt to solve this problem.<ref>“UFTP - Encrypted UDP based FTP with multicast”. http://www.tcnj.edu/~bush/uftp.html</ref> The protocol is designed in three phases: announce/register, file transfer, and completion/confirmation.<ref>“UFTP - Encrypted UDP based FTP with multicast”. http://www.tcnj.edu/~bush/uftp.html</ref> The latest version was released on 3/29/2011 and the source code is available in the website. To access the site for more info, see [http://www.tcnj.edu/~bush/uftp.html The College of New Jersey] article.<ref>“UFTP - Encrypted UDP based FTP with multicast”. http://www.tcnj.edu/~bush/uftp.html</ref>

===Current Alternatives===

Today, one alternative in multicast encryption involves the use of symmetric key encryption where data is decoded by intended receivers using a traffic encryption key (TEK). The TEK is changed any time a member joins or leaves the group. This is not feasible for large groups. Users must be continuously connected to obtain the new keys. Another more common method involves asymmetric keys. Here, a private key is shared and those shares are given out asymmetrically. The initial member is given a number of shares, one of which is passed to each group member. If a member has a valid share of the key, he can view the message.<ref>Duan, Yitao and John Canny. Computer Science Division, UC Berkeley. “How to Construct Multicast Cryptosystems Provably Secure Against Adaptive Chosen Ciphertext Attack”. http://www.cs.berkeley.edu/~jfc/papers/06/CT-RSA06.pdf</ref>

===References===

{{Reflist}}