Encrypted satellite communications

Abstract

1. A method for providing encrypted communications for transmission via a satellite, the method comprising: providing a transport layer session with a secure server via a satellite; generating a cryptographic session public / private key pair using a hardware-based cryptographic processor; sending a message including the public session key to a secure server over a transport layer session; receiving a response from the secure server, the response comprising the public key; calculating a shared key in a hardware-based cryptographic processor using the received public key and the generated private key; encrypting payload data using a shared key; sending the encrypted payload data to a secure server; Equipped with.

Description

[Technical Field]

[0001] This application relates to the provision of encrypted wireless communications over satellite. More particularly, this application relates to a method for the provision of encrypted wireless communications over a commercial satellite link, and an associated apparatus for carrying out the method. [Background technology]

[0002] Satellite communications are a key part of national security and defense-related government communications (Govsatcom), with many use cases that can include surveillance, crisis management, critical infrastructure management, border control, and election monitoring. Govsatcom traffic is projected to grow 25-fold by 2040, with civilian applications representing the majority of usage (approximately 80%). Therefore, solutions must be found to accommodate the growing traffic. While some private satcom providers offer dedicated national services, these are expensive and tend to run on only a small portion of the available bandwidth. This creates availability issues. Additionally, users must still trust the provider, which raises security concerns, particularly data confidentiality.

[0003] Using commercial satellite communications (Comsatcom) capabilities for government users would solve most of the problems described above. However, a major obstacle to making Comsatcom accessible to government users is the level of security, as existing commercial implementations suffer from various identified security flaws that need to be addressed.

[0004] The main reason behind the lack of security at existing Comsatcom is that most satellite internet service providers (ISPs) do not offer over-the-air encryption within their satellite networks because known techniques such as VPNs significantly impact the performance of the link, usually increasing latency. Summary of the Invention [Problem to be solved by the invention]

[0005] It is an object of the present invention to overcome or mitigate at least some of the above-mentioned problems. [Means for solving the problem]

[0006] In a first aspect, there is provided a method of providing encrypted communications for transmission via a satellite, the method comprising: providing a transport layer session with a secure server via a satellite; generating a cryptographic public-private key pair using a hardware-based cryptographic processor; sending a message including the public key to a secure server over a transport layer session; receiving a response from the secure server, the response comprising the public key; calculating a shared key in a hardware-based cryptographic processor using the received public key and the generated private key; encrypting payload data using a shared key; sending the encrypted payload data to a secure server; Equipped with.

[0007] Thus, by using a hardware-based crypto-processor, the method can be implemented in a highly secure manner.

[0008] In an embodiment, the hardware-based cryptographic processor is configured to communicate with the transport layer session solely through a software interface operating within the secure processing environment, and thus the hardware-based cryptographic processor may be operated in a secure manner.

[0009] In embodiments, the transport layer session operates outside the secure processing environment, and a software interface operating within the secure processing environment communicates with the transport layer session indirectly through a second software interface operating outside the secure processing environment. Thus, despite operating outside the secure processing environment, the transport layer session can communicate with the hardware-based cryptographic processor in a secure manner without requiring extensive modifications to the transport layer session.

[0010] In some embodiments, the transport layer session is a QUIC session, and the method further comprises receiving payload data to be transmitted in the form of a TCP connection and transmitting the received payload data over an encrypted QUIC stream. Thus, standard network protocols can be employed, and the method is capable of receiving data in a format typical of Internet data.

[0011] In some embodiments, a QUIC stream comprises multiple multiplexed connections, and thus the method can enable high throughput of data, transmitting data from multiple user devices over a single stream.

[0012] In some embodiments, the generated public-private key pair comprises a static key pair and an ephemeral key pair, and sending the message comprises sending a message including the static public key and sending a message including the ephemeral public key. Thus, the method can provide a means for both encrypting data and authenticating communicating remote devices.

[0013] In some embodiments, the transmission of the message containing the public key forms part of a Transport Layer Security (TLS) version 1.3 handshake procedure. In some embodiments, the public key is transmitted in the first message of the handshake procedure. Thus, the method can employ a highly time-efficient handshake procedure that can be completed in fewer round trips than would be possible using TCP.

[0014] In some embodiments, the method is partially performed in software, and the integrity of the software is verified upon boot using information from a hardware-based cryptographic processor. In some embodiments, a secure processing environment (305) in combination with a hardware-based cryptographic processor (307) executes all processes that use cryptographic keys. In some embodiments, the software is immutable. Thus, the method can be highly resistant to external attacks.

[0015] In a second aspect, there is provided a secure router device configured to perform encrypted communications over a satellite, the device comprising: a hardware-based cryptographic processor; a processing environment, and a secure router device providing a transport layer session with a secure server via a satellite; generating a cryptographic public-private key pair in a hardware-based cryptographic processor; sending a message including the public key to a secure server over a transport layer session; receiving a response from the secure server, the response comprising the public key; calculating a shared key using the received public key and the generated private key; encrypting payload data using a shared key; Sending the encrypted payload data to a secure server; The device is configured to:

[0016] In some embodiments, the cryptographic processor comprises a Trusted Platform Module (TPM). In some embodiments, the TPM is a certified device. Thus, a low-cost device can be used to achieve the required level of security.

[0017] In some embodiments, the hardware cryptographic processor (307) is configured to communicate with the transport layer session through a software interface (323) that operates within a secure processing environment (305) implemented using ARM TrustZone security extensions. Thus, a low-cost processing system can be used to achieve the required level of security.

[0018] In a further aspect, there is provided a computer program product comprising computer readable instructions which, when implemented on a system comprising a processor and a hardware cryptographic processor, perform all of the steps of the method of the first aspect, as well as a computer readable medium comprising such a computer program.

[0019] The present invention will now be described with reference to the accompanying drawings. [Brief explanation of the drawings]

[0020] [Figure 1] 1 illustrates a prior art satellite communication system; [Figure 2] 1 illustrates a satellite communication system according to an embodiment. [Figure 3] FIG. 3 is a diagram showing details of a router used in the system of FIG. 2. [Figure 4] FIG. 4 illustrates details of the method of operation of the router of FIG. 3. [Figure 5] FIG. 4 shows details of an alternative method of operation of the router of FIG. 3. [Figure 6] FIG. 4 shows details of a server for use with the router of FIG. 3. [Figure 7] 3 is a diagram illustrating the operation result of the communication system of FIG. 2. DETAILED DESCRIPTION OF THE INVENTION

[0021] 1 shows a typical scenario in the prior art in which a user device 101 is communicating with a destination server 113 via a satellite 107. The user device 101 can be any type of user device, such as a computer workstation, a laptop, a mobile phone, a tablet computer, or an Internet of Things (IoT) device. The destination server 113 can be any server device that allows for external communications, such as an Internet server.

[0022] In the prior art, a user device 101 communicates 115 with a first satellite ground station 105 through a router 102. The communication is established using one or more communication protocols that enable the transport of data from the user device 101 to the router and then to the first satellite ground station 105. This transfer of data typically occurs over the Internet and may be implemented in a wired or wireless manner, or some combination of the two. The first satellite ground station includes a modem device, which it uses to transmit data to a satellite 107, which in turn transmits the data to a second ground station 109. The transmission of data between the satellite 107 and the ground stations 105, 109 may be accomplished using the Transmission Control Protocol TCP or another protocol, such as DVB or ATSC.

[0023] The second ground station 109 transmits the data to the server 110 and then to the destination server 113, again, this transmission may be accomplished using one or more communication protocols that enable the transport of data.

[0024] When transmitting data over the Internet, if encryption is to be used, a virtual private network (VPN) may be employed. VPNs tend to cause a small reduction in available bandwidth when implemented over terrestrial Internet connections, but tend to have a significant detrimental effect when satellite communications are used. Most of this detrimental effect arises due to the large latency associated with transmission to and from geostationary satellites. This latency can be reduced by using satellites in low Earth orbit, but this comes at the expense of increased system complexity. Therefore, the architecture shown in FIG. 1 is generally not suitable for transmitting encrypted data using known techniques.

[0025] Figure 2 shows an architecture according to one embodiment. Similar to the architecture of Figure 1, the user device 101 is configured to communicate with a destination server 113. However, in this embodiment's architecture, the user device 101 is configured to communicate 115 with a secure router 103 located between the user device 101 and a first ground station 105. The secure router 103 can be located on the premises of the first ground station 105, on the premises where the user device 101 is located, or somewhere else. In some embodiments, the secure router 103 can form part of the user device 101. In other embodiments, the secure router 103 can form part of a satellite modem located at the first ground station 105.

[0026] The user device 101 communicates 115 with the secure router 103 using one or more communication protocols that enable the transport of data. In some embodiments, the protocol is TCP over Ethernet or Wi-Fi. In further embodiments, the protocol is Bluetooth, WIMAX, or LoRa.

[0027] In embodiments where secure router 103 is located along with a user device, e.g., within a private network in which user device 101 also resides, communications between user device 101 and secure router 103 need not be encrypted. Conversely, in embodiments where user device 101 is remote from secure router 103, data is typically exchanged in encrypted form. Such encrypted exchanges may be accomplished using a VPN.

[0028] Upon receiving the data, secure router 103 converts the data format to a general-purpose transport layer protocol, such as QUIC, and encrypts the data using cryptography. In embodiments where the QUIC protocol is used, the data is transmitted using User Datagram Protocol (UDP). In such embodiments, multiple streams of data may be multiplexed so that they are transmitted within a single QUIC stream. Secure router 103 may employ a secure performance-enhancing proxy (SPEP) to format and encrypt the data. Further details of the operation of secure router 103 are described below with respect to FIG. 3.

[0029] The encrypted data from secure router 103 is transmitted (117) to first ground station 105, then to satellite 107, and then to second ground station 109. From second ground station 109, the encrypted data is transmitted (119) to secure server 111. Secure server 111 may include components essentially similar to those of first secure router 103 and may perform decryption and reconversion of the data, for example, back to the TCP protocol. Secure server 111 also includes components for performing the tasks of a server device.

[0030] Secure server 111 then transmits 121 the decrypted data to destination server 113. Secure server 111 may be located on the premises of second ground station 109, on the premises where destination server 113 is located, or at some other location. In some embodiments, secure server 111 may form part of destination server 113. In some embodiments, secure server 111 may be cloud-based.

[0031] In embodiments in which secure server 111 is located with destination server 113, e.g., within a private network in which destination server 113 also resides, communications between secure server 111 and destination server 113 need not be encrypted. Conversely, in embodiments in which destination server 113 is remote from secure server 111, data is typically exchanged in encrypted form. Such encrypted exchange may again be accomplished using a VPN.

[0032] For data flow from destination server 113 to user device 101, the process described above is reversed.

[0033] 3 shows further details of the secure router 103. The secure router 103 includes a processing environment 303 comprising a processor and memory (not shown). In an exemplary embodiment, the processing environment may be based on an ARM processor, such as an ARM Cortex-A processor, which may be an ARM Cortex-A7 32-bit RISC core.

[0034] In embodiments in which the secure processing portion 305 is within the processing environment 303 and the processing environment 303 is implemented on an ARM processor, the secure portion 305 may be implemented using ARM TrustZone technology. A hardware cryptographic processor 307 is included within the secure router 103. The hardware cryptographic processor contains cryptographic keys. These keys may either be stored during manufacture of the hardware cryptographic processor 307 or generated by the device during operation, or both. The cryptographic keys may be used to authenticate a remote device, such as the secure server 111, and / or provide an asymmetric key pair for a key exchange process, and subsequently to encrypt and decrypt payload data to be transmitted across a link between the user device 101 and the secure server 111. In some embodiments, the hardware cryptographic processor is a Trusted Platform Module (TPM), and in some embodiments, the TPM is an ST33TPHF20SPI device. The secure processing environment may also be referred to as a secure enclave.

[0035] In some embodiments, both the secure processing environment 305 and the (non-secure) processing environment 303 execute simultaneously on a single processing core.

[0036] A secure performance enhancement proxy (SPEP) 309 is configured to operate within processing environment 303. In an embodiment, SPEP 309 is configured to operate within a secure operating system that is outside of secure processing portion 305. Typically, there is insufficient processing power within secure portion 305 for SPEP 309 to operate within. Thus, by operating within a secure operating system, SPEP 309 may be more secure than if it were operating within an insecure operating system.

[0037] Cryptographic services 311 are established to provide an interface between SPEP 309 and hardware cryptographic processor 307. Cryptographic services 311 also provide a key management system for handling cryptographic keys from hardware cryptographic processor 307. Cryptographic services 311 are configured to operate partially within secure processing portion 305 and partially outside within the secure operating system.

[0038] The portion of cryptographic services 311 that operates within secure processing portion 305 is cryptographic operations portion 323. Because cryptographic operations portion 323 operates within secure processing portion 305, it is able to handle cryptographic keys and associated cryptographic data securely.

[0039] The portion of cryptographic services 311 that operates outside of secure processing portion 305 is cryptographic application programming interface (API) 321. Cryptographic API 321 provides a means for SPEP 309 to interface with cryptographic processor 307 via cryptographic operations 323. In an embodiment, cryptographic API 321 is configured to be the only means by which SPEP 309 can communicate with cryptographic processor 307, thereby providing a high degree of security for cryptographic data. Moreover, because only cryptographic operations 323 can communicate with cryptographic processor 307, to the user, router 103 appears to be a standard router without secure processing portion 305 or cryptographic processor 307.

[0040] Moreover, those skilled in the art will recognize that SPEP 309 is not typically configured to interface with hardware cryptographic processor 307 or secure processing environment 305, and thus use of cryptographic API 321 allows for such interfacing without significant modifications to SPEP 309. Thus, advantageously, SPEP 309 can be standard software.

[0041] In contrast, if the API 321 were located within the secure processing environment 305, the SPEP 309 software would require modification to enable interaction with the hardware cryptographic processor 307 via the secure processing environment 305.

[0042] In operation, when sending data to a destination server 113, the secure router 103 receives data from the user device 101, typically formatted in TCP (115). The SPEP 309 reformats the received data. The SPEP 309 also requests the cryptographic service 311 to encrypt the reformatted data using the cryptographic key received from the cryptographic processor 307. The SPEP then transmits the data to the first ground station 105 (117). Typically, data sent to the first ground station 105 is formatted in UDP and encapsulated by the SPEP. The encapsulated data is transmitted by tunneling. When receiving data from the first ground station 105 at the user device 101, the process is reversed. Thus, encrypted data in UDP format is received from the first ground station 105, decrypted, reformatted, and / or decapsulated into TCP, and transmitted to the user device 101 in TCP format.

[0043] In operation, secure router 103 intercepts and terminates all incoming connections, such as TCP connections, and sends the tunneled, encrypted QUIC stream to secure server 111. At secure server 111, the tunneled traffic is decapsulated and decrypted by secure server 111. Secure server 111 then routes the decapsulated traffic through the Internet as if it were secure router 103. Typically, secure server 111 converts the decrypted data back to TCP format before transmission to destination server 113.

[0044] When a response is received by secure server 111 from the Internet, the same process is performed in reverse using the established QUIC stream. If the QUIC stream is not established when the response is received, the process to establish the QUIC stream is performed again.

[0045] In a further embodiment according to FIG. 3, secure boot procedures and / or access controls are employed within the secure router 103. Thus, in such an embodiment, the integrity of operating system files executing on the secure operating system on the secure router 103 is verified at each boot instance of the software. In such an embodiment, the authenticity of all files executing within the processing environment 303, both within the secure portion 305 and outside the secure portion 303, can be verified. However, there is typically no verification performed on modules of applications executing on the secure router 103 that are not involved in encrypting or transmitting data. Moreover, there is typically no verification performed on the hardware cryptographic processor 307. In some embodiments, the cryptographic processor 307 is configured to provide a hardware root-of-trust.

[0046] In some embodiments according to FIG. 3, all steps employing cryptographic keys are undertaken within the secure processing environment 305.

[0047] Figure 4 shows further details of the method of operation of the secure router 103 according to Figure 3. The secure router 103 is configured to establish (S401) a QUIC session that provides a data link between the secure router 103 and the secure server 111. The data link may be based on the QUIC transport layer network protocol.

[0048] Cryptographic processor 307 then generates a public / private cryptographic key pair (S403). Those skilled in the art will recognize how a cryptographic processor can be used to generate such a key pair, so no further description is provided here. The trigger for generating the key pair may be receipt at secure router 103 of a message indicating that user device 101 desires to establish a communications link with destination server 113. Although not shown, secure server 111 also generates a similar cryptographic key pair. The trigger for generating the key pair at secure server 111 may be receipt at secure server 111 of a message indicating that user device 101 desires to establish a communications link with destination server 113.

[0049] Secure router 103 then transmits the public key from the key pair over the QUIC session to secure server 111 (S405). Similarly (not shown), secure server 111 transmits its public key over the QUIC session to secure router 103, where it is received (S407).

[0050] Steps S405 and S407 are commonly referred to together as a process of key exchange, and more particularly, as a process of asymmetric key exchange.

[0051] Secure router 103 (and similarly secure server 111) can each calculate a shared key using the received public keys and their corresponding private keys (S409) using known methods. The routers can then use the shared key to encrypt payload data received from user device 101 (S411) and transmit the encrypted data using the QUIC session (S413).

[0052] 5 illustrates an alternative method of operation of secure router 103 according to one embodiment. Secure router 103 is configured to establish (S501) a QUIC session that provides a data link between secure router 103 and secure server 111. The data link can be based on the QUIC transport layer network protocol. By using a QUIC session, the ISP of the satellite link employed does not need to install a PEP server at the ISP's gateway to decapsulate encrypted traffic. Rather, users of the satellite link only need to QUIC tunnel their traffic through the ISP gateway for receipt at secure server 111.

[0053] The cryptographic processor 307 then generates an ephemeral public-private key pair (S503) and employs the pre-shared certificate for authentication. Those skilled in the art will recognize how a cryptographic processor can be used to generate such a key pair, so no further description will be provided here. The trigger for generating the key pair may be receipt at the secure router 103 of a message indicating that the user device 101 desires to establish a communications link with the destination server 113. Although not shown, the secure server 111 also generates a similar static encryption key and an ephemeral encryption key pair. The trigger for generating the key pair at the secure server 111 may be receipt at the secure server 111 of a message indicating that the user device 101 desires to establish a communications link with the destination server 113.

[0054] Secure router 103 then transmits the static public key and the ephemeral public key over the QUIC session to secure server 111 (S505). Similarly (not shown), secure server 111 transmits its public static key and public ephemeral key over the QUIC session to secure router 103, where they are received (S507).

[0055] Secure router 103 (and similarly secure server 111) can each authenticate the other using the received public static key and their corresponding private static key. Secure router 103 and secure server 111 can then calculate a shared key using the received public ephemeral key and their corresponding private ephemeral key (S509) using known methods. The router can then use the shared key to encrypt payload data received from user device 101 (S511) and transmit the encrypted data using the QUIC session (S513).

[0056] Thus, in embodiments in which both static and ephemeral keys are employed, the static keys can be used to provide secure router 103 with a level of authentication that identifies secure server 111, and vice versa. The ephemeral keys ensure that if the static portion is compromised after several transactions have occurred, an eavesdropper will still not be able to derive the shared key because the ephemeral portion changes between different sessions. This process is commonly referred to as forward secrecy. Those skilled in the art are familiar with the process of forward secrecy, and therefore no further explanation is provided here.

[0057] In some embodiments, when secure router 103 and secure server 111 initially communicate with each other during a session, TLS protocol version 1.3 is employed. In such embodiments, a handshake protocol may be used to enable secure router 103 and secure server 111 to negotiate the protocol version, select cryptographic algorithms, authenticate each other, and establish a shared secret key. In some embodiments using TLS 1.3, a key exchange mode employing pre-shared keys (PSK) (static keys) and elliptic curve Diffie-Hellmann exchange (EC(DHE)) (ephemeral keys) is employed.

[0058] In some embodiments, EC(DHE) may comprise the X25519 or P-256 key exchange algorithm. In such embodiments, with a limited set of available options, secure router 103 may choose to send Diffie-Hellmann key shares on the first trip in the handshake process. By doing this, secure server 111 knows the shared key and can send encrypted data one round trip sooner than would otherwise be possible. Thus, such embodiments enable a more efficient process for establishing secure communications.

[0059] In embodiments where TLS 1.3 is employed, zero round-trip time resumption (0-RTT) data may be used. In such embodiments using PSK, the secure router 103 can send encrypted data earlier in the handshake procedure than would otherwise be possible. Thus, such embodiments allow for a more efficient process for establishing secure communications.

[0060] Typically, when using TLS 1.3, the cryptographic primitives (i.e., the low-level cryptographic algorithms used to construct the cryptographic protocol) are received from a software library, such as OpenSSL or other library. Thus, a software library is used to perform the cryptographic operations. In contrast, in embodiments such as those described herein, a hardware cryptographic processor 307 is used to perform these cryptographic operations.

[0061] Because the hardware cryptographic processor 307 is a hardware device, it is more resistant to attacks than a software device. Therefore, the architecture of the secure router 103 provides an improved level of security compared to purely software-based implementations of cryptographic systems. Moreover, because the secure router 103 employs a secure processing environment, and the private cryptographic key remains within this environment, the level of security of the secure router 103 is further improved.

[0062] Moreover, in embodiments in which the cryptographic processor 307 includes a Trusted Platform Module (TPM) and / or the secure processing environment 305 includes ARM TrustZone security extensions, a high level of security may be achieved using relatively simple, inexpensive, and compact components. Moreover, such TPM devices may be certified devices, with a certificate verifying that the TPM meets a set of compliance and security requirements.

[0063] Furthermore, by employing QUIC in the described manner, the handshake procedure is simple so that the setup of a QUIC stream can be negotiated in a single round trip. Moreover, QUIC does not require that all data packets in a stream be processed in any particular order. Therefore, multiple TCP flows can be enabled within a single encrypted QUIC session.

[0064] In a further embodiment, in combination with any of the previously described embodiments, a public key infrastructure (PKI) may be used. In such an embodiment, a trusted third party is additionally used as a certificate authority (CA). Either the secure router 103 or the secure server 111, or both, can obtain a digital certificate from the CA to authenticate other parties. When using a PKI, all cryptographic material, including certificates and cryptographic keys, is securely stored within the hardware crypto processor 307. Those skilled in the art will understand how to institute such authentication and storage, and therefore no further description is provided here.

[0065] In some embodiments, the operating system files on which SPEP 309 runs are immutable. In further embodiments, the files that provide cryptographic services 311 are also immutable. Thus, secure router 103 is highly secure from software-based attacks.

[0066] In some embodiments, the shared key may remain valid until the end of communication between the user device 101 and the destination server 113. In alternative embodiments, a time limit may be placed on the shared key, at the end of which the shared key may be invalidated. In some embodiments, the time limit may be one hour.

[0067] 6 illustrates architectural details of secure server 111 according to some embodiments. Secure server 111 comprises a processing environment 603. Processing environment 603 hosts first secure container 621 and second secure container 629. First secure container 621 and second secure container 629 comprise software packages that are isolated from both other software and other processes executing within processing environment 603. First secure container 621 is configured to host a cryptographic API 623. Similar to cryptographic API 321 in secure router 103, cryptographic API 623 in secure server 111 provides a means for interfacing between a hardware cryptographic processor and SPEP software.

[0068] In the case of secure server 111, the SPEP software is a secure PEP server 631 running in a second secure container 629. SPEP server 631 communicates with a crypto API 623 through a Kubernetes container orchestration system 613. Those skilled in the art are familiar with software orchestration systems, so further details will not be provided here.

[0069] By using Kubernetes with additional security settings, a single secure server 111 can simultaneously manage multiple transmissions, with each transmission running in a separate container that hosts a separate instance of the SPEP server 631. As a result, each instance of the SPEP 631 is completely isolated from each other. Thus, multiple user devices 101 can be supported simultaneously using a single secure server 111.

[0070] The processing environment 603 also comprises a runtime environment 611 and a trusted operating system 607. Those skilled in the art are familiar with these functions, so further details will not be provided here.

[0071] Secure server 111 also comprises hardware, including one or more processors, memory, and a hardware security module (HSM) 617. HSM 617 is a hardware computing device that stores and manages digital keys, performs encryption and decryption functions, digital signature verification, authentication, and other cryptographic functions.

[0072] The HSM 617 may use one or more smart cards containing cryptographic information. In operation, the HSM 617 generates and stores cryptographic data. In some embodiments, the HSM 617 is a FIPS 140-2 Level 3 certified European TSM.

[0073] In an embodiment, the crypto API 623 is configured to be the only means by which the SPEP server 631 can communicate with the HSM 617, thereby providing a high degree of security to the cryptographic data.

[0074] By using an HSM 617 instead of a TPM as used in secure router 103, more processing power is available in crypto processor 617. This is advantageous because secure server 111 tends to serve multiple user devices 101 and therefore requires a PEP instance for each such device.

[0075] In some embodiments, the secure server 111 employs an AMD EPYC 7002 series generation CPU. The server may also include a TPM to provide secure boot capabilities.

[0076] In some embodiments, the secure server 111 employs the Kata-container runtime to provide isolation between containers, which, when combined with an AMD-SEV CPU, provides a private computing environment inside an encrypted virtual machine (VM) to the SPEP server 631 and crypto API 623.

[0077] In operation, when sending data to the destination server 113, the secure server 111 receives (119) data from the second ground station 109 over QUIC, typically formatted in UDP, as described above. The secure server 111 decrypts and reformats the received data using a shared encryption key derived in the manner described above, and sends (121) the data to the destination server 113. Typically, data sent to the destination server 113 is formatted in TCP. When sending data from the destination server 113 to the user device 101, the process is reversed. Thus, data in TCP format is received from the destination server 113, encrypted and reformatted to UDP, and sent over QUIC to the second ground station 109 in UDP.

[0078] Figure 7 shows the results obtained using the system described in the embodiment compared to a prior art system. The results in Figure 7 are obtained by transmitting data over a satellite link in the system shown in Figure 2.

[0079] The chart in Figure 7 shows an example of throughput achieved in megabits per second versus file transfer size. The solid line shows the average performance achieved using a system as described in the embodiments, and the gray area surrounding this average shows the performance achieved during different test runs. As can be seen, an average throughput of approximately 22 MB / s is achieved for all file sizes. The dashed line shows the average throughput for a corresponding system without encryption enabled. Again, the gray area around that line shows the performance achieved during different test runs. As is evident from the dashed line, the average performance without encryption is approximately 42 MB / s.

[0080] In comparison, the dashed line shows the performance of the same system when a prior art open source VPN is implemented. As can be seen, an average performance of approximately 6 MB / s is achieved. It is therefore clear from this figure that the performance achieved using a system as described in the embodiments provides a significant improvement over VPN and approximately half the throughput achieved with an unencrypted system.

[0081] Embodiments may include functionality embodied in a computer program product that, when loaded into an information processing system, can perform the described methods. Computer program means or computer program in this context means any expression, in any language, code, or notation, of a set of instructions intended to cause an information processing capable system to perform a specific function, either directly or after conversion to another language. Such a computer program may be stored on a computer-readable or machine-readable medium that allows data, instructions, messages, or message packets, and other machine-readable information to be read from the medium. The computer-readable or machine-readable medium may include non-volatile memory, such as ROM, flash memory, disk drive memory, CD-ROM, and other permanent storage devices. Additionally, the computer-readable or machine-readable medium may include volatile storage devices, such as RAM, buffers, cache memory, and network circuits. Additionally, the computer-readable or machine-readable medium may comprise computer-readable or machine-readable information in a transitory state medium, such as a network link and / or network interface, including a wired or wireless network, that enables a device to read such computer-readable or machine-readable information.

[0082] Words such as "comprise," "include," "incorporate," "contain," "is," and "have" should be construed in a non-exclusive manner when interpreting the description and its associated claims, i.e., as allowing for other items or components not expressly specified to also be present. References to the singular should also be construed as references to the plural, and vice versa.

[0083] While what are presently considered to be preferred embodiments of the present invention have been shown and described, it will be understood by those skilled in the art that various other modifications may be made and equivalents substituted without departing from the true scope of the invention. Additionally, many modifications may be made to adapt a particular situation to the teachings of the present invention without departing from the central inventive concept described herein. Moreover, an embodiment of the present invention may not include all of the features described above. Therefore, the invention is not limited to the particular embodiments disclosed, but is intended to include all embodiments that fall within the scope of the present invention as broadly defined above.

[0084] Those skilled in the art will readily appreciate that the various parameters disclosed in the description may be modified and that the various embodiments disclosed and / or claimed may be combined without departing from the scope of the present invention. [Explanation of symbols]

[0085] 101 User Devices 102 Router 103 Secure Router 105 First satellite ground station, first ground station 107 satellite 109 Second Ground Station 110 Server 111 Secure Server 113 Destination Server 303 Processing Environment 305 Secure Processing Environment, Secure Processing Part 307 Hardware-based cryptographic processor 309 Secure Performance Enhancement Proxy (SPEP) 311 Cryptographic Services 321 Cryptographic Application Programming Interface (API) 323 Software Interface, Cryptographic Operation Part 603 Processing Environment 607 Trusted Operating System 611 Runtime Environment 613 Kubernetes Container Orchestration System 617 Hardware Security Modules (HSMs), Cryptographic Processors 621 First Secure Container 623 Cryptographic API 629 Second Secure Container 631 Secure PEP Server

Claims

1. 1. A method of providing encrypted communications for transmission via satellite, comprising: A step (S401) of providing a transport layer session with a secure server (111) via a satellite; generating (S403) a cryptographic session public / private key pair using a secure hardware-based cryptographic processor (307); a step (S405) of transmitting a message including the public session key to the secure server (111) via the transport layer session; receiving (S407) a response from the secure server (111), the response comprising a public key; Calculating (S409) a shared key in the hardware-based cryptographic processor (307) using the received public key and the generated private key; encrypting payload data using the shared key (S411); a step (S413) of transmitting the encrypted payload data to the secure server (111); A method comprising:

2. 2. The method of claim 1, wherein the hardware cryptographic processor (307) is configured to communicate with the transport layer session through a software interface (323) operating within a secure processing environment (305).

3. 3. The method of claim 2, wherein the transport layer session operates outside the secure processing environment, and the software interface operating within the secure processing environment communicates with the transport layer session indirectly via a second software interface operating outside the secure processing environment.

4. 2. The method of claim 1, wherein the transport layer session is a QUIC session, the method further comprising receiving payload data to be transmitted in the form of a TCP connection; and transmitting the received payload data over an encrypted QUIC stream.

5. 5. The method of claim 1, wherein the generated public key / private key pair comprises a static key pair and an ephemeral key pair, and wherein sending (S405) the message comprises sending a message including the static public key and sending a message including the ephemeral public key.

6. 6. The method of claim 1, wherein said sending (S405) of a message including said public session key forms part of a TLS version 1.3 handshake procedure.

7. The method of claim 6 , wherein the public session key is transmitted in a first message of the handshake procedure.

8. 4. The method of claim 2 or 3, wherein the method is performed partly in software, and the integrity of the software is verified upon boot using information from the hardware-based cryptoprocessor.

9. 9. The method of claim 8, wherein the secure processing environment (305) in combination with the hardware-based cryptographic processor (307) executes all processes that use the cryptographic key.

10. The method of claim 9 , wherein the software is immutable.

11. A secure router device (103) configured to perform encrypted communications via a satellite, a hardware-based cryptographic processor (307); a processing environment (303); The secure router device (103) comprises: providing a transport layer session with a secure server (111) via a satellite; generating a cryptographic public-private key pair in said hardware-based cryptographic processor (307); Sending a message including the public key to the secure server (111) over the transport layer session; receiving a response from the secure server (111), the response comprising a public key; calculating a shared key using the received public key and the generated private key; encrypting payload data using the shared key; Sending the encrypted payload data to the secure server (111); A secure router device (103) configured to perform the above.

12. 12. The secure router (103) of claim 11, wherein the hardware cryptographic processor (307) comprises a Trusted Platform Module (TPM).

13. 13. The secure router (103) of claim 11 or 12, wherein the hardware cryptographic processor (307) is configured to communicate with the transport layer session via a software interface (323) operating within a secure processing environment (305) implemented using ARM TrustZone security extensions.

14. 11. A computer program product comprising computer readable instructions that, when executed on a system comprising a processor and a hardware cryptographic processor (307), performs all of the steps of the method of any one of claims 1 to 10.

15. 15. A computer readable medium comprising the computer program of claim 14.

Images