Every year, major cybersecurity firms release their report on the trends of cyber threats/attacks they observe during that year.

Some also release their forecast of cybersecurity trends for the next year.

Examples of reports for 2022 are provided in the list of references.

A summary of the trends observed in these reports is provided here, with additional commentary on how some of these attacks happened.

Among the most impactful trends identified [Che22, Cro22b, Man22a, Spl22] are (in no particular order):

• State-sponsored cyber armies, advanced persistent threats (APTs) and cyberwarfare are on the rise.

  Mandiant has an extensive report [Man22a] on the activities of various threat groups in 2022.

  Threat groups from the “big four” — Russia, China, Iran, North Korea — are expected to be highly active in 2023, using destructive attacks, information operations, financial threats and more [Man22b].

• Ransomware has been occupying news headlines, and nobody should be a stranger to this escalating threat anymore.

  It is not even farfetched to expect ransomware to be used to attack space systems [Pet22].

• Macro viruses have existed ever since Microsoft Office started supporting macros.

  They do not seem to be going away.

  Documents containing malicious macros are called “maldoc”, and Emotet (🖱 for details), one of the world’s most prevalent malware (see Fig. 1), has been hailed as the “unofficial king of maldoc usage” [Che22]

• Mobile malware has in recent years started exploiting zero-click vulnerabilities [Jin21], posing tremendous risks to unpatched devices.
  

• Cloud-based services are increasingly abused by malicious actors in the course of computer network operations, a trend that is likely to continue in the foreseeable future as more businesses seek hybrid work environments [Cro22b].

  Common cloud attack vectors include cloud vulnerability (e.g., CVE-2021-21972) exploitation, credential theft, cloud service provider abuse, use of cloud services for malware hosting and command & control (C2), and the exploitation of misconfigured Docker containers [Cro22b].

• In 2021, compromise of cyber supply chain accounted for 17% of intrusions, compared to less than 1% in 2020 [Man22a].

  Furthermore, 86% of these compromises were related to the SolarWinds breach and the SUNBURST malware (trojanised digitally signed component of the SolarWinds Orion software framework that contains a backdoor that communicates via HTTP with third-party servers).

  Watch news report by ABC:

• An increasing number of malware has cryptocurrency mining (“cryptomining” for short) capabilities [Che22], since these capabilities are readily available in the public domain.

  For example, XMRig is available on GitHub, and is the most popular cryptominer (see Fig. 2).

• The highest-profile example of attack on cryptocurrency is undoubtedly the “FTX hack”, which allegedly stole USD 415 million from the FTX exchange.

  The attacker had been using crypto laundering services like ChipMixer to launder the stolen funds.

High-level overview

Abstract interpretation, first formalised by Cousot and Cousot in 1977 [CC77], executes a program on an abstract machine to determine the properties of interest [vJ11, p. 1255].

The level of detail in the abstract machine specification typically determines the accuracy of the results.

At one end of the spectrum is an abstract machine that faithfully represents the concrete semantics of the language.

Abstract interpretation on such a machine 👆 would correspond to a concrete execution on the real machine.

Typical abstract interpretation analyses, however, do not require detailed semantics.

A bit of theory

Fundamentally, the correctness problem of a program is undecidable, so approximation is necessary [Cou01, Abstract].

The purpose of abstract interpretation is to formalise this idea 👆 of approximation; see Fig. 1.

Formally, abstract interpretation is founded in the theory for approximating sets and set operations [Cou01, Sec. 2].

The semantics of a program can be defined as the solution to a fixpoint (short for fixed point) equation.

Thus, an essential role of abstract interpretation is providing constructive and effective methods for fixpoint approximation and checking by abstraction.

By observing computations at different levels of abstraction (trace semantics → relational semantics → denotational semantics → weakest precondition semantics → Hoare logics), fixpoints can be approximated.

Address space layout randomisation (ASLR) refers to the randomisation of the locations of the key components of an executable — stack, heap, libraries and memory-mapped files, executable code — in the address space; to mitigate remote code execution and other attacks targeting CWE-787 and CWE-125.

Watch Dr. Yeongjin Jang’s lecture on ASLR:

ASLR targets memory corruption vulnerabilities such as buffer overflows, which typically occur when data get written to memory that is smaller than the size of the data — a common programming error when using a memory-unsafe language like C.

By introducing uncertainty into the locations of the shellcode (or any other attack code), ASLR hinders exploitations of memory corruption vulnerabilities.

There are many ways ASLR can be done, and different operating systems do it differently.

There are three dimensions to be considered [MGRR19]:

Advanced persistent threat (APT, see Definition 1) has been occupying the attention of many cybersecurity firms.

Since APT groups are characterised by sophistication, persistence and resourcefulness, they are challenging to counter. Lists of APT groups are being actively maintained, e.g., by MITRE and Mandiant.

See public-key cryptography.

See 👇 attachment (coming soon) or the latest source on Overleaf.

The original purpose of the delay-tolerant networking (DTN) protocols was to provide space communications scenarios with network-layer functionality similar to that provided by IP-based networks on Earth.

Since space communication scenarios cannot be supported by the terrestrial IP protocol suite, a new solution had to be developed.

The CCSDS Bundle Protocol (BP), based on Bundle Protocol version 6 as defined in RFC 5050 [SB07] and RFC 6260 [Bur11], is meant to provide 1️⃣ basic network-layer functionality, and 2️⃣ storage capability to enable networking benefits even in the presence of delays, disconnections, and rate mismatches [IEH+19].

The BP is such an important protocol several open-source implementations exist:

• NASA provides a C-based implementation of BPv6 called bplib.
• A University of Marburg research team provides a Rust-based implementation of BPv7.

The CCSDS File Delivery Protocol (CFDP) is standardised in

• ISO 17355:2007,
• CCSDS 727.0-B-5 [CCS20], with CCSDS 720.1-G-4 [CCS21a] and CCSDS 720.2-G-4 [CCS21b] providing further explanatory information.

CFDP has existed for decades, and it is intended to enable packet delivery services in space (space-to-ground, ground-to-space, and space-to-space) environments [CCS20, Sec. 1.1].

CFDP defines 1️⃣ a protocol suitable for the transmission of files to and from spacecraft data storage, and 2️⃣ file management services to allow control over the storage medium [CCS20, Sec. 2.1].

CFDP assumes a virtual filestore and associated services that an implementation must map to the capabilities of the actual underlying filestore used [CCS20, Sec. 1.1].

File transfers can be either unrealiable (class 1) or reliable (class 2):

Fig. 3 summarises 1️⃣the operation primitives and PDUs in CFDP, as well as 2️⃣ the relationships of these primitives and PDUs to the operational process from initiation through termination.

Watch an introduction to the CFDP on YouTube:

There are several open-source implementations of CFDP, e.g.,

• as part of YAMCS (see Java code and documentation),
• as part of the LibreCube project (see Python code).

The International Telecommunication Union (ITU) has defined a series of regulations or recommendations for space research, space operations and Earth exploration-satellite services [ITU20, Recommendation ITU-R SA.1154-0], but CCSDS has tweaked these recommendations for their purposes [CCS21, Sec. 1.5].

For example, the recommendations for telemetry RF comm are summarised in Table 1.

Table 1: Telemetry recommendation summary [CCS13a, p. 2.0-5], where NRZ = non-return-to-zero, PCM = pulse code modulation, QPSK = quadrature phase-shift keying,  OQPSK = offset quadrature phase-shift keying, BPSK = binary phase-shift keying, GMSK = Gaussian minimum shift keying, APSK = amplitude and phase-shift keying.

Note:

• For Category-A missions [CCS21, Sec. 2.4.12A], filtered OQPSK and GMSK modulations are recommended for high-rate telemetry in 1️⃣ the 2-GHz and 8-GHz Space Research bands, 2️⃣ the 8-GHz Earth Exploration-Satellite band, and 3️⃣ the 26-GHz Space Research band.

  Filtered 8PSK modulation is also recommended for the 8-GHz Earth Exploration-Satellite band.

  2 GHz, 8 GHz and 26 GHz are part of the L/S, X and Ka bands respectively.

  This knowledge base entry discusses usage of different frequency bands.

• For Category-B missions [CCS21, Sec. 2.4.12B], GMSK is recommended for high-rate telemetry in the 2-GHz, 8-GHz and 32-GHz bands.

• The 25.5–27.0 GHz band (part of K band) is already being used for high-rate transmission in many missions, and usage is expected to rise [CCS21, Sec. 2.4.23].

• The 32-GHz band (part of Ka band) is planned to become the backbone for communications with high-rate Category-B missions [CCS21, Sec. 2.4.20B].

The Proximity-1 physical layer is separate from all the above.

See 👇 attachment or the latest source on Overleaf.

This is a student-friendly explanation of the hardware weakness CWE-1037 “Processor Optimization Removal or Modification of Security-critical Code”, which is susceptible to

• CAPEC-663 “Exploitation of Transient Instruction Execution”

While increasingly many security mechanisms have been baked into software, the processors themselves are optimising the execution of the programs such that these mechanisms become ineffective.

This is a student-friendly explanation of the hardware weakness CWE-1189 “Improper Isolation of Shared Resources on System-on-a-Chip (SoC)”, which is susceptible to

• CAPEC-124 “Shared Resource Manipulation”.

A system-on-a-chip (SoC) may have many functions but a limited number of pins or pads.

A pin can only perform one function at a time, but it can be configured to perform multiple functions; this technique is called pin multiplexing.

Similarly, multiple resources on the chip may be shared to multiplex and support different features or functions.

When such resources are shared between trusted and untrusted agents, untrusted agents may be able to access assets authorised only for trusted agents.

Consider the generic SoC architecture in Fig. 1 below:

The SRAM in the hardware root of trust (HRoT) is mapped to the core{0-N} address space accessible by the untrusted part of the system.

The HRoT interface (hrot_iface in Fig. 1) mediates access to private memory ranges, allowing the SRAM to function as a mailbox for communication between the trusted and untrusted partitions.

• Assuming a malware resides in the untrusted partition, and has access to the core{0-N} memory map.
• The malware can read from and write to the mailbox region of the SRAM access-controlled by hrot_iface.
• Security prohibits information from entering or exiting the mailbox region of the SRAM through hrot_iface when the system is in secure or privileged mode.

This is a student-friendly explanation of the hardware weakness CWE-1191 “On-Chip Debug and Test Interface With Improper Access Control”, which is susceptible to

• CAPEC-1 “Accessing Functionality Not Properly Constrained by ACLs” and
• CAPEC-180 “Exploiting Incorrectly Configured Access Control Security Levels”.

The internal information of a device may be accessed through a scan chain of interconnected internal registers, typically through a Joint Test Action Group (JTAG) interface.

• The JTAG interface provides access to these registers in a serial fashion in the form of a scan chain for the purposes of debugging programs running on the device.
• Since almost all information contained within a device may be accessed over this interface, device manufacturers typically implement some form of access control — debug authorisation being the simplest form — in addition to on-chip protections, to prevent unintended use of this sensitive information.
• If access control is not implemented or not implemented correctly, a user may be able to bypass on-chip protection mechanisms through the debug interface.

Sometimes, designers choose not to expose the debug pins on the motherboard.

• Instead, they choose to hide these pins in the intermediate layers of the board, to work around the lack of debug authorisation inside the chip.
• In this scenario (without debug authorisation), when the debug interface is exposed, chip internals become accessible to an attacker.

This is a student-friendly explanation of the software weakness CWE-125 “Out-of-bounds Read”, where the vulnerable entity reads data past the end, or before the beginning, of the intended buffer. This weakness is susceptible to

• CAPEC-540 “Overread Buffers”

This and CWE-787 are two sides of the same coin.

Typically, this weakness allows an attacker to read sensitive information from unexpected memory locations or cause a crash.

This is a student-friendly explanation of the hardware weakness CWE-1256 “Improper Restriction of Software Interfaces to Hardware Features”, which is susceptible to

• CAPEC-624 “Hardware Fault Injection”
• CAPEC-625 “Mobile Device Fault Injection”

Not ready for 2023.

This is a student-friendly explanation of the hardware weakness CWE-1260.

Not ready for 2023.

This is a student-friendly explanation of the hardware weakness CWE-1300 “Improper Protection of Physical Side Channels”, which is susceptible to

• CAPEC-189 “Black Box Reverse Engineering”
• CAPEC-699 “Eavesdropping on a Monitor”

A hardware product with this weakness does not contain sufficient protection mechanisms to prevent physical side channels from exposing sensitive information due to patterns in physically observable phenomena such as variations in power consumption, electromagnetic emissions (EME), or acoustic emissions.

More examples of side-channel attacks are available here.

This is a student-friendly explanation of the hardware weakness CWE-1384 “Improper Handling of Physical or Environmental Conditions”, where a hardware product does not properly handle unexpected physical or environmental conditions that occur naturally or are artificially induced.

This weakness CWE-1384 and the weakness CWE-1300 can be seen as two sides of a coin: while the latter is about leakage of sensitive information, the former is about injection of malicious signals.

Example 1

The GhostTouch attack [WMY+22] generates electromagnetic interference (EMI) signals on the scan-driving-based capacitive touchscreen of a smartphone, which result in “ghostly” touches on the touchscreen; see Fig. 1.

The EMI signals can be generated, for example, using ChipSHOUTER.

These ghostly touches enable the attacker to actuate unauthorised taps and swipes on the victim’s touchscreen.

Watch the authors’ presentation at USENIX Security ’22:

PCspooF is another example of an attack exploiting weakness CWE-1384.

This is a student-friendly explanation of the software weakness CWE-787 “Out-of-bounds write”, where the vulnerable entity writes data past the end, or before the beginning, of the intended buffer.

This and CWE-125 are two sides of the same coin.

This can be caused by incorrect pointer arithmetic (see Example 1), accessing invalid pointers due to incomplete initialisation or memory release (see Example 2), etc.

#include <stdlib.h>

int main() {
	char *p;
	p = (char *)malloc(1);
	*(p+2) = 1;
	return 0;
}

#include <stdlib.h>

int main() {
	char *p;
	p = (char *)malloc(1);
	free(p);
	*p = 1;
	return 0;
}

Typically, the weakness CWE-787 can result in corruption of data, a crash, or code execution.

Example 3

Using the unsafe keyword, we can write code involving pointers in C#, e.g.,

// compile with: -unsafe
class UnsafeTest
{
    unsafe static void Main()
    {
        int *p; int i = 0;
        p = &i;
        p[2] = 1;
        // Console.WriteLine(p[2]);
    }
}

Enabling compilation of unsafe code in Visual Studio as per Fig. 1, the code above can be compiled.

Once compiled and run, the code above will not trigger any runtime error, unless the line writing p[2] to the console is uncommented.

Question: What runtime error would the Console.WriteLine statement in the code above trigger?

This is a student-friendly explanation of the software weakness CWE-79 “Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')”, which is susceptible to

• CAPEC-85 “AJAX Footprinting”,
• CAPEC-209 “XSS Using MIME Type Mismatch”,
• CAPEC-588 “DOM-based XSS”, and more.

This weakness exists when user-controllable input is not neutralised or is incorrectly neutralised before it is placed in output that is used as a web page that is served to other users.

In general, cross-site scripting (XSS) vulnerabilities occur when:

• Untrusted data enters a web application, typically through a web request.
• The web application dynamically generates a web page that contains this untrusted data.
• During page generation, the application does not prevent the data from containing content that is executable by a web browser, such as JavaScript, HTML tags, HTML attributes, mouse events, etc.
• A victim visits the generated web page through a web browser, which contains malicious script that was injected using the untrusted data.
• Since the script comes from a web page that was sent by the web server, the victim’s web browser executes the malicious script in the context of the web server’s domain.
• This effectively violates the intention of the web browser’s same-origin policy, which states that scripts in one domain should not be able to access resources or run code in a different domain.

Once the malicious script is injected, a variety of attacks are achievable, e.g.,

• The script could transfer private information (e.g., cookies containing session information) from the victim’s computer to the attacker.
• The script could send malicious requests to a web site on behalf of the victim, which could be especially dangerous to the site if the victim has administrator privileges to manage that site. Phishing attacks could be used to emulate trusted web sites and trick the victim into entering a password, allowing the attacker to compromise the victim’s account on that web site.
• The script could exploit a vulnerability of the web browser itself, potentially taking over the victim’s computer. This is known as “drive-by attack”.

The attacks above can usually be launched without alerting the victim.

Even with careful users, URL encoding or Unicode can be used to obfuscate web requests, to make the requests look less suspicious.

Watch an introduction to XSS on LinkedIn Learning:

Understanding cross-site scripting from Security Testing: Vulnerability Management with Nessus by Mike Chapple

Watch a demonstration of XSS on LinkedIn Learning:

Cross-site scripting attacks from Web Security: Same-Origin Policies by Sasha Vodnik

This is a student-friendly explanation of the software weakness CWE-917 “Improper Neutralization of Special Elements used in an Expression Language Statement ('Expression Language Injection')”.

The vulnerable entity constructs all or part of an expression language (EL) statement in a framework such as Jakarta Server Pages (JSP, formerly JavaServer Pages) using externally-influenced input from an upstream component, but it does not neutralise or it incorrectly neutralises special elements that could modify the intended EL statement before it is executed.

• In the context of JSP, the EL provides a mechanism for enabling the presentation layer (web pages) to communicate with the application logic (managed beans).
• This weakness is a descendant of CWE-707 “Improper Neutralization”.

The Cyber Kill Chain® framework/model was developed by Lockheed Martin as part of their Intelligence Driven Defense® model for identification and prevention of cyber intrusions.

The model identifies what an adversary must complete in order to achieve its objectives.

The seven steps of the Cyber Kill Chain sheds light on an adversary’s tactics, techniques and procedures (TTP):

Watch a quick overview of the Cyber Kill Chain on LinkedIn Learning:

Overview of the cyber kill chain from Ethical Hacking with JavaScript by Emmanuel Henri

In a mobile ad hoc network (MANET, see Definition 1), nodes move around causing connections to form and break over time.

Due to mobility, a node can sometimes find itself devoid of network neighbours. In this case, the node 1️⃣ stores the messages en route to their destination (which is not the node itself), and 2️⃣ when it finds a route of the destination of the messages, forwards the messages to the next node on the route. This networking paradigm is called store-and-forward.

A delay-tolerant networking (DTN) architecture [CBH+07] is a store-and-forward communications architecture in which source nodes send DTN bundles through a network to destination nodes. In a DTN architecture, nodes use the Bundle Protocol (BP) to deliver data across multiple links to the destination nodes.

Watch short animation from NASA:

Watch detailed lecture from NASA:

First identified in 2014 [ANY14], the Emotet malware evolved from a banking Trojan designed to steal sensitive information (including credentials) to a modular, polymorphic, multi-threat downloader for other, more destructive malware [MGB22].

The Encapsulation Packet Protocol (EPP) is used to transfer protocol data units (PDUs) recognised by CCSDS that are not directly transferred by the Space Data Link Protocols over an applicable ground-to-space, space-to-ground, or space-to-space communications link [CCS20b].

A flow is a set of ordered tuples delineated by a start time and an end time, and having the same 1️⃣ session ID, 2️⃣ protocol type, 3️⃣ source and destination IP addresses, as well as 4️⃣ source and destination ports.

Homodyne detection = method of detecting a weak frequency-modulated signal through mixing with a strong reference frequency-modulated signal (so-called local oscillator).

NIST defines intrusion detection to be:

Intrusion prevention goes beyond intrusion detection, although “prevention” is strictly speaking an exaggeration:

In Definition 2, an “attempt” can be sending an alarm to the administrator(s), resetting a network connection, reconfiguring a firewall to block traffic from the source address, etc.

Thus, “intrusion detection and prevention system” (IDPS) is synonymous with “intrusion prevention system” (IPS) [SM07, Appendix A], and is a bit of a redundant term.

Fig. 1 shows an example of a high-end IPS appliance from Cisco.

In the 1970s and the early 1980s, administrators had to print out system logs on papers and manually audit the printout [KV02]. The process was clearly 1️⃣ reliant on the auditors’ expertise, 2️⃣ time-consuming, and 3️⃣ too slow to detect attacks in progress.

In the 1980s, storage became cheaper, and intrusion detection programs became available for analysing audit logs online, but the programs could only be run at night when the system’s user load was low [KV02]. Thus, detecting attacks in time remained a challenge.

In the early 1990s, real-time intrusion detection systems (IDSs) that analysed audit logs as the logs were produced became available [KV02].

Since the inception of IDSs, the quality and quantity of audit logs have always been a challenge [KV02]:

Quality

The accuracy (how often the data are correct) and precision (how close the reported values are to the true values) of the data collected are crucial.

Inaccurate or imprecise data could lead to false negatives (illegitimate events misdiagnosed as legitimate) or false positives (legitimate events misdiagnosed as illegitimate).

Quantity

On one hand, not collecting enough data ⇒ an attack could evade detection. For example, network-related data alone cannot help with detecting a malware that does not access any network.

On the other, collecting too much data (from too many sources and/or too frequently) ⇒ storage could run out and processing could take too long.

Effective detection of attacks depends on capturing all relevant data at sufficiently fine time scales.

An IDS is meant to detect [KV02]:

Misuses

These are abuses and attacks of known patterns that can be encoded in computer-interpretable rules or signatures.

An abuse is an intentional or unintentional violation of organisational policies.

Anomalies

An anomaly, also called outlier, is a “significant” deviation from some model of normalcy, where “significance” is contextual and can be fluid.

A model of normalcy is called a baseline model and is often challenging to build for a dynamic environment.

Accordingly, intrusion detection algorithms can be classified as [SM07; YT11, p. 2; BK14, p. 4; Led22; Pal22]:

Rule-based / signature-based

A rule specifies the conditions of legitimacy of an event, typically with the help of signatures.

Signatures can be

• exploit-facing, e.g., malicious byte sequences, email subject headings associated with phishing, email attachments containing executable binaries, traffic going to known malicious domains, scanning of file hashes; or
• vulnerability-facing, e.g., SSH requests specifying a vulnerable version number, system log entries indicating disablement of auditing.

Signatures can encode violations of organisational policies, e.g., remote login attempts as “root”.

Stateful protocol analysis or deep packet inspection analyses protocols at the application layer to compare vendor-developed profiles of benign protocol activity against observed events to identify deviations [SH09, Jun16]. This is an example of rule-based detection, contrary to the classification in [LRLT13].

As threats grow, the dictionary of signatures necessarily grows, demanding more computational and storage resources accordingly.

Rule-based detection is effective against known threats that can be expressed using a set of rules and signatures.

Rule-based detection is ineffective against known threats that are hard to capture using a finite set of rules and signatures, e.g., multi-stage attacks; as well as previously unknown threats.

Snort is an industry-standard open-source rule-based intrusion prevention software (hence, also an intrusion detection software). It can for example be found in the appliance in Fig. 1.

Anomaly-based / behaviour-based

This is the application of machine learning techniques to determining whether a user or component behaviour is anomalous.

Depends on the prior establishment of a baseline behavioural model.

Can detect previously unknown attacks as long as the attacks manifest as anomalies relative to the baseline model.

Effective at detection but tends to produce excessive false positives.

Behaviour-based detection, when applied to network behaviour, falls into the area of network behaviour analysis.

Definition 3: Network behaviour analysis [SM07, Xu22]

End-to-end process of collecting, extracting, analysing, modelling, and interpreting network behaviour (e.g., distributed denial of service, worm, backdoor, policy violation) of end systems and network applications from a large volume of network traffic data such as TCP/IP data packets and network flows.

A network behaviour analysis pipeline typically consists of these steps [Xu22, Fig. 2.1]: 1️⃣ network traffic data collection, 2️⃣ data storage and preprocessing, 3️⃣ behavioural feature selection and exploration, 4️⃣ analysis and modeling, 5️⃣ behavioural insights and applications.

Depending on its type, an IDS can comprise several types of components, as shown in Fig. 2: sensors/agents (which monitor and analyse network activities and may also perform preventive actions), management servers, database servers, user and administrator consoles, and management networks [SM07].

There is more than one way to classify IDSs. See the attachment for different classifications of IDSs.

Watch the following LinkedIn Learning video for a quick summary of IDS:

What is an IDS? from Protecting Your Network with Open Source Software by Jungwoo Ryoo

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].

Besides scan chains, test access ports (TAPs) and associated protocols constitute the fundamental test mechanism [VDSDN+19].

Among the earliest standards for test access ports is IEEE Std 1149.1a-1993, first drafted by the Joint Test Action Group (JTAG) in the late 1980s, and then standardised by the IEEE in the early 1990s [IEEE13].

• The most recent edition of the standard is the 444 pages-long IEEE Std 1149.1-2013 [IEEE13].
• This standard defines a test access port and boundary scan architecture for 1️⃣ digital integrated circuits and for 2️⃣ the digital portions of mixed analog/digital integrated circuits.
• The architecture of boundary scan in Fig. 1 is responsible for controlling scan chains through a JTAG interface and an embedded hardware module [BT19, Sec. 3.6.3].
• The technique of boundary scan involves the inclusion of a shift-register stage (contained in a boundary-scan register cell, see Fig. 2) adjacent to each component pin so that signals at component boundaries can be controlled and observed using scan testing principles [IEEE13, Sec. 1.2.3].
• Instructions (not states) are loaded into the instruction register (IR), and depending on the instruction, a different data register (DR) is connected between the TDI and TDO terminals; for example, the BYPASS instruction connects a single flip-flop between the TDI and TDO ports [VDSDN+19, p. 96].

The TAP controller in Fig. 1 implements the 16-state finite state machine in Fig. 3.

For example, Select-DR-Scan is a temporary controller state (i.e., the next rising edge of TCK makes the controller exit this state) in which all test data registers (DRs) selected by the current instruction retain their previous state [IEEE13, p. 26].

• If TMS is held low and a rising edge is applied to TCK, the controller enters the Capture-DR state and a scan sequence for the selected test data register is initiated.
• If TMS is held high and a rising edge is applied to TCK, the controller enters the Select-IR-Scan state.
• The instruction does not change while the TAP controller is in this state.

Operationally speaking, the most important consideration for a security analyst, when assessing the security of a device, is finding a JTAG interface. Standard tools such as the Bus Pirate, JTAGulator and Open On-Chip Debugger (OpenOCD) can then be used to probe the device through this interface.

Watch the following tutorial on YouTube:

Key establishment (see Definition 1) is part of key management (see Definition 2).

Simply speaking, key management is a set of processes and mechanisms which support key establishment and the maintenance of ongoing keying relationships between parties, including replacing older keys with new keys as necessary [MvV96, Definition 1.64]; see Fig. 1.

Key establishment can be broadly classified into key agreement (see Definition 3) and key transport (see Definition 4).

Key agreement is more popular than key transport, and the de facto standard key agreement protocol is Diffie-Hellman key agreement.

CCSDS has adopted the Licklider Transmission Protocol (LTP) as specified in the IETF RFC 5326 [BFR08b] and the associated security extensions specified in IETF RFC 5327 [BFR08a] to provide reliability and authentication mechanisms on top of an underlying (usually data link) communication service [CCS15b, Sec. 1.1].

Out-of-order execution is a prevalent performance feature of modern processors for reducing latencies of busy execution units, e.g., a memory fetch unit waiting for data from memory: instead of stalling execution, a processor skips ahead and executes subsequent instructions [LSG+18].

See Fig. 1.

Although the instructions executed out of order do not have any visible architectural effect on the registers or memory, they have microarchitectural side effects [LSG+18, Sec. 3].

• During out-of-order execution, referenced memory contents are fetched into the registers and also stored in the cache.
• If the result of out-of-order execution has to be discarded, the register and memory contents are retired, but the cached memory contents are kept in the cache.
• A microarchitectural side-channel attack such as FLUSH+RELOAD [YF14] can then be exploited to detect whether a specific memory location is cached, to make this microarchitectural state visible.

Meltdown consists of two building blocks [LSG+18, Sec. 4], as illustrated in Fig. 2:

1. The first building block makes the CPU execute one or more instructions that would never occur in the normal executed path.

   These instructions, which are executed out of order and leaving measurable side effects, are called transient instructions.

2. The second building block transfers the microarchitectural side effect of the transient instruction sequence to an architectural state to further process the leaked secret.

Operation-wise, Meltdown consists of 3 steps [LSG+18, Sec. 5.1]:

1. The content of an attacker-chosen memory location, which is inaccessible to the attacker, is loaded into a register.
2. A transient instruction accesses a cache line based on the secret content of the register; see Fig. 2.
3. The attacker uses FLUSH+RELOAD to determine the accessed cache line and hence the secret stored at the chosen memory location.

Watch the presentation given by one of the discoverers of Meltdown attacks at the 27th USENIX Security Symposium:

Since FLUSH+RELOAD was mentioned, watch the original presentation at USENIX Security ’14:

More information on the Meltdown and Spectre website.

The field of adversarial machine learning (AML) is concerned with the study of attacks on machine learning (ML) algorithms and the design of robust ML algorithms to defend against these attacks [TBH+19, Sec. 1].

ML systems (and by extension AI systems) can fail in many ways, some more obvious than the others.

AML is not about ML systems failing when they make wrong inferences; it is about ML systems being tricked into making wrong inferences.

Consider three basic attack scenarios on ML systems:

Black-box evasion attack: Consider the most common deployment scenario in Fig. 1, where an ML model is deployed as an API endpoint.

• In this black-box setting, an adversary can query the model with inputs it can control, and observe the model’s outputs, but does not know how the inputs are processed.
• The adversary can craft adversarial data (also called adversarial examples), usually by subtly modifying legitimate test samples, that cause the model to make different inferences than what the model would have made based on the legitimate test samples — this is called an evasion attack [OV23, p. 8].
• This technique can be used to evade a downstream task where machine learning is utilised, e.g., machine-learning-based threat detection.

White-box evasion attack: Consider the scenario in Fig. 2, where an ML model exists on a smartphone or an IoT edge node, which an adversary has access to.

• In this white-box setting, the adversary could reverse-engineer the model.
• With visibility into the model, the adversary can optimise its adversarial data for its evasion attack.

Poisoning attacks: Consider the scenario in Fig. 3, where an adversary has control over the training data, process and hence the model.

• Attacks during the ML training stage are called poisoning attacks [OV23, p. 7].
• A data poisoning attack is a poisoning attack where the adversary controls a subset of the training data by either inserting or modifying training samples [OV23, pp. 7-8].
• A model poisoning attack is a poisoning attack where the adversary controls the model and its parameters [OV23, p. 8].
• A backdoor poisoning attack is a poisoning attack where the adversary poisons some training samples with a trigger or backdoor pattern such that the model performs normally on legitimate test samples but abnormally on test samples containing a trigger [OV23].

Watch introduction to evasion attacks (informally called “perturbation attacks”) on LinkedIn Learning:

Perturbation attacks and AUPs from Security Risks in AI and Machine Learning: Categorizing Attacks and Failure Modes by Diana Kelley

Watch introduction to poisoning attacks on LinkedIn Learning:

Poisoning attacks from Security Risks in AI and Machine Learning: Categorizing Attacks and Failure Modes by Diana Kelley

In response to the threats of AML, in 2020, MITRE and Microsoft, released the Adversarial ML Threat Matrix in collaboration with Bosch, IBM, NVIDIA, Airbus, University of Toronto, etc.

Subsequently, in 2021, more organisations joined MITRE and Microsoft to release Version 2.0, and renamed the matrix to MITRE ATLAS (Adversarial Threat Landscape for Artificial-Intelligence Systems).

MITRE ATLAS is a knowledge base — modelled after MITRE ATT&CK — of adversary tactics, techniques, and case studies for ML systems based on real-world observations, demonstrations from ML red teams and security groups, and the state of the possible from academic research.

Watch MITRE’s presentation:

References

Among the tools that support the ATT&CK framework is MITRE CALDERA™ (source code on GitHub).

• CALDERA is a cyber security platform built on the ATT&CK framework for 1️⃣ automating adversary emulation, 2️⃣ assisting manual red-teaming, and 3️⃣ automating incident response.
• CALDERA consists of two components:
  1. The core system: This includes an asynchronous command-and-control (C2) server with a RESTful API.
  2. Plugins: These are repositories that expand the core framework capabilities. Examples include Pathfinder, a plugin for automating ingestion of network scanning tool output.

A (blurry) demo is available on YouTube:

MITRE’s Common Attack Pattern Enumeration and Classification (CAPEC™) effort provides a publicly available catalogue of common attack patterns to help users understand how adversaries exploit weaknesses in applications and other cyber-enabled capabilities.

Attack patterns are descriptions of the common attributes and approaches employed by adversaries to exploit known weaknesses in cyber-enabled capabilities.

• Attack patterns define the challenges that an adversary may face and how they go about solving it.
• They derive from the concept of design patterns applied in a destructive rather than constructive context and are generated from in-depth analysis of specific real-world exploit examples.
• In contrast to CAPEC, MITRE ATT&CK catalogues individual techniques (more fine-grained) rather than patterns (collection of sequences of techniques).

As of writing, CAPEC stands at version 3.9 and contains 559 attack patterns.

For example, CAPEC-98 is phishing:

CAPEC-98 can be mapped to CWE-451 “User Interface (UI) Misrepresentation of Critical Information”.

MITRE D3FEND is a knowledge base — more precisely a knowledge graph — of cybersecurity countermeasures/techniques, created with the primary goal of helping standardise the vocabulary used to describe defensive cybersecurity functions/technologies.

• It serves as a catalogue of defensive cybersecurity techniques and their relationships to offensive/adversarial techniques.

The D3FEND knowledge graph was designed to map MITRE ATT&CK techniques (or sub-techniques) through digital artefacts to defensive techniques; see Fig. 1.

• Any digital trail left by an adversary, such as Internet search, software exploit and phishing email, is a digital artefact [KS21, Sec. IVE].

Operationally speaking, the D3FEND knowledge graph allows looking up of defence techniques against specific MITRE ATT&CK techniques.

• For example, looking up Data Obfuscation (T1001) returns this knowledge graph.

Watch an overview of the D3FEND knowledge graph from MITRE on YouTube:

MITRE Engage (previously MITRE Shield) is a framework for planning and discussing adversary engagement operations.

• It is meant to empower defenders to engage their adversaries and achieve their cybersecurity goals.

Cyber defense has traditionally focussed on applying defence-in-depth to deny adversaries’ access to an organisation’s critical cyber assets.

Increasingly, actively engaging adversaries proves to be more effective defence [MIT22b].

• For example, making adversaries doubt the value of any data/information they stole drives down the value of their operations and up their operating cost.

The foundation of adversary engagement, within the context of strategic planning and analysis, is cyber denial and cyber deception [MIT22b]:

• Cyber denial is the ability to prevent or otherwise impair adversaries’ ability to conduct their operations.
• Cyber deception intentionally reveals deceptive facts and fictions to mislead the adversary, while concealing critical facts and fictions to prevent the adversary from making correct estimations or taking appropriate actions.

While MITRE Engage has not been around for long, the practice of cyber deception has a long history; honeypots for example can be traced back to the 1990s [Spi04, Ch. 3].

MITRE Engage prescribes the 10-Step Process, which was adapted from the process of deception in [RW13, Ch. 19], in Fig. 1:

Operationalise the Methodologies

The foundation of an adversary engagement strategy is the Engage Matrix:

The Matrix serves a shared reference that bridges the gap between defenders and decision makers when discussing and planning denial, deception, and adversary engagement activities.

The Matrix allows us to apply the theoretical 10-Step Process (see Fig. 1) to an actual operation.

The top row identifies the goals: Prepare and Understand, as well as the objectives: Expose, Affect and Elicit.

• The Prepare and Understand Goals focus on the inputs and outputs of an operation.
• While the Matrix is linear like the 10-Step Process, it should be viewed as cyclical.

The second row identifies the approaches, which let us make progress towards our selected goal.

The remainder of the Matrix identifies the activities.

• The same activities often appear under one or more approach or goal/objective, e.g., Lures under Expose ▶ Detect, Affect ▶ Direct and Affect ▶ Disrupt, because activities can be adapted to fit multiple use cases.
• An adversary’s action may expose an unintended weakness of the adversary.
• We can look at each MITRE ATT&CK® technique to examine the weaknesses revealed and identify engagement activities to exploit these weaknesses.
• Fig. 3 shows an example of mapping a MITRE ATT&CK technique to an engagement activity.

Model checking is a method for formally verifying that a model satisfies a specified property [vJ11, p. 1255].

Model checking algorithms typically entail enumerating the program state space to determine if the desired properties hold.

Example 1 [CDW04]

Developed by UC Berkeley, MOdelchecking Programs for Security properties (MOPS) is a static (compile-time) analysis tool, which given a program and a security property (expressed as a finite-state automaton), checks whether the program can violate the security property.

The security properties that MOPS checks are temporal safety properties, i.e., properties requiring that programs perform certain security-relevant operations in certain orders.

An example of a temporal security property is whether a setuid-root program drops root privileges before executing an untrusted program; see Fig. 1.

The National Institute of Standards and Technology (NIST) has an essential role in identifying and developing cybersecurity risk frameworks for voluntary use by owners and operators of critical infrastructure (see Definition 1) [NIS18, Executive Summary].

Definition 1: Critical infrastructure [NIS18, Sec. 1.0]

Systems and assets, whether physical or virtual, so vital that the incapacity or destruction of such systems and assets would have a debilitating impact on security, national economic security, national public health or safety, or any combination of those matters.

One such framework is the Framework for Improving Critical Infrastructure Cybersecurity (Cybersecurity Framework for short), for which NIST is maintaining an official website.

As of writing, the latest version of the NIST Cybersecurity Framework is 1.1 [NIS18].

The Cybersecurity Framework provides a common language for understanding, managing and expressing cybersecurity risks to internal and external stakeholders [NIS18, Sec. 2.0].

The Cybersecurity Framework has three parts: 1️⃣ Framework Core, 2️⃣ Implementation Tiers, and 3️⃣ Framework Profiles.

Framework Core

This is a set of cybersecurity activities, desired outcomes and applicable references (industry standards, guidelines and practices) that are common across critical infrastructure sectors [NIS18, Sec. 1.1].

The Framework Core consists of five concurrent and continuous Functions that provide a high-level strategic view of the lifecycle of an organisation’s management of cybersecurity risks:

1. Identify: Develop an organisational understanding to manage cybersecurity risks to systems, people, assets, data and capabilities [NIS18, p. 7].

   Applicable activities include [MMQT21]:

   • identifying critical enterprise processes and assets;
   • documenting information flows (how information is collected, stored, updated and used);
   • maintaining hardware and software inventories;
   • establishing cybersecurity policies specifying roles, responsibilities and procedures in integration with enterprise risk considerations;
   • identifying and assessing vulnerabilities and threats;
   • identifying, prioritising, executing and tracking risk responses.

2. Protect: Develop and implement appropriate safeguards to ensure delivery of critical services [NIS18, p. 7].

   Applicable activities include [MMQT21]:

   • managing access to assets and information;
   • safeguarding sensitive data, including applying authenticated encryption and deleting data that are no longer needed;
   • making regular backups and storing backups offline;
   • deploying firewalls and other security products, with configuration management, to protect devices;
   • keeping device firmware and software updated, while regularly scanning for vulnerabilities;
   • training and regularly retraining users to maintain cybersecurity hygiene.

3. Detect: Develop and implement appropriate activities to identify the occurrence of a cybersecurity event [NIS18, p. 7].

   Applicable activities include [MMQT21]:

   • developing, testing and updating processes and procedures for detecting unauthorised entities and actions in the cyber and physical environments;
   • maintaining logs and monitoring them for anomalies, including unexpected changes to systems or accounts, illegitimate communication channels and data flows.

4. Respond: Develop and implement appropriate activities to take action regarding a detected cybersecurity incident [NIS18, p. 8].

   Applicable activities include [MMQT21]:

   • making, testing and updating response plans, including legal reporting requirements, to ensure each personnel is aware of their responsibilities;
   • coordinating response plans and updates with all key internal and external stakeholders.

5. Recover: Develop and implement appropriate activities to maintain plans for resilience and to restore any capabilities or services that were impaired by a cybersecurity incident [NIS18, p. 8].

   Applicable activities include [MMQT21]:

   • making, testing and updating recovery plans;
   • coordinating recovery plans and updates with all key internal and external stakeholders, paying attention to what, how and when information is shared;
   • managing public relations and company reputation.

Each Function comprises Categories, and each Category comprises Subcategories, and for each Subcategory, Informative References are provided [NIS18, Sec. 2.1].

• A Category is a cybersecurity outcome closely tied to programmatic needs and particular activities.
• A Subcategory is an outcome of technical and/or management activities for supporting achievement of the outcomes in each Category.
• An Informative Reference is a specific part of a standard, guideline and practice common among critical infrastructure sectors that illustrates a method to achieve the outcomes associated with each Subcategory.

Fig. 1 shows Categories, and the Subcategories under the Category “Business Environment”, and furthermore the Informative References for each of these Subcategories.

Implementation Tiers

The four tiers in Table 1 provide context on how an organisation views cybersecurity risks and the processes in place to manage those risks [NIS18, p. 8].

Table 1: Implementation tiers [NIS18, pp. 9-11].

Tier	Risk management process	Integrated risk management program	External participation
1, Partial	Not formalised, ad hoc and reactive.	Limited cybersecurity awareness. Risk management is irregular and case-by-case.	Organisation does not engage with other entities, and lacks awareness of cyber supply chain risks.
2, Risk-informed	Formalised but not organisation-wide. Prioritisation of cybersecurity objectives and activities is directly informed by organisational risks, business requirements, or the threat environment.	Cybersecurity awareness exists at the organisational level, but risk management is not organisation-wide. Irregular risk assessment of assets.	Organisation receives information from other entities and generates some of its own, but may not share information with others. Organisation is aware of cyber supply chain risks, but does not respond formally to the risks.
3, Repeatable	Formalised and regularly updated based on the application of risk management processes to changes in business requirements and the threat landscape.	Risk management is organisation-wide. Organisation accurately and consistently monitors cybersecurity risks of assets. Organisation responds effectively and consistently to changes in risks. Cybersecurity is considered through all lines of operation.	Organisation receives information from other entities and share its original information with others. Organisation is aware of cyber supply chain risks, and usually responds formally to the risks.
4, Adaptive	Formalised and adaptable to experience and forecast. Continuously improved leveraging advanced cybersecurity technologies and practices, to respond to evolving, sophisticated threats in a timely and effective manner.	Risk management is organisation-wide. Decision making is grounded in clear understanding of the relationship between cybersecurity risks and financial risks / organisational objectives. Risk management is integral to organisational culture and is supported by continuous awareness of activities on systems and networks.	Organisation receives, generates and reviews prioritised information to inform continuous risk assessment. Organisation uses real-time information to respond formally and consistently to cyber supply chain risks.

Implementation tiers do not represent maturity levels; they are meant to support organisational decision making about how to manage cybersecurity risks.

Framework Profiles

A Framework Profile (“Profile”) is a representation of the outcomes that a particular system or organisation has selected from the Framework Categories and Subcategories [NIS18, Appendix B].

A Profile specifies the alignment of the Functions, Categories, and Subcategories with the business requirements, risk tolerance, and resources of an organisation [NIS18, Sec. 2.3].

A Profile enables organisations to establish a roadmap for reducing cybersecurity risks, that 1️⃣ is well aligned with organisational and sector goals, 2️⃣ considers legal/regulatory requirements and industry best practices, and 3️⃣ reflects risk management priorities [NIS18, Sec. 2.3].

For example,

• The NIST Interagency Report 8401 [LSB22] specifies a Profile for securing satellite ground segments.
• A Profile for securing hybrid satellite networks is currently under development.
• More examples of Profiles can be found here.

Watch a more detailed explanation of the Cybersecurity Framework presented at RSA Conference 2018:

Imagine writing a piece of networking software.

• It needs to enable two neighbouring (i.e., directly connected) devices to communicate.
• It also needs to enable two devices separated by multiple hops to communicate.

The Open Systems Interconnection (sometimes Open Systems Interconnect or simply OSI) model 1️⃣ enables networking software to be built in a structured manner; 2️⃣ provides an interoperability framework for networking protocols.

History: The OSI model was introduced in 1983 by several major computer and telecom companies; and was adopted by ISO as an international standard in 1984 [Imp22].

• The second and latest edition of the international standard is ISO/IEC 7498-1:1994 [ISO94].

Watch the following video for a quick overview:

Learning the seven layers from Networking Foundations: Networking Basics by Kevin Wallace

More details follows.

The OSI model is a logical (as opposed to physical) model that consists of seven nonoverlapping layers (going bottom-up, opposite to Fig. 1):

1. Layer 1 (L1), physical layer [TW11, p. 43]: This layer transmits and/or receives raw bits (see Fig. 2) over a communication channel (e.g., coaxial cable, optical fibre, RF channel).

   This layer deals with mechanical, electrical, and timing interfaces, as well as the physical transmission medium, which lies below the physical layer.

   For example, the IEEE Standard for Ethernet [IEE22] specifies several variants of the physical layer and one data link layer.

2. Layer 2 (L2), data link layer [TW11, p. 43]: This layer transforms a raw transmission facility into a line that appears free of undetected transmission errors, by masking the real errors so the network layer above does not see them.

   Input data is encapsulated in data frames (see Fig. 2) which are transmitted sequentially.

   For example, the Challenge-Handshake Authentication Protocol (CHAP, see RFC 1994 and RFC 2433) is a link-layer protocol.

3. Layer 3 (L3), network layer [TW11, pp. 43-44]: This layer controls the operation of a subnet (see Fig. 2), by determining how packets (see Fig. 2) are routed from a source to a destination.

   For example, the Internet Protocol Security (IPsec) is a network-layer protocol.

4. Layer 4 (L4), transport layer [TW11, pp. 44]: This layer accepts data from above it, split it up into smaller units, called transport protocol data units (TPDUs, see Fig. 2), if need be, passes these to the network layer, and ensures that all pieces arrive correctly and efficiently at the other end.

   For example, the Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) are transport-layer protocols (see Fig. 1).

5. Layer 5 (L5), session layer [TW11, pp. 44-45]: This layer enables users on different machines to establish sessions between them.

   Sessions offer various services, including dialog control (keeping track of whose turn it is to transmit), token management (preventing two parties from attempting the same critical operation simultaneously), and synchronisation (checkpointing long transmissions to allow them to pick up from where they left off in the event of a crash and subsequent recovery).

   For example, SOCKS5 (see RFC 1928) is a session-layer protocol.

6. Layer 6 (L6), presentation layer [TW11, p. 45]: This layer manages the syntax and semantics of the information to be transmitted.

   For most protocols however, the distinction between the presentation layer and application layer is blur. For example, the HyperText Transfer Protocol (HTTP) is commonly classified as an application-layer protocol although it has clear presentation-layer functions such as encoding, decoding, and managing different content types [FNR22].

7. Layer 7 (L7), application layer [TW11, p. 45]: This layer implements a suite of protocols for supporting end-user applications.

   For example, HTTP is a stateless application-layer protocol for distributed, collaborative, hypertext information systems [FNR22]. HTTP supports eight “methods”, including the GET method for requesting transfer of a target resource in a specified representation [FNR22, Sec. 9.3.1].

Both models use 1️⃣ the transport and lower layers to provide an end-to-end, network-independent transport service; and 2️⃣ the layers above transport for applications leveraging the transport service.

Most real-world protocol stacks are developed based on a hybrid of the OSI and TCP/IP models, consisting of these layers (from bottom to top): physical, data link, network, transport, application [TW11, Sec. 1.4.3].

Physical unclonable functions (PUFs, see Definition 1) serve as a physical and unclonable alternative to digital cryptographic keys.

Think of a PUF as a keyed hash function, where the key is built-in and unique due to manufacturing variations [GASA20].

• Given an input, which we shall call a challenge, a PUF outputs a response. The challenge-response pair (CRP) is unique to the PUF.
• Every CRP is used only once.

Types of PUFs include 1️⃣ optical PUFs, 2️⃣ arbiter PUFs, 3️⃣ memory-based intrinsic PUFs [GASA20].

• An intrinsic PUF is a PUF that is already embedded within a device at the time of manufacturing.
• The first intrinsic PUF was introduced in 2007 in the form of an SRAM PUF.
• Flash memory PUFs and DRAM PUFs were subsequently introduced.
• A memory-based PUF usually offers desired independence among response bits, so its primary application is on-demand derivation of volatile cryptographic keys.

Watch a high-level introduction to SRAM PUF:

Proximity-1 covers the data link layer [CCS20d] and physical layer [CCS13b].

Proximity-1 enables communications among probes, landers, rovers, orbiting constellations, and orbiting relays in a proximate environment, up to about 100,000 km [CCS13c].

These scenarios are devoid of manual intervention from ground operators, and furthermore, resources such as computational power and storage are typically limited at both ends of the link.

In fact, Proximity-1 has been field-tested in the 2004-2005 Mars missions; see Figs. 1-2 for illustration.

In contrast, the AOS/TC/TM Space Data Link Protocols are meant for Earth-deep space links, over extremely long distances.

Proximity-1 supports symbol rates of up to 4,096,000 coded symbols per second.

Designed for the Mars environment, the physical Layer of Proximity-1 only uses UHF frequencies [CCS13b, Sec. 1.2].

The frequency range consists of 60 MHz between 390 MHz to 450 MHz with a 30 MHz guard-band between forward and return frequency bands, specifically 435-450 MHz for the forward channel and 390-405 MHz for the return channel [CCS13b, Sec. 3.3.2].

Also known as asymmetric-key cryptography, public-key cryptography (PKC) uses a pair of keys called a public key and a private key for 1️⃣ encryption and decryption, as well as 2️⃣ signing and verification.

Digital certificates and public-key infrastructure (PKI)

Suppose 👩 Alice is somebody everybody trusts.

• When 👩 Alice signs 🧔 Bob’s public key, anybody can verify Bob’s public key using Alice’s public key.
• Successful verification means we can trust that the public key is Bob’s because we trust Alice.
• Essentially, 🧔 Bob’s public key with 👩 Alice’s signature on it serves a 📜 digital certificate (see Definition 2) certifying Bob’s identity.

Watch a quick introduction to digital certificates on LinkedIn Learning:

Digital certificates and signing from Ethical Hacking: Cryptography by Stephanie Domas

Digital certificates are only useful if we can trust their signatories.

To ensure signatories and hence certificates can be trusted, PKC relies on a public-key infrastructure (PKI, see Definition 3) to work.

Watch a quick introduction to PKI from an operational viewpoint on LinkedIn Learning:

Cryptography: Public key infrastructure and certificates from CISA Cert Prep: 5 Information Asset Protection for IS Auditors by Human Element LLC and Michael Lester

A PKI, as specified in the ITU-T X.509 [ITU19] standard, consist of certification authorities (CAs).

• One or more CAs are trusted to create and digitally sign public-key certificates in response to certificate signing requests (CSRs).

• A CA may optionally create the subjects’ keys.

• A CA certificate is a public-key certificate for one CA [ITU19, Sec. 7.4]

  • issued by another CA, in which case the CA certificate is a cross-certificate;

  • issued by the same CA, in which case the CA certificate is a self-issued certificate.

    If the signing key is the private key associated with the public key signed, the self-issued certificate is a self-signed certificate.

• Thus, CAs can clearly exist in a hierarchy, e.g., the two-tier hierarchy in Fig. 1, or the three-tier hierarchy in Fig. 2.
• In a hierarchy, the root CA serves as the trust anchor [ITU19, Sec. 7.5].
• Examples of CAs: IdenTrust, DigiCert Group, others.
• An example of a software solution that implements CA functionality is Cloudfare’s CFSSL.

A PKI also has registration authorities (RAs).

• One or more RAs are responsible for those aspects of a CA’s responsibilities that are related to identification and authentication of the subject of a public-key certificate to be issued by that CA.
• An RA may either be a separate entity or be an integrated part of the CA.
• CAs typically play the role of RA as well.
• An example of a software solution that implements RA functionality is PrimeKey’s EJBCA Registration Authority.

Although the X.509 standard does not specify any validation authority (VA), a VA allows an entity to check that a certificate has not been revoked [NCS20, p. 3].

• The VA role is often carried out by an online facility hosted by an organisation who operates the PKI.
• VAs often use the Online Certificate Status Protocol (OCSP, see RFC 6960) or certificate revocation lists (CRLs) to advertise revoked certificates.
• Fig. 3 illustrates the interactions among an RA, a CA and a VA in a PKI.
• An example of a software solution that implements VA functionality is PrimeKey’s EJBCA Validation Authority.

Public-key cryptosystems

Algorithmically speaking, there is more than one way of constructing a public-key cryptosystem.

Standard public-key cryptosystems: 1️⃣ Rivest-Shamir-Adleman (RSA) cryptosystem, 2️⃣ elliptic-curve cryptosystems.

These cryptosystems rely on the hardness of certain computational problems for their security.

The hardness of these computational problems has come under threat of quantum computers and quantum algorithms like Shor’s algorithm.

As a countermeasure, NIST has been searching for post-quantum cryptography (PQC, also called quantum-resistant cryptography).

As of writing, there are three PQC candidates.

See 👇 attachment (coming soon) or the latest source on Overleaf.

Not ready for 2023 but see reference below.

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.

NIST provides guidelines on engineering trustworthy (see Definition 1) and cyber-resilient (see Definition 2) systems through NIST SP 800-160 volumes 1 and 2 [RWM22, RPG+21], to be used in conjunction with

• ISO/IEC/IEEEE International Standard 15288:2015 [ISO15],
• NIST SP 800-37 [Joi18] and
• NIST SP 800-53 [Joi20].

A primary objective of NIST SP 800-160 volume 1 is to provide a basis for establishing a discipline for systems security engineering as part of systems engineering in terms of its principles, concepts, activities and tasks.

• Systems engineering is a transdisciplinary and integrative approach to enabling the successful realisation, use, and retirement of engineered systems [RWM22, Sec. 2.2].
• Systems security engineering is meant to provide complementary engineering capabilities that extend the concept of trustworthiness to deliver trustworthy systems [RWM22, p. 2].
• Without going into details, Fig. 1 captures the workflow in the prescribed Systems Security Engineering Framework [RWM22, Sec. 4].

A primary objective of NIST SP 800-160 volume 2 is to provide guidance on how to apply cyber resilience concepts, constructs and engineering practices to systems security engineering and risk management for systems (e.g., enterprise IT, industrial control systems, Internet of Things) and organisations.

Trusted Autonomy (TA) is a field of research that focuses on understanding and designing the interaction space between two entities each of which exhibits a level of autonomy [APM+16].

Type checking checks that program statements are well-formed with respect to a typing logic [vJ11, p. 1255].

For example, integers can be added and functions can be called, but integers cannot be called and functions cannot be added.

Type checking can be used to ensure programs are type-safe, meaning that at every step of the execution, all values have well-defined and appropriate types, and that there is a valid next step of execution.

First proposed by Canetti [Can01], the paradigm of universally composable security guarantees security even when a secure protocol is composed with an arbitrary set of protocols, or more generally when the protocol is used as a component of an arbitrary system.

• It guarantees security even when an unbounded number of protocol instances are executed concurrently in an adversarially controlled manner.
• It is an essential property for maintaining security of cryptographic protocols in complex and unpredictable environments such as the Internet.

Ettus’s wiki for B210.

Ettus’ wiki for X300/X310

Setting up UHD through Anaconda and GNU Radio.

Verifying operation.

PySDR: A Guide to SDR and DSP using Python, set up UHD following Ch. 6 (original instructions). Note highest Python version supported is 3.9. Use conda to save trouble.

Stuck at ldconfig:

/sbin/ldconfig.real: Can't link /usr/lib/wsl/lib/libnvoptix_loader.so.1 to libnvoptix.so.1
/sbin/ldconfig.real: /usr/lib/wsl/lib/libcuda.so.1 is not a symbolic link

UHD Python API

>>> x310 = uhd.usrp.MultiUSRP("type=x300")
[INFO] [X300] X300 initialization sequence...
Traceback (most recent call last):
  File "stdin", line 1, in module
  File "C:\Users\lawyw\Miniconda3\envs\gnuradio\Lib\site-packages\uhd\usrp\multi_usrp.py", line 30, in __init__
    super(MultiUSRP, self).__init__(args)
RuntimeError: RuntimeError: Expected FPGA compatibility number 39.0, but got 13.0:
The FPGA image on your device is not compatible with this host code build.
Download the appropriate FPGA images for this version of UHD.
As an Administrator, please run:

"C:\Users\lawyw\Miniconda3\envs\gnuradio\Library\bin\uhd\utils\uhd_images_downloader.py"

Then burn a new image to the on-board flash storage of your
USRP X3xx device using the image loader utility. Use this command:

"C:\Users\lawyw\Miniconda3\envs\gnuradio\Library\bin\uhd_image_loader" --args="type=x300,addr=192.168.10.2"

For more information, refer to the UHD manual:

 http://files.ettus.com/manual/page_usrp_x3x0.html#x3x0_flash