ROSCon 2018

libddssec
Adding secure security to ROS2•
© 2018 Arm Limited

Filipe Rinaldi - filipe.rinaldi@arm.com• September 2018

Introduction
About us:
Members of the Arm Open Source Software group. Part of a new team (a revamp ofthe Robotics team) with focus on the automotive area:• Filipe Rinaldi (myself)• Florian Depraz (present at ROSCon)• Louis Mayencourt (present at ROSCon)• Kurtis Charnock

Todays presentation:
Overview of a new project called libddssec: A library that implements the security
portion of a DDS implementation using Arm TrustZone (Cortex-A profile) [1].

2

© 2018 Arm Limited

Agenda:• Key concepts• DDS Nodes• DDS Security• Arm TrustZone• The libddssec project• Overview• The current work
• Main challenges• Future work

• Why securing DDS/ROS2?
• References3© 2018 Arm Limited

Key Concepts
DDS© 2018 Arm Limited

DDS: Nodes

Publisher

Topic X

Subscriber

Node A

Publisher
Node C5© 2018 Arm Limited

Node BDDS: Specs (cont.)
There is a collection of specifications [2] around the DDS split into different groups: Core,Extensions, Gateways and API).
This presentation focus on:• DDSI-RTPS protocol v2.2 [core]: low-level interoperability wire protocol• DDS v1.4 [core]: Data centric Push/Sub model• DDS-Security v1.1 [extension]: Security model and plugin interface

6© 2018 Arm Limited

DDS: Security Model
The DDS security model defines the users of the system, the objects that are being
secured and the operations that are to be restricted.
• Securing DDS means providing:• Confidentiality of the data samples• Integrity of the data samples and the messages that contain them
• Authentication of DDS writers and readers• Authorization of DDS writers and readers• Message/Data origin authentication• Non-repudiation of data

7

© 2018 Arm Limited

DDS: Security - Threat Model
Specification details four categories of threats:• Unauthorized subscription• Unauthorized publication• Tampering and replay• Unauthorized access to data

8

© 2018 Arm Limited

DDS Security: Implementation
The DDS Security specification defines plugins to implement• Authentication• Certificate management• Cryptography• Crypto operations• Access control• Policy enforcement9© 2018 Arm Limited

DDS Security: Implementation (cont.)• Asymmetric key cryptography used mainly for discovery, authentication and sharedsecret establishment phase.
• The use of cyphers, HMAC, or digital signatures is selectable on a per stream (Topic)
basis.

10© 2018 Arm Limited

Key Concepts
What is Arm TrustZone?

© 2018 Arm Limited

What is Arm TrustZone?
• Provides a second virtual world allowing a different software stack to co-exist• Physical address space is partitioned between these two worlds• Orthogonal to the Exception/Privilege Levels

12© 2018 Arm Limited

What is TrustZone? (cont.)• It is all about who you trustAppOS13© 2018 Arm Limited

What is TrustZone? (cont.)

AppAppOS

OSHypervisor

14© 2018 Arm Limited

What is TrustZone? (cont.)
Non-Secure

SecureEL0AppApp

Trusted App

EL1

OS

OS

Trusted OSHypervisor

EL2
EL315

Secure Monitor© 2018 Arm Limited

What is TrustZone? (cont.)
Non-Secure

Secure

EL0

App

App

Trusted App

EL1OSOSOPTEE-OS

Hypervisor

EL2
EL3

16

Trusted Firmware A© 2018 Arm Limited

The libddssec© 2018 Arm Limited

The libddssec: Goals• Move all security assets into the Trusted Execution Environment (TEE)• Certificates• Key generation• Security operations• Limit attacks• E.g. No key leakage• Provide a reference implementation on how to take advantage of the TrustZone IP tosecure DDS (using OPTEE).

18© 2018 Arm Limited

The libddssec: Overview
The DDS implementations we came across use OpenSSL for the security support:
DDS Implementation
Auth

AccessCryptoOpenSSL• Certificates in filesystem• Operations in non-secure world

19© 2018 Arm Limited

The libddssec: Overview (cont.)
Non-secure world

Secure world

Move security operations into a TEE
DDS Implementation
AuthAccess

CryptoDDS-Sec TA

Generic low-level Security API

OPTEE-OSTEE-backend
OpenSSLOPTEE-Client20© 2018 Arm Limited

TF-A

The libddssec: Overview (cont.)
Non-secure world

Secure world

Isolate code into its own projectDDS Implementation
Auth

Accesslibddssec

libddssec API
TEE-backend

DDS-Sec TA

CryptoOPTEE-OS

OpenSSL-backend
OpenSSLOPTEE-Client21© 2018 Arm Limited

TF-A

The libddssec: Overview (cont.)
Non-secure world

Secure world

Under discussion: Implement plugins in the library
DDS Implementation
Auth

AccessCryptoAuth

AccessCryptolibddssec API
TEE-backend

DDS-Sec TA

libddssec

OPTEE-OS

OpenSSL-backend
OpenSSLOPTEE-Client22© 2018 Arm Limited

TF-A

The libddssec: Current work
• Moving code from the prototype into the standalone library:• Reviewing prototype API whilst moving code into the new library• Adding unit tests instead of relying only on Fast-RTPS’s tests• Threat model• Ensure prototype design is sound• Ensure key deployment is safe

• Ensure Non-secure interface is safe (or at least limit attacks)• Investigating the new x.509 support in OPTEE 3.2• Current base code still uses OpenSSL for some of the operations, including handling of certificates23© 2018 Arm Limited

The libddssec: Main challenges• Latency:• One of the main trade-offs when using TEE will be the extra latency• Apex.ai recently released a benchmark tool to measure latency in DDS implementations that can be useful on

this area.

• Vulnerabilities in the non-secure world could allow the secure assets to be used bypotential attackers• Key and certificate deployment24© 2018 Arm Limited

The libddssec: Future work
Further areas that can be explored:• Key and certificate deployment• Ideally using hardware ID to derive keys

• As far as we are aware, OPTEE (or GlobalPlatforms) has no API for deriving keys using hardware ID (yet)• Evaluate the possibility of running “DDS Trusted Applications”• In other words, move a whole DDS application into the TEE• This means having a DDS layer in the TEE other sorts of complications• ARMv8-M Support (microcontrollers)• Retarget OPTEE and Trusted application to use Trusted-Firmware-M• Both using MBedTLS

25© 2018 Arm Limited

The libddssec• Under development and soon to be available in Github under the ARM-Softwareumbrella• License: BSD (provisional)• Language: C, C++• Development using standard-ish ArmPlatforms [4] stack:• Base AEMv8-A Base Platform FVP• Linaro’s kernel-latest• OpenEmbedded• OPTEE (currently manually enabled)

26© 2018 Arm Limited

Why are we doing this?
• DDS being adopted in mission critical applications• These usually have associated security requirements as well

• Increased adoption on the automotive area:• Autosar consortium [5] is adopting DDS in its specifications (Adaptive)• Baidu’s Apollo [3] uses ROS1 and is moving to another solution based on DDS• Autoware [6] currently ROS1 but planning to add support for ROS2

• We are aware of other automotive frameworks based on ROS2 project.

27© 2018 Arm Limited

Thank YouDankeMerci

GraciasKiitos감사합니다ध"यवाद‫תודה‬28© 2018 Arm Limited

References[1] https://www.arm.com/why-arm/technologies/trustzone-for-cortex-a[2] http://portals.omg.org/dds/omg-dds-standard[3] http://apollo.auto/[4] https://community.arm.com/dev-platforms/w/docs[5] https://www.autosar.org/[6] https://autoware.ai/[7] https://github.com/ApexAI/performance_test

29© 2018 Arm Limited

The Arm trademarks featured in this presentation are registered trademarks ortrademarks of Arm Limited (or its subsidiaries) in the US and/or elsewhere. All rights
reserved. All other marks featured may be trademarks of their respective owners.
www.arm.com/company/policies/trademarks

30© 2018 Arm Limited