Scalable and Interoperable DDS Security

Transcription

1 Scalable and Interoperable DDS Security Angelo CORSARO, Ph.D. Chief Technology Officer OMG DDS Sig Co-Chair PrismTech

2 DDS Security Approaches

3 Trusted Environment Most DDS-based applications run today under a trusted environment assumption These applications are secure so long as the the trusted environment hypothesis holds true Trusted Environment

4 Perimeter Security Small scale DDS-based Systems of Systems are integrated using the perimeter security model Under this model, each system/subsystem is considered to run in a trusted/ controlled environment, but their interconnection happens over an untrusted/uncontrolled environment Trusted Environment System B Trusted Environment System A Secure Communication Trutsted Environment System C Untrusted Environment

5 Perimeter Security Secure information exchange is implemented in this case by simply securing the point-to-point communication between any-two systems/ subsystems Trusted Environment System B Trusted Environment System A Secure Communication Trutsted Environment System C Untrusted Environment

6 Perimeter Security in DDS

7 DDS Tunneling The secure channel between the two system can be easily implemented by tunneling DDS traffic over a secure connection, using TLS/DTLS or IPSec However this approach does not provide a way of policing what is securely shared, e.g., once network connectivity is available between the two system/subsystem anything becomes visible Trusted Environment System B Secure Communication Untrusted Environment Trusted Environment System A

8 Mediated DDS Tunneling A Mediator can be used for controlling was is safe to expose Notice that the choice is not always binary, meaning yes/no In some cases, some data can be exposed only with degraded quality Trusted Environment System B Mediator Secure Communication Untrusted Environment Trusted Environment System A

9 DDS Tunneling in Action

10 TCP/UDP Tunneling DDS Domain 0 Integrate different DDS Domains via TCP (or UDP) tunnel Per Topic bridging Unidirectional or bidirectional Possibly adding SSL/TLS 1 // on GW1: 2 from("ddsi:circle:0/shapetype") 3 to("netty:tcp://localhost:6789?sync=false"); 1 // on GW2: 2 from("netty:tcp://localhost:6789?sync=false") 3 to("ddsi:circle:0/shapetype"); Topic Circle GW 1 GW 2 TCP Topic Circle DDS Domain 0

11 HTTP/HTTPS Tunneling DDS Domain 0 Integrate different DDS Domains via HTTP/HTTPS tunneling Per Topic bridging Unidirectional or bidirectional 1 // on GTW1 2 from("ddsi:circle:0/shapetype") 3 unmarshal("cdr") 4 marshal().json() 5 to("jetty: 1 // on GTW1 2 from("jetty: 3 unmarshal().json() 4 marshal("cdr") 5 to("ddsi:circle:0/shapetype"); Topic Circle GW 1 GW 2 Topic Circle HTTP DDS Domain 0

12 Limitations of Boundary Security The trusted environment assumptions is sometimes too strong Point-to-Point integrations works fine only at a small scale No support for multicast communication Some of the security protocol, e.g. TLS/DTLS, used to do boundary security can create Limited support for sophisticated secure data sharing schemes (more in next slides...) Trusted Environment System B Secure Communication Untrusted Environment Trusted Environment System A

13 Toward Scalable and Interoperable DDS Security

14 A Case Study: SESAR Flight Objects will be shared through DDS at a pan-european level using DDS Not only, FlightObjects need to be securely shared among ATC/ ATM actors, but different portion of the flight object might be made available Due to the scale and traffic volumes the use of multicast is highly desirable

15 DDS Security

16 DDS Security RFP 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

17 Overall 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

18 Security 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

19 Security Model

20 What can I Access? Security policies are expressed in terms of operations that Subjects can perform on Objects 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

21 What can we secure? Two composable level of security are provided: Topic-Level A topic can be secured as a whole making its access unavailable to unauthorized/untrusted 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

22 Examples

23 Topic Security The entire topic content is secured Uniform access to topic attributes is provided to authorized users enum BloodType { A, B, AB, O, An, Bn, ABn, On }; struct Person { string name; string surname; string ssn; string ; sequence<string> telephone; sequence<string> pathologies; BloodType bloodtype; long salary }; DDS Application DDS Core Hash Payload encipherment in Core Data Sample Hash DDS Durability Service Hash DDS Application DDS Core Hash

24 Attribute Security Sometimes, for a secured topic you need to provide nonuniform 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 ; sequence<string> sequence<string> pathologies; BloodType long salary }; DDS Application DDS Core Hash Field encipherment by application Data Sample Hash DDS Durability Service Hash Hash DDS Application DDS Core Hash

25 Field vs. Topic Security Topic security completely transparent to the application The infrastructures takes care of dealing with key distribution, encryption, decryption, etc. Field-based security is based on the concept of security containers 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

26 Transport Security

27 TLS & DTLS TLS 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, cannot 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.

28 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 An approach similar to SRTP can be used for securing DDS transport while maintaining support for unicast and multicast!

29 Projecting SRTP to DDSI <+ R T P S Protocol Version Vendor ID GUID Prefix > payload ( DDSI Packet) padding pad count +> <+ ~ SRTP MKI (OPTIONAL) ~ : authentication tag (RECOMMENDED) : Encrypted Portion* Authenticated Portion ---+ The "Encrypted Portion" of an SRTP packet consists of the encryption of the RTP payload (including RTP padding when present) of the The MKI (Master Key Identifier) is defined, signaled, and used by key management. The MKI identifies the master key from which the session key(s) were derived that authenticate and/or encrypt the particular packet. The authentication tag is used to carry message authentication data. NOTE: The GUID Prefix is used as the Synchronization source (SSRC) identifier in RTP

30 Key Distribution

31 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 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

32 Next Steps

33 DDS Security Standardization We are working with other vendors to standardize a Scalable and Interoperable DDS Security protocol The standardization process is current at the revised submission step Finalization is expected by the end of the year

34

35 :: Connect with Us :: opensplice.com opensplice.org youtube.com/opensplicetube