OMG Data-Distribution Service Security

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


App

App

App App

App


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


DDS Data-‐Centric Bus

App App App App App App

App

App

App App

App


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


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


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


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


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


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.


Fine-‐Grained Data-‐Centric Security

•  Access control per Topic •  Read versus-‐write permissions

•  Field-‐specific permissions


Topics

Three security boundaries

•  Boundary security

•  Transport-‐Level – Network (layer 3) security – Session (layer 4/5) security

•  Fine-‐grained Data-‐Centric Security


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)


Transport Layer Security (TLS) for DDS


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


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


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


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


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


UlDmately you need to implement the 3 of them

Secure DDS Specifica:on


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


Security Plugin APIs & Behavior

DDS & RTPS support for Security

BuilDn Plugins

Security Model

Secure DDS Specifica:on: Security Model


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


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


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


MR# 6.5.1

Mapping of DDS API to protected opera:ons


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


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


MR# 6.5.2

Pla�orm Independent Intercep:on Pts + SPIs


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


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


Create Domain


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


Create Domain


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


Ignore Remote DP

No

Yes


Message security

DDS Security Flow – Remote Authen:ca:on


Discover remote

Endpoints

Discover remote DP


Ignore Remote DP

No

Yes


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


Authen:ca:on SPI


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.


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.


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



Remote Par:cipant Authen:ca:on

Par:cipants receive Hash(X.509 Iden:tyCert) & Hash (Permissions Doc) of remote par:cipant via discovery


Each Par:cipant calls validate_remote_iden:ty(). Par:cipant with highest GUID returns PENDING_HANDSHAKE_REQUEST, the other PENDING_HANDSAHKE_MESSAGE



Par:cipant1 creates CHALLENGE1 = “CHALLENGE:<nonce> and sends message via Par:cipantMessageWriter with HanshakeMessageToken := {CHALLENGE1, Iden:ty, Permissions}



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}



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.



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


Secure DDS Specifica:on: Access Control Plugin


Access Control SPI


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


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)


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


Example Domain Governance

Example Permissions

Secure DDS Specifica:on: Cryptographic Plugin


Cryptographic SPI


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


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


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


Background: RTPS


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


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.


Data Tagging


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


Data Logging


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


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.


Discussion


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

Technology

OMG Data-Distribution Service Security