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.