omg dds security standard
TRANSCRIPT
Your systems. Working as one.
DDS SECURITY
Revised Submission
Doc num: mars/2012-‐06-‐15 Gerardo Pardo-‐Castellote, Ph.D. CTO, Real-‐Time InnovaLons, Inc.
SubmiMer: Real-‐Time InnovaLons, Inc.
© 2012 Real-‐Time InnovaLons, Inc. -‐ All rights reserved
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
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.
33 6/25/12 © 2012 Real-‐Time InnovaLons, Inc. -‐ All rights reserved
Security as a system problem
• UlLmately security is a system property – Involves hardware, so\ware, humans, procedures…
• Most directly related:
1. Securing the data-‐cenLrc bus
2. IntegraLng across security domains
3. Securing the operaLng system
4. Securing the hardware & so\ware configuraLon
6/25/12 © 2012 Real-‐Time InnovaLons, Inc. -‐ All rights reserved 4
Scope of the RFP
Out of Scope
Scope of the DDS Security RFP
Three security boundaries
• Boundary security
• Transport-‐Level – Network (layer 3) security – Session (layer 4/5) security
• Fine-‐grained Data-‐Centric Security
6/25/12 © 2012 Real-‐Time InnovaLons, Inc. -‐ All rights reserved
Ul5mately you need to implement the 3 of them
5
Fine-‐Grained Data-‐Centric Security
• Access control per Topic • Read versus-‐write permissions
• Field-‐specific permissions
Topics
6/25/12 6 © 2012 Real-‐Time InnovaLons, Inc. -‐ All rights reserved
Data Security Example: UAV
6/25/12 © 2012 Real-‐Time InnovaLons, Inc. -‐ All rights reserved 7
Topics Authen5ca5on Access Control
Integrity Non-‐repudia5on
Confiden5ality
UAV health data
X X
Remote commands
X X X X X
Sensor Data X X X X
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
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
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
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
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
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
Threats 1. Unauthorized subscripLon 2. Unauthorized publicaLon 3. Tampering and replay 4. Unauthorized access to data
by infrastructure services
6/25/12 © 2012 Real-‐Time InnovaLons, Inc. -‐ All rights reserved 14
Alice: Allowed to publish topic T Bob: Allowed to subscribe to topic T Eve: Non-‐authorized eavesdropper Trudy: Intruder Trent: Trusted infrastructure service Mallory: Malicious insider
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
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
Compromise of Infrastructure Service (2)
• SituaLon: – Alice creates a Crypto Key to write topic T
– 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 data.
6/25/12 © 2012 Real-‐Time InnovaLons, Inc. -‐ All rights reserved 17
SubMsg Hdr(T1)
RTPS Hdr
DATA (T1)
SubMsg Hdr(T2)
DATA (T2)
UDP Hdr
MAC + EncrypLon
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 authorized readers
This is not in the submission yet 6/25/12 © 2012 Real-‐Time InnovaLons, Inc. -‐ All rights reserved 18
SubMsg Hdr(T1)
RTPS Hdr
DATA (T1)
SubMsg Hdr(T2)
DATA (T2)
UDP Hdr
EncrypLon MAC
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
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
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
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
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
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
Mapping of DDS API to protected operaLons
6/25/12 © 2012 Real-‐Time InnovaLons, Inc. -‐ All rights reserved 25
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 Protocol.receive_instance_new
Topic.create_instance
DataWriter.dispose Topic.dispose_instance
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
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/[email protected]</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>
6/25/12 © 2012 Real-‐Time InnovaLons, Inc. -‐ All rights reserved 27
• 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”
Pluggable Security Architecture
App.
Other DDS System
Secure DDS middleware
AuthenLcaLon Plugin
Access Control Plugin Cryptography
Plugin
Key Management Plugin
Secure Kernel
Crypto Module (e.g. TPM )
Secure Transport (e.g. TLS)
applicaLon component cerLficates
?
Data cache
Protocol Engine
Kernel Policies
DDS EnLLes
Network Driver
?
Network
Encrypted Data
TAG
Other DDS System
Other DDS System
App. App.
AudiLng Plugin
© 2012 Real-‐Time InnovaLons, Inc. -‐ All rights reserved
Tagging Plugin
6/25/12 28
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
IntercepLon Points: Current logical flow
6/25/12 © 2012 Real-‐Time InnovaLons, Inc. -‐ All rights reserved 31
Create Domain
ParLcipant AuthenLcate
DP?
Create Endpoints
Discover remote
Endpoints
Send/Receive data
Discover remote DP
IntercepLon Points inserted into the logical flow
6/25/12 © 2012 Real-‐Time InnovaLons, Inc. -‐ All rights reserved 32
Create Domain
ParLcipant AuthenLcate
DP?
Create Endpoints
Discover remote
Endpoints
Send/Receive data
Discover remote DP
AuthenLcate DP?
Yes
Domain ParLcipant Create Fails
No
Access OK? Endpoint Create Fails
No
AuthenLcate Remote DP?
Ignore Remote DP
No
Yes
Access OK? Ignore remote endpoint
Message security
AuthenLcaLon -‐ Local
6/25/12 © 2012 Real-‐Time InnovaLons, Inc. -‐ All rights reserved 33
Create Domain
ParLcipant AuthenLcate
DP?
AuthenLcate DP?
Yes
Domain ParLcipant Create Fails
No Load IdenLty
CerLficates
Get Auth Token
For PKI, token is PKI cerLficate
DDS Security Flow: Access Control
6/25/12 © 2012 Real-‐Time InnovaLons, Inc. -‐ All rights reserved 34
Create Endpoints
Access OK? Endpoint Create Fails
No Load Security Policies
Yes
Get Keys
If desired, add tag
Data Writer?
Yes
IntercepLon Points – Remote AuthenLcaLon and Access Control
6/25/12 © 2012 Real-‐Time InnovaLons, Inc. -‐ All rights reserved 35
Discover remote
Endpoints
Discover remote DP
AuthenLcate Remote DP?
Ignore Remote DP
No
Yes
Access OK? Ignore remote endpoint
Receive IdenLty Token
No
Matched DW?
Get Keys
Get remote DW tag
Yes
Yes
Does the remote Data
Writer match a local Data Reader
Receive Permissions Token
DDS Security Flow: Send Data
6/25/12 © 2012 Real-‐Time InnovaLons, Inc. -‐ All rights reserved 36
Write Encrypt?
Access CriptoKeys + Encrypt
DigitalSig?
Yes
Access PrivateKey +
Sign
No Marshall
Yes
Send RTPS Message to DesLnaLon
Marshal SampleInfo (KeyHash, SN, GUID)
Yes
MAC?
Access MACKeys +
compute MAC
Append MAC
Yes
Assemble Submessages
Send to UDP
Append Digital Signature
CipherText ClearText CipherText Header has
KeyId
TBD: DSig Header precedes ciphertext?
TBD: MAC as separate submessage? First or last?
In RTPS Header?
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
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
DDS DDS App
DDS App
AuthenLcaLon Service
© 2012 Real-‐Time InnovaLons, Inc. -‐ All rights reserved 6/25/12 39
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
AuthenLcaLon OperaLons
6/25/12 © 2012 Real-‐Time InnovaLons, Inc. -‐ All rights reserved 41
Opera5on Descrip5on
validate_local_identity
Validates the identity of the local DomainParticipant based on credentials, biometrics or whatever the plug-in requires.
validate_remote_identity
Validates the identity of the remote DomainParticipant, based on an IdentityToken representation. This operation may return an Identity Challenge that must be sent and replied to by the remote participant.
get_identity_token
Returns an IdentityToken that can be sent over the network to identify the DomainParticipant.
challenge_identity
Asks the local AuthenticationPlugin to respond to an identity challenge. The operation is invoked if a remote Participant sends a message requesting an identity challenge
validate_identity_challenge
Provides the AuthenticationPlugin with the response to an 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.
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
Access Control SPI
Access Control OperaLons
6/25/12 © 2012 Real-‐Time InnovaLons, Inc. -‐ All rights reserved 43
Opera5on Descrip5on
validate_local_permissions()
Validates the permissions of the local DomainParticipant. The permissions could be based on a PermissionsCredential presented to the plugin. The operation returns a PermissionsHandle object, if successful.
validate_remote_permissions()
Validates the permissions of the remote DomainParticipant, propagated as a PermissionsToken. The operation returns a PermissionsHandle, if successful.
check_create_particpant()
Enforces the permissions of the local DomainParticipant. Ensurng it is allowed to join the specified domain_id with the specified Participant QoS.
check_create_datawriter()
Enforces permissions to ensure the local DomainParticipant is allowed to write the specified Topic with the specified QoS.
check_create_datareader()
Enforces permissions to ensure the local DomainParticipant is allowed to read the specified Topic with the specified QoS.
check_create_topic()
Enforces permissions to ensure the local DomainParticipant is allowed to create the specified Topic with the specified QoS.
Access Control OperaLons (II)
6/25/12 © 2012 Real-‐Time InnovaLons, Inc. -‐ All rights reserved 44
Opera5on Descrip5on
check_local_datawriter_register_instance()
In case the access control requires a finer granularity at the instance level, this operation enforces the permissions of the local DataWriter to create a particular instance.
check_local_datawriter_dispose_instance()
In case the access control requires a finer granularity at the instance level, this operation enforces the permissions of the local DataWriter to delete a particular instance.
check_remote_participant()
Enforces the permissions on the remote DomainParticipant, ensuring it has permissions to join the domain with the specified domain_id and QoS.
check_remote_datawriter()
Enforces the permissions on the remote DomainParticipant 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_datareader()
Enforces the permissions on the remote DomainParticipant 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_topic()
Enforces permissions to ensure the remote DomainParticipant is allowed to create the specified Topic with the specified QoS.
Access Control OperaLons (III)
6/25/12 © 2012 Real-‐Time InnovaLons, Inc. -‐ All rights reserved 45
Opera5on Descrip5on
check_remote_datawriter_register_instance()
In case the access control requires a finer granularity at the instance level, this operation checks the permissions of the remote DataWriter allow it to create a particular instance.
check_remote_datawriter_dispose_instance()
In case the access control requires a finer granularity at the instance level, this operation checks the permissions of the remote DataWriter allow it to delete a particular instance.
get_permissions_token()
Returns the PermissionsToken that can be used to represent on the network the Participant’s permissions, which are identified by the specified PermissionsHandle.
set_listener()
Sets the listener for the AccessControl object.
Access Control Listener OperaLons
6/25/12 © 2012 Real-‐Time InnovaLons, Inc. -‐ All rights reserved 46
Opera5on Descrip5on
on_revoke_permissions()
DomainParticipants’ Permissions can be revoked/changed. This listener provides a callback for permission revocation/changes.
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
© 2012 Real-‐Time InnovaLons, Inc. -‐ All rights reserved 6/25/12 47
6/25/12 © 2012 Real-‐Time InnovaLons, Inc. -‐ All rights reserved 48
Provides support for: • Encrypt/Decrypt • MessageAuthenLcaLon • Digital signature &
verificaLon
Cryptographic SPI
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
Cryptographic OperaLons
6/25/12 © 2012 Real-‐Time InnovaLons, Inc. -‐ All rights reserved 50
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_info_from_token()
Returns the corresponding to a CryptographicToken.
get_key_from_token()
Returns the CryptographicKey corresponding to a CryptographicToken.
get_local_encryption_token()
Returns the local cryptographic token, CryptographicToken, given the local key.
get_remote_encryption_token()
Returns the remote CryptographicTokengiven the cypher info for it. In order to achieve interoperability, the cipher info needs to be known.
Cryptographic OperaLons (II)
6/25/12 © 2012 Real-‐Time InnovaLons, Inc. -‐ All rights reserved 51
Opera5on Descrip5on
set_key_for_token()
Associates a cryptographic key to a cryptographic token.
sign() Digitally signs the data and attaches the signatures on the wire.
verify() Verifies the signature of the data.
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 (o\en 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
© 2012 Real-‐Time InnovaLons, Inc. -‐ All rights reserved 6/25/12 52
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
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
Key Management OperaLons
6/25/12 © 2012 Real-‐Time InnovaLons, Inc. -‐ All rights reserved 55
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_access_ticket()
Returns a Ticket for a previously stored Token to be used by a 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_handle()
Looks up a Token given a Ticket. The KeyManager will 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.
Key Management Listener OperaLons
6/25/12 © 2012 Real-‐Time InnovaLons, Inc. -‐ All rights reserved 56
Opera5on Descrip5on
identity_challenge()
Used to enforce that only the intended recipient idenLty can get access to a stored Token
Logging (AudiLng) Plug-‐in
• Goal: Provide mechanism to log either locally or centralized all security events for audiLng
DDS App
Audit DB
Secure Plug-‐ins
© 2012 Real-‐Time InnovaLons, Inc. -‐ All rights reserved 6/25/12 57
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
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
BuilLn Plugins
6/25/12 © 2012 Real-‐Time InnovaLons, Inc. -‐ All rights reserved 60
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
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
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
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/[email protected] Validity Not Before: May 31 00:11:29 2012 GMT Not A\er : May 31 00:11:29 2013 GMT
Subject: C=US, ST=MA, L=Boston, O=OMG, OU=DDS SIG, CN=DDS Security Specifica5on/[email protected] 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: 5d:b6:d8:05
6/25/12 © 2012 Real-‐Time InnovaLons, Inc. -‐ All rights reserved 63
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/[email protected] Validity Not Before: May 31 00:43:09 2012 GMT Not A\er : May 31 00:43:09 2013 GMT
Subject: C=US, ST=CA, L=Sunnyvale, O=ACME Inc., OU=CTO Office, CN=DDS Shapes Demo/[email protected] 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
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
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/[email protected]</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
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
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 68 © 2012 Real-‐Time InnovaLons, Inc. -‐ All rights reserved
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
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
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
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
Submission status: 70% Overall (weighted)
6/25/12 © 2012 Real-‐Time InnovaLons, Inc. -‐ All rights reserved 73
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 Independent IntercepLon Points and SPIs
85% Complete definiLon of 6 SPIs with detailed descripLon of when they are invoked and behaviors:
Missing: Management of “relay” services. ClarificaLons on how it impacts wire format of messages specifically with discovery and mulLcast
Bindings of SPIs to programming languages
20% Binding missing from spec…. But they are reasonably straight forward to define from UML models and detailed descripLons.
BuilLn SPI ImplementaLons
30% One set of builLn-‐plugins is well defined. 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 requirements
0% None of the opLonal requirements are addressed
Other 50% Missing introductory material in moLvaLon an scenarios, clarificaLons and guidance for implementers, traceability to RFP requirements, discussion of evaluaLon criteria, etc.
Requirements Fulfilled
6/25/12 © 2012 Real-‐Time InnovaLons, Inc. -‐ All rights reserved 74
Level Mandatory Requirements
Plahorm Independent Security Model for DDS
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
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 intercepLon points and SPI contracts implemented by DDS Security Plug-‐ins
6.5.2.1 Allow applicaLons to exchange credenLals with a DDS Domain ParLcipant
6.5.2.2 Allow an external plug-‐in to perform all the authorizaLon funcLons of DDS Security Model
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 Independent Plug-‐ins
6.5.3.1 Allow means for accessing and configuring the DDS Security policies
Plahorm Specific Mappings to all the language PSMs
6.5.4.1 Consistent with the mappings of the DDS PIM to that language PSM
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