1 / 37

Group Key Management Protocol (GKMP)

Group Key Management Protocol (GKMP). Presented By Aafreen Shaikh Course CMSC 621. Summary of Presentation 1. Need for Multicast Security Dynamic entry and exit of members Authentication of the group members Integrity during transmission Confidentiality services for a multicast session

hu-tucker
Download Presentation

Group Key Management Protocol (GKMP)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Group Key Management Protocol(GKMP) Presented By Aafreen Shaikh Course CMSC 621

  2. Summary of Presentation 1 • Need for Multicast Security • Dynamic entry and exit of members • Authentication of the group members • Integrity during transmission • Confidentiality services for a multicast session • Introduction to GKMP • Experimental protocol for internet community • No central key distribution site needed • Create grouped symmetric keys • Features of GKMP • Multicast and Security • Latency • Reliability and Extendibility • Operating expense and communication resources

  3. Current Key Management Architecture • Key Distribution Center (KDC): • It is used for setting up symmetric keys • Military systems such as BLACKER, EKMS and commercial systems such as Kerberos all operate using dedicated KDCs. • A group key request is sent to the KDC • The KDC acts as an access controller and decides whether the request is authenticate by verifying whether all the members of a group are cleared to receive all the data on a group • The KDC would then call up each member and download the symmetric key • When each member had the key the KDC would notify the requestor and the secure communication could begin • Key Generation Protocols like FireFly, Diffe-Hellman, RSA can be used which rely on cooperative key generation algorithms to create a cryptographic key • These pairwise key management protocols can be integrated into communication protocol or application • Drawbacks - the third party whose primary interest isn’t communication, needs to get involved

  4. GKMP ARCHITECTURE • Basic operations of GKMP - access control - key generation - key distribution • Hierarchy in GKMP - security manager - group manager - group controller - group members

  5. Sender Initiated Operation • Identification of Group Key Controller: • The originator of the multicast group creates or obtains a group management certificate from its certification hierarchy • The certificate identifies the holder as responsible for generation and distribution of the group key • The originator relays the membership list to the Group Key Management (GKM) application • Group Key Creation : • The GKM application, operating on behalf of the originator, selects one member of the group, contacts it, and creates a Group Key Packet (GKP) • A GKP contains the current group traffic encrypting key (GTEK) and future group key encrypting key (GKEK) • Group Key Packet (GKP) = [GTEKn,GKEKn+1]

  6. Sender Initiated Operation • Group Key Distribution: • the group controller contacts each member of the group, creates a Session Key Package (SKP), validates their permissions (check member's certificate against group parameters), and create a Group Re-key Package (GRP) for that member • A SKP contains a session TEK and a session KEK for a particular member Session Key Package (SKP) = [STEK, SKEK] • A GRP contains the GKP encrypted in a KEK and signed using the originator's certificate Group Re-key Package (GRP) = {[GKP]KEK} Signature Controller

  7. Receiver Initiated Operation • Selection of Group Key Controller: • Selection of controller may be made through a voting system, by a simple default or configuration • There is no need for the selected controller to be the controller for all time, but at any one time only one controller may be active for each group • The current controller's identity must be made available to all members, and potential members, for initial group key load and error recovery • Group Key Creation : • The GKP is created and distributed as in sender initiated operations • Group Key Distribution : • After creation of the GKP, as other members contact the controller, a SKP is created, member permissions are validated and a GRP is loaded to the member • Some number of regional GKM applications are enabled with the ability to validate the permissions of new members and upon validation send to them the current GKP

  8. GKMP ROLES • Group Controller (GC): - Why need a controller? - the group must operate on the same symmetric key and hence we need the controller . All group members have the capability to be a GC and could assume this duty upon assignment. • Functions of Group Controller: - Create keys - Distribute keys - Create group re-key messages - Report on the progress - Collects acknowledgement of key receipt messages from the receiver

  9. GKMP ROLES Contd.. • Group Member: • Wait for distribution message • assist the controller in creating the key • Decrypt the messages received from the GC • Validate the controller authorization to perform actions • accept key from the controller • request key from the controller • maintain local Compromise Recovery List (CRL) lists • manage local key • perform peer review of key management actions • acknowledge receipt of new key

  10. Supporting Functions • Security Management: • GKMP relies on security management to operate • Why is it necessary to have a security manager? - permission management - initialization of software - compromise recovery • The security manager creates credentials that uniquely identify the host and its permissions and this credential is signed by the security management by its private key and can be verified by all net members with the public key • Permission certificates signed by the security management is given to each host which uniquely identify the host and its access permissions • Compromise recovery management: if a group member is found compromised then the protocol must facilitate the exclusion of the member

  11. Supporting Functions • Group Management: • interacts with other management functions in the network to provide the GKMP with the group membership lists and group relevant commands • group manager receives group progress reports from the GC • assignment of a group address • update of router databases • distribution of group address to group members • GC would also be a recipient of this message • incase of group creation failure this failure should also be reported to the group requestor

  12. Data Item Primitives in GKMP • GC gets the list of members and initiates contact • Authority which commands the group creates a group token • Token consists of information regarding the GC and the permissions that are required for the group • Group ID- unique identification so that several groups can coexist in a network • GTEK id • GKEK id • GTEK creation field • GKEK creation field • Distributor signature – GC private key • Distributor public – GC public key • Member signature – member private key • Member public – member public key • Controller permissions – assigned by the security manager • SKEK id • SKEK creation field

  13. Data Item Primitives in GKMP • Member permissions – provided by the security manager • Encrypted group keys • Confirmation of decryption • Request • Member delete list

  14. Example Figure taken from Secure Multicast Group Key distribution

  15. States in GKMP • State 1: • The source address is checked to ensure it is not on the CRL. • The token field is validated with the public key of the source. • The token version number is checked to ensure this token is current. • The group ID is checked to see if this group exists. The controller ID field is then read. If the receiver is listed as the GC, the receiver assumes the role of controller. If not, the role assumed is that of receiver. • The GC reads the group permission field in the group token. It then verifies that its' personnel permissions exceed or equal those of the group. • The GC will creates its' portion of the key creation message. • The Create Grp Keys_1 message is completed and transmitted.

  16. States in GKMP • State 2: • The source signature field is validated using the public key of the source. • The source ID field is compared against the local CRL. If the source is on the CRL the association is terminated. • The request field is read. The local contributions to the group keys are created. • The Group keys are created and stored pending negotiation. • The key table is updated to show the group key pending negotiation.

  17. States in GKMP • State 3: • The permission certificate is retrieved and validated using the security managers public key. The permissions of the message source are checked to verify they meet or exceed those of the group. • The group token is retrieved and validated using the appropriate public key. • The token version number is checked to ensure the token is current. • The group ID specified in the token is compared with the actual group ID. If they are different the exchange is terminated. • The controller ID specified in the token is compared with the GC ID. If they do not match the exchange is terminated. • The local permissions are compared to the permissions specified for the group. If they do not meet or exceed the group permissions the exchange is terminated and a report is generated. • The re-key interval specified in the token is stored locally. • The key table is updated to reflect the key permissions, re-key interval, group ID and current time.

  18. States in GKMP • State 4: • The permission certificate is retrieved and validated using the security members public key. The permissions of the message source are checked to verify they meet or exceed those of the group. • The key table is updated to reflect the key permissions, re-key interval, group ID and current time. • State 5: • The source signature field is validated using the public key of the source. • The source ID field is compared against the local CRL. If the source is on the CRL, the association is terminated. • The request field is read. The local contribution to the SKEK are created. The SKEK is created and stored pending negotiation. • The key table is updated to show the SKEK pending negotiation.

  19. States in GKMP • State 6: • The permission certificate is retrieved and validated • The group token is retrieved and validated • The token version number is checked • The group ID specified in the token is stored. • The controller ID specified in the token is compared with the GC ID. If they do not match the exchange is terminated. • The local permissions are compared to the permissions specified for the group. If they do not meet or exceed the group permissions the exchange is terminated and a report is generated. • The re-key interval specified in the token is stored locally. • The key table is updated to reflect the key permissions, re-key interval, group ID and current time.

  20. States in GKMP • State 7: • The permission certificate is retrieved and validated using the security managers public key. The permissions of the message source are checked to verify they meet or exceed those of the group. • The key table is updated. • State 8: • The group ID is checked. • The group keys are decrypted using the SKEK. Data integrity checks are validated to ensure proper decryption. • The key table is updated to reflect the new group keys, key permissions, re-key interval, group ID and current time. • State 9: • Update group management log

  21. States in GKMP • State 10: • The permission certificate is retrieved and validated using the security managers public key. The permissions of the message source are checked to verify they meet or exceed those of the group. • The group token is retrieved and validated using the appropriate public key. • The token version number is checked to ensure the token is current. • The group ID specified in the token is checked. • The controller ID specified in the token is compared with the GC ID. If they do not match, the exchange is terminated. • The local permissions are compared to the permissions specified for the group. If they do not meet or exceed the group permissions the exchange is terminated and a report is generated. • The re-key interval specified in the token is stored locally. • The new group keys are decrypted with the current GKEK. The data integrity field is checked to ensure proper decryption. • The key table is updated to reflect the key permissions, re-key interval, group ID and current time.

  22. States in GKMP • State 11: • Validate signature using sources public key. • Check to see if member initiated group join is available. If not, ignore. If so begin distribution of group keys. • State 12: • Validate signature using GCs public. • Retrieve delete list. Check to see if on delete list, if so continue. • Create Grp_Keys_Deleted_Ack • Delete group keys • State 13: • Validate signature using GCs public. • Retrieve delete list. If list is global delete, verify alternative key. • Switch group operations to alternative key. • Create Grp_Keys_Deleted_Ack.. Delete group keys.

  23. Table of Some Data Primitives Used

  24. Table of Some Data Primitives Used

  25. Message Definitions • Command_Create Group: Group members, Grp ID, Grp controller ID, Grp action, Grp permissions, Rekey interval, Token version, Token signature, Token public key • Create Grp Keys_1: Grp ID, Request, GTEK ID, GKEK ID, GTEK creation field, GKEK creation field, Grp token, Controller signature, Controller public • Create Grp Keys_2: Grp ID, GTEK ID, GKEK ID, GTEK creation field, GKEK creation field, member signature, member public • Negotiate Grp Keys_1: Grp ID, TEK ID, KEK ID, Group token, Controller permissions • Negotiate Grp Keys_2: Grp ID, GTEK ID, GKEK ID, Member permissions • Create Session KEK_1: KEK for one time use between the GC and selected net member • Create Session KEK_2: KEK for one time use between the selected net member and GC

  26. Message Definitions • Negotiate Session Keys_1 : group ID, SKEK ID, CRL version number, Group token and GCs permissions • Negotiate Session Keys_2: identifies the group, SKEK, CRL version number and the member permissions • Download Grp Keys: GRP ID and Encrypted Grp Keys • Key download ack: GRP ID and Confirmation_decryption data items • Rekey _Multicast: Grp ID, GTEK ID, GKEK ID, Group token, Controller permissions • Request_Group_Join: Request, Grp ID, Member Signature, Member Public • Delete_Group_Keys: grp ID, Request, Member delete list, Controller signature, Controllers public • Grp_Keys_Deleted_Ack: grp ID, member ID, member signature, member public

  27. Message Definitions • Grp_Keys_Deleted_Ack: grp ID, request, member delete list, controller signature, controller public • Grp_Keys_Deleted_Ack : grp ID, member ID, member signature, member public

  28. Group Key Creation Group Controller (GC) Group initiator Command Create group to GC from Initiator State1(GC) – State2(GM): create group keys 1 State2(GM) – State2(GC): create group keys 2 State2(GC) – State3(GM): Negotiate group keys 1 State3(GM) – State4(GC): Negotiate group keys 2 Group Member (GM)

  29. Group Re-Key Create Session KEK_1(GC) – State 5 (GM) State 5(GM) – State 5(GC): Create Session KEK_2 State 5(GC) – State 6(GM): Negotiate Sess keys 1 State 6(GM) – State 7(GC): Negotiate Sess keys 2 State 7(GC) – State 8(GM): Download Grp Keys State 8 (GM) – State 9(GC): Key download ack Group Controller (GC) Group Member (GM)

  30. Member Initiated Join Group Controller (GC) Request_Group Join GM - GC State 11(GC) – State 5(GM): Create Session KEK_1 State 5(GM) – State 5(GC): Create Session KEK_2 State 5(GC) – State 6(GM): Negotiate Sess keys 1 State 6(GM) – State 7(GC): Negotiate Sess keys 2 State 7(GC) – State 8(GM): Download Grp Keys State 8(GM) – State 9(GC): Key Download Ack Group Member (GM)

  31. Types of Member Deletion • Cooperative Deletion: • Occurs between a trusted member and the GC. • It results in a reliable deletion of the group key encryption and GTEKs at the deleted member • Hostile Deletion: • Occurs when the group losses trust in a member • Essentially create another group, minus the untrusted member, and transfer group operations to that new group • When the group losses trust in the controller, another controller must be appointed and then the hostile deletion process can proceed • There are some security and operational management issues surrounding compromise recovery. The essence of the issues involve a tradeoff between operational continuity and security vulnerability

  32. Member Deletion Group Controller (GC) GC – State 12 (GM): Delete_Group_Keys State 12 (GM) – State 9(GC): Group_Keys_Deleted_Ack Group Member (GM)

  33. Restrict Access of Compromised Members • Mechanisms to restrict access: • Method 1: - GKMP implements a Certificate Revocation List (CRL) which is checked during the group creation process - it will not allow a compromised member to be included in a new group • Method 2: - GKMP facilitates the creation of another group (minus the compromised member(s)) - it does not dictate whether or not the group may continue to operate with a compromised member • The mechanism the GKMP uses to remove a compromised member is to key that member out • This entails creating a new group, without the compromised member, and switching group operations • The old group is canceled by several multicasts of a group delete message

  34. Issues in GKMP • Error conditions • Multi-level secure (MLS) environment • Access control • Commercial vs. Military • Algorithm Type • Management Philosophy • Receiver initiated operation • Security conditions

  35. References • RFC 2093 Group Key Management Protocol (GKMP) Specification – H. Harney, C. Muckenhirn. SPARTA, Inc. July 1997 • RFC 2094 Group Key Management Protocol (GKMP) Architecture – H. Harney, C. Muckenhirn. SPARTA, Inc. July 1997 • Unicast vs. Multicastover Wireless: A Cross Disciplinary Mindshare for Educational Application Researchers – Patrick Bristow • Techniques and Issuesin Multicast Security – Peter S. Kruus, Joseph P. Macker. Naval Research Laboratory

  36. Thank You

More Related