P.O. Box 3041 Sarasota, Florida 34230 Cage Code: 06141 eSRVIVR® Cockpit Voice and Flight Data Recorder (CVFDR) Encryption Module eSRVIVR Non-Proprietary Security Policy Document No: 905-E6247-86 Revision: B R.Schofield EDC 2016-06-09 Created By: John W. Buonasera, Senior Software Engineer 6/8/16 Reviewed by: John S. Patrick, Manager, SRVIVR® & Tactical Product Development 6/8/16 Review by: Robert S. Morich, Sr. Director Engineering 6/8/16 DISTRIBUTION STATEMENT: This document consists of general capabilities information that is not defined as controlled technical data under ITAR Part 120.10 or EAR Part 772. © Copyright 2015-2016 L-3 Communications Corporation. This document can be freely reproduced and distributed; but only whole and intact, including this copyright notice. eSRVIVR CVFDR Security Policy THIS PAGE INTENTIONALLY LEFT BLANK 905-E6247-86 Rev. B 2 eSRVIVR CVFDR Security Policy Revisions Sym Reason/Description Requested/ Date Changed By – Initial Release J. Buonasera 27-Oct-15 A Updated with comments from Cygnacom D. Cunningham 29-Dec-15 B Updated with comments from Cygnacom J. Buonasera / F. 11-Apr-16 / Cortes 07-Jun-16 905-E6247-86 Rev. B 3 eSRVIVR CVFDR Security Policy Table of Contents 1.1.  Purpose ............................................................................................................................................................. 6  1.2.  Acronyms and Abbreviations ........................................................................................................................... 6  1.3.  References ........................................................................................................................................................ 8  1.3.1.  External References .................................................................................................................................... 8  1.3.2.  L-3 AR References ..................................................................................................................................... 8  2.  ENCRYPTION MODULE ................................................................................................................................. 9  2.1.  Overview .......................................................................................................................................................... 9  2.2.  Module Specification ..................................................................................................................................... 10  2.3.  Module Interfaces ........................................................................................................................................... 14  2.4.  Security Rules................................................................................................................................................. 14  2.4.1.  FIPS 140-2 Imposed Security Rules ......................................................................................................... 14  2.4.2.  L3 AR Imposed Security Rules ................................................................................................................. 15  2.5.  Roles, Authentication and Services ................................................................................................................ 16  2.5.1.  Non Authenticated User Role ................................................................................................................... 16  2.5.2.  User and Crypto Officer Roles ................................................................................................................. 16  2.5.3.  Services .................................................................................................................................................... 17  2.6.  Physical Security ............................................................................................................................................ 19  2.7.  Operational Environment ............................................................................................................................... 20  2.8.  Cryptographic Key Management.................................................................................................................... 20  2.9.  Self-Tests ........................................................................................................................................................ 21  2.10.  EMI/EMC Compatibility ............................................................................................................................... 23  2.11.  Design Assurance ......................................................................................................................................... 23  2.12.  Delivery and Operation ................................................................................................................................ 23  2.13.  Guidance....................................................................................................................................................... 24  2.14.  Mitigation of Other Attacks.......................................................................................................................... 24  APPENDIX A............................................................................................................................................................. 25  A.1 Password Strength.............................................................................................................................................. 25  905-E6247-86 Rev. B 4 eSRVIVR CVFDR Security Policy LIST OF FIGURES FIGURE 1 – LOGICAL BOUNDARY OF L-3 AR ESRVIVR® CRYPTOGRAPHIC MODULE ................................................. 11  FIGURE 2 - L-3 AR ESRVIVR® CRYPTOGRAPHIC BOUNDARY .................................................................................... 12  FIGURE 3 - PHYSICAL BOUNDARY OF L-3 AR ESRVIVR® CRYPTOGRAPHIC MODULE ................................................ 13  LIST OF TABLES TABLE 1 - SECURITY LEVEL PER FIPS 140-2 SECTION ....................................................................................... 10  TABLE 2 - FIPS 140-2 LOGICAL INTERFACES OF THE L-3 AR ESRVIVR® CRYPTOGRAPHIC MODULE ........................ 14  TABLE 3 - ROLES AND REQUIRED IDENTIFICATION AND AUTHENTICATION ................................................................. 16  TABLE 4 - STRENGTHS OF AUTHENTICATION MECHANISMS ......................................................................................... 16  TABLE 5 - INSPECTION/TESTING OF PHYSICAL SECURITY MECHANISMS ...................................................................... 20  TABLE 6 - LISTING OF MODULE SUPPORTED KEY AND CRITICAL SECURITY PARAMETERS .......................................... 20  TABLE 7 - ACCESS TYPES LEGEND ............................................................................................................................... 20  TABLE 8 - CSP SERVICE VERSUS CSP ACCESS ............................................................................................................. 21  TABLE 9 - MITIGATION OF OTHER ATTACKS ................................................................................................................ 24  905-E6247-86 Rev. B 5 eSRVIVR CVFDR Security Policy Introduction 1.1. Purpose The Cryptographic Module Security Policy includes the rules derived from the requirements of the FIPS 140-2 standard (see FIPS 140-2 Appendix C) and the rules derived from any additional requirements imposed by L-3 Communications, Aviation Recorders (L-3 AR). This is the Cryptographic Module Security Policy for the L-3 AR eSRVIVR® Cockpit Voice and Flight Data Recorder (CVFDR) Encryption Module. This Security Policy describes how the L-3 AR eSRVIVR® Cockpit Voice and Flight Data Recorder (CVFDR) Encryption Module meets the security requirements of FIPS 140-2 and how to run the module in a secure FIPS 140-2 mode. This policy was prepared as part of the Level 2 FIPS 140-2 validation of the module. FIPS 140-2 (Federal Information Processing Standards Publication 140-2 — (Security Requirements for Cryptographic Modules)) details the U.S. Government requirements for cryptographic modules. More information about the FIPS 140-2 standard and validation program is available on the National Institute of Standards and Technology (NIST) Cryptographic Module Validation Program (CMVP) website at http://csrc.nist.gov/groups/STM/cmvp/index.html. The L-3 AR eSRVIVR® Cockpit Voice and Flight Data Recorder (CVFDR) Encryption Module is referred to in this document as eSRVIVR®, eSRVIVR® cryptographic module, eSRVIVR® module, cryptographic module, crypto module, firmware cryptographic module, firmware module, or module. 1.2. Acronyms and Abbreviations AR / L-3 AR L-3 Aviation Recorders AES Advanced Encryption Standard (FIPS PUB 197) API Application Program Interface ASCII American Standard Code for Information Interchange CDF Configuration Data File CM Crypto Module CMS Configuration Management System CMVP Cryptographic Module Validation Program CO Crypto Officer CPM Crash Protected Memory CPU Central Processing Unit CRC Cyclic redundancy check CSP Critical Security Parameter CVFDR Cockpit Voice and Flight Data Recorder ECB Electronic codebook mode EMC Electromagnetic Compatibility EMI Electromagnetic Interference 905-E6247-86 Rev. B 6 eSRVIVR CVFDR Security Policy eSRVIVR Encrypted SRVIVR Recorder FAA Federal Aviation Administration FCC Federal Communications Commission FIPS Federal Information Processing Standard FIPS PUB FIPS Publication FPGA Field-programmable gate array FRAM Ferroelectric Random Access Memory(Non Volatile RAM) GHz Gigahertz (10^9 Hertz) unit of frequency GSE Ground Station Equipment KAT Known Answer Tests (AES test vectors) LRU Line-Replaceable Unit MHz Megahertz (10^6 Hertz) unit of frequency NIOS II 32-bit embedded-processor architecture for FPGAs. NIST National Institute of Standards and Technology NVRAM Non Volatile RAM OFP Operational Flight Program OS Operating System RTOS Real Time Operating System RAM Random Access Memory 905-E6247-86 Rev. B 7 eSRVIVR CVFDR Security Policy 1.3. References This document deals only with operations and capabilities of the module in the technical terms of a FIPS 140-2 cryptographic module security policy. More information is available on the module from the following sources: 1.3.1. External References ARINC 429-19 Mark 33 Digital Information Transfer System (DITS) ARINC 717-14 Flight Data Acquisition and Recording System IEEE STD 802.3 CSMA/CD Access Method and Physical Layer Specifications, Institute of Electrical and Electronic Engineers Military standard requirements for EMI compatibility. MIL‐STD‐461(E) Military Standard Tests for Environmental Conditions. MIL‐STD‐810 Dept. Of Defense Interface Standard for Digital Time Division MIL‐STD‐1553 Command/Response Multiplex Data RS-422-A Electrical Characteristics of Balanced Voltage Digital Interface Circuits, Electronic Industries Association RTCA/DO-178B Software Considerations in Airborne Systems and Equipment Certification. RTCA/DO-254 Design Assurance for Airborne Electronic Hardware. CMVP website (http://csrc.nist.gov/groups/STM/cmvp/index.html) contains contact information for answers to technical or sales-related questions for the module. 1.3.2. L-3 AR References L-3 Communications, (http://www.l-3ar.com/index.html) contains information on the full line Aviation Recorders of products from L-3 Communications. website 8250029-1 Polysulfide sealant rubber per AMS 3281 . Sealing compound, Polysulfide, Class B-2 (CH), Vendor Part No. PR-1776M B-2, Mfr: 8250029-2 PPG Aerospace - PRC DeSoto 8050417-2 Housing, Main, SRVIVR 8051587-2 LABEL, TAMPER-EVIDENT 8051599-1 LABEL, HARDWARE, ESRVIVR AMS-3281 Sealing Compound, Polysulfide (T) Synthetic Rubber for Integral Fuel Tank and Fuel Cell Cavities, Low Density 905-E6247-86 Rev. B 8 eSRVIVR CVFDR Security Policy 2. Encryption Module 2.1. Overview The eSRVIVR® CVFDR is a flight recorder that enables the storage of encrypted or plain text voice and flight data to a Crash Protected Memory (CPM). The eSRVIVR® cryptographic module is firmware code that performs encryption for the CVFDR. This data is recorded into a primary/backup pair of up to eight (8) physical and logical data partitions. The organization of the data and whether a partition is encrypted in the CPM is defined per partition pair via a factory-loaded Configuration Data File (CDF) that is developed by L-3 AR to customer specifications. The CDF resides outside of the cryptographic module boundary and controls which data is encrypted by the cryptographic module and which data is recorded and stored into which partition. The CDF file is configurable, but it cannot be changed by a user. The CDF file and the OFP can only be uploaded at the factory. The eSRVIVR® Ground Station Equipment (GSE) interface (eSIS-2) allows Application Interface Software operators to send commands to perform security functions related to loading and zeroizing keys used for encrypting, and provides methods of decrypting stored voice and flight data using the FIPS 197 certified AES encryption algorithm. 905-E6247-86 Rev. B 9 eSRVIVR CVFDR Security Policy 2.2. Module Specification The encryption module (module version 1.0) is a firmware module composed of a set of functions for key management including loading, storage, authentication, diagnostics, and encryption. These functions are implemented entirely in the C programming language. The encryption module is a part of the eSRVIVR® firmware running on the processor contained in the CPU board. The cryptographic module is compiled into the generated software images and loaded onto the processor at boot time from the non- volatile memory. Per FIPS PUB 140-2, the eSRVIVR® cryptographic module is classified as an embedded multi-chip firmware cryptographic module. The module meets overall Level 2 FIPS 140-2 requirements as detailed in Table 1. The encryption module is enabled on the eSRVIVR® CVFDR on an as-defined basis for individual recording partitions as defined by the Configuration Data File (CDF) and can only operate in a single authorized mode (FIPS Mode). In this mode of operation, the Data recorder receives data that is not encrypted, then using the AES algorithm encrypts the data with the installed key for those CPM partitions that are defined to be encrypted. Operators can not alter whether partition data will be encrypted. This will be done at the factory only, as defined by the Configuration Data File. Section Section Title Level 1 Cryptographic Module Specification 2 2 Cryptographic Module Ports and Interfaces 2 3 Roles, Services, and Authentication 2 4 Finite State Model 2 5 Physical Security 2 6 Operational Environment N/A 7 Cryptographic Key Management 2 8 EMI/EMC 2 9 Self-tests 2 10 Design Assurance 2 11 Mitigation of Other Attacks N/A -- Overall Level 2 TABLE 1 - SECURITY LEVEL PER FIPS 140-2 SECTION 905-E6247-86 Rev. B 10 eSRVIVR CVFDR Security Policy FIGURE 1 – LOGICAL BOUNDARY OF L-3 AR ESRVIVR® CRYPTOGRAPHIC MODULE FIGURE 1 above depicts the firmware and the logical boundary of the eSRVIVR® cryptographic module. The cryptographic module consists of the key load processes, key storage processes, password management, and AES Encryption Engine. 905-E6247-86 Rev. B 11 eSRVIVR CVFDR Security Policy rt. pt Pa cry En FIGURE 2 - L-3 AR ESRVIVR® CRYPTOGRAPHIC BOUNDARY FIGURE 2 above depicts the logical interfaces and the data flows of encrypted and plaintext data, keys, and CSPs related to the functional tasks of the eSRVIVR® cryptographic module. 905-E6247-86 Rev. B 12 eSRVIVR CVFDR Security Policy FIGURE 3 - PHYSICAL BOUNDARY OF L-3 AR ESRVIVR® CRYPTOGRAPHIC MODULE FIGURE 3 depicts the Processor card LRU and the physical boundary of the eSRVIVR® cryptographic module. Upon boot up, once the firmware integrity and Known Answer Tests are passed and a valid key is found, the cryptographic module becomes operational. If the startup tests fail or a valid encryption key is not available, the cryptographic module is disabled and the module discontinues all output (except status output) from the cryptographic module. 905-E6247-86 Rev. B 13 eSRVIVR CVFDR Security Policy 2.3. Module Interfaces The cryptographic module’s physical interfaces of the embedded multi-chip module lie on its physical cryptographic boundary. They connect from the Module to the CVFDR’s Aircraft interfaces, GSE interfaces, and the Crash Protected Memory (CPM) memory interfaces which are physical connections of the CVFDR and not the Crypto Module’s interfaces. A processor status word bit will be set when in the error state and it will be clear when in normal operation. The logical interface to the cryptographic module is the API (function calls) to the module. All of the physical ports Table 2 are separated into logical interfaces defined by FIPS 140-2. Logical Interface of the FIPS 140-2 Logical Module Physical Port Module Interface Encryption API Aircraft/Serial Interface Data Input Interface (ARINC-429,MIL-STD 1553, A/D, Ethernet, RS-422) Serial Messages API Aircraft/Serial Interface Data Input Interface (Ethernet/RS-422) Serial Messages API Serial Interface Data Output Interface (Ethernet/RS-422) Crash Protected Memory CPM Interface Data Output Interface Interface (CPM MMC Bus) Serial Messages API Aircraft/Serial Interface Control Input Interface (Ethernet/RS-422) Serial Messages API Aircraft/Serial Interface Status Output Interface (ARINC-429,MIL-STD 1553, A/D, Ethernet, RS-422) Encryption API Zeroize Input Discrete Pin Control Input Interface Encryption API CVFDR Maintenance Output Pin Status Output Interface Power pins in ‘Aircraft connector’ and Not Applicable Power Interface external battery TABLE 2 - FIPS 140-2 LOGICAL INTERFACES OF THE L-3 AR ESRVIVR® CRYPTOGRAPHIC MODULE 2.4. Security Rules The cryptographic module’s security rules are broken up into those imposed by FIPS 140-2, and those imposed by L3 AR. 2.4.1. FIPS 140-2 Imposed Security Rules 905-E6247-86 Rev. B 14 eSRVIVR CVFDR Security Policy 1. The Cryptographic Module inhibits all data output whenever an error state exists and during self-tests. 2. The Cryptographic Module does not perform any cryptographic functions while in an error state. 3. The Cryptographic Module logically disconnects the data output path from the circuitry and all processes when performing key zeroization. 4. The Cryptographic Module enforces Role-Based authentication. 5. The Cryptographic Module supports 2 Authenticated Roles; a User role and a Crypto-Officer role. 6. The Cryptographic Module uses authentication for all commands that require authentication. 7. To help prevent brute-force attacks, the Cryptographic Module enforces a minimum password length of eight (8) ASCII printable characters. 8. To help prevent brute-force attacks, the Cryptographic Module enforces a maximum password length of fifteen (15) ASCII printable characters. 9. To help prevent brute-force attacks, the Cryptographic Module enforces a minimum number of characters types required in the password. At least one each of the following character types are required:  A symbol character (!@#$%^&*,...)  A number character (0-9)  An upper case character (A-Z)  A lower case character (a-z) The probability of a successful random attempt is one in 3,025,989,069,143,040. See Appendix A for more details on how this probability is calculated. 10. To help prevent brute-force attacks, the Cryptographic Module enforces a hard ten (10) minute lockout after three (3) failed login attempts within a minute. The lockout will be persistent across hard or soft reboots. This ensures that random attempt success rate will be less than 1 in 100,000 in one (1) minute. 11. The Cryptographic Module protects keys from unauthorized disclosure, modification, and substitution. 12. The Cryptographic Module does not output Authentication data. 13. Key data is stored in a key record that includes a CRC over all of the fields to detect data corruption. 14. The Cryptographic Module denies access to the plaintext cryptographic key contained within the module. 15. The Cryptographic Module provides the capability to Zeroize the Cryptographic key stored in Non Volatile Memory within the module. 2.4.2. L3 AR Imposed Security Rules 1. The Cryptographic Module does not support multiple concurrent users. 2. The Cryptographic Module can only be reset to factory defaults by the Crypto Officer. 3. All other Cryptographic module services are suspended during key loading, including encryption. 4. Each command that requires authentication by the Cryptographic Module must be individually authenticated. 905-E6247-86 Rev. B 15 eSRVIVR CVFDR Security Policy 2.5. Roles, Authentication and Services The module enforces operators to assume a role and supports two Authenticated Roles: a Crypto Officer role and an Authenticated User role. The cryptographic module implicitly assumes the Crypto Officer role to encrypt any data received from the aircraft as previously enabled by the Crypto Officer. An operator assumes the User or Crypto Officer role based on the authentication process. For example: After startup, to load a new AES key, the operator is required to use the Crypto Officer password with the load key command and will assume the Crypto Officer role. Once this password is matched, the operator is designated as a Crypto Officer for the duration of the function’s execution. There are limits or requirements on password length (See Section 2.4.1, FIPS 140-2 Imposed Security Rules). Since this authentication is a FIPS level-2 compliant authentication, the passwords will be used for role based authentication and will not be assigned for identity based authentication. Descriptions and responsibilities for the Crypto Officer and User roles are described below. Role Type of Authentication Authentication Data Crypto Officer (GSE) Role based Password (explicit) 95 ASCII printable characters, (see rules in Section 2.4.1) User (GSE) Role based Password 95 ASCII printable characters, (see rules in Section 2.4.1) TABLE 3 - ROLES AND REQUIRED IDENTIFICATION AND AUTHENTICATION Authentication Mechanism Strength of Mechanism Password (Random Attempt) One in 3,025,989,069,143,040 Password (Random Attempt success rate) Persistent Hard ten (10) minute lockout after a total of three (3) failed login attempts within a minute. TABLE 4 - STRENGTHS OF AUTHENTICATION MECHANISMS The values shown in TABLE 4 exceed the FIPS 140-2 requirements for each random attempt (1 in 1,000,000) and for multiple random attempts (1 in 100,000). 2.5.1. Non Authenticated User Role Although some commands do not require authentication, there are no Non-Authenticated Roles. 2.5.2. User and Crypto Officer Roles The User and Crypto Officer (Authenticated Users) can execute all commands transmitted via the Aircraft, Serial and GSE interfaces including API message IDs authenticated if a valid key has been loaded. The User and Crypto Officer (Authenticated Users) can each set their own password. Except for the “Zeroize Key” command, only the Crypto Officer can execute commands that change the security configuration of the L-3 eSRVIVR® Cockpit Voice and Flight Data Recorder. Once the AES key is loaded, the received data can utilize the cryptographic functionality of the eSRVIVR, which is assuming an implied Crypto Officer Role. 905-E6247-86 Rev. B 16 eSRVIVR CVFDR Security Policy 2.5.3. Services Key zeroization will be performed when the Zeroize discrete pin generates an interrupt, or when a serial “Zeroize Key” command message is received. Key zeroization will also be performed when a “Reset to Factory” command message is received. The “Zeroize Key” command is used to delete the current cryptographic key that is stored in the recorder. This command is not password protected and can be sent by any operator. The “Zeroize Key” command is unprotected by design. All of the recorder’s data encryption capability is disabled after this command is used. This command is intended for both Aircraft and GSE use. The “Encrypt” command is used within the Data Recorder by the Crypto Officer Role Implicitly, if the unit is keyed. This command is not separately callable. The “Set Crypto Key” command is used to set the cryptographic key that is required for data encryption. This command is intended to be used by the Crypto Officer. Therefore, the Crypto Officer password must be provided in order to use this command successfully. In addition, this command must be used at least once before any encryption can take place. This command is intended for GSE use. The “Set Password” command is used to set the password of the specified user (either Crypto Officer or User). Note that the Crypto Officer can set the password for either the Crypto Officer or the User, but the User can only set the password for the User. This command is password protected so a valid Crypto Officer password or valid User password must be provided for this command to be successful. This command is intended for GSE use. The “Validate Password” command is used within other API calls that require authentication before it can execute. This command is not separately callable. The “Get Crypto Status” command is used to get the status of various crypto items residing in the recorder. These items include the current encryption algorithm that is being used to encrypt the data, the version of the encryption algorithm, the total number of failed login attempts, and the total number of valid login attempts for all roles. This command is password protected so a valid Crypto Officer password or valid User password must be provided for this command to be successful. This command is intended for GSE use. The “Reset to Factory” command is used to reset the cryptographic information in the recorder to the same state as it was when it was manufactured. This command will Zeroize the cryptographic key so that all further data encryption is disabled. A new key must be set using the “Set Crypto Key” command before encryption is enabled. It will also reset the Crypto Officer password and the User password to their factory defaults. This command is intended to be used by the Crypto Officer. Therefore, the Crypto Officer password must be provided in order to use this command successfully. After successful completion of this command, the default factory Crypto Officer password must be provided for any command that needs a Crypto Officer password. This command is intended for GSE use. The “Perform Self-Tests” command forces the entire Recorder to restart and re-execute the Internal Built in Test (IBIT). This command is not password protected and can be sent by any operator. See the Self- Test section for a description of the test. The “Retrieve File Segment Auth” command is used to access the audit data saved in the Crypto Log Information Partition. These items include the time logged events for: Encryption Start, Encryption Stop, Crypto Officer Login, Crypto Officer Login Fail, Crypto Officer Password Change, Crypto Officer Password Change Fail, User Login, User Login Fail, User Password Change, User Password Change Fail, Crypto Key Load, Crypto Key Load Fail, and Crypto Key Zeroize. This command is password protected 905-E6247-86 Rev. B 17 eSRVIVR CVFDR Security Policy so a valid Crypto Officer password must be provided for this command to be successful. This command is intended for GSE use. 905-E6247-86 Rev. B 18 eSRVIVR CVFDR Security Policy 2.6. Physical Security The physical embodiment of the firmware module, in FIPS terminology, is defined as a multi-chip embedded cryptographic module. The module’s physical embodiment is made of all production-grade components and is enclosed in a stainless steel housing, Part Number: 8050417-3 (Housing, Main, SRVIVR), which surrounds all of the module’s internal components, including all hardware and firmware. The exterior components are painted to meet DO-160 or MIL-STD-810 environmental standards as applicable. A polysulfide sealant rubber, per AMS 3281 will provide the ability to detect any physical tampering by sealing any entry points on the outside surface of the CSMU. The entire CSMU is environmentally sealed by the application of polysulfide around the perimeters of the front cover and top cover, including all seams, screws, and connectors, providing an environmentally seal around the entire CSMU housing thus blocking any fluids, humidity, sand and dust. In addition, the MIL-C-38999 Series III connectors environmentally seal the CSMU power and communication interfaces. There will be four tamper evident labels (See Reference Documents 8501587-2 (LABEL, TAMPER- EVIDENT) and 8501599-1 (LABEL, HARDWARE, ESRVIVR) used to meet the tamper evidence requirements of FIPS 140-2 along with the environmental standards of DO-160 or MIL-STD-810 (as applicable). Tamper Evident Labels The unit will often be installed in hard to access locations on aircraft that do not allow access other than at unit installation, or when maintenance is required. Therefore, inspection to look for signs of physical tampering will only be performed during product installation and maintenance. The operator is never allowed to perform any maintenance that involves opening the case. All such maintenance shall be performed at the factory. Units that display evidence of tampering shall be declared defective, and returned to the factory. The investigation of tampering will be treated as a maintenance defect to be serviced by authorized personnel at the factory. 905-E6247-86 Rev. B 19 eSRVIVR CVFDR Security Policy Physical Security Mechanisms Recommended Frequency of Inspection/Test Guidance Inspection/Test Details Stainless steel housing Installation/Removal Treat as a Maintenance Defect. Polysulfide sealant rubber Installation/Removal Treat as a Maintenance Defect. Tamper evident label Installation/Removal Treat as a Maintenance Defect. Note: * - For Inspection/Test Guidance, see the Installation/Maintenance manual. TABLE 5 - INSPECTION/TESTING OF PHYSICAL SECURITY MECHANISMS 2.7. Operational Environment The operational environment is non-modifiable and thus not applicable to FIPS 140-2, section 4.6.1 for this firmware module. The cryptographic module in the eSRVIVR® Cockpit Voice and Data Recorder (Hardware version: 1493200-3000) runs on an embedded Nucleus Plus 1.15.6 Real-Time Operating System (RTOS) by Mentor Graphics. 2.8. Cryptographic Key Management The module implements the following FIPS-approved algorithms:  AES-128, AES-192, AES-256 (ECB mode, encryption only) – FIPS 197 Validation #3754. The module does not implement any non-approved algorithms. Key Type Generation Storage Use CSP AES Key 128, 196, 256 bit Externally generated Held in volatile memory Encrypts voice AES key and electronically in plaintext. Stored in and/or flight data per loaded via the SRVIVR non-volatile memory configuration, and is GSE Interface. and retrieved on reboot. not output from the module. User/Crypto- 8-15 character Entered into the Stored in non-volatile Used for User & CO Officer ASCII password module SRVIVR via memory as plaintext. Role Authentication. Password the GSE over the Serial Interface. TABLE 6 - LISTING OF MODULE SUPPORTED KEY AND CRITICAL SECURITY PARAMETERS Crypto Access Type Description x - Role Applies to specified role. s - Store Storage in volatile and non-volatile memory. u - Use Uses Key and CSPs internally for encryption / decryption services. z - Zeroize Zeroizes the AES Key. TABLE 7 - ACCESS TYPES LEGEND 905-E6247-86 Rev. B 20 eSRVIVR CVFDR Security Policy Service (API Calls)  CSP  Role  Type of Access to CSP  Crypto‐Officer Password  Crypto‐Officer Role  No Role Required  User Password  User Role  AES Key    Validate Crypto‐Officer Password  (R)ead Password  (used within other API calls)  u  x  Set Password (Crypto Officer)  u,s  x  (W)rite Password  Validate User Password  (R)ead Password  Not  Used1 (used within other API calls)  u  x  1 Set Password (User)  u,s  u  x  x  (W)rite Password  Set Crypto Key  s  u  x  (W)rite Key  Zeroize Key  z  x  (W)rite Key  2 Encrypt  u  x  (E)xecute  (W)rite Password and  Reset to Factory  z  u  x  Key  Perform Self‐Tests  x  (R)ead Key (internally)  Get Crypto Status  u  u  x  x  (R)ead Password  Retrieve File Segment Auth      u    x    (R)ead Password  Notes: 1 – The Crypto Officer password is validated when the Crypto Officer changes the user password. 2 – All CM encryption falls under the Crypto Officer Role Implicitly, if the unit is keyed. TABLE 8 - CSP SERVICE VERSUS CSP ACCESS 2.9. Self-Tests If any of the self-tests fail, the module will output an error indication on the CVFDR Maintenance pin or the Data Fault pin (see below) and the Crypto Module in the eSRVIVR® will stop all cryptographic operations and discontinue operating in normal mode (encryption of voice and flight data halts and no data designated for an encrypted data partition is recorded). The eSRVIVR® Crypto Module performs the following self-tests: 905-E6247-86 Rev. B 21 eSRVIVR CVFDR Security Policy 1. Conditional tests  There are not applicable conditional tests. 2. Power up and on-demand tests  Cryptographic Algorithm Known Answer Tests (KAT): The algorithms (AES-128, AES-192, and AES-256 in ECB mode) are tested by using a known key, known plaintext data, and known encrypted data. The plaintext data is then encrypted and compared with the known encrypted data; the test passes if the final encrypted data matches the known encrypted data, otherwise it fails. If the Cryptographic Algorithm Known Answer Tests (KAT) fail, the eSRVIVR® Crypto Module asserts a status bit (for the Report Status command) which will drive the CVFDR Maintenance pin. The module then transitions to the non-recoverable error state.  Firmware Integrity Test: Upon startup the cryptographic module performs a 16-bit CRC of the program memory where it resides and any associated constants stored in memory as part of its self-tests. A failure of the cryptographic module’s CRC value compared to the expected CRC value will assert a status bit (for the Report Status command) which will drive the CVFDR Maintenance pin. The module then transitions to the non-recoverable error state. The eSRVIVR uses an industry standard CRC-16 (CCITT) polynomial (X^16 + X^12 + X^5 + 1) for authentication of Crypto module code and constant data. The CRC-16 algorithm is implemented via a table lookup method.  Key CRC Test: Any failure that occurs while trying to validate the cryptographic key will cause an assertion of a status bit (for the Report Status command) which will drive the Data Fault pin. The module then transitions to the recoverable error state. Once the module is in the power off state, powering the unit on will initiate the power-on self-tests. All of the power-on self-tests are run as soon as possible after the system has been initialized. This occurs before any of the data collection tasks that use the crypto module are running. None of the self-tests require any inputs or actions by the operator. There are two ways to check for the success or failure of the self-tests: 1) Output Pin Interface – Two pins provide an electrical means of checking for self-test failures: a. CVFDR Maintenance Pin – Pin 18 of the J-1 connector can be used to check for the success or failure of the Known Answer Test and the Firmware Integrity Test. Pin 18 will be at the standard ground voltage level (i.e. asserted) if the Known Answer Test or the Firmware Integrity Test has failed. Pin 18 will be open/not connected (i.e. not asserted) if the Known Answer Test and the Firmware Integrity Test have passed. Note that this pin is used to report the success or failure of crypto-specific self-tests as well as the non-crypto self-tests so an assertion on this pin doesn’t necessarily mean that only the Known Answer Test or the Firmware Integrity Test has failed. b. Data Fault Pin – Pin 19 of the J-1 connector can be used to check for the success or failure of the Key Load Test. Pin 19 will be at the standard ground voltage level (i.e. asserted) if the Key Load Test failed. Pin 19 will be open/not connected (i.e. not asserted) if the Key Load Test passed. Note that this pin is used to report the success or failure of crypto-specific self- tests as well as the non-crypto self-tests so an assertion on this pin doesn’t necessarily mean that only the Key Load Test has failed. 2) Report Status Command – The “Report Status” GSE command can be used for a detailed report of the success or failure of the self-tests. The crypto-specific self-test results are part of the “Processor” status word. Results are given for the following tests: 905-E6247-86 Rev. B 22 eSRVIVR CVFDR Security Policy a. Crypto Algorithm (Known Answer Test) Failure b. Crypto CRC Failure c. Crypto Key Load Failure 2.10. EMI/EMC Compatibility The eSRVIVR® Data Recorders meets MIL Standard 461F emissions requirements that are more stringent than the level 2 - EMI/EMC requirements specified by 47 Code of Federal Regulations, Part 15, Subpart B, Unintentional Radiators, Digital Devices, Class A (i.e., for business use) The L-3 encryption module meets all applicable FCC requirements by similarity to the MIL-STD-461F radiated emissions (RE102) testing. The applicable FCC Emissions requirement (for radio) specifies that the radiated coverage runs from 30 MHz to 1 GHz which aligns with the much broader limits of MIL-STD 461F in that spans the frequency range 10 kHz – 18 GHz. 2.11. Design Assurance Microsoft Visual SourceSafe CMS is used as the configuration management system to control the source code versions and releases of the L-3 AR eSRVIVR® cryptographic module. The CMS automatically records modifications made to the source code set, noting the date and time. The system retains all intermediate versions of the source code back to the original implementation. Each file checked into the CMS has a version number that is initialized to 1. This version number is incremented by 1 each time the file is revised (by first checking out the file, revising the file, and then checking the file back into CMS). The information tracked by the CMS allows the engineering team to identify the specific version of each file that is required to build an executable configuration. The CMS system has facilities for restricting or completely eliminating modifications to controlled items, which are used to control configurations. This mechanism, combined with a regular backup routinely administered by systems administration staff, ensures the ability to retrieve and build any given firmware configuration. The hardware drawings and circuit schematics are maintained in a separate archive. This archive keeps tracks of the version number and date of each hardware drawing and schematic. Every new file (drawing or schematic) is assigned a unique version number. The version number starts at 1 and is incremented when newer versions are added to the archive. All versions of a file are kept in the archive and are never deleted. The access to the archive is limited to a few authorized personnel that can retrieve files and add to the archive. Once stored in the archive, a file cannot be modified and stored with the same version number. The Project-level Integrated Compliance Management System is used as the primary interface between the Project Team, Customer and/or the FAA for the L-3 AR eSRVIVR® cryptographic module. This Web-based system is comprised of a SecureWeb Management System, Problem Reporting Management System, Document Review Management System, Meeting and Action Item Management System, Requirements Traceability Management System and Coverage Analysis Management System. All systems were specifically developed to show compliance with the objectives of DO-178B and DO-254. The Microsoft SharePoint web application platform is used for editing and tracking changes to documents. A SharePoint database record is kept for each document; it also provides a hyperlink to the document. The system maintains and keeps track of separate versions of every file that is stored in the database. 2.12. Delivery and Operation 905-E6247-86 Rev. B 23 eSRVIVR CVFDR Security Policy The L-3 AR eSRVIVR® CVFDR is delivered with all necessary firmware installed and configured for proper operation. The operator is required to turn the Data Recorder on and follow the operating instructions from the user’s guide to operate the device. 2.13. Guidance Administration and maintenance of the L-3 AR eSRVIVR® CVFDR is accomplished via the commands listed in section 2.5. The L-3 AR GSE software package (eSIS-2) provides an easy way for the Crypto Officer or the User to execute these commands. Details of the wiring needed to power, run, and monitor the L-3 AR eSRVIVR® CVFDR is given in the user’s guide. 2.14. Mitigation of Other Attacks Other Attacks Mitigation Specific Mechanism Limitations N/A N/A N/A TABLE 9 - MITIGATION OF OTHER ATTACKS The eSRVIVR® cryptographic module does not employ security mechanisms to mitigate specific attacks. 905-E6247-86 Rev. B 24 eSRVIVR CVFDR Security Policy APPENDIX A A.1 Password Strength The strength of the passwords used to gain access to the Crypto-Officer role or the User role is calculated as shown below. To calculate the probability of a successful random attempt, we find cardinality of the union of n sets: 1) Start with 95 ASCII printable characters for the principle of inclusion–exclusion (95^8) 2) Next, exclude (subtract): a. All passwords with no lowercase characters (69^8) b. All passwords with no uppercase characters (69^8) c. All passwords with no digit characters (85^8) d. All passwords with no special characters (62^8) 3) Next, include (add): a. All passwords with no lowercase characters AND no uppercase characters (43^8) b. All passwords with no lowercase characters AND no digit characters (59^8) c. All passwords with no lowercase characters AND no special characters (36^8) d. All passwords with no uppercase characters AND no digit characters (59^8) e. All passwords with no uppercase characters AND no special characters (36^8) f. All passwords with no digit characters AND no special characters (52^8) 4) Next, exclude (subtract): a. All passwords with only lowercase characters (26^8) b. All passwords with only uppercase characters (26^8) c. All passwords with only digit characters (10^8) d. All passwords with only special characters (33^8) 5) Result: 95^8 – (69^8 + 69^8 + 85^8 + 62^8) + (43^8 + 59^8 + 36^8 + 59^8 + 36^8 + 52^8) – (26^8 + 26^8 + 10^8 + 33^ 8) = 3,025,989,069,143,040 The probability of a successful random attempt is one in 3,025,989,069,143,040. 905-E6247-86 Rev. B 25