This document provides an overview of data distribution service (DDS) and security considerations for DDS. It discusses the data-centric publish-subscribe model of DDS, how data is identified in the global data space, and approaches to software integration like point-to-point and broker-based that DDS improves upon. The document also touches on key aspects of the DDS security specification and next steps.

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

3. Technical
Mee:ng
Agenda
• DDS
Background
• Security
Background
• DDS
Security
Specifica:on
• Discussion
&
Next
Steps
3

4. DDS
Background
3/17/14
©
2012
Real-­‐Time
Innova:ons,
Inc.
-­‐
All
rights
reserved
4

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

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

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

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

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

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

11. Approaches
to
Sogware
Integra:on
App
App
App
App
App
App
Point-­‐to-­‐point
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

12. Approaches
to
Sogware
Integra:on
DDS
Data-­‐Centric
Bus
App
App
App
App
App
App
App
App
App
App
App
App
Point-­‐to-­‐point
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

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

14. Security
Background
3/17/14
©
2012
Real-­‐Time
Innova:ons,
Inc.
-­‐
All
rights
reserved
14

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

16. 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!

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

18. Threats
1. Unauthorized
subscrip:on
2. Unauthorized
publica:on
3. Tampering
and
replay
4. Unauthorized
access
to
data
by
infrastructure
services
3/17/14
©
2012
Real-­‐Time
Innova:ons,
Inc.
-­‐
All
rights
reserved
18
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

19. 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
3/17/14
©
2012
Real-­‐Time
Innova:ons,
Inc.
-­‐
All
rights
reserved
19

20. 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
3/17/14
©
2012
Real-­‐Time
Innova:ons,
Inc.
-­‐
All
rights
reserved
20

21. 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
3/17/14
©
2012
Real-­‐Time
Innova:ons,
Inc.
-­‐
All
rights
reserved
21

22. 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.
3/17/14
©
2012
Real-­‐Time
Innova:ons,
Inc.
-­‐
All
rights
reserved
22

23. Fine-­‐Grained
Data-­‐Centric
Security
• Access
control
per
Topic
• Read
versus-­‐write
permissions
• Field-­‐specific
permissions
3/17/14
©
2012
Real-­‐Time
Innova:ons,
Inc.
-­‐
All
rights
reserved
23
Topics

24. Three
security
boundaries
• Boundary
security
• Transport-­‐Level
– Network
(layer
3)
security
– Session
(layer
4/5)
security
• Fine-­‐grained
Data-­‐Centric
Security
3/17/14
©
2012
Real-­‐Time
Innova:ons,
Inc.
-­‐
All
rights
reserved
24
UlDmately
you
need
to
implement
the
3
of
them

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

26. 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)
3/17/14
©
2012
RTI
•
COMPANY
CONFIDENTIAL
26

27. Transport
Layer
Security
(TLS)
for
DDS
3/17/14
©
2012
RTI
•
COMPANY
CONFIDENTIAL
27
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

28. 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
3/17/14
©
2012
RTI
•
COMPANY
CONFIDENTIAL
28

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

30. DTLS
Performance
–
Latency
3/17/14
©
2011
Real-­‐Time
Innova:ons,
Inc.
COMPANY
CONFIDENTIAL
30

31. 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
3/17/14
©
2012
RTI
•
COMPANY
CONFIDENTIAL
31
These
scenarios
are
supported
in
Connext
DDS
4.5
and
5.0

32. 1.
Secure
Channel
between
Systems
3/17/14
32
System
1
Rou:ng
Service
Gateway
acts
as
security
point
System
2
Rou:ng
Service
TLS
This
solu7on
is
available
in
Connext
DDS
4.5
and
5.0

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

34. 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
System
1
Rou:ng
Service
Remote
App
Remote
App
This
solu7on
is
available
in
Connext
DDS
4.5
and
5.0
Assymetric
TLS

35. 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
3/17/14
©
2012
Real-­‐Time
Innova:ons,
Inc.
-­‐
All
rights
reserved
35
UlDmately
you
need
to
implement
the
3
of
them

36. Secure
DDS
Specifica:on
3/17/14
©
2012
Real-­‐Time
Innova:ons,
Inc.
-­‐
All
rights
reserved
36

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

38. DDS
Security
covers
4
related
concerns
3/17/14
©
2012
Real-­‐Time
Innova:ons,
Inc.
-­‐
All
rights
reserved
38
Security
Plugin
APIs
&
Behavior
DDS
&
RTPS
support
for
Security
BuilDn
Plugins
Security
Model

39. Secure
DDS
Specifica:on:
Security
Model
3/17/14
©
2012
Real-­‐Time
Innova:ons,
Inc.
-­‐
All
rights
reserved
39

40. 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
3/17/14
©
2012
Real-­‐Time
Innova:ons,
Inc.
-­‐
All
rights
reserved
40
MR#
6.5.1

41. 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
3/17/14
©
2012
Real-­‐Time
Innova:ons,
Inc.
-­‐
All
rights
reserved
41

42. 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
3/17/14
©
2012
Real-­‐Time
Innova:ons,
Inc.
-­‐
All
rights
reserved
42
MR#
6.5.1

43. Mapping
of
DDS
API
to
protected
opera:ons
3/17/14
©
2012
Real-­‐Time
Innova:ons,
Inc.
-­‐
All
rights
reserved
43
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

44. Secure
DDS
Specifica:on:
Security
Plugins
3/17/14
©
2012
Real-­‐Time
Innova:ons,
Inc.
-­‐
All
rights
reserved
44

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

46. Pla€orm
Independent
SPIs
3/17/14
©
2012
Real-­‐Time
Innova:ons,
Inc.
-­‐
All
rights
reserved
46
MR#
6.5.2

47. Pla€orm
Independent
Intercep:on
Pts
+
SPIs
3/17/14
©
2012
Real-­‐Time
Innova:ons,
Inc.
-­‐
All
rights
reserved
47
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

48. Buil:n
Plugins
3/17/14
©
2012
Real-­‐Time
Innova:ons,
Inc.
-­‐
All
rights
reserved
48
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

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

50. DDS
Security
Flow
3/17/14
©
2012
RTI
•
UNCLASSIFIED
•
PROPRIETARY
50
Create
Domain
Par:cipant
Authen:cate
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

51. DDS
Security
Flow:
Access
Control
3/17/14
©
2012
RTI
•
UNCLASSIFIED
•
PROPRIETARY
51
Create
Domain
Par:cipant
Authen:cate
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

52. DDS
Security
Flow
–
Remote
Authen:ca:on
3/17/14
©
2012
RTI
•
UNCLASSIFIED
•
PROPRIETARY
52
Discover
remote
Endpoints
Discover
remote
DP
Authen:cate
Remote
DP?
Ignore
Remote
DP
No
Yes
Access
OK?
Ignore
remote
endpoint
Receive
Auth
Token
No
Matched
DW?
Get
Keys
Get
remote
DW
tag
Yes
Yes
Does
the
remote
Data
Writer
match
a
local
Data
Reader

53. Secure
DDS
Specifica:on:
Authen:ca:on
Plugin
3/17/14
©
2012
Real-­‐Time
Innova:ons,
Inc.
-­‐
All
rights
reserved
53

54. Authen:ca:on
SPI
3/17/14
©
2012
Real-­‐Time
Innova:ons,
Inc.
-­‐
All
rights
reserved
54
MR#
6.5.2

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

56. 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.
3/17/14
©
2012
Real-­‐Time
Innova:ons,
Inc.
-­‐
All
rights
reserved
56

57. 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.
3/17/14
©
2012
Real-­‐Time
Innova:ons,
Inc.
-­‐
All
rights
reserved
57

58. 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
3/17/14
©
2012
Real-­‐Time
Innova:ons,
Inc.
-­‐
All
rights
reserved
58

59. 3/17/14
©
2012
Real-­‐Time
Innova:ons,
Inc.
-­‐
All
rights
reserved
59
Remote
Par:cipant
Authen:ca:on
Par:cipants
receive
Hash(X.509
Iden:tyCert)
&
Hash
(Permissions
Doc)
of
remote
par:cipant
via
discovery

60. 3/17/14
©
2012
Real-­‐Time
Innova:ons,
Inc.
-­‐
All
rights
reserved
60
Each
Par:cipant
calls
validate_remote_iden:ty().
Par:cipant
with
highest
GUID
returns
PENDING_HANDSHAKE_REQUEST,
the
other
PENDING_HANDSAHKE_MESSAGE
Remote
Par:cipant
Authen:ca:on

61. 3/17/14
©
2012
Real-­‐Time
Innova:ons,
Inc.
-­‐
All
rights
reserved
61
Par:cipant1
creates
CHALLENGE1
=
“CHALLENGE:<nonce>
and
sends
message
via
Par:cipantMessageWriter
with
HanshakeMessageToken
:=
{CHALLENGE1,
Iden:ty,
Permissions}
Remote
Par:cipant
Authen:ca:on

62. 3/17/14
©
2012
Real-­‐Time
Innova:ons,
Inc.
-­‐
All
rights
reserved
62
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}
Remote
Par:cipant
Authen:ca:on

63. 3/17/14
©
2012
Real-­‐Time
Innova:ons,
Inc.
-­‐
All
rights
reserved
63
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.
Remote
Par:cipant
Authen:ca:on

64. 3/17/14
©
2012
Real-­‐Time
Innova:ons,
Inc.
-­‐
All
rights
reserved
64
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
Remote
Par:cipant
Authen:ca:on

65. Secure
DDS
Specifica:on:
Access
Control
Plugin
3/17/14
©
2012
Real-­‐Time
Innova:ons,
Inc.
-­‐
All
rights
reserved
65

66. Access
Control
SPI
3/17/14
©
2012
Real-­‐Time
Innova:ons,
Inc.
-­‐
All
rights
reserved
66
MR#
6.5.2

67. 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
3/17/14
©
2012
Real-­‐Time
Innova:ons,
Inc.
-­‐
All
rights
reserved
67

68. 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)
3/17/14
©
2012
Real-­‐Time
Innova:ons,
Inc.
-­‐
All
rights
reserved
68

69. 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
3/17/14
©
2012
Real-­‐Time
Innova:ons,
Inc.
-­‐
All
rights
reserved
69

70. Example
Domain
Governance

71. Example
Permissions

72. Secure
DDS
Specifica:on:
Cryptographic
Plugin
3/17/14
©
2012
Real-­‐Time
Innova:ons,
Inc.
-­‐
All
rights
reserved
72

73. Cryptographic
SPI
3/17/14
©
2012
Real-­‐Time
Innova:ons,
Inc.
-­‐
All
rights
reserved
73

74. 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
3/17/14
©
2012
Real-­‐Time
Innova:ons,
Inc.
-­‐
All
rights
reserved
74

75. 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
3/17/14
©
2012
Real-­‐Time
Innova:ons,
Inc.
-­‐
All
rights
reserved
75

76. 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
3/17/14
©
2012
Real-­‐Time
Innova:ons,
Inc.
-­‐
All
rights
reserved
76

77. Background:
RTPS
3/17/14
©
2012
Real-­‐Time
Innova:ons,
Inc.
-­‐
All
rights
reserved
77
RTPS
SubMessage
RTPS
Header
RTPS
SubMessage
RTPS
SubMessage
RTPS
SubMessage
SubMsg
Header
SubMsg
Element
SubMsg
Element
SerializedData
RTPS
SubMessage
RTPS
Message

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

79. RTPS
SubMessage
SerializedData
RTPS
Header
RTPS
Header
RTPS
SubMessage
SecuredData
SerializedData
encode_serialized_data
RTPS
SubMessage
RTPS
SubMessage

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

81. RTPS
SubMessage
RTPS
SubMessage
RTPS
Header
RTPS
Header
RTPS
SecureSubMsg
encode_rtps_message
RTPS
SubMessage
RTPS
SubMessage
RTPS
SubMessage
RTPS
SubMessage

82. Cryptographic
SPI
at
the
wire-­‐protocol
level
©
2012
RTI
•
UNCLASSIFIED
•
PROPRIETARY
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
Transforma:on

83. 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
3/17/14
©
2012
Real-­‐Time
Innova:ons,
Inc.
-­‐
All
rights
reserved
83
MR#
6.5.3

84. 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.
3/17/14
©
2012
Real-­‐Time
Innova:ons,
Inc.
-­‐
All
rights
reserved
84

85. Data
Tagging
3/17/14
©
2012
Real-­‐Time
Innova:ons,
Inc.
-­‐
All
rights
reserved
85

86. 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
3/17/14
©
2012
Real-­‐Time
Innova:ons,
Inc.
-­‐
All
rights
reserved
86

87. Data
Logging
3/17/14
©
2012
Real-­‐Time
Innova:ons,
Inc.
-­‐
All
rights
reserved
87

88. 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
3/17/14
©
2012
Real-­‐Time
Innova:ons,
Inc.
-­‐
All
rights
reserved
88

89. 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.
3/17/14
©
2012
Real-­‐Time
Innova:ons,
Inc.
-­‐
All
rights
reserved
89

90. Discussion
3/17/14
©
2012
Real-­‐Time
Innova:ons,
Inc.
-­‐
All
rights
reserved
90

91. Your
systems.
Working
as
one.
Discussion
&
Next
Steps

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