Summary of the ATN/OSI Doc Security Validation Report

Transcription

1 International Civil Aviation Organization WORKING PAPER ACP-WGM16/WP May 2010 AERONAUTICAL COMMUNICATIONS PANEL (ACP) 16h MEETING OF WORKING GROUP M Paris, France May 2010 Agenda Item 3a: ATN/OSI Document 9880 Update Status Security Updates Summary of the ATN/OSI Doc 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 Security Validation Report. The detailed validation report is included as an appendix to ACP-WGM16-WP08. ACTION The working group is invited to review the ATN/OSI Security Validation results and consider recommended improvements to Part IV-B. (28 pages) WG-M WP ATN-OSI Security Validation Report Summary_ pdf

2 Background Under the terms of the FAA DataComm Avionics Contract, Honeywell was tasked to perform validation of ATN security provisions Task 1 ICAO Doc Requirements Validation Analyze and document similarities between ICAO Doc and ARINC 823, ACARS Message Security (AMS) Identify validation objectives Leverage Honeywell Secure ACARS to establish that ICAO Doc security provisions have been validated in a representative environment Deliverable: Doc 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. 2

3 Validation Report Table of Contents 1. Introduction 4. Validation Analysis & Results 1.1. Purpose Analysis format and example 1.2. Scope 4.1. Chapter 2 ATN Security Services 1.3. Document Overview 4.2. Chapter 4 ATN PKI 1.4. Terminology 4.3. Chapter 5 ATN Crypto 1.5. Reference Documents 4.4. Chapter 6 ATN SSO 2. Validation Objectives 2.1. High-level Validation Objectives 2.2. ATN Security Validation Scope 2.3. Validation Means 2.4. ATN Security Validation Matrix 5. Conclusions 5.1. Summary Results 5.2. Recommendations 3. Validation Approach Validation report topics highlighted in RED are summarized in this working paper presentation Overall Approach Provision Alignment Implementation Verification Means 3

4 1.1 Purpose 1. Introduction 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 is intended to update and supersede the ATN/OSI security provisions specified in Sub-volume VIII of ICAO Doc 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 14 th 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. 4

5 2. Validation Objectives [1/5] 2.1 High-Level Validation Objectives Re-use high-level objectives applied previously to validate ICAO Doc Ed. 3, SV-III References to SV-VIII changed to Part IV-B Focus is on the highlighted objectives SVO 1 SVO 2 SVO 3 FVO 1 FVO 2 FVO 3 FVO 4 FVO 5 FVO 6 FVO 7 TVO 1 TVO 2 TVO 3 TVO 4 TVO 5 TVO 6 TVO 7 TVO 8 Determine which system level requirements are satisfied by Part IV-B requirements. Validate that the Part IV-B requirements trace to other sub-volumes, where applicable. Validate that Part IV-B includes provision for backward compatibility with prior versions of peer ATN implementations that do not incorporate security services. Validate that Part IV-B supports implementation of local security policies and practices, within the boundaries of SARPs, as determined by States/Organizations. Validate that Part IV-B requirements are complete. Validate that Part IV-B requirements are unambiguous. Validate that Part IV-B requirements are consistent. Determine if there are any Part IV-B requirements that would have no effect if removed. Determine if provision has been made to ensure that Part IV-B is implementation independent. Determine if Part IV-B includes provision for security services necessary for all security users. Validate that Part IV-B includes provisions for both mobile and fixed ATN users. Validate that Part IV-B minimizes air-ground security related protocol overhead. Validate that Part IV-B supports the security provisions of the ATN Upper Layer Communications Service (ULCS). Validate that Part IV-B supports the security provisions of the ATN IDRP. Validate that independent implementations built in accordance to Part IV-B will be able to interoperate. To determine if the ATN security solution has any unacceptable behavior. To determine if provision for future migration has been addressed. To determine if the functionality described in Part IV-B is implementable. 5

6 2.2 ATN Security Validation Scope Indentifies the Part IV-B chapters that are included in the scope of the validation effort 2. Validation Objectives [2/5] 6

7 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. 7

8 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. 8

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

10 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 SV-VIII (plus the enhancements included in Doc 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. Given that alignment 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. Consequently 10

11 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. 11

12 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 ICAO Doc SV-VIII ATN/OSI 2. Provisions transferred to ICAO Doc Part IV-B ATN/OSI 4. Provision Alignment ARINC 823 ACARS Message Security 3. ARINC 823 influenced enhancements incorporated in Part IV-B 1. ARINC 823 is based directly on ATN/OSI security 12

13 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. 13

14 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 (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 to Honeywell MK-II CMU 14

15 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. 15

16 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 Demonstration Environment 16

17 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 format Paragraph 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 provisions I Indication (Yes/No) as to whether the provision was implemented in Secure ACARS V Indication as to whether the provision was verified and the verification means: I Inspection S System-level bench test U Unit-level test D Over-the-air flight demonstration 17

18 4. Validation Analysis and Results [2/3] 4. Validation Analysis and Results (continued) Validation results are presented in the following tabular format Applicable validation objective(s) per the validation matrix in Section 2.4. 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. 18

19 4. Validation Analysis and Results [3/3] Example 19

20 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. 20

21 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 21

22 5. Conclusions [3/7] Defects Identified (continued) DEFECT TYPE: FVO3 = Editorial FVO4 = Not consistent FVO5 = No effect if removed 22

23 5. Conclusions [4/7] 5.2. Recommendations Recommendation 1: Certificate and CRL Profile Specifications Improvement Opportunity AMS and Secure ACARS Experience Detailed certificate and CRL profiles transferred from Doc SV-VIII were developed in the late 1990 s and do not necessarily reflect current industry standards (commercial or aero) 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 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 Part IV-B and Doc Significant simplification of text in Doc Part IV-B Potential Cons None identified. 23

24 5. Conclusions [5/7] 5.2. Recommendations (continued) Recommendation 2: Compressed Certificates Improvement Opportunity AMS and Secure ACARS Experience 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 and 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. 24

25 5. Conclusions [6/7] 5.2. Recommendations (continued) Recommendation 3: Compressed Elliptic Curve Points Improvement Opportunity AMS and Secure ACARS Experience 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 3 rd 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. 25

26 5. Conclusions [7/7] 5.2. Recommendations (continued) Recommendation 4: Number of Required Key Pairs Improvement Opportunity AMS and Secure ACARS Experience 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. 26

27 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 Part IV-B Note: The ICAO Doc 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

28 Point of Contact Honeywell Aerospace Advanced Technology Michael Olive Sr. Principal Systems Engineer Tel: + 1 (410) Questions? 28