Your SlideShare is downloading. ×

DDS Security

2,605
views

Published on

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.

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.

Published in: Technology

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
2,605
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
106
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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

×