Successfully reported this slideshow.
Your SlideShare is downloading. ×

DDS Security for the Industrial Internet - London Connext DDS Conference


Check these out next

1 of 37 Ad

More Related Content

Slideshows for you (20)


Similar to DDS Security for the Industrial Internet - London Connext DDS Conference (20)

More from Gerardo Pardo-Castellote (20)


Recently uploaded (20)

DDS Security for the Industrial Internet - London Connext DDS Conference

  1. 1. DDS DDS Security Gerardo Pardo-Castellote, Ph.D. Chief Technology Officer, RTI October 2014
  2. 2. © 2014 Real-Time Innovations, Inc.
  3. 3. Data-Centric Qos-Aware Pub-Sub Model Virtual, decentralized global data space Persistence Service Recording Service © 2014 Real-Time Innovations, Inc. CRUD operations Source (Key) Speed Power Phase WPT1 37.4 122.0 -12.20 WPT2 10.7 74.0 -12.23 WPTN 50.2 150.07 -11.98
  4. 4. Is there a Conflict? © 2014 Real-Time Innovations, Inc. • Security… – desires to restrict communication to only happen between authorized subjects – requires to confidentiality so that only communicating subjects see the information • PubSub/DDS – attempts to create a ‘global information space’ where anybody can access the information it needs – de-couples communications so publishers are unaware of subscribers and vice-versa 4
  5. 5. No Conflict: Security in the Global Information Space The key is to use a net-centric security model • Publishers are decoupled from subscribers via the Global Information Space – This does not mean loss of access control to the information – It means that the Information Space must have an associated security model • DDS can use standard PKI and cryptographic techniques to enforce the security policies • The situation is analogous to access control policies in a file system © 2014 Real-Time Innovations, Inc.
  6. 6. Security Terms: a Safe-Deposit Box • Authentication: The bank knows who you are; you must show ID. • Access Control: The bank only lets those on an access list into your box. • Confidentiality: 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 repudiation: You sign when you come in and out so you can’t claim that you weren’t there. • Availability: The bank is always open. © 2014 Real-Time Innovations, Inc.
  7. 7. Threats 1. Unauthorized subscription 2. Unauthorized publication 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 10/27/2014 © 2012 Real-Time Innovations, Inc. - All rights reserved 7 © 2014 Real-Time Innovations, Inc.
  8. 8. Data-centric/multicast Insider Threats • Two insider threats affecting (multicast) data-centric systems are of unique significance 1. Reader mis-behaves as unauthorized writer An application 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 10/27/2014 © 2012 Real-Time Innovations, Inc. - All rights reserved 8 © 2014 Real-Time Innovations, Inc.
  9. 9. Session Sequence Number Attack © 2014 Real-Time Innovations, Inc. • Background: – 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 attacker can spoof a packet with the session ID and Hearbeat/GAP causing the DataReader to advance the session sequence-numbers blocking future messages reception – Attacker only needs GUID of the DataWriter to attack, which can be obtained from snooping traffic. – Attack can be used to prevent the Authentication of legitimate Participants
  10. 10. Squatting Attack on GUID © 2014 Real-Time Innovations, Inc. • Background: – DDS DomainParticipants are identified by unique GUID, Readers/Writers derive their GUID from it. – GUID used to uniquely identifies the RTPS sessions and the location of each participant • Vulnerability: – An attacker with legit Identity can authenticate using the GUID of another Participant – Attacker with be accepted with “cuckooed” GUID blocking legitimate Participant from using its GUID – Attacker only needs GUID of the Participant to attack, which can be obtained from snooping traffic.
  11. 11. DDS Security covers 4 related concerns Security Model Security Plugin APIs & Behavior DDS & RTPS support © 2014 Real-Time Innovations, Inc. for Security Builtin Plugins
  12. 12. Security Model Example: UNIX FileSystem (simplified) • Subjects: Users, specifically processes executing on behalf of a specific userid • Protected Objects: Files and Directories • Protected Operations on Objects: – Directory.list, Directory.createFile, Directory.createDir, Directory.removeFile, Directory.removeDir, Directory.renameFile – File.view, File.modify, File.execute © 2014 Real-Time Innovations, Inc. • 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 combination of READ, WRITE, EXECUTE permissions for the assigned OWNER and GROUP – Each protected operation 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 IS-IN Subject.groupId[] AND File.permissions(GROUP) includes READ
  13. 13. DDS Security Model © 2014 Real-Time Innovations, Inc. 10/27/2014 © 2012 Real-Time Innovations, Inc. - All rights reserved 13 Concept Unix Filesystem Security Model DDS Security Model Subject User Process executing for a user DomainParticipant Application joining a DDS domain Protected Objects Directories Files Domain (by domain_id) Topic (by Topic name) DataObjects (by Instance/Key) Protected Operations Directory.list, Directory.create (File, Dir) Directory.remove (File, Dir) Directory.rename (File, Dir), File.write, File.execute Domain.join Topic.create (includes QoS) Topic.write (includes QoS) Data.createInstance Data.writeInstance Data.deleteInstance Access Control Policy Control Fixed in Kernel Configurable via Plugin Builtin Access Control Mode Per-File/Dir Read/Write/Execute permissions for OWNER, GROUP, USERS Per-DomainParticipant Permissions : What Domains and Topics it can JOIN/READ/WRITE
  14. 14. Support for Security in DDS & RTPS • DDS Participants need to exchange security information – Certificates for Authentication & Permissions – Handshake messages for mutual authentication and shared-secret establishment – KeyTokens for key-exchange (Including Multicast Key Exchange) • Some reuse of existing DDS mechanisms – Builtin Participant data readers / writers – Discovery topic-types • Addition of secure discovery topics • Addition of a InterparticipantStatelessWriter/Reader • Encryption and signatures introduce new RTPS Submessage and Submessage elements – SecureSubMessage – SecuredData 10/27/2014 © 2012 Real-Time Innovations, Inc. - All rights reserved 14 © 2014 Real-Time Innovations, Inc.
  15. 15. Pluggable Security Architecture certificates application component ? Data cache Transport (e.g. UDP) Crypto Module (e.g. TPM ) © 2014 Real-Time Innovations, Inc. App. AApppp.. Other DDS System Secure DDS middleware Authentication Plugin Access Control Plugin Cryptographic Plugin Secure Kernel Protocol Engine Kernel Policies DDS Entities ? Network Driver Network Encrypted Data Other DDS System Other DDS System Logging Plugin DataTagging Plugin MAC
  16. 16. Platform Independent Interception Pts + SPIs © 2014 Real-Time Innovations, Inc. 10/27/2014 © 2012 Real-Time Innovations, Inc. - All rights reserved 16 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
  17. 17. Builtin Plugins SPI Builtin Plungin Notes Authentication DDS:Auth:PKI-RSA/DSA-DH Uses PKI with a pre-configured shared Certificate Authority. DSA and Diffie-Hellman for authentication and key exchange Establishes shared secret AccessControl DDS:Access:PKI-Signed- XML-Permissions Governance Document and Permissions Document Each signed by shared Certificate Authority Cryptography DDS:Crypto:AES-CTR-HMAC- RSA/DSA-DH Protected key distribution AES128 and AES256 for encryption (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 © 2014 Real-Time Innovations, Inc.
  18. 18. DDS Security Flow Authenticate DP? © 2014 Real-Time Innovations, Inc. Domain Participant Create Fails Authenticate Yes DP? No Ignore Remote DP Authenticate Remote DP? No Yes No Yes Access OK? Ignore remote endpoint Message security Endpoint Create Fails Yes Access OK? No Create Domain Participant Create Endpoints Discover remote DP Discover remote Endpoints Send/Receiv e data
  19. 19. Cryptographic SPI at the wire-protocol level Message Transformation RTPS Header RTPS Header © 2014 Real-Time Innovations, Inc. RTPS SubMessage SerializedData RTPS SubMessage SerializedData RTPS SubMessage (*) RTPS SubMessage (*) RTPS SubMessage SecuredData SerializedData RTPS SubMessage (*) RTPS SubMessage SecuredData SerializedData Secure encoding Secure decoding
  20. 20. Crypto-AES-CTR-HMAC-RSA/DSA-DH • Encryption uses AES in counter mode – Similar to SRTP, but enhanced to support multiple 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 critical to support DDS QoS like history, content filters, best-efforts etc. • DSA and Diffie-Hellman used for mutual authentication and secure key exchange © 2014 Real-Time Innovations, Inc. MR# 6.5.3
  21. 21. Builtin DDS:Auth:PKI-DSA-DH • Uses shared Certificate Authority (CA) – All Participants pre-configured with shared-CA • Performs mutual authentication between discovered participants using the Digital Signature Algorithm (DSA) • Establishes a shared secret using Diffie-Hellman. © 2014 Real-Time Innovations, Inc.
  22. 22. Remote Participant Authentication Participants detect each other via discovery and exchange Identity and Permission Tokens (Hashes) © 2014 Real-Time Innovations, Inc.
  23. 23. Remote Participant Authentication Each Participant calls validate_remote_identity(). Participant with highest GUID returns PENDING_HANDSHAKE_REQUEST, the other PENDING_HANDSHAKE_MESSAGE © 2014 Real-Time Innovations, Inc.
  24. 24. Remote Participant Authentication Participant1 creates CHALLENGE1 = “CHALLENGE:<nonce> and sends message via ParticipantMessageWriter with messageToken1:= {CHALLENGE1, Identity1, Permissions1} © 2014 Real-Time Innovations, Inc.
  25. 25. Remote Participant Authentication Participant2 validates Identity of Participant1 against CA Participant2 creates CHALLENGE2 := CHALLENGE:<nonce> Participant2 sends to Participant1 message with messageToken2:= { SIGN(HASH(CHALLENGE1#Identity1#Permissions1)), CHALLENGE2, Identity2, © 2014 Real-Time Permissions2} Innovations, Inc.
  26. 26. Part1 validates Identity of Participant2 against CA Part1 verifies SIGN(CHALLENGE1) using Participant2’s PK Part1 computes a SharedSecret Part1 sends message with contents: messageToken3 := { ENCRYPT(SharedSecret), SIGN( HASH(CHALLENGE2 # Identity2 # Permissions2 # ENCRYPT(SharedSecret))) } Encrypt uses Part2’s PK. Remote Participant Authentication 10/27/2014 © 2012 Real-Time Innovations, Inc. - All rights reserved 26 © 2014 Real-Time Innovations, Inc.
  27. 27. Remote Participant Authentication Part2 verifies SIGN( HASH(CHALLENGE2 #Identity2#Permissions2# ENCRYPT(SharedSecret))) 10/27/2014 © 2012 Real-Time Innovations, Inc. - All rights reserved 27 © 2014 Real-Time Innovations, Inc. using Part1’s PK Part2 decrypts ENCRYPT(SharedSecret) using its own PK We have Mutual Authentication and a SharedSecret
  28. 28. Builtin DDS:AC:PKI SPI © 2014 Real-Time Innovations, Inc. • Configured with: – X.509 Certificate of shared Permissions CA – The Domain governance signed by the Permissions CA – The DomainParticipant permissions signed by the Permissions CA • The Domain governance configures – Which topics shall be secured and how – Whether discovery is secured and how • DomainParticipant permissions – Specifies what Domains Id can be joined by the DomainParticipant – Specified which Topics and be Read/Written by the DomainParticipant on each DomainId – Ties to the SubjectName matching the one on IdentityCertificate 10/27/2014 © 2012 Real-Time Innovations, Inc. - All rights reserved 28
  29. 29. Example Domain Governance © 2014 Real-Time Innovations, Inc.
  30. 30. Configuration possibilities • Are “legacy” or un-identified applications allowed in the Domain? Yes or No. – If yes an Unauthenticated applications will: • See the “unsecured” discovery Topics • Be allowed to read/write the “unsecured” Topics • Is a particular Topic discovered over protected discovery? – If so it can only be seen by “authenticated applications” • Is a access particular Topic protected? – If so only authenticated applications with the correct permissions © 2014 Real-Time Innovations, Inc. can read/write • Is data on a particular Topic protected? How? – If so data will be sent signed or encrypted+signed • Are all protocol messages signed? Encrypted? – If so only authenticated applications with right permissions will see anything
  31. 31. Example Permissions © 2014 Real-Time Innovations, Inc.
  32. 32. Secure discovery • Additional built-in endpoints: – DCPSPublicationsSecure – DCPSSubscriptionsSecure • Same discovery topic-data but encrypted & signed • Operation AccessControl::get_endpoint_security_attributes() controls which Topics use Secure Discovery 10/27/2014 © 2012 Real-Time Innovations, Inc. - All rights reserved 32 © 2014 Real-Time Innovations, Inc.
  33. 33. Configuration Possibilities • Is the access to a particular Topic protected? – If so only authenticated applications with the correct permissions can read/write • Is data on a particular Topic protected? How? – If so data will be sent signed or encrypted+signed • Are all protocol messages signed? Encrypted? – If so only authenticated applications with right permissions will see anything © 2014 Real-Time Innovations, Inc.
  34. 34. More Powerful Than Other Secure Middleware Technologies • Standard & Interoperable • Scalable: Supports multicast • Fine-grain: Control Topic-level aspect • Flexible: Build your own plugins • Generic: Works over any Transport • Transparent: No changes to Application Code! © 2014 Real-Time Innovations, Inc.
  35. 35. DDS-Secure Standard Status • The specification was adopted in March 2014. – Considered “Beta” for 1 year – RTI chairing the Finalization Task Force • This specification provides a framework for securing DDS systems. The builtin plugins provide a “common” approach for applications without specialized requirements – It is expected that plugins will be developed to match more specialized deployments and integrate with existing infrastructure. 10/27/2014 © 2012 Real-Time Innovations, Inc. - All rights reserved 35 © 2014 Real-Time Innovations, Inc.
  36. 36. Questions? © 2014 RTI © 2014 Real-Time Innovations, Inc.
  37. 37. Find out more… © 2014 Real-Time Innovations, Inc. © 2014 RTI