Third revised submission to the OMG Data Distribution Service 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.
• 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 focused on the use of exisKng technologies (MIKEY / SRTP) to supports the needs of secure DDS
• RTI took AI to show how MIKEY and SRTP could be supported as specific SPIs on the proposed SPI architecture – potenKally could lead to joint submission – Basic KeyExchange and EncrypKon mechanisms in PT submission are now possible in the built-‐in plugins
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
• 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 aLack 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
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
– 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.
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
AuthenKcaKon PKI_AuthenKcaKonPlugin Uses PKI with a pre-‐configured shared CerKficate Authority
AccessControl PKI_PermissionsPlugin Permissions document signed by shared CerKficate Authority
Cryptography Crypto-‐AES-‐CTR-‐HMAC-‐DSA-‐DH AES128 and AES256 for encrypKon (in counter mode) SHA1 and SHA256 for digest HMAC-‐SHA1 and HMAC-‐256 for MAC DSA and Diffie-‐Hellman for authenKcaKon and key exchange
KeyManagement PKI_Protected_DDS_KeyDistribuKon Use authorized reader PK to protect KeyDistribuKon Not described in submission
DataTagging Discovered_EndpointTags Send Tags via Endpoint Discovery
Logging DedicatedDDS_LogTopic
MR# 6.5.3
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 exchanage
• 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.
– 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)
Tokens are a generic mechanism to pass informaKon between DDS and SPIs Token interpretaKon defined by SPI ImplementaKons Some tokens are propagated via DDS
• 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.
• 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.