Date post: | 08-May-2015 |
Category: |
Technology |
Upload: | gerardo-pardo-castellote |
View: | 630 times |
Download: | 0 times |
Your systems. Working as one.
RTI Technical Update
Focus: DDS Security
Gerardo Pardo-‐Castellote, Ph.D
CTO. Real-‐Time Innova:ons (RTI)
Prepared
February 2014
Technical Mee:ng Agenda
• DDS Background • Security Background • DDS Security Specifica:on • Discussion & Next Steps
3
DDS Background
3/17/14 © 2012 Real-‐Time Innova:ons, Inc. -‐ All rights reserved 4
Data-‐Centric Qos-‐Aware Pub-‐Sub Model
Persistence Service
Recording Service
Virtual, decentralized global data space
CRUD opera:ons
Source (Key) Speed Power Phase
WPT1 37.4 122.0 -12.20
WPT2 10.7 74.0 -12.23
WPTN 50.2 150.07 -11.98
Data Reader “Alarm”
Domain Par:cipant
Data Writer “Alarm”
Domain Par:cipant
Data-‐Centric Communica:ons Model
• ParDcipants scope the global data space (domain) • Topics define the data-‐objects (collec:ons of subjects) • DataWriters publish data on Topics • DataReaders subscribe to data on Topics • QoS Policies are used configure the system • Listeners are used to no:fy the applica:on of events
Listener Offered QoS Listener
Got new data
Requested QoS
New subscriber!
example
Data-‐Object Iden:ty in the Global Data Space
• Domain: world you’re talking about
• Topic: group of similar objects – Similar structure (“type”) what – Similar way they change when
over :me (“QoS”) how • Instance: individual object
– Like the “key” fields in a database table
• DataWriter: source of observa:ons about a set of data-‐objects (Topic)
• DataReader: observer of a set of data-‐objects (Topic)
Domain (e.g. Yellowstone Park)
Topic (e.g. bears in the park)
Topic Snow Depth Sensors
ID GPS value
ID GPS value
ID GPS value
ID GPS value
ID GPS value
ID GPS value
ID GPS value
ID GPS value
ID GPS value
ID GPS value
ID GPS value
ID GPS value
ID GPS value
ID GPS value
ID GPS value
ID GPS value
ID GPS value
ID GPS value
ID GPS value
ID GPS value
ID GPS value
ID GPS value
ID GPS value
Instance (e.g. Yogi the bear)
Instance
Object Address == Object Iden:ty
Sample Iden:fica:on need
• DataReaders must be able to combine the samples from mul7ple physical data sources publishing from related logical data source(s).
• Example: MulD-‐Path Delivery
• Example: Cross-‐Topic Ordering
8
DataReader
Durability Service
DDS Domain
“PosiDon” DataReader
“PosiDon” DataWriter
“Velocity” DataWriter
DDS Domain
“Velocity” DataReader
Subscriber Publisher
Global Sample Iden:fica:on
Each sample within a Domain and a Topic is uniquely iden:fied by a virtual iden:ty: the tuple (Virtual GUID, Virtual SequenceNumber) – Virtual GUID (VGUID): 16-‐byte iden:fier iden:fying the data source. – Virtual Sequence Number (VSN): monotonically increasing 64-‐bit integer that iden:fies the sample in the data source.
DataWriter
DataWriter
DataWriter
DataBus Domain DataReader
(1,1)
(1,1)
(1,1)
(1,1)
(2,1)
(2,1)
(1,1) (2,1)
A DataReader only delivers a single copy of a sample to the applica:on. Duplicates are filtered out.
(2,1) Sample with VGUID 2 and VSN1
Approaches to Sogware Integra:on
App
App
App App
App
App Point-‐to-‐point
Not maintainable: -‐ Number of interfaces grows as Modules^2 -‐ Add hoc integra:on makes reuse difficult -‐ Addi:on of new modules affects exis:ng ones
Approaches to Sogware Integra:on
App
App
App App
App
App Point-‐to-‐point
App
App
App App
App
App Server/ Broker/ ESB
Inefficient, not-‐robust, and expensive: -‐ Centralized server becomes boFleneck -‐ Server or server-‐comm failure compromises system -‐ Server is hard to deploy, power, hide
Approaches to Sogware Integra:on
DDS Data-‐Centric Bus
App App App App App App
App
App
App App
App
App Point-‐to-‐point
App
App
App App
App
App Server/ Broker/ ESB
Superior approach: -‐ Number of interfaces can be constant or linear -‐ No servers => performance & availability -‐ Lower cost in hardware & soMware maintenance
Architecture to maximize Availability, Performance & Scalability
• RTI Connext DDS operates peer-‐to-‐peer, without brokers
• RTI Connext DDS uses RTPS, an Advanced Mul7-‐Session protocol suppor7ng Reliable Mul7cast
RTI Connext DDS Approach
RTPS
JMS AMQP ESBs …
Others: Broker-‐based middleware
13 © 2010 Real-‐Time Innova:ons, Inc.
Security Background
3/17/14 © 2012 Real-‐Time Innova:ons, Inc. -‐ All rights reserved 14
Is there a Conflict?
• Security… – desires to restrict communica:on to only happen between authorized subjects
– requires to confiden:ality so that only communica:ng subjects see the informa:on
• PubSub/DDS – alempts to create a ‘global informa:on space’ where anybody can access the informa:on it needs
– de-‐couples communica:ons so publishers are unaware of subscribers and vice-‐versa
© 2007, Real-‐Time Innova:ons, Inc. 15
No Conflict: Security in the Global Informa:on Space
• Publishers are decoupled from subscribers via the Global Informa:on Space – This does not mean loss of access control to the informa:on
– It means that the Informa:on Space must have an associated security model
• DDS can use standard PKI and cryptographic techniques to enforce the security policies
• The situa:on is analogous to access control policies in a file system
© 2007, Real-‐Time Innova:ons, Inc. 16
The key is to use a net-‐centric security model!
Security Terms: a Safe-‐Deposit Box
• Authen:ca:on: The bank knows who you are; you must show ID.
• Access Control: The bank only lets those on an access list into your box.
• Confiden:ality: You are alone in the room Nobody can see the contents of the box.
• Integrity: The box is sealed. If anybody touches it you will know.
• Non repudia:on: You sign when you come in and out so you can’t claim that you weren’t there.
• Availability: The bank is always open. 1717
Threats 1. Unauthorized subscrip:on 2. Unauthorized publica:on 3. Tampering and replay 4. Unauthorized access to data
by infrastructure services
3/17/14 © 2012 Real-‐Time Innova:ons, Inc. -‐ All rights reserved 18
Alice: Allowed to publish topic T Bob: Allowed to subscribe to topic T Eve: Non-‐authorized eavesdropper Trudy: Intruder Trent: Trusted infrastructure service Mallory: Malicious insider
Data-‐centric/mul:cast Insider Threats
• Two insider threats affec:ng (mul:cast) data-‐centric systems are of unique significance 1. Reader mis-‐behaves as unauthorized writer
An applica:on uses knowledge gained as authorized reader to spoof the system as a writer
2. Compromise of Infrastructure Service A service that is trusted to read and write data on behalf
of others (e.g. a persistence service ) becomes compromised
3/17/14 © 2012 Real-‐Time Innova:ons, Inc. -‐ All rights reserved 19
Reader mis-‐behaves as unauthorized writer
• Situa:on: – Alice -‐ creates a Crypto Key per Topic/DataWriter – Alice -‐ shares its Key with all intended readers as needed to mul:cast – Mallory – is an authorized reader so it has Alice’s key – Mallory – behaves maliciously and uses Alice’s key to create fake UDP messages puung
Alice’s informa:on (IP, Port, GUIDs, etc.) but with bad data.
• Implica:ons: – Bob sees message from Mallory and processes it believing it is from Alice – Mallory can provide a system-‐wide failure for all subscribers to topic T, making them
process wrong data, delete instances, – Depending on the Topic this can be catastrophic for the system
• Notes: – The problem is that all secrets shared by Alice and Bob are also known to Mallory
• So the alack cannot be solved with a MAC or HMAC if Alice’s key is also shared with all readers…
– The problem can be solved with a digital signature but that is 1000X slower than a MAC
3/17/14 © 2012 Real-‐Time Innova:ons, Inc. -‐ All rights reserved 20
Session Sequence Number Alack • Background:
– Reliable protocols rely on a session_id and a sequence number to avoid duplicates and detect message loss
– RTPS protocol can use GAP messages and HeartBeat messages to advance the session (DataWriter) sequence number
• Vulnerability: – An alacker can spoof a packet with the session ID and Hearbeat/GAP causing the DataReader to advance the session sequence-‐numbers blocking future messages recep:on
– Alacker only needs GUID of the DataWriter to alack, which can be obtained from snooping traffic.
– Alack can be used to prevent the Authen:ca:on of legi:mate Par:cipants
3/17/14 © 2012 Real-‐Time Innova:ons, Inc. -‐ All rights reserved 21
Squaung Alack on GUID • Background:
– DDS DomainPar:cipants are iden:fied by unique GUID, Readers/Writers derive their GUID from it.
– GUID used to uniquely iden:fies the RTPS sessions and the loca:on of each par:cipant
• Vulnerability: – An alacker with legit Iden:ty can authen:cate using the GUID of another Par:cipant
– Alacker with be accepted with “cuckooed” GUID blocking legi:mate Par:cipant from using its GUID
– Alacker only needs GUID of the Par:cipant to alack, which can be obtained from snooping traffic.
3/17/14 © 2012 Real-‐Time Innova:ons, Inc. -‐ All rights reserved 22
Fine-‐Grained Data-‐Centric Security
• Access control per Topic • Read versus-‐write permissions
• Field-‐specific permissions
3/17/14 © 2012 Real-‐Time Innova:ons, Inc. -‐ All rights reserved 23
Topics
Three security boundaries
• Boundary security
• Transport-‐Level – Network (layer 3) security – Session (layer 4/5) security
• Fine-‐grained Data-‐Centric Security
3/17/14 © 2012 Real-‐Time Innova:ons, Inc. -‐ All rights reserved 24
UlDmately you need to implement the 3 of them
Secure Data Transfer
1. Authen:cate – Verify your iden:ty
2. Securely exchange cryptographic keys 3. Use keys to:
– Encrypt data – Add a message authen:ca:on code
3/17/14 © 2012 RTI • COMPANY CONFIDENTIAL 25
App 1 App 2
Transport Layer Security (TLS) for DDS
• Provides – Authen:ca:on and key exchange – Encryp:on with symmetric keys
– Message authen:ca:on
• Proven and widely used – Web browsing, email, IM, VoIP
– Client-‐server – Primarily used over TCP but there is also a UDP version (DTLS)
3/17/14 © 2012 RTI • COMPANY CONFIDENTIAL 26
Transport Layer Security (TLS) for DDS
3/17/14 © 2012 RTI • COMPANY CONFIDENTIAL 27
TLS Handshake Protocol
TLS Record Protocol
TCP/IP
DDS
Applica:on 1
TLS Handshake Protocol
TLS Record Protocol
TCP/IP
DDS
Applica:on 1
PKI Cer:ficate Exchange, Verifica:on, Crea:on of Session Keys
Encrypted, & Signed Traffic
RTPS Traffic
Secure Discovery and Data Exchange
TLS/TCP for Real-‐Time Systems
• DDS typically runs over UDP/IP – Runs in best-‐effort mode for sensor data
– Reliable mode – tuned for real-‐:me
• Performance challenges with TCP – Latency – more jiler for sensor data, generally higher
– Throughput
3/17/14 © 2012 RTI • COMPANY CONFIDENTIAL 28
29
(D)TLS Transport for DDS
• DTLS: Datagram version of the TLS protocol
• Like TLS provides: AuthenDcaDon, encrypDon, integrity • Requires:
– A Cer:ficate Authority (CA) – An applica:on must be configured with an iden:fying cer:ficate assigned by the CA
– An applica:on must have a private key associated with the public key in the cer:ficate
• Standard protocol ( with open source: OpenSSL ) – The protocol is highly scru:nized – No mulDcast support This transport is available in
Connext DDS 4.5 and 5.0
DTLS Performance – Latency
3/17/14 © 2011 Real-‐Time Innova:ons, Inc. COMPANY CONFIDENTIAL 30
Secure Transport-‐Level Solu:ons for DDS
• Scenarios: 1. Connect separate real-‐:me systems
2. Provide a secure connec:on into a real-‐:me system
3. Connect LANs over an non-‐secured WAN
3/17/14 © 2012 RTI • COMPANY CONFIDENTIAL 31
These scenarios are supported in Connext DDS 4.5 and 5.0
1. Secure Channel between Systems
3/17/14 32
System 1 Rou:ng Service
Gateway acts as security point
System 2 Rou:ng Service
TLS
This solu7on is available in Connext DDS 4.5 and 5.0
Secure Channel with Firewall
3/17/14 33
System 1 Rou:ng Service System 2
Rou:ng Service
TLS
Can use firewall as added protec:on This solu7on is available in
Connext DDS 4.5 and 5.0
DDS Rou:ng Service with Secure Asymmetric TCP
• WAN clients access DDS data within LAN – Clients communicate with par:cipants in LAN not between each other – Clients behind fire-‐walls – Only one public address required. Only one firewall configured
• Example: Exposing a service to end-‐user clients
Remote App
System 1 Rou:ng Service
Remote App
Remote App
This solu7on is available in Connext DDS 4.5 and 5.0
Assymetric TLS
Scope of the DDS Security RFP
Three security boundaries
• Boundary security
• Transport-‐Level – Network (layer 3) security – Session (layer 4/5) security
• Fine-‐grained Data-‐Centric Security
3/17/14 © 2012 Real-‐Time Innova:ons, Inc. -‐ All rights reserved 35
UlDmately you need to implement the 3 of them
Secure DDS Specifica:on
3/17/14 © 2012 Real-‐Time Innova:ons, Inc. -‐ All rights reserved 36
RPC over DDS
2014
DDS Security
2014 Web-‐Enabled DDS
2013
Family of Specifica:ons
37
DDS Implementa:on
Network / TCP / UDP / IP
App
DDS Implementa:on
App
DDS Implementa:on
DDS Spec
2004
DDS Interoperablity
2006
UML Profile for DDS
2008
DDS for Lw CCM
2009
DDS X-‐Types
2010 2012
DDS-‐STD-‐C++ DDS-‐JAVA5
App
37 © 2012 RTI • ALL RIGHTS RESERVED
DDS Security covers 4 related concerns
3/17/14 © 2012 Real-‐Time Innova:ons, Inc. -‐ All rights reserved 38
Security Plugin APIs & Behavior
DDS & RTPS support for Security
BuilDn Plugins
Security Model
Secure DDS Specifica:on: Security Model
3/17/14 © 2012 Real-‐Time Innova:ons, Inc. -‐ All rights reserved 39
Security Model
• A security model is defined in terms of: – The subjects (principals) – The objects being protected
• The opera:ons that are protected on the objects – Access Control Model
• A way to map each subject to the objects they can perform opera:ons on and which are the allowed opera:ons
3/17/14 © 2012 Real-‐Time Innova:ons, Inc. -‐ All rights reserved 40
MR# 6.5.1
Security Model Example: UNIX FileSystem (simplified)
• Subjects: Users, specifically processes execu:ng on behalf of a specific userid
• Protected Objects: Files and Directories
• Protected Opera:ons on Objects:
– Directory.list, Directory.createFile, Directory.createDir, Directory.removeFile, Directory.removeDir, Directory.renameFile
– File.view, File.modify, File.execute
• Access Control Model:
– A subject is given a userId and a set of groupId – Each object is assigned a OWNER and a GROUP
– Each Object is given a combina:on of READ, WRITE, EXECUTE permissions for the assigned OWNER and GROUP
– Each protected opera:on is mapped to a check, for example • File.view is allowed if and only if
– File.owner == Subject.userId AND File.permissions(OWNER) includes READ – OR File.group IS-‐IN Subject.groupId[] AND File.permissions(GROUP) includes READ
3/17/14 © 2012 Real-‐Time Innova:ons, Inc. -‐ All rights reserved 41
DDS Security Model • Subjects: DDS DomainPar:cipant (Par:cipant GUID)
• Protected Objects: DDS Domain and DDS Topic
• Protected OperaDons on Objects (logical view):
– DomainPar:cipant.join – DomainPar:cipant.add_read_par::on
– DomainPar:cipant.add_write_par::on
– Topic.create – Topic.set_qos – Topic.set_reader_qos – Topic.read – Topic.set_writer_qos – Topic.write – Topic.create_instance – Topic.update_instance – Topic.dispose_instance
3/17/14 © 2012 Real-‐Time Innova:ons, Inc. -‐ All rights reserved 42
MR# 6.5.1
Mapping of DDS API to protected opera:ons
3/17/14 © 2012 Real-‐Time Innova:ons, Inc. -‐ All rights reserved 43
DDS API Call Protected OperaDon DomainPar:cipantFactory.create_par:cipant Discovery.match_remote_par:cipant DomainPar:cipant.join DomainPar:cipant.create_publisher Publisher.set_qos DomainPar:cipant.add_write_par::on
DomainPar:cipant.create_subscriber Subscriber.set_qos DomainPar:cipant.add_read_par::on
DomainPar:cipant.create_topic Discovery.dicover_topic Topic.create, Topic.seq_qos
Topic.set_qos Topic.set_qos Subscriber.create_datareader Discovery.dicover_datareader Topic.read, Topic.set_reader_qos
DataReader.set_qos Discovery.change_datareader_qos Topic.set_reader_qos
Publisher.create_datawriter Discovery.dicover_datawriter Topic.write, Topic.set_writer_qos
DataWriter.set_qos Discovery.change_datawriter_qos Topic.set_writer_qos
DataWriter.register_instance DataWriter.write Protocol.receive_instance_new
Topic.create_instance
DataWriter.dispose Protocol.receive_dispose Topic.dispose_instance
MR# 6.5.1
Secure DDS Specifica:on: Security Plugins
3/17/14 © 2012 Real-‐Time Innova:ons, Inc. -‐ All rights reserved 44
Pluggable Security Architecture
© 2012 RTI • UNCLASSIFIED • PROPRIETARY
App.
Other DDS System
Secure DDS middleware
Authen:ca:on Plugin
Access Control Plugin Cryptographic
Plugin
Secure Kernel
Crypto Module (e.g. TPM )
Transport (e.g. UDP)
applica:on component cer:ficates
?
Data cache
Protocol Engine
Kernel Policies
DDS En::es
Network Driver
?
Network
Encrypted Data TAG
Other DDS System
Other DDS System
App. App.
Logging Plugin
DataTagging Plugin
MAC
Pla�orm Independent SPIs
3/17/14 © 2012 Real-‐Time Innova:ons, Inc. -‐ All rights reserved 46
MR# 6.5.2
Pla�orm Independent Intercep:on Pts + SPIs
3/17/14 © 2012 Real-‐Time Innova:ons, Inc. -‐ All rights reserved 47
Service Plugin Purpose Interactions Authentication Authenticate the principal that is
joining a DDS Domain.
Handshake and establish shared secret between participants
The principal may be an application/process or the user associated with that application or process. Participants may messages to do mutual authentication and establish shared secret
Access Control Decide whether a principal is allowed to perform a protected operation.
Protected operations include joining a specific DDS domain, creating a Topic, reading a Topic, writing a Topic, etc.
Cryptography Perform the encryption and decryption operations. Create & Exchange Keys. Compute digests, compute and verify Message Authentication Codes. Sign and verify signatures of messages.
Invoked by DDS middleware to encrypt data compute and verify MAC, compute & verify Digital Signatures
Logging Log all security relevant events Invoked by middleware to log
Data Tagging Add a data tag for each data sample
MR# 6.5.2
Buil:n Plugins
3/17/14 © 2012 Real-‐Time Innova:ons, Inc. -‐ All rights reserved 48
SPI BuilDn Plungin Notes
Authen:ca:on DDS:Auth:PKI-‐RSA/DSA-‐DH Uses PKI with a pre-‐configured shared Cer:ficate Authority. DSA and Diffie-‐Hellman for authen:ca:on and key exchange Establishes shared secret
AccessControl DDS:Access:PKI-‐Signed-‐XML-‐Permissions
Permissions document signed by shared Cer:ficate Authority
Cryptography DDS:Crypto:AES-‐CTR-‐HMAC-‐RSA/DSA-‐DH
Protected key distribu:on AES128 and AES256 for encryp:on (in counter mode) SHA1 and SHA256 for digest HMAC-‐SHA1 and HMAC-‐256 for MAC
DataTagging Discovered_EndpointTags Send Tags via Endpoint Discovery
Logging DedicatedDDS_LogTopic
MR# 6.5.3
DDS Flow
3/17/14 © 2012 RTI • UNCLASSIFIED • PROPRIETARY 49
Create Domain
Par:cipant Authen:cate
DP?
Create Endpoints
Discover remote
Endpoints
Send/Receive data
Discover remote DP
DDS Security Flow
3/17/14 © 2012 RTI • UNCLASSIFIED • PROPRIETARY 50
Create Domain
Par:cipant Authen:cate
DP?
Create Endpoints
Discover remote
Endpoints
Send/Receive data
Discover remote DP
Authen:cate DP?
Yes
Domain Par:cipant Create Fails
No
Access OK? Endpoint Create Fails
No
Authen:cate Remote DP?
Ignore Remote DP
No
Yes
Access OK? Ignore remote endpoint
Message security
DDS Security Flow: Access Control
3/17/14 © 2012 RTI • UNCLASSIFIED • PROPRIETARY 51
Create Domain
Par:cipant Authen:cate
DP?
Create Endpoints
Discover remote
Endpoints
Send/Receive data
Discover remote DP
Authen:cate DP?
Yes
Domain Par:cipant Create Fails
No
Access OK? Endpoint Create Fails
No
Authen:cate Remote DP?
Ignore Remote DP
No
Yes
Access OK? Ignore remote endpoint
Message security
DDS Security Flow – Remote Authen:ca:on
3/17/14 © 2012 RTI • UNCLASSIFIED • PROPRIETARY 52
Discover remote
Endpoints
Discover remote DP
Authen:cate Remote DP?
Ignore Remote DP
No
Yes
Access OK? Ignore remote endpoint
Receive Auth Token
No
Matched DW?
Get Keys
Get remote DW tag
Yes
Yes
Does the remote Data Writer match a local Data Reader
Secure DDS Specifica:on: Authen:ca:on Plugin
3/17/14 © 2012 Real-‐Time Innova:ons, Inc. -‐ All rights reserved 53
Authen:ca:on SPI
3/17/14 © 2012 Real-‐Time Innova:ons, Inc. -‐ All rights reserved 54
MR# 6.5.2
Authen:ca:on Behavior 3/17/14 © 2012 Real-‐Time Innova:ons, Inc. -‐ All rights reserved 55
MR# 6.5.2
Meta-‐Protocol to handshake and establish shared secret
Buil:n DDS:Auth:PKI-‐DSA-‐DH
• Uses shared Cer:ficate Authority (CA) – All Par:cipants pre-‐configured with shared-‐CA
• Performs mutual authen:ca:on between discovered par:cipants using the Digital Signature Algorithm (DSA)
• Establishes a shared secret using Diffie-‐Hellman.
3/17/14 © 2012 Real-‐Time Innova:ons, Inc. -‐ All rights reserved 56
Configura:on of Auth:PKI-‐DS-‐DH
• Three things: – X.509 cer:ficate that defines the shared CA. This cer:ficate contains the Public Key of the CA.
– RSA private key of the DomainPar:cipant. – A (PEM-‐encoded) X.509 Iden:tyCer:ficate
• Chains up to the CA, • Binds PublicKey to the dis:nguished name (subject name) for the DomainPar:cipant
• Configura:on API outside scope of specifica:on – Vendors can use file, QoS property, etc.
3/17/14 © 2012 Real-‐Time Innova:ons, Inc. -‐ All rights reserved 57
Behavior of Auth:PKI-‐DS-‐DH
• validate_local_par:cipant – Iden:tyCreden:alToken has X.509 cer:ficate – Validates cer:ficate against CA
• begin_handshake_request – Sends X.509 Cer:ficate to peer par:cipant – Sends Signed Permissions to to peer par:cipant – Sends Challenge
• begin_handshake_reply – Sends X.509 Cer:ficate to peer par:cipant – Sends Signed Permissions to to peer par:cipant – Replies to Challenge & sends counter Challenge
• process_handshake – Verifies challenge response – Responds to final challenge – Exchanges SharedSecret
3/17/14 © 2012 Real-‐Time Innova:ons, Inc. -‐ All rights reserved 58
3/17/14 © 2012 Real-‐Time Innova:ons, Inc. -‐ All rights reserved 59
Remote Par:cipant Authen:ca:on
Par:cipants receive Hash(X.509 Iden:tyCert) & Hash (Permissions Doc) of remote par:cipant via discovery
3/17/14 © 2012 Real-‐Time Innova:ons, Inc. -‐ All rights reserved 60
Each Par:cipant calls validate_remote_iden:ty(). Par:cipant with highest GUID returns PENDING_HANDSHAKE_REQUEST, the other PENDING_HANDSAHKE_MESSAGE
Remote Par:cipant Authen:ca:on
3/17/14 © 2012 Real-‐Time Innova:ons, Inc. -‐ All rights reserved 61
Par:cipant1 creates CHALLENGE1 = “CHALLENGE:<nonce> and sends message via Par:cipantMessageWriter with HanshakeMessageToken := {CHALLENGE1, Iden:ty, Permissions}
Remote Par:cipant Authen:ca:on
3/17/14 © 2012 Real-‐Time Innova:ons, Inc. -‐ All rights reserved 62
Par:cipant2 validates Iden:ty of Par:cipant1 against CA Par:cipant2 creates CHALLENGE2 := CHALLENGE:<nonce> Par:cipant2 sends to Par:cipant1 message with MessageToken := {SIGN(CHALLENGE1), CHALLENGE2, Iden:ty, Permissions}
Remote Par:cipant Authen:ca:on
3/17/14 © 2012 Real-‐Time Innova:ons, Inc. -‐ All rights reserved 63
Part1 validates Iden:ty of Par:cipant2 against CA Part1 verifies SIGN(CHALLENGE1) using Par:cipant2’s PK Part1 computes a SharedSecret Part1 sends message with contents: MessageToken := { ENCRYPT(SharedSecret), SIGN( HASH(CHALLENGE2 # ENCRYPT(SharedSecret))) } Encrypt uses Part2’s PK.
Remote Par:cipant Authen:ca:on
3/17/14 © 2012 Real-‐Time Innova:ons, Inc. -‐ All rights reserved 64
Part2 verifies SIGN( HASH(CHALLENGE2 # ENCRYPT(SharedSecret)))using Part1’s PK Part2 decrypts ENCRYPT(SharedSecret) using its own PK
We have Mutual AuthenDcaDon and a SharedSecret
Remote Par:cipant Authen:ca:on
Secure DDS Specifica:on: Access Control Plugin
3/17/14 © 2012 Real-‐Time Innova:ons, Inc. -‐ All rights reserved 65
Access Control SPI
3/17/14 © 2012 Real-‐Time Innova:ons, Inc. -‐ All rights reserved 66
MR# 6.5.2
Full AccessControl SPI • check_create_par:cipant
• check_create_datawriter • check_create_datareader • check_create_topic • check_local_datawriter_register_instance • check_local_datawriter_dispose_instance
• check_remote_par:cipant • check_remote_datawriter • check_remote_datareader • check_remote_topic • check_local_datawriter_match • check_local_datareader_match
• check_remote_datawriter_register_instance • check_remote_datawriter_dispose_instance • get_permissions_token • get_permissions_creden:al_token • set_listener • return_permissions_token
• return_permissions_creden:al_token • validate_local_permissions • validate_remote_permissions
3/17/14 © 2012 Real-‐Time Innova:ons, Inc. -‐ All rights reserved 67
Support for AccessControl on data-‐tags and par::ons
• check_local_datawriter_match • check_local_datareader_match
– Opera:ons receive the reader & writer Permissions Handles and DataTags
• The PermissionsHandles can cache any QoS that is relevant to access control decisions
Supports AccessControl rules based on DataTags or matching of other writer/reader alributes (e.g. based on par::on names)
3/17/14 © 2012 Real-‐Time Innova:ons, Inc. -‐ All rights reserved 68
Buil:n DDS:AC:PKI SPI
• Configured with: – X.509 Cer:ficate of shared Permissions CA – The Domain governance signed by the Permissions CA – The DomainPar:cipant permissions signed by the Permissions CA
• The Domain governance configures – Which topics shall be secured and how – Whether discovery is secured and how
• DomainPar:cipant permissions – Specifies what Domains Id can be joined by the DomainPar:cipant – Specified which Topics and be Read/Wrilen by the DomainPar:cipant on
each DomainId – Ties to the SubjectName matching the one on Iden:tyCer:ficate
3/17/14 © 2012 Real-‐Time Innova:ons, Inc. -‐ All rights reserved 69
Example Domain Governance
Example Permissions
Secure DDS Specifica:on: Cryptographic Plugin
3/17/14 © 2012 Real-‐Time Innova:ons, Inc. -‐ All rights reserved 72
Cryptographic SPI
3/17/14 © 2012 Real-‐Time Innova:ons, Inc. -‐ All rights reserved 73
Full Cryptographic SPI (CryptoKeyFactory)
• register_local_par:cipant • register_matched_remote_par:cipant
• register_local_datawriter • register_matched_remote_datareader
• register_local_datareader • register_matched_remote_datawriter
• unregister_par:cipant • unregister_datawriter • unregister_datareader
3/17/14 © 2012 Real-‐Time Innova:ons, Inc. -‐ All rights reserved 74
Full Cryptographic SPI (CryptoKeyExchnage)
• encode_serialized_data • encode_datawriter_submessage
• encode_datareader_submessage • encode_rtps_message
• decode_rtps_message
• preprocess_secure_submsg
• decode_datawriter_submessage • decode_datareader_submessage
• decode_serialized_data
3/17/14 © 2012 Real-‐Time Innova:ons, Inc. -‐ All rights reserved 75
Full Cryptographic SPI (CryptoTransform)
• register_local_par:cipant • register_matched_remote_par:cipant
• register_local_datawriter • register_matched_remote_datareader
• register_local_datareader • register_matched_remote_datawriter
• unregister_par:cipant • unregister_datawriter • unregister_datareader
3/17/14 © 2012 Real-‐Time Innova:ons, Inc. -‐ All rights reserved 76
Background: RTPS
3/17/14 © 2012 Real-‐Time Innova:ons, Inc. -‐ All rights reserved 77
RTPS SubMessage
RTPS Header
RTPS SubMessage
RTPS SubMessage
RTPS SubMessage
SubMsg Header
SubMsg Element
SubMsg Element
SerializedData
RTPS SubMessage
RTPS Message
RTPS SubMessage
SerializedData
RTPS SubMessage
SerializedData
RTPS Header RTPS Header
RTPS SecSubMsg
RTPS SubMessage
SecuredData
SerializedData
RTPS SubMessage
SecuredData
SerializedData
RTPS SecSubMsg
RTPS SecSubMsg
encode_rtps_message
encode_datawriter_submessage
encode_serialized_data
The Cryptographic plugin implementa:on & configura:on determines which transforma:ons should occur. For example encrypt only some topics. HMAC only the whole RTPS message, etc.
RTPS SubMessage
SerializedData
RTPS Header RTPS Header
RTPS SubMessage
SecuredData
SerializedData
encode_serialized_data
RTPS SubMessage
RTPS SubMessage
RTPS SubMessage
RTPS Header
encode_datawriter_submessage
RTPS Header
RTPS SecureSubMsg
RTPS SubMessage
RTPS SubMessage
RTPS SubMessage
RTPS SubMessage
RTPS Header
encode_datareader_submessage
RTPS Header
RTPS SecureSubMsg
RTPS SubMessage
RTPS SubMessage
RTPS SubMessage
RTPS SubMessage
RTPS SubMessage
RTPS Header RTPS Header
RTPS SecureSubMsg
encode_rtps_message
RTPS SubMessage RTPS SubMessage
RTPS SubMessage
RTPS SubMessage
Cryptographic SPI at the wire-‐protocol level
© 2012 RTI • UNCLASSIFIED • PROPRIETARY
RTPS SubMessage
SerializedData
RTPS SubMessage
SerializedData
RTPS Header RTPS Header
RTPS SubMessage (*)
RTPS SubMessage
SecuredData
SerializedData
RTPS SubMessage
SecuredData
SerializedData
RTPS SubMessage (*)
RTPS SubMessage (*)
Secure encoding
Secure decoding
Message Transforma:on
Crypto-‐AES-‐CTR-‐HMAC-‐DSA-‐DH
• Encryp:on uses AES in counter mode – Similar to SRTP, but enhanced to support mul:ple topics within a single RTPS message and infrastructure services like a relay or persistence
• Use of counter mode turns the AES block cipher into a stream cipher – Each DDS sample is separately encrypted and can be decrypted without process the previous message
• This is cri:cal to support DDS QoS like history, content filters, best-‐efforts etc.
• DSA and Diffie-‐Hellman used for mutual authen:ca:on and secure key exchange
3/17/14 © 2012 Real-‐Time Innova:ons, Inc. -‐ All rights reserved 83
MR# 6.5.3
Buil:n DDS:Crypto-‐AES-‐CTR-‐HMAC-‐DSA-‐DH SPI
• Shared secret used to create a KeyExchangeKey • KeyExchangeKey used to send following Master Key Material using the
Buil:nPublica:onWriter: – MasterKey – MasterSalt – MasterHMACSalt
• Based on this the following Key Material is computed: – SessionSalt := HMAC(MasterKey,"SessionSalt" + MasterSalt + SessionId + 0x00) [ Truncated to 128 bits] – SessionKey := HMAC(MasterKey,"SessionKey" + MasterSalt + SessionId + 0x01) – SessionHMACKey := HMAC(MasterKey,"SessionHMACKey" + MasterHMACSalt + SessionId) Note: SessionId goes on the EncryptedMessage Envelope
• Encryp:on uses AES in Counter (CTR) mode – The session counter is sent on EncryptedMessage Envelope.
3/17/14 © 2012 Real-‐Time Innova:ons, Inc. -‐ All rights reserved 84
Data Tagging
3/17/14 © 2012 Real-‐Time Innova:ons, Inc. -‐ All rights reserved 85
DataTagging: DDS:Tagging:DDS_Discovery
• DataWriter and DataReader en::es have associated tags
• DataWriter Tags are propagated via DDS discovery • AccessControl plugin has visibility into tags and can make decisions based on that
• Buil:n plugins – AccessControl plugin ignores tags – Permissions document format does not allow rules based on data-‐tags
– Rules can be added when use-‐case is beler understood
3/17/14 © 2012 Real-‐Time Innova:ons, Inc. -‐ All rights reserved 86
Data Logging
3/17/14 © 2012 Real-‐Time Innova:ons, Inc. -‐ All rights reserved 87
DataLogging: DDS:Logging:DDS_LogTopic
[Sec:on s:ll missing] • Intent is to use a dedicated DDS Topic to Log the security-‐relevant messages
• DDS Secure Log Topic will be encrypted
3/17/14 © 2012 Real-‐Time Innova:ons, Inc. -‐ All rights reserved 88
Status & Conclusions
• The specifica:on is likely to be adopted in March 2014
• This specifica:on provides a framework for securing DDS systems. The buil:n plugins provide a “common” approach for applica:ons without specialized requirements
– It is expected that plugins will be developed to match more specialized deployments and integrate with exis:ng infrastructure.
3/17/14 © 2012 Real-‐Time Innova:ons, Inc. -‐ All rights reserved 89
Discussion
3/17/14 © 2012 Real-‐Time Innova:ons, Inc. -‐ All rights reserved 90
Your systems. Working as one.
Discussion & Next Steps
Find out more… www.r:.com
community.r:.com
demo.r:.com
www.youtube.com/real:meinnova:ons
blogs.r:.com
www.twiler.com/RealTimeInnov
www.facebook.com/RTIsogware
www.slideshare.net/GerardoPardo
dds.omg.org
www.omg.org
© 2012 RTI • ALL RIGHTS RESERVED 92