Draft Recommendation for
Space Data System Standards
SPACE DATA LINK
SECURITY PROTOCOL
PROPOSED STANDARD
CCSDS 355.0-R-1
RED BOOK
February 2016
DRAFT CCSDS RECOMMENDED STANDARD FOR SPACE DATA LINK SECURITY
AUTHORITY
Issue:
Red Book, Issue 1
Date:
February 2016
Location:
Not Applicable
(WHEN THIS RECOMMENDED STANDARD IS FINALIZED, IT WILL CONTAIN
THE FOLLOWING STATEMENT OF AUTHORITY:)
This document has been approved for publication by the Management Council of the
Consultative Committee for Space Data Systems (CCSDS) and represents the consensus
technical agreement of the participating CCSDS Member Agencies. The procedure for
review and authorization of CCSDS documents is detailed in the Procedures Manual for the
Consultative Committee for Space Data Systems, and the record of Agency participation in
the authorization of this document can be obtained from the CCSDS Secretariat at the
address below.
This document is published and maintained by:
CCSDS Secretariat
Space Communications and Navigation Office, 7L70
Space Operations Mission Directorate
NASA Headquarters
Washington, DC 20546-0001, USA
CCSDS 355.0-R-1
Page i
February 2016
DRAFT CCSDS RECOMMENDED STANDARD FOR SPACE DATA LINK SECURITY
FOREWORD
This document describes a protocol for applying security protections to the contents of Space
Data Link Protocol transfer frames used by space missions over a space link.
Through the process of normal evolution, it is expected that expansion, deletion, or
modification of this document may occur. This Recommended Standard is therefore subject
to CCSDS document management and change control procedures, which are defined in the
Procedures Manual for the Consultative Committee for Space Data Systems. Current
versions of CCSDS documents are maintained at the CCSDS Web site:
http://www.ccsds.org/
Questions relating to the contents or status of this document should be addressed to the
CCSDS Secretariat at the address indicated on page i.
CCSDS 355.0-R-1
Page ii
February 2016
DRAFT CCSDS RECOMMENDED STANDARD FOR SPACE DATA LINK SECURITY
At time of publication, the active Member and Observer Agencies of the CCSDS were:
Member Agencies
–
–
–
–
–
–
–
–
–
–
–
Agenzia Spaziale Italiana (ASI)/Italy.
British National Space Centre (BNSC)/United Kingdom.
Canadian Space Agency (CSA)/Canada.
Centre National d’Etudes Spatiales (CNES)/France.
China National Space Administration (CNSA)/People’s Republic of China.
Deutsches Zentrum für Luft- und Raumfahrt e.V. (DLR)/Germany.
European Space Agency (ESA)/Europe.
Federal Space Agency (FSA)/Russian Federation.
Instituto Nacional de Pesquisas Espaciais (INPE)/Brazil.
Japan Aerospace Exploration Agency (JAXA)/Japan.
National Aeronautics and Space Administration (NASA)/USA.
Observer Agencies
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
Austrian Space Agency (ASA)/Austria.
Belgian Federal Science Policy Office (BFSPO)/Belgium.
Central Research Institute of Machine Building (TsNIIMash)/Russian Federation.
Centro Tecnico Aeroespacial (CTA)/Brazil.
Chinese Academy of Sciences (CAS)/China.
Chinese Academy of Space Technology (CAST)/China.
Commonwealth Scientific and Industrial Research Organization (CSIRO)/Australia.
Danish National Space Center (DNSC)/Denmark.
European Organization for the Exploitation of Meteorological Satellites
(EUMETSAT)/Europe.
European Telecommunications Satellite Organization (EUTELSAT)/Europe.
Hellenic National Space Committee (HNSC)/Greece.
Indian Space Research Organization (ISRO)/India.
Institute of Space Research (IKI)/Russian Federation.
KFKI Research Institute for Particle & Nuclear Physics (KFKI)/Hungary.
Korea Aerospace Research Institute (KARI)/Korea.
MIKOMTEK: CSIR (CSIR)/Republic of South Africa.
Ministry of Communications (MOC)/Israel.
National Institute of Information and Communications Technology (NICT)/Japan.
National Oceanic and Atmospheric Administration (NOAA)/USA.
National Space Organization (NSPO)/Chinese Taipei.
Naval Center for Space Technology (NCST)/USA.
Space and Upper Atmosphere Research Commission (SUPARCO)/Pakistan.
Swedish Space Corporation (SSC)/Sweden.
United States Geological Survey (USGS)/USA.
CCSDS 355.0-R-1
Page iii
February 2016
DRAFT CCSDS RECOMMENDED STANDARD FOR SPACE DATA LINK SECURITY
PREFACE
(WHEN THIS PROPOSED STANDARD IS RELEASED FOR FORMAL AGENCY
REVIEW, IT WILL CONTAIN THE FOLLOWING STATEMENT OF
AUTHORITY:)
This document is a draft CCSDS Recommended Standard. Its draft status indicates that the
CCSDS believes the document to be technically mature and has released it for formal review
by appropriate technical organizations. As such, its technical contents are not stable, and
several iterations of it may occur in response to comments received during the review process.
Implementers are cautioned not to fabricate any final equipment in accordance with this
document’s technical content.
CCSDS 355.0-R-1
Page iv
February 2016
DRAFT CCSDS RECOMMENDED STANDARD FOR SPACE DATA LINK SECURITY
DOCUMENT CONTROL
Document
Title and Issue
Date
Status
CCSDS
355.0-R-1
Space Data Link Security Protocol,
Draft Recommended Standard,
Issue 1
February
2016
Current draft
CCSDS 355.0-R-1
Page v
February 2016
DRAFT CCSDS RECOMMENDED STANDARD FOR SPACE DATA LINK SECURITY
CONTENTS
Section
Page
DOCUMENT CONTROL......................................................................................................V
CONTENTS........................................................................................................................... VI
1 INTRODUCTION.......................................................................................................... 1-1
1.1 PURPOSE ............................................................................................................... 1-1
1.2 SCOPE .................................................................................................................... 1-1
1.3 APPLICABILITY ................................................................................................... 1-1
1.4 RATIONALE.......................................................................................................... 1-2
1.5 DOCUMENT STRUCTURE ................................................................................. 1-2
1.6 DEFINITIONS........................................................................................................ 1-3
1.7 CONVENTIONS .................................................................................................... 1-5
1.8 REFERENCES ....................................................................................................... 1-5
2 OVERVIEW ................................................................................................................... 2-6
2.1 CONCEPT OF SECURITY PROTOCOL ............................................................. 2-6
2.2 FEATURES OF SECURITY PROTOCOL ........................................................... 2-6
2.2.1 INTERNAL ORGANIZATION OF PROTOCOL ENTITY ..................... 2-7
2.2.2 PLACEMENT OF THE SERVICE IN TM ................................................ 2-7
2.2.3 PLACEMENT OF THE SERVICE IN TC................................................. 2-8
2.2.4 PLACEMENT OF THE SERVICE IN AOS .............................................. 2-9
2.3 SERVICE FUNCTIONS ...................................................................................... 2-10
2.3.1 SECURITY ASSOCIATIONS ................................................................. 2-10
2.3.2 AUTHENTICATION ............................................................................... 2-11
2.3.3 ENCRYPTION ......................................................................................... 2-13
2.3.4 AUTHENTICATED ENCRYPTION....................................................... 2-14
3 SERVICE DEFINITION............................................................................................. 3-15
3.1 OVERVIEW ......................................................................................................... 3-15
3.2 SOURCE DATA................................................................................................... 3-15
3.2.1 SOURCE DATA FOR ENCRYPTION ................................................... 3-15
3.2.2 SOURCE DATA FOR AUTHENTICATION ......................................... 3-17
3.2.3 TM ENCRYPTION PAYLOADERROR! BOOKMARK NOT DEFINED.
3.2.4 TC ENCRYPTION PAYLOAD ERROR! BOOKMARK NOT DEFINED.
3.2.5 AOS ENCRYPTION PAYLOADERROR! BOOKMARK NOT DEFINED.
3.2.6 TM AUTHENTICATION PAYLOAD .................................................... 3-17
3.2.7 TC AUTHENTICATION PAYLOAD ..................................................... 3-17
3.2.8 AOS AUTHENTICATION PAYLOAD .................................................. 3-18
3.3 SECURITY ASSOCIATION (SA) MANAGEMENT SERVICE ....................... 3-18
3.3.1 SA MANAGEMENT SERVICE PARAMETERS .................................. 3-18
3.3.2 SA MANAGEMENT SERVICE PRIMITIVES ...................................... 3-20
3.4 ENCRYPTION SERVICE ................................................................................... 3-20
3.4.1 ENCRYPTION SERVICE PARAMETERS ............................................ 3-20
3.4.2 ENCRYPTION SERVICE PRIMITIVES ................................................ 3-21
3.5 AUTHENTICATION SERVICE ......................................................................... 3-21
3.5.1 AUTHENTICATION SERVICE PARAMETERS .................................. 3-22
CCSDS 355.0-R-1
Page vi
February 2016
DRAFT CCSDS RECOMMENDED STANDARD FOR SPACE DATA LINK SECURITY
4
5
6
7
3.5.2 AUTHENTICATION SERVICE PRIMITIVES ...................................... 3-22
PROTOCOL SPECIFICATION ................................................................................ 4-24
4.1 PROTOCOL DATA UNITS ................................................................................ 4-24
4.1.1 SECURITY HEADER .............................................................................. 4-24
4.1.2 SECURITY TRAILER ............................................................................. 4-25
4.2 SECURITY PROTOCOL PROCEDURES .......................................................... 4-26
4.2.1 SECURITY ASSOCIATION MANAGEMENT PROCEDURES .......... 4-26
4.2.2 SENDING PROCEDURES ...................................................................... 4-28
4.2.3 RECEIVING PROCEDURES .................................................................. 4-31
USE OF THE SERVICES WITH CCSDS PROTOCOLS ...................................... 5-34
5.1 TM PROTOCOL .................................................................................................. 5-34
5.1.1 TM TRANSFER FRAME PROCEDURES ............................................. 5-34
5.2 TC PROTOCOL ................................................................................................... 5-35
5.2.1 TC TRANSFER FRAME PROCEDURES .............................................. 5-35
5.3 AOS PROTOCOL ................................................................................................ 5-36
5.3.1 AOS TRANSFER FRAME PROCEDURES ........................................... 5-36
5.4 SUMMARY OF PROTOCOL SERVICES.......................................................... 5-37
MANAGED PARAMETERS ..................................................................................... 6-39
SECURITY ................................................................................................................... 7-41
7.1 INTRODUCTION ................................................................................................ 7-41
7.2 SECURITY CONCERNS .................................................................................... 7-41
7.3 POTENTIAL THREATS AND ATTACK SCENARIOS ................................... 7-41
7.4 CONSEQUENCES OF NOT APPLYING SECURITY ...................................... 7-42
CCSDS 355.0-R-1
Page vii
February 2016
DRAFT CCSDS RECOMMENDED STANDARD FOR SPACE DATA LINK SECURITY
1
1.1
INTRODUCTION
PURPOSE
The purpose of this Recommended Standard is to specify the Space Data Link Security
Protocol (hereafter referred as the Security Protocol) for CCSDS data links. This protocol
provides a security header and trailer along with associated procedures that may be used with
the CCSDS Telemetry, Telecommand, and Advanced Orbiting Systems Space Data Link
Protocols (references [1]-[3]) to provide a structured method for applying data authentication
and/or data confidentiality at the link layer.
1.2
SCOPE
This Recommended Standard defines the Security Protocol in terms of:
a) the protocol data units employed by the service provider; and
b) the procedures performed by the service provider.
It does not specify:
a) individual implementations or products;
b) the implementation of service interfaces within real systems;
c) the methods or technologies required to perform the procedures; or
d) the management activities required to configure and control the service.
This Recommended Standard does not mandate the use of any particular cryptographic
algorithm with the Security Protocol. Reference [5] provides a listing of algorithms
recommended by CCSDS; any organization should conduct a risk assessment before
choosing to substitute other algorithms. Annex C (non-normative) defines baseline
implementations suitable for a large range of space missions.
1.3
APPLICABILITY
This Recommended Standard applies to the creation of Agency standards and to the future
data communications over space links between CCSDS Agencies in cross-support situations.
The Recommended Standard includes comprehensive specification of the service for interAgency cross support. It is neither a specification of, nor a design for, real systems that may
be implemented for existing or future missions.
The Recommended Standard specified in this document is to be invoked through the normal
standards programs of each CCSDS Agency, and is applicable to those missions for which
cross support based on capabilities described in this Recommended Standard is anticipated.
Where mandatory capabilities are clearly indicated in sections of the Recommended
Standard, they must be implemented when this document is used as a basis for cross support.
CCSDS 355.0-R-1
Page 1-1
February 2016
DRAFT CCSDS RECOMMENDED STANDARD FOR SPACE DATA LINK SECURITY
Where options are allowed or implied, implementation of these options is subject to specific
bilateral cross support agreements between the Agencies involved.
1.4
RATIONALE
The goals of this Recommended Standard are to:
a) provide a standard method of applying security at the data link layer, independent of
the underlying cryptographic algorithms employed by any particular space mission;
b) preserve compatibility with existing CCSDS Space Data Link Protocol transfer frame
header formats and frame processing implementations so that where appropriate,
legacy frame processing infrastructure may continue to be used without modification;
and,
c) preserve compatibility with the CCSDS Space Link Extensions (SLE) forward and
return services; and
d) facilitate the development of common commercial implementations to improve
interoperability across agencies.
More discussion of the Security Protocol’s goals and design choices may be found in
reference [B1].
1.5
DOCUMENT STRUCTURE
This document is organized as follows:
Section 1 presents the purpose, scope, applicability and rationale of this Recommended
Standard and lists the conventions, definitions, and references used throughout the document.
Section 2 provides an overview of the Security Protocol.
Section 3 defines the services provided by the protocol entity.
Section 4 specifies the protocol data units provided for this service and the procedures
employed by the service provider.
Section 5 specifies the transfer frame formats and constraints associated with this service for
each of the supported Space Data Link Protocols.
Section 6 lists the managed parameters associated with this service.
Section 7 provides an overview of security concerns with using the Security Protocol.
Annex A provides a Protocol Implementation Conformance Statement.
Annex B provides a list of informative references.
CCSDS 355.0-R-1
Page 1-2
February 2016
DRAFT CCSDS RECOMMENDED STANDARD FOR SPACE DATA LINK SECURITY
Annex C defines baseline implementations suitable for a large range of space missions.
1.6
DEFINITIONS
Access Control: The process of granting access to the resources of a system only to
authorized users, programs, processes, or other systems.
Access Control Mechanism: Hardware or software features, operating procedures,
management procedures, and various combinations of these designed to detect and prevent
unauthorized access and to permit authorized access in an automated system.
Authentication: Verification of the originating source of data that have been stored,
transmitted, or otherwise exposed to possible unauthorized modification. In the context of
data transmission, this usually refers to verification by the receiver of a message
authentication code which was associated with particular data as it was generated by the
sender using a secret key. Such verification ensures both the authenticity and integrity of the
data.
Authorization: The granting to a user, program, or process (i.e., a system entity) the right to
access a system resource.
‘Black’: A condition in which data being processed or transmitted does not require
protection, either because a requirement to secure the data has already been met, or because
the data inherently has no need for protection; in the context of data transmission, this usually
refers to data in its protected state, subsequent to encryption or prior to decryption.
Bulk Encryption: The encryption of transmitted data at OSI Layer 1, such that all of the data
link-layer framing headers and higher-layer information are sent as ciphertext.
Ciphertext: Data that has been obscured by the application of encryption.
Confidentiality: Assurance that information is not disclosed to unauthorized entities or
processes.
Data Integrity: Condition that exists when data is unchanged from its source and has not been
accidentally or maliciously modified, altered, or destroyed.
Denial of Service: Any action or series of actions that prevents any part of a system from
functioning in accordance with its intended purpose. This includes any action that causes
unauthorized destruction, modification, or delay of service.
Encryption: The translation of data into a form that is unintelligible without a deciphering
mechanism. Encryption transforms ‘plaintext’ into ‘ciphertext’. Decryption, the reverse
operation, transforms ciphertext into plaintext.
Initialization Vector: Encryption algorithm-dependent data that some modes of operation
require as an additional initial input. It does not need to be secret, but in some modes, it
CCSDS 355.0-R-1
Page 1-3
February 2016
DRAFT CCSDS RECOMMENDED STANDARD FOR SPACE DATA LINK SECURITY
needs to be unpredictable. Its length is generally fixed according to the algorithm’s block
size.
Link-Layer Encryption: The encryption of transmitted data at OSI Layer 2, such that the data
link-layer framing headers are sent as plaintext but all of the upper-layer packet headers and
information are sent as ciphertext.
Network-Layer Encryption: The encryption of transmitted data at OSI Layer 3, such that the
network-layer packet headers are sent as plaintext but all higher-layer information is sent as
ciphertext.
Padding: Fill data required by certain encryption block cipher modes. If a particular mode
of operation (e.g. cipher block chaining) must operate on data units that are a multiple of the
algorithm’s block size, then any undersized blocks must be padded prior to encryption.
Plaintext: Data that has not been obscured by the application of encryption.
‘Red’: A condition in which data being processed or transmitted requires protection; in the
context of data transmission, this usually refers to data in its original state, prior to encryption
or subsequent to decryption.
Risk: A combination of the likelihood that a threat will occur, the likelihood that a threat
occurrence will result in an adverse impact, and the severity of the resulting adverse impact.
Security Association: An establishment of shared security information between two network
entities to support secure communication.
Security Parameter Index: An index used to identify a Security Association.
Security Policy: The set of laws, rules, and practices that regulate how information is
managed, protected, and distributed.
Threat: Any action (accidental or deliberate) or event (natural or environmental) with the
potential to cause harm to a system in the form of destruction, disclosure, adverse
modification of data, and/or denial of service.
Threat Analysis: The examination of all actions and events that might adversely affect a
system or operation.
Traffic Analysis: The attempt to defeat communications security by analyzing patterns in the
content and timing of communications traffic, to infer either the identity of specific parties
exchanging information or the specific information being exchanged.
Vulnerability Analysis: The systematic examination of systems in order to determine the
adequacy of security measures, identify security deficiencies, and provide data from which to
predict the effectiveness of proposed security measures.
CCSDS 355.0-R-1
Page 1-4
February 2016
DRAFT CCSDS RECOMMENDED STANDARD FOR SPACE DATA LINK SECURITY
1.7
CONVENTIONS
The following conventions apply throughout this Recommended Standard:
a) the words ‘shall’ and ‘must’ imply a binding and verifiable specification;
b) the word ‘should’ implies an optional, but desirable, specification;
c) the word ‘may’ implies an optional specification;
d) the words ‘is’, ‘are’, and ‘will’ imply statements of fact.
1.8
REFERENCES
The following documents contain provisions which, through reference in this text, constitute
provisions of this Recommended Standard. At the time of publication, the editions indicated
were valid. All documents are subject to revision, and users of this Recommended Standard
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 documents.
[1] TM Space Data Link Protocol. Recommendation for Space Data System Standards,
CCSDS 132.0-B-1. Blue Book. Issue 1. Washington, D.C.: CCSDS, September 2003.
[2] TC Space Data Link Protocol. Recommendation for Space Data System Standards,
CCSDS 232.0-B-1. Blue Book. Issue 1. Washington, D.C.: CCSDS, September 2003.
[3] AOS Space Data Link Protocol. Recommendation for Space Data System Standards,
CCSDS 732.0-B-2. Blue Book. Issue 2. Washington, D.C.: CCSDS, July 2006.
[4] Space Link Identifiers. Recommendation for Space Data System Standards, CCSDS
135.0-B-4. Blue Book. Issue 3. Washington, D.C.: CCSDS, October 2009.
[5] CCSDS Security Algorithms. Recommendation for Space Data System Standards,
CCSDS 352.0-B-1. Blue Book. Issue 1. Washington, D.C.: CCSDS, _____.
[6] Information Technology—Open Systems Interconnection—Basic Reference Model: The
Basic Model. International Standard, ISO/IEC 7498-1. 2nd ed. Geneva: ISO, 1994.
CCSDS 355.0-R-1
Page 1-5
February 2016
DRAFT CCSDS RECOMMENDED STANDARD FOR SPACE DATA LINK SECURITY
2
OVERVIEW
2.1
CONCEPT OF SECURITY PROTOCOL
The Space Data Link Security Protocol is a data processing method for space missions that
need to apply authentication and/or confidentiality to the contents of transfer frames used by
Space Data Link Protocols over a space link. The Security Protocol is provided at the Data
Link Layer (Layer 2) of the OSI Basic Reference Model [5], as illustrated in Figure 2-1. It is
an extra service of the Space Data Link Protocols defined in references [1]-[3], and therefore
shall be used together with one of these references.
OSI LAYERS
7
Application
6
Presentation
5
Session
4
Transport
3
Network
CCSDS LAYERS
Data Link Protocol Sublayer
Security Protocol
2
Data Link
Synchronization &
Channel Coding Sublayer
1
Physical
Figure 2-1. Security Protocol within OSI Model
2.2
FEATURES OF SECURITY PROTOCOL
The purpose of the Security Protocol is to provide a secure standard method, with associated
data structures, for performing security functions on octet-aligned user data within Space
Data Link Protocol transfer frames over a space link. The maximum length of input data that
can be accommodated is not limited by the Security Protocol, but is an attribute of the
underlying Space Data Link Protocol. Both Security Header and Trailer are provided for
CCSDS 355.0-R-1
Page 2-6
February 2016
DRAFT CCSDS RECOMMENDED STANDARD FOR SPACE DATA LINK SECURITY
delimiting the necessary cryptographic parameters within transfer frames. The size of the
Security Header and Trailer used will reduce the maximum size of the input data unit bytefor-byte below the maximum allowed by the underlying Space Data Link Protocol.
Features of the Security Protocol are as follows:
a) Unidirectional (one way) service: one end of a connection can send, but not receive,
data through the space link, while the other end can receive, but not send, data
through the space link.
b) Asynchronous service: There are no specified timing relationships between the
transfer of data units supplied by the user and the actual transmission mechanism
within the Data Link Layer.
c) Unconfirmed service: the sending user does not receive confirmation from the
receiving end indicating that data has been received.
d) Incomplete service: the service does not guarantee completeness, but the service
provider may signal gaps in the sequence of data units delivered to the receiving user.
e) Sequence preserving service: the sequence of data units supplied by the sending user
is preserved through the transfer over the space link, although there may be gaps in
the sequence of data units delivered to the receiving user.
In each case, the Security Protocol provides only whatever quality of service is provided by
the underlying Space Data Link Protocol.
2.2.1 INTERNAL ORGANIZATION OF PROTOCOL ENTITY
Two sublayers of the Data Link Layer are defined for CCSDS space link protocols as shown
in reference [B5]. Each of the three supported Space Data Link Protocols (TM, TC, and
AOS) correspond to the Data Link Protocol Sublayer. Operation of the Security Protocol is
unaffected by the Synchronization And Channel Coding Sublayer.
2.2.2 PLACEMENT OF THE SERVICE IN TM
The conceptual order of processing of the Security Protocol’s functions with respect to other
functions of the TM Protocol is shown in Figure 2-2. Depending on the security services
actually used, not all of the functions may be present in a real system.
CCSDS 355.0-R-1
Page 2-7
February 2016
DRAFT CCSDS RECOMMENDED STANDARD FOR SPACE DATA LINK SECURITY
(SENDING END)
Packet
Service
(RECEIVING END)
VC Access
Service
Packet
Service
Packet
Processing
VC Access
Service
Packet
Extraction
Encryption
VC_FSH VC_OCF
Service Service
Decryption
VC Frame
Service
Virtual Channel Generation
Virtual Channel Reception
MC_FSH MC_OCF
Service Service
Virtual Channel Multiplexing
VC Frame
Service
Virtual Channel Demultiplexing
Master Channel Generation
Message Authentication
VC_FSH VC_OCF
Service Service
MC_FSH MC_OCF
Service Service
Master Channel Reception
MC Frame
Service
Message Verification
Master Channel Multiplexing
Master Channel Demultiplexing
All Frames Generation
All Frames Reception
MC Frame
Service
Data Transmission
NOTE: Services not supported by the security protocol are shown greyed-out and italicized
Figure 2-2. Conceptual Order of Processing within TM
All Security Protocol functions (Authentication, Encryption, and Authenticated Encryption)
can be used with TM to protect the Packet and VC Access Services. They can be used with
the VC_FSH and MC_FSH Services for authentication only. They have no effect on the
VC_OCF, VC Frame, MC_OCF, and MC Frame Services.
2.2.3 PLACEMENT OF THE SERVICE IN TC
The conceptual order of processing of the Security Protocol’s functions with respect to other
functions of the TC Protocol is shown in Figure 2-3. Depending on the services actually
used, not all of the functions may be present in a real system.
CCSDS 355.0-R-1
Page 2-8
February 2016
DRAFT CCSDS RECOMMENDED STANDARD FOR SPACE DATA LINK SECURITY
(SENDING END)
MAP Packet
Service
MAP Access
Service
VC Packet
Service
MAP Packet
Processing
MAP
Generation
VC Packet
Processing
(RECEIVING END)
VC Access
Service
MAP Multiplexing
MAP Packet
Service
MAP Access
Service
VC Packet
Service
MAP Packet
Extraction
MAP
Generation
VC Packet
Extraction
VC Access
Service
MAP Demultiplexing
COP
Mgmt.
Service
Encryption
Decryption
Virtual Channel Generation
Virtual Channel Reception
VC Frame
Service
Message Authentication
Virtual Channel Multiplexing
COP
Mgmt.
Service
Message Verification
MC Frame
Service
Virtual Channel Demultiplexing
Master Channel Multiplexing
Master Channel Demultiplexing
All Frames Generation
All Frames Reception
VC Frame
Service
MC Frame
Service
Data Transmission
NOTE: Services not supported by the security protocol are shown greyed-out and italicized
Figure 2-3. Conceptual Order of Processing within TC
All Security Protocol functions (Authentication, Encryption, and Authenticated Encryption)
can be used with TC to protect the MAP Packet, MAP Access, VC Packet, and VC Access
Services. They have no effect on the COP Management, VC Frame, and MC Frame
Services.
2.2.4 PLACEMENT OF THE SERVICE IN AOS
The conceptual order of processing of the Security Protocol’s functions with respect to other
functions of the AOS Protocol is shown in Figure 2-4. Depending on the services actually
used, not all of the functions may be present in a real system.
CCSDS 355.0-R-1
Page 2-9
February 2016
DRAFT CCSDS RECOMMENDED STANDARD FOR SPACE DATA LINK SECURITY
(SENDING END)
Packet
Service
Bitstream
Service
Packet
Processing
Bitstream
Processing
(RECEIVING END)
VC Access
Service
VC_OCF
Service
Encryption
Packet
Service
Bitstream
Service
Packet
Extraction
Bitstream
Extraction
VC Access
Service
VC_OCF
Service
Decryption
Virtual Channel Generation
Virtual Channel Reception
VC Frame
Service
Message Authentication
Virtual Channel Multiplexing
Message Verification
MC Frame
Service
Master Channel Multiplexing
Virtual Channel Demultiplexing
Insert
Service
Master Channel Demultiplexing
All Frames Generation
VC Frame
Service
MC Frame
Service
Insert
Service
All Frames Reception
Data Transmission
NOTE: Services not supported by the security protocol are shown greyed-out and italicized
Figure 2-4. Conceptual Order of Processing within AOS
All Security Protocol functions (Authentication, Encryption, and Authenticated Encryption)
can be used with AOS to protect the Packet, Bitstream, and VC Access Services. They have
no effect on the VC_OCF, VC Frame, MC Frame, and Insert Services.
2.3
SERVICE FUNCTIONS
2.3.1 SECURITY ASSOCIATIONS
The Security Protocol provides security associations for defining the cryptographic
communications parameters to be used by both the sending and receiving ends of a
communications session, and for maintaining state information for the duration of the
session. A Security Association (SA) defines a simplex (one-way), stateful cryptographic
session for providing authentication, data integrity, replay protection, and/or data
confidentiality.
2.3.1.1
Security Association Context
All Transfer Frames that share the same Security Association on a physical channel
constitute a Secure Channel. A Secure Channel consists of one or more Global Virtual
Channels or Global MAP IDs (TC only) assigned to a SA at the time of its creation.
The Security Parameter Index (SPI) is a transmitted value that uniquely identifies the
Security Association applicable to a Transfer Frame. All Transfer Frames having the same
SPI on a physical channel share a single Security Association. The SPI can be considered as
a table index key to a Security Association Database that stores all of the managed
information required by each of the Security Associations on a physical channel.
CCSDS 355.0-R-1
Page 2-10
February 2016
DRAFT CCSDS RECOMMENDED STANDARD FOR SPACE DATA LINK SECURITY
2.3.1.2
Security Association Service Types
When a Security Association is created, one of the following cryptographic functions is
selected to be applied on specified fields for all transfer frames using that Security
Association:
a) Authentication;
b) Encryption;
c) Authenticated Encryption.
Once a Security Association is created, the authentication and/or encryption algorithms
specified, along with their modes of operation, are fixed and cannot be changed for the
duration of the SA.
2.3.1.3
Security Header and Trailer
All Transfer Frames using a Security Association on a physical channel include a Security
Header and Trailer surrounding the Frame Data area of the transfer frame. The Security
Header carries the Security Parameter Index, initialization vector, anti-replay sequence
number, length of any encryption block padding used (where necessary); the Security Trailer
carries a message authentication code.
Once a Security Association is created, the lengths of the managed fields in the Security
Header and Trailer are fixed for the duration of that SA.
2.3.1.4
Security Association Management
Both the sender and the receiver must create a Security Association, associate it with
cryptographic key(s), and activate it before the Security Association may be used to secure
Transfer Frames on a channel.
Security Associations may be statically pre-loaded prior to the start of a mission. Security
Associations may also be created dynamically as needed, even while other existing SAs are
active. The mechanism for switching from one active Security Association to another is an
application-layer function.
NOTE:
Over-the-air negotiation of SA parameters is a (currently undefined) applicationlayer function.
2.3.2 AUTHENTICATION
The Security Protocol provides for the use of authentication algorithms to ensure the integrity
of transmitted data and the authenticity of the data source. The Security Protocol also
provides for the use of sequence numbering to detect the unauthorized replay of previously
transmitted data.
CCSDS 355.0-R-1
Page 2-11
February 2016
DRAFT CCSDS RECOMMENDED STANDARD FOR SPACE DATA LINK SECURITY
2.3.2.1
Message Authentication and Integrity
When the Security Protocol is used for Authentication, a Message Authentication Code
(MAC) is computed over the specified transfer frame fields, which are the Frame Header, the
optional Secondary Header, the Security Header (as part of this security protocol), and the
Frame Data Field. Excluded fields are the channel coding synchronization marker, optional
Operational Control Field, optional frame Error Control Field, and the MAC field within the
Security Trailer.
2.3.2.2
Replay Protection
When the Security Protocol is used for Authentication, a sequence number is also transmitted
in the transfer frame. As part of a Security Association providing Authentication, both the
sender and receiver manage the following information:
a) a sequence number value (current value for the sender, expected value for the
receiver);
b) a sequence number window for comparison by the receiver;
c) the length (number of least-significant bits) of the transmitted portion of the sequence
number;
d) the location within the transfer frame of the transmitted portion of the sequence
number.
2.3.2.2.1 Sequence Number
The sender increments its managed sequence number by one with each transmitted frame
belonging to that Security Association. The receiver increments its managed sequence
number by one with each valid received frame belonging to that Security Association. The
receiver compares each received frame’s Sequence Number to its managed sequence number.
If the received Sequence Number exceeds the expected value by more than a defined
window, the receiver discards the frame, and does not increment its managed sequence
number.
NOTE:
The interpretation of a sequence number rollover (to zero) is mission-specific.
Rollover of the sequence number could be used to signal to both the sender and
the receiver when the acceptable lifetime of a cryptographic key will end, in
order that a key change may be commanded programmatically.
2.3.2.2.2 Sequence Number Window
The sequence number window is a fixed delta value, specified in the SA, for the receiver to
use in comparing the sequence number received to the expected value. Received frames
whose sequence number falls outside this window should be discarded. The size of the
selected window should account for predicted delays and gaps in RF transmission.
CCSDS 355.0-R-1
Page 2-12
February 2016
DRAFT CCSDS RECOMMENDED STANDARD FOR SPACE DATA LINK SECURITY
2.3.2.2.3 Sequence Number Length
The sequence number may be transmitted in its entirety. Alternatively, a defined length of
the sequence number’s least-significant bits may be transmitted, as specified in the Security
Association.
NOTE:
The transmitted portion of each SA’s sequence number should be of sufficient
length that the transmitted portion will not roll over to zero within fewer frames
than the defined sequence number window allows. If the counter is likely to roll
over, the SA should specify to transmit the entire sequence number.
2.3.2.2.4 Sequence Number Location
The location of the transmitted Sequence Number in the transfer frame is specified in the
Security Association. Three options are provided:
a) The transmitted portion of the Sequence Number may be located in the Sequence
Number field of the Security Header. In this case, its length is a managed SA
parameter.
b) For systems which implement Authenticated Encryption using a simple incrementing
counter as an Initialization Vector (i.e., as in Galois/Counter-mode algorithms), the
Initialization Vector field of the Security Header may serve also as the transmitted
portion of the Sequence Number. In this case, the Sequence Number field in the
Security Header is zero octets in length.
c) For systems using AOS which implement usage restrictions such that one and only
one AOS Virtual Channel may use a single Security Association, the Virtual Channel
Frame Count field of the AOS primary header may also serve as the transmitted
portion of the Sequence Number. In this case, the Sequence Number field in the
Security Header is zero octets in length. With this option, the managed values of both
the sequence number and the Virtual Channel Frame Count field should be set to a
defined value in the first frame of this Virtual Channel in which the SA is used, to
ensure synchronization.
NOTE:
This option is applicable only if the AOS Space Data Link Protocol is
used on the channel. In all other cases it is invalid.
2.3.3 ENCRYPTION
The Security Protocol provides for the use of encryption algorithms to ensure the
confidentiality of transmitted data.
When the Security Protocol is used for Encryption, the data area of the frame (the ‘plaintext’)
is replaced with an encrypted version of the same data (the ‘ciphertext’). An Initialization
Vector (IV) should be used as an input to the encryption process. Depending upon the
CCSDS 355.0-R-1
Page 2-13
February 2016
DRAFT CCSDS RECOMMENDED STANDARD FOR SPACE DATA LINK SECURITY
encryption algorithm and mode used, additional fill data may be needed to pad any
undersized encryption blocks.
2.3.4 AUTHENTICATED ENCRYPTION
The Security Protocol provides for the use of authentication and encryption as one combined
procedure.
When the Security Protocol is used for Authenticated Encryption, the frame data supplied by
the user is first encrypted as described in section 2.3.3, a current anti-replay Sequence
Number is applied to the transfer frame, and lastly a Message Authentication Code (MAC) is
computed over the resultant transfer frame as described in section 2.3.2.
CCSDS 355.0-R-1
Page 2-14
February 2016
DRAFT CCSDS RECOMMENDED STANDARD FOR SPACE DATA LINK SECURITY
3
3.1
SERVICE DEFINITION
OVERVIEW
This section provides service definition in the form of primitives, which present an abstract
model of the logical exchange of data and control information between the protocol entity
and the service user.
The definitions of primitives are independent of specific
implementation approaches.
The parameters of the primitives are specified in an abstract sense and specify the
information to be made available to the user of the primitives. The way in which a specific
implementation makes this information available is not constrained by this specification. In
addition to the parameters specified in this section, an implementation may provide other
parameters to the service user (e.g., parameters for controlling the service, monitoring
performance, facilitating diagnosis, and so on).
3.2
SOURCE DATA
This subsection specifies the service data units that are transferred from sending users to
receiving users by the Security Protocol.
3.2.1 SOURCE DATA FOR ENCRYPTION
The service data units encrypted by the Security Protocol on a physical channel are one of the
following types of service data units, according to the Space Data Link Protocol used on the
channel:
a) TM Encryption Payload;
b) TC Encryption Payload;
c) AOS Encryption Payload.
3.2.1.1
TM Encryption Payload
The TM Encryption Payload shall consist of a TM Transfer Frame Data Field.
NOTE 1:
The TM Transfer Frame Data Field is the data field of the fixed-length protocol
data unit of the TM Space Data Link Protocol whose format is defined in [1].
The TM Transfer Frame Data Field is provided to the Security Protocol either by
the Packet processing function of the TM Space Data Link Protocol or by the
Virtual Channel Access (VCA) Service user.
NOTE 2:
The length of the TM Transfer Frame Data Field Unit is reduced with respect to
the maximum size defined in the TM Space Data Link Protocol by the sizes of
the Security Header and Trailer.
CCSDS 355.0-R-1
Page 3-15
February 2016
DRAFT CCSDS RECOMMENDED STANDARD FOR SPACE DATA LINK SECURITY
3.2.1.2
TC Encryption Payload
The TC Encryption Payload shall consist of one of the following types of frame data for the
TC Space Data Link Protocol defined in [2]:
a) a TC Segment provided by the MAP processing function of the TC Space Data Link
Protocol, excluding the Segment Header;
b) a TC Transfer Frame Data Field consisting of an integral number of Virtual Channel
Packets provided by the Virtual Channel Packet processing function of the TC Space
Data Link Protocol; or,
c) a Virtual Channel Access Service Data Unit (VCA_SDU) provided by a VCA service
user.
Only one of these Encryption Payload types shall exist on a virtual channel.
NOTE 1:
The TC Segment is the variable-length protocol data unit of the TC Space Data
Link Protocol when the Segment Header is used on the Virtual Channel. The TC
Segment contains an integral number of octets of user data corresponding to one
Frame Data Unit (for a Type-D Transfer Frame), not including the Segment
Header. Its format is defined in [2].
NOTE 2:
The Virtual Channel Packet is the variable-length protocol data unit of the TC
Space Data Link Protocol when the Segment Header is not used on the Virtual
Channel. The TC Transfer Frame Data Field contains an integral number of
Virtual Channel Packets corresponding to one Frame Data Unit for a Type-D
Transfer Frame. Its format is defined in [2].
NOTE 3:
The VCA_SDU is a fixed-length, octet-aligned data unit, the format of which is
unknown to the service provider. Its length is established by management.
VCA_SDUs are transferred over a space link with the Virtual Channel Access
Service.
3.2.1.3
AOS Encryption Payload
The AOS Encryption Payload shall consist of a Multiplexing Protocol Data Unit (M_PDU), a
Bitstream Protocol Data Unit (B_PDU), or a Virtual Channel Access Service Data Unit
(VCA_SDU).
NOTE 1:
The Multiplexing Protocol Data Unit (M_PDU) is the fixed-length protocol data
unit of the AOS Multiplexing Service. Its format is defined in [3].
NOTE 2:
The Bitstream Protocol Data Unit (B_PDU) is the fixed-length protocol data unit
of the AOS Bitstream Service. Its format is defined in [3].
CCSDS 355.0-R-1
Page 3-16
February 2016
DRAFT CCSDS RECOMMENDED STANDARD FOR SPACE DATA LINK SECURITY
NOTE 3:
The VCA_SDU is a fixed-length, octet-aligned data unit, the format of which is
unknown to the service provider. Its length is established by management.
VCA_SDUs are transferred over a space link with the Virtual Channel Access
Service.
NOTE 4:
The length of the M_PDU, B_PDU, or VCA_SDU is reduced with respect to the
maximum size defined in the AOS Space Data Link Protocol by the sizes of the
Security Header and Trailer.
3.2.2 SOURCE DATA FOR AUTHENTICATION
The service data units authenticated by the Security Protocol on a physical channel are one,
and only one, of the following types of partially formatted transfer frame, according to the
Space Data Link Protocol used on the channel:
d) TM Authentication Payload;
e) TC Authentication Payload;
f) AOS Authentication Payload.
3.2.2.1
TM Authentication Payload
The TM Authentication Payload shall consist of the portion of the TM Transfer Frame from
the first octet of the Transfer Frame Primary Header to the last octet of the Transfer Frame
Data Field immediately preceding the MAC field in the Security Trailer, excluding the
optional OCF and ECF.
NOTE:
3.2.2.2
The TM Transfer Frame is the fixed-length protocol data unit of the TM Space
Data Link Protocol. Its format is defined in [1]. The length of any Transfer
Frame transferred on a Physical Channel must be constant, and is established by
management.
TC Authentication Payload
The TC Authentication Payload shall consist of the portion of the TC Transfer Frame from
the first octet of the Transfer Frame Primary Header to the last octet of the Transfer Frame
Data Field immediately preceding the MAC field in the Security Trailer, excluding the
optional ECF.
NOTE:
The TC Transfer Frame is the variable-length protocol data unit of the TC Space
Data Link Protocol. Its format is defined in [2].
CCSDS 355.0-R-1
Page 3-17
February 2016
DRAFT CCSDS RECOMMENDED STANDARD FOR SPACE DATA LINK SECURITY
3.2.2.3
AOS Authentication Payload
The AOS Authentication Payload shall consist of the portion of the AOS Transfer Frame
from the first octet of the Transfer Frame Primary Header to the last octet of the Transfer
Frame Data Field immediately preceding the MAC field in the Security Trailer, excluding
the optional Insert Zone, OCF, and ECF.
NOTE:
3.3
The AOS Transfer Frame is the fixed-length protocol data unit of the AOS Space
Data Link Protocol. Its format is defined in [3]. The length of any Transfer
Frame transferred on a Physical Channel must be constant, and is established by
management.
SECURITY ASSOCIATION (SA) MANAGEMENT SERVICE
The Security Association Management Service establishes the context of a Security
Association for a particular Global Virtual Channel and/or MAP ID. Implementation of the
services necessary to manage the parameters contained in the Security Association Database
is a mission-specific function.
3.3.1 SA MANAGEMENT SERVICE PARAMETERS
Each Security Association is composed of the commonly applicable parameters listed in
3.3.1.1 below, as well as those parameters in subsections 3.3.1.2 and 3.3.1.3 applicable to the
cryptographic function(s) specified in the SA.
3.3.1.1
Security Association Parameters required by all SAs
3.3.1.1.1 Global Virtual Channel ID (GVCID)
The GVCID parameter shall contain the ID of the Global Virtual Channel applicable to the
Security Association.
NOTE:
The GVCID consists of a Master Channel ID and a Virtual Channel ID.
3.3.1.1.2 Multiplexer Access Point ID (MAP_ID)
The MAP_ID parameter shall contain a TC MAP ID that indicates the Multiplexer Access
Point (MAP) Channel (within the Virtual Channel specified by GVCID) applicable to the
Security Association.
NOTE:
The MAP_ID parameter is applicable only if the TC Space Data Link Protocol is
used on the channel.
3.3.1.1.3 Security Parameter Index (SPI)
The SPI parameter shall contain an index identifying the Security Association applicable to a
Frame. Each Security Association on a Physical Channel is identified by a unique Security
Parameter Index.
CCSDS 355.0-R-1
Page 3-18
February 2016
DRAFT CCSDS RECOMMENDED STANDARD FOR SPACE DATA LINK SECURITY
3.3.1.1.4 SA_service_type
The SA_service_type parameter indicates the cryptographic function(s) specified for the
Security Association: one of Authentication, Encryption, or Authenticated Encryption.
3.3.1.1.5 SA_length_SN
The SA_length_SN parameter indicates the length of the Sequence Number field in the
Security Header.
3.3.1.1.6 SA_length_IV
The SA_length_IV parameter indicates the length of the Initialization Vector field in the
Security Header.
3.3.1.1.7 SA_length_PL
The SA_length_PL parameter indicates the length of the Pad Length field in the Security
Header.
3.3.1.1.8 SA_length_MAC
The SA_length_MAC parameter indicates the length of the Message Authentication Code
field in the Security Trailer.
3.3.1.2
Security Association Parameters specific to Authentication
3.3.1.2.1 SA_authentication_algorithm
The SA_authentication_algorithm parameter indicates the applicable authentication
algorithm and mode of operation.
NOTE:
The SA_authentication_algorithm parameter is applicable only if
SA_service_type parameter is Authentication or Authenticated Encryption.
the
3.3.1.2.2 SA_authentication_key
The SA_authentication_key parameter indicates the value of a provided authentication key,
or of an index that refers to the actual key.
3.3.1.2.3 SA_sequence_number
The SA_sequence_number parameter indicates the present value of a managed anti-replay
sequence number.
CCSDS 355.0-R-1
Page 3-19
February 2016
DRAFT CCSDS RECOMMENDED STANDARD FOR SPACE DATA LINK SECURITY
3.3.1.2.4 SA_sequence_window
The SA_sequence_window parameter indicates the amount of deviation which the receiving
end will accept between the expected anti-replay sequence number and the sequence number
in the received frame.
3.3.1.3
Security Association Parameters specific to Encryption
3.3.1.3.1 SA_encryption_algorithm
The SA_encryption_algorithm parameter indicates the applicable encryption algorithm and
mode of operation.
NOTE:
The SA_encryption_algorithm parameter is applicable only
SA_service_type parameter is Encryption or Authenticated Encryption.
if
the
3.3.1.3.2 SA_encryption_key
The SA_encryption_key parameter indicates the value of a provided encryption key, or of an
index that refers to the actual key.
3.3.1.3.3 SA_initialization_vector
The SA_initialization_vector parameter indicates the present value of a managed
initialization vector.
3.3.2 SA MANAGEMENT SERVICE PRIMITIVES
At present, this Recommendation does not define any service primitives for the Security
Association Management Service. Specific directives may be defined in a future revision of
this Recommendation.
3.4
ENCRYPTION SERVICE
The Encryption Service transfers Encryption Payloads as applicable to the Space Data Link
Protocol in use on the channel. Encryption Payloads, pre-formatted by the service user
according to the specification given in section 3.2.1 of this Recommendation, are transferred
by the service provider according to the Security Association parameters for the applicable
Global Virtual Channel.
3.4.1 ENCRYPTION SERVICE PARAMETERS
3.4.1.1
Encryption Payload
The Encryption Payload parameter shall contain an Encryption Payload of the applicable
Space Data Link Protocol (TM, TC, or AOS) to be transferred on the Virtual Channel
identified by GVCID.
CCSDS 355.0-R-1
Page 3-20
February 2016
DRAFT CCSDS RECOMMENDED STANDARD FOR SPACE DATA LINK SECURITY
3.4.1.2
GVCID
The GVCID parameter shall contain the ID of the Global Virtual Channel on which the
Encryption Payload is to be transferred.
NOTE:
The GVCID consists of a Master Channel ID and a Virtual Channel ID.
3.4.2 ENCRYPTION SERVICE PRIMITIVES
The service primitives associated with this service are:
a) ENCRYPT.request;
b) ENCRYPT.indication.
3.4.2.1
ENCRYPT.request
3.4.2.1.1 Function
At the sending end, the Encryption Service user shall pass an ENCRYPT.request primitive to
the service provider in order to encrypt and transfer the Encryption Payload through the
specified channel.
3.4.2.1.2 Semantics
The ENCRYPT.request primitive shall provide parameters as follows:
ENCRYPT.request
3.4.2.2
(Encryption Payload, GVCID)
ENCRYPT.indication
3.4.2.2.1 Function
At the receiving end, the service provider shall pass an ENCRYPT.indication primitive to the
Encryption Service user in order to transfer the decrypted Payload.
3.4.2.2.2 Semantics
The ENCRYPT.indication primitive shall provide parameters as follows:
ENCRYPT.indication
3.5
(Encryption Payload, GVCID)
AUTHENTICATION SERVICE
The Authentication Service transfers Authentication Payloads as applicable to the Space Data
Link Protocol in use on the channel. Authentication Payloads, pre-formatted by the service
user according to the specification given in section 3.2.2 of this Recommendation, are
transferred by the service provider according to the Security Association for the applicable
Global Virtual Channel.
CCSDS 355.0-R-1
Page 3-21
February 2016
DRAFT CCSDS RECOMMENDED STANDARD FOR SPACE DATA LINK SECURITY
3.5.1 AUTHENTICATION SERVICE PARAMETERS
3.5.1.1
Authentication Payload
The Authentication Payload parameter shall contain an Authentication Payload of the
applicable Space Data Link Protocol (TM, TC, or AOS) to be transferred on the Virtual
Channel identified by GVCID.
3.5.1.2
GVCID
The GVCID parameter shall contain the ID of the Global Virtual Channel on which the
Frame is to be transferred.
NOTE:
3.5.1.3
The GVCID consists of an Master Channel ID and a Virtual Channel ID.
Exception
The Exception parameter shall contain a message or status code for the service user to
indicate the reason for an authentication failure (e.g., MAC mismatch or sequence number
mismatch).
3.5.2 AUTHENTICATION SERVICE PRIMITIVES
The service primitives associated with this service are:
c) AUTHENTICATE.request;
d) AUTHENTICATE.indication.
e) AUTHENTICATE.exception.
3.5.2.1
AUTHENTICATE.request
3.5.2.1.1 Function
At the sending end, the Authentication Service user shall pass an AUTHENTICATE.request
primitive to the service provider in order to perform authentication processing on the
Authentication Payload supplied by the service user and transfer the Authentication Payload
through the specified channel.
3.5.2.1.2 Semantics
The AUTHENTICATE.request primitive shall provide parameters as follows:
AUTHENTICATE.request
CCSDS 355.0-R-1
(Authentication Payload, GVCID)
Page 3-22
February 2016
DRAFT CCSDS RECOMMENDED STANDARD FOR SPACE DATA LINK SECURITY
3.5.2.2
AUTHENTICATE.indication
3.5.2.2.1 Function
At the receiving end, the service provider shall pass a AUTHENTICATE.indication primitive to
the Authentication Service user to deliver an Authentication Payload after the service has
successfully verified the MAC and sequence number of the received Authentication Payload.
3.5.2.2.2 Semantics
The AUTHENTICATE.indication primitive shall provide parameters as follows:
AUTHENTICATE.indication
3.5.2.3
(Authentication Payload, GVCID)
AUTHENTICATE.exception
3.5.2.3.1 Function
At the receiving end, the service provider shall pass a AUTHENTICATE.exception primitive to
the Authentication Service user to notify the user that the service has received a Authentication
Payload but the Authentication Payload’s MAC or sequence number has failed verification.
3.5.2.3.2 Semantics
The AUTHENTICATE.exception primitive shall provide parameters as follows:
AUTHENTICATE.exception
CCSDS 355.0-R-1
(Exception, Authentication Payload, GVCID)
Page 3-23
February 2016
DRAFT CCSDS RECOMMENDED STANDARD FOR SPACE DATA LINK SECURITY
4
PROTOCOL SPECIFICATION
4.1
PROTOCOL DATA UNITS
4.1.1 SECURITY HEADER
The Security Header is mandatory and shall consist of one mandatory field and three optional
fields, positioned contiguously, in the following sequence:
a) Security Parameter Index (16 bits; mandatory);
b) Initialization Vector (octet-aligned, fixed-length for the duration of the Security
Association; optional);
c) Sequence Number (octet-aligned, fixed-length for the duration of the Security
Association; optional);
d) Pad Length (octet-aligned, fixed-length for the duration of the Security Association;
optional).
A Security Header shall consist of at most 64 octets. The receiver will determine the
presence and length of optional fields in the Security Header by using the Security Parameter
Index to reference the corresponding Security Association.
The format of the Security Header is shown in Figure 4-1.
SECURITY HEADER
(bits)
SECURITY
PARAMETER
INDEX
INITIALIZATION VECTOR
(Optional)
SEQUENCE
NUMBER
(Optional)
PAD
LENGTH
(Optional)
16
Managed
Managed
Managed
Figure 4-1. Security Header
4.1.1.1
Security Parameter Index (SPI)
Bits 0-15 of the Security Header shall contain the Security Parameter Index.
This 16-bit field shall be used as an index to identify a Security Association (SA). There can
be up to 65534 Security Associations per Master Channel. A value of all zeros (‘0’) or all
ones (‘65535’) for this field is reserved by CCSDS for future use.
4.1.1.2
Initialization Vector
The Initialization Vector field shall follow the Security Parameter Index field, without gap.
This field, if Encryption or Authenticated Encryption is selected for a Security Association,
shall contain the transmitted portion of the initialization vector, consisting of a integral
number of octets. The Initialization Vector field length is managed and is fixed for the
CCSDS 355.0-R-1
Page 4-24
February 2016
DRAFT CCSDS RECOMMENDED STANDARD FOR SPACE DATA LINK SECURITY
duration of the Security Association. If Encryption is not selected for a Security Association,
this field shall be zero octets in length.
4.1.1.3
Sequence Number
The Sequence Number field shall follow the Initialization Vector field, without gap.
This field, if Authentication or Authenticated Encryption is selected for a Security
Association, shall contain the transmitted portion of the anti-replay sequence number,
consisting of a integral number of octets. The Sequence Number field length is managed and
is fixed for the duration of the Security Association. If Authentication or Authenticated
Encryption is not selected for a Security Association, this field shall be zero octets in length.
NOTE 1:
For systems which implement Authenticated Encryption using a simple
incrementing counter as an Initialization Vector (i.e., as in Galois/Counter-Mode
algorithms), the Initialization Vector field of the Security Header may serve also
as the transmitted portion of the Sequence Number. In this case, the Sequence
Number field in the Security Header is zero octets in length.
NOTE 2:
For systems which implement Authentication or Authenticated Encryption over
AOS Space Data Link protocol, which implement usage restrictions such that one
and only one AOS Virtual Channel may use a single Security Association, the
Virtual Channel Frame Count field of the AOS primary header may also serve as
the transmitted portion of the Sequence Number. In this case, the Sequence
Number field in the Security Header is zero octets in length. With this option,
the managed values of both the sequence number and the Virtual Channel Frame
Count field should be set to a defined value in the first frame of this Virtual
Channel in which the SA is used, to ensure synchronization.
4.1.1.4
Pad Length
The Pad Length field shall follow the Sequence Number field, without gap. It shall contain
an integral number of octets. If Encryption is not selected for a Security Association, this
field shall be zero octets in length.
4.1.2 SECURITY TRAILER
The Security Trailer is optional and shall consist of a Message Authentication Code (octetaligned, fixed-length for the duration of the Security Association). The format of the
Security Trailer is shown in Figure 4-2. If Authentication is not selected for a Security
Association, this field should be zero octets in length.
CCSDS 355.0-R-1
Page 4-25
February 2016
DRAFT CCSDS RECOMMENDED STANDARD FOR SPACE DATA LINK SECURITY
SECURITY TRAILER
MESSAGE AUTHENTICATION CODE (MAC)
(Optional)
(bits)
Managed
Figure 4-2. Security Trailer
4.2
SECURITY PROTOCOL PROCEDURES
The following procedures shall be carried out to perform the operations of the active Security
Association. Prior to operation of the SDLS Protocol, the sending and receiving ends shall
initialize a common SA data base containing all the parameters of the SAs to be used on the
link. Synchronization of the contents of the sender’s and receiver’s SA data bases should be
maintained during operation. Initialization, modification, and maintenance procedures for
those SA data bases are not part of this SDLS protocol but will be developed later by
CCSDS.
4.2.1 SECURITY ASSOCIATION MANAGEMENT PROCEDURES
In order to use a Security Association to secure Transfer Frames on a channel, each end (both
sending and receiving end) of a Security Association shall:
a) create the Security Association;
b) associate it with cryptographic key(s); and,
c) associate it with the Global Virtual Channel(s) or Global Multiplexer Access Point
(MAP) IDs with which it is to be used.
NOTE 1:
It is expected that some missions will choose to define Security Associations
statically and pre-load/pre-activate them prior to the start of the mission.
NOTE 2:
Specifying the successful implementation of cryptographic key management is
beyond the scope of this document.
4.2.1.1
Security Association Context
Every Security Association shall specify one or more Global Virtual Channels or Global
Multiplexer Access Point (MAP) IDs (TC only) with which the Security Association is to be
used.
NOTE 1:
The GVCID consists of a Master Channel ID and a Virtual Channel ID.
NOTE 2:
The MAP_ID parameter is applicable only if the TC Space Data Link Protocol is
used on the channel. In all other cases it is invalid.
CCSDS 355.0-R-1
Page 4-26
February 2016
DRAFT CCSDS RECOMMENDED STANDARD FOR SPACE DATA LINK SECURITY
4.2.1.1.1 OID Transfer Frames and Virtual Channels
Security Associations shall not be created for use with Virtual Channels reserved by CCSDS
for carrying “fill” data (i.e., “Only Idle Data” (OID) transfer frames).
4.2.1.2
Security Parameter Index
Every Security Association shall be associated with a Security Parameter Index (SPI). The
Security Parameter Index (SPI) is a transmitted value that uniquely identifies the Security
Association applicable to a Transfer Frame. All Transfer Frames having the same SPI on a
master channel share a single Security Association.
4.2.1.3
Security Association Service Type
Every Security Association shall specify one and only one of the following cryptographic
functions to perform:
a) Authentication;
b) Encryption;
c) Authenticated Encryption.
NOTE:
4.2.1.4
It is possible to create a “clear mode” Security Association using one of the
defined service types, by specifying the algorithm as a “no-op” function (no
actual cryptographic operation to be performed). Such a Security Association
might be used, e.g,, during development testing of other aspects of data link
processing before cryptographic capabilities are available for integrated testing.
To avoid inducing a false illusion of secure communications, and the problems
described in section 7.4, the use of such a Security Association is not
recommended in normal operation. It is also possible to activate a ‘clear mode’
by designating one or more Virtual Channels to use the underlying Space Data
Link Protocol without the Security Protocol’s protections.
Parameters Common to All SAs
Every Security Association shall also specify the following:
a) Security Parameter Index;
b) length of Initialization Vector field in Security Header;
c) length of Sequence Number field in Security Header;
d) length of Pad Length field in Security Header;
e) length of Message Authentication Code field in Security Trailer.
CCSDS 355.0-R-1
Page 4-27
February 2016
DRAFT CCSDS RECOMMENDED STANDARD FOR SPACE DATA LINK SECURITY
4.2.1.5
Parameters for Authentication SAs
Every Security Association providing Authentication shall also specify the following:
a) authentication algorithm and mode of operation;
b) managed Sequence Number;
c) managed Sequence Number window.
4.2.1.6
Parameters for Encryption SAs
Every Security Association providing Encryption shall also specify the following:
a) encryption algorithm and mode of operation1.
b) managed Initialization Vector.
4.2.1.7
Parameters for Authenticated Encryption SAs
Every Security Association providing Authenticated Encryption shall specify everything
required in both sections 4.2.1.5 and 4.2.1.6 above.
4.2.2 SENDING PROCEDURES
This subsection describes procedures at the sending end associated with each of the functions
shown in Figure 2-2, Figure 2-3, and Figure 2-4. These figures identify data-handling
functions performed by the protocol entity, and show logical relationships among these
functions. These figures are not intended to imply any hardware or software configuration in
a real system. Depending on the services actually used for a real system, not all of the
functions may be present in the protocol entity. The procedures described in this section are
defined in an abstract sense and are not intended to imply any particular implementation
approach of a protocol entity.
4.2.2.1
Authentication Operations
If Authentication is selected for a Security Association, the sender shall:
a) increment the Security Association’s managed sequence number by one with each
transmitted frame belonging to that Security Association;
b) place the transmitted portion of the sequence number (the least-significant bits of the
managed sequence number) in the Sequence Number field of the Security Header,
unless that Security Association specifies to use the Virtual Channel Frame Count
field of the transfer frame primary header as a sequence number (AOS only);
1
The chosen algorithm and mode also imply other attributes such as the required encryption block size and the
corresponding need to pad undersized data blocks.
CCSDS 355.0-R-1
Page 4-28
February 2016
DRAFT CCSDS RECOMMENDED STANDARD FOR SPACE DATA LINK SECURITY
c) compute a Message Authentication Code over the transfer frame from the first octet
of the Transfer Frame Primary Header to the last octet of the Transfer Frame Data
Field immediately preceding the MAC field in the Security Trailer, excluding the
optional Insert Zone (AOS only), optional OCF (TM, AOS only), and optional ECF;
d) (if necessary) truncate the least-significant bits of the computed MAC, such that the
result is of identical length to the MAC field in the Security Trailer;
e) place the computed MAC in the Security Trailer.
An abstract model of the Authentication function is illustrated in Figure 4-3 for the TM
protocol, and in Figure 4-4 for the TC and AOS protocols. NOTE: While the operation of
the Authentication function is substantially the same across TM, TC, and AOS, its execution
is deferred in TM until after Master Channel Generation due to the placement of the Master
Channel Frame Count in the TM Primary Header.
Master Channel Generation Function
MC Frames
Authentication
Function for a
Virtual Channel
Message Authentication
MC Frames
Master Channel Multiplexing Function
Figure 4-3. Abstract Model of Authentication Function in TM
CCSDS 355.0-R-1
Page 4-29
February 2016
DRAFT CCSDS RECOMMENDED STANDARD FOR SPACE DATA LINK SECURITY
Virtual Channel Generation Function
VC Frames
Authentication
Function for a
Virtual Channel
Message Authentication
VC Frames
Virtual Channel Multiplexing Function
Figure 4-4. Abstract Model of Authentication Function in TC or AOS
4.2.2.2
Encryption Operations
If Encryption is selected for a Security Association, the sender shall:
a) encrypt the Frame Data field.
b) (optionally) if the encryption algorithm and mode selected for the Security
Association require the use of fill padding, place the number of fill bytes used in the
encryption process into the Pad Length field of the Security Header.
An abstract model of the Encryption function is illustrated in Figure 4-5.
CCSDS 355.0-R-1
Page 4-30
February 2016
DRAFT CCSDS RECOMMENDED STANDARD FOR SPACE DATA LINK SECURITY
(Only one of these entities exists for a Virtual Channel)
VC Packet
Processing
Function
(TM, TC, AOS)
Bitstream
Processing
Function
(AOS)
MAP Multiplexing
Function
(TC)
Frame Data
Units
Frame Data
Units
Encryption
Function for a
Virtual Channel
Frame Data
Units
VCA
Service User
(TM, TC, AOS)
Frame Data
Units
Encryption
(Encrypted)
Frame Data Units
Virtual Channel Generation Function
Figure 4-5. Abstract Model of Encryption Function
4.2.2.3
Authenticated Encryption Operations
If Authenticated Encryption is selected for a Security Association, the sender shall:
a) carry out the Encryption operations described in the preceding section 4.2.2.2; then,
b) carry out the Authentication operations described in the preceding section 4.2.2.1.
4.2.3 RECEIVING PROCEDURES
This subsection describes procedures at the receiving end associated with each of the
functions shown in Figure 2-2, Figure 2-3, and Figure 2-4. These figures identify datahandling functions performed by the protocol entity, and show logical relationships among
these functions. These figures are not intended to imply any hardware or software
configuration in a real system. Depending on the services actually used for a real system, not
all of the functions may be present in the protocol entity. The procedures described in this
section are defined in an abstract sense and are not intended to imply any particular
implementation approach of a protocol entity.
4.2.3.1
Security Association Management Operations
Each receiver shall enforce the following policy for all frames received over a Global Virtual
Channel. Prior to performing the specific Security Association operations described in
sections 4.2.3.2, 4.2.3.3, and 4.2.3.4, the receiver shall:
CCSDS 355.0-R-1
Page 4-31
February 2016
DRAFT CCSDS RECOMMENDED STANDARD FOR SPACE DATA LINK SECURITY
a) discard frames in which the received frame has a Security Header, but the Security
Association referenced in its Security Parameter Index is not associated with that
Virtual Channel.
4.2.3.2
Authentication Operations
If Authentication is selected for a Security Association, the receiver shall:
a) compute a Message Authentication Code over the transfer frame from the first octet
of the Transfer Frame Primary Header to the last octet of the Transfer Frame Data
Field immediately preceding the MAC field in the Security Trailer, excluding the
optional Insert Zone (AOS only), optional OCF (TM, AOS only), and optional ECF;
b) (if necessary) truncate the least-significant bits of the computed MAC, such that the
result is of identical length to the MAC field in the Security Trailer;
c) verify that the computed MAC matches the MAC received in the Security Trailer;
d) report an exception to the service user for frames in which the received frame fails
MAC verification;
e) extract the transmitted portion of the sequence number from either the Sequence
Number field of the Security Header, the Initialization Vector field of the Security
Header, or the Virtual Channel Frame Count field of the Transfer Frame Primary
Header, according to the options specified for that Security Association;
f) compute a current value by performing a logical-OR of the transmitted sequence
number with the most-significant bits of the managed sequence number, according to
the lengths specified for that Security Association, and compare the current value to
the managed sequence number;
g) report an exception to the service user for frames in which the current value deviates
from the expected value by more than the window defined for that Security
Association;
h) increment the managed sequence number only upon receipt of frames that pass the
verification operations a) - g) above;
i) remove the Security Trailer from the Frame Data Field to be returned to the service
user;
j) if Authentication only is specified for the Security Association, remove the Security
Header from the Frame Data Field to be returned to the service user.
4.2.3.3
Encryption Operations
If Encryption is selected for a Security Association, the receiver shall:
CCSDS 355.0-R-1
Page 4-32
February 2016
DRAFT CCSDS RECOMMENDED STANDARD FOR SPACE DATA LINK SECURITY
a) decrypt the Frame Data field;
b) remove the Security Header from the Frame Data Field to be returned to the service
user.
4.2.3.4
Authenticated Encryption Operations
If Authenticated Encryption is selected for a Security Association, the receiver shall:
a) carry out the Authentication operations described in the preceding section 4.2.3.2;
then,
b) carry out the Encryption operations described in the preceding section 4.2.3.3.
CCSDS 355.0-R-1
Page 4-33
February 2016
DRAFT CCSDS RECOMMENDED STANDARD FOR SPACE DATA LINK SECURITY
5
5.1
USE OF THE SERVICES WITH CCSDS PROTOCOLS
TM PROTOCOL
The following restrictions apply to use of the Security Protocol with TM:
a) the Packet and VC Access Services may be used on a Global Virtual Channel with
the Authentication, Encryption, or Authenticated-Encryption Service, and are
protected by each of these services;
b) the VC_FSH and MC_FSH Services may be used on a Global Virtual Channel with
the Authentication, Encryption, or Authenticated-Encryption Service, and are
protected by Authentication but are not protected by Encryption;
c) the VC_OCF, VC Frame, MC_OCF, and MC Frame Services are not protected by the
Authentication, Encryption, or Authenticated-Encryption Services, but may be used
on the same Master Channel.
5.1.1 TM TRANSFER FRAME PROCEDURES
The format of the TM Transfer Frame is defined in reference [1]. The following rules on the
format of the TM Transfer Frame shall be applied when the Security Header is present:
a) the TM Frame Secondary Header, if present, shall follow the TM Transfer Frame
Primary Header;
b) the Security Header shall follow the TM Frame Secondary Header, if present;
c) the Transfer Frame Data Field shall follow the Security Header;
d) the Security Trailer (MAC), if present, shall follow the Transfer Frame Data Field;
e) the Operational Control Field (OCF), if present, shall follow the Security Trailer
(MAC);
f) the Frame Error Control Field (ECF), if present, shall follow the Operational Control
Field.
The format of a TM Transfer Frame using the Security Protocol is shown in Figure 5-1.
CCSDS 355.0-R-1
Page 5-34
February 2016
DRAFT CCSDS RECOMMENDED STANDARD FOR SPACE DATA LINK SECURITY
TM TRANSFER FRAME
6
2-64
SECURITY
HEADER
FRAME DATA
MAC
ECF
(Optional)
SECONDARY
HEADER
(Optional)
OCF
(Optional)
(octets)
TRANSFER
FRAME
PRIMARY
HEADER
4
2
Encryption is done on Frame Data only.
MAC is computed over Primary Header, Secondary Header, Security Header, and Frame Data.
MAC is not computed over frame sync mark (not shown), OCF, or ECF.
Figure 5-1. TM Transfer Frame using the Security Protocol
5.2
TC PROTOCOL
The following restrictions apply to use of the Security Protocol with TC:
a) the MAP Packet, MAP Access, VC Packet, and VC Access Services may be used on
a Global Virtual Channel with the Authentication, Encryption, or AuthenticatedEncryption Service, and are protected by each of these services;
b) the COP Management, VC Frame, and MC Frame Services are not protected by the
Authentication, Encryption, or Authenticated-Encryption Services, but may be used
on the same Master Channel.
5.2.1 TC TRANSFER FRAME PROCEDURES
The format of the TC Transfer Frame is defined in reference [2]. The following rules on the
format of the TC Transfer Frame shall be applied when the the Security Header is present:
a) the TC Segment Header, if present, shall follow the TC Transfer Frame Primary
Header;
b) the Security Header shall follow the TC Segment Header, if present;
c) the Transfer Frame Data Field shall follow the Security Header;
d) the Security Trailer (MAC), if present, shall follow the Transfer Frame Data Field.
e) the Frame Error Control Field (ECF), if present, shall follow the Transfer Frame Data
Field.
The format of a TC Transfer Frame using the Security Protocol is shown in
Figure 5-2. TC Transfer Frame using the Security Protocol
.
CCSDS 355.0-R-1
Page 5-35
February 2016
DRAFT CCSDS RECOMMENDED STANDARD FOR SPACE DATA LINK SECURITY
TC TRANSFER FRAME
5
1
SECURITY
HEADER
FRAME DATA
MAC
ECF
(Optional)
SEGMENT
HEADER
(octets)
TRANSFER
FRAME
PRIMARY
HEADER
2
Encryption is done on Frame Data only.
MAC is computed over Primary Header, Segment Header, Security Header, and Frame Data.
MAC is not computed over frame sync mark (not shown) or ECF.
Figure 5-2. TC Transfer Frame using the Security Protocol
5.3
AOS PROTOCOL
The following restrictions apply to use of the Security Protocol with AOS:
a) the Packet, Bitstream, and VC Access Services may be used on a Global Virtual
Channel with the Authentication, Encryption, or Authenticated-Encryption Services,
and are protected by each of these services;
b) the VC_OCF Service, VC Frame, MC Frame, and Insert Services are not protected
by the Authentication, Encryption, or Authenticated-Encryption Services, but may be
used on the same Master Channel.
5.3.1 AOS TRANSFER FRAME PROCEDURES
The format of the AOS Transfer Frame is defined in reference [3]. The following rules on
the format of the AOS Transfer Frame shall be applied when the Security Header is present:
a) the Insert Zone, if present, shall follow the AOS Transfer Frame Primary Header;
b) the Security Header shall follow the Insert Zone, if present;
c) the Transfer Frame Data Field shall follow the Security Header;
d) the Security Trailer (MAC), if present, shall follow the Transfer Frame Data Field;
e) the Operational Control Field (OCF), if present, shall follow the Security Trailer
(MAC);
f) the Frame Error Control Field (ECF), if present, shall follow the Operational Control
Field.
The format of an AOS Transfer Frame using the Security Protocol is shown in Figure
5-3.
CCSDS 355.0-R-1
Page 5-36
February 2016
DRAFT CCSDS RECOMMENDED STANDARD FOR SPACE DATA LINK SECURITY
AOS TRANSFER FRAME
6-8
Managed
SECURITY
HEADER
MAC
FRAME DATA
ECF
(Optional)
INSERT
ZONE
(Optional)
OCF
(Optional)
(octets)
TRANSFER
FRAME
PRIMARY
HEADER
4
2
Encryption is done on Frame Data only.
MAC is computed over Primary Header, Security Header, and Frame Data.
MAC is not computed over frame sync mark (not shown), Insert, OCF, or ECF.
Figure 5-3. AOS Transfer Frame using the Security Protocol
5.4
SUMMARY OF PROTOCOL SERVICES
Table 5-1 provides a summary of which services of the supported Space Data Link Protocols
may be protected using the service functions of the Security Protocol.
Table 5-1. Summary of Protocol and Services Support
Space Data Link
Protocol
TM
TC
CCSDS 355.0-R-1
Service
Authentication
Encryption
Authenticated
Encryption
Packet
Protected
Protected
Protected
VC Access
Protected
Protected
Protected
VC_FSH
Protected
Not protected
Authentication
only
VC_OCF
Not protected
Not protected
Not protected
VC Frame
Not protected
Not protected
Not protected
MC_FSH
Protected
Not protected
Authentication
only
MC_OCF
Not protected
Not protected
Not protected
MC Frame
Not protected
Not protected
Not protected
MAP Packet
Protected
Protected
Protected
MAP Access
Protected
Protected
Protected
VC Packet
Protected
Protected
Protected
Page 5-37
February 2016
DRAFT CCSDS RECOMMENDED STANDARD FOR SPACE DATA LINK SECURITY
AOS
CCSDS 355.0-R-1
VC Access
Protected
Protected
Protected
COP
Management
Not protected
Not protected
Not protected
VC Frame
Not protected
Not protected
Not protected
MC Frame
Not protected
Not protected
Not protected
Packet
Protected
Protected
Protected
Bitstream
Protected
Protected
Protected
VC Access
Protected
Protected
Protected
VC_OCF
Not protected
Not protected
Not protected
VC Frame
Not protected
Not protected
Not protected
MC Frame
Not protected
Not protected
Not protected
Insert
Not protected
Not protected
Not protected
Page 5-38
February 2016
DRAFT CCSDS RECOMMENDED STANDARD FOR SPACE DATA LINK SECURITY
6
MANAGED PARAMETERS
In order to conserve bandwidth on the space link, certain parameters associated with the
Security Protocol are handled by management, and not transmitted as part of the inline
communications protocol. The managed parameters are those which tend to be static for long
periods of time, and whose change generally signifies a major reconfiguration of the service
provider associated with a particular mission. Through the use of a management system,
management conveys the required information to the service provider.
The managed parameters used for the Security Protocol are listed in Table 6-1. These
parameters are defined in an abstract sense, and are not intended to imply any particular
implementation of a management system.
The majority of managed parameters are the parameters of the Security Association Database
managed by both the sending and receiving ends, which must match one another in order to
operate correctly.
Table 6-1. Managed Parameters for Security Protocol
Managed Parameter
Allowed Values
Defined In
Minimum TM/TC/AOS Frame Data Unit length
(octets)
Integer
Reference
[4]
Maximum TM/TC/AOS Frame Data Unit length
(octets)
Integer
Reference
[4]
Security Association Database Parameters:
Security Parameter Index (SPI)
1-65534
Security Association Service Type
Authentication
(indicates which cryptographic operations are
performed for a Security Association)
Encryption
Authenticated
Encryption
Security Association Context
GVCID
(identifies the GVCIDs or Global MAP IDs with which
a Security Association is used)
Global MAP ID
CCSDS 355.0-R-1
Page 6-39
References
[1], [2], [3]
Reference
[2]
February 2016
DRAFT CCSDS RECOMMENDED STANDARD FOR SPACE DATA LINK SECURITY
Transmitted length of Sequence Number
(if used)
2-8 octets
Transmitted length of Initialization Vector
(if used)
0-32 octets
Transmitted length of Pad Length
(if used)
0-2 octets
Transmitted length of Message Authentication Code
(if used)
8-64 octets
Authentication algorithm
Reference
[5]
Authentication key
Anti-replay sequence number
Integer
Anti-replay sequence number window (± current
Sequence Number)
Integer
Encryption algorithm
Reference
[5]
Encryption key
Encryption initialization vector
CCSDS 355.0-R-1
Page 6-40
February 2016
DRAFT CCSDS RECOMMENDED STANDARD FOR SPACE DATA LINK SECURITY
7
SECURITY
7.1
INTRODUCTION
Communications security attempts to ensure the confidentiality, integrity, and/or authenticity
of transmitted data, as required depending on the threat, the mission security policy(s), and
the desire of the mission planners. It is possible for a single data unit to require all three of
these security attributes to ensure that the payload is not disclosed, not altered, and not
spoofed.
7.2
SECURITY CONCERNS
Security concerns specific to the Security Protocol design are addressed in more detail in
reference [B1].
It may be necessary to apply security services at multiple layers within the protocol stack, to
account for distributed processing and cross-support, to account for different classes of data
or end users, or to account for protection of data during unprotected portions of the complete
end-to-end transmission (e.g., across ground networks). The specification of security
services at other layers is outside the scope of this document.
For more information regarding the choice of services and where they can be implemented,
see references [B2] and [B3]. For more information regarding the choice of particular
cryptographic algorithms, see reference [5].
7.3
POTENTIAL THREATS AND ATTACK SCENARIOS
The Security Protocol provides no protection against denial-of-service attacks against the
communications channel, such as radio-frequency jamming.
The Security Protocol provides no protection against traffic flow analysis. Where encryption
is used, a careful choice of algorithm and mode will provide protection to the user-supplied
data unit, but an attacker can use the Spacecraft ID, Virtual Channel ID, TC MAP ID, OCF,
or COP control directives as metadata for inferring information about the parties
communicating and possibly the nature or status of their communications.
The Security Protocol provides no cryptographic key management protocol. Specifying the
successful implementation of cryptographic key management is beyond the scope of this
document. See Reference [B4] for more information.
The Security Protocol provides no protection to TC COP control commands nor to COP
CLCW status information returned in the OCF; an attacker could use false COP control
directives or OCF contents to interfere with a communications session.
The Security Protocol foresees the existence of a ‘clear’ mode for certain VCs. If a clear
mode is implemented, the conditions under which, and by which, it is activated should be
carefully analyzed, as those might introduce major security vulnerabilities.
CCSDS 355.0-R-1
Page 7-41
February 2016
DRAFT CCSDS RECOMMENDED STANDARD FOR SPACE DATA LINK SECURITY
Specific potential threats and attack scenarios are addressed in more detail in reference [B1].
7.4
CONSEQUENCES OF NOT APPLYING SECURITY
Without authentication, unauthorized commands or software might be uploaded to a
spacecraft or data received from a source masquerading as the spacecraft. Without data
integrity, corrupted commands or software might be uploaded to a spacecraft potentially
resulting in the loss of the mission. Without data integrity, corrupted telemetry might be
retrieved from a spacecraft which could result in an incorrect course of action being taken. If
confidentiality is not implemented, data flowing to or from a spacecraft might be visible to
unauthorized entities resulting in disclosure of sensitive or private information.
CCSDS 355.0-R-1
Page 7-42
February 2016
DRAFT CCSDS RECOMMENDED STANDARD FOR SPACE DATA LINK SECURITY
ANNEX A
PROTOCOL IMPLEMENTATION CONFORMANCE STATEMENT
(NORMATIVE)
[Annexes contain ancillary information. Normative annexes precede informative annexes.
Informative references are placed in an informative annex. See CCSDS A20.0-Y-2, CCSDS
Publications Manual (Yellow Book, Issue 2, June 2005) for discussion of the kinds of
material contained in annexes.]
CCSDS 355.0-R-1
Page A-1
February 2016
DRAFT CCSDS RECOMMENDED STANDARD FOR SPACE DATA LINK SECURITY
ANNEX B
INFORMATIVE REFERENCES
(This annex is not part of the Recommendation)
[B1] Space Data Link Security Concept of Operation. Informational Report, CCSDS
350.5-G-1. Green Book. Washington, D.C.: CCSDS, _____.
[B2] The Application of CCSDS Protocols to Secure Systems. Informational Report,
CCSDS 350.0-G-2. Green Book. Issue 2. Washington, D.C.: CCSDS, January 2006.
[B3] Security Architecture for Space Data Systems. Informational Report, CCSDS 350.5M-1. Magenta Book. Washington, D.C.: CCSDS, ____.
[B4] Space Missions Key Management Concept. Informational Report, CCSDS 350.6-Gx. Green Book. Washington, D.C.: CCSDS, ____.
[B5] Overview of Space Link Protocols. Informational Report, CCSDS 130.0-G-1. Green
Book. Issue 1. Washington, D.C.: CCSDS, June 2001.
NOTE:
Normative references are listed in section 1.8.
CCSDS 355.0-R-1
Page B-2
February 2016
DRAFT CCSDS RECOMMENDED STANDARD FOR SPACE DATA LINK SECURITY
ANNEX C
BASELINE IMPLEMENTATION MODE
(This annex is not part of the Recommendation)
C.1.
BASELINE MODE FOR USE WITH TM
C.2.
ALGORITHM
The baseline implementation to be used for interoperability testing and operation is
Authenticated Encryption, using the Advanced Encryption Standard (AES) algorithm in the
Galois/Counter Mode (GCM) as defined in [5]. In addition:
a) the key shall be 128 bits in total length;
b) the input initialization vector shall be 96 bits in total length, where all 96 bits are
transmitted in-line in the Initialization Vector field of the Security Header;
c) the output Message Authentication Code shall be 128 bits in total length.
C.3.
SECURITY HEADER
The baseline implementation uses a Security Header of 14 octets in length. The format of the
Security Header is shown in Figure 7-1.
NOTE 1:
The Galois/Counter Mode of operation normally uses a simple incrementing
counter as its initialization vector. A separate anti-replay Sequence Number is
unnecessary, therefore the Sequence Number field shown in Figure 7-1 is zero
octets in length. See section 4.1.1.2.
NOTE 2:
The Galois/Counter Mode of operation does not require padding, therefore the
length of the Pad Length field shown in Figure 7-1 is zero octets.
SECURITY HEADER
(bits)
SECURITY
PARAMETER
INDEX
INITIALIZATION VECTOR
SEQUENCE
NUMBER
PAD
LENGTH
16
96
0
0
Figure 7-1. Security Header (TM Baseline)
C.4.
SECURITY TRAILER
The baseline implementation uses a Security Trailer of 16 octets in length. The format of the
Security Header is shown in Figure 7-2.
CCSDS 355.0-R-1
Page C-3
February 2016
DRAFT CCSDS RECOMMENDED STANDARD FOR SPACE DATA LINK SECURITY
SECURITY TRAILER
MESSAGE AUTHENTICATION CODE (MAC)
(bits)
128
Figure 7-2. Security Trailer (TM Baseline)
C.5.
BASELINE MODE FOR USE WITH TC
C.6.
ALGORITHM
The baseline implementation to be used for interoperability testing and operation is
Authentication, using the Advanced Encryption Standard (AES) algorithm used in the
Cipher-based Message Authentication Code (CMAC) mode as defined in [5]. In addition:
d) the key shall be 128 bits in total length;
e) the anti-replay sequence number shall be 32 bits in total length, where all 32 bits are
transmitted in-line in the Sequence Number field of the Security Header;
f) the output Message Authentication Code shall be 128 bits in total length.
C.7.
SECURITY HEADER
The baseline implementation uses a Security Header of 6 octets in length. The format of the
Security Header is shown in Figure 7-3.
NOTE:
The CMAC mode of operation performs no encryption and does not require an
initialization vector nor padding, therefore the length of the Initialization Vector
and Pad Length fields shown in Figure 7-3 are zero octets each.
SECURITY HEADER
(bits)
SECURITY
PARAMETER
INDEX
INITIALIZATION
VECTOR
SEQUENCE NUMBER
PAD
LENGTH
16
0
32
0
Figure 7-3. Security Header (TC Baseline)
C.8.
SECURITY TRAILER
The baseline implementation uses a Security Trailer of 16 octets in length. The format of the
Security Header is shown in Figure 7-4.
CCSDS 355.0-R-1
Page C-4
February 2016
DRAFT CCSDS RECOMMENDED STANDARD FOR SPACE DATA LINK SECURITY
SECURITY TRAILER
MESSAGE AUTHENTICATION CODE (MAC)
(bits)
128
Figure 7-4. Security Trailer (TC Baseline)
C.9.
BASELINE MODE FOR USE WITH AOS
C.10. ALGORITHM
The baseline implementation to be used for interoperability testing and operation is
Authenticated Encryption, using the Advanced Encryption Standard (AES) algorithm used in
the Galois/Counter Mode (GCM) as defined in [5]. In addition:
g) the key shall be 128 bits in total length;
h) the input initialization vector shall be 96 bits in total length, where all 96 bits are
transmitted in-line in the Initialization Vector field of the Security Header;
i) the output Message Authentication Code shall be 128 bits in total length.
C.11. SECURITY HEADER
The baseline implementation uses a Security Header of 14 octets in length. The format of the
Security Header is shown in Figure 7-5.
NOTE 1:
The Galois/Counter Mode of operation normally uses a simple incrementing
counter as its initialization vector. A separate anti-replay Sequence Number is
unnecessary, therefore the Sequence Number field shown in Figure 7-5 is zero
octets in length. See section 4.1.1.2.
NOTE 2:
The Galois/Counter Mode of operation does not require padding, therefore the
length of the Pad Length field shown in Figure 7-5 is zero octets.
SECURITY HEADER
(bits)
SECURITY
PARAMETER
INDEX
INITIALIZATION VECTOR
SEQUENCE
NUMBER
PAD
LENGTH
16
96
0
0
Figure 7-5. Security Header (AOS Baseline)
C.12. SECURITY TRAILER
The baseline implementation uses a Security Trailer of 16 octets in length. The format of the
Security Header is shown in Figure 7-6.
CCSDS 355.0-R-1
Page C-5
February 2016
DRAFT CCSDS RECOMMENDED STANDARD FOR SPACE DATA LINK SECURITY
SECURITY TRAILER
MESSAGE AUTHENTICATION CODE (MAC)
(bits)
128
Figure 7-6. Security Trailer (AOS Baseline)
CCSDS 355.0-R-1
Page C-6
February 2016