Ensuring cybersecurity for smallsats is becoming an increasingly important challenge. This article discusses five key areas of security optimization and was provided by cybersecurity company CYSEC.
Smallsats are gaining incredible traction in the space segment with more than 1,000 new satellites expected to launch each year over the next decade. They offer a combination of short time-to-market and powerful new capabilities that expand potential applications and service models.
In the rush to build and launch these new systems, operators and manufacturers have prioritized speed, affordability and flexibility. Security, if considered at all, is often an afterthought despite the sensitive data smallsats create and transmit, which makes them an attractive target for cyber attacks.
There are two primary reasons for this. First, manufacturers historically do not usually have an ingrained culture of cybersecurity for smallsats; engineers are space engineers first and won’t necessarily have security training and expertise. Second, smallsats are an underserved market when it comes to off-the-shelf security solutions.
Security providers are beginning to address the latter. CYSEC’s ARCA and ARCASPACE comprise one of the first end-to-end security solutions on the market designed to protect on-ground and in-orbit satellite communications. To address the former, it’s important for space engineers, operators and manufacturers to be familiar with key security concepts so they can start to embed cybersecurity into their culture. This article will explain five of those concepts as they pertain to smallsat operations.
1. Encryption and cryptographic keys
Since a physical attack on an orbiting satellite can still be reasonably considered science fiction, it’s important to recognize that a cyber attack against a satellite will be rooted from the ground.
A ground attack can occur during the satellite’s development phase—e.g., by placing an invisible backdoor or malware on board before launch—or through the ground infrastructure during operation—e.g., by accessing cloud services, ground stations or mission control.
In addition, current trends such as of greater satellite connectivity, increasingly complex and powerful on-board software, use of third-party services, are all increasing the attack surface by opening up more vulnerabilities.
To protect satellite communications and data, most satellite operators rely on encryption, in particular on the Advanced Encryption Standard (AES), to encrypt the uplink and downlink. AES has been the standard in security since 2002 and is extremely resilient against brute force attacks.
However, AES alone is not enough to ensure secure communication for smallsats. Transforming plain text into a cipher during encryption requires an algorithm and a cryptographic key (also known as a secret).
Since AES is a symmetric algorithm, the key used to encrypt a telecommand on the ground would be the same key used to decrypt it on board. If the key is compromised in any way, then the information transmitted is also compromised.
Symmetric encryption shows even greater limitations when many satellites are part of a single constellation. One cannot imagine using the same secret for all of them. A compromise of one would result in a compromise of the entire fleet.
As a result, the level of protection provided by an encryption algorithm is directly linked to the level of trust one has in the secrets used by that algorithm, regardless of its complexity.
Secrets can be compromised, for example, by using weak techniques for their generation, poor management practices on ground, such as sharing secrets via unprotected email services, or by underestimating the risk of attack after they have been injected on board, but before the satellite has launched (e.g. during transportation or at the launch site).
Therefore, we need a more complete solution for securing keys on ground and on board. This is where establishing a root of trust comes in.
2. Roots of trust and confidential computing
As explained above, it is essential to be able to trust the cryptographic operations, keys and, more generally speaking, any applications considered mission-critical that are used on ground and on board. The basis of this trust comes in the concept of root of trust (RoT).
RoT refers to the environment where secrets are generated and stored, typically in the ground servers or the cloud infrastructure of the Mission Control Center (MCC), or in the on-board computer (OBC). An RoT is made up of highly reliable hardware, firmware and software components that are designed to perform these very specific, critical security functions.
RoTs provide a firm foundation from which to build security and trust, but the mere existence of an RoT is not enough. Attackers can also exploit the logic associated with the hardware and software that rely on the secrets in order to access confidential data stored in memory. Protecting that logic requires an additional layer of security known as confidential computing.
Confidential computing represents the next frontier in cybersecurity for smallsats, allowing operators to process encrypted data in memory in order to protect data while it’s in use.
An example of confidential computing in action is the trusted execution environment (TEE). A TEE is an environment that provides a level of assurance for data integrity, data confidentiality and code integrity, and that prevents unauthorized entities from having access to data and logic.
These entities include other applications on the host, the host operating system and hypervisor, system administrators, service providers, the infrastructure owner, or anyone else with physical access to the hardware or software.
TEEs are gaining adoption in terrestrial markets and are a way forward for protecting space infrastructures—both on ground to protect the Mission Control Software (MCS) and secrets used to communicate with the satellite, as well as on board to provide a secure environment for the software executed in the OBC.
3. End-to-end security architecture
Though attacks during flight can only be ground-based, it is nevertheless paramount to trust the on-board secrets, software and hardware the satellite will use to collect, process and transmit sensitive information to the ground, while also preserving their confidentiality, integrity and availability.
This requires an end-to-end approach to securely storing the cryptographic secrets that enable space operations at the platform and payload levels. An end-to-end security architecture involves security mechanisms both on ground and on board that can perform the following operations:
- encrypt/decrypt the uplink,
- decrypt/encrypt the downlink,
- authenticate satellites and ground segments,
- create/verify the signature of software updates for reconfiguration and
- secure the key management lifecycle.
While there are several known mechanisms for securing the ground segment, development for the space segment has lagged.
CYSEC has worked to close the gap with its confidential computing package designed for commercial space missions. ARCA on ground, a trusted execution environment with a hardware-based cryptographic backend and a trusted operating system, protects cryptographic secrets and applications such as the MCS.
ARCASPACE provides an on-board RoT to store cryptographic secrets and perform cryptographic operations and key management. The result is a secure, end-to-end communication channel between the ground and the satellite, ensuring the confidentiality, integrity and availability of the transmitted data.
4. Security by design
It is a classic pitfall in the space industry, as well as in terrestrial markets, to jump right into implementation of a security mechanism without having the larger picture in mind. Security design and implementation are just two of the eight phases required for deploying an end-to-end security architecture. Before the design phase can begin, it is important to:
- define relevant threats and assess impacts,
- map out risk scenarios, and
- understand the trade-off between acceptable and unacceptable risks.
1) Threat modeling
During the threat modeling phase, smallsat operators should define the profile of potential attackers, their level of knowledge, their resources and their motivations, as well as the impacts to the system should an attack occur. This phase is essential as it sets the foundation for the rest of the process and drives the ultimate outcome.
For example, a nanosat operator could define potential attackers as “bored students trying to hack the university’s nanosat just for fun”; whereas a commercial operator contracting its platform to business-to-government (B2G) customers is more likely to define its profile of attackers as national agencies with significant resources and experienced hackers.
2) Risk analysis
Once attacker profiles have been defined, operators should draw up all the potential risk scenarios. This phase usually takes the form of a brainstorming session with inputs from both the operator’s technical team and an external offensive team of qualified ethical hackers.
The scenarios will typically be numerous—there could easily be over 100 for a simple smallsat mission. In order to prepare for the next phase, the scenarios should be plotted on a graph based on likelihood and severity. It’s also important for operators to estimate the level of effort required to mitigate each scenario.
3) Risk trade-off
Once the list of scenarios has been created, operators should determine which risks can be considered acceptable and which ones must be mitigated.
For example, an operator of a two-year CubeSat mission would likely accept the risk associated with not being able to upgrade its cryptographic algorithms in orbit to prevent post-quantum attacks. However, the operator of a sensitive GEO satcom mission lasting 15 years may find this risk unacceptable.
On the scenario plot, these risk trade-offs can be represented visually by a diagonal line that separates the risks to be mitigated (high severity, high likelihood) from the risk identified as acceptable (low severity, low likelihood).
4) And only after … architecture design
Obviously, each use case or mission scenario is unique, and each operator or client will have its own definition of what the level of risk can be considered acceptable. This will result in a unique architecture, but the central concepts will still apply.
Innovators in the NewSpace movement in particular have an opportunity to follow a security by design approach. Rather than bolting security mechanisms onto an existing flawed architecture, manufacturers can identify and improve weak spots in the architecture while the satellite is in development, not only building resilience to attacks but actually developing a stronger overall system. This is the concept behind “antifragility”, which is closely linked to security by design.
5. Zero trust
Zero trust is an approach that is seeing wider and wider adoption in terrestrial markets and can help shrink the risk associated with the growing popularity of “as-a-service” models. According to the National Institute of Standards and Technology (NIST), a zero trust approach “assumes there is no implicit trust granted to assets or user accounts based solely on their physical or network location” where “authentication and authorization are discrete functions before a session to an enterprise resource is established.”
More and more stakeholders in the space industry are adopting “as a service” models (e.g., satellite- or ground segment-as-a-service) that allow clients to share a platform by bringing their own payload without having to develop, launch and operate their own satellite.
This presents a very attractive value proposition but requires delegating trust to a third party. Trust, after all, is essential for secure satellite operations and communication. A zero trust approach can help ensure that trust is maintained even when the platform is shared with payloads owned by different organizations.
For example, instead of automatically granting clients access to the secrets stored in the OBC (including those used in telemetry and telecommand (TMTC) encryption), cryptographic operations can be performed on the payload itself, independent of the main satellite OBC. Secrets are injected on ground and are only known and managed by the client. This separates security of the location (OBC) from security of the asset (payload data) and the user (client).
In this case, CYSEC ARCA and ARCASPACE for example allow users to generate and store cryptographic secrets on board the payload that are only known to them. As a result, only they can access the data on ground, which ensures confidentiality, due to encryption, and integrity due to the authentication and signature process.
Conclusion – cybersecurity for smallsats
Understanding these concepts is key to increasing cybersecurity maturity within the space segment. To capitalize on advancements related to smallsats, the Newspace revolution and new “as-a-service” models, satellite operators and manufacturers must prioritize security at the same level as speed, affordability, and flexibility. Otherwise, the benefits to be gained could easily be erased by one successful cyber attack.
In addition, with competition increasing in the market around the world, developing a more robust approach to satellite development or service provision can become a key commercial differentiator for the future.
To find out more about CYSEC please view their satsearch supplier hub here. CYSEC is also organizing the first European executive event on space industry cybersecurity that is taking place virtually from 17-19 of March 2021 as part of Davos. Find out more here at the event website.