SEARCH · Engineering Papers

Results for “Hardware Security”

Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.

SourceResearch connectionFrom yearThrough year

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

At least 91 records · Page 5

All sources NASA NTRS DOE OSTI

NASA NTRS2008

Space Science and the International Traffic in Arms Regulations: Summary of a Workshop

The United States seeks to protect its security and foreign-policy interests, in part, by actively controlling the export of goods, technologies, and services that are or may be useful for military development in other nations. "Export" is defined not simply as the sending abroad of hardware but also as the communication of related technology and know-how to foreigners in the United States and overseas. The U.S. government mechanism for controlling dual-use items--items in commerce that have potential military use is the Export Administration Regulations (EAR) administered by the Department of Commerce; items defined in law as defense articles fall under the jurisdiction of the Department of State and the International Traffic in Arms Regulations (ITAR). Because of the potential military implications of the export of defense articles, the ITAR regime imposes much greater burdens (on both the applicant and the government) than does the EAR regime during the process of applying for, and implementing the provisions of, licenses and technical-assistance agreements. Until the early 1990s export control activity related to all space satellites (commercial and scientific) was handled under ITAR. Between 1992 and 1996 the George H.W. Bush and the Clinton administrations transferred jurisdiction over the licensing of civilian communications satellites to the Commerce Department under EAR. In 1999, however, in response to broad concerns about Chinese attempts to acquire U.S. high technology, the U.S. House of Representatives convened the Select Committee on U.S. National Security and Military/Commercial Concerns with the People s Republic of China, also known as the Cox Committee. One of the many consequences of the Cox Committee's report was Congress's mandate that jurisdiction over export and licensing of satellites and related equipment and services, irrespective of military utility, be transferred from the Department of Commerce to the State Department and that such equipment and services be covered as defense articles under ITAR. Scientific satellites were explicitly included despite their use for decades in peaceful internationally conducted cooperative scientific research. It is widely recognized that the shift in regulatory regime from EAR to ITAR has had major deleterious effects on international scientific research activities that depend on satellites, spaceflight hardware, and other items that are now controlled by ITAR. Furthermore, contravening U.S. interests in attracting foreign students to U.S. universities, the capture of space technology by ITAR has caused serious problems in the teaching of university space science and engineering classes, virtually all of which include non-U.S. students. This report is a summary of a September 2007 workshop in which participants from the space research communities and the export-control administration and policy communities came together to discuss problems, effects, and potential solutions regarding the application of ITAR to space science. The principal themes and ideas that emerged from the discussions are summarized.

Finarelli, Margaret G.↗

NASA NTRS1976

Implementation of an experimental fault-tolerant memory system

The experimental fault-tolerant memory system described in this paper has been designed to enable the modular addition of spares, to validate the theoretical fault-secure and self-testing properties of the translator/corrector, to provide a basis for experiments using the new testing and correction processes for recovery, and to determine the practicality of such systems. The hardware design and implementation are described, together with methods of fault insertion. The hardware/software interface, including a restricted single error correction/double error detection (SEC/DED) code, is specified. Procedures are carefully described which, (1) test for specified physical faults, (2) ensure that single error corrections are not miscorrections due to triple faults, and (3) enable recovery from double errors.

Carter, W. C.↗

NASA NTRS1998

Issues and Methods for Assessing COTS Reliability, Maintainability, and Availability

Many vendors produce products that are not domain specific (e.g., network server) and have limited functionality (e.g., mobile phone). In contrast, many customers of COTS develop systems that am domain specific (e.g., target tracking system) and have great variability in functionality (e.g., corporate information system). This discussion takes the viewpoint of how the customer can ensure the quality of COTS components. In evaluating the benefits and costs of using COTS, we must consider the environment in which COTS will operate. Thus we must distinguish between using a non-mission critical application like a spreadsheet program to produce a budget and a mission critical application like military strategic and tactical operations. Whereas customers will tolerate an occasional bug in the former, zero tolerance is the rule in the latter. We emphasize the latter because this is the arena where there are major unresolved problems in the application of COTS. Furthermore, COTS components may be embedded in the larger customer system. We refer to these as embedded systems. These components must be reliable, maintainable, and available, and must be with the larger system in order for the customer to benefit from the advertised advantages of lower development and maintenance costs. Interestingly, when the claims of COTS advantages are closely examined, one finds that to a great extent these COTS components consist of hardware and office products, not mission critical software [1]. Obviously, COTS components are different from custom components with respect to one or more of the following attributes: source, development paradigm, safety, reliability, maintainability, availability, security, and other attributes. However, the important question is whether they should be treated differently when deciding to deploy them for operational use; we suggest the answer is no. We use reliability as an example to justify our answer. In order to demonstrate its reliability, a COTS component must pass the same reliability evaluations as the custom components, otherwise the COTS components will be the weakest link in the chain of components and will be the determinant of software system reliability. The challenge is that there will be less information available for evaluating COTS components than for custom components but this does not mean we should despair and do nothing. Actually, there is a lot we can do even in the absence of documentation on COTS components because the customer will have information about how COTS components are to be used in the larger system. To illustrate our approach, we will consider the reliability, maintainability, and availability (RMA) of COTS components as used in larger systems. Finally, COTS suppliers might consider increasing visibility into their products to assist customers in determining the components' fitness for use in a particular application. We offer ideas of information that would be useful to customers, and what vendors might do to provide it.

Schneidewind, Norman F.↗

NASA NTRS2017

[Network Design of the Spaceport Command and Control System]

I helped the Launch Control System (LCS) hardware team sustain the network design of the Spaceport Command and Control System. I wrote the procedure that will be used to satisfy an official hardware test for the hardware carrying data from the Launch Vehicle. I installed hardware and updated design documents in support of the ongoing development of the Spaceport Command and Control System and applied firewall experience I gained during my spring 2017 semester to inspect and create firewall security policies as requested. Finally, I completed several online courses concerning networking fundamentals and Unix operating systems.

Teijeiro, Antonio↗

NASA NTRS1966

Rocket engine vibration accurately measured by photography

High speed instrumentation camera focused on a partially masked light bulb which is securely mounted to the test fixture permits measurement of engine performance parameters when usual electronic vibration instrumentation is unavailable. Vibration is recorded as a light trace deviating from the light rays photographed in the static hardware condition.

Craig, K. A.↗

NASA NTRS1999

Partitioning in Avionics Architectures: Requirements, Mechanisms, and Assurance

Automated aircraft control has traditionally been divided into distinct "functions" that are implemented separately (e.g., autopilot, autothrottle, flight management); each function has its own fault-tolerant computer system, and dependencies among different functions are generally limited to the exchange of sensor and control data. A by-product of this "federated" architecture is that faults are strongly contained within the computer system of the function where they occur and cannot readily propagate to affect the operation of other functions. More modern avionics architectures contemplate supporting multiple functions on a single, shared, fault-tolerant computer system where natural fault containment boundaries are less sharply defined. Partitioning uses appropriate hardware and software mechanisms to restore strong fault containment to such integrated architectures. This report examines the requirements for partitioning, mechanisms for their realization, and issues in providing assurance for partitioning. Because partitioning shares some concerns with computer security, security models are reviewed and compared with the concerns of partitioning.

Rushby, John↗

NASA NTRS2017

Non-Maximally Decimated Filter Banks Enable Adaptive Frequency Hopping for Unmanned Aircraft Vehicles

In the last few years, radio technologies for unmanned aircraft vehicle (UAV) have advanced very rapidly. The increasing need to fly unmanned aircraft systems (UAS) in the national airspace system (NAS) to perform missions of vital importance to national security, defense, and science has pushed ahead the design and implementation of new radio platforms. However, a lot still has to be done to improve those radios in terms of performance and capabilities. In addition, an important aspect to account for is hardware cost and the feasibility to implement these radios using commercial off-the-shelf (COTS) components. UAV radios come with numerous technical challenges and their development involves contributions at different levels of the design. Cognitive algorithms need to be developed in order to perform agile communications using appropriate frequency allocation while maintaining safe and efficient operations in the NAS and, digital reconfigurable architectures have to be designed in order to ensure a prompt response to environmental changes. Command and control (C2) communications have to be preserved during "standard" operations while crew operations have to be minimized. It is clear that UAV radios have to be software-defined systems, where size, weight and power consumption (SWaP) are critical parameters. This paper provides preliminary results of the efforts performed to design a fully digital radio architecture as part of a NASA Phase I STTR. In this paper, we will explain the basic idea and technical principles behind our dynamic/adaptive frequency hopping radio for UAVs. We will present our Simulink model of the dynamic FH radio transmitter design for UAV communications and show simulation results and FPGA system analysis.

UAV↗

NASA NTRS2014

Scalable Asset Discovery, Vulnerability Scanning, and Penetration Testing for Remote Sites and Wireless Spectrums Utilizing an Embedded Linux Plug - PwniPlug and the Raspberry Pi B+ as a Sample Pen Test

All devices attached to the NASA KSC network are subject to security vulnerability scanning and/or penetration testing. In today's changing environment, vulnerable and/or unprotected systems can easily be overlooked. Systems that are not properly managed can become a potential threat to the operational integrity of our systems and networks. This includes all NASA (internal and external) information systems within NASA KSC Internet Protocol (IP) address space, and NASA KSC facilities. The Office of the Chief Information Officer (OCIO) recommends that all NASA Centers and information systems be subject to penetration testing on a regular interval in accordance with the guidelines identified by the National Institute of Standards and Technology (NIST). (ITS-HBK-2810.04-02A) Protecting information and equipment at NASA is an area of increasing concern. In addition to the CPU's on the network; Supervisory, Control and Data Acquisition (SCADA) systems are especially vulnerable because these systems have lacked standards, use embedded controllers with little computational power and informal software, are connected to physical processes, have few operators, and are increasingly also being connected to corporate networks. The scope of work is comprised of several individual components which together build upon previous work by Drew Branch, NASA KSC Intern. The Pwn Plug is the selected COTS (Commercial-Off-The-Shelf) device chosen to test simplification of mandatory IT Security tasks. The device will be utilized to provide services to NASA KSC and enable an assessment of infrastructure soundness and regulatory compliance in an efficient, economical, and business responsive manner. The Pwn Plug is designed as a pen testing appliance which provides a hardware platform that can support commercial penetration testing efforts at significantly reduced costs. The expected outcomes are: 1) External Penetration Testing, 2) Social Engineering, 3) Procedural Documentation, 4) Recommended Remediation Action Plan, 5) System Retest & Remediation Attestation and 6) Final Reports, out briefing and Presentation. Due to physical and material constraints beyond intern and mentor control, the project was redefined as a working pen-test scenario. Limitations of lab availability and tools dictated an academic exercise. This report was developed within the scenario guidelines suggested by the project mentor. The guidelines were to be creative in developing a Pen Test program for a client.

Penetration Testing↗

NASA NTRS2016

R2U2 in Space: System and Software Health Management for Small Satellites

In order for small but complex systems like rovers, SmallSats, or Unmanned Aircraft (UAS) to operate autonomously, they must have a real-time solution for assessing their own system health. System and Software Health Management (SHM) enables better detection of faulty sensors and software problems, and enables better fault management including mitigation of unpredicted fault scenarios in the absence of a human on-board. In recent work, we have developed a Responsive, Realizable, Unobtrusive Unit (R2U2) for on-board SHM of autonomous UAS and demonstrated its ability to detect faults during flight time. These faults, from sensor failures, to software problems, to malicious security attacks, can present as transient temporal faults that even humans are challenged to find. An R2U2 congfiuration is a modular combination of multiple types of temporal logic runtime observers with fault-specic Bayesian Nets and sensor filters. R2U2 reasons about both on-board hardware and software components; R2U2 itself can be instantiated as an independent FPGA (Field-Programmable Gate Array)-based conguration or as a software component running independently from other software on-board. Small satellites, such as CubeSats, also require on-board SHM and failure mitigation, as limited telemetry bandwidth does not allow the transmission of the entire system state for ground-based health management. However, the autonomous operation of satellites brings a set of challenges different from UAS, including the effects of radiation on non-rad-hard, low-cost components, and the harsher environment of space. We surmise that a new extension of R2U2 could be adapted to help better detect, for example, radiation errors in cheaper COTS (Commercial Off the Shelf) (not rad-hard) components often used in small space systems. Since small satellites often operate in coordination, we will also examine new ways of distributed monitoring of their communication and cooperation and real-time detection of off-nominal situations utilizing multiple satellites. This talk will discuss preliminary work and ideas for building on terrestrial success of system and software health management for the harsher, and differently challenging, environment of space.

Runtime Verification & Validation↗

NASA NTRSDate not supplied

The State of Cryptolib – The Open-Source Satellite Cryptography Library

What state would the world be in if all internet traffic was unencrypted? Imagine an alternate universe where you can plug a packet sniffing device into your home internet and capture the web traffic of the entire world. It seems obvious that this scenario is less than desirable. If we would not allow this for the internet, why would we allow this in the space domain? With the advent of open-source ground stations, commercial off the shelf hardware, and ground stations as a service, the barrier to entry for space communications is rapidly lowering. New players enter the space realm everydayevery day, and the presence of tools to allow apprentice evildoers the ability to exploit satellite communications is on the horizon. Not only are legacy missions at risk, but future missions are as well - particularly lower budget science missions with more stringent sciencesize, weight, and power constraints. that may find it difficult to utilize hardware-based encryption solutions. In terms of Civilian Aerospace, NASA Standard 1006 generally directs that missions "shall protect the command stack with encryption that meets or exceeds Federal Information Processing Standards (FIPS) 140". Fortunately, the Consultative Committee for Space Data Systems (CCSDS) has published an international standard on Space Data Link Security. The combination of these two forces has resulted in CryptoLib - an open-source, C-based, encryption library that aims to be CCSDS SDLS compliant. CryptoLib is designed to support smaller missions on a tight budget that may be subject to the more stringent command link encryption requirements. Additionally, CryptoLib serves as an underpinning in JPL's Key Management & Cryptography (KMC) suite and is also designed to function as a 'drop-in' for smaller missions. CryptoLib is in active development and currently provides Telecommand (TC), Telemetry (TM), and Advanced Orbiting Systems (AOS) encryption and decryption capabilities with a variety of encryption and authentication schemes. This presentation will report the latest features, current status, and future plans for CryptoLib.

open-source encryption↗

NASA NTRSDate not supplied

The State of CryptoLib – The Open-Source Satellite Cryptography Library

open-source encryption↗

NASA NTRS2003

Reconfigurable Hardware Adapts to Changing Mission Demands

A new class of computing architectures and processing systems, which use reconfigurable hardware, is creating a revolutionary approach to implementing future spacecraft systems. With the increasing complexity of electronic components, engineers must design next-generation spacecraft systems with new technologies in both hardware and software. Derivation Systems, Inc., of Carlsbad, California, has been working through NASA s Small Business Innovation Research (SBIR) program to develop key technologies in reconfigurable computing and Intellectual Property (IP) soft cores. Founded in 1993, Derivation Systems has received several SBIR contracts from NASA s Langley Research Center and the U.S. Department of Defense Air Force Research Laboratories in support of its mission to develop hardware and software for high-assurance systems. Through these contracts, Derivation Systems began developing leading-edge technology in formal verification, embedded Java, and reconfigurable computing for its PF3100, Derivational Reasoning System (DRS ), FormalCORE IP, FormalCORE PCI/32, FormalCORE DES, and LavaCORE Configurable Java Processor, which are designed for greater flexibility and security on all space missions.

Source record↗

NASA NTRS1979

Private sector involvement in civil space remote sensing. Volume 1: Report

A survey of private sector developers, users, and interpreters of Earth resources data was conducted in an effort to encourage private investment and participation in remote sensing systems. Results indicate positive interest in participation beyond the current hardware contracting level, however, there is a substantial gap between current market levels and system costs. Issues identified include the selection process for an operating entity, the public/private interface, data collection and access policies, price and profit regulation in a subsidized system, international participation, and the responsibility for research and development. It was agreed that the cost, complexity, and security implications of integrated systems need not be an absolute bar to their private operation.

Source record↗

NASA NTRS2011

Improvements to the Ionizing Radiation Risk Assessment Program for NASA Astronauts

To perform dosimetry and risk assessment, NASA collects astronaut ionizing radiation exposure data from space flight, medical imaging and therapy, aviation training activities and prior occupational exposure histories. Career risk of exposure induced death (REID) from radiation is limited to 3 percent at a 95 percent confidence level. The Radiation Health Office at Johnson Space Center (JSC) is implementing a program to integrate the gathering, storage, analysis and reporting of astronaut ionizing radiation dose and risk data and records. This work has several motivations, including more efficient analyses and greater flexibility in testing and adopting new methods for evaluating risks. The foundation for these improvements is a set of software tools called the Astronaut Radiation Exposure Analysis System (AREAS). AREAS is a series of MATLAB(Registered TradeMark)-based dose and risk analysis modules that interface with an enterprise level SQL Server database by means of a secure web service. It communicates with other JSC medical and space weather databases to maintain data integrity and consistency across systems. AREAS is part of a larger NASA Space Medicine effort, the Mission Medical Integration Strategy, with the goal of collecting accurate, high-quality and detailed astronaut health data, and then securely, timely and reliably presenting it to medical support personnel. The modular approach to the AREAS design accommodates past, current, and future sources of data from active and passive detectors, space radiation transport algorithms, computational phantoms and cancer risk models. Revisions of the cancer risk model, new radiation detection equipment and improved anthropomorphic computational phantoms can be incorporated. Notable hardware updates include the Radiation Environment Monitor (which uses Medipix technology to report real-time, on-board dosimetry measurements), an updated Tissue-Equivalent Proportional Counter, and the Southwest Research Institute Radiation Assessment Detector. Also, the University of Florida hybrid phantoms, which are flexible in morphometry and positioning, are being explored as alternatives to the current NASA computational phantoms.

Semones, E. J.↗

NASA NTRSDate not supplied

NASA's Moon to Mars Autonomous Habitat Status

NASA is developing a strategy for sending humans to the Mars vicinity, known broadly as the Moon to Mars (M2M) Campaign. A critical part of this campaign is the development of in-space and surface habitation systems capable of substantially extending human presence beyond Low Earth Orbit (LEO). Mars missions feature an in-space transit habitat capable of supporting crews of four on ~850-1200-day missions, including transit to and from Mars and time in Mars orbit. Surface and transit habitats are complex elements which must keep crewmembers healthy and productive in deep-space environments with limited resources, long rescue times in contingency situations, and communication delays; all within constrained mass, volume, and power budgets. These habitats provide crew both living and workspace as well as most of the resources needed to support crew life. For deep space habitats, automation needs to be employed due to latency and for significant amounts of time when the habitats are uncrewed. Automation of systems is possible in space applications, but there are limitations. Outside of the Earth’s (or any) magnetosphere, radiation environments are harsh to both the physical hardware and the software components. Radiation (charged particles and ionizing electromagnetic waves) degrades and damages the hardware and causes single event upsets (SEUs) in software. If the hardware is damaged, data can be lost, or control actions not made. For software, SEUs cause algorithms to result in different solutions, or incorrect commands to be sent out. This means that algorithms and hardware used for deep space systems are different than what is used on Earth. Radiation-tolerant hardware is generations behind the current state-of-the-art hardware. Recent NASA missions, such as James Webb Space Telescope, continue to rely on older technologies such as the RAD750 processor, and the most advanced processors are still single core and less than 1.5 GHz. There have been attempts to use higher performance processors, but these often take multiple mitigation steps to handle the radiation environments, which limits the processing power and/or throughput. Current techniques for radiation mitigation have been redundancies, voting, physical separation of hardware, encasing materials, under-clocking hardware, and more. Some radiation mitigation techniques do provide benefits such as having a redundant system to improve the probability that a system will be available when needed. Autonomous software systems will have fewer interactions with humans on deep space missions and therefore need to be able to handle more off-nominal conditions. Microgravity also complicates the autonomous aspects of the mission because autonomous systems are usually built from known deterministic states, but microgravity causes physical objects to shift and move changing the location an autonomous system placed the object. Not only does the software need to be reliable and deterministic, losing resources due to a software error is not only costly but detrimental to reputation. The combination of having lower performance hardware and having to be able to verify and deterministically run software and an ever-changing environment makes deep space autonomous systems more complicated. Multiple gaps have been identified including verification of autonomous software algorithms (including artificial intelligence and machine learning), higher performance processors (graphics and general purpose), high speed networks (onboard and transmissions), memory, power distribution, data security, and variations from these. These gaps need to be closed for more advanced systems to be deployed and reduce the size, weight, and power impacts on the habitats.

Scott B. Tashakkor↗

NASA NTRS1992

Deep Space Network information system architecture study

The purpose of this article is to describe an architecture for the Deep Space Network (DSN) information system in the years 2000-2010 and to provide guidelines for its evolution during the 1990s. The study scope is defined to be from the front-end areas at the antennas to the end users (spacecraft teams, principal investigators, archival storage systems, and non-NASA partners). The architectural vision provides guidance for major DSN implementation efforts during the next decade. A strong motivation for the study is an expected dramatic improvement in information-systems technologies, such as the following: computer processing, automation technology (including knowledge-based systems), networking and data transport, software and hardware engineering, and human-interface technology. The proposed Ground Information System has the following major features: unified architecture from the front-end area to the end user; open-systems standards to achieve interoperability; DSN production of level 0 data; delivery of level 0 data from the Deep Space Communications Complex, if desired; dedicated telemetry processors for each receiver; security against unauthorized access and errors; and highly automated monitor and control.

Beswick, C. A.↗

NASA NTRSDate not supplied

Nomenclature for the OSIRIS-REx Returned Sample Collection to be Curated at NASA Johnson Space Center

The Origins, Spectral Interpretation, Resource Identification, and Security–Regolith Explorer (OSIRIS-REx) space-craft collected material from the asteroid Bennu on October 20, 2020. The OSIRIS-REx Sample Return Capsule (SRC) is planned to return to Earth on September 24, 2023. The OSIRIS-REx returned sample collection to be curated at NASA Johnson Space Center (JSC) will include both the asteroid material and the flight hardware. We expect most of the asteroid material to be inside the head of the Touch-and-Go Sample Acquisition Mechanism (TAGSAM), and that this material will include a broad range of particles sizes from as large as a few centimeters to less than a micrometer across in their longest dimension. In addition, asteroid material may have been returned along with the flight hardware: intentionally by the contact pads or screens on the witness plates, or serendipitously wedged into or adhering to hardware items. The nomenclature for this new astromaterials collection must accommodate the different types of samples it comprises.

asteroid↗

NASA NTRS2007

Launching to the Moon, Mars, and Beyond

America is returning to the Moon in preparation for the first human footprint on Mars, guided by the U.S. Vision for Space Exploration. This presentation will discuss NASA's mission today, the reasons for returning to the Moon and going to Mars, and how NASA will accomplish that mission. The primary goals of the Vision for Space Exploration are to finish the International Space Station, retire the Space Shuttle, and build the new spacecraft needed to return people to the Moon and go to Mars. Unlike the Apollo program of the 1960s, this phase of exploration will be a journey, not a race. In 1966, the NASA's budget was 4 percent of federal spending. Today, with 6/10 of 1 percent of the budget, NASA must incrementally develop the vehicles, infrastructure, technology, and organization to accomplish this goal. Fortunately, our knowledge and experience are greater than they were 40 years ago. NASA's goal is a return to the Moon by 2020. The Moon is the first step to America's exploration of Mars. Many questions about the Moon's history and how its history is linked to that of Earth remain even after the brief Apollo explorations of the 1960s and 1970s. This new venture will carry more explorers to more diverse landing sites with more capable tools and equipment. The Moon also will serve as a training ground in several respects before embarking on the longer, more perilous trip to Mars. The journeys to the Moon and Mars will require a variety of vehicles, including the Ares I Crew Launch Vehicle, the Ares V Cargo Launch Vehicle, the Orion Crew Exploration Vehicle, and the Lunar Surface Access Module. The architecture for the lunar missions will use one launch to ferry the crew into orbit on the Ares I and a second launch to orbit the lunar lander and the Earth Departure Stage to send the lander and crew vehicle to the Moon. In order to reach the Moon and Mars within a lifetime and within budget, NASA is building on proven hardware and decades of experience derived from the Apollo Saturn, Space Shuttle, and contemporary commercial launch vehicle programs. Less than one year after the Exploration Launch Projects Office was formed at NASA's Marshall Space Flight Center, engineers are testing engine components, firing test rocket motors, refining vehicle designs in wind tunnel tests, and building hardware for the first flight test of Ares I, scheduled for spring 2009. The Vision for Exploration will require this nation to develop tools, machines, materials, and processes never before invented, technologies and capabilities that can be turned over to the private sector to benefit nearly all aspects of life on Earth. This new pioneering venture, as did the Apollo Program before it, will contribute to America's economic leadership, national security, and technological global competitiveness and serve as an inspiration for all its citizens.

Sumrall, John P.↗