Search NASA⌕ Search

SEARCH · Search NASA

Results for “communication system 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.

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

At least 163 records · Page 9

Using software security analysis to verify the secure socket layer (SSL) protocol

nal Aeronautics and Space Administration (NASA) have tens of thousands of networked computer systems and applications. Software Security vulnerabilities present risks such as lost or corrupted data, information the3, and unavailability of critical systems. These risks represent potentially enormous costs to NASA. The NASA Code Q research initiative 'Reducing Software Security Risk (RSSR) Trough an Integrated Approach '' offers, among its capabilities, formal verification of software security properties, through the use of model based verification (MBV) to address software security risks. [1,2,3,4,5,6] MBV is a formal approach to software assurance that combines analysis of software, via abstract models, with technology, such as model checkers, that provide automation of the mechanical portions of the analysis process. This paper will discuss: The need for formal analysis to assure software systems with respect to software and why testing alone cannot provide it. The means by which MBV with a Flexible Modeling Framework (FMF) accomplishes the necessary analysis task. An example of FMF style MBV in the verification of properties over the Secure Socket Layer (SSL) communication protocol as a demonstration.

software↗

Requirements for a network storage service

Sandia National Laboratories provides a high performance classified computer network as a core capability in support of its mission of nuclear weapons design and engineering, physical sciences research, and energy research and development. The network, locally known as the Internal Secure Network (ISN), was designed in 1989 and comprises multiple distributed local area networks (LAN's) residing in Albuquerque, New Mexico and Livermore, California. The TCP/IP protocol suite is used for inner-node communications. Scientific workstations and mid-range computers, running UNIX-based operating systems, compose most LAN's. One LAN, operated by the Sandia Corporate Computing Directorate, is a general purpose resource providing a supercomputer and a file server to the entire ISN. The current file server on the supercomputer LAN is an implementation of the Common File System (CFS) developed by Los Alamos National Laboratory. Subsequent to the design of the ISN, Sandia reviewed its mass storage requirements and chose to enter into a competitive procurement to replace the existing file server with one more adaptable to a UNIX/TCP/IP environment. The requirements study for the network was the starting point for the requirements study for the new file server. The file server is called the Network Storage Services (NSS) and is requirements are described in this paper. The next section gives an application or functional description of the NSS. The final section adds performance, capacity, and access constraints to the requirements.

Kelly, Suzanne M.↗

Managing Multi-Instrument Data Streams in Secure Environments

The capture and curation of all primary instrument data is a potentially valuable source of added insight into experiments or diagnostics in laboratory experiments. The data can, when properly curated, enable analysis beyond the current practice that uses just a subset of the as-measured data. Complete curated data can also be input for machine learning and other data exploration tools. Conveniently storing and accessing instrument data requires that the instruments are connected to databases and users through a networking infrastructure. This infrastructure needs to accommodate a wide array of instruments which can range from single laboratory mounted probes for environment monitoring to computers managing multiple instruments. These resources may also include mobile devices on which researchers record instrument and experiment state related notes. These varied data sources bring with them the challenges of different communications capabilities and protocols as well as the primary data typically being produced in proprietary formats. These challenges are further compounded when the instruments need to operate in secure environments such as required in national laboratories. We will discuss the SmartLab, an ongoing effort to set up a system for instrument and simulation data curation at NASA Langley Research Center. We will outline the challenges faced in managing the data sources required for ongoing research activities and the solutions that are being considered and implemented to address those challenges.

instrument data management↗

IPv6 and IPsec Tests of a Space-Based Asset, the Cisco Router in Low Earth Orbit (CLEO)

This report documents the design of network infrastructure to support testing and demonstrating network-centric operations and command and control of space-based assets, using IPv6 and IPsec. These tests were performed using the Cisco router in Low Earth Orbit (CLEO), an experimental payload onboard the United Kingdom – Disaster Monitoring Constellation (UKDMC) satellite built and operated by Surrey Satellite Technology Ltd (SSTL). On Thursday, 29 March 2007, NASA Glenn Research Center, Cisco Systems and SSTL performed the first configuration and demonstration of IPsec and IPv6 onboard a satellite in low Earth orbit. IPv6 is the next generation of the Internet Protocol (IP), designed to improve on the popular IPv4 that built the Internet, while IPsec is the protocol used to secure communication across IP networks. This demonstration was made possible in part by NASA’s Earth Science Technology Office (ESTO) and shows that new commercial technologies such as mobile networking, IPv6 and IPsec can be used for commercial, military and government space applications. This has direct application to NASA’s Vision for Space Exploration. The success of CLEO has paved the way for new space-based Internet technologies, such as the planned Internet Routing In Space (IRIS) payload at geostationary orbit, which will be a U.S. Department of Defense Joint Capability Technology Demonstration. This is a sanitized report for public distribution. All real addressing has been change to psueco addressing.

Communication↗

NASA Biomedical Informatics Capabilities and Needs

To improve on-orbit clinical capabilities by developing and providing operational support for intelligent, robust, reliable, and secure, enterprise-wide and comprehensive health care and biomedical informatics systems with increasing levels of autonomy, for use on Earth, low Earth orbit & exploration class missions. Biomedical Informatics is an emerging discipline that has been defined as the study, invention, and implementation of structures and algorithms to improve communication, understanding and management of medical information. The end objective of biomedical informatics is the coalescing of data, knowledge, and the tools necessary to apply that data and knowledge in the decision-making process, at the time and place that a decision needs to be made.

Johnson-Throop, Kathy A.↗

Space Station Information System - Concepts and international issues

The Space Station Information System (SSIS) is outlined in terms of its functions and probable physical facilities. The SSIS includes flight element systems as well as existing and planned institutional systems such as the NASA Communications System, the Tracking and Data Relay Satellite System, and the data and communications networks of the international partners. The SSIS strives to provide both a 'user friendly' environment and a software environment which will allow for software transportability and interoperability across the SSIS. International considerations are discussed as well as project management, software commonality, data communications standards, data security, documentation commonality, transaction management, data flow cross support, and key technologies.

Williams, R. B.↗

Space Mission Operations Ground Systems Integration Customer Service

The facility, which is now the Huntsville Operations Support Center (HOSC) at Marshall Space Flight Center in Huntsville, AL, has provided continuous space mission and related services for the space industry since 1961, from Mercury Redstone through the International Space Station (ISS). Throughout the long history of the facility and mission support teams, the HOSC has developed a stellar customer support and service process. In this era, of cost cutting, and providing more capability and results with fewer resources, space missions are looking for the most efficient way to accomplish their objectives. One of the first services provided by the facility was fax transmission of documents to, then, Cape Canaveral in Florida. The headline in the Marshall Star, the newspaper for the newly formed Marshall Space Flight Center, read "Exact copies of Documents sent to Cape in 4 minutes." The customer was Dr. Wernher von Braun. Currently at the HOSC we are supporting, or have recently supported, missions ranging from simple ISS payloads requiring little more than "bentpipe" telemetry access, to a low cost free-flyer Fast, Affordable, Science and Technology Satellite (FASTSAT), to a full service ISS payload Alpha Magnetic Spectrometer 2 (AMS2) supporting 24/7 operations at three operations centers around the world with an investment of over 2 billion dollars. The HOSC has more need and desire than ever to provide fast and efficient customer service to support these missions. Here we will outline how our customer-centric service approach reduces the cost of providing services, makes it faster and easier than ever for new customers to get started with HOSC services, and show what the future holds for our space mission operations customers. We will discuss our philosophy concerning our responsibility and accessibility to a mission customer as well as how we deal with the following issues: initial contact with a customer, reducing customer cost, changing regulations and security, and cultural differences, to ensure an efficient response to customer issues using a small Customer Service Team (CST) and adaptability, constant communication with customers, technical expertise and knowledge of services, and dedication to customer service. The HOSC Customer Support Team has implemented a variety of processes, and procedures that help to mitigate the potential problems that arise when integrating ground system services for a variety of complex missions and the lessons learned from this experience will lead the future of customer service in the space operations industry.

Roth, Karl↗

Internet Based Remote Operations

This is the Final Report for the Internet Based Remote Operations Contract, has performed payload operations research support tasks March 1999 through September 1999. These tasks support the GSD goal of developing a secure, inexpensive data, voice, and video mission communications capability between remote payload investigators and the NASA payload operations team in the International Space Station (ISS) era. AZTek has provided feedback from the NASA payload community by utilizing its extensive payload development and operations experience to test and evaluate remote payload operations systems. AZTek has focused on use of the "public Internet" and inexpensive, Commercial-off-the-shelf (COTS) Internet-based tools that would most benefit "small" (e.g., $2 Million or less) payloads and small developers without permanent remote operations facilities. Such projects have limited budgets to support installation and development of high-speed dedicated communications links and high-end, custom ground support equipment and software. The primary conclusions of the study are as follows: (1) The trend of using Internet technology for "live" collaborative applications such as telescience will continue. The GSD-developed data and voice capabilities continued to work well over the "public" Internet during this period. 2. Transmitting multiple voice streams from a voice-conferencing server to a client PC to be mixed and played on the PC is feasible. 3. There are two classes of voice vendors in the market: - Large traditional phone equipment vendors pursuing integration of PSTN with Internet, and Small Internet startups.The key to selecting a vendor will be to find a company sufficiently large and established to provide a base voice-conferencing software product line for the next several years.

Chamberlain, James↗

Quantum Technologies for UAS (QTech)

Recent advances in small Unmanned Aerial System (sUAS) technologies lower the barriers for use by both private and commercial entities. However, these advances are also likely to lead to greater vehicle densities, a more heterogenous mix of vehicles and equipment and greater levels of vehicle autonomy, which can increase the chance for communications disruptions. For the safe and secure operation of these vehicles, it is essential to have a robust communications network. This work is focused on harnessing the power of quantum technologies to enable this robust communications network by: (1) utilizing quantum optimization algorithms to design robust network with routing redundancy that can respond adaptively to dynamically changing real-time environment and disruptions, (2) utilize quantum optimization algorithms resource allocation for detection, localization, and tracking of mobile communication disruption agents and (3) utilize quantum key distribution (QKD) to execute secure key sharing in anti-jamming protocols for secure radio frequency (RF) communication. Efforts to map these quantum optimization algorithms to commercially available quantum annealers and soon to be available general-purpose gate-model quantum hardware architectures will be reviewed, and plans for testing the solutions to these algorithms through indoor sUAS flight tests will be discussed. Lastly, efforts to miniaturize and practically deploy Quantum Key Distribution (QKD) hardware, which could ultimately be used to securely exchange encryption keys, in sUAS networks will be reviewed.

Quantum Computing↗

STS-101: Crew Activity Report CAR/Flight Day 04 Highlights

On this fourth day of the STS-101 Atlantis mission, the flight crew, Commander James D. Halsell Jr., Pilot Scott J. Horowitz, and Mission Specialists Mary Ellen Weber, Jeffrey N. Williams, James S. Voss, Susan J. Helms, and Yuri Vladimirovich Usachev are seen performing final preparations for the scheduled space walk. Horowitz, Williams and Voss are seen in the mid-deck before the space walk. Horowitz and Weber are also seen in the flight deck, powering-up the robot-arm. During the space walk Voss is seen checking the American Cargo Crane-Orbital Replacement Unit Transfer Device. Voss and Williams are shown securing the American-built crane that was installed on the station last year. They are seen as they install the final parts (boom extension) of a Russian-built crane on the station. Voss and Williams are also shown as they replace a faulty antenna for one of the station's communications systems on the Unity Module, and install several handrails and a camera cable on the station's exterior.

Source record↗

Research and Technology 2003

The NASA Glenn Research Center at Lewis Field, in partnership with U.S. industries, universities, and other Government institutions, is responsible for developing critical technologies that address national priorities in aeropropulsion and space applications. Our work is focused on research for new aeropropulsion technologies, aerospace power, microgravity science (fluids and combustion), electric propulsion, and communications technologies for aeronautics, space, and aerospace applications. As NASA s premier center for aeropropulsion, aerospace power, and turbomachinery, our role is to conduct world-class research and to develop key technologies. We contribute to economic growth and national security through safe, superior, and environmentally compatible U.S. civil and military aircraft propulsion systems. Our Aerospace Power Program supports all NASA Enterprises and major programs, including the International Space Station, Advanced Space Transportation, and new initiatives in human and robotic exploration. Glenn Research Center leads NASA s research in the microgravity science disciplines of fluid physics, combustion science, and acceleration measurement. Almost every space shuttle science mission has had an experiment managed by NASA Glenn, and we have conducted a wide array of similar experiments on the International Space Station. The Glenn staff consists of over 3200 civil service employees and support service contractor personnel. Scientists and engineers comprise more than half of our workforce, with technical specialists, skilled workers, and an administrative staff supporting them. We aggressively strive for technical excellence through continuing education, increased diversity in our workforce, and continuous improvement in our management and business practices so that we can expand the boundaries of aeronautics, space, and aerospace technology. Glenn Research Center is a unique facility located in northeast Ohio. Situated on 350 acres of land adjacent to the Cleveland Hopkins International Airport, Glenn comprises more than 140 buildings, including 24 major facilities and over 500 specialized research and test facilities. Additional facilities are located at Plum Brook Station, which is about 50 miles west of Cleveland. Plum Brook Station has four large, major, world-class facilities for space research available for Government and industry programs. Knowledge is the end product of our activities. The R&T reports help make this knowledge fully available to potential users the aircraft engine industry, the space industry, the energy industry, the automotive industry, the aerospace industry, and others. It is organized so that a broad cross section of the community can readily use it. Each article begins with a short introductory paragraph that should prove valuable for the layperson. These articles summarize the progress made during the year in various technical areas and portray the technical and administrative support associated with Glenn s technology programs. We hope that this information is useful to all. If additional information is desired, readers are encouraged to contact the researchers identified at the end of each article and to visit Glenn on the World Wide Web at http://www.grc.nasa.gov.

Julian Earls↗

Requirements for an Integrated UAS CNS Architecture

The National Aeronautics and Space Administration (NASA) Glenn Research Center (GRC) is investigating revolutionary and advanced universal, reliable, always available, cyber secure and affordable Communication, Navigation, Surveillance (CNS) options for all altitudes of UAS operations. In Spring 2015, NASA issued a Call for Proposals under NASA Research Announcements (NRA) NNH15ZEA001N, Amendment 7 Subtopic 2.4. Boeing was selected to conduct a study with the objective to determine the most promising candidate technologies for Unmanned Air Systems (UAS) air-to-air and air-to-ground data exchange and analyze their suitability in a post-NextGen NAS environment. The overall objectives are to develop UAS CNS requirements and then develop architectures that satisfy the requirements for UAS in both controlled and uncontrolled air space. This contract is funded under NASAs Aeronautics Research Mission Directorates (ARMD) Aviation Operations and Safety Program (AOSP) Safe Autonomous Systems Operations (SASO) project and proposes technologies for the Unmanned Air Systems Traffic Management (UTM) service. Communications, Navigation and Surveillance (CNS) requirements must be developed in order to establish a CNS architecture supporting Unmanned Air Systems integration in the National Air Space (UAS in the NAS). These requirements must address cybersecurity, future communications, satellite-based navigation APNT, and scalable surveillance and situational awareness. CNS integration, consolidation and miniaturization requirements are also important to support the explosive growth in small UAS deployment. Air Traffic Management (ATM) must also be accommodated to support critical Command and Control (C2) for Air Traffic Controllers (ATC). This document therefore presents UAS CNS requirements that will guide the architecture.

Templin, Fred↗

Advanced Utilization of the Payload Executive Processor (PEP) Ethernet Port to Support JSL Based Payloads

Increased interest by Payload Developers in utilization of the Joint Station LAN (Local Area Network) (JSL) for command and data transactions has driven the investigation of providing bi-directional Ethernet communication with PEP (Payload Executive Processor). Ethernet-only payload developers are interested in taking advantage of the services provided by PEP. Enabling Ethernet communications within PEP requires more than just turning on the hardware. PEP contains no Operating System (OS) or Ethernet stack so it does not inherit any built in functionality for Ethernet support. Both hardware drivers and application software must be developed from scratch. In the absence of an OS (Operating System) the design must address security issues in terms of access and data transferred, i.e. blocking unauthorized users and preventing denial of service. Developing a design to process Ethernet data within the existing real-time constraints of PEP requires a few compromises: data rates, supported protocols, custom packet format and limited client connections to name a few. Integration of the light weight internet protocol (LwIP). Ethernet stack provides a customizable solution for the embedded real-time environment. As utilization of the JSL increases, the successful implementation of an Ethernet interface enhances the utilization of PEP, and provides a new path for future Ethernet-only payloads to gain access to around the clock command and data services.

Guyette, Greg↗

Space Station needs, attributes and architectural options. Volume 2, book 2, part 1: Mission implementation concepts

The overall configuration and modules of the initial and evolved space station are described as well as tended industrial and polar platforms. The mass properties that are the basis for costing are summarized. User friendly attributes (interfaces, resources, and facilities) are identified for commercial; science and applications; industrial park; international participation; national security; and the external tank option. Configuration alternates studied to determine a baseline are examined. Commonality for clustered 3-man and 9-man stations are considered as well as the use of tethered platforms. Requirements are indicated for electrical, communication and tracking; data management Subsystem requirements for electrical, data management, communication and tracking, environment control/life support system; and guidance navigation and control subsystems are identified.

Source record↗

An Airborne Communications Roadmap for the U.S. Federal Air Marshal Service: Overview and Status

Following the events of September 11, 2001, the responsibilities, operations and numbers of the U.S. Federal Air Marshal Service (FAMS) wer e greatly expanded. With this expansion, new critical research and te chnology needs were identified, including the need for air to ground telecommunications capabilities. To address this need, the FAMS has cr eated a working group to develop, deploy and enhance aviation communi cations with respect to security and law enforcement. This paper presents the working group's progress to date in generating a FAMS air-gro und communications roadmap identifying expected communications servic es, technology maturity, and technology gaps over a timeline. The paper includes a communications preliminary requirements summary and syst em performance characteristics needed to meet identified operational needs. The system engineering process utilized is presented beginning with the identification of users, their operational needs and relevant constraints. The operational needs are translated to desired airbor ne communications services. System technical performance requirements associated with the identified services are summarized. In addition, notional communications architectures addressing the requirements are presented. Finally, future plans to identify and assess potential ca ndidate systems and their associated technical architectures, gaps and barriers to implementation are discussed. The paper addresses the cu rrent, near term (within 5 years) and far term (10 years) timeframes for such an airborne communications system.

Martzaklis, Konstantinos S.↗

Software Defined Radio Architecture Contributions to Next Generation Space Communications

Space communications architecture concepts, comprising the elements of the system, the interactions among them, and the principles that govern their development, are essential factors in developing National Aeronautics and Space Administration (NASA) future exploration and science missions. Accordingly, vital architectural attributes encompass flexibility, the extensibility to insert future capabilities, and to enable evolution to provide interoperability with other current and future systems. Space communications architectures and technologies for this century must satisfy a growing set of requirements, including those for Earth sensing, collaborative observation missions, robotic scientific missions, human missions for exploration of the Moon and Mars where surface activities require supporting communications, and in-space observatories for observing the earth, as well as other star systems and the universe. An advanced, integrated, communications infrastructure will enable the reliable, multipoint, high-data-rate capabilities needed on demand to provide continuous, maximum coverage for areas of concentrated activity. Importantly, the cost/value proposition of the future architecture must be an integral part of its design; an affordable and sustainable architecture is indispensable within anticipated future budget environments. Effective architecture design informs decision makers with insight into the capabilities needed to efficiently satisfy the demanding space-communication requirements of future missions and formulate appropriate requirements. A driving requirement for the architecture is the extensibility to address new requirements and provide low-cost on-ramps for new capabilities insertion, ensuring graceful growth as new functionality and new technologies are infused into the network infrastructure. In addition to extensibility, another key architectural attribute of the space communication equipment's interoperability with other NASA communications systems, as well as those communications and navigation systems operated by international space agencies and civilian and government agencies. In this paper, we review the philosophies, technologies, architectural attributes, mission services, and communications capabilities that form the structure of candidate next-generation integrated communication architectures for space communications and navigation. A key area that this paper explores is from the development and operation of the software defined radio for the NASA Space Communications and Navigation (SCaN) Testbed currently on the International Space Station (ISS). Evaluating the lessons learned from development and operation feed back into the communications architecture. Leveraging the reconfigurability provides a change in the way that operations are done and must be considered. Quantifying the impact on the NASA Space Telecommunications Radio System (STRS) software defined radio architecture provides feedback to keep the standard useful and up to date. NASA is not the only customer of these radios. Software defined radios are developed for other applications, and taking advantage of these developments promotes an architecture that is cost effective and sustainable. Developments in the following areas such as an updated operating environment, higher data rates, networking and security can be leveraged. The ability to sustain an architecture that uses radios for multiple markets can lower costs and keep new technology infused.

Lessons Learned↗

Aerospace Communications Security Technologies Demonstrated

In light of the events of September 11, 2001, NASA senior management requested an investigation of technologies and concepts to enhance aviation security. The investigation was to focus on near-term technologies that could be demonstrated within 90 days and implemented in less than 2 years. In response to this request, an internal NASA Glenn Research Center Communications, Navigation, and Surveillance Aviation Security Tiger Team was assembled. The 2-year plan developed by the team included an investigation of multiple aviation security concepts, multiple aircraft platforms, and extensively leveraged datalink communications technologies. It incorporated industry partners from NASA's Graphical Weather-in-the-Cockpit research, which is within NASA's Aviation Safety Program. Two concepts from the plan were selected for demonstration: remote "black box," and cockpit/cabin surveillance. The remote "black box" concept involves real-time downlinking of aircraft parameters for remote monitoring and archiving of aircraft data, which would assure access to the data following the loss or inaccessibility of an aircraft. The cockpit/cabin surveillance concept involves remote audio and/or visual surveillance of cockpit and cabin activity, which would allow immediate response to any security breach and would serve as a possible deterrent to such breaches. The datalink selected for the demonstrations was VDL Mode 2 (VHF digital link), the first digital datalink for air-ground communications designed for aircraft use. VDL Mode 2 is beginning to be implemented through the deployment of ground stations and aircraft avionics installations, with the goal of being operational in 2 years. The first demonstration was performed December 3, 2001, onboard the LearJet 25 at Glenn. NASA worked with Honeywell, Inc., for the broadcast VDL Mode 2 datalink capability and with actual Boeing 757 aircraft data. This demonstration used a cockpitmounted camera for video surveillance and a coupling to the intercom system for audio surveillance. Audio, video, and "black box" data were simultaneously streamed to the ground, where they were displayed to a Glenn audience of senior management and aviation security team members.

Griner, James H.↗

L-Band System Engineering - Concepts of Use, Systems Performance Requirements, and Architecture

This document is being provided as part of ITT s NASA Glenn Research Center Aerospace Communication Systems Technical Support (ACSTS) contract NNC05CA85C, Task 7: New ATM Requirements-Future Communications, C-band and L-band Communications Standard Development. Task 7 was motivated by the five year technology assessment performed for the Federal Aviation Administration (FAA) under the joint FAA-EUROCONTROL cooperative research Action Plan (AP-17), also known as the Future Communications Study (FCS). It was based on direction provided by the FAA project-level agreement (PLA FY09_G1M.02-02v1) for "New ATM Requirements-Future Communications." Task 7 was separated into two distinct subtasks, each aligned with specific work elements and deliverable items. Subtask 7-1 addressed C-band airport surface data communications standards development, systems engineering, test bed development, and tests/demonstrations to establish operational capability for what is now referred to as the Aeronautical Mobile Airport Communications System (AeroMACS). Subtask 7-2, which is the subject of this report, focused on preliminary systems engineering and support of joint FAA/EUROCONTROL development and evaluation of a future L-band (960 to 1164 MHz) air/ground (A/G) communication system known as the L-band digital aeronautical communications system (L-DACS), which was defined during the FCS. The proposed L-DACS will be capable of providing ATM services in continental airspace in the 2020+ timeframe. Subtask 7-2 was performed in two phases. Phase I featured development of Concepts of Use, high level functional analyses, performance of initial L-band system safety and security risk assessments, and development of high level requirements and architectures. It also included the aforementioned support of joint L-DACS development and evaluation, including inputs to L-DACS design specifications. Phase II provided a refinement of the systems engineering activities performed during Phase I, along with continued joint FAA/EUROCONTROL L-DACS development and evaluation support.

Henriksen, Stephen↗