This is the presentation on the 6th Revised Submission to the OMG DDS Security specification.
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Your systems. Working as one.
DDS SECURITY 6th Revised Submission (Joint) Presented at OMG Mars Task Force on September 24, 2013
Status recap • Started with two separate submissions by RTI and PrismTech
• As of the December 2012 all joined the RTI submission
• Several reviews, last one in Berlin idenTfied a couple of vulnerabiliTes – Sequence Number AVack on reliable channels – Cuckoo aVack on ParTcipant GUID
• Most current version cleaned spec and addresses idenTfied vulnerabiliTes
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/mulTcast Insider Threats
• Two insider threats affecTng (mulTcast) data-‐centric systems are of unique significance 1. Reader mis-‐behaves as unauthorized writer
An applicaTon 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
• SituaTon: – Alice -‐ creates a Crypto Key per Topic/DataWriter – Alice -‐ shares its Key with all intended readers as needed to mulTcast – Mallory – is an authorized reader so it has Alice’s key – Mallory – behaves maliciously and uses Alice’s key to create fake UDP messages pukng
Alice’s informaTon (IP, Port, GUIDs, etc.) but with bad data.
• ImplicaTons: – 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 aVack 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
– Reliable protocols rely on a session_id and a sequence number to avoid duplicates and detect message loss
– RTPS protocol can use GAP messages and HeartBeat messages to advance the session (DataWriter) sequence number
• Vulnerability: – An aVacker can spoof a packet with the session ID and Hearbeat/GAP causing the DataReader to advance the session sequence-‐numbers blocking future messages recepTon
– AVacker only needs GUID of the DataWriter to aVack, which can be obtained from snooping traffic.
– AaVack can be used to prevent the AuthenTcaTon of legiTmate ParTcipants
Proposals may define authorizaTon policies that control … 6.6.1 … the content a DDS ParTcipant is allowed to publish on a Topic. 6.6.2 … the content a DDS ParTcipant is allowed to subscribe on a Topic.. 6.6.3 … the QoS Policies a DDS ParTcipants can use when publishing a Topic 6.6.4 … the QoS Policies a DDS ParTcipant 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 authenTcaTon and
authorizaTon 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
– Do not impact parts of the system that do not have security needs
– Allow opTng out of specific features such as MAC, EncrypTon. Digital Signature with sufficient granularity
– Limit use of asymmetric keys to discovery & session establishment
– Support MulTcast
• 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 mulT-‐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: consumpTon of samples out of order, best efforts, Tme filters, history cache,
etc.
• Leverage exis5ng technologies – Support plugging in exiTng technologies for ciphers, MAC, PKI
• Ease of use & Flexibility – Do not preclude integraTng with their exisTng security and crypto infrastructure.
• DDS ParTcipants need to exchange security informaTon – CerTficates for AuthenTcaTon & Permissions – Handshake messages for mutual authenTcaTon and shared-‐
secret establishment – KeyTokens for key-‐exchange
• Some reuse of exisTng DDS mechanisms – Discovery topics – BuilTn data readers / writers
• AddiTon of a InterparTcipantStatelessWriter/Reader • EncrypTon and signatures introduce new RTPS Submessage and Submessage elements
InterParTcipantStateless channel • Inherent “sequence number” vulnerability with any stateful channel.
– Send a Heartbeat for a future sequence number effecTvely shuts down channel
• Well-‐known in TCP. But miTgated via: – Random start sequence number per session – RejecTon of sequence numbers outside window
These “works” for TCP because it is point-‐to-‐point and is not communicaTng state (so no GAPs). It would not work for discovery, using mulTcast, etc.
To be robust to this aVack you need a protocol that does not reject things based on sequence numbers
This is already supported in the RTPS specificaTon
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
AuthenTcaTon DDS:Auth:PKI-‐RSA/DSA-‐DH Uses PKI with a pre-‐configured shared CerTficate Authority. DSA and Diffie-‐Hellman for authenTcaTon and key exchange Establishes shared secret
Protected key distribuTon AES128 and AES256 for encrypTon (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.
• Three things: – X.509 cerTficate that defines the shared CA. This cerTficate contains the Public Key of the CA.
– RSA private key of the DomainParTcipant. – A (PEM-‐encoded) X.509 cerTficate that chains up to the CA, that binds the DomainParTcipant public key to the disTnguished name (subject name) for the parTcipant and any intermediate CA cerTficates required to build the chain.
• ConfiguraTon API outside scope of specificaTon – Vendors can use file, QoS property, etc.
• validate_local_parTcipant – IdenTtyCredenTalToken has X.509 cerTficate – Validates cerTficate against CA
• begin_handshake_request – Sends X.509 CerTficate to peer parTcipant – Sends Signed Permissions to to peer parTcipant – Sends Challenge
• begin_handshake_reply – Sends X.509 CerTficate to peer parTcipant – Sends Signed Permissions to to peer parTcipant – Replies to Challenge & sends counter Challenge
• process_handshake – Verifies challenge response – Responds to final challenge – Exchanges SharedSecret
ParTcipant2 validates IdenTty of ParTcipant1 against CA ParTcipant2 creates CHALLENGE2 := CHALLENGE:<nonce> ParTcipant2 sends to ParTcipant1 message with MessageToken := {SIGN(CHALLENGE1), CHALLENGE2, IdenTty, Permissions}
Support for AccessControl on data-‐tags and parTTons
• check_local_datawriter_match
• check_local_datareader_match – OperaTons receive the reader & writer Permissions Handles and DataTags • The PermissionsHandles can cache any QoS that is relevant to access control decisions
Supports AccessControl rules based on DataTags or matching of other writer/reader aVributes (e.g. based on parTTon names)
• EncrypTon uses AES in counter mode – Similar to SRTP, but enhanced to support mulTple 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 criTcal to support DDS QoS like history, content filters, best-‐efforts etc.
• DSA and Diffie-‐Hellman used for mutual authenTcaTon and secure key exchange
• 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
• EncrypTon uses AES in Counter (CTR) mode – The session counter is sent on EncryptedMessage Envelope.