Method and key management system for establishing secure communications between a satellite control center and a satellite

A PKI-based key management system with semi-mutual authentication and self-signed certificates addresses the limitations of symmetric key cryptography in space systems, ensuring secure and efficient communication by eliminating pre-shared secrets and simplifying operations.

FR3150061A1Active Publication Date: 2024-12-20THALES SA
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
FR2023006094
Authority / Receiving Office
FR · FR
Patent Type
Applications
Current Assignee / Owner
Filing Date
2023-06-15
Publication Date
2024-12-20
Estimated Expiration
2043-06-15

AI Technical Summary

Technical Problem

Current space communication systems rely on symmetric secret key cryptography for securing edge-ground links, which requires cumbersome manual distribution chains and pre-shared secret keys, violating key management rules and posing security risks due to persistent confidentiality and operational constraints.

Method used

Implement a key management infrastructure based on public key cryptography (PKI) using digitally signed certificates and semi-mutual authentication, where satellites use self-signed certificates and physical parameters for authentication, eliminating the need for pre-shared secret keys and simplifying key management.

Benefits of technology

This approach ensures secure, efficient, and rule-compliant key management for space systems, reducing the risk of key compromise and operational complexity, while maintaining confidentiality and authenticity of messages.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 00000000_0000_ABST
    Figure 00000000_0000_ABST
Patent Text Reader

Abstract

The present invention provides a key management method for establishing secure communications between a ground control center and an orbiting satellite. When the satellite is on the ground, the method enables the operation of an asymmetric cryptography protocol with a certificate authority. This allows for the deployment, on cryptographic equipment at the ground control center, of a ground private key and a certificate signed by the certificate authority, containing a ground public key; and on cryptographic equipment on the satellite on the ground, of a certificate self-signed by the certificate authority, containing a certificate authority public key. When the satellite is in orbit, the method enables the operation of a semi-mutual authentication protocol between the ground control center and the satellite, authenticating the satellite by one or more physical characteristics that identify it. Figure 3 (for the abstract)
Need to check novelty before this filing date? Find Prior Art

Description

Title of the invention: Method and key management system for establishing secure communications between a satellite control center and a satellite technical field

[0001] The present invention relates to the space domain of communications between a satellite control center located on Earth and satellites in orbit. The invention is more specifically concerned with the security of such communications. State of the art

[0002] In the general field of communications, it is recognized that the security of communications between two parties is based on three fundamental factors: the availability of a communication channel, the confidentiality of the messages exchanged, and the authenticity of the messages exchanged (authentication of the source of the messages and integrity of the messages).

[0003] There are two common approaches to securing communications between two parties A and B, generally referred to as Alice and Bob: public / private key cryptography or asymmetric cryptography, and symmetric secret key cryptography.

[0004] In the specific field of space communications, security principles must be respected. For any communication link between a satellite control center (CCS) located on Earth (also referred to as the ground control segment) and a satellite in orbit, the availability of the transmission channel, the confidentiality and the authenticity of the messages exchanged must be guaranteed.

[0005] The present invention is specifically concerned with the authenticity and confidentiality of messages exchanged between a ground control segment and a satellite.

[0006] To date, space systems base the security of their ship-to-ground communication on based on symmetric secret-key cryptography.

[0007] As is known, during secure internet exchanges, denoted https: / / , symmetric secret-key cryptography allows two parties, generally referred to as Alice and Bob, to secure their communication. The secret key is negotiated from public elements exchanged between Alice and Bob and private elements that are unique to them and known only to them. These public / private elements are generated in real time and are therefore "ephemeral." The authentication of Alice and Bob relies on the implementation of certificates, signed by a trusted third-party authority, which contain their respective public keys. These public certificates are issued by a trusted Certificate Authority (CA) that guarantees the validity and authenticity of the certificates. This infrastructure is called a Public Key Infrastructure (PKI) according to The established English term allows for the creation of shared secret keys on demand and at the time required by Alice and Bob. However, this type of infrastructure does not exempt Alice and Bob from maintaining a persistent secret, which is their respective private key.

[0008] For communications of current space systems, symmetric secret-key cryptography is also used to secure exchanges between the ground control segment and the satellite, except that the establishment of the secret key does not rely on a PKI and requires that the ground control segment and the satellite have pre-shared secret keys known only to each other.

[0009] An infrastructure for the management of secret keys, with the acronym (SKI) for "Secret Key Infrastructure" according to the established anglicism, is shown schematically in [Fig.1].

[0010] The illustrated example of infrastructure 100 allows for the production on the ground and distribution in ground encryption / decryption equipment 102 and in a satellite 104 before its launch into orbit, of secret encryption keys for the exchange of telemetry data TM and remote control data TC.

[0011] The infrastructure allows the distribution of secret keys, from key generation equipment (random number generators) 106 and key management equipment 108, to ground cryptographic equipment 102 and to the satellite 104 before it is put into orbit, and this via different media (CD-ROM, USB key, Smart-Card, key injectors, ...).

[0012] This infrastructure requires the implementation of a complex, manually operated distribution chain on the ground, relying on both organizational measures and accredited personnel, such as the Information Systems Security Officer (ISSO). It necessitates the implementation of stringent security measures: personnel authorization, certification of key production and distribution equipment, etc.

[0013] Moreover, such an infrastructure does not allow for compliance with all the rules and best practices in terms of secret key management. Thus, for example, the principle that "a secret key must be created at the time the system needs it so that it is only exposed for the time necessary during its use" is not respected in the case of space systems, because secret keys are generated at the very beginning of a mission while the satellite is on the ground, and are generated once for the entire lifetime of the satellite in orbit (i.e., between 10 and 20 years).

[0014] Another rule that is rarely or never respected by this type of infrastructure relates to the fact that "the security of a secret key must not depend on the security of other secret keys used previously during encryption or decryption operations." This relates to the concept of Prefect Forward Secrecy, or PFS.

[0015] Finally, this type of infrastructure remains limited to systems with few satellites to operate and little equipment deployed on the ground.

[0016] This type of infrastructure (SKI) also imposes significant operational constraints to guarantee the confidentiality of the keys for the entire lifespan of the system, including constraints to ensure the confidentiality and integrity of the keys loaded into the satellite during the entire pre-launch phase at the launch site. Indeed, the requirement for an initial secret (a symmetric secret key or even a private key) remains strong for space systems, especially at the satellite level when it is located either at an industrial site, during transport, or at a launch site.

[0017] Thus, faced with these limitations and disadvantages, there is a need for an encryption key management solution which allows, in a simple way, space solution operators who have to manage one or a plurality of satellites, to secure on-board-ground links between one or more satellites and their ground control segment.

[0018] The present invention meets this need. Summary of the invention

[0019] One object of the present invention is to solve the problem of distributing secret keys for the encryption / decryption of remote control and telemetry data exchanged between a ground control segment and an orbiting satellite. Indeed, the initial establishment of secret keys raises the problem of the initial authentication of the ground control segment with respect to the satellite, and the initial authentication of the satellite with respect to the ground control segment.

[0020] Advantageously, the method of the invention makes it possible to do without the presence of an initial secret in the satellite during the entire preparation phase of the latter up to the launch.

[0021] Advantageously, the present invention makes it possible to do away, for a satellite, with the need to carry an initial secret (a symmetric secret key or a private key) before it is put into orbit, and is based on a secret key negotiation protocol with semi-mutual authentication.

[0022] The proposed solution is based on a key management infrastructure based on the implementation of digitally signed (PKI) public (non-secret) certificates, the use of public / private key cryptography (i.e. asymmetric cryptography) for the signing of certificates and for the negotiation of secret keys, and on an authentication of an orbiting satellite which relies solely on unique physical parameters of the latter, such as its orbital position.

[0023] The key management infrastructure of the invention is based on the principles of a PKI-type infrastructure, but where, in contrast and contrary to expectations according to the infrastructure In classic PKI structures, the satellite in question carries with it only a self-signed certificate from a certification authority (CA) with a PAC public key, which is not confidential.

[0024] According to the PKI infrastructure of the present invention, ground cryptographic equipment (generally part of the control center) produces a "public key / private key" pair. The public key is transmitted to a CA so that it can be inserted into a certificate signed by PAC (i.e., with PAC's private key). At the end of this preparatory certificate setup phase, advantageously the satellite is devoid of sensitive information, as it only possesses PAC's public key.

[0025] Once the satellite is launched, the ground control center can send it its valid ground certificate. The satellite can verify the authenticity of this ground certificate by countersigning it with its PAC public key. The satellite's cryptographic function and the ground cryptographic equipment can then exchange public (non-sensitive) parameters, generated on the spot, which allow them to produce a shared secret key.

[0026] The authentication of messages sent by the ground control center is then carried out via the ground signature with the private key and the counter-signature (i.e. the authentication verification) on board with the ground public key (the one that was present in the certificate sent by the ground).

[0027] Advantageously, the authentication of the satellite by the control center does not involve a cryptographic mechanism, but physical parameters that identify the satellite without any doubt.

[0028] In one of the possible embodiments, the authentication of the satellite is based on the ephemerides of the operated satellite, and on the fact that a control center knows them at all times, the latter being unique and specific to each object in orbit around the Earth.

[0029] Other methods of satellite authentication can be considered such as, for example, identification by RF fingerprint analysis of the TM message modulator or of a beacon.

[0030] Advantageously, the method of the invention allows for key management that does not require the initial secret to be placed in a ground-based satellite before it is placed in orbit. Thus, the method of the invention allows for a drastic simplification of key management operations throughout the entire lifespan of a space system.

[0031] The invention applies to space systems for which an end user requires secure air-to-ground communication links. This is the case for all current space systems, whether civilian or military.

[0032] Advantageously, the implementation of the invention avoids requiring an end user to take on the complex management of a ground-based secret key infrastructure. (SKI). This management remains the responsibility of the manufacturer who will deliver to the end customer the elements enabling them to easily secure the edge-to-ground links of their system: certificates from the certification authority, certificates from ground cryptographic equipment and cryptographic functions for signing and negotiating secret keys.

[0033] The space systems targeted are essentially geostationary telecommunications satellites for civil or commercial satellite operators. However, the method can be extended to other space systems (low Earth orbit constellations) provided that the system's operations are not unduly affected.

[0034] The invention makes it possible to comply with the basic rules concerning the management of secret keys, i.e., the use of "fresh" keys and the guarantee of persistent confidentiality in the event of the compromise of a previous key. It thus makes it possible to reduce the risk of compromise of the secret keys used throughout the lifetime of the space system.

[0035] To obtain the desired results, a key management method is proposed for establishing secure communications between a ground control center and an orbiting satellite, the method comprising steps consisting of:

[0036] - in a phase where the satellite is on the ground, to operate an asys cryptography protocol metric with a certificate authority, enabling deployment:

[0037] - on cryptographic equipment in the ground control center, a ground private key and a certificate signed by the certification authority, containing a ground public key; and

[0038] - on cryptographic equipment on the ground satellite, a self-signed certificate by the certification authority, containing a public key of the certification authority;

[0039] - in a phase where the satellite is in orbit, to operate an authentication protocol semi-mutual, between the ground control center and the orbiting satellite, consisting of:

[0040] - for the cryptographic equipment of the ground control center: to authenticate the satellite by one or more physical characteristics identifying the satellite; to send to said authenticated satellite a message signed with the private key sol, said message containing the certificate self-signed by the certification authority and the public key sol; and

[0041] - for the cryptographic equipment of the satellite in orbit: to authenticate the certificate received from the cryptographic equipment of the ground control center, using the public key AC of the certification authority.

[0042] During the establishment or exchange of a secret key between the satellite and the ground control center, messages sent by the ground control center are signed with the ground control center's private key and countersigned by the satellite with the ground control center's public key. The orbiting satellite, the source of the messages sent to the ground control center, is authenticated by one of its physical characteristics. which implicitly authenticates the messages sent by the satellite to the ground control center.

[0043] The invention offers several separate or combined embodiments.

[0044] Thus, the step of operating an asymmetric cryptography protocol with a certification authority includes:

[0045] - a step where the certification authority produces a public / private CA key pair (AC public key, AC private key);

[0046] - a step where the certification authority constitutes a self-signed certificate with said private key AC, and containing said public key AC; and

[0047] - a step where said self-signed certificate is transmitted on the one hand to the cryptographic equipment ground-based totographic and, on the other hand, to the cryptographic equipment of the ground-based satellite.

[0048] The method further comprises:

[0049] - a step where the cryptographic ground equipment: produces a ground key pair public / private (public key, private key); and transmits said public key to the certification authority;

[0050] - a step where the certification authority: integrates the received ground public key into a certificate; signs it with said private key AC; and transmits the signed certificate to the ground cryptographic equipment.

[0051] In one embodiment, the certification authority is capable of performing key registration functions.

[0052] In an embodiment, the step of authenticating the satellite by one or more physical characteristics consists of authenticating said satellite by its ephemerides, by authenticating parameters related to its orbital position, in particular the azimuth and the elevation.

[0053] In one variant, the step of authenticating the satellite by one or more physical characteristics consists of authenticating said satellite by characteristics of a modulated signal emitted by a telemetry transmitter or by a beacon of the targeted satellite.

[0054] In another variant, the step of authenticating the satellite by one or more physical characteristics consists of authenticating said satellite by a Doppler of a down-modulated signal.

[0055] In another variant, the step of authenticating the satellite by one or more physical characteristics consists of authenticating said satellite by a thermal signature of the satellite.

[0056] The method further includes, after semi-mutual authentication between the ground control center and the orbiting satellite, steps consisting of the establishment or exchange of secret keys between the ground control center and the authenticated satellite.

[0057] The invention also covers a key management device for establishing secure communications between a ground control center and an orbiting satellite, the device comprising means for implementing the steps of the process of the invention.

[0058] The invention also addresses a computer program comprising code instructions which, when the program is executed by a computer, lead the latter to implement the process of the invention. Brief description of the drawings

[0059] Other features and advantages of the present invention will become more apparent upon reading the following description in relation to the following drawings:

[0060] Fig. 1 illustrates a known secret key management infrastructure (SKI) for space system communications;

[0061] Fig. 2 illustrates a known public key infrastructure (PKI) for internet communications;

[0062] Figure 3 illustrates a public key infrastructure (PKI) for communications of space systems, according to one embodiment of the invention;

[0063] Figure 4 schematically illustrates the general principle of an authentication process according to one embodiment of the invention;

[0064] Figure 5 schematically illustrates the establishment or exchange of secret keys between an orbiting satellite and ground equipment, according to one embodiment of the invention. Detailed description of the invention

[0065] First, some reminders are made about various general and known principles of cryptography.

[0066] In information systems, communication security is ensured through cryptographic algorithms. A cryptographic algorithm transforms initial data into final data that can serve different purposes. Cryptography guarantees the confidentiality and authenticity of messages. A cryptographic algorithm is defined as any secure function that ensures that, through any type of computer attack (cryptanalysis, prediction, computing power, etc.), it is not possible to circumvent the security mechanisms in place.

[0067] Symmetric secret-key cryptography:

[0068] To ensure the confidentiality of the messages they will exchange, Alice and Bob must have the following items:

[0069] - a cryptographic message encryption primitive for Alice called EK;

[0070] - a cryptographic message decryption primitive for Bob called DK

[0071] - a symmetric secret key K known only to Alice and Bob.

[0072] Alice uses the secret key K and the primitive EK to encrypt her initial plaintext message. The encrypted message can be transmitted to Bob and will not be understandable to anyone person who does not possess the secret key K that would allow the message to be decrypted.

[0073] Bob, when he receives the encrypted message sent by Alice, can decrypt it using the primitive DK and the secret key K to extract the plaintext message initially constructed by Alice.

[0074] The confidentiality of the messages exchanged between Alice and Bob is based on the fact that only Alice and Bob have a shared common secret key.

[0075] A first problem that arises is that of sharing the secret key between Alice and Bob. This need for a shared secret requires that Alice and Bob meet at least once to exchange the secret key, away from prying eyes. The issue of distributing / exchanging secret keys remains a major problem in communication security. However, meeting allows Alice and Bob to authenticate each other during the initial exchange of the secret key. This at least resolves the initial authentication phase.

[0076] The cryptography used here is called symmetric secret-key cryptography or, incorrectly, "symmetric cryptography".

[0077] To ensure the authenticity of the messages, Alice and Bob must have the following elements:

[0078] - a one-way hash function for Alice and for Bob;

[0079] - a message encryption primitive for Alice called EK;

[0080] - a message decryption primitive for Bob called DK;

[0081] - a symmetric secret key K known only to Alice and Bob.

[0082] Alice uses a one-way hash function that produces a summary of her Alice then uses the secret key K to encrypt the digest of the initial plaintext message using the primitive EK. She can then send both the plaintext and the ciphertext to Bob.

[0083] Bob uses the same hash function as Alice to calculate the digest of the received plaintext message. Then, he uses the same secret key K and the primitive DK to decrypt the digest of the original message. Bob thus obtains two message digests that he can compare.

[0084] If the two message summaries obtained by Bob are strictly identical, then Bob will have two certainties:

[0085] - the message he just received is intact (thanks to the hash function),

[0086] - the message he just received does indeed come from Alice (thanks to the operation of encryption / decryption with the secret key K known only to Alice and Bob).

[0087] Alice and Bob now have secure means of exchanging messages while guaranteeing the authenticity and confidentiality of the messages. They must nevertheless meet to agree or exchange a secret key common which is a mandatory prerequisite.

[0088] Public / private key cryptography:

[0089] Public / private key cryptography is based on the principle that both parties Alice and Bob will have to use different keys for encryption and decryption operations.

[0090] It is assumed that Bob has at his disposal two complementary keys:

[0091] - a so-called "public" key which by definition is not sensitive, and which Bob can send to Alice via a non-confidential channel (i.e., a clear channel);

[0092] - a so-called "private" key which is sensitive and which must absolutely remain known that This key belongs to him alone. It must never be shared, not even with Alice. It is Bob's personal key.

[0093] To ensure the confidentiality of the exchanges, Alice encrypts her message with the public key that Bob previously provided to her. The encrypted message can then be sent to Bob, who can decrypt it with his private key (which is the only coherent key to his public key, the one used by Alice for encryption). A third party, "Eve," could attempt to decrypt the encrypted message with Bob's public key (which she would have intercepted), but she would obtain an unintelligible message since she did not use the private key (known only to Bob), which is the only key that allows the recovery of the original plaintext message.

[0094] The advantage provided by asymmetric cryptography is that Bob was able to transmit his public key to Alice via a non-confidential channel. However, the initial authentication phase, which would guarantee to Alice that the key sent by Bob was indeed Bob's, was not resolved.

[0095] Asymmetric cryptography can be used to add message authenticity. Alice must possess her own public / private key pair, also called a key pair. She previously gave her public key to Bob and kept her own private key secret.

[0096] Alice encrypts the message she wants to send to Bob using Bob's public key. But this time, she also calculates a digest of the original plaintext message using a one-way hash function, and then encrypts this digest with her own private key known only to her.

[0097] Alice then sends to Bob:

[0098] - the encrypted summary of the initial plaintext message (encrypted with Alice's private key);

[0099] - the message encrypted with Bob's public key.

[0100] Bob can then perform the following operations:

[0101] - decrypt, using Alice's public key, the encrypted digest of the initial plaintext message that he received;

[0102] - decrypt, using its private key, the received encrypted message to obtain the message deciphered (which is a priori identical to Alice's initial clear message);

[0103] - calculate, using the same one-way hash function as that used by Alice, the summary of the deciphered message.

[0104] If the two message summaries obtained by Bob are strictly identical, then Bob will have two certainties:

[0105] - the message he just received is intact,

[0106] - the message he just received is indeed from Alice.

[0107] Thus, the authenticity of messages obtained through asymmetric cryptography goes somewhat further than that obtained through symmetric cryptography. Since Alice has a private key different from Bob's, the integrity of the messages sent by Alice is linked to her private key. This creates specific integrity patterns which, in this particular case, are called "digital signatures".

[0108] Unlike the authenticity mechanism of symmetric cryptography, which produces a cryptographic integrity pattern attached to the secret key shared by Alice and Bob, the authenticity process of asymmetric cryptography is attached to only one of the two private keys, which justifies speaking of a "digital signature" rather than a cryptographic integrity pattern.

[0109] If Bob retains the encrypted message and, more importantly, the encrypted message digest using Alice's private key, this serves as proof for him that the message was indeed sent by Alice. Since Alice is the only one who possesses his private key, she is the only one who can produce a signature that can be cross-checked with the public key Bob possesses. This is known as the non-repudiation mechanism, which is enabled by asymmetric cryptography but not by symmetric secret-key cryptography.

[0110] Thanks to asymmetric cryptography, Alice and Bob thus have a means of instantiating the concept of a digital signature. However, this scheme remains flawed by the following weakness: how can Alice guarantee to Bob that the public key she sends him is indeed her public key, and vice versa? To verify this, Alice and Bob could meet physically to exchange their public keys. However, this offers no more than what symmetric secret-key cryptography provides. It then remains to solve, using asymmetric cryptography, the problem of initial authentication that guarantees to Alice that she is indeed communicating with Bob, and vice versa.

[0111] In the field of information systems security, this initial authentication problem for the initial exchange of public keys is summarized by a well-known attack called a "Man-in-the-Middle" attack. This attack consists of a third party, designated "Eve," interposing themselves between Alice and Bob at the communication channel and impersonating Alice and Bob.

[0112] When Alice sends her public key to Bob, Eve retrieves it and sends Bob her own public key; Bob believes he is receiving Alice's public key when he is actually receiving Eve's. Then, when Bob sends his public key to Alice, Eve retrieves it and sends Alice her own public key; Alice believes she is receiving Bob's public key when she is actually receiving Eve's.

[0113] This attack is possible because Alice and Bob do not yet have a reliable way to perform the initial authentication phase. This phase is crucial in any communication.

[0114] Subsequently, each time Alice encrypts a message, she will unknowingly use Eve's public key, which Eve will be able to easily decrypt with her private key. Eve will then be able to modify and "re-encrypt" the new message using Bob's public key, before sending it to Bob, who will decrypt it with his own private key, thinking that Alice encrypted it with Bob's public key.

[0115] For the signature, Alice will "digitally sign" her message with her private key. But Eve will replace Alice's signature with her own (created with her own private key). When Bob receives the signed message, he will countersign it with Eve's public key, thinking he is using Alice's. Eve will also be able to intercept messages sent in the other direction (those sent by Bob to Alice) to impersonate Bob in Alice's eyes.

[0116] This attack, feared by information systems security specialists, is unstoppable as long as Alice and Bob do not have a secure way to perform the initial authentication which would then allow them to thwart a man-in-the-middle attack.

[0117] To escape the threat of a man-in-the-middle attack, one solution is for Alice and Bob to rely on a public key infrastructure (PKI).

[0118] A PKI is based on the digital signature mechanisms enabled by asymmetric cryptography and on the implementation of certificates digitally signed by a third party entity (external to Alice, Bob and Eve) called a "trusted" entity or third party.

[0119] Figure 2 illustrates in a simplified manner the operational mechanism of an infrastructure PKI structure for an example where Alice (A) wants to develop a business by offering an online sales service. To do this, she must deploy a 202 server that must provide guarantees of authenticity (in the sense of source authenticity) to all her future online customers, in this example Bob (B). When a customer connects to Alice's server, they must be certain that they are indeed connecting to Alice's server and not to a fraudulent server that might have been set up by Eve (E) to steal sensitive information (for example, credit card numbers).

[0120] To guarantee the authenticity of her server to her clients, Alice requests that her server produce a public / private key pair (a key pair). She then compiles a file to request a certificate that will authorize her to connect her server to the web. She sends her public key, along with all the information related to her business activity—her company's SIRET number, proof of legal deposit, and other official documents—to a Certificate Authority (CA).

[0121] The CA will propagate Alice's request to a Registration Authority (RA), which will contact Alice through another channel to verify that she is indeed the person (or business entity) she claims to be. Once this verification is complete, the RA authorizes the CA to generate the certificate containing Alice's public key and sign it with her private CA key, which is known only to her. Once Alice has received her certificate signed by the CA and containing her public key, she can connect her server to the internet.

[0122] Bob (B) can then connect to Alice's server with complete confidence. To ensure that when he connects to Alice's server, he is indeed connected to it and not to a fraudulent server, Bob knows that his internet browser, which was installed along with his operating system (OS), already contains a range of certificates from various certificate authorities, all recognized as trustworthy. Among others, he will find the self-signed 214 certificate from the CA that also signed Alice's certificate.

[0123] When Bob connects to Alice's server, Alice's server will send him a 216 message signed with Alice's private key and containing Alice's certificate (along with her public key) signed by the CA. Bob's computer will perform several checks to authenticate the message and the certificate it contains: it will countersign the received certificate with the CA's public key to verify that the certificate is genuinely Alice's and not a forged certificate from Eve; it will countersign the received message with Alice's public key to verify that it was indeed Alice's server (the only one with the private key) that sent the message containing the certificate.

[0124] Thus, at this point in the exchange:

[0125] - Bob, the client, is certain that he is connected to Alice's server;

[0126] - Alice's server doesn't know much about the connected client, but that's not serious in the sense that the server is ready to chat with already registered customers or even with new customers.

[0127] The next part of the exchange will allow Bob's computer to exchange or establish (depending on the asymmetric cryptography mechanism chosen, but not detailed here) a symmetric secret key 218 with Alice's server. Once both Bob's computer and Alice's server possess the symmetric secret key, they will be able to exchange This data will be encrypted and authenticated using symmetric cryptography. At that point, Bob can confidentially enter his 220 credentials – his login and password – to authenticate himself to the server as a registered customer and access his personal account.

[0128] In this configuration:

[0129] - Bob is certain he is connected to Alice's server;

[0130] - Alice's server is certain to be connected to Bob's computer;

[0131] - Alice's server and Bob's computer have a shared secret key which allows them to exchange confidential and authenticated information without Alice needing to physically meet Bob to share the secret key.

[0132] The initial mutual authentication was thus performed by:

[0133] - sending to Bob, of Alice's certificate signed by the AC at the very beginning of the communication nization;

[0134] - sending Bob's login credentials, once the secure channel is established with the shared secret key.

[0135] In summary, three steps are required to establish fully secure communication between a client (B) and a server (A) over the internet. The first step involves initial mutual authentication through the exchange of signed certificates countersigned using the public key of a recognized CA. These exchanges are themselves signed / countersigned with the public / private keys of A and B. The second step involves the exchange of the secret key with mutual authentication by signing / countersigning with the authenticated private / public keys of A and B. The third step involves secure communication with mutual authentication through symmetric encryption / decryption of message digests based on a one-way hash function.

[0136] It appears that all stages involve a mutual authentication mechanism. Source authentication is therefore paramount and must be guaranteed from the very first contact (i.e., initial mutual authentication) to the last exchange in any secure communication. During exchanges, which are all secured with the shared symmetric secret key, message authenticity (source authentication and integrity) is ensured by symmetric secret key cryptography coupled with a one-way hash function that takes over until the end of the communication.

[0137] This example shows that a PKI infrastructure is not inherently much simpler than an SKI infrastructure. However, for the end user, a PKI is much simpler to manage. In the example of Bob's computer connecting to Alice's server, Bob simply has to manage his login and password correctly. The rest of the process is handled, without his knowledge, by the certificate infrastructure deployed in upstream in Alice's server and in Bob's computer's internet browser. Every time Bob connects to a server on the internet, he unknowingly triggers cryptographic mechanisms of rare complexity whose sole purpose is to secure his connection and simplify his task.

[0138] The present invention, with application to the space field, aims to enable space solution operators to manage, in a simple way, the securing of the edge-to-ground links between their ground control segment and their satellite(s).

[0139] In general, the device of the invention is based on a public key management infrastructure, e.g. of the PKI type, with a digitally signed certificate intermediary.

[0140] Fig. 3 is a schematic illustration of a public key management infrastructure 300 for communications of space systems, according to an embodiment of the invention, which allows a control ground segment 302 and a satellite 304 to be "keyed together".

[0141] The expression "to put to key" refers to the act of achieving a situation where the two parties involved in a communication share the same symmetric secret key which will allow them to ensure the security of their communications.

[0142] The space system is said to be "closed" and "private" in the sense that the recipients (the ground control segment and the satellite) of the certificates containing the public keys are identified in advance and do not change over time. The space system in question is "static" and does not evolve over time, unlike an open system such as the internet.

[0143] In the example, for the sake of simplifying the illustration, a key registration authority is confused with a 306 certification authority, the functions of the key registration authority being taken over by the certification authority (i.e. on a device implementing the functions of a certification authority).

[0144] The implementation of the public key management infrastructure according to the invention makes it possible to deploy certificates in the ground cryptographic equipment 302 and in the ground satellite 304, advantageously without any of the deployed elements being confidential.

[0145] The process implemented to deploy the certificates consists of a succession of the following steps:

[0146] - a step where the AC 306 produces its own public / private key pair (key public key AC / private key AC);

[0147] - a step where the 306 AC constitutes a 308 certificate containing its public key, self-signed certificate with its private key which is known only to it;

[0148] - a step where the self-signed certificate 308 of AC 306 is transmitted on the one hand to the ground cryptographic equipment 302 and on the other hand to the cryptographic function present in the ground satellite 304;

[0149] - a stage where the sol 302 cryptographic equipment produces its own pair of public / private keys (public key / private key);

[0150] - a step where the ground public key of the ground cryptographic equipment is transmitted to the CA which integrates it into a certificate which is signed with the CA's private key;

[0151] - a step where the signed 310 certificate containing the public key of the encrypted equipment Ground-based cryptographic data is transmitted via the AC to the ground-based cryptographic equipment.

[0152] A person skilled in the art understands that the implementation of each step can be carried out by known techniques such as those described above for a PKI type infrastructure.

[0153] This preliminary phase of PKI infrastructure deployment, which takes place before the satellite launch, allows the ground cryptographic equipment to have (a) its own ground private key which must remain confidential, and (b) its certificate which contains its ground public key and which is signed by PAC.

[0154] This preliminary phase of PKI infrastructure deployment, which takes place before the satellite launch, also ensures that the satellite cryptographic equipment has the CA's self-signed certificate containing the CA's public key. This will allow it to countersign (i.e., authenticate) messages received from the ground segment (those signed with the ground private key).

[0155] Thus, in this preliminary phase, the only two sensitive elements that must remain confidential are the AC private key of the certification authority (which is located at the PAC level), and the ground private key of the ground equipment (which is located at the ground equipment level).

[0156] Advantageously, none of the sensitive elements are, at any time, transported from one piece of equipment to another. This minimizes the risks of compromise associated with the handling of sensitive and confidential elements.

[0157] The satellite therefore did not carry, before launch, a sensitive secret element that would require confidentiality to be guaranteed throughout the ground launch preparation sequence.

[0158] The initial deployment of certificates in the satellite and at the level of the ground control segment according to the described process ensures that a third party (i.e. Eve) will never be able to impersonate the control center and therefore take control of the satellite.

[0159] Once the PKI infrastructure is fully deployed, the satellite is devoid of sensitive elements. Therefore, the satellite did not carry any initial secrets before being placed in orbit.

[0160] After the preliminary phase, the satellite is placed in orbit. Another object of the invention relates to the authentication between a ground control segment and a satellite in orbit whose respective certificates were initially deployed according to the method of the invention described for the preliminary phase.

[0161] Figure 4 schematically illustrates the general principle of the authentication process according to one embodiment of the invention. The inventors refer to the principle by the acronym KARMAH, for "Key Negotiation Protocol with Semi-Mutual Authentication".

[0162] A 402 control ground segment which has (a) a ground private key and (b) its certificate signed by a certification authority and which contains its ground public key (by setting up in a preliminary phase of the PKI infrastructure according to the invention), wishes to authenticate a 404 satellite in orbit, which has a self-signed certificate from the same certification authority and which contains the public key AC of the certification authority (again by setting up in a preliminary phase of the PKI infrastructure according to the invention).

[0163] Advantageously, instead of using an initial secret to authenticate the satellite as in prior art solutions, the ground control segment relies on non-confidential public parameters related to the satellite itself.

[0164] Different types of public parameters can be taken into account by the control ground segment. Examples include:

[0165] - satellite ephemerides, that is to say parameters related to its orbital position, such as azimuth and elevation in the case of a geostationary satellite, and as illustrated in [Fig.4];

[0166] - characteristics of a modulated signal emitted by a telemetry transmitter or by a beacon of the targeted satellite. These modulation characteristics are designated by the term (RFF) for "Radio Frequency Fingerprint" in English or RF fingerprint;

[0167] - a Doppler of a down-modulated signal, in the case of orbiting satellites (in low Earth orbit or (LEO) for "Low Earth Orbit" in English);

[0168] - a thermal signature of the satellite (provided that the ground station has a infrared detector accurate enough to perform this type of measurement).

[0169] The physical parameters allow the control ground segment 402 to authenticate with certainty the satellite 404 with which it wishes to establish a secure communication.

[0170] Indeed, with regard to ephemerides, national and international organizations, such as space agencies or the North American Aerospace Defense Command (NORAD), are responsible for mapping the sky with respect to orbiting objects. It is therefore impossible to position a satellite in orbit without it being cataloged and characterized from the point of view of its ephemerides.

[0171] The authentication according to the invention is said to be semi-mutual, in that on the communication channel, only the ground control segment authenticates itself by a cryptographic means vis-à-vis the satellite.

[0172] The control ground segment 402, after authenticating the satellite by one or more physical parameters, sends it a ground message (406) signed with its ground private key which contains its ground certificate signed by the CA, and its ground public key.

[0173] When the satellite receives the certificate sent by the ground control segment, it can authenticate it using the CA's public key, which it already possesses. This resolves the initial ground authentication by the satellite and allows the satellite to formally authenticate the source of the message containing the certificate.

[0174] Once satellite 404 has the public key of the ground segment, communication for exchanges or for the establishment of a secret key can begin.

[0175] Uplink messages are authenticated on board the satellite via signature with the ground private key and countersignature with the onboard public key.

[0176] For downlink messages, it is the orbital position of the satellite (or any other physical means linked to the satellite) that authenticates the source.

[0177] Figure 5 schematically illustrates the establishment or exchange of secret keys between a control ground segment 502 and a satellite 504, according to one embodiment of the invention.

[0178] During this phase of establishing or exchanging a secret key between the satellite and the ground control center, the messages sent by the ground control center are signed with the ground control center's private key and countersigned by the satellite with the ground control center's public key. The orbiting satellite, the source of the messages sent to the ground control center, is authenticated by one of its physical characteristics, which implicitly authenticates the messages sent by the satellite to the ground control center.

[0179] Advantageously, various key exchange protocols of the type Key Encapsulation Mechanism or (KEM) can be used to securely transmit a session key through an insecure channel.

[0180] More generally, all asymmetric signature, key exchange or key establishment mechanisms used can indifferently be based on pre-quantum asymmetric algorithms (RSA, DSA, Diffie-Hellman, elliptic curves, etc.) or on post-quantum asymmetric algorithms (CRYSTAL-KYBER, CRYSTAL DILITHIUM, FALCON, SPHINCS+, etc.).

[0181] In one embodiment, the key exchange mechanism consists of the following:

[0182] - Satellite 504 generates symmetric secret keys (which will then be used to secure the TM / TC edge-to-ground links);

[0183] - Satellite 504 encrypts the symmetric secret keys with the public key sol of the control ground segment 502;

[0184] - satellite 504 sends the encrypted secret keys to the control ground segment 502;

[0185] - Control Ground Segment 502 receives the encrypted secret keys and authenticates the origin of this key via the orbital position of satellite 504, the transmitter of the encrypted keys;

[0186] - the control ground segment 502 decrypts the secret keys with its private ground key;

[0187] - the control ground segment 502 and the satellite 504 share the same set of keys secret keys which then allow them to carry out TM / TC exchanges which are secured (confidentiality and authenticity of messages) thanks to the shared secret keys.

[0188] According to other embodiments, "Key Agreement" or "Key Negotiation" type key establishment protocols may be used.

[0189] Thus, in a particular embodiment:

[0190] - the satellite generates a pair of public and private elements (according to the protocols key establishment based on asymmetric Diffie-Hellman type mechanisms which are not detailed here);

[0191] - the control ground segment generates a pair of public and private elements;

[0192] - the satellite sends its public element to the ground control segment;

[0193] - the ground control segment sends its public element to the satellite;

[0194] - the control ground segment (ground) and the satellite (edge) apply a function 'F' identical on the elements they have (public and private) to arrive at the same common secret 'K'.

[0195] The 'F' function for the ground is of the type:

[0196] F[public element ground, public element edge, private element ground] = Shared secret key K ground-edge.

[0197] The 'F' function for the boundary is of type:

[0198] F[public element ground, public element edge, private element edge] = Shared secret key K ground-edge.

[0199] The ground control segment and the satellite then share the same secret key K which allows them to carry out TM / TC exchanges which are secured (confidentiality and authenticity of messages) thanks to the shared secret key.

[0200] Key establishment (or key negotiation) protocols base the generation of the secret key on the exchange of public ephemeral elements which are renewed each time a new secret key is to be established.

[0201] Key exchange protocols (or KEM key encapsulation protocols) require the use of the ground segment's private / public key pair to encrypt / decrypt the secret key exchanged between the edge and the ground. Since the ground segment key pair is persistent, it does not guarantee the independence of the secret keys whose Security depends on the private key present at the ground segment level. Therefore, key establishment protocols are preferred over key exchange protocols.

[0202] Thus, a method has been described in which the integrity of the certification authority's certificate is ensured by a keyless one-way hash function. When the CA produces its self-signed certificate, it passes it through a secure hash function to produce a reference digest. This reference digest allows verification at key points in the satellite's lifecycle (just before launch, just after orbital insertion, before the certificate is transmitted from the ground to the satellite, etc.) that the CA's certificate on board the satellite is still intact. On demand, the ground station calculates the certificate digest using the same keyless one-way hash function that was used by the CA to calculate the reference digest. The ground station can compare the digest calculated by the ground station to the reference digest to verify that the CA's certificate on board is indeed intact and uncorrupted.

Claims

Claims

1. Key management method for establishing secure communications between a ground control center (402) and a satellite in orbit (404), the method comprising steps consisting of: - in a phase where the satellite is on the ground, operating an asymmetric cryptography protocol with a certification authority (306), making it possible to deploy: - on cryptographic equipment (302) of the ground control center, a ground private key and a certificate (310) signed by the certification authority, containing a ground public key; and - on cryptographic equipment (304) of the satellite on the ground, a certificate (308) self-signed by the certification authority, containing a public key AC of the certification authority;- in a phase where the satellite is in orbit, to operate a semi-mutual authentication protocol, between the ground control center and the satellite in orbit, consisting of: - for the cryptographic equipment of the ground control center: to authenticate the satellite by one or more physical characteristics identifying the satellite; to send to said authenticated satellite, a message (406) signed with the ground private key, said message containing the certificate self-signed by the certification authority and the ground public key; and - for the cryptographic equipment of the satellite in orbit: to authenticate the certificate received from the cryptographic equipment of the ground control center, using the public key AC of the certification authority.;

2. Method according to claim 1 wherein the step of operating an asymmetric cryptography protocol with a certification authority (306), comprises: - a step where the certification authority produces a public / private AC key pair (public key AC, private key AC); - a step where the certification authority constitutes a self-signed certificate with said private key AC, and containing said public key AC; and - a step where said self-signed certificate (308) is transmitted on the one hand to the ground cryptographic equipment (302) and on the other hand to the cryptographic equipment (304) of the satellite on the ground.

3. Method according to claim 2 further comprising: - a step where the ground cryptographic equipment (302): produces a public / private sol key pair (sol public key, sol private key); and transmits said sol public key to the certification authority (306); - a step where the certification authority (306): integrates the received sol public key into a certificate; signs it with said private key AC; and transmits the signed certificate (310) to the sol cryptographic equipment.

4. A method according to any preceding claim wherein the certification authority is capable of performing key registration functions.

5. Method according to any one of the preceding claims in which the step of authenticating the satellite by one or more physical characteristics, consists of authenticating said satellite by its ephemerides, by authenticating parameters linked to its orbital position, in particular the azimuth and the elevation.

6. Method according to any one of the preceding claims in which the step of authenticating the satellite by one or more physical characteristics, consists of authenticating said satellite by characteristics of a modulated signal emitted by a telemetry transmitter or by a beacon of the targeted satellite.

7. A method according to any preceding claim wherein the step of authenticating the satellite by one or more physical characteristics, comprises authenticating said satellite by a Doppler of a downlink modulated signal.

8. A method according to any one of the preceding claims wherein the step of authenticating the satellite by one or more physical characteristics, consists of authenticating said satellite by a thermal signature of the satellite.

9. A method according to any preceding claim further comprising, after the semi-mutual authentication between the ground control center and the orbiting satellite, steps consisting of establishing or exchanging secret keys between the ground control center (502) and the authenticated satellite (504).

10. A computer program comprising code instructions for carrying out the steps of the method according to any one of the preceding claims, when said program is executed on a computer.

11. A key management device for establishing secure communications between a ground control center (402) and an orbiting satellite (404), the device comprising means for implementing the steps of method according to any one of the preceding method claims.