System, method and computer program product for detecting a rogue member in a multicast group

Technical field of system, method and computer program product for detecting fraudulent members in multicast group

[0001] The present invention generally relates to a system and method for providing multicast security, and more specifically, to a system and method for providing data source authentication in multicast security.

Background technique

[0002] Because multimedia streaming is intended to replace well-known TV applications such as video-on-demand, pay-per-view or video broadcasting, it is considered to be the main Internet application for development. Currently, many portal sites provide Internet Protocol (IP) multicast services, which will be expanded to deliver such services to wireless terminals. Using this service, the wireless system broadcasts data packets to multiple wireless terminals. Each wireless terminal receives and processes the same packet stream. An example of a multicast service is IP multicast streaming in audio and video formats for news and entertainment content. In other service types, multiple sources broadcast data packets to multiple wireless terminals. An example of such a service is a multi-party multimedia conference, whereby during the conference session, multiple wireless terminals broadcast data packets to each other. It can be understood that multicast communication is typically more spectrally efficient than unicast communication because multicast communication services can be broadcast to a group of wireless terminals. Because the frequency spectrum used for wireless services is very limited and expensive to expand, the use of multicast services is very attractive to wireless service providers.

[0003] As the use of multicast communication has increased, the provision of security for such communication has also increased. Generally, multicast security has many goals, including, for example, protecting multicast communications (ie, encryption) for the multicast group, integrity protection, and providing automatic exchange and management of key materials for the multicast group. In addition, multicast security usually attempts to deploy one or more security policies for multicast communications in a multicast group.

[0004] Generally, in addition to protecting the multicast communication of the multicast group, multicast security typically also wants to provide data source authentication. It can be understood that in the case of point-to-point communication, the data source is usually automatically authenticated. Especially in the case of such peer-to-peer communication is symmetric key protection, because only the source and destination possess the symmetric keys needed to decrypt and/or authenticate the transferred content. In contrast, in many conventional multicast security technologies, all members of a multicast group possess a symmetric key shared by the group members. In this case, the data source can typically only be identified as a member of the multicast group, and cannot identify specific group members.

[0005] A conventional technique for authenticating data sources in multicast communication is to digitally sign each data packet transmitted from the source to the members of the multicast group. Digital signatures provide non-repudiation over data source authentication and integrity protection . However, digital signatures also typically use public key cryptography, which is significantly slower to implement than the message authentication code (MAC) of symmetric key cryptography. Digital signatures usually require more data space overhead than MAC.

[0006] In order to reduce the overhead associated with digital signatures, a technology for amortizing digital signatures among multiple packets has been developed. Examples of this technique are: star/hash technique, and different variants of hash chain. Although this sharing technique does reduce the overhead associated with digital signatures, this technique also typically increases communication costs, and usually requires the source and destination to buffer data. In addition, various technologies such as those provided by the Timed Efficient Flow Loss Tolerant Authentication (TESLA) protocol and its variants require a form of time synchronization between the source and the destination, making the source authentication process more complicated.

[0007] A recently developed technology was filed on June 14, 2004 by US Patent Application No. 10/867, 150 entitled "System, Method and Computer Program Product for Authenticating a DataSource in Multicast Communications", which The content is incorporated here by reference in its entirety.

CN 101124770 Β

According to this recently developed technology, a multicast group includes a source member of a multicast data packet and a plurality of destination members receiving the data packet, wherein each member of the multicast group is associated with a symmetric key, and the secret The key is known to every other member in the multicast group.

[0008] In operation, the source member can use the symmetric key associated with the source member to generate a code for the data packet, and then multicast the data packet and the code. Then, each of the destination members can receive data packets and codes. When the destination member determines that the source member claims the identity of the corresponding destination member (that is, pretending to be the identity of the corresponding destination member), the destination member can multicast the secondary call group to the members of the multicast group, The source member in this case operates as a fraudulent member of the multicast group. In addition, the destination member can authenticate the source member based on the code.

[0009] For example, 150 application of the disclosed technology of authenticating a source in multicast communication overcomes the shortcomings of the other technologies mentioned above. In this regard, in point-to-multipoint multicast communication, the technology applied by the '150 allows the destination member to authenticate the source member without the need for digital signatures or time synchronization between the source and the destination. However, those skilled in the art will easily understand and generally expect to further improve on the existing technology (including the technology applied in '150).

Summary of the invention

[0010] Inspired by the foregoing background, embodiments of the present invention provide a further improved system, method, and computer program product for multicasting data packets and authenticating the source of the data packets. According to an embodiment of the present invention, in a multicast group, the destination member can authenticate the source member of the multicast communication, for example, according to the technology applied in '150. In addition, further according to the embodiment of the present invention, in the multicast communication, another fraudulent member who claims to be a member of the group can be identified. By identifying a fraudulent member, the fraudulent member can be isolated or removed from the multicast group to prevent the fraudulent member from continuing to impersonate another multicast group member.

[0011] According to an aspect of the present invention, a system for multicasting data packets in a multicast group is provided. The system includes: a network entity, such as a group controller/key server (GCKS), and multiple members of the multicast group. At least one member can notify the network entity that a member of the group is operating as a fraudulent member claiming the identity of another member in the group, and the other member is a counterfeit member. In response to being notified, the network entity may distribute different versions of the symmetric key related to the impersonated member to at least members of the group other than the impersonated member. Moreover, the network entity may be arranged to distribute all different versions of the symmetric key related to the impersonated member to the impersonated member.

[0012] After the network entity distributes the symmetric key set, the member who informs the network entity that the fraudulent member can receive the next data packet and the code for the next data packet, the code has been used at the fraudulent member A symmetric key version related to the impersonated member is generated. By distributing different versions of the symmetric key to different members of the multicast group, fraudulent members can be identified based on the symmetric key version, for example by the members of the group and/or the network entity. The network entity can then exclude the fraudulent member from the multicast group after identifying the fraudulent member.

[0013] More specifically, the member who notifies the fraudulent member to the network entity can receive the data packet and determine whether the received data packet is multicast from a group member operating as a fraudulent member. For example, the corresponding member can receive a content packet including a data packet, a code for the data packet, and a member identifier. The corresponding member can then determine whether the received data packet is multicast from a fraudulent member by comparing the member identifier in the content group with the member identifier associated with the member receiving the content group. In this case, when the comparison identifies that the member identifier in the content group matches the member identifier associated with the member receiving the content group, the corresponding member can determine that the received data group has been multicast from the fraudulent member. Regardless of how the corresponding member determines that the received data packet is multicast from the fraudulent member, the corresponding member can then notify the network entity in response to such a determination.

CN 101124770 Β

[0014] In another aspect of the invention, one or more members can authenticate other members of the group. In this case, at least one member of the multicast group can operate as a destination member to receive a data packet and a code for the data packet from another member of the group operating as a source member, wherein the code is already in the source member Use the symmetric key associated with the source member to generate it. The destination member can then determine whether the received data packet has been multicast from a group member operating as a fraudulent member. If the received data packet is multicast from a fraudulent member, the destination member can multicast a recall packet to members of the multicast group. In addition, the destination member can authenticate the source member based on the code associated with the data packet. However, when it is determined that the received data packet is multicast from the fraudulent member, and before and in response to this, the destination member may also notify the network entity of the existence of the fraudulent member.

[0015] According to other aspects of the present invention, members, methods and computer program products of a multicast group are provided. The embodiments of the present invention therefore provide improved systems, group members, methods, and computer program products for multicasting data packets in a multicast group and identifying fraudulent members. In a similar manner as disclosed in the '150 application, members of a multicast group can authenticate members of a multicast data packet based on codes generated using the data packet and a symmetric key associated with the source member. It is also similar to the method disclosed in the '150 application. When a member receives a data packet from a fraudulent member, the member can also be configured to multicast a "second call" packet to the multicast group. The data packet claims to come from the member itself, and the member does not Multicast the data packet to the group. However, according to an embodiment of the present invention, one or more members can also identify fraudulent members, so that the fraudulent members can be excluded from the multicast group thereafter. Therefore, the system, group members, method, and computer program product of the embodiments of the present invention solve the problems pointed out by the prior art and provide additional advantages.

Description of the drawings

[0016] Having described the present invention in a general sense, reference will now be made to the accompanying drawings, which are not necessarily drawn to scale, in which:

[0017] FIG. 1 is a block diagram of a terminal and system that will benefit from an embodiment of the present invention;

[0018] FIG. 2 is a schematic block diagram of an entity capable of operating as a terminal, an origin server, a user processor, and/or a group controller/key server according to an embodiment of the present invention;

[0019] FIG. 3 is a schematic block diagram of a terminal according to an embodiment of the present invention;

[0020] FIG. 4 is a functional block diagram of a group controller/key server for distributing symmetric keys to multicast group members according to an embodiment of the present invention;

[0021] FIG. 5a is a functional block diagram of a source member who multicasts a content group to a destination member of a multicast group according to an embodiment of the present invention;

[0022] FIG. 5b is a schematic diagram of multicasting as shown in FIG. 5a according to an embodiment of the present invention;

[0023] FIG. 6a shows that according to an embodiment of the present invention, a fraudulent member multicasts content packets to the destination member, and in response to the destination member receiving the content packets from the fraudulent member, the destination member multicasts to other members of the multicast group Functional block diagram of secondary call grouping;

[0024] FIG. 6b is a schematic diagram of an exemplary secondary call packet multicast in the case shown in FIG. 6a according to an embodiment of the present invention;

[0025] FIG. 7 is a functional block diagram of a group controller/key server (GCKS) re-providing keys for group members in response to being notified of fraudulent members according to an embodiment of the present invention;

[0026] FIG. 8a is an embodiment of the present invention, after the GCKS shown in FIG. 7 re-provides keys for the members of the group, the fraudulent member of FIG. 6a multicasts subsequent content groups to the destination member, based on the content grouping Functional block diagram for identifying fraudulent members;

CN 101124770 Β

[0027] FIG. 8b is a schematic diagram of multicast as shown in FIG. 8a according to an embodiment of the present invention;

[0028] FIG. 9 is a functional block diagram of GCKS re-providing the key to group members other than the identified fraudulent member according to an embodiment of the present invention; and

[0029] FIG. 10 and FIG. 11a-FIG. 11f are flowcharts of various steps of a method for authenticating source members in a multicast group and identifying fraudulent members in the group according to an embodiment of the present invention.

Detailed ways

[0030] Hereinafter, the present invention will be explained more fully with reference to the accompanying drawings, in which preferred embodiments of the present invention are shown. However, the present invention can be implemented in many different forms and should not be construed as being limited to the embodiments presented here; on the contrary, these embodiments are provided so that this disclosure will be comprehensive and complete, and will be comprehensive to those skilled in the art. Convey the scope of the invention. The same numbers throughout the text indicate the same elements.

[0031] Referring to FIG. 1, a diagram of a system that would benefit from the present invention is provided. The system, method, and computer program product of the embodiments of the present invention will be explained mainly in conjunction with mobile communication applications. However, it should be understood that the system, method, and computer program product of the embodiments of the present invention can be used in combination with a variety of other applications within the mobile communication industry and outside the mobile communication industry. For example, the system, method, and computer program product of the embodiments of the present invention can be used in combination with wired and/or wireless network (for example, Internet) applications.

[0032] As shown in the figure, the system may include a terminal 10, and the terminal 10 may have an antenna 12 for transmitting and receiving signals to and from a base station or base station (BS) 14. A base station is part of one or more cellular or mobile networks, each of which includes the elements required to operate the network, such as a mobile switching center (MSC) 16. As known to those skilled in the art, the mobile network may also be called a base station/MSC/interaction function (BMI). In operation, when the terminal is making and receiving a call, the MSC can route the call from the terminal or route the call to the terminal. When the terminal participates in a call, the MSC can also provide a connection to the ground communication trunk. In addition, the MSC can control the forwarding and forwarding of messages from and to the terminal, and can also control the forwarding of messages from the terminal to the message center and from the message center to the terminal, such as short message service (SMS) messages to and from the SMS center (SMSC) 18. .

[0033] The MSC 16 may be coupled to a data network, such as a local area network (LAN), a metropolitan area network (MAN), and/or a wide area network (WAN). The MSC can be directly coupled to the data network. However, in a typical embodiment, the MSC is coupled to the GTW 20, and the GTW is coupled to the WAN, such as the Internet 22. Next, a device such as a processing unit (for example, a personal computer, a server computer, etc.) may be coupled to the terminal 10 via the Internet. For example, as described below, the processing unit may include one or more processing units related to one or more origin servers 23, user processors 24, group controller/key server (GCKS) 25, etc., each of which is such as Figure 1 is shown and explained as follows.

[0034] The BS 14 may also be coupled to a signaling GPRS (General Packet Radio Service) support node (SGSN) 26. As known to those skilled in the art, the SGSN can typically perform functions similar to those used by the MSC 16 for packet switching services. Similar to the MSC, the SGSN can be coupled to a data network, such as the Internet 22. The SGSN can be directly coupled to the data network. However, in a more typical embodiment, the SGSN is coupled to a packet-switched core network, such as the GPRS core network 28. The packet-switched core network is then coupled to another GTW, such as the GTW GPRS Support Node (GGSN) 30, and the GGSN is coupled to the Internet. In addition to the GGSN, the packet switching core network can also be coupled to the GTW20. The GGSN can also be coupled to a messaging center, such as a multimedia messaging service (MMS) center 32. At this point, like MSC, GGSN and SGSN can control message forwarding, such as MMS messages. The GGSN and SGSN can also control the forwarding of messages from the terminal to the messaging center and from the messaging center to the terminal.

CN 101124770 Β

[0035] By coupling the SGSN 24 to the GPRS core network 26 and the GGSN 28, devices such as the service provider 22 can be coupled to the terminal 10 via the Internet 20, SGSN, and GGSN. At this point, for example, the service provider's equipment can communicate with the terminal across SGSN, GPRS, and GGSN. In addition, by coupling the SGSN 26 to the GPRS core network 28 and the GGSN 30, devices such as the origin server 23, the user processor 24, and/or the GCKS 25 can be coupled to the terminal 10 via the Internet 22, SGSN, and GGSN. At this point, for example, the origin server, The user processor and/or GCKS device can communicate with the terminal across SGSN, GPRS and GGSN. By directly or indirectly connecting the terminal and other devices (such as origin servers, user processors, etc.) to the Internet, the terminal and other devices can communicate with each other, for example, according to a multicast communication technology such as Multimedia Broadcast Multicast Service (MBMS). For more information about MBMS, refer to the Third Generation Partnership Project (3GPP) technical specification 3GPP TS 22.146, titled Multimedia Broadcast Multicast Service (MBMS), the content of which is incorporated herein by reference in its entirety.

[0036] Although every unit of every possible network is not shown and described here, it should be understood that the terminal 10 may be coupled to any one or more of many different networks. At this point, the mobile network can support any one or more of a variety of first-generation (1G), second-generation (20), 2.5G and/or third-generation (3G) mobile communication protocols, etc. Communication. Additionally or alternatively, the mobile network can support communications based on any one or more of many different digital broadcast networks, such as those including DVB-T (DVB-Terrestrial) and/or DVB-H (DVB-Handheld). Video Broadcasting (DVB) network, Integrated Services Digital Broadcasting (ISDB) network including ISDB-T (ISDB-Terrestrial), etc.

[0037] More specifically, for example, the terminal 10 may be coupled to one or more networks capable of supporting communication according to the 2G wireless communication protocols IS-136 (TDMA), GSM, and IS-95 (CDMA). Moreover, for example, one or more of the networks can support communication according to the 2.5G wireless communication protocol GPRS, Enhanced Data GSM Environment (EDGE), and the like. In addition, for example, one or more of the networks can support communication according to a 3G wireless communication protocol, such as a Universal Mobile Telephone System (UMTS) network using Wideband Code Division Multiple Access (WCDMA) wireless access technology. Some narrowband AMPS (NAMPS) and TACS networks can also benefit from embodiments of the present invention, and dual-mode or multi-mode phones should also be available (for example, digital/analog or TDMA/CDMA/analog phones).

[0038] The terminal 10 may also be coupled to one or more wireless access points (AP) 34. The AP can be set to communicate with the terminal according to any one of a variety of different wireless networking technologies such as, for example, radio frequency (RF), Bluetooth (BT), infrared (IrDA) technology, or a variety of different wireless networking technologies including WLAN technology. The AP 34 may be coupled to the Internet 22. Like the MSC 16, the AP can be directly coupled to the Internet. However, in one embodiment, the AP is indirectly coupled to the Internet via GTW20. It will be understood that by directly or indirectly connecting the terminal and any one of the origin server 23, the user processor 24, GCKS 25, and/or multiple other devices to the Internet, the terminals can communicate with each other and the user processor, so Realize various functions of the terminal, such as sending data, content, etc. to the user processor, and/or receiving content, data, etc. from the user processor. As used herein, the terms "data", "content", "information" and similar terms may be used interchangeably to denote data that can be sent, received, and/or stored according to embodiments of the present invention. Therefore, the use of any such terms should not be seen as limiting the spirit and scope of the present invention.

[0039] Although not shown in FIG. 1, in addition to or instead of coupling the terminal 10 to the user processor 24 across the Internet 22, the terminal and the user processor may be coupled to each other and according to, for example, RF.BT.IrDA or include a LAN And/or WLAN technology any one of many different wired or wireless communication technologies. Additionally or alternatively, one or more user processors may include a removable memory capable of storing content, which may then be delivered to the terminal.

[0040] Referring now to FIG. 2, there is shown a block diagram of an entity capable of operating as a terminal 10, an origin server 23, a user processor 24, and/or a GCKS according to an embodiment of the present invention. Although shown as separate entities, in some embodiments, one or more entities may support one or more of the terminal, the origin server, and/or the user processor, which are logically independent but are all located in the entity together. For example, a single entity can support logically independent but co-located terminals and original

CN 101124770 Β

server. For another example, a single entity may support a terminal and a user processor that are logically independent but located at the same place.

[0041] As shown in the figure, the entity capable of operating as the terminal 10, the origin server 23, the user processor 24, and/or the GCKS 25 may generally include a processor 37 connected to the memory 39. The processor may also be connected to at least one interface 41 or other devices for sending and/or receiving data, content, and the like. The memory may include volatile and/or non-volatile memory, and typically stores content, data, etc. For example, the memory typically stores content sent from and/or received by the entity. For another example, according to an embodiment of the present invention, the memory typically stores software applications, instructions, etc., for the processor to perform steps related to the operation of the entity . For example, when the entity includes GCKS, the memory may store a symmetric key that can be generated or provided for each member of the entity's multicast group related to the corresponding member and the symmetric key related to each other member of the multicast group. Key manager for keys. In this regard, when the entity is used as a member of the entity's multicast group, the memory may store the symmetric key provided by GCKS. In addition, the memory can store a symmetric key common to all members of the multicast group. Moreover, the memory can store a public key/private key pair related to the corresponding entity.

[0042] Reference is now made to FIG. 3, which shows one type of terminal 10 that would benefit from an embodiment of the present invention. However, it should be understood that the terminal shown and described below is only an example of a terminal that will benefit from the embodiments of the present invention, and should not be considered as a limitation on the scope of the present invention. Although several embodiments of the terminal are shown and will be explained as examples below, other types of terminals, such as portable digital assistants (PDAs), pagers, laptop computers, and other types of electronic systems, are easy to use the present invention.

[0043] As shown in the figure, in addition to the antenna 12, the terminal 10 may include a transmitter 38, a receiver 40, and a controller 42 or other processors that provide signals to the transmitter and receive signals from the receiver, respectively. These signals include signaling information according to the air interface standard of the applicable cellular system, as well as user voice and/or user-generated data. At this point, the terminal can operate with one or more air interface standards, communication protocols, modulation types, and access types. More specifically, the terminal can operate according to any one of a variety of first-generation (1G), second-generation (20), 2.5G, and/or third-generation (3G) communication protocols. For example, the terminal can operate according to the 2G wireless communication protocol IS-136 (TDMA), GSM and IS-95 (CDMA). For another example, the terminal may be able to operate according to the 2.5G wireless communication protocol GPRS, Enhanced Data GSM Environment (EDGE), and so on. For another example, the terminal can operate according to a 3G wireless communication protocol such as the Universal Mobile Telephone System (UMTS) using Wideband Code Division Multiple Access (WCDMA) wireless access technology. Some narrowband AMPS (NAMPS) and TACS mobile terminals can also benefit from the method of the present invention, and dual-mode or multi-mode phones are also possible (for example, digital/analog or TDMA/CDMA/analog phones).

[0044] It can be understood that the controller 42 includes circuits required to implement the audio and logic functions of the terminal 10. For example, the controller may include a digital signal processor device, a microprocessor device, and various analog-to-digital converters, digital-to-analog converters, and other support circuits. The control and signal processing functions of the terminal are allocated to these devices according to their respective capabilities. The controller may additionally include an internal voice encoder (VC) 42a, and may include an internal data modem (DM) 42b. Furthermore, the controller may include a function of operating one or more software programs, which may be stored in a memory (below Description). For example, the controller can operate a connectivity program, such as a conventional Web browser. The connectivity program may then allow the terminal to send and receive web content, for example according to HTTP and/or Wireless Application Protocol (WAP).

[0045] The terminal 10 also includes a user interface that includes a conventional headset or speaker 44, a ringer 46, a microphone 48, a display 50, and a user input interface, all of which are coupled to the controller 42. The user input interface that allows the terminal to receive data may include any one of a plurality of devices that allow the terminal to receive data, such as a keypad 52, a touch display (not shown), or other input devices. In an embodiment including a keypad, the keypad includes conventional numbers (0-9) and related keys (#, *) and other keys for operating the terminal. Although not shown, the terminal may include a battery, such as a vibrating battery pack, for powering various circuits required to operate the terminal, and optionally providing mechanical vibration as a detectable output.

CN 101124770 Β

[0046] The terminal 10 may also include one or more devices for sharing and/or obtaining data. For example, the terminal may include a short-range radio frequency (RF) transceiver or interrogator 54 so that according to RF technology, data may be shared and/or obtained from an electronic device. Additionally or alternatively, the terminal may include other short-range transceivers, such as, for example, an infrared (IR) transceiver 56, and/or a Bluetooth transceiver 58 that operates using Bluetooth brand wireless technology developed by the Bluetooth Special Interest Group. Therefore, additionally or alternatively, according to these technologies, the terminal can send data to and/or receive data from the electronic device. Although not shown, additionally or alternatively, according to many different wireless networking technologies, including WLAN technology such as IEEE802.11 technology, etc., the terminal can send data to and/or receive data from the electronic device.

[0047] The terminal 10 may also include a memory, such as a subscriber identity module (SIM) 60, a removable subscriber identity module (R-UIM), etc., which typically store information elements related to a mobile user. In addition to the SIM, the terminal may include other removable and/or fixed memory. In this regard, the terminal may include volatile memory 62, such as volatile random access memory (RAM) including a cache area for temporary storage of data. The terminal may also include other non-volatile memory 64, which may be embedded and/or removable. Additionally or alternatively, the non-volatile memory may include EEPROM, flash memory, and the like. The memory can store any one of multiple software applications, instructions, information segments, and data used by the terminal to realize the functions of the terminal. For example, the memory can store identifiers such as International Mobile Equipment Identity (IMEI) code, International Mobile Subscriber Identity (IMSI) code, Mobile Station Integrated Services Digital Network (MSISDN) code (mobile phone number), Internet Protocol (IP) address, The Session Initiation Protocol (SIP) address, etc., can uniquely identify the terminal, for example, for MSC16o

[0048] As mentioned in the background section, a recently developed technique for authenticating multicast group members was submitted on June 14, 2004 with the title ^uSystem, Method and Computer Program Product for Authenticating a Data Source in Multicast Communications, US Patent Application No. 10/867, 150 is published. In this technique, the source member of the multicast data packet can use the symmetric key associated with the source member to generate a code for the data packet, and then multicast the data packet and the code. After receiving the data packet and code, the destination member can authenticate the source member based on the code or determine that the source member is a fraudulent member of the multicast group. In addition, as mentioned in the background section, although the technology applied by the '150 overcomes the shortcomings of the conventional technology for authenticating data sources in multicast communication, it is generally desirable to further improve the existing technology.

[0049] Reference is now made to FIGS. 4 to 11, which show embodiments of the present invention in more detail. As described below in conjunction with FIGS. 4, 7 and 9, for example, GCKS 25 can operate key manager 68 to distribute symmetric keys to members of a multicast group including N members, where member 170a, member i 70b, and member i 70b are shown. j 70c and member n 70d. As briefly described below, each member of the multicast group can be associated with a symmetric key K known to every other member of the multicast group. The key manager can distribute symmetric keys to members of a multicast group in one or more situations, for example, at regular or irregular intervals, where the symmetric keys associated with one or more members range from one situation to The next situation may change.

[0050] As described below in conjunction with FIGS. 5a, 6a, and 8a, the source member 72 of the multicast group can group one or more content groups (CP) 73 each including one or more data packets (see FIGS. 5b and 8b). ) Send, multicast, or transmit to multiple destination members 74 of the multicast group (three destination members 74a, 74b, and 74c are shown). The source member can operate an application, such as the source client 76, which can multicast one or more data packets from the data store 78 in the source's memory (eg, the memory 39) to the destination member. And then each destination member can operate the destination client 80, which can receive the content group and authenticate the source member based on the information in the content group. Thereafter, if the source member is authenticated, the destination agent can store the data packet in the content storage 82 associated with the corresponding destination member.

[0051] As explained in more detail below, according to an embodiment of the present invention, the destination client 80 of the destination member 74 can authenticate the source member 72 without a digital signature or source and destination in a point-to-multipoint multicast communication. Time synchronization between places.

CN 101124770 Β

In order to allow the source member to multicast data packets to the destination member and allow the destination member to authenticate the source member of the data packet, the source client 76 of the source member can generate a content packet 73 based on the symmetric key associated with the source member. Packets include data packets. More specifically, the source client may generate a content grouping that includes a data grouping, the identity of the source member, and a code generated using a symmetric key related to the source member. And if necessary, the source client can use its symmetric key or group symmetric key to encrypt data packets and/or source member IDo

[0052] The destination client 80 of the destination member 74 can then authenticate the source member 72 based on the content grouping and the symmetric key associated with the source member. More specifically, the destination client can authenticate the source member by using the symmetric key of the source member to decrypt and authenticate the code. Then, if the identity of the source member is authenticated, the destination client can use the source symmetric key or the group symmetric key (which was used to encrypt the data packet) to decrypt the data packet, and then store the decrypted data packet in the data In the memory 82. By using the symmetric key related to the source member and authenticating the source member based on the symmetric key, the destination client in the embodiment of the present invention can authenticate the source member in communication with the outside of the multicast group.

[0053] However, it is understandable that because each member of a multicast group knows the symmetric key of every other member of the group, a fraudulent member of the group can use the symmetric key and identity of another member of the group to multicast Data is grouped, thus impersonating or claiming the identity of another member of the group. In this way, in order to prevent a group member from operating as a fraudulent member, each member of the multicast group can be set up when the member receives a data packet claiming to be from itself and the member does not multicast the data packet to the group (assuming, for example The member has knowledge of his multicast data packets or does not receive his multicast data packets), and multicasts a "second call" packet (RP) 83 to the multicast group, as shown in Figure 6a. Then, the destination client 80 of the destination member 74 who received the content packet from the impersonation member may also receive the secondary call packet and determine from the secondary call packet that the previously received content packet is not actually identified by the content packet. Issued by members of. The destination client then disposes of the previously received content packet as if the source member who multicasted the content packet (ie, the impersonating group member) is not authenticated.

[0054] In order to further identify a fraudulent member who impersonates or claims to be another member of the group, in response to receiving a data packet purporting to be from itself, the destination client 80 of the impersonated destination member 74 may also be set to A fraudulent member in the multicast group is notified to GCKS 25. Then, in response to receiving the notification, the key manager 68 distributes the symmetric key to the multicast group members as before. However, in contrast to the previous key distribution, the secret The key manager can distribute different versions of the symmetric key related to the impersonated member to group members other than the impersonated member, as shown in FIG. 7. That is, the key manager can distribute different versions of the symmetric key related to the impersonated member to each group member except the impersonated member. Then, in the next case where the fraudulent member multicasts the content group 73 claiming to be from the impersonated member, the destination member may not be able to authenticate the fraudulent member because the version of the symmetric key of the impersonated member used to generate the content group is different The version of the symmetric key of the impersonated member known to other members of the group is shown in Figure 8a. And because each member receives a different version of the symmetric key, the fraudulent member can be identified based on the version of the symmetric key used to generate the content group. Thereafter, the identified fraudulent member can be removed from the multicast group, for example, by providing the group member with a new key, but excluding the fraudulent member, so that the fraudulent member no longer has the relevant symmetric keys of other members of the group, or Symmetric key Knowledge, as shown in Figure 9.

[0055] As shown and described herein, the key manager 68, the source client 76, and the destination client 80 each include software operated by the GCKS 25, the source member 72, and the destination member 74, respectively. However, it should be understood that, without departing from the spirit and scope of the present invention, the key manager, the source client, and/or the destination client may optionally include firmware or hardware. Moreover, although the key manager, source client, and destination client are shown and described as being local to the GCKS, source member, and destination member, respectively, among the key manager, source client, and destination client Any one or more of are optionally distributed and communicated with GCKS, source and destination respectively, for example across the Internet 22. As shown and described here, the content is grouped and

CN 101124770 Β

Other data, information, etc. are sent or transmitted between GCKS, source members and/or destination members. However, it should be understood that the terms "send", "multicast" and "transmit" are used interchangeably herein, and without departing from the spirit and scope of the present invention, sending, multicasting, and transmitting data packets may include, for example, from a source The member moves or copies content to the destination member.

[0056] The system, method, and computer program product of the embodiment of the present invention will now be described in more detail in connection with the source member 72 sending, multicasting, or transmitting one or more data packets to the multiple destination members 74. As described herein, according to any number of different multicast communication technologies, the source and destination members are members of a multicast group and each includes any entity capable of multicasting and/or receiving data packets, content, etc. (e.g., Terminal 10, original server 23, user processor 24, GCKS25, etc.). In a multicast group, according to an embodiment of the present invention, the source member may include any group member capable of multicasting one or more data packets to multiple destination members. On the other hand, according to an embodiment of the present invention, the destination member may include any group member that can receive a data packet from the source member and then authenticate the source member. It will also be understood that although functionally operated in different ways, the same entity can be used as one or more of GCKS, source member, destination member or GCKS, source member, and destination member at different times.

[0057] Referring now to the flowcharts of FIGS. 10 and 11a-llf, which will be explained in conjunction with FIGS. 4-9 to describe an embodiment of the present invention, authenticating source members in a multicast group and identifying fraud in the group The individual steps of the members approach. As shown in block 84 of FIG. 4 and FIG. 10, the method may include GCKS 25, or more specifically, a key manager 68 including GCKS 25, which serves as a multicast group member by distributing a symmetric key set to each member 70a-70d provide keys, where members can receive the keys and store them in the corresponding data storage 82 (see Figure 5a). The symmetric key set received by each member may include the symmetric key associated with the corresponding member and the symmetric key associated with each other member of the group, shown as being used for group member 170a, member i 70b, and member respectively. The keys 0, K:, Kj, and K of j 70c and member n 70d_nOIn addition, although not shown, the symmetric key set may also include a group symmetric key known to each member of the multicast group, such as a group traffic encryption key (GTEK).

[0058] The key manager 68 of GCKS25 can generate a symmetric key and distribute the symmetric key to the multicast group members 70a-70d in any of many different ways_oFor example, the key manager may generate a symmetric key from the same or different key material, which may include an identifier or index of each member of the multicast group. The symmetric key can then be distributed to the multicast group, such as according to the Diffie-Hellman key agreement protocol known to those skilled in the art.

[0059] As noted above, the key manager 68 of the GCKS 25 can be configured to provide keys for the members 70a-70d of the multicast group in one or more situations, which can be at one or more regular or irregular intervals. , Or as needed. Although the key manager can provide members with keys in the same way in each case, one or more of the symmetric keys in the key set distributed in any given case can be different from the corresponding ones distributed in the previous case. Key. Therefore, by changing one or more keys distributed in different situations, the key manager of the embodiment of the present invention can provide more than a key manager that distributes keys in a single case or distributes the same key in each case. Good security. In addition, by distributing keys at multiple intervals, the key manager can also prepare for the increase and decrease of group members.

[0060] In any case after the keys are provided or re-provided for the multicast group members 70a-70d, the source client 76 of the source member 72 (eg member i 70b) may be activated to transmit one or more contents Fragments, as shown in Figure 5a and block 86 in Figure 10. After starting the source client 78, the source client may format the content into one or more data packets. For example, the source client can format the content as Ethernet frames, Internet Protocol (IP) packets, segments, or datagrams, etc. Then, the source client can but does not need to encrypt the data packet, as shown in block 88. The source member can encrypt data packets according to any of a variety of different technologies. For example, in one embodiment, the source client may encrypt data packets according to multicast encapsulation security payload (MESP) technology. In this regard, according to one embodiment, the source client may utilize the known group of each member of the multicast group

CN 101124770 Β

A symmetric key (for example, GTEK) is used to encrypt data packets.

[0061] After the data packet is encrypted, the source client 76 (for example, member i 70b) of the source member 72 can add or connect to the encrypted data packet an identifier that can identify the source member with respect to other members of the multicast group ( ID), as shown in block 90. In this regard, each member 70a-70d of the multicast group may be associated with any one of many different identifiers that can identify the member relative to the other members of the group. For example, when the multicast member includes the mobile terminal 10, the member identifier may include IMEI code, IMSI code>MS ISDN code, IP address, SIP address, and so on.

[0062] Regardless of the member identifier connected to the encrypted data packet, the source client 76 of the source member 76 (for example, member i 70b) can then use the connected packet and the symmetric key related to the source member to generate code, such as block 92 Shown. As noted above, each member 70a-70d of a multicast group may be associated with a symmetric key known to every other member of the multicast group. The destination member can then authenticate the source member based on the code and the symmetric key associated with the source member.

[0063] The code generated by the source client 76 of the source member 72 (for example, the member i 70b) may include any one of a plurality of different codes. In a typical embodiment, for example, the code includes a message authentication code (MAC). The MAC may include, for example, a cryptographic checksum of the connection packet generated using the source member's symmetric key. Optionally, for example, the MAC may include a cryptographic checksum of the hash of the connection packet generated using the symmetric key of the source member. In this case, although not shown, the connected packet may be hashed before generating the MAC so that the MAC is smaller than the MAC generated by the unhashing connected packet. However, regardless of how the source client generates the MAC, the source client The content group 73 may then be multicast to a plurality of destination members 74 of the multicast group including the source member, as shown in block 94. The content grouping multicast by the source member includes the connected grouping and MAC (generated using the symmetric key of the source member). To illustrate the content grouping of the example, see Figure 5b (Ki represents the symmetric key of group member i operating as a source member to generate MAC).

[0064] Referring now to FIGS. 11a-llf, a method for authenticating a source member 72 of a multicast group including a source member and a plurality of destination members 74 is provided, that is, a method of identifying in the multicast group Ways to defraud members. As shown in the figure, the method includes receiving each destination member of a content packet 73, the content packet 73 includes a connected packet and a MAC, and the connected packet contains an encrypted data packet and a source member identifier, as shown in the block of FIG. 11a. 96 shown. Thereafter, each destination member, or more specifically, each destination client 80 of each destination member, can determine based on the source member identifier whether the content packet originated from fraud that impersonates or claims the identity of the corresponding destination member member. More specifically, the destination client may determine whether the source member identifier in the content packet matches the destination member identifier of the corresponding destination member (rather than the source member who actually delivered the content packet), as shown in block 98.

[0065] To illustrate, assume that group member j 70c is a fraudulent member posing as group member i 70b, where group member j operates as source member 72, as shown in FIG. 6a. In this case, the source client 76 of the group member j generates a content group 73, as shown in FIG. 5b, the content group 73 includes: a connected group, which includes an encrypted data group; and a member of member i Identifier; and the MAC generated using the symmetric key (ie Ki) associated with member i. Then group member j multicasts content to the destination member 74 of the multicast group. The multicast group includes group member 1 70a, group member i 70b, and group member n 70. When receiving the content grouping, the destination members 74a and 74b (Ie, group member 1 and group member n) the destination client 80 both determines that the source member identifier (ie, the identifier of member i) in the content group does not match their corresponding member identifier. On the other hand, the destination client of the destination member 74c (ie, group member i) does recognize that the source member identifier in the content group matches its corresponding member identifier, indicating that the fraudulent member is impersonating the destination member 74c. Identity.

[0066] Therefore, if the destination client 80 of the destination member 74 (eg, group member i 70b) recognizes a match between the source member identifier and the member identifier of the corresponding destination member, the destination client Able to generate and multicast two

CN 101124770 Β

Secondary call group (RP) 83 to notify other members of the multicast group (for example, group member 1 70a, group member j, and group member η 70d) that the source member 72 is a fraudulent member, and the corresponding destination member does not know the fraudulent member at this time , As shown in block 112 of Figure lib. In other words, the destination client can generate a second call group to notify members of the multicast group that the member identifier in the content group is not related to the source member who sent the content group, but is related to the destination member of the multicast second call group.

[0067] The secondary call group may include any of a number of different pieces of information, such as, for example, notification to other members of the multicast group (eg, group member 1 70a, group member j, and group member n 70d). In order to reduce the possibility of the destination member 74 successfully multicasting the secondary call packet in response to the content packet 73 correctly transmitted from the source member 72, the destination client 80 of the corresponding destination member may digitally sign the secondary call packet , For example, using the private key of the public/private key pair related to the destination member, as also shown in block 112. At this point, each member of the multicast group can also be associated with a public/private key pair, where the public key of the pair is known to other members of the multicast group and GCKS. For example, for the second call group digital signature, see Figure 6b ο

[0068] After digitally signing the secondary call group, the destination client 80 of the corresponding destination member 74 (for example, group member i 70b) can multicast the digitally signed secondary call group to the multicast group. The broadcast group includes other destination members 74 (for example, group member 1 70a and group member n 70d) and the source member 72 of the initial multicast content group 73 (for example, group member j 70c) (now for the purpose of the second call group Land member), as shown in Figure 6a and block 114 in Figure lib. Moreover, the destination client can notify the GCKS 25 of the presence of fraudulent members in the multicast group, such as by multicasting a digitally signed secondary call group to GCKS. Moreover, after identifying a match between the source member identifier and the corresponding destination member identifier, typically after multicasting the secondary call packet, the destination client can discard the encrypted data packet because the destination client The source member cannot be authenticated, as shown in block 116.

[0069] If the destination client 80 of the destination member 74 (for example, group member 1 70a, group member n 70d) does not recognize the source member identifier (for example, the identifier of member i 70b) and the destination member identifier The destination client can generate a comparison MAC with a symmetric key related to the source member identifier (for example, Ki), for example to generate a comparison MAC with the source client 76 of the source member 72 (for example, member j 70b). The MAC in the content grouping 73 is in the same way, as shown in block 100 of Fig. 11a. More specifically, for example, the destination client may use the connected group and the symmetric key associated with the group member identified by the source member identifier to generate a comparison MAC. In this regard, the corresponding symmetric key can be selected based on the source member identifier, for example when the destination member stores the symmetric key for the group member indexed by the group member identifier. Alternatively, when the source client hashes the connected packet before generating the MAC, the destination client may hash the connected packet before generating the MAC, and then generate the MAC from the hash.

[0070] As shown in block 102, after generating the comparison MAC, the destination client 80 of the destination member 74 (eg, group member 1 70a, group member n 70d) may compare the comparison MAC with the MAC in the content group 73. Compare. If the destination client does not recognize a match, the source member (eg, member j 70b) is not authenticated. In this case, the destination client can discard the encrypted packet and, if necessary, can notify the source member that the destination cannot authenticate the source member, as shown in block 104. On the other hand, if the destination client does recognize a match, the source member is authenticated, and the destination client can store the data packet in a temporary data queue in the destination member's data storage 82, as shown in block 106. But before storing the data packet in the temporary data queue, if necessary, the destination client can decrypt the data packet, for example, in the opposite way that the source member encrypts the data packet (e.g., group symmetric key or source member Symmetric key).

[0071] The destination client 80 of the destination member 74 (eg, group member 1 70a, group member n 70d) may then keep the data packet in the data queue for a waiting period to allow another destination member (eg, member i 70b) Destination

CN 101124770 Β

The client determines the match between the source member identifier and the corresponding destination member identifier, and if a match is recognized, multicasts the digitally signed secondary call group to the multicast group including the destination of the corresponding destination client , As described above (see block 98 of Fig. 11a and blocks 112-116 of Fig. lib). If the destination client does not receive the secondary call packet within the waiting period, the destination client can decrypt the data packet (unless it has been decrypted before being stored in the temporary data queue), for example, in the opposite way to the source member's encrypted data packet (For example, group symmetric key or source member symmetric key), as shown in blocks 108 and 110. The destination client can then move the decrypted data packet from the data queue to another, more permanent location in the destination's data store, as also shown in block 110.

[0072] However, if the destination client 80 of the destination member 74 (eg, group member 1 70a, group member n 70d) does receive the secondary call packet within the waiting period, the destination client may then be based on the number The signature attempts to authenticate the digitally signed secondary call packet, as shown in blocks 118 and 120 of Figure 11c. At this point, the destination client can use the private/public key pair associated with the destination client of the impersonated group member of the multicast secondary call group (now the source member for the secondary call group) The public key to authenticate the second call group. If the second call packet is authenticated, the destination client can interpret the notification of the second call packet and recognize that the decrypted data packet originated from a fraudulent member and not from the source member identified in the content packet 73, and discarded The decrypted data packet from the data queue in the data storage 82 of the destination member is shown in blocks 122 and 124. However, if the second call packet is not authenticated, the destination client can continue to store the decrypted data packet in the data queue for the waiting period (see block 108 of Figure 11a), if the destination client does not receive it within the waiting period When the second call packet is reached and authenticated, the decrypted data packet is moved (see block 110) ο

[0073] Moreover, if the GCKS 25 is notified that there is a fraudulent member in the multicast group, for example, by receiving a second call group with a digital signature of GCKS, GCKS can also try to authenticate the second call group based on the digital signature, as shown in the block of lid. 126 and 128 are shown. Like the destination client, GCKS can use the private/public key pair associated with the destination client of the multicast secondary call group that is pretended to be a member of the group (now the source member of the secondary call group) The public key is used to authenticate a call group. If the first call group is authenticated, GCKS can interpret the first call group notification and recognize that the multicast group includes fraudulent members. In the next case when the group members are re-keyed, or after the second call group is authenticated At some other time, immediately re-provide the key for group members 70a-70d or instruct the key manager 68 to re-provide the key, as shown in blocks 130 and 132. But as pointed out above, compared with the previous key distribution, the key manager can distribute symmetric keys related to the impersonated member to group members other than the impersonated member (different versions of KJ, as shown in Figure 7. As shown. For example, when group member i is a fake member, the key manager can distribute different versions of the symmetric key related to member i, Kii, K" and Yin, and the versions are distributed to member 1, member j, respectively. And member n. Therefore, for example, the destination member 74a (ie group member 1) can receive a symmetric key set, including Κι (Key related to itself), Κ:] (the first version of the key related to the impersonated group member i), $ (key related to group member j), and heart (related to group member η) Key). Similarly, the source member 72 (ie, fraudulent group member j) can receive a symmetric key set, including Κι, Κ" (the j-th version of the key related to the impersonated group member i), Kj (related to itself Key) and heart; and the destination member 74b (ie group member η) can receive a symmetric key set, including Κι (key related to group member 1), 1 (Yuan (related to the impersonated group member i) The nth version of the key), Kj and K_nO

[0074] In order to allow the impersonated members (ie, members of the multicast secondary call group 83) to identify fraudulent members, the key manager 68 of the GCKS 25 may distribute to the impersonated members of the group a symmetric key including themselves (The symmetric key set of all versions of KJ is also shown in Figure 7. Continue the above example, then the destination member 74c (ie group member i 70b) can receive the symmetric key set, including Ki, Kii, K" and Yin , (Distributed to other members of the group, related to the impersonated group member i

CN 101124770 Β

Version of the key), $ and heart. It will be understood that if not all the different versions of the key (eg, island, K" and KQ related to the impersonated group member (eg, member i) are different from the keys before group members 70a-70d, then at least one The version is different from the keys previously provided by group members 70a-70d, where all group members receive the same symmetric key related to the corresponding group member (such as KJ (see Figure 4). But other symmetric keys related to other members of the group) , May or may not be different from the previous key of the group member, although other symmetric keys in a typical embodiment are indeed different from the provided keys.

[0075] As shown in FIG. 8a, at a certain point after the key manager 68 of the GCKS 25 re-provides the keys for the members 70a-70d of the multicast group, the fraudulent member (for example, the member j 70c) may act as before Multicast content group 73 again in the same way as impersonating a member of the same group (for example, member i 70b) (see Figures 6a and 10). However, compared with before, due to re-providing the group members with keys, the codes generated by the fraudulent members are generated based on different symmetric keys related to the impersonated members. At this point, the content group previously multicast by the fraudulent member includes a symmetric key based on the impersonated member known to all members of the multicast group (such as code generated by KJ, an example of which is also shown in Figure 5b. However. , The content grouping now multicast by the fraudulent member includes a symmetric key version based on only the fraudulent member and the fake member known by the fake member (such as the code generated by KQ. Regarding the current multicast by the fraudulent member For an example of content grouping, see Figure 8b (compared to the content grouping shown in Figure 5b).

[0076] Similar to the previous, each destination member receives the next multicast content packet 73 from the source member 72 (for example, member j 70c) operating as a fraudulent member, as shown in block 134 of FIG. 1E. In this case, the multicast content packet includes the encrypted data packet and the member identifier of the impersonated member (e.g., member i 70b), and the symmetric key (e.g., KQ generated by the impersonated member) of the version associated with the impersonated member The MAC, where the key version is distributed to fraudulent members during the re-keying period. Similar to the previous one, each destination member, or more specifically, each destination client 80 of each destination member It may be determined whether the source member identifier in the content packet matches the destination member identifier of the corresponding destination member (rather than the source member that actually delivered the content packet), as shown in block 136.

[0077] Assuming that the source member 72 operates as a fraudulent member again, the destination member 74 (for example, group member 170a, group member n 70d) other than the destination member (for example, member i 70b) being impersonated is the destination client 80 did not recognize a match between the source member identifier (for example, the identifier of member i) and the destination member identifier. Therefore, in a similar manner as before, the destination client can generate a comparison MAC to compare it with the MAC in the content packet 73 to continue. In this regard, the destination client may select a symmetric key for use in generating the comparison MAC based on the source member identifier. However, like the fraudulent source member, the destination client of the destination member now has a symmetric key version of the impersonated member identified as the source member in the content grouping, where this version has only the corresponding destination member and the impersonated member The members know it themselves.

[0078] Therefore, regardless of the destination member 74, the corresponding destination client 80 uses the symmetric key version of the impersonated member to generate a comparison MAC, which is different from the version used to generate the MAC in the content packet. Continue to re-provide keys for group members 70a-70d in the previous example. When group member j is a fraudulent member and group member i is a counterfeit member, then group member j is considered to include the use of symmetry related to group member i in the content grouping The jth version of the key (that is, the MAC generated by KQ_OOn the other hand, the destination client of the group member 1 operating as the destination member 74a uses the first version of the symmetric key related to the group member i (ie, KQ generates a comparison MAC. Similarly, the operation is the destination member 74b The destination client of group member n uses the nth version of the symmetric key related to group member i (ie K_in) Generate comparison MAC_O

[0079] As shown in block 102 of FIG. 11a, after generating the comparison MAC, the destination client 80 of the destination member 74 (eg, group member 1 70a, group member n 70d) may group the comparison MAC with the content Compare with the MAC in 73. but

CN 101124770 Β

Yes, since the destination client uses the symmetric key version of the impersonated member to generate the comparison MAC, and this version is different from the version used to generate the MAC in the content packet, the destination client will typically recognize a mismatch. Then, similar to before, the destination client cannot authenticate the source member (for example, member j 70b), and therefore discards the encrypted packet accordingly, again as shown in block 104.

[0080] In contrast to the destination client 80 of the destination member 74 (eg, group member 1 70a, group member n 70d), the destination client of the impersonated destination member 74 (eg, group member i 70b) A match between the source member identifier and the member identifier of each destination member can be recognized. Previously, the destination client of the impersonated destination member generated and multicasts the second call group (RP) 83 to notify the other members of the multicast group (for example, group member 1 70a, group member j, and group member n 70d) The source member 72 is a fraudulent member. However, in this case, the destination client does not need to multicast the secondary call group, because as described above, other destination members of the multicast group have already operated in a way that the source member cannot be authenticated. Conversely, the destination client of the impersonated destination member can identify the fraud source member 72 based on the MAC.

[0081] More specifically, the destination client 80 of the impersonated destination member (e.g., member i 70b) can identify the symmetric key associated with the corresponding destination member (e.g., version of Kii, K" or KQ This version is also distributed to the fraud source member and used to generate MAC (such as KQ. The destination client can identify the fraudulent member (such as member j 70c) based on the identified symmetric key version, as shown in block 138 of Figure lie. Because only the fraudulent member and the corresponding impersonated destination member receive the symmetric key version. The destination client can identify each version of the symmetric key in any of many different ways. For example, the destination The client can use different versions of the symmetric key associated with the corresponding destination member to generate different comparison MACs until the destination client recognizes a match between the comparison MAC and the MAC in the content packet 73. Then, know which ones After the group member has received which symmetric key versions related to the impersonated destination member, the destination client can then identify that the fraudulent member is a group member that has received the symmetric key version used to generate a matching comparison MAC.

[0082] Regardless of how the destination client 80 of the destination member being impersonated (for example, member i 70b) specifically recognizes the fraudulent member (for example, member j 70c), the destination client can then notify the GCKS 25 of the identity of the fraudulent member . The destination client can notify GCKS in any of many different ways, for example, by generating and transmitting a notification packet (NP) 85 to GCKS, where the notification packet includes the identity of the fraudulent member, as shown in block 140 in Figure 8a and Figure lie. Shown. Notification packets can be generated in any of many different ways, and include any of many different pieces of information. In one embodiment, for example, the notification packet is generated in a similar manner to the secondary call packet 83, and includes a notification that a fraudulent member is identified. Also similar to the secondary call grouping, in order to provide added security to the notification grouping, the destination client can digitally sign the notification grouping, for example, using the private key in the public/private key pair associated with the corresponding destination member .

[0083] After digitally signing the notification packet 85, the destination client 80 of the corresponding destination member 74 (for example, member i 70b) may send a digitally signed notification packet to the GCKS 25, as shown in FIGS. 8a and lie Shown in block 142. Similar to receiving a secondary call packet, GCKS may receive the digitally signed notification packet, and then attempt to authenticate the notification packet based on the digital signature, as shown in blocks 144 and 146 of FIG. 11f. At this point, GCKS may use the public key in the private/public key pair associated with the destination client of the corresponding destination member to authenticate the notification packet. If the second call group is authenticated, GCKS can interpret the notification of the second call group and recognize the identity of the fraudulent member (for example, member j 70c), re-provide the key or instruct the key manager 68 to re-provide the secret for the group members The key is performed, for example, immediately after the identity of the fraudulent member is recognized or at some other time after the authentication notification packet, as shown in blocks 148 and 150.

[0084] The members of the multicast group can be rekeyed again in many different ways, for example as shown in FIG. 4

CN 101124770 Β

Similar way. However, compared with the situation shown in Figure 4, GCKS can remove fraud from the multicast group by instructing the key manager 68 to distribute new symmetric key sets to other members of the multicast group and not to the identified fraudulent members. Members, as shown in Figure 9. Therefore, as shown in the figure, for the case where member j 70c is identified as a fraudulent member, for example, the key manager can distribute a new symmetric key set to member 1 70a, member i 70b, and member n 70c, but not to members j (now a former member of the multicast group) distributes a symmetric key set. In the example shown, the symmetric key set includes a new symmetric key related to each member of the multicast group (ie, K, i, K, i, or K, n), but does not include the previous member j The associated symmetric key (ie, K'j). Although the symmetric key related to one or more members of the multicast group may not change every time the key is re-provided, the symmetric key related to all members is re-provided for the member after the fraudulent member is identified. The key period does typically change so that the fraudulent member does not have knowledge of the symmetric key associated with the multicast group member.

[0085] The foregoing description assumes that at a certain point after the key manager 68 of the GCKS 25 re-provides the keys for the multicast group members 70a-70d, the fraudulent member (for example, the member j 70c) follows the impersonation of the same group member (for example, , Member i 70b) multicast the content group 73 again in the same way as the identity. However, it should be understood that in various situations, a fraudulent member may not pretend to be a member of the same group to multicast the content group again, or may only pretend to be a member of the same group after a long period of time. Therefore, the GCKS may be set to wait for a period of time to receive the notification packet 85 from the destination client 80 of the impersonated destination 74. For example, GCKS can be set to wait for a period of time from one moment when the group member is rekeyed to the next moment when the group member is rekeyed. Then, if GCKS does not receive the notification packet after the time period, GCKS can respond by re-providing the key for the group member, and again include the same symmetric key related to the impersonated destination member in the symmetric key set ( See Figure 4 and Figure 10, block 84). Therefore the multicast group reverts to typical operation as if the fraudulent member had not previously impersonated another member of the group.

[0086] As described above, the source client 76 of the source member 72 may add or connect an identifier (ID) related to the source member to the data packet (encrypted or otherwise). The destination member can then use the source member identifier to determine whether the source member is impersonating the identity of the corresponding destination member, select the symmetric key associated with the source member, and authenticate the source member based on the corresponding symmetric key (ie , By using the corresponding symmetric key to generate a comparison MAC). It should be noted, however, that the source client does not have to add or connect the source member identifier to the data packet. In this case, the destination member can generate and compare the comparison MAC based on the symmetric key associated with each other member of the multicast group until the comparison MAC matches the MAC of the content packet to determine the source member identifier . Each destination member can also determine whether the source member is impersonating the identity of the destination member by generating a comparison MAC based on the destination member's symmetric key and comparing the comparison MAC with the MAC of the content packet. If the destination member recognizes a match, the source member impersonates the identity of the destination member.

[0087] As also mentioned above, the source client 76 of the source member 72 can encrypt the data packet, connect the data packet to the source member identifier, hash the connected packet, and hash the connected packet based on the hash of the source member identifier. Packet generation MAC to generate content packets. It should also be understood that, if necessary, the steps of generating content groupings can occur in one or more optional sequences. For example, the source member may generate the content packet by hashing the data packet, connecting the hashed data packet with the source member identifier, and generating a MAC based on the connected packet according to the source member identifier. However, in either of these two events, the source client can but does not need to hash the connected packets or data packets.

[0088] As shown and described herein, the multicast group includes a source member 72 and a plurality of destination members 74. It should be understood, however, that at any given time, more than one group member 70 can operate as a source member to achieve multi-sender multicast. In such a case, the multicast group may include multiple source members and at least one destination member (if not multiple).

[0089] Moreover, as described above, the key manager 68 of the GCKS 25 distributes a symmetric key set to the impersonated member of the multicast group (ie, a member of the multicast secondary call group 83), which includes Related symmetric keys (all of KJs

CN 101124770 Β

Version, which allows the impersonated member to identify the fraudulent member. It should be understood that any one or more of many other network entities may operate equivalently to receive all versions of the symmetric key and identify fraudulent members. For example, GCKS can receive or save all versions of the symmetric key by itself. In this case, after the destination client 80 of the impersonated destination member 74 (eg, group member i 70b) recognizes that the source member identifier matches the member identifier of the corresponding destination member (see block 136 ), as before, the destination client can generate a notification packet 85 and digitally sign it. However, in this case, with respect to the identity of the fraudulent member, the notification packet may include the MAC in the content packet 73 received by the destination client. GCKS can then identify the fraudulent member based on the MAC in the content packet, for example, in combination with the above. Impersonate the destination member of the destination client in the same way as described.

[0090] According to one aspect of the present invention, all or part of the system of the present invention, such as GCKS25. All or part of the source member 72 and/or the destination member 74 are usually in a computer program product (for example, the key manager 68, Operation under the control of the source client 76, the destination client 80, etc.). The computer program product used to execute the method of the embodiment of the present invention includes: a computer-readable storage medium, such as a non-volatile storage medium, and a computer-readable program code portion, for example contained in the computer-readable storage medium A series of computer instructions.

[0091] In this regard, FIGS. 10 and 11a-llf are flowcharts of methods, systems, and program products according to the present invention. It can be understood that each block or step of the flowchart and the combination of blocks in the flowchart can be implemented by computer program instructions. These computer program instructions can be loaded onto a computer or other programmable equipment to produce a machine, so that the instructions running on the computer or other programmable equipment establish a device that implements the functions specified in the flowchart blocks or steps. These computer program instructions can also be stored in a computer-readable memory, which can instruct computers or other programmable devices to work in a specific manner, so that the instructions stored in the computer-readable memory produce processed items, which include blocks that implement flowcharts. Or the instruction device of the function specified in the step. Computer program instructions can be loaded on a computer or other programmable equipment to cause a series of operable steps to be executed on the computer or other programmable equipment to produce a computer-implemented process, so that the instructions run on the computer or other programmable equipment Provides steps to implement the functions specified in the flowchart blocks or steps.

[0092] Therefore, the blocks or steps of the flowchart support a combination of means for performing designated functions, a combination of steps for performing designated functions, and program instruction means for performing designated functions. It should also be understood that each block or step of the flowchart, and the combination of blocks or steps in the flowchart, can be implemented by a dedicated hardware-based computer system or a combination of dedicated hardware and computer instructions that executes the specified function or step. achieve.

[0093] Those skilled in the art to which the present invention pertains with the advantages of the teachings provided by the above description and related drawings will come to mind many modifications and other embodiments of the present invention. It should therefore be understood that the present invention is not limited to the specific embodiments disclosed, and modifications and other embodiments are intended to be included within the scope of the appended claims. Although specific terms are used here, they are only used in a general and descriptive sense and not for limiting purposes.

CN 101124770 Β