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

PersistenceService

RecordingService

Virtual, decentralized global data space

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

• 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

The key is to use a net-centric security model


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.


Threats1. Unauthorized subscription2. Unauthorized publication3. Tampering and replay 4. Unauthorized access to data

by infrastructure services

10/27/2014 © 2012 Real-Time Innovations, Inc. - All rights reserved 7

Alice: Allowed to publish topic TBob: Allowed to subscribe to topic TEve: Non-authorized eavesdropper Trudy: IntruderTrent: Trusted infrastructure serviceMallory: Malicious insider


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 Plugin APIs & Behavior

DDS & RTPS support for Security

Builtin Plugins

Security Model


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 UserProcess executing for a user

DomainParticipantApplication joining a DDS domain

ProtectedObjects

DirectoriesFiles

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.joinTopic.createTopic.read (includes QoS)Topic.write (includes QoS)Data.createInstanceData.writeInstanceData.deleteInstance

Access Control Policy Control

Fixed in Kernel Configurable via Plugin

Builtin Access Control Mode

Per-File/DirRead/Write/Executepermissions 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

App.

Other DDSSystem

Secure DDS middleware

AuthenticationPlugin

Access ControlPlugin Cryptographic

Plugin

Secure Kernel

Crypto Module(e.g. TPM )

Transport (e.g. UDP)

application componentcertificates

?

Datacache

ProtocolEngine

KernelPolicies

DDS Entities

NetworkDriver

?

Network

Encrypted Data

Other DDSSystem

Other DDSSystem

App.App.

LoggingPlugin

DataTaggingPlugin

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 PluginsSPI 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 exchangeEstablishes shared secret

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

Governance Document andPermissions DocumentEach signed by shared Certificate Authority

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

Protected key distributionAES128 and AES256 for encryption (in counter mode)SHA1 and SHA256 for digestHMAC-SHA1 and HMAC-256 for MAC

DataTagging Discovered_EndpointTags Send Tags via Endpoint Discovery

Logging DedicatedDDS_LogTopic


DDS Security FlowDomain

Participant Create Fails

AuthenticateDP?Yes

AuthenticateDP?

No

Ignore Remote DP

AuthenticateRemote DP?

No

Yes

No

Yes

Access OK?Ignore remote

endpoint

Message security

Endpoint Create Fails

YesAccess OK?

No

Create Domain

Participant

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 Transformation


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 CAParticipant2 creates CHALLENGE2 := CHALLENGE:<nonce>Participant2 sends to Participant1 message with messageToken2:= { SIGN(HASH(CHALLENGE1#Identity1#Permissions1)), CHALLENGE2, Identity2, Permissions2}


© 2014 Real-Time Innovations, Inc.10/27/2014 © 2012 Real-Time Innovations, Inc. - All rights reserved 26

Part1 validates Identity of Participant2 against CAPart1 verifies SIGN(CHALLENGE1) using Participant2’s PKPart1 computes a SharedSecretPart1 sends message with contents:messageToken3

:= { ENCRYPT(SharedSecret), SIGN( HASH(CHALLENGE2 # Identity2 # Permissions2 #

ENCRYPT(SharedSecret))) }Encrypt uses Part2’s PK.


© 2014 Real-Time Innovations, Inc.10/27/2014 © 2012 Real-Time Innovations, Inc. - All rights reserved 27

Part2 verifies SIGN( HASH(CHALLENGE2 #Identity2#Permissions2# ENCRYPT(SharedSecret)))

using Part1’s PKPart2 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

dds.omg.org

www.omg.org

© 2014 RTI

www.slideshare.net/GerardoPardowww.slideshare.net/RealTimeInnovations

http://www.rti.com

http://community.rti.com

http://demo.rti.com

http://www.youtube.com/realtimeinnovations

http://blogs.rti.com

http://www.twitter.com/RealTimeInnov

http://www.facebook.com/RTIsoftware

http://dds.omg.org

http://www.omg.org

http://www.slideshare.net/GerardoPardo

http://www.slideshare.net/RealTimeInnovations

DDS Security for the Industrial Internet - London Connext DDS Conference

Technology

Transcript of DDS Security for the Industrial Internet - London Connext DDS Conference