Synopsis detail

PRESOLICITATION NOTICE
Subject:70--Pre-Solicitation for Trusted Handheld Platform (information only)
Synopsis Date:Feb 23, 2012
Contracting Office
Address:
M67854 MARINE CORPS SYSTEMS COMMAND 2200 Lester Street Quantico, VA
NAICS Code:334290 Other Communications Equipment Manufacturing
Classification Code:70 - General Purpose Information Technology Equipment
Solicitation Number:M6785412R2408
Response Date:Apr 06, 2012
Archive Date:May 06, 2012
Contact Points:Edward McGrail 703-432-3148 Edward McGrail - Contract Specialist, Edward.McGrail@usmc.mil, Ph# 703-432-3148, PLEASE USE EMAIL: pg_11_trusted_handhld@usmc.mil FOR ALL QUESTIONS.
Description:This DRAFT Statement of Objectives (SOO) is for informational purposes only. The actual solicitation will be posted in approximately 90 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.0 Purpose.

The purpose of this procurement is 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.

3.0 Program Goals/Scope

The scope of this solicitation covers the Marine Corps’ requirements for secure mobile handheld devices. At the conclusion of each period of performance the contractor must deliver a multiple domain capable architecture implemented on mobile devices including the deliverables listed in the CDRLs (See exhibits A0001 through A0009).

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 offeror’s understanding of all aspects of the effort to be performed by eliminating unnecessary ‘how to’ instructions historically contained in a Government provided SOW. The government assumes the offeror will leverage their internal research and development budgets with a common understanding that the resulting technology supports much larger interests.

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 commercial enterprise 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 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.0 Minimum Requirements.

5.1 Description.

Exhibit (1), represents a high level description of the governments desired device architecture. Use the reference architectures described in Exhibit (1) as the framework for proposing a solution to this solicitation. The following list of requirements represents the government’s minimum device characteristics. The paragraphs provide the governments rationale behind each requirement. All proposed architectures must, at an absolute minimum, include all of the following characteristics.

5.1.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.1.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.1.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.1.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.1.5 Access to security critical code and Configuration Management (CM) systems. The government requires access to security critical code and the developer’s CM systems for the purposes of conducting certifications and accreditation evaluations. If necessary, the government evaluators are willing to travel to vendor site for code review. The government requires access to the above mentioned security critical code and developer’s CM systems no later than the delivery of the initial devices.


5.2 Optional Capabilities

5.2.0 Description. Submitted proposals are not required to meet any optional capabilities. However, the optional capabilities represent the government’s desire for a more secure architecture. The requirements are divided in groups based on desirability.

5.2.1 Desirable Capabilities (Most Desired)

5.2.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.2.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.2.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.2.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.2.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.2.2 Desirable Capabilities (More Desired)

5.2.2.1 Device variations. To receive 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.2.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.2.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.2.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.2.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.2.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.2.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.2.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.2.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.2.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.2.2.8.1 Enterprise Reset – the ability to locally reset the device to original enterprise provisioned state.
5.2.2.8.2 Pristine Reset - the ability to locally reset the device to initial factory state.
5.2.2.8.3 Remote Reset - the ability to remotely activate a pristine or enterprise reset.

5.2.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.2.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.2.2.10 Tamper Evident Hardware. The devices’ security critical hardware shall be tamper evident.. This requirement is intended to provide some additional hardware protections against reverse engineering and malicious modifications.

5.2.3 Desirable Capabilities (Desired)

5.2.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.2.3.1.1 Secure Boot Loader. Attestation shall be provided for the boot process to include the isolation technology.
5.2.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.2.2.1.3 Supervisor Domain. Configuration parameters shall be verified including the executable of additional processes installed in the supervisor domain.
5.2.2.1.4 Domains other than the Supervisor Domain. Integrity checks shall be performed as those domains are loaded.

5.2.3.2 External Cryptography. The devices shall support external cryptography. For example, with 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.2.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.2.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.2.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.2.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.2.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.2.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.

6.1.9 Cellular power amp. Cellular power amp A device that increases the power of an RF cellular signal.

6.1.10 Cellular transceiver. A device that transmits and receives data over a cellular network.

6.1.11 Domain. An environment or context that includes a set of system resources and a set of system entities that have the right to access the resources as defined by a common security policy, security model, or security architecture.

6.1.12 Earpiece. A part, as of a telephone receiver, that fits in or is held next to the ear.

6.1.13 Global Positioning System (GPS). Global Positioning System (GPS) receiver. A receiver that determines the geographic location of the associated antenna based on signals from the GPS satellite constellation.

6.1.14 Graphics Processor. A secondary processor used to speed up the display of graphics.

6.1.15 Handheld Device . Very small, lightweight device which provides functionality approaching that of a laptop computer, typically having a display screen with touch input and/or a miniature keyboard.

6.1.16 Hardware Root of Trust. A hardware store for cryptographic keys (e.g., Trusted Platform Module).

6.1.17 Implementation. The executable instantiation of the system.

6.1.18 Implementation representation. The detailed internal workings of the security functions. This may be software source code, firmware source code, hardware diagrams and/or chip specifications.

6.1.19 Isolation Technology. A mechanism that provides domain separation, process isolation, and resource encapsulation. Examples are separation and security kernels

6.1.20 Keypad. A set of buttons arranged in a block or "pad" which usually bear digits, symbols and usually a complete set of alphabetical letters.

6.1.21 Liquid Crystal Display (LCD) Controller. A device that converts pixel or text data into the raster signals used by an LCD display.

6.1.22 LCD Display. A thin, flat electronic visual display that uses the light modulating properties of liquid crystals (LCs).

6.1.23 Microphone. A device for converting sound waves into analog electrical signals, which may then be amplified.

6.1.24 Multi-Core Processor. The unit that reads and executes program instructions, which are fixed-length (typically 32 or 64 bit) or variable-length chunks of data.

6.1.25 Negated And (NAND) Flash. Nonvolatile memory that retains state without power.

6.1.26 Personal Area Network (PAN). Computer networks used for communication among digital devices (including telephones and PDAs) that are close to one person.

6.1.27 Power Management. A feature that turns off the power or switches the system to a low-power state when inactive and optimizes the amount of power used during operation.

6.1.28 Robustness. Measure of confidence with respect to a set of properties of a system to operate as required, designed, and expected throughout its lifecycle ensuring essential services, coping with faults, failures, unexpected interactions and malicious activities.

6.1.29 Secure boot. The process of reaching an attestable secure initial state.

6.1.30 Secure Boot Loader. A boot loader that achieves an attestable secure initial state for the process(es) being loaded into memory for execution.

6.1.31 Security Domains. A domain that implements a security policy and is administered by a single authority.

6.1.32 Security Kernel. A security kernel binds internal sensitivity labels to exported resources, and mediates access by subjects to other resources according to a partial ordering of the labels defined in an internal policy module.

6.1.33 Separation Kernel. Hardware and/or firmware and/or software mechanisms whose primary function is to establish, isolate and separate multiple partitions and control information flow between the subjects and exported resources allocated to those partitions.

6.1.34 Speaker. A device that converts analog electrical signals into the equivalent air vibrations in order to make audible sound.

6.1.35 Synchronous Dynamic Random Access Memory (SDRAM) . A dynamic random access memory (DRAM) that is synchronized with the processor’s memory bus.

6.1.36 System Administrator Guide. The guide used by a person in charge of managing and maintaining a computer or telecommunication system.

6.1.37 System-on-a-Chip (SoC). Refers to integrating all components of a computer or other electronic system into a single integrated circuit (chip). It may contain digital, analog, mixed-signal, and often radio-frequency functions – all on a single chip substrate.

6.1.38 Supervisor Application. Software executing under the control of the Supervisor domains manager. Applications are often programs designed for end users.

6.1.39 Supervisor Domain. A privileged domain that allocates device resources (including external interfaces) to the user domains and mediates user domain access to those resources..

6.1.40 Supervisor Manager. Privileged software (i.e., an operating system) within the Supervisor domain that allocates domain resources to executing applications and provides services to those applications.

6.1.41 Touch screen controller. The monitor screen that can detect and respond to something, such as a finger or stylus, pressing on it.

6.1.42 Trusted Boot Loader. The boot loader architecture and implementation that provides for the integrity of the boot sequence.

6.1.43 Trusted Path. A mechanism by which a user (through an input device) can communicate directly with the security functions of the information system with the necessary confidence to support the system security policy. This mechanism can only be activated by the user or the security functions of the information system and cannot be imitated by un-trusted software.

6.1.44 Trusted Platform Module (TPM). A micro-controller with cryptographic functionality to securely store and process cryptographic keys.

6.1.45 User Application. Software executing under the control of the User domains manager. Applications are often programs designed for end users.

6.1.46 User Domain. A domain within the device that operates with less privilege than the Supervisor domain and uses resources allocated to it by the Supervisor domain.

6.1.47 User Manager. Privileged software (i.e., an operating system) within the User domain that allocates domain resources to executing applications and provides services to those applications.

6.1.48 Universal Serial Bus (USB) An industry standard connection technology for connecting peripheral devices to a computer.

6.1.49 Wide Area Network (WAN). A computer network in which the computers connected may be far apart, generally having a radius of half a mile or more.

6.1.50 Wi-Fi transceiver. A device that transmits and receives on a high-frequency wireless local area network (WLAN).

6.1.51 Wireless Local Area Network (WLAN). A local area network that uses high frequency radio signals to transmit and receive data over distances of a few hundred feet; uses ethernet protocol.

NECO Footer Feedback Clauses Numbered Notes Abbreviations Classification Codes NECO Links NECO FAQ Submit an Offer Business Opportunities Synopsis Database NECO Vendor Registration NECO Home United States Navy United States Marine Corps Buyer Login