DDS Security for the Industrial Internet - London Connext DDS Conference

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

Data-Centric Qos-Aware Pub-Sub
Model
Virtual, decentralized global data space
Persistence
Service
Recording
Service
CRUD operations
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 communication to only happen
between authorized subjects
– requires to confidentiality so that only communicating
subjects see the information
• PubSub/DDS
– attempts to create a ‘global information space’ where
anybody can access the information it needs
– de-couples communications so publishers are
unaware of subscribers and vice-versa
4

No Conflict:
Security in the Global Information Space
The key is to use a net-centric security model
• Publishers are decoupled from subscribers via the
Global Information Space
– This does not mean loss of access control to the
information
– It means that the Information Space must have an
associated security model
• DDS can use standard PKI and cryptographic
techniques to enforce the security policies
• The situation is analogous to access control
policies in a file system

Security Terms: a Safe-Deposit Box
• Authentication: The bank knows who you are; you
must show ID.
• Access Control: The bank only lets those on an
access list into your box.
• Confidentiality: 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 repudiation: 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 subscription
2. Unauthorized publication
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
10/27/2014 © 2012 Real-Time Innovations, Inc. - All rights reserved 7

Data-centric/multicast Insider Threats
• Two insider threats affecting (multicast) data-centric
systems are of unique significance
1. Reader mis-behaves as unauthorized writer
An application 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

Session Sequence Number Attack
• 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 attacker can spoof a packet with the session ID and
Hearbeat/GAP causing the DataReader to advance the session
sequence-numbers blocking future messages reception
– Attacker only needs GUID of the DataWriter to attack, which
can be obtained from snooping traffic.
– Attack can be used to prevent the Authentication of legitimate
Participants

Squatting Attack on GUID
• Background:
– DDS DomainParticipants are identified by unique GUID,
Readers/Writers derive their GUID from it.
– GUID used to uniquely identifies the RTPS sessions and the
location of each participant
• Vulnerability:
– An attacker with legit Identity can authenticate using the GUID
of another Participant
– Attacker with be accepted with “cuckooed” GUID blocking
legitimate Participant from using its GUID
– Attacker only needs GUID of the Participant to attack, which
can be obtained from snooping traffic.

DDS Security covers 4 related concerns
Security Model
Security Plugin
APIs & Behavior
DDS & RTPS support
for Security
Builtin Plugins

Security Model Example:
UNIX FileSystem (simplified)
• Subjects: Users, specifically processes executing on behalf of a specific userid
• Protected Objects: Files and Directories
• Protected Operations 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 combination of READ, WRITE, EXECUTE permissions
for the assigned OWNER and GROUP
– Each protected operation 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/27/2014
© 2012 Real-Time Innovations, Inc. - All rights reserved
13
Concept Unix Filesystem Security Model DDS Security Model
Subject User
Process executing for a user
DomainParticipant
Application joining a DDS domain
Protected
Objects
Directories
Files
Domain (by domain_id)
Topic (by Topic name)
DataObjects (by Instance/Key)
Protected
Operations
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
Builtin Access
Control Mode
Per-File/Dir
Read/Write/Execute
permissions for OWNER,
GROUP, USERS
Per-DomainParticipant Permissions :
What Domains and Topics it can
JOIN/READ/WRITE

Support for Security in DDS & RTPS
• DDS Participants need to exchange security information
– Certificates for Authentication & Permissions
– Handshake messages for mutual authentication and shared-secret
establishment
– KeyTokens for key-exchange (Including Multicast Key Exchange)
• Some reuse of existing DDS mechanisms
– Builtin Participant data readers / writers
– Discovery topic-types
• Addition of secure discovery topics
• Addition of a InterparticipantStatelessWriter/Reader
• Encryption and signatures introduce new RTPS Submessage
and Submessage elements
– SecureSubMessage
– SecuredData

Pluggable Security Architecture
certificates application component
?
Data
cache
Transport (e.g. UDP)
Crypto
Module
(e.g. TPM )
App.
AApppp..
Other
DDS
System
Secure DDS
middleware
Authentication
Plugin
Access Control
Plugin Cryptographic
Plugin
Secure Kernel
Protocol
Engine
Kernel
Policies
DDS Entities
?
Network
Driver
Network
Encrypted Data
Other
DDS
System
Other
DDS
System
Logging
Plugin
DataTagging
Plugin
MAC

Platform Independent Interception Pts + SPIs
10/27/2014
© 2012 Real-Time Innovations, 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

Builtin Plugins
SPI Builtin Plungin Notes
Authentication DDS:Auth:PKI-RSA/DSA-DH Uses PKI with a pre-configured shared
Certificate Authority.
DSA and Diffie-Hellman for authentication
and key exchange
Establishes shared secret
AccessControl DDS:Access:PKI-Signed-
XML-Permissions
Governance Document and
Permissions Document
Each signed by shared Certificate Authority
Cryptography DDS:Crypto:AES-CTR-HMAC-
RSA/DSA-DH
Protected key distribution
AES128 and AES256 for encryption (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
Authenticate
DP?
Domain
Participant
Create Fails
Authenticate
Yes DP?
No
Ignore
Remote DP
Authenticate
Remote DP?
No
Yes
No
Yes
Access OK?
Ignore
remote
endpoint
Message
security
Endpoint
Create Fails
Yes
Access OK?
No
Create
Domain
Participant
Create
Endpoints
Discover
remote DP
Discover
remote
Endpoints
Send/Receiv
e data

Cryptographic SPI at the wire-protocol level
Message Transformation
RTPS Header RTPS Header
RTPS SubMessage
SerializedData
RTPS SubMessage
SerializedData
RTPS SubMessage (*)
RTPS SubMessage (*)
RTPS SubMessage
SecuredData
SerializedData
RTPS SubMessage (*)
RTPS SubMessage
SecuredData
SerializedData
Secure encoding
Secure decoding

Crypto-AES-CTR-HMAC-RSA/DSA-DH
• Encryption uses AES in counter mode
– Similar to SRTP, but enhanced to support multiple
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 critical to support DDS QoS like history, content filters,
best-efforts etc.
• DSA and Diffie-Hellman used for mutual
authentication and secure key exchange
MR# 6.5.3

Builtin DDS:Auth:PKI-DSA-DH
• Uses shared Certificate Authority (CA)
– All Participants pre-configured with shared-CA
• Performs mutual authentication between
discovered participants using the Digital
Signature Algorithm (DSA)
• Establishes a shared secret using Diffie-Hellman.

Remote Participant Authentication
Participants detect each other via discovery and exchange
Identity and Permission Tokens (Hashes)

Each Participant calls validate_remote_identity().
Participant with highest GUID returns
PENDING_HANDSHAKE_REQUEST, the other
PENDING_HANDSHAKE_MESSAGE

Participant1 creates CHALLENGE1 = “CHALLENGE:<nonce>
and sends message via ParticipantMessageWriter with
messageToken1:= {CHALLENGE1, Identity1, Permissions1}

Participant2 validates Identity of Participant1 against CA
Participant2 creates CHALLENGE2 := CHALLENGE:<nonce>
Participant2 sends to Participant1 message with
messageToken2:= {
SIGN(HASH(CHALLENGE1#Identity1#Permissions1)),
CHALLENGE2, Identity2, © 2014 Real-Time Permissions2}
Innovations, Inc.

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

Part2 verifies SIGN( HASH(CHALLENGE2 #Identity2#Permissions2#
ENCRYPT(SharedSecret)))
using Part1’s PK
Part2 decrypts ENCRYPT(SharedSecret) using its own PK
We have Mutual Authentication and a SharedSecret

Builtin DDS:AC:PKI SPI
• Configured with:
– X.509 Certificate of shared Permissions CA
– The Domain governance signed by the Permissions CA
– The DomainParticipant permissions signed by the Permissions CA
• The Domain governance configures
– Which topics shall be secured and how
– Whether discovery is secured and how
• DomainParticipant permissions
– Specifies what Domains Id can be joined by the DomainParticipant
– Specified which Topics and be Read/Written by the DomainParticipant on
each DomainId
– Ties to the SubjectName matching the one on IdentityCertificate

Example Domain Governance

Configuration possibilities
• Are “legacy” or un-identified applications allowed in the
Domain? Yes or No.
– If yes an Unauthenticated applications will:
• See the “unsecured” discovery Topics
• Be allowed to read/write the “unsecured” Topics
• Is a particular Topic discovered over protected discovery?
– If so it can only be seen by “authenticated applications”
• Is a access particular Topic protected?
– If so only authenticated applications with the correct permissions
can read/write
• Is data on a particular Topic protected? How?
– If so data will be sent signed or encrypted+signed
• Are all protocol messages signed? Encrypted?
– If so only authenticated applications with right permissions will see
anything

Example Permissions

Secure discovery
• Additional built-in endpoints:
– DCPSPublicationsSecure
– DCPSSubscriptionsSecure
• Same discovery topic-data but encrypted &
signed
• Operation
AccessControl::get_endpoint_security_attributes()
controls which Topics use Secure Discovery

Configuration Possibilities
• Is the access to a particular Topic protected?
– If so only authenticated applications with the correct
permissions can read/write
• Is data on a particular Topic protected? How?
– If so data will be sent signed or encrypted+signed
• Are all protocol messages signed? Encrypted?
– If so only authenticated applications with right
permissions will see anything

More Powerful Than Other Secure
Middleware Technologies
• Standard & Interoperable
• Scalable: Supports multicast
• Fine-grain: Control Topic-level aspect
• Flexible: Build your own plugins
• Generic: Works over any Transport
• Transparent: No changes to Application Code!

DDS-Secure Standard Status
• The specification was adopted in March 2014.
– Considered “Beta” for 1 year
– RTI chairing the Finalization Task Force
• This specification provides a framework for securing
DDS systems. The builtin plugins provide a “common”
approach for applications without specialized
requirements
– It is expected that plugins will be developed to match more specialized
deployments and integrate with existing infrastructure.

Find out more…
www.rti.com
community.rti.com
demo.rti.com
www.youtube.com/realtimeinnovations
blogs.rti.com
www.twitter.com/RealTimeInnov
www.facebook.com/RTIsoftware
www.slideshare.net/GerardoPardo
www.slideshare.net/RealTimeInnovations
dds.omg.org
www.omg.org
© 2014 RTI

DDS Security for the Industrial Internet - London Connext DDS Conference

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to DDS Security for the Industrial Internet - London Connext DDS Conference

Similar to DDS Security for the Industrial Internet - London Connext DDS Conference (20)

More from Gerardo Pardo-Castellote

More from Gerardo Pardo-Castellote (20)

Recently uploaded

Recently uploaded (20)

DDS Security for the Industrial Internet - London Connext DDS Conference