Distributed Data Service for Secure Cloud Simulations Sonia R. von - PowerPoint PPT Presentation

Distributed Data Service for Secure Cloud Simulations Sonia R. von der Lippe, M&S Systems Engineer, HII-TSD, Orlando, FL Andre Odermatt, Technical Marketing Manager, Real-Time Innovations, Sunnyvale, USA

Operation Training In Infrastructure (O (OTI) I) Vis isio ion Realistic integrated training environment that allows our forces to train in an operationally and tactically relevant employment scheme to achieve and sustain full-spectrum readiness. AOC AOC Transitioning

Objectives • Shared Environment • Shared Environment – Interoperability – Interoperability • Multi-level Security • Multi-level Security – Data-Centric – Data-Centric • No/Short Notice or Self- Service – Persistent • Rapid Elasticity – Modular, Scalable • Measured Service

DDS Standards 2014 2015 2012 OPC-UA to DDS IDL 4.0 DDS Application 2016 Gateway Security Instrumentation 2013 DDS-WEB 2017 DDS-XRCE 2010 RPC over DDS App 2015 DDS X-Types DDS-API-C++ 2012 Approved DDS-API-JAVA 2004 In progress DDS Spec DDS DDSI-RTPS-TCP 2016 Implementation DDS-RTPS 2.2 2006 DDS-RTPS 2.3 2019 Wire Protocol Wire Protocol (Interoperability) Network / TCP / UDP / IP

Connection Via ia The DDS Databus Sensor Unit Health Monitor Device Control Operator Application 1 Application 2 Application 3 Application 3 DDS DDS DDS DDS Platform Platform Platform Platform DDS Databus Different colors represent different topics

Connection Via ia The DDS Databus A Data Model (written in IDL) describes the Data is cached at endpoints by DDS data in the system and allows DDS to (based on the QoS settings); the ‘understand’ and manage data in the system application always has the data it appropriately. requires when it requires it. Topic and role based security Data flows are configured via ‘ Quality of Service’ (QoS) settings that define DDS abstracts the application how data is delivered between nodes away from the Operating in the distributed system. In DDS System making the application terminology these data flows are DDS optimizes network usage by less complex, more portable called Topics. filtering data appropriately (at either and transport agnostic. source or destination) and only delivering data when and where it is needed.

DDS Terminology “Global Data Space” generalizes Subject -Based Addressing  Data objects addressed by Domain ID, Topic and Key  Domains provide a level of isolation  Topic groups homogeneous subjects (same data-type and meaning)  Key is a generalization of subject Topic Data Writer Data Reader Key (subject) Airline Flight Destination Time SWA 023 PDX 14:05 Instance Data Writer UA 119 LAX 14:40

Practical Security Needs Many Layers • System edge • Host  Machine/OS/Applications/Files • Network transport  Media access (layer 2)  Network (layer 3)  Session/Endpoint (layer 4/5) • Dataflow  Control application interaction DDS Security Secure systems need all ll four

DDS: : Data-Centric, Fin ine-Grained Security Simulate Visualize Control Operator Applications • Per-Data-Topic Security  Control r,w access for each function  Ensures proper dataflow operation • Complete Protection Data Topics  Discovery authentication  Data-centric access control BaseEntity Detonation Fire  Cryptography Data Topic Security model:  Tagging and logging Simulate: Fire(r), BaseEntity(w) •  Non-repudiation • Visualize: BaseEntity(r), Detonation(w) Control: BaseEntity(r), Fire(w) •  Secure multicast • Operator: *(r), Fire(w)  100% standards compliant

Plu lugg ggable Architecture • Requires trivial or no change to Application existing DDS apps and adapters • Includes default plugins; customizable Authentication Access Control • Runs over any transport Encryption Secure DDS Library  Including low bandwidth, unreliable Logging  Does not require TCP or IP Data Tagging  Multicast for scalability, low latency Any Transport • Completely decentralized (e.g., TCP, UDP, multicast, shared memory … )  High performance and scalability  No single point of failure

Configuring and Deploying DDS Security Permissions Domain Identity CA Governance CA Shared By All Participants Certificate Certificate Document P2 Permissions P1 Permissions File P2 Identity File Certificate P1 Identity Certificate P2 P1 P2 Private Key P1 Private Key

Demo Objectives • Demonstrate a cloud environment producing aircraft simulation data at different security pseudo -security levels • Aircraft data is generated via a fielded simulation framework, AFSIM • Connext DDS Secure publishes aircraft data to multiple subscribers • Each subscriber is given different security permissions

Demo Operational Overv rview • Publisher writes pre-generated aircraft data including fuel, sensor, identification, and location data • Flight data from two aircraft will be published • Aircraft data published at three classification levels • Three displays: – Simple display to present with access to the lowest classification level – Simblocks.io-based display with access to the lowest and middle classification level – Simblocks.io-based display with access to all classification levels

Demo Setup Flight Data Generation CIGI Raspberry Pi Text Data Fuel Level Linux System Security Domain 0 One World Terrain Security Domain 0 Sensor Data Connext DDS Databus Security Domain 1 Aircraft ID, Position SimBlocks.io CIGI Aircraft Display Security Domain 1 Linux PC Security Domains One World SDK for Unity Aircraft 1 0 and 1 (DDS to CIGI Host) Flight Data Generation Fuel Level Single World Displaying SimBlocks.io CIGI Security Domain 0 Aircraft Display Both Aircraft with different Linux PC data available based on Security Domain Sensor Data One World SDK for Unity 0, 1, and 2 Authentication and Role Security Domain 1 (DDS to CIGI Host) Based Access Control Aircraft ID, Position Security Domain 2 Low Security Level Medium Security Level Aircraft 2 High Security Level

Security Requirements • Participant Authentication • Access control • Encryption

Cla lassification Overview • 3 pseudo -classification levels: – Green • Fuel information from each plane – Blue • Position and sensor information from plane 1 • Sensor information from plane 2 – Red • Position of plane 2

Security Governance • Authorization to publish or subscribe to a topic enforced by a ”permissions” file signed by a common CA • Privacy and message authentication is provided by encryption to the blue and red security domains • Participant authentication enforced across all security domains • Access controls applied to the blue and red security domains • Message Authentication Code (MAC) applied to all security domains

Demo Setup Flight Data Generation CIGI Raspberry Pi Text Data Fuel Level Linux System Security Domain 0 One World Terrain Security Domain 0 Sensor Data Connext DDS Databus Security Domain 1 Aircraft ID, Position SimBlocks.io CIGI Aircraft Display Security Domain 1 Linux PC Security Domains One World SDK for Unity Aircraft 1 0 and 1 (DDS to CIGI Host) Flight Data Generation Fuel Level Single World Displaying SimBlocks.io CIGI Security Domain 0 Aircraft Display Both Aircraft with different Linux PC data available based on Security Domain Sensor Data One World SDK for Unity 0, 1, and 2 Authentication and Role Security Domain 1 (DDS to CIGI Host) Based Access Control Aircraft ID, Position Security Domain 2 Low Security Level Medium Security Level Aircraft 2 High Security Level

Network Configuration Fuel Level Display Network Switch SimBlocks.io Flight Sim Display AFSIM SimBlocks.io Flight Sim Display Wireshark

Future Development / Next xt steps • Data model extension • Origin Authentication • Configuration of the Security Policies • Evaluate Security Requirements • Support for bi-direction flow of simulation data • Performance Testing and Improvements

Questions?

Stay Connected With RTI rti.com rtisoftware Free trial of Connext DDS connextpodcast @rti_software rti.com/blog @rti_software