![](media/image1.emf){width="4.416666666666667in"
height="1.2777777777777777in"}

**REPORT CONCERNING SPACE**

**DATA SYSTEM STANDARDS**

  -----------------------------------------------------------------------
  **THE APPLICATION OF CCSDS PROTOCOLS TO SECURE SYSTEMS**

  -----------------------------------------------------------------------

**CCSDS 350.0-G-1**

**GREEN BOOK**

March 1999

![](media/image2.emf){width="4.125in" height="1.9305555555555556in"}

# AUTHORITY

  ---- -------------------- ------------------------------------------ ----
                                                                       

       Issue:               Green Book, Issue 1                        

       Date:                March 1999                                 

       Location:            Washington, D.C., USA                      

                                                                       
  ---- -------------------- ------------------------------------------ ----

This document has been approved for publication by the Management
Council of the Consultative Committee for Space Data Systems (CCSDS) and
reflects the consensus of technical panel experts from CCSDS Member
Agencies. The procedure for review and authorisation of CCSDS Reports is
detailed in the *Procedures Manual for the Consultative Committee for
Space Data Systems.*

This document is published and maintained by:

> CCSDS Secretariat
>
> Program Integration Division (Code MT)
>
> National Aeronautics and Space Administration
>
> Washington, DC 20546, USA

# FOREWORD

This document is a CCSDS Report that contains background and explanatory
material to supplement the CCSDS Recommendations for conventional
telecommand and telemetry, Advanced Orbiting Systems (AOS), and Space
Communications Protocol Specification (SCPS).

Through the process of normal evolution, it is expected that expansion,
deletion or modification to this Report may occur. This Report is
therefore subject to CCSDS document management and change control
procedures. Current versions of CCSDS documents are maintained at the
CCSDS Web site:

http://www.ccsds.org/ccsds/

Questions about the contents or status of this Report should be
addressed to the CCSDS Secretariat.

At time of publication, the active Member and Observer Agencies of the
CCSDS were:

[Member Agencies]{.underline}

> -- British National Space Centre (BNSC)/United Kingdom.
>
> -- Canadian Space Agency (CSA)/Canada.
>
> -- Centre National d'Etudes Spatiales (CNES)/France.
>
> -- Deutsches Zentrum für Luft- und Raumfahrt e.V. (DLR)/Germany.
>
> -- European Space Agency (ESA)/Europe.
>
> -- Instituto Nacional de Pesquisas Espaciais (INPE)/Brazil.
>
> -- National Aeronautics and Space Administration (NASA)/USA.
>
> -- National Space Development Agency of Japan (NASDA)/Japan.
>
> -- Russian Space Agency (RSA)/Russian Federation.

[Observer Agencies]{.underline}

> -- Austrian Space Agency (ASA)/Austria.
>
> -- Central Research Institute of Machine Building (TsNIIMash)/Russian
> Federation.
>
> -- Centro Tecnico Aeroespacial (CTA)/Brazil.
>
> -- Chinese Academy of Space Technology (CAST)/China.
>
> -- Commonwealth Scientific and Industrial Research Organisation
> (CSIRO)/Australia.
>
> -- Communications Research Laboratory (CRL)/Japan.
>
> -- Danish Space Research Institute (DSRI)/Denmark.
>
> -- European Organisation for the Exploitation of Meteorological
> Satellites (EUMETSAT)/Europe.
>
> -- European Telecommunications Satellite Organisation
> (EUTELSAT)/Europe.
>
> -- Federal Service of Scientific, Technical & Cultural Affairs
> (FSST&CA)/Belgium.
>
> -- Hellenic National Space Committee (HNSC)/Greece.
>
> -- Indian Space Research Organisation (ISRO)/India.
>
> -- Industry Canada/Communications Research Centre (CRC)/Canada.
>
> -- Institute of Space and Astronautical Science (ISAS)/Japan.
>
> -- Institute of Space Research (IKI)/Russian Federation.
>
> -- KFKI Research Institute for Particle & Nuclear Physics
> (KFKI)/Hungary.
>
> -- MIKOMTEK: CSIR (CSIR)/Republic of South Africa.
>
> -- Korea Aerospace Research Institute (KARI)/Korea.
>
> -- Ministry of Communications (MOC)/Israel.
>
> -- National Oceanic & Atmospheric Administration (NOAA)/USA.
>
> -- National Space Program Office (NSPO)/Taipei.
>
> -- Swedish Space Corporation (SSC)/Sweden.
>
> -- United States Geological Survey (USGS)/USA.

DOCUMENT CONTROL

  -------------- ---------------------- ---------- ----------------------------
  **Document**   **Title**              **Date**   **Status**

                                                   

  CCSDS          The Application of     March 1999 Original Issue
  350.0-G-1      CCSDS Protocols to                
                 Secure Systems                    

                                                   
  -------------- ---------------------- ---------- ----------------------------

# CONTENTS

1 INTRODUCTION 1-1

1.1 PURPOSE 1-1

1.2 SCOPE 1-1

1.3 RATIONALE 1-1

1.4 ORGANIZATION OF THIS REPORT 1-2

1.5 REFERENCES 1-3

2 SECURITY CONCEPTS AND DEFINITIONS 2-1

2.1 OVERVIEW 2-1

2.2 DEFINITIONS 2-2

2.3 THREATS 2-3

3 CCSDS SECURITY REQUIREMENTS 3-1

3.1 SPACE DATA SYSTEM REFERENCE MODEL 3-1

3.2 MISSION SCENARIOS 3-2

4 SECURITY MECHANISMS 4-1

4.1 CONFIDENTIALITY 4-1

4.2 4.2 AUTHENTICATION 4-2

4.3 DATA INTEGRITY 4-3

4.4 ACCESS CONTROL 4-3

5 CCSDS SECURITY IMPLEMENTATION OPTIONS 5-1

5.1 Overview 5-1

5.2 BULK ENCRYPTION 5-1

5.3 Data Link Security 5-3

5.4 Network Layer Security 5-7

5.5 Application Security 5-9

5.6 ccsds security option Combinations 5-9

6 CCSDS SECURITY IMPLICATIONS 6-1

6.1 Impact of encryption 6-1

6.2 IMPACT ON CROSS-SUPPORT SERVICES 6-1

6.3 SECURITY OPTION COMPARISION 6-3

6.4 Security Option Selection 6-4

ANNEX A Specific Agency Implementations A-1

CONTENTS (continued)

[Figure]{.underline} [Page]{.underline}

3-1 CCSDS Space Mission Protocols and Security Options 3-1

4-1 The Concept of Encryption and Decryption 4-1

4-2 Digital Signature Concept 4-2

5-1 Security Implementation Options Considered in this Report 5-1

5-2 Bulk Encryption of CCSDS Protocols 5-2

5-3 Telecommand Data Link Layer Security Options 5-4

5-4 Telemetry Data Link Layer Security Options 5-5

5-5 Location of AOS Security Services 5-6

5-6 AOS VCA Sublayer Security 5-7

5-7 SCPS Security Protocol Structure 5-8

5-8 CCSDS Packet Security Concept 5-9

5-9 CCSDS Data Link and Network Security Combination Architecture 5-10

6-1 Impact of Security on Return SLE Services 6-2

6-2 Impact of Security on Forward SLE Services 6-2

A-1 ESA Telecommand Authentication Sublayer Structure A-1

[Table]{.underline}

6-1 Impact of Confidentiality on CCSDS Data Fields 6-1

# INTRODUCTION

## PURPOSE

This Report is intended to provide guidance to missions that wish to use
the CCSDS Recommendations for spacecraft control and data handling but
also require a level of security or data protection. The report provides
background information on security, details various options for security
implementation in space missions, and outlines the impact of security on
defined CCSDS services.

## SCOPE

THE INFORMATION CONTAINED IN THIS REPORT IS NOT PART OF ANY OF THE CCSDS
RECOMMENDATIONS. In the event of any conflict between any CCSDS
Recommendation and the material presented herein, the CCSDS
Recommendation shall prevail.

This report is intended as an implementation guide to aid space missions
requiring secure CCSDS space mission data systems. It primarily
addresses security of the space-ground ground-space data link and does
not provide information on protecting the ground element of a space
mission. Detailed information on security analysis and risk assessment
methodology are beyond the scope of this report; however, references
\[9\] and \[10\] provide further information.

## RATIONALE

To date, most civil space missions have relied on their uniqueness to
deter unauthorised access to the space mission data system, whereas
military missions have implemented mission specific security measures to
protect the spacecraft command and telemetry data. This situation is
changing with the advent of more open systems for space mission control
and data distribution. Civil space mission and ground system developers
must now consider security as part of the system design process.

It is likely that most future space missions will require a level of
mission-data-system security to protect the spacecraft and ground
systems from unauthorised access. This likelihood is particularly
evident as space mission control activities gradually make more use of
public networks, such as the Internet, for ground network connectivity.
Some missions will require increasingly higher levels of security for a
variety of operational and commercial reasons.

The work performed by CCSDS has provided a sound basis for the
spacecraft control and mission data systems for all types of future
space missions. The CCSDS Recommendations for conventional telecommand
(references \[1\], \[2\], and \[3\]) and telemetry (reference \[4\]),
and Advanced Orbiting Systems (AOS---reference \[5\]) have been
developed by civil space agencies and are primarily intended to satisfy
the communications requirements of civil missions. However, the CCSDS
initiative has generated significant interest within the other space
communities, such as government/military and commercial, for a number of
reasons, including:

a\) increased complexity of spacecraft and payloads for all mission
types requiring more advanced control and monitor systems, including
packet-based mechanisms and on-board autonomy;

b\) reduction in space mission budgets with encouragement to utilise
commercial technologies and standards where appropriate;

c\) availability of space- and ground-segment commercial products to
reduce mission development costs;

d\) initiatives to consolidate civil and military ground station
networks requiring widespread data systems standardisation;

e\) increased reliance on national and international co-operation to
achieve space mission objectives.

Promoting the use of CCSDS Recommendations for a wider range of
missions, including commercial and military, will make possible further
reductions in mission development costs for all mission types through
the wider availability of commercial products. In the same way,
establishing generic security concepts to satisfy the security
requirements of future commercial and military missions will further
extend the CCSDS user environment. Establishing generic security
concepts is one of the objectives of this implementation guide.

## ORGANIZATION OF THIS REPORT

This document is organised as follows:

Section 2 provides an introduction to security, defines terms that are
used in this report, and identifies generic space mission security
threats.

Section 3 presents a space mission security architecture based on a
CCSDS reference model and establishes the security requirements of
different types of space missions.

Section 4 describes the specific security mechanisms that may be
utilised to achieve required security services.

Section 5 highlights the various available options for security for
missions using CCSDS Recommendations and describes the impact on
protocol data structures.

Section 6 presents the implications of security on the space mission
architecture and cross-support services. A comparison of possible
security options, with guidance on option selection, is also provided.

Annex A describes some known implementation examples of CCSDS missions
that have incorporated additional security features.

## REFERENCES

The following documents are referenced in the text of this Report. At
the time of publication, the editions indicated were valid. All
documents are subject to revision, and users of this Recommendation are
encouraged to investigate the possibility of applying the most recent
editions of the documents indicated below. The CCSDS Secretariat
maintains a register of currently valid CCSDS Recommendations and
Reports.

\[1\] *Telecommand Part 1---Channel Service*. Recommendation for Space
Data System Standards, CCSDS 201.0-B-2. Blue Book. Issue 2. Washington,
D.C.: CCSDS, November 1995.

\[2\] *Telecommand Part 2---Data Routing Service*. Recommendation for
Space Data Systems Standards, CCSDS 202.0-B-2. Blue Book. Issue 2.
Washington, D.C.: CCSDS, November 1992.

\[3\] *Telecommand Part 2.1 - Command Operation Procedures*.
Recommendation for Space Data System Standards, CCSDS 202.1-B-1. Blue
Book. Issue 1. Washington, D.C.: CCSDS, October 1991.

\[4\] *Packet Telemetry*. Recommendation for Space Data System
Standards, CCSDS 102.0-B-4. Blue Book. Issue 4. Washington, D.C.: CCSDS,
November 1995.

\[5\] *Advanced Orbiting Systems, Networks and Data Links: Architectural
Specification*. Recommendation for Space Data Systems Standards, CCSDS
701.0-B-2. Blue Book. Issue 2. Washington, D.C.: CCSDS, November 1992.

\[6\] *Telecommand Summary of Concept and Rationale*. Report Concerning
Space Data System Standards, CCSDS 200.0-G-6. Green Book. Issue 6.
Washington, D.C.: CCSDS, January 1987.

\[7\] *Advanced Orbiting Systems, Networks and Data Links: Summary of
Concept, Rationale and Performance*. Report Concerning Space Data
Systems Standards, CCSDS 700.0-G-3. Green Book. Issue 3. Washington,
D.C.: CCSDS, November 1992.

\[8\] *Space Communications Protocol Specification (SCPS)---Security
Protocol (SCPS-SP)*. Recommendation for Space Data System Standards,
CCSDS 713.5-B-1. Blue Book. Issue 1. Washington, D.C.: CCSDS, May 1999.

\[9\] *OSI Reference Model---Security Architecture*. International
Standard, ISO 7498-2-1988(E). Geneva: ISO, 1988.

\[10\] K.M. Jackson and J. Hruska, eds. *Computer Security Reference
Book*. Oxford: Butterwoth-Heinemann, 1992.

\[11\] *Packet Telemetry Services*. Recommendation for Space Data System
Standards, CCSDS 103.0-B-1. Blue Book. Issue 1. Washington, D.C.: CCSDS,
May 1996.

\[12\] *Cross Support Reference Model---Part 1: Space Link Extension
Services*. Recommendation for Space Data System Standards, CCSDS
910.4-B-1. Blue Book. Issue 1. Washington, D.C.: CCSDS, May 1996.

\[13\] *Cross Support Concept---Part 1: Space Link Extension Services*.
Report Concerning Space Data Systems Standards, CCSDS 910.3-G-1. Green
Book. Issue 1. Washington, D.C.: CCSDS, May 1995.

\[14\] *Packet Telecommand Standard*. ESA PSS-04-107, Issue 2. Paris:
ESA, 1992.

# SECURITY CONCEPTS AND DEFINITIONS

## OVERVIEW

### Definition of Security

Security can be described as the effect or process of minimising the
vulnerabilities of assets or resources. The three key elements of
information security for a data communications system are availability,
confidentiality, and integrity. *Availability* is the assurance that a
system will be available for use, *confidentiality* is protection
against unauthorised disclosure of information, and *integrity* is
protection against unauthorised modification of data.

To incorporate security in a space mission data system, the following
entities may require protection:

a\) information and data contained within the system (i.e.,
*information*);

b\) communications and data processing services (i.e., *services*);

c\) space mission ground equipment and spacecraft (i.e., *resources*).

Security can be achieved by the implementation of a number of different
'security services' at specific locations in the space mission data
system. To incorporate the appropriate level of security for a
particular mission, at least one security service or a combination of
security services is required.

### The System Security Policy

In selecting the appropriate security services for a particular mission,
the first task is to assess the security threats to the system. This
task is normally part of the development of a System Security Policy
(SSP). The SSP is usually a formal document providing a description of
the system, the top-level security objectives, and identification of the
specific information-security and system-availability threats against
the system. Other information may be included in the SSP, such as the
security standards and evaluation requirements to be applied to the
system.

As part of the SSP development process, a *threat assessment* should be
performed. The threat assessment should assess the vulnerabilities of
the system and then establish the likelihood, consequences, and cost of
realisation of each threat to the system. A threat is a problem only if
a system is found to be vulnerable. Once the threat assessment process
is complete, specific security services can be identified to counter
each threat/vulnerability. The selection of countermeasures is likely to
require a cost-benefit analysis to justify the implementation cost of
security services within the system. Detailed information on threat
assessment is beyond the scope of this report. There are many
information sources on this subject, including reference \[10\].

## DEFINITIONS

The following security service definitions are used within this report.
Examples of the application of the security service in a space mission
environment are provided as part of each definition.

### Confidentiality

Confidentiality ensures that information is not available or disclosed
to unauthorised personnel, entities, or processes. It ensures that data
is disclosed only to those who are authorised to see it.

In a space mission environment, data confidentiality may be used to
prevent the disclosure of sensitive information contained within any
part of the space mission data system. Confidentiality is particularly
relevant for sensitive data transmitted over the ground-to-space (or
space-to-ground) Radio Frequency (RF) link or via public networks within
the ground segment.

Confidentiality may also be relevant for space mission protocol headers
and trailers, to prevent analysis of the communications traffic within
the spacecraft control system. Traffic analysis could disclose
information on the operational status of the system, and such disclosure
may be undesirable for certain types of missions.

### Authentication

Authentication provides the assurance that information transmitted from
a claimed source (i.e., a source's identity) actually came from that
source. This service is also known as *data origin authentication*. It
does not provide protection against duplication or modification of data.

In a space mission environment, authentication may be used to achieve
assurance that the received data originated from an authorised space
mission control centre. Thus, authentication can provide spacecraft
protection by requiring that the on-board data handling system accept
only validated telecommands. Any telecommands that do not pass the
authentication process are rejected.

### Data Integrity

Data integrity assures that information transmitted from a source has
not been modified or destroyed by an unauthorised entity.

In a space mission environment, an integrity service may be used to
ensure that mission data has not been manipulated in any way during
transmission across ground networks or over the RF link. Data integrity
can also prevent malicious replay of previously transmitted authorised
data (otherwise known as 'replay attack').

### Access Control

Access control prevents unauthorised use of a resource as well as use of
a resource in an unauthorised manner. Access control may be applied to
various types and levels of access to a resource (e.g., the actual use
of a resource, the deletion of information, or the ability to read
information).

An example of access control within a space mission environment is the
use the mechanisms and procedures to enable only approved operators to
access the mission control system through a secure user name and
password access control scheme.

## THREATS

### Types of Threat

A threat is defined as any circumstance or event having the potential to
cause harm to a system through destruction, disclosure, and modification
of data, and/or through denial of service. A threat can also be defined
as a potential violation of security. However, a threat remains only a
*potential* violation of security until it can be shown that there is a
high likelihood that the threat can cause harm. At that time, the threat
is re-categorised as a vulnerability.

Threats can be classified as accidental or intentional and may be active
or passive. The threats to a space mission data system include:

a\) unauthorised destruction of information and/or resources (e.g.,
spacecraft or ground systems);

b\) unauthorised corruption or modification of information within the
system;

c\) theft or loss of information and/or resources;

d\) disclosure of information to unauthorised entities;

e\) interruption of services.

Accidental threats have no premeditated intent and include system
malfunctions and operational errors. Intentional threats range from
casual examination of system information to sophisticated attacks using
specific knowledge about the system.

Passive threats, if realised, would not result in modification to any
information in the space data system and the system itself would remain
unaffected. Security violations falling into this category are generally
associated with loss of data confidentiality, since this is the only
security property that can be compromised without trace.

Realisation of active threats would involve modification of information
contained within the system or malicious changes to the operation or
state of the system (space and/or ground segment). Active threats can
compromise the information passing across a space mission data
communication system by violating the integrity of the data or by
degrading the availability of the system.

### Threats to Space Systems

The threats to a space mission data system can be categorised into three
areas:

a\) threats to RF transmissions;

b\) threats to the space system resources (e.g., spacecraft and onboard
instruments);

c\) threats to the ground element of the mission data system.

Threats to spacecraft telecommands and telemetry links originate from
the fact that they are transmitted through the physical RF medium. These
transmissions are potentially subject to detection and interception by
entities unauthorised to receive the information. As a result, there is
a possibility that the information contained within the transmissions
could be exploited.

A particularly dangerous active threat might allow an unauthorised
entity to transmit to a spacecraft telecommands that might cause
accidental or malicious damage, cause theft of the spacecraft, or
ultimately destroy the spacecraft. With the large investment needed to
deploy space missions, any processes that may counter the threats to the
spacecraft are desirable and will be essential for some types of space
mission.

Threats to the space mission ground data system can be considered the
same as the information security threats to any open or private computer
network. Specific types of information security attack are described in
reference \[9\], and a brief overview is provided in the following
sections.

### Passive Attacks

A passive attack is typically accomplished by eavesdropping (e.g.,
listening in on an RF transmission, wiretapping). A space system can be
subjected to two principle types of passive attack:

a\) *Compromise of data confidentiality*---unauthorised disclosure of
information flowing between ground and space systems or across the
ground mission data network.

b\) *Compromise of traffic flow confidentiality*---unauthorised
disclosure of aspects such as the volume, source, and destination of the
information in the system, without explicitly disclosing the content of
the data.

### Active Attacks

Some of the possible types of active attacks to be considered for space
systems are described below.

a\) *Modification of messages* occurs when some or all of the content of
a data transmission is altered or destroyed without detection, resulting
in an undesirable or malicious effect on the system.

b\) *Masquerade* occurs when an unauthorised entity pretends to be an
authorised entity. It is usually used with some other form of active
attack, such as replay or data modification. For example, if an attacker
can divert network connections to another computing host, which is
masquerading as the genuine host, system passwords or other useful
information can be captured.

c\) A *replay attack* is carried out when a message or part of a message
is recorded and is repeated at a later time to produce an undesirable
effect. For example, a previously sent, authorised telecommand may be
retransmitted to a spacecraft at a later time resulting in an
undesirable affect on the spacecraft payload.

d\) A *denial of service* *attack* occurs when the system, or parts of
the system, are prevented from performing their proper functions. This
type of attack includes RF jamming and overloading of system resources.

e\) *Insider attacks* occur when authorised users of the system behave
in an illicit manner. Most known computer crimes are a result of insider
attacks.

f\) *Software threats* include *viruses,* which can infect and disrupt
computers within the space mission network, *trapdoors,* which are
intentionally created loopholes within the system software to allow
access to the system bypassing usual security controls, and *Trojan
Horses,* which are software processes that have damaging unauthorised
functions in addition to their authorised functions.

# CCSDS SECURITY REQUIREMENTS

## SPACE DATA SYSTEM REFERENCE MODEL

To provide the overall security architecture for space mission data
systems, a space link reference model is used as shown in figure 3-1.
The model highlights the various CCSDS protocols that are available and
four security implementation points that have been selected for a
variety of reasons explained in this report. The four security
implementation points considered are:

-- Physical layer;

-- Data link layer (conventional and AOS);

-- Network (or packet) layer;

-- Application layer.

Security may be applied at other layers (e.g., the transport layer) if
required by the mission requirements. However, this report considers
only the four security implementation points, shown in figure 3-1, that
are likely to satisfy the requirements of most missions. Figure 3-1 does
not show all possible CCSDS protocol combinations.

![](media/image3.wmf){width="5.736111111111111in"
height="3.638888888888889in"}

Figure 3-1: CCSDS Space Mission Protocols and Security Options

The security implementation approach selected for any particular space
mission is dependent on the following factors:

a\) the mission security requirements;

b\) the mission operational requirements;

c\) the CCSDS Recommendation in use (e.g., conventional telecommand and
telemetry, AOS, SCPS);

d\) the capability of the on-board systems.

Different security services may be applied at different layers of the
spacecraft communications system as indicated in figure 3-1, although
not all layers may be implemented within the data system of any
particular mission.

## MISSION SCENARIOS 

To define sets of generic security requirements for different space
mission types, missions have been classified as requiring either *high*,
*moderate*, or *minimal* levels of security. This grouping is intended
only to act as a guide for the purposes of this report and is not
restrictive. Some missions may have security requirements that cannot be
contained within one of these groups.

Different mission types will require the implementation of different
security services to satisfy specific mission requirements. In addition,
different mission types may require different *assurance of correctness
of operation* for each security service. For example, high security
missions will require many security services and the highest assurance
that these services are operating as intended (e.g., use of high grade,
government approved cryptographic algorithms). Moderate security
missions may require the same security services as high security
missions, but with lower levels of assurance. Minimal security missions
will require the fewest security services and the lowest level of
assurance.

### High Security

Missions requiring high security are generally associated with the
government or military sector. Secure access to the spacecraft control
system is required at all times during the mission and under all
possible operational or environmental conditions. The mission data
system must be protected from unauthorised access and measures must be
implemented to prevent detection, interception, and exploitation of the
data links.

The following security requirements are likely for high security
missions:

a\) protection of all telecommand data:

-- confidentiality,

-- authentication,

-- access controls,

-- data integrity (including anti-replay measures);

b\) protection of all telemetry data:

-- confidentiality,

-- integrity,

-- possibly other security services such as authentication;

c\) protection of all data in the ground data system:

-- confidentiality,

-- authentication,

-- data integrity,

-- access controls.

### Moderate Security

Missions requiring moderate security may include commercial
communications, meteorological, and remote sensing missions. Satellite
navigation systems may also be included in this class.

These missions will require spacecraft and ground system protection from
unauthorised access and may need to protect payload data that is
commercially or operationally sensitive, or safety-critical. Protection
from unauthorised access is especially important if the mission utilises
open ground networks such as the Internet to provide ground station
connectivity.

At a minimum, moderate security missions are likely to have the
following security requirements:

a\) protection of telecommand data:

-- authentication,

-- data integrity,

-- possible requirement for confidentiality;

b\) protection of some or all telemetry data:

-- confidentiality,

-- integrity;

c\) protection of some or all data in the ground data system:

-- authentication,

-- data integrity,

-- possible requirement for confidentiality.

### Minimal Security

Missions requiring minimal security include all other space missions.
These missions are likely to require security of the telecommand system
to prevent unauthorised access or tampering with the data, either
intentionally or unintentionally. For manned missions, which may fall
into this class, telecommand system security is particularly important
to ensure the safety of life. There may also be confidentiality
requirements for specific telemetry information (e.g., medical data
within manned missions).

Minimal security missions are likely to have the following security
requirements:

a\) protection of all telecommand data:

-- authentication,

-- data integrity,

-- possible requirements for confidentiality;

b\) protection of some telemetry data: confidentiality;

c\) protection of some data in the ground data system: confidentiality.

# SECURITY MECHANISMS

## CONFIDENTIALITY

The security mechanism for confidentiality is *encryption*. Encryption
can also contribute to the achievement of other security mechanisms such
as data integrity and authentication. Encryption, when used for
confidentiality, transforms sensitive data to a less sensitive form.
When used for integrity or authentication, cryptographic techniques are
used to generate unforgeable functions such as a digital signature as
described in 4.2.

Encryption is performed on *plaintext* to produce *ciphertext*. The
reverse process is known as decryption. A key is used during both
encryption and decryption to direct specific transformations as part of
the cryptographic process as shown in figure 4-1. When a key is changed,
different ciphertext is obtained. The security of the encryption process
is dependant on the cryptographic algorithm being used and the secrecy
of the deciphering key. Sometimes, details of the cryptographic
algorithm being used are publicly known, as is the case with the Data
Encryption Standard (DES) algorithm published in 1977. In this case,
security of the system is totally dependent on secure key distribution.

Figure 4-1: The Concept of Encryption and Decryption

Encryption algorithms may be *symmetric* or *asymmetric*. In a symmetric
key encryption system both the encryption and decryption keys are kept
secret. Thus, a secure key distribution system must be implemented to
generate, distribute, and account for all the keys that are required in
the system. DES is an example of a symmetric cryptographic algorithm.

In an asymmetric system, each communicating end-system has a key-pair --
a public key and a private key. The private key is kept secret, but the
public key is made available to anyone who wants it. An asymmetric (or
public key) system relies on the fact that it is practically impossible
to obtain knowledge of the decryption key from knowledge of the
encryption (public) key. This is based on the difficulty of finding
prime factors of large numbers. The public key does not need to remain
secure, which implies that no prior secret key exchange is required, and
which in-turn leads to reduced security development and operations
costs. The most well known 'public key' algorithm is RSA, which is by
far the most commercialised system currently in use. However, in
practice RSA uses a combination of public and private key systems to
improve efficiency.

Before it is used, any cryptographic system must be subjected to
analysis in order to discover if there are any weaknesses that could be
exploited by a potential attacker. During this analysis, the following
worst case assumptions are usually made:

a\) an attacker has complete knowledge of the algorithm;

b\) an attacker has obtained a considerable amount of ciphertext;

c\) an attacker knows the plaintext equivalent of a certain amount of
ciphertext.

As a result, the key must be distributed and maintained securely, as it
is the primary means by which information is protected.

There are many different types of cryptographic algorithms that operate
in different modes. For example, a *stream cipher* enciphers one bit of
plaintext at a time, whereas a *block cipher* enciphers data in blocks,
which can be more convenient for octet-oriented systems. The DES
algorithm is a block cipher that has a 64-bit input and produces a
64-bit output under the control of a 56-bit key. Detailed information on
cryptographic algorithms can be found elsewhere (see reference \[10\]).

## AUTHENTICATION

Authentication is usually achieved by appending an extra unit of
information to the original message. This extra unit of information is
called the *digital signature* as shown in figure 4-2. The digital
signature definitively identifies the origin of the data, and the
receiver of the data is thus assured that the data is from the claimed
source. The essential characteristic of the digital signature mechanism
is that the signed data unit cannot be created by an unauthorised
entity.

![](media/image6.wmf)

Figure 4-2: Digital Signature Concept

Many digital signature generation mechanisms require the use of an
asymmetric cryptographic algorithm where sender and receiver do not hold
the same cryptographic keys (as described in 4.1). Rather, a pair of
public and private keys that are mathematically related to one another
are used. At the origin of the data, the cryptographic algorithm
generates an encrypted digital signature using the sender's private key.
The signature may be generated from the data itself and is of a specific
length depending on the algorithm used. Data origin authentication is
achieved when the digital signature is successfully verified by the
receiver using the sender's public key.

Encryption of the data itself can also provide implicit authentication
when using a symmetric cryptographic algorithm. Authentication is
achieved because the recipient must have and use the correct key to
decipher the digital signature appended to the data. This assumes there
is an assured key distribution mechanism. Also, encryption provides
implicit authentication when using an asymmetric (public key) system if
there is assurance that the public key is bound to the originator (e.g.,
signed by a certificate authority).

## DATA INTEGRITY 

Data integrity can be considered as having two different functions: the
integrity of the individual data units, and the integrity of a stream of
data units. Different mechanisms are generally used to provide these
different integrity functions.

Integrity of individual data units is achieved by appending an
*Integrity Check Value* *(ICV)* to the data structure in a similar way
to the way a digital signature is appended. However, the ICV is always a
function of the data itself. A Cyclic Redundancy Check (CRC) is a simple
example of such a function. The receiver generates a corresponding check
value by performing an operation (which may be cryptographic) on the
data and comparing the result to a received value to determine if the
data has been modified in transit. In some applications, both
authentication and individual data unit integrity can be provided by one
mechanism.

To provide integrity of a stream of data units, some form of sequence
numbering is usually implemented which protects against replay attack.
Otherwise, time-stamping of data may be used to provide limited replay
protection.

## ACCESS CONTROL

The basic function of access control is to ensure the availability of
data for authorised users. As a result of ensuring data availability,
access control mechanisms may provide limited confidentiality and
integrity. It should be noted, however, that access control is not a
fundamental technique for providing these other two security services;
it is purely a barrier in the path of a potential intruder.

Access control requires the use of a number of techniques, including the
establishment of access control information bases, where the access
rights of users are maintained securely. User authentication information
such as user IDs and passwords provide management and control of user
access to the system. Passwords should be administered effectively by
establishing details such as appropriate password length and content,
implementing procedures for regularly changing passwords, and ensuring
that password secrecy is maintained. It should be noted that automation
of password generation increases security significantly. Also, plaintext
passwords should not be transmitted over an unprotected medium. Audit
trails are an important mechanism in security management. They are used
to monitor system usage and password changes and should contain as much
information regarding the system user details and previous accesses as
possible.

# CCSDS SECURITY IMPLEMENTATION OPTIONS

## Overview

This implementation guide considers the incorporation of security within
four specific layers within the space mission data system, the
application, network, link, and physical layers as shown in figure 5-1.
The various security options considered are described in this section,
and the implications on the defined services of each layer are presented
in section 6. At the application layer, only access control services are
considered.

![](media/image7.wmf)

Figure 5-1: Security Implementation Options Considered in this Report

## BULK ENCRYPTION

Bulk encryption provides *confidentiality* to all of the communication
system data structure. It is implemented at the physical layer and
provides the highest possible level of data confidentiality available on
a point-to-point basis. No separate integrity, authentication or access
control services are implied other than those implicitly provided by
encryption. For example, if symmetric key encryption is used,
authentication is implicitly achieved, because the receiving end must
have the correct key, which has been distributed by an assured key
distribution system, in order to decipher the data.

If applied to missions using the CCSDS Recommendations, bulk encryption
would result in encryption of the full physical layer data structure.
For telecommand (see reference \[1\]), use of bulk encryption implies
that the Command Link Transmission Unit (CLTU) as well as the
acquisition and idle sequences would be encrypted. For telemetry (see
reference \[4\]), the Channel Access Service Data Unit (CA_SDU) as
defined in the Packet Telemetry Services Blue Book (reference \[11\])
would be encrypted. A similar result would be obtained if bulk
encryption were applied to AOS (see reference \[5\]), where the full
Physical Channel Access Protocol Data Unit (PCA_PDU) would be encrypted.

The implications of bulk encryption on the various physical-layer
protocol data structures are shown in figure 5-2 and discussed in
section 6.

![](media/image8.wmf)

Figure 5-2: Bulk Encryption of CCSDS Protocols

## Data Link Security

Within this report, the conventional CCSDS data link layers are defined
to include all the protocol layers defined within the CCSDS Telecommand
(references \[1\], \[2\], and \[3\]) and Packet Telemetry (reference
\[4\]) Recommendations *except the packet layer*. The packet layer
(including the packet header and data fields) is assumed to be located
at the network layer.

The AOS data link layer includes all the AOS point-to-point Space Link
Subnet (SLS) services defined in the AOS Recommendation (see reference
\[5\]). These are:

-- VCDU service;

-- VCA service;

-- Bitstream service;

-- Insert service;

-- Encapsulation service;

-- Multiplexing service.

The AOS Path and Internet services are assumed to be part of the network
layer.

The CCSDS data link layer provides protocol synchronisation, increases
the space data link performance by implementing channel coding
mechanisms, and provides low-level data routing functions. Also, a
reliable data channel is provided through the ARQ process within the
tele­command and AOS data link protocols (not available within the
conventional telemetry data link). The link layer operates on the space
link of the data transmission path only (i.e., not end-to-end).

A range of security services may be applied at the Telecommand (TC),
Telemetry (TM) and AOS data link layers to provide confidentiality,
integrity and authentication services. Implementation of access control
at the data link layer is not considered; it is assumed to be provided
at the application layer (layer 7).

It should be noted that security services do not have to be applied to
all data units in the space link. Security services can be selectively
applied to different Virtual Channels (Telecommand, Packet Telemetry,
and AOS) and Master Channels (Packet Telemetry) provided that frame
headers are not encrypted. This selective application corresponds to
Option B data link security as defined in the following sections.
However, selective Virtual or Master Channel security may increase the
difficulty of implementation, because of the incorporation of different
encryption/authentication algorithms within the system, and implies an
increased level of key management complexity.

### Telecommand Data Link Security

For TC data link security, two options are considered in this report:

*Option A*: Implementation of security services below the transfer
sublayer.

*Option B*: Implementation of security services below the segmentation
sublayers.

Figure 5-3 outlines these two options with new *security layers* at the
appropriate point in the data system. Each option has particular
benefits, which are discussed, in section 6.

Figure 5-3: Telecommand Data Link Layer Security Options

Within both Option A and Option B, the security layer is incorporated
between the relevant layers of the TC system. The necessary security
services can then be contained within one layer, which will reduce the
impact of security on the TC system and ensure 'clean' layering.

The basic mode of operation is encapsulation of the protocol data unit
at that layer (Transfer Frame for Option A, Segment for Option B) within
a new security layer protocol. The security layer protocol may implement
confidentiality, authentication, and integrity services as required by
the mission. The security protocol is likely to require additional
headers and trailers to be added to the data structure. An example of
the headers and trailers that may be required is provided by the SCPS
Security Protocol (SCPS-SP) as described in 5.4.1.

The implications of security on the TC data link protocol are discussed
in section 6. Some examples of security service implementation within
the TC data link protocol are presented below.

**Confidentiality**

*Option A:* The TC transfer frame is encrypted; however, the coding
layer Forward Error Correction (FEC) octets and start/tail sequences are
not encrypted.

*Option B:* The TC segment is encrypted; however, the transfer frame
header and error control field are not encrypted.

**Authentication**

*Option A:* An authentication signature is appended to the transfer
frame (after the error control field).

*Option B:* An authentication signature is appended to the segment.

**Data Integrity**

*Option A:* An ICV is appended to the transfer frame before the
authentication signature (note that some authentication mechanisms may
also provide data integrity).

*Option B:* An ICV is appended to the segment before the authentication
signature.

### Telemetry Data Link Security

For conventional TM data link security, two options are also considered
as shown in figure 5-4.

*Option A:* Implementation of security services below the TM Transfer
Frame.

*Option B:* Implementation of security services above the TM Transfer
Frame.

![](media/image10.emf)

Figure 5-4: Telemetry Data Link Layer Security Options

As in the telecommand case, the security services required by the
mission may be implemented within one security layer to limit the impact
of security on the system. Figure 5-4 shows Telemetry Packets being
multiplexed into the Transfer Frame Data Field; however, the Privately
Defined Data Field (see reference \[11\]) may also be carried in the
Transfer Frame Data Field and protected by either security Option A or
B.

For Option A, the full TM Transfer Frame is encrypted after any other
necessary security services (e.g., data integrity) are applied. The
synchronisation word, which may be applied at the TM logical link or
channel coding sublayers depending on the on-board implementation,
should remain in plaintext to enable the ground systems to delimit the
Channel Access Service Data Units (CA_SDU).

For Option B, the security services are applied to the Transfer Frame
Data Field. For example, the application may include the addition of an
ICV and encryption of the Transfer Frame Data Field. The Transfer Frame
headers and trailers will remain in plaintext. In this case, the
optional Frame Secondary Header (64 octets maximum) may be used for
security management functions such as key identification.

### AOS Data Link Security

##  {#section .unnumbered}

The approach for AOS data link security is similar to the conventional
case with two possible options shown in figure 5-5. Option A
incorporates security services below the Virtual Channel Access (VCA)
sublayer and provides a high level of protection as the complete Virtual
Channel Data Unit (VCDU) is protected. Option B enables data protection
and other security services to be applied to separate Virtual Channels,
whilst retaining cross-support capability. Also, with Option B the
security mechanisms would not interfere with the standard SLS
verification techniques and would permit recovery from the effects of
errors or interruptions in the communications process.

![](media/image11.wmf)

Figure 5-5: Location of AOS Security Services

If implemented within the VCA sublayer of the Space Link Subnet (Option
B), the digital signature, ICV, and encrypted portion of the data should
be included completely within the data field of the VCDU and should not
interfere with the processing of header or trailer information. One
possible location for the digital signature and/or ICV is the Insert
Zone. The Insert Zone can also be used for other security management
functions such as key identification or cryptographic synchronisation.

The data structure impact of implementing security services at the VCA
sublayer is shown in figure 5-6. This implementation approach for AOS
security has been taken by a number of operational and planned missions
(see annex A).

![](media/image12.emf)

Figure 5-6: AOS VCA Sublayer Security

## Network Layer Security

### SCPS-SP

As part of the Space Communications Protocol Specification (SCPS)
programme, a Security Protocol (SP) has been developed to operate at the
network layer in the OSI stack as indicated in figure 3-1. It is an
optional protocol that may be included if the user requires *end-to-end*
security services and is utilising the other protocols in the SCPS
stack. SCPS-SP is based on several other layer three U.S. Department of
Defence, ISO, and Internet security protocols and has been refined for
space applications to ensure minimal transmitted bit overhead (see
reference \[8\]).

The primary benefit of SCPS-SP is its ability to provide end-to-end
security, i.e., from the source of the data to its final destination.
Any non-security related intermediate systems and networks will not have
access to the data unless explicitly authorised, and therefore unsecure
networks may be utilised to transmit sensitive data. The communication
end points are implementation specific and are defined by the
implementing system. SCPS-SP does not mandate any specific security
algorithm but defines the protocol framework to provide network layer
data confidentiality, integrity, and authentication services for space
communications systems.

The structure of SCPS-SP is shown in figure 5-7. The protocol adds a
clear header of 8 bits (minimum), a protected header of 8 bits (minimum)
plus options, and a variable length ICV to the protocol data unit from
the layer above (e.g., the SCPS Transport Protocol). All of the data
except for the clear header is encrypted by a user-defined,
implementation-specific algorithm.

Figure 5-7: SCPS Security Protocol Structure

### Space Packet Protocol Security

Security may be applied at the space packet layer to protect the
telecommand and telemetry data, or to achieve spacecraft command
authentication. It can be achieved by encrypting the packet data field
for confidentiality and including a digital signature and/or ICV within
the packet data field for authentication and data integrity,
respectively. The space packet protocol headers would remain
unencrypted.

The concept of space packet layer security is shown in figure 5-8. Only
the application data field is encrypted. The optional secondary header
may be also encrypted. All other protocol fields in the lower layers of
the system remain in plaintext.

![](media/image14.wmf){width="3.7291666666666665in"
height="1.1458333333333333in"}

Figure 5-8: CCSDS Packet Security Concept

##  {#section-1 .unnumbered}

It should be noted that if a mission requires security of selected
packets in the space link, then the Application Process Identifier
(APID) in the packet header may be used to differentiate between
encrypted or plaintext packets.

##  {#section-2 .unnumbered}

## Application Security

Security services may be applied at the application layer; however, in
the case of a space mission using the space packet protocol,
implementation of confidentiality, integrity, and authentication
services are likely to be similar to the space packet security case as
outlined in 5.4.2.

The primary security service to be applied at the application layer is
access control. Access control may be achieved by implementing secure
user-access-right database facilities at the mission data system access
points. Further details on implementation of such facilities are beyond
the scope of this report.

## ccsds security option Combinations

### General

To meet specific space mission requirements, it may be necessary to
utilise a combination of the CCSDS security options defined in the
previous sections. In this case security services may be implemented in
multiple layers of the mission data system simultaneously.

For example, some advanced high security missions may require a
combination of the network layer security to provide end-to-end data
protection, particularly across ground networks, and lower layer
security operating over only the space link to prevent traffic analysis
between the ground and space segments. This concept, with the respective
security end points, is shown in figure 5-9.

![](media/image15.wmf){width="5.961111111111111in"
height="2.6180555555555554in"}

Figure 5-9: CCSDS Data Link and Network Security Combination
Architecture

Space systems with a number of in-orbit resources and inter-satellite
communications may also utilise the concepts proposed in the combination
solution shown in figure 5-9. The combination solution may be conceived
with link layer security operating on the ground-to-space links only,
and network layer security operating on the communications links between
different spacecraft and in the ground network.

# CCSDS SECURITY IMPLICATIONS

## Impact of encryption

In general, confidentiality has the greatest impact on the CCSDS
architecture and services, as compared with authentication and data
integrity services, because specific protocol information (headers and
trailers) may be hidden through encryption and may therefore be
unavailable for use for other network or cross-support services. In
contrast, authentication and data integrity services usually require
inclusion of a small number of additional fields at an appropriate point
in the data structure.

The impact of confidentiality on the various CCSDS layer fields for the
different security options is shown in table 6-1. The fields that are
unencrypted are shown as 'Plain'.

Table 6-1: Impact of Confidentiality on CCSDS Data Fields

  -------------------- ----------- ----------- ----------- ---------- ----------- ----------- ------------
  **CCSDS Security     **ASM +     **Frame     **Frame     **Packet                           **Packet
  Option**             EDAC**      Header**    Data        Header**                           Data Field**
                                               Field**                                        

  Network Layer        Plain       Plain       Plain                  Plain       Encrypted   
  Security                                                                                    

  Data Link (Option B) Plain       Plain       Encrypted              Encrypted   Encrypted   

  Data Link (Option A) Plain       Encrypted   Encrypted              Encrypted   Encrypted   

  Physical (Bulk       Encrypted   Encrypted   Encrypted              Encrypted   Encrypted   
  Encryption)                                                                                 

  (ASM - Attached                                                                             
  Synchronisation                                                                             
  Marker, EDAC - Error                                                                        
  Detection and                                                                               
  Correction)                                                                                 
  -------------------- ----------- ----------- ----------- ---------- ----------- ----------- ------------

## IMPACT ON CROSS-SUPPORT SERVICES

The CCSDS Space Link Extension (SLE) cross-support services are a set of
services that provide access to the ground termination of the space link
services from a remote ground-based system (see reference \[12\]). The
SLE services can be separated into two categories:

-- Return SLE services;

-- Forward SLE services.

### Return SLE Services

The various types of cross-support services have been split into
different Functional Groups (FGs) based on the CCSDS Reference Model
layers. Figure 6-1 shows FGs and services included in the Return SLE
architecture and the impact that each of the CCSDS security options has
on the SLE services provided. The impact is defined as whether the
cross-support service is available or not when using that particular
security option. The CCSDS security implementation options covered
include Options A and B data link security and space packet (network)
layer security. Physical layer security is not considered because
cross-support services are not available for this option (it is assumed
that the data can be decrypted only by the end user and that no protocol
information is available to enable cross-support).

![](media/image16.emf)

Figure 6-1: Impact of Security on Return SLE Services

### Forward SLE Services

Figure 6-2 shows the Forward SLE services in FGs based on the CCSDS
Reference Model and the impact that each of the security options has on
the services provided. The CCSDS security implementation options covered
include Options A and B data link security and space packet (network)
layer security. Again, physical layer security is not considered.

![](media/image17.emf)

Figure 6-2: Impact of Security on Forward SLE Services

## SECURITY OPTION COMPARISION

### Physical Layer or Bulk Encryption

Physical layer security (bulk encryption) provides the highest possible
level of data confidentiality for space mission data systems on a
point-to-point basis. No additional security services are implied other
than those provided by the encryption mechanism used to provide data
confidentiality.

The application of bulk encryption to the CCSDS conventional
telecommand, telemetry, and AOS Recommendations will deny all
cross-support services without pre-placed copies of the encryption keys
at system access points. Also, bulk encryption does not allow the CCSDS
link layer synchronisation services to operate, and, as a result, the
cryptographic devices utilised would need to provide data
synchronisation.

Bulk encryption does not allow any Error Detection and Correction (EDAC)
information to be available in plaintext. Thus, all CCSDS channel coding
services would be rendered meaningless, as the data must be acquired,
synchronised, and decrypted before the coding sublayer information
becomes available. The CCSDS EDAC information would therefore be
unnecessary overhead in such a scheme. However, it should be noted that
some high-grade cryptographic devices may include independent EDAC
functionally.

Bulk encryption does not provide any concept of end-to-end security in
the OSI sense. It is applied to the data on a hop-by-hop basis with a
cryptographic device at each node in the communications network.

In summary, the security requirements of high security missions would be
satisfied by bulk encryption at the physical layer; however, specific
operational benefits provided by the CCSDS Recommendations would not be
available.

### Data Link Security

Data link layer security can be considered as a compromise for missions
requiring a relatively high level of security but opting to retain a
number of CCSDS benefits. The CCSDS data structure may be used
throughout the mission data system; however, only the coding sublayer of
the data link layer and the physical layer remain in plaintext.

Traffic flow security is provided through encryption of the data link
layer headers and trailers by implementing encryption below the data
link transfer layers (Option A in 5.3). Specific CCSDS data link
benefits such as link synchronisation and performance enhancement
through EDAC mechanisms are retained as the EDAC information remains in
plaintext over the space link.

Data link layer encryption does not provide end-to-end security in the
OSI sense. It is applied to the data on a hop-by-hop basis; however,
some low-level cross-support services are available to extend the secure
space link within the ground network.

### Network and Application Layer Security

SCPS-SP provides security on an end-to-end basis, from the source of the
transmitted data to the final destination. For example, an instrument
control centre could be one end point where the security services
(confidentiality, integrity, and authentication) are applied to the
data, and an instrument on board a spacecraft could be the other end
point. All intermediate systems, such as routers, gateways, and control
centres, would not have access to the user data unless explicitly
authorised.

In order to provide end-to-end security, the SCPS-SP approach allows the
headers from the layers below (e.g., network, link, and physical) to
remain in plaintext to enable the intermediate routing of the SCPS-SP
protocol data units. Thus, traffic analysis protection is not provided,
and the encrypted data may be intercepted in the intermediate networks.

The CCSDS packet protocol or application-layer security approaches are
suitable for implementations requiring protection of only the
application data itself. However, there may be requirements for a number
of different application-specific security mechanisms, which could lead
to duplicated effort or more importantly to the introduction of security
flaws in the system (see 6.4.1).

##  {#section-3 .unnumbered}

## Security Option Selection

### Choice of Position of Encryption

Most space missions that require confidentiality services will not
require encryption at more than one layer in the data systems
architecture. By limiting the implementation of encryption to one layer,
the following benefits are obtained:

-- a simplified system security approach;

-- minimised security-development and operating costs;

-- low overall security processing requirements on the data system.

Also, if encryption implementation is limited to the network layer or
below, different applications will not need to implement their own
encryption mechanisms. Multiple encryption mechanisms duplicate effort
and could introduce security flaws as well as increase development and
operations cost. Flaws can be introduced through multiple
implementations where not all of the implementations are performed
correctly. There is less chance of propagating problems if a single,
verified encryption implementation is used within the space data system.

If full traffic analysis protection is required, then encryption will
need to be implemented at the physical layer on a hop-by-hop basis.
Physical layer encryption (or bulk encryption) may be combined with
transmission security techniques such as frequency hopping or spread
spectrum to enhance the level of security by reducing the probability of
detection and interception of the RF link.

If a mission requires a high level of security with some traffic flow
confidentiality, and requires key benefits provided by use of CCSDS
Recommendations, then data link layer security will provide the
solution. It is noted that data link layer security will operate almost
exclusively over the space link only; however, low-level SLE services
(Return All Frames and Forward CLTU) may be used to extend the secure
space data link within the ground network.

If a mission requires confidentiality of different virtual channels,
which could correspond to confidentiality between different payloads on
a shared spacecraft, then encryption should be included above the frame
sublayer (conventional transfer frame or AOS VCDU) within the data link
layer. This approach corresponds to the conventional CCSDS 'B options'
and AOS security approach described in 5.3.

If a mission requires end-to-end protection of all data in the space
mission data system, then network-layer encryption should be chosen.
Depending on the mission data system architecture, network-layer
encryption may be implemented via use of the SCPS-SP confidentiality
service or via encryption of the space packet protocol as described in
5.4.

If a mission requires a high granularity of data protection (for
example, a separate key for encryption of different application data in
the system) or selective field data protection, then encryption of the
different application processes is necessary. Although more complex to
implement, selective field encryption may be beneficial to protect only
the sensitive fields in the application data, as most cryptographic
algorithms consume large amounts of processing power.

If a mission requires high security over the RF medium, with additional
end-to-end security services in the ground network or on board the
spacecraft, then encryption may need to be provided at more than one
layer. For example, bulk encryption or data link layer security may be
applied on all space-ground and ground-space links with additional
encryption at the network layer to achieve end-to-end data protection.

### Location of Other Security Services

The choice of implementation of authentication, data integrity, and
access control services has less impact on the data system architecture.
For example, it may be beneficial to locate the additional fields (e.g.,
digital signature, ICV, sequence number) that may be required for
authentication and data integrity services at the same layer as
encryption to keep all security services in one 'clean' security layer.

Otherwise, it may be more appropriate to provide authentication and data
integrity between different network-layer or application-layer entities.
The choice is very much dependent on the data system's architecture, the
protocol in use, and the mission security requirements.

Access control security services are likely to be implemented at the
application layer. Many missions may wish to utilise the access control
mechanisms built into network operating systems (e.g., Windows NT).

########   Specific Agency Implementations

A1 THE ESA TELECOMMAND AUTHENTICATION APPROACH

ESA have standardised their approach to telecommand authentication
within the ESA Packet Telecommand Standard (reference \[14\]). The
technique appends a digital signature (generated by an authentication
algorithm with a secret key, the command data, and an additional
counter) to the telecommand packet as part of the segmentation layer.
The inclusion of a counter, which increments each time a telecommand
segment is successfully authenticated on board the spacecraft, provides
protection against replay attack (i.e., anti-spoofing). In effect, an
authentication and data integrity sublayer is included between the
transfer sublayer and the segmentation sublayer. Data confidentiality
services are not provided by the system.

ESA have specified that a nine octet 'authentication tail' be added to
the segmentation layer. The general layout of the layer is shown in
figure A-1. The counter is defined as a two-bit identifier and
thirty-bit count number. The authentication signature is a five-octet
data field. The ESA authentication approach is similar to the space
packet layer security concept described in 5.4.2 with authentication and
data integrity services implemented.

Figure A-1: ESA Telecommand Authentication Sublayer Structure

A2 INTERNATIONAL SPACE STATION

The International Space Station (ISS) mission communications system will
utilise the AOS Recommendation (reference \[5\]) for the telecommand and
telemetry links. The Multiplex Protocol Data Unit (MPDU) and Bitstream
services will be used to support different data types.

Encryption using the Data Encryption Standard (DES) algorithm will be
incorporated on the uplink at the VCA sublayer as described in 5.3 of
this report. This means that the VCDU data unit zone will be encrypted.
The insert zone (set to 64 bits) will be used to provide cryptographic
synchronisation.

A3 EUMETSAT

EUMETSAT are planning to implement security on the downlink of the METOP
polar orbiting spacecraft. The proposed location of security is similar
to the ISS implementation, with the VCDU data zone encrypted via the DES
algorithm. The insert zone (set to 16 bits) is used for encryption
control.

EUMETSAT have also implemented encryption on the Meteosat Second
Generation (MSG) spacecraft. It is understood that NOAA have implemented
or are planning similar confidentiality systems on their spacecraft.

A4 THE SPACE TECHNOLOGY RESEARCH VEHICLE 1C/D MISSIONS

The Space Technology Research Vehicle (STRV) 1c/d microsatellite
missions are planning to implement conventional CCSDS data link layer
security on the telecommand and telemetry links. This corresponds to the
Option A security layers in 5.3. Confidentiality and authentication
services are planned to be implemented as part of the security layer on
the telecommand link, with confidentiality only on the telemetry link.