190 likes | 333 Views
Group Key Management Architecture. Howie Weiss NASA/JPL/SPARTA hsw@sparta.com. 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
E N D
Group Key Management Architecture Howie Weiss NASA/JPL/SPARTA hsw@sparta.com
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
We Gotta Get Away From This… Bank of KW-26s in service from ‘60s – ‘80s.
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 • KOK-22 Key Processor • Local key generation • Digital signature • KYK-13 • KOI-18 • CYZ-10 • New fill devices
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)
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
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
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
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?
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
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
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
GSAKMP Architecture Group Owner Policy Group Controller/Key Server [Keys] Key Infrastructure Sub GC/KS Sub GC/KS Sub GC/KS Sub GC/KS Policy & Keys M M M M M M M M
Bob Alice Alice Bob 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? Group Trust Group policy vs. Peer Policies
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
GSAKMP - Group Joins Member Member Member Member Member 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 Group Controller Member Member Member Member
Binary Key Trees A B C D E F 1 2 3 4 5 6 7 8 1,C,A 2,C,A 3,DA 4,DA 5,E,B 6,E,B 7,F,B 8,F,B
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.
By The Way….. • Cisco is using an alternative group key (GDOI – RFC 3547) to more easily establish VPN groups.