Security Module Solution for Electronic Control Units (ECUs) within US Army Ground Combat Vehicles.

As of 12/3/2020, New text is underlined. I. Description of Intent: The Army Contracting Command-Detroit Arsenal (ACC-DTA), in conjunction with US Army's Combat Capabilities Development Command (CCDC), Ground Vehicle System Center (GVSC), Ground System Cyber Engineering (GSCE) is issuing a Request for Information (RFI) for the procurement of a hardware security module (HSM) solution for electronic control units (ECUs) within US Army Ground Combat Vehicles. An HSM is a computing device that safeguards and manages digital keys, performs cryptographic functions for securing devices such as encryption, and digital signature verification and authentication. GVSC-GSCE requesting information on all potential cybersecurity solutions that address HSMs, however GSCE is not soliciting Intrusion Defense Systems (IDS) solutions at this time. The objective of the RFI is to better understand the availability and capabilities of products and the potential of the manufacturers. The information gathered by the Army through this RFI, along with other market investigation data, is solely intended for use by the U.S. Army and will not be shared with any company. Participation in this RFI provides an important opportunity to influence the Army's approach to procuring the hardware security module solution for electronic control units (ECUs) within US Army Ground Combat Vehicles. The U.S. Government is in no way liable to pay for or reimburse any companies or entities that respond to this announcement. Any costs incurred by interested companies in response to this announcement will NOT be reimbursed. This is a RFI ONLY and is not a solicitation for proposals; therefore, no questions will be taken at this time. A prototype project will not be awarded in response to this announcement. RESPONSE TIME: We thank you in advance, for your time and participation in this RFI. The U.S. Government requires all responses be returned by 3:00 pm Eastern Standard Time (EST), 10 December 2020 to Troy Haarala at troy.r.haarala.civ@mail.mil. PART 1. BUSINESS INFORMATION: Please provide the following Administrative information as the first section of your submission. 1. Manufacturer a. Company Name (and any former names): b. Traditional or Non-Traditional Contractor: *Non-Traditional Contractor: An entity that is not currently performing and has not performed, for at least the one-year period preceding the solicitation of sources by DoD for the procurement or transaction, any contract or subcontract for the DoD that is subject to full coverage under the cost accounting standards prescribed pursuant to section 1502 of title 41 and the regulations implementing such section (see 10 U.S.C. 2302(9)). c. Mailing Address: 2. Personnel Responding to this Survey a. Name: b. Title: c. Company Responsibility/Position: d. Telephone/Fax Numbers: e. E-mail address: PART 2. TECHNICAL QUESTIONNAIRE: Introduction/Background: Current US Army Ground Combat vehicles make use of several Electronic Control Units (ECUs), which have cybersecurity requirements for maintaining the confidentiality, integrity, and availability of the system and its communication networks. ECUs were designed without cybersecurity in mind and can be manipulated in malicious ways to hinder the vehicle's functionality. Thus, there is a need to secure the ECUs and their communications. The Ground Systems Cyber Engineering (GSCE) team has determined that one such way to do this is to examine the feasibility of using hardware security module technology suitable for ground combat vehicle components. GSCE is seeking solutions that will allow the DoD to: 1) if a cybersecurity anomaly occurs, provide rapid remediation to ensure full vehicle functionality is retained 2) ensure the authenticity of software and firmware updates of components, 3) protect the confidentiality of communications between components, and 4) safeguard and manage cryptologic items. Questions: 1.) Have you developed a hardware security module solution, hardware and/or software, with the intended purpose to be used on any commercial and/or US Army Ground Combat vehicle as it relates to ECUs? 2.) How does the hardware security module interface with other vehicle components? 3.) If a cybersecurity anomaly occurs, what remediation or mitigation strategies have you developed to ensure full vehicle functionality is retained? 4.) What is the anticipated method for updating the software, firmware, and cryptologic items that are used or employed by the hardware security module? 5.) What confidentiality and integrity methodologies are supported by your hardware security module solution? 6.) What network or communication protocols are supported by your hardware security module solution? 7.) What is the current Technology Readiness Level (TRL) (descriptions of TRL below) of the hardware security module technology? Technology Readiness Levels (TRLs) - Level 1: Basic Principles observed and reported: o Lowest level of technology readiness. Scientific research begins to be translated into applied research and development. Examples might include paper studies of a technology's basic properties. - Level 2: Technology concept and/or application formulated: o Invention begins. Once basic principles are observed, practical applications can be invented. Applications are speculative and there may be no proof or detailed analysis to support the assumptions. Examples are limited to analytic studies. - Level 3: Analytical and experimental critical function and/or characteristic proof of concept. o Active research and development is initiated. This includes analytical studies and laboratory studies to physically validate analytical predictions of separate elements of the technology. Examples include components that are not yet integrated or representative. - Level 4: Component and/or breadboard validation in laboratory environment. o Basic technological components are integrated to establish that they will work together. This is relatively - low fidelity compared to the eventual system. Example include integration of - ad hoc hardware in the laboratory. - Level 5: Component and/or breadboard validation in relevant environment. o Fidelity of breadboard technology increases significantly. The basic technological components are integrated with reasonably realistic supporting elements so it can be tested in a simulated environment. Examples include - high fidelity laboratory integration of components. - Level 6: System/subsystem model or prototype demonstration in a relevant environment. o Representative model or prototype system, which is well beyond that of TRL 5, is tested in a relevant environment. Represents a major step up in a technology's demonstrated readiness. Examples include testing a prototype in a high-fidelity laboratory environment or in simulated optional environment. - Level 7: System prototype demonstration in an operational environment. o Prototype near, or at, planned operational system. Represents a major step up from TRL 6, requiring demonstration of an actual system prototype in an operational environment such as an aircraft, vehicle, or space. Example include testing the prototype in a test bed aircraft. - Level 8: Actual system completed and qualified through test and demonstration. o Technology has been proven to work in its final form and under expected conditions. In almost all cases, this TRL represents the end of true system development. Examples include developmental test and evaluation of the system in its intended weapon system to determine if it meets design specifications. - Level 9: Actual system proven through successful mission operations. o Actual application of the technology in its final form and under mission conditions, such as those encountered in operational test and evaluation. Examples include using the system under the system under operational mission conditions.