Manual On Detailed Technical Specifications For The Aeronautical Telecommunication Network (Atn) Using Iso/Osi Standards and Protocols

IV-B-1 Manual on detailed technical specifications for the Aeronautical Telecommunication Network
using ISO/OSI standards Part IV-B – Security Services
Doc. 9880-AN/466
(July 2011)
MANUAL ON DETAILED TECHNICAL SPECIFICATIONS FOR THE

AERONAUTICAL TELECOMMUNICATION NETWORK (ATN) using ISO/OSI
standards and protocols
PART IV-B – SECURITY SERVICES
1st edition
Manual on detailed technical specifications for the Aeronautical Telecommunication Network
using ISO/OSI standards Part IV-B – Security Services IV-B-2
Foreword
This manual replaces the “Manual of technical provisions for the Aeronautical Telecommunication Network
(ATN)”, Doc. 9705 – third edition. Amendments to Doc. 9705 are incorporated. These amendments were
necessary as a result of ongoing validation, and operational experience gained during implementation of elements
of the ATN. These amendments were reviewed at the ACP Working Group of the Whole #1 meeting in June
2005 and further updated at the ACP Working Group N/06 meeting held in July 2006. Relevant background
material is available in the reports of these meetings, which can be accessed at www.icao.int/anb/panels/acp.
The different parts of this manual will be published as and when the relevant sub-volumes of Doc. 9705 have
been updated and completed. With the publication of each part of this manual, the relevant sub-volumes of Doc.
9705 will become obsolete.
This manual contains the detailed technical specifications for the ATN, based on relevant standards and
protocols established by the International Organization for Standardization (ISO) and the Telecommunication
Standardization Sector of the International Telecommunication Union (ITU-T) for Open Systems Interconnection
(OSI). A separate manual, addressing detailed technical specifications for the ATN, based on standards developed
by the Internet Society (ISOC) for the Internet Protocol Suite (IPS) has been prepared (ICAO Doc 9896).
Where necessary and to avoid duplication of essential material, the IPS manual refers to this manual, as
required.
This manual will be published in the following parts:
Part I Air-ground applications (Doc. 9705/sub-volume II)
Part IIA Ground-ground applications AIDC (Doc. 9705/sub-volume III)
Part IIB Ground-ground applications – AMHS (Doc. 9705/sub-volume III)
Part III Internet communication service, including upper layer communications service
(Doc. 9705/sub-volumes IV and V)
Part IVA Directory service,

(Doc. 9705/sub-volume VII)
Part IVB Ssecurity services,

(Doc. 9705/sub-volume VIII)
Part IVC Identifier registration and definitions.

(Doc. 9705/sub-volumes IX)
SECURITY SERVICES
1 INTRODUCTION
Part IV-B of this manual replaces and updates the ICAO Manual of technical provisions for the Aeronautical
Telecommunication Network (ATN) (Doc. 9705; third edition), Sub-Volume VIII.
Structure of this document:
Chapter 1: INTRODUCTION contains introductory material to the remainder of this

part of the manual;
Chapter 2: ATN GENERIC SECURITY SERVICES presents the general ATN security
concept in terms of generic security services to be provided in the ATN.
Chapter 3: ATN SECURITY FRAMEWORK contains the ATN security framework. It

specifies the ATN information security framework, which includes:
 framework standards,
 the framework for public key infrastructure,
 the framework for provision of security services in ATN systems,
 the framework for provision of security services within the Upper Layer Communication
Service,
 the framework for provision of security services within the Context Management
application,
 the framework for provision of security services within other ATN applications,
 the framework for provision of security services within SM Managers,
 the framework for provision of security services within ATN Directory Servers,
 the framework for provision of security services for auditing of ATN systems,
 the framework for provision of security services for system management of ATN
systems, and
 backward compatibility.
Chapter 3 also identifies the ATN physical security framework.
Chapter 4: ATN PUBLIC KEY INFRASTRUCTURE contains the ATN Public

Key Infrastructure (PKI). It specifies general requirements for certificate policy and certificate
practice statements, ATN PKI certificate format, ATN PKI certificate revocation list (CRL)
format, and ATN PKI certificate and CRL validation.
Chapter 5: ATN CRYPTOGRAPHIC INFRASTRUCTURE contains the ATN

cryptographic infrastructure. It contains terms and notational conventions and specifies the ATN
cryptographic setting, the ATN key agreement scheme, the ATN digital signature scheme, the
ATN keyed message authentication code scheme, and ATN auxiliary cryptographic functions.
Chapter 6: ATN SYSTEM SECURITY OBJECT contains the ATN System

Security Object. It specifies a set of abstract services for the generation and verification of
security items.
Chapter 7: ATN SECURITY ASN.1 MODULE contains the ASN.1 module for
ATN security.
1.1 Overview
1.1.1 This part of Doc 9880 specifies the ATN security services which are intended to support operational
requirements for the secure exchange of ATS information via the ATN and for protection of ATN resources from
unauthorized access. The ATN security services will accommodate mobile as well as fixed users of the network.
1.1.2 The ATN security services are used to provide assurance that the originator of a message delivered via
the ATN can be unambiguously authenticated by the receiving entity and that appropriate control is applied when
ATN resources are accessed.
1.1.3 Security services in general support but do not guarantee protection from security violations. In
particular, cryptanalytic advances and local implementation issues may affect the overall level of protection.
2 ATN GENERIC SECURITY SERVICES
Access control services shall be provided to prevent the unauthorized use of ATN resources.
Authentication services shall be provided to ensure the identity of participating entities is as claimed.
The ATN security strategy employs asymmetric and symmetric cryptographic mechanisms (Chapter 5) to
provide strong authentication services.
Data integrity services shall be provided to ensure that ATN data is not altered or destroyed in an unauthorized
manner.
Although no requirements exist herein for confidentiality services, i.e., for encryption of ATS application data,
the ATN information security services consists of a set of security related functions and a cryptographic setting
that may be used by States and organizations in support of applications which require confidentiality but are not
subject to ICAO standardisation.
3 ATN SECURITY FRAMEWORK
The ATN information security framework is based on ISO/IEC 7498-2, which defines basic terms and concepts
used in specifying ATN security.
3.1 Information Security
3.1.1 Framework Standards
3.1.1.1 The ATN information security framework is based on:
a) ISO/IEC 10181-1: Information Technology - Security Frameworks in Open Systems - Frameworks

Overview.
b) ISO/IEC 10181-2: Information Technology - Security Frameworks in Open Systems - Authentication

Framework.
c) ISO/IEC 10181-3: Information Technology - Security Frameworks in Open Systems - Access Control
Framework.
d) ISO/IEC 10181-6: Information Technology - Security Frameworks in Open Systems - Integrity

Framework.
3.1.1.2 The ATN upper layer communications services shall provide secured dialogues for ATN security services
based on ISO/IEC 11586-1.
3.1.1.2.1 The ATN upper layer communications services are defined in Doc 9880 Part III.
3.1.1.3 Secured exchanges associated with the ATSMHS application shall provide secured messaging based on
ISO/IEC 10021.
3.1.1.3.1 The ATSMHS application is defined in Doc 9880 Part IIB.
3.1.1.4 The ATN internet communication service shall provide secured exchanges of routing information among
Boundary Intermediate Systems based on provisions for authentication in ISO/IEC 10747.
3.1.1.4.1 The ATN internet communication service is defined in Doc 9880 Part III.
3.1.2 Framework for Public Key Infrastructure
3.1.2.1 The ATN information security framework shall provide a Public Key Infrastructure for key management
and distribution based on ISO/IEC 9594-8 and ITU-T Recommendation X.509.
3.1.2.1.1 ITU-T Recommendation X.509 and ISO/IEC 9594 contain identical text and are hereafter simply
referred to by the term X.509.
3.1.2.2 Each State participating in the ATN security scheme shall designate a single Certificate Authority (CA)
that issues certificates and certificate revocation lists (CRLs).
3.1.2.2.1 The generation and control of public keys requires management, and for this purpose X.509
describes the notion of a 'trusted' authority. Such trusted authorities can be either associated with the user's
organization or a third party. A Certificate Authority serves as such a trusted third party for the generation of
security certificates that contain the user's public key. (The term "Certificate Authority" is used rather than the
X.509 term "Certification Authority" due to the interpretation of "certification" commonly used throughout the
aviation community.)
3.1.2.2.2 The state's certificate authority could be operated by the State or by a commercial CA on behalf of
that State. A given CA may be the designated CA for multiple States.
3.1.2.3 State CAs shall have a non-transitive peer relationship among one another, rather than a hierarchical
relationship.
3.1.2.3.1 The State designated CAs are the highest level of CA, i.e., there is no root CA for the ATN public
key infrastructure.
3.1.2.3.2 The relationship among such CAs is expected to be established and maintained through bilateral
and/or multilateral agreements, which includes, for example, provision for cross-certification.
3.1.2.4 The State's designated certificate authority shall issue certificates and CRLs to users within the State's
domain, to Aircraft Operating Entities, other CAs within the State's domain, and to the designated CAs of other
States.
3.1.2.4.1 ATN users within the State's domain include airborne and ground ATN applications and ATN
routers, i.e., applications processes within end systems and network entities within intermediate systems.
3.1.2.4.2 Aircraft Operating Entities, if present, issue certificates and CRLs to airborne ATN applications
and ATN routers. Each Aircraft Operating Entity may in turn designate a CA that issues certificates and CRLs.
3.1.2.4.3 Other CAs within the State's domain include service providers.
3.1.2.5 Each State shall establish a distribution service that provides distribution of certificates and CRLs to
ATN ground users within the State's domain.
3.1.2.5.1 Relevant certificate data may be cached on a local basis.
3.1.2.6 CAs shall issue short-lived certificates for relying entities which do not have access to the distribution
service.
3.1.2.6.1 Since aircraft do not have access to a distribution service ground certificates provided to them will
be short-lived.
3.1.2.7 If a directory service is used for certificate and CRL distribution, the service shall conform to the ATN
directory service as specified in Doc 9880 Part IV-A.
3.1.2.7.1 A generic distribution service is identified rather than a specific mechanism so as not to constrain
States or their users and since the service needs of individual States will vary; however, it is generally
recommended that the ATN directory service be used for certificate and CRL distribution.
3.1.2.7.2 State established distribution services are expected to exchange certificates and CRLs with other
State distribution services.
3.1.2.7.3 The relationship among State established distribution services is expected to be established and
maintained through bilateral and/or multilateral agreement.
3.1.2.8 CAs shall generate their own key pairs consisting of a public key and a private key.
3.1.2.9 A user, a user's CA, or a trusted third party designated by the user's CA shall generate user key pairs
consisting of a public key and a private key.
3.1.2.10 The private key shall be safeguarded against unauthorized disclosure or use.
3.1.2.10.1 X.509 states that, "it is vital to the overall security that all private keys remain known only to the
user to whom they belong." If a private key is generated by a CA or a designated third party, X.509 requires the
third party to release the private key to the user in a physically secure manner and then actively destroy all
information relating to the creation of the key pair plus the keys themselves.
3.1.2.11 Key pairs and the corresponding certificates for airborne users should be associated with a given
airframe.
3.1.2.11.1 Key pairs and certificates are associated with the airframe, and not, for example with a pilot or a
particular flight identifier.
3.1.2.12 Key pairs and certificates for airborne users shall be valid for at least 28 days.
3.1.2.12.1 It is expected that key pairs and certificates for airbourne users will be valid for considerably
longer than 28 days - i.e. a year or more. The intent is to ensure that under normal circumstances - i.e. when no
key compromise occurs - security information not be required to be updated more frequently than normal
avionics update cycles.
3.1.2.13 A unique key pair and the corresponding certificate for airborne users shall be shared among all
ATS applications on a given airframe.
3.1.2.13.1 All ATS applications share the CM key pair and corresponding certificate, i.e., the key pair and
certificate assigned to the CM application.
3.1.2.14 <<Requirement deleted>>
3.1.2.15 A key pair and corresponding certificate shall be established for each ATN ground application.
3.1.2.15.1 On a local basis all instances of applications of the same type (e.g. CPDLC, ADS-C, etc,) may
share the same key pair. In this context, these applications form a CM Domain for key-usage.
3.1.3 Framework for Provision of Security Services within ATN Systems
If an ATN Intermediate System or End System supports ATN security services, it will support the general
requirements of this section.
3.1.3.1 Intermediate Systems
3.1.3.1.1 ATN Air-Ground and Ground Boundary Intermediate Systems (BISs) shall support the ATN Key
Agreement Scheme (AKAS) and the ATN Keyed Message Authentication Code Scheme (AMACS).
3.1.3.1.2 <<Requirement deleted>>
3.1.3.1.3 ATN Air-Ground BISs and Ground BISs shall support mutual entity authentication with peer
Ground or Air-Ground BISs.
3.1.3.1.4 ATN Air-Ground BISs and Ground BISs shall support data origin authentication of routing
information exchanges.
3.1.3.1.5 ATN Air-Ground BISs and Ground BISs shall support protection of routing information exchanges
from replay and manipulation.
3.1.3.2 End Systems
The ATN security model defines security services that may be used by applications residing in ATN end systems.
Such end systems would support the security provisions of the upper layer communication services defined in
Sub-Volume IV for air-ground applications defined in Sub-Volume II or for end systems supporting the ground-
ground applications and associated communication services defined in Sub-Volume III. The ATN security
services may also be used for the management of end systems as defined in Sub-Volume VI.
3.1.3.2.1 ATN end systems shall support the ATN Key Agreement Scheme (AKAS), the ATN Digital
Signature Scheme (ADSS), and the ATN Keyed Message Authentication Code Scheme (AMACS).
3.1.3.2.2 ATN end systems shall support mutual entity authentication with peer end systems which support
ATN security services.
3.1.3.2.3 ATN end systems shall support data origin authentication of application information exchanges.
3.1.3.2.4 ATN end systems shall support protection of application information exchanges from replay and
manipulation attacks.
3.1.4 Framework for Provision of Security Services within the Upper Layer Communications Service (ULCS)
If the ULCS (see Doc 9880 Part III) in an ATN End System supports ATN security services, it will support the
3.1.4.1 The ULCS shall support the request of the dialogue service security types as defined in Table 9-1 by the
dialogue service user.
Table 9-1. Dialogue Service Security Types
Dialogue Dialogue Abstract Value Description
Security Type
1 No Security No authentication is provided for application user
data exchanges over the dialogue.
2 Secured Dialogue Supporting Key Exchange of key agreement data is provided in
Management dialogue establishment. Authentication is provided for
dialogue establishment and for all application user
data exchanges by user applications over the dialogue
when the dialogue is maintained.
3 Secured Dialogue Authentication is provided for dialogue establishment
and for all application user data exchanges by user
applications over the dialogue.
4 Reserved Reserved for future use.
3.1.4.1.1 Dialogue security type 2 is used in initial dialogue establishment between CM applications, i.e.,
during CM Logon or Contact. Subsequent dialogues by ATS applications may then invoke dialogue security
type 3, in which case the ULCS will use the key agreement data exchanged during the initial dialogue..
3.1.4.1.2 Security type 4 is reserved for future use to support confidentiality along with authentication.
3.1.4.2 The initiating ULCS shall have prior knowledge of the private keys of the calling application and the
information necessary to validate the certificate path to the responding application using the SSO abstract
service as specified in section 6.3.6.
3.1.4.3 The responding ULCS shall have prior knowledge of the private keys of the responding application and
the information necessary to validate the certificate path to the calling application using the SSO abstract service
as specified in section 6.3.6.
3.1.4.4 The ground ULCS shall support the retrieval of certificates and CRLs from a certificate distribution
service using the SSO abstract service as specified in 6.3.7 and validation of the certificate path of retrieved
certificates using the SSO abstract service as specified in section 6.3.6.
3.1.4.5 The ULCS shall support validation of certificate paths and CRLs.
3.1.4.6 The initiating ULCS shall support generation of digital signatures using the SSO abstract service as
specified in section 6.3.1.
3.1.4.7 The responding ULCS shall support verification of digital signatures using the SSO abstract services as
3.1.4.8 The initiating ULCS shall support generation and verification of tags using the SSO abstract services as
specified in sections 6.3.3 and 6.3.4.
3.1.4.9 The responding ULCS shall support generation and verification of tags using the SSO abstract services
as specified in section 6.3.3 and 6.3.4.
3.1.4.10 The ULCS shall support derivation of a shared session key using the SSO abstract service as
3.1.5 Framework for Provision of Security Services within the Context Management (CM) application
If the CM application (see Part I-A) supports the ATN security services, it will support the requirements of this
section.
3.1.5.1 The airborne CM application shall have the ability to request the use of a secured dialogue with the
abstract value "secured dialogue supporting key management" when initiating a CM-logon request.
3.1.5.2 The ground CM application shall have the ability to request the use of a secured dialogue with the
abstract value "secured dialogue supporting key management" when initiating a CM-update request.
3.1.5.3 The CM application shall request a dialogue with the type of security services appropriate to the
application in the given operational domain.
3.1.5.4 The ground CM application shall support the storage, within the ground system's data base, of the
shared key derivation parameter (X) for the aircraft along with the other information contained in the CM logon
request.
3.1.5.5 The ground CM application shall support the authenticated distribution to ground-based ATS
applications of the shared key derivation parameter (X) for the aircraft.
3.1.5.5.1 How authentication is accomplished is a local matter.
3.1.5.5.2 The ground CM may additionally support the authenticated distribution of the aircraft's key
agreement public key, e.g., for applications which do not have access to the certificate distribution service.
3.1.5.6 The airborne CM application shall support the distribution to airborne-based ATS applications of the
shared key derivation parameter (X), ground application public key agreement keys, and the aircraft's private key
agreement key.
3.1.6 Framework for Provision of Security Services within Other ATN Applications
3.1.6.1 Air-Ground Applications
3.1.6.1.1 If air-ground applications (see Sub-Volume II) support ATN security services, they will support the
3.1.6.1.2 The CPDLC, ADS-C and FIS applications shall request a dialogue with the type of security
services appropriate to the application in the given operational domain.
3.1.6.1.3 The CPDLC, ADS-C, and FIS applications shall support access and retrieval of the key derivation
parameter (X) for an aircraft from a ground CM application entity serving the associated administrative domain
(e.g., State, organization, etc.).
3.1.6.2 Ground-Ground Applications
If a ground-ground application (see Part II) supports ATN security services, it will support the requirements of
this section.
3.1.6.2.1 Ground-ground applications other than ATSMHS shall authenticate ground-ground message
exchanges with the type of security services appropriate to the given operational domain.
3.1.6.2.1.1 Ground-ground applications perform authentication using a purely asymmetrical solution, i.e., using
signatures only.
3.1.6.2.2 ATSMHS Application
3.1.6.2.2.1 ATSMHS applications shall support the provision of the end-to-end security services of content
integrity, origin authentication, and message sequence integrity using MHS Security Class S0 with the ATN
Digital Signature Scheme as specified in section 5.4.
3.1.6.2.2.2 ATSMHS applications shall support validation of the originator's certificate path as specified in
section 4.5.1.
3.1.6.2.2.3 The originator's certificate path may either be included in the message by the originator or may be
retrieved by the recipient using the ATN distribution service.
3.1.6.2.2.4 ATSMHS applications shall identify the use of the ATN Digital Signature Scheme using the same
identifier used for ATN certificates as specified in section 4.3.
3.1.7 Framework for Provision of Security Services within ATN System Management (SM) Managers
<<Section deleted>>
3.1.8 Framework for Provision of Security Services within ATN Directory Servers
3.1.8.1 ATN directory applications shall support an access control scheme appropriate to the given operational
domain in order to limit access to only authorised ATN users.
3.1.8.2 ATN directory applications shall support authentication appropriate to the given operational domain.
3.1.8.2.1 Authentication for directory applications applies to the access control scheme and to information
exchanged between directory servers.
3.1.8.2.2 In accordance with X.500, "simple authentication" based on password procedures or "strong
authentication" using cryptographic techniques may be applied.
3.1.8.3 If strong authentication is used, then directory applications shall generate their digital signature
component as specified in section 5.5.2.1 - the ATN Signature Generation Primitive (ASP).
3.1.8.4 If strong authentication is used, then directory applications shall verify their digital signature
components as specified in 5.5.2.2 - the ATN Signature Verification Primitive (ASP).
3.1.8.5 If strong authentication is used, then directory applications shall support validation of the originator's
certificate path as specified in 4.5.1.
3.1.8.6 If strong authentication is used, then directory applications shall identify the use of the ATN Digital
Signature scheme using the same identifier used for the ATN Certificates as specified in section 4.3.
3.1.9 Framework for Provision of Security Services for Auditing of ATN Systems
3.1.9.1 ATN systems should be capable of detecting and recording authentication failures and unauthorized
access attempts.
3.1.9.2 ATN systems should be able to generate an audit record of authentication failures and unauthorized
access attempts.
3.1.9.3 ATN systems should provide the Security Audit Trail Function in accordance with ISO/IEC 10164-8.
3.1.10 Framework for Provision of Security Services for Security Management of ATN Systems
<<Section deleted>>
3.1.11 Backward compatibility
3.1.11.1In order to accommodate the evolution of the ATN, ATN end systems and intermediate systems shall be
able to support backward compatibility with prior versions of peer systems that either do not support ATN
security services or support prior versions of the ATN security services.
3.1.11.2The later generation versions of the ATN security services will thus need to be able to revert to a mode
compatible with prior version(s). This can be accomplished by having the later generation implementation
recognize either security provisions do not exist in the peer system or that an earlier version of the security
provisions are supported. This is generally enabled through the use of version numbers and/or indicators that
security options are not supported.
3.1.11.3Backward compatibility of systems providing security with systems which do not provide security
weakens and in some cases eliminates the protection of the system with security.
3.2 ATN Physical Security Framework
3.2.1 Access to ATN end systems, intermediate system and critical subnetwork components/ subsystems shall
be controlled consistent with the provisions of Annex 17 Security Safeguarding International Civil Aviation
against Acts of Unlawful Interference and Security Manual for Safeguarding Civil Aviation Against Acts of
Unlawful Interference (Doc 8973).
4 ATN PUBLIC KEY INFRASTRUCTURE
This section specifies the requirements for the ATN Public Key Infrastructure (PKI). It specifies required
certificate policy and certificate practice statements, the format and content of certificates and CRLs, and the
requirements for validation of these certificates and CRLs.
4.1 Certificate Policy
4.1.1 CAs shall develop a Certificate Policy that defines the creation, management, and use of public key
certificates that they issue.
4.1.1.1 X.509 defines a certificate policy as a named set of rules that indicates the applicability of a certificate
to a particular community and/or class of application with common security requirements.
4.1.2 The Certificate Policy shall conform to the Internet X.509 Public Key Infrastructure Certificate Policy
and Certification Practices Framework, IETF PKIX RFC3647.
4.2 Certificate Practice Statement
4.2.1 CAs shall publish a Certificate Practice Statement that describes the expected use of public key
certificates that they issue.
4.2.1.1 Practices may include such items as initialization/certification of entities and their key pairs, certificate
revocation, key backup and recovery, CA key rollover, cross-certification, etc.
4.2.2 The Certificate Practice Statement shall conform to the Internet X.509 Public Key Infrastructure
Certificate Policy and Certification Practices Framework, IETF PKIX RFC3647.
4.2.2.1 The Certificate Policy and Certificate Practice Statements of a given State could be used by other States
in establishing their trust relationships and operating policies such as cross certification.
4.3 ATN PKI Certificate Format
This certificate profile used for ATN PKI certificates is a profile of RFC 5280, Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List (CRL) Profile. RFC 5280 is in turn a profile of the
X.509 v3 certificate. This certificate profile places constraints on certain X.509 fields when used in the ATN to
enable the effective operation of the ATN, and these are identified below.
The ATN PKI certificate profile specified in this section is mandatory only for end entity certificates, i.e.,
certificates issued by one entity to another different entity.
4.3.1 Uncompressed Certificates
4.3.1.1 Certificate and Certificate Extensions Profile of Uncompressed Certificates
4.3.1.1.1 Uncompressed ATN certificates shall be in accordance with the Certificate and Certificate
Extensions Profile specified in RFC 5280
4.3.1.1.2 The Air Transport Association (ATA) Digital Security Working Group (DSWG) has developed a
Certificate Policy (ATA Specification 42) for use in the aviation community. ATA Specification 42 provides
additional implementation guidance on the use of PKI in civil aviation to include guidance on trust anchor
management and the use of an Aviation Bridge CA.
4.3.1.2 ATN Signatures on Uncompressed Certificates
4.3.1.2.1 ATN CAs sign certificates using the ATN Signature Primitive (see 5.5.2.1) which shall be
indicated using the syntax and object identifiers specified in RFC 5480 for the algorithm ecdsa-with-SHA256.
4.3.1.2.1.1 The applicable RFC 5480 ASN.1 Syntax elements are:
ECDSA-Sig-Value
ECParameters
ECPoint
4.3.1.2.1.2 The applicable RFC 5480 object identifiers are::
ecdsa-with-SHA256 {1 2 840 10045 4 3 2 }

id-ecPublicKey {1 2 840 10045 2 1}
sect233r1 {1 3 132 0 27}
4.3.1.3 To Be Signed Uncompressed Certificates
4.3.1.3.1 subject field
4.3.1.3.1.1 If the subject is a CA or an AMHS entity with a distinguished name (rather than an X.400 name),
the subject field shall contain the distinguished name of the subject in accordance with the directory schema
specified in Part IV-A.
4.3.1.3.1.2 If the subject is not a CA or an AMHS entity with a distinguished name, the subject field shall be an
empty sequence.
4.3.1.3.2 subjectPublicKeyInfo field
The syntax for the subjectPublicKeyInfo field shall be as specified in RFC 5480.
4.3.1.3.3 The Extensions field in all ATN certificates shall contain the authority key identifier extension, the key
usage extension, the subject alternative name extension, and the issuer alternative name extension.
4.3.1.3.3.1 When the subject of the certificate is a CA, the Extensions field shall in addition contain the basic
constraints extension and the subject key identifier extension.
4.3.1.3.3.2 Authority key identifier extension
4.3.1.3.3.2.1 The value of keyIdentifier shall be composed of a four bit type field with the value 0100 followed
by the least significant 60 bits of the SHA-256 hash of the value of the subjectPublicKey of the certificate issuer.
4.3.1.3.3.3 Key usage extension
4.3.1.3.3.3.1 KeyUsage in ATN certificates shall be asserted in accordance with RFC 5480.
4.3.1.3.3.4 Subject alternative name extension
4.3.1.3.3.4.1 If the subject is an ATN ATS end system other than an AMHS end system, the subject alternative
name extension shall contain the entity's AP-title.
4.3.1.3.3.4.2 If the subject is an AMHS entity, the subject alternative name extension shall contain the AMHS
entity's distinguished name or X.400 address.
AMHS entities are identified by X.400 addresses and optionally in addition distinguished names. X.400 names
are placed in the subject alternative name extension, and, if present, distinguished names are placed in the subject
field. If an AMHS entity has both a distinguished name and an X.400 address, both the subject field and the
subject alternative name extension are populated.
4.3.1.3.3.4.3 If the subject is an intermediate system, the subject alternative name extension shall contain the
entity's Network Entity Title (NET) defined as follows:
NET ::= OCTET STRING (SIZE (20))
4.3.1.3.3.4.4 When the subject alternative name extension contains an entity's AP-title, this shall be placed in
the extension as the value encoded as a registeredID.
4.3.1.3.3.4.5 When the subject alternative name extension contains an AMHS X.400 distinguished name, this
shall be encoded as the value of directoryName.
4.3.1.3.3.4.6 When the subject alternative name extension contains an AMHS X.400 address, this shall be
encoded as the value of x400Address.
4.3.1.3.3.4.7 When the subject alternative name extension contains an entity's NET, this shall be encoded as
the value of ipAddress.
4.3.1.3.3.5 Issuer alternative name extension
4.3.1.3.3.5.1 The issuer alternative name extension in ATN certificates shall contain a single alternative name
(which will be issuer's AP-title).
4.3.1.3.3.5.2 The issuing entity's AP-title shall be placed in the extension as the value encoded as a
registeredID.
4.3.1.3.3.6 Subject key identifier extension
4.3.1.3.3.6.1 When it is present, the value of SubjectKeyIdentifier shall be composed of a four bit type field
with the value 0100 followed by the least significant 60 bits of the SHA-256 hash of the value of the
subjectPublicKey of the certificate subject.
4.3.1 Encoding of Compressed Certificates
ATN Air/Ground certificates are sent in a compressed form using PER encoding The receiving entity recovers
the original (CA generated) certificate by re-encoding the certificate using DER encoding. After recovering the
original certificate from the compressed certificate, the receiving entity validates the original certificate.
4.3.1.1 ATN certificates transmitted over air/ground subnetworks shall be encoded using the basic aligned
variant of the Packed Encoding Rules (PER) as specified in ISO/IEC 8825-2.
4.4 ATN PKI CRL Format
This CRL profile used for ATN PKI CRLs is a profile of RFC 5280, Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation List (CRL) Profile. RFC 5280 is in turn a profile of the X.509 v2 CRL.
This certificate profile places constraints on certain X.509 fields when used in the ATN to enable the effective
operation of the ATN, and these are identified below.
4.4.1 CRL and CRL Extensions Profile
4.4.1.1 All CRLs in the ATN shall be in accordance with the CRL and CRL Extensions Profile specified in
RFC 5280.
4.4.1.2 Signatures for ATN CRLs shall be as specified for ATN certificates in 4.3.1.2.
4.5 ATN PKI Certificate and CRL Validation
This section specifies how ATN entities validate ATN certificates and CRLs.
4.5.1 Certificate Validation
When an ATN entity validates a certificate, the ATN entity performs the following checks:
4.5.1.1 The ATN entity shall retrieve an authentic copy of the issuing CA's public key.
The issuing CA will be either the designated State CA or a CA within the State's domain.
4.5.1.2 The ATN entity shall check that the certificate is an X.509 certificate with the authority key identifier,
key usage, subject alternative name, and issuer alternative name extensions present.
The certificate should conform to general X.509 and ATN-specific syntax as specified in 4.3.
Validation checks that specified extensions are present even though they are marked non-critical.
4.5.1.3 The ATN entity shall check that the subject alternative name and issuer alternative name extensions each
contain a single name.
4.5.1.4 The ATN entity shall check that the certificate is signed using the ATN Signature Primitive by examining
the signatureAlgorithm and signature fields of the certificate.
4.5.1.5 The ATN entity shall check that the certificate is a version 3 certificate by examining the version field of
the certificate.
4.5.1.6 The ATN entity shall check that the certificate was issued by the appropriate CA by examining the
issuer field and the issuer alternative name extension.
4.5.1.7 The ATN entity shall check that the certificate has not been revoked if a CRL list is available to the
entity, and that it is fresh by examining the validity field.
If a CRL list which is expected to be available to an entity ( in particular, a ground entity), cannot be accessed,
then the certificate is to be treated as revoked. This is to prevent attacks wherein the CRL list is blocked.
4.5.1.8 The ATN entity shall check that the certificate was issued to the appropriate entity by examining the
subject field and the subject alternative name extension.
4.5.1.9 The ATN entity shall check that the certificate contains the appropriate elliptic curve public key
algorithm and parameters by examining the subjectPublicKeyInfo field.
4.5.1.10 The ATN entity shall check that the certificate certifies the appropriate key type by examining
the key usage extension.
4.5.1.11 The ATN entity shall check that the certificate is valid by verifying the signature contained in the
signatureValue field using the issuing CA's public key.
4.5.2 CRL Validation

ATN entities check that certificates issued by an issuing CA to a subject have not been revoked by performing
the following checks:
4.5.2.1 The ATN entity shall retrieve the most recent CRL issued by the issuing CA.
4.5.2.2 The ATN entity shall check that the CRL is an X.509 CRL with the nextUpdate field present, the issuer
alternative name CRL extension present
4.5.2.3 The ATN entity shall check that a single name is in the issuer alternative name extension.
4.5.2.4 The ATN entity shall check that the CRL is signed using the ATN Signature Primitive by examining the
signatureAlgorithm and signature fields of the CRL.
4.5.2.5 The ATN entity shall check that the CRL is a version 2 CRL by examining the version field of the CRL.
4.5.2.6 The ATN entity shall check that the CRL was issued by the appropriate CA by examining the issuer field
and the issuer alternative name extension.
4.5.2.7 The ATN entity shall check that the CRL is fresh by examining the thisUpdate field and the nextUpdate
field.
4.5.2.8 The ATN entity shall check that the subjectissuing CA's certificate is not revoked by checking that the
certificate's serial number does not appear in the list of revoked certificates' serial numbers in the
revokedCertificates field.
4.5.2.9 The ATN entity shall check that the CRL is valid by verifying the signature in the signatureValue field
using the issuing CA's public key.
4.5.3 Additional Certificate Path Validation
In addition to the certificate and CRL validation procedures already described in this section, the following
checks are necessary when validating a certificate path.
4.5.3.1 When validating a certificate path, ATN entities shall check that the certificate path contains at most one
certificate issued by a State CA to another State CA.
Trust among States is not transitive - a certificate issued to State B's CA from State A's CA together with a
certificate to State C's CA from State B's CA does not indicate that State A trusts State C.
5 ATN CRYPTOGRAPHIC INFRASTRUCTURE
This section specifies the ATN cryptographic algorithms which are aligned with other relevant standards to
provide interoperability and to insure that non-developmental implementations will be available to ATN system
developers. The principal standards are: the American National Standards Institute standards, Public Key
Cryptography For The Financial Services Industry: Key Agreement and Key Transport Using Elliptic Curve
Cryptography (ANSI X9.63)and Public Key Cryptography For The Financial Services Industry: The Elliptic
Curve Digital Signature Algorithm (ANSI X9.62); and, the industry standard, Standards for Efficient
Cryptography Group (SECG), Elliptic Curve Cryptography (SEC 1). In addition, the algorithms are aligned
with the International Organization for Standardization standards, Cryptographic techniques based on elliptic
curves - Part II: Signatures, (ISO/IEC 15946-2), and Part 3: Key establishment (ISO/IEC 15946-3). The
specific elliptic curves and associated parameters are from Standards for Efficient Cryptography Group,
Recommended Elliptic Curve Domain Parameters (SEC 2) and the US National Institute of Standards and
Technology, Digital Signature Standard (FIPS 186-2).
5.1 Terms
This section defines terms used throughout section 5.
Base point (G). A selected point of large prime order n on an elliptic curve..
Basis . A representation of the elements of the finite field F2m. In the current ATN security scheme, only
polynomial basis representations are used.
Binary polynomial. A polynomial whose coefficients are in the field F2. When adding, multiplying, or dividing
two binary polynomials, the coefficient arithmetic is performed modulo 2.
Characteristic 2 finite field. A finite field containing 2m elements, where m ≥ 1 is an integer. In the current ATN
security scheme, only characteristic 2 fields containing 2m elements with m prime are used.
Elliptic curve. An elliptic curve over F2m. is a set of points which satisfy a certain equation specified by 2
parameters a and b, which are elements of the field F2m.
Elliptic curve key pair (Q, d). Given particular elliptic curve domain parameters, an elliptic curve key pair
consists of an elliptic curve public key (Q) and the corresponding elliptic curve private key (d).
Elliptic curve private key (d). Given particular elliptic curve domain parameters, an elliptic curve private key,
d, is a statistically unique and unpredictable integer in the interval [1, n-1], where n is the prime order of the base
point G.
Elliptic curve public key (Q). Given particular elliptic curve domain parameters, and an elliptic curve private
key d, the corresponding elliptic curve public key, Q, is the elliptic curve point Q = dG, where G is the base
point.
Elliptic curve domain parameters. Elliptic curve domain parameters are comprised of a field size 2 m, the
reduction polynomial f(x), an indication of the basis used, an optional SEED, two elements a, b in F2m, which
define an elliptic curve E over F2m, a point G=(xG,yG) of prime order in E(F2m) and the order n of G.
Elliptic curve point. If E is an elliptic curve defined over a field F2m, then an elliptic curve point P is either: a
pair of field elements (xp, yp) (where xp, yp  F2m) such that the values x = xp and y = yp satisfy the equation
defining E, or a special point  called the point at infinity.  is the identity element of the elliptic curve group.
Irreducible binary polynomial. A binary polynomial f(x) is irreducible if it does not factor as a product of two
or more binary polynomials, each of degree less than the degree of f(x).
Order of a point. The order of a point P is the smallest positive integer n such that nP =  (the point at
infinity).
Point Compression. Point compression allows a point P = (xp,, yp) to be represented compactly using xp and a
single additional bit yp derived from xp and yp.
Reduction polynomial. A reduction polynomial is the irreducible binary polynomial f(x) of degree m that is used
to determine a polynomial basis representation of F2m.
Scalar multiplication. If k is a positive integer, then kP denotes the point obtained by adding together k copies
of the point P. The process of computing kP from P and k is called scalar multiplication.
5.2 Notational Conventions
This section defines notation for objects and operations used throughout section 5.
|| denotes concatenation. Thus X || Y denotes the string which results when the string Y is
appended to the string X.
x denotes the ceiling of x, i.e., the smallest integer ≥ x
 denotes a coefficient of the defining elliptic curve equation associated with a set of
elliptic curve domain parameters
AHASH(Data) denotes the established ATN hash function which computes the hash value
corresponding to Data.
AKDF(Z, denotes the ATN key derivation function which derives keying data of length keydatalen
keydatalen, using the key derivation function based on AHASH from the shared secret value Z and
SharedInfo) other shared data SharedInfo.
AMACP(MacKey, denotes the ATN tagging primitive which computes a MAC of length mactaglen on the
MacData, data MacData using HMAC with AHASH under the MAC session key MacKey
mactaglen)
AMACVP(MacKey; denotes the ATN MAC verification primitive which verifies MacTag of length
MacData, MacTag, mactaglen on the data MacData under the session key MacKey using the ATN tagging
mactaglen) primitive AMACP.
ASP(dsig, SignData) denotes the ATN signature generation primitive which computes a signature (r,s) on the
data SignData using ECDSA under the elliptic curve signing private key dsig.
ASVDP(ds,U, Qs,V) denotes the ATN secret value derivation primitive which derives a "Diffie-Hellman"
shared secret value from the private key ds,U, and the public key Qs,V.
AVP(SignData,(r',s'), denotes the ATN signature verification primitive which verifies the signature (r',s') on
Qsig) the data SignData was generated using ECDSA under the elliptic curve signing private
key corresponding to the public key Qsig.
b denotes a coefficient of the defining elliptic curve equation associated with a set of
elliptic curve domain parameters.
CA denotes the identity of a Certificate Authority.
d denotes an elliptic curve private key.
f(x) denotes the reduction polynomial associated with a set of elliptic curve domain
parameters.
G denotes an elliptic curve base point associated with a set of elliptic curve domain
parameters.
m denotes the extension degree of the binary field associated with a set of elliptic curve
domain parameters.
n denotes the order of the base point associated with a set of elliptic curve domain
parameters.
 denotes the point at infinity on an elliptic curve. The additive identity of the elliptic
curve group.
Q denotes an elliptic curve public key.
Rand denotes a random challenge.
T denotes a sextuple of elliptic curve domain parameters, (m,f(x),a,b,G,n).
Time denotes a time field.
U,V denotes an ATN application or an ATN router. ATN applications are identified by an
Application Process Title (AP-Title). ATN routers are identified by a Network Entity
Title (NET).
X denotes a shared public value. X is used as a key derivation parameter during the
calculation of session keys for applications
z or Z denotes a shared secret value. z denotes a shared secret field element and Z is a shared
secret octet string.
Subscript notation is used to indicate the association of a value to a particular entity, or to indicate the use of a
value. For example:
ds,U denotes the static elliptic curve key agreement private key owned by the entity U.
dsig,U denotes the elliptic curve signing private key owned by the entity U.
GATN denotes the elliptic curve base point associated with the ATN elliptic curve domain
parameters TATN.
Qs,U denotes the static elliptic curve key agreement public key owned by the entity U. Since
the entity U uses the ATN elliptic curve domain parameters TATN for key agreement, Qs,U
= ds,U GATN
Qsig,U denotes the elliptic curve signing public key owned by the entity U. Since the entity U
uses the ATN elliptic curve domain parameters, TATN, Qsig,U = dsig,U tATN.
RandV denotes a random challenge chosen by the entity V.
TATN denotes the standard strength elliptic curve domain parameters used by ATN entities and
supporting CAs for key agreement and signing.
TimeV denotes a time field generated by the entity V.

5.3 ATN Cryptographic Setting
The ATN cryptographic schemes are based on arithmetic operations on an elliptic curve over a finite field. This
section defines the finite fields, elliptic curves, elliptic curve domain parameters, and constraints on the use of
random values used by the ATN cryptographic schemes.
5.3.1 ATN finite field F2m
5.3.1.1 ATN applications, ATN routers, and supporting CAs shall use a characteristic 2 finite field (F2m)
containing 2m elements, where m is a domain parameter, as the underlying finite field for ATN cryptographic
algorithms.
5.3.1.2 The elements of F2m shall be represented by the set of binary polynomials of degree m-1, with operations
performed using the reduction polynomial f(x) of degree m, where f(x) is a domain parameter.
5.3.2 ATN elliptic curves
5.3.2.1 ATN applications, ATN routers, and supporting CAs shall use elliptic curves, E(F2m), defined by the
equation E: y2+xy=x3+ax2+b over F2m, where a, and b are domain parameters.
5.3.3 ATN elliptic curve point representation
5.3.3.1 ATN elliptic curve points shall be use the full (uncompressed) representation.
5.3.3.2 Point compression is mandated for bandwidth efficiency and to facilitate use of non-developmental CA
products.
5.3.4 ATN elliptic curve domain parameters
5.3.4.1 ATN applications, network entities, and supporting CAs shall use the domain parameters TATN for the
random curve over a 233-bit binary curve as defined in SEC 2 (sect233r1).
5.3.4.2 The domain parameters TATN as defined in SEC 2 for the 233-bit binary curve shall not include the co-
factor h.
5.3.4.3 The domain parameters TATN as defined in SEC 2 for the 233-bit binary curve sect233r1 shall use the
base point G in its uncompressed form.
5.3.5 ATN random values
5.3.5.1 ATN random or pseudo-random values shall be generated in a cryptographically secure manner.
5.3.5.2 Inadequate random value generation is one of the most common causes of cryptographic failure.
Implementations of ATN security must therefore use caution in random and pseudo-random number generation.
5.3.5.3 See ANSI X9.62 for example generation of random and pseudo random values.
5.4 ATN Key Agreement Scheme (AKAS)
ATN applications and ATN routers derive keying data using the key agreement scheme given in this section.
5.4.1 AKAS Prerequisites
5.4.1.1 Each ATN application or ATN router shall have a copy of the ATN elliptic curve domain paramters,
TATN , specified in section 5.3.4.
5.4.1.2 Each ATN application or ATN router performing key agreement shall be bound to a static key pair
associated to the ATN elliptic curve domain parameters.
5.4.1.3 Each ATN application or ATN router shall have a copy of the peer's public key.
5.4.2 ATN applications and ATN routers will have an authentic copy of the peer application’s public key.
AKAS Operation
An ATN application, U, communicating over an air/ground subnetwork with a peer application, V, agrees on
keying data by: 1) deriving a shared secret value (Z) using the primitive ASVDP, 2) deriving a shared key
derivation parameter(X) using AKDF, and 3) deriving keying data (KeyData) using AKDF.
An ATN router, U, communicating with a peer ATN router, V, agrees on keying data by: 1) deriving a shared
secret value (Z) using the primitive ASVDP and 2) deriving keying data (KeyData) using AKDF.
5.4.2.1 Derive Shared Secret Value
5.4.2.1.1 ATN applications and routers shall invoke the ATN Secret Value Derivation primitive as specified
in 5.4.3 to derive a shared secret value Z from the private key ds,U and the public key Qs,V under the parameters
TATN.
5.4.2.2 Derive Shared Key Derivation Parameter
ATN applications communicating over air/ground subnetworks derive a shared key derivation parameter (X)
using the technique given in this section.
5.4.2.2.1 An ATN application communicating over an air/ground subnetwork shall form the shared key
derivation parameter X as output of AHASH (5.7.2) applied to the concatenation of a signature S, and a random
variable Rand.
5.4.2.3 Derive Keying Data
5.4.2.3.1 ATN applications communicating over an air-ground subnetwork shall form SharedInfo as the
concatenation of a constant value 01 16,the shared key derivation parameter X, the AP-Title of the airborne
application, and the AP-Title of the ground application.
5.4.2.3.2 ATN routers shall form SharedInfo as the concatenation of the initiating ATN router's random
variable RandU and the responding ATN router's random variable RandV.
5.4.2.3.3 The ATN application or ATN router shall invoke the ATN Key Derivation function (AKDF)
specified in 5.7.1 with Z, SharedInfo, and keydatalen = 32 octets to derive a shared key.
5.4.3 ATN Secret Value Derivation Primitive (ASVDP)
ATN applications and ATN routers derive shared secret values for key agreement using the technique given in
this section. ASVDP follows the Elliptic Curve Diffie-Hellman primitive (ECDH) as defined in ANSI X9.63 and
the SECG Elliptic Curve Cryptography (SEC 1) standard.
5.4.3.1 To calculate a shared secret value, the ASVDP shall:
a) accept as input a private key ds,U owned by U,
b) accept as input a public key Qs,V owned by V,
c) compute the point P as the elliptic curve scalar product ds,U Qs,V,
d) If the point P is equal to the point at infinity of the curve group, i.e., P= , output
'invalid' and stop.
e) assign the value xP to z, i.e., set z= xP, where xP is the x-coordinate of P,
f) convert zF2m to an octet string Z, and
g) output Z.
There are potentially security issues if an entity combines their private key using the ASVDP mechanism with a
supposed public key Qs,V which is in fact not a point on the elliptic curve, or which is a point on the elliptic curve
which does not have order n. There are various mechanisms that mitigate against this concern. For example,
implementations may check that the supposed public key satisfies both that the arithmetic properties of a point
on the associated elliptic curve and that nQ= . How an implementation chooses to handle this issue is considered
a local matter.
5.5 ATN Digital Signature Scheme (ADSS)
ATN applications, ATN routers, and CAs sign and verify data using the signature scheme given in this section.
ADSS follows the Elliptic Curve Digital Signature Algorithm (ECDSA) as defined in ANSI X9.62 and the
SECG Elliptic Curve Cryptography (SEC 1) standard.
5.5.1 ADSS Prerequisites
5.5.1.1 Each ATN application, ATN router, or CA shall have a copy of the appropriate ATN elliptic curve
domain parameters, TATN specified in 5.3.4.
5.5.1.2 Each signing ATN application, ATN router, or CA shall be bound to a static key pair associated to the
ATN elliptic curve domain parameters.
5.5.1.3 Each verifying ATN application, ATN router, or CA shall have an authentic copy of the signer's public
key.
5.5.2 ADSS Operation
5.5.2.1 ATN Signature Generation Primitive (ASP)
An ATN application, ATN router, or CA uses the primitive ASP to sign data.
5.5.2.1.1 To sign data, the ASP shall:
a) accept as input an octet string SignData of data to be signed,
b) accept as input an elliptic curve signing private key dsig,U owned by the signing entity,
U, which corresponds to the domain parameters, TATN ,
c) compute the integers r and s which comprise the signature on SignData as follows:
1) compute the hash value H = AHASH(SignData) using the ATN hash function specified in 5.7.2,
2) convert H to an integer e,
3) select a random integer k in the interval [1,n-1],
4) compute the elliptic curve point (x1, y1) = kG,
5) convert the field element x1 to an integer x1,
6) set r = x1mod n,
7) If r = 0, continue at step 3),
8) compute s = k-1(e + dsig,Ur) mod n,
9) If s = 0, continue at step 3), otherwise

10) output the pair of integers r and s.
5.5.2.2 ATN Signature Verification Primitive (AVP)
An ATN application, ATN router, or CA uses the primitive AVP to verify a purported signature on data.
5.5.2.2.1 To verify a signature, the AVP shall:
a) accept as input the bit string SignData',
b) accept as input a pair of integers r' and s' which are the purported signature of
SignData',
c) accept as input an EC signing public key Qsig,U owned by the signing entity, U, which
corresponds to the domain parameters, TATN ,
d) verify the purported signature using the verification transformation as follows:
1) compute the hash value H' = AHASH(SignData') using the ATN hash function
specified in Section 5.7.2,
2) convert H' to an integer e',
3) If r' is not an integer in the interval [1, n-1], then reject the signature,
4) If s' is not an integer in the interval [1, n-1], then reject the signature,
5) compute c = (s')-1 mod n,
6) compute u1 = e'c mod n and u2 = r'c mod n,
7) compute the elliptic curve point (x1, y1) = u1G + u2 Qsig,U ,
8) If u1G + u2 Qsig,U is the point at infinity, then reject the signature,
9) convert the field element x1 to an integer x1',
10) compute v = x1' mod n, and
11) If r' = v, then the output 'valid' to indicate a valid signature; otherwise, output
'invalid'.
5.6 ATN Keyed Message Authentication Code Scheme (AMACS)
ATN applications and ATN routers perform message authentication using the tagging transformation and the tag
checking transformation given in this section. AMACS follows the Hashed Message Authentication Code HMAC
scheme as specified in RFC 2104
5.6.1 AMACS Prerequisites
5.6.1.1 ATN applications shall use the AMACS with 32-bit tags, i.e., HMAC-SHA-256-32.
5.6.1.2 ATN routers shall use the AMACS with 80-bit tags, i.e., HMAC-SHA-256-80.
HMAC is employed using 256-bit keys. 256-bit keys provide assurance that approximately 2 256 operations are
required to achieve universal forgery, i.e., to be able to forge the tag on any message.
For ATN applications, 32-bit tags are employed. 32-bit tags ensure that the chances of simply guessing the tag
on a single message are approximately 2-32. The lifetime of the tag is that of a CM session. For ATN routers, 80-
bit tags are employed. 80-bit tags ensure that the chances of guessing the tag on a single message are
approximately 2-80. Longer tags are used in this environment because the lifetime of the tag in the ground-ground
environment will last as long as the IDRP connection is maintained (continuously in the absence of errors).
5.6.1.3 ATN applications and ATN routers shall establish a 160-bit session key using AKAS with the peer
application or router using AKAS prior to using AMACS.
5.6.2 AMACS Operation
5.6.2.1 ATN Keyed Message Authentication Code Generation Primitive (AMACP)
Data will be tagged using the tagging transformation specified as follows:
5.6.2.1.1 To compute a tag on data, the AMACP shall:
a) accept as input an octet string MacData to be MACed,
b) accept as input a 32-octet MacKey to be used as the key,
c) accept as input the integer mactaglen which is the size in octets of MacTag,
d) calculate the tag MacTag = MACMacKey(MacData) of length mactaglen, where

MACMacKey(MacData) denotes the computation of the tag on MacData under MacKey
using the HMAC tagging transformation specified in RFC 2104 with AHASH as
specified in 5.7.2, and
e) output the octet string MacTag of mactaglen.
5.6.2.2 ATN Keyed Message Authentication Code Verification Primitive (AMACVP)
The purported tag on data will be checked using the tag checking transformation specified as follows:
5.6.2.2.1 To verify a purported tag on data, the AMACVP shall:
a) accept as input an octet string MacData,
b) accept as input the purported tag for MacData which is an octet string MacTag',
c) accept as input a 32-octet MacKey to be used as the key,
d) accept as input the integer mactaglen which is the size in octets of MacTag,
e) calculate the tag MacTag = MACMacKey(MacData), where MacTag = MACMacKey(MacData) denotes the
computation of the tag on MacData under MacKey using the HMAC tagging transformation specified in RFC
2104 with AHASH as specified in 5.7.2.
f) If MacTag'=MacTag, output 'valid',
g) If MacTag'  MacTag, output 'invalid'.

5.7 ATN Auxiliary Cryptographic Primitives and Functions
5.7.1 ATN Key Derivation Function (AKDF)
ATN applications and ATN routers derive keying data under the ATN Key Agreement Scheme (5.4) using the key
derivation function given in this section.
5.7.1.1 To calculate keying data, the AKDF shall:
a) accept as input an octet string Z which is the shared secret value,
b) accept as input an integer keydatalen less than hashlen(232-1) which is the length in
octets of the keying data to be generated,
hashlen is the output of the function AHASH which is 32 octets for SHA-256.
c) accept as input an octet string SharedInfo which consists of some data shared by the
two entities intended to share the secret value Z,
d) compute key data using the sequence of steps in this section,
e) initialize a 32-bit, big-endian bit string counter as 0000000116,
f) For i=1 to j= keydatalen/hashlen,
1) compute Hashi = AHASH(Z || counter || SharedInfo), where AHASH is as

specified in 5.7.2,
2) increment counter,
3) increment i.
g) if keydatalen/hashlen is an integer, let HHashj denote Hashj,
h) if keydatalen/hashlen is not an integer, let HHashj denote the (keydatalen -

(hashlen (j-1))) leftmost octets of Hashj,
i) set KeyData = Hash1||Hash2||…||Hashj-1||HHashj, and
j) output the octet string KeyData of length keydatalen.
5.7.2 ATN Hash Function (AHASH)
ATN applications and ATN routers calculate hash values associated with an octet string using the cryptographic
hash function given in this section.
5.7.2.1 To calculate hash values, the AHASH Function shall:
a) accept as input an octet string Data of length less than maxhashlen octets,
maxhashlen is 264, which is the maximum input length for SHA-256.
b) calculate the hash value Hash corresponding to Data using SHA-256 as specified in
FIPS 180-2, and
c) output hashlen which is the length in octets of Hash.
hashlen is 32 octets for SHA-256.
d) output the octet string Hash of length hashlen octets.

6 ATN SYSTEM SECURITY OBJECT
6.1 Introduction
The System Security Object (SSO) provides a set of abstract services for the generation and verification of
security items. It describes all the necessary steps to perform the cryptographic schemes and primitives described
in section 4.5 and 5.
The SSO is an architectural component of the Upper Layer Communication Service (ULCS). Its purpose is to
isolate the security-related transformations from the protocol used to exchange security data. The SSO is used in
the context of a secured association (managed by the S-ASO defined in Part III B) between two ULCS entities
for security-related transformations.
A secured association is defined as one or more secured dialogues between a pair of application entities. For
most ATN applications, the duration of the secured association is the same as the duration of the secured
dialogue used for that application. For Context Management, the duration of the secured association may span
across multiple secured dialogues. This property allows for the use of the same secured association data on a
new Context Management dialogue when the first dialogue between a pair of Context Management peers is not
maintained. The duration is no longer than the duration of a single flight segment (from gate to gate, including
pre- and post-flight activities). However, the actual duration is subject to local considerations (e.g., time
constraints).
All ATS applications on an airframe share the same key-agreement key pair, which is "owned" by the Context
Management application peer. The airframe's Context Management AP-title will be used as the subject in the
airframe's public key-agreement key certificate. Therefore, in order to retrieve the public key-agreement key
certificate for the airborne peer, the airframe's Context Management AP-title is used.
As with all other abstract interfaces, there is no requirement to implement the SSO in any product. ATN systems
will in general be designed in such a way that it is impossible to detect (from external access) whether or not an
interface corresponding to the SSO has been implemented. The only requirement is that the implementation be
able to perform the set of functions described here.
For the purposes of this specification, the SSO maintains the following information for each pair of ULCS peers
involved in a secured association:
a) Source Peer: the initiator of the secured association (e.g., the AP-title for ATS
applications).
b) Destination Peer: the responder of the secured association (e.g., the AP-title for ATS
applications).
c) Secured-Association-Signature: the ATN Appendix sent from the Source Peer to the Destination Peer
in the first exchange on a Secured Dialogue Supporting Key Management. The Secured-Association-Signature
applies only to communication between an airborne peer and a ground peer.
d) Random Challenge: the random 32-bit unsigned integer generated by the Destination Peer and sent to
the Source Peer in reply to the first exchange from the Source Peer to the Destination Peer on a Secured
Dialogue Supporting Key Management. The Random Challenge applies only to communication between an
airborne peer and a ground peer.
e) Shared Secret Value: the value created using the private key-agreement-key of the
local peer and the public key-agreement-key of the remote peer. Due to the
properties of the underlying Cryptographic Infrastructure, only the Source Peer and
Destination Peer are able to calculate this value. The Shared Secret Value applies
only to communication between an airborne peer and a ground peer.
f) Shared Key Derivation Parameter: the value created by the peers that participate in
the first exchange on a Secured Dialogue Supporting Key Management. The peers
involved in that first exchange are not always the Source and Destination Peers
involved in subsequent exchanges. The Source and Destination Peers may acquire
the Shared Key Derivation Parameter by local means from one of the peers that
actively participated in its calculation. The Shared Key Derivation Parameter may
be made public, but its distribution is performed securely. It is used to minimize
the number of air-ground exchanges in the calculation of session keys for each
supported ATN application. The Shared Key Derivation Parameter applies only to
communication between an airborne peer and a ground peer.
g) Session Key: the symmetric key calculated for use between an airborne peer and a
ground peer. There is a unique session key for each pair of peers even though all
ULCS peers on a given airframe share the same key-agreement key pair and all
ULCS peers of a given application type within a Context Management Domain may
share the same key-agreement key pair. The Session Key applies only to
communication between an airborne peer and a ground peer.
h) Counters: two counters are maintained for each secured association. One counter
counts messages sent from the Source Peer to the Destination Peer. The other
counter counts messages sent from the Destination Peer to the Source Peer. These
counters provide for replay protection. The counters apply only to communication
between an airborne peer and a ground peer.
The ATN Cryptographic Schemes secure octet strings, while ATN application data is typically PER encoded and
may therefore be an arbitrary length bit string (i.e. a bit string whose length is not a multiple of 8). To address
this discrepancy, the SSO pads bit strings on the right with zeroes to form octet strings. There is a security
drawback to this: the padding process is not 1-to-1, meaning that different bit strings may result in the same octet
string after padding. For example, the bit strings 10 and 100 both pad to 10000000. This is not a problem for the
existing ATN applications since there is no situation where an application will interpret data X and data X0..0
(i.e. X with a small number of zeroes added) as having different meanings, but implementors should be aware
that the SSO provides security as the octet string rather than bit string level if adapting the SSO to secure other
applications.
The lifetime of a secured association (including the session key) is implicitly limited by the maximum value of
either of the Counters; however unconstrained integers are used. The encoding of an unconstrained integer is
specified. If a counter reaches its maximum value in an implementation, the security-association must be
aborted; otherwise, replay protection is lost. A new Shared Key Derivation Parameter must be calculated before
the pair of peers may enter into another secured association. With the current ATN applications, it is very
unlikely that these Counters will ever reach the point where a secured association must be aborted.
This section is organized as follows. 6.2 defines the general processing requirements associated with the set of
SSO abstract services. 6.3 describes each of the SSO functions.
6.2 General Processing Requirements
6.2.1 Encoding Rules for SSO Data
6.2.1.1 The SSO shall use the basic unaligned variant of the Packed Encoding Rules (PER) for ASN.1, as
specified in ISO|IEC 8825-2, when encoding security-related data.
The SSO encodes data structures in the course of constructing security appendices. The SSO also reconstructs
these data structures upon receipt of a security appendix. The reconstructed interim data is then encoded and
used in the security appendix verification process.
When using the basic unaligned variant of PER in a security context, care must be taken to ensure that the
encoding is 'canonical enough' to support security. All SSO abstract data structures are specified so as to
produce a canonical encoding using the basic, unaligned variant of PER.
6.2.2 Error Processing Requirements
6.2.2.1 In the event that the SSO cannot complete any requested function, the SSO shall notify the SSO-user.
Examples of error events requiring SSO-user notification are incompatible input, required information not
available, and failure of an ATN Cryptographic Infrastructure primitive. The means of notification of these
errors is a local matter.
6.3 SSO Functions
The following external (i.e., visible to SSO users) functions are provided by the SSO:
a) SSO-Sign, which is used to generate an ATN Appendix containing either a Signature-appendix or

a MAC-appendix for the passed user data,
b) SSO-SignCheck, which is used to verify an ATN Appendix containing either a Signature-appendix or

a MAC-appendix for the passed user data,
c) SSO-ProtectSign, which is used to generate an ATN Appendix containing either a Signature-

appendix or a MAC-appendix for the passed user data and to provide the ATN Appendix and user data in
one abstract value,
d) SSO-ProtectSignCheck, which is used to verify an ATN Appendix containing either a

Signature-appendix or a MAC-appendix that is received along with user data as one abstract value,
e) SSO-CertificateCheck, which is used to verify an X.509 certificate that is reconstructed from an ATN
Compressed Certificate,
f) SSO-GetCertificatePath, which is used to retrieve an ATN Compressed Certificate that is constructed

from an X.509 certificate, and
g) SSO-Stop, which is used to record security-related information when a security-related error is

detected in a secured association.
The following functions are used only by the SSO:
a) SSO-SessionKey, which is used to generate a shared secret key between two ULCS peers,
b) SSO-ASP, which is used to generate an ATN Appendix containing a Signature-appendix,
c) SSO-AVP, which is used to verify an ATN Appendix containing a Signature-appendix,
d) SSO-AMACP, which is used to generate an ATN Appendix containing a MAC-appendix, and
e) SSO-AMACVP, which is used to verify an ATN Appendix containing a MAC-appendix.
Each function has an associated table of parameters. For a given function, the presence of each parameter is
described by one of the following values in the parameter tables:
a) blank not present;
b) C conditional upon some predicate explained in the text;
c) C(=) conditional upon the value of the parameter to the left being present, and equal to that value;
d) M mandatory;
e) M(=) mandatory, and equal to the value of the parameter to the left;
f) U user option.
6.3.1 SSO-Sign function
The parameters of the SSO-Sign function are specified in Table 6-1.
Table 6-1
Parameter Name In Out
Appendix Type M
Source Peer M
Destination Peer M
User Data U
ATN Signature C
The Appendix Type parameter refers to the cryptographic primitive to be applied to UserData and takes an
abstract value of either 'Signature-appendix' or 'MAC-appendix'.
The Source Peer parameter refers to the entity that invoked this function and is an abstract value of an AP-title
or PSAP .
The Destination Peer parameter refers to the entity that is to receive the output of this function and is an abstract
value of an AP-title or PSAP.
The User Data parameter is a bit string and refers to the data that is to be protected.
The ATN Signature parameter is the result of the cryptographic primitive applied to User Data and is an ASN.1
type ATNAppendix. The ATN Signature will be present in the output only if the function succeeds.
6.3.1.1 Upon activation of the SSO-Sign function, the SSO shall:
a) build the Source Peer ATNPeerId and the Destination Peer ATNPeerId.
b) revoke any existing session key shared by the peers by using the SSO-Stop function with the Source
Peer as the SSO-Stop Calling Peer and the Destination Peer as the SSO-Stop Called Peer.
This requirement ensures that old secured associations are destroyed before a new secured association is created.
c) build the ATN Signature using the SSO-ASP function with the following parameters when the
Appendix Type is Signature-appendix:
1) Source Peer ATNPeerId as the SSO-ASP Source Peer, and
2) Destination Peer ATNPeerId as the SSO-ASP Destination Peer, and
3) User Data, padded on the right with the minimum number of zeroes necessary to make an octet string,
as the SSO-ASP User Data.
d) build the ATN Signature using the SSO-AMACP function with the following parameters when the
Appendix Type is MAC-appendix:
1) Source Peer ATNPeerId as the SSO-AMACP Source Peer, and
2) Destination Peer ATNPeerId as the SSO-AMACP Destination Peer, and
as the SSO-AMACP User Data.
6.3.2 SSO-SignCheck function
The parameters of the SSO-SignCheck function are specified in Table 6-2.
Table 6-2
Source Peer M
Destination Peer M
User Data U
Security Item M
Certificate Path C
The Source Peer parameter refers to the entity that generated the signature to be verified and is an abstract value
of an AP-title or PSAP.
The Destination Peer parameter refers to the entity that invoked this function and is an abstract value of an AP-
title or PSAP.
The User Data parameter is a bit string and refers to the data whose security item is to be verified. It is included
in the input when the Destination Peer receives it from the Source Peer.
The Security Item parameter is the security item received from the Source Peer and is an ASN.1 type
ATNAppendix. It is the ATN Appendix to be verified.
The Certificate Path is the Source Peer's public signature-key compressed certificate path when the Security Item
contains a Signature-appendix and is the Source Peer's public key-agreement-key compressed certificate path
when the Security Item contains a MAC-appendix. It is included in the input when the SSO-user receives it from
the Source Peer and is an ASN.1 type ATNCertificates.
6.3.2.1 Upon activation of the SSO-SignCheck function, the SSO shall:
b) when the Security Item contains a Signature-appendix and a current session key exists:
1) verify that the Security Item does not have the same value as the retained Secured-Association-
Signature for the Source Peer and Destination Peer, and
2) revoke the current session key by using the SSO-Stop function with the Source Peer as the SSO-Stop
Calling Peer and the Destination Peer as the SSO-Stop Called Peer when the Security Item verification succeeds.
This check protects against replay attacks and also ensures that a new Session Key will be computed for the air
and ground peer if a previous Session Key existed. If one of the peers is an airborne peer, only the first exchange
on a secured dialogue supporting key management will be signed. All subsequent exchanges on a secured
dialogue supporting key management, and all exchanges between an airborne peer and a ground peer on a
secured dialogue, will use a MAC-appendix, computed using a session key derived from the Shared Key
Derivation Parameter. All exchanges between two ground peers on a secured dialogue will use a Signature-
appendix. A Session Key is not created, thus never exists, for use between two ground peers.
c) invoke SSO-CertificateCheck to verify the Certificate Path when the Certificate Path is present in the
input.
d) when the Certificate Path is not present in the input and the SSO does not have a (cached) verified
uncompressed certificate path for the Source Peer:
1) retrieve the Source Peer's public signature-key uncompressed certificate path when the Security Item
contains a Signature-appendix, or
2) retrieve the Source Peer's public key-agreement-key uncompressed certificate path when the Security
Item contains a MAC-appendix, and
3) verify the Source Peer's uncompressed certificate path according to the procedure in 4.5.
The SSO may elect to cache certificate paths after verification. The length of time that certificate paths are
cached is subject to local policy.
e) verify the Security Item using the SSO-AVP function with the following parameters when the Security
Item contains a Signature-appendix:
1) Source Peer ATNPeerId as the SSO-AVP Source Peer, and
2) Destination Peer ATNPeerId as the SSO-AVP Destination Peer, and
as the SSO-AVP User Data, and
4) the Security Item as the SSO-AVP ATN Appendix.
f) verify the Security Item using the SSO-AMACVP function with the following parameters when the
Security Item contains a MAC-appendix:
1) Source Peer ATNPeerId as the SSO-AMACVP Source Peer, and
2) Destination Peer ATNPeerId as the SSO-AMACVP Destination Peer, and
as the SSO-AMACVP User Data, and
4) the Security Item as the SSO-AMACVP ATN Appendix.
6.3.3 SSO-ProtectSign function

The parameters of the SSO-ProtectSign function are specified in Table 6-3.
Table 6-3
Appendix Type M
Source Peer M
Destination Peer M
User Data U
Security Item C
The Appendix Type parameter refers to the cryptographic primitive to be applied to User Data and takes an
abstract value of either 'Signature-appendix' or 'MAC-appendix'.
The Source Peer parameter refers to the entity that invoked this function and is an abstract value of an AP-title
or PSAP
The Destination Peer parameter refers to the entity that is to receive the output of this function and is an abstract
value of an AP-title or PSAP .
The User Data parameter is a bit string and refers to the data that is to be protected.
The Security Item parameter is the security item to be generated for sending to the Destination Peer and is an
ASN.1 type ATNProtectSign. The Security Item will be present in the output only if the function succeeds.
6.3.3.1 Upon activation of the SSO-ProtectSign function, the SSO shall:
b) build the ATN Appendix using the SSO-ASP function with the following parameters when the
Appendix Type is Signature-appendix:
1) Source Peer ATNPeerId as the SSO-ASP Source Peer, and
2) Destination Peer ATNPeerId as the SSO-ASP Destination Peer, and
as the SSO-ASP User Data.
c) build the ATN Appendix using the SSO-AMACP function with the following parameters when the
Appendix Type is MAC-appendix:
1) Source Peer ATNPeerId as the SSO-AMACP Source Peer, and
2) Destination Peer ATNPeerId as the SSO-AMACP Destination Peer, and
as the SSO-AMACP User Data.
d) set the Security Item unprotected user data to User Data, padded on the right with the
minimum number of zeroes necessary to make an octet string.
e) set the Security Item appendix to the ATN Appendix.
6.3.4 SSO-ProtectSignCheck function
The parameters of the SSO-ProtectSignCheck function are specified in Table 6-4.
Table 6-4
Source Peer M
Destination Peer M
Security Item M
The Source Peer parameter refers to the entity that generated the Security Item to be verified and is an abstract
value of an AP-title or PSAP.
The Destination Peer parameter refers to the entity that invoked this function and is an abstract value of an AP-
title or PSAP.
The Security Item parameter is the security item to be verified and is an ASN.1 type ATNProtectSign.
6.3.4.1 Upon activation of the SSO-ProtectSignCheck function, the SSO shall:
b) if one of the Source Peer and Destination Peer is an airborne Peer, verify that the Security Item
contains a MAC-appendix.
This check ensures against replay attacks. If one of the peers is an airborne peer, only the first exchange on a
secured dialogue supporting key management should be signed. All subsequent exchanges on a secured dialogue
supporting key management will use a MAC-appendix. All exchanges between an airborne peer and a ground
peer on a secured dialogue will use a MAC-appendix. All exchanges between two ground peers on a
secured dialogue will use a Signature-appendix.
c) verify the Security Item using the SSO-AVP function when the Security Item contains a Signature-
appendix:
1) Source Peer ATNPeerId as the SSO-AVP Source Peer, and
2) Destination Peer ATNPeerId as the SSO-AVP Destination Peer, and
3) the unprotected user data of the Security Item as the SSO-AVP User Data, and
4) the appendix of the Security Item as the SSO-AVP ATN Appendix.
d) verify the Security Item using the SSO-AMACVP function when the Security Item contains
a MAC-appendix:
1) Source Peer ATNPeerId as the SSO-AMACVP Source Peer, and
2) Destination Peer ATNPeerId as the SSO-AMACVP Destination Peer, and
3) the unprotected user data of the Security Item as the SSO-AMACVP User Data, and
4) the appendix of the Security Item as the SSO-AMACVP ATN Appendix.
6.3.5 SSO-SessionKey function
The parameters of the SSO-SessionKey function are specified in Table 6-5.
Table 6-5
Local Peer M
Remote Peer M
The Local Peer parameter refers to the entity that invoked this function and is an ASN.1 type ATNPeerId.
The Remote Peer parameter refers to a paired peer to the entity that invoked this function and is an ASN.1 type
ATNPeerId.
6.3.5.1 Upon activation of the SSO-SessionKey function, the SSO shall:
a) when the SSO has an authentic public key-agreement key available for the Remote Peer, retrieve it.
This case may occur when the local entity is the air component of one of the air-ground ATS applications other
than CM. Then the authentic public key may be available after being conveyed by the CM-ground-user to the
associated CM-air-user in an authenticated exchange, and made available to the SSO by the CM-air-user.
b) when the SSO has a verified key-agreement key uncompressed certificate path for the Remote Peer
available, retrieve the Remote Peer's key-agreement key from the uncompressed certificate path.
This case may occur when the local entity has cached the verified uncompressed certificate path of the Remote
Peer after obtaining it during a previous exchange.
c) when the SSO does not have an authentic public key-agreement key for the Remote Peer and does not
have a verified key-agreement key uncompressed certificate path available for the Remote Peer:
1) retrieve the Remote Peer's public key-agreement key uncompressed certificate path, and
The method of retrieving the public key-agreement key uncompressed certificate path for the Remote Peer is a
local matter. If the Remote Peer is a ground entity, the compressed certificate path would have been received via
the air-ground link. If the Remote Peer is an airborne entity, the Certificate Distribution Service may be used.
2) validate the Remote Peer's public key-agreement key uncompressed certificate path
according to the procedure of 4.5.
The SSO may elect to cache uncompressed certificate paths after verification. The length of time that
uncompressed certificate paths are cached is subject to local policy.
3) retrieve the Remote Peer's key-agreement key from the Remote Peer's public key-agreement key
uncompressed certificate path.
d) retrieve the Local Peer's private key-agreement key.
e) compute the Shared Secret Value associated with the Local Peer and Remote Peer by
invoking ASVDP with:
1) the Local Peer's private key-agreement-key as the ASVDP input parameter dU, and
2) the Remote Peer's public key-agreement-key as the ASVDP input parameter QV.
6.3.5.2 When the output of ASVDP is the Shared Secret Value Z for the Local Peer and Remote Peer, the SSO
shall retrieve the Shared Key Derivation Parameter for the Local Peer and Remote Peer.
The method of retrieving the Shared Key Derivation Parameter for the Local Peer and Remote Peer is a local
matter.
6.3.5.3 When the Shared Key Derivation Parameter for the Local Peer and Remote Peer could not be retrieved,
the SSO shall:
a) retrieve the Secured-Association-Signature for the Local Peer and Remote Peer.
b) retrieve the Random Challenge for the Local Peer and Remote Peer when it has been
generated previously.
c) generate the Random Challenge for the Local Peer and Remote Peer when it has not been generated
previously.
d) retain the Random Challenge for the Local Peer and Remote Peer when it is generated.
e) construct the Shared Key Derivation Parameter for the Local Peer and Remote Peer by invoking
AHASH with the AHASH parameter Data formed by taking the Secured-Association-Signature, which is an
encoded value of type ATNAppendix, i.e. a bit string; padding the Secured-Association-Signature on the right
with the minimum number of zeroes necessary to make an octet string; and appending the Random Challenge, a
bit string of length 32, to the right of the result.
f) make the Shared Key Derivation Parameter available for use by other entities.
6.3.5.4 When the Shared Key Derivation Parameter for the Local Peer and Remote Called Peer is retrieved or
successfully calculated, the SSO shall:
a) encode the Airborne Peer using the Encoding Rules for SSO Data.
b) encode the Ground Peer using the Encoding Rules for SSO Data.
c) construct the Session Key Derivation Information as the concatenation of a single octet with value
0116, the Shared Key Derivation Parameter for the Local Peer and the Remote Peer, the encoded Airborne Peer,
and the encoded Ground Peer.
Airborne Peer refers to the air end system and Ground Peer refers to the ground end system. These can be
determined by the naming conventions used for the Local Peer and Remote Peer.
d) compute the Session Key associated with the Local Peer and Remote Peer by invoking AKDF with:
1) the Shared Secret Value for the Local Peer and Remote Peer as the AKDF input parameter Z, and
2) the AKDF input parameter keydatalen set to 32 octets, and
3) Session Key Derivation Information as the AKDF input parameter SharedInfo.
e) initialize to zero the Counter for messages sent from the Local Peer to the Remote Peer.
f) initialize to zero the Counter for messages sent from the Remote Peer to the Local Peer.
The session key and counters values are maintained for the duration of a secured association (until destroyed
using SSO-Stop). This ensures that replay protection spans all secured dialogues in a secured association.
6.3.5.5 The session key should be stored securely and its access restricted to its use in computing and verifying
appendices only.
6.3.5.6 After generating the Session Key, the SSO shall verify that the generated Session Key has not been
revoked via a previous invocation of SSO-Stop (see 6.3.8).
If the session key computed has been revoked, it will be necessary for a new Secured Dialogue Supporting Key
Management to be initiated between the relevant peers in order to establish a new shared key derivation
parameter.
6.3.6 SSO-CertificateCheck function
The parameters of the SSO-CertificateCheck function are specified in Table 6-6.
Table 6-6
Certificate Path M
The Certificate Path parameter is the compressed certificate path to be validated and is an ASN.1 type
ATNCertificates.
6.3.6.1 Upon activation of the SSO-CertificateCheck function, the SSO shall:
a) reconstruct the uncompressed certificate path from the Certificate Path.
The method for reconstructing the uncompressed certificate path from a compressed certificate path is a local
implementation matter.
b) validate the uncompressed certificate path according to the procedure of 4.5.
6.3.7 SSO-GetCertificatePath function
The parameters of the SSO-GetCertificatePath function are specified in Table 6-7.
Table 6-7
Entity Identification M
Key Usage M
Target Entity ID M
Certificate Path C
The Entity Identification parameter refers to the entity whose certificate is to be retrieved and is an abstract value
of an AP-title or PSAP. When the entity is an airborne ATS entity, the Context Management AP-title is used to
retrieve the uncompressed certificate path.
The Key Usage parameter refers to the type of compressed certificate path that is desired and is an ASN.1 type
KeyUsage. Key Usage will have an abstract value of either digitalSignature or keyAgreement.
The Target Entity ID parameter refers to the entity to which it is intended to deliver the compressed certificate
path and is an abstract value of an AP-Title or PSAP.
The Certificate Path parameter is the compressed certificate path for the requested entity and is an ASN.1 type
ATNCertificates. It is included in the output when the function succeeds.
6.3.7.1 Upon activation of the SSO-GetCertificatePath function, the SSO shall:
a) retrieve the certificate path from the Target Entity's CA to the public key specified by KeyUsage of the
entity.
The method of retrieval of the certificate path, and the method of identifying the CA of Target Entity are a local
matter.
The uncompressed certificate path may be validated according to the procedure of 4.5 in order to ensure that
SSO-GetCertificatePath does not return an invalid certificate path.
The Key Usage parameter refers to the type of compressed certificate path that is desired and is an ASN.1 type
KeyUsage. Key Usage will have an abstract value of either digitalSignature, keyAgreement, or both
digitalSignature and keyAgreement.
b) validate the uncompressed certificate path according to the procedure of 4.5.
b) compress the retrieved uncompressed certificate path into the appropriate compressed certificate path
using the abstract syntax specified in 4.3.3.
c) set the Certificate Path parameter to the compressed certificate path.

6.3.8 SSO-Stop function
The parameters of the SSO-Stop function are specified in Table 6-8.
Table 6-8
Calling Peer M
Called Peer M
The Calling Peer parameter refers to the entity that invoked this function and is an abstract value of an AP-title
or PSAP.
The Called Peer parameter refers to a paired peer to the entity that invoked this function and is an abstract value
of an AP-title or PSAP.
6.3.8.1 Upon activation of the SSO-Stop function, the SSO shall:
a) delete the following state data associated with the Calling Peer and Called Peer:
1) Shared Secret Value,
2) Shared Key Derivation Parameter,
3) both Counters,
4) Secured-Association-Signature, and
5) Random Challenge.
b) retain the Session Key associated with the Calling Peer and Called Peer as revoked at the time of
invocation
Retention as revoked of the Session Key is used to prevent the replay of previous exchanges between these
two peers using this Session Key since a Session Key between the two peers will be recalculated as the same
value until a new Secured-Association-Signature is received from the Initiator on a Secured Dialogue Supporting
Key Management.
6.3.9 SSO-ASP function
The parameters of the SSO-ASP function are specified in Table 6-9.
Table 6-9
Source Peer M
Destination Peer M
User Data U
ATN Appendix C
The Source Peer parameter refers to the entity that invoked this function and is an ASN.1 type ATNPeerId.
The Destination Peer parameter refers to the entity that is to receive the output of this function and is an ASN.1
type ATNPeerId.
The User Data parameter refers to the data that is to be signed.
The ATN Appendix parameter is the result of the cryptographic primitive applied to User Data and is an ASN.1
type ATNAppendix. The ATN Appendix will be present in the output only if the function succeeds.
6.3.9.1 Upon activation of the SSO-ASP function, the SSO shall:
a) retrieve the Source Peer's private signature-key.
Retrieval of the Source Peer's private signature-key is a local implementation matter.
b) generate a Time Field using the current system time.
c) construct the To Be Signed Data from the Source Peer, Destination Peer, Time Field
generated above, and the User Data.
d) generate a Signature-appendix over the To Be Signed Data by invoking ASP as specified in 5.5.2.1
with:
1) To Be Signed Data, padded on the right with the minimum number of zeroes necessary to make an
octet string, as the ASP parameter SignData, and
2) the Source Peer's private signature-key as the ASP parameter d.
6.3.9.2 The To Be Signed Data shall conform to the encoding of the abstract syntax SignData using the
Encoding Rules for SSO Data.
6.3.9.3 The Time Field shall conform to the abstract syntax ATNSecurityDateTime.
6.3.9.4 The Signature-appendix shall conform to the abstract syntax ECDSA-Sig-Value.
6.3.9.5 When the output of ASP is the valid Signature-appendix, the SSO shall:
a) omit ATNAppendix.algorithmId when the default algorithm for ASP is used.
b) set ATNAppendix.algorithmId to the OBJECT IDENTIFIER for the signature algorithm for ASP
when the default algorithm for ASP is not used.
c) set ATNAppendix.validity.timeField to the Time Field generated above.
d) set ATNAppendix.value.ecdsa-Signature to the Signature-appendix.
e) retain the ATN Appendix as the Secured-Association-Signature associated with the Source Peer and
Destination Peer for use later in generating the Shared Key Derivation Parameter for use with AKDF when either
the Source Peer or the Destination Peer is an airborne entity.
Communication between ground peers is secured using a purely asymmetric solution and does not use AKDF
later; therefore the Secured-Association-Signature is not retained when both peers are ground entities.
6.3.10 SSO-AVP function
The parameters of the SSO-AVP function are specified in Table 6-10.
Table 6-10
Source Peer M
Destination Peer M
User Data U
ATN Appendix M
The Source Peer parameter refers to the entity that generated the ATN Appendix to be verified and is an ASN.1
type ATNPeerId.
The Destination Peer parameter refers to the entity that invoked this function and is an ASN.1 type ATNPeerId.
The User Data parameter refers to the data that is to be signed. It is included in the input when it is received
from the Source Peer.
The ATN Appendix parameter contains the Signature-appendix that was received from the Source Peer and is to
be verified. It is an ASN.1 type ATNAppendix
6.3.10.1 Upon activation of the SSO-AVP function, the SSO shall:
a) verify that the Time Field in the ATN Appendix is valid.
The criteria used to verify the Time Field in the ATN Appendix is a local matter.
b) reconstruct the To Be Signed Data from the Source Peer, Destination Peer, Time Field, and the User
Data.
c) retrieve the Signature-appendix from the ATN Appendix.
d) retain the ATN Appendix as the Secured-Association-Signature associated with the Source Peer and
Destination Peer for use later in generating the Shared Key Derivation Parameter for use with AKDF when either
the Source Peer or the Destination Peer is an airborne entity.
Communication between ground peers is secured using a purely asymmetric solution and does not use AKDF
later.
e) obtain the Source Peer's public signature-key.
f) verify the Signature-appendix by invoking AVP as specified in 5.5.2.2 with:

1) To Be Signed Data, padded on the right with the minimum number of zeroes necessary to make an
octet string, as the AVP parameter SignData', and
2) Signature-appendix as the AVP parameters r' and s', and
3) the Source Peer's public signature-key as the AVP parameter Q.
6.3.10.2 The criteria for verification of the Time Field should include a relationship to the transit delay
associated with the Class of Communication requested for the application dialogue.
6.3.10.3 The To Be Signed Data shall conform to the encoding of the abstract syntax SignData using the
Encoding Rules for SSO Data.
6.3.10.4 The Signature-appendix shall conform to the abstract syntax ECDSA-Sig-Value.
6.3.11 SSO-AMACP function
The parameters of the SSO-AMACP function are specified in Table 6-11.
Table 6-11
Source Peer M
Destination Peer M
User Data U
ATN Appendix C
The Source Peer parameter refers to the entity that invoked this function and is an ASN.1 type ATNPeerId.
The Destination Peer parameter refers to the entity that is to receive the output of this function and is an ASN.1
type ATNPeerId.
The User Data parameter refers to the data that is to be signed.
The ATN Appendix parameter is the result of the cryptographic primitive applied to User Data and is an ASN.1
type ATNAppendix. The ATN Appendix will be present in the output only if the function succeeds.
SSO-AMACP is intended to be used between air and ground peers. Communication between ground peers is
secured using a purely asymmetrical solution and this function is not needed; therefore, no distinction is made for
airborne users in this function.
6.3.11.1 Upon activation of the SSO-AMACP function, the SSO shall:
a) retrieve the Session Key for the Source Peer and Destination Peer when it is available at invocation of
SSO-AMACP.
b) invoke SSO-SessionKey to calculate the Session Key shared by the two peers when it is not available
at invocation of SSO-AMACP.
c) retrieve the Counter for the ordered pair of Source Peer and Destination Peer.
d) increment Counter by 1.
e) retrieve the Random Challenge for the Source Peer and Destination Peer when the Shared Key
Derivation Parameter is not available at invocation of SSO-AMACP.
f) retrieve the Secured-Association-Signature corresponding to the Source Peer and Destination

Peer when the Shared Key Derivation Parameteris not available at invocation of SSO-AMACP.
g) construct the MAC Data for the AMACP from the Source Peer, Destination Peer, the
Counter from above, the User Data, the Random Challenge retrieved above, and the Secured-Association-
Signature from above when the Shared Key Derivation Parameteris not available at invocation of SSO-
AMACP.
h) construct the MAC Data for the AMACP from the Source Peer, Destination Peer, the
Counter from above, and the User Data when the Shared Key Derivation Parameter is available at invocation of
SSO-AMACP.
i) generate a MAC over MAC Data by invoking AMACP as specified in 5.6.2.1 with:
1) MacData, padded on the right with the minimum number of zeroes necessary to make an octet string,
as the AMACP parameter MacData,
2) Session Key as the AMACP parameter MacKey, and
3) the AMACP parameter mactaglen set to 4 octets.
6.3.11.2 The MAC Data shall conform to the encoding of the abstract syntax MacData using the Encoding
Rules for SSO Data.
6.3.11.3 When the output of AMACP is a valid MAC MacTag, the SSO shall:
a) omit ATNAppendix.algorithmId when the default algorithm for AMACP is used.
b) set ATNAppendix.algorithmId to the OBJECT IDENTIFIER for the algorithm for AMACP when the
default algorithm for AMACP is not used.
c) set ATNAppendix.validity.random to the Random Challenge for the Source Peer and
Destination Peer when the Shared Key Derivation Parameter is not available at invocation of SSO-
AMACP.
d) omit ATNAppendix.validity.random when the Shared Key Derivation Parameter is available

at invocation of SSO-AMACP.
e) set ATNAppendix.value.hmac-Tag to the AMACP returned MAC MacTag.
6.3.12 SSO-AMACVP function
The parameters of the SSO-AMACVP function are specified in Table 6-12.

Table 6-12
Source Peer M
Destination Peer M
User Data U
ATN Appendix M
The Source Peer parameter refers to the entity that generated the signature to be verified and is an ASN.1 type
ATNPeerId.
The Destination Peer parameter refers to the entity that invoked this function and is an ASN.1 type ATNPeerId.
The User Data parameter refers to the data whose security item is to be verified. It is included in the input when
it is received from the Source Peer.
The ATN Appendix parameter contains the MAC-appendix that was received from the Source Peer and is to be
verified. It is an ASN.1 type ATNAppendix.
SSO-AMACVP is intended to be used between air and ground peers. Ground- ground communication is secured
using a purely asymmetrical solution and this function is not needed; therefore, no distinction is made for
airborne users in this function.
6.3.12.1 Upon activation of the SSO-AMACVP function, the SSO shall:
a) retrieve the Random Challenge from the ATN Appendix and retain it for use later in
generating the Shared Key Derivation Parameter for the Source Peer and Destination Peer when the Random
Challenge is present in the ATN Appendix.
b) invoke the SSO-SessionKey function to calculate the Session Key shared by the two peers when the
Session Key is not available at invocation of SSO-AMACVP.
c) retrieve the Session Key shared by the two peers when the Session Key is available at invocation of
SSO-AMACVP.
d) retrieve the Counter for the ordered pair of Source Peer and Destination Peer.
e) increment Counter by 1.
f) retrieve the Secured-Association-Signature corresponding to the Source Peer and Destination

Peer when the Shared Key Derivation Parameter is not available at invocation of SSO-AMACVP.
g) reconstruct the MAC Data for the AMACVP from the Source Peer, Destination Peer, the Counter
from above, the User Data, the Random Challenge retrieved above, and the Secured-Association-Signature from
above when the Shared Key Derivation Parameter is not available at invocation of SSO-AMACVP.
h) reconstruct the MAC Data for the AMACVP from the Source Peer, Destination Peer, the Counter
from above, and the User Data when the Shared Key Derivation Parameter is available at invocation of SSO-
AMACVP.
i) retrieve the received MAC from the ATN Appendix.
j) verify that the received message authentication code by invoking AMACVP as specified in 5.6.2.2
with:
1) MAC Data, padded on the right with the minimum number of zeroes necessary to make an octet
string, as the AMACVP parameter MacData, and
2) the received MAC as the AMACVP parameter MacTag',
3) Session Key as the AMACVP parameter MacKey, and
4) the AMACVP parameter mactaglen set to 4 octets.
6.3.12.2 The MAC Data shall conform to the encoding of the abstract syntax MacData using the Encoding
Rules for SSO Data.
7 ATN SECURITY ASN.1 MODULE
This chapter contains a description of the information unique to ATN certificates and the information internally
used by the SSO.
The abstract syntax used by the SSO and the ATN PKI shall comply with the description contained in the ASN.1
modules ATN-PKI and ATN-PKI-EXPLICIT (conforming to ITU-T Rec X.680), as defined here.
ATN-PKI { iso(1) identified-organization(3) icao(27)

atn-security-requirements(5) modules(1) atnPKI(3) }
DEFINITIONS AUTOMATIC TAGS ::= BEGIN
-- EXPORTS ALL --
IMPORTS
AlgorithmIdentifier, Certificate, CertificateSerialNumber FROM

AuthenticationFramework { joint-iso-ccitt ds(5) module(1)
authenticationFramework(7) 3 }
KeyUsage FROM
CertificateExtensions { joint-iso-ccitt ds(5) module(1)
certificateExtensions(26) 0 }
securityExchanges FROM
ATNObjectIdentifiers { iso(1) identified-organization(3)
icao(27) atn(0) objectIdentifiers(0) }
ATNAppendix FROM
ATNSecurityExchanges securityExchanges
--
-- Compressed Certificates
--
ATNCertificates ::= SEQUENCE

{
compressedUserCertificate
CompressedUserCertificate,
certificatePath ForwardCertificatePath OPTIONAL
}
CompressedUserCertificate ::= SEQUENCE

{
serialNumber CertificateSerialNumber,
algorithmIdentifier AlgorithmIdentifier OPTIONAL,
validity ATNValidity,
subjectPublicKey BIT STRING,
subjectAltName ATNPeerId,
issuerAltName ATNPeerId,
keyUsage KeyUsage,
encrypted BIT STRING,
...
}
ForwardCertificatePath ::= SEQUENCE OF CACertificates
CACertificates ::= SEQUENCE OF CompressedUserCertificate
--
-- Entity Identifications
--
ATNPeerId ::= CHOICE

{
atn-ats-es-id ATN-es-id,
-- required for ATS app entities
atn-is-id ATN-is-id,
-- required for all intermediate systems
atn-ca-id ATN-ca-id,
-- required for all ATN CAs
atn-other-id ATN-other-id,
-- available for any non-ATS use
-- AOC can put PSAPs here
...
}
-- ATN ATS End Systems are defined by their AP-title as defined in Part IV-C
--
ATN-es-id ::= CHOICE
{
rel-air-ap-title RELATIVE-OID,
-- relative to { iso(1) identified-organization(3)
-- icao(27) atn-end-system-air(1) }
rel-ground-ap-title RELATIVE-OID
-- relative to { iso(1) identified-organization(3)
-- icao(27) atn-end-system-ground(2) }
}
-- ATN Intermediate Systems are identified by their Network Entity

-- Title, a 20-octet address. The first 3 octets of this address are
-- fixed to decimal 470027. The RDF is the 8th octet of the NET and
-- is fixed to the value 0. The type below takes advantage of these
-- facts and uses only 16 octets rather than the full 20.
ATN-is-id ::= OCTET STRING (SIZE (16))
ATN-ca-id ::= RELATIVE-OID

-- relative to { iso(1) identified-organization(3) icao(27)
-- atn-ca(6) }
-- Note: this is one OID sub-identifier
ATN-other-id ::= OCTET STRING
--
-- Supporting Types
--
ATNValidity ::= SEQUENCE

{
notBefore ATNSecurityDateTime,
notAfter ATNSecurityDateTime
}
ATNSecurityDateTime ::= SEQUENCE

{
date ATNSecurityDate,
time ATNSecurityTime
}
ATNSecurityDate ::= SEQUENCE

{
year Year,
month Month,
day Day
}
Day ::= INTEGER (1..31)

-- unit = Day, Range (1..31), resolution = 1
Month ::= INTEGER (1..12)

-- unit = Month, Range (1..12), resolution = 1
ATNSecurityTime ::= SEQUENCE

{
hours Timehours,
minutes Timeminutes,
seconds Timeseconds
}
Timehours ::= INTEGER (0..23)

-- units = hour, range (0..23), resolution = 1
Timeminutes ::= INTEGER (0..59)

-- units = minutes, range (0..59, resolution = 1
Timeseconds ::= INTEGER (0..59)

-- units = seconds, range (0..59), resolution = 1
Year ::= INTEGER (1996..2095)

-- unit = Year, Range (1996..2095), resolution = 1
NET ::= OCTET STRING (SIZE (20))
--
-- SSO Data Types
--
MacData ::= SEQUENCE

{
sourcePeerId ATNPeerId,
destPeerId ATNPeerId,
counter INTEGER (0..MAX),
userData OCTET STRING OPTIONAL,
random INTEGER (0..4294967295) OPTIONAL,
-- 32-bit unsigned integer
atnSignature ATNAppendix OPTIONAL
}
SignData ::= SEQUENCE

{
sourcePeerId ATNPeerId,
destPeerId ATNPeerId,
timeField ATNSecurityDateTime,
userData OCTET STRING OPTIONAL
}
END -- ATN-PKI --
--
-- ASN.1 module containing supporting ASN.1 types that require the use of an
-- explicit tagging environment. Most of these definitions are reproduced
-- from supporting standards (e.g., ANSI-X9-62 and SEC2).
--
ATN-PKI-Explicit { iso(1) identified-organization(3) icao(27)

atn-security-requirements(5) modules(1) atnPKI-explicit(4) }
DEFINITIONS EXPLICIT TAGS ::= BEGIN
-- EXPORTS ALL --
-- IMPORTS Nothing --
--
-- From ANSI X9.62
--
--
-- The ECDSA-Sig-Value type is used for all ATN Signature values.
--
ECDSA-Sig-Value ::= SEQUENCE
{
r INTEGER,
s INTEGER
}
--
-- The EcpkParameters type is used in the subjectPublicKeyInfo field of ATN
-- Certificates. See 4.3.1.3.6.
--
EcpkParameters ::= CHOICE {
ecParameters [0] NULL, -- Not used in ATN, tag and type changed
namedCurve CURVES.&id ({CurveNames}),
implicitCA NULL -- Not used in ATN
}
--
-- The ECPoint type is used for all ATN public keys. See 4.3.1.3.6.3.
--
ECPoint ::= OCTET STRING
--
-- The OID ecdsa-with-SHA256 is used to identify the signature algorithm used
-- by the ATN Signature Primitive. See 4.3.1.2.1
--
ecdsa-with-SHA256 OBJECT IDENTIFIER ::= { 1 2 840 10045 3 2}
--
-- The OID id-ecPublicKey is used in the subjectPublicKeyInfo field of ATN
-- Certificates. See 4.3.1.3.7
--
id-ecPublicKey OBJECT IDENTIFIER ::= { 1 2 840 10045 2 1 }
--
-- The CURVES type is an Information Object Class that is used to constrain
-- the set of valid elliptic curves. This Information Object Class is used
-- below in the CurveNames Information Object Set to identify the elliptic
-- curves that are used for the ATN.
--
CURVES ::= CLASS {
&id OBJECT IDENTIFIER UNIQUE
}
WITH SYNTAX { ID &id }
--
-- End From ANSI X9.62
--
--
-- From SEC2
--
--
--
-- The OID sect233r1 implicitly identifies the ATN
-- elliptic curve domain parameters. See 4.3.1.3.6.2.2.
--
sect233r1 OBJECT IDENTIFIER ::= { 1 3 132 0 27 }
--
-- End From SEC2
--
--
-- CurveNames is the table (Information Object Set) of valid ATN curves.
-- This Information Object Set replaces the CurveNames table in ANSI X9.62
-- for the ATN.
--
CurveNames CURVES ::= {
{ ID sect233r1 },
...
}
END -- ATN-PKI-Explicit –
-- END --

Manual On Detailed Technical Specifications For The Aeronautical Telecommunication Network (Atn) Using Iso/Osi Standards and Protocols

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Manual On Detailed Technical Specifications For The Aeronautical Telecommunication Network (Atn) Using Iso/Osi Standards and Protocols

Uploaded by

Copyright:

Available Formats

IV-B-1 Manual on detailed technical specifications for the Aeronautical Telecommunication Network

using ISO/OSI standards Part IV-B – Security Services

MANUAL ON DETAILED TECHNICAL SPECIFICATIONS FOR THE

This manual will be published in the following parts:

Part I Air-ground applications (Doc. 9705/sub-volume II)

Part IIA Ground-ground applications AIDC (Doc. 9705/sub-volume III)

Part IIB Ground-ground applications – AMHS (Doc. 9705/sub-volume III)

Part IVA Directory service,

Part IVB Ssecurity services,

Part IVC Identifier registration and definitions.

Structure of this document:

Chapter 1: INTRODUCTION contains introductory material to the remainder of this

Chapter 3: ATN SECURITY FRAMEWORK contains the ATN security framework. It

Chapter 3 also identifies the ATN physical security framework.

Chapter 4: ATN PUBLIC KEY INFRASTRUCTURE contains the ATN Public

Chapter 5: ATN CRYPTOGRAPHIC INFRASTRUCTURE contains the ATN

Chapter 6: ATN SYSTEM SECURITY OBJECT contains the ATN System

2 ATN GENERIC SECURITY SERVICES

3 ATN SECURITY FRAMEWORK

3.1 Information Security

3.1.1 Framework Standards

3.1.1.1 The ATN information security framework is based on:

a) ISO/IEC 10181-1: Information Technology - Security Frameworks in Open Systems - Frameworks

b) ISO/IEC 10181-2: Information Technology - Security Frameworks in Open Systems - Authentication

d) ISO/IEC 10181-6: Information Technology - Security Frameworks in Open Systems - Integrity

3.1.1.3.1 The ATSMHS application is defined in Doc 9880 Part IIB.

3.1.2 Framework for Public Key Infrastructure

3.1.2.5.1 Relevant certificate data may be cached on a local basis.

3.1.2.14 <<Requirement deleted>>

3.1.3 Framework for Provision of Security Services within ATN Systems

3.1.3.1 Intermediate Systems

3.1.3.1.2 <<Requirement deleted>>

3.1.3.2 End Systems

3.1.5.5.1 How authentication is accomplished is a local matter.

3.1.6.1 Air-Ground Applications

3.1.6.2 Ground-Ground Applications

3.1.6.2.2 ATSMHS Application

3.1.11 Backward compatibility

3.2 ATN Physical Security Framework

4 ATN PUBLIC KEY INFRASTRUCTURE

4.1 Certificate Policy

4.2 Certificate Practice Statement

4.3 ATN PKI Certificate Format

4.3.1 Uncompressed Certificates

4.3.1.1 Certificate and Certificate Extensions Profile of Uncompressed Certificates

4.3.1.2 ATN Signatures on Uncompressed Certificates

4.3.1.2.1.1 The applicable RFC 5480 ASN.1 Syntax elements are:

4.3.1.2.1.2 The applicable RFC 5480 object identifiers are::

ecdsa-with-SHA256 {1 2 840 10045 4 3 2 }

4.3.1.3 To Be Signed Uncompressed Certificates

4.3.1.3.1 subject field

4.3.1.3.2 subjectPublicKeyInfo field

4.3.1.3.3.2 Authority key identifier extension

4.3.1.3.3.3 Key usage extension

4.3.1.3.3.4 Subject alternative name extension

NET ::= OCTET STRING (SIZE (20))

4.3.1.3.3.5 Issuer alternative name extension

4.3.1.3.3.6 Subject key identifier extension

4.3.1 Encoding of Compressed Certificates

4.4 ATN PKI CRL Format

4.4.1 CRL and CRL Extensions Profile

4.5 ATN PKI Certificate and CRL Validation

4.5.1 Certificate Validation