dds security
DESCRIPTION
This presentation provides an overview of the initial submission to the OMG RFP on DDS Security. The presentation introduces the overall security model proposed for DDS and the protocols.TRANSCRIPT
Angelo CORSARO, Ph.D.Chief Technology Officer OMG DDS Sig [email protected]
DDS Security [PrismTech Initial Submission for the OMG RFP mars/2010-12-37]
Copyrig
ht 2010, PrismTech – A
ll Rights Reserved.
Agenda¨ Context
¨ Security Model
¨ Transport Security
¨ Key Distribution
¨ Data Protection
¨ Next Steps
Copyrig
ht 2010, PrismTech – A
ll Rights Reserved.
The DDS Security specification focuses on three orthogonal aspects
¨ A definition of the DDS security model
¨ A set of API defining the interface for pluggable security plugins
¨ A set extensions to the DDSI/RTPS protocol to enable interoperable security
Context
Copyrig
ht 2010, PrismTech – A
ll Rights Reserved.
Submission Approach¨ Address key requirements commonly raising in
systems and system of systems
¨ Allow both endpoint as well as perimeter security approaches
¨ Leverage existing standards when possible
¨ Preserve DDS scalability do not limit the use of multicast when available
Copyrig
ht 2010, PrismTech – A
ll Rights Reserved.
Security PropertiesThis submission focuses on providing DDS with the following desirable properties:
¨ Confidentiality of the data samples being exchanged
¨ Integrity of DDS messages, data and the overall system
¨ Authentication of DDS readers and writers
¨ Authorization of DDS Entities (e.g. DomainParticipants, DataReader, DataWriters)
¨ Non-repudiation of data being sent
¨ Availability
Security Model
Copyrig
ht 2010, PrismTech – A
ll Rights Reserved.
What can I Access?¨ The submission proposes to define the security policies in terms of
operations that “Subjects” can perform on “Objects”
¨ This submission considers the following classification: ¨ Subjects
¨ DomainParticipants¨ Objects
¨ Topics
¨ As a consequence a DomainParticipant might be provided with rights to Create, Read, Update or Dispose Topics or a specific set of Topics
Copyrig
ht 2010, PrismTech – A
ll Rights Reserved.
What can we secure?This submission provides two composable level of security
¨ Topic-Level¨ A topic can be secure as a whole thus making its access unavailable
to un-authorized applications
¨ Attribute-Level¨ An attribute can be “obfuscated” to further control its availability. In
this case some DomainParticipants might have the right to see the Topic but not the specific attribute
Examples
Copyrig
ht 2010, PrismTech – A
ll Rights Reserved.
Topic Security
¨ The entire topic content is secured
¨ Uniform access to topic attributes is provided to authorized users
DDS Core
DDS Application
Data Sample
DDS Durability Service
DDS Application
DDS Core
xxxxx
xxxxxxxxxx
xxxxx
xxxxxxxxxx
Payload encipherment
in Core
HashHash
HashHash
Hash
Hash
enum BloodType { A, B, AB, O, An, Bn, ABn, On };struct Person { string name; string surname; string ssn; string email; sequence<string> telephone; sequence<string> pathologies; BloodType bloodType; long salary };
Copyrig
ht 2010, PrismTech – A
ll Rights Reserved.
Field-Based Security¨ Sometimes, for a secured
topic you need to provide non-uniform access to some of its fields¨ example: Salary, Medical
Records, etc.
¨ Field-based security provides a way to control access at a field level via security containers
¨ Field-based security can be overlaid over a secure topic
enum BloodType { A, B, AB, O, An, Bn, ABn, On };struct Person { string name; string surname; string ssn; string email; sequence<string> telephone; @protected sequence<string> pathologies; BloodType bloodType; @protected long salary };
DDS Application
Data Sample
DDS Core
DDS Durability Service
DDS Application
DDS Core
xxxxx
xxxxxxxxxx
xxxxx
xxxxxxxxxx
xxxxx
xxxxx
Hash
xxxxx
xxxxx
Hash
xxxxx
xxxxx
Hash
xxxxx
xxxxx
Hashxxxxx
xxxxx
Hash
Field encipherment by
application
Copyrig
ht 2010, PrismTech – A
ll Rights Reserved.
Field vs. Topic Security¨ The current proposal makes Topic security completely transparent to
the application
¨ The infrastructures takes care of transparently dealing with key distribution, encryption, decryption, etc.
¨ Field-based security is based on the concept of security container
¨ The infrastructure generates secure containers for “secured-fields” but will not automatically distribute keys
¨ The keys necessary to “open” the secured field are to be distributed by an application specific logic. Notice that a specific secure topic could be used for this purpose
Transport Security
Copyrig
ht 2010, PrismTech – A
ll Rights Reserved.
TLS & DTLSTLS and DTLS are commonly used cryptographic protocols in “client/server” applications. However for DDS they present some shortcomings
¨ TLS and DTLS use in-band, blocking key-negotiation, in the default setup, thus interrupting the data exchange for a non-predictable amount of time
¨ At anytime one of the two peers may initiate a key re-negotiation, causing interruption of the data-transfer until a new session-key has been negotiated.
¨ A major drawback is that both, TLS and D-TLS, can not deal with multicast communication. A TLS based transport security would degrade a DDS system to a client-server system. Both, TLS and DLTS, are not suited for DDS transport layer security protocols.
Copyrig
ht 2010, PrismTech – A
ll Rights Reserved.
SRTP & DDS¨ The Secure Real-time Transport Protocol (or SRTP) defines a
profile of RTP (Real-time Transport Protocol), intended to provide encryption, message authentication and integrity, and replay protection to the RTP data in both unicast and multicast applications It was first published by the IETF in March 2004 as RFC 3711.
¨ This submission proposes the use of the SRTP approach for securing DDS transport while maintaining support for unicast and multicast!
Key Distribution
Copyrig
ht 2010, PrismTech – A
ll Rights Reserved.
MIKEY & DDS¨ The Multimedia Internet KEYing (MIKEY) is a key management protocol that is
intended for use with real-time applications. It can specifically be used to set up encryption keys for multimedia sessions that are secured using SRTP. MIKEY is defined in RFC 3830.
¨ MIKEY supports five different methods to set up a Common Secret:¨ Pre-Shared Key (PSK): This is the most efficient way to handle the transport of the Common Secret,
since only symmetric encryption is used and only a small amount of data has to be exchanged. ¨ Public-Key: The Common Secret is exchanged with the help of public key encryption. ¨ Diffie-Hellman: A Diffie-Hellman key exchange is used to set up the Common Secret. ¨ DH-HMAC (HMAC-Authenticated Diffie-Hellman): This is a light-weight version of Diffie-Hellman MIKEY¨ RSA-R (Reverse RSA): The Common Secret is exchanged with the help of public key encryption in a
way that doesn't require any PKI
¨ The RSA-R method is the appropriate concept for DDS (see submission for details)
Data Protection
Copyrig
ht 2010, PrismTech – A
ll Rights Reserved.
Payload Protection¨ The header contains the relevant
attributes to fetch the required secrets and keys from originator or key-archive
¨ The key-archive shall operate similar to a durability service, storing keys for late joiners
¨ The tail contains the digest, which allows to verify integrity of the payload
¨ The concept of header and tail allows re-fragmentation of the serialized data
Data Submessage
Payload Security HeaderDATA header Security Tail
Copyrig
ht 2010, PrismTech – A
ll Rights Reserved.
Next Steps
¨ Detail the use of SRTP and MIKEY in the context of the DDSI/RTPS wire-protocol
¨ Finalize the API for security plugin
¨ Vote for adoption
Copyrig
ht 2010, PrismTech – A
ll Rights Reserved.
:: Connect with Us ::
¥ @prismtech
¥ @acorsaro
¥ youtube.com/opensplicetube ¥ slideshare.net/angelo.corsaro
¥ [email protected]¥ [email protected]
¥ opensplice.com ¥ forums.opensplice.org
¥ opensplice.org ¥ [email protected]