SGLv2: The Secure Group Layer

1
C O M P U T A T I O
N A L R E S E A R
C H D I V I S I O N
SGLv2 The Secure Group Layer Guillaume
Egles Thursday, December 09, 2004
Project RSGC (Reliable and Secure Group
Communication) Team Deborah Agarwal, Karlo
Berket, Abdelilah Essiari, Olivier Chevassut,
Guillaume Egles Web Page http//dsd.lbl.gov/rsgc
2
Summary

• Part 1 Introduction / background
• Part 2 Current state of SGL
• Part 3 using SGL
• Part 4 Future work
• Conclusion
• Questions

3
Introduction

• New types of multi-party applications are
  emerging
• Collaboratories (VRVS, AG, ..)
• File sharing (Scishare, ..)
• Peer-to-peer
• They need to communicate
• Reliably
• Not just on LANs, but over the Internet
• Across organizations
• In an ad-hoc manner (without central servers)
• Security is becoming essential.

4
Wanted Security

• Security features needed by applications
• Who can be in the group (access control)
• Who is in the group and when (secure memb)
• Confidentiality
• Authenticity
• Integrity
• Forward secrecy
• All of those over a public insecure network
  (Group Key Agreement)

5
2 Problems

• Inherent to those features lies 2 problems
• The N-party security problems
• Solved through cryptography theory (Oliviers
  work) and our experience in secure protocol
  design.
• The N-party communication problem
• Solved through reliable N-party communication
  theory and our experience (Totem, InterGroup).
• New challenge
• Collision of 2 complex worlds
• N-party communication security

6
2 vs N Security/Crypto

• 2-party
• Number of participants unchanging (2)
• Membership type static
• Key Exchange cost constant
• Encryption/Decryption cost constant
• N-party
• Number of participants variable
• Membership type dynamic
• Key Exchange cost depending on N
• Encryption/Decryption cost constant

7
2 vs N Key Exchange

• 2-party Diffie-Hellman Key Exchange

• N-party Group Diffie-Hellman Key Exchange
  (Oliviers work)

8
2 vs N Need for reliable communication

• Reliability becomes indirectly part of security
  (tied together)
• End-to-end argument
• How much of it do we implement ourselves ?
• How much can we re-use from the underlying layer
  (by just verifying its behavior) ?
• 2-party
• Problem is well-known and studied
• For example SSL leverages off of TCP and simply
  verifies its behavior
• N-party
• A lot more complex
• Variety of properties.
• Which one do we need, which one do we provide
• A variety of services
• Central server (inefficient)
• N x TCP connections
• Peer-to-peer
• Reliable multicast

9
Motivation for SGL

• Answer both the N-party security and the
  communication problems.
• TODO

10
SGL Goals

• Provide
• A framework for secure group communication
• Key agreement over insecure network
• Dynamic secure membership
• Data protection (confidentiality, auth,
  integrity)
• On top of a reliable transport protocol
• As transparent as possible for the application
• Scalable
• Extensible
• Different KEs
• Different ciphers
• Different membership policies

11
Our approach

• Come up with a framework similar to SSL but
  adapted to N-party communication
• Look at and understand SSL well
• Use our experience in group communication theory
• Divide and conquer approach to solve these
  complex/intricated problems.
• First focus on the overall system before focusing
  on the cryptographic details.

12
Summary

• Part 1 Introduction / background
• Part 2 Current state of SGL
• Part 3 Using SGL
• Part 4 Future work
• Conclusion
• Questions

13
High-level architecture
14
SGL Layer and Engine
15
SGL Layer and Engine

• SGL Layer
• manages both the transport and SGL (the engine).
• maintains a global state of the overall SGL
  system.
• Part of the RSGC stack
• SGL engine
• Maintains its own state.
• Assumes the transport is being handled by someone
  else.
• Standalone piece Can be used elsewhere

16
SGL Engine
17
ND and Memb

• ND
• Tells who will participate in the SGL membership.
• Only synchronous piece of the system (time-outs,
  etc..).
• Pluggable
• Memb
• Comes up with the new view (members viewId) the
  HS will then verify.
• Current impl
• Uses IG infos directly
• Direct mapping between IG and SGL members

18
The Handshake Protocol
19
The Handshake Protocol

• Cornerstone of the system
• Verifies the view and its members
• Comes up with the shared secret (key)
• Controls and configures the RL
• Controls the Application
• 3 phases
• Hello phase gathering of information
• Key Exchange Agree on a shared secret
• Flush phase verify the shared secret and
  synchronize all the members

20
The Hello Phase

• Hello message from each member
• Version
• Random value
• for the KE
• ViewId
• Id of the view this member is coming from
• CipherSuites
• List of the supported cipherSuites.
• Extensions
• List of extensions
• Certificate, Certificate URL, Member name, etc..

21
The Key Exchange

• There are a lot of different Group KE out there
• Not just different in the crypto (like the
  2-party ones)
• Different in the communication pattern
• Different in their potential optimization
• Pluggable interface (As generic/basic as
  possible)
• Provided with all the infos gathered by the Hello
  phase.
• One generic message with an opaque payload.

22
GDH Key Exchange

• 1 Implementation
• Based on Oliviers work
• Supports static and dynamic GDH
• TODO Maybe talk about cascading here
• 3 Flavors
• Anonymous
• Authenticated (X.509 Certificates)
• Encrypted (Shared password)

23
The Flush Phase

• Verifies the secret (through a hash)
• Provides a synchronization point between 2 views
• Stops the Application from sending
• Switches the RL progressively

24
The Record Layer
25
The Record Layer

• Standard crypto
• Encrypts/Decrypts messages for the upper
  protocols
• Controls that the transport protocol is behaving
  correctly (through sequence numbers)

26
The Application Protocol
27
The Alert Protocol
28
Summary

• Part 1 Introduction / background
• Part 2 Current state of SGL
• Part 3 Using SGL
• Part 4 Future work
• Conclusion
• Questions

29
Populate your SGLContext
30
Create a SGLChannel

• Channel Asynchronous API
• Equivalent of a socket, but adapted to group
  communication
• Join/Leave/Send calls
• onData/onView callbacks

31
Summary

• Part 1 Introduction / background
• Part 2 Current state of SGL
• Part 3 Using SGL
• Part 4 Future work
• Conclusion
• Questions

32
Testing/implementation

• Performance Testing
• Maximum number of members
• Time for the handshake in various scenarios
• Throughput/latency of the data communication
• Implement new ND/Memb(s) (independent from IG)
• Strict (like SSL)
• Loose (support network partitions and merges)
• Improve and verify the crypto details

33
Group Communication

• Lower the requirements on the properties of the
  transport layer
• From Total order to Source Order (i.e. N TCP
  connections)
• Provide more flexible properties to the
  application
• Some applications do not care in what view the
  message is received, but they care about being
  blocked or not.
• Use a formal method throughout SGL (leverage off
  the work done in IG)

34
Later

• Update and publish the SGL specification
• Incorporate new Key Exchanges
• Add an authorization policy system

35
Questions/information

• GEgles_at_lbl.gov
• Impl http//dsd.lbl.gov/rsgc
• Project http//dsd.lbl.gov/CIF/GroupComm