ACP-WG S-7/WP-XX
International Civil Aviation Organization
13/06/15
WORKING PAPER
AERONAUTICAL COMMUNICATIONS PANEL (ACP)
SEVENTH MEETING OF THE WORKING GROUP S (Surface)
Montreal, Canada 22 – 23 June, 2015
Agenda Item xx: Xxx
TOPICS OF X.509 CERTIFICATE POLICY CONSIDERATIONS FOR AERONAUTICAL
MOBILE AIRPORT COMMUNICATIONS SYSTEM (AEROMACS) AND THE IMPORTANCE
OF A PKI POLICY AUTHORITY
(Presented by Rich Hawkins, WiMAX Forum)
SUMMARY
The WiMAX Forum Aviation Working Group PKI Task Group is comprised
of subject matter experts from the aviation industry and security providers.
Leveraging this combined experience, this group has developed some
recommendations and guidelines that could be used to define requirements for
an AeroMACS PKI Certificate Policy and Certificate Practices Statement
ACTION
Consider and evaluate the finding of the WiMAX Forum AWG PKI Task
Group in defining the AeroMACS PKI Certificate Policy & Practices
requirements for inclusion in the ICAO IPS Technical Manual and Guidance
Material
1.
INTRODUCTION
1.1
WiMAX Forum has an established robust Public Key Infrastructure (“PKI”) Program.
The WiMAX PKI is described in the Governing Documents of the WiMAX Forum and is operated under
the supervision of the WiMAX Policy Authority. The existing WiMAX PKI provides a mechanism that
permits Authorized Users to obtain Public Key Certificates (“PKCs”) through Certificate Authorities
(“CA”) which are entities that the WiMAX Policy Authority has authorized to issue PKCs to unrelated
third-party customers or users. The current authorized CA is Symantec. WiMAX Certificate Authority
(8 pages)
Document1
ACP-WGW S-7/WPXX
-2-
(CA) provides hosting of the WiMAX Public Key Infrastructure (PKI) hierarchy and supplies device and
server certificates for use in WiMAX networks.
1.2
The WiMAX Forum Aviation Working Group (AWG) formed a PKI Task Group to
leverage the experience of the Forum, Symantec and subject matter experts from the aviation community
to identify topics of consideration for determining the policy practices for issuing certificates to the
various devices and servers in the AeroMACS ecosystem.
1.3
With the next generation of “connected aircraft” and the need to propel towards increased
efficiency and interoperability, there have been extensive requirements for external interaction of the
various systems in the aerospace industry. As the number of intelligent devices rises, the potential damage
that could be caused by lack of security will continue to increase. It is important to note that such
advancements in technology highly demand proper security framework in place. The purpose of this
paper is to share the finding of the AWG PKI Task Group in hopes that we can provide guidance to WGS in defining the requirements of an AeroMACS PKI ecosystem for the secure electronic transfer of
information related to AeroMACS applications and services.
1.4
Whether it is an Airline subscriber station or a Service Provider subscriber substation that
aims to join the airport operations network, great care must be taken to ensure that only legitimate
communication or “information transfer” is occurring between these devices. The concept of the ability to
identify and authenticate individual components, to a high level of assurance, is extremely important to
the security of the aircraft and its operating environment.
1.5
To satisfy such security requirements around identity assurance, AeroMACS can enforce
the data integrity requirements of the civil aviation industry through deployment of identity management
solutions, based on Public Key Infrastructure (PKI) technology with a “chain of trust” to a Certificate
Authority (CA)
2.
2.1
DISCUSSION
Definition
2.1.1
Public Key Infrastructure is a set of policies, practices, and technologies used to create a
trust framework in such large private ecosystems as AeroMACS, for securing digital data and
authenticating digital identities. Generally speaking, the benefits of PKI in a variety of applications can be
best expressed in terms of confidentiality, message integrity, and user authentication. These benefits can
protect a secured system against electronic fraud and other threats such as data tampering, eavesdropping,
and masquerading.
2.1.2
To give an example, a Subscriber substation in next generation AeroMACS framework
tries to securely connect to the ATC network, the digital Certificate associated with the server asserts the
identity of that server to authenticate it to the network safely. To prevent forgery of these certificates,
each Digital Certificate is cryptographically signed by the governing root of trust. The model works only
because the CA’s “Roots of Trust” have been configured to allow for trust by the device ahead of time.
Without CAs acting as middlemen in the trust transaction, there is no way for a client to be sure of the
identity of the server to which it is communicating. A “self-signed” certificate issued without the
verification of a CA can claim to represent anyone, a claim that can’t be confirmed or denied. With
“Roots of Trust” pushed to the client devices and server, the subscriber (such as the device or server) can
-3-
ACP-WGW S-7/WPXX
use a root to authenticate itself to the network only if the “chain of trust” for validation by the device is
established.
2.2
PKI Policy Authority: When a PKI supports a complex ecosystem of interdependent
elements as in the AeroMACS ecosystem, sound practices are essential to establish trust. A PKI Policy
Authority should be established. The AeroMACS PKI Policy Authority plays an instrumental role in
defining policies that form the basis of interoperability of multiple domains. If the expectation in an
AeroMACS network is for the certificates to be used and relied upon by an open community of users, it is
recommended that a public-accessible Certificate Policy (CP) and Certificate Practices Statement (CPS) is
written to inform the community of users about AeroMACS certificate policy and practices. One or more
self-signed root CAs may be created under the name of this Policy Authority.
2.3
Main Topics of Certificate Policy Considerations
2.3.1
Single global root of trust versus multiple CI (Certificate Issuer) model
SINGLE GLOBAL ROOT OF TRUST MODEL
SINGLE
GLOBAL CI
Technical
Pros
Cons
Simplicity: One root certificate
across the entire infrastructure.
Clear hierarchical roles and
relationships between the root
CA, intermediate policy CAs,
the CAs that issue end entity
certificates (if any), and the endentity certificates themselves
Security: Compromise of the Root
CA, single trust anchor and
everyone’s trust point results in a
compromise of the entire PKI.
Path Discovery and
Validation: Certification paths
are easy to develop because the
paths are unidirectional. This
results in a simple, obvious and
deterministic path from a
device’s certificate back to the
trust point.
However, a Certificate Authority can
diminish this threat to a great extent
with best implementation around PKI
practices and stringent technical,
facility and security controls for key
protection
Shorter Path Length: The path
lengths for validation are
relatively smaller than that in a
cross certification model. The
longest path is equal to the depth
of the hierarchy plus one: a CA
certificate for each subordinate
CA plus the device certificate.
Offline Root: Does not require
any run-time connectivity for
path validation
Operational
Interoperability: Uses basic
PKI constructs, widely
Retrofit: Cannot be added to existing
PKI domains without distributing the
-4-
ACP-WGW S-7/WPXX
supported by even the simplest
PKI software stacks
Scalability: To incorporate a
new community or ecosystem,
the root CA can easily establish
a trust relationship with that
global Root CA in one location.
SINGLE
GLOBAL CI
new root CA to all relying party
Devices and issuing/cross certifying
member operator CAs
It may be commercially and
operationally challenging to identify
and work with single organization
that can serve the Single Global Root
of Trust.
Policy Authority: Policy
controls are introduced in a topdown fashion
Root CA can control the policy
of subordinate CAs including
whether additional CAs can be
added to the hierarchy by
subordinate CAs
Policy
Since single root CA is anchor
of trust or all devices and CAs
within the hierarchy, maximum
physical security policies and
practices are required only for
the Root CA, rather than all CAs
within the hierarchy.
MULTIPLE CERTIFICATE ISSUER MODEL
-5-
ACP-WGW S-7/WPXX
Pros
2.3.2
Cons
Distribution: Multiple Root CAs
need to be distributed down to the
devices
Complexity: Multiple CI model
results in a more complex path
validation due to cross certification
Compatibility: Certificate-validation
software on devices must consider
each organization's hierarchical trust
relationships as well as the crosscertification trust relationships
between multiple CAs.
Technical
Resource Constraints: Validation
software on devices with limited
resources may not be able to handle
traversing the path lengths efficiently.
AIA pointers can be used to traverse
the hierarchy, but it is not always
populated correctly, nor are most
relying party clients equipped to do
this correctly.
Speed and efficiency: Increased
network traffic due to the extended
length of the certificate chain.
Multiple CI
Scalability: Issue can be
possibly resolved with a natural
grouping.
Operational
Scalability: Overhead unprecedented
even for a relatively small number of
organizations
Compatibility: Relying parties must
retrieve AIA extension CAIssuers
bundle at runtime (or cache) which
could be huge resource overhead
Policy Overhead:
Policy
Considerations
1.
Need to establish initial and
continuing audit policies and
practices to ensure all CIs follow
stringent set of policies and
procedures for certificate issuance
2.
AeroMACS Policy Authority to audit
policies for each member’s PKI
including:
3.
- Pre-issuance identity vetting
policies,
- private-key protection policies,
- CA and directory infrastructure
operational policies.
-6-
ACP-WGW S-7/WPXX
2.3.3
Device Certificates: ATA Spec 42 defines these as certificates that are used for
identifying physical hardware, such as webservers, VPN servers, wireless access points, aircraft, ground
stations, or other nonperson items.
2.3.3.1
Server Certificates: The AeroMACS Certificate policy needs to document and call out
the requirements for a Server and a Device certificate profile distinctly. It is necessary to understand the
validity/lifetime/method of certificate issuance for these Server certificates.
2.3.3.2
Device Certificates: Standards (ATA Spec 42 lists) mention that 3 years to be the
validity of the device certificate.
2.3.4
Device Vetting Requirements:
The ATA DSWG Certificate Policies state, as a basic requirement, that no unvalidated
information shall be included in a certificate. Currently, for device and aircraft entities, the
information listed below is endorsed by the ATA DSWG CP, and this list is available to
system designers for use in defining the identities of the systems. This information must be verifiable by
the Certificate Authority. For instance, if an IETF DNS Fully Qualified Domain Name (FQDN) is used,
the Certificate Authority may require that they be able to resolve the FQDN by means of a DNS lookup,
or by validating with the relevant whois database.
The following name forms are suggested to be used by System Designers as the values for
the “Subject” Distinguished Name commonName field:
For devices other than aircraft:
Character ATA/IATA Address
context of the Certificate Authority's PKI.
For aircraft:
-GABC, N-12345)
-bit ICAO Address
For the various entities leveraging the AeroMACS technology, a complete set of guidelines such as the
above need to be established for the systems designers to allow their system identification in the network.
These guidelines need to be published as part of the Certificate Policy. The certificate policy also needs to
identify the process for any system designer that wishes to use a custom attribute/identifier and a
mechanism whereby the Certificate Authority may verify that the applicant is entitied to the use of that
identifier.
The Ceritifcate Policy should provide minimum requirements that makes a certificate valid and fit for use
in the AeroMACS ecosystem. For example:
-7-
ACP-WGW S-7/WPXX
- The certificate does not contain any extension marked critical that the application
does not understand;
- The certificate is fit for purpose (i.e. has the correct keyUsage, extendedKeyUsage,
and fits within the policy constraints of the application);
2.3.5
Certification Revocation mechanism: The mechanism for checking certificate validity
will depend on the client software, however, generally speaking the Certificate Policy should define the
options for revocation mechanism to provide guidelines for the system implementers. The following
means of revocation are available:
2.3.5.1
CRL: Certificate Revocation List
Each CA maintains a public list of certificates it has issued that have been revoked. Each certificate that is
conformant to the AeroMACS Certificate profiles, contains a link to the CRL of the issuing CA. It is the
relying party's responsibility to retrieve the issuing CA's CRL and check whether a certificate being
evaluated is listed as revoked.
2.3.5.2
OCSP: OCSP is useful when a CRL grows too large to be feasibly retrievable.
OCSP Stapling: The other alternative to OCSP is OCSP Stapling. In OCSP stapling, the Web server
obtains the OCSP response from the CA. When a browser comes to the site, the OCSP response is stapled
to the SSL handshake. This means there is no extra connection to the CA’s OCSP service. The result is
less latency and a faster response. System designers that want to consider implementing OCSP Stapling
will need to find out if their server supports OCSP Stapling.
Verification of each of these requires an “on-line” connection to the global internet,
Checking of CRL and/or OSCP. The AeroMACS certificate policy will need to define the
preferred/desirable entities where validation is deemed important. For example: It can be considered
highly desirable to perform validation for the ground based side of the communications and verifications
systems. It however may not be simple / feasible to perform validation for “on-board” systems.
2.3.6
Key Zeroization:
The Certificate Policy should determine next steps for when a device changes ownership to avoid an
unknown party posing itself as the old keyholder.
When certificate revocation is applicable, zeroization may be less important, however the CP should still
provide guidelines on how and if, system implementers should consider key zeroization in addition to
certificate revocation.
For those devices where certificate revocation is not applicable, how/and should the private keys be
destroyed/erased if the device changes ownership. Guidelines along these also to be documented.
2.3.7
Key Generation:
For those devices that cannot generate their own keys, the certificate policy needs to define acceptable
procedures for installing keys on this type of equipment. For example, for aircraft equipment, the keys
may need to be generated elsewhere and CP needs to define the delivery, maintenance and change of
ownership processes.
ACP-WGW S-7/WPXX
-8-
The Certificate Policy must also provide guidelines to the system implementers for the key generation.
Card Management System:

For Devices that are not able to generate their own keys, how are the keys to be generated? Are these
certificates to be issued on Smartcards that will then be manually installed by a technician onto the
aircraft device? If so, would there be a requirement for individual certificates (non-device
certificates)?
2.3.8
References to Certipath/FAA: The CertiPath Bridge offers a secure and efficient means
of exchanging information, eliminating the costly and complex process of individually mapping
PKI/hardware tokens and issuing project-specific credentials for every new customer, supplier, or partner.
CertiPath’s trust community extends beyond its own enterprise members to the U.S. Federal government
via a Bridge-to-Bridge trust relationship between CertiPath and the U.S. Federal Bridge, which operates
its own hub-spoke peer-to-peer environment for the U.S. Federal agencies. This hub-to-hub relationship
enables inter-organizational trust between the members of the two Bridges.

Hence, in the U.S.A. is cross certifications with the Certipath Bridge a mandatory or an optional
requirement?
2.3.9
Signing Algorithm: Certificate profiles for Self Signed Root CA reflect ECC, Elliptic
Curve Cryptography, a family of public- key algorithms that can provide shorter key lengths, one of the
first practical public-key cryptosystems and is widely used for secure data transmission where the
encryption key is public and differs from the decryption key which is kept secret. AeroMACS needs to
finalize on; whether a single Root CA should be adopted and then the associated signing algorithm (other
aviation security standards either already specify or are moving in the direction-of using ECC as the root).
If both algorithms are needed, two primary self-signed roots must be created.
3.
ACTION BY THE MEETING
3.1
The ACP WG-S is invited to:
3.1.1
Consider and evaluate the finding of the WiMAX Forum AWG PKI Task Group in
defining the AeroMACS PKI Certificate Policy requirements for inclusion in the ICAO IPS Technical
Manual and Guidance Material and elaborate the items partially mentioned in section 2.2 of this Working
Paper.
3.1.2
requirements.
experience
Provide input on Questions that remain to be answered in an effort to better define
In some cases we have provided recommendations based on the LKI Task Groups
3.1.3
Consider future collaboration with the WiMAX Forum Aviation Working Group to
further this effort