SOLICITATION NOTICE
70 -- Pre-Solicitation for Trusted Handheld Platform (information only)
- Notice Date
- 11/21/2011
- Notice Type
- Presolicitation
- NAICS
- 334290
— Other Communications Equipment Manufacturing
- Contracting Office
- M67854 MARINE CORPS SYSTEMS COMMAND 2200 Lester Street Quantico, VA
- ZIP Code
- 00000
- Solicitation Number
- M6785412I2414
- Response Due
- 12/22/2011
- Archive Date
- 1/23/2012
- Point of Contact
- Sharon Edwards 703-432-3151 Sharon Edwards
- E-Mail Address
-
.edwards@usmc.mil<br
- Small Business Set-Aside
- N/A
- Description
- This DRAFT Statement of Objective (SOO) is for informational purposes only. The actual solicitation will posted in approximately 60 days. 1.0 Background The current commercial off the shelf (COTS) mobile devices that are available on or off the Nationwide-Department of the Navy Wireless Contracts (NDWC) or the Army Air Force Blanket Purchase Agreements do not provide an approved architecture for accessing multiple enclaves (e.g., internet, Non-secure Internet Protocol Router Network (NIPR), Secure Internet Protocol Router Network (SIPR), etc.) and processing and storing sensitive information which could adversely affect national security if compromised. The National Security Agency offers a procurement method to government entities via IDIQ contracts for purchasing mobile devices capable of accessing multiple domains. The devices offered by these contracts do not meet the requirements listed in this solicitation. For example, the devices contain various technologies (Controlled COMSEC Item, (CCI)) that preclude them from being sold commercially. 2.0Purpose. The purpose of this procurement is to establish a working relationship between the government and commercial consortiums in order to advance the development of commercial mobile device technology, beneficial to the U.S. government (i.e., DoD) by providing a capability to access multiple security domains. After completion of the period of performance, it is planned that the devices will be commercially available to the general public and to the government via the federal wireless contracts (e.g., the Nationwide Department of the Navy s Wireless Contracts [NDWC], the Army Air Force Blanket Purchase Agreement [AAFBPA] and U.S. General Services Administration [GSA] contract, etc.). This intended multiple award procurement is needed to provide a mechanism for incentivizing the commercial industry consortiums to adopt government desired handheld device security characteristics. The resulting contract will be a means for the government to partner with commercial consortiums that are already developing technology similar to the government s handheld device security requirements. 3.0Program Goals/Scope The scope of this solicitation covers the Marine Corps requirements for secure mobile handheld devices. As part of the proposal submission for this solicitation the offerors must present a demonstration of the multiple domain technology that would satisfy the requirements listed in this solicitation. At the conclusion of each period of performance the contractor must deliver a multi-domain capable architecture implemented on mobile devices including the deliverables listed in CDRLs. The following paragraphs describe the basic objectives of the trusted handheld effort and are provided in lieu of a Government Statement of Work (SOW). This approach provides offerors the flexibility to develop cost effective solutions and the opportunity to propose innovative alternatives meeting the stated objectives. It also presents the Government with an opportunity to assess the offerors understanding of all aspects of the effort to be performed by eliminating unnecessary how to instructions historically contained in a Government provided SOW. 4.0 Objectives Proposed Program Implementation. The offerors shall propose their Performance-Based approach to achieve the requirements within the performance criteria listed in the minimum and optional requirements of the solicitation. The intent of the collaborative consortium between the government and industry is to establish clear requirements and collectively influence development of mobile devices towards including mutually beneficial security characteristics. The resulting framework should help reduce cost, speed time-to-market, and reduce complexity of the devices. Early collaboration in the development phases should help reduce the impact of long certification processes. The goal for the resulting technology is to become a standard commercial product offered by mobile device original equipment manufacturers using the same hardware and software technologies used in consumer-only devices. The resulting devices must support modular additions without re-engineering or re-architecting the solutions to meet the required security controls for the high security domains. The government assumes the partnered consortia will leverage their internal research and development budgets with a common understanding that the resulting technology supports much larger interests. The approach(es) shall: 4.0.1 Describe the offeror s approach to continually evolve the initial proposed product line into the next set of mutually beneficial mobile devices. For example, how does the offeror propose to penetrate the mobile commercial market to support broader market adoption? 4.0.2 Explain in as much detail as possible how domain separation, process isolation, and resource encapsulation is provided for the mobile device components such as the human machine interface (e.g., display and keyboard), multi-core processor, graphics processing unit, baseband processor, and the shared hardware root of trust. 4.0.3 Describe how the mobile devices security architecture embodies the security principles of modularity and simplicity. 4.1. Strategic Sourcing has been identified in this requirement. During the performance of the contract(s), the Government and the contractor(s) will work together, much like in a partnership, towards shared goals and objectives. The goals and objectives include: 4.1.1 Securely send voice, video, and data across multiple security domains using mobile devices without perceived degradation. 4.1.2 Mobile communications across multiple wireless networks (e.g., Personal Area Network [PAN], Wireless Local Access Netwok [WLAN], Wide Area Network [WAN]). 4.1.3 Produce secure mobile COTS devices. 4.1.4 Mobile communication interoperability with international networks. 5.1 Minimum Requirements. 5.1.0 Description. The following list of requirements represents the government s minimum set of desired device characteristics. The paragraphs provide the governments rationale behind each requirement. The paragraph headers are defined in paragraph 5.1. All proposed architectures must, at an absolute minimum, include all of the following characteristics. 5.2.1 Isolation Technology (e.g., separation kernel, security kernel, etc.). The isolation technology shall isolate the software components, control the intra-domain access and isolate the other resources on the devices. This capability is expected to support a wide range of highly sensitive security domains. The isolation technology shall provide trustworthy data paths for the user interfaces and peripherals. The base isolation technology shall be read-only to restrict after OEM build time (i.e., following the OEM s initial build). However, this will not eliminate the enterprise s ability to configure the isolation technology s policy enforcement (i.e., resource interaction). The isolation technology facilitates the ability for the user to securely access information residing on different domains within the device. 5.2.2 Multi-personality. The devices must be capable of supporting multiple personalities on a single handset. These personalities may manifest carrier operating systems or enterprise owned operating system. The intent is to provide a handheld device architecture that will support unmodified user managers (i.e., guest mobile operating systems) and prevent the unnecessary consumption of valuable computing resources. Example methods for obtaining multiple personalities include the use of: Advanced Reduced Instruction Set Computer (RISC) Machine [ARM] Virtual Extensions (VE), Intel Virtualization Technology (VT), etc. 5.2.3 Commercial Standards. All devices must leverage commercial standards for designs and documentation (e.g., device I/O). If the devices leverage commercial standards, then parallel developments are possible with minimal interoperability conflicts. 5.2.4 Common Product Line Architecture Across Multiple Platforms. The proposals must address how the proposed architecture will be developed for multiple handheld devices (e.g., smartphones, tablets, etc.). 5.3 Optional Capabilities 5.3.0 Description. Submitted proposals are not required to meet any optional capability. However, the optional capabilities represent the government s desire for a more secure architecture. Proposals that meet more of these capabilities will rank above others that fail to include these characteristics. The requirements are divided in groups based on desirability and listed within the groups in descending order of importance. 5.3.1 Desirable Capabilities (High) 5.3.1.1 Hardware root of trust (e.g., Trusted Platform Module[TPM]). A hardware root of trust shall be provided to facilitate secure key storage. 5.3.1.2 Trusted Boot Loader. The boot loader architecture and implementation shall provide integrity for the boot sequence. For example, the boot loader should be resistant to software attacks (e.g. jail breaking ). 5.3.1.3 Multiple Active User Domains. The devices shall execute multiple user domains simultaneously with each only having access to its assigned resources. If this optional requirement is chosen, the domain indicator option must be implemented (i.e., providing the user verification of the active domain.) 5.3.1.4 Domain Indicator. The devices shall securely indicate which domain has focus. This may be provided using an indicator separate from the primary display (i.e., touch screen) controlled by the supervisor domain. Alternately, reserved areas of the primary display (decoration) may be used to identify the domain with focus. The preferred indicator for screen decoration is a colored border outlining the visible screen of each domain. The color of the decoration associated with each domain shall be configurable. 5.3.1.5 Advanced Software Integrity Attestation. In addition to the device providing medium software integrity attestation, the measurement and attestation process shall be tied to a hardware root trust such as a TPM and have the ability to perform runtime measurement and attestation. 5.3.2 Desirable Capabilities (Medium) 5.3.2.1 Device variations. To get credit for this capability, the offeror shall propose and deliver at least three variations of handheld devices (i.e., smartphones, tablets, etc.). The intent is to meet different users requirements with regards to size, weight, and form factor. The devices shall include at least one device with a physical keyboard and one device without a physical keyboard (i.e., leveraging only a virtual keyboard). 5.3.2.2 Medium Software Integrity Attestation. The devices shall be capable of basic software integrity attestation in addition to providing manager and application attestation. ( i.e., the device shall verify the integrity of manager and applications.) 5.3.2.3 Policy Enforcement. The devices shall provide the ability to enforce security policies to meet the requirements of the carrier, enterprise and device owner. 5.3.2.3.1 Dynamically Defined Policy. The devices shall support system level policies that define the interactions between the software components and resources. The devices shall provide the ability to leverage enterprise management and support a diverse set of security goals. 5.3.2.3.2 Application. The devices shall support the installation of a third party device management application hosted in the supervisor domain. Having the management application running in the supervisor domain is intended to increase the integrity and availability of the application. Since the application is critical for controlling the security policy, the application shall reside in the supervisor domain. 5.3.2.4 Multi-core Processor. The devices shall use a multi-core processor. As multiple core technology begins proliferating in mobile devices, special attention needs to be given to the implementation. If the proposed solutions leverage multi-core processing, the resulting technology should help establish a baseline approach for further development. 5.3.2.5 Personality Creation Flexibility. The devices shall support the creation of an arbitrary number of domains and the ability to populate those domains with enterprise security solutions. 5.3.2.6 Fail Secure. The devices shall provide fail secure operation so that events that can result in unauthorized inter-domain data flows shall stop current operations and restart the devices or load a designated domain image. This must protect against unauthorized release of, or access to, sensitive information. 5.3.2.7 Fail for Availability. The devices shall provide fail for availability operation. The purpose is to allow corrupted virtual machines to restart. The devices shall have the ability to load master images when the guest images are corrupted. For example, if the environment within the guest image is corrupted and fails to operate, the device will restart and load the master image. 5.3.2.8 Memory Sanitization. The devices shall provide the ability to overwrite any physical location in flash memory. To meet this requirement the proposal must describe the overwrite capability and any involvement of bad block management and wear leveling mechanisms. 5.3.2.8.1 Enterprise Reset the ability to locally reset the device to original enterprise provisioned state. 5.3.2.8.2 Pristine Reset - the ability to locally reset the device to initial factory state. 5.3.2.8.3 Remote Reset - the ability to remotely activate a pristine or enterprise reset. 5.3.2.9 Hardware Integrity Verifications. There shall be a method to validate the integrity of the device hardware. Unauthorized component identification. Via external verification methods the device s hardware components shall be verified to include detecting unauthorized components. The purpose of external verification is to mitigate against unauthorized modifications of the hardware. 5.3.2.9.1 Power-On Self Test. At boot-up, the devices shall perform simple health checks and alerts the user if any failures are detected. 5.3.2.10 Tamper Evident Hardware. The device s security critical hardware shall be tamper evident.. This requirement is intended to provide some additional hardware protections against reverse engineering and malicious modifications. 5.3.3 Desirable Capabilities (Low) 5.3.3.1 Basic Software Integrity Attestation. The devices shall be capable measuring and attesting to the state of the user environment, security components and core system software. The following components are desired to verify the integrity of the software. The proposals must specify how a successful integrity check is displayed to the user. 5.3.3.1.1 Secure Boot Loader. Attestation shall be provided for the boot process to include the isolation technology. 5.3.3.1.2 Isolation Technology. There shall be a process that verifies the integrity of the isolation technology configuration parameters that are loaded on startup. 5.3.2.1.3 Supervisor Domain. Configuration parameters shall be verified including the executable of additional processes installed in the supervisor domain. 5.3.2.1.4 Domains other than the Supervisor Domain. Integrity checks shall be performed as those domains are loaded. 5.3.3.2 External Cryptography. The devices shall support external cryptography. For example, with the external cryptography functionality, the user could insert a secure digital (SD) card with an embedded microprocessor to facilitate an encryption capability independent of the inherent processors. The intent of this requirement is to facilitate data-at-rest and data-in-transit encryption for access to highly sensitive networks. 5.3.3.3 Suite B Cryptography. The devices shall contain the ability to encrypt data with a FIPS 140-2 and NSA certified implementation. The intent is to enable the devices to process sensitive data on U.S. Government networks. 5.3.3.4 Protected Storage. The devices shall provide data-at rest-protection for the domains. This may be accomplished through whole disk encryption, file system encryption, and OS image encryption. The selection of key, algorithm, and storage location shall be selectable per domain (e.g., hardware root of trust, Suite B SD microprocessor, or installed SD card). 5.3.3.5 Carrier aware dual personalities. The devices shall support multiple network personalities. The devices shall be configurable to assign the carrier identification information to different domains. For example, the devices could be equipped with a personal Subscriber Identity Module (SIM) and a business SIM where the personal SIM is paid for by the consumer, and the business SIM is paid for by the organization. Additionally, this facilitates the ability for the carrier identification information to support network authentication. For example, personal domain accesses network via personal SIM credentials and business domain access network via business SIM credentials). 5.3.3.6 Messaging. The devices shall provide message transport between supervisor and user domains. This shall include security relevant event messages originating from the isolation technology layer. Any message presented to user must be capable of being stored and accessible within an audit log. 5.3.3.7 Sideloading. The devices shall be capable of loading software and data through external interfaces. This provides the capability of loading software and data locally vice over- the-air. 5.3.3.8 Auditing. The devices shall be capable of auditing security relevant events (e.g., boot events, fail secure events, configuration changes, etc.). The devices shall protect the audit trail, provide a means of exporting the audit trail from the devices, and a means of clearing the audit trail. Understanding comprehensive internal auditing can monopolize the devices resources, the offerors must distinguish where each audit function will occur (i.e., internal to the device or in the enterprise). 6.0 Definitions 6.1.1 Accelerometer. A device for measuring acceleration that can be used to determine movement of the handheld device. 6.1.2 Application Processor. An IC (integrated circuit) that executes applications. 6.1.3 Assurance. Measure of confidence that the security features, practices, procedures, and architecture of an information system accurately mediates and enforces the security policy. 6.1.4 Audio Codec. A mechanism digitally encoding/decoding an analog signal. Most audio codecs are optimized for speech signals and provide compression of the data, at the cost of some loss of fidelity when the analog signal is recovered. 6.1.5 Baseband Processor. A processor that operates on signals whose frequency range is from approximately 0 Hertz to a specific cut-off frequency. 6.1.6 Battery. One or more electrochemical cells that convert stored chemical energy into electrical energy. 6.1.7 Bluetooth transceiver. A device that transmits and receives proprietary open wireless technology standard (BLUETOOTH)for exchanging data over short distances (using short wavelength radio transmissions in the ISM band from 2400-2480 MHz) from fixed and mobile devices, creating personal area networks (PANs) with high levels of security. 6.1.8 Camera. A device that records and stores photographic images in digital form.
- Web Link
-
FBO.gov Permalink
(https://www.fbo.gov/spg/DON/USMC/M67854/M6785412I2414/listing.html)
- Record
- SN02626635-W 20111123/111121234117-4cdcdf654514cd4a9031dbafc371d463 (fbodaily.com)
- Source
-
FedBizOpps Link to This Notice
(may not be valid after Archive Date)
| FSG Index | This Issue's Index | Today's FBO Daily Index Page |