For decades, the designs of military, government and commercial satellite systems from space-capable nations have been on the most part, proprietary. This is in part due to the nature of the tasks these satellites were performing, those related to national security and sending sensitive data, or to protect satellite operator’s intellectual property, although academic institutions generally detail the hardware and software in use in their satellite experiments. This section analyses key technologies of the New Space era.
Space segment
CubeSats One of the notable developments in satellites in New Space is the CubeSat specificationFootnote 9. Developed by California Polytechnic State University and Stanford University in 1999, the CubeSat specification encourages interest and skill development of small satellite manufacture and design whilst reducing costs and time efforts. The specification stipulates fixed dimensions of \(10\hbox { cm} \times 10\hbox { cm} \times 11.35\hbox { cm}\) and a total mass of 1.33 kg for the base unit (1U). CubeSats can be increased in size and mass by an order of units; common sizes are 3U and 6U, and even 20U in [16]. Other classifications for small satellites exist based upon their mass, as given in Table 4. 1U CubeSats belong to the picosatellite category.
Table 4 Small satellite classifications CubeSats are steadily becoming a part of global computing infrastructure, where components need to be protected from adversarial physical access. Sensitive computation often has to be performed in a trusted execution environment (TEE), which, in turn, requires tamper-proof hardware. If the computational fabric can be tampered with, the correctness of the computation cannot be trusted. A recent study [48] has demonstrated this approach, providing a practical hardware security module solution for space and using them as a root of trust for a certificate authority (CA). CubeSats have also been used to demonstrate quantum key distribution (QKD) [49], a series of post-quantum secure cryptographic techniques for sharing a secret key among two parties (cf. Sect. 4.5).
COTS components, open source and GPL-licensed products The space industry has taken advantage of the global boom of affordable and powerful commercial electronics. The use of COTS components in academic endeavours is commonplace due to the limited budgets of research projects, but it has also provided a platform to examine and exhibit these technologies in-orbit. It seems a likely conclusion that satellite start-ups originating from university students will continue COTS practices to build upon their academic experience. In addition, the time and cost savings are a strong driver for COTS use across the entire commercial sector.
Details of satellites designed and constructed by academic institutions with COTS components in mind are prevalent. Many of these constructions utilize field programmable gate arrays (FPGAs), system-on-chip (SoC) components and microcontrollers. These satellites also make use of the open-source real-time operating system such as “XilKernel” [50], FreeRTOS [51]. Other open-source software and hardware designs specifically for space and ground systems include KubOSFootnote 10, UPSatFootnote 11 and EQUiSatFootnote 12.
In recent years, some companies have been more forthcoming about their satellite architectures, mainly those which implement COTS technologies. Section 2.3.1 details the information known about the construction of Planet and HawkEye 360’s satellites. Planet also released an open-source radio solutionFootnote 13 which has been deployed in each of its satellites, providing both hardware and software tools.
The trend towards use of COTS software and hardware is driven by several factors, including significantly lower procurement cost. COTS products are often highly complex, some of them involving tens of millions of lines of code, so that no one knows their content and behaviour in detail. Legacy systems make up the vast bulk of the code base, and all new systems become legacy when they come on line. With this complex system, COTS products are essentially a black box to their users. The US government provides a list [52] of risks associated with employing COTS software and mitigation techniques to avoid them. The usage of COTS products, thus, needs to be met with vigorous security analysis through black-box testing mechanisms (e.g. fuzzing, boundary value analysis, equivalence partitioning) using COTS tools [53] or be checked for compliance with known security guidelines like STIG (Security Technical Implementation Guides)Footnote 14 and OWASP Top TenFootnote 15 for software and FIPS 140-3 [54] for hardware before being deployed in use.
Software-defined radios (SDRs) One of the major technology advancements made in the New Space era is SDRs, which “represent a radio that has software control over some functions, and still being partly implemented in analog electronics” [55]. Functionality traditionally implemented in hardware—filters, modulators, mixers—is now moving to software. This technology affords space systems with flexibility and reconfigurability, whilst also removing the need for dedicated hardware to save space on satellite buses. SDRs such as RTL-SDR, USRP and LimeSDR are commonly available for purchase.
This move to SDRs shows a shift between the technologies in Old Space and New Space. For Old Space, radio communications were achieved through traditional dedicated radio hardware. The relationship between satellite hardware, software and the Open Systems Interconnection (OSI) model, which abstracts communications into seven separate layers, typically falls into the one shown on the left side of Fig. 7. Hardware is used for the physical and data link layers, with software covering the other five layers and optionally the data link layer. SDRs implement functions that originally resided in hardware, but now in software, encapsulating the physical, data link and network layers, demonstrated in the right side of Fig. 7. More parts of the communications stack consist of software instead of hardware, reducing satellite reliance on hardware but opening the system to software threats. Traditional radio components have in-built limitations, such as specific frequencies and filter ranges. Trusted hardware functions are now in software, so future implementations must consider how to trust software to behave as intended and in a secure manner.
Authentication of signals is a critical aspect of secure communication. Most mechanisms of authentication (e.g. digital signatures and certificates) exist above the physical layer, though some (e.g. spread-spectrum communications) exist at the physical layer often with an additional cost in bandwidth. The use of SDRs at physical layer has provided low-cost authentication solutions using various software techniques like fingerprint embedding where a low-power secret modulation is superimposed over the message waveform which serves as an authentication tag [56, 57].
Although SDRs provide significant advantages over hardware techniques, they introduce protocol-independent software vulnerabilities into the system. In the process of securing SDRs, several integrated components have been proposed. A survey paper [58] on the security of SDRs discusses the threat model SDR faces and architectures proposed to mitigate them. Notably, a secure SDR architecture proposed [59] is composed of an automatic and calibration unit (ACU), a radio security module (RSM) and a location component based on a GNSS receiver (cf. Fig. 8). The ACU controls the output spectrum to be compliant with the local spectrum regulations. The SDR stores the information (e.g. spectrum configuration files) on the spectrum regulations in various spectrum jurisdictions in the world. The GNSS receiver in-built provides the location of the SDR at any given time; the ACU uses the location and the spectrum configuration files to determine the correct spectrum regulations.
The ACU represents a protection technique against security threat if the SDR services are related to transmission and communication of signals. Even if a malicious waveform is activated in the SDR node, the ACU can prevent it from transmitting in unauthorized bands. The RSM is responsible for download, activation and execution of the software modules. With the potential harm that malicious SDR code could cause, the veracity of the RSM functions is critical; therefore, these functions must be implemented with a suitable level of trust.
A popular digital signal processing software used with SDRs is GNU radio, which provides standardized signal processing blocks to implement radio communications with SDRs, either with real RF hardware or in a simulated environment. It has been used widely in academic circles (for instance in [60,61,62,63]) with some confirmed usage in the commercial sector [17, 64].
SDR usage is becoming more widespread with significant numbers of “How To” guides on satellite eavesdropping with SDRs available on the Internet, e.g. [65, 66] detail how to obtain weather satellite imagery using SDRs, [67] provides commentary on using an SDR to listen on transmissions from spacecraft travelling to the International Space Station (ISS), and a tutorial for decoding messages from the satellite communications provider Inmarsat is available from [68].
Ground segment
Automation and autonomy Autonomy has made great strides in the past few decades with autonomous vehicle prototypes in action and great leaps made in robotics. Autonomous operations are those in which a system performs self-regulating and self-controlling actions and have been attempted to be implemented in the ground segment since the late 1980s [69]. Strides have been taken to provide autonomy in space rovers—NASA’s Curiosity rover employed autonomy in areas such as navigation and sample selection [70, 71].
The ability of a ground station and mission control centre to command, control and receive payload transmissions for satellites without the need for human interaction is a desirable one. Automation helps to reduce costs but also enable scalable and complete management of potentially large numbers of satellites belonging to a constellation [72].
Experimentation of autonomous ground station and on-orbit operations has been developing, with examples provided in [72,73,74,75], reporting successful demonstrations of autonomous operations. Autonomy has also expanded to commercial interests with SpaceX releasing Starlink constellation information which states that satellites are “capable of tracking on-orbit debris and autonomously avoiding collision” [76].
Commercial interests, such as Planet, have already incorporated automated procedures in both their software and firmware development and in the satellite commissioning stages, which are expanded upon in [14]. Initially, a ground-based software process, Planet, moved to on-board commissioning software due to the unscalability of their original process for an entire constellation. Forty-seven out of 88 of its satellites were able to complete the commissioning process completely automated. Out of the 150 calibration manoeuvres for ADCS across all satellites, 110 were fully automated. Whilst not a perfect run, these automated operations allowed satellites to be commissioned by teams of 1–2 operators, reducing their involvement and increasing the efficiency of the entire process.
Cloud computing Cloud computing is a strong candidate to provide part of ground segment infrastructure, moving processing and storage away from personal computers to large data centres, accessed over the Internet. Cloud computing affords greater flexibility and availability with multiple sites for redundancy and provides an independence from location or device-type restrictions [77]. Planet’s imagery data and mission control software are hosted in the cloud and customer’s access imagery through web-based protocols.
From an education and amateur standpoint, networks such as the Satellite Network Open Ground Stations (SatNOGS)Footnote 16 and Global Educational Network for Satellite Operations (GENSO)Footnote 17 (no longer actively maintained), provide software and hardware details to begin tracking satellites with the use of cloud computing architecture. These implementations use client software to operate the ground station after receiving instructions through their network, with telemetry data available for access over the Internet.
Some ground station operators such as KSAT [78], who provide these capabilities for Earth-i and HawkEye 360 [79, 80], have already adopted cloud-based technologies to manage customer’s scheduling needs through browser-based applications [81]. RBC signals, a satellite ground station network operator, confirmed that it had plans to implement cloud-based mission control software developed by KubOS [82].
Even Amazon is transitioning into the space arena after success in ecommerce and cloud platforms, providing ground stations as a serviceFootnote 18. Space sector companies such as DigitalGlobe, BlackSky, Spire Global, Capella Space and Open Cosmos are reported to be its first customers [83].
Whilst cloud providers can guarantee some measurable non-functional performance metrics, e.g. service availability or throughput, there is lack of adequate mechanisms for guaranteeing certifiable and auditable security, trust and privacy of the applications and the data they process. For example, there exists a fragile transparency in the trustworthiness of remote satellite imagery from cloud providers because of conflicting policies between them and governments on grounds of international security [84]. Object Management GroupFootnote 19 provides a list [85] of cloud security standards and certification to be expected from the providers before moving to a service. In addition to the general standards and frameworks, there are others that operate at country or regional levels or that apply to specific industries (e.g. PCI DSS) or to specific types of data (e.g. HIPAA, GDPR). It is impertinent that cloud customers continually review service provider security controls and standards to ensure they are properly defined and enforced as this is the sole security guarantee from a cloud provider.
Edge computing An abstraction of cloud computing, edge computing [86], leverages processing within a closer local network to perform operations typically performed in cloud services. This brings applications and data to a closer location to the user, reducing latency in networks.
Edge computing has been used with Internet of things (IoT) devices, especially sensors which provide readings for processing to nearby edge devices. System decisions can then be made based upon readings and then data sent to the cloud afterwards. An example of this is smart cities where sensors readings across cities provide edge devices the data to make decisions to influence transportation, energy and crime [87].
IoT devices, edge computing and satellites have already become intertwined. The Australian-based company Fleet provides a gateway device containing an edge server, satellite modem and antenna which connects to IoT devices. This gateway collects, processes and analyses sensor data and uses their satellite communications network to send only the relevant information to a business’s central cloud infrastructure [88].
Space protocols and their security
Satellite communication links often suffer from higher error rates and latencies than terrestrial cabled networks and, in the case of LEO satellites, only have a small window of time to communicate whilst in range of a ground station. Communication protocols have often been lightweight to lower the resource requirements of satellites.
The CCSDS has created a set of protocols for telemetry, telecommand and OSI model layers (application, transport, etc.). Adapted to support protocols from the IP suite, CCSDS is making data communications more accessible and familiar for new enterprises in the space industry [89]. The implementation and demonstration of these protocols have been noted in over a thousand missions listed on the CCSDS website at [90], with several commercial telecommunication satellites using CCSDS command and control capabilities.
Surveys on satellite communication protocols are presented in [91, 92] which summarize current protocols in use. This section aims to provide a more extensive overview into their security.
Physical One of the most widely used satellite services is satellite TV. The majority of satellite TV broadcasts is achieved using DVBFootnote 20 protocols, i.e. DVB-S, DVB-S2, DVB-SH. These physical (and data link) layer protocols standardize methods to broadcast television signals globally, and encryption can be applied on top of these transmissions. The conditional access system (DVB-CA) defines a common scrambling algorithm (DVB-CSA) and a physical common interface (DVB-CI) for accessing encrypted content. DVB-CA providers develop their wholly proprietary conditional access systems with reference to these specifications. Cryptanalysis of the common scrambling algorithm [93,94,95] provides intuition for the vulnerability of the algorithm to several generic attacks. However, no feasible attack against the protocol with considerable advantage has been published yet. Constellation companies Planet and LeoSat propose to use DVB protocols for imagery downlinks [14] and “both earth-to-satellite and satellite-to-earth links” [26] respectively.
Optical communications A recent development in satellite communications is the use of optical communication payloads using visible light communications (VLCs). These can provide higher data rates whilst steering clear of radio frequency electronic warfare activities such as jamming and avoiding exhausting the RF spectrum. Whilst affected by cloud coverage, making them less fitting for ground to space links, they are suitable for inter-satellite links.
Already large optical payloads have been demonstrated in satellites such as Artemis, Spot-4, Envisat Adeos-II, OICETS, Kodama, DAICHI and SDS-1 at extremely high wireless data rates [96]. NASA’s Laser Communication relay [97] aims to discover whether optical communication transceivers can be built with similar mass and power requirements to a traditional RF system. Broadband constellation plans such as Starlink and LeoSat aim to use laser communications for inter-satellite links to reduce latencies in their networks.
Optical communication can be secured by quantum cryptographic techniques using QKD (cf. Sect. 4.5). A less secure but significantly studied in the literature method of securing communication is chaotic encryption [98,99,100]. It can be realized by encoding the message using chaotic carriers. The objective of chaos hardware encryption is to encode the information signal within a chaotic carrier generated by components whose physical, structural and operating parameters form the secret key. Once the information encoding has been carried out, the chaotic carrier is sent by conventional means to a receiver. Decoding of the message is then achieved directly in real time through a so-called chaos synchronization process [101]. However, chaotic cryptosystems have proven to be insecure because of the inadequacy of logistic maps used for encryption [102] (Fig. 9).
Data link Educational and small satellites have been noted to use various simplistic data link protocols, some of which were originally designed for amateur packet radio such as AX.25Footnote 21, offering data frame processing and fault detection, but not error correction. Other data link protocols such as the unified space link protocol (USLP), new satellite data link protocol (NSLP), low-altitude multiple satellite data link control (LAMS-DLC), Proximity-1 and Nanolink, detailed in [91], provide similar data framing services and varying degrees of error correction and reliability procedures, but no built-in security.
Low-impact educational missions do not immediately prompt for more complex and security-driven protocols; however, commercial enterprises such as Planet also reported using the AX.25 protocol [103]. These organizations often have greater needs for confidentiality and privacy, for which these types of lightweight protocols may not be suitable.
The CCSDS Space Data Link Security (SDLS) protocol [104] extends its data link protocols to incorporate confidentiality services through encryption of the frame data, authentication and integrity through authenticated and non-authenticated message authentication codes (MACs), respectively, and anti-replay protection through the use of sequence numbers. The scheme is designed and analysed in adherence to the security concerns mentioned in ISO 7498-2 [105]. The protocol, overall, attempts to offer confidentiality, integrity and/or authenticity of the transmitted data. However, it fails to provide guarantee against DDoS by jamming, traffic flow analysis and data substitution attack if the encryption does not use authentication.
Networking and transport Network protocols such as the Space Packet Protocol (SPP) and Delay Tolerant Network Bundle Protocol (DTN BP) allow for asynchronous data transfers, suitable for data transmission delays found in satellite communications. Broadband services commonly use IP protocols. Reliability services emerge through transport protocols. The space communications protocol specification-transport protocol (SCPS-TP) based upon TCP and Licklider Transmission Protocol (LTP) which can run over UDP or the data link offer such services. The TP stack was actually designed as a part of SCPS protocol suite, with an SP security layer, FP file transfer and NP network protocol intended to replace IPSec, FTP and IP, respectively. However, with the evolution of the Internet and supporting protocols, these other SCPS layers have become irrelevant. TCP has historically been deemed ill-fitting for space due to its bad performance [106]; however, these newer space-related protocols are designed to balance the high error rates and latency issues which lower TCP performance. Alternatively, TCP performance enhancing proxies (PEPs) are widely used to overcome the limitations of TCP over satellite links. This is known as TCP splitting [107], where each overlay hop between each PEP is considered as a new TCP connection.
IPSec provides authentication and encryption of data packets to provide secure encrypted communication between two computers over an IP network. However, TCP PEPs are not compatible with IPSec [108] as PEPs need to analyze the headers of TCP segments and IP packets between two ends to route the packets through suitable PEPs. Since IPSec tunnels mask the content of the IP packets, in particular the source and destination of data, it is impossible to implement a PEP through a IPSec tunnel. Several solutions [109,110,111] have been proposed to circumvent this issue by either adding additional information to the packet or selective usage of the IPSec protocol.
The CubeSat Space Protocol (CSP)Footnote 22 provides a simple design to achieve networking and transport services, which also compatible with several different physical and data link protocols. CSP includes encryption and integrity features with the use of the XTEA [112] algorithm for encryption of packets and HMAC-SHA1 [113] for message authentication. Although these algorithms have known cryptographic weaknesses [114,115,116] that undermine these security features, they are preferred for their lightweight operation on CubeSat’s embedded systems.
For securing communications for the CCSDS Space Packet protocol, in [117], the use of encryption and digital signatures is prescribed to increase security. The encryption lies solely on the application data and not the header of packets, and the digital signature or an integrity check value (ICV) is appended to the end of the encrypted data. Some drawbacks appear with this implementation namely that the header remains in cleartext; this solution offers no anti-replay protection, and it may be possible to differentiate between encrypted and unencrypted packets from the header.
Application Whilst application layer protocols are usually mission dependent, we note some file transfer protocols that are currently in use: CFDP [118] developed by CCSDS and Saratoga [119] developed by SSTLFootnote 23. Whilst Saratoga is designed to operate over IP and is suitable for short LEO satellite passes, CFDP combines functionalities from both the application and transport layers to ensure reliable file delivery over multiple types of link with minimal resource consumption.
Application layer security controls can be applied to the communication stack; however, security considerations provided at lower protocols, at the network, data link or physical layers, may be sufficient for some missions. [117] lists the transport layer security protocol and X.509 certificates [120] as a way to implement encryption and authentication controls, though the verification of certification chains renders this protocol unsuitable for space owing to long latency times whilst handshaking [121].
User segment
The user segment deals with the applications of satellite systems. Applications such as navigation, TV and communications often require dedicated hardware. Other systems use the data that these dedicated receivers collect to serve a specific product or application. For satellite TV transmissions, a dish and set-top box must be installed to receive the particular channels provided and perform subsequent tuning and decoding of transmissions for viewing. For navigation purposes, a GNSS receiver acquires signals from a constellation to determine the location of the receiver. Applications use data from GNSS receivers in mobile phones or satellite navigation devices to plan routes, e.g. WazeFootnote 24.
Alternatively, instead of consumers having the ability to receive satellite signals themselves, a satellite operator may collect all data themselves and then distribute it via terrestrial networks. Earth observation, signal intelligence, metrological and scientific applications typically make use of this. This way, customers do not need to install or buy hardware to get access to the data. Access to the data is managed by the operator, and key technologies include web APIs and customer web portals, often cloud-based, or dedicated installable software. Planet and HawkEye 360 provide various apps and APIs to access imagery and signal mapping data for customers. Scientific data may be free to access and download from the web, e.g. datasets from the International Satellite Cloud Climatology Project (ISCCP) are accessible from their website [122].
Cryptography for New Space
Novel cryptographic mechanisms are emerging in the satellite industry. Navigation message authentication (NMA) is an authentication mechanism to provide authenticity and integrity of the navigation data to the receiver. NMA can use both or either of the symmetric/asymmetric key encryption approaches to achieve this goal.
The Chips Message Robust Authentication (CHIMERA) [123] is a hybrid NMA and spreading code authentication mechanism proposed for GPS signals. It achieves NMA using asymmetric elliptic curve digital signature algorithm (ECDSA) P-224, a well-established standard. However, CHIMERA requires receivers to have occasional access, via-non-GPS channels, to provide authenticated GPS public keys and a public key infrastructure (PKI) to verify the authenticity of the key provided.
The Galileo GNSS, as part of message authentication of its public open service, will incorporate the established Timed Efficient Stream Loss-tolerant Authentication (TESLA) protocol [124] with a novel single one-way chain of cryptographic keys shared by all satellites. The TESLA protocol has low computational and communication overhead and can also support one-to-many transmissions, making it a suitable choice for GNSS. The TESLA protocol uses MAC to prove the origin and identity of a message. The key to compute the MAC, belonging to a chain generated by a one-way function, is sent some time after the message and the MAC.
In the Galileo Open Service implementation [125], different keys are transmitted to user receivers from different satellites, but the keys are still from the same chain. The keys are transmitted in the reverse order of their computation from the chain. Hence, using the one-way function, the receiver can verify that each chain key is from the same chain as the root key by recomputing the chain. However, it is impossible to predict future keys by adversaries as it is computationally hard to invert an one-way function. Cryptanalysis of the architecture shows that with current proposed parameters, combined with the use of efficient hashing hardware, it can lead to a feasible attack with significant collision probability [126]. Whilst increasing robustness of transmissions against data losses and in difficult visibility conditions, it also allows cross-authentication of neighbouring satellites.
The symmetric key encryption style of TESLA eliminates the PKI requirement posted by CHIMERA. However, the main disadvantage of the scheme arises from their security condition; it requires a coarse time synchronization between the sender and the receiver. Without this assurance, the receiver cannot be certain that the navigation message has not been generated by a spoofer who received the valid signing key from the satellite signal.
Variants of TESLA protocol include \(\mu \)TESLA [127], inf-TESLA [128] and multi-level \(\mu \)TESLA [129] which have been proposed for wireless sensor networks to overcome the disadvantages of the TESLA protocol. Still, performance analysis has not been performed for them with respect to GNSS satellite links.
QKD allows two parties to establish a secret key with unconditional post-quantum security by making use of the fundamental laws of quantum mechanics. QKD occurs in two phases, namely the quantum phase, where quantum superimposed signals are exchanged between the two parties establishing the raw key for each party. The second phase is the classical phase, where interactive key exchange protocols are used to distil two identical strings from the raw key [130].
Optical communication networks provide ideal channels for exchange of quantum photons. However, glass in the optic fibres tends to absorb the photons, increasing the error rate of the transmitted signals. Since security bound for quantum security provides a maximum error rate of 11% for transmission [131], the use of optic fibres is limited to a distance of few hundred kilometres for appreciable security.
On the other hand, by using satellites equipped with high-quality optical links, satellite-QKD can achieve ultra-long-distance quantum communication in the 1000 km range. Hence, optical free space links are currently the most promising channel for large-scale quantum communication by use of satellites and ground stations. The usage of a satellite terminal in space makes it possible to develop quantum communication networks on a global scale [132]. Significant experimental efforts have been devoted to investigating the feasibility of satellite-based quantum communications. NanoBob [133], QEYSSat [134] and NanoQEY [135] are some key advances in quantum research to establish a practical satellite QKD system.