Multicast encryption

Multicast is what enables a node on a network to address one unit of data to a specific group of receivers.[1] In interactive multicast at the 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 multiple copies are created and then sent to the desired recipient by the network infrastructure nodes.[1] In for example IP multicast, a multicast group is identified by a class D IP address. A host enters or exits a group using IGMP (Internet Group Management Protocol).[2] A message sent via multicast is sent to all nodes on the network, but only the intended nodes accept the multicast frames.[3] Multicasting is useful in situations such as video conferencing and online gaming.[1] Multicast was used originally in LANs, with Ethernet being the best example.[3] A problem with multicast communication is that it is difficult to guarantee that only designated receivers receive the data being sent. This is largely because multicast groups are always changing; users come and go at any time. A solution to the problem of ensuring that only the chosen recipient obtains the data is known as multicast encryption.[1]

ISO Standards

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.[3]

  • Confidentiality: No unauthorized 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.[3]

To be secure, members who are just being added to the group must be restricted from viewing past data. Also, members removed from a group may not access future data.[4]

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.[1] Another theory suggests a primary key subsidized by additional keys belonging to legitimate group members.[1] One protocol called UFTP (encrypted UDP based FTP over multicast) was created in an attempt to solve this problem. The protocol is designed in three phases: announce/register, file transfer, and completion/confirmation. The latest version 4.9.5 was released on 12/16/2017 and the source code is available in the website.[5]

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.[2]

gollark: Also simpler, since you would avoid having to have weird interfaces between the `runsvdir` and `runsv`s.
gollark: I feel like it would be more efficient to move that into one process which can then do dependency management and stuff.
gollark: `runsvdir` has one `runsv` process *per service*? Huh.
gollark: You could avoid having to maintain some kind of weird local-specific API for them, conveniently manage stuff on remote systems if you wanted to for whatever reason, and... okay that's about it.
gollark: > <@258639553357676545> yeah, but that should be separate from the service manage<@!309787486278909952> But you could make the `sv`/`systemctl` equivalent tools use that! It would be mildly convenient!

See also

References
  1. Micciancio, Daniele and Saurabh Panjwani. “Multicast Encryption: How to maintain secrecy in large, dynamic groups?”
  2. Duan, Yitao and John Canny. Computer Science Division, UC Berkeley. “How to Construct Multicast Cryptosystems Provably Secure Against Adaptive Chosen Ciphertext Attack”.
  3. Pessi, Pekka. Department of Computer Science, Helsinki University Of Technology. “Secure Multicast”.
  4. Pannetrat, Alain and Refik Molva. “Multiple Layer Encryption for Multicast Groups”.
  5. “UFTP – Encrypted UDP based FTP with multicast”
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.