Sepucha_Date_01 Group Key Management Architecture Howie Weiss NASA/JPL/SPARTA [email protected].
-
date post
19-Dec-2015 -
Category
Documents
-
view
216 -
download
0
Transcript of Sepucha_Date_01 Group Key Management Architecture Howie Weiss NASA/JPL/SPARTA [email protected].
Sepucha_Date_01
Group Key Management ArchitectureGroup Key Management Architecture
Howie WeissNASA/JPL/[email protected]
Sepucha_Date_02
Types of Key ManagementTypes 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_03
We Gotta Get Away From This…We Gotta Get Away From This…
Bank of KW-26s in service from ‘60s – ‘80s.
Sepucha_Date_04
A Bit Better ….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
Sepucha_Date_05
IPsec RequirementsIPsec 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_06
Application Layer SecurityApplication 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_07
ConundrumsConundrums
• 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_08
So…..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_09
Therefore…..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_010
Group Key OverviewGroup 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_011
Group SecurityGroup 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_012
GSAKMP EntitiesGSAKMP 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_013
GSAKMP ArchitectureGSAKMP Architecture
Group Owner
Group Controller/Key
Server
Sub GC/KS
Sub GC/KS
Sub GC/KS
Sub GC/KS
M M M M M M M M
Key Infrastructure
Policy[Keys]
Policy & Keys
Sepucha_Date_014
Group Trust Group Trust Group policy vs. Peer PoliciesGroup policy vs. Peer Policies
Alice Bob
•A and B have 1st hand knowledge
•A and B are sharing their own data
•A and B participate in key creation
Alice Bob
Sue ?
•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 strongAs 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_015
GSAKMP / Group PolicyGSAKMP / 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_016
GSAKMP - Group JoinsGSAKMP - Group Joins
GroupController
MemberMember
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
MemberMember
MemberMember
MemberMember
MemberMember
Member
Member
Member
Member
Sepucha_Date_017
Binary Key TreesBinary Key Trees
1 2 3 4 5 6 7 8
A B
C D E F
1,C,A 2,C,A 3,DA 4,DA 5,E,B 6,E,B 7,F,B 8,F,B
Sepucha_Date_018
Bottom LineBottom 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.