Revised Submission to the OMG Security RFP. Covers the plugin architecture and the proposed builtin plugins to provide Authentication, Access Control, Key Management, Confidentiality (Encryption), Message Authentication, and Auditing

1. Your
systems.
Working
as
one.
DDS
SECURITY
Revised
Submission
Doc
num:
mars/2012-­‐06-­‐15
SubmiMer:
Gerardo
Pardo-­‐Castellote,
Ph.D.
Real-­‐Time
InnovaLons,
Inc.
CTO,
Real-­‐Time
InnovaLons,
Inc.
©
2012
Real-­‐Time
InnovaLons,
Inc.
-­‐
All
rights
reserved

2. Agenda
• Background
• Requirements
• Threats
• Security
Model
• Plugins
and
SPIs
• BuilLn
Plugins
• Status
&
Conclusion
6/25/12
©
2012
Real-­‐Time
InnovaLons,
Inc.
-­‐
All
rights
reserved
2

3. Security
Terms:
a
Safe-­‐Deposit
Box
• AuthenLcaLon:
The
bank
knows
who
you
are;
you
must
show
ID.
• Access
Control:
The
bank
only
lets
those
on
an
access
list
into
your
box.
• ConfidenLality:
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
repudiaLon:
You
sign
when
you
come
in
and
out
so
you
can’t
claim
that
you
weren’t
there.
• Availability:
The
bank
is
always
open.
6/25/12
©
2012
Real-­‐Time
InnovaLons,
Inc.
-­‐
All
rights
reserved
33

4. Security
as
a
system
problem
• UlLmately
security
is
a
system
property
– Involves
hardware,
soware,
humans,
procedures…
• Most
directly
related:
Scope
of
1. Securing
the
data-­‐cenLrc
bus
the
RFP
2. IntegraLng
across
security
domains
Out
3. Securing
the
operaLng
system
of
Scope
4. Securing
the
hardware
&
soware
configuraLon
6/25/12
©
2012
Real-­‐Time
InnovaLons,
Inc.
-­‐
All
rights
reserved
4

5. Three
security
boundaries
Ul5mately
you
need
to
implement
the
3
of
them
• Boundary
security
• Transport-­‐Level
– Network
(layer
3)
security
– Session
(layer
4/5)
security
• Fine-­‐grained
Data-­‐Centric
Security
Scope
of
the
DDS
Security
RFP
6/25/12
©
2012
Real-­‐Time
InnovaLons,
Inc.
-­‐
All
rights
reserved
5

6. Fine-­‐Grained
Data-­‐Centric
Security
Topics
• Access
control
per
Topic
• Read
versus-­‐write
permissions
• Field-­‐specific
permissions
6/25/12
©
2012
Real-­‐Time
InnovaLons,
Inc.
-­‐
All
rights
reserved
6

7. Data
Security
Example:
UAV
Topics
Authen5ca5on
Access
Integrity
Non-­‐ Confiden5ality
Control
repudia5on
UAV
health
X
X
data
Remote
X
X
X
X
X
commands
Sensor
Data
X
X
X
X
6/25/12
©
2012
Real-­‐Time
InnovaLons,
Inc.
-­‐
All
rights
reserved
7

8. Agenda
• Background
• Requirements
• Threats
• Security
Model
• Plugins
and
SPIs
• BuilLn
Plugins
• Status
&
Conclusion
6/25/12
©
2012
Real-­‐Time
InnovaLons,
Inc.
-­‐
All
rights
reserved
8

9. RFP
Mandatory
Requirements
Proposals
shall
define
…
6.5.1
…
a
Plahorm
Independent
Security
Model
for
DDS
independent
of
the
programming
language
used…
6.5.2
…
a
collecLon
of
Plahorm
Independent
IntercepLon
Points
and
SPIs
…
6.5.3
…
built-­‐in
Plahorm
Independent
Security
Plugins
that
implement
the
Plahorm
Independent
Interfaces
6.5.4
…
plahorm
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
applicaLons
to
interoperate
securely
6/25/12
©
2012
Real-­‐Time
InnovaLons,
Inc.
-­‐
All
rights
reserved
9

10. 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
ParLcipant
to
run
in
a
plahorm
6.5.1.2
…
support
mechanisms
to
configure
and
access
the
credenLals
of
the
underlying
DDS
ParLcipants
…
6.5.1.3
…
allow
specificaLon
of
authorizaLon
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
ParLLon,
[6]
Subscribing
on
a
DDS
ParLLon
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
encrypLon
[4]
use
of
different
keys
for
data
from
different
DataWriters
6/25/12
©
2012
Real-­‐Time
InnovaLons,
Inc.
-­‐
All
rights
reserved
10

11. Mandatory
Requirements
6.5.2:
Set
of
IntercepLon
Points
and
SPIs
The
Plugin
SPIs
shall
…
6.5.2.1
…
allow
applicaLons
to
exchange
credenLals
with
a
DDS
ParLcipant
[1]
exchanging
credenLals
for
authenLcaLon
[2]
delegaLon
of
authority
for
authenLcaLon
6.5.2.2
…
allow
an
external
plugin
to
perform
all
the
authorizaLon
funcLons
[1]
full
support
of
the
authorizaLon
policies
[3]
support
delegaLon
of
authority
[4]
support
delegaLon
of
authority
separately
for
each
DDS
Topic
6.5.2.3
…
allow
an
external
plugin
to
perform
all
the
tagging
and
tag-­‐accessing
funcLons
6.5.2.4
…
allow
an
external
plugin
to
perform
all
the
encrypLon
and
decrypLon
funcLons
6.5.2.5
…
external
plugin
to
perform
all
the
digital
signing
and
verificaLon
funcLons
6/25/12
©
2012
Real-­‐Time
InnovaLons,
Inc.
-­‐
All
rights
reserved
11

12. RFP
OpLonal
Requirements
Proposals
may
define
authorizaLon
policies
that
control
…
6.6.1
…
the
content
a
DDS
ParLcipant
is
allowed
to
publish
on
a
Topic.
6.6.2
…
the
content
a
DDS
ParLcipant
is
allowed
to
subscribe
on
a
Topic..
6.6.3
…
the
QoS
Policies
a
DDS
ParLcipants
can
use
when
publishing
a
Topic
6.6.4
…
the
QoS
Policies
a
DDS
ParLcipant
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
authenLcaLon
and
authorizaLon
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
UnidirecLonal
Transports.
6/25/12
©
2012
Real-­‐Time
InnovaLons,
Inc.
-­‐
All
rights
reserved
12

13. Agenda
• Background
• Requirements
• Threats
• Security
Model
• BuilLn
Plugins
• Plugins
and
SPIs
• Status
&
Conclusion
6/25/12
©
2012
Real-­‐Time
InnovaLons,
Inc.
-­‐
All
rights
reserved
13

14. Threats
Alice:
Allowed
to
publish
topic
T
1. Unauthorized
subscripLon
Bob:
Allowed
to
subscribe
to
topic
T
Eve:
Non-­‐authorized
eavesdropper
2. Unauthorized
publicaLon
Trudy:
Intruder
3. Tampering
and
replay
Trent:
Trusted
infrastructure
service
Mallory:
Malicious
insider
4. Unauthorized
access
to
data
by
infrastructure
services
6/25/12
©
2012
Real-­‐Time
InnovaLons,
Inc.
-­‐
All
rights
reserved
14

15. Data-­‐centric/mulLcast
Insider
Threats
• Two
insider
threats
affecLng
(mulLcast)
data-­‐
centric
systems
are
of
unique
significance
1. Reader
mis-­‐behaves
as
unauthorized
writer
An
applicaLon
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
6/25/12
©
2012
Real-­‐Time
InnovaLons,
Inc.
-­‐
All
rights
reserved
15

16. Reader
mis-­‐behaves
as
unauthorized
writer
• SituaLon:
– Alice
-­‐
creates
a
Crypto
Key
per
Topic/DataWriter
– Alice
-­‐
shares
its
Key
with
all
intended
readers
as
needed
to
mulLcast
– Mallory
–
is
an
authorized
reader
so
it
has
Alice’s
key
– Mallory
–
behaves
maliciously
and
uses
Alice’s
key
to
create
fake
UDP
messages
purng
Alice’s
informaLon
(IP,
Port,
GUIDs,
etc.)
but
with
bad
data.
• ImplicaLons:
– 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
aMack
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
6/25/12
©
2012
Real-­‐Time
InnovaLons,
Inc.
-­‐
All
rights
reserved
16

17. Compromise
of
Infrastructure
Service
(2)
UDP
RTPS
SubMsg
DATA
SubMsg
DATA
Hdr
Hdr
Hdr(T1)
(T1)
Hdr(T2)
(T2)
• SituaLon:
– Alice
creates
a
Crypto
Key
to
write
topic
T
MAC
+
EncrypLon
– Alice
encrypts
the
whole
RTPS
sub-­‐message
related
to
topic
T
– Trent
is
an
infrastructure
(e.g.
relay)
that
must
store
and
forward
data
from
Alice
to
Bob
• To
operate
Trent
needs
to
see
submessage
header
informaLon:
GUIDs,
SequenceNumber,
KeyHash,
…
– Alice
shares
the
key
used
for
topic
T
with
Trent
• Trent
has
access
to
the
keys
for
all
the
data
it
relays
– Trent
is
aMacked
and
compromised
• ImplicaLons:
– Trent
aMacker
has
access
to
all
the
keys
for
all
the
topics
that
Trent
was
relaying
– Infrastructure
must
be
granted
“super
user
privileges”
to
see
many
topics
despite
fact
they
have
no
need
to
see
the
data
– Compromise
of
a
single
infrastructure
service
can
be
lead
to
catastrophic
informaLon
leakage
• Notes:
– The
problem
is
that
Trent
is
given
access
to
secrets
that
allow
it
to
see
the
data
despite
the
fact
that
it
does
not
have
a
need
to
do
so,
effecLvely
elevaLng
its
privileges
and
creaLng
a
big
vulnerability
– The
problem
can
be
solved
if
the
submessage-­‐header
informaLon
Trent
needs
is
not
encrypted
with
the
same
key
as
the
topic
eal-­‐Time
InnovaLons,
Inc.
-­‐
All
rights
reserved
6/25/12
©
2012
R
data.
17

18. The
submission
must
address
these
vulnerabiliLes
• Maintain
separaLon
between
different
classes
of
data
receivers
1. Cannot
access
any
informaLon
on
topic
T
2. Can
relay
the
submessages
on
topic
T,
but
not
the
payload
data
3. Can
access
the
payload
data
on
topic
T
but
not
relay
messages
• Examples:
– UnauthenLcated
or
Non-­‐authorized
applicaLons.
ApplicaLons
without
the
rights
to
join
a
specific
DDS
domain
– DDS
Persistence
Service
which
is
allowed
to
store
encrypted
payload.
Recording
Services,
Gateways
and
rouLng
components
• They
need
to
see
enough
(Topic,
Key,
Sequence
Numbers)
but
not
the
data
– AuthenLcated
applicaLons
authorized
to
read
data
on
a
specific
Topic
• This
can
be
enforced
by
combining
a
MAC
and
EncrypLon
and
sharing
these
keys
selecLvely
– MAC
Key
shared
with
relay
service
– MAC
&
Crypto
Key
shared
with
UDP
Hdr
RTPS
Hdr
SubMsg
Hdr(T1)
DATA
(T1)
SubMsg
Hdr(T2)
DATA
(T2)
authorized
readers
This
is
not
in
the
submission
yet
MAC
EncrypLon
6/25/12
©
2012
Real-­‐Time
InnovaLons,
Inc.
-­‐
All
rights
reserved
18

19. Agenda
• Background
• Requirements
• Threats
• Security
Model
• Plugins
and
SPIs
• BuilLn
Plugins
• Status
&
Conclusion
6/25/12
©
2012
Real-­‐Time
InnovaLons,
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
opLng
out
of
specific
features
such
as
MAC,
EncrypLon.
Digital
Signature
with
sufficient
granularity
– Limit
use
of
asymmetric
keys
to
discovery
&
session
establishment
– Support
MulLcast
• 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
mulL-­‐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:
consumpLon
of
samples
out
of
order,
best
efforts,
Lme
filters,
history
cache,
etc.
• Leverage
exisLng
technologies
– Support
plugging
in
exiLng
technologies
for
ciphers,
MAC,
PKI
• Ease
of
use
&
Flexibility
– DO
not
preclude
integraLng
with
their
exisLng
security
and
crypto
infrastructure.
6/25/12
©
2012
Real-­‐Time
InnovaLons,
Inc.
-­‐
All
rights
reserved
20

21. Audience
and
Purpose
for
this
SpecificaLon
• Audience:
– DDS
vendors/implementers,
not
the
users
of
DDS
• Purpose:
– Define
a
Security
Model
for
DDS
systems
– Define
concrete
IntercepLon
points
in
the
middleware
where
SPI
interfaces
must
be
called
– Define
concrete
SPI
Interfaces
vendors
must
invoke
at
the
IntercepLon
Points
and
the
behavior
upon
various
returns
– Define
specific
SPI
implementaLons
to
the
extent
required
for
interoperability
– NOT
guidance
to
users
implemenLng
secure
DDS
systems
– NOT
definiLon
of
security
technologies
beyond
what
is
required
to
implement
the
specificaLon
6/25/12
©
2012
Real-­‐Time
InnovaLons,
Inc.
-­‐
All
rights
reserved
21

22. Security
Model
• A
security
model
is
defined
in
terms
of:
– The
subjects
(principals)
– The
objects
being
protected
• The
operaLons
that
are
protected
on
the
objects
– Access
Control
Model
• A
way
to
map
each
subject
to
the
objects
they
can
perform
operaLons
on
and
which
are
the
allowed
operaLons
6/25/12
©
2012
Real-­‐Time
InnovaLons,
Inc.
-­‐
All
rights
reserved
22

23. Security
Model
Example:
UNIX
FileSystem
(simplified)
• Subjects:
Users,
specifically
processes
execuLng
on
behalf
of
a
specific
userid
• Protected
Objects:
Files
and
Directories
• Protected
OperaLons
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
combinaLon
of
READ,
WRITE,
EXECUTE
permissions
for
the
assigned
OWNER
and
GROUP
– Each
protected
operaLon
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
6/25/12
©
2012
Real-­‐Time
InnovaLons,
Inc.
-­‐
All
rights
reserved
23

24. DDS
Security
Model
• Subjects:
DDS
DomainParLcipant
(ParLcipant
GUID)
• Protected
Objects:
DDS
Domain
and
DDS
Topic
• Protected
Opera5ons
on
Objects
(logical
view):
– DomainParLcipant.join
– DomainParLcipant.add_read_parLLon
– DomainParLcipant.add_write_parLLon
– 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
6/25/12
©
2012
Real-­‐Time
InnovaLons,
Inc.
-­‐
All
rights
reserved
24

25. Mapping
of
DDS
API
to
protected
operaLons
DDS
API
Call
Protected
Opera5on
DomainParLcipantFactory.create_parLcipant
Discovery.match_remote_parLcipant
DomainParLcipant.join
DomainParLcipant.create_publisher
Publisher.set_qos
DomainParLcipant.add_write_parLLo
n
DomainParLcipant.create_subscriber
Subscriber.set_qos
DomainParLcipant.add_read_parLLo
n
DomainParLcipant.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
Topic.create_instance
6/25/12
Protocol.receive_instance_new
©
2012
Real-­‐Time
InnovaLons,
Inc.
-­‐
All
rights
reserved
25

26. Access
Control
Model
• Flexible
Access
Control
Model
implemented
by
the
AccessControl
SPI.
– AccessControl
plugin
implementaLons
can
customize
the
behavior.
• General
Access
Control
Model
– Each
subject
(DomainParLcipant)
is
configured
with
a
set
of
permissions
– The
AccessControl
Plugin
intercepts
each
of
the
protected
operaLons
and
decides
whether
is
is
allowed
or
denied.
• Access
Control
Model
implemented
by
builLn-­‐plugins:
– Explicit
permissions
assigned
to
DomainPaLcipants
based
on
the
Topic
name
(in
current
submission)
– Role-­‐based
access
control
– Label-­‐based
access
control
6/25/12
©
2012
Real-­‐Time
InnovaLons,
Inc.
-­‐
All
rights
reserved
26

27. Example:
Explicit
permissions
<permisions
xsi:noNamespaceSchemaLocation="omg_shared_ca_permissions.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-­‐instance">
<validity>
<!-­‐-­‐
Format
is
YYYYMMDDHH
in
GMT-­‐-­‐>
<not_before>2012060113</not_before>
<not_after>2013060113</not_after>
</validity>
<subject_name>/C=US/ST=CA/L=Sunnyvale/O=ACME
Inc./OU=CTO
Office/CN=DDS
Shapes
Demo/emailAddress=cto@acme.com</subject_name>
<allow_with_exceptions>
<domain_id>0</domain_id>
<allow>
<publish>Sq*</publish>
<subscribe>Circle</subscribe>
</allow>
<exception>
<publish>SquareControl</publish>
</exception>
</allow_with_exceptions>
</permissions>
• The
DomainParLcipant
is
allowed
to
join
domain
0
• Within
domain
0
the
DomainParLcipant
is
allowed
to
wriLng
any
Topic
with
a
name
that
matches
the
expression
“Sq*”
with
the
excepLon
of
Topic
named
“SquareControl”
• Within
domain
0
the
DomainParLcipant
is
allowed
to
read
only
the
Topic
named
“Circle”
6/25/12
©
2012
Real-­‐Time
InnovaLons,
Inc.
-­‐
All
rights
reserved
27

28. Pluggable
Security
Architecture
cerLficates
applicaLon
component
App.
App.
App.
AuthenLcaLon
Secure
DDS
Key
Plugin
middleware
Management
? Plugin
Other
Other
Other
Access
Control
DDS
Plugin
DDS
EnLLes
Cryptography
DDS
DDS
System
System
Plugin
System
AudiLng
Protocol
Data
Plugin
Engine
cache
Tagging
Plugin
Secure
Transport
(e.g.
TLS)
Kernel
? Crypto
Policies
Module
Network
(e.g.
TPM
)
Driver
Secure
Kernel
TA Encrypted
G
Data
©
2012
Real-­‐Time
InnovaLons,
Inc.
-­‐
All
rights
reserved
6/25/12
Network
28

29. Service
Plugins
(SPIs)
• Authen5ca5on:
Provides
the
mechanism
to
verify
that
idenLty
of
the
applicaLon
and
or
user
that
invokes
operaLons
on
DDS
in
order
to
join
a
domain,
publish,
subscribe,
etc.
• AccessControl:
Provides
the
means
to
enforce
policy
decisions
on
what
DDS
related
operaLons
an
authenLcated
user
can
perform.
For
example
which
domains
it
can
join,
which
Topics
it
can
publish
or
subscribe,
etc.
• Cryptography:
Implements
(or
interfaces
with
libraries
that
implement)
all
cryptographic
operaLons,
including
encrypLon,
decrypLon,
digital
signatures,
etc.
• KeyManagement:
Provides
key
distribuLon
and
access
services.
It
allows
DDS
implementaLons
to
access
the
necessary
keys
given
the
idenLty
and
access
control
policies.
• Tagging:
Tag/Label
data
samples.
• Logging:
Supports
audiLng
of
all
DDS
security-­‐relevant
events.
6/25/12
©
2012
Real-­‐Time
InnovaLons,
Inc.
-­‐
All
rights
reserved
29

30. 6/25/12
©
2012
Real-­‐Time
InnovaLons,
Inc.
-­‐
All
rights
reserved
30

31. IntercepLon
Points:
Current
logical
flow
Create
Domain
AuthenLcate
ParLcipant
DP?
Create
Endpoints
Discover
remote
DP
Discover
remote
Endpoints
Send/
Receive
data
6/25/12
©
2012
Real-­‐Time
InnovaLons,
Inc.
-­‐
All
rights
reserved
31

32. IntercepLon
Points
inserted
into
the
logical
flow
Create
Domain
Domain
AuthenLcate
No
ParLcipant
AuthenLcate
DP?
ParLcipant
Create
Fails
Yes
DP?
Create
No
Endpoint
Access
OK?
Endpoints
Create
Fails
Discover
AuthenLcate
No
Ignore
remote
DP
Remote
DP?
Remote
DP
Yes
Discover
Ignore
remote
Access
OK?
remote
Endpoints
endpoint
Send/ Message
Receive
data
security
6/25/12
©
2012
Real-­‐Time
InnovaLons,
Inc.
-­‐
All
rights
reserved
32

33. AuthenLcaLon
-­‐
Local
Create
Load
Domain
Domain
IdenLty
AuthenLcate
No
ParLcipant
AuthenLcate
DP?
ParLcipant
CerLficates
Create
Fails
DP?
Yes
For
PKI,
token
is
PKI
Get
Auth
cerLficate
Token
6/25/12
©
2012
Real-­‐Time
InnovaLons,
Inc.
-­‐
All
rights
reserved
33

34. DDS
Security
Flow:
Access
Control
Load
No
Create
Endpoint
Security
Access
OK?
Endpoints
Create
Fails
Policies
Yes
Data
Writer?
Yes
Get
Keys
If
desired,
add
tag
6/25/12
©
2012
Real-­‐Time
InnovaLons,
Inc.
-­‐
All
rights
reserved
34

35. IntercepLon
Points
–
Remote
AuthenLcaLon
and
Access
Control
Discover
Receive
AuthenLcate
No
Ignore
remote
DP
IdenLty
Token
Remote
DP?
Remote
DP
Yes
Discover
No
Ignore
Receive
remote
Access
OK?
remote
Permissions
Token
Endpoints
endpoint
Yes
Does
the
Matched
DW?
remote
Data
Writer
Yes
match
a
Get
Keys
local
Data
Reader
Get
remote
DW
tag
6/25/12
©
2012
Real-­‐Time
InnovaLons,
Inc.
-­‐
All
rights
reserved
35

36. DDS
Security
Flow:
Send
Data
Access
Yes
Write
Marshall
Encrypt?
CriptoKeys
+
No
Encrypt
ClearText
CipherText
CipherText
Header
has
KeyId
Marshal
Access
SampleInfo
DigitalSig?
PrivateKey
+
(KeyHash,
Yes
Sign
SN,
GUID)
TBD:
DSig
Append
Digital
Signature
Header
Yes
precedes
Access
ciphertext?
Send
RTPS
Assemble
MACKeys
+
Message
to
MAC?
Submessages
Yes
compute
MAC
DesLnaLon
TBD:
Append
MAC
MAC
as
separate
submessage?
Send
to
UDP
First
or
last?
6/25/12
©
2012
Real-­‐Time
InnovaLons,
Inc.
-­‐
All
rights
reserved
In
RTPS
Header?
36

37. Agenda
• Background
• Requirements
• Threats
• Security
Model
• Plugins
and
SPIs
• BuilLn
Plugins
• Status
&
Conclusion
6/25/12
©
2012
Real-­‐Time
InnovaLons,
Inc.
-­‐
All
rights
reserved
37

38. 6/25/12
©
2012
Real-­‐Time
InnovaLons,
Inc.
-­‐
All
rights
reserved
38

39. AuthenLcaLon
Plug-­‐in
• Goal:
authorize
DDS
enLLes.
Only
an
authorized
DDS
applicaLon
can
send
or
receive
data
in
that
domain
• The
unique
idenLty
of
a
Domain
ParLcipants
is
locally
authenLcated
• When
a
remote
Domain
ParLcipant
is
discovered,
its
idenLty
must
be
validated
AuthenLcaLon
Service
DDS
DDS
DDS
App
App
6/25/12
©
2012
Real-­‐Time
InnovaLons,
Inc.
-­‐
All
rights
reserved
39

40. AuthenLcaLon
SPI
• IdenLtyCredenLal:
configures
the
plugin
with
the
informaLon
it
needs
to
idenLfy
and
authenLcate
the
local
parLcipant
• IdenLtyHandle:
used
refer
locally
to
an
authenLcated
parLcipant.
• IdenLtyToken:
characterizes
the
idenLty
informaLon
of
a
DomainParLcipant,
which
is
propagated
via
discovery
• AuthenLcaLonListener
noLfy
of
status
changes:
E.g.
when
a
cerLficate
has
expired
and
revokes
the
idenLty
6/25/12
©
2012
Real-­‐Time
InnovaLons,
Inc.
-­‐
All
rights
reserved
40

41. AuthenLcaLon
OperaLons
Opera5on
Descrip5on
validate_local Validates the identity of the local DomainParticipant based on
_identity credentials, biometrics or whatever the plug-in requires.
validate_remot Validates the identity of the remote DomainParticipant, based on
e_identity an IdentityToken representation. This operation may return an
Identity Challenge that must be sent and replied to by the remote
participant.
get_identity_t Returns an IdentityToken that can be sent over the network to
oken identify the DomainParticipant.
challenge_iden Asks the local AuthenticationPlugin to respond to an identity
tity challenge. The operation is invoked if a remote Participant sends a
message requesting an identity challenge
validate_ident Provides the AuthenticationPlugin with the response to an
ity_challenge identity challenge that was previously requested as a result of a call to
validate_remote_identity
set_listener Sets the listener necessary for determining identity status changes to
the AuthenticationListener objects received as an argument.
6/25/12
©
2012
Real-­‐Time
InnovaLons,
Inc.
-­‐
All
rights
reserved
41

42. Access
Control
SPI
Access
Control
SPI
• PermissionsCredenLal:
provided/configured
on
the
DomainParLcipant
to
prove
its
permissions
• PermissionsHandle:
internal
handle
to
refer
to
the
permissions
of
an
idenLfied
DomainParLcipant
• PermissionsToken:
characterizes
the
DomainParLcipant
permissions,
which
is
propagated
via
discovery
• AccessControlListener
noLfy
of
status
changes.
E.g.
a
change
in
permissions.
6/25/12
©
2012
Real-­‐Time
InnovaLons,
Inc.
-­‐
All
rights
reserved
42

43. Access
Control
OperaLons
Opera5on
Descrip5on
validate_loc Validates the permissions of the local DomainParticipant. The
al_permissio permissions could be based on a PermissionsCredential
ns()
presented to the plugin. The operation returns a
PermissionsHandle object, if successful.
validate_rem Validates the permissions of the remote DomainParticipant,
ote_permissi propagated as a PermissionsToken. The operation returns a
ons()
PermissionsHandle, if successful.
check_create Enforces the permissions of the local DomainParticipant.
_particpant Ensurng it is allowed to join the specified domain_id with the
()
specified Participant QoS.
check_create Enforces permissions to ensure the local DomainParticipant is
_datawriter allowed to write the specified Topic with the specified QoS.
()
check_create Enforces permissions to ensure the local DomainParticipant is
_datareader allowed to read the specified Topic with the specified QoS.
()
check_create Enforces permissions to ensure the local DomainParticipant is
_topic()
6/25/12
allowed©
2012
Real-­‐Time
Ithe specified Topic with the specified QoS.
to create nnovaLons,
Inc.
-­‐
All
rights
reserved
43

44. Access
Control
OperaLons
(II)
Opera5on
Descrip5on
check_local_da In case the access control requires a finer granularity at the instance
tawriter_regis level, this operation enforces the permissions of the local DataWriter
ter_instance()
to create a particular instance.
check_local_da In case the access control requires a finer granularity at the instance
tawriter_dispo level, this operation enforces the permissions of the local DataWriter
se_instance()
to delete a particular instance.
check_remote_p Enforces the permissions on the remote DomainParticipant,
articipant()
ensuring it has permissions to join the domain with the specified
domain_id and QoS.
check_remote_d Enforces the permissions on the remote DomainParticipant
atawriter()
ensuring is has permissions to write data on the specified Topic name
and type (extracted from the publication_data) and with the discovered
QoS.
check_remote_d Enforces the permissions on the remote DomainParticipant
atareader()
ensuring is has permissions to read data on the specified Topic name and
type (extracted from the publication_data) and with the discovered QoS.
check_remote_t Enforces permissions to ensure the remote DomainParticipant is
opic()
allowed to create the specified Topic with the specified QoS.
6/25/12
©
2012
Real-­‐Time
InnovaLons,
Inc.
-­‐
All
rights
reserved
44

45. Access
Control
OperaLons
(III)
Opera5on
Descrip5on
check_remote In case the access control requires a finer granularity at the instance
_datawriter_ level, this operation checks the permissions of the remote
register_ins DataWriter allow it to create a particular instance.
tance()
check_remote In case the access control requires a finer granularity at the instance
_datawriter_ level, this operation checks the permissions of the remote
dispose_inst DataWriter allow it to delete a particular instance.
ance()
get_permissi Returns the PermissionsToken that can be used to represent on
ons_token() the network the Participant’s permissions, which are identified by the
specified PermissionsHandle.
set_listener Sets the listener for the AccessControl object.
()
6/25/12
©
2012
Real-­‐Time
InnovaLons,
Inc.
-­‐
All
rights
reserved
45

46. Access
Control
Listener
OperaLons
Opera5on
Descrip5on
on_revoke_pe DomainParticipants’ Permissions can be revoked/changed.
rmissions()
This listener provides a callback for permission revocation/changes.
6/25/12
©
2012
Real-­‐Time
InnovaLons,
Inc.
-­‐
All
rights
reserved
46

47. Cryptographic
Plug-­‐in
Goal:
Provide
cryptographic
capabiliLes
for
DDS
data
samples
• Customer
security
policy
dictates
which
per
sample
cryptography
is
required
– MAC
for
message
authenLcaLon
and
integrity
– Digest
for
integrity
or
as
part
of
compuLng
a
Digital
Signature
– Digital
signature
– EncrypLon
• Highlights:
– Designed
to
support
different
encrypLon
methods
• PKI,
Symmetric
keys,
IdenLty
based
encrypLon
• Counter-­‐mode
encrypLon
(for
non
stream-­‐oriented
sessions)
– General
and
extensible
API
• can
support
different
implementaLons
of
the
crypto,
including
interfacing
with
device
drives
and
hardware
– Designed
for
performance
• Separate
prepare
&
execute
cycles
• Supports
performing
cryptographic
operaLons
on
non-­‐conLguous
buffers
6/25/12
©
2012
Real-­‐Time
InnovaLons,
Inc.
-­‐
All
rights
reserved
47

48. Cryptographic
SPI
Provides
support
for:
• Encrypt/Decrypt
• MessageAuthenLcaLon
• Digital
signature
&
verificaLon
6/25/12
©
2012
Real-­‐Time
InnovaLons,
Inc.
-­‐
All
rights
reserved
48

49. Main
Types
• Handle
(CryptoHandle,
CryptoSession
MACHandle,
DSigHandle):
– Provide
internal
handle
to
“prepared”
key
material
inside
the
Plugin
for
efficient
operaLons
• Token
(CryptoToken,
MACToken,
DSigToken):
– Encode
all
the
informaLon
needed
to
iniLalize
the
algorithms.
This
informaLon
created
at
the
request
of
applicaLon
generaLng
the
message
and
made
available
to
the
authorized
recipients
with
the
help
of
the
MeyManager
plugin
• State
(CryptoState,
CryptoState
MACState,
DSigState):
– Internal
handle
to
algorithmic
state
to
support
operaLons
on
non-­‐conLguous
buffers
6/25/12
©
2012
Real-­‐Time
InnovaLons,
Inc.
-­‐
All
rights
reserved
49

50. Cryptographic
OperaLons
Opera5on
Descrip5on
decrypt() Given a cryptographic token and encrypted data, this function
generates decrypted output. This will be used by a DataReader to
decrypt encrypted data it received on the wire.
encrypt() Given an encryption token and data, this function generates encrypted
output. This will be used by a DataWriter to encrypt data prior to
sending it out on the wire.
get_cypher_in Returns the corresponding to a CryptographicToken.
fo_from_token
()
get_key_from_ Returns the CryptographicKey corresponding to a
token() CryptographicToken.
get_local_enc Returns the local cryptographic token, CryptographicToken,
ryption_token given the local key.
()
get_remote_en Returns the remote CryptographicTokengiven the cypher info
cryption_toke for it. In order to achieve interoperability, the cipher info needs to be
n()
6/25/12
known.
2012
Real-­‐Time
InnovaLons,
Inc.
-­‐
All
rights
reserved
©
50

51. Cryptographic
OperaLons
(II)
Opera5on
Descrip5on
set_key_for_t Associates a cryptographic key to a cryptographic token.
oken()
sign() Digitally signs the data and attaches the signatures on the wire.
verify() Verifies the signature of the data.
6/25/12
©
2012
Real-­‐Time
InnovaLons,
Inc.
-­‐
All
rights
reserved
51

52. Key
Management
Plug-­‐In
Goal:
enable
efficient
method
for
management
of
cryptographic
keys
• Each
Data
Writer
needs
a
key
for
– EncrypLon
– Message
AuthenLcaLon
Codes
– Digital
Signature
(oen
the
PKI
cert
private
key)
• A
Matched
Data
Reader
needs
matching
key
• The
KeyManagent
plugin
is
responsible
for
propagaLng
the
different
Keys
to
the
authorized
readers
6/25/12
©
2012
Real-­‐Time
InnovaLons,
Inc.
-­‐
All
rights
reserved
52

53. Key
Management
SPI
• KeyManagerTokenHandle:
local
opaque
reference
to
a
previously
stored
token
• TokenAccessTicket:
Opaque
Lcket
granLng
access
to
a
key
to
an
idenLfied
DomainParLcipant
6/25/12
©
2012
Real-­‐Time
InnovaLons,
Inc.
-­‐
All
rights
reserved
53

54. Highlights
• Generic
API
supports
custom
and
well
as
commercial
Key
Managers
• Integrates
well
with
exisLng
DDS
mechanisms
• Model:
– The
KeyManager
stores
keys
(KeyTokens)
at
the
request
of
the
sender
– The
sender
requests
a
Ticket
to
be
generated
for
to
granLng
access
to
a
KeyToken
to
a
specific
subject
Iden5ty
(DomainParLcipant).
– The
sender
can
share
the
Ticket
with
the
intended
recipient.
This
message
does
not
need
to
be
protected
– Upon
presentaLon
of
the
Ticket
by
the
intended
Iden5ty
the
KeyManager
gives
it
the
KeyToken.
6/25/12
©
2012
Real-­‐Time
InnovaLons,
Inc.
-­‐
All
rights
reserved
54

55. Key
Management
OperaLons
Opera5on
Descrip5on
store_token() Stores a Token a cryptographic Token in the Manger retuning a
KeyManagerTokenHandle that can be used to locally refer to
the stored Token.
get_token_acce Returns a Ticket for a previously stored Token to be used by a
ss_ticket()
specified subject Identitity. The Ticket grants access to the
Token only to the identity that was specified so it maybe shared
in cleartext with the intended recipient.
lookup_token_h Looks up a Token given a Ticket. The KeyManager will
andle() ensure that the identity of the requester is the one for whom the
Ticket was intended. Returns a KeyManagerTokenHandle that
can be used to locally refer to the stored Token.
get_token() Retrieves a previously stored Token given its local
KeyManagerTokenHandle.
6/25/12
©
2012
Real-­‐Time
InnovaLons,
Inc.
-­‐
All
rights
reserved
55

56. Key
Management
Listener
OperaLons
Opera5on
Descrip5on
identity_chall Used
to
enforce
that
only
the
intended
recipient
idenLty
can
get
enge() access
to
a
stored
Token
6/25/12
©
2012
Real-­‐Time
InnovaLons,
Inc.
-­‐
All
rights
reserved
56

57. Logging
(AudiLng)
Plug-­‐in
• Goal:
Provide
mechanism
to
log
either
locally
or
centralized
all
security
events
for
audiLng
DDS
App
Secure
Audit
Plug-­‐ DB
ins
6/25/12
©
2012
Real-­‐Time
InnovaLons,
Inc.
-­‐
All
rights
reserved
57

58. Data
Tagging
• Tag
is
added
to
a
Data
Writer
• Tag
is
propagated
over
discovery
• The
Data
Reader
stores
the
tag
of
each
Data
Writer
• When
the
Data
Reader
applicaLon
gets
a
data
sample,
it
can
retrieve
the
tag
associated
with
that
sample
from
the
middleware
6/25/12
©
2012
Real-­‐Time
InnovaLons,
Inc.
-­‐
All
rights
reserved
58

59. Agenda
• Background
• Requirements
• Threats
• Security
Model
• Plugins
and
SPIs
• Buil5n
Plugins
• Status
&
Conclusion
6/25/12
©
2012
Real-­‐Time
InnovaLons,
Inc.
-­‐
All
rights
reserved
59

60. BuilLn
Plugins
SPI
Buil5n
Plungin
Notes
AuthenLcaLon
SharedCA_AuthenLcaLonPlugin
Uses
PKI
with
a
pre-­‐configured
shared
CerLficate
Authority
AccessControl
SharedCA_PermissionsPlugin
Permissions
document
signed
by
shared
CerLficate
Authority
Cryptography
Crypto-­‐AES-­‐CTR-­‐HMAC
AES128
and
AES256
for
encrypLon
(in
counter
mode)
SHA1
and
SHA256
for
digest
HMAC-­‐SHA1
and
HMAC-­‐256
for
MAC
PKI
digital
signature
KeyManagement
PKI_Protected_DDS_KeyDistribuLon
Use
authorized
reader
PK
to
protect
KeyDistribuLon
Not
described
in
submission
DataTagging
Discovered_EndpointTags
Send
Tags
via
Endpoint
Discovery
Logging
DedicatedDDS_LogTopic
6/25/12
©
2012
Real-­‐Time
InnovaLons,
Inc.
-­‐
All
rights
reserved
60

61. SharedCA_AuthenLcaLonPlugin
(1)
• 2048-­‐bit
RSA
x.509
CerLficates
in
combinaLon
with
a
configurable
shared
CerLficate
Authority
(CA)
• Each
ParLcipant
is
configured
with
– Shared
CA
described
by
self-­‐signed
cerLficate
(e.g.
PEM,
DER
formats)
– The
ParLcipant
Private
Key
(e.g.
PEM,
DER)
– The
ParLcipant
signed
cerLficate
from
the
CA
binding
the
• DisLnguished
Name
for
the
parLcipant
• ParLcipant
Public
Key
– AuthenLcaLonToken
is
signed
cerLficate
in
PEM
format
• All
implementable
with
openssl
toolkit
6/25/12
©
2012
Real-­‐Time
InnovaLons,
Inc.
-­‐
All
rights
reserved
61

62. SharedCA_AuthenLcaLonPlugin
(2)
• Local
idenLty
is
verified
by
presence
of
private
key
that
corresponds
with
PK
in
cerLficate
• Remote
IdenLty
verified
via
challenge.
– Plugin
create
a
NONCE
and
sends
as
a
challenge
to
remote
parLcipant
– Remote
ParLcipant
Pluging
must
encrypt
NONCE
with
private
key
– Plugin
checks
response
against
the
PublicKey
in
the
cerLficate
– These
messages
flow
over
the
exisLng
ParLcipantMessage
builLn
Topic
6/25/12
©
2012
Real-­‐Time
InnovaLons,
Inc.
-­‐
All
rights
reserved
62

63. Example
self-­‐signed
cerLficate
for
CA
CerLficate:
Data:
Version:
1
(0x0)
Serial
Number:
9a:49:85:d1:3e:b9:85:04
Signature
Algorithm:
sha1WithRSAEncrypLon
Issuer:
C=US,
ST=MA,
L=Boston,
O=OMG,
OU=DDS
SIG,
CN=DDS
Security
Specifica5on/emailAddress=dds@omg.org
Validity
Not
Before:
May
31
00:11:29
2012
GMT
Not
Aer
:
May
31
00:11:29
2013
GMT
Subject:
C=US,
ST=MA,
L=Boston,
O=OMG,
OU=DDS
SIG,
CN=DDS
Security
Specifica5on/emailAddress=dds@omg.org
Subject
Public
Key
Info:
Public
Key
Algorithm:
rsaEncrypLon
RSA
Public
Key:
(2048
bit)
Modulus
(2048
bit):
00:c5:8e:2b:3d:d1:97:a6:ce:8b:1f:91:0b:5b:1c:
5a:a0:60:42:b4:b8:89:35:40:de:9c:a0:51:12:25:
63:51:67:4c:26:8a:48:00:d0:98:0a:a0:2b:9b:ea:
50:9f:12:1e:9c:27:92:76:c4:38:4d:94:a1:38:37:
86:46:45:~:8e:b1:a4:b5:76:35:1a:6c:17:5c:05:
25:66:b7:f4:58:e4:6c:ad:a3:17:ef:fe:3b:ec:fa:
7b:60:e0:7f:9e:f3:a3:0b:a0:91:5f:ef:32:c7:d7:
57:37:8c:49:58:9c:be:fd:2b:b8:4c:3a:44:a0:c3:
6b:63:a0:ae:97:1d:bf:b0:af:09:3f:fc:ca:4d:1a:
8e:c4:1c:fd:db:2c:a8:20:e7:2d:61:8d:38:c3:46:
d5:94:0c:78:aa:17:e4:32:08:49:ed:8a:fa:b0:ce:
fc:bd:e4:8f:5a:53:73:b4:1c:a7:68:b4:39:b3:b3:
ff:~:80:ff:f3:87:ba:cc:48:5a:ed:b7:04:81:d4:
b5:89:48:ba:b5:3c:c3:9a:cd:6f:5a:94:ea:06:e5:
fa:b6:ee:ce:04:29:2a:ea:1d:54:2f:83:ef:c9:~:
5e:9e:ca:a7:74:c9:53:30:b7:fe:7d:e5:2b:4b:b1:
3a:81:9d:07:47:eb:45:02:95:79:48:d2:77:23:0b:
39:49
Exponent:
65537
(0x10001)
Signature
Algorithm:
sha1WithRSAEncrypLon
42:96:cf:ee:95:c9:62:7c:6c:33:c9:cd:05:80:3c:99:89:32:
54:fa:5c:3f:83:0c:87:91:f3:95:23:10:61:7c:ae:18:43:4f:
9e:36:60:dd:bf:60:d0:2d:82:3d:56:dc:f1:cd:25:37:3d:c3:
bd:c7:74:73:f1:fe:e1:0b:86:56:fc:82:83:71:45:e5:84:6f:
bb:45:f9:a0:47:11:03:4a:13:7c:ed:15:24:9d:7b:5a:06:13:
2c:15:ae:1e:98:c5:5e:cc:22:a9:2f:77:ca:2f:a7:~:82:b2:
09:38:9d:dd:95:6e:65:e3:2b:10:e4:63:fe:30:04:b4:62:10:
66:97:a3:ea:3d:ce:ef:83:e2:05:03:f1:7a:78:f3:6c:6c:75:
72:f7:55:b0:3a:58:a5:4d:e7:f9:30:f8:3b:97:36:ad:fc:bc:
93:90:de:b7:e8:bd:2d:25:5d:20:13:0b:5d:c7:64:ff:65:43:
1b:3d:d8:5d:9f:ee:03:b7:81:a6:a9:39:ea:3a:cd:00:e2:48:
de:2b:df:cb:76:74:45:ad:8c:00:ce:ec:06:55:5e:93:7c:68:
3b:2f:48:e1:72:ed:1d:6e:45:33:12:b2:97:71:74:07:5d:4d:
bd:0f:ff:c5:10:d9:fa:22:63:ab:9e:a0:44:33:c4:0f:e9:09:
2012
Real-­‐Time
InnovaLons,
Inc.
-­‐
All
rights
reserved
6/25/12
©
63
5d:b6:d8:05

64. Example
CA
signed
ParLcipant
CerLficate
CerLficate:
Data:
Version:
1
(0x0)
Serial
Number:
2
(0x2)
Signature
Algorithm:
sha1WithRSAEncrypLon
Issuer:
C=US,
ST=MA,
L=Boston,
O=OMG,
OU=DDS
SIG,
CN=DDS
Security
Specifica5on/emailAddress=dds@omg.org
Validity
Not
Before:
May
31
00:43:09
2012
GMT
Not
Aer
:
May
31
00:43:09
2013
GMT
Subject:
C=US,
ST=CA,
L=Sunnyvale,
O=ACME
Inc.,
OU=CTO
Office,
CN=DDS
Shapes
Demo/emailAddress=cto@acme.com
Subject
Public
Key
Info:
Public
Key
Algorithm:
rsaEncrypLon
RSA
Public
Key:
(2048
bit)
Modulus
(2048
bit):
00:eb:4e:24:f0:99:cd:e7:a6:2b:a8:85:af:c9:44:
b1:6e:fd:b1:bd:f5:9e:fa:af:a3:02:57:e5:ca:de:
18:d6:8f:cd:67:62:c7:61:74:41:14:b1:f3:cc:20:
9e:31:3c:65:c0:a8:67:c7:3c:b1:2e:50:62:d5:96:
9b:61:5c:d0:d1:a2:65:e6:27:51:3d:33:02:de:c0:
6a:79:f5:a9:6b:ff:cc:17:65:a2:8b:da:bf:7b:c2:
ca:15:5a:5b:71:d6:84:0f:48:9a:b4:a0:35:22:55:
8e:bb:de:67:09:de:41:73:ea:f9:0c:8e:2c:5f:d7:
06:5f:d3:3d:61:59:f9:c0:87:c4:b3:41:92:2f:7e:
68:8d:ba:1d:45:a4:1c:5e:4c:28:11:1f:bb:a1:95:
84:29:ee:dc:10:fe:fc:65:~:6d:e9:66:1a:5d:93:
44:51:fc:49:0c:a4:ef:51:b4:1d:4b:cd:38:19:88:
da:74:60:21:88:7e:8b:12:92:ec:51:f3:c2:8a:60:
bb:9e:b4:c5:63:dd:3d:12:1a:8c:40:ee:6a:de:1c:
90:4c:32:c2:c5:c3:9a:57:cc:24:~:c9:8b:08:1d:
de:5d:06:45:81:6d:21:c3:2e:44:9f:c7:da:19:9b:
cc:34:21:7a:e4:cb:13:0a:d2:87:87:dc:79:c1:8a:
30:ed
Exponent:
65537
(0x10001)
Signature
Algorithm:
sha1WithRSAEncrypLon
7e:45:b8:01:29:ea:25:6a:02:e4:6e:e4:15:10:69:a7:68:b3:
d5:76:46:35:b7:74:09:c8:b5:6e:bf:b4:91:f1:79:03:17:d5:
d7:94:91:12:19:b6:49:28:cc:3f:12:9c:18:bc:5a:af:e7:ea:
4b:d4:3d:40:de:78:9c:e3:17:3c:c7:22:e5:ae:14:b9:67:6a:
81:8e:04:05:98:86:f5:bc:99:a5:e6:2b:b6:46:34:ae:b1:df:
b6:65:d2:1b:43:ff:6b:d4:de:10:48:16:42:aa:c3:5f:fe:e2:
9f:72:0c:8f:54:c1:c6:e6:95:76:d3:df:be:5d:42:2f:d6:7a:
0a:e1:31:ee:19:55:75:cc:18:54:1f:b2:c1:df:6b:65:70:de:
3e:31:ec:9a:70:5e:9c:44:ba:ce:6c:1e:a1:c4:b3:c1:79:cf:
f6:2a:e5:b5:0a:40:e3:32:a9:b4:f5:68:fa:15:70:77:5b:43:
c2:67:6d:a4:07:f8:89:1c:4c:b2:68:a4:53:56:1f:91:66:78:
62:29:1b:19:5a:19:90:92:8a:1c:f4:d5:59:29:15:83:55:94:
e7:e8:ed:53:21:f9:2c:30:11:21:94:44:bd:73:de:60:f1:45:
63:e9:1c:22:3b:66:f5:9e:c7:a6:d1:d1:bb:5b:26:d0:34:de:
c8:a2:a9:83
6/25/12
©
2012
Real-­‐Time
InnovaLons,
Inc.
-­‐
All
rights
reserved
64

65. SharedCA_PermissionsPlugin
(1)
• XML
permissions
document
signed
by
shared
CA
– Can
be
same
CA
as
for
AuthenLcaLon
– Can
be
new
configured
CA
via
self-­‐signed
X.509
cert
– XML
document
specifies
the
ParLcipant’s
DisLnguished
Name
from
AuthenLcaLon
cerLficate
– PermissionsToken
is
the
PKCS7
signature
of
the
XML
document,
signed
by
the
permissions
CA.
This
is
a
widely
supported
IETF
standard
– PermissionsToken
sent
via
regular
DDS
Discovery
as
addiLonal
EnLtyQoS
• Permissions
document
uses
allow/deny
syntax
to
specify
which
Topics
the
ParLcipant
can
publish
and
subscribe
– XML
Syntax
could
be
extended
to
permissions
for
instances
creaLon
and
deleLon
– XML
Syntax
could
be
extended
to
specify
allowed
QoS
such
as
ParLLons
– These
are
currently
not
specifiable
in
the
plugin
• Permissions
document
also
allows
user-­‐extensibility
via
tag/value
pairs
which
are
also
signed.
6/25/12
©
2012
Real-­‐Time
InnovaLons,
Inc.
-­‐
All
rights
reserved
65