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.

The attachment covers the following topics:

• Complexity and asymptotic notation.
• Complexity classes.

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