Group Key Management Architecture
Howie Weiss
NASA/JPL/SPARTA
hsw@sparta.com
Sepucha_Date_01
Types of Key Management
• Manual key generation & distribution
– Hardcopy, paper tape, key cards, floppy disks, magnetic
tape
– Hand carried and manually loaded
• Electronic key generation & distribution
– EKMS (electronic key management system)
» LMD/KP (local KPs, dial-up to download keys)
» KDC (e.g., STU-III Central Facility, STU-II Bellfield)
• Public Key
– Key agreements between key pairs
» Public/private key negotiation to establish
symmetric key
• Group Key
– Generate, distribute, manage keys and policies for a
group of systems
Sepucha_Date_02
We Gotta Get Away From This…
Bank of KW-26s in service from
‘60s – ‘80s.
Sepucha_Date_03
A Bit Better ….
•Key order processing
•Electronic generation & dist
•FIREFLY generation
•Seed Key conversion
•CRL
•OTAR
•Central Office of Record
•Phys key dist
•Elect key dist
•Key generation
•Key ordering
•KYK-13
•KOI-18
•CYZ-10
•New fill devices
•KOK-22 Key Processor
•Local key generation
•Digital signature
Sepucha_Date_04
IPsec Requirements
• IPsec “lives” between the network (IP) layer and
transport (TCP or UDP) layer
• Requires a “security policy database” to determine
what services are applied to what connections
– E.g., connection A-B requires encryption+auth
– E.g., connection C-D requires encryption
– E.g., all other connections require no security services
• Crypto keys
– Manually loaded, or
– IKEv2 negotiated
• Policy:
– Manually loaded in each individual device, or
» RFC 4807 (IPsec Security Policy Database
Configuration MIB)
» IPsec Security Policy IPsec Action MIB (ID)
» IPsec Security Policy IKE Action MIB (ID)
Sepucha_Date_05
Application Layer Security
• A la SSL/TLS (but TBD)
• Requires keys
– SSL/TLS would use Diffie-Helman key negotiation
which may not be possible for Cx flight systems.
– Pre-shared symmetric keys a la RFC 4279.
» e.g., TLS_PSK_WITH_AES_128_CBC_SHA
• Requires policy
– SSL/TLS really has no policy database
– “https” == encrypt connection
– Mutual authentication (dual cert) vs. server-side
authentication (single cert)
• Messaging security
– Pub/Sub messaging security mechanims
Sepucha_Date_06
Conundrums
• Keys are required by heterogeneous systems
• Policy is required by heterogeneous systems
• Ground/Mission systems have good, broadband
connectivity
• Space systems may have intermittent, lossy, and
limited bandwidth connectivity
Sepucha_Date_07
So…..
• Public Key technology and Electronic Key Distribution
are the ‘modern’ ways to generate and distribute keys,
but…….
– Not a problem for ground-based systems with good
connectivity
– Can be a problem for space-based systems with not so
good connectivity
Sepucha_Date_08
Therefore…..
• How do we combine ‘modern’ electronic key
distribution with varying types of connectivity across
the entire program?
– 1) go with PKI and hope for the best (a la cellular phone
systems)?
– 2) use only PKI in control centers and do something
else for space?
– 3) use symmetric keys everywhere and deliver them
manually (e.g., floppy, flash drive, paper tape)?
– 4) LMD/KP local site generation and manual loading?
– 5) Central key distribution center (KDC) that all systems
must contact to obtain keys?
– 6) ‘Group keying’ techniques doing what’s best and
available for the given part of the system?
Sepucha_Date_09
Group Key Overview
• From RFC 2094:
– “GKMP combines techniques developed for creation of
pair-wise keys with techniques used to distribute keys
from a KDC (i.e., symmetric encryption of keys) to
distribute symmetric key to a group of hosts.”
• Defined in RFC 4535 - GSAKMP: Group Secure
Association Key Management Protocol
– Parameters for a given GSAKMP group are provided in
the Group Security Policy Token, whose structure is
defined in RFC 4534
Sepucha_Date_010
Group Security
• Use of cryptography to protect data shared between
multiple endpoints
– Encryption of data
» Network layer
» Application layer
– Key management for groups
» Definition of mutual suspicious key exchanges for groups
» Security policy and policy dissemination
» Key creation and dissemination
– Security management for groups
» Scalability of security infrastructure
» Coalitions and diverse mechanisms
» Low latency group establishment
» Management of group membership
Sepucha_Date_011
GSAKMP Entities
• Group Owner
– responsible for creating the security policy rules for a group
and expressing these in the policy token
• Group Controller/Key Server
– responsible for creating/obtaining keys, maintaining the keys,
and enforcing the group policy by granting access to potential
Group Members (GMs) in accordance with the policy token
– In a distributed mode, there can be multiple subordinate
GC/KSs
• Group Member
– responsible for verifying key and policy disseminations and
for protecting group data according to group policy
Sepucha_Date_012
GSAKMP Architecture
Group Owner
Policy
Group
Controller/Key
Server
Sub
GC/KS
M
M
Sub
GC/KS
M
M
Policy & Keys
[Keys]
Key
Infrastructure
Sub
GC/KS
M
Sub
GC/KS
M
M
M
Sepucha_Date_013
Group Trust
Group policy vs. Peer Policies
Alice
Bob
Bob
Alice
Sue
?
•A and B have 1st hand knowledge
•A and B are sharing their own data
•A and B participate in key creation
•A and B have 1st hand knowledge
•A and S have 1st hand knowledge
•B and S have never communicated
•Who owns the data?
•How can S trust B? B trust S?
•Was the A to B key exchange as strong
As the A to S exchange?
•Will A and B protect the data equally?
•Is A authorized to distribute key?
•Is A controlling the group?
Sepucha_Date_014
GSAKMP / Group Policy
• Must support mutual suspicion
– All actors must prove they are authorized
» Policy creation authorities
» Key dissemination
» Key possession
» Group management
• Must provide flexible group definitions
– Rule based access control
» Limited only by infrastructures available
– Mechanism flexibility
» Algorithms
» Infrastructures
» Protocols
– Operational flexibility
» Group management
» DoS controls
» Protocol latency controls
Sepucha_Date_015
GSAKMP - Group Joins
•
Group
Controller
Member
Member
Member
•
•
•
Member
Member
Member
Member
Group Controller
– Defines group policy
– Creates initial keys
Members join the group
– Can become subordinate GCs
– Can be key consumers
Member can get keys from GC or S-GC
Group membership is managed using
group cryptography
– One message can reconfigure
membership of receivers
Member
Member
Member
Member
Member
Sepucha_Date_016
Binary Key Trees
A
C
1
1,C,A
B
D
2
3
2,C,A
3,DA
E
4
4,DA
5
5,E,B
F
6
7
8
6,E,B
7,F,B
8,F,B
Sepucha_Date_017
Bottom Line
• GSAKMP can provide key and policy management for
scalable groups (large or small).
• Group members can perform a full, negotiated group
join or can just receive keys from a group or sub-group
controller
• Combines the best of public key, symmetric key, and
policy management.
• Can provide keys (with work on the host side) to
applications, IPsec (using multicast SAs), and even
bulk encryptors if they can be controlled by the
system.
Sepucha_Date_018
By The Way…..
• Cisco is using an alternative group key (GDOI – RFC
3547) to more easily establish VPN groups.
Sepucha_Date_019