WP5-16-AIT

Cryptographic algorithms adapted for drones

Identifier	WP5-16-AIT
Contributor	AIT
License	Functional
TRL	4
Description	This component represents a collection of cryptographic primitives and protocols whose characteristics are tailored to the use within drone environments (resource consumption, latency). In particular, the cryptographic protocols while providing means to satisfy low latency requirements will at the same time provide strong security guarantees (like full forward secrecy). Another important focus will be to provide long-term security and in particular resilience to quantum computers, i.e., post-quantum security, and privacy protection of the entities involved in a communication.
Key Enabling Technology	KET: Security — CATEGORY: U-Space Capabilities, KET: Network Centric Communications Systems — CATEGORY: System Functions
U-Space Capabilities	“U1: Communication, navigation and surveillance” and “U3: U-space Advanced Services”. This component can be integrated and used by drone manufacturers for general remote communication, as well as V2I and V2V communications, since in the communication-layer the component is located below the standardized and commonly used “TLS” communication layer.
System Functions	“Communication / Network Centric Communications”: The SW-component provides functionality for secure channel establishment to protect the confidentiality and integrity of messages between two communicating entities by means of a key exchange mechanism with strong security and privacy features. Moreover, with respect to entity authentication it enables unilateral or mutual authentication of communication partners within the secure channel establishment and additionally provides a means for privacy-friendly entity authentication.
CD4 objectives (O), success criteria (SC), and measurable outcomes (MO)	O3 / SC3.1: Reduction of cybersecurity risks of drone-to-x communications, MO3.3: Mechanisms for secure communications
Improvement	State-of-the-art cryptographic protocols do not provide low latency as well as strong security properties such as full forward secrecy at the same time. Currently, available protocols are no means to support privacy-friendly authentication. Moreover, they lack security in the face of powerful quantum computers. All these aspects are considered within this component, improving significantly over the state-of-the-art.
Task	T5.3
Use Case	UC5 — Agriculture
Demonstrator	D2 — Wine production
Contact	Otto.Brechelmacher at ait.ac.at

Architecture context and interfaces

The AIT component does not represent a stand-alone module but can be viewed as being located within the “VehicleCom” and “GroundCom” modules, i.e., the modules in charge of the communication between vehicles or between vehicles and the ground station and adds security features to the communication (confidentiality, authenticity, privacy).

Architecture context of the component WP5-16-AIT

The component can be viewed as a collection of libraries implementing protocols (e.g., secure channel establishment with strong security or privacy-friendly entity authentication) and typically replaces or augments other existing cryptographic primitives (e.g., basic mechanisms in the transport layer security (TLS) protocol). It runs on the Vehicle (VehicleCom), where it is intended to be used together with the “Secure Element” (SE) module to provide stronger security features (i.e., realize secret key operations within the SE). It also runs on the GroundStation and in combination it is possible for the Vehicle and the GroundStation to establish a secure communication (confidential and authenticated).

The core features our component was focusing on can be summarized as follows:

(Low-latency) Key-exchange protocols: Our key-exchange protocols to achieve low latency (zero round-trip time, 0-RTT) together with strong security properties are built upon so called puncturable encryption schemes (or key encapsulation mechanisms).

Privacy-preserving authentication: Depending on the required degree of privacy (only with respect to eavesdroppers or even communication partners like the base station), we focused on protocols either obtained from anonymous (authenticated) key-exchange protocols or primitives underlying anonymous attribute-based credentials or group signature schemes.

Internals and technologies

For the implementation of our component, we require a few external libraries:

A pairing implementation, for which we rely on the popular and highly optimized open-source pairing library RELIC6. This choice is done for multiple reasons: (1) it includes implementation of currently recommended pairing-friendly curves such as BLS12-381, (2) includes optimizations for desktop and server CPUs as well as embedded CPUs such as ARM and AVR processors, and (3) allows to configure memory handling suitable for the target platform.

The pyrelic library7 which provides Python bindings for the popular and highly optimized open-source pairing library RELIC.

OpenSSL8, as one of the most used libraries for TLS which also provides TLS 1.3 support.

Our library that implements the secure channel establishment has finally been integrated into OpenSSL and our library for privacy-preserving authentication has been integrated into the pyrelic library. More details can be found in Deliverables D5.5 and D5.6.

As our evaluation platform we use a Raspberry Pi 3 Model B powered by a quad-core ARM Cortex-A53 1200 MHz processor and has 1 GB SDRAM.