summary of the atn/osi doc. 9880 security validation report · this working paper provides a...

AERONAUTICAL COMMUNICATIONS PANEL (ACP)

16h MEETING OF WORKING GROUP M

Paris, France 17-19 May 2010

Summary of the ATN/OSI Doc. 9880 Security Validation Report

(Presented by Michael Olive, Honeywell International Inc., United States)

SUMMARY

This working paper provides a summary overview of the analysis,results, and recommendations presented in the ATN/OSI Doc. 9880Security Validation Report. The detailed validation report is includedas an appendix to ACP-WGM16-WP08.

ACTIONThe working group is invited to review the ATN/OSI Security Validation results and consider recommended improvements to Part IV-B.

ACP-WGM16/WP-0917 May 2010

Agenda Item 3a: ATN/OSI Document 9880 Update Status – Security Updates

International Civil Aviation Organization

WORKING PAPER

(28 pages) WG-M WP1609 - ATN-OSI Security Validation Report Summary_20100517.pdf

2

Honeywell.com

ICAO ACP WGM16/WP-09 – 17 May 2010

Background• Under the terms of the FAA DataComm Avionics Contract,

Honeywell was tasked to perform validation of ATN security provisions

– Task 1 – ICAO Doc. 9880 Requirements Validation• Analyze and document similarities between ICAO Doc. 9880 and

ARINC 823, ACARS Message Security (AMS)• Identify validation objectives• Leverage Honeywell Secure ACARS to establish that ICAO Doc.

9880 security provisions have been validated in a representative environment

• Deliverable: Doc. 9880 Security Validation Report– Task 2 – ICAO ACP WG-M Meeting Participation

• Participate in WG-M meetings• Present results of the security validation task

Purpose of this working paper.

3

Honeywell.com


Validation Report Table of Contents

• 1.1. Purpose• 1.2. Scope• 1.3. Document Overview• 1.4. Terminology• 1.5. Reference Documents

1. Introduction

• 2.1. High-level Validation Objectives• 2.2. ATN Security Validation Scope• 2.3. Validation Means• 2.4. ATN Security Validation Matrix

2. Validation Objectives

• 3.1. Overall Approach• 3.2. Provision Alignment• 3.3. Implementation• 3.4. Verification Means

3. Validation Approach Validation report topics highlighted in RED are

summarized in this working paper presentation.

• Analysis format and example• 4.1. Chapter 2 – ATN Security Services• 4.2. Chapter 4 – ATN PKI• 4.3. Chapter 5 – ATN Crypto• 4.4. Chapter 6 – ATN SSO

4. Validation Analysis & Results

• 5.1. Summary Results• 5.2. Recommendations

5. Conclusions

4

Honeywell.com


1. Introduction1.1 Purpose• The purpose of the report is to present results of validation analysis of the

security provisions proposed for Part IV-B, ATN Security Services, of ICAO Doc. 9880, Manual of Technical Provisions for the Aeronautical Telecommunications Network (ATN) using ISO/OSI Protocols.

• Part IV-B of ICAO Doc. 9880 is intended to update and supersede the ATN/OSI security provisions specified in Sub-volume VIII of ICAO Doc. 9705 Edition 3, Manual of Technical Provisions for the Aeronautical Telecommunications Network (ATN).

• The proposed Part IV-B security provisions were presented by the US Federal Aviation Administration (FAA) as information paper IP1405 during the 14th meeting of Working Group M (WG-M) of the ICAO Aeronautical Communications Panel (ACP).

• Honeywell was tasked by the FAA to perform this validation as part of the FAA Data Communications (DataComm) Avionics contract.

5

Honeywell.com


2. Validation Objectives [1/5]2.1 High-Level

Validation Objectives

– Re-use high-level objectives applied previously to validate ICAO Doc. 9705 Ed. 3, SV-III

– References to “SV-VIII” changed to “Part IV-B”

– Focus is on the highlighted objectives

SVO 1 Determine which system level requirements are satisfied by Part IV-B requirements.SVO 2 Validate that the Part IV-B requirements trace to other sub-volumes, where applicable.SVO 3 Validate that Part IV-B includes provision for backward compatibility with prior versions

of peer ATN implementations that do not incorporate security services.FVO 1 Validate that Part IV-B supports implementation of local security policies and practices,

within the boundaries of SARPs, as determined by States/Organizations.FVO 2 Validate that Part IV-B requirements are complete.FVO 3 Validate that Part IV-B requirements are unambiguous.FVO 4 Validate that Part IV-B requirements are consistent.FVO 5 Determine if there are any Part IV-B requirements that would have no effect if removed.FVO 6 Determine if provision has been made to ensure that Part IV-B is implementation

independent.FVO 7 Determine if Part IV-B includes provision for security services necessary for all security

users.TVO 1 Validate that Part IV-B includes provisions for both mobile and fixed ATN users.TVO 2 Validate that Part IV-B minimizes air-ground security related protocol overhead.TVO 3 Validate that Part IV-B supports the security provisions of the ATN Upper Layer

Communications Service (ULCS).TVO 4 Validate that Part IV-B supports the security provisions of the ATN IDRP.TVO 5 Validate that independent implementations built in accordance to Part IV-B will be able

to interoperate.TVO 6 To determine if the ATN security solution has any unacceptable behavior.TVO 7 To determine if provision for future migration has been addressed.TVO 8 To determine if the functionality described in Part IV-B is implementable.

6

Honeywell.com


2. Validation Objectives [2/5]2.2 ATN Security

Validation Scope

– Indentifies the Part IV-B chapters that are included in the scope of the validation effort

7

Honeywell.com


2. Validation Objectives [3/5]2.3. Validation Means

– Re-use validation means (and notation) applied previously to validate ICAO Doc. 9705, Sub-Volume VIII

The means applicable to this validation activity is analysis and inspection. However, the analysis leverages and references the Secure ACARS flight demonstration, which is a representative implementation validated by one organization in a relevant operational communications environment.

8

Honeywell.com


2. Validation Objectives [4/5]2.4. Validation Matrix

– Cross-reference security provisions included in the scope of the validation to high-level validation objectives and validation means.

9

Honeywell.com


2. Validation Objectives [5/5]2.4. Validation Matrix (continued)

10

Honeywell.com


3. Validation Approach [1/7]3.1. Overall Approach

• Leverage…– ARINC Standard 823, ACARS Message Security (AMS), which

is based on ATN/OSI security provisions in Doc. 9705 SV-VIII (plus the enhancements included in Doc. 9880 Part IV-B)

– Honeywell Secure ACARS, which is an existing ARINC 823-compliant implementation of AMS

• To show, by analysis and inspection that…1. There is substantial alignment between the AMS provisions in ARINC

823 and ATN/OSI security provisions specified in Part IV-B.

2. Secure ACARS is a representative implementation of the technical security solution specified in Part IV-B.

3. Successful system-level testing and flight demonstration of the Secure ACARS implementation in a representative, operational communications environment satisfies high-level ATN security validation objectives and provides confidence in the technical security solution specified in Part IV-B .

Given that

alignment

Consequently

11

Honeywell.com


3. Validation Approach [2/7]3.1. Overall Approach (continued)

• Why is this validation approach feasible?– The ATN/OSI technical security solution – i.e., the security

framework, security services, cryptographic algorithms, and public key infrastructure – is independent of the upper layer applications that use the security services and the underlying sub-network(s) over which the security protocol is communicated.

– In other words, the technical security solution is suitable for protecting bit-oriented ATN application messages communicated over the ATN network as well as protecting character-oriented ACARS messages communicated over the ACARS network

» Recognizing that some minor adaptation is necessary to accommodate differences in network addressing.

– Consequently, an ACARS security implementation that is based on ATN/OSI security can serve as a suitable platform for validation of ATN/OSI technical security provisions.

12

Honeywell.com


3. Validation Approach [3/7]3.2. Analysis Component 1 – Provision Alignment

• Qualitative assessment of provision alignment between AMS provisions in ARINC 823 and ATN/OSI security provisions in Part IV-B

» Focus on technical equivalence, recognizing that technically equivalent provisions may be worded differently in their respective specifications

ARINC823

ACARSMessageSecurity

ICAO Doc.9880

Part IV-B

ATN/OSI

ICAO Doc.9705

SV-VIII

ATN/OSI

2. Provisions transferred to

4. Provision Alignment

3. ARINC 823 influenced enhancements incorporated

in Part IV-B

1. ARINC 823 is based directly on ATN/OSI security

13

Honeywell.com


3. Validation Approach [4/7]Background: What were the primary drivers for selecting

ATN/OSI security as the basis for ACARS security?1. In developing the ATN/OSI security solution, the ICAO ATN Panel

Security Sub-group considered the unique challenges of the mobile aeronautical communications environment, including RF bandwidth constraints and avionics resource limitations, which are shared by both ATN and ACARS.

2. The ATN Panel Security Sub-group specified a security solution that is based on internationally recognized cryptographic and public key infrastructure standards. This ensures a high degree of confidence in the cryptographic strength of the solution, and it also facilitates use of commercially available security tool-kits, which reduces development time and minimizes life cycle cost, including non-recurring, procurement, maintenance, and support costs.

3. Finally, a common datalink security solution for both ATN/OSI and ACARS is consistent with ARINC Report 811, which recommends use of common security controls and a common security infrastructure (e.g., PKI) in order to minimize airline investment.

14

Honeywell.com


3. Validation Approach [5/7]3.3. Analysis Component 2 – Implementation

• Honeywell Secure ACARS implementation of ARINC 823 employs a two-part System Security Object (SSO)

» The ATN SSO, which supports authentication, data integrity, and key/certificate management services as specified in Sub-volume VIII of ICAO Doc. 9705 (and Part IV-B of Doc. 9880), and,

» AMS-specific SSO extensions that support confidentiality services as well as initialization and self-test functions (these functions are not included in ATN provisions since they are not required for interoperability)

Software ported toHoneywell MK-II CMU

15

Honeywell.com


3. Validation Approach [6/7]3.4. Analysis Component 3 – Verification

– Secure ACARS Unit-level test

– Secure ACARS System-level bench test (end-to-end)» Simulated network environment, non-operational ground system,» Simulated network environment, operational ground system,» Virtual network environment, operational ground system,» Over-the-air network environment, operational ground system.

16

Honeywell.com


3. Validation Approach [7/7]3.4. Analysis Component 3 – Verification (continued)

– Secure ACARS over-the-air flight demonstration» Verification of datalink security operation (nominal & error modes)» Conducted in accordance with a formal test plan» Using operational VHF frequency, DSP, and ground system » Witnessed by USAF representatives

Avionics test pallet

DemonstrationEnvironment

17

Honeywell.com


4. Validation Analysis and Results [1/3]4. Validation Analysis and Results

– This section is organized by Chapter and Section of Part IV-B – Validation analysis of provisions within a Chapter/Section is

presented in the following tabular formatParagraph number of each specific ATN security provision

Reference to corresponding AMS security provision(s) in ARINC 823 and/or ATA Spec 42

Commentary explaining any exceptions

Validation analysis in terms of:A – Assessment (Yes/No) of the alignment between the ATN and AMS security provisionsI – Indication (Yes/No) as to whether the provision was implemented in Secure ACARSV – Indication as to whether the provision was verified and the verification means:

I – Inspection S – System-level bench testU – Unit-level test D – Over-the-air flight demonstration

18

Honeywell.com


4. Validation Analysis and Results [2/3]4. Validation Analysis and Results (continued)

– Validation results are presented in the following tabular format

Summary of the validation analysis (i.e., alignment, implementation, and verification) with respect to each applicable validation objective, including identification of any defects uncovered during the analysis.

Applicable validation objective(s) per the validation matrix in Section 2.4.

19

Honeywell.com


4. Validation Analysis and Results [3/3]

Example

20

Honeywell.com


5. Conclusions [1/7]5.1. Summary Results

• Validation Objectives FVO2, FVO3, FVO4, FVO5– Overall, the validation analysis shows alignment between ATN and AMS

provisions for security services, PKI, cryptographic infrastructure, and SSO functions. This provides a high degree of confidence that the Part IV-B provisions are complete (FVO 2), unambiguous (FVO 3), consistent (FVO 4), and necessary (FVO 5).

• Validation Objective FVO6– Overall, successful adaptation of the aligned ATN provisions to the ACARS

communications environment provides a high degree of confidence that the provisions in Part IV-B are implementation independent.

• Validation Objective FVO7– Overall, inspection of the ARINC 823 (AMS) provisions and the successful

implementation and flight demonstration of the aligned AMS provisions provide a high degree of confidence that Part IV-B includes provisions necessary for all security users, including those users that may desire confidentiality services in the future.

• Validation Objective TVO1– Overall, inspection of the ARINC 823 (AMS) provisions and the successful

implementation and flight demonstration of the aligned AMS provisions provide a high degree of confidence that Part IV-B includes provisions necessary for both mobile and fixed communicating entities.

21

Honeywell.com


5. Conclusions [2/7]5.1. Summary Results (continued)

• Validation Objective TVO8– Overall, successful implementation and flight demonstration of the aligned AMS

provisions provides a high degree of confidence that the Part IV-B provisions for SSO functions are implementable.

• Defects Identified

DEFECT TYPE:

FVO3 = Editorial

FVO4 = Not consistent

FVO5 = No effect if removed

22

Honeywell.com


5. Conclusions [3/7]• Defects Identified (continued)

DEFECT TYPE:

FVO3 = Editorial

FVO4 = Not consistent

FVO5 = No effect if removed

23

Honeywell.com


5. Conclusions [4/7]5.2. Recommendations

Recommendation 1: Certificate and CRL Profile SpecificationsImprovement Opportunity

• Detailed certificate and CRL profiles transferred from Doc. 9705 SV-VIII were developed in the late 1990’s and do not necessarily reflect current industry standards (commercial or aero)

AMS and Secure ACARS Experience

• AMS certificate/CRL requirements, based on ATN/OSI, were coordinated with the ATA Digital Security Working Group (DSWG)

• ATA Spec 42 specifies certificate policy and certificate/CRL profiles suitable for aero applications – including AMS and ATN – and for interoperability with an aero bridge.

Recommendation • Replace Sections 4.1-4.4 with wording consistent with ICAO Doc. 9896:• X.509 certificate/CRL profiles per IETF RFC 5280• Certificate policy and practices framework per IETF RFC 3647• Note indicating that ATA Spec 42 is available for use by the aero community

Potential Pros • Harmonization with ATA Spec 42 and industry standard practice• Harmonization between text in Doc. 9880 Part IV-B and Doc. 9896• Significant simplification of text in Doc. 9880 Part IV-B

Potential Cons • None identified.

24

Honeywell.com


5. Conclusions [5/7]5.2. Recommendations (continued)

Recommendation 2: Compressed CertificatesImprovement Opportunity

• ATN compressed certificates are a non-standard, ATN-unique format. The constraints imposed on uncompressed certificates may be difficult to achieve since they do not reflect industry standard practice for PKI (the subject of Recommendation #1).


• AMS considered and rejected the non-standard, ATN-unique format.• To minimize air-ground security overhead, the AMS protocol includes coordination

logic between the aircraft and ground entities such that ground certificates are sent over-the-air only when necessary.

Recommendation • At a minimum, remove provisions for compressed certificates in Section 4.3.2 and 4.3.3 of Part IV-B.

• Consider air-ground coordination logic employed by AMS to minimize air-ground security overhead associated with certificate delivery.

Potential Pros • Eliminate non-standard, ATN-unique format.• Eliminate constraints imposed by compressed certificate format and ensure

harmonization with industry standard PKI practices ( minimize life cycle costs).

Potential Cons • Without air-ground coordination logic (or similar), elimination of compressed certificates may increase air-ground security overhead. However, the implementation of Recommendation #4 offsets the increase in security overhead.

25

Honeywell.com



Recommendation 3: Compressed Elliptic Curve PointsImprovement Opportunity

• ATN/OSI provisions specify use of compressed elliptic curve points, which offers some bandwidth efficiency, but at the expense of additional computation by the aircraft entity.

• Implementation of EC point compression my infringe 3rd party intellectual property, and therefore may not be widely supported by crypto toolkits and certificate suppliers.


• AMS considered and rejected the non-standard, ATN-unique format due to the impact on the aircraft entity and potential for limiting crypto toolkit and certificate suppliers.

Recommendation • Re-consider specification of EC point compression.

Potential Pros • Eliminate impact on aircraft computational requirements (important for legacy).• Maximize support by crypto tool-kit and certificate suppliers (i.e., minimize costs).

Potential Cons • Use of un-compressed EC points does increase slightly the air-ground security overhead. But, this needs to be evaluated against the potential drawbacks associated with using compressed EC points. In addition, the implementation of Recommendation #4 offsets the increase in security overhead.

26

Honeywell.com



Recommendation 4: Number of Required Key PairsImprovement Opportunity

• ATN/OSI provisions specify use of two public/private elliptic curve key pairs: one for key agreement and a separate one for digital signature.

• This approach increases the numbers and types of security items that an airline must manage, which may increase maintenance actions and life-cycle costs.


• During development of the AMS standard, airlines – including the US Air Force –recommended that AMS specify a single key pair that is used for both key agreement and digital signature.

Recommendation • Revise ATN/OSI provisions to specify a single public/private key pair for key agreement and digital signature.

Potential Pros • Addresses airline-identified need to minimize the numbers and types of aircraft keys/certificate to be procured and managed.

• Reduces air-ground security overhead since a single ground entity certificate, rather than two certificates, is delivered to the aircraft entity over the air-ground datalink; this offsets the potential increase in security overhead resulting from implementation of Recommendations 2 and 3

Potential Cons • None identified.

27

Honeywell.com


Action by the Meeting

• The ACP WG-M is invited to:– Review the detailed ATN/OSI Security Validation

results, and – Consider recommended improvements to ICAO

Doc. 9880 Part IV-B

Note: The ICAO Doc. 9880 Part IV-B Security Validation Report contains the complete security validation results and recommended improvements. The validation report is included as Appendix A to working paper ACP WGM16/WP-08.

28

Honeywell.com


Point of ContactHoneywell Aerospace Advanced Technology

Michael OliveSr. Principal Systems EngineerE-mail: [email protected]: + 1 (410) 964-7342

Questions?

mailto:[email protected]�