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

AOC AOC

Transitioning

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.

Objectives

• Shared Environment

– Interoperability

• Multi-level Security

– Data-Centric

• No/Short Notice or Self-

Service

– Persistent

• Rapid Elasticity

– Modular, Scalable

• Measured Service
• Shared Environment

– Interoperability

• Multi-level Security

– Data-Centric

DDS Standards

IDL 4.0 2015 DDS Security 2014 DDS Implementation

Network / TCP / UDP / IP

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

Connection Via ia The DDS Databus

Platform Platform Platform

Application 3

DDS

Application 2

DDS

Application 1

DDS

Sensor Unit Health Monitor Device Control

DDS Databus

Platform

Application 3

DDS

Operator

Different colors represent different topics

Connection Via ia The DDS Databus

Data flows are configured via ‘Quality

• f Service’ (QoS) settings that define

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

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

Data Writer Data Reader

Airline Flight Destination Time SWA 023 PDX 14:05 UA 119 LAX 14:40

Data Writer

Topic Instance Key (subject)

DDS Security

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

Secure systems need all ll four

DDS: : Data-Centric, Fin ine-Grained Security

• Per-Data-Topic Security
• Control r,w access for each function
• Ensures proper dataflow operation
• Complete Protection
• Discovery authentication
• Data-centric access control
• Cryptography
• Tagging and logging
• Non-repudiation
• Secure multicast
• 100% standards compliant

Operator

Fire

Data Topics Applications

Control Visualize Simulate

BaseEntity Detonation

Data Topic Security model:

• Simulate: Fire(r), BaseEntity(w)
• Visualize: BaseEntity(r), Detonation(w)
• Control: BaseEntity(r), Fire(w)
• Operator: *(r), Fire(w)

Plu lugg ggable Architecture

• Requires trivial or no change to

existing DDS apps and adapters

• Includes default plugins; customizable
• Runs over any transport
• Including low bandwidth, unreliable
• Does not require TCP or IP
• Multicast for scalability, low latency
• Completely decentralized
• High performance and scalability
• No single point of failure

Secure DDS Library

Authentication Access Control Encryption Data Tagging Logging

Application

Any Transport (e.g., TCP, UDP, multicast, shared memory…)

Configuring and Deploying DDS Security

Domain Governance Document Identity CA Certificate Permissions CA Certificate P2 Identity Certificate P2 Private Key

P2

P2 Permissions File P1 Identity Certificate P1 Private Key

P1

P1 Permissions File

Shared By All Participants

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

Flight Data Generation Aircraft 1

Demo Setup

Fuel Level Security Domain 0

Raspberry Pi Linux System Security Domain 0

Aircraft ID, Position Security Domain 1 Sensor Data Security Domain 1 Fuel Level Security Domain 0 Aircraft ID, Position Security Domain 2 Sensor Data Security Domain 1

Flight Data Generation Aircraft 2

Linux PC Security Domains 0 and 1

CIGI Text Data CIGI

SimBlocks.io Aircraft Display

CIGI

SimBlocks.io Aircraft Display One World SDK for Unity (DDS to CIGI Host) One World SDK for Unity (DDS to CIGI Host)

Single World Displaying Both Aircraft with different data available based on Authentication and Role Based Access Control

One World Terrain

Low Security Level Medium Security Level High Security Level

Linux PC Security Domain 0, 1, and 2

Connext DDS Databus

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

Flight Data Generation Aircraft 1

Demo Setup

Fuel Level Security Domain 0

Raspberry Pi Linux System Security Domain 0

Aircraft ID, Position Security Domain 1 Sensor Data Security Domain 1 Fuel Level Security Domain 0 Aircraft ID, Position Security Domain 2 Sensor Data Security Domain 1

Flight Data Generation Aircraft 2

Linux PC Security Domains 0 and 1

CIGI Text Data CIGI

SimBlocks.io Aircraft Display

CIGI

SimBlocks.io Aircraft Display One World SDK for Unity (DDS to CIGI Host) One World SDK for Unity (DDS to CIGI Host)

Single World Displaying Both Aircraft with different data available based on Authentication and Role Based Access Control

One World Terrain

Low Security Level Medium Security Level High Security Level

Linux PC Security Domain 0, 1, and 2

Connext DDS Databus

Network Configuration

Network Switch

Wireshark

AFSIM

SimBlocks.io Flight Sim Display SimBlocks.io Flight Sim Display Fuel Level Display

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

Free trial of Connext DDS

@rti_software @rti_software rtisoftware rti.com/blog connextpodcast