Acta Astronautica 149 (2018) 61–76

Contents lists available at ScienceDirect

Acta Astronautica
journal homepage: www.elsevier.com/locate/actaastro

Data authentication, integrity and confidentiality mechanisms for federated T

satellite systems
Olga von Maurich∗, Alessandro Golkar
Skolkovo Institute of Science and Technology, Skolkovo Innovation Center, Building 3, Moscow, 143026, Russia

A R T I C LE I N FO A B S T R A C T

Keywords: This work addresses a critical topic in federated satellites development: the lack of trust between stakeholders
Federated satellite systems (FSS) that would prevent any stakeholder joining a satellite federation owned and operated by multiple parties. A
Distributed satellite systems characterisation of security needs for federated satellite systems is proposed, showing that in order for a fed-
Public key infrastructure (PKI) eration to offer an environment for a beneficial cooperation, a notion of identity, both user identity and data
Digital signatures
authentication, has to be introduced, and stakeholders' security requirements have to be satisfied. This paper
Hybrid encryption
presents a public key infrastructure (PKI) based protocol for addressing stakeholders' security requirements and
ensuring data authentication, integrity and confidentiality in data transfer operations within satellite federa-
tions. The performance and cost overheads of the proposed security protocol are first characterised with an
experimental implementation on a Raspberry Pi 2 platform, used as a representative proxy testbed of commercial
off-the-shelf avionics for small satellites, and then with a benchmark on a range of CPUs to analyse which
platforms achieve set performance goals with radio-based and laser-based communications. Recommendations
for implementing security mechanisms in federated satellite systems are thus derived.

1. Introduction service will be executed correctly.

Security is a critical topic in federated satellites development: the
lack of trust between stakeholders would prevent any stakeholder
joining a satellite federation owned and operated by multiple parties
and providing access to her spacecraft. Federated Satellite Systems
(FSS) [1] are a ”sharing economy” approach to space systems that aims
to enable distribution of unused capacity among spacecraft by bringing
spacecraft into a peer-to-peer (P2P) network and enabling an exchange
of resources among spacecraft [2]. The aim of federated satellite sys-
tems (FSS) [2] is to provide a beneficial cooperation, which directly
depends on the number of participating stakeholders. The more parti-
cipants join the system, the more applications and a more beneficial
cooperation federated satellite systems could offer. Keeping spacecraft
interested in joining a satellite federation is therefore of crucial im-
portance for federated satellite systems.
Federated satellite systems enable a large number of applications,
where spacecraft’ operators decide to collaborate with each other if
they find the collaboration beneficial and secure. Security in federated
satellite systems is motivated by the desired security requirements of
the operators of federated satellite systems' spacecraft: the operators
need to be able to verify identity of each other before engaging in a
cooperation and have guarantees, that if they pay for a service, the
To offer an environment for a beneficial cooperation, federated
satellite systems have to respond to federated satellite systems' security
requirements and provide security guarantees. The work in this paper
investigates how notions of identity, data authentication, integrity and
confidentiality could respond to federated satellite systems' security
requirements. This work is conducted in the framework of the ONION
″Operational Network of Individual Observation Nodes” project sup-
ported by the European Union's Horizon 2020 research and innovation
programme. The goal of ONION is to propose a pragmatic, evolutionary
and scalable approach, hybridising fractionated and federated satellite
system concepts, and augmenting existing space assets for the devel-
opment of future space missions and new services. Data security within
opportunistic intersatellite operations is one of the fundamental chal-
lenges to enable innovative distributed satellite system concepts, as the
absence of security guarantees between stakeholders would hinder the
prospect of future satellite federations owned and operated by multiple
parties, as the conducted security need analysis and identified security
problems in Section 3.1 and Section 3.2 will show. This paper provides
extended results that address not only to the goals of the ONION pro-
ject, but also aim development of security mechanisms in generic
spacecraft operations (not limited to Earth Observation).
The research objectives of the paper are to identify and apply

∗
Corresponding author.
E-mail addresses: olga.korobova@skolkovotech.ru (O. von Maurich), a.golkar@skoltech.ru (A. Golkar).

https://doi.org/10.1016/j.actaastro.2018.05.003
Received 25 January 2017; Received in revised form 3 November 2017; Accepted 2 May 2018
Available online 10 May 2018
0094-5765/ © 2018 IAA. Published by Elsevier Ltd. All rights reserved.
O. von Maurich, A. Golkar
suitable security mechanisms to regulate opportunistic intersatellite
operations in federated satellite systems. The focus of the paper is on
the space segment only, in particular satellite-to-satellite operations.
More specifically, this work unfolds into five research objectives:
(i) to identify data security problems in federated satellite systems'
operations and federated satellite systems' needs for authentica-
tion, integrity and confidentiality;
(ii) to identify security mechanisms that are suitable for federated
satellite systems' operations, i.e., security mechanisms that address
formulated security requirements and account for the constraints
introduced by opportunistic intersatellite operations, i.e., a com-
putational constraint (accounting for the computational constraint
is illustrated throughout the Implementation Section 4.1);
(iii) to provide a security protocol to regulate secure data transactions
in federated satellite systems' operations;
(iv) to characterise the performance of the security protocol on a
CubeSAT candidate testbed of commercial off-the-shelf avionics for
small satellites and a wider range of more powerful CPUs; and
(v) to provide recommendations for developing security mechanisms
for opportunistic intersatellite operations in federated satellite
systems in the Earth Observation domain, as a representative use
case.
The remainder of this paper is structured as follows. Section 2
proposes a literature review discussing related work, including security
research in satellite systems and the Copernicus Security Framework
[3] in the Earth Observation domain. Section 3 describes the approach
of this work: first, a stakeholder need analysis and a security problem
discussion is conducted to identify satellite systems' stakeholders' se-
curity requirements for opportunistic intersatellite operations; then a
security protocol for data relay addressing these requirements is for-
mulated. Section 4 discusses security guarantees and presents an ex-
perimental characterisation of the computational and network over-
head on a range of commercial platforms benchmarking results with
performance data using the ECRYPT Benchmarking of Cryptographic
Systems. Performance goals of the proposed protocol and platforms that
achieve this goal are discussed. Section 5 provides the summary of the
paper, lists limitations, states the contribution and discusses future
work.
2. Literature review
This section presents an overview of security research in satellite
systems and the Copernicus Security Framework (CSF) [3]. CSF is taken
as a representative security policy for existing satellite systems, as ap-
plied to Earth Observation satellites. The framework addresses the
ground segment security aspects only - therefore, the CSF framework
will not be able to respond to all federated satellite systems' security
requirements and regulate opportunistic intersatellite operations within
federated satellite systems.
2.1. Security research in satellite systems
A thorough survey of the security and related issues in satellite
systems, with both military and commercial destination of use, is dis-
cussed in Ref. [4]. The authors discuss authenticated key-exchange
(AKE) protocols that could establish secure channels between space-
craft, explain why Internet Protocol Security (IPsec) [5], Transport
Layer Security (TLS) [6], Transmission Control Protocol (TCP) [7] cause
performance degradation when applied to satellite networks and list
research directions (e.g., selective retransmission with User Datagram
Protocol (UDP)) [8] towards the protocols' performance optimisation
[4]. Distributed Denial of Service Attacks (DDOS) [9], its classification
and detection, is discussed as one of the most harmful attacks in sa-
tellite communication networks; furthermore, an overview of the
62
Acta Astronautica 149 (2018) 61–76
command link protection system deployed by the American Satellite
Company (ASC) is given [4].
Security of satellite networks has mainly been researched in relation
to mobile satellite communication and focused on efficient authenti-
cation, encryption and key update mechanisms, as discussed in Refs.
[10] [11], and [12]. As mobile satellite communication systems provide
real-time services, any additional time delay is critical for the systems'
performance. The above work has been concentrated on minimising the
computation overhead caused by the public key infrastructure (PKI)
(PKI is introduced in Section 3.4.1).
Security parameters as fault management [13] [14] and multi-level
security across applications [15] [13] [14] have defined a novel set of
capabilities of fractionated spacecraft and spacecraft clusters. The dis-
tinctive and innovative characteristics of software platforms for dis-
tributed spacecraft are spatial and temporal isolation between missions
and shared resources approached by running applications in isolated
partitions [14] [16], fault isolation among applications [17], data iso-
lation between different stakeholders based on security label checking
and constrained information flow [14] [18].
Fault tolerant models and hardware implementations of crypto-
graphic algorithms are other directions towards recovering spacecraft
from failures and targeted attacks. Developing cryptographic primitives
for a harsh space environment is challenging due to an increasing
probability of single event upsets (SEUs). The PhD dissertation of
Marcio Juliato [19] addresses fault tolerant cryptographic primitives
for on-board security in spacecraft (i.e. SEUs-recovery techniques [20],
SEU-resistant SHA-256 design [20]); a fault-tolerant model of AES was
introduced by Ref. [21]; an SEUs-resistant FPGA-based implementation
of the substitution transformation in AES was published by Ref. [22].
An example of an operational security framework that addresses
unclassified satellite information security from its acquisition and sto-
rage to elaboration and distribution to the users is the Copernicus
Security Framework [3] developed and deployed by the European
Space Agency (ESA) to mitigate security risks within the Copernicus
programme based on a threat assessment and Copernicus regulations
[23] [3]. The focus of the framework is on the information security and
access control: data integrity and availability and special data con-
fidentiality are fundamental for services like emergency management or
security surveillance.
The Copernicus Security Framework states data security as funda-
mental to many satellite systems' services. Currently the CSF framework
addresses the ground segment security only, which motivates us to
propose a security protocol for intersatellite operations within feder-
ated satellite systems.
3. Approach
This section describes the approach proposed in this paper. The
approach is two-phased: first, a stakeholder analysis is conducted on a
representative case of satellite operations to identify typical security
needs; then a security protocol for data relay addressing such needs for
federated satellite systems is formulated.
3.1. Federated satellite systems stakeholder need analysis
The stakeholder need analysis for federated satellite systems is
prototyped and based on the stakeholder need analysis of the
Copernicus Earth Observation system and extended to address the
network's and stakeholders' specifics of federated satellite systems. The
Copernicus Earth Observation system serves a representative use case:
(i) Earth observation is among the most beneficial potential applica-
tions of federated satellite systems; and (ii) being under deployment at
the time of writing of this paper, the Copernicus programme is re-
presentative of the needs of present and future Earth Observation
missions, which are seen as promising customer candidates of federated
satellite systems' services [1].
O. von Maurich, A. Golkar Acta Astronautica 149 (2018) 61–76

Table 1
Security requirements to Copernicus data.
Category Requirement Source

Data Authentication 2. In order to attain the general objectives set out in paragraph 1, Copernicus shall have the following REGULATION (EU) No 377/2014 Article 4
specific objectives: a) delivering accurate and reliable data and information to Copernicus users […].
Data Integrity 2. In order to attain the general objectives set out in paragraph 1, Copernicus shall have the following REGULATION (EU) No 377/2014 Article 4
specific objectives: a) delivering accurate and reliable data and information to Copernicus users […].
Data Confidentiality (12) The Commission should apply restrictions on the GMES open dissemination, where the free, full REGULATION (EU) No 1159/2013
and open access to some GMES dedicated data and GMES service information would affect the rights
and principles enshrined in the Charter of Fundamental Rights of the EU such as the right for private
life privacy, the protection of personal data or intellectual property rights on data used as inputs in the
production process of GMES services.
(13) Where necessary, restrictions should protect the security interests of the Union, as well as the REGULATION (EU) No 1159/2013
national security interests of the Member States. […]
1. Where the open dissemination of GMES dedicated data and GMES service information presents an REGULATION (EU) No 1159/2013
unacceptable degree of risk to the security interests of the Union or its Member States due to the Chapter 3, Article 12
sensitivity of the data and information, the Commission shall restrict their dissemination pursuant to
Article 13(1) of Regulation (EU) No 911/2010.
Stakeholder Authentication (17) […] Fourthly, a strict registration procedure should be used to address the need to restrict access REGULATION (EU) No 1159/2013
for security reasons requiring the unequivocal identification of the user.
2. The users for whom access is reserved […] shall register in order to gain access, providing their REGULATION (EU) No 1159/2013
identity, contact information, area of activity and country of establishment. Chapter 4, Article 17
Authorisation (12) The Commission should apply restrictions on the GMES open dissemination, where the free, full REGULATION (EU) No 1159/2013
and open access to some GMES dedicated data and GMES service information would affect the rights
and principles enshrined in the Charter of Fundamental Rights of the EU such as the right for private
life privacy, the protection of personal data or intellectual property rights on data used as inputs in the
production process of GMES services.
(17) […] Fourthly, a strict registration procedure should be used to address the need to restrict access REGULATION (EU) No 1159/2013
for security reasons requiring the unequivocal identification of the user.
1. Where the open dissemination of GMES dedicated data and GMES service information presents an REGULATION (EU) No 1159/2013
unacceptable degree of risk to the security interests of the Union or its Member States due to the Chapter 3, Article 12
sensitivity of the data and information, the Commission shall restrict their dissemination pursuant to
Article 13(1) of Regulation (EU) No 911/2010.

Copernicus stakeholders. Copernicus consists of the three components
[24]: (i) a space observation component; (ii) an in-situ observation
component; and (iii) a service component that delivers observation data
to users [24]. The Copernicus Space Component (CSC) consists of a
constellation of dedicated missions, the Sentinels, and of contributing
missions [25]. As of 2015 over 60 national and commercial space
missions provided geospatial data to the Copernicus users [25]. The
Copernicus in-situ component is based on the infrastructure that is
owned and operated by a large number of national, European, inter-
national and private stakeholders [26]. Copernicus user categories and
ground-based stakeholders are listed in Ref. [25].
Copernicus security needs and requirements. The Copernicus pro-
gramme advertises free of charge services and data and a direct access
to satellite data. However, limitations exist. Regulations of the
European Parliament and of the Council list the following limitations to
the ”full, open and free-of-charge” access among which are ”licensing
conditions for third party data” and ”ensuring reliable access to Copernicus
data and Copernicus information for European users” [24].
Table 1 presents security requirements to Copernicus data outlined
in regulations [27] and [24]. By organising these requirements into
categories such as data authentication, data integrity, data con-
fidentiality, stakeholder authentication and authorisation, and gen-
eralising these requirements, Copernicus stakeholder needs and re-
quirements are summarised in Table 2. This generalised formulation of
Copernicus stakeholder needs will later serve as basis for the derivation
of the federated satellite systems' security needs.
Deducted security needs and requirements for federated satellite systems.
The Copernicus system and federated satellite systems differ sig-
nificantly in their network and stakeholder topology. Copernicus is a
system owned by the two main stakeholders, European Commission
(EC) and European Space Agency (ESA); federated satellite systems are
owned by a variety of heterogeneous stakeholders. Copernicus space-
based stakeholders are isolated spacecraft operators, who communicate
only with a trusted ground segment; the stakeholders of federated sa-
tellite systems communicate with each other, untrusted federated
satellites network participants. The satellite network structure of
Copernicus and federated satellite systems also differs: unlike the
Copernicus network a federated satellite systems' network is a P2P
network and has therefore no central authority. These significant dif-
ferences and new services that federated satellite systems introduce, in
particular data relay (Section 3.2), introduce new security needs and
requirements of the federated satellite systems' stakeholders.
Table 3 proposes the formulation of security needs of federated
satellite systems' stakeholders. The FSS data security needs and re-
quirements have been deducted by the analysis by analogy, where the
Copernicus stakeholder security needs and requirements were taken as
a basis and extended to account for a federated satellite systems' dif-
ferent network structure and new applications, i.e., opportunistic in-
tersatellite operations.
3.2. Security problems in federated satellite systems
The section introduces the security problems identified in the op-
erations of federated satellite systems.
Data relay: concept of operations. With respect to traditional ”stove-
piped” systems (satellites communicated to their dedicated ground
stations only), opportunistic data relay allows federated satellite sys-
tems' participants to send either a higher amount of data to a ground
station, or data with a lower latency, or a weighted combination of both
(depending on the willingness to pay for the service), by relaying data
through federated satellite systems' participants.
Data relay within federated satellite systems is based on myopic
network knowledge [28]. Federated satellite systems' participants dis-
cover the federated satellite systems' network through “hello” messages
that available spacecraft-participants constantly (in intervals) transmit
to the neighboring spacecraft [28]. The “hello” messages contain the
Network State Knowledge Matrix (NSKM) where the availability of
federated satellite systems' participants is stated [28]. This paper as-
sumes NSKM-led federated satellite systems' network operation, but it is
not the only possible approach of how a federated satellite systems'

63
O. von Maurich, A. Golkar Acta Astronautica 149 (2018) 61–76

Table 2
Copernicus stakeholder data security needs and requirements.
Stakeholder Type

Space Mission Operators and in-situ Stakeholders Copernicus User Stakeholders

(stakeholders who generate data) (stakeholders who access data)

Security Needs for Access restriction to the generated data through data encryption.
Access restriction to the generated data through authorisation procedures.
Copernicus data Stakeholder authentication, i.e., stakeholder identity verification for
authorisation procedures.
Verification of whether the generated data was delivered to the ground
segment correctly and in full.
Verification of whether the received Copernicus data is authentic.
Access restriction to the generated data through authorisation procedures
(Copernicus Services).
User authentication, i.e., user identity verification for authorisation
procedures (Copernicus Services).

network could operate.
The data relay path is calculated at each hop based on the custo-
mer's objective function F and a local Network State Knowledge Matrix
(NSKM): the decision about the next best hop is determined by the path
that minimizes the customer's objective function based on the space-
craft availability stated in the NSKM. If the best next hop spacecraft
candidate does not answer the request to send data, the sender tries to
relay data D with the next best candidate [28].
Fig. 1 presents a graphical illustration of the envisioned concept of
operations for data relay in federated satellite systems. When a space-
craft, denoted as a customer , wishes to send a piece of data D to a
ground station by using data relay services, it determines the next best
hop based on his objective function F and his NSKM, appends his ID and
the ID of the next spacecraft to the data path P and sends D, P and F to
the chosen federated satellite systems' spacecraft. The federated sa-
tellite systems' spacecraft that receives the data from a customer com-
putes the next best hop, appends the ID of the next best hop to the data
path P and relays D, P and F to that spacecraft. The data D sent from the
customer gets iteratively relayed until it reaches the ground station. The
ground station receives the data D, the customer's objective function F
and the data path P, which lists the spacecraft that relayed data D to the
ground station (Fig. 1).
If the application of data relay becomes a commercial service, then
the data path P would determine the spacecraft that performed the
services of relaying data and that have to be paid. The ground station
would issue payments according to the received data path P.
In the operations of federated satellite systems, it is assumed that
some participating spacecraft may act with the intent to harm the
federation of selected nodes within it. Those malicious nodes are de-
fined as adversaries. An adversary is a spacecraft that legally joins the
system but then acts maliciously: he prevents the system or its parti-
cipants to operate correctly and achieve their goals and/or gathers
private information about federated satellite systems' participants.
Security problems. This section identifies potential security problems
that spacecraft may incur by participating in federated satellite opera-
tions. Authors' analysis' results and an overview of the following dis-
cussion of security problems in federated satellite systems are sum-
marised in Table 4. Opportunistic intersatellite operations' security
problems will be addressed by the proposed security protocol in Section
3.4.2. The discussion of the federated satellite systems' network security
problems will define a direction for future work, discussed in Section 5.
Federated satellite systems' network overload. As the network state is
shared through the “hello” messages containing the Network State
Knowledge Matrix (NSKM), a malicious user could exploit the querying
nature of a P2P network to overload the federated satellite systems'
network by constantly sending out “hello” messages. By exploiting the

Table 3
FSS Stakeholder Data Security Needs and Requirements (addressed needs by the proposed security protocol in Section 3.4 are marked in bold).
Security Needs Stakeholder Type

Space Mission Operators (stakeholders who generate data) Ground-based Users (stakeholders who access data)

Deducted from Copernicus
Needs
Deducted from the FSS Network
Structure
Deducted from FSS Opportunistic
Intersatellite Operations
Access restriction to the generated data through data encryption. Verification of whether the received data is
authentic.
Access restriction to the generated data through authorisation procedures. Access restriction to the generated data through
authorisation procedures (Copernicus Services).
Stakeholder (ground-based and spacecraft) authentication, i.e., stakeholder User authentication, i.e., user identity verification
identity verification for authorisation procedures. for authorisation procedures (Copernicus Services).
Verification of whether the generated data was delivered to the ground
segment correctly and in full.
The federated satellite systems' network should operate reliably; it should have
effective preventative mechanisms against network overload and network
disruption.
A customer, data relaying spacecraft and a ground station should be able to
verify that the received data D, data path P and the customer's objective
function F are authentic and were not modified along the way to a ground
station.
No federated satellite systems' participant except for the designated receiver
should be able to read the relayed data D.
A customer, data relaying spacecraft and a ground station should be able to verify
that the data path P was optimised by the customer's objective function F.
A ground station should be able to verify that a data relay request was not
forged by a malicious user.
A service provider should have a guarantee that he will be paid for his service.
All data relay participants should have a guarantee that a malicious user
will be identified and will be responsible for compensating the data relay
costs and other caused damage.

64
O. von Maurich, A. Golkar Acta Astronautica 149 (2018) 61–76

Fig. 1. Concept of operation for data relay in federated satellite systems.

properties of a P2P network and overloading the network a malicious
user could achieve a data relay application disruption or a total network
disruption.
Network State Knowledge Matrix forgery. A malicious user could send
out inaccurate “hello” messages and thus disseminate a wrong network
state. In the application of data relay, controlling the Network State
Knowledge Matrix would also control the path calculation process. A
spacecraft that a malicious user marked as unavailable will not be
chosen for a data path. If a malicious user cooperates with multiple
malicious spacecraft, marking the malicious spacecraft as the only
available in the network would increase their chances for being selected
for a data relay and thus being paid.
Spacecraft’ coordinate forgery. Federated satellite systems owned and
operated by multiple parties have a spacecraft’ coordinate database
maintained by mutually untrusting parties, e.g., space agencies. The
”spacecraft ID - coordinates” binding is therefore not trusted. A ″cur-
ious” satellite operator may decide to increase its chances of getting
more data relay requests and gathering data from other parties by al-
tering ”spacecraft ID - coordinates” correspondences of other space
agencies' spacecraft and marking their coordinates not suitable for a
particular data relay path. Verifying the coordinates of federated sa-
tellite systems' spacecraft with the public NORAD Catalog could prob-
ably resolve this problem. Yet, it is worth noting that the public in-
formation on spacecraft’ trajectories is not always accurate: according
to the public data the collided on the February 10, 2009 Iridium 33
(USA) and Cosmos 2251(Russia) spacecraft were supposed to pass each
other with an interval of not less than half a kilometer [29].
Malware. Federated satellite systems' participants have to trust that
the data they receive from each other is not corrupted. A malicious user
could exploit this trust and insert malicious code in the data that is
shared within the federated satellite systems' network or in the data
that is being relayed to a ground station through the data relay appli-
cation. Such malware could corrupt particular missions or a spacecraft’
operation in general.
Changing data content, data path or customer's objective function. A
malicious user could undetectably change the content of the customer's
data and relay modified data D′, data path P′ or customer's objective
function F ′ further to a ground station. None of federated satellite
systems' participants would be able to detect that D′, P′ or F ′ are not
original. In the current setting, a customer pays for a data relay, but he
cannot verify that his data D reached the ground station correctly.
Relaying data between adversaries for extra profit. A malicious user
could omit the calculation of the data path that minimizes the custo-
mer's objective function and instead of relaying customer's data to the
next best hop relay customer's data to another malicious spacecraft a
malicious user could be collaborating with. The data could be relayed
between collaborating adversaries an unlimited number of times. Each
malicious user will append his ID to the data path P and will be paid for
the data relay. A ground station will not be able to detect that the data
path did not optimise the customer's objective function and will charge
the customer for all unnecessary data relays in the path P.
Forging data relay requests for extra profit. A malicious user could
forge a data relay request by creating some piece of data D and a data
path P with the ID of a spacecraft that a ground station would consider
as a customer. A malicious user could then relay D and P between
malicious spacecraft to create profit as described in Relaying Data be-
tween Adversaries for Extra Profit. When a ground station receives D and
the data path P, it will look up the customer's ID and will charge the
customer for the path P. In this case the customer will be a victim who
did not order the data relay, but who will be charged for each data relay
of the adversaries.
Liability question. The discussion of the security problems brings up a
liability question: who is responsible for the consequences of a mal-
icious behavior, when no federated satellite systems' participants can
identify the malicious user? When a spacecraft claims that it was
charged for a data relay it did not initiate, should a ground station
believe the spacecraft and issue a refund? When a spacecraft claims that
it relayed a piece of data D, but was not paid, should a ground station
pay that spacecraft? If so, should a customer's account be charged?
What if that customer already suffered from a malicious user who
changed the data path of his data relay and therefore had to pay more
than he should have? While many of them will be addressed by the
security protocol in Section 3.4.2, some will yet fall beyond the scope of
this paper and will remain a key area of future work in the field.
3.3. Proposed system architecture for security mechanisms in federated
satellite systems
Federated satellite systems comprise of (i) mutually untrusting
participants; and (ii) a central authority, trusted by all participants. The
federated satellite systems' central authority registers new spacecraft-
participants in the system (Fig. 2): the central authority checks the

Table 4
Security problems in federated satellite systems.
Security Problem Problem Cause

FSS Network
Security Problems
Opportunistic Intersatellite
Operations Security
Problems
Network overload
Network State Knowledge Matrix forgery
Spacecraft’ coordinate forgery
Malware
Changing data content, data path or customer's objective function
Relaying data between adversaries for extra profit
Forging data relay requests for extra profit
Central authority absence, P2P network properties exploitation
Central authority absence, P2P network properties exploitation
Central authority absence, abuse of the notion of trust
Central authority absence, data validation absence, abuse of the notion of trust
Data integrity and authentication absence
Data integrity and authentication absence
Data integrity and authentication absence

65
O. von Maurich, A. Golkar Acta Astronautica 149 (2018) 61–76

Fig. 2. Federated satellite systems' registration process.

credentials of the owner of the spacecraft and provides the federated

satellite systems' hardware that enables the inter-satellite link (ISL) and
a P2P communication. A spacecraft is then a federated satellite systems'
participant and is technically enabled to collaborate with other feder-
ated satellite systems' participants.
The system's architecture for implementing security mechanisms is
implementation independent, i.e., it is independent from the tech-
nology adopted for the communication link. It could be built on top of a
radio or a laser communication-based network, although it should be
noted, that the laser communication itself would address security in
federated satellite systems by making eavesdropping and jamming
”nearly impossible” [30]. Lluch et al. introduced a federated satellite
systems' network protocol concept (radio-based) and assessed its per-
formance in Ref. [28]. An implementation of a software-defined radio
communication for federated satellite systems was introduced and
tested in Ref. [31].
The proposed solution will introduce the following overhead: (i)
computational overhead (the time it takes for a spacecraft to execute the
operations defined in Fig. 4); and (ii) network overhead (additional bytes
that have to be transferred due to the operations defined in Fig. 4).
Computational overhead and network overhead are the performance
metrics for security mechanisms in federated satellite systems that are
defined by the main constraints of federated satellite systems: the
computational and the bandwidth constraints of spacecraft due to on-
board hardware limitations.

3.4. Protocol for data authentication, integrity and confidentiality in

opportunistic intersatellite operations

Fig. 4. Security Protocol's diagram.

The proposed security protocol, based on public key infrastructure
(PKI), allows spacecraft to reliably verify each other's identity before
engaging in a cooperation, immediately detects a change in the relayed
data content and identifies malicious spacecraft; it also ensures data
confidentiality. The use of PKI allows to overcome the key predis-
tribution problem, where secret keys would have to be embedded in
spacecraft before deployment. The proposed protocol addresses the
security problems in federated satellite systems and their causes stated
in Table 4. The discussion of which security guarantees are addressed
by the protocol and which are not is presented in Table 5.
3.4.1. Background
The section introduces key notions used in later technical discus-
sions, including those of the security protocol in Section 3.4.2.
Public Key Infrastructure (PKI). Public Key Infrastructure (PKI) is a
set of policies and procedures that facilitates a secure information
transfer and enables a verification of data authenticity, data origin and
identity verification of the parties involved in a communication [32].
Applied to federated satellite systems the PKI model allows (i) every
federated satellite systems' participant and every ground station to
verify the identity of every spacecraft that is registered within the
federated satellite systems; (ii) every federated satellite systems' parti-
cipant and every ground station to verify whether the received data D,
data path P and a customer's objective function F originated from the
customer and was not changed in transit; and (iii) achieve data con-
fidentiality with encryption.
As mentioned in Section 3.3, every spacecraft has to be registered at
the federated satellite systems' central authority to join federated sa-
tellite systems. After verifying the identity of a new spacecraft by ver-
ifying the credentials of the spacecraft's operator, the central authority
issues a key pair (signing key, verification key) and a public key cer-
tificate that a spacecraft will use to prove its ownership of the public
key. The certificate includes the public key, the spacecraft's identity,
and the digital signature of the federated satellite systems' central au-
thority that verified that the certificate's content is correct. The central
authority will also distribute the second key pair (private key, public
key) that a spacecraft will use for encryption. Fig. 3 illustrates public
key infrastructure within federated satellite systems.

Fig. 3. Public key infrastructure within federated satellite

systems.

66
O. von Maurich, A. Golkar
Table 5
Protocol's guarantees' discussion.
Security Requirement from Table 3
Access restriction to the generated data through data encryption.
Verification of whether the received data is authentic.
Access restriction to the generated data through authorisation procedures.
Access restriction to the generated data through authorisation procedures (Copernicus
Services).
Stakeholder (ground-based and spacecraft) authentication, i.e., stakeholder
identity verification for authorisation procedures.
User authentication, i.e., user identity verification for authorisation procedures
(Copernicus Services).
Verification of whether the generated data was delivered to the ground segment
correctly and in full.
The federated satellite systems' network should operate reliably; it should have effective
preventative mechanisms against network overload and network disruption.
A customer, data relaying spacecraft and a ground station should be able to verify
that the received dataD, data pathPand the customer's objective functionFare
authentic and were not modified along the way to a ground station.
No federated satellite systems' participant except for the designated receiver
should be able to read the relayed dataD.
A customer, data relaying spacecraft and a ground station should be able to verify that
the data path P was optimised by the customer's objective function F.
A ground station should be able to verify that a data relay request was not forged
by a malicious user.
A service provider should have a guarantee that he will be paid for his service.
All data relay participants should have a guarantee that a malicious user will be
identified and will be responsible for compensating the data relay costs and
other caused damage.
Digital Signatures. A digital signature scheme [33] is a cryptographic
tool allowing a sender to sign a message so that any receiver can check
that the message indeed originated from the sender. It consists of the
three algorithms:
(i) a generator algorithm Gen that, given as input the security para-
meter, samples a key pair (sk , vk) , where sk is the private signing
key and vk is the corresponding public verification key;
(ii) a signature algorithm Sign that, given as input the signing key sk
and a message m, outputs a signature σ for m; and
(iii) a verification algorithm Verify that, given as input the verification
key vk , the message m, and signature σ, checks if σ is a valid sig-
nature for m under vk .
The security of a digital signature scheme says that it is computa-
tionally infeasible for anyone that only has access to the verification key
vk (as well as any number of already-signed messages of his choice) to
produce a new message along with a valid signature. Intuitively, this
means that if one receives a message signed with respect to the ver-
ification key vk , then the sender of that message is in possession of the
67
Acta Astronautica 149 (2018) 61–76
Is the Requirement Addressed by the Protocol?
Yes. The requirement is met because only one entity, the receiver, possesses the
private decryption key kpr (recall Section 3.4.1 and Fig. 5).
Yes. Data authenticity is guaranteed due to the unforgeability of digital signatures
[46]. A signature cannot be forged because only one entity, the owner, possesses the
private signing key sk . The chain of signatures cannot be forged due to the
unforgeability of each signature scheme (recall Section 3.4.1 and Fig. 5).
Yes. The requirement is met by the identity verification procedure (recall Section
3.4.1 and Fig. 4).
No. This requirement is out of scope of this paper, as the primary focus of the paper is
intersatellite operations within federated satellite systems.
Yes. The requirement is met by the identity verification procedure (recall Section
3.4.1 and Fig. 4).
No. This requirement is out of scope of this paper, as the primary focus of the paper is
intersatellite operations within federated satellite systems.
Yes. The security protocol allows to verify data origin and to ensure data integrity by
verifying a digital signature over a piece of data (recall Section 3.4.1 and Fig. 5). Data
freshness is ensured by the authentication procedure with random challenges (Fig. 4).
Now every federated satellite systems' participant has a guarantee that he will pay
only for a data relay request that he indeed initiated and only when a ground station
ultimately receives the correct data, the correct data path and the correct customer's
objective function.
No, achieving this requirement is left for future work, see Section 5. This requirement
is out of scope of this paper, as the primary focus of the paper is intersatellite
operations within federated satellite systems.
Yes. The security protocol allows to verify data origin and to ensure data integrity by
verifying a digital signature over a piece of data (recall Section 3.4.1 and Fig. 5).
Yes. The requirement is met because only one entity, the receiver, possesses the
private decryption key kpr (recall Section 3.4.1 and Fig. 5).
No, achieving this requirement is left for future work, see Section 5. Signing F is not
enough to ensure that the data path P optimized a customer's objective function F:
nothing prevents a spacecraft from omitting using F in the path calculation.
Yes. The security protocol allows to verify data origin and to ensure data integrity by
verifying a digital signature over a piece of data (recall Section 3.4.1 and Fig. 5). Data
freshness is ensured by the authentication procedure with random challenges (Fig. 4).
Now every federated satellite systems' participant has a guarantee that he will pay
only for a data relay request that he indeed initiated and only when a ground station
ultimately receives the correct data, the correct data path and the correct customer's
objective function.
No, achieving this requirement is left for future work, see Section 5. The security
protocol cannot retrieve a spacecraft that was removed from a data path by a
malicious user. Therefore, the security protocol does not guarantee that every service
provider will be paid for a data relay.
Yes. According to the data relay procedure for data authenticity, integrity and
confidentiality in Section 3.4.2, a malicious user is identified as follows: if the
signature verification algorithm Verify (σ , m, vk) returns false, then m was modified
and the data relay application must be terminated. The malicious user is then the
sender of the modified data.
corresponding signing key sk , which enables the receiver to gain con-
fidence in the authenticity of the message (provided he believes that the
sender did not leak his signing key to other people); this also means that
third parties cannot intercept and modify a message without also in-
validating its signature.
Encryption. An encryption scheme [34] is a cryptographic tool al-
lowing a sender to encrypt a message so that only the receiver can
decrypt it and read. It consists of the three algorithms:
(i) a generator algorithm Gen that, given as input the security para-
meter, samples a key pair (k pr , k pub) , where k pub is the public en-
cryption key and k pr is the corresponding private decryption key;
(ii) an encryption algorithm Encrypt that, given as input the encryp-
tion key k pub and a message m, outputs a ciphertext c for m; and
(iii) a decryption algorithm Decrypt that, given as input the decryption
key k pr and the ciphertext c decrypts c into m.
To address the computational constraint of federated satellite sys-
tems the use of a hybrid encryption is proposed, which allows payload
to be encrypted with a symmetric cipher, e.g. AES, which tends to be
O. von Maurich, A. Golkar
much faster than public-key encryption [35]. An AES key is encrypted
with public-key encryption and is sent along with a payload encrypted
with this AES key. The receiver decrypts the AES key with his private
key and decrypts the payload with the decrypted AES key.
3.4.2. Protocol for data authenticity, integrity and confidentiality
The protocol uses digital signatures and encryption and relies on a
public key infrastructure (PKI) to enforce a correspondence between
public keys and identities. Each spacecraft s is assigned:
(i) a key pair (sks , vks) , where sks is the private signing key and vks is
the public verification key; and
(ii) a key pair (k prs , k pubs) , where k prs is the private decryption key and
k pubs is the public encryption key.
The private keys sks and k prs are stored in the spacecraft's memory;
the public keys vks and k pubs are embedded in the public key infra-
structure certificate cert that is available to all federated satellite sys-
tems' participants.
The proposed protocol for opportunistic intersatellite operations is a
combination of identity verification (authentication-only station-to-
station (STS) protocol [36]) and the data relay procedures described in
detail below. The security protocol is illustrated by Fig. 4.
Identity verification. Each spacecraft can verify the identity of an-
other spacecraft by verifying the public key stated in its public key
certificate and the public key certificate itself. If the signature over the
public key certificate certs is verifiable with the central authority's
public key, then the certificate certs is valid. If the signature made by a
spacecraft s is verifiable with the public key vks that is stated in the certs ,
then the identity of s is as stated in the certs .
Authentication protocols differ in security guarantees and in the
number of the required communications and cryptographic operations,
which affects the computational load and therefore efficiency. A famous
Kerberos protocol [37] was designed to authenticate users to servers,
machines with substantial computing power. Although the protocol was
later extended to support a user-to-user authentication, it is still not
applicable to a federated satellite systems' P2P network mainly due to
the requirement of an on-line authentication server [37], [38]. The
X.509 authentication protocol [39] is not desirable due to the weak-
nesses outlined in Ref. [40] [41] that allow an adversary to authenticate
himself as someone else.
The use of the authentication-only station-to-station (STS) protocol
[36] is proposed, which is similar to the ISO three-way protocol [42],
because of its simplicity, efficiency and the absence of the weaknesses
described above [36]. The STS protocol is a typical protocol for key
authentication: for example, the protocols used in Transport Layer Se-
curity (TLS) and IPSEC are based on the station-to-station (STS) pro-
tocol [43]. The authentication-only STS protocol is included in the se-
curity protocol's diagram in Fig. 4. The protocol is public-key based and
provides two-party mutual authentication [36].
The protocol is based on random numbers, challenges R, and does
not rely on timestamps to provide freshness. This is another protocol's
advantage, as timestamps impose implementational challenges [36]
[41]: local clocks may drift after periodical synchronisations and an
appropriate time window has to be allocated to compensate for clock
drifts and network delays. Parties with local clock differences larger
than the allocated window would not be able to communicate. The
practical problems of timestamps are documented in Refs. [38] [44],
[45].
Data relay procedure for data authenticity, integrity and confidentiality.
Opportunistic intersatellite operations are regulated in the proposed
protocol as follows (Fig. 5):
1. A customer spacecraft s1 wants to relay data D to a ground station
(GS). He prepares three pieces of data: data D, data path P, which
initially contains the customer's ID, and the objective function F for
68
Acta Astronautica 149 (2018) 61–76
the data path calculation. He calculates the optimized data path
based on his objective function F and determines that the spacecraft
s2 is the next best hop on the way to the ground station. The cus-
tomer appends the ID of s2 to the data path P, generates a random
AES key, encrypts it with the public key k pub of the receiver to obtain
e (kAES) , encrypts D with that AES key to obtain e (D) and signs the
message m s1 = (e (D), e (kAES), F , s1, s2) using his secret key sk s1 to
obtain the signature σs1. The customer sends (m s1, σs1, cert s1) to s2 ,
where cert s1 is the public key certificate of s1.
2. Spacecraft s2 verifies that received e (D) , e (kAES) , F and P are au-
thentic by verifying the received signature relative to the according
public verification key from the received certificate. If the signature
verification algorithm Verify (σ , m , vk) returns false, then m was
modified and the data relay application must be terminated. The
malicious user is then the sender of the modified data. If the sig-
nature verifies, s2 calculates the optimized data path based on the
customer's objective function F and determines that the spacecraft s3
is the next best hop. He appends the ID of s3 to m s1, signs the message
m s2 = (m s1, s3) using his secret key sk s2 to obtain the signature σs2
and sends (m s2 , σs1, σs2, cert s1, cert s2) to s3 .
3. Spacecraft s3 verifies all received signatures and proceeds only if all
signatures verify relative to the according public verification keys.
The data relay application will continue in this way until a ground
station is reached.
4. A ground station will receive mi , containing the encrypted custo-
mer's data e (D) , the encrypted AES key e (kAES) , the data path P, the
customer's objective function F, a chain of signatures and a list of
public key certificates, containing the public public verification keys
of the spacecraft. If all signatures verify, the data relay application
was successful - the ground station received the authentic encrypted
data e (D) , the encrypted AES key e (kAES) , the data path P and the
customer's objective function F. The receiver of the data D decrypts
e (kAES) with his private key k pr to obtain the AES key with which he
then decrypts e (D) to obtain data D. If at least one signature ver-
ification fails, the ground station concludes that the sender is the
malicious user.
Notes on performance improvement: public key certificates could be
distributed once, verified and stored by each spacecraft to reduce the
communication cost. In this case the certificate revocation list of the
federated satellite systems' central authority has to be renewed peri-
odically by each spacecraft. That way spacecraft would not have to
relay a list of certs certificates to a ground station, but instead derive the
identities from the data path P and corresponding public keys from
memory. Furthermore, if data D is large it could be signed only once by
s1, consecutive spacecraft could then simply include previous signatures
into the message they sign instead of the encrypted data, e.g.,
m s2 = (σm s1, F , s1, s2, s3) .
4. Results
The section discusses security guarantees achieved by the proposed
security protocol (Section 3.4.2) and presents an experimental char-
acterisation of the computational and network overhead on proxies to
space qualified computer for CubeSats, a Raspberry Pi 2 platform, and a
discussion of what platforms achieve a baseline performance goal of
2 min with radio-based (processing 7.5 GB of data per an opportunistic
intersatellite operation) and laser-based communication (processing
75 GB of data per an opportunistic intersatellite operation). We define
the performance goal for the non-interactive operations of the security
protocol (the interactive part of the protocol, identity verification, is
insignificant) to be 2 min - an engineering assumption based on best
judgment that pointing an antenna or a laser (including spacecraft
manoeuvering) takes about 2 min. The interactive part of the protocol,
identity verification, is insignificant, as it does not involve large data
processing, e.g., computing the hash of the large (larger than 1 MB)
O. von Maurich, A. Golkar
Fig. 5. Data Relay Flowchart.
input data (subsection Computational Overhead, Section 4.1). Identity
verification procedure requires a hash function being applied to the
concatenated random challenges (Figs. 4), 128 bits each, and therefore,
introduces no computational overhead.
If spacecraft that is relaying data to the next hop computes the
operations required for the data relaying procedure within 2 min while
it prepares its spacecraft for the communication with the next data hop,
the protocol would introduce no operational delay. As Table 12 and
Table 13 will later report, hardware selection may greatly impact the
computing time. Fig. 6 illustrates an intersatellite operation and how
the performance goal is deducted.
Note that the proposed security protocol is an application level
protocol and its overhead does not depend on the packet size and the
number of packets required to relay the entire payload. The security
overhead does not change in case packets on the data link layer are split
into smaller packets. The cryptographic signature is computed on the
application layer over the full data before transmission.
Protocol's guarantees. The addressed federated satellite systems' data
security needs and requirements that are met by the security protocol
are marked in bold in Table 3. Table 5 discusses achieving protocol's
guarantees in more detail. A technical discussion about suitable algo-
rithms, their strength and performance, and how they meet the security
requirements in practice are provided in the following section.
4.1. Security protocol's implementation and performance characterisation
on a CubeSat candidate platform, Raspberry Pi 2
The security protocol was implemented in the C programming lan-
guage for a typical data relay with three hops and the relayed data size
of 100 kB with two different libraries (wolfSSL and Sodium) and three
different digital signature algorithms (ECDSA with Curve P-384, 3072-
bit RSA and Ed25519) for comparison purposes and implementation
analysis on a Raspberry Pi 2 board with a 900 MHz quad-core ARM
Cortex-A7 CPU. The measurements were taken using the system-wide
high-resolution real time clock of the Raspberry Pi; the presented
measurements are the average of 150 measurements with randomised
input. The Raspberry Pi 2 board was chosen as the platform for the FSS
payload prototype because it proved itself as a low-cost and effective
on-board computer for spaceflights. The Autonomous Assembly of a
Reconfigurable Space Telescope (AAReST) mission, for example, in-
corporated Raspberry Pi as an on-board computer for CoreSat and
Fig. 6. Close-up of an intersatellite operation.
69
Acta Astronautica 149 (2018) 61–76
MirrorSat components [47].
Algorithms. Three digital signature algorithms were used and
compared for the security protocol's implementation: the Elliptic Curve
Digital Signature Algorithm (ECDSA) with Curve P-384 as re-
commended by the National Security Agency (NSA) ”Suite B″ standard
[48]; 3072-bit RSA signatures (a withdrawn NSA recommendation, but
still a common digital signature algorithm choice with the minimum
3072-bit modulus required by ”Suite B” [48]); a digital signature
system Ed25519 (proposed as a considerably faster and simpler [49],
but not less secure system by Bernstein et al. [50]).
Hybrid encryption (Section 3.4.1) was implemented with the sym-
metric AES-128 cipher [51] for the payload encryption and 3072-bit
RSA for the AES key encryption.
Libraries. Two cryptographic C-language-based libraries were used:
wolfSSL and Sodium. The wolfSSL library is an embedded SSL library
with more than 1 billion copies used in both open source and com-
mercial projects. The library provides building blocks for the develop-
ment and customisable configuration flags for targeting different goals
(e.g. building for non-standard environments, for increasing perfor-
mance, for reducing memory usage). The Sodium library is a fork of
NaCl [50], a new cryptographic library aimed to provide a transition
from customisable libraries as OpenSSL (and its variants like wolfSSL)
to a completely new easy-to-use cryptographic library, whose simple
high-level API avoids developers' cryptographic mistakes that are pos-
sible with libraries such as OpenSSL. Preselected cryptographic choices
(algorithms and constants) of NaCl enforce security and enable high
speeds and efficient use of bandwidth. The authors state that NaCl has
been integrated into high-security applications today, e.g. Threema, a
proprietary encrypted instant messaging application [50]. Sodium, an
API-compatible version of NaCl, was used due to its additional ad-
vantages of being even more user-friendly, portable, cross-compilable,
installable and packageable.
All three choices of digital signature algorithms provide security
levels of at least 128 bit of equivalent symmetric security, which means
that at least 2128 operations are required to break the algorithms.
Running 2128 operations is considered to be infeasible with existing and
foreseeable technology [52]. ECDSA with Curve P-384 (192 bit security
[53]) and 3072-bit RSA (128 bit security [54]) were paired with SHA-
384 (192 bit security [55]); Ed25519 signatures (2128 security level
[56]) are combined with SHA-512(256 bit security [55]).
Security protocol's performance. The wolfSSL library was con-
figured with the following flags for increased performance: fastmath
was enabled (–enable-fastmath) to speed up the operations with as-
sembly when possible; size of long long was set to 8 bytes
SIZEOF_LONG_LONG 8 as wolfSSL benefits speed-wise from 64-bit types. The
Sodium library, as it was noted earlier, is already preconfigured for
maximum performance.
Computational Overhead. The total computational overhead in-
troduced by the security protocol in the data relay application is de-
scribed by the following function: T
(n) = tenc + (3n + 3) tSign + ( (n + 1)(n + 2)
2 )
+ 2n + 2 tVerify , where n is a
number of data relay hops, tenc is the duration of the encryption
O. von Maurich, A. Golkar Acta Astronautica 149 (2018) 61–76

Table 6 Table 8
Encryption Times for Relay Data Size of 100 kB. Security Protocols' Total Computational Overhead for Relay Data Size of
100 kB.
t [ms]
Total Computational Overhead T(n)
3072-bit RSA Encryption of the AES Key 86.02
AES Encryption of the payload 27 ECDSA with Curve P-
Total Encryption time tenc 86.02 + 27 = 113.02 384
113.02 + 191.13(3n + 3) + 240.52 ( (n + 1)(n + 2)
2
+ 2n + 2 )
3072-bit RSA
113.02 + 1273.34(3n + 3) + 86.02 ( )
(n + 1)(n + 2)
+ 2n + 2
2
Ed25519
algorithm Encrypt for the data D and the AES key, tSign is the duration of 113.02 + 38.66(3n + 3) + 21.42 ( )
(n + 1)(n + 2)
+ 2n + 2
2
the signature algorithm Sign, and tVerify is the duration of the verifica-
tion algorithm Verify . For each additional data relay hop, three sig-
nature operations have to be executed: two for the identity verification
procedure and one for signing the relayed data. Accounting for the
downlink operation (with the same reasoning for the three signature
operations), the total number of the executions of the signature algo-
rithm Sign is (3n + 3) . The total number of the executions of the ver-
ification algorithm Verify is composed of (n + 1)(n + 2) , the total number of
2
signature verifications for the relayed data (Gauss sum), and (2n + 2) ,
two signature verifications for the identity verification for each addi-
tional hop plus two verifications for the downlink operation. Encryption
happens only once by the customer before relaying the data.
The time overhead of the Encrypt , Sign and Verify algorithms was
measured for a typical data relay with three hops and the size of the
relayed data D was set to 100 kB; the results are averaged over 150
measurements each. Table 6 presents the average measurements of the
Encrypt algorithm applied to the payload and the AES key (wolfSSL
library); Table 7 presents the average measurements of the Sign and
Verify algorithms with ECDSA with Curve P-384 (wolfSSL library),
3072-bit RSA (wolfSSL library) and Ed25519 signatures (Sodium li- Fig. 7. Security Protocol's Computational Overhead for Relay Data Size of
brary); Table 8 presents the overall computational overhead for the 100 kB.
relay data size of 100 kB. Fig. 7 plots the overall computational over-
head for the relay data size of 100 kB introduced by the security pro- Table 9
tocol for a number of data relay hops from one to ten. Signature and Verification Times for x MB of Input Data.
Computation time for large data processing (larger than 1 MB) tSign [ms] t Verify [ms]
mostly depends on the time it takes to compute the hash of the input
data. Hashing 1 MB of data with SHA-384 on the Raspberry Pi 2 plat- ECDSA with Curve P-384 128.63 + 625x 178.02 + 625x
form takes 625 ms. Signature and verification times for x MB of input 3072-bit RSA 1210.84 + 625x 23.52 + 625x
Ed25519 4.34 + 377.54x 4.35 + 187.82x
data can be computed according to Table 9. Encryption time for x MB of
input data can be computed according to Table 10. Fig. 8 shows how
changing the payload size to, for example, 7.5 GB changes the compu-
Table 10
tational overhead of the protocol. The protocol's implementation with Encryption Times for x MB of Input Data.
3072-bit RSA signatures (wolfSSL library) and the implementation with
ECDSA Curve P-384 signatures (wolfSSL library) introduce the same t [ms]

computational overhead, as the computation time is dominated by the 3072-bit RSA Encryption of the AES Key 86.02
SHA-384 hash of 7.5 GB of data, which is computed in both schemes. AES Encryption of the payload 270x
The protocol's implementation with Ed25519 signatures also hashes Total Encryption time tenc 86.02 + 270x
7.5 GB of data, but the algorithm's SHA-512 and its optimised im-
plementation in the Sodium library results in a lower computation time.
Note that the computational overhead depends only on the total
amount of data to be sent and does not depend on the datagram size
inside the protocol of the intersatellite link used. For example, if
100 MB of data have to be split into packets of 20 MB, the computa-
tional overhead would not increase 5 times. The security overhead does
not change in case packets on the data link layer are split into smaller
packets - the cryptographic signature is computed on the application
layer over the full data before transmission.
Network Overhead. The network overhead introduced by the security

Table 7
Signature and Verification Times for Relay Data Size of 100 kB.
tSign [ms] t Verify [ms]

ECDSA with Curve P-384 191.13 240.52

3072-bit RSA 1273.34 86.02
Ed25519 38.66 21.42
Fig. 8. Security Protocol's computational overhead for relay data size of 7.5 GB.

70
O. von Maurich, A. Golkar
Table 11
Signature sizes.
Algorithm Signature Size [bytes]
ECDSA with Curve P-384 96
3072-bit RSA 384
Ed25519 64
Fig. 9. Security Protocol's network overhead with 3072-bit RSA signatures.
protocol is defined by the size of the signatures that have to be relayed
along with the relayed data divided by the bandwidth of federated
satellite systems' spacecraft. It is assumed that public key certificates
are preshared and do not have to be relayed with signatures. The net-
work overhead augments with the number of hops, as at each hop a
signature that has to be relayed to a ground station is added. Table 11
lists signature sizes of ECDSA with Curve P-384, 3072-bit RSA and
Ed25519 algorithms. The security protocol does not add a significant
load on the network, as the worst case of transmitting security proto-
col's signatures for a 10 hop data relay requires less than 0.5 s (Fig. 9).
The protocol implemented with Ed25519 signatures introduces the
smallest computational and network overhead.
4.2. Achieving performance goal: characterisation on a range of more
powerful platforms
This section discusses what CPUs could achieve the performance
goal for the non-interactive operations of the security protocol of 2 min,
so that the protocol introduces no operational delay.
Protocol's design improvement. To provide an effective operation of
the security protocol on large data inputs, protocol's design is changed
as it was noted in Section 3.4.2: large data D is signed only once by the
customer, while consecutive spacecraft sign m s2 = (σm s1, F , s1, s2, s3) ,
m s3 = (σm s1, F , s1, s2, s3, s4 ) , etc. This allows to reduce the size of the
message to be signed and verified and improves the efficiency of the
security protocol.
Fig. 10. Improved data relay procedure.
71
Acta Astronautica 149 (2018) 61–76
Fig. 10 illustrates the improved design of the data relay procedure
that significantly improves the performance of the security protocol.
Performance characterisation on various platforms. Performance
characterisation is performed for two types of communication: radio-
based and laser-based. Given that spacecraft have about 10 min com-
munication frame, an expected bandwidth for a radio-based commu-
nication is 100 Mb/s and 1 Gb/s for a laser-based communication,
spacecraft can transmit a maximum of 7.5 GB and 75 GB of data re-
spectively per connection. Therefore, two cases are described: a data
relay of 7.5 GB and a data relay of 75 GB.
Section 4.1, Fig. 8, showed that a Raspberry Pi 2 platform is not
suitable for the proposed security protocol with large data inputs.
Tables 12 and 13 provide a performance characterisation of the pro-
tocol on a range of CPUs with a power consumption ranging of 2–90 W
based on the performance data of ECRYPT Benchmarking of Crypto-
graphic Systems. When we compare the ratio of MIPs over the clock
cycles per second of the platforms presented in Tables 12 and 13 with
that ratio of space platforms like Atmel ERC-32 (Sentinel-2), GR740,
Nanomind A712D GOMSPACE ARM7, ISIS OBC ISIS ARM9, Pluggable
Socketed Pumpkin C8051F120, PowerPC 405, ATmega328P (stated in
the ”Small Spacecraft Technology State of the Art” Report by NASA,
2016) we can estimate that none of the mentioned space platforms will
outperform Cortex-A7 (Raspberry Pi 2) and Cortex-A8 (BeagleBone), as
their MIPs over the clock cycles per second are under 1.9. RAD750 is
the closest space analog for Cortex-A7 and Cortex-A8 with 1.8 IPS/clock
cycles per second.
Data Relay of 7.5 GB - Radio-based Communication. Fig. 11 illustrates
what non-interactive data relay operations have to be performed at
each hop with 7.5 GB of input data. Only three hops are considered, as
according to [28], three hops are enough to resolve 70% of data relay
requests. Operations of the ground station are not included, as they are
not limited in computational resources and introduce no time delay.
Computational overhead to execute these operations on different
CPUs and its impact in terms of transmission efficiency is characterised
in Table 12. The impact of the computational overhead in terms of
transmission efficiency was calculated by comparing the computational
overhead to the transmission time of the bare payload (600 s). Note that
the difference in computational overhead between the three hops in
most cases is less than 10 ms.
Fig. 12 and Fig. 13 illustrate the time it takes for a CPU to perform
non-interactive data relay operations against the CPU's power con-
sumption. When radio-based communication is used, i.e., the size of the
input is 7.5 GB, most of the CPUs meet the performance goal of 2 min,
and a CPU with a smaller power consumption can then be chosen.
Data Relay of 75 GB - Laser-based Communication. Fig. 14 illustrates
what non-interactive data relay operations have to be performed at
each hop with 75 GB of input data. As with radio communication, op-
erations of the ground station are not included, as they are not limited
in computational resources and introduce no time delay.
Computational overhead to execute these operations on different
CPUs and its impact in terms of transmission efficiency is characterised
in Table 13. The impact of the computational overhead in terms of
 Table 12
Computational overhead with 7.5 GB input on a range of CPUs.
Platform Customer time [s]/Transmission Hop 1 time [s]/Transmission Hop 2 time [s]/Transmission Hop 3 time [s]/Transmission Power Consumption [W]
Efficiency [%] Efficiency [%] Efficiency [%] Efficiency [%]

Cortex-A7 (410fc075); 2015 Broadcom BCM2836; 582,84/2,86 263,26/56,12 263,26/56,12 263,26/56,12 2,1
4 × 900 MHz
O. von Maurich, A. Golkar

Cortex-A8 (413fc082); 2012 TI Sitara XAM3359AZCZ100; 328,51/45,25 183,46/69,42 183,46/69,42 183,47/69,42 2

1 × 1000 MHz
Skylake (506e3); 2015 Intel Core i5-6600; 4 × 3310 MHz 13,60/97,73 11,49/98,09 11,49/98,09 11,49/98,09 73
K8 (40fb2); 2006 AMD Athlon 64 X2; 2 × 2000 MHz 75,11/87,48 35,03/94,16 35,03/94,16 35,03/94,16 89
Piledriver (610f01); 2012 AMD A10-5800K; 2 × 3800 MHz 26,05/95,66 23,47/96,09 23,47/96,09 23,47/96,09 85
Atom (30661); 2011 Intel Atom D2500; 2 × 1866 MHz 257,36/57,11 61,70/89,72 61,70/89,72 61,70/89,72 10
Cortex-A15 (410fc0f4); 2012 Samsung Exynos 5 Dual; 145,28/75,79 76,77/87,21 76,77/87,21 76,77/87,21 7
2 × 1700 MHz
Sandy Bridge (206a7); 2011 Intel Core i3-2310 M; 78,32/86,95 39,07/93,49 39,07/93,49 39,07/93,49 65
2 × 2100 MHz
IB + AES (306a9); 2012 Intel Xeon E3-1275 V2; 20,21/96,63 17,42/97,10 17,42/97,10 17,42/97,10 77
4 × 3500 MHz
Westmere + AES (206c2); 2010 Intel Xeon E5620; 35,47/94,09 30,84/94,86 30,84/94,86 30,84/94,86 65
4 × 2400 MHz
K10 65 nm (100f23); 2008 AMD Opteron 8354; 70,32/88,28 33,91/94,35 33,91/94,35 33,91/94,35 60.94
8 × 2194 MHz
C2 45 nm (10676); 2008 Intel Pentium E5200; 65,94/89,01 29,67/95,06 29,67/95,06 29,67/95,06 52.81
2 × 2500 MHz

72
Table 13
Computational overhead with 75 GB input on a range of CPUs.
Platform Customer time [s]/Transmission Hop 1 time [s]/Transmission Hop 2 time [s]/Transmission Hop 3 time [s]/Transmission Power Consumption [W]
Efficiency [%] Efficiency [%] Efficiency [%] Efficiency [%]

Cortex-A7 (410fc075); 2015 Broadcom BCM2836; 5828,34/0 2632,51/0 2632,51/0 2632,51/0 2,1
4 × 900 MHz
Cortex-A8 (413fc082); 2012 TI Sitara XAM3359AZCZ100; 3285,01/0 1834,51/0 1834,51/0 1834,52/0 2
1 × 1000 MHz
Skylake (506e3); 2015 Intel Core i5-6600; 4 × 3310 MHz 135,95/77,34 114,88/80,85 114,88/80,85 114,88/80,85 73
K8 (40fb2); 2006 AMD Athlon 64 X2; 2 × 2000 MHz 751,13/0 350,25/41,63 350,25/41,63 350,25/41,63 89
Piledriver (610f01); 2012 AMD A10-5800K; 2 × 3800 MHz 260,53/56,58 234,67/60,89 234,67/60,89 234,67/60,89 85
Atom (30661); 2011 Intel Atom D2500; 2 × 1866 MHz 2573,55/0 616,96/0 616,96/0 616,97/0 10
Cortex-A15 (410fc0f4); 2012 Samsung Exynos 5 Dual; 1452,8/0 767,65/0 767,65/0 767,65/0 7
2 × 1700 MHz
Sandy Bridge (206a7); 2011 Intel Core i3-2310 M; 783,21/0 390,71/34,89 390,71/34,89 390,71/34,89 65
2 × 2100 MHz
IB + AES (306a9); 2012 Intel Xeon E3-1275 V2; 202,07/66,32 174,21/70,97 174,21/70,97 174,21/70,97 77
4 × 3500 MHz
Westmere + AES (206c2); 2010 Intel Xeon E5620; 354,69/40,86 308,44/48,59 308,44/48,59 308,44/48,59 65
4 × 2400 MHz
K10 65 nm (100f23); 2008 AMD Opteron 8354; 703,17/0 339,11/43,48 339,11/43,48 339,11/43,48 60.94
8 × 2194 MHz
C2 45 nm (10676); 2008 Intel Pentium E5200; 659,40/0 296,70/50,55 296,70/50,55 296,70/50,55 52.81
2 × 2500 MHz
Acta Astronautica 149 (2018) 61–76
O. von Maurich, A. Golkar
Fig. 11. Improved data relay procedure.
transmission efficiency was calculated by comparing the computational
overhead to the transmission time of the bare payload (600 s). Note that
the difference in computational overhead between the three hops in
most cases is less than 10 ms.
Fig. 15 and Fig. 16 illustrate the time it takes for a CPU to perform
non-interactive data relay operations against its power consumption.
When laser-based communication is used, i.e., the size of the input is
75 GB, fewer CPUs can achieve the performance goal of 2 min - from the
CPUs present in Table 13 only Skylake (506e3) 2015 Intel Core i5-6600
4 × 3310 MHz finished the data relay operations from Fig. 14 in 2 min.
Results Discussion. The performance characteristic of the data relay
procedure on a range of CPUs shows that it is critical to prepare pro-
tocol's computations before the transmission's start, as otherwise the
transmission efficiency will be impacted. As the proposed security
protocol is an application level protocol and does not depend on the
implementation of the intersatellite communication link and the se-
curity computational overhead does not change in case packets on the
data link layer are split into smaller packets, encryption and signatures
should be precomputed before the transmission. Tables 12 and 13 show
that the proposed security protocol can achieve the performance goal of
2 min (even with 75 GB of input data with a Skylake (506e3) 2015 Intel
Core i5-6600 4 × 3310 MHz CPU), thus not adding an operational
delay, as spacecraft can perform these computations while they point
their antennas/lasers and prepare their spacecraft for a communication
with the next spacecraft. Fig. 13 shows that when radio-based com-
munication is used, less powerful and more energy efficient CPUs could
be chosen. When laser-communication is chosen, however, the pro-
posed security protocol demands more powerful and energy consuming
CPUs - otherwise the overhead of large data processing will be limiting
the data throughput, transmission efficiency, and therefore the benefit
of the laser communication.
5. Conclusion and future work
This section provides the summary of the work and its limitations. It
outlines the paper's contribution and discusses directions of future
Fig. 12. Customer's Computational Time vs CPU Power Consumption: 7.5 GB Input (Radio Communication).
73
Acta Astronautica 149 (2018) 61–76
work.
5.1. Summary and contribution
The paper proposes the first characterisation of security needs for
federated satellite systems based on the stakeholder need analysis and a
discussion of security problems that could arise in federated satellite
systems. Based on the identified security needs a system architecture for
implementing security mechanisms in satellite federations and a public
key infrastructure (PKI) based security protocol is proposed. The system
architecture for implementing security mechanisms defines interfaces
in federated satellite operations, addressing related security issues, and
formulates metrics to evaluate the impact of security in federated sa-
tellite operations. The proposed public key infrastructure (PKI) based
protocol for security in data transfer in federated satellite systems
identifies suitable security mechanisms for federated satellite systems
and enhances federated data relay applications with data authentica-
tion, integrity and confidentiality. The protocol allows spacecraft to
reliably verify each other's identity, ensures data confidentiality, im-
mediately detects a change in the relayed data content and identifies
malicious spacecraft. The protocol satisfies the following security re-
quirements:
• verification of whether the received data is authentic;
• access restriction to the generated data through data encryption;
• access restriction to the generated data through authorisation pro-
cedures;
• stakeholder (ground-based and spacecraft) authentication, i.e., sta-
keholder identity verification for authorisation procedures;
• verification of whether the generated data was delivered to the
ground segment correctly and in full;
• a customer, data relaying spacecraft and a ground station should be
able to verify that the received data D, data path P and the custo-
mer's objective function F are authentic and were not modified
along the way to a ground station;
• no federated satellite systems' participant except for the designated
O. von Maurich, A. Golkar
Fig. 13. Average Computational Time per Hop vs CPU Power Consumption: 7.5 GB Input (Radio Communication).
receiver should be able to read the relayed data D;
• a ground station should be able to verify that a data relay request
was not forged by a malicious user; and
• all data relay participants should have a guarantee that a malicious
user will be identified and will be responsible for compensating the
data relay costs and other caused damage.
The security requirements that are not satisfied by the protocol ei-
ther because they do not directly relate to federated satellite systems'
opportunistic intersatellite operations or because additional security
mechanisms are required are:
• access restriction to the generated data through authorisation pro-
cedures (Copernicus Services);
• user authentication, i.e., user identity verification for authorisation
procedures (Copernicus Services);
• federated satellite systems' network should operate reliably; it
the
should have effective preventative mechanisms against network
overload and network disruption;
• a customer, data relaying spacecraft and a ground station should be
able to verify that the data path P was optimised by the customer's
objective function F; and
• a service provider should have a guarantee that he will be paid for
his service.
An experimental characterization of the proposed security protocol
implemented on a CubeSat candidate, Raspberry Pi 2, a low-cost and
effective on-board computer for spaceflights [47] and a benchmarking
characterisation on a wider range of platforms is presented. The per-
formance characteristic of the data relay procedure on a range of CPUs
shows that it is critical to prepare protocol's computations before the
transmission's start, as otherwise the transmission efficiency will be
impacted. As the proposed security protocol is an application level
protocol and the security computational overhead does not change in
case packets on the data link layer are split into smaller packets, en-
cryption and signatures should be precomputed before the
Fig. 14. Improved data relay procedure.
74
Acta Astronautica 149 (2018) 61–76
transmission. Tables 12 and 13 show that the proposed security pro-
tocol can achieve the performance goal of 2 min (even with 75 GB of
input data with a Skylake (506e3) 2015 Intel Core i5-6600
4 × 3310 MHz CPU), thus not adding an operational delay, as space-
craft can perform these computations while they point their antennas/
lasers and prepare their spacecraft for a communication with the next
spacecraft.
5.2. Limitations
The main limitation of the proposed protocol for data authentica-
tion, integrity and confidentiality discussed in Section 3.4 is perfor-
mance. While the introduced network overhead was insignificant and
could be neglected, the computational overhead could get expensive
when the input size of the payload is gigabytes and terabytes of data.
The computational overhead thus limits the platform choice: less
powerful and more energy efficient platforms could be chosen when the
radio-communication is used (due to the relative small input data size
of 7.5 GB per a data transfer), but more powerful platforms are de-
manded by the laser communication (when 75 GB of data per connec-
tion is transferred).
5.3. Future work
The main direction of future work is to extend the proposed protocol
for data authentication, integrity and confidentiality (Section 3.4) to
address more security needs and requirements. Recall that not all of the
federated satellite systems' stakeholder data security needs and re-
quirements were addressed by the proposed security protocol. Possible
directions of future work include the development of effective pre-
ventative mechanisms against federated satellite systems' network
overload and network disruption to increase the reliability of the fed-
erated satellite systems' network, development of mechanisms for ver-
ification that the data relay path P indeed was optimised by the cus-
tomer's objective function F and achieving guarantees that a service
provider in federated satellite systems, e.g., a spacecraft offering data
O. von Maurich, A. Golkar
Fig. 15. Customer's Computational Time vs CPU Power Consumption: 75 GB Input (Laser Communication).
Fig. 16. Average Computational Time per Hop vs CPU Power Consumption: 75 GB Input (Laser Communication).
relay services, will be paid for his service. Another direction of future
work would be an experimental characterization of the proposed se-
curity protocol on existing satellites, for example, S1 and EDRS, once
we have access to the real data and technical characteristics of S1 and
EDRS.
Acknowledgment
This study was conducted in the framework of the ONION
″Operational Network of Individual Observation Nodes” project and it
has received funding from the European Union's Horizon 2020 research
and innovation programme under grant agreement No 687490, co-
ordinated by Thales Alenia Space France.
References
[1] I. Lluch i Cruz, A. Golkar, Resource Balancing Analysis of Federated Satellite
Systems, AIAA SPACE 2014 Conference and Exposition. http://dx.doi.org/10.2514/
6.2014-4270.
[2] A. Golkar, I.L. i Cruz, The Federated Satellite Systems paradigm: concept and
business case evaluation, Acta Astronaut. 111 (0) (2015) 230–248, http://dx.doi.
org/10.1016/j.actaastro.2015.02.009.
[3] G. Buscemi, B. Angelucci, M. Di Mascolo, M. Nardelli, A. Damiani, Comprehensive
Security Framework for Copernicus: Free & Open Data Access, TNC15.
[4] S. Shah, J. Muhammad, A. Nasir, H. Ahmed, A survey paper on security issues in
satellite communication network infrastructure, Int. J. Eng. Res. Gen. Sci. 2.
[5] N. Doraswamy, D. Harkins, IPSec: the new security standard for the Internet, in-
tranets, and virtual private networks, Prentice Hall Professional,, 2003.
[6] T. Dierks, RFC 5246: the Transport Layer Security (TLS) Protocol Version 1.2.
[7] J. Postel, RFC 793: Transmission Control Protocol, September 1981, Status:
Standard 88.
[8] J. Postel, RFC 768: User Datagram Protocol.
[9] S.T. Zargar, J. Joshi, D. Tipper, A survey of defense mechanisms against distributed
denial of service (DDoS) flooding attacks, IEEE Communications Surveys Tutorials
15 (4) (2013) 2046–2069, http://dx.doi.org/10.1109/SURV.2013.031413.00127.
[10] Y.-F. Chang, C.-C. Chang, An efficient authentication protocol for mobile satellite
75
Acta Astronautica 149 (2018) 61–76
communication systems, SIGOPS oper, Syst. Rev. 39 (1) (2005) 70–84, http://dx.
doi.org/10.1145/1044552.1044560.
[11] Tzung-Her Chen and Wei-Bin Lee and Hsing-Bai Chen, A self-verification authen-
tication mechanism for mobile satellite communication systems, Comput. Electr.
Eng. 35 (1) (2009) 41–48, http://dx.doi.org/10.1016/j.compeleceng.2008.05.003.
[12] H.S. Cruickshank, A Security System for Satellite Networks, Fifth International
Conference on Satellite Systems for Mobile Communications and Navigation, 1996,
pp. 187–190, , http://dx.doi.org/10.1049/cp:19960437.
[13] W.R. Otte, A. Dubey, S. Pradhan, P. Patil, A. Gokhale, G. Karsai, J. Willemsen,
F6com: a Component Model for Resource-constrained and Dynamic Space-based
Computing Environments, (2013), pp. 1–8, http://dx.doi.org/10.1109/ISORC.
2013.6913199.
[14] T. Levendovszky, A. Dubey, W.R. Otte, D. Balasubramanian, A. Coglio, S. Nyako,
W. Emfinger, P. Kumar, A. Gokhale, G. Karsai, Distributed real-time managed sys-
tems: a model-driven distributed secure information architecture platform for
managed embedded systems, Software, IEEE 31 (2) (2014) 62–69, http://dx.doi.
org/10.1109/MS.2013.143.
[15] W.R. Otte, A. Dubey, G. Karsai, A Resilient and Secure Software Platform and
Architecture for Distributed Spacecraft, in: SPIE 9085, Sensors and Systems for
Space Applications VII, International Society for Optics and Photonics, 2014,
http://dx.doi.org/10.1117/12.2054055 90850J–90850J.
[16] C. Partridge, R. Walsh, M. Gillen, G. Lauer, J. Lowry, W.T. Strayer, D. Kong,
D. Levin, J. Loyall, M. Paulitsch, A secure content network in space, Proceedings of
the Seventh ACM International Workshop on Challenged Networks, ACM, 2012, pp.
43–50, , http://dx.doi.org/10.1145/2348616.2348626.
[17] A. Dubey, W. Emfinger, A. Gokhale, G. Karsai, W.R. Otte, J. Parsons, C. Szabó,
A. Coglio, E. Smith, P. Bose, A software platform for fractionated spacecraft,
Aerospace Conference, 2012 IEEE, IEEE, 2012, pp. 1–20, , http://dx.doi.org/10.
1109/AERO.2012.6187334.
[18] A. Dubey, A. Gokhale, G. Karsai, W. Otte, J. Willemsen, A model-driven software
component framework for fractionated spacecraft, Proceedings of the 5th
International Conference on Spacecraft Formation Flying Missions and
Technologies (SFFMT), IEEE, Munich, Germany, 2013.
[19] M. Juliato, Fault Tolerant Cryptographic Primitives for Space Applications,
University of Waterloo.
[20] M. Juliato, C. Gebotys, SEU-resistant SHA-256 design for security in satellites,
Signal Processing for Space Communications, 2008. SPSC 2008. 10th International
Workshop on, IEEE, 2008, pp. 1–7, , http://dx.doi.org/10.1109/SPSC.2008.
4686705.
[21] T. Vladimirova, R. Banu, M. Sweeting, On-board security services in small satellites,
MAPLD Proceedings, 2005.
O. von Maurich, A. Golkar
[22] S. Ghaznavi, C. Gebotys, A SEU-resistant, FPGA-based implementation of the sub-
stitution transformation in AES for security on satellites, Signal Processing for Space
Communications, 2008. SPSC 2008. 10th International Workshop on, IEEE, 2008,
pp. 1–5, , http://dx.doi.org/10.1109/SPSC.2008.4686706.
[23] European Space Agency, Regulations of the european space agency, Security
Regulations (2012).
[24] European Commission, Regulation (EU) No 377/2014 of the european parliament
and of the Council of 3 april 2014, Official Journal of the European Union, L
122/44.
[25] European Space Agency, Copernicus Space Component Data Access Portfolio: Data
Warehouse 2014-2020, (2016).
[26] M. Muller, GMES in Situ Coordination (GISC): Revised List of Stakeholders,
European Environment Agency, (December 2011).
[27] Commission Delegated Regulation (EU) No 1159/2013 of 12 July 2013
Supplementing Regulation (EU) No 911/2010 of the European Parliament and of
the Council on the European Earth Monitoring Programme (GMES) by Establishing
Registration and Licensing Conditions for GMES Users and Defining Criteria for
Restricting Access to GMES Dedicated Data and GMES Service Information OJ L
309, 19.11.2013, p. 1–6 (BG, ES, CS, DA, DE, ET, EL, EN, FR, HR, IT, LV, LT, HU,
MT, NL, PL, PT, RO, SK, SL, FI, SV). URL {European␣Legislation␣Identifier␣(ELI):
http://data.europa.eu/eli/reg_del/2013/1159/oj}.
[28] I. Lluch, A. Grogan, P.U. Pica, A. Golkar, Simulating a proactive ad-hoc network
protocol for federated satellite systems, Aerospace Conference, 2015 IEEE, 2015,
pp. 1–16, , http://dx.doi.org/10.1109/AERO.2015.7118984.
[29] L. Kamm, J. Willemson, Secure floating-point arithmetic and private satellite col-
lision analysis, Int. J. Inf. Secur. (2014) 1–18 https://doi.org/10.1007/s10207-014-
0271-8.
[30] Debbie Kedar, Shlomi Arnon, Urban optical wireless communication networks: the
main challenges and possible solutions, Communications Magazine, IEEE 42 (5)
(2004) S2–S7, http://dx.doi.org/10.1109/MCOM.2004.1299334.
[31] Rustam Akhtyamov, Ignasi Lluch i Cruz, Hripsime Matevosyan, Dominik Knoll,
Udrivolf Pica, Marco Lisi, Alessandro Golkar, An implementation of software de-
fined radios for federated aerospace networks: informing satellite implementations
using an inter-balloon communications experiment, Acta Astronaut. 123 (2016)
470–478 Special Section: Selected Papers from the International Workshop on
Satellite Constellations and Formation Flying 2015 https://doi.org/10.1016/j.
actaastro.2015.12.043.
[32] J.A. Buchmann, E. Karatsiolis, A. Wiesmaier, Introduction to Public Key
Infrastructures, Springer Publishing Company, 2013 Incorporated.
[33] S. Goldwasser, S. Micali, R.L. Rivest, A digital signature scheme secure against
adaptive chosen-message attacks, SIAM J. Comput. Times 17 (2) (1988) 281–308,
http://dx.doi.org/10.1137/0217017.
[34] W. Diffie, M.E. Hellman, New directions in cryptography, Information Theory, IEEE
Transactions on 22 (6) (1976) 644–654, http://dx.doi.org/10.1109/TIT.1976.
1055638.
[35] I.C. Paar, I.J. Pelzl, Introduction to public-key cryptography, Understanding
Cryptography, Springer, 2010, pp. 149–171.
[36] W. Diffie, P.C. Van Oorschot, M.J. Wiener, Authentication and authenticated key
exchanges, Des. Codes Cryptogr. 2 (2) (1992) 107–125, http://dx.doi.org/10.1007/
BF00124891.
[37] D. Davis, R. Swick, Workstation services and Kerberos authentication at project
athena, Massachusetts institute of technology. Laboratory for computer science
MIT/LCS/TM-424X, http://publications.csail.mit.edu/lcs/pubs/pdf/MIT-LCS-TM-
424.pdf, (1990).
[38] S.M. Bellovin, M. Merritt, Limitations of the Kerberos authentication system,
76
Acta Astronautica 149 (2018) 61–76
Comput. Commun. Rev. 20 (5) (1990) 119–132, http://dx.doi.org/10.1145/
381906.381946.
[39] Yee, Peter, Updates to the Internet X. 509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile.
[40] M. Burrows, M. Abadi, R.M. Needham, A logic of authentication, Proceedings of the
Royal Society of London a: Mathematical, Physical and Engineering Sciences, Vol.
426, the Royal Society, 1989, pp. 233–271, , http://dx.doi.org/10.1145/77648.
77649.
[41] Behnam Rahnama, Atilla Elci, Applying ParseKey+ as a new multi-way client and
server authentication approach to resolve imperfect counter utilization in IEEE802.
11i for impersonation avoidance, Security of Information and Networks:
Proceedings of the First International Conference on Security of Information and
Networks (SIN 2007), Trafford Publishing, 2008, p. 308.
[42] International Organization for Standardization, Information technology - security
techniques - entity authentication - Part 3: mechanisms using digital signature
techniques, ISO/IEC 9798–3.
[43] R. Zuccherato, Key Authentication, Springer US, Boston, MA, 2011, pp. 678–679,
http://dx.doi.org/10.1007/978-1-4419-5906-5_83 https://doi.org/10.1007/978-1-
4419-5906-5_83.
[44] R. Bird, I. Gopal, A. Herzberg, P. Janson, S. Kutten, R. Molva, M. Yung, Systematic
Design of Two-party Authentication Protocols, in: Advances in Cryptology-
crypto’91, Springer, 1991, pp. 44–61, http://dx.doi.org/10.1007/3-540-46766-1_3.
[45] K. Gaarder, E. Snekkenes, Applying a formal analysis technique to the CCITT X. 509
strong two-way authentication protocol, J. Cryptol. 3 (2) (1991) 81–98, http://dx.
doi.org/10.1007/BF00196790.
[46] R.L. Rivest, A. Shamir, L. Adleman, A method for obtaining digital signatures and
public-key cryptosystems, Commun. ACM 21 (2) (1978) 120–126.
[47] C. Underwood, S. Pellegrino, V.J. Lappas, C.P. Bridges, J. Baker, Using cubesat/
micro-satellite technology to demonstrate the autonomous assembly of a re-
configurable space telescope (aarest), Acta Astronaut. 114 (2015) 112–122 https://
doi.org/10.1016/j.actaastro.2015.04.008 http://www.sciencedirect.com/science/
article/pii/S0094576515001642.
[48] National Security Agency, Suite B Cryptography, NSA, URL: https://www.iad.gov/
iad/programs/iad-initiatives/cnsa-suite.cfm.
[49] Daniel J. Bernstein, Niels Duif, Tanja Lange, Peter Schwabe, Bo-Yin Yang, High-
speed High-security Signatures, Springer Berlin Heidelberg, Berlin, Heidelberg,
2011, pp. 124–142 https://doi.org/10.1007/978-3-642-23951-9_9.
[50] Daniel J. Bernstein, Tanja Lange, Peter Schwabe, The Security Impact of a New
Cryptographic Library, Springer Berlin Heidelberg, Berlin, Heidelberg, 2012, pp.
159–176, http://dx.doi.org/10.1007/978-3-642-33481-8_9 https://doi.org/10.
1007/978-3-642-33481-8_9.
[51] FIPS, PUB, 197: the Official AES Standard, Figure 2: Working Scheme with Four
LFSRs and Their IV Generation LFSR1 LFSR, (2001), p. 2.
[52] Smart, Nigel P, Modular Arithmetic, Groups, Finite Fields and Probability, Springer
International Publishing, Cham, 2016, pp. 3–25, http://dx.doi.org/10.1007/978-3-
319-21936-3_1.
[53] Jivsov Andrey, RFC 6637: Elliptic Curve Cryptography (ECC) in OpenPGP, (2012).
[54] S. Blake-wilson, N. Bolyard, Sun Microsystems, V. Gupta, C. Hawk, B, Moeller and
Ruhr-uni Bochum, Elliptic Curve Cryptography (ECC) Cipher Suites for Transport
Layer Security (TLS), RFC4492, (2006).
[55] Dang, Quynh H., Secure Hash Standard, Federal Inf. Process. Stds. (NIST FIPS)-
180–184.
[56] D.J. Bernstein, N. Duif, T. Lange, P. Schwabe, B.-Y. Yang, High-speed high-security
signatures, J. Cryptograph. Eng. 2 (2) (2012) 77–89, http://dx.doi.org/10.1007/
s13389-012-0027-1 https://doi.org/10.1007/s13389-012-0027-1.