This is the presentation on the 6th Revised Submission to the OMG DDS Security specification.

1. Your
systems.
Working
as
one.
DDS
SECURITY
6th
Revised
Submission
(Joint)
Presented
at
OMG
Mars
Task
Force
on
September
24,
2013
Doc
num:
mars/2013-­‐09-­‐09
SpecificaTon
lead:
Gerardo
Pardo-­‐Castellote,
Ph.D.
CTO,
Real-­‐Time
InnovaTons,
Inc.
SubmiVers:
Real-­‐Time
InnovaTons,
Inc.
PrismTech
Corp.
eProsima
(supporter)
©
2012
Real-­‐Time
InnovaTons,
Inc.
-­‐
All
rights
reserved

2. Outline
for
DDS
Security
Spec
• Status
recap
• Scope
• Threats
• Summary
of
RFP
requirements
• SpecificaTon
details
– Overview
– Security
Model
– DDS
&
RTPS
support
for
security
– Security
Plugin
Architecture
• Security
Plugins
– AuthenTcaTon
plugin
– AccessControl
plugin
– Cryptographic
plugin
– DataTagging
plugin
– DataLogging
plugin
10/9/13
©
2012
Real-­‐Time
InnovaTons,
Inc.
-­‐
All
rights
reserved
2

3. Status
recap
• Started
with
two
separate
submissions
by
RTI
and
PrismTech
• As
of
the
December
2012
all
joined
the
RTI
submission
• Several
reviews,
last
one
in
Berlin
idenTfied
a
couple
of
vulnerabiliTes
– Sequence
Number
AVack
on
reliable
channels
– Cuckoo
aVack
on
ParTcipant
GUID
• Most
current
version
cleaned
spec
and
addresses
idenTfied
vulnerabiliTes
• Some
under-­‐specified
issues
remain
10/9/13
©
2012
Real-­‐Time
InnovaTons,
Inc.
-­‐
All
rights
reserved
3

4. Scope
10/9/13
©
2012
Real-­‐Time
InnovaTons,
Inc.
-­‐
All
rights
reserved
4

5. Security
as
a
system
problem
• UlTmately
security
is
a
system
property
– Involves
hardware,
soaware,
humans,
procedures…
• Most
directly
related:
1. Securing
the
data-­‐centric
bus
2. IntegraTng
across
security
domains
3. Securing
the
operaTng
system
4. Securing
the
hardware
&
soaware
configuraTon
10/9/13
©
2012
Real-­‐Time
InnovaTons,
Inc.
-­‐
All
rights
reserved
5
Scope
of
the
RFP
Out
of
Scope

6. 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
10/9/13
©
2012
Real-­‐Time
InnovaTons,
Inc.
-­‐
All
rights
reserved
Ul5mately
you
need
to
implement
the
3
of
them
6

7. Fine-­‐Grained
Data-­‐Centric
Security
• Access
control
per
Topic
• Read
versus-­‐write
permissions
• Field-­‐specific
permissions
(not
addressed)
Topics
10/9/13
7
©
2012
Real-­‐Time
InnovaTons,
Inc.
-­‐
All
rights
reserved

8. Threats
10/9/13
©
2012
Real-­‐Time
InnovaTons,
Inc.
-­‐
All
rights
reserved
8

9. Threats
1. Unauthorized
subscripTon
2. Unauthorized
publicaTon
3. Tampering
and
replay
4. Unauthorized
access
to
data
by
infrastructure
services
10/9/13
©
2012
Real-­‐Time
InnovaTons,
Inc.
-­‐
All
rights
reserved
9
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. Data-­‐centric/mulTcast
Insider
Threats
• Two
insider
threats
affecTng
(mulTcast)
data-­‐
centric
systems
are
of
unique
significance
1. Reader
mis-­‐behaves
as
unauthorized
writer
An
applicaTon
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/9/13
©
2012
Real-­‐Time
InnovaTons,
Inc.
-­‐
All
rights
reserved
10

11. Reader
mis-­‐behaves
as
unauthorized
writer
• SituaTon:
– Alice
-­‐
creates
a
Crypto
Key
per
Topic/DataWriter
– Alice
-­‐
shares
its
Key
with
all
intended
readers
as
needed
to
mulTcast
– Mallory
–
is
an
authorized
reader
so
it
has
Alice’s
key
– Mallory
–
behaves
maliciously
and
uses
Alice’s
key
to
create
fake
UDP
messages
pukng
Alice’s
informaTon
(IP,
Port,
GUIDs,
etc.)
but
with
bad
data.
• ImplicaTons:
– 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
aVack
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
10/9/13
©
2012
Real-­‐Time
InnovaTons,
Inc.
-­‐
All
rights
reserved
11

12. Session
Sequence
Number
AVack
• 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
aVacker
can
spoof
a
packet
with
the
session
ID
and
Hearbeat/GAP
causing
the
DataReader
to
advance
the
session
sequence-­‐numbers
blocking
future
messages
recepTon
– AVacker
only
needs
GUID
of
the
DataWriter
to
aVack,
which
can
be
obtained
from
snooping
traffic.
– AaVack
can
be
used
to
prevent
the
AuthenTcaTon
of
legiTmate
ParTcipants
10/9/13
©
2012
Real-­‐Time
InnovaTons,
Inc.
-­‐
All
rights
reserved
12

13. Cuckoo
AVack
on
GUID
• Background:
– DDS
DomainParTcipants
are
idenTfied
by
unique
GUID,
Readers/Writers
derive
their
GUID
from
it.
– GUID
used
to
uniquely
idenTfies
the
RTPS
sessions
and
the
locaTon
of
each
parTcipant
• Vulnerability:
– An
aVacker
with
legit
IdenTty
can
authenTcate
using
the
GUID
of
another
ParTcipant
– AVacker
with
be
accepted
with
“cuckooed”
GUID
blocking
legiTmate
ParTcipant
from
using
its
GUID
– AVacker
only
needs
GUID
of
the
ParTcipant
to
aVack,
which
can
be
obtained
from
snooping
traffic.
10/9/13
©
2012
Real-­‐Time
InnovaTons,
Inc.
-­‐
All
rights
reserved
13

14. Summary
of
RFP
requirements
10/9/13
©
2012
Real-­‐Time
InnovaTons,
Inc.
-­‐
All
rights
reserved
14

15. RFP
Mandatory
Requirements
Proposals
shall
define
…
6.5.1
…
a
Plasorm
Independent
Security
Model
for
DDS
independent
of
the
programming
language
used…
6.5.2
…
a
collecTon
of
Plasorm
Independent
IntercepTon
Points
and
SPIs
…
6.5.3
…
built-­‐in
Plasorm
Independent
Security
Plugins
that
implement
the
Plasorm
Independent
Interfaces
6.5.4
…
plasorm
specific
mappings
for
the
built-­‐in
plugins
to
all
the
language
PSMs
supported
by
DDS
6.5.5
…
how
the
DDS
Interoperability
Wire
Protocol
is
used
to
allow
DDS
applicaTons
to
interoperate
securely
10/9/13
©
2012
Real-­‐Time
InnovaTons,
Inc.
-­‐
All
rights
reserved
15

16. Mandatory
Requirements
6.5.1:
Security
Model
The
Security
Model
for
DDS
shall
…
6.5.1.1
…
support
mechanisms
that
establish
the
ability
for
a
DDS
ParTcipant
to
run
in
a
plasorm
6.5.1.2
…
support
mechanisms
to
configure
and
access
the
credenTals
of
the
underlying
DDS
ParTcipants
…
6.5.1.3
…
allow
specificaTon
of
authorizaTon
policies,
controlling
[1]
Joining
a
DDS
Domain
[2]
Access
to
DDS
Discovery
Data
[3]
Publishing
a
DDS
Topic,
[4]
Subscribing
to
a
DDS
Topic
[5]
Publishing
on
a
DDS
ParTTon,
[6]
Subscribing
on
a
DDS
ParTTon
6.5.1.4
…
include
the
concept
of
data
tagging
6.5.1.5
…
support
mechanism
for
ensuring
data
integrity,
including
[1]
traceability,
pedigree,
and
tamper
[2]
digital
signatures
[3]
data
encrypTon
[4]
use
of
different
keys
for
data
from
different
DataWriters
10/9/13
©
2012
Real-­‐Time
InnovaTons,
Inc.
-­‐
All
rights
reserved
16

17. Mandatory
Requirements
6.5.2:
Set
of
IntercepTon
Points
and
SPIs
The
Plugin
SPIs
shall
…
6.5.2.1
…
allow
applicaTons
to
exchange
credenTals
with
a
DDS
ParTcipant
[1]
exchanging
credenTals
for
authenTcaTon
[2]
delegaTon
of
authority
for
authenTcaTon
6.5.2.2
…
allow
an
external
plugin
to
perform
all
the
authorizaTon
funcTons
[1]
full
support
of
the
authorizaTon
policies
[3]
support
delegaTon
of
authority
[4]
support
delegaTon
of
authority
separately
for
each
DDS
Topic
6.5.2.3
…
allow
an
external
plugin
to
perform
all
the
tagging
and
tag-­‐accessing
funcTons
6.5.2.4
…
allow
an
external
plugin
to
perform
all
the
encrypTon
and
decrypTon
funcTons
6.5.2.5
…
external
plugin
to
perform
all
the
digital
signing
and
verificaTon
funcTons
10/9/13
©
2012
Real-­‐Time
InnovaTons,
Inc.
-­‐
All
rights
reserved
17

18. RFP
OpTonal
Requirements
Proposals
may
define
authorizaTon
policies
that
control
…
6.6.1
…
the
content
a
DDS
ParTcipant
is
allowed
to
publish
on
a
Topic.
6.6.2
…
the
content
a
DDS
ParTcipant
is
allowed
to
subscribe
on
a
Topic..
6.6.3
…
the
QoS
Policies
a
DDS
ParTcipants
can
use
when
publishing
a
Topic
6.6.4
…
the
QoS
Policies
a
DDS
ParTcipant
can
use
when
subscribing
to
a
Topic.
Proposals
may
define
…
6.6.5
…
data-­‐tagging
plugins
that
apply
different
tags
for
each
data-­‐sample
published
by
a
DDS
DataWriter.
6.6.6
…
built-­‐in
plugins
that
interoperate
with
standard
authenTcaTon
and
authorizaTon
protocols
and
services,
such
as,
LDAP
and
SAML.
6.6.7
…
a
PSM
mapping
of
the
DDS-­‐RTPS
Interoperability
Wire
Protocol
to
a
secure
transport,
such
as,
DTLS.
6.6.8
…
a
PSM
of
the
DDS-­‐RTPS
Interoperability
Wire
Protocol
allowing
interoperability
over
UnidirecTonal
Transports.
10/9/13
©
2012
Real-­‐Time
InnovaTons,
Inc.
-­‐
All
rights
reserved
18

19. Overview
of
DDS
Security
spec.
10/9/13
©
2012
Real-­‐Time
InnovaTons,
Inc.
-­‐
All
rights
reserved
19

20. Submission
Guiding
Principles
• Performance
&
Scalability
– Do
not
impact
parts
of
the
system
that
do
not
have
security
needs
– Allow
opTng
out
of
specific
features
such
as
MAC,
EncrypTon.
Digital
Signature
with
sufficient
granularity
– Limit
use
of
asymmetric
keys
to
discovery
&
session
establishment
– Support
MulTcast
• Robustness
&
Availability
– Be
robust
to
the
failure
or
compromise
of
any
single
component.
– Limit
privileges
of
infrastructure
services
and
relays
– Avoid
centralized
policy
decisions/services
– Avoid
mulT-­‐party
key
agreement
protocols
• Fitness
to
data-­‐centric
model
– Express
policies
and
permissions
in
terms
of
familiar
DDS
terminology
and
objects
– Support
all
of
DDS:
consumpTon
of
samples
out
of
order,
best
efforts,
Tme
filters,
history
cache,
etc.
• Leverage
exis5ng
technologies
– Support
plugging
in
exiTng
technologies
for
ciphers,
MAC,
PKI
• Ease
of
use
&
Flexibility
– Do
not
preclude
integraTng
with
their
exisTng
security
and
crypto
infrastructure.
10/9/13
©
2012
Real-­‐Time
InnovaTons,
Inc.
-­‐
All
rights
reserved
20

21. Audience
and
Purpose
for
this
SpecificaTon
• Audience:
– DDS
vendors/implementers,
not
the
users
of
DDS
• Purpose:
– Define
a
Security
Model
for
DDS
systems
– Define
concrete
IntercepTon
points
in
the
middleware
where
SPI
interfaces
must
be
called
– Define
concrete
SPI
Interfaces
vendors
must
invoke
at
the
IntercepTon
Points
and
the
behavior
upon
various
returns
– Define
specific
SPI
implementaTons
to
the
extent
required
for
interoperability
– NOT
guidance
to
users
implemenTng
secure
DDS
systems
– NOT
defini5on
of
security
technologies
beyond
what
is
required
to
implement
the
specificaTon
10/9/13
©
2012
Real-­‐Time
InnovaTons,
Inc.
-­‐
All
rights
reserved
21

22. DDS
Security
covers
4
related
concerns
10/9/13
©
2012
Real-­‐Time
InnovaTons,
Inc.
-­‐
All
rights
reserved
22
Security
Plugin
APIs
&
Behavior
DDS
&
RTPS
support
for
Security
Buil5n
Plugins
Security
Model

23. Security
Model
10/9/13
©
2012
Real-­‐Time
InnovaTons,
Inc.
-­‐
All
rights
reserved
23

24. Security
Model
• A
security
model
is
defined
in
terms
of:
– The
subjects
(principals)
– The
objects
being
protected
• The
operaTons
that
are
protected
on
the
objects
– Access
Control
Model
• A
way
to
map
each
subject
to
the
objects
they
can
perform
operaTons
on
and
which
are
the
allowed
operaTons
10/9/13
©
2012
Real-­‐Time
InnovaTons,
Inc.
-­‐
All
rights
reserved
24
MR#
6.5.1

25. Security
Model
Example:
UNIX
FileSystem
(simplified)
• Subjects:
Users,
specifically
processes
execuTng
on
behalf
of
a
specific
userid
• Protected
Objects:
Files
and
Directories
• Protected
OperaTons
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
combinaTon
of
READ,
WRITE,
EXECUTE
permissions
for
the
assigned
OWNER
and
GROUP
– Each
protected
operaTon
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
10/9/13
©
2012
Real-­‐Time
InnovaTons,
Inc.
-­‐
All
rights
reserved
25

26. DDS
Security
Model
• Subjects:
DDS
DomainParTcipant
(ParTcipant
GUID)
• Protected
Objects:
DDS
Domain
and
DDS
Topic
• Protected
Opera5ons
on
Objects
(logical
view):
– DomainParTcipant.join
– DomainParTcipant.set_read_parTTons
.set_write_parTTons
– 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
10/9/13
©
2012
Real-­‐Time
InnovaTons,
Inc.
-­‐
All
rights
reserved
26
MR#
6.5.1

27. Mapping
of
DDS
API
to
protected
operaTons
10/9/13
©
2012
Real-­‐Time
InnovaTons,
Inc.
-­‐
All
rights
reserved
27
DDS
API
Call
Protected
Opera5on
DomainParTcipantFactory.create_parTcipant
Discovery.match_remote_parTcipant
DomainParTcipant.join
DomainParTcipant.create_publisher
Publisher.set_qos
DomainParTcipant.set_write_parTTons
DomainParTcipant.create_subscriber
Subscriber.set_qos
DomainParTcipant.set_read_parTTons
DomainParTcipant.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

28. DDS
&
RTPS
Support
for
Security
10/9/13
©
2012
Real-­‐Time
InnovaTons,
Inc.
-­‐
All
rights
reserved
28

29. Support
for
Security
in
DDS
&
RTPS
• DDS
ParTcipants
need
to
exchange
security
informaTon
– CerTficates
for
AuthenTcaTon
&
Permissions
– Handshake
messages
for
mutual
authenTcaTon
and
shared-­‐
secret
establishment
– KeyTokens
for
key-­‐exchange
• Some
reuse
of
exisTng
DDS
mechanisms
– Discovery
topics
– BuilTn
data
readers
/
writers
• AddiTon
of
a
InterparTcipantStatelessWriter/Reader
• EncrypTon
and
signatures
introduce
new
RTPS
Submessage
and
Submessage
elements
– SecureSubMessage
– SecuredData
10/9/13
©
2012
Real-­‐Time
InnovaTons,
Inc.
-­‐
All
rights
reserved
29

30. Extensions
to
BuilTnTopics
• DCPSParTcipants:
– AddiTonal
members:
idenTty_token
:
IdenTtyToken
(PID
0x1001)
permissions_token
:
PermissionsToken
(PID
0x1002)
• DCPSPublicaTons
and
DCPSSubscripTons:
– AddiTonal
member:
data_tags
:
DataTag
(PID
0x1003)
struct
Tag
{
string
name;
string
value;
};
struct
DataTags
{
sequence<Tag>;
};
struct DataHolder {
string classid;
StringMap properties;
OctetsMap properties;
StringSeq strings_value;
OctetSeq binary_value1;
OctetSeq binary_value2;
LongLongSeq longlongs_value;
};
//@Extensibility
MUTABLE_EXTENSIBILITY
struct Token DataHolder ;
typedef <XXX>Token Token;
Changed

31. InterParTcipantStateless
channel
• Inherent
“sequence
number”
vulnerability
with
any
stateful
channel.
– Send
a
Heartbeat
for
a
future
sequence
number
effecTvely
shuts
down
channel
• Well-­‐known
in
TCP.
But
miTgated
via:
– Random
start
sequence
number
per
session
– RejecTon
of
sequence
numbers
outside
window
These
“works”
for
TCP
because
it
is
point-­‐to-­‐point
and
is
not
communicaTng
state
(so
no
GAPs).
It
would
not
work
for
discovery,
using
mulTcast,
etc.
To
be
robust
to
this
aVack
you
need
a
protocol
that
does
not
reject
things
based
on
sequence
numbers
This
is
already
supported
in
the
RTPS
specificaTon
10/9/13
©
2012
Real-­‐Time
InnovaTons,
Inc.
-­‐
All
rights
reserved
31

32. InterParTcipant
Stateless
channel
• InterparTcipantStatelessWriter
and
InterparTcipantStatelessReader
• InterparTcipantStatelessGenericMessage
10/9/13
©
2012
Real-­‐Time
InnovaTons,
Inc.
-­‐
All
rights
reserved
32
struct
MessageIdenTty
{
octet
source_guid[16];
long
long
sequence_number;
};
typedef
string<>
GenericMessageClassId;
struct
InterParTcipantStatelessGenericMessage
{
//
target
for
the
request.
Can
be
GUID_UNKNOWN
BuilTnTopicKey_t
des5na5on_par5cipant_key;
MessageIdenTty
messageIdenTty;
MessageIdenTty
relatedMessageIdenTty;
GenericMessageClassId
msgClassid;
DataHolder msgData;
//@shared
};
//@Extensibility
MUTABLE_EXTENSIBILITY
Uses
the
RTPS
stateless
writers
and
readers
RTPS
v.
2.1
SecTon
8.4.7.2
and
8.4.10.2

33. Security
informaTon
exchanged
via
InterParTcipantStatelessWriter/Reader
Behavior:
RTPS
v
2.1
stateless
writer/rdr
(secTon
8.4.7.2
&
8.4.10.2)
• Does
not
reject
messages
based
on
sequence
number
• Robust
against
sequence
number
aVack
10/9/13
©
2012
Real-­‐Time
InnovaTons,
Inc.
-­‐
All
rights
reserved
33
struct
MessageIdenTty
{
octet
source_guid[16];
long
long
sequence_number;
};
typedef
string<>
GenericMessageClassId;
struct
InterParTcipantStatelessGenericMessage
{
//
target.
Can
be
GUID_UNKNOWN
BuilTnTopicKey_t
des5na5on_par5cipant_key;
MessageIdenTty
message_idenTty;
MessageIdenTty
related_message_idenTty;
GenericMessageClassId
message_classid;
DataHolder
message_data;
//@shared
};
//@Extensibility
MUTABLE_EXTENSIBILITY
Changed
4
message
kinds:
GMCLASSID_SECURITY_AUTH_HANDSHAKE
GMCLASSID_SECURITY_PARTICIPANT_CRYPTO_TOKENS
GMCLASSID_SECURITY_DATAWRITER_CRYPTO_TOKENS
GMCLASSID_SECURITY_DATAREADER_CRYPTO_TOKENS

34. Security
informaTon
exchanged
via
InterParTcipantStateless
Writer/Reader
10/9/13
©
2012
Real-­‐Time
InnovaTons,
Inc.
-­‐
All
rights
reserved
34
struct
CryptoTokensMsg
{
octet
sending_guid[16];
octet
receiving_guid[16];
sequence<CryptoToken>
crypto_tokens;
};
typedef
Token
HandshakeTokenMsg;
typedef
CryptoTokensMsg
Par5cipantCryptoTokensMsg;
typedef
CryptoTokensMsg
DatawriterCryptoTokensMsg;
typedef
CryptoTokensMsg
DatareaderCryptoTokensMsg;
4
message
kinds:
GMCLASSID_SECURITY_AUTH_HANDSHAKE
GMCLASSID_SECURITY_PARTICIPANT_CRYPTO_TOKENS
GMCLASSID_SECURITY_DATAWRITER_CRYPTO_TOKENS
GMCLASSID_SECURITY_DATAREADER_CRYPTO_TOKENS

35. Protocol-­‐level
support
Background:
RTPS
10/9/13
©
2012
Real-­‐Time
InnovaTons,
Inc.
-­‐
All
rights
reserved
35
RTPS
SubMessage
RTPS
Header
RTPS
SubMessage
RTPS
SubMessage
RTPS
SubMessage
SubMsg
Header
SubMsg
Element
SubMsg
Element
SerializedData
RTPS
SubMessage
RTPS
Message

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

37. Security
Plugin
Architecture
10/9/13
©
2012
Real-­‐Time
InnovaTons,
Inc.
-­‐
All
rights
reserved
37

38. Plasorm
Independent
IntercepTon
Pts
+
SPIs
10/9/13
©
2012
Real-­‐Time
InnovaTons,
Inc.
-­‐
All
rights
reserved
38
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

39. Plasorm
Independent
SPIs
10/9/13
©
2012
Real-­‐Time
InnovaTons,
Inc.
-­‐
All
rights
reserved
39
MR#
6.5.2

40. BuilTn
Plugins
10/9/13
©
2012
Real-­‐Time
InnovaTons,
Inc.
-­‐
All
rights
reserved
40
SPI
Buil5n
Plungin
Notes
AuthenTcaTon
DDS:Auth:PKI-­‐RSA/DSA-­‐DH
Uses
PKI
with
a
pre-­‐configured
shared
CerTficate
Authority.
DSA
and
Diffie-­‐Hellman
for
authenTcaTon
and
key
exchange
Establishes
shared
secret
AccessControl
DDS:Access:PKI-­‐Signed-­‐
XML-­‐Permissions
Permissions
document
signed
by
shared
CerTficate
Authority
Cryptography
DDS:Crypto:AES-­‐CTR-­‐
HMAC-­‐RSA/DSA-­‐DH
Protected
key
distribuTon
AES128
and
AES256
for
encrypTon
(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

41. Mapping
to
DDS
Language
PSMs
• Plugin
SPIs
to
be
defined
using
IDL
• IDL-­‐to-­‐Language
mappings
used
for
each
Language
PSM
• No
need
to
define
mappings
to
new
Javs5
PSM
and
STD-­‐C++
PSM
– IDL-­‐derived
Language
PSMs
suffice
as
these
are
low-­‐level
interfaces
that
will
only
be
exercised
by
SPI
plugin
implementers.
NOTE:
IDL
file
is
missing
from
submission
10/9/13
©
2012
Real-­‐Time
InnovaTons,
Inc.
-­‐
All
rights
reserved
41
MR#
6.5.4

42. AuthenTcaTon
10/9/13
©
2012
Real-­‐Time
InnovaTons,
Inc.
-­‐
All
rights
reserved
42

43. AuthenTcaTon
SPI
10/9/13
©
2012
Real-­‐Time
InnovaTons,
Inc.
-­‐
All
rights
reserved
43
MR#
6.5.2

44. Full
AuthenTcaTon
SPI
• validate_local_idenTty
• get_idenTty_token
• set_permissions_credenTal_and_token
• validate_remote_idenTty
• begin_handshake_request
• begin_handshake_reply
• process_handshake
• get_shared_secret
• get_peer_permissions_credenTal_token
• set_listener
• return_idenTty_token
• return_peer_permissions_credenTal_token
• return_handshake_handle
• return_idenTty_handle
• return_sharedsecret_handle
10/9/13
©
2012
Real-­‐Time
InnovaTons,
Inc.
-­‐
All
rights
reserved
44

45. AuthenTcaTon
Behavior
10/9/13
©
2012
Real-­‐Time
InnovaTons,
Inc.
-­‐
All
rights
reserved
45
MR#
6.5.2
Meta-­‐Protocol
to
handshake
and
establish
shared
secret

46. BuilTn
DDS:Auth:PKI-­‐DSA-­‐DH
• Uses
shared
CerTficate
Authority
(CA)
– All
ParTcipants
pre-­‐configured
with
shared-­‐CA
• Performs
mutual
authenTcaTon
between
discovered
parTcipants
using
the
Digital
Signature
Algorithm
(DSA)
• Establishes
a
shared
secret
using
Diffie-­‐
Hellman.
10/9/13
©
2012
Real-­‐Time
InnovaTons,
Inc.
-­‐
All
rights
reserved
46

47. ConfiguraTon
of
Auth:PKI-­‐DS-­‐DH
• Three
things:
– X.509
cerTficate
that
defines
the
shared
CA.
This
cerTficate
contains
the
Public
Key
of
the
CA.
– RSA
private
key
of
the
DomainParTcipant.
– A
(PEM-­‐encoded)
X.509
cerTficate
that
chains
up
to
the
CA,
that
binds
the
DomainParTcipant
public
key
to
the
disTnguished
name
(subject
name)
for
the
parTcipant
and
any
intermediate
CA
cerTficates
required
to
build
the
chain.
• ConfiguraTon
API
outside
scope
of
specificaTon
– Vendors
can
use
file,
QoS
property,
etc.
10/9/13
©
2012
Real-­‐Time
InnovaTons,
Inc.
-­‐
All
rights
reserved
47

48. Behavior
of
Auth:PKI-­‐DS-­‐DH
• validate_local_parTcipant
– IdenTtyCredenTalToken
has
X.509
cerTficate
– Validates
cerTficate
against
CA
• begin_handshake_request
– Sends
X.509
CerTficate
to
peer
parTcipant
– Sends
Signed
Permissions
to
to
peer
parTcipant
– Sends
Challenge
• begin_handshake_reply
– Sends
X.509
CerTficate
to
peer
parTcipant
– Sends
Signed
Permissions
to
to
peer
parTcipant
– Replies
to
Challenge
&
sends
counter
Challenge
• process_handshake
– Verifies
challenge
response
– Responds
to
final
challenge
– Exchanges
SharedSecret
10/9/13
©
2012
Real-­‐Time
InnovaTons,
Inc.
-­‐
All
rights
reserved
48

49. 10/9/13
©
2012
Real-­‐Time
InnovaTons,
Inc.
-­‐
All
rights
reserved
49
Remote
ParTcipant
AuthenTcaTon
ParTcipants
receive
Hash(X.509
IdenTtyCert)
&
Hash
(Permissions
Doc)
of
remote
parTcipant
via
discovery

50. 10/9/13
©
2012
Real-­‐Time
InnovaTons,
Inc.
-­‐
All
rights
reserved
50
Each
ParTcipant
calls
validate_remote_idenTty().
ParTcipant
with
highest
GUID
returns
PENDING_HANDSHAKE_REQUEST,
the
other
PENDING_HANDSAHKE_MESSAGE
Remote
ParTcipant
AuthenTcaTon

51. 10/9/13
©
2012
Real-­‐Time
InnovaTons,
Inc.
-­‐
All
rights
reserved
51
ParTcipant1
creates
CHALLENGE1
=
“CHALLENGE:<nonce>
and
sends
message
via
ParTcipantMessageWriter
with
HanshakeMessageToken
:=
{CHALLENGE1,
IdenTty,
Permissions}
Remote
ParTcipant
AuthenTcaTon

52. 10/9/13
©
2012
Real-­‐Time
InnovaTons,
Inc.
-­‐
All
rights
reserved
52
ParTcipant2
validates
IdenTty
of
ParTcipant1
against
CA
ParTcipant2
creates
CHALLENGE2
:=
CHALLENGE:<nonce>
ParTcipant2
sends
to
ParTcipant1
message
with
MessageToken
:=
{SIGN(CHALLENGE1),
CHALLENGE2,
IdenTty,
Permissions}
Remote
ParTcipant
AuthenTcaTon

53. 10/9/13
©
2012
Real-­‐Time
InnovaTons,
Inc.
-­‐
All
rights
reserved
53
Part1
validates
IdenTty
of
ParTcipant2
against
CA
Part1
verifies
SIGN(CHALLENGE1)
using
ParTcipant2’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
ParTcipant
AuthenTcaTon

54. 10/9/13
©
2012
Real-­‐Time
InnovaTons,
Inc.
-­‐
All
rights
reserved
54
Part2
verifies
SIGN(
HASH(CHALLENGE2
#
ENCRYPT(SharedSecret)))
using
Part1’s
PK
Part2
decrypts
ENCRYPT(SharedSecret)
using
its
own
PK
We
have
Mutual
Authen5ca5on
and
a
SharedSecret
Remote
ParTcipant
AuthenTcaTon

55. Access
Control
10/9/13
©
2012
Real-­‐Time
InnovaTons,
Inc.
-­‐
All
rights
reserved
55

56. Access
Control
SPI
10/9/13
©
2012
Real-­‐Time
InnovaTons,
Inc.
-­‐
All
rights
reserved
56
MR#
6.5.2

57. Full
AccessControl
SPI
• check_create_parTcipant
• check_create_datawriter
• check_create_datareader
• check_create_topic
• check_local_datawriter_register_instance
• check_local_datawriter_dispose_instance
• check_remote_parTcipant
• 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_credenTal_token
• set_listener
• return_permissions_token
• return_permissions_credenTal_token
• validate_local_permissions
• validate_remote_permissions
10/9/13
©
2012
Real-­‐Time
InnovaTons,
Inc.
-­‐
All
rights
reserved
57

58. Support
for
AccessControl
on
data-­‐tags
and
parTTons
• check_local_datawriter_match
• check_local_datareader_match
– OperaTons
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
aVributes
(e.g.
based
on
parTTon
names)
10/9/13
©
2012
Real-­‐Time
InnovaTons,
Inc.
-­‐
All
rights
reserved
58

59. BuilTn
DDS:AC:PKI
SPI
• Configured
with:
– X.509
CerTficate
of
shared
Permissions
CA
– PermissionsCredenTalToken
• PermissionsCredenTalToken
contains
– XML
file
with
permissions
– Includes
SubjectName
matching
the
one
on
IdenTtyCredenTalToken
– All
signed
by
Permissions
CA
– FormaXed
as
PKCS#7
document
of
type
signed
data
This
binds
the
permissions
to
the
idenTty
established
by
the
AuthenTcaTonPlugin
10/9/13
©
2012
Real-­‐Time
InnovaTons,
Inc.
-­‐
All
rights
reserved
59

60. Example
Permissions
10/9/13
©
2012
Real-­‐Time
InnovaTons,
Inc.
-­‐
All
rights
reserved
60

61. Cryptographic
10/9/13
©
2012
Real-­‐Time
InnovaTons,
Inc.
-­‐
All
rights
reserved
61

62. 10/9/13
©
2012
Real-­‐Time
InnovaTons,
Inc.
-­‐
All
rights
reserved
62
Cryptographic

63. Full
Cryptographic
SPI
(CryptoKeyFactory)
• register_local_parTcipant
• register_matched_remote_parTcipant
• register_local_datawriter
• register_matched_remote_datareader
• register_local_datareader
• register_matched_remote_datawriter
• unregister_parTcipant
• unregister_datawriter
• unregister_datareader
10/9/13
©
2012
Real-­‐Time
InnovaTons,
Inc.
-­‐
All
rights
reserved
63

64. 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
10/9/13
©
2012
Real-­‐Time
InnovaTons,
Inc.
-­‐
All
rights
reserved
64

65. Full
Cryptographic
SPI
(CryptoTransform)
• register_local_parTcipant
• register_matched_remote_parTcipant
• register_local_datawriter
• register_matched_remote_datareader
• register_local_datareader
• register_matched_remote_datawriter
• unregister_parTcipant
• unregister_datawriter
• unregister_datareader
10/9/13
©
2012
Real-­‐Time
InnovaTons,
Inc.
-­‐
All
rights
reserved
65

66. RTPS
SubMessage
SerializedData
RTPS
Header
RTPS
Header
RTPS
SubMessage
SecuredData
SerializedData
encode_serialized_data
RTPS
SubMessage
RTPS
SubMessage

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

68. RTPS
SubMessage
RTPS
SubMessage
RTPS
Header
RTPS
Header
RTPS
SecureSubMsg
encode_rtps_message
RTPS
SubMessage
RTPS
SubMessage
RTPS
SubMessage
RTPS
SubMessage

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

70. Crypto-­‐AES-­‐CTR-­‐HMAC-­‐DSA-­‐DH
• EncrypTon
uses
AES
in
counter
mode
– Similar
to
SRTP,
but
enhanced
to
support
mulTple
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
criTcal
to
support
DDS
QoS
like
history,
content
filters,
best-­‐efforts
etc.
• DSA
and
Diffie-­‐Hellman
used
for
mutual
authenTcaTon
and
secure
key
exchange
10/9/13
©
2012
Real-­‐Time
InnovaTons,
Inc.
-­‐
All
rights
reserved
70
MR#
6.5.3

71. BuilTn
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
BuilTnPublicaTonWriter:
– 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
• EncrypTon
uses
AES
in
Counter
(CTR)
mode
– The
session
counter
is
sent
on
EncryptedMessage
Envelope.
10/9/13
©
2012
Real-­‐Time
InnovaTons,
Inc.
-­‐
All
rights
reserved
71

72. Data
Tagging
10/9/13
©
2012
Real-­‐Time
InnovaTons,
Inc.
-­‐
All
rights
reserved
72

73. DataTagging:
DDS:Tagging:DDS_Discovery
• DataWriter
and
DataReader
enTTes
have
associated
tags
• DataWriter
Tags
are
propagated
via
DDS
discovery
• AccessControl
plugin
has
visibility
into
tags
and
can
make
decisions
based
on
that
• BuilTn
plugins
– AccessControl
plugin
ignores
tags
– Permissions
document
format
does
not
allow
rules
based
on
data-­‐tags
– Rules
can
be
added
when
use-­‐case
is
beVer
understood
10/9/13
©
2012
Real-­‐Time
InnovaTons,
Inc.
-­‐
All
rights
reserved
73

74. Data
Logging
10/9/13
©
2012
Real-­‐Time
InnovaTons,
Inc.
-­‐
All
rights
reserved
74

75. DataLogging:
DDS:Logging:DDS_LogTopic
[SecTon
sTll
missing]
• Intent
is
to
use
a
dedicated
DDS
Topic
to
Log
the
security-­‐relevant
messages
• DDS
Secure
Log
Topic
will
be
encrypted
10/9/13
©
2012
Real-­‐Time
InnovaTons,
Inc.
-­‐
All
rights
reserved
75

76. Status
&
Conclusions
• We
feel
specificaTon
will
be
ready
to
adopt
in
December
• Tasks/Missing
items
– Update
UML
with
added
operaTons
– Complete
secTons
7.2.3
and
7.2.4
(extra
details
on
how
RTPS
is
affected)
– Add
descripTon
on
how
discovery
traffic
is
secured
(Kx
for
builTn
topics)
– Add
descripTon
of
the
built-­‐in
Logging
plugin
– Review
document
for
grammar
10/9/13
©
2012
Real-­‐Time
InnovaTons,
Inc.
-­‐
All
rights
reserved
76

77. Find
out
more…
www.rT.com
community.rT.com
demo.rT.com
www.youtube.com/realTmeinnovaTons
blogs.rT.com
www.twiVer.com/RealTimeInnov
www.facebook.com/RTIsoaware
www.slideshare.net/GerardoPardo
dds.omg.org
www.omg.org
©
2012
RTI
•
ALL
RIGHTS
RESERVED
77