Case Study - Centralized Data Flow Management for On-Premise Encryption | Leanspace

Table of Contents

Case Study – Centralized Data Flow Management for On-Premise Encryption & Decryption with Routes

Case Study – Centralized Data Flow Management for On-Premise Encryption & Decryption with Routes

In our previous article, we introduced you to Leanspace’s recently launched tool that hit the market: Routes. The tool solves major problems that impact the ability of satellite operators to scale their operations.

In this article, we explore how Leanspace helps growing satellite operators reach their next major milestones by using Routes to handle on-premise encryption and decryption.

Case Study Overview

In the satellite industry, managing data effectively and securely is of paramount importance. Everyday, we encounter space companies who struggle to scale their operations while ensuring data security and compliance.

A recent customer, who had recently launched an IOD, was seeking to build a new mission based on their previous learnings. They are seeking to do Earth Observation (EO) and grow towards a constellation.


Learnings from their first mission

At the time of their IOD mission, they did not have to encrypt and decrypt their telemetry and telecommands. For their next mission, they needed to demonstrate that they were compliant with certain cybersecurity requirements to prevent eavesdropping and tampering.

A potential solution would be for the manufacturer to own and supply the keys for encryption and decryption but the operator realized that this would not be a good fit for them long term.

A lack of control over their keys would be a serious problem as it severely limits the operators ability to evolve their cybersecurity setup, now and in the future. For instance, if a prospect has compliance related requirements, the operator would be limited in how they comply as they are bound to their manufacturer.

Instead, they were seeking to do their encryption and decryption on-premise, which gave them the control that they needed, such as key generation and processing, whilst enjoying all the benefits of the cloud.

If you’re unfamiliar with how the communication happens between your ground station and command and control system, check out this article here to learn more.

Constraints for their next mission

  • A scalable and maintainable cybersecurity setup to handle a constellation
  • Integration with a cybersecurity provider for on-premise encryption and decryption
  • Use a custom protocol to encrypt and decrypt a single frame 


Given these constraints, the operator chose Leanspace to handle the telemetry and a well-established cybersecurity provider to perform encryption/decryption on-premise.

The Solution

Part 1: Hardware Solution

From a hardware perspective, the satellite operator worked with the cybersecurity provider to install a hardware security module on-premise. This enabled the operator to both control and keep their encryption/decryption keys on-premise, whilst leveraging the processing capabilities of their cybersecurity provider.

Part 2: Software Solution

Using the Leanspace Routes tool, the operator created a yaml file, one for encryption and one for decryption, which modeled the data flows covering the inputs and outputs, data processing, and error handling for redundancy purposes. Let’s learn more about how this happens using a code block example.

How to build and manage the data flows of a cloud based space mission using Leanspace Routes

If you’re not familiar with the Routes tool by Leanspace, it’s a highly versatile tool, where you can easily model, deploy custom-code logic, and monitor dataflows. If you’re curious to learn more about the tool, check out the introductory blog here.

In the below diagram, the red arrows reflect the data flows from the satellite to the ground station, and onwards to the On-premise Mission Data Center, where the encryption and decryption occurs. It is then sent over to the Mission Control system in the Cloud via SSL

With the Routes tool, you can configure all of these flows within a single yaml file, which is what we’ll cover in today’s case study. We’ll walk you through each step before the final reveal of the full yaml file.

The first step is to identify the processors that are going to be used, along with the correct credentials that are to be used.
These have been referenced in the Route file in two places: Beans, to call the name and the Type which acts as the address (class) of the processor; and within the steps of the Route itself.

- beans:
    - name: decryptionProcessor
      type: io.leanspace.routes.processors.frameDecryptionProcessor("host.docker.internal:####", "00000000-0000-0000-0000-000000000000", "####", "AES_CBC_PKCS7")

As the constraints were to do decryption, a processor has been referenced (explained below), along with appropriate parameters. In this case, the API token and key ID. The Route will take this information and use it in the API call to the cybersecurity provider.

How the decryption processor works

As an overview of the process, the decryption processor, that we’ve referenced here, gets encrypted binary frames as its input and produces decrypted binary frames. 

When the encrypted binary frames are received, the Routes tool connects to a local encryption service (in this case, it was hosted on docker) to perform the actual decryption of the data.  

There is an authentication step, as the encryption service itself is also protected via a bearer token. To perform the decryption, the key id and algorithm (AES_CBC_PKCS7) is also required so that the encryption service knows which ones to use when processes the data. 

Satellite and Ground Station Transmission

When your telemetry is transmitted to your secure ground station environment, typically via a gRPC API, it will arrive in an encrypted state.
In this case, the Route uses an entry point of a TCP protocol, as seen in the below code block, connecting to a GSaaS provider for their telemetry downlink. Note that Routes also supports using local files, a Queue, or a TCP/UDP/HTTP or a custom protocol, if needed.

- route:
    id: tm
    from:
      uri: netty:tcp://0.0.0.0:11111

On-premise decryption

To perform the decryption on-premise, the encrypted telemetry is sent to the hardware security module (HSM) with an access token and a key id. This takes care of the authentication and tells the HSM which key id to use when processing.

        - process:
            ref: "decryptionProcessor"
        - process:
            ref: "#class:io.leanspace.routes.processors.FrameSplitterProcessor"

In the Route steps above, the decryption processor and the frame splitter are listed. Line [2], references the decryption processor, which will decrypt the entire frame. On line [4] there is an address of a custom processor for frame splitting using a custom protocol. 

What this means is that the keys never leave the on-premise, secure environment, allowing the operator to have complete control over their use.

Securing data in the Leanspace Platform

The final step in the process is sending the data to Leanspace. In this case, it is sent to the Bitstreams tool to map and store the operator’s time series data.

- to:
            uri: leanspace-stream:####-####
            parameters:
              tenant: leanspace
              clientId: ####
              clientSecret: ####

As all endpoints within the Leanspace Platform are protected by OpenID Connect, the client credentials and the secret allows the operator to use the streams connector to communicate with the Leanspace service. All communications occur over SSL, which helps ensure that they are secure from eavesdropping, or tampering for when it is in transit and at rest.

A complete Routes file

Below is a complete Routes file, which is based on the above explanation. You can see that all of the steps are modeled in a single file. Although it has not been captured in this case study, it has additional functionalities, such as Custom Processors. You can learn more about this in the Routes overview blog.

- beans:
    - name: decryptionProcessor
      type: io.leanspace.routes.processors.frameDecryptionProcessor("host.docker.internal:####", "00000000-0000-0000-0000-000000000000", "####", "AES_CBC_PKCS7")
     
- route:
    id: tm
    from:
      uri: netty:tcp://0.0.0.0:11111
      steps:
        - process:
            ref: "decryptionProcessor"
        - process:
            ref: "#class:io.leanspace.routes.processors.FrameSplitterProcessor"
        - to:
            uri: leanspace-stream:####-####
            parameters:
              tenant: leanspace
              clientId: ####
              clientSecret: ####

Conclusion

As you can see above, you always stay in control over the creation and management of your data flows, even within a compliant context. On-premise decryption does not have to be a difficult challenge to master, with Leanspace Routes you can be up and running in no time at all. 

If you are interested in learning more about how to create your own powerful on-premise solutions for your satellite operations, including creating your own processors with specific requirements, reach out to one of our engineers.

DISCOVER MORE BLOG ARTICLES

Get Leanspace Insights

Sign up for the latest product releases and updates, delivered straight to your inbox each month.

JOIN OUR TEAM

Discover our exciting job vacancies.
We are constantly hiring.
Come and join the Leanspace adventure!

CONNECT WITH US

MEDIA

Introducing ITAR compatible Deployment Options! The freedom to deploy on your terms is here!

X