Third revised submission to the OMG Data Distribution Service Security Specification.

1. Your
systems.
Working
as
one.
DDS
SECURITY
3rd
Revised
Submission
dds/2012-­‐12-­‐12
Doc
num:
mars/2012-­‐12-­‐12
SubmiLers:
Presenter:
Real-­‐Time
InnovaKons,
Inc.
Gerardo
Pardo-­‐Castellote,
Ph.D.
PrismTech
Corp.
CTO,
Real-­‐Time
InnovaKons,
Inc.
©
2012
Real-­‐Time
InnovaKons,
Inc.
-­‐
All
rights
reserved

2. Agenda
• Status
recap
• Summary
of
submission
• What
has
changed?
• Some
details
• Status
&
Conclusion
2/14/13
©
2012
Real-­‐Time
InnovaKons,
Inc.
-­‐
All
rights
reserved
2

3. Status
recap
• Started
with
two
separate
submissions
by
RTI
and
PrismTech
– RTI
submission
focused
on
the
mandatory
requirements
for
an
SPI
Architecture
and
built-­‐in
SPIs
– PrismTech
focused
on
the
use
of
exisKng
technologies
(MIKEY
/
SRTP)
to
supports
the
needs
of
secure
DDS
• RTI
took
AI
to
show
how
MIKEY
and
SRTP
could
be
supported
as
specific
SPIs
on
the
proposed
SPI
architecture
–
potenKally
could
lead
to
joint
submission
– Basic
KeyExchange
and
EncrypKon
mechanisms
in
PT
submission
are
now
possible
in
the
built-­‐in
plugins
– PrismTech
has
joined
the
submission
2/14/13
©
2012
Real-­‐Time
InnovaKons,
Inc.
-­‐
All
rights
reserved
3

4. Agenda
• Status
recap
• Summary
of
submission
• What
has
changed?
• How
the
submission
allows
a
specializaKon
to
use
MIKEY
and
SRTP
• Status
&
Conclusion
2/14/13
©
2012
Real-­‐Time
InnovaKons,
Inc.
-­‐
All
rights
reserved
4

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

6. Three
security
boundaries
Ul:mately
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
2/14/13
©
2012
Real-­‐Time
InnovaKons,
Inc.
-­‐
All
rights
reserved
6

7. Fine-­‐Grained
Data-­‐Centric
Security
Topics
• Access
control
per
Topic
• Read
versus-­‐write
permissions
• Field-­‐specific
permissions
2/14/13
©
2012
Real-­‐Time
InnovaKons,
Inc.
-­‐
All
rights
reserved
7

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

9. Data-­‐centric/mulKcast
Insider
Threats
• Two
insider
threats
affecKng
(mulKcast)
data-­‐
centric
systems
are
of
unique
significance
1. Reader
mis-­‐behaves
as
unauthorized
writer
An
applicaKon
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
2/14/13
©
2012
Real-­‐Time
InnovaKons,
Inc.
-­‐
All
rights
reserved
9

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

11. RFP
Mandatory
Requirements
Proposals
shall
define
…
6.5.1
…
a
Plaoorm
Independent
Security
Model
for
DDS
independent
of
the
programming
language
used…
6.5.2
…
a
collecKon
of
Plaoorm
Independent
IntercepKon
Points
and
SPIs
…
6.5.3
…
built-­‐in
Plaoorm
Independent
Security
Plugins
that
implement
the
Plaoorm
Independent
Interfaces
6.5.4
…
plaoorm
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
applicaKons
to
interoperate
securely
2/14/13
©
2012
Real-­‐Time
InnovaKons,
Inc.
-­‐
All
rights
reserved
11

12. 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
ParKcipant
to
run
in
a
plaoorm
6.5.1.2
…
support
mechanisms
to
configure
and
access
the
credenKals
of
the
underlying
DDS
ParKcipants
…
6.5.1.3
…
allow
specificaKon
of
authorizaKon
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
ParKKon,
[6]
Subscribing
on
a
DDS
ParKKon
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
encrypKon
[4]
use
of
different
keys
for
data
from
different
DataWriters
2/14/13
©
2012
Real-­‐Time
InnovaKons,
Inc.
-­‐
All
rights
reserved
12

13. Mandatory
Requirements
6.5.2:
Set
of
IntercepKon
Points
and
SPIs
The
Plugin
SPIs
shall
…
6.5.2.1
…
allow
applicaKons
to
exchange
credenKals
with
a
DDS
ParKcipant
[1]
exchanging
credenKals
for
authenKcaKon
[2]
delegaKon
of
authority
for
authenKcaKon
6.5.2.2
…
allow
an
external
plugin
to
perform
all
the
authorizaKon
funcKons
[1]
full
support
of
the
authorizaKon
policies
[3]
support
delegaKon
of
authority
[4]
support
delegaKon
of
authority
separately
for
each
DDS
Topic
6.5.2.3
…
allow
an
external
plugin
to
perform
all
the
tagging
and
tag-­‐accessing
funcKons
6.5.2.4
…
allow
an
external
plugin
to
perform
all
the
encrypKon
and
decrypKon
funcKons
6.5.2.5
…
external
plugin
to
perform
all
the
digital
signing
and
verificaKon
funcKons
2/14/13
©
2012
Real-­‐Time
InnovaKons,
Inc.
-­‐
All
rights
reserved
13

14. RFP
OpKonal
Requirements
Proposals
may
define
authorizaKon
policies
that
control
…
6.6.1
…
the
content
a
DDS
ParKcipant
is
allowed
to
publish
on
a
Topic.
6.6.2
…
the
content
a
DDS
ParKcipant
is
allowed
to
subscribe
on
a
Topic..
6.6.3
…
the
QoS
Policies
a
DDS
ParKcipants
can
use
when
publishing
a
Topic
6.6.4
…
the
QoS
Policies
a
DDS
ParKcipant
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
authenKcaKon
and
authorizaKon
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
UnidirecKonal
Transports.
2/14/13
©
2012
Real-­‐Time
InnovaKons,
Inc.
-­‐
All
rights
reserved
14

15. Submission
Guiding
Principles
• Performance
&
Scalability
– Do
not
impact
parts
of
the
system
that
do
not
have
security
needs
– Allow
opKng
out
of
specific
features
such
as
MAC,
EncrypKon.
Digital
Signature
with
sufficient
granularity
– Limit
use
of
asymmetric
keys
to
discovery
&
session
establishment
– Support
MulKcast
• 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
mulK-­‐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:
consumpKon
of
samples
out
of
order,
best
efforts,
Kme
filters,
history
cache,
etc.
• Leverage
exis:ng
technologies
– Support
plugging
in
exiKng
technologies
for
ciphers,
MAC,
PKI
• Ease
of
use
&
Flexibility
– DO
not
preclude
integraKng
with
their
exisKng
security
and
crypto
infrastructure.
2/14/13
©
2012
Real-­‐Time
InnovaKons,
Inc.
-­‐
All
rights
reserved
15

16. Audience
and
Purpose
for
this
SpecificaKon
• Audience:
– DDS
vendors/implementers,
not
the
users
of
DDS
• Purpose:
– Define
a
Security
Model
for
DDS
systems
– Define
concrete
IntercepKon
points
in
the
middleware
where
SPI
interfaces
must
be
called
– Define
concrete
SPI
Interfaces
vendors
must
invoke
at
the
IntercepKon
Points
and
the
behavior
upon
various
returns
– Define
specific
SPI
implementaKons
to
the
extent
required
for
interoperability
– NOT
guidance
to
users
implemenKng
secure
DDS
systems
– NOT
definiKon
of
security
technologies
beyond
what
is
required
to
implement
the
specificaKon
2/14/13
©
2012
Real-­‐Time
InnovaKons,
Inc.
-­‐
All
rights
reserved
16

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

18. Security
Model
Example:
UNIX
FileSystem
(simplified)
• Subjects:
Users,
specifically
processes
execuKng
on
behalf
of
a
specific
userid
• Protected
Objects:
Files
and
Directories
• Protected
OperaKons
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
combinaKon
of
READ,
WRITE,
EXECUTE
permissions
for
the
assigned
OWNER
and
GROUP
– Each
protected
operaKon
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
2/14/13
©
2012
Real-­‐Time
InnovaKons,
Inc.
-­‐
All
rights
reserved
18

19. MR#
6.5.1
DDS
Security
Model
• Subjects:
DDS
DomainParKcipant
(ParKcipant
GUID)
• Protected
Objects:
DDS
Domain
and
DDS
Topic
• Protected
Opera:ons
on
Objects
(logical
view):
– DomainParKcipant.join
– DomainParKcipant.add_read_parKKon
– DomainParKcipant.add_write_parKKon
– 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
2/14/13
©
2012
Real-­‐Time
InnovaKons,
Inc.
-­‐
All
rights
reserved
19

20. MR#
6.5.1
Mapping
of
DDS
API
to
protected
operaKons
DDS
API
Call
Protected
Opera:on
DomainParKcipantFactory.create_parKcipant
Discovery.match_remote_parKcipant
DomainParKcipant.join
DomainParKcipant.create_publisher
Publisher.set_qos
DomainParKcipant.add_write_parKKon
DomainParKcipant.create_subscriber
Subscriber.set_qos
DomainParKcipant.add_read_parKKon
DomainParKcipant.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
Protocol.receive_instance_new
DataWriter.dispose
2/14/13
Protocol.receive_dispose
Topic.dispose_instance
©
2012
Real-­‐Time
InnovaKons,
Inc.
-­‐
All
rights
reserved
20

21. Plaoorm
Independent
IntercepKon
Pts
+
SPIs
MR#
6.5.2
Service Plugin Purpose Interactions
Authentication Authenticate the principal that is The principal may be an
joining a DDS Domain. application/process or the user
associated with that application
Handshake and establish or process.
shared secret between
Participants may messages to
participants do mutual authentication and
establish shared secret
Access Control Decide whether a principal is allowed Protected operations include
to perform a protected operation. joining a specific DDS domain,
creating a Topic, reading a
Topic, writing a Topic, etc.
Cryptography Perform the encryption and Invoked by DDS middleware to
decryption operations. Create & encrypt data compute and verify
Exchange Keys. Compute digests, MAC, compute & verify Digital
compute and verify Message Signatures
Authentication Codes. Sign and
verify signatures of messages.
Logging Log all security relevant events Invoked by middleware to log
Data Tagging
2/14/13
Add a data ©
2012
Real-­‐Time
InnovaKons,
Inc.
-­‐
All
rights
reserved
tag for each data sample 21

22. Plaoorm
Independent
SPIs
MR#
6.5.2
2/14/13
©
2012
Real-­‐Time
InnovaKons,
Inc.
-­‐
All
rights
reserved
22

23. MR#
6.5.3
BuilKn
Plugins
SPI
Buil:n
Plungin
Notes
AuthenKcaKon
PKI_AuthenKcaKonPlugin
Uses
PKI
with
a
pre-­‐configured
shared
CerKficate
Authority
AccessControl
PKI_PermissionsPlugin
Permissions
document
signed
by
shared
CerKficate
Authority
Cryptography
Crypto-­‐AES-­‐CTR-­‐HMAC-­‐DSA-­‐DH
AES128
and
AES256
for
encrypKon
(in
counter
mode)
SHA1
and
SHA256
for
digest
HMAC-­‐SHA1
and
HMAC-­‐256
for
MAC
DSA
and
Diffie-­‐Hellman
for
authenKcaKon
and
key
exchange
KeyManagement
PKI_Protected_DDS_KeyDistribuKon
Use
authorized
reader
PK
to
protect
KeyDistribuKon
Not
described
in
submission
DataTagging
Discovered_EndpointTags
Send
Tags
via
Endpoint
Discovery
Logging
DedicatedDDS_LogTopic
2/14/13
©
2012
Real-­‐Time
InnovaKons,
Inc.
-­‐
All
rights
reserved
23

24. MR#
6.5.3
Crypto-­‐AES-­‐CTR-­‐HMAC-­‐DSA-­‐DH
• EncrypKon
uses
AES
in
counter
mode
– Similar
to
SRTP,
but
enhanced
to
support
mulKple
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
criKcal
to
support
DDS
QoS
like
history,
content
filters,
best-­‐efforts
etc.
• DSA
and
Diffie-­‐Hellman
used
for
mutual
authenKcaKon
and
secure
key
exchanage
2/14/13
©
2012
Real-­‐Time
InnovaKons,
Inc.
-­‐
All
rights
reserved
24

25. MR#
6.5.4
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
2/14/13
©
2012
Real-­‐Time
InnovaKons,
Inc.
-­‐
All
rights
reserved
25

26. Use
of
DDS
Interoperability
Protocol
MR#
6.5.5
• Uses:
Buil%nPar%cipantMessageWriter/Reader
– Msg
kind:
KIND_SECURITY_AUTH_HANDSHAKE
• data:
MessageToken
– Msg
kind:
KIND_SECURITY_KEY_TOKEN
• Data:
KeyToken
• Discovery
propagates
addiKonal
security
info
– Buil:nPar:cipantTopicData
• Iden:tyToken
[PID_SEC_IDENTITY_TOKEN]
• PermissionsToken
[PID_SEC_PERMISSIONS_TOKEN]
– Buil:nPublica:onTopicData
• DataTags
[PID_SEC_DATA_TAGS]
2/14/13
©
2012
Real-­‐Time
InnovaKons,
Inc.
-­‐
All
rights
reserved
26

27. Agenda
• Status
recap
• Summary
of
submission
• What
has
changed?
• Some
details
• Status
&
Conclusion
2/14/13
©
2012
Real-­‐Time
InnovaKons,
Inc.
-­‐
All
rights
reserved
27

28. What
has
changed
• Unified
Token
representaKons
– All
Tokens
use
common
data-­‐type
– Tokens
can
be
encrypted
(wrapped)
by
key
• AuthenKcaKon
SPI
can
now
do:
– Configurable
mulK-­‐step
Handshake
(subsumes
Challenge)
– Establishment
of
Shared
Secret
• Cryptography
SPI
– Focuses
just
on
Crypto,
MAC,
DigitalSignature
and
KeyExchange
– No
handshakes
anymore
• Secure
envelopes
– Data
protected
by
encrypKon
using
AES-­‐CTR
(as
before)
– MAC
can
be
used
for
whole
RTPS
message
(as
before)
– MAC
can
be
used
for
part
of
RTPS
message
(new)
2/14/13
©
2012
Real-­‐Time
InnovaKons,
Inc.
-­‐
All
rights
reserved
28

29. Agenda
• Status
recap
• Summary
of
submission
• What
has
changed?
• Some
details
• Status
&
Conclusion
2/14/13
©
2012
Real-­‐Time
InnovaKons,
Inc.
-­‐
All
rights
reserved
29

30. Tokens
are
a
generic
mechanism
to
pass
informaKon
between
DDS
and
SPIs
Token
interpretaKon
defined
by
SPI
ImplementaKons
Some
tokens
are
propagated
via
DDS
2/14/13
©
2012
Real-­‐Time
InnovaKons,
Inc.
-­‐
All
rights
reserved
30

31. Token
RepresentaKon
typedef string<> TokenClass;
typedef string<> TokenWrappingClass;
struct DDS_Property {
char *property_name;
char *property_value;
};
struct DDS_Token {
TokenClass token_classid;
WrappingClass wrapping_classid;
DDS_PropertySeq properties;
DDS_OctetSeq value;
DDS_OctetSeq wrapped_value;
};
2/14/13
©
2012
Real-­‐Time
InnovaKons,
Inc.
-­‐
All
rights
reserved
31

32. AuthenKcaKon
SPI
MR#
6.5.2
2/14/13
©
2012
Real-­‐Time
InnovaKons,
Inc.
-­‐
All
rights
reserved
32

33. MR#
6.5.2
Meta-­‐Protocol
to
handshake
and
AuthenKcaKon
establish
shared
2/14/13
©
2012
Real-­‐Time
InnovaKons,
Inc.
-­‐
All
rights
reserved
Behavior
secret
33

34. BuilKn
DDS:Auth:PKI-­‐DSA-­‐DH
• Uses
shared
CerKficate
Authority
(CA)
– All
ParKcipants
pre-­‐configured
with
shared-­‐CA
• Performs
mutual
authenKcaKon
between
discovered
parKcipants
using
the
Digital
Signature
Algorithm
(DSA)
• Establishes
a
shared
secret
using
Diffie-­‐
Hellman.
2/14/13
©
2012
Real-­‐Time
InnovaKons,
Inc.
-­‐
All
rights
reserved
34

35. ConfiguraKon
of
Auth:PKI-­‐DS-­‐DH
• Three
things:
– X.509
cerKficate
that
defines
the
shared
CA.
This
cerKficate
contains
the
Public
Key
of
the
CA.
– RSA
private
key
of
the
DomainParKcipant.
– An
X.509
cerKficate
that
chains
up
to
the
CA,
that
binds
the
DomainParKcipant
public
key
to
the
disKnguished
name
(subject
name)
for
the
parKcipant
and
any
intermediate
CA
cerKficates
required
to
build
the
chain
• ConfiguraKon
API
outside
scope
of
specificaKon
– Vendors
can
use
file,
QoS
property,
etc.
2/14/13
©
2012
Real-­‐Time
InnovaKons,
Inc.
-­‐
All
rights
reserved
35

36. Behavior
of
Auth:PKI-­‐DS-­‐DH
• validate_local_parKcipant
– IdenKtyCredenKalToken
has
X.509
cerKficate
– Validates
cerKficate
against
CA
• validate_remote_parKcipant
– Receives
X.509
cert
of
remote
parKcipant
in
IdenKtyToken
– Validates
X.509
cert
against
CA
– Does
3-­‐message
handshake
to:
• verify
possession
of
private
key
• establish
SharedSecret
2/14/13
©
2012
Real-­‐Time
InnovaKons,
Inc.
-­‐
All
rights
reserved
36

37. ParKcipants
receive
X.509
Cert
of
remote
parKcipant
via
discovery
2/14/13
©
2012
Real-­‐Time
InnovaKons,
Inc.
-­‐
All
rights
reserved
37

38. Each
ParKcipant
calls
validate_remote_idenKty()
this
checks
remote
X.509
Cert
against
locally-­‐configured
CA
ParKcipant
with
highest
GUID
returns
PENDING_HANDSHAKE_REQUEST,
the
other
PENDING_HANDSAHKE_MESSAGE
2/14/13
©
2012
Real-­‐Time
InnovaKons,
Inc.
-­‐
All
rights
reserved
38

39. ParKcipant1
creates
CHALLENGE1
=
“CHALLENGE:<nonce>
and
sends
message
via
ParKcipantMessageWriter
with
MessageToken
:=
{CHALLENGE1}
2/14/13
©
2012
Real-­‐Time
InnovaKons,
Inc.
-­‐
All
rights
reserved
39

40. ParKcipant2
creates
CHALLENGE2
:=
CHALLENGE:<nonce>
ParKcipant2
sends
to
ParKcipant1
message
with
MessageToken
:=
{SIGN(CHALLENGE1),
CHALLENGE2}
2/14/13
©
2012
Real-­‐Time
InnovaKons,
Inc.
-­‐
All
rights
reserved
40

41. Part1
verifies
SIGN(CHALLENGE1)
using
Part2’s
PK
Part1
computes
a
SharedSecret
Part1
sends
message
with
contents:
MessageToken
:=
{SIGN(CHALLENGE2),
ENCRYPT(SharedSecret)}
Encrypt
uses
Part2’s
PK.
2/14/13
©
2012
Real-­‐Time
InnovaKons,
Inc.
-­‐
All
rights
reserved
41

42. Part2
verifies
SIGN(CHALLENGE2)
using
Part1’s
PK
Part2
decrypts
SharedSecret
using
its
own
PK
We
have
Mutual
Authen:ca:on
and
a
SharedSecret
2/14/13
©
2012
Real-­‐Time
InnovaKons,
Inc.
-­‐
All
rights
reserved
42

43. MR#
6.5.2
Access
Control
SPI
2/14/13
©
2012
Real-­‐Time
InnovaKons,
Inc.
-­‐
All
rights
reserved
43

44. 2/14/13
©
2012
Real-­‐Time
InnovaKons,
Inc.
-­‐
All
rights
reserved
44

45. BuilKn
DDS:AC:PKI
SPI
• Configured
with:
– X.509
CerKficate
of
shared
Permissions
CA
– PermissionsCredenKalToken
• PermissionsCredenKalToken
contains
– XML
file
with
permissions
– Includes
SubjectName
matching
the
one
on
IdenKtyCredenKalToken
– All
signed
by
Permissions
CA
This
binds
the
permissions
to
the
indenKty
established
by
the
AuthenKcaKonPlugin
2/14/13
©
2012
Real-­‐Time
InnovaKons,
Inc.
-­‐
All
rights
reserved
45

46. Example
Permissions
2/14/13
©
2012
Real-­‐Time
InnovaKons,
Inc.
-­‐
All
rights
reserved
46

47. BuilKn
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
BuilKnPublicaKonWriter:
– 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
• EncrypKon
uses
AES
in
Counter
(CTR)
mode
– The
session
counter
is
sent
on
EncryptedMessage
Envelope.
2/14/13
©
2012
Real-­‐Time
InnovaKons,
Inc.
-­‐
All
rights
reserved
47

48. Conclusion
• Submission
revised
based
on
addiKonal
implementaKon
experience
• Plugin
APIs
modified
to
enhance
performance
and
support
implementaKons
that
want
to
use
MIKEY
exchanges
and
SRTP
style
encrypKon
• A
few
things
are
sKll
missing
– IDL
for
interfaces
– Wire
protocol
parameter-­‐ID
assignment
– Resolve
inconsistencies
in
document
• TargeKng
March
2012
for
vote
to
recommend
adopKon
• Joined
submissions
2/14/13
©
2012
Real-­‐Time
InnovaKons,
Inc.
-­‐
All
rights
reserved
48