omg dds security. 4th revised submission
DESCRIPTION
DDS Security: Fourth revised submission to the OMG Data Distribution Service (DDS) Security Specification.TRANSCRIPT
Your systems. Working as one.
DDS SECURITY 4rd Revised Submission (Joint) mars/2013-‐03-‐10
Doc num: mars/2013-‐03-‐10 SpecificaKon lead: Gerardo Pardo-‐Castellote, Ph.D. CTO, Real-‐Time InnovaKons, Inc.
SubmiRers: Real-‐Time InnovaKons, Inc. PrismTech Corp. eProsima (supporter)
© 2012 Real-‐Time InnovaKons, Inc. -‐ All rights reserved
Agenda
• Status recap • Summary of submission
• What has changed?
• Some details
• Status & Conclusion
3/21/13 © 2012 Real-‐Time InnovaKons, Inc. -‐ All rights reserved 2
Status recap
• Started with two separate submissions by RTI and PrismTech – RTI submission focused on the mandatory requirements for an SPI Architecture and built-‐in SPIs
– PrismTech discussed on the use of technologies such as (MIKEY / SRTP) to support the needs of secure DDS
• As of the December 2012 meeKng PrismTech joined the RTI submission
3/21/13 © 2012 Real-‐Time InnovaKons, Inc. -‐ All rights reserved 3
Agenda
• Status recap • Summary of submission
• What has changed?
• How the submission allows a specializaKon to use MIKEY and SRTP
• Status & Conclusion
3/21/13 © 2012 Real-‐Time InnovaKons, Inc. -‐ All rights reserved 4
Intro to DDS Security and scope of this specificaKon
3/21/13 © 2012 Real-‐Time InnovaKons, Inc. -‐ All rights reserved 5
Security as a system problem
• UlKmately security is a system property – Involves hardware, so`ware, humans, procedures…
• Most directly related:
1. Securing the data-‐centric bus
2. IntegraKng across security domains
3. Securing the operaKng system
4. Securing the hardware & so`ware configuraKon
3/21/13 © 2012 Real-‐Time InnovaKons, Inc. -‐ All rights reserved 6
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
3/21/13 © 2012 Real-‐Time InnovaKons, Inc. -‐ All rights reserved
Ul:mately you need to implement the 3 of them
7
Fine-‐Grained Data-‐Centric Security
• Access control per Topic • Read versus-‐write permissions
• Field-‐specific permissions
Topics
3/21/13 8 © 2012 Real-‐Time InnovaKons, Inc. -‐ All rights reserved
Threats 1. Unauthorized subscripKon 2. Unauthorized publicaKon 3. Tampering and replay 4. Unauthorized access to data
by infrastructure services
3/21/13 © 2012 Real-‐Time InnovaKons, Inc. -‐ All rights reserved 9
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/mulKcast Insider Threats
• Two insider threats affecKng (mulKcast) data-‐centric systems are of unique significance 1. Reader mis-‐behaves as unauthorized writer
An applicaKon uses knowledge gained as authorized reader to spoof the system as a writer
2. Compromise of Infrastructure Service A service that is trusted to read and write data on behalf
of others (e.g. a persistence service ) becomes compromised
3/21/13 © 2012 Real-‐Time InnovaKons, Inc. -‐ All rights reserved 10
Reader mis-‐behaves as unauthorized writer
• SituaKon: – Alice -‐ creates a Crypto Key per Topic/DataWriter – Alice -‐ shares its Key with all intended readers as needed to mulKcast – Mallory – is an authorized reader so it has Alice’s key – Mallory – behaves maliciously and uses Alice’s key to create fake UDP messages pumng
Alice’s informaKon (IP, Port, GUIDs, etc.) but with bad data.
• ImplicaKons: – Bob sees message from Mallory and processes it believing it is from Alice – Mallory can provide a system-‐wide failure for all subscribers to topic T, making them process
wrong data, delete instances, – Depending on the Topic this can be catastrophic for the system
• Notes: – The problem is that all secrets shared by Alice and Bob are also known to Mallory
• So the aRack 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
3/21/13 © 2012 Real-‐Time InnovaKons, Inc. -‐ All rights reserved 11
Summary of RFP requirements
3/21/13 © 2012 Real-‐Time InnovaKons, Inc. -‐ All rights reserved 12
RFP Mandatory Requirements
Proposals shall define … 6.5.1 … a Plaoorm Independent Security Model for DDS
independent of the programming language used… 6.5.2 … a collecKon of Plaoorm Independent IntercepKon
Points and SPIs … 6.5.3 … built-‐in Plaoorm Independent Security Plugins that
implement the Plaoorm Independent Interfaces 6.5.4 … plaoorm specific mappings for the built-‐in plugins to
all the language PSMs supported by DDS 6.5.5 … how the DDS Interoperability Wire Protocol is used
to allow DDS applicaKons to interoperate securely
3/21/13 © 2012 Real-‐Time InnovaKons, Inc. -‐ All rights reserved 13
Mandatory Requirements 6.5.1: Security Model
The Security Model for DDS shall … 6.5.1.1 … support mechanisms that establish the ability for a DDS ParKcipant to run in a
plaoorm
6.5.1.2 … support mechanisms to configure and access the credenKals of the underlying DDS ParKcipants …
6.5.1.3 … allow specificaKon of authorizaKon policies, controlling
[1] Joining a DDS Domain
[2] Access to DDS Discovery Data [3] Publishing a DDS Topic, [4] Subscribing to a DDS Topic
[5] Publishing on a DDS ParKKon, [6] Subscribing on a DDS ParKKon
6.5.1.4 … include the concept of data tagging
6.5.1.5 … support mechanism for ensuring data integrity, including
[1] traceability, pedigree, and tamper [2] digital signatures
[3] data encrypKon
[4] use of different keys for data from different DataWriters
3/21/13 © 2012 Real-‐Time InnovaKons, Inc. -‐ All rights reserved 14
Mandatory Requirements 6.5.2: Set of IntercepKon Points and SPIs
The Plugin SPIs shall … 6.5.2.1 … allow applicaKons to exchange credenKals with a DDS ParKcipant
[1] exchanging credenKals for authenKcaKon
[2] delegaKon of authority for authenKcaKon
6.5.2.2 … allow an external plugin to perform all the authorizaKon funcKons
[1] full support of the authorizaKon policies [3] support delegaKon of authority
[4] support delegaKon of authority separately for each DDS Topic
6.5.2.3 … allow an external plugin to perform all the tagging and tag-‐accessing funcKons
6.5.2.4 … allow an external plugin to perform all the encrypKon and decrypKon funcKons
6.5.2.5 … external plugin to perform all the digital signing and verificaKon funcKons
3/21/13 © 2012 Real-‐Time InnovaKons, Inc. -‐ All rights reserved 15
RFP OpKonal Requirements
Proposals may define authorizaKon policies that control … 6.6.1 … the content a DDS ParKcipant is allowed to publish on a Topic. 6.6.2 … the content a DDS ParKcipant is allowed to subscribe on a Topic.. 6.6.3 … the QoS Policies a DDS ParKcipants can use when publishing a Topic 6.6.4 … the QoS Policies a DDS ParKcipant can use when subscribing to a
Topic.
Proposals may define … 6.6.5 … data-‐tagging plugins that apply different tags for each data-‐sample
published by a DDS DataWriter. 6.6.6 … built-‐in plugins that interoperate with standard authenKcaKon and
authorizaKon protocols and services, such as, LDAP and SAML. 6.6.7 … a PSM mapping of the DDS-‐RTPS Interoperability Wire Protocol to a
secure transport, such as, DTLS. 6.6.8 … a PSM of the DDS-‐RTPS Interoperability Wire Protocol allowing
interoperability over UnidirecKonal Transports.
3/21/13 © 2012 Real-‐Time InnovaKons, Inc. -‐ All rights reserved 16
Summary of DDS Security spec.
3/21/13 © 2012 Real-‐Time InnovaKons, Inc. -‐ All rights reserved 17
Submission Guiding Principles • Performance & Scalability
– Do not impact parts of the system that do not have security needs
– Allow opKng out of specific features such as MAC, EncrypKon. Digital Signature with sufficient granularity
– Limit use of asymmetric keys to discovery & session establishment
– Support MulKcast
• Robustness & Availability – Be robust to the failure or compromise of any single component.
– Limit privileges of infrastructure services and relays
– Avoid centralized policy decisions/services
– Avoid mulK-‐party key agreement protocols
• Fitness to data-‐centric model – Express policies and permissions in terms of familiar DDS terminology and objects – Support all of DDS: consumpKon of samples out of order, best efforts, Kme filters, history cache,
etc.
• Leverage exis:ng technologies – Support plugging in exiKng technologies for ciphers, MAC, PKI
• Ease of use & Flexibility – DO not preclude integraKng with their exisKng security and crypto infrastructure.
3/21/13 © 2012 Real-‐Time InnovaKons, Inc. -‐ All rights reserved 18
Audience and Purpose for this SpecificaKon
• Audience: – DDS vendors/implementers, not the users of DDS
• Purpose: – Define a Security Model for DDS systems – Define concrete IntercepKon points in the middleware where SPI interfaces must be called
– Define concrete SPI Interfaces vendors must invoke at the IntercepKon Points and the behavior upon various returns
– Define specific SPI implementaKons to the extent required for interoperability
– NOT guidance to users implemenKng secure DDS systems – NOT definiKon of security technologies beyond what is required to implement the specificaKon
3/21/13 © 2012 Real-‐Time InnovaKons, Inc. -‐ All rights reserved 19
DDS Security covers 4 related concerns
3/21/13 © 2012 Real-‐Time InnovaKons, Inc. -‐ All rights reserved 20
Security Plugin APIs & Behavior
DDS & RTPS support for Security
Buil:n Plugins
Security Model
Security Model
3/21/13 © 2012 Real-‐Time InnovaKons, Inc. -‐ All rights reserved 21
Security Model
• A security model is defined in terms of: – The subjects (principals) – The objects being protected
• The operaKons that are protected on the objects – Access Control Model
• A way to map each subject to the objects they can perform operaKons on and which are the allowed operaKons
3/21/13 © 2012 Real-‐Time InnovaKons, Inc. -‐ All rights reserved 22
MR# 6.5.1
Security Model Example: UNIX FileSystem (simplified)
• Subjects: Users, specifically processes execuKng on behalf of a specific userid • Protected Objects: Files and Directories
• Protected OperaKons on Objects:
– Directory.list, Directory.createFile, Directory.createDir, Directory.removeFile, Directory.removeDir, Directory.renameFile
– File.view, File.modify, File.execute
• Access Control Model: – A subject is given a userId and a set of groupId – Each object is assigned a OWNER and a GROUP
– Each Object is given a combinaKon of READ, WRITE, EXECUTE permissions for the assigned OWNER and GROUP
– Each protected operaKon is mapped to a check, for example • File.view is allowed if and only if
– File.owner == Subject.userId AND File.permissions(OWNER) includes READ
– OR File.group IS-‐IN Subject.groupId[] AND File.permissions(GROUP) includes READ
3/21/13 © 2012 Real-‐Time InnovaKons, Inc. -‐ All rights reserved 23
DDS Security Model • Subjects: DDS DomainParKcipant (ParKcipant GUID) • Protected Objects: DDS Domain and DDS Topic
• Protected Opera:ons on Objects (logical view):
– DomainParKcipant.join – DomainParKcipant.add_read_parKKon
– DomainParKcipant.add_write_parKKon
– Topic.create – Topic.set_qos – Topic.set_reader_qos – Topic.read – Topic.set_writer_qos – Topic.write – Topic.create_instance – Topic.update_instance – Topic.dispose_instance
3/21/13 © 2012 Real-‐Time InnovaKons, Inc. -‐ All rights reserved 24
MR# 6.5.1
Mapping of DDS API to protected operaKons
3/21/13 © 2012 Real-‐Time InnovaKons, Inc. -‐ All rights reserved 25
DDS API Call Protected Opera:on DomainParKcipantFactory.create_parKcipant Discovery.match_remote_parKcipant DomainParKcipant.join DomainParKcipant.create_publisher Publisher.set_qos DomainParKcipant.add_write_parKKon DomainParKcipant.create_subscriber Subscriber.set_qos DomainParKcipant.add_read_parKKon
DomainParKcipant.create_topic Discovery.dicover_topic Topic.create, Topic.seq_qos Topic.set_qos Topic.set_qos Subscriber.create_datareader Discovery.dicover_datareader Topic.read, Topic.set_reader_qos DataReader.set_qos Discovery.change_datareader_qos Topic.set_reader_qos Publisher.create_datawriter Discovery.dicover_datawriter Topic.write, Topic.set_writer_qos DataWriter.set_qos Discovery.change_datawriter_qos Topic.set_writer_qos DataWriter.register_instance DataWriter.write Protocol.receive_instance_new
Topic.create_instance
DataWriter.dispose Protocol.receive_dispose Topic.dispose_instance
MR# 6.5.1
DDS & RTPS Support for Security
3/21/13 © 2012 Real-‐Time InnovaKons, Inc. -‐ All rights reserved 26
Support for Security in DDS & RTPS
• DDS ParKcipants need to exchange security informaKon – CerKficates for AuthenKcaKon & Permissions – Handshake messages for mutual authenKcaKon and shared-‐secret establishment
– KeyTokens for key-‐exchange • These messages reuse exisKng DDS mechanisms
– Discovery topics – BuilKn data readers / writers
• EncrypKon and signatures introduce new RTPS Submessage and Submessage elements – SecureSubMessage – SecuredData
3/21/13 © 2012 Real-‐Time InnovaKons, Inc. -‐ All rights reserved 27
Security informaKon propagated via DDS discovery
2 addiKonal aRributes added to ParKcipantBuilKnTopicData:
IdenKtyToken idenKty;
PermissionsToken permissions;
3/21/13 © 2012 Real-‐Time InnovaKons, Inc. -‐ All rights reserved 28
struct Property { string<> name; string<> value; }; typedef sequence<Property> PropertySeq;
struct Token { string<> token_classid; string<> wrapper_classid; PropertySeq properKes; sequence<octet> value; sequence<octet> wrapped_value; };
typedef Token Iden:tyToken; typedef Token PermissionsToken;
Security informaKon exchanged via BuilKnParKcipantMessageWriter
4 addiKonal kinds:
KIND_SECURITY_AUTH_HANDSHAKE
KIND_SECURITY_PARTICIPANT_CRYPTO_TOKENS
KIND_SECURITY_DATAWRITER_CRYPTO_TOKENS KIND_SECURITY_DATAREADER_CRYPTO_TOKENS
3/21/13 © 2012 Real-‐Time InnovaKons, Inc. -‐ All rights reserved 29
struct CryptoTokensMsg { octet sending_guid[16]; octet receiving_guid[16]; CryptoTokenSeq crypto_tokens; };
typedef Token CryptoToken; sequence<CryptoToken> CryptoTokenSeq;
typedef Token HandshakeTokenMsg; typedef CryptoTokensMsg Par:cipantCryptoTokensMsg; typedef CryptoTokensMsg DatawriterCryptoTokensMsg; typedef CryptoTokensMsg DatareaderCryptoTokensMsg;
BuilKnParKcipantMessageWriter
3/21/13 © 2012 Real-‐Time InnovaKons, Inc. -‐ All rights reserved 30
typedef octet GuidPrefix_t[12]; typedef octet Par:cipantMessageDataKind[4];
struct Par:cipantMessageData { GuidPrefix_t par:cipantGuidPrefix; //@Key Par:cipantMessageDataKind kind; //@Key sequence<octet> data; };
Background: RTPS
3/21/13 © 2012 Real-‐Time InnovaKons, Inc. -‐ All rights reserved 31
RTPS SubMessage
RTPS Header
RTPS SubMessage
RTPS SubMessage
RTPS SubMessage
SubMsg Header
SubMsg Element
SubMsg Element
SerializedData
RTPS SubMessage
RTPS Message
Cryptographic SPI at the wire-‐protocol level
© 2012 RTI • UNCLASSIFIED • PROPRIETARY
RTPS SubMessage
SerializedData
RTPS SubMessage
SerializedData
RTPS Header RTPS Header
RTPS SubMessage (*)
RTPS SubMessage
SecuredData
SerializedData
RTPS SubMessage
SecuredData
SerializedData
RTPS SubMessage (*)
RTPS SubMessage (*)
Secure encoding
Secure decoding
Message TransformaKon
RTPS SubMessage
SerializedData
RTPS Header RTPS Header
RTPS SubMessage
SecuredData
SerializedData
encode_serialized_data
RTPS SubMessage
RTPS SubMessage
RTPS SubMessage
RTPS Header
encode_datawriter_submessage
RTPS Header
RTPS SecureSubMsg
RTPS SubMessage
RTPS SubMessage
RTPS SubMessage
RTPS SubMessage
RTPS Header
encode_datareader_submessage
RTPS Header
RTPS SecureSubMsg
RTPS SubMessage
RTPS SubMessage
RTPS SubMessage
RTPS SubMessage
RTPS SubMessage
RTPS Header RTPS Header
RTPS SecureSubMsg
encode_rtps_message
RTPS SubMessage RTPS SubMessage
RTPS SubMessage
RTPS SubMessage
RTPS SubMessage
SerializedData
RTPS SubMessage
SerializedData
RTPS Header RTPS Header
RTPS SecSubMsg
RTPS SubMessage
SecuredData
SerializedData
RTPS SubMessage
SecuredData
SerializedData
RTPS SecSubMsg
RTPS SecSubMsg
encode_rtps_message
encode_datawriter_submessage
encode_serialized_data
Security Plugins
3/21/13 © 2012 Real-‐Time InnovaKons, Inc. -‐ All rights reserved 37
Plaoorm Independent IntercepKon Pts + SPIs
3/21/13 © 2012 Real-‐Time InnovaKons, Inc. -‐ All rights reserved 38
Service Plugin Purpose Interactions
Authentication Authenticate the principal that is joining a DDS Domain.
Handshake and establish shared secret between participants
The principal may be an application/process or the user associated with that application or process. Participants may messages to do mutual authentication and establish shared secret
Access Control Decide whether a principal is allowed to perform a protected operation.
Protected operations include joining a specific DDS domain, creating a Topic, reading a Topic, writing a Topic, etc.
Cryptography Perform the encryption and decryption operations. Create & Exchange Keys. Compute digests, compute and verify Message Authentication Codes. Sign and verify signatures of messages.
Invoked by DDS middleware to encrypt data compute and verify MAC, compute & verify Digital Signatures
Logging Log all security relevant events Invoked by middleware to log
Data Tagging Add a data tag for each data sample
MR# 6.5.2
Plaoorm Independent SPIs
3/21/13 © 2012 Real-‐Time InnovaKons, Inc. -‐ All rights reserved 39
MR# 6.5.2
BuilKn Plugins
3/21/13 © 2012 Real-‐Time InnovaKons, Inc. -‐ All rights reserved 40
SPI Buil:n Plungin Notes
AuthenKcaKon DDS:Auth:PKI-‐RSA/DSA-‐DH Uses PKI with a pre-‐configured shared CerKficate Authority. DSA and Diffie-‐Hellman for authenKcaKon and key exchange Establishes shared secret
AccessControl DDS:Access:PKI-‐Signed-‐XML-‐Permissions
Permissions document signed by shared CerKficate Authority
Cryptography DDS:Crypto:AES-‐CTR-‐HMAC-‐RSA/DSA-‐DH
Protected key distribuKon AES128 and AES256 for encrypKon (in counter mode) SHA1 and SHA256 for digest HMAC-‐SHA1 and HMAC-‐256 for MAC
DataTagging Discovered_EndpointTags Send Tags via Endpoint Discovery
Logging DedicatedDDS_LogTopic
MR# 6.5.3
Mapping to DDS Language PSMs
• Plugin SPIs to be defined using IDL • IDL-‐to-‐Language mappings used for each Language PSM
• No need to define mappings to new Javs5 PSM and STD-‐C++ PSM – IDL-‐derived Language PSMs suffice as these are low-‐level interfaces that will only be exercised by SPI plugin implementers.
NOTE: IDL file is missing from submission
3/21/13 © 2012 Real-‐Time InnovaKons, Inc. -‐ All rights reserved 41
MR# 6.5.4
Use of DDS Interoperability Protocol
• Uses: Buil%nPar%cipantMessageWriter/Reader – Msg kind: KIND_SECURITY_AUTH_HANDSHAKE
• data: MessageToken
– Msg kind: KIND_SECURITY_KEY_TOKEN • Data: KeyToken
• Discovery propagates addiKonal security info – Buil:nPar:cipantTopicData
• Iden:tyToken [PID_SEC_IDENTITY_TOKEN] • PermissionsToken [PID_SEC_PERMISSIONS_TOKEN]
– Buil:nPublica:onTopicData • DataTags [PID_SEC_DATA_TAGS]
3/21/13 © 2012 Real-‐Time InnovaKons, Inc. -‐ All rights reserved 42
MR# 6.5.5
Agenda
• Status recap • Summary of submission
• What has changed?
• Some details
• Status & Conclusion
3/21/13 © 2012 Real-‐Time InnovaKons, Inc. -‐ All rights reserved 43
What has changed • Unified Token representaKons
– All Tokens use common data-‐type – Tokens can be encrypted (wrapped) by key
• AuthenKcaKon SPI can now do: – Configurable mulK-‐step Handshake (subsumes Challenge) – Establishment of Shared Secret
• Cryptography SPI – Focuses just on Crypto, MAC, DigitalSignature and KeyExchange
– No handshakes anymore • Secure envelopes
– Data protected by encrypKon using AES-‐CTR (as before) – MAC can be used for whole RTPS message (as before) – MAC can be used for part of RTPS message (new)
3/21/13 © 2012 Real-‐Time InnovaKons, Inc. -‐ All rights reserved 44
Agenda
• Status recap • Summary of submission
• What has changed?
• Some details
• Status & Conclusion
3/21/13 © 2012 Real-‐Time InnovaKons, Inc. -‐ All rights reserved 45
Tokens are a generic mechanism to pass informaKon between DDS and SPIs Token interpretaKon defined by SPI ImplementaKons Some tokens are propagated via DDS
3/21/13 © 2012 Real-‐Time InnovaKons, Inc. -‐ All rights reserved 46
Token RepresentaKon
3/21/13 © 2012 Real-‐Time InnovaKons, Inc. -‐ All rights reserved 47
typedef string<> TokenClass; typedef string<> TokenWrappingClass;
struct DDS_Property { char *property_name; char *property_value; };
struct DDS_Token { TokenClass token_classid; WrappingClass wrapping_classid; DDS_PropertySeq properties; DDS_OctetSeq value; DDS_OctetSeq wrapped_value;
};
AuthenKcaKon
3/21/13 © 2012 Real-‐Time InnovaKons, Inc. -‐ All rights reserved 48
AuthenKcaKon SPI
3/21/13 © 2012 Real-‐Time InnovaKons, Inc. -‐ All rights reserved 49
MR# 6.5.2
AuthenKcaKon Behavior 3/21/13 © 2012 Real-‐Time InnovaKons, Inc. -‐ All rights reserved 50
MR# 6.5.2
Meta-‐Protocol to handshake and establish shared secret
BuilKn DDS:Auth:PKI-‐DSA-‐DH
• Uses shared CerKficate Authority (CA) – All ParKcipants pre-‐configured with shared-‐CA
• Performs mutual authenKcaKon between discovered parKcipants using the Digital Signature Algorithm (DSA)
• Establishes a shared secret using Diffie-‐Hellman.
3/21/13 © 2012 Real-‐Time InnovaKons, Inc. -‐ All rights reserved 51
ConfiguraKon of Auth:PKI-‐DS-‐DH
• Three things: – X.509 cerKficate that defines the shared CA. This cerKficate contains the Public Key of the CA.
– RSA private key of the DomainParKcipant. – An X.509 cerKficate that chains up to the CA, that binds the DomainParKcipant public key to the disKnguished name (subject name) for the parKcipant and any intermediate CA cerKficates required to build the chain
• ConfiguraKon API outside scope of specificaKon – Vendors can use file, QoS property, etc.
3/21/13 © 2012 Real-‐Time InnovaKons, Inc. -‐ All rights reserved 52
Behavior of Auth:PKI-‐DS-‐DH
• validate_local_parKcipant – IdenKtyCredenKalToken has X.509 cerKficate – Validates cerKficate against CA
• validate_remote_parKcipant – Receives X.509 cert of remote parKcipant in IdenKtyToken
– Validates X.509 cert against CA – Does 3-‐message handshake to:
• verify possession of private key • establish SharedSecret
3/21/13 © 2012 Real-‐Time InnovaKons, Inc. -‐ All rights reserved 53
3/21/13 © 2012 Real-‐Time InnovaKons, Inc. -‐ All rights reserved 54
Remote ParKcipant AuthenKcaKon
ParKcipants receive X.509 Cert of remote parKcipant via discovery
3/21/13 © 2012 Real-‐Time InnovaKons, Inc. -‐ All rights reserved 55
Each ParKcipant calls validate_remote_idenKty() this checks remote X.509 Cert against locally-‐configured CA
ParKcipant with highest GUID returns PENDING_HANDSHAKE_REQUEST, the other PENDING_HANDSAHKE_MESSAGE
Remote ParKcipant AuthenKcaKon
3/21/13 © 2012 Real-‐Time InnovaKons, Inc. -‐ All rights reserved 56
ParKcipant1 creates CHALLENGE1 = “CHALLENGE:<nonce> and sends message via ParKcipantMessageWriter with MessageToken := {CHALLENGE1}
Remote ParKcipant AuthenKcaKon
3/21/13 © 2012 Real-‐Time InnovaKons, Inc. -‐ All rights reserved 57
ParKcipant2 creates CHALLENGE2 := CHALLENGE:<nonce> ParKcipant2 sends to ParKcipant1 message with MessageToken := {SIGN(CHALLENGE1), CHALLENGE2}
Remote ParKcipant AuthenKcaKon
3/21/13 © 2012 Real-‐Time InnovaKons, Inc. -‐ All rights reserved 58
Part1 verifies SIGN(CHALLENGE1) using Part2’s PK Part1 computes a SharedSecret Part1 sends message with contents: MessageToken := {SIGN(CHALLENGE2), ENCRYPT(SharedSecret)} Encrypt uses Part2’s PK.
Remote ParKcipant AuthenKcaKon
3/21/13 © 2012 Real-‐Time InnovaKons, Inc. -‐ All rights reserved 59
Part2 verifies SIGN(CHALLENGE2) using Part1’s PK Part2 decrypts SharedSecret using its own PK
We have Mutual Authen:ca:on and a SharedSecret
Remote ParKcipant AuthenKcaKon
Access Control
3/21/13 © 2012 Real-‐Time InnovaKons, Inc. -‐ All rights reserved 60
Access Control SPI
3/21/13 © 2012 Real-‐Time InnovaKons, Inc. -‐ All rights reserved 61
MR# 6.5.2
BuilKn DDS:AC:PKI SPI
• Configured with: – X.509 CerKficate of shared Permissions CA – PermissionsCredenKalToken
• PermissionsCredenKalToken contains – XML file with permissions – Includes SubjectName matching the one on IdenKtyCredenKalToken
– All signed by Permissions CA
This binds the permissions to the idenKty established by the AuthenKcaKonPlugin
3/21/13 © 2012 Real-‐Time InnovaKons, Inc. -‐ All rights reserved 62
Example Permissions
3/21/13 © 2012 Real-‐Time InnovaKons, Inc. -‐ All rights reserved 63
Cryptographic
3/21/13 © 2012 Real-‐Time InnovaKons, Inc. -‐ All rights reserved 64
Cryptographic
3/21/13 © 2012 Real-‐Time InnovaKons, Inc. -‐ All rights reserved 65
Crypto-‐AES-‐CTR-‐HMAC-‐DSA-‐DH
• EncrypKon uses AES in counter mode – Similar to SRTP, but enhanced to support mulKple topics within a single RTPS message and infrastructure services like a relay or persistence
• Use of counter mode turns the AES block cipher into a stream cipher – Each DDS sample is separately encrypted and can be decrypted without process the previous message
• This is criKcal to support DDS QoS like history, content filters, best-‐efforts etc.
• DSA and Diffie-‐Hellman used for mutual authenKcaKon and secure key exchange
3/21/13 © 2012 Real-‐Time InnovaKons, Inc. -‐ All rights reserved 66
MR# 6.5.3
BuilKn DDS:Crypto-‐AES-‐CTR-‐HMAC-‐DSA-‐DH SPI
• Shared secret used to create a KeyExchangeKey • KeyExchangeKey used to send following Master Key Material using the
BuilKnPublicaKonWriter: – MasterKey – MasterSalt – MasterHMACSalt
• Based on this the following Key Material is computed: – SessionSalt := HMAC(MasterKey,"SessionSalt" + MasterSalt + SessionId + 0x00) [ Truncated to 128 bits] – SessionKey := HMAC(MasterKey,"SessionKey" + MasterSalt + SessionId + 0x01) – SessionHMACKey := HMAC(MasterKey,"SessionHMACKey" + MasterHMACSalt + SessionId) Note: SessionId goes on the EncryptedMessage Envelope
• EncrypKon uses AES in Counter (CTR) mode – The session counter is sent on EncryptedMessage Envelope.
3/21/13 © 2012 Real-‐Time InnovaKons, Inc. -‐ All rights reserved 67
Conclusion • Submission revised based on addiKonal implementaKon experience
• Plugin APIs modified to enhance performance and support implementaKons that want to use MIKEY exchanges and SRTP style encrypKon
• A few things are sKll missing – IDL for interfaces – Wire protocol parameter-‐ID assignment – Resolve inconsistencies in document – Examine is there are special rules that affects ParKKons
• TargeKng June 2013 for vote to recommend adopKon
3/21/13 © 2012 Real-‐Time InnovaKons, Inc. -‐ All rights reserved 68
Find out more… www.rK.com
community.rK.com
demo.rK.com
www.youtube.com/realKmeinnovaKons
blogs.rK.com
www.twiRer.com/RealTimeInnov
www.facebook.com/RTIso`ware
www.slideshare.net/GerardoPardo
dds.omg.org
www.omg.org
© 2012 RTI • ALL RIGHTS RESERVED 69