10.2 Security Analysis
10.2.1 General Security Assessment
In this section we analyze the security of the proposed GKMF in general to see that the proposed framework meets the requirements specified inSection 8.2.2.
(a) Provision of entity authentication
We have assumed the use of secure entity authentication mechanisms in our proposed protocols (see Section 9.1.3). This provides a means for both group members and key manager entity(s) to authenticate and verify each other’s identities.
(b) Provision of backward and/or forward secrecy
A particular security service that is specific to multicast group commu- nication is the provision of confidentiality with respect to backward and forward secrecy. As mentioned in Section 4.7.3, a good design of GKMFs for secure multicast group communications should offer this as a default option. Our framework has provided these options for backward and/or forward secrecy, which can be managed using Protocol I: Creation of new Group and initial distribution of keys (see Section 8.4.1). Also, we have provided separate protocols for these options in new member joining, ex- isting member leaving and member moving protocols (see Chapter 9). (c) Data (Message) integrity and authentication
We have assumed the use of data origin authentication (hence data in- tegrity) mechanisms in our proposed protocols (see Section 9.1.3). This provides a means for both group members and key manager(s) to verify the integrity of data received.
(d) Secure data exchange
10.2 Security Analysis
through careful application of security techniques and mechanisms, as dis- cussed in Section 9.1.2. We have assumed secure use of these techniques and mechanisms, and the availability of secure encryption algorithms (as mentioned earlier, see Section 10.2). These provide a means for all group communicating entities to ensure that their communications remain con- fidential, and that access is only allowed to authorized group members. (e) Secure key distribution
Our framework supports secure distribution of the keys needed in the framework. We have assumed that the distribution of long-term keys to key managers and group members (Section 8.3.6.1) is done in a secure manner, as discussed in Section 8.3.6.3. This provides a means for key managers to protect the distribution of short-term keys (Section 8.3.6.2) to all group members prior to group communication.
(f) Secure key updates (re-keying)
Our framework supports re-keying of short-term keys (in particular the traffic key of a multicast group and the area key of a particular area), which may need to occur whenever there is a change in group membership (either due to new joins, member leaves, or member moves). We have provided re-keying of these keys, which can be managed using Protocol V: Re-keying the traffic key (Section 9.10) and Protocol VI: Re-keying the area key (Section 9.11).
We have also provided options for re-keying to occur if provision for back- ward and/or forward secrecy is required. These can be managed using
Protocol II(b): New member joining with backward secrecy (Section 9.4),
Protocol III(b): Existing member leaving with forward secrecy(Section 9.6), and Protocol IV(b): Member moving with backward secrecy (Section 9.8). We have assumed secure establishment of long-term keys between key man- agers and group members (Section 8.3.6.1), the use of secure entity and data origin authentication mechanisms in the protocols as discussed in
Chapter 9, and the availability of secure encryption algorithms (as men- tioned earlier, see Section 10.2). These provide a means for key managers to protect re-keying that needs to occur at the domain and area levels, and to securely inform group members when re-keying of a particular key is required.
10.2 Security Analysis
Table 10.1: Re-keying of traffic key and area key. (g) Additional key management during host mobility
Our framework supports host mobility. We have provided the establish- ment of short-term session mobility key that needs to occur prior to host mobility usingProtocol IV(c): Establishment of session mobility key (Sec- tion 9.9). Also, we have demonstrated that in order to preserve backward secrecy, a re-keying operation must occur whenever a member moves to an- other area, which can be managed using Protocol IV(b): Member moving with backward secrecy (Section 9.8).
Table 10.1 summarizes re-keying operations of both a traffic key T−Key
and an area keyA−Key, which occurred due to group membership change. We indicate re-keying of each key with a √ notation, otherwise they are indicated with a dash. From the table, with the exception of member moving, provision of backward and forward secrecy require re-keying of both T−Key and A−Key.
Re-keying of T−Key does not need to occur during host mobility because moving members are still in a same group session. When a member moves into an area, the A−key of the visited area (where the member is moving to) is re-keyed with a new area key.
(h) Provision of trust model
We have assumed the availability of secure environments for key manage- ment, as discussed inSection 8.3.6.3, and the existence of trustworthy and reliable key managers in a domain, as specified inSection 8.3.2. These pro- vide a secure foundation for our framework to exercise the proposed group key management protocols for secure multicast group communication.
10.2 Security Analysis