1.
DDS Security[PrismTech Initial Submission for the OMG RFP mars/2010-12-37]Angelo CORSARO, Ph.D.Chief Technology OfficerOMG DDS Sig Co-ChairPrismTechangelo.corsaro@prismtech.com

2.
Agenda¨ Context Copyright 2010, PrismTech – All Rights Reserved.¨ Security Model¨ Transport Security¨ Key Distribution¨ Data Protection¨ Next Steps

3.
Context The DDS Security specification focuses on three orthogonal aspects Copyright 2010, PrismTech – All Rights Reserved. ¨ 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

4.
Submission Approach¨ Address key requirements commonly raising in Copyright 2010, PrismTech – All Rights Reserved. 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

5.
Security PropertiesThis submission focuses on providing DDS with the following desirable properties: Copyright 2010, PrismTech – All Rights Reserved.¨ 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

6.
Security Model

7.
What can I Access?¨ The submission proposes to define the security policies in terms of Copyright 2010, PrismTech – All Rights Reserved. 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

8.
What can we secure?This submission provides two composable level of security Copyright 2010, PrismTech – All Rights Reserved.¨ 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

9.
Examples

10.
Topic Security 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; Copyright 2010, PrismTech – All Rights Reserved. BloodType bloodType;¨ The entire topic long salary }; Payload content is secured encipherment in Core DDS Application DDS Application¨ Uniform access to xxxxx xxxxx Data Sample xxxxx xxxxx topic attributes is xxxxx Hash xxxxx DDS Core DDS Core provided to authorized Hash Hash Hash users DDS Durability Service Hash Hash

11.
Field-Based Security enum BloodType { A, B, AB, O, An, Bn, ABn, On }; struct Person {¨ Sometimes, for a secured string name; string surname; topic you need to provide string ssn; Copyright 2010, PrismTech – All Rights Reserved. string email; non-uniform access to sequence<string> telephone; @protected sequence<string> pathologies; some of its fields BloodType bloodType; @protected long salary }; ¨ example: Salary, Medical Records, etc. Field encipherment by application¨ Field-based security DDS Application DDS Application provides a way to control xxxxx xxxxx Data Sample xxxxx xxxxx Hash access at a field level via xxxxx xxxxx xxxxx DDS Core DDS Core security containers Hash xxxxx Hash xxxxx xxxxx¨ Field-based security can be xxxxx DDS Durability Service xxxxx Hash overlaid over a secure topic Hash xxxxx xxxxx xxxxx xxxxx

12.
Field vs. Topic Security¨ The current proposal makes Topic security completely transparent to Copyright 2010, PrismTech – All Rights Reserved. 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

13.
Transport Security

14.
TLS & DTLSTLS and DTLS are commonly used cryptographic protocols in “client/server” Copyright 2010, PrismTech – All Rights Reserved.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.

15.
SRTP & DDS¨ The Secure Real-time Transport Protocol (or SRTP) defines a Copyright 2010, PrismTech – All Rights Reserved. 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!

16.
Key Distribution

17.
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 Copyright 2010, PrismTech – All Rights Reserved. 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 doesnt require any PKI¨ The RSA-R method is the appropriate concept for DDS (see submission for details)

18.
Data Protection

19.
Payload Protection¨ The header contains the relevant attributes to fetch the required secrets Copyright 2010, PrismTech – All Rights Reserved. and keys from originator or key- archive¨ The key-archive shall operate similar to a durability service, storing keys for late joiners Data Submessage¨ The tail contains the digest, which DATA header Security Header Payload Security Tail allows to verify integrity of the payload¨ The concept of header and tail allows re-fragmentation of the serialized data

20.
Next Steps Copyright 2010, PrismTech – All Rights Reserved.¨ 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

21.
:: Connect with Us :: Copyright 2010, PrismTech – All Rights Reserved. ¥ opensplice.com ¥ forums.opensplice.org ¥ @acorsaro ¥ opensplice.org ¥ opensplicedds@prismtech.com ¥ @prismtech ¥ crc@prismtech.com ¥ sales@prismtech.com¥ youtube.com/opensplicetube ¥ slideshare.net/angelo.corsaro