A safe programming language is one that is memory-safe (see Definition 1), type-safe (see Definition 2) and thread-safe (see Definition 3).

A significant percentage of software vulnerabilities have been attributed to memory safety issues [NSA22], hence memory safety is of critical importance.

Examples of violations of memory safety can be found in the discussion of common weakness CWE-787 and CWE-125.

Type safety ⇒ memory safety, but the converse is not true [SM07, Sec. 6.5.2], hence type safety is commonly considered to be a central theme in language-based security [Fru07].

Type-safe programming languages, e.g., Java , Ruby, C#, Go, Kotlin, Swift and Rust, have been around for a while. However, memory-unsafe languages are still being used because:

• Type-safety features come at the expense of performance. There is for example overhead associated with checking the bounds on every array access [NSA22].

  Even the current speed champion, Rust, among the type-safe languages, and the only type-safe language that has made it to the Linux kernel [VN22] and Windows kernel [Thu23], is not efficient enough for all use cases [Iva22]. This is one of the reasons why Google is still trying to create a successor to C++ called Carbon.

• Type-safety features also come at the expense of resource requirements. Most memory-safe languages use garbage collection for memory management [NSA22], and this translates to higher memory usage.

• Although most type-safe languages are supported on the mainstream computing platforms (e.g., Wintel), the same cannot be said of embedded platforms.

  It can be challenging to program a resource-constrained platform using a type-safe language.

• There is already a vast amount of legacy code in C/C++ and other memory-unsafe languages.

  The cost to port legacy code, including the cost of training programmers, is often prohibitive.

  Depending on the language, interfacing memory-safe code with unsafe legacy code can be cumbersome.

• Besides invoking unsafe code, it is all too easy to do unsafe things with a type-safe language, e.g., not checking user input, not implementing access control.

  Programmers often use this as an excuse to not use a different language than what they are familiar with.

Nevertheless, adoption of type-safe languages, especially Rust, has been on the rise [Cla23].

Thread safety rounds up the desirable properties of type-safe languages.

Watch the following LinkedIn Learning video about thread safety:

Thread safety from IoT Foundations: Operating Systems Fundamentals by Ryan Hu

Rust is an example of a type-safe language that is also thread-safe.

Fig. 1 depicts the usage of different frequency bands.

IEEE Standard 512 [IEE20] defines the letters designating the frequency bands.

According to ESA, the main satellite frequency bands range from L to Ka; see also the same link for discussion of different usage of the frequency bands.

The increasing usage of cutting-edge technologies in safety-critical applications leads to strict requirements on the detection of defects both at the end of manufacturing and in the field [VDSDN+19].

This gives birth to the design-for-testability (DFT) paradigm, which necessitates additional test circuits to be implemented on a system to 1️⃣ provide access to internal circuit elements, and thereby 2️⃣ provide enhanced controllability and observability of these elements [BT19, Sec. 4.7.1].

Scan is the most popular DFT technique [BT19, Sec. 3.7.2].

• The technique of scan design (see Definition 1) offers simple read/write access to all or a subset of the storage elements in a design.

  Definition 1: Scan design [IEEE13, p. 10]

  A design technique that introduces shift-register paths into digital electronic circuitry, providing controllability and observability in deeply embedded regions of circuity and thereby improving testability.

• Scan design is realised by replacing flip-flops by with scan flip-flops (SFFs, see Fig. 1) and connecting them to form one or more shift registers in test mode.

  Watch YouTube video for a revision of D-type flip-flip:

• SFFs are generally used for clock-edge-triggered scan design, whereas level-sensitive scan design (LSSD) cells are used for level-sensitive, latch-based designs.

A scan chain is a chain of SFFs [BT19, Sec. 3.7.2.2]; see Fig. 2.

When Test Enable (TE) is high, the scan chain works in test/shift mode [BT19, Sec. 3.7.2.2; VDSDN+19, p. 95].

• Inputs from the Scan In (SI) pin are shifted through the scan chain to the Scan Out (SO) pin.
• The circuit is then set to normal mode and run for a specified number of clock cycles.
• When the circuit reaches a target state, the circuit is switched back into test mode and the content of the scan chain is shifted out from the SO port.
• Finally, a test program compares the SO values with the expected values for validation.

Multiple scan chains are often used to reduce the time to load and observe.

The integrity of a scan chain should be tested prior to application of a scan test sequence.

For more information, see the attachment.

The discussion below provides some historical context, an overview and a description of the network protocol stack of the Solar System Internetwork (SSI).

History

In 1999, the Interagency Operations Advisory Group (IOAG) was established to achieve cross support across the international space community and to expand the enabling levels of space communications and navigation interoperability [CCS14, Foreword].

In 2007, the IOAG chartered a Space Internetworking Strategy Group (SISG) to reach international consensus on a recommended approach for transitioning the participating agencies towards a future network-centric era of space mission operations [CCS14, Foreword].

In 2008, the SISG released a preliminary report on their operations concept for a Solar System Internetwork (SSI) [CCS14, Foreword]; see the 2011 conference version of the report [EDB11].

In 2010, the IOAG finalised the SSI Operations Concept and asked the Consultative Committee for Space Data Systems (CCSDS) to create the SSI architectural definition [CCS14, Foreword].

In 2014, the CCSDS Space Internetworking Services - Delay-Tolerant Networking (SIS-DTN) working group released the official informational report [CCS14].

The SSI architecture is based on international standards and voluntary agreements [CCS14, Executive Summary].

Participation in the SSI is expected to be incremental, and furthermore, the SSI specification and technologies are still evolving.

In fact, the Interplanetary Networking Special Interest Group (IPNSIG), a chapter of the Internet Society, has the vision to develop a secure and robust Solar System Internet, by extending networking to space, from the historical point-to-point, “bent pipe” communication architecture to a store-and-forward, packet-switched design, interconnecting any number of terrestrial and space-borne nodes [KCB+21].

Overview

The fundamental objective of the SSI is to provide automated and internetworked data communication services for space ventures (at least across the solar system) [CCS14, Executive Summary; EDB11, Sec. 2].

The emphasis on automation arises from the need to support communication among the various participants operating in space ventures without requiring a detailed understanding of space communication operations [CCS14, Executive Summary].

Examples of participants include [CCS14, Sec. 2.1]:

• crewed and robotic space-faring vehicles, often carrying investigative instruments;
• planetary surface systems, with crew and/or instruments;
• ground antenna stations;
• centralised ground-based mission operations centres (MOCs) on Earth;
• science investigators at widely distributed laboratories on Earth.

The SSI interconnects multiple networks built on two types of networking architectures, namely 1️⃣ the Internet architecture and 2️⃣ the DTN architecture.

Fig. 1 depicts a communication scenario that the SSI architecture is designed to support.

In Fig. 1,

• Multiple missions may be involved, and each mission may operate multiple spacecrafts, which may autonomously collaborate on mission objectives.
• The set of spacecrafts conducting a long-lived mission may change over time, as disabled spacecrafts become decommissioned and new spacecrafts get deployed.
• Data may be routinely relayed among spacecrafts, even among spacecrafts deployed for different missions, by different space agencies. Furthermore, data may be relayed through different spacecrafts at different times, introducing the possibility of multiple data paths between spacecrafts and MOCs.

To accommodate the multi-agency, multi-mission scenario in Fig. 1, the SSI architecture specifies three stages of functionality:

• Stage 1 Mission Functionality
• Stage 2 Internetwork Functionality
• Stage 3 Advanced Functionality

Protocol stack

The SSI protocol stack is a combination of the Internet Protocol (IP) stack and the Delay-Tolerant Network (DTN) protocol stack, as shown in Fig. 2.

Going top-down along the DTN “facet” (CCSDS term) [CCS14, Sec. C3],

• DTN applications are applications designed to operate with communications characterised by variable, substantial latencies due to 1️⃣ large signal propagation delays, 2️⃣ lengthy physical communication outages, or 3️⃣ both.

  These applications are implemented to utilise the CCSDS File Delivery Protocol (CFDP) and optionally other DTN application-layer services over a Bundle Protocol (BP) network.

• The BP network runs over the Licklider Transmission Protocol (LTP).

  While protocols from the IP suite are limited to scenarios in which network paths are continuously connected and have low latencies, BP network can operate in any scenario in the SSI, including on top of TCP/IP, as Fig. 3 shows.

• Fig. 3 also shows below the LTP layer, sit the Encapsulation Packet Protocol and Space Packet Protocol.

  The Space Data Link Protocols (SDLPs) sit further down the protocol stack.

• Among the SDLPs, the Proximity-1 Space Link Protocol is defined for short-range, bi-directional, fixed or mobile radio links, generally used to communicate among probes, landers, rovers, orbiting constellations, and orbiting relays.

  The 1️⃣ Telecommand (TC) SDLP, 2️⃣ Telemetry (TM) SDLP, and 3️⃣ Advanced Orbital Systems (AOS) SDLP [CCS15d] serve other scenarios.

  Fig. 4 demonstrates the usage of AOS-SDLP in a space network and Proximity-1 in a Mars network.

  Fig. 5 demonstrates the usage of Proximity-1 between two space nodes; and the usage of AOS-SDLP and TC-SDLP between a space node and a ground terminal.

  Improving upon the preceding protocols, the Unified Space Data Link Protocol (USLP, not typo) has been designed to meet the requirements of space missions for efficient transfer of space application data of various types and characteristics over space-to-ground, ground-to-space, and space-to-space communications links [CCS21c].

  Fig. 6 maps the protocols discussed so far to the Open System Interconnection (OSI) model.

• Finally in the physical layer, RF communication and optical communication options exist (🖱 click links for details).
  

This continues from Solar System Internetwork (SSI).

The Stage 1 Mission Functionality of the Solar System Internetwork (SSI) is the automation of basic communication processes between vehicles and Mission Operations Centers (MOCs) that might be performed for a single space flight mission, including [CCS14, Sec. 3]:

• the initiation and termination of transmissions;
• the scheduling of data for transmission according to priority designations declared by SSI users;
• the segmentation and reassembly of large data items for transmission in small increments;
• the retransmission of data that were lost or corrupted in transmission;
• the relaying of data from one entity to another via some other entity pre-selected by management.

Fig. 1 depicts a sample communication scenario between two SSI nodes: one onboard the spacecraft and another at the spacecraft MOC.

• The SSI data flow between these two nodes is established by requesting a space link session from the Earth station control center.
• Data are exchanged via the Earth station by link-layer mechanisms, which are nominally based on the CCSDS Space Link Extension (SLE) service [CCS13].

The network configuration in Fig. 1 can be extended by setting up a separate SSI node for use by the instrument MOC, enabling the instrument MOC to operate on native instrument data flows securely routed through the node at the spacecraft MOC.

Prerequisites and protocols

To be part of the SSI, each node must be configured to run the Bundle Protocol (BP), i.e., a Bundle Protocol Agent (BPA) must be deployed at each node.

For each node on the Earth surface, a Convergence-Layer Adapter (CLA) must be deployed underneath BP, enabling the node to communicate with other Earth-bound nodes via the Internet.

For interoperation with the Internet, the CLA can use the Transmission Control Protocol (TCP) and User Datagram Protocol (UDP), or potentially the Licklider Transmission Protocol (LTP) running on top of UDP/Internet Protocol (IP).

The Aerospace Corporation created the Space Attack Research and Tactic Analysis (SPARTA) cybersecurity matrix

• to address the information and communication barriers that hinder the identification and sharing of space-cyber Tactic, Techniques, and Procedures (TTP);
• to provide unclassified information to space professionals about cyber threats to spacecraft.

The SPARTA matrix is a specialisation of the MITRE ATT&CK matrix for defining and categorising commonly identified activities that contribute to spacecraft compromises.

The nine SPARTA tactics shown in the top row of Fig. 1 are a subset of the tactics in MITRE ATT&CK.

Under each SPARTA tactic in Fig. 1, each of the main techniques accompanied by a double vertical sign, namely ⏸, can be divided into sub-techniques. For example, under tactic “Reconnaissance” (ST0001), the technique “Gather Spacecraft Design Information” (REC-0001) can be divided into 1️⃣ Software (REC-0001.01), 2️⃣ Firmware (REC-0001.02), 3️⃣ Cryptographic Algorithms (REC-0001.03), 4️⃣ Data Bus (REC-0001.04), 5️⃣ Thermal Control System (REC-0001.05), 6️⃣ Manoeuvre and Control (REC-0001.06), 7️⃣ Payload (REC-0001.07), 8️⃣ Power (REC-0001.08), and 9️⃣ Fault Management (REC-0001.09).

Example 1: Payload

The South Australian 6U CubeSat Kanyini has two payloads: 1️⃣ a hyperspectral imager called HyperScout 2 for earth observation, and 2️⃣ an Internet-of-Things communications module.

Example 2: Applying SPARTA to modelling a recent cyber attack

Watch a quick overview of the attack called PCspooF:

A mixed-criticality system (MCS) is an embedded computing platform in which application functions of different criticalities share computation and/or communication resources [EDN16].

A mixed time-criticality system is an MCS where the criticality is messaging timeliness.

Time-Triggered Ethernet (TTEthernet), as standardised in SAE AS6802, defines algorithms for clock synchronisation, clique detection, startup, and restart for switches and end systems to achieve fault-tolerant synchronisation in an Ethernet-based (IEEE 802.3) mixed time-criticality system.

TTEthernet is used in avionics, industrial control systems (including those for power systems) and automotive systems [LPDK23], so any security vulnerability in TTEthernet would have wide-reaching consequences.

• In avionics, TTEthernet is used as a bus service for a variety of spacecraft including NASA’s Orion capsule, NASA’s Lunar Gateway space station, and ESA’s Ariane 6 launcher [The22].

How TTEthernet works [LPDK23]

A TTEthernet network contains two types of devices: switches and end systems.

Fault-tolerance is enabled by network redundancy, and each redundant network is called a plane; Fig. 2 shows an example of a system using two planes.

Time-triggered (TT) design = All TTEthernet devices are tightly synchronised and the behaviour of the network is determined by a global schedule made offline and loaded onto each TTEthernet device before deployment.

The global schedule specifies when TT frames are forwarded and expected to arrive.

The latency and jitter of TT traffic can be reduced to below 13 μs and 1 μs respectively [Fid15, slide 12].

TTEthernet also carries best-effort (BE, i.e., regular) Ethernet traffic and rate-constrained Avionics Full Duplex Switched Ethernet (AFDX, as standardised in ARINC Specification 664 P7-1) traffic; see Fig. 3.

TTEthernet switches forward BE traffic around the pre-scheduled TT traffic when bandwidth permits.

Mechanisms exist to isolate TT traffic from BE traffic, e.g.,

• there are windows reserved for TT traffic only;
• TT and BE frames are stored in different switch buffers.

Central to TTEthernet is a synchronisation protocol, in which a device can participate as 1️⃣ a sync master, 2️⃣ a compression master, or 3️⃣ a sync client.

• Typically, a subset of the end systems serve as sync masters, while 1-2 switches per plane serve as compression masters.
• The remaining devices serve as sync clients.

Devices exchange protocol control frames (PCFs) every integration cycle.

• At the beginning of each integration cycle, every sync master sends a PCF containing its local clock value to the compression masters.
• The compression masters average the received clock values, then send out the average in a new PCF to the sync masters and clients, which then correct their local clocks.

Receiving certain PCFs from a compression master can cause sync masters and clients to lose synchronisation.

• An example of such PCFs is “coldstart acknowledgement”, which tells a sync master another sync master detected loss of synchronisation and is reestablishing it.
• Since a PCF can cause de-synchronisation, TTEthernet requires each compression master to be a self-checking pair, which only produces a PCF if two independent processors agree on the contents.

Attacker/threat model for PCspooF

The PCspooF attack is feasible provided:

• Attacker has access to at least one BE device, e.g.,
  • by supplying such a device (as a malicious supplier) for integration into the TTEthernet network before the network is deployed;
  • by connecting the device to the TTEthernet network after the network has been deployed.
• Attacker can control the BE device operating in one plane; see Fig. 4.
• Attacker-controlled BE device includes additional circuit components for conducting electromagnetic interference (EMI) through its Ethernet cable into a switch; see Fig. 5.

The PCspooF attack

PCspooF is a cyber-physical attack that attempts to disrupt the TTEthernet synchronisation protocol by spoofing PCFs, and thereby inflict denial of service on its victim.

The attack happens in two stages:

• Stage 1️⃣: This is the cyber stage, where the attacker fabricates a valid PCF.

  A PCF has the same structure as a standard minimum-sized Ethernet frame, but instead of a destination MAC address, it has a 4-byte Critical Traffic Marker (a special value used to identify all PCFs and TT traffic) and a 2-byte Virtual Link ID (also called Critical Traffic ID [Lov15], which identifies the source of a PCF); see Fig. 6.

  These two fields 👆 must match the values specified in the network schedule loaded onto the TTEthernet devices. These two fields happen to be the only fields that pose a challenge to spoof.

  Skipping the details [LPDK23, Sec. IIIA], an attacker can determine valid Critical Traffic Markers by abusing the Address Resolution Protocol and trying a maximum of around one billion possible values.

  Skipping the details again [LPDK23, Sec. IIIA], an attacker can try to use 4071 or 4070 as the Virtual Link ID, or in the worst case, try a maximum of 65536 values.

  The fabricated PCF is stored inside the payload of a benign BE frame, because TTEthernet switches drop PCFs from BE devices.

  The next stage is to trick a switch into forwarding the aforementioned BE frame as a PCF.

• Stage 2️⃣: This is the physical stage, where the attacker uses EMI to convert a BE frame into a PCF during transmission.

  This is an example of a link reset attack, which in turn is an example of a packet-in-packet attack [GBM+11].

  Scenario: a BE device is transmitting to a switch, but the PHY preamble becomes corrupted, and consequently the PHY layer of the switch resets itself.

  Attacker uses the opportunity to send packet below:

  In Fig. 7, the PHY layer and outgoing port of the switch recover during the transmission of the fake preamble.

  Result: Inner frame, which contains the fake PCF, gets sent.

  Corruption of PHY preamble can be achieved through EMI; see Figs. 8-9.

Applying SPARTA

Using the language of SPARTA, these attack stages can be identified [The22]: 1️⃣ Reconnaissance, 2️⃣ Resource Development, 3️⃣ Initial Access, 4️⃣ Execution, 5️⃣ Lateral Movement, 6️⃣ Impact

Table 1 and Table 2 map these attack stages to the attack steps in PCspooF.

Table 1: The first three stages of PCspooF.

Reconnaissance (ST0001)	Resource Development (ST0002)	Initial Access (ST0003)
Gather Spacecraft Design Information (REC-0001), and specifically, Data Bus (REC-0001.04): 😈 Attacker gathers information required for successful spoofing of TTEthernet frame fields (e.g., Critical Traffic Marker, Virtual Link ID) and design of EMI-injecting PCB. Gather Supply Chain Information (REC-0008), and specifically, Hardware (REC-0008.01): 😈 Attacker gathers information on the hardware in use, e.g., TTEthernet utilisation, EMI target. Eavesdropping (REC-0005): 😈 Attacker eavesdrops on the network to infer valid Critical Traffic Markers and Virtual Link IDs from devices’ responses or lack of response.	Stage Capabilities (RD-0004), and specifically, Identify/Select Delivery Mechanism (RD-0004.01): 😈 Attacker identifies the ideal BE device to use for executing the attack.	Compromise Supply Chain (IA-0001), and specifically, Hardware Supply Chain (IA-0001.03): 😈 Attacker sneaks the attacking BE device into the supply chain before or after the deployment of the targeted TTEthernet network. Auxiliary Device Compromise (IA-0011): 😈 Attacker investigates potential use of a USB/generic hardware vector instead of a BE device.

Table 2: The last three stages of PCspooF.

Execution (ST0004)	Lateral Movement (ST0007)	Impact (ST0009)
Time Synchronised Execution (EX-0008): 😈 Attacker implements a “ticking timebomb” trigger, which activates attack after a preset amount of post-deployment time. Flooding (EX-0013), and specifically, Erroneous Input (EX-0013.02): 😈 Attacker brute-forces ARP requests and emissions of EMI. Exploit Hardware/Firmware Corruption (EX-0005), and specifically, Design Flaws (EX-0005.01): 😈 Attacker exploits weaknesses permitting aggressive ARP polling of BE devices, gathering of information (e.g., Critical Traffic Markers, Virtual Link IDs), and link reset attacks for spoofing PCFs (see Fig. 7). Spoofing (EX-0014), and specifically, Bus Traffic (EX-0014.02): 😈 Attacker injects spoofed PCFs via EMI-based link reset attacks.	Exploit Lack of Bus Segregation (LM-0002): 😈 Attacker is enabled by the situation where critical (TT) and non-critical (BE) components share the same physical networking infrastructure to use a non-critical component (BE device) to disrupt the operations of critical components (TT devices).	Disruption (IMP-0002): 😈 TTEthernet synchronisation broken, critical operations not being performed, leading to disruption of critical spacecraft operations (e.g., manoeuvring, sensing, communications) and overall mission.

Introduction

In many space applications, it is desirable to have a single, common application-layer data structure for the creation, storage, and transport of variable-length application-layer data.

These data is expected to be 1️⃣ exchanged and stored on board, 2️⃣ transferred over one or more space data links, and 3️⃣ used within ground systems.

It is often necessary to identify the 1️⃣ type, 2️⃣ source, and/or 3️⃣ destination of these data.

The preceding needs motivate the definition of the Space Packet Protocol (SPP).

The SPP is designed as a self-delimited carrier of a data unit — called a Space Packet — that contains an application process identifier (APID) used to identify the data contents, data source, and/or data user within a given enterprise [CCS20d, Sec. 2.1.1].

Fig. 1 shows where the SPP sits in the CCSDS protocol stack.

Fig. 2 shows a communication scenario between a spacecraft and a ground terminal, where the SPP plays an important role.

APID

APIDs are unique in a single naming domain [CCS20d, Sec. 2.1.3]

An APID naming domain usually corresponds to a spacecraft, or an element of a constellation of space vehicles.

Every space project allocates the APIDs to be used in a naming domain.

More precisely, the space project assigns APIDs to managed data paths within a naming domain.

Open-source implementations

The following open-source implementations are known at the time of writing:

• A C-based implementation is available from NASA.
• A Python-based implementation is available from the LibreCube project.

The Spectre attacks exploit the weakness CWE-1037 “Processor Optimization Removal or Modification of Security-critical Code”.

Modern processors use branch prediction and speculative execution to maximise performance, but the implementations of these optimisations in many processors were found to have broken a range of software security mechanisms, including operating system process separation, containerisation, just-in-time (JIT) compilation, and countermeasures to cache timing and side-channel attacks [KHF+20].

Watch the presentation given by one of the discoverers of Spectre attacks at the 40th IEEE Symposim on Security and Privacy:

More information on the Meltdown and Spectre website.