Draft Recommendation for
Space Data System Standards
CRYPTOGRAPHIC
SERVICE FOR CCSDS
DATA LINKS
PROPOSED STANDARD
CCSDS 132.5-W-1
WHITE BOOK
February 2016
DRAFT CCSDS RECOMMENDED STANDARD FOR CRYPTOGRAPHIC SERVICE
AUTHORITY
Issue:
White 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 132.5-W-1
Page i
February 2016
DRAFT CCSDS RECOMMENDED STANDARD FOR CRYPTOGRAPHIC SERVICE
FOREWORD
This document describes a data encapsulation method 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 132.5-W-1
Page ii
February 2016
DRAFT CCSDS RECOMMENDED STANDARD FOR CRYPTOGRAPHIC SERVICE
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 132.5-W-1
Page iii
February 2016
DRAFT CCSDS RECOMMENDED STANDARD FOR CRYPTOGRAPHIC SERVICE
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 132.5-W-1
Page iv
February 2016
DRAFT CCSDS RECOMMENDED STANDARD FOR CRYPTOGRAPHIC SERVICE
DOCUMENT CONTROL
Document
Title and Issue
Date
Status
CCSDS
132.5-W-1
Cryptographic Service for CCSDS
Data Links,
Draft Recommended Standard,
Issue 1
February
2016
Current draft
CCSDS 132.5-W-1
Page v
February 2016
DRAFT CCSDS RECOMMENDED STANDARD FOR CRYPTOGRAPHIC SERVICE
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-1
1.5 DOCUMENT STRUCTURE ................................................................................. 1-2
1.6 DEFINITIONS........................................................................................................ 1-2
1.7 CONVENTIONS .................................................................................................... 1-4
1.8 REFERENCES ....................................................................................................... 1-5
2 OVERVIEW ................................................................................................................... 2-6
2.1 CONCEPT OF CRYPTOGRAPHIC SERVICE .................................................... 2-6
2.2 FEATURES OF CRYPTOGRAPHIC SERVICE .................................................. 2-6
2.2.1 INTERNAL ORGANIZATION OF PROTOCOL ENTITY ..................... 2-7
2.2.2 RELATIONSHIP OF THE SERVICE TO TM .......................................... 2-7
2.2.3 RELATIONSHIP OF THE SERVICE TO TC ........................................... 2-8
2.2.4 RELATIONSHIP OF THE SERVICE TO AOS ........................................ 2-8
2.3 SERVICE FUNCTIONS ........................................................................................ 2-9
2.3.1 SECURITY ASSOCIATIONS ................................................................... 2-9
2.3.2 AUTHENTICATION ............................................................................... 2-11
2.3.3 ENCRYPTION ......................................................................................... 2-12
2.3.4 AUTHENTICATED ENCRYPTION....................................................... 2-13
3 DATA UNITS ............................................................................................................... 3-14
3.1 SECURITY HEADER .......................................................................................... 3-14
3.1.1 SECURITY HEADER VERSION NUMBER ......................................... 3-14
3.1.2 SECURITY HEADER LENGTH............................................................. 3-14
3.1.3 SECURITY PARAMETER INDEX (SPI) ............................................... 3-15
3.1.4 SEQUENCE NUMBER ........................................................................... 3-15
3.1.5 INITIALIZATION VECTOR................................................................... 3-15
3.1.6 MESSAGE AUTHENTICATION CODE................................................ 3-15
3.1.7 PAD .......................................................................................................... 3-15
4 CRYPTOGRAPHIC SERVICE PROCEDURES .................................................... 4-16
4.1 SECURITY ASSOCIATION MANAGEMENT PROCEDURES ...................... 4-16
4.1.1 SA MANAGEMENT OPERATIONS...................................................... 4-16
4.2 SENDING PROCEDURES .................................................................................. 4-17
4.2.1 AUTHENTICATION OPERATIONS ..................................................... 4-17
4.2.2 ENCRYPTION OPERATIONS ............................................................... 4-18
4.2.3 AUTHENTICATED ENCRYPTION OPERATIONS............................. 4-18
4.3 RECEIVING PROCEDURES .............................................................................. 4-18
4.3.1 SA POLICY ENFORCEMENT OPERATIONS ..................................... 4-18
4.3.2 AUTHENTICATION OPERATIONS ..................................................... 4-19
CCSDS 132.5-W-1
Page vi
February 2016
DRAFT CCSDS RECOMMENDED STANDARD FOR CRYPTOGRAPHIC SERVICE
4.3.3 ENCRYPTION OPERATIONS ............................................................... 4-19
4.3.4 AUTHENTICATED ENCRYPTION OPERATIONS............................. 4-19
5 USE OF THE SERVICE WITH CCSDS PROTOCOLS ........................................ 5-20
5.1 TM PROTOCOL .................................................................................................. 5-20
5.1.1 TM TRANSFER FRAME PROCEDURES ............................................. 5-20
5.2 TC PROTOCOL ................................................................................................... 5-21
5.2.1 TC TRANSFER FRAME PROCEDURES .............................................. 5-21
5.3 AOS PROTOCOL ................................................................................................ 5-22
5.3.1 AOS TRANSFER FRAME PROCEDURES ........................................... 5-22
6 MANAGED PARAMETERS ..................................................................................... 6-24
7 SECURITY ................................................................................................................... 7-26
7.1 INTRODUCTION ................................................................................................ 7-26
7.2 SECURITY CONCERNS .................................................................................... 7-26
7.2.1 DATA PRIVACY ..................................................................................... 7-26
7.2.2 DATA INTEGRITY ................................................................................. 7-26
7.2.3 AUTHENTICATION OF COMMUNICATING ENTITIES................... 7-26
7.2.4 CONTROL OF ACCESS TO RESOURCES ........................................... 7-27
7.2.5 AVAILABILITY OF RESOURCES ........................................................ 7-27
7.2.6 AUDITING OF RESOURCE USAGE .................................................... 7-27
7.3 POTENTIAL THREATS AND ATTACK SCENARIOS ................................... 7-27
7.4 CONSEQUENCES OF NOT APPLYING SECURITY ...................................... 7-27
CCSDS 132.5-W-1
Page vii
February 2016
DRAFT CCSDS RECOMMENDED STANDARD FOR CRYPTOGRAPHIC SERVICE
1
1.1
INTRODUCTION
PURPOSE
The purpose of this Recommended Standard is to specify the Cryptographic Service for
CCSDS data links. This service provides a secondary header format 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 encryption at the link layer.
1.2
SCOPE
This Recommended Standard defines the Cryptographic Service 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.
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.
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:
CCSDS 132.5-W-1
Page 1-1
February 2016
DRAFT CCSDS RECOMMENDED STANDARD FOR CRYPTOGRAPHIC SERVICE
a) provide a method of cryptographic encapsulation 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) facilitate cross-support using 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 Cryptographic Service’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 Cryptographic Service.
Section 3 specifies the protocol data units provided for this service.
Section 4 specifies 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 Cryptographic Service.
Annex A provides a Protocol Implementation Conformance Statement.
Annex B provides a list of informative references.
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.
CCSDS 132.5-W-1
Page 1-2
February 2016
DRAFT CCSDS RECOMMENDED STANDARD FOR CRYPTOGRAPHIC SERVICE
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 of access rights to a user, program, or process.
‘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 transformation of data using mathematical algorithms in order to provide
confidentiality. 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
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.
CCSDS 132.5-W-1
Page 1-3
February 2016
DRAFT CCSDS RECOMMENDED STANDARD FOR CRYPTOGRAPHIC SERVICE
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. Parameters managed in a Security Association
include field lengths, algorithms used, cryptographic keys, and managed values for sequence
counters, IV, and MAC.
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.
1.7
CONVENTIONS
The following conventions apply throughout this Recommended Standard:
a) the words ‘shall’ and ‘must’ imply a binding and verifiable specification;
CCSDS 132.5-W-1
Page 1-4
February 2016
DRAFT CCSDS RECOMMENDED STANDARD FOR CRYPTOGRAPHIC SERVICE
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-3. Blue Book. Issue 3. Washington, D.C.: CCSDS, October 2006.
[5] Information Technology—Open Systems Interconnection—Basic Reference Model: The
Basic Model. International Standard, ISO/IEC 7498-1. 2nd ed. Geneva: ISO, 1994.
CCSDS 132.5-W-1
Page 1-5
February 2016
DRAFT CCSDS RECOMMENDED STANDARD FOR CRYPTOGRAPHIC SERVICE
2
OVERVIEW
2.1
CONCEPT OF CRYPTOGRAPHIC SERVICE
The Cryptographic Service is a data processing method for space missions that need to apply
authentication and/or encryption to the contents of transfer frames used by Space Data Link
Protocols over a space link. The Cryptographic Service is provided at the Data Link Layer
(Layer 2) of the OSI Basic Reference Model [5]. 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.
2.2
FEATURES OF CRYPTOGRAPHIC SERVICE
The purpose of the Cryptographic Service is to provide a secure standard format for
encapsulating 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 Cryptographic Service, but is an attribute of the underlying Space Data Link Protocol. A
Security Header is provided for delimiting the necessary cryptographic parameters within
transfer frames. The size of the Security Header used will reduce the maximum size of the
input data unit byte-for-byte below the maximum allowed by the underlying Space Data Link
Protocol.
Features of the Cryptographic Service 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 Cryptographic Service provides only whatever quality of service is provided
by the underlying Space Data Link Protocol.
CCSDS 132.5-W-1
Page 2-6
February 2016
DRAFT CCSDS RECOMMENDED STANDARD FOR CRYPTOGRAPHIC SERVICE
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 [B6]. Each of the three supported Space Data Link Protocols (TM, TC, and
AOS) correspond to the Data Link Protocol Sublayer.
When used with the supported Protocols, the Cryptographic Service is nominally interposed
on the sending end between the virtual channel generation and multiplexing functions; on the
receiving end, between the demultiplexing and virtual channel reception functions. Because
these functions occur entirely within the Data Link Protocol Sublayer, operation of the
Cryptographic Service is unaffected by the Synchronization And Channel Coding Sublayer.
2.2.2 RELATIONSHIP OF THE SERVICE TO TM
The relationship of the Cryptographic Service’s functions to other functions of the TM
Protocol is shown in Figure 2-1. Depending on the services actually used, not all of the
functions may be present in a real system.
(SENDING END)
Packet
Service
Packet
Processing
(RECEIVING END)
VC Access
Service
Packet
Service
VC_FSH VC_OCF
Service Service
VC Access
Service
Packet
Extraction
Virtual Channel Generation
VC_FSH VC_OCF
Service Service
Virtual Channel Reception
VC Frame
Service
Encryption
Virtual Channel Multiplexing
MC_FSH MC_OCF
Service Service
Virtual Channel Demultiplexing
Master Channel Generation
Message Authentication
VC Frame
Service
Decryption
MC_FSH MC_OCF
Service Service
Master Channel Reception
MC Frame
Service
MC Frame
Service
Message Verification
Master Channel Multiplexing
Master Channel Demultiplexing
All Frames Generation
All Frames Reception
Data Transmission
Figure 2-1. Conceptual Order of Processing within TM
All Cryptographic Service 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, VC_OCF, MC_FSH, and MC_OCF Services for authentication
only. They have no effect on the VC Frame and MC Frame Services.
CCSDS 132.5-W-1
Page 2-7
February 2016
DRAFT CCSDS RECOMMENDED STANDARD FOR CRYPTOGRAPHIC SERVICE
2.2.3 RELATIONSHIP OF THE SERVICE TO TC
The relationship of the Cryptographic Service’s functions to other functions of the TC
Protocol is shown in Figure 2-2. Depending on the services actually used, not all of the
functions may be present in a real system.
(SENDING END)
MAP Packet
Service
MAP Access
Service
MAP Packet
Processing
MAP
Generation
MAP Multiplexing
VC Packet
Service
(RECEIVING END)
COP Mgmt. VC Access
Service
Service
VC Packet
Processing
MAP Packet
Service
MAP Access
Service
MAP Packet
Extraction
MAP
Generation
MAP Demultiplexing
VC Packet
Service
COP Mgmt. VC Access
Service
Service
VC Packet
Extraction
Virtual Channel Generation
Virtual Channel Reception
Encryption
Decryption
Message Authentication
Virtual Channel Multiplexing
VC Frame
Service
VC Frame
Service
Message Verification
MC Frame
Service
MC Frame
Service
Virtual Channel Demultiplexing
Master Channel Multiplexing
Master Channel Demultiplexing
All Frames Generation
All Frames Reception
Data Transmission
Figure 2-2. Conceptual Order of Processing within TC
All Cryptographic Service functions (Authentication, Encryption, and Authenticated
Encryption) can be used with TC to protect the MAP Packet, MAP Access, VC Packet, COP
Management, and VC Access Services. They have no effect on the VC Frame and MC
Frame Services.
2.2.4 RELATIONSHIP OF THE SERVICE TO AOS
The relationship of the Cryptographic Service’s functions to other functions of the AOS
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 132.5-W-1
Page 2-8
February 2016
DRAFT CCSDS RECOMMENDED STANDARD FOR CRYPTOGRAPHIC SERVICE
(SENDING END)
Packet
Service
Bitstream
Service
Packet
Processing
Bitstream
Processing
(RECEIVING END)
VC Access
Service
VC_OCF
Service
Packet
Service
Bitstream
Service
Packet
Extraction
Bitstream
Extraction
VC Access
Service
VC_OCF
Service
Virtual Channel Generation
Virtual Channel Reception
Encryption
Decryption
Message Authentication
Virtual Channel Multiplexing
VC Frame
Service
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
Figure 2-3. Conceptual Order of Processing within AOS
All Cryptographic Service functions (Authentication, Encryption, and Authenticated
Encryption) can be used with AOS to protect the Packet, Bitstream, and VC Access Services.
They can be used with the VC_OCF Service for authentication only. They have no effect on
the VC Frame and MC Frame Services.
Neither Authentication nor Authenticated Encryption can be used with the Insert Service on
the physical channel, unless both of the following are true: (a) the sender defers message
authentication until Insert Zone data has been added into the transfer frame; and (b) the
receiver defers the extraction of Insert Zone data until message verification is complete.
Encryption has no effect on the Insert Service.
2.3
SERVICE FUNCTIONS
2.3.1 SECURITY ASSOCIATIONS
The Cryptographic Service 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.
CCSDS 132.5-W-1
Page 2-9
February 2016
DRAFT CCSDS RECOMMENDED STANDARD FOR CRYPTOGRAPHIC SERVICE
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. A maximum of 254
simultaneous Security Associations may be defined across an entire physical channel.
2.3.1.2 Security Association Service Types
When a Security Association is created, one of the following cryptographic functions is
selected to be carried out 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
All Transfer Frames using a Security Association on a physical channel include a Security
Header preceding the Frame Data area of the transfer frame. The Security Header carries the
Security Parameter Index, sequence number, initialization vector, message authentication
code, and any encryption block padding if necessary.
Once a Security Association is created, the lengths of the managed fields in the Security
Header are fixed and cannot be changed for the duration of the 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.
CCSDS 132.5-W-1
Page 2-10
February 2016
DRAFT CCSDS RECOMMENDED STANDARD FOR CRYPTOGRAPHIC SERVICE
NOTE:
Over-the-air negotiation of SA parameters is a (currently undefined) applicationlayer function.
2.3.2 AUTHENTICATION
The Cryptographic Service provides for the use of authentication algorithms to ensure the
integrity of transmitted data and the authenticity of the data source. The Cryptographic
Service also provides for the use of sequence numbering to detect the unauthorized replay of
previously transmitted data.
2.3.2.1 Message Authentication and Integrity
When the Cryptographic Service is used for Authentication, a Message Authentication Code
(MAC) is computed over the entire transfer frame, excluding the channel coding
synchronization marker, optional frame Error Control Field, and the MAC field within the
Security Header.
2.3.2.2 Replay Protection
When the Cryptographic Service 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 sequence number 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 deviates from the expected value by more than a defined
window, the receiver discards the frame, and does not increment its managed sequence
number.
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
CCSDS 132.5-W-1
Page 2-11
February 2016
DRAFT CCSDS RECOMMENDED STANDARD FOR CRYPTOGRAPHIC SERVICE
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.
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. Two 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.
NOTE:
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 ‘co-located’ with the Initialization Vector field.
b) 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 managed 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 Cryptographic Service provides for the use of encryption algorithms to ensure the
confidentiality of transmitted data.
CCSDS 132.5-W-1
Page 2-12
February 2016
DRAFT CCSDS RECOMMENDED STANDARD FOR CRYPTOGRAPHIC SERVICE
When the Cryptographic Service 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 encryption algorithm and mode used, additional fill data may be needed to pad any
undersized encryption blocks.
2.3.4 AUTHENTICATED ENCRYPTION
The Cryptographic Service provides for the use of authentication and encryption as one
combined procedure.
When the Cryptographic Service 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 132.5-W-1
Page 2-13
February 2016
DRAFT CCSDS RECOMMENDED STANDARD FOR CRYPTOGRAPHIC SERVICE
3
DATA UNITS
3.1
SECURITY HEADER
The Security Header is mandatory and shall consist of three mandatory fields and four
optional fields, positioned contiguously, in the following sequence:
a) Security Header Version Number (2 bits, mandatory);
b) Security Header Length (6 bits; mandatory);
c) Security Parameter Index (8 bits; mandatory);
d) Sequence Number (octet-aligned, fixed-length for the duration of the Security
Association; optional);
e) Initialization Vector (octet-aligned, fixed-length for the duration of the Security
Association; optional);
f) Message Authentication Code (octet-aligned, fixed-length for the duration of the
Security Association; optional).
g) Pad (octet-aligned, variable-length; optional).
A Security Header shall consist of at least 2 and 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 3-1.
SECURITY HEADER
VERSION
(‘01’)
(bits)
SECURITY
HEADER
LENGTH
SECURITY
PARAMETER
INDEX
SEQUENCE
NUMBER
(Optional)
INITIALIZATION
VECTOR
(Optional)
MESSAGE
AUTHENTICATION
CODE
(Optional)
PAD
(Optional)
2
6
8
Managed
Managed
Managed
Variable
Figure 3-1. Security Header
3.1.1 SECURITY HEADER VERSION NUMBER
Bits 0-1 of the Security Header shall contain the (Binary Encoded) Security Header Version
Number. This 2-bit field shall identify the data unit as a Security Header defined by this
subsection; it shall be set to ‘01’.
3.1.2 SECURITY HEADER LENGTH
Bits 2-7 of the Security Header shall contain the Security Header Length.
CCSDS 132.5-W-1
Page 3-14
February 2016
DRAFT CCSDS RECOMMENDED STANDARD FOR CRYPTOGRAPHIC SERVICE
This 6-bit field shall identify the total length in octets of the Security Header. The minimum
length value for this field is 2 octets, and the maximum is 64 octets.
3.1.3 SECURITY PARAMETER INDEX (SPI)
Bits 8-15 of the Security Header shall contain the Security Parameter Index.
This 8-bit field shall be used as an index to identify a Security Association (SA). There can
be up to 254 Security Associations per Master Channel. A value of all zeros (‘0’) for this
field is invalid. A value of all ones (‘255’) for this field is reserved by CCSDS for future use.
3.1.4 SEQUENCE NUMBER
The Sequence Number field shall follow the Security Parameter Index, without gap. This
field, if replay protection 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:
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 ‘co-located’ with the Initialization Vector.
3.1.5 INITIALIZATION VECTOR
The Initialization Vector field shall follow the Sequence Number field, without gap. It 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 duration of the
Security Association. If Encryption is not selected for a Security Association, this field shall
be zero octets in length.
3.1.6 MESSAGE AUTHENTICATION CODE
The Message Authentication Code field shall follow the Initialization Vector field, without
gap. It shall contain the transmitted portion of the Message Authentication Code, consisting
of a integral number of octets. The Message Authentication Code field length is managed
and is fixed for the duration of the Security Association. If Authentication is not selected for
a Security Association, this field shall be zero octets in length.
3.1.7 PAD
The Pad field shall follow the Message Authentication Code field, without gap. It shall
contain a data unit, supplied by the service user, consisting of an integral number of octets. If
encryption is not selected for a Security Association, this field shall be zero octets in length.
CCSDS 132.5-W-1
Page 3-15
February 2016
DRAFT CCSDS RECOMMENDED STANDARD FOR CRYPTOGRAPHIC SERVICE
4
CRYPTOGRAPHIC SERVICE PROCEDURES
The following procedures shall be carried out to perform the operations of the active Security
Association.
4.1
SECURITY ASSOCIATION MANAGEMENT PROCEDURES
4.1.1 SA MANAGEMENT OPERATIONS
Before a Security Association may be used to secure Transfer Frames on a channel, both the
sender and the receiver must create the Security Association and associate it with
cryptographic key(s).
NOTE 1:
It is expected that some missions will choose to define Security Associations
statically and pre-load 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.1.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 an 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.
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. A maximum of 254
simultaneous Security Associations may be defined across an entire physical channel.
4.1.1.2 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.
CCSDS 132.5-W-1
Page 4-16
February 2016
DRAFT CCSDS RECOMMENDED STANDARD FOR CRYPTOGRAPHIC SERVICE
4.1.1.3 Parameters Common to All SAs
Every Security Association shall also specify the following:
a) Security Parameter Index;
b) length and offset of Sequence Number field in Security Header;
c) length and offset of Initialization Vector field in Security Header;
d) length and offset of Message Authentication Code field in Security Header.
4.1.1.4 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.1.1.5 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.1.1.6 Parameters for Authenticated Encryption SAs
Every Security Association providing Authenticated Encryption shall specify everything
required in both sections 4.1.1.4 and 4.1.1.5 above.
4.2
SENDING PROCEDURES
4.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) either in the Sequence Number field of the Security
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 132.5-W-1
Page 4-17
February 2016
DRAFT CCSDS RECOMMENDED STANDARD FOR CRYPTOGRAPHIC SERVICE
Header or in the Virtual Channel Frame Count field of the transfer frame primary
header, according to the options specified for that Security Association;
c) compute a Message Authentication Code over the entire transfer frame, excluding the
frame synchronization marker, optional frame ECF, and the MAC field within the
Security Header;
d) truncate the least-significant bits of the computed MAC, such that the result is of
identical length to the MAC field within the Security Header;
e) place the computed MAC in the Security Header.
4.2.2 ENCRYPTION OPERATIONS
If Encryption is selected for a Security Association, the sender shall:
f) (optionally) prepend the frame data with fill bytes, placing the fill bytes in the Pad
field of the Security Header (only applicable if the encryption algorithm and mode
selected for the Security Association requires that the algorithm operate only upon an
integral number of fixed-size blocks);
g) encrypt the Pad and Frame Data fields.
4.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; then,
b) carry out the Authentication operations described in the preceding section 4.2.1.
4.3
RECEIVING PROCEDURES
4.3.1 SA POLICY ENFORCEMENT 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 the
following sections (4.3.2, 4.3.3, and 4.3.4), the receiver shall:
a) discard frames in which the received frame lacks a Security Header, but a Security
Association is active for that Virtual Channel;
b) discard frames in which the received frame has a Security Header, but no Security
Association is active for that Virtual Channel;
c) discard frames in which the received frame has a Security Header, but the Security
Association referenced in its Security Parameter Index is not the correct Security
Association for that Virtual Channel.
CCSDS 132.5-W-1
Page 4-18
February 2016
DRAFT CCSDS RECOMMENDED STANDARD FOR CRYPTOGRAPHIC SERVICE
4.3.2 AUTHENTICATION OPERATIONS
If Authentication is selected for a Security Association, the receiver shall:
a) compute a Message Authentication Code over the entire transfer frame, excluding the
frame synchronization marker, optional frame ECF, and the MAC field within the
Security Header;
b) truncate the least-significant bits of the computed MAC, such that the result is of
identical length to the MAC field within the Security Header;
c) verify that the computed MAC matches the MAC received in the Security Header;
d) discard 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, 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) discard 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) - Error! Reference source not found. above.
4.3.3 ENCRYPTION OPERATIONS
If Encryption is selected for a Security Association, the receiver shall:
a) decrypt the Pad and Frame Data fields.
4.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.3.2;
then,
b) carry out the Encryption operations described in the preceding section 4.3.3.
CCSDS 132.5-W-1
Page 4-19
February 2016
DRAFT CCSDS RECOMMENDED STANDARD FOR CRYPTOGRAPHIC SERVICE
5
5.1
USE OF THE SERVICE WITH CCSDS PROTOCOLS
TM PROTOCOL
The following restrictions apply to use of the Cryptographic Service 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, VC_OCF, MC_FSH, and MC_OCF 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 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.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 value of the Transfer Frame Security Header Flag shall be ‘1’2;
b) the TM Frame Secondary Header, if present, shall follow the TM Transfer Frame
Primary Header;
c) the Security Header shall follow the TM Frame Secondary Header, if present;
d) the Transfer Frame Data Field shall follow the Security Header;
e) the Operational Control Field (OCF), if present, shall follow the Transfer Frame Data
Field;
f) the Frame Error Control Field (ECF), if present, shall follow the Operational Control
Field.
The format of a TM Transfer Frame using the Cryptographic Service is shown in Figure 5-1.
2
The current revision of reference [1] does not include a Security Header Flag. It is proposed that the bit currently
designated as a Packet Order Flag in the TM Transfer Frame Primary Header should be redefined as a Security Header Flag
to signal the existence of a Security Header, and a Pink Sheet issued to amend reference [1].
CCSDS 132.5-W-1
Page 5-20
February 2016
DRAFT CCSDS RECOMMENDED STANDARD FOR CRYPTOGRAPHIC SERVICE
TM TRANSFER FRAME
6
Managed
SECURITY
HEADER
V
L
SPI
SEQ
IV
MAC
FRAME DATA
PAD
2-64
ECF
(Optional)
FRAME
SECONDARY
HEADER
(Optional)
OCF
(Optional)
(octets)
TRANSFER
FRAME
PRIMARY
HEADER
4
2
Encryption is done on Pad field in Security Header
and on Frame Data.
MAC is computed over Primary Header, FSH, Security Header, Frame Data, and OCF.
MAC is not computed over frame sync mark (not shown) or ECF.
Figure 5-1. TM Transfer Frame using the Cryptographic Service
5.2
TC PROTOCOL
The following restrictions apply to use of the Cryptographic Service with TC:
a) the MAP Packet, MAP Access, VC Packet, COP Management, 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 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 value of the Transfer Frame Security Header Flag shall be ‘1’;3
b) the TC Segment Header, if present, shall follow the TC Transfer Frame Primary
Header;
c) the Security Header shall follow the TC Segment Header, if present;
d) the Transfer Frame Data Field shall follow the Security Header;
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 Cryptographic Service is shown in Figure
5-2.
3
The current revision of reference [2] does not include a Security Header Flag. One of the two bits currently designated as
Spare in the TC Transfer Frame Primary Header should be redefined as a Security Header Flag to signal the existence of a
secondary header, and a Pink Sheet issued to amend reference [2].
CCSDS 132.5-W-1
Page 5-21
February 2016
DRAFT CCSDS RECOMMENDED STANDARD FOR CRYPTOGRAPHIC SERVICE
TC TRANSFER FRAME
5
1
SECURITY
HEADER
V
L
SPI
SEQ
IV
MAC
ECF
(Optional)
SEGMENT
HEADER
(octets)
TRANSFER
FRAME
PRIMARY
HEADER
FRAME DATA
PAD
2-64
2
Encryption is done on Pad field in Security Header and on Frame Data.
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 Cryptographic Service
5.3
AOS PROTOCOL
The following restrictions apply to use of the Cryptographic Service 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 Service,
and is protected by each of these services;
b) the VC_OCF Service may be used on a Global Virtual Channel with the
Authentication, Encryption, or Authenticated-Encryption Service, and is protected by
Authentication but is not protected by Encryption;
c) the 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;
d) the Insert Service interferes with the use of Authentication or AuthenticatedEncryption Services, and must not be used on any Master Channel in which the
Authentication or Authenticated-Encryption Services are used, unless both of the
following are true: (a) the sender defers message authentication until Insert Zone data
has been added into the transfer frame; and (b) the receiver defers the extraction of
Insert Zone data until message verification is complete. The Insert Service is not
protected by the Encryption Service, 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 value of the Transfer Frame Security Header Flag shall be ‘1’;4
b) the Insert Zone, if present, shall follow the AOS Transfer Frame Primary Header;
4
The current revision of reference [3] does not include a Security Header Flag. One of the two bits currently designated as
Spare in the AOS Transfer Frame Primary Header should be redefined as a Security Header Flag to signal the existence of a
Security Header, and a Pink Sheet issued to amend reference [3].
CCSDS 132.5-W-1
Page 5-22
February 2016
DRAFT CCSDS RECOMMENDED STANDARD FOR CRYPTOGRAPHIC SERVICE
c) the Security Header shall follow the Insert Zone, if present;
d) the Transfer Frame Data Field shall follow the Security Header;
e) the Operational Control Field (OCF), if present, shall follow the Transfer Frame Data
Field;
f) the Frame Error Control Field (ECF), if present, shall follow the Operational Control
Field.
The format of an AOS Transfer Frame using the Cryptographic Service is shown in
Figure 5-3.
AOS TRANSFER FRAME
V
(octets)
6-8
Managed
L
SPI
SEQ
IV
MAC
FRAME DATA
PAD
2-64
ECF
(Optional)
SECURITY
HEADER
INSERT
ZONE
(Optional)
OCF
(Optional)
TRANSFER FRAME
PRIMARY HEADER
4
2
Encryption is done on Pad field in Security Header
and on Frame Data.
MAC is computed over Primary Header, Insert Zone, Security Header, Frame Data, and OCF.
MAC is not computed over frame sync mark (not shown) or ECF.
Figure 5-3. AOS Transfer Frame using the Cryptographic Service
CCSDS 132.5-W-1
Page 5-23
February 2016
DRAFT CCSDS RECOMMENDED STANDARD FOR CRYPTOGRAPHIC SERVICE
6
MANAGED PARAMETERS
In order to conserve bandwidth on the space link, certain parameters associated with the
Cryptographic Service 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 Cryptographic Service 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.
Table 6-1. Managed Parameters for Cryptographic Service
Managed Parameter
Allowed Values
Defined In
Minimum data unit length (octets)
Integer
Reference
[4]
Maximum data unit length (octets)
Integer
Reference
[4]
Header Version Number
’01’
Reference
[4]
Security Parameter Index (SPI)
1-254
Security Association Service Type
Authentication
(indicates which cryptographic operations are
performed for this Security Association)
Encryption
Authenticated
Encryption
Security Association Context
GVC ID
(identifies the GVC IDs or GMAP IDs with which this
SA is used)
GMAP ID
Transmitted length of Message Authentication Code
(octets)
Integer
Transmitted length of Initialization Vector (octets)
Integer
CCSDS 132.5-W-1
Page 6-24
February 2016
DRAFT CCSDS RECOMMENDED STANDARD FOR CRYPTOGRAPHIC SERVICE
Anti-replay Sequence Number
Integer
Anti-replay Sequence Number window (± current
Sequence Number)
Integer
Transmitted length of Sequence Number (octets)
Integer
CCSDS 132.5-W-1
Page 6-25
February 2016
DRAFT CCSDS RECOMMENDED STANDARD FOR CRYPTOGRAPHIC SERVICE
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 Cryptographic Service 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].
7.2.1 DATA PRIVACY
If there is a reason to believe that non-authorized entities might be able to view or obtain the
data, and if there is a need to ensure that non-authorized entities not be able to view or obtain
the data, then confidentiality needs to be applied. For more information regarding the choice
of particular cryptographic algorithms, see reference [B5].
7.2.2 DATA INTEGRITY
If there is a need to ensure that the data has not been modified in transit without such
modification being recognized, then integrity needs to be applied. For more information
regarding the choice of particular cryptographic algorithms, see reference [B5].
7.2.3 AUTHENTICATION OF COMMUNICATING ENTITIES
If the authenticity of the source of the data is required (e.g., the data contains spacecraft
commands), then authentication needs to be applied. For more information regarding the
choice of particular cryptographic algorithms, see reference [B5].
CCSDS 132.5-W-1
Page 7-26
February 2016
DRAFT CCSDS RECOMMENDED STANDARD FOR CRYPTOGRAPHIC SERVICE
7.2.4 CONTROL OF ACCESS TO RESOURCES
7.2.5 AVAILABILITY OF RESOURCES
The Cryptographic Service provides no protection against denial-of-service attacks against
the communications channel, such as radio-frequency jamming.
7.2.6 AUDITING OF RESOURCE USAGE
7.3
POTENTIAL THREATS AND ATTACK SCENARIOS
The Cryptographic Service 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, or TC
MAP ID as metadata for inferring information about the parties communicating and possibly
the nature of their communications.
The Cryptographic Service 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.
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 132.5-W-1
Page 7-27
February 2016
DRAFT CCSDS RECOMMENDED STANDARD FOR CRYPTOGRAPHIC SERVICE
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 132.5-W-1
Page A-1
February 2016
DRAFT CCSDS RECOMMENDED STANDARD FOR CRYPTOGRAPHIC SERVICE
ANNEX B
INFORMATIVE REFERENCES
(This annex is not part of the Recommendation)
[B1] Concept of Operation: Cryptographic Service for CCSDS Data Links. Informational
Report, CCSDS xxx.x-G-x. 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-x. 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] CCSDS Security Algorithms. Recommendation for Space Data System Standards,
CCSDS 352.0-B-1. Blue Book. Issue 1. Washington, D.C.: CCSDS, _____.
[B6] Overview of Space Link Protocols. Informational Report, CCSDS 130.0-G-1. Green
Book. Issue 1. Washington, D.C.: CCSDS, June 2001.
[B7] Idaho State University, Glossary of INFOSEC and INFOSEC Related Terms,
SIMPLOT Decision Center, August 1996.
NOTE:
Normative references are listed in section 1.8.
CCSDS 132.5-W-1
Page B-2
February 2016