WO2009003383A1 - Procédé de multidiffusion, dispositif de réseau et système de multidiffusion - Google Patents

Procédé de multidiffusion, dispositif de réseau et système de multidiffusion Download PDF

Info

Publication number
WO2009003383A1
WO2009003383A1 PCT/CN2008/071187 CN2008071187W WO2009003383A1 WO 2009003383 A1 WO2009003383 A1 WO 2009003383A1 CN 2008071187 W CN2008071187 W CN 2008071187W WO 2009003383 A1 WO2009003383 A1 WO 2009003383A1
Authority
WO
WIPO (PCT)
Prior art keywords
key
multicast
network device
sender
packet
Prior art date
Application number
PCT/CN2008/071187
Other languages
English (en)
French (fr)
Inventor
Elvis Wu
Original Assignee
Huawei Technologies Co., Ltd.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co., Ltd. filed Critical Huawei Technologies Co., Ltd.
Publication of WO2009003383A1 publication Critical patent/WO2009003383A1/zh

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0891—Revocation or update of secret information, e.g. encryption key update or rekeying
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1886—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast with traffic restrictions for efficiency improvement, e.g. involving subnets or subdomains
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H04L63/123—Applying verification of the received information received data contents, e.g. message integrity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/21—Monitoring or handling of messages
    • H04L51/212—Monitoring or handling of messages using filtering or selective blocking

Definitions

  • Multicast method Network device and multicast system
  • the present invention relates to the field of communications, and in particular, to a multicast method, a network device, and a multicast system. Background technique
  • multicast technology has become a key technology for broadband multimedia applications, and multicast packets are transmitted more and more in the network.
  • a valid unicast IP address Internet Protocol
  • IGMP Internet Group Management Protocol
  • the terminal in the network declares that it needs a multicast packet with a multicast address through the IGMP (Internet Group Management Protocol). If the network supports the multicast protocol, the multicast packet is received. The receiver will be reached through the path specified by the multicast protocol.
  • the method for sending a multicast packet by the multicast packet sender has the following problems: Any terminal can declare to the multicast network that it needs a multicast address of the multicast address through IGMP, even if the multicast group The owner does not want his multicast message to be received by an unauthorized terminal.
  • the MSEC Mul t icas t Security, Multicast Security
  • IETF The Interne t Eng ineering Task Force
  • a solution mainly for each Group members (including senders and receivers) joined to a specific group are authenticated to determine whether the group members have the right to join the group. If they have the right to join the group, create a multicast on the access device.
  • the tree sends a key to the group member through the GCKS (Group Control ler and Key Server). After that, all the multicast packets of the group sent by the sender are encrypted by the key.
  • the broadcast tree is sent to other recipients.
  • the above processing methods still have problems.
  • One is symmetric encryption, that is, the encryption party and the decryption party have the same key, and the encryption party uses the key to perform the forward direction. Encrypted, and the decrypting party uses this key for reverse decryption.
  • This encryption method is not too secure and cannot identify the identity of the encrypting party based on the key.
  • the other is asymmetric encryption, that is, the encryption party and the decryption party have different keys.
  • the key owned by the encryption party is called the public key
  • the key owned by the decryption party is called the private key
  • the encryption party is encrypted with the public key.
  • the decryption party decrypts with the private key.
  • the asymmetric encryption method is characterized by a large amount of computation and a slow operation speed.
  • the multicast message sender In order to prevent the multicast system from being attacked by malicious multicast packets, the multicast message sender must be strictly controlled and managed. Only the allowed multicast packet sender can send multicast packets to the multicast network. .
  • Today's multicast networks usually use ACLs (Access Control Lists) to limit the address range of multicast message senders, and thus control the multicast messages sent by multicast message senders.
  • the information in the ACL includes the correspondence between the multicast sender address and the multicast address.
  • ACLs are used to control the management of multicast packets.
  • ACLs are configured on the access layer routers and switches of the multicast network. Switches and routers support ACL rules and filter packets are not allowed to send multicasts to specific multicast addresses.
  • Multicast packet sent by the sender of the multicast packet The specific process is as follows: When the switch or the access layer router receives the multicast packet, it determines whether the sender address of the received multicast packet is within the range specified by the ACL according to the configured ACL. In the meantime, it means that the sender address of the multicast message is allowed to send the multicast message to the destination address of the multicast message, and the switch or the access layer router retrieves the multicast message to allow the multicast. The packet enters the multicast network and controls the sender of the multicast packet.
  • the ACL configured in the access layer router and switch of the multicast network is static.
  • the restriction on the multicast packet sender or multicast address needs to be changed, the content in the ACL needs to be changed.
  • the ACL content is inflexible and requires manual participation. This is not suitable for automatic real-time management of multicast packets by the multicast network. This results in high cost of multicast network management and maintenance, and manageability of multicast networks. Poorly operability.
  • the hash algorithm generates a MAC (Mes sage Authent ica t ion Code), and adds the message authentication code to the packet to be sent. As shown in FIG. 1 , it is encrypted in the prior art. Schematic diagram. When the communication party has only two parties, the two parties can realize the identification of the other party by comparing the MAC.
  • MAC Mobile sage Authent ica t ion Code
  • Authent ica t ion a time-based efficient stream packet authentication protocol that tolerates packet loss, mainly realizes the asymmetric function of the symmetric encryption algorithm through time-based asymmetric implementation, that is, the receiver does not Knowing the current key of the current time, it takes a while for the receiver to know the key of the current time period.
  • the method includes:
  • the sender defines the total length of time according to the multicast content that needs to be sent by itself, and then divides the total time length into k time intervals of length T, where k is a natural number;
  • the explicit delay refers to how long after the current key is advertised to the receiver. Generally, there are several time intervals of length T. We assume n, where n is Natural number;
  • the function of the one-way function is to know the key of the (k-1) time period through the one-way function f if the key KEY (k) of the kth time period is known.
  • Key KEY (kl) Similarly, when KEY (k-1) is calculated, KEY (k-2) can be calculated, so when the key KEY (k) of the kth time period is known, The key of all time periods before the kth time period can be calculated; another feature of the one-way function is that it is unidirectional, that is, the key KEY (k) of the kth time period is known, and cannot be calculated.
  • FIG. 2 is a schematic diagram of the encrypted message sent in the prior art, as shown in FIG. A message in the i-th time period, where Pi is a multicast message encrypted by the current time period key KEY (i), and KEY (in) is the key of the (in) time period,
  • the field is a multicast key advertised to the recipient for the (in) time period of the group, and the message authentication code MAC (K, (i)) is used to enable the receiver to source the message in the ith time period.
  • Information certification is used to enable the receiver to source the message in the ith time period.
  • KEY (i) If you know KEY (i), you can use the one-way function f to calculate all the keys before the ith time period. Therefore, the key KEY (i) is confidential and is not allowed to be obtained by other devices. Therefore, you need to KEY (i) protects, KEY (i) protects by unidirectionally converting key KEY (i) to K by defining a one-way function g, (i) but without K, (i) one-way Converted to KEY (i), the process is shown in Figure 3.
  • a receiver When a receiver joins a group, it will register with the sender. During the registration process, parameters such as the length of the parameter acquisition period, the one-way function one-way function 8, the explicit delay, etc., need to be negotiated, and the receiver and the sender are guaranteed. Synchronization in time.
  • the sender performs asymmetric encryption and authenticates the sender. That is to say, in the whole process, only this asymmetric encryption is performed, the sender's information is obtained, the sender's identity is authenticated, and the sender is sent. Based on the authentication, the first key KEY (0) in the entire key chain is obtained.
  • the receiver When the receiver receives the multicast message of the kth time period, because the receiver does not have the multicast key KEY (k) of the kth time period, the receiver sends the multicast report of the time period.
  • the message When the message is buffered, when the message of the k+nth time period is received, the key of the kth time period is extracted from the message of the k+nth time period, and then the original cached multicast can be obtained. The message is decrypted.
  • the inventor of the present invention finds in the process of the invention that: in the TESLA protocol, the receiver can discard the multicast packet sent by the sender who does not have the current key through the TESLA protocol; For example, a multicast router or an access router cannot detect whether the multicast packet is legal. Because the network device does not participate in the authentication process of the TESLA, the group must always be The broadcast message is sent to the receiver to detect whether the multicast message is legal. This may result in a large waste of network bandwidth. Summary of the invention
  • the embodiments of the present invention provide a multicast method, a network device, and a multicast system, which can effectively utilize network bandwidth resources.
  • An embodiment of the present invention provides a multicast method, including:
  • the network device obtains the key
  • the network device When the network device receives the multicast packet sent by the sender of the multicast packet, the network device authenticates whether the sender of the multicast packet is legal and whether the multicast packet is legal according to the key. The multicast message is forwarded, otherwise, the multicast message is discarded.
  • An embodiment of the present invention further provides a network device, including:
  • a registration management unit configured to register with a multicast message sender, and obtain a key from the multicast message sender
  • a packet processing unit configured to receive a multicast packet sent by the sender of the multicast packet, and perform legality on the sender of the multicast message and the law of the multicast message according to the key The authentication is performed. When both are valid, the multicast packet is forwarded to the receiver. Otherwise, the multicast packet is discarded.
  • An embodiment of the present invention further provides a multicast system, including:
  • the sender of the multicast packet sends a multicast packet and a key to the network device.
  • the network device receives the multicast packet from the sender of the multicast packet, and authenticates the sender of the multicast packet according to the key and whether the multicast packet is legal. When both are legal, the multicast packet is received. Send to the receiver, otherwise discard the multicast packet.
  • the embodiment of the invention further provides a network device, including:
  • the registration management unit registers with the group control key server GCKS to obtain a key from the GCKS; the message processing unit is configured to receive the multicast message sent by the multicast message sender, according to the key pair multicast
  • the legality of the sender of the packet and the legality of the multicast packet are authenticated. When both are legal.
  • the multicast packet is forwarded.
  • the embodiment of the invention further provides a multicast system, including:
  • a policy server a group control key server, a GCKS, a multicast message sender, and a network device,
  • the policy server is configured to send a key to the group control key server GCKS in response to the request of the group control key server GCKS.
  • the group control key server GCKS is configured to request a key from the policy server, and when receiving the registration request of the multicast sender and the registration request of the network device, the key is Sending to the multicast message sender and the network device;
  • the multicast message sender is configured to acquire the key from the group control key server GCKS, encrypt the multicast message by using the key, and send the encrypted multicast to the network device. a packet, the network device, obtaining the key from the group control key server GCKS, receiving the encrypted multicast message, and authenticating the multicast message sender according to the key And authenticating the validity of the encrypted multicast, and when the two are both legal, the encrypted multicast packet is forwarded, otherwise the encrypted multicast packet is discarded.
  • the network device obtains a key, uses a key to determine the legality of the multicast message sender, and determines the legality of the multicast packet sent by the network, as long as one of the two If the entry is invalid, the multicast file is discarded. In this way, for illegal multicast "3 ⁇ 4 texts, the network device will not forward again, thus avoiding a large waste of network bandwidth.
  • FIG. 1 is a schematic diagram of a packet sent by encryption in the prior art
  • FIG. 2 is a schematic diagram of a packet sent by encryption in the prior art
  • FIG. 3 is a schematic diagram of a key conversion process in the prior art
  • FIG. 5 is a schematic structural diagram of a network device according to an embodiment of the present invention.
  • FIG. 6 is a simplified schematic diagram of a multicast security architecture
  • FIG. 7 is a signaling flowchart of still another embodiment of the present invention. detailed description
  • the receiver in order to prevent the multicast message sent by an illegal sender from passing through the entire network and the receiver to discover that the multicast message is illegal, the receiver needs to be connected to the illegal sender.
  • the network device determines whether the multicast packet is legal.
  • Illegal senders and network devices can be connected directly or not directly. For example, if there are many Layer 2 devices between the illegal sender and the Layer 3 multicast router, the illegal sender and the Layer 3 group can be considered. Broadcast routers are directly connected at the third layer, such as belonging to the same subnet. In other words, the network needs to have the key in the TESLA protocol, and determine whether the multicast message sender is legal and whether the multicast message is legal according to the key.
  • the above illegal sender may be a legitimate receiver, but has no permission to send multicast messages.
  • FIG. 4 is a signaling flowchart in an embodiment of the present invention. As shown in FIG. 4, the process includes:
  • the pre-connected person will send a registration message (for example, IGMP (Internet Group Management Protoco l, Internet Group Management Protocol) ))))
  • IGMP Internet Group Management Protoco l, Internet Group Management Protocol
  • the network device here is usually a multicast router or a Layer 2 switch. If it is a Layer 2 switch, it may do IGMP snooping (Internet Group Management Protocol snooping). Forward the IGMP message.
  • the network device After receiving the IGMP message, the network device sends a multicast routing protocol join message to the aggregation point of the multicast tree, for example, PIM-SM.
  • the receiver registers with the sender to obtain information about the TESLA in order to receive the multicast message.
  • the network device needs to have the relevant information of the TESLA, so that the network device receives the group sent by the sender of the multicast message.
  • the network device When a message is broadcast, it can be determined whether the sender of the multicast packet is legal and whether the multicast packet is legal. If one of the packets is invalid, the multicast packet is discarded. Therefore, the network device also needs to register with the sender.
  • the parameter acquisition time length T, the one-way function one-way function g, the explicit delay, and the like need to be negotiated, and the network device and the sender are synchronized in time. .
  • the above two processes that is, the network device requests the key from the sender, and the sender performs asymmetric encryption to authenticate the sender.
  • the first key KEY (0) in the entire key chain is obtained based on the authentication of the sender.
  • the network device When the network device processes the multicast packet from the sender, it needs to know the key of each time period and determine whether the received multicast packet is a valid multicast packet based on the key.
  • the network device can learn the keys of each time period in various ways. For example, if the security of the network device can be completely guaranteed, the sender can directly send the KEY (k) to the network device in the first time period, directly to the network device.
  • the biggest advantage of sending KEY (k) is that it will no longer need to send a key to the network device every time interval of length T, because the network device can directly calculate the kth according to KEY (k) combined with the one-way function f. The key for any time period before the time period.
  • the sender sends KEY (i) to the network device during the ith time period (i values from 0 to k).
  • the sender sends in the i+n time period KEY (i) is given to the network device (i values from 0 to k).
  • the network device needs to buffer the multicast packets received during the ith time period. After n time intervals T The key corresponding to the multicast packet received in the ith time period can be obtained.
  • the processing of the multicast packet by the network device includes: when the network device receives the multicast packet sent by the sender, the MAC address of the multicast packet is sent, and the MAC address is used according to the key of the corresponding time segment of the multicast packet. (Media Acces s Control), if the MAC is legal, the multicast packet is forwarded to the receiver. If the MAC address is invalid, the network device discards the multicast packet.
  • FIG. 5 is a simplified schematic diagram of a network device in an embodiment of the present invention.
  • the network device includes a registration management unit and a text processing unit.
  • the registration management unit registers with the sender of the multicast message, and obtains the key from the sender of the multicast message; the message processing unit is configured to receive the multicast message sent by the sender of the multicast message, according to the secret.
  • the key authenticates the validity of the sender of the multicast packet and the validity of the multicast packet. When both are valid, the multicast packet is forwarded. Otherwise, the multicast packet is discarded.
  • the network device may further include a recipient authentication unit that receives the registration request sent by the pre-recipient and registers the pre-receiver as the recipient. If secure multicast is involved, it may be necessary to authenticate the registration request sent by the pre-receiver to determine whether the pre-receiver has the right to join the group. Therefore, in this case, the receiver authentication unit includes a rights authentication module that authenticates the registration request sent by the pre-receiver, and when the authentication is legal, registers the pre-receiver as the receiver.
  • the multicast system comprises:
  • the sender of the multicast packet sends a multicast packet and a key to the network device.
  • the network device receives the multicast packet from the sender of the multicast packet, and authenticates the sender of the multicast packet according to the key and whether the multicast packet is legal. When both are legal, the multicast packet is received. Hair Send to the receiver, otherwise discard the multicast packet.
  • Figure 6 is a simplified schematic diagram of a multicast security architecture.
  • the multicast key is distributed by GCKS, where 1-m represents one-to-many message transmission, and mm represents multi-point to multi-point message transmission.
  • Figure 7 is a signaling flow diagram in yet another embodiment of the present invention. As shown in Figure 7, the process includes:
  • the sender initiates registration with GCKS, and informs itself of relevant information, including time period length unidirectional function f, one-way function 8, explicit delay and other information, and ensures the sender and GCKS time synchronization.
  • the network device initiates registration with GCKS, and the network device is authenticated by GCKS to ensure the security of the network device.
  • the recipient initiates registration with GCKS, and the recipient is authenticated by GCKS to ensure the security of the recipient.
  • the GCKS queries the Policy Server (not shown in Figure 7) and sends the key to the sender based on the queried policy.
  • the GCKS queries the policy server (not shown in Figure 7) and sends a key to the network device based on the queried policy.
  • the GCKS queries the policy server (not shown in FIG. 7), and sends a key to the receiver according to the queried policy.
  • There are multiple schemes for the specific sending manner for example, if the current time is the ith time period, then the first sending Multicast key KEY (i) for i time periods. For another example, if the current time is the i+nth time period, the multicast key KEY(i) of the i-th time period is sent. Another example is to send according to the strategy from the beginning. KEY (k) , which is the key of the last time period. Of course, you can also use other methods to send the key. The numbering of the above steps is not intended to limit the order between these steps, and there is no necessary sequential relationship between these steps.
  • the multicast packet is encrypted by the key from the GCKS and then sent to the network device.
  • the network device uses the key from the GCKS to determine whether the sender is legal and whether the received multicast packet is received. Legitimate, if both are valid, the multicast packet is forwarded, otherwise the multicast packet is discarded.
  • the receiver After receiving the multicast packet forwarded by the network device, the receiver decrypts the packet by using the key from the GCKS.
  • the network device includes:
  • the registration management unit registers with the group control key server GCKS to obtain a key from the GCKS; the message processing unit is configured to receive the multicast message sent by the multicast message sender, and send the multicast message according to the key
  • the validity of the multicast and the legality of the multicast message are authenticated. When both are legal, the multicast packet is forwarded to the receiver. Otherwise, the multicast packet is discarded.
  • the multicast system includes a policy server, a group control key server GCKS, a multicast message sender, and a network device, wherein the group control key server GCKS requests a key from the policy server, and the policy The server response group controls the request of the key server GCKS, and issues a key to the group control key server GCKS.
  • the group control key server receives the registration request of the multicast message sender and the registration request of the network device, the GCKS sends the key to the multicast sender and the network device.
  • the multicast message sender encrypts and sends the multicast message to the network device by using the key.
  • the network device receives the multicast packet sent by the sender of the multicast packet, and authenticates the sender of the multicast packet according to the key and whether the multicast packet is legal. When both are legal, the multicast packet is forwarded. Otherwise, multicast packets are discarded.
  • the network device obtains a key, uses a key to determine the legality of the multicast message sender, and determines the legality of the multicast packet sent by the network, as long as one of the two If the entry is invalid, the multicast file is discarded. In this way, for illegal multicast "3 ⁇ 4 texts, the network device will not forward again, thereby avoiding a large waste of network bandwidth.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Description

组播方法、 网络设备及组播系统
技术领域
本发明涉及通信领域， 尤其涉及一种组播方法、 网络设备及组播系统。 背景技术
随着互联网中流媒体、 视频会议和视频点播等多媒体业务的发展， 组播 技术已成为宽带多媒体应用的关键技术， 组播报文在网络中的传输越来越多。 当前组播网络中， 一个合法的单播 IP ( Internet Protoco l,网际协议）地址 可以作为一个组播 文发送者， 以一个组播地址为目的地址向组播网络发送 组播报文。 同时网络中的终端通过 IGMP ( Interne t Group Management Protocol , 国际互联网组管理协议） 向组播网络声明其需要某个组播地址的 组播报文， 如果网络支持组播协议， 则组播报文会通过组播协议指定的路径 到达接收者。 上述组播报文发送者发送组播报文的方法， 存在以下问题： 任 何一个终端都可以通过 IGMP向组播网络声明其需要某个组播地址的组播才艮 文， 即使该组播组的所有者并不希望自己的组播报文被没有经过授权的终端 所接收。
为了解决上述问题, IETF ( The Interne t Eng ineer ing Task Force , 互 连网工程任务组） 的 MSEC ( Mul t icas t Secur i ty, 组播安全）工作组提出了 一种解决方法， 主要是对每个加入到某个特定组的组成员（包括发送者和接收 者）进行认证， 判定组成员是否具有加入到该组的权限， 如果具备加入到该组 的权限， 则在接入设备上创建组播树并通过 GCKS ( Group Control ler and Key Server , 组控制密钥服务器）给组成员下发一个密钥， 之后发送者发送的该 组的所有组播报文都是经过该密钥加密后通过组播树发送到其他的接收者 中。
但是上述处理方法仍然存在问题。 目前的加密技术存在两种。 一种是对 称加密， 也就是加密方和解密方拥有相同的密钥， 加密方用该密钥进行正向 加密， 而解密方用该密钥进行逆向解密。 这种加密方法安全性不是太高， 无 法根据密钥来识别加密方的身份。 另一种是非对称加密， 也就是加密方和解 密方拥有不同的密钥， 加密方拥有的密钥称之为公钥， 解密方拥有的密钥称 之为私钥， 加密方用公钥加密， 解密方用私钥解密。 非对称加密方法的特点 是运算量大， 运算速度慢。
为了使组播系统避免受到恶意组播报文的攻击， 需要对组播报文发送者 进行严格的控制管理， 只有被允许的组播报文发送者才可以向组播网络发送 组播报文。 现在的组播网络通常釆用 ACL ( Acce s s Cont ro l L i s t , 访问控制 列表）来限制组播报文发送者的地址范围， 进而控制组播报文发送者发送的 组播 文。 ACL中的信息包括组播 ^艮文发送者地址和组播地址的对应关系。 通 过 ACL来实现组播报文发送者的控制管理， 在组播网络的接入层路由器、 交换 机中配置 ACL , 交换机、 路由器支持 ACL规则并根据 ACL过滤掉不允许向特定组 播地址发送组播报文的组播报文发送者发来的组播报文。 具体过程为： 当交 换机或接入层路由器接收到组播报文时， 根据其配置的 ACL判断接收到的组播 报文的发送者地址是否在 ACL指定的范围内， 如果在 ACL指定的范围内， 则表 示允许组播 ^艮文的发送者地址向组播 ^艮文的目的地址发送组播 ^艮文， 交换机 或接入层路由器釆取对组播报文转发等方法允许该组播报文进入组播网络， 实现对组播报文发送者的控制。
但是， 上述方案中， 要在组播网络的接入层路由器、 交换机中配置的 ACL 是静态的， 当对组播报文发送者或组播地址的限制需要更改， 即对 ACL中的内 容需要更改时， 需要人为的修改各接入层路由器、 交换机中的 ACL。 ACL内容 变化不灵活， 需要人工参与， 这样一来就不适合组播网络对组播报文发送者 的自动实时管理， 致使组播网络管理和维护的成本高， 组播网络的可管理性 和可运营性差。
为了解决这个问题， 出现了一种修改对称加密算法的方法， 使之可以具 备非对称加密算法的优点， 可以进行发送者的鉴别同时又可以实现发送者的 自动识别， 防止不是发送者的终端发送组播 文。 该方法在 IETF的 RFC ( Reques t For Comment , 请求注解） 4082、 RFC4383、 RFC4442等标准进行了 阐述。 简单来说， 在对称加密方法中， 发送者和接收者共享一个对称密钥并 协商出相应的一段明文字段， 发送者和接收者都用该对称密钥和这段明文字 段通过原先协商好的哈希（hash)算法生成一个 MAC ( Mes sage Authent ica t ion Code , 消息认证码） ， 把该消息认证码添加到报文中发送， 如图 1所示， 是现 有技术中加密发送的 4艮文示意图。 通信方只有双方时， 双方通过比较 MAC即可 实现对对方的识别。
但是通过上面的阐述可以看出， 在组播环境下， 前面的对称加密算法并 不适用, 于是引入 TESLA ( Timed Eff i c ient Stream Los s-Tolerant
Authent ica t ion, 基于时间的高效的容忍丟包的流认证协议） ， 主要是通过 时间上的非对称实现对称加密算法在功能上的非对称进而实现算法的非对 称， 也就是说接收者不知道当前时间的当前密钥， 需要过一段时间之后， 接 收者才得以知道当前时间段的密钥。 该方法包括：
( 1 )发送者定义参数
发送者根据自身需要发送的组播内容定义出总的时间长度， 再把总的时 间长度划分成 k个长度为 T的时间间隔， 其中， k是自然数；
定义显密时延， 显密时延是指经过多长的时间以后把当前的密钥通告给 接收者， 一般来说是几个长度为 T的时间间隔， 我们假设为 n个， 其中 n是自然 数；
定义一个单向函数 f , 该单向函数的作用为如果知道第 k个时间段的密钥 KEY (k) ,那么通过单向函数 f ,可以计算出第（k-1 )个时间段的密钥 KEY (k-l) , 同样的， 当计算出 KEY (k-1)后， 就可以计算出 KEY (k-2) , 所以， 当知道第 k个 时间段的密钥 KEY (k)后， 就可以计算出第 k个时间段以前的所有时间段的密 钥； 单向函数的另一个特点是它是单向的， 也就是说知道第 k个时间段的密钥 KEY (k) , 无法计算出第 （k+1 )个时间段的密钥 KEY (k+l)。 当上述参数定义出来以后， 发送者就可以利用定义出来的密钥进行报文 的加密以及密钥的通告了， 图 2是现有技术中加密发送的报文示意图， 如图 2 所示， 是在第 i个时间段内的某个报文， 其中 Pi是经过当前时间段密钥 KEY (i) 加密的组播报文， KEY (i-n)是第（i-n)个时间段的密钥， 该字段是通告给接收 者第（i-n)个时间段该组的组播密钥， 消息认证码 MAC (K， (i) )用于使接收者 能够在第 i个时间段进行该报文的源信息认证。 如果知道 KEY (i)以后， 就可以 通过单向函数 f计算出第 i个时间段以前的所有密钥， 所以密钥 KEY (i)是机密 信息， 不允许被其他设备获得， 因此就需要对 KEY (i)进行保护， KEY (i)的保 护是通过定义单向函数 g ,把密钥 KEY (i)单向的转换为 K， （i) ,但是却无 K， (i) 单向的转换为 KEY (i) , 这一过程如图 3所示。
( 2 )接收者向发送者协商参数
当一个接收者加入到一个组后， 会到发送者进行注册， 注册过程中需要 协商参数获取时间段长度 Τ、 单向函数 单向函数8、 显密时延等信息， 并保 证接收者和发送者时间上的同步。 同时和发送者进行非对称加密， 对发送者 进行认证，也就是说， 在整个过程中， 只进行这一次的非对称加密， 获得发送 者的信息， 对发送者的身份进行认证， 在对发送者进行认证的基础上获得整 个密钥链中的第一个密钥 KEY (0)。
( 3 )接收者接收到组播报文的处理
当接收者接收到第 k个时间段的组播报文时， 因为此时接收者并没有第 k 个时间段的组播密钥 KEY (k) , 所以接收者把这个时间段的组播报文进行緩存， 当收到第 k+n个时间段的报文时， 从第 k+n个时间段的报文中提取出第 k个时间 段的密钥后， 才能对原先緩存的组播报文进行解密。
然而， 本发明的发明人， 在发明过程中发现： TESLA协议中， 虽然接收者 通过 TESLA协议对于不具备当前密钥的发送者所发送的组播报文， 可以进行丟 弃； 但是网络设备， 例如组播路由器、 接入路由器等却无法察觉该组播报文 是否合法， 因为网络设备没有参与到 TESLA的认证过程中， 所以， 一直要把组 播报文发送到接收者处才能察觉该组播报文是否合法， 这样就可能造成网络 带宽的大量浪费。 发明内容
基于上述分析， 本发明实施例提供组播方法、 网络设备及组播系统， 能 够有效利用网络带宽资源。
本发明的实施例提供一种组播方法， 包括：
网络设备获取密钥；
网络设备接收到组播报文发送者发来的组播报文时， 根据所述密钥认证 所述组播报文发送者是否合法及所述组播报文是否合法， 当二者均合法时， 转发所述组播 文， 否则， 丟弃所述组播 文。
本发明的实施例还提供了一种网络设备， 包括：
注册管理单元， 用于向组播报文发送者进行注册， 从所述组播报文发送 者获取密钥；
报文处理单元， 用于接收所述组播报文发送者发来的组播报文， 根据所 述密钥对所述组播 ^文发送者的合法性和所述组播 ^文的合法性进行认证， 当二者均合法时， 转发所述组播报文到接收者， 否则， 丟弃所述组播报文。
本发明的实施例还提供了一种组播系统， 包括：
组播报文发送者， 向网络设备发送组播报文和密钥；
网络设备， 接收组播报文发送者发来的组播报文， 根据密钥认证组播报 文发送者是否合法以及组播报文是否合法， 当二者均合法时， 将组播报文发 送给接收者， 否则丟弃组播报文。
本发明的实施例又提供了一种网络设备， 包括：
注册管理单元， 向组控制密钥服务器 GCKS进行注册， 从 GCKS获取密钥； 报文处理单元， 用于接收组播报文发送者发来的组播报文， 根据所述密 钥对组播报文发送者的合法性和组播报文的合法性进行认证， 当二者均合法 时， 转发所述组播报文。
本发明的实施例又提供了一种组播系统， 包括：
策略服务器、 组控制密钥服务器 GCKS、 组播报文发送者和网络设备， 其 中，
所述策略服务器， 用于响应所述组控制密钥服务器 GCKS的请求， 下发密 钥给所述组控制密钥服务器 GCKS。
所述组控制密钥服务器 GCKS , 用于向所述策略服务器请求密钥， 接收到 所述组播 ^艮文发送者的注册请求和所述网络设备的注册请求时， 将所述密钥 下发给所述组播报文发送者和所述网络设备；
所述组播报文发送者， 用于从所述组控制密钥服务器 GCKS获取所述密钥， 利用所述密钥对组播报文进行加密， 向所述网络设备发送加密后的组播报文； 所述网络设备， 从所述组控制密钥服务器 GCKS获取所述密钥， 接收所述 加密后的组播报文， 根据所述密钥对所述组播报文发送者的合法性和所述加 密后的组播 的合法性进行认证， 当二者均合法时， 转发所述加密后的组 播报文， 否则丟弃所述加密后的组播报文。
在本发明的实施例中， 网络设备获取密钥， 利用密钥对组播报文发送者 的合法性进行判断， 并对其发送的组播报文的合法性进行判断， 只要二者中 有一项不合法， 则丟弃组播 文。 这样一来， 对于非法的组播"¾文， 网络设 备不会再进行转发， 从而能够避免对网络带宽的大量浪费。
附图说明
图 1为现有技术中加密发送的报文示意图；
图 2为现有技术中加密发送的报文示意图；
图 3为现有技术中密钥转换过程示意图；
图 4为本发明的一个实施例中的信令流程图；
图 5为本发明的一个实施例中的网络设备的简化结构示意图；
图 6为组播安全架构的简化示意图； 图 7为本发明的又一实施例中的信令流程图。 具体实施方式
下面结合附图对本发明的实施例进行详细说明。
在本发明的实施例中， 为了避免当一个非法的发送者发送的组播报文经 过整个网络， 到达接收者时才让接收者发现该组播报文非法， 就需要在与非 法发送者相连的网络设备上判断组播报文是否合法。 非法发送者与网络设备 可以直接相连， 也可以不直接相连， 举例来说， 非法发送者和三层组播路由 器之间很可能存在多个二层设备， 那么可以认为非法发送者和三层组播路由 器在三层是直接相连的，比如属于同一个子网。换句话说，网络需要具有 TESLA 协议中的密钥， 根据密钥在网络设备上判断组播报文发送者是否合法以及组 播报文是否合法。 当然， 上述非法的发送者可能是一个合法的接收者， 只是 没有发送组播报文的权限。
图 4是本发明的一个实施例中的信令流程图， 如图 4所示， 该过程包括：
0. IGMP注册；
1.组播树建立；
上述两个过程， 也就是说， 当一个预接收者想加入到一个组播组时， 该 预接^：者会发送注册才艮文 (例 ^IGMP ( Internet Group Management Protoco l , Internet组管理协议）报文）到与之连接的网络设备上， 这里的网络设备一 般是组播路由器， 也可以是二层交换机， 如果是二层交换机则可能会做 IGMP snooping (互联网组管理协议窥探）后再转发该 IGMP报文。 网络设备收到 IGMP 报文后， 向组播树的汇聚点发送组播路由协议加入报文， 例如 PIM-SM
( Protoco l Independent Mul t ica s t-Sparse Mode , 稀疏模式协议无关组播) 加入报文， 进而建立起组播树。 如果涉及到安全组播， 可能在发送组播路由 协议加入报文之前需要先对该 I GMP报文进行认证， 判断该预接收者是否具备 加入到该组的权限， 如果不具备加入到该组的权限， 则不发送组播路由协议 加入 ^艮文； 如果具备加入到该组的权限， 则发送组播路由协议加入 文建立 起组播树， 该预接收者加入组后则成为接收者。
接收者向发送者注册， 获得 TESLA的相关信息以便接收组播报文。
2. TESLA注册；
3. 注册成功；
上述两个过程， 也就是说， 为了防止发送组播报文的一方是非法发送者， 就需要网络设备也拥有 TESLA的相关信息， 使网络设备在接收到组播报文发送 者发来的组播报文时就可以判断组播报文发送者是否合法以及该组播报文是 否合法， 只要有一者不合法则丟弃该组播报文。 所以， 网络设备也要向发送 者进行注册， 注册过程中需要协商参数获取时间段长度 T、 单向函数 单向 函数 g、 显密时延等信息， 并保证网络设备和发送者时间上的同步。
4.请求密钥；
5.通告当前密钥；
上述两个过程， 也就是说， 网络设备向发送者请求密钥， 和发送者进行 非对称加密， 对发送者进行认证。 在对发送者进行认证的基础上获得整个密 钥链中第一个密钥 KEY (0)。 也可以釆用其他方案来获取 KEY (0) , 譬如， 因为 网络设备可能属于运营商设备， 安全系数较高， 所以不釆用非对称密钥进行 加密而直接获取 KEY (0) 。
网络设备处理来自发送者的组播报文时， 需要获知各个时间段的密钥并 根据这些密钥来判断收到的组播报文是否是合法的组播报文。 网络设备获知 各个时间段的密钥的方式多种多样， 譬如， 如果网络设备的安全能够完全保 证， 那么发送者可以在第一个时间段直接发送 KEY (k)给网络设备， 直接向网 络设备发送 KEY (k)的最大好处是， 后续将不再需要每隔长度为 T的时间间隔向 网络设备发送一个密钥， 因为网络设备可以根据 KEY (k)结合单向函数 f直接算 出第 k个时间段之前任何时间段的密钥。 又如， 发送者在第 i个时间段发送 KEY (i)给网络设备（i的取值从 0到 k)。 再如， 发送者在第 i+n个时间段发送 KEY (i)给网络设备（ i的取值从 0到 k ) , 在这种情况下， 网络设备需要对第 i 个时间段接收到的组播报文进行緩存， 经过 n个时间间隔 T后才能获知到第 i个 时间段接收到的组播报文所对应的密钥。
网络设备对组播报文的处理包括： 当网络设备收到发送者发来的组播报 文时， 提出组播报文的 MAC字段， 根据该组播报文对应时间段的密钥进行 MAC ( Media Acces s Control , 媒体访问控制） 的校验， 如果 MAC合法， 则将该组 播报文转发给接收者， 如果 MAC不合法， 则网络设备丟弃该组播报文。
本领域普通技术人员可以理解实现上述实施例方法中的全部或部分步 骤， 是可以通过程序指令相关硬件完成的。 实施例对应的软件可以存储在一 个计算机可存储读取的介质中， 如 R0M/RAM、 磁碟、 光盘等。
图 5是本发明的一个实施例中网络设备的简化结构示意图。 如图 5所示， 该网络设备包括注册管理单元和 文处理单元。 注册管理单元向组播 ^艮文发 送者进行注册， 从该组播报文发送者获取密钥； 报文处理单元用于接收组播 报文发送者发来的组播报文， 根据该密钥对组播报文发送者的合法性和组播 报文的合法性进行认证， 当二者均合法时， 转发组播报文； 否则， 丟弃组播 报文。
在本发明的又一实施例中， 网络设备还可以包括接收者认证单元， 接收 预接收者发来的注册请求， 将该预接收者注册为接收者。 如果涉及安全组播， 可能需要对预接收者发来的注册请求进行认证， 判断该预接收者是否具备加 入到该组的权限。 所以， 在这种情况下， 接收者认证单元中则包括权限认证 模块， 对预接收者发来的注册请求进行认证， 当认证合法时， 将该预接收者 注册为接收者。
在本发明的一个实施例中， 组播系统包括：
组播报文发送者， 向网络设备发送组播报文和密钥；
网络设备， 接收组播报文发送者发来的组播报文， 根据密钥认证组播报 文发送者是否合法以及组播报文是否合法， 当二者均合法时， 将组播报文发 送给接收者， 否则丟弃组播报文。
图 6是组播安全架构的简化示意图。 目前在 MSEC工作组中已有定义， 其中 的组播密钥都是通过 GCKS来分发的， 其中， 1-m表示一点到多点的报文传输， m-m表示多点到多点的报文传输。 结合图 6所示的安全组播架构， 图 7是本发明 的又一实施例中的信令流程图。 如图 7所示， 该过程包括：
1.发送者向 GCKS发起注册， 告知自身的相关信息， 包括时间段长度 单 向函数 f、 单向函数8、 显密时延等信息， 并保证发送者和 GCKS时间上的同步。
2.网络设备向 GCKS发起注册， 由 GCKS对网络设备进行认证， 保证网络设 备的安全性。
3.接收者向 GCKS发起注册， 由 GCKS对接收者进行认证， 保证接收者的安 全性。
4. GCKS向策略服务器（图 7中未示出）进行查询， 根据查询到的策略向发 送者发送密钥。 具体发送方式存在多种方案， 譬如， 如果当前时间为第 i个时 间段， 则发送第 i个时间段的组播密钥 KEY (i)。 又如， 当前时间为第 i+n个时 间段， 则发送第 i个时间段的组播密钥 KEY (i)。 再如， 一开始就根据策略发送 KEY (k) , 即最后一个时间段的密钥。 当然， 也可以釆用其他方式来发送密钥。
5. GCKS向策略服务器（图 7中未示出）进行查询， 根据查询到的策略向 网络设备发送密钥。 具体发送方式存在多种方案， 譬如， 如果当前时间为第 i 个时间段， 则发送第 i个时间段的组播密钥 KEY (i)。 又如， 当前时间为第 i+n 个时间段， 则发送第 i个时间段的组播密钥 KEY (i)。 再如， 一开始就根据策略 发送 KEY (k) , 即最后一个时间段的密钥。 当然， 也可以釆用其他方式来发送 密钥。
6. GCKS向策略服务器（图 7中未表示）进行查询， 根据查询的策略向接收 者发送密钥， 具体发送方式存在多种方案， 譬如， 如果当前时间为第 i个时间 段， 则发送第 i个时间段的组播密钥 KEY (i)。 又如， 当前时间为第 i+n个时间 段， 则发送第 i个时间段的组播密钥 KEY (i)。 再如， 一开始就根据策略发送 KEY (k) , 即最后一个时间段的密钥。 当然， 也可以釆用其他方式来发送密钥。 上述步骤的编号并不用于限定这些步骤之间的先后顺序， 这些步骤之间 并不存在必然的先后关系。
发送者发送报文时， 利用来自 GCKS的密钥对组播报文进行加密， 然后发 送给网络设备， 网络设备利用来自 GCKS的密钥判断发送者是否合法， 以及收 到的组播报文是否合法， 如果二者均合法， 则转发组播报文， 否则丟弃组播 报文。 接收者接收到网络设备转发来的组播报文后， 利用来自 GCKS的密钥对 报文进行解密。
在本发明的又一个实施例中， 网络设备包括：
注册管理单元， 向组控制密钥服务器 GCKS进行注册， 从 GCKS获取密钥； 报文处理单元， 用于接收组播报文发送者发来的组播报文， 根据密钥对 组播 文发送者的合法性和组播 "^文的合法性进行认证， 当二者均合法时， 转发组播报文给接收者， 否则丟弃组播报文。
在本发明的又一个实施例中， 组播系统包括策略服务器、 组控制密钥服 务器 GCKS、 组播报文发送者和网络设备， 其中， 组控制密钥服务器 GCKS向策 略服务器请求密钥， 策略服务器响应组控制密钥服务器 GCKS的请求， 下发密 钥给组控制密钥服务器 GCKS。 组控制密钥服务器 GCKS接收到组播报文发送者 的注册请求和网络设备的注册请求时， 将密钥下发给组播 文发送者和网络 设备。 组播报文发送者利用密钥向所述网络设备加密发送组播报文。 网络设 备接收组播报文发送者发来的组播报文， 根据密钥认证组播报文发送者是否 合法以及组播报文是否合法， 当二者均合法时， 转发组播报文， 否则丟弃组 播报文。
在本发明的实施例中， 网络设备获取密钥， 利用密钥对组播报文发送者 的合法性进行判断， 并对其发送的组播报文的合法性进行判断， 只要二者中 有一项不合法， 则丟弃组播 文。 这样一来， 对于非法的组播"¾文， 网络设 备不会再进行转发， 从而能够避免对网络带宽的大量浪费。 以上所述， 仅为本发明较佳的具体实施方式， 但本发明的保护范围并不 局限于此， 任何熟悉该技术的人在本发明所揭露的技术范围内， 可轻易想到 的变化或替换， 都应涵盖在本发明的保护范围之内。

Claims

权 利 要求 书
1、 一种组播方法， 其特征在于， 包括：
网络设备获取密钥；
网络设备接收到组播报文发送者发来的组播报文时， 根据所述密钥认证所 述组播报文发送者是否合法及所述组播报文是否合法， 当二者均合法时， 转发 所述组播 ^文， 否则， 丟弃所述组播 4艮文。
2、 如权利要求 1所述的组播方法， 其特征在于， 所述网络设备获取密钥， 包括：
所述网络设备向所述组播报文发送者注册， 从所述组播报文发送者获取所 述密钥。
3、 如权利要求 2所述的组播方法， 其特征在于， 所述从所述组播报文发送 者获取所述密钥， 包括：
在第 i个时间段获取密钥 KEY (i) , 或者，
在第 i+n个时间段获取密钥 KEY (i) , 或者，
在第一个时间段获取密钥 KEY (k) , 其中， i是从 0到 k的非负整数， n是自 然数， k是自然数。
4、 如权利要求 1所述的组播方法， 其特征在于， 所述网络设备获取密钥， 包括：
所述网络设备向组控制密钥服务器注册， 从所述组控制密钥服务器获取所 述密钥。
5、 如权利要求 4所述的组播方法， 其特征在于， 所述组播报文发送者发来 的组播报文经过加密密钥加密， 所述加密密钥来自所述组控制密钥服务器。
6、 如权利要求 4或 5所述的组播方法， 其特征在于， 所述从所述组控制密 钥服务器获取密钥， 包括：
在第 i个时间段获取密钥 KEY (i) , 或者，
在第 i+n个时间段获取密钥 KEY (i) , 或者， 在第一个时间段获取密钥 KEY (k) , 其中， i是从 0到 k的非负整数， n是自 然数， k是自然数。
7、 一种网络设备， 其特征在于， 包括：
注册管理单元， 用于向组播报文发送者进行注册， 从所述组播报文发送者 获取密钥；
报文处理单元， 用于接收所述组播报文发送者发来的组播报文， 根据所述 密钥对所述组播报文发送者的合法性和所述组播报文的合法性进行认证， 当二 者均合法时， 转发所述组播报文到接收者， 否则， 丟弃所述组播报文。
8、 如权利要求 7所述的网络设备， 其特征在于， 所述网络设备还包括： 接收者认证单元： 用于接收预接收者发来的注册请求， 将该预接收者注册 为所述接收者。
9、 如权利要求 8所述的网络设备， 其特征在在于， 所述接收者认证单元包 括：
权限认证模块， 用于对所述预接收者发来的注册请求进行认证， 当认证合 法时， 将所述预接收者注册为接收者。
10、 一种组播系统， 其特征在于， 包括：
组播报文发送者， 向网络设备发送组播报文和密钥；
网络设备， 接收组播报文发送者发来的组播报文， 根据密钥认证组播报文 发送者是否合法以及组播报文是否合法， 当二者均合法时， 将组播报文发送给 接收者， 否则丟弃组播报文。
11、 一种网络设备， 其特征在于， 包括：
注册管理单元， 向组控制密钥服务器 GCKS进行注册， 从 GCKS获取密钥； 报文处理单元， 用于接收组播报文发送者发来的组播报文， 根据所述密钥 对组播报文发送者的合法性和组播报文的合法性进行认证， 当二者均合法时， 转发所述组播 文。
12、一种组播系统，其特征在于，包括策略服务器、组控制密钥服务器 GCKS、 组播报文发送者和网络设备， 其中，
所述策略服务器， 用于响应所述组控制密钥服务器 GCKS的请求， 下发密钥 给所述组控制密钥服务器 GCKS。
所述组控制密钥服务器 GCKS , 用于向所述策略服务器请求密钥， 接收到所 述组播报文发送者的注册请求和所述网络设备的注册请求时， 将所述密钥下发 给所述组播报文发送者和所述网络设备；
所述组播报文发送者， 用于从所述组控制密钥服务器 GCKS获取所述密钥， 利用所述密钥对组播报文进行加密， 向所述网络设备发送加密后的组播报文； 所述网络设备， 从所述组控制密钥服务器 GCKS获取所述密钥， 接收所述加 密后的组播报文， 根据所述密钥对所述组播报文发送者的合法性和所述加密后 的组播报文的合法性进行认证， 当二者均合法时， 转发所述加密后的组播报文， 否则丟弃所述加密后的组播报文。
PCT/CN2008/071187 2007-06-30 2008-06-04 Procédé de multidiffusion, dispositif de réseau et système de multidiffusion WO2009003383A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CNA2007100763101A CN101106470A (zh) 2007-06-30 2007-06-30 一种组播方法、网络设备及系统
CN200710076310.1 2007-06-30

Publications (1)

Publication Number Publication Date
WO2009003383A1 true WO2009003383A1 (fr) 2009-01-08

Family

ID=39000173

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2008/071187 WO2009003383A1 (fr) 2007-06-30 2008-06-04 Procédé de multidiffusion, dispositif de réseau et système de multidiffusion

Country Status (2)

Country Link
CN (1) CN101106470A (zh)
WO (1) WO2009003383A1 (zh)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101106470A (zh) * 2007-06-30 2008-01-16 华为技术有限公司 一种组播方法、网络设备及系统
KR102281019B1 (ko) 2014-09-18 2021-07-26 삼성전자주식회사 전자 장치 및 전자 장치에서 데이터를 처리하는 방법
CN104486082B (zh) * 2014-12-15 2018-07-31 中电长城网际系统应用有限公司 认证方法和路由器
CN107528781A (zh) * 2016-06-22 2017-12-29 中兴通讯股份有限公司 组播报文的转发方法及装置、路由器
CN111917534B (zh) * 2020-06-17 2023-12-15 深圳市风云实业有限公司 一种在报文中嵌入密文策略的组播数据传输方法

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1395388A (zh) * 2001-07-09 2003-02-05 深圳市中兴通讯股份有限公司 一种对组播业务进行认证的方法
CN1571335A (zh) * 2004-04-30 2005-01-26 北京航空航天大学 一种应用于组播通信系统中的源认证方法
CN1801711A (zh) * 2006-01-18 2006-07-12 杭州华为三康技术有限公司 一种组播组成员认证方法和装置
EP1681826A1 (en) * 2005-01-12 2006-07-19 Abb Research Ltd. Method of authenticating multicast messages
CN101106470A (zh) * 2007-06-30 2008-01-16 华为技术有限公司 一种组播方法、网络设备及系统

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1395388A (zh) * 2001-07-09 2003-02-05 深圳市中兴通讯股份有限公司 一种对组播业务进行认证的方法
CN1571335A (zh) * 2004-04-30 2005-01-26 北京航空航天大学 一种应用于组播通信系统中的源认证方法
EP1681826A1 (en) * 2005-01-12 2006-07-19 Abb Research Ltd. Method of authenticating multicast messages
CN1801711A (zh) * 2006-01-18 2006-07-12 杭州华为三康技术有限公司 一种组播组成员认证方法和装置
CN101106470A (zh) * 2007-06-30 2008-01-16 华为技术有限公司 一种组播方法、网络设备及系统

Also Published As

Publication number Publication date
CN101106470A (zh) 2008-01-16

Similar Documents

Publication Publication Date Title
Ballardie Scalable multicast key distribution
US6963573B1 (en) System, device, and method for receiver access control in a multicast communication system
US7360084B1 (en) System, device, and method for controlling access in a multicast communication network
US8458462B1 (en) Verifying integrity of network devices for secure multicast communications
US7301946B2 (en) System and method for grouping multiple VLANs into a single 802.11 IP multicast domain
US11770707B2 (en) Lattice mesh
JP2001265729A (ja) マルチキャストシステム、認証サーバ端末、マルチキャスト受信者端末管理方法、並びに記録媒体
KR101495070B1 (ko) Ｐｔｐ프로토콜을 위한 키들을 분배하기 위한 방법들 및 장치들
WO2009021428A1 (fr) Dispositif de protection sécurisé et procédé permettant le transfert de messages
WO2011075976A1 (zh) 用户终端之间安全连接的建立方法及系统
WO2009036685A1 (fr) Procédé et appareil pour implémenter une authentification de multidiffusion
US10375051B2 (en) Stateless server-based encryption associated with a distribution list
WO2008098506A1 (fr) Procédé, système et dispositif de multidiffusion
WO2009003383A1 (fr) Procédé de multidiffusion, dispositif de réseau et système de multidiffusion
Liyanage et al. Secure hierarchical virtual private LAN services for provider provisioned networks
US8230010B1 (en) System, device, and method for controlling access in a multicast communication network
Park et al. Survey for secure IoT group communication
Mukherjee et al. Scalable solutions for secure group communications
Heimgaertner et al. A security architecture for the publish/subscribe C-DAX middleware
JP2004242210A (ja) マルチキャスト配信システム及びその方法並びにデータ中継装置、クライアント装置、認証・鍵管理装置
KR100660385B1 (ko) 오버레이 멀티캐스트 보안을 위한 구간별 키 관리 방법
Pinto et al. On performance of group key distribution techniques when applied to IPTV services
JP2002368751A (ja) マルチキャスト通信システム
Kirstein et al. Secure multicast conferencing
Pinto et al. Multicast deflector: Secure video distribution system

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 08757598

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 08757598

Country of ref document: EP

Kind code of ref document: A1