# Multi-Device Security Application for Unmanned Surface and Aerial Systems
## 2 UxS MLS Implementation
### MLS Architecture  
MLS [15] supports synchronous and asynchronous communication and authentication for groups of devices. It is designed to provide authenticated encryption through the use of symmetric keys (e.g., \(Enc_{K}(data)\)) while keys are distributed using a key encapsulation method (\(KEM_{pk\_receiver}(K)\)). MLS uses standard ciphersuites for encryption and key encapsulation but employs a novel key hierarchy for management which reduces the distribution overhead. This key management approach also supports _continuous key agreement_ such that setup overhead is only incurred _once_ for the lifetime of the devices. Thus, if devices \(D_{1},\ldots,D_{n}\) are in a group, they can be tasked separately and resume group communications on a joint tasking weeks or months later without re-incurring setup overhead. Due to space considerations, a detailed breakdown of key management in MLS can be found in the specification [15].  
For practical deployment of MLS, there are two vital components of the implementation architecture: the Authentication Service and Delivery Service. Figure 1 depicts the protocol's architecture and overall functionality.  
**Authentication Service** Per the MLS Architecture RFC, the Authentication Service must provide two specific functionalities, namely \"It authenticates the credentials used in a group... and it authenticates messages sent in groups by authenticating the message signature and the sending member's credentials\" [16]. The Authentication Service is thus notably a _service functionality_ rather than a _server_. The degree of the service functionality that is on the end-user device is determined by the implementation. Furthermore, the Authentication Service might be part of a federated service or something similar.  
**Delivery Service** The Delivery Service stores and delivers initial public keys required by clients to establish a secret group key. The Delivery Service is in charge of broadcasting messages to all group members, which can have from two to thousands of clients sending and receiving information [16]. The client can be any device in the MLS architecture identified by a unique cryptographic signature. Like the Authentication Service, the Delivery Service is a service functionality versus a specific server. There are various instantiations of a Delivery Service. For example, message delivery might be managed by multiple end devices in the group to avoid a single point of failure in the architecture, and/or the group information can be saved on a separate server.  
For our use case, the MLS application is installed on two LvS and a ground station. We abstract away part of the Authentication Service functionality, specifically the authentication of credentials for the group. We assume a pre-installed credential use case, for ease of implementation; however, such use of pre-installed certificates is potentially realistic for many LvS use cases, where all group devices may be \"initialized\" with required certificates before send-off. The function of a Delivery Service is minimalistic in our test case, conducted by the user creating the MLS group, in our case, the primary LvS.