OMG DDS Security Standard

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


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


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


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


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


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


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.


Agenda

•  Background •  Requirements

• Threats •  Security Model •  BuilLn Plugins •  Plugins and SPIs •  Status & Conclusion


Threats 1.  Unauthorized subscripLon 2.  Unauthorized publicaLon 3.  Tampering and replay 4.  Unauthorized access to data

by infrastructure services


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


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


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.


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


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.


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


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


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


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


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


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>


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


IntercepLon Points: Current logical flow


Create Domain

ParLcipant AuthenLcate

DP?

Create Endpoints

Discover remote

Endpoints

Send/Receive data

Discover remote DP

IntercepLon Points inserted into the logical flow


Create Domain


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


Create Domain


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


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


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


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


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


AuthenLcaLon OperaLons


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.


Access Control SPI

Access Control OperaLons


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)


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)


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


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



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


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_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)


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


Key Management SPI

•  KeyManagerTokenHandle: local opaque reference to a previously stored token

•  TokenAccessTicket: Opaque Lcket granLng access to a key to an idenLfied DomainParLcipant


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.


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_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


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


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


Agenda

•  Background •  Requirements •  Threats •  Security Model •  Plugins and SPIs • Buil5n Plugins •  Status & Conclusion


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

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


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


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


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.


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.


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


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


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


Agenda

•  Background •  Requirements •  Threats •  Security Model •  Plugins and SPIs •  BuilLn Plugins • Status & Conclusion


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


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

OMG DDS Security Standard

Technology

Transcript of OMG DDS Security Standard