Successfully reported this slideshow.
Your SlideShare is downloading. ×
Loading in …3

Check these out next

1 of 37 Ad

More Related Content

Slideshows for you (20)

Viewers also liked (20)


Similar to DDS Security (20)

More from Real-Time Innovations (RTI) (20)


Recently uploaded (20)

DDS Security

  1. 1. DDS DDS Security Gerardo Pardo-­‐Castellote, Ph.D. Chief Technology Officer, RTI October 2014
  2. 2. © 2014 Real-­‐Time InnovaFons, Inc.
  3. 3. Data-­‐Centric Qos-­‐Aware Pub-­‐Sub Model Virtual, decentralized global data space Persistence Service Recording Service © 2014 Real-­‐Time InnovaFons, Inc. CRUD operaFons 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? • Security… © 2014 Real-­‐Time InnovaFons, Inc. – desires to restrict communicaFon to only happen between authorized subjects – requires to confidenFality so that only communicaFng subjects see the informaFon • PubSub/DDS – aWempts to create a ‘global informaFon space’ where anybody can access the informaFon it needs – de-­‐couples communicaFons so publishers are unaware of subscribers and vice-­‐versa 4
  5. 5. No Conflict: Security in the Global InformaFon Space The key is to use a net-­‐centric security model © 2014 Real-­‐Time InnovaFons, Inc. • Publishers are decoupled from subscribers via the Global InformaFon Space – This does not mean loss of access control to the informaFon – It means that the InformaFon Space must have an associated security model • DDS can use standard PKI and cryptographic techniques to enforce the security policies • The situaFon is analogous to access control policies in a file system
  6. 6. Security Terms: a Safe-­‐Deposit Box • AuthenFcaFon: The bank knows who you are; © 2014 Real-­‐Time InnovaFons, Inc. you must show ID. • Access Control: The bank only lets those on an access list into your box. • ConfidenFality: 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 repudiaFon: You sign when you come in and out so you can’t claim that you weren’t there. • Availability: The bank is always open.
  7. 7. Threats 1. Unauthorized subscripFon 2. Unauthorized publicaFon 3. Tampering and replay 4. Unauthorized access to data by infrastructure services 10/30/14 7 © 2014 Real-­‐Time InnovaFons, Inc. 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
  8. 8. Data-­‐centric/mulFcast Insider Threats • Two insider threats affecFng (mulFcast) data-­‐ centric systems are of unique significance 1. Reader mis-­‐behaves as unauthorized writer An applicaFon 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/30/14 8 © 2014 Real-­‐Time InnovaFons, Inc.
  9. 9. Session Sequence Number AWack • Background: © 2014 Real-­‐Time InnovaFons, Inc. – 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 aWacker can spoof a packet with the session ID and Hearbeat/GAP causing the DataReader to advance the session sequence-­‐numbers blocking future messages recepFon – AWacker only needs GUID of the DataWriter to aWack, which can be obtained from snooping traffic. – AWack can be used to prevent the AuthenFcaFon of legiFmate ParFcipants
  10. 10. Squakng AWack on GUID • Background: © 2014 Real-­‐Time InnovaFons, Inc. – DDS DomainParFcipants are idenFfied by unique GUID, Readers/Writers derive their GUID from it. – GUID used to uniquely idenFfies the RTPS sessions and the locaFon of each parFcipant • Vulnerability: – An aWacker with legit IdenFty can authenFcate using the GUID of another ParFcipant – AWacker with be accepted with “cuckooed” GUID blocking legiFmate ParFcipant from using its GUID – AWacker only needs GUID of the ParFcipant to aWack, which can be obtained from snooping traffic.
  11. 11. DDS Security covers 4 related concerns Security Model © 2014 Real-­‐Time InnovaFons, Inc. Security Plugin APIs & Behavior DDS & RTPS support for Security BuilHn Plugins
  12. 12. Security Model Example: UNIX FileSystem (simplified) • Subjects: Users, specifically processes execuFng on behalf of a specific userid © 2014 Real-­‐Time InnovaFons, Inc. • Protected Objects: Files and Directories • Protected OperaFons 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 combinaFon of READ, WRITE, EXECUTE permissions for the assigned OWNER and GROUP – Each protected operaFon 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. © 2014 Real-­‐Time InnovaFons, Inc. DDS Security Model 10/30/14 © 2012 Real-­‐Time InnovaFons, Inc. -­‐ All rights reserved 13 Concept Unix Filesystem Security Model DDS Security Model Subject User Process execuFng for a user DomainParFcipant ApplicaFon joining a DDS domain Protected Objects Directories Files Domain (by domain_id) Topic (by Topic name) DataObjects (by Instance/Key) Protected OperaFons 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 BuilFn Access Control Mode Per-­‐File/Dir Read/Write/ Execute permissions for OWNER, GROUP, USERS Per-­‐DomainParFcipant Permissions : What Domains and Topics it can JOIN/READ/WRITE
  14. 14. Support for Security in DDS & RTPS • DDS ParFcipants need to exchange security informaFon © 2014 Real-­‐Time InnovaFons, Inc. – CerFficates for AuthenFcaFon & Permissions – Handshake messages for mutual authenFcaFon and shared-­‐ secret establishment – KeyTokens for key-­‐exchange (Including MulFcast Key Exchange) • Some reuse of exisFng DDS mechanisms – BuilFn ParFcipant data readers / writers – Discovery topic-­‐types • AddiFon of secure discovery topics • AddiFon of a InterparFcipantStatelessWriter/Reader • EncrypFon and signatures introduce new RTPS Submessage and Submessage elements – SecureSubMessage – SecuredData 10/30/14 14
  15. 15. Pluggable Security Architecture Transport (e.g. UDP) Crypto Module (e.g. TPM ) © 2014 Real-­‐Time InnovaFons, Inc. App. AApppp. . Other DDS System Secure DDS middleware AuthenFcaFon Plugin Access Control Plugin Cryptographic Plugin Secure Kernel cerFficates applicaFon component ? Data cache Protocol Engine Kernel Policies DDS EnFFes ? Network Driver Network Encrypted Data Other DDS System Other DDS System Logging Plugin DataTagging Plugin MAC
  16. 16. Plaworm Independent IntercepFon Pts + SPIs © 2014 Real-­‐Time InnovaFons, Inc. 10/30/14 © 2012 Real-­‐Time InnovaFons, 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. © 2014 Real-­‐Time InnovaFons, Inc. BuilFn Plugins SPI BuilHn Plungin Notes AuthenFcaFon DDS:Auth:PKI-­‐RSA/DSA-­‐DH Uses PKI with a pre-­‐configured shared CerFficate Authority. DSA and Diffie-­‐Hellman for authenFcaFon and key exchange Establishes shared secret AccessControl DDS:Access:PKI-­‐Signed-­‐ XML-­‐Permissions Governance Document and Permissions Document Each signed by shared CerFficate Authority Cryptography DDS:Crypto:AES-­‐CTR-­‐ HMAC-­‐RSA/DSA-­‐DH Protected key distribuFon AES128 and AES256 for encrypFon (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
  18. 18. DDS Security Flow Domain ParFcipant Create Fails AuthenFcate AuthenFcate DP? © 2014 Real-­‐Time InnovaFons, Inc. Yes DP? No Ignore Remote DP AuthenFcate Remote DP? No Yes No Yes Access OK? Ignore remote endpoint Message security Endpoint Create Fails Yes Access OK? No Create Domain ParFcipant Create Endpoints Discover remote DP Discover remote Endpoints Send/ Receive data
  19. 19. Cryptographic SPI at the wire-­‐protocol level Message TransformaFon © 2014 Real-­‐Time InnovaFons, Inc. RTPS Header RTPS SubMessage SerializedData RTPS SubMessage SerializedData RTPS Header 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 • EncrypFon uses AES in counter mode © 2014 Real-­‐Time InnovaFons, Inc. – Similar to SRTP, but enhanced to support mulFple 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 criFcal to support DDS QoS like history, content filters, best-­‐efforts etc. • DSA and Diffie-­‐Hellman used for mutual authenFcaFon and secure key exchange MR# 6.5.3
  21. 21. BuilFn DDS:Auth:PKI-­‐DSA-­‐DH • Uses shared CerFficate Authority (CA) © 2014 Real-­‐Time InnovaFons, Inc. – All ParFcipants pre-­‐configured with shared-­‐CA • Performs mutual authenFcaFon between discovered parFcipants using the Digital Signature Algorithm (DSA) • Establishes a shared secret using Diffie-­‐Hellman.
  22. 22. Remote ParFcipant AuthenFcaFon ParFcipants detect each other via discovery and exchange IdenFty and Permission Tokens (Hashes) © 2014 Real-­‐Time InnovaFons, Inc.
  23. 23. Remote ParFcipant AuthenFcaFon Each ParFcipant calls validate_remote_idenFty(). ParFcipant with highest GUID returns PENDING_HANDSHAKE_REQUEST, the other PENDING_HANDSHAKE_MESSAGE © 2014 Real-­‐Time InnovaFons, Inc.
  24. 24. Remote ParFcipant AuthenFcaFon ParFcipant1 creates CHALLENGE1 = “CHALLENGE:<nonce> and sends message via ParFcipantMessageWriter with messageToken1:= {CHALLENGE1, IdenFty1, Permissions1} © 2014 Real-­‐Time InnovaFons, Inc.
  25. 25. Remote ParFcipant AuthenFcaFon ParFcipant2 validates IdenFty of ParFcipant1 against CA ParFcipant2 creates CHALLENGE2 := CHALLENGE:<nonce> ParFcipant2 sends to ParFcipant1 message with messageToken2:= { SIGN(HASH(CHALLENGE1#IdenFty1#Permissions1)), CHALLENGE2, IdenFty2, © 2014 Permissions2} Real-­‐Time InnovaFons, Inc.
  26. 26. Part1 validates IdenFty of ParFcipant2 against CA Part1 verifies SIGN(CHALLENGE1) using ParFcipant2’s PK Part1 computes a SharedSecret Part1 sends message with contents: messageToken3 := { ENCRYPT(SharedSecret), SIGN( HASH(CHALLENGE2 # IdenFty2 # Permissions2 # ENCRYPT(SharedSecret))) } 10/30/14 26 © 2014 Real-­‐Time InnovaFons, Inc. Encrypt uses Part2’s PK. Remote ParFcipant AuthenFcaFon
  27. 27. Remote ParFcipant AuthenFcaFon Part2 verifies SIGN( HASH(CHALLENGE2 #IdenFty2#Permissions2# ENCRYPT(SharedSecret))) 10/30/14 © 2012 Real-­‐Time InnovaFons, Inc. -­‐ All rights reserved 27 © 2014 Real-­‐Time InnovaFons, Inc. using Part1’s PK Part2 decrypts ENCRYPT(SharedSecret) using its own PK We have Mutual AuthenHcaHon and a SharedSecret
  28. 28. BuilFn DDS:AC:PKI SPI • Configured © 2014 Real-­‐Time InnovaFons, Inc. with: – X.509 CerFficate of shared Permissions CA – The Domain governance signed by the Permissions CA – The DomainParFcipant permissions signed by the Permissions CA • The Domain governance configures – Which topics shall be secured and how – Whether discovery is secured and how • DomainParFcipant permissions – Specifies what Domains Id can be joined by the DomainParFcipant – Specified which Topics and be Read/WriWen by the DomainParFcipant on each DomainId – Ties to the SubjectName matching the one on IdenFtyCerFficate 10/30/14 28
  29. 29. Example Domain Governance © 2014 Real-­‐Time InnovaFons, Inc.
  30. 30. ConfiguraFon possibiliFes • Are “legacy” or un-­‐idenFfied applicaFons allowed in the © 2014 Real-­‐Time InnovaFons, Inc. Domain? Yes or No. – If yes an UnauthenFcated applicaFons will: • See the “unsecured” discovery Topics • Be allowed to read/write the “unsecured” Topics • Is a parFcular Topic discovered over protected discovery? – If so it can only be seen by “authenFcated applicaFons” • Is a access parFcular Topic protected? – If so only authenFcated applicaFons with the correct permissions can read/write • Is data on a parFcular Topic protected? How? – If so data will be sent signed or encrypted+signed • Are all protocol messages signed? Encrypted? – If so only authenFcated applicaFons with right permissions will see anything
  31. 31. Example Permissions © 2014 Real-­‐Time InnovaFons, Inc.
  32. 32. Secure discovery • AddiFonal built-­‐in endpoints: – DCPSPublicaFonsSecure – DCPSSubscripFonsSecure • Same discovery topic-­‐data but encrypted & signed • OperaFon AccessControl::get_endpoint_security_attributes() controls which Topics use Secure Discovery 10/30/14 32 © 2014 Real-­‐Time InnovaFons, Inc.
  33. 33. ConfiguraFon PossibiliFes © 2014 Real-­‐Time InnovaFons, Inc. • Is the access to a parFcular Topic protected? – If so only authenFcated applicaFons with the correct permissions can read/write • Is data on a parFcular Topic protected? How? – If so data will be sent signed or encrypted+signed • Are all protocol messages signed? Encrypted? – If so only authenFcated applicaFons with right permissions will see anything
  34. 34. More Powerful Than Other Secure Middleware Technologies • Standard & Interoperable © 2014 Real-­‐Time InnovaFons, Inc. • Scalable: Supports mulFcast • Fine-­‐grain: Control Topic-­‐level aspect • Flexible: Build your own plugins • Generic: Works over any Transport • Transparent: No changes to ApplicaFon Code!
  35. 35. DDS-­‐Secure Standard Status © 2014 Real-­‐Time InnovaFons, Inc. • The specificaFon was adopted in March 2014. – Considered “Beta” for 1 year – RTI chairing the FinalizaFon Task Force • This specificaFon provides a framework for securing DDS systems. The builFn plugins provide a “common” approach for applicaFons without specialized requirements – It is expected that plugins will be developed to match more specialized deployments and integrate with exisFng infrastructure. 10/30/14 35
  36. 36. QuesFons? © 2014 Real-­‐Time InnovaFons, Inc.
  37. 37. © 2014 Real-­‐Time InnovaFons, Inc. Find out more…ƒware