Security – Presentation by Gerardo Pardo-Castellote, CTO, RTI

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

2. ©
2014
Real-­‐Time
InnovaFons,
Inc.

3. Data-­‐Centric
Qos-­‐Aware
Pub-­‐Sub
Model
Virtual,
decentralized
global
data
space
Persistence
Service
Recording
Service
©
2014
Real-­‐Time
InnovaFons,
Inc.
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

4. Is
there
a
Conflict?
• Security…
©
2014
Real-­‐Time
InnovaFons,
Inc.
– 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

5. No
Conflict:
Security
in
the
Global
InformaFon
Space
The
key
is
to
use
a
net-­‐centric
security
model
©
2014
Real-­‐Time
InnovaFons,
Inc.
• 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

6. Security
Terms:
a
Safe-­‐Deposit
Box
• AuthenFcaFon:
The
bank
knows
who
you
are;
©
2014
Real-­‐Time
InnovaFons,
Inc.
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.

7. Threats
1. Unauthorized
subscripFon
2. Unauthorized
publicaFon
3. Tampering
and
replay
4. Unauthorized
access
to
data
by
infrastructure
services
10/30/14
7
©
2014
Real-­‐Time
InnovaFons,
Inc.
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

8. 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
©
2014
Real-­‐Time
InnovaFons,
Inc.

9. Session
Sequence
Number
AWack
• Background:
©
2014
Real-­‐Time
InnovaFons,
Inc.
– 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

10. Squakng
AWack
on
GUID
• Background:
©
2014
Real-­‐Time
InnovaFons,
Inc.
– 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.

11. DDS
Security
covers
4
related
concerns
Security
Model
©
2014
Real-­‐Time
InnovaFons,
Inc.
Security
Plugin
APIs
&
Behavior
DDS
&
RTPS
support
for
Security
BuilHn
Plugins

12. Security
Model
Example:
UNIX
FileSystem
(simplified)
• Subjects:
Users,
specifically
processes
execuFng
on
behalf
of
a
specific
userid
©
2014
Real-­‐Time
InnovaFons,
Inc.
• 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

13. ©
2014
Real-­‐Time
InnovaFons,
Inc.
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

14. Support
for
Security
in
DDS
&
RTPS
• DDS
ParFcipants
need
to
exchange
security
informaFon
©
2014
Real-­‐Time
InnovaFons,
Inc.
– 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

15. Pluggable
Security
Architecture
Transport
(e.g.
UDP)
Crypto
Module
(e.g.
TPM
)
©
2014
Real-­‐Time
InnovaFons,
Inc.
App.
AApppp.
.
Other
DDS
System
Secure
DDS
middleware
AuthenFcaFon
Plugin
Access
Control
Plugin
Cryptographic
Plugin
Secure
Kernel
cerFficates
applicaFon
component
?
Data
cache
Protocol
Engine
Kernel
Policies
DDS
EnFFes
?
Network
Driver
Network
Encrypted
Data
Other
DDS
System
Other
DDS
System
Logging
Plugin
DataTagging
Plugin
MAC

16. Plaworm
Independent
IntercepFon
Pts
+
SPIs
©
2014
Real-­‐Time
InnovaFons,
Inc.
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

17. ©
2014
Real-­‐Time
InnovaFons,
Inc.
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

18. DDS
Security
Flow
Domain
ParFcipant
Create
Fails
AuthenFcate
AuthenFcate
DP?
©
2014
Real-­‐Time
InnovaFons,
Inc.
Yes
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
DP
Discover
remote
Endpoints
Send/
Receive
data

19. Cryptographic
SPI
at
the
wire-­‐protocol
level
Message
TransformaFon
©
2014
Real-­‐Time
InnovaFons,
Inc.
RTPS
Header
RTPS
SubMessage
SerializedData
RTPS
SubMessage
SerializedData
RTPS
Header
RTPS
SubMessage
(*)
RTPS
SubMessage
(*)
RTPS
SubMessage
SecuredData
SerializedData
RTPS
SubMessage
(*)
RTPS
SubMessage
SecuredData
SerializedData
Secure
encoding
Secure
decoding

20. Crypto-­‐AES-­‐CTR-­‐HMAC-­‐RSA/DSA-­‐DH
• EncrypFon
uses
AES
in
counter
mode
©
2014
Real-­‐Time
InnovaFons,
Inc.
– 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

21. BuilFn
DDS:Auth:PKI-­‐DSA-­‐DH
• Uses
shared
CerFficate
Authority
(CA)
©
2014
Real-­‐Time
InnovaFons,
Inc.
– 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.

22. Remote
ParFcipant
AuthenFcaFon
ParFcipants
detect
each
other
via
discovery
and
exchange
IdenFty
and
Permission
Tokens
(Hashes)
©
2014
Real-­‐Time
InnovaFons,
Inc.

23. Remote
ParFcipant
AuthenFcaFon
Each
ParFcipant
calls
validate_remote_idenFty().
ParFcipant
with
highest
GUID
returns
PENDING_HANDSHAKE_REQUEST,
the
other
PENDING_HANDSHAKE_MESSAGE
©
2014
Real-­‐Time
InnovaFons,
Inc.

24. Remote
ParFcipant
AuthenFcaFon
ParFcipant1
creates
CHALLENGE1
=
“CHALLENGE:<nonce>
and
sends
message
via
ParFcipantMessageWriter
with
messageToken1:=
{CHALLENGE1,
IdenFty1,
Permissions1}
©
2014
Real-­‐Time
InnovaFons,
Inc.

25. Remote
ParFcipant
AuthenFcaFon
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,
©
2014
Permissions2}
Real-­‐Time
InnovaFons,
Inc.

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)))
}
10/30/14
26
©
2014
Real-­‐Time
InnovaFons,
Inc.
Encrypt
uses
Part2’s
PK.
Remote
ParFcipant
AuthenFcaFon

27. Remote
ParFcipant
AuthenFcaFon
Part2
verifies
SIGN(
HASH(CHALLENGE2
#IdenFty2#Permissions2#
ENCRYPT(SharedSecret)))
10/30/14
©
2012
Real-­‐Time
InnovaFons,
Inc.
-­‐
All
rights
reserved
27
©
2014
Real-­‐Time
InnovaFons,
Inc.
using
Part1’s
PK
Part2
decrypts
ENCRYPT(SharedSecret)
using
its
own
PK
We
have
Mutual
AuthenHcaHon
and
a
SharedSecret

28. BuilFn
DDS:AC:PKI
SPI
• Configured
©
2014
Real-­‐Time
InnovaFons,
Inc.
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

29. Example
Domain
Governance
©
2014
Real-­‐Time
InnovaFons,
Inc.

30. ConfiguraFon
possibiliFes
• Are
“legacy”
or
un-­‐idenFfied
applicaFons
allowed
in
the
©
2014
Real-­‐Time
InnovaFons,
Inc.
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

31. Example
Permissions
©
2014
Real-­‐Time
InnovaFons,
Inc.

32. 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
©
2014
Real-­‐Time
InnovaFons,
Inc.

33. ConfiguraFon
PossibiliFes
©
2014
Real-­‐Time
InnovaFons,
Inc.
• 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

34. More
Powerful
Than
Other
Secure
Middleware
Technologies
• Standard
&
Interoperable
©
2014
Real-­‐Time
InnovaFons,
Inc.
• 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!

35. DDS-­‐Secure
Standard
Status
©
2014
Real-­‐Time
InnovaFons,
Inc.
• 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

36. QuesFons?
©
2014
Real-­‐Time
InnovaFons,
Inc.

37. ©
2014
Real-­‐Time
InnovaFons,
Inc.
Find
out
more…
dds.omg.org
www.omg.org
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
www.slideshare.net/GerardoPardo
www.slideshare.net/RealTimeInnovaFons