N251-024 TITLE: Self-Hosted Certificate-Key Management Server
OUSD (R&E) CRITICAL TECHNOLOGY AREA(S): Advanced Computing and Software;Integrated Sensing and Cyber
The technology within this topic is restricted under the International Traffic in Arms Regulation (ITAR), 22 CFR Parts 120-130, which controls the export and import of defense-related material and services, including export of sensitive technical data, or the Export Administration Regulation (EAR), 15 CFR Parts 730-774, which controls dual use items. Offerors must disclose any proposed use of foreign nationals (FNs), their country(ies) of origin, the type of visa or work permit possessed, and the statement of work (SOW) tasks intended for accomplishment by the FN(s) in accordance with the Announcement. Offerors are advised foreign nationals proposed to perform on this topic may be restricted due to the technical data under US Export Control Laws.
OBJECTIVE: Provide a Self-Hosted Certificate-Key Management Server (CKMS) hosted on Gigabit Ethernet Data Multiplex System (GEDMS) to allow for individual systems to communicate over encrypted channels.
DESCRIPTION: A CKMS is a specialized server or system designed for the management of digital certificates and cryptographic keys in a secure and organized manner. Digital certificates are used in public key infrastructure (PKI) systems to verify the identity of entities and secure communications over the internet. A CKMS focuses on the management of cryptographic keys that are associated with these certificates, ensuring they are generated, stored, and distributed securely. The Self-Hosted CKMS will provide a secure and (de)centralized way to manage certificates and keys for devices within a closed network. The CKMS will be designed to be scalable, extensible, and easy to use and administer.
CKMS is especially important in environments where digital certificates are widely used for authentication and data encryption, such as securing web communications with Secure Sockets Layer and Transport Layer Security (SSL/TLS), code signing, secure email, and many other applications. It ensures that the cryptographic keys and certificates are managed in a way that maintains their security and reliability.
Device certificates are digital certificates that enable mutual authentication and secure connections between two devices (i.e., machine-to-machine [M2M] communications) and is achieved using PKI. A device certificate is typically issued by an organization’s internal certificate authority, known as a private CA. The private CA will be internal to the organization (meaning, an organization issues its own certificates for use on its network).
GEDMS is a mission-critical system that provides IP-based network transport and the collection, processing and distribution of data across DDG 51 class destroyers. GEDMS is designed to provide high-speed data communication and networking capabilities to support a wide range of shipboard systems and applications, including command and control, radar, navigation, weapons systems, communications, damage control, and other mission-critical functions. It allows for the efficient and secure exchange of data among various shipboard systems and subsystems.
Key features and characteristics of GEDMS in a Navy context may include:
GEDMS is an integral part of DDG 51 class destroyers, helping to ensure the efficient operation and coordination of various Platforms and Enclaves on board. It plays a crucial role in supporting the Navy's mission and enhancing its capabilities in a network-centric warfare environment.
Given the critical nature, and the crucial role GEDMS provides in supporting the Navy’s mission, it’s imperative to ensure the integrity, confidentiality, and availability of the data transmitted across the network. The lack of secure device communication can provide attack vectors that make the GEDMS environment susceptible to Man-In-The-Middle (MITM) attacks, spoofed commands, and status message spoofing.
The Navy seeks a closed-network CKMS to provide a secure and centralized way to manage certificates and keys for devices within the closed network. The CKMS shall run on a single board computer with the following minimum specifications, Quad-Core X86 1.5Ghz CPU, 16GB RAM, 256GB internal storage, and two (2) network interfaces supporting the following types: 10/100/1000BASE-TX, 1000BaseLX, and 100BaseFX. The single board computer shall support Linux and Win10 Operating systems. The CKMS will be responsible for generating, distributing, renewing, and revoking certificates and keys, as well as auditing and logging all activity. To enhance security, mitigate vulnerabilities and protect the confidentiality and integrity of the GEDMS environment, the following steps should be considered to build, configure, and implement the CKMS solution:
To establish a secure and well-maintained CKMS for a closed network, it is imperative to systematically address various aspects.
Navy needs a Key Management server that is superior to what is commercially available, is able to operate in a self-contained environment, and is decentralized, so combat damage to the server will not disable ship network access. Currently, we are not aware of any Key Management Servers that meet these requirements. PMS 400D investigated this in the past and rejected the available candidates because they presented a single point of failure that is unacceptable in combat. Innovation will be needed to produce a robust cybersecurity solution.
Work produced in Phase II may become classified. Note: The prospective contractor(s) must be U.S. owned and operated with no foreign influence as defined by 32 U.S.C. § 2004.20 et seq., National Industrial Security Program Executive Agent and Operating Manual, unless acceptable mitigating procedures can and have been implemented and approved by the Defense Counterintelligence and Security Agency (DCSA) formerly Defense Security Service (DSS). The selected contractor must be able to acquire and maintain a secret level facility and Personnel Security Clearances. This will allow contractor personnel to perform on advanced phases of this project as set forth by DCSA and NAVSEA in order to gain access to classified information pertaining to the national defense of the United States and its allies; this will be an inherent requirement. The selected company will be required to safeguard classified material during the advanced phases of this contract IAW the National Industrial Security Program Operating Manual (NISPOM), which can be found at Title 32, Part 2004.20 of the Code of Federal Regulations.
PHASE I: Develop a concept for an improved device for a Self-Hosted CKMS that meets the requirements above. Demonstrate the feasibility of the concept in meeting Navy needs and establish that the concept can be developed into a useful product for the Navy. Feasibility will be established via computer modeling or other means deemed appropriate. The Phase I Option, if exercised, will include the initial design specifications and capabilities description to build a prototype solution in Phase II.
PHASE II: Develop a CKMS prototype, to include designing the CKMS architecture, database schema, user interface, APIs, and other software. The prototype will be tested to demonstrate its core functionality, such as certificate and key generation, distribution, renewal, and revocation. Additionally, the prototype will be tested at a Land Based Test Facility to ensure its suitability to shipboard use. The results of these tests will be used to refine the prototype into a design that will meet Navy requirements. Prepare a Phase III manufacturing and development plan to transition the CKMS to Navy use.
Begin by clearly defining the network's specific needs, encompassing device types, security levels, compliance standards, and scalability requirements. Select robust cryptographic algorithms that adhere to industry best practices for key generation and certificate signing. Establish a Certificate Authority (CA) responsible for validating device identities and signing certificates. Implement secure key storage mechanisms, such as Hardware Security Modules (HSMs), to safeguard cryptographic keys from unauthorized access. Enforce a robust access control mechanism, preferably Role-Based Access Control (RBAC), to restrict key and certificate management to authorized personnel. Develop functionality for the entire certificate lifecycle, including automated processes for generation, distribution, renewal, and revocation. Implement comprehensive logging and auditing features to ensure accountability and security in CKMS activities. Secure communication by encrypting data in transit using protocols like TLS. Employ monitoring tools and alerts to promptly identify and respond to suspicious activities. Establish regular backup procedures and a disaster recovery plan for quick restoration in case of failures or data loss. Ensure compliance with relevant industry standards and regulations such as X.509, PCI DSS, or HIPAA. Maintain comprehensive documentation for the CKMS, covering configuration details and guidelines for ongoing maintenance and troubleshooting. Conduct thorough testing in a controlled environment, encompassing functional, security, and performance aspects before deploying in the production environment. Keep the CKMS software and underlying systems up to date with the latest security patches to address emerging threats. Finally, provide training to administrators and users on proper key and certificate management practices to prevent inadvertent security issues. This holistic approach ensures the CKMS aligns with the specific requirements and compliance standards of the closed network, fostering a robust and secure key management infrastructure.
It is probable that the work under this effort will be classified under Phase II (see Description section for details).
PHASE III DUAL USE APPLICATIONS: Support the Navy in transitioning the CKMS to Navy use.
Commercial uses may be limited due to the security posture inherent in these types of Navy systems. Other military applications would include use on any network that requires an added level of security between the systems communications and interfaces with minimal disruption to the design of existing user.
REFERENCES:
1. Barker, Elaine and Smid, Miles. "A Framework for Designing Cryptographic Key Management Systems." NIST Information Technology Laboratory, August 2013. https://csrc.nist.gov/pubs/sp/800/130/final
2. Barker, Elaine and Smid, Miles. "A Profile for U.S. Federal Cryptographic Key Management Systems." NIST Information Technology Laboratory, October 2015. . https://csrc.nist.gov/pubs/sp/800/152/final
3. Barker, Elaine. "Recommendation for Key Management: Part 1 - General." NIST Information Technology Laboratory, May 2020. https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final
4. Barker, Elaine and Barker, William. "Recommendation for Key Management: Part 2 – Best Practices for Key Management Organizations." NIST Information Technology Laboratory, May 2019. https://csrc.nist.gov/pubs/sp/800/57/pt2/r1/final
5. "National Industrial Security Program Executive Agent and Operating Manual (NISP), 32 U.S.C. § 2004.20 et seq. (1993)." https://www.ecfr.gov/current/title-32/subtitle-B/chapter-XX/part-2004
KEYWORDS: Control System Network; Multimedia Communication; Digital Key Management; Cryptographic keys; Access Control; Key Management Server
** TOPIC NOTICE ** |
The Navy Topic above is an "unofficial" copy from the Navy Topics in the DoD 25.1 SBIR BAA. Please see the official DoD Topic website at www.dodsbirsttr.mil/submissions/solicitation-documents/active-solicitations for any updates. The DoD issued its Navy 25.1 SBIR Topics pre-release on December 4, 2024 which opens to receive proposals on January 8, 2025, and closes February 5, 2025 (12:00pm ET). Direct Contact with Topic Authors: During the pre-release period (December 4, 2024, through January 7, 2025) proposing firms have an opportunity to directly contact the Technical Point of Contact (TPOC) to ask technical questions about the specific BAA topic. Once DoD begins accepting proposals on January 8, 2025 no further direct contact between proposers and topic authors is allowed unless the Topic Author is responding to a question submitted during the Pre-release period. DoD On-line Q&A System: After the pre-release period, until January 22, at 12:00 PM ET, proposers may submit written questions through the DoD On-line Topic Q&A at https://www.dodsbirsttr.mil/submissions/login/ by logging in and following instructions. In the Topic Q&A system, the questioner and respondent remain anonymous but all questions and answers are posted for general viewing. DoD Topics Search Tool: Visit the DoD Topic Search Tool at www.dodsbirsttr.mil/topics-app/ to find topics by keyword across all DoD Components participating in this BAA.
|
1/19/25 | Q. | What is the TPS and concurrency, and the required response time? We understand that some transactions, such as RSA key generation, will require higher response times. |
A. | The transaction per second and concurrency depend on the different type of ship configuration. I am unable to provide the number of users and different configuration. | |
1/19/25 | Q. | Can you be specific regarding the number of expected nodes, and if not possible, can you please provide the scale of the number nodes required, perhaps in terms of the highest number possible? Thanks. |
A. | The minimum expected nodes will be 2, a primary and back up node. | |
1/19/25 | Q. | Do you require key generation and the KMS to be FIPS 140-3 compliant, and if so, at what level (1,2, or 3). Alternatively, can the key generation and KMS be common criterion (CC) compliant? |
A. | There is no requirement to be FIPS 140-3 compliant. | |
1/19/25 | Q. | Please describe any relevant requirements for CNSA 2.0 (or generally DOD) cryptography for commercial systems transitioning to post-quantum cryptography. |
A. | I am not sure if there are DoD cryptography requirements. The write up states “Select robust cryptographic algorithms that adhere to industry best practices for key generation and certificate signing.” | |
1/13/25 | Q. |
|
A. |
|
|
1/13/25 | Q. | Per SBIR Program Document N251-024, the “Navy needs a Key Management server that is superior to what is commercially available, is able to operate in a self-contained environment, and is decentralized, so combat damage to the server will not disable ship network access. Currently, we are not aware of any Key Management Servers that meet these requirements. PMS 400D investigated this in the past and rejected the available candidates because they presented a single point of failure that is unacceptable in combat."
Our questions are as follows: 1. Which commercially available candidates were investigated in the past by PMS 400D? 2. Are the PMS 400D assessments of those commercial candidates available upon request, and if so, where can they be found or requested? 3. Did those assessments include evaluation of the cost structures of candidate solutions? |
A. | 1. The Navy will not list which commercial products were previously investigated. In summary, existing commercial product functional requirements are centered around a centralized key management server that is connected to the Internet 24/7. This SBIR is looking to fulfill a Navy need of an offline (closed network), decentralized (distributed) key management system that can easily maintain certificates for the lifecycle of the ship to support system authentication and data encryption.
2. N/a, see above 3. N/a, see above |