Security risks discussed in this chapter concern the transmission of the eAIP, from an AIS office, to the AIP end-user. The following areas are not covered:
the creation and edition of an eAIP (covered by the AIS quality assurance process),
the use of the eAIP (relevant to the end-user internal safety/security policy and covered by specific regulations).
It is assumed that the data contained in an eAIP is non-confidential and that it does not need to be modified during transport. A user must be able to notice if it has been modified between publication and usage.
Publishing an electronic AIP introduces a variety of risks: the publication, transmission and use of the eAIP could take place over several untrusted networks, such as the Internet. To reduce the risk of data tampering and data loss, the use of electronic signatures is recommended.
Most software mentioned in relation with the eAIP Specification is Open Source and Free Software. This software environment is not intended for production use, but rather to facilitate the adoption of and experimentation with public key technology. It is up to the interested organisation to select software, open or closed source, to fulfil the goals of eAIP security.
These documents do not contain guidelines for internal security policy, or any other information necessary for the set-up and operation of a production-quality Certificate Authority (CA) or PGP-based security infrastructure.
The security implications of operating any cryptographic technology, legal ramifications and other issues are outside the scope of this document. Interested parties should consider seeking professional help from security experts if they don't have adequate knowledge internally.
For each identified risk below, a risk classification table is included. It describes the risk, its likelihood, and its impact on the parties involved. The table is structured as follows:
Type: What kind of risk is it?
Impersonation: the end-user believes the attacker is a legitimate person
Data Integrity: the content of the eAIP is modified or destroyed
Availability: the eAIP is not available to the end-users
Impact of risk: What is the impact level to the sending and/or receiving party?
High: severe impact on safety
Medium: some minor impacts
Low: no impacts on safety
Difficulty: How easy is it to achieve or how likely is it to happen?
Easy: unskilled hacker / short time / very likely
Difficult: confirmed hacker / medium time frame / likely
Very difficult: well equipped and confirmed hacker / long time frame / unlikely
The following risks have been identified:
Please note that this list is not exhaustive.
This vulnerability applies to eAIP distribution via a file download service, for example a Web server or an FTP server. It can concerns both secured (by Secure Socket Layer - SSL) and not secured download servers, accessible on the Internet or any other network.
An AIS office can publish eAIP packages on-line on a server for end-users to download. This server is an obvious target. A successful attacker who, using a flaw in the server software, gains control over the computer on which it is running, may impact:
Availability: He is able to take the server out of order or to delete eAIP packages;
Data Integrity: He can replace an eAIP by another document of his craft, while an end-user things that he is using an official eAIP.
Possible controls to mitigate the risks stated above:
Proper security practice: Keep the server secure, with the latest security patches applied. Secure the operating system the service is running on.
Electronic signature: End users can check authenticity of the electronically signed packages they download.
This vulnerability applies to eAIP distribution via a file download service, for example a Web server or an FTP server. It can concerns both secured (by SSL) and not secured download servers, accessible on the Internet or any other network.
Hardware and software are more likely to fail against this type of attack. A successful attacker who, using a flaw in the server software, manages to remotely take the server out of order, may impact availability: eAIP packages will not be available until the attack ends or the service is restored.
Possible controls to mitigate the risks stated above:
Proper security practice: Keep the server secure, with the latest security patches applied. Secure the operating system the service is running on.
Offer redundant service;
For end users: do not rely solely on remote services, especially through public networks.
This vulnerability applies to eAIP distribution via Web downloads, secured by SSL or not, through the Internet or not.
This "man in the middle" attack consists in intercepting Web requests sent by end users to the Web server, and responding to them. The attacker is effectively bypassing the Web server, and providing his own forged Web server instead. This can be done by DNS hijacking or by network path control (i.e. one of the computers traversed by the request is controlled by the attacker).
It can happen even on servers secured by SSL if the end user does not carefully verify the server's certificate or if his computer has been tampered without his knowledge so that it silently accepts forged certificates.
Possible controls to mitigate the risks stated above:
Proper security practice: Securing all computers and devices which are crossed by the Web requests from the end-user's side to the server's side. This includes firewall, routers and proxy servers.
Use of SSL: Using an SSL enabled Web server confirms to the end-user that he is connected to the expected Web server, and not the attacker's. However, the end user must manually check the authenticity of the SSL certificate. If not, he may be connecting to the attacker's Web server without noticing.
Electronic signature: End users can check authenticity of the electronically signed packages they download.
This vulnerability applies to eAIP distribution by email through the Internet or another network.
SMTP, the protocol used for email transmission on the Internet, does not provide authentication of the sending party. Anybody can forge the sender's name and email address. Therefore, the sender's name and address cannot be trusted. To impersonate an AIS office, all the attacker needs to know is the (usually, publicly available) email address and name. He can then simply change his name and email address in his email client software and send out mails which appear to come from the official AIS office, and which contains modified, outdated or erroneous data..
This vulnerability applies to eAIP distribution via CD-ROM, DVD, hard disk or any other digital transmission which requires physical transport.
A determined attacker may arrange the interception of one or several packages containing eAIP digital media. He may replace these media by others containing a modified or outdated eAIP.
The integrity of the eAIP package is not guaranteed: transport and media failures (a hard disk failure, CD-ROM corruption or interrupted download) can leave the user with an incomplete or corrupt eAIP.
This corruption can be accidental or intentional (i.e. sabotage).
Electronic signature: An end user can check the validity of a file using the electronic signature. Indeed, the signature contains integrity information regarding the signed file. Data corruption is similar to data tampering in the sense that the file is modified. As such, it will not match its signature.
The risk analysis above shows us that the use of electronic signatures can reduce the risks associated with the publication and transmission of the electronic AIP.
The use of electronic signature in conjunction with the eAIP has the following effects:
The end-user can certify the authenticity of the information: certify that the eAIP originates from the right authority;
The end-user can guarantee the integrity of the data: certify that the received eAIP is complete, not corrupt and unmodified since its publication by the AIS office.
In short, this solution requires first to set-up the necessary environment:
The AIS office sets up a signing environment, for example, x509 or PGP.
The AIS office provides each end-user with the signing certificate or public key using a different channel than the one used for transmitting the eAIP. The end-user checks with the AIS office for authenticity.
The end-user acquires the proper software to verify the signature.
For each publication of an eAIP:
The AIS office signs the published eAIP package, for example using x509 or PGP. If several packages are provided, each is signed individually.
The eAIP packages are distributed together with their signatures.
The end-user receives the eAIP and checks the signature.
Introducing cryptography in a document work-flow solves some security problems, as seen above. However, it also introduces other issues, such as:
Once using cryptography, it is easy for producer and end-users to believe that ultimate security has been achieved. This is not the case. Cryptography is only a tool, which can be used to increase security. It is nothing without proper security practises (e.g. strong password policy, efficient physical security, etc.). The secure state of mind is often described as "healthy paranoia".
Public/private key cryptography (both PGP and x509) relies on the secrecy of the private key. The theft of the private key (and the knowledge of its associated password) is dramatic: the attacker now has the ability to impersonate the publisher in the eyes of the end-users. The issue is to create a security environment where it becomes possible to detect such an event, and have appropriate procedure to revoke and change the incriminated keys and associated certificates.
It is easy to create forged certificates and PGP keys which bear the same contact and organisation information as the legitimate one. If an attacker manages to convince an end-user to trust such a look-alike certificate, he can avoid other more difficult attack scenarios. Therefore, it is vital to organise a verification procedure: when the end-user receives any certificate, he must check its validity with the originating party using an alternative communication channel (i.e., not the channel used to distribute the certificate). Note that if the attacker manages to convince the end-user to send him an email or phone him on his "direct line", he has effectively bypassed the verification procedure. So the end-user must use trusted contact information for this verification procedure.
The use of electronic signatures ensures that the data integrity of the eAIP product can be ensured with relatively little efforts, at the same level as for the paper document. In addition, authenticity and non-repudiation may be ensured, which is not the case with the paper document. Therefore, it is recommended that electronic signatures are used in all eAIP package distribution to end-users.