Method of Operating a Public Key Certificate Validation System for Facilitating a Secure Communication Between an Aircraft and a Ground Entity

The instant application claims priority under 35 U.S.C § 119 to European patent application 24 174 490.3 entitled METHOD OF OPERATING A PUBLIC KEY CERTIFICATE VALIDATION SYSTEM FOR FACILITATING A SECURE COMMUNICATION BETWEEN AN AIRCRAFT AND A GROUND ENTITY, filed May 7, 2024. Said patent application 24 174 490.3 is herein incorporated by reference in its entirety.

The present invention is in the field of aircraft communications. In particular, the present invention is in the field of establishing secure communication between aircraft and ground entities.

Aircraft operate in an environment that is heavily constrained in terms of communication resources. In particular, aircraft often times work in limited radiofrequency (RF) bandwidth environments. They often have to share a single frequency between many aircraft. Accordingly, RF transmission time is a very precious resource for aircraft.

It is further highly important for aircraft to establish secure communications with ground entities. Modern aircraft rely on encryption of messages with respective key pairs of public and private keys. The public key of every key pair is commonly associated with a public key certificate, which is an electronic document for proving the validity of a public key. The establishing of secure communication commonly requires an elaborate handshake protocol, leading to a large communication overhead, before the actual exchange of payload data is enabled. Given the limited RF resource, the handshakes may be a large burden on the RF resources. Also, with common handshakes often requiring the completion of the handshake to take place in a limited amount of time and with the RF resource being constrained, handshakes often fail due to time-out constraints.

Accordingly, it would be beneficial to provide a framework that reduces the risk of handshakes failing due to time-out constraints.

Exemplary embodiments of the invention include a method of operating a public key certificate validation system for facilitating a secure communication between an aircraft and a ground entity, the method comprising: sending a public key certificate of the ground entity from the ground entity to a trusted responder; at the trusted responder, validating the public key certificate of the ground entity and storing a trust indication regarding the public key certificate of the ground entity in a pre-cached validation database; and at the trusted responder, maintaining the pre-cached validation database for providing a validation response regarding the public key certificate of the ground entity, when a validation request, associated with the secure communication between the aircraft and the ground entity, reaches the trusted responder, wherein the validation response is based on the trust indication regarding the public key certificate of the ground entity from the pre-cached validation database.

Exemplary embodiments of the invention allow for a particularly low turn-around time in the validation of the public key certificate of the ground entity. In this way, exemplary embodiments of the invention may contribute to a low duration of the handshake between the aircraft and the ground entity and may, thus, contribute to a reduced risk of the handshake between the aircraft and the ground entity failing due to time-out constraints. With the trust indication regarding the public key certificate of the ground entity being readily available in the pre-cached validation database, the trusted responder may provide a very quick response to a validation request regarding the public key certificate of the ground entity. The need for carrying out the validation process of the public key certificate of the ground entity ad-hoc, i.e. right when the validation request reaches the trusted responder, may be eliminated. The validation process of the public key certificate of the ground entity, which may involve evaluating/validating multiple legs of a public key infrastructure (PKI) and which may, thus, be a time-consuming process, may be front-loaded. In particular, the validation process of the public key certificate of the ground entity may be made independent from a concrete validation request and may, thus, be de-coupled from the handshake between the aircraft and the ground entity. At the time of the handshake of the aircraft and the ground entity, the trust indication may be readily available in the pre-cached validation database.

As described herein, exemplary embodiments of the invention relate to methods for facilitating secure communication between aircraft and ground entities. The term secure communication relates to communication that is protected by cryptographic means. In particular, the secure communication may be implemented via the use of a cryptographic key pair for each of the aircraft and the ground entity. Further in particular, each of the aircraft and the ground entity may have a respective pair of a public key and a private key, with the outbound communication being encrypted with the public key of the respectively other entity and with the inbound communication being decrypted with the private key of the receiving entity. Each of the cryptographic key pairs may in particular be an RSA key pair, an ESDSA key pair or any other type of suitable key pair. A public key certificate of the aircraft is associated with the public key of the aircraft, and the public key certificate of the ground entity is associated with the public key of the ground entity. The cryptographic key pairs may be predefined/pre-generated key pairs or may be session key pairs. The term secure communication does not necessarily mean that the communication is 100% secure against attacks. Rather, the term secure communication relates to communication that is protected by the use of encryption keys, with the certificates associated with the encryption keys being subject to some form of authentication in the initial stages of the establishment of the communication between the aircraft and the ground entity.

There may be various reasons for the need to have a secure communication between the aircraft and the ground entity and to perform an authentication in the initial stages of the communication. The need may arise from the contents of the communication. For example, the aircraft and the ground entity may share safety-relevant data regarding the flight of the aircraft and/or the flight path of the aircraft. For such data, there is a very strong interest in maintaining communication integrity between the aircraft and the ground entity. The need may also arise from the fact that there is no or only a low level of prima facie trust between the aircraft and the ground entity, i.e. that there is no or only a low level of trust at the onset of the communication. For example, the aircraft may be from a different country than the location of the ground entity. In another example, the aircraft operator may be different from the operator of the ground entity. With different countries and different operators of aviation equipment belonging to different trust groups and/or to different trust levels, general aviation procedures may require a mutual authentication of the aircraft and the ground entity, in order to establish a trustworthiness of both entities that is considered sufficient, in particular sufficient for exchanging potentially safety-relevant communication between the aircraft and the ground entity.

For security reasons, certificates are often short-lived in the aviation field. For example, the public key certificates, as described herein, may be valid for some days only. Accordingly, the demand for validation of public key certificates is an ongoing demand in the aviation field.

The aircraft may have a key pair comprising a public key and a private key. The public key certificate of the aircraft is associated with the key pair of the aircraft. It can also be said that the public key certificate of the aircraft is associated with the public key of the aircraft. The aircraft may send its public key to the ground entity.

The ground entity may have a key pair, comprising a public key and a private key. The public key certificate of the ground entity is associated with the key pair of the ground entity. It can also be said that the public key certificate of the ground entity is associated with the public key of the ground entity. The ground entity may send its public key to the aircraft.

The key pairs may be predefined/pre-generated key pairs. It is also possible that session key pairs are generated in an algorithmic manner with the help of the public key certificates of the aircraft and the ground entity. The session key pairs may be generated/exchanged after the exchange/obtainment of the certificates of the aircraft and ground entity.

The public key certificate of the aircraft/ground entity may also be referred to as a digital certificate or as an identity certificate or simply as a certificate of the aircraft/ground entity herein. The public key certificate of the aircraft/ground entity may be a TLS/DTLS certificate, i.e. a certificate that is suitable for being used for authentication according to the TLS/DTLS standard.

The ground entity may be any ground entity that is part of an aviation communication network and that offers ground communication services to aircraft. The ground entity may, for example, be an airport or a communication outpost on an island or in a remote land portion or a ground communication link in a sparsely populated region/in a region with sparse aviation infrastructure.

The method comprises sending a public key certificate of the ground entity from the ground entity to a trusted responder and, at the trusted responder, validating the public key certificate of the ground entity. The trusted responder is an entity that is configured to navigate the public key infrastructure (PKI) and to determine a trustworthiness of a particular public key certificate and/or a trustworthiness of a path within the public key infrastructure between two certificates. In case the public key infrastructure is seen as a PKI tree, the trusted responder may evaluate the trustworthiness of a certain path between two leaves of said tree and/or the trustworthiness of a certain leaf, also referred to as certain node of the tree. For this purpose, the trusted responder may walk the PKI tree from the certificate in question up to a recognized certificate authority. It can also be said that the trusted responder may walk the legs of the PKI tree from the certificate in question up to a recognized certificate authority. This process of determining the trustworthiness of a particular public key certificate may be understood as validating the particular public key certificate. The validating of the public key certificate may include additional checks, such as checking whether the public key certificate is expired, revoked, etc. It is understood that the trusted responder may involve other entities for validating the public key certificate of the ground entity. As the trusted responder initiates the validation, controls the validation, and stores the result of the validation, the step of validating the public key certificate of the ground entity is considered to be carried out at the trusted responder, regardless of whether the trusted responder uses/interacts with other entities in the process.

The term trusted responder is commonly used in various protocols where certificates may be checked/validated in online procedures. An example of such a protocol is the Online Certificate Status Protocol (OCSP). The trusted responder is considered trusted, because one of the entities of the end-to-end communication trusts the trusted responder for making a reliable determination regarding the validity/authenticity of the certificate to be validated. As discussed above, different countries and/or different aviation operators may be in different trust groups and/or may not have an upfront trust for each other. Accordingly, an aircraft from a first trust group may want to communicate with a ground entity from a second trust group and may indicate a trusted responder within the first trust group to the ground entity for having the public key certificate of the ground entity validated.

The trusted responder may in particular be a responder that the aircraft trusts. In this way, the aircraft can gain a sufficient level of trust for the ground entity from the validation response, without having to carry out the validation process itself. In particular, because the validation response stems from an entity that the aircraft trusts, the aircraft can determine from the validation response whether the trustworthiness of the ground entity is high enough to start the secure communication. The aircraft may be brought into a position to take an informed/reasoned decision on whether to trust the ground entity or not, without having to carry out its own validation procedure over the scarce RF resource. With the validation of the public key certificate of the ground entity being front-loaded and being offloaded to ground entities, which do not operate in a constrained RF network, the validation regarding the public key certificate of the ground entity may be carried out in a predictable and quick manner. The risk of the handshake between the aircraft and the ground entity timing out, as has often been the case in previous approaches where the RF resource was involved, may be greatly reduced.

The method comprises storing a trust indication regarding the public key certificate of the ground entity in a pre-cached validation database. The trust indication may be the result of the validation process regarding the public key certificate of the ground entity, as laid out above, or may be information derived/deduced from the result of said validation process. The pre-cached validation database may be any database that is capable of storing such validation process results/such information derived from the validation process results in a searchable manner. In particular, the public key certificate of the ground entity or another unique identifier of the ground entity may be used for querying the pre-cached validation database, in order to retrieve the respective validation process result/the respective information derived from the respective validation process result. The pre-cached validation database is in particular configured to store the trust indications independent from concrete validation requests. In particular, the pre-cached validation database is a database entity that is populated in a preemptive manner. The database entries of the pre-cached validation database are maintained for later use. They may in particular be stored irrespective of whether and when they are potentially read out in response to a concrete validation request. The pre-cached validation database is a database of cached validation process results/of cached information derived from validation process results, wherein the cached nature of those trust indications allows for a quick access, if and when they are requested. The pre-cached validation database may be maintained at the site of the trusted responder/may be integrated with the trusted responder. The pre-cached validation database may also be a separate entity that is coupled to and accessible from the trusted responder. As the trusted responder has access to and control over the contents of the pre-cached validation database, the pre-cached validation database is considered to be maintained at the trusted responder, irrespective of the exact location and the particular nature of the data connection between the trusted responder and the pre-cached validation database.

The trust indication, as stored in the pre-cached validation database, may also be referred to as an indication regarding the trustworthiness of the public key certificate of the ground entity. Stated differently, the trust indication may be an indication regarding the level of trust that a communication partner, e.g. the aircraft, can have with respect to the ground entity. The indication regarding the trustworthiness of the public key certificate of the ground entity may be a simple trustworthy/not trustworthy indication. It may also contain some sort of score regarding the trustworthiness of the public key certificate of the ground entity. This score may, for example, depend on the level of confidence in the individual legs of the path of the public key infrastructure tree between the ground entity and a trusted certificate authority, as assessed by the trusted responder. In any case, the trust indication may contain information that enables the aircraft to make a well-informed/well-reasoned decision whether or not to trust the ground entity.

The method comprises, at the trusted responder, maintaining the pre-cached validation database for providing a validation response regarding the public key certificate of the ground entity, when a validation request, associated with the secure communication between the aircraft and the ground entity, reaches the trusted responder, wherein the validation response is based on the trust indication regarding the public key certificate of the ground entity from the pre-cached validation database. The validation request is a validation request regarding the public key certificate of the ground entity. In the course of establishing the secure communication between the aircraft and the ground entity, said validation request may be issued by the aircraft or by the ground entity. The trusted responder uses the pre-cached validation database for addressing the validation request. In particular, the trusted responder queries the pre-cached validation database for the pre-stored/cached trust indication regarding the public key certificate of the ground entity. Further in particular, when receiving the validation request, the trusted responder does not have to carry out the validation process regarding the public key certificate of the ground entity on the spot/ad-hoc, but can rely on the readily available pre-cached validation database.

The language of providing a validation response regarding the public key certificate of the ground entity, when a validation request, associated with the secure communication between the aircraft and the ground entity, reaches the trusted responder, does not imply a strict timing relationship between receiving the validation request and sending out the validation response. Rather, the expression may be understood as the trusted responder issuing the validation response pursuant to/in response to receiving a concrete validation request, associated with the secure communication between the aircraft and the ground entity. With the pre-cached validation database being readily available, the validation response can be sent out considerably more quickly after receiving the validation request, as compared to previous approaches, where the validation process was started after receiving the validation request.

The trusted responder maintains the pre-cached validation database, in order to react quickly to a concrete validation request, associated with the secure communication between the aircraft and the ground entity. It can be said that the trusted responder maintains the pre-cached validation database for being able to provide a validation response regarding the public key certificate of the ground entity, if and when a validation request, associated with the secure communication between the aircraft and the ground entity, reaches the trusted responder. In operation, the trusted responder may maintain the pre-cached validation database for an extended period of time and may provide the validation response in the course of a concrete handshake between the aircraft and the ground entity.

The validation response is a response to the validation request. The validation response may comprise the trust indication, as obtained from the pre-cached validation database, or may comprise information deduced/derived from the trust indication, as obtained from the pre-cached validation database. In any case, the validation response is based on the trust indication regarding the public key certificate of the ground entity from the pre-cached validation database.

As described herein, exemplary embodiments of the invention relate to a method of operating a public key certificate validation system. Said public key certificate validation system may comprise the ground entity and the trusted responder. The ground entity and the trusted responder may carry out various method steps, as described herein, irrespective of a particular instance of communication between the ground entity and an aircraft. The public key certificate validation system may operate in the described manner, in order to be ready for quickly facilitating a secure communication between the ground entity and an aircraft, when desired. It is understood that the public key certificate validation system may comprise a plurality of ground entities and a plurality of trusted responders. In this way, an aircraft may establish a secure communication with a plurality of ground entities and may choose from a plurality of trusted responders, selectively making use of the various pre-cached validation databases maintained at the plurality of trusted responders.

According to a further embodiment, the trusted responder is an OCSP trusted responder. In other words, the trusted responder may be a trusted responder in accordance with the Online Certificate Status Protocol (OCSP).

According to a further embodiment, the validation request is an OCSP validation request and the validation response is an OCSP validation response. In other words, the validation request and the validation response may be a validation request and a validation response in accordance with the Online Certificate Status Protocol (OCSP).

It has been found that the Online Certificate Status Protocol (OCSP) is a highly efficient protocol for establishing the trustworthiness of the ground entity and, potentially, for establishing the trustworthiness of the full public key infrastructure path between the aircraft and the ground entity. The trust indication, as stored in the pre-cached validation database, may be stored in a format that is readily usable for the Online Certificate Status Protocol (OCSP).

According to a further embodiment, said validating of the public key certificate of the ground entity comprises evaluating all legs of a public key infrastructure (PKI) path between the public key certificate of the ground entity and a trusted root node. The trusted root mode may for example be a trusted certificate authority. Each of the legs of the public key infrastructure path may be evaluated via leg-specific validation request and validation response messages. In particular, each of the legs of the public key infrastructure path may be evaluated via respective OCSP messages.

According to a further embodiment, the trust indication regarding the public key certificate of the ground entity, stored in the pre-cached validation database, is a trust indication regarding a public key infrastructure (PKI) path between the public key certificate of the ground entity and a trusted root node. The trusted root node may for example be a trusted certificate authority. In this way, the trust indication may be a piece of information that represents a compiled trustworthiness of the full PKI path between the public key certificate of the ground entity and a trusted root node. This piece of information may be readily used for the validation response, and the validation response may put the aircraft in a position to take well-reasoned decision regarding the trustworthiness of the public key certificate of the ground entity, taking into account the relevant parts of the underlying public key infrastructure.

According to a further embodiment, the secure communication between the aircraft and the ground entity is a TLS/DTLS-based secure communication. In other words, the secure communication between the aircraft and the ground entity may be carried out in accordance with the Transport Layer Security (TLS) protocol. As a specific implementation thereof, the secure communication between the aircraft and the ground entity may be carried out in accordance with the Datagram Transport Layer Security (DTLS) protocol. As used herein, the expression TLS/DTLS means TLS or DTLS. The secure communication may be carried out in accordance with any version of TLS, such as TLS 1.3, or in accordance with any version of DTLS, such as DTLS 1.3.

According to a further embodiment, the method further comprises re-sending the public key certificate of the ground entity from the ground entity to the trusted responder in predefined intervals; and, at the trusted responder, re-validating the public key certificate of the ground entity and storing an updated trust indication regarding the public key certificate of the ground entity in the pre-cached validation database. In this way, the validation of the public key certificate of the ground entity may be re-done in a proactive manner, and developments affecting the trustworthiness of the public key certificate of the ground entity may be detected in a timely manner. It may be prevented that a positive trust indication is “frozen” in the pre-cached validation database for an extended period of time, although the trustworthiness of the public key certificate of the ground entity may have gone down. The predefined intervals may be regular intervals/periodic intervals. It is possible that certain deviations from a regular/periodic schedule are accepted. This may help in accounting for data traffic constraints, in accounting for delays due to the ground entity being busy with other communication tasks, etc. In an exemplary embodiment, the ground entity may re-send its public key certificate to the trusted responder once per day. It is also possible that the ground entity re-sends its public key certificate to the trusted responder in randomized intervals. In case this randomized nature of the intervals is intended and programmed accordingly, the randomized intervals are considered a particular form of predefined intervals. The updated trust indication may be the same as the previous trust indication in terms of the result of the validation process or may be different. The pre-cached validation database may store a time stamp of the trust indication/of the updated trust indication or may have another suitable data field for logging the time sequence of trust indications.

According to a further embodiment, the method further comprises sending a new public key certificate of the ground entity from the ground entity to the trusted responder; and, at the trusted responder, validating the new public key certificate of the ground entity and storing an updated trust indication regarding the new public key certificate of the ground entity in the pre-cached validation database. In this way, the public key certificate validation system may react to the replacement of public key certificates in a proactive manner. In particular, the update/exchange of the public key certificate of the ground entity may be reflected in the pre-cached validation database in a timely manner. The pre-cached validation database may be kept up to date in a reliable manner. This may be particularly beneficial in the aviation field, where public key certificates are often short-lived certificates.

According to a further embodiment, the method comprises: sending the public key certificate of the ground entity from the ground entity to a plurality of trusted responders; at each of the plurality of trusted responders, validating the public key certificate of the ground entity and storing a respective trust indication regarding the public key certificate of the ground entity in a respective pre-cached validation database; and at each of the plurality of trusted responders, maintaining the respective pre-cached validation database for providing a validation response regarding the public key certificate of the ground entity, when a validation request, associated with the secure communication between the aircraft and the ground entity, reaches the respective trusted responder, wherein the validation response is based on the respective trust indication regarding the public key certificate of the ground entity from the respective pre-cached validation database. In this way, the public key certificate of the ground entity may be distributed among a wide set of trusted responders, and each of the trusted responders may be in a position to quickly react to a validation request regarding the public key certificate of the ground entity. An aircraft, relying on a particular trusted responder or on a particular set of trusted responders, may thus have a high chance of obtaining a quick validation response via the pre-cached validation database if the particular trusted responder(s).

According to a further embodiment, the method comprises: at the trusted responder, receiving, from each of a plurality of ground entities, a respective public key certificate; at the trusted responder, validating, for each of the plurality of ground entities, the respective public key certificate and storing a respective trust indication regarding the respective public key certificate of the respective ground entity in the pre-cached validation database; and, at the trusted responder, maintaining the pre-cached validation database for providing respective validation responses regarding the respective public key certificates of the plurality of ground entities, wherein the respective validation responses are based on the respective trust indications regarding the respective public key certificates of the plurality of ground entities from the pre-cached validation database. In this way, the trusted responder may be in a position to quickly react to validation requests regarding the public key certificates of many ground entities. An aircraft, wanting to enter into a secure communication with a particular ground entity out of a large number of ground entities, may therefore have a high chance of obtaining a quick validation response via the pre-cached validation database.

It is understood that the aspects of the two preceding paragraphs, namely the aspect of a particular trusted responder maintaining a pre-cached validation database with trust indications of many ground entities and the aspect of a particular ground entity sending its public key certificate to many trusted responders for a front-loaded validation, may be combined. An extended network of ground entities and trusted responders may be established. In this way, an aircraft, wanting to communicate with a particular ground entity and relying on one or a few particular trusted responders, may still have a high chance of obtaining a quick validation response via the pre-cached validation database of a particular trusted responder. Stated differently, the public key certificate validation system, as described herein, may comprise a plurality of ground entities and a plurality of trusted responders, and the method steps, as described for a single ground entity and a single trusted responder, may be applied to many or even all possible pairs of ground entity and trusted responder.

According to a further embodiment, the method comprises: at the trusted responder, receiving, from each of a plurality of aircraft, a respective aircraft public key certificate; at the trusted responder, validating, for each of the plurality of aircraft, the respective aircraft public key certificate and storing a respective aircraft trust indication regarding the respective aircraft public key certificate of the respective aircraft in the pre-cached validation database; and at the trusted responder, maintaining the pre-cached validation database for providing respective validation responses regarding the respective aircraft public key certificates of the plurality of aircraft, wherein the respective validation responses are based on the respective trust indications regarding the respective aircraft public key certificates of the plurality of aircraft from the pre-cached validation database. In this way, the infrastructure of the public key validation system, as described herein, may be extended to public key certificates of aircraft. In particular, the pre-cached validation database(s) of the trusted responder(s) may additionally be populated with trust indications regarding the public key certificates of a plurality of aircraft. Accordingly, when a particular ground entity enters into a secure communication with a particular aircraft and wishes to validate the public key certificate of the aircraft, the particular ground entity may also have a high chance of obtaining a quick validation response via a pre-cached validation database. This may further reduce the risk of the handshake failing due to time-out constraints.

In embodiments where trust indications regarding public key certificates of ground entities and trust indications regarding public key certificates of aircraft are stored in the pre-cached validation database, validation responses relating to both the public key certificate of the ground entity and the public key certificate of the aircraft may be provided in a quick manner on the basis of the data contained in the pre-cached validation database. In particular, pursuant to receiving a validation request that relates to both the public key certificate of the ground entity and the public key certificate of the aircraft, the trusted responder may retrieve the trust indication regarding the public key certificate of the ground entity and the trust indication regarding the public key certificate of the aircraft from the pre-cached validation database. On the basis of both of these trust indications, the trusted responder may provide a validation response that indicates a combined trustworthiness of two portions of the public key infrastructure tree, namely the public key infrastructure path from the public key certificate of the ground entity to a trusted root node and the public key infrastructure path from the public key certificate of the aircraft to a trusted root node. In this way, a single validation response may have sufficient information to put both the ground entity and the aircraft in a position to take a well-informed decision whether to enter into the secure communication or not.

According to a further embodiment, the validation request regarding the public key certificate of the ground entity is sent from the ground entity to the trusted responder in response to receiving a communication initialization message from the aircraft. In this way, implementations of the handshake between the aircraft and the ground entity with a particularly low usage of the RF resource may be achieved. As compared to previous approaches where it was the aircraft's task to validate the public key certificate of the ground entity out of its own motion, after receiving the public key certificate of the ground entity from the ground entity, the burden of validating the public key certificate of the ground entity may be offloaded to a validation process on the ground where the involved entities are not as constrained in terms of their communication resources. In previous approaches, the aircraft triggered some form of certificate validation process via a separate message over the constrained RF resource and received some form of response, also over the constrained RF resource. With the ground entity issuing the validation request to the trusted responder, this requirement may be eliminated and the validation of the public key certificate of the ground entity may be offloaded to a network of ground entities only. In this way, the scarce RF resource may be alleviated from the traffic generated in the context of validating the public key certificate of the ground entity.

The term communication initialization message indicates that that message is the beginning of an initial exchange of messages between the aircraft and the ground entity. In particular, the communication initialization message may be the first message with which the aircraft starts a communication with the ground entity. The communication initialization message may be the first message of a handshake protocol between the aircraft and the ground entity. The said initial exchange of messages is an exchange of messages that requires an exchange of public key certificates and, potentially, public keys for establishing a secure communication. The initial exchange of messages may comprise a mutual authentication and may comprise a validation of the exchanged public key certificates. The initial exchange of messages is a non-resumption exchange, i.e. it is not part of an exchange of messages between the aircraft and the ground entity that is subsequent to a previously established communication, which may have been paused or which may have been lost due to the aircraft and the ground entity losing the joint radio frequency channel. For example, in case an aircraft flies through the coverage area of a particular ground entity and re-enters that coverage area a short time later, such as later during the same day or the following day, it is possible to resume the previous secure communication via a resumption operation. In this case, it is possible that no exchange of certificates is needed. The communication initialization message is not part of such a resumption of a previous secure communication, but forms part of an establishing of a secure communication where a full handshake, including an exchange of certificates and a validation of certificates, is required.

According to a further embodiment, the trusted responder is indicated in the communication initialization message from the aircraft. The ground entity may only be allowed to use the trusted responder for validating its public key certificate, when said trusted responder is indicated in the communication initialization message from the aircraft. In this way, the aircraft may have control over which trusted responder may issue an acceptable validation response. The trusted responder may be indicated via a responder identification and/or via an address where the trusted responder may be reached, e.g. an IP address.

According to a further embodiment, the trusted responder is indicated in a listing of at least one potential trusted responder, said listing being included in the communication initialization message from the aircraft. In this way, the aircraft may give the ground entity some freedom to decide between different trusted responders. This may in particular be beneficial where the ground entity has sent its public key certificate to some trusted responders, but not all trusted responders of the public key certificate validation system. The ground entity may match the listing of potential trusted responder(s) with those trusted responders that the ground entity previously sent its public key certificate to. The intersection is a set of trusted responder(s) that are accepted by the aircraft for validating the public key certificate of the ground entity and that promise a quick turn-around due to their pre-cached validation database already having a record regarding the ground entity. In case the listing of at least one potential trusted responder comprises a plurality of potential trusted responders, the ground entity may select among that plurality of trusted responders. In case the listing of at least one potential trusted responder comprises only one trusted responder, the ground entity has to select this trusted responder.

According to a further embodiment, the communication initialization message is a client hello message. In particular, the communication initialization message may be a client hello message in accordance with the TLS communication protocol or in accordance with the DTLS communication protocol. By definition, the client hello message of the TLS/DTLS communication protocol is the message to start the communication.

According to a further embodiment, the listing of the at least one potential trusted responder is included in a responder extension of the client hello message. The term responder extension is used as referring to any suitable extension of the client hello message that may contain the listing of the at least one potential trusted responder. In particular, the client hello message may comprise a certificate status request, such as a certificate status request in accordance with the Online Certificate Status Protocol (OCSP). Said certificate status request may be provided with one or more trusted responder IDs. It can therefore also be said that the at least one potential trusted responder is provided in a certificate status request with trusted responder IDs extension of the client hello message. The certificate status request may in particular be structured in accordance with the RFC 6066 Section 8 definition of the TLS extension. The listing of the at least one potential trusted responder may be provided as a responder_ID_list in the extension of the client hello message.

According to a further embodiment, the listing of at least one potential trusted responder comprises a plurality of potential trusted responders. By providing a plurality of potential trusted responders, the ground entity is brought into a position to select a suitable one of the potential trusted responders. In particular, the ground entity may select the trusted responder that promises the shortest turn-around time for providing the validation response. Also, the ground entity may turn to a fall-back trusted responder, in case the originally selected trusted responder is out of service, does not answer, fails to provide the validation response, etc.

According to a further embodiment, the communication initialization message comprises a public key certificate of the aircraft, herein also referred to as aircraft public key certificate. Including the public key certificate of the aircraft into the communication initialization message may allow for the mutual authentication of the aircraft and the ground entity with a lower number of messages and with a low usage of the RF resources to/from the aircraft. As compared to previous approaches, the message exchange for the handshake between the aircraft and the ground entity may be kept to a reduced number of messages. In particular, as compared to previous approaches where the aircraft initiated the communication with a first message, where the ground entity responded to the first message with a second message, which included the public key certificate of the ground entity, and where the aircraft sent the public key certificate of the aircraft to the ground entity in a third message, the exchange of public key certificates may be kept to a first message from the aircraft, herein referred to as the communication initialization message, and a second message from the ground entity, herein referred to as the response message to the communication initialization message. By including the public key certificate of the aircraft into the communication initialization message, a front loading of the exchange of certificates and a reduction of messages for exchanging certificates may be achieved.

The public key certificate of the aircraft may be contained in the communication initialization message in an uncompressed version or in a compressed version. When using a compressed version of the public key certificate of the aircraft, the communication initialization message may have a smaller size than in the case of using an uncompressed version of the public key certificate and, potentially, the public key. In this way, the usage of the constrained RF resource may be kept particularly low.

According to a further embodiment, the communication initialization message comprises unique identification information regarding a public key certificate of the aircraft, herein also referred to as aircraft public key certificate. The unique identification information may comprise any kind of information that allows for an unambiguous identification of the public key certificate of the aircraft. For example, the unique identification information may comprise certificate issuer information and a serial number of the public key certificate of the aircraft. In other words, the unique identification information may comprise an unambiguous indication which authority issued the public key certificate of the aircraft and what the serial number of the public key certificate of the aircraft is.

In embodiments where the communication initialization message comprises unique identification information regarding the public key certificate of the aircraft, the method may comprise the step of obtaining the public key certificate of the aircraft via the unique identification information. The obtaining of the public key certificate is arranged for by the ground entity. Accordingly, it can also be said that the method comprises obtaining, at the ground entity, the public key certificate of the aircraft via the unique identification information. The ground entity may obtain the public key certificate of the aircraft from any suitable entity that has the public key certificate of the aircraft available. In particular, the ground entity may request the public key certificate of the aircraft from an entity for which it has a high level of trust. It is possible that the public key certificate of the aircraft is requested right from the issuer of the certificate or from another entity. In this way, the aircraft may be freed from the need to send its public key certificate to the ground entity.

According to a further embodiment, the public key certificate of the aircraft or the unique identification information regarding the public key certificate of the aircraft is provided in a certificate extension of the client hello message. In previous approaches, no extension for communicating the client certificate in the client hello message existed. Accordingly, providing a certificate extension and using said certificate extension for communicating the client certificate in the client hello message, i.e. for communicating the public key certificate of the aircraft in the client hello message, provides for a particularly efficient way of frontloading the certificate exchange between the aircraft and the ground entity. The term certificate extension is used as referring to any suitable extension of the client hello message that may contain the public key certificate of the aircraft or the unique identification information regarding the public key certificate of the aircraft. In an exemplary embodiment, the “Reserved for Private Use” section of the cached info extension of the RFC 7924 definition for TLS extensions may be used.