You are here

Cloud Based Secure Handhelds for Missions requiring Mobility

Description:

OBJECTIVE: Securely connect mobile computing hardware to appropriate commercial and DoD/IC networks while maintaining data separation and commercial functionality. DESCRIPTION: DoD and IC users have come to expect one level of access to information via mobile technology at home and another, reduced level while on the job. While there are many valid reasons for this, specifically including restrictions on the access of classified material among others, it is potentially possible to reduce this gap by creating the ability for trustworthy"compartments"within mobile devices to securely connect with appropriate infrastructure. Many parts needed to solve this challenge already exist. Examples of ways to improve assurance of the mobile endpoint include the Trusted Platform Monitor, NSA"s SE Android and Citrix"XenClient XT, among many others. The first two options and their analogues could allow for the endpoint to launch applications in an extremely tamper-resistant manner, while the last option along with other hypervisor or separation kernels can also help provide trustworthy compartments to prevent inappropriate information sharing. Commercially available endpoints (cell phones, tablets, etc) provide multiple standardized ways to communicate with international infrastructure (3G/4G, WiFi, etc) as well as a large number of sensors (accelerometers, cameras, touch screen, microphone, etc), ever growing capacity to transmit, receive, store and process information and given their commercial acceptance & growth they provide the users with a general comfort level while utilizing their functionality. What does not yet exist is secure attestation of system state regardless of which one of multiple"compartments"are attempting to connect to appropriate remote services, be these cloud-based or otherwise. The ability to ensure only trustworthy processes are running on a mobile endpoint, enabled from a known good hardware and software state, regardless of separation into"compartments"or not, is a very important portion of the end-to-end connections needed. This works well today within a single"compartment", but the difficulties in any single compartment initiating the communications (as per several normal modes of operation of mobile commercial systems) have yet to be conquered. Thus this SBIR is intended to provide a prototype and method for secure attestation to remote assets regardless of which"compartment"on the mobile device initiates or receives the connection request. These attestations may be up to (but may not be limited to) some"measured launch environment"(MLE), in order to provide assurance that the underlying system maintains its trusted state. While ideally this would work regardless of the number or type of"compartments", it may be necessary to limit this breadth to some lesser scope. If so, justification of these limitations will need to be accomplished. Similarly, ideally this would not require any hardware modification of commercially available mobile endpoints (cell phones, tablets, etc). If there are necessary limitations, identifying and justifying those limits will be needed. Ideally, full commercially available functionality will also be preferred, but justified limitations may be acceptable. The resultant prototype must have detailed plans to be extensible to cover NIST SP 800-53 security controls as selected from the UCDMO Cross Domain Solutions Overlay (CDSO), as well as the guidance and requirements made available via the"Commercial for Classified"effort and Mobility Program sites from NSA (links below, Intelink-U account required for UCDMO CDSO). Any further limitations along similar lines to meet these security requirements will need to be identified and appropriately justified. PHASE I: Identify and detail a multi-compartment secure attestation of system state using commercial hardware & software as described above. Reuse existing capabilities where practical, or justify where impractical. Analyze security risks associated with these choices and identify options to mitigate them. The proposed system design must meet or exceed appropriate security controls as identified. PHASE II: Create a limited prototype product to implement the security design chosen. Include development of security relevant documentation covering concept of operations, a cross-referenced test plan for functional & security requirements, and test results. Demonstrate performance, functionality and security of the prototype. Identify and partner with one or more operational customer(s) for further development and productization. PHASE III: With an operational customer submit product for certification & accreditation. Simultaneously offer the product(s) to commercial vendors for use in high-assurance roles (healthcare, financial market, personal finances, etc). REFERENCES: 1. Unified Cross Domain Management Office"s Cross Domain Solutions Overlay, https://www.intelink.gov/sites/ucdmo/Docs/Documents/CDS_Overlay%20V1.docx 2. NSA Commercial Solutions for Classified site: http://www.nsa.gov/ia/programs/csfc_program/index.shtml. 3. NSA Mobility Program http://www.nsa.gov/ia/programs/mobility_program/index.shtml. 4. XenClient XT product page: http://www.citrix.com/English/ps2/products/subfeature.asp?contentID=2315434. 5. SELinux Project wiki page on SE Android: http://selinuxproject.org/page/SEAndroid.
US Flag An Official Website of the United States Government