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.

1. DDS Security
[PrismTech Initial Submission for the OMG RFP mars/2010-12-37]
Angelo CORSARO, Ph.D.
Chief Technology Officer
OMG DDS Sig Co-Chair
PrismTech
angelo.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 Properties
This 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 & DTLS
TLS 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 doesn't 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