OMG DDS Security Standard
1 like3,563 views
The document outlines a security model for Data Distribution Service (DDS) systems, detailing requirements for a platform-independent security framework, including authentication, access control, and data integrity mechanisms. It highlights various threats such as unauthorized access, insider threats, and the importance of maintaining separation between data recipients. Additionally, the submission provides guiding principles, mandatory requirements, and examples of proposed security policies and mechanisms to ensure secure operations within DDS environments.
![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](https://image.slidesharecdn.com/ddssecuritysubmissionjune2012mars20120615-120721001302-phpapp01/85/OMG-DDS-Security-Standard-10-320.jpg)
![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](https://image.slidesharecdn.com/ddssecuritysubmissionjune2012mars20120615-120721001302-phpapp01/85/OMG-DDS-Security-Standard-11-320.jpg)
![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](https://image.slidesharecdn.com/ddssecuritysubmissionjune2012mars20120615-120721001302-phpapp01/85/OMG-DDS-Security-Standard-23-320.jpg)
OMG DDS Security Standard
- 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
- 66. Example Permissions document <?xml version="1.0" encoding="utf-‐16” <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>SquareExtra</publish> </exception> </allow_with_exceptions> <extra_tags> <tag> <name>aTagName</name> <value>aTagValue</value> </tag> </extra_tags> </permissions> 6/25/12 © 2012 Real-‐Time InnovaLons, Inc. -‐ All rights reserved 66
- 67. Crypto-‐AES-‐CTR-‐HMAC • EncrypLon uses AES in counter mode – Similar to SRTP, but enhanced to support mulLple 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 criLcal to support DDS QoS like history, content filters, best-‐efforts etc. 6/25/12 © 2012 Real-‐Time InnovaLons, Inc. -‐ All rights reserved 67
- 68. Counter Mode EncrypLon • Each DataWriter creates a SessionKey and IniLalizaLonVector (IV). – Blocks are fixed to 128 bits – These are derived from a MasterKey – To decrypt the receiver must know SessionKey, IV, and SessionCounter • We derive SessionCounter from DDS SampleSequenceNumber and byte offset. – Messages encrypted in blocks of 7 bytes (128 bits) – SessionCounter := SampleSeqNum << 24 + block_counter – block_counter re-‐starts at zero for each Sample – This also applies to fragmented sample. Max size of sample limited to 2 Gbits 6/25/12 © 2012 Real-‐Time InnovaLons, Inc. -‐ All rights reserved 68
- 69. SessionKey derivaLon SessionSalt := HMAC(MasterKey,"SessionSalt" + MasterSalt + SessionId + 0x00) Truncated to 128 bits SessionKey := HMAC(MasterKey, "SessionKey" + MasterSalt + SessionId + 0x01) SessionHMACKey := HMAC(MasterKey, "SessionHMACKey” + MasterHMACSalt + SessionId) Notes: • MasterKey, MasterSalt, MasterHMACSalt are part of the CryptoKeyToken and HMACKeyToken • MasterKeyId and SessionId is encapsulated in the DDS/RTPS SerializaLonHeader 6/25/12 © 2012 Real-‐Time InnovaLons, Inc. -‐ All rights reserved 69
- 70. Digest and MAC ComputaLon • MAC is performed over a complete Submessage. Includes Headers, In-‐line QoS, KeyHash, and Encrypted Payload mac := H( ekey XOR opad, H( ekey XOR ipad, message ) Where: • H is the hash funcLon: SHA1 or SHA256 • opad is the byte 0x5C repeated 64 Lmes • ipad is the byte 0x36 repeated 64 Lmes • ekey is the secret HMacKey right padded with zero bytes to make it 64 bytes 6/25/12 © 2012 Real-‐Time InnovaLons, Inc. -‐ All rights reserved 70
- 71. DigitalSignature computaLon • Uses the PrivateKey of the DomainParLcipant to sign a HASH of the: – KeyHash – InlineQos – ORIGINAL_WRITER_INFO – Encrypted Payload • Complete Submessage not signed to support relay services propagaLon of digital signature 6/25/12 © 2012 Real-‐Time InnovaLons, Inc. -‐ All rights reserved 71
- 72. Agenda • Background • Requirements • Threats • Security Model • Plugins and SPIs • BuilLn Plugins • Status & Conclusion 6/25/12 © 2012 Real-‐Time InnovaLons, Inc. -‐ All rights reserved 72
- 73. Submission status: 70% Overall (weighted) RFP area Status Notes Security Model 80% The generic model is well defined, but it gets realized by the (sLll in progress) AccessControl plugin implementaLons. Plahorm 85% Complete definiLon of 6 SPIs with detailed descripLon of when Independent they are invoked and behaviors: IntercepLon Points and SPIs Missing: Management of “relay” services. ClarificaLons on how it impacts wire format of messages specifically with discovery and mulLcast Bindings of SPIs to 20% Binding missing from spec…. programming But they are reasonably straight forward to define from UML languages models and detailed descripLons. BuilLn SPI 30% One set of builLn-‐plugins is well defined. ImplementaLons Missing: We are intending to provide a second set of plugins that interfaces with exisLng infrastructure like LDAP and also a role-‐based and label-‐based access control model OpLonal 0% None of the opLonal requirements are addressed requirements Other 50% Missing introductory material in moLvaLon an scenarios, clarificaLons and guidance for implementers, traceability to RFP 6/25/12 © 2012 Real-‐Time InnovaLons, Inc. -‐ All rights reserved 73 requirements, discussion of evaluaLon criteria, etc.
- 74. Requirements Fulfilled Level Mandatory Requirements 6.5.1.1 Support mechanisms that establish the ability of a DDS Domain ParLcipant to run in a plahorm 6.5.1.2 Support mechanisms to configure and access credenLals for DDS Domain ParLcipants Plahorm Independent Security Model for DDS 6.5.1.3 Allow specificaLon of authorizaLon policies 6.5.1.4 Include the concept of data tagging 6.5.1.5 Support mechanisms for ensuring the confidenLality and integrity for the data delivered Plahorm Independent 6.5.2.1 Allow applicaLons to exchange credenLals with a DDS Domain ParLcipant intercepLon points and SPI 6.5.2.2 Allow an external plug-‐in to perform all the authorizaLon funcLons of DDS Security Model contracts implemented by DDS Security Plug-‐ins 6.5.2.3 Allow an external plug-‐in to perform all the tagging and tag-‐accessing funcLons of the Security Model for DDS 6.5.2.4 Allow an external plug-‐in to perform all the encrypLon and decrypLon of the Secure DDS 6.5.2.5 Allow an external plug-‐in to perform all the digital signing and verificaLon of the Secure DDS Built-‐in Plahorm 6.5.3.1 Allow means for accessing and configuring the DDS Security policies Independent Plug-‐ins Plahorm Specific Mappings 6.5.4.1 Consistent with the mappings of the DDS PIM to that language PSM to all the language PSMs RTPS Secure interoperability 6.5.5.1 Use RTPS in a way that does not break interoperability with exisLng RTPS compliant applicaLons 6.5.5.2 Use the extensibility mechanisms already present in RTPS to add any security-‐related features to the protocol 6/25/12 © 2012 Real-‐Time InnovaLons, Inc. -‐ All rights reserved 74
- 75. Thank You! 6/25/12 © 2012 Real-‐Time InnovaLons, Inc. -‐ All rights reserved 75