DDS Security

DDS

DDS Security Gerardo Pardo-‐Castellote, Ph.D. Chief Technology Officer, RTI

October 2014


Data-‐Centric Qos-‐Aware Pub-‐Sub Model

Persistence Service

Recording Service

Virtual, decentralized global data space

CRUD operaFons

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


Is there a Conflict?

•  Security… –  desires to restrict communicaFon to only happen between authorized subjects

–  requires to confidenFality so that only communicaFng subjects see the informaFon

•  PubSub/DDS –  aWempts to create a ‘global informaFon space’ where anybody can access the informaFon it needs

–  de-‐couples communicaFons so publishers are unaware of subscribers and vice-‐versa

4


No Conflict: Security in the Global InformaFon Space

•  Publishers are decoupled from subscribers via the Global InformaFon Space –  This does not mean loss of access control to the informaFon

–  It means that the InformaFon Space must have an associated security model

•  DDS can use standard PKI and cryptographic techniques to enforce the security policies

•  The situaFon is analogous to access control policies in a file system

The key is to use a net-‐centric security model


Security Terms: a Safe-‐Deposit Box •  AuthenFcaFon: The bank knows who you are; you must show ID.

•  Access Control: The bank only lets those on an access list into your box.

•  ConfidenFality: 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 repudiaFon: You sign when you come in and out so you can’t claim that you weren’t there.

•  Availability: The bank is always open.


Threats 1.  Unauthorized subscripFon 2.  Unauthorized publicaFon 3.  Tampering and replay 4.  Unauthorized access to data

by infrastructure services

10/30/14 7

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/mulFcast Insider Threats

•  Two insider threats affecFng (mulFcast) data-‐centric systems are of unique significance 1.   Reader mis-‐behaves as unauthorized writer

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

10/30/14 8


Session Sequence Number AWack •  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 aWacker can spoof a packet with the session ID and Hearbeat/GAP causing the DataReader to advance the session sequence-‐numbers blocking future messages recepFon

–  AWacker only needs GUID of the DataWriter to aWack, which can be obtained from snooping traffic.

–  AWack can be used to prevent the AuthenFcaFon of legiFmate ParFcipants


Squakng AWack on GUID •  Background:

–  DDS DomainParFcipants are idenFfied by unique GUID, Readers/Writers derive their GUID from it.

–  GUID used to uniquely idenFfies the RTPS sessions and the locaFon of each parFcipant

•  Vulnerability: –  An aWacker with legit IdenFty can authenFcate using the GUID of another ParFcipant

–  AWacker with be accepted with “cuckooed” GUID blocking legiFmate ParFcipant from using its GUID

–  AWacker only needs GUID of the ParFcipant to aWack, which can be obtained from snooping traffic.


DDS Security covers 4 related concerns

Security Plugin APIs & Behavior

DDS & RTPS support for Security

BuilHn Plugins

Security Model


Security Model Example: UNIX FileSystem (simplified)

•  Subjects: Users, specifically processes execuFng on behalf of a specific userid •  Protected Objects: Files and Directories •  Protected OperaFons 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 combinaFon of READ, WRITE, EXECUTE permissions

for the assigned OWNER and GROUP –  Each protected operaFon 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

10/30/14 © 2012 Real-‐Time InnovaFons, Inc. -‐ All rights reserved

13

Concept Unix Filesystem Security Model DDS Security Model

Subject User Process execuFng for a user

DomainParFcipant ApplicaFon joining a DDS domain

Protected Objects

Directories Files

Domain (by domain_id) Topic (by Topic name) DataObjects (by Instance/Key)

Protected OperaFons

Directory.list, Directory.create (File, Dir) Directory.remove (File, Dir) Directory.rename (File, Dir) File.read, File.write, File.execute

Domain.join Topic.create Topic.read (includes QoS) Topic.write (includes QoS) Data.createInstance Data.writeInstance Data.deleteInstance

Access Control Policy Control

Fixed in Kernel Configurable via Plugin

BuilFn Access Control Mode

Per-‐File/Dir Read/Write/Execute permissions for OWNER, GROUP, USERS

Per-‐DomainParFcipant Permissions : What Domains and Topics it can JOIN/READ/WRITE


Support for Security in DDS & RTPS

•  DDS ParFcipants need to exchange security informaFon –  CerFficates for AuthenFcaFon & Permissions –  Handshake messages for mutual authenFcaFon and shared-‐secret establishment

–  KeyTokens for key-‐exchange (Including MulFcast Key Exchange) •  Some reuse of exisFng DDS mechanisms

–  BuilFn ParFcipant data readers / writers –  Discovery topic-‐types

•  AddiFon of secure discovery topics •  AddiFon of a InterparFcipantStatelessWriter/Reader •  EncrypFon and signatures introduce new RTPS Submessage

and Submessage elements –  SecureSubMessage –  SecuredData

10/30/14 14


Pluggable Security Architecture

App.

Other DDS System

Secure DDS middleware

AuthenFcaFon Plugin

Access Control Plugin Cryptographic

Plugin

Secure Kernel

Crypto Module (e.g. TPM )

Transport (e.g. UDP)

applicaFon component cerFficates

?

Data cache

Protocol Engine

Kernel Policies

DDS EnFFes

Network Driver

?

Network

Encrypted Data

Other DDS System

Other DDS System

App. App.

Logging Plugin

DataTagging Plugin

MAC


Plaworm Independent IntercepFon Pts + SPIs

10/30/14 © 2012 Real-‐Time InnovaFons, Inc. -‐ All rights reserved

16

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


BuilFn Plugins SPI BuilHn Plungin Notes

AuthenFcaFon DDS:Auth:PKI-‐RSA/DSA-‐DH Uses PKI with a pre-‐configured shared CerFficate Authority. DSA and Diffie-‐Hellman for authenFcaFon and key exchange Establishes shared secret

AccessControl DDS:Access:PKI-‐Signed-‐XML-‐Permissions

Governance Document and Permissions Document Each signed by shared CerFficate Authority

Cryptography DDS:Crypto:AES-‐CTR-‐HMAC-‐RSA/DSA-‐DH

Protected key distribuFon AES128 and AES256 for encrypFon (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


DDS Security Flow Domain

ParFcipant Create Fails

AuthenFcate DP? Yes

AuthenFcate DP?

No

Ignore Remote DP

AuthenFcate Remote DP?

No

Yes

No

Yes

Access OK? Ignore remote endpoint

Message security

Endpoint Create Fails

Yes Access OK?

No

Create Domain

ParFcipant

Create Endpoints

Discover remote

Endpoints

Send/Receive data

Discover remote DP


Cryptographic SPI at the wire-‐protocol level

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 TransformaFon


Crypto-‐AES-‐CTR-‐HMAC-‐RSA/DSA-‐DH

•  EncrypFon uses AES in counter mode –  Similar to SRTP, but enhanced to support mulFple 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 criFcal to support DDS QoS like history, content filters, best-‐efforts etc.

•  DSA and Diffie-‐Hellman used for mutual authenFcaFon and secure key exchange

MR# 6.5.3


BuilFn DDS:Auth:PKI-‐DSA-‐DH

•  Uses shared CerFficate Authority (CA) – All ParFcipants pre-‐configured with shared-‐CA

•  Performs mutual authenFcaFon between discovered parFcipants using the Digital Signature Algorithm (DSA)

•  Establishes a shared secret using Diffie-‐Hellman.


Remote ParFcipant AuthenFcaFon

ParFcipants detect each other via discovery and exchange IdenFty and Permission Tokens (Hashes)


Each ParFcipant calls validate_remote_idenFty(). ParFcipant with highest GUID returns PENDING_HANDSHAKE_REQUEST, the other PENDING_HANDSHAKE_MESSAGE



ParFcipant1 creates CHALLENGE1 = “CHALLENGE:<nonce> and sends message via ParFcipantMessageWriter with messageToken1:= {CHALLENGE1, IdenFty1, Permissions1}



ParFcipant2 validates IdenFty of ParFcipant1 against CA ParFcipant2 creates CHALLENGE2 := CHALLENGE:<nonce> ParFcipant2 sends to ParFcipant1 message with messageToken2:= { SIGN(HASH(CHALLENGE1#IdenFty1#Permissions1)), CHALLENGE2, IdenFty2, Permissions2}


© 2014 Real-‐Time InnovaFons, Inc. 10/30/14 26

Part1 validates IdenFty of ParFcipant2 against CA Part1 verifies SIGN(CHALLENGE1) using ParFcipant2’s PK Part1 computes a SharedSecret Part1 sends message with contents: messageToken3 := { ENCRYPT(SharedSecret), SIGN( HASH(CHALLENGE2 # IdenFty2 # Permissions2 # ENCRYPT(SharedSecret))) } Encrypt uses Part2’s PK.


© 2014 Real-‐Time InnovaFons, Inc. 10/30/14 © 2012 Real-‐Time InnovaFons, Inc. -‐ All rights reserved 27

Part2 verifies SIGN( HASH(CHALLENGE2 #IdenFty2#Permissions2# ENCRYPT(SharedSecret))) using Part1’s PK Part2 decrypts ENCRYPT(SharedSecret) using its own PK

We have Mutual AuthenHcaHon and a SharedSecret



BuilFn DDS:AC:PKI SPI •  Configured with:

–  X.509 CerFficate of shared Permissions CA –  The Domain governance signed by the Permissions CA –  The DomainParFcipant permissions signed by the Permissions CA

•  The Domain governance configures –  Which topics shall be secured and how –  Whether discovery is secured and how

•  DomainParFcipant permissions –  Specifies what Domains Id can be joined by the DomainParFcipant –  Specified which Topics and be Read/WriWen by the DomainParFcipant on

each DomainId –  Ties to the SubjectName matching the one on IdenFtyCerFficate

10/30/14 28


Example Domain Governance


ConfiguraFon possibiliFes •  Are “legacy” or un-‐idenFfied applicaFons allowed in the

Domain? Yes or No. –  If yes an UnauthenFcated applicaFons will:

•  See the “unsecured” discovery Topics •  Be allowed to read/write the “unsecured” Topics

•  Is a parFcular Topic discovered over protected discovery? –  If so it can only be seen by “authenFcated applicaFons”

•  Is a access parFcular Topic protected? –  If so only authenFcated applicaFons with the correct permissions can read/write

•  Is data on a parFcular Topic protected? How? –  If so data will be sent signed or encrypted+signed

•  Are all protocol messages signed? Encrypted? –  If so only authenFcated applicaFons with right permissions will see anything


Example Permissions


Secure discovery

•  AddiFonal built-‐in endpoints: – DCPSPublicaFonsSecure – DCPSSubscripFonsSecure

•  Same discovery topic-‐data but encrypted & signed

•  OperaFon AccessControl::get_endpoint_security_attributes()

controls which Topics use Secure Discovery

10/30/14 32


ConfiguraFon PossibiliFes

•  Is the access to a parFcular Topic protected? –  If so only authenFcated applicaFons with the correct permissions can read/write

•  Is data on a parFcular Topic protected? How? –  If so data will be sent signed or encrypted+signed

•  Are all protocol messages signed? Encrypted? –  If so only authenFcated applicaFons with right permissions will see anything


More Powerful Than Other Secure Middleware Technologies

•  Standard & Interoperable •  Scalable: Supports mulFcast •  Fine-‐grain: Control Topic-‐level aspect •  Flexible: Build your own plugins •  Generic: Works over any Transport •  Transparent: No changes to ApplicaFon Code!


DDS-‐Secure Standard Status

•  The specificaFon was adopted in March 2014. –  Considered “Beta” for 1 year –  RTI chairing the FinalizaFon Task Force

•  This specificaFon provides a framework for securing DDS systems. The builFn plugins provide a “common” approach for applicaFons without specialized requirements –  It is expected that plugins will be developed to match more specialized

deployments and integrate with exisFng infrastructure.

10/30/14 35


QuesFons?


Find out more… www.rF.com

community.rF.com

demo.rF.com

www.youtube.com/realFmeinnovaFons

blogs.rF.com

www.twiWer.com/RealTimeInnov

www.facebook.com/RTIso�ware

dds.omg.org

www.omg.org

www.slideshare.net/GerardoPardo www.slideshare.net/RealTimeInnovaFons

DDS Security

Technology

Transcript of DDS Security