Author Topic: Cybersecurity  (Read 1322 times)

Offline alamos

  • Member
  • Posts: 2
  • St-Louis
  • Liked: 0
  • Likes Given: 2
« on: 04/12/2017 12:39 AM »
Hello all,

I am a graduate student in Cybersecurity.
I am doing some researches about cybersecutiry for space systems.
It is really hard to find resources about this, may it be for the ground control segment, the space segment, or even the user segment.
Can someone give me some hints or paths for my research?

Thanks for any comment!
« Last Edit: 04/12/2017 12:40 AM by alamos »

Offline Hanelyp

  • Full Member
  • ***
  • Posts: 369
  • Liked: 65
  • Likes Given: 252
Re: Cybersecurity
« Reply #1 on: 04/12/2017 04:18 AM »
Round trip latency on the communications link might require a change towards protocols that don't require back and forth exchange of packets.  So error correction on the link layer instead of ack and retransmission of corrupted packets.  And perhaps digital signatures on the individual timestamped command packet.  But otherwise the major concerns are the same as a terrestrial data link.

Offline gosnold

  • Full Member
  • ****
  • Posts: 445
  • Liked: 134
  • Likes Given: 982
Re: Cybersecurity
« Reply #2 on: 04/12/2017 06:44 PM »
Hello all,

I am a graduate student in Cybersecurity.
I am doing some researches about cybersecutiry for space systems.
It is really hard to find resources about this, may it be for the ground control segment, the space segment, or even the user segment.
Can someone give me some hints or paths for my research?

Thanks for any comment!

Eoportal ( has some stuff on the security architecture of some Earth Observation missions.
For instance Ingenio:
SEOSat/Ingenio security system:

The Security System Architecture was defined by the SEOSAT system team, under the technical supervision of ESA. EADS Astrium Crisa contributed to the definition of the system architecture as part of the SEOSAT's system team, and was awarded with the contracts for the development of the DCUs (Deciphering and Ciphering Units) and the associated EGSE (Electrical Ground Support Equipment). The DCU Flight Models (FMs) have been delivered by the end of 2012, and are currently (2013) being integrated in the Satellite at the CASA-Espacio facilities. The security functions of the GS (Ground Segment)for the FOS (Flight Operation Stations) and PDGS (Payload Data Ground Station) have been specified by ESA and are currently under development by the GS subcontractor. 13) 14)

Security system architecture:

The SEOSAT overall system is depicted in Figure 7. The Security System aims at protecting both the S-band and X-band space links between the satellite and the GS. For this purpose, complementary security functions have been allocated at the satellite and GS, namely:

• TC Authenticated Encryption ("Auth Enc") and Decryption ("Auth Dec"), and anti-replay protection

• Housekeeping TM Encryption ("HK-TM Enc") and Decryption ("HK-TM Dec")

• Payload TM Encryption ("PL-TM Enc") and Decryption ("PL-TM Dec").


Figure 7: SEOSAT/Ingenio system overview (image credit: EADS Astrium Crisa)

SEOSat in LEO implies relatively short contact times with the GS. Therefore, the satellite is provided with a relatively high autonomy. Concerning the security system, the satellite is able to autonomously configure the security functions for routine operations. GS intervention is required basically for mission timeline uploads and troubleshooting. At the same time, given the short contact times, operational procedures and protocol overheads associated to the security system management are limited to the minimum necessary.

Besides technical requirements for the security functions, industrial organization constraints were considered for the definition of the security system architecture. The security functions had to be integrated within the satellite's platform without any major impact in the on-going development of other units or system functions. In addition, given the complex subcontractor network, the security perimeter (understood as the human team with direct knowledge about the security functions) had to be carefully limited. Finally, the security functions were the last to be specified and procured, with the subsequent pressure in schedule and cost. Given this scenario, it was decided to implement the security functions by purely hardware (HW) units and without involving the OBSW (On-Board Software) in them.

Security system architecture overview:

SEOSat's security system implements three functional DCUs, respectively, for TC authenticated decryption, HK-TM encryption and PL-TM encryption. The first two are packaged into a common housing, so two physical units have been developed: DCU-S (for S-band DCU) and DCU-X (for X-band DCU). DCU-S includes two hot redundant DCU-S (TC) modules and two cold redundant DCU-S (TM) modules. DCU-X includes two cold redundant modules. Both units are functionally placed in the S-band and X-band chains respectively, as shown in Figure 8.


Figure 8: Schematic view of the SEOSat/Ingenio security system architecture (image credit: EADS Astrium Crisa)

The DCU-S(TC) module processes CLTUs (Communications Link Transmission Units) received from the Transponders (TRSPs) transparently for the OBC (On-Board Computer). The processing is done by a FPGA (Field Programmable Gate Array) and includes: CLTU delimitation, BCH decoding, de-randomization, Security Header extraction, TC Transfer Frame (TF) authenticated decryption and anti-replay control, pseudorandomization and BCH encoding. This module operates nominally at 64 kbit/s, but withstands up to 128 kbit/s.

The DCU-S(TM) module processes CADUs (Channel Access Data Units) received from the OBC transparently for the TRSPs. The processing is also done by a FPGA and includes: SP-L (Split-Phase-Level) line decoding, CADU delimitation, TF encryption and Security Header insertion (within secondary header), Reed-Solomon (RS) encoding, pseudo-randomization and SP-L encoding. VC (Virtual Channel) multiplexing is done by the OBC, so this module is not intended to insert (or remove) any additional bit in the bitstream. This module operates at two possible fixed rates, 1 Mbit/s and 128 kbit/s.

The DCU-X module processes CADUs received from the primary and secondary PDHUs (Payload Data Handling Units). The processing is also done by FPGAs and includes: input flow control, CADU delimitation, VC multiplexing, TF encryption and Security Header insertion (within insert zone), Reed-Solomon (RS) encoding, pseudo-randomization. The VC multiplexing is based on a Round-Robin scheduler, and Idle TFs are inserted automatically if no payload TF is available at the inputs. This module operates at fixed output rate of 280 Mbit/s, and withstands sustained input rates between 1 Mbit/s and 342 Mbit/s.

Crypto algorithms and keys:

All cryptographic algorithms used in SEOSAT are based on AES (Advanced Encryption Standard), and the modes of operation used are in accordance to the CCSDS recommended standard. 15) The algorithms are hard-coded in DCU's FPGAs. A set of cryptographic keys per functional DCU are available on-board. Part of them (session keys) can be updated in flight by means of secure commands, and part of them (master keys) are fixed throughout the mission. Keys are stored in DCU's non-volatile memory and are protected from potential corruption by means of triplication and EDAC (Error Detection And Correction) codes.

The initial key fill is performed while on ground via a dedicated connector on the satellite's skin (Key Fill I/F in Figure 8), and by means of a KFD (Key Fill Device). The KFD is a handheld battery-operated equipment that is used to transport the keys from the KMF (Key Management Facility) to the satellite, and to inject them directly into the DCUs (see also Figure 10). The Key Fill I/F is physically a "data diode", i.e. keys cannot be readout by any means once injected into the Satellite. As for any symmetric key system, the system security relies on the confidentiality of the keys. Anti-tamper mechanisms have been implemented in order to ensure DCU physical integrity while on ground.

Security function management:

Autonomous on-board monitoring of the DCUs is performed by the OBSW through the Mil-STD-1553 bus interfaces, and the associated HK-TM is also reported to GS. The DCUs can be managed from GS by means of the PUS (Packet Utilization Standard) TCs, which are processed by the OBSW. For non-security-related commands, plain TCs are used. For security-related commands (e.g. for key management), authenticated and encrypted messages are embedded into the TCs. When processed by the OBSW, these messages are decapsulated and blindly forwarded to the target DCU. The messages are finally decrypted and authenticated by the DCU's FPGA, and the resulting command is executed. This approach allows excluding OBSW from the security perimeter. Secure commands allow for example OTAR (Over-The-Air-Rekeying), key integrity checks and key disabling.

The security system can be operated in Secure Mode or Clear Mode, with security functions active or inactive, respectively. The satellite and the GS must be configured in the same mode and with the same crypto-parameters (if in Secure Mode), otherwise the TT&C may be interrupted. The security function configuration is nominally initiated by the GS, although in exceptional cases (e.g. autonomous reconfiguration) it can be initiated by the satellite.

Ground Segment constraints and operation:

SEOSAT's GS, specified by ESA and the satellite prime contractor, provides (among other information) the interface control documents, the mission operations concept and the satellite's user manual. For what the Security System and TT&C concerns, several constraints for the GS have been identified in these documents.

In general, TC TFs need to be encrypted, authenticated and sequence number stamped at uplink time while in Secure Mode, which implies that TT&C equipment shall process TC TFs on-the-fly. Optionally, pre-generated CLTUs could be uplinked by auxiliary FOS stations with no crypto-equipment, provided that the embedded TFs have sequential anti-replay stamps and use the COP-1 expedited service. However, the anti-replay acceptance window needs to be sized in order to avoid rejections in case re-transmissions are needed (e.g. due to channel errors). On the other hand, the on-board processing of some secure TCs can take longer than the minimum time specified for the inter-CLTU gap . In this case, the GS must insert a guard time (i.e. extend PLOP-2 CMM-4) after the TC.

Likewise, the HK-TM TFs need to be decrypted at downlink time while in Secure Mode by the TT&C equipment. However this is not strictly necessary, as the CLCWs (Command Link Control Words) in the TF Trailer fields are not encrypted (for any VC) and can therefore be extracted from the encrypted TF stream. Additionally, either in Clear or in Secure Modes, the Idle TFs are left un-encrypted, which allows the possibility of segregating the Idle TFs from the rest before the storage (if any) and decryption process. Regarding the PL-TM, in spite of the higher data rate, the TF processing on ground is less stringent for several reasons, namely: decryption can be performed off-line, the Idle TFs are also left un-encrypted (they can be discarded prior to storage and decryption), and the decryption function can process standalone PL-TM TFs with complete independence of previous TFs in the stream.

The satellite can initiate self-configuration under off-nominal situations, potentially configuring the satellite in an operational mode unexpected for the GS (different from the mode during previous contact). When this occurs outside the GS visibility, the TT&C link may be lost at the following pass. It is important for the operator to plan in advance how to handle such scenarios.

Since the PL-TM data on-board storage is massive, it may happen that a contact time is not long enough to complete the downlink of a big data file. The DCU-X implements input data flow override by command, allowing the operator to split the downlink along several contacts. Downlink in progress can be stopped preserving the encryption context, then resumed during the following contact.

Space data link protocols:

SEOSat's Security Layer is implemented at the Transfer Sublayer of the TC link and HK-TM link applicable protocols, respectively, 16) 17) and at the Data Link Protocol Sublayer of the PL-TM link applicable protocol. 18) The applicable standard for the TM (both HK and PL) Synchronization and Channel Coding Sublayer is provided in reference. 19) The Security Layer was specified ad-hoc for the SEOSat mission during 2009-10 timeframe, when there was still no related standardization available. This situation is well recognized in reference 20), where a summary is given for the recent CCSDS draft recommended standard for SDLS (Space Data Link Security) Protocol.21)

Transfer Sublayer Implementation Aspects:

First, the CLCWs are left un-encrypted so the COP-1 loop can be closed without needing TM decryption (actually with independence of the security mode). Second, the TC authenticated decryption on-board is performed prior to the FARM-1 process, therefore any channel error not detected at Synchronization and Channel Coding Sublayer (via BCH codes), and that could be eventually detected at TC TF level (by means of the ECF field), will result in authentication errors. Third, the TC TF rejection due to authentication errors will not reach the OBC, so from the FOP-1 process viewpoint they cannot be distinguished from channel errors. Fourth, TM TF decryption algorithm is self-synchronizing, so any interruption of the S-band downlink channel does not prevent the re-synchronization of the decryption process on ground. Finally, any potential contingency in the TC and TM links can be alleviated by a proper processing of DCU HK-TM (in order to discriminate errors) and by controlling the size of the TC anti-replay acceptance windows (in order to restrict or relax the allowed number of retransmissions).

Synchronization and Channel Coding Sublayer Implementation Aspects:

First, any loss of bit synchronization at the OBC to DCU-S TM interface may result in the loss of TM at GS. This can be caused by an operator error or by unexpected on-board error (e.g. due to Single Event Effects, SEEs). In this scenario, the DCU-S will generate a pseudo-randomized idle sequence (with no data structure) in order to feed the TRSP with modulation data. Otherwise, the TRSP would transmit an un-modulated carrier potentially violating ITU regulations on power flux density. Secondly, at the time of issuing the standard, no randomization scheme was agreed upon for high data rate TM (above 2 Msymbol/s). SEOSat's X-band symbol rate is 35 Msymbol/s (280 Mbit/s with 4D-8PSK-TCM modulation), so power flux density requirements could not be met during a continuous transmission of Idle TM TFs. The study 22) confirms that the ECSS standard polynomial does not provide enough randomness for long sequences of Idle TFs, resulting in power spectral density spurious above ITU recommendations. To improve randomness, DCU-X implements a configurable pseudo-randomizer (order 32 polynomial) for the Idle TM TF data field, in addition to the CCSDS standard randomizer (order 8 polynomial) for the RS codeblock. This second pseudo-randomizer can be enabled and disabled by command. Both randomizers are shown in Figure 9.


Figure 9: X-band TM pseudo-randomization implementation (image credit: EADS Astrium Crisa)

Comparison with Draft CCSDS SDLS Recommended Standard:

The first CCSDS SDLS protocol draft recommended standard (Ref. 21) was issued in February 2012. It aims at providing a common generic framework for TC, TM and AOS (Advanced Orbiting System) links, by defining additional protocol data unit fields and services. As opposed to it, the SEOSat implementation is ad-hoc and aims at inserting a low-overhead and low-impact Security Layer on the applicable standard protocol stack, and on the on-going system design. Both solutions place the Security Layer at the Transfer Sublayer, with some differences in the TF formats and security processing (encryption/authentication) which are shown in Figure 10.


Figure 10: CCSDS Transfer Frames (left) versus SEOSAT/Ingenio TM Transfer Frames (right), image credit: EADS Astrium Crisa

The CCSDS recommendation defines a common fixed-length Security Header (2-64 octets) and Security Trailer (8-64 octets), which are inserted around the Data Field. The Security Trailer includes just the MAC ( Message Authentication Code), and is optional. For TM TFs, SEOSAT's Security Layer uses the existing Secondary Header and Insert Zone fields in the ECSS and AOS standard TFs, respectively, for inserting (by overwriting specific octets) the Security Header. This solution avoids any overhead and allows keeping the TM TF format generated by the OBC and PDHU. It must be noted that the ECF (Error Control Field) is not used; otherwise it would need to be updated accordingly. The whole TF is error protected by the RS channel encoding (code (255,223) for TM and (255,239) for AOS). SEOSAT does not implement the TM TF authentication, whereas the CCSDS recommendation is to implement authenticated encryption.

Best way to find this kind of content is to google eoportal encryption and see what comes up.

Offline alamos

  • Member
  • Posts: 2
  • St-Louis
  • Liked: 0
  • Likes Given: 2
Re: Cybersecurity
« Reply #3 on: 05/01/2017 06:12 AM »
That was really helpful.
Thank you so much!

Offline Eer

  • Full Member
  • **
  • Posts: 283
  • Liked: 144
  • Likes Given: 138
Re: Cybersecurity
« Reply #4 on: 05/01/2017 09:25 AM »
Look, too, at the DARPA fleet sat RFPs like "System F6" (DARPA-BAA-11-01) published in October 2010. MLS spread across multiple sats where sats dynamically join and leave the fleet configuration.

From the 2010 BAA:
The goal of the System F6 program is to demonstrate the feasibility and benefits of
disaggregated—or fractionated—space architectures, wherein the functionality
traditionally co-resident within a single, large, “monolithic” satellite is delivered by a
cluster of wirelessly-interconnected modules capable of sharing their resources and
utilizing resources found elsewhere in the cluster.
1. Capability for semi-autonomous long-duration maintenance of a cluster and
cluster network, and to add and remove spacecraft modules to/from the cluster
and cluster network;
2. Capability to securely share resources across the cluster network with real time
guarantees and among payloads or users in multiple security domains;

Appendix A details the MultiLevel Security requirements.

[edit - corrected program from F7 to F6, removed offensive Tapatalk advertisement, and added quotes from the 2010 original BAA]

« Last Edit: 05/02/2017 09:00 PM by Eer »