Here are the comments from Jeronimo Bezerra on encryption options:
Ignoring scenarios where an attacker would have physical access to the Summit, Base, or Archive Datacenters, there are a few scenarios we could tackle to protect the data flows:
1) Encrypt the data before sending it from Summit or Base. If we encrypt the payload (image and reports), we would add a layer of complexity to unauthorized access. Decrypting it won’t be an extremely challenging using current technology, but by the time the payload is decrypted, that information is no longer useful (assuming the satellites are constantly moving). It will require CPU and memory, probably going to make payload larger and delay transfers by [milli]seconds. However, it is doable.
2) On top (recommended) of option #1 or in parallel (not recommended), we could add a layer of protection by encrypting at Layer 4 (Transport) using TLS. Easy to implement, not expensive. It will require CPU and memory, probably going to make payload larger and delay transfers by [milli]seconds. However, it is doable.
3) Encrypting at Layer 3 using IPSEC from source to the destination:
a. If done from the Distributors/Forwarders: It will require CPU and memory, probably going to make payload larger. It will increase OPEX and demand engagement from the IT team. However, it is doable.
b. If a new IPSEC appliance is used to encrypt traffic from all Distributors/Forwarders: Single going to failure, high CAPEX, low OPEX once it is deployed. Better than #3.a
4) Encrypting at Layer 2 using MACSEC: Juniper has routers capable of doing it at line-rate. However, we would need to understand what to do in the path from Chile to NCSA. High CAPEX, Medium OPEX.
5) Encrypting at Layer 1: Surreal (nearly impossible) CAPEX. Low OPEX. It only makes sense when combined with one or more options above. Ideal for Summit to Base. Not for international connectivity.