For the purpose of this document, the following definitions apply:
Freedom from unacceptable risk. [EUROCONTROL, SRC DOC 4, Glossary of Terms and Definitions & List of Acronyms, Edition 2, 27.02.2002]
A combination of measures and human and material resources intended to safeguard civil aviation against acts of unlawful interference. [ICAO, DOC 9569, Definitions]
The Integrated Aeronautical Information Package (IAIP) contains safety-related aeronautical information, which is essential for the daily operations of airlines, pilots, air traffic controllers and other actors in the aeronautical sector.
The eAIP Specification relates to those aspects that are specific to the electronic format. In this context, most stakeholders are concerned with the security and data integrity issue, especially regarding the distribution of aeronautical data over public networks.
Safety and security are not completely separated issues. For example, an attack on computer a server can take the server out of service for several hours or days. This is a security aspect, which triggers a safety issue: the eAIP site hosted by that server might become unavailable for some time.
In this example, software and procedures would be put in place to protect the server against this kind of attack or to ensure the continuity of the service by using different servers or routes. On the safety side, risk mitigation of eAIP unavailability could require to always store and make available on the client side computer/network a local copy of the eAIP. Due to the AIRAC cycle, a local copy will not be outdated in a few hours or days.
The eAIP Specification defines an electronic format for the AIP data, which is different from the paper format currently in use. The information content and structure is however exactly the same. The quality system (ICAO Annex 15 requirement) and the static data procedures currently implemented in AIS are equally applicable to the eAIP production process. This shall ensure that data issued in the form of an electronic AIP are of the same quality as data issued in the form of a paper AIP.
The way AIP/eAIP data are used for operational needs is subject to specific ATS, ATM, avionics, etc. regulations and is considered outside the scope of the eAIP Specification. This will however fall within the scope of the proposed EUROCONTROL project on end-to-end data integrity.
Therefore, the scope of the safety and security considerations included in the eAIP Specification is limited to demonstrating that the data integrity provided by the electronic format is the same or better than for the paper format.
How can data integrity be ensured on the (electronic) path between the eAIP editor and the eAIP user? The answer to this question does not lie in data format, but in data transmission. If the transmission path is safe, then data are safe as well. However, we know that the Internet, as a public network, is currently not a secure path. In order to have a secure path through an insecure environment, we need to enclose data inside a protection layer. This layer can be provided by technologies such as electronic signature and authentication. These technologies even bring an additional benefit: non-repudiation. Once electronically signed, the originator cannot deny having signed and issued the data.
This chapter and the following one discuss general safety / security aspects and risks associated with publishing an eAIP. Additional documentation is available in the User's, Editor's and Developer's manuals. Most eAIP safety and security related documentation is targeted to a specific audience, as detailed below:
Table 8.1.
| Intended Audience | eAIP Security Document |
|---|---|
| All stakeholders | This document |
| eAIP Users | How to check the signature of an eAIP |
| eAIP Distributors | |
| eAIP Developers | Technical and procedural choices |
| Security Managers and eAIP Distributors |
"eAIP Distributors" designates the persons in charge of the distribution of eAIP material, within the eAIP publishing organisation. In some organisations, this might be the Editors, performing both roles. In other organisations, eAIP distribution might be outsourced. In this case, "eAIP Distributors" means the persons responsible for sending all material to the distribution company.
Disclaimer: Please note that the information contained in these documents should not be considered as ultimate computer security expert advice; they only give a general introduction to the concepts. Security-conscious organisations should seek expert computer security advice before implementing the technologies described hereunder.
Please read also the safety-related questions in the Frequently Asked Questions (FAQ) and the eAIP Security Risks and Mitigating Strategies.
There are three different aspects to information security: Confidentiality, Integrity and Availability.
Table 8.2. Security Aspects
| Security aspect | When it applies |
|---|---|
| Confidentiality | when a piece of information must not be read by any unauthorised party |
| Integrity | when a piece of information must not be tampered with |
| Availability | when a piece of information must be accessible without interruption or delays (H24, typically) |
Different technologies exist that usually address one or two of these aspects. Needless to say, it is more difficult (read: costly) to address all of them at the same time. Information system managers need to evaluate these three aspects based on their relative importance in their specific context.
Confidentiality: In the AIS domain in general, information is rarely confidential. An exception may be in some AIS-related military information. For the rest, it is usually in the interest of the publishing authority that access to AIS data is as open as possible.
Integrity: This is a growing concern.
Availability: In the context of static AIS data, availability is not the primary concern. It should not be a serious problem if an AIP is not available for a few minutes or even for a few hours for an on-line document. Simple solutions, such as local storage are available. However, this is obviously not the case with NOTAM, which must be immediately available to those concerned.
An interesting IT security technique for the AIS domain is electronic signature. An electronic signature not only ensures data integrity, but also guarantees the sender's identity. This means that a recipient can be sure that he received AIS information from the legitimate sender (authentication) and it also means that the sender cannot deny having sent the information (non-repudiation). When applied to a specific document, an electronic signature ensures that document's integrity as well.
The use of an electronic signature scheme is the favourite candidate for ensuring the eAIP integrity. This will provide users with three levels of protection:
AIS data integrity: protection against modification on the path from originator to user;
AIS data authentication: certification of the data originator;
AIS data non-repudiation: originator cannot deny having signed the data.
Non-repudiation normally concerns a transaction and applies to both parties, namely originator and recipient. In this document, the recipient side is not addressed, but it can be addressed in a very similar way if necessary (for example, through the use of a trusted third party).
The concept of the electronic signature is very similar to the hand signature:
The originator electronically signs a document using a private "key".
The originator sends the document to the user with a copy of his public key or certificate.
The user opens the document and checks the electronic signature against his copy of the originator's public key or certificate.
The main difference lies in the way to check for an electronic signature's validity. An electronic signature is created using strong encryption technology and is virtually impossible to forge (with current computer technology). With appropriate software, a user can read the electronic signature, which contains information about its owner and issuer.
This issuer can be a centrally-managed organisation (called Certificate Authority, or CA), which is trusted by the user community to certify public keys of legitimate owners. For example, a CA would verify thoroughly a user's identity before certifying public keys containing that user's name.
A private key is protected by a password, known only by its owner. If the password were to be disclosed, the owner would revoke his certificate and obtain a new one. The CA can be queried for certificates that have been revoked by their owners.
For more a more detailed explanation, you can refer for example to Learning About Cryptography by Terry Ritter.
Electronic signatures (also called security certificates) are common in the Internet community. They are notably used to authentify Web servers, for example for Web banking services (when you connect to your bank's Web site, you want to be sure that it is indeed your bank and not a fake Web site that has hijacked your connection). Consequently, several companies offer CA services: Thawte, VeriSign, GlobalSign to name a few. They sell public certificates and also CA delegation, when an organisation wants to issue certificates directly to its members or employees.
It is also possible for an organisation (or individual) to proclaim itself as the Certificate Authority and begin to issue certificates. The only natural condition is that a community of users exists who trusts it (him/her) as a CA. Open Source (free) software as well as commercial software are available to manage a CA and issue certificates.
These techniques are being used, for example, in the European AIS Database (EAD) project. EAD's system-to-system interface is based on the exchange of XML messages, which are signed by the originator for authentication.