Research and Development for
Space Data System Standards
Experimental Specification
CCSDS xxx.x-O-1
Orange Book
October 2008
EXPERIMENTAL SPECIFICATION FOR CRYPTOGRAPHIC SERVICE
AUTHORITY
Issue: / Orange Book, Issue 1Date: / October 2008
Location: / Not Applicable
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.
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
FOREWORD
This document is a CCSDS Experimental Specification that describes a data encapsulation method for space missions that need to apply security protections to the contents of transfer frames used by Space Data Link Protocols over a space link.
Through the process of normal evolution, it is expected that expansion, deletion, or modification of this document may occur. This document 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.
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.
– Deutsches Zentrum für Luft- und Raumfahrt e.V. (DLR)/Germany.
– European Space Agency (ESA)/Europe.
– Federal Space Agency (Roskosmos)/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 Space Technology (CAST)/China.
– Commonwealth Scientific and Industrial Research Organization (CSIRO)/Australia.
– Danish Space Research Institute (DSRI)/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 & Atmospheric Administration (NOAA)/USA.
– National Space Organization (NSPO)/Taipei.
– Space and Upper Atmosphere Research Commission (SUPARCO)/Pakistan.
– Swedish Space Corporation (SSC)/Sweden.
– United States Geological Survey (USGS)/USA.
PREFACE
This document is a CCSDS Experimental Specification. Its Experimental status indicates that it is part of a research or development effort based on prospective requirements, and as such it is not considered a Standards Track document. Experimental Specifications are intended to demonstrate technical feasibility in anticipation of a ‘hard’ requirement that has not yet emerged. Experimental work may be rapidly transferred onto the Standards Track should a hard requirement emerge in the future.
DOCUMENT CONTROL
Document / Title / Date / StatusCCSDS xxx.x-O-1 / Cryptographic Service,
Experimental Specification, Issue 1 / October 2008 / Current issue
CONTENTS
Section Page
CCSDS xxx.x-O-1 Page i October 2008
EXPERIMENTAL SPECIFICATION FOR CRYPTOGRAPHIC SERVICE
1 Introduction 8
1.1 Purpose 8
1.2 Scope 8
1.3 Applicability 8
1.4 Rationale 8
1.5 Document Structure 9
1.6 Definitions 9
1.7 Conventions 11
1.8 References 11
2 Overview 13
2.1 Concept of Cryptographic Service 13
2.2 Features of Cryptographic Service 13
2.2.1 Security Association 14
2.2.2 Security Association Database 15
2.3 Service Functions 15
2.3.1 Authentication 15
2.3.2 Encryption 15
2.3.3 Authenticated Encryption 16
2.3.4 Encryption with Validation 16
2.3.5 Replay Protection 16
3 DATA UNITS AND PROCEDURES 19
3.1 Security Header 19
3.1.1 Secondary Header Version Number 19
3.1.2 Secondary Header Length 20
3.1.3 Secondary Header Follows Flag 20
3.1.4 Security Parameter Index (SPI) 20
3.1.5 Sequence Number 20
3.1.6 Initialization Vector 20
3.1.7 Integrity Check Value 21
3.1.8 Pad 21
3.2 Cryptographic Service Procedures 21
3.2.1 Sending Procedures 21
3.2.1.1 Cryptographic Operations 21
3.2.1.2 Anti-Replay Operations 22
3.2.2 Receiving Procedures 22
3.2.2.1 SA Policy Enforcement 22
3.2.2.2 Cryptographic Operations 22
3.2.2.3 Anti-Replay Operations 23
3.3 TM Transfer Frame Procedures 23
3.4 TC Transfer Frame Procedures 24
3.5 AOS Transfer Frame Procedures 25
4 MANAGED PARAMETERS 26
5 SECURITY 28
5.1 Security Background 28
5.2 Security concerns 28
5.3 Potential threats and attack scenarios 28
5.4 Consequences of not applying security 29
Figures
Figure 31. Security Header 19
Figure 32. Use of Cryptographic Service with TM. 24
Figure 33. Use of Cryptographic Service with TC. 24
Figure 34. Use of Cryptographic Service with AOS. 25
CCSDS xxx.x-O-1 Page i October 2008
EXPERIMENTAL SPECIFICATION FOR CRYPTOGRAPHIC SERVICE
1 Introduction
1.1 Purpose
The purpose of this Experimental Specification is to specify the Cryptographic Service for CCSDS data links. This service provides a secondary header format and associated procedures that may be used with the CCSDS Telecommand, Telemetry, 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 Experimental Specification 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 CCSDS Experimental specification has been contributed to CCSDS by NASA. It describes a data encapsulation mechanism for applying communications security to the contents of space data link protocol transfer frames at OSI Layer 2. The Experimental Specification specified in this document is to be invoked through the normal standards program of each CCSDS Agency, and is applicable to those missions for which the use of communications security at the data link layer is anticipated.
1.4 Rationale
The goals of this Experimental Specification are to:
a) provide data structures for cryptographic encapsulation that facilitate (and do not impede) successful implementation of the underlying cryptography;
b) provide a method independent of the underlying cryptographic algorithms employed by any particular space mission;
c) 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,
d) facilitate cross-support and use of the CCSDS Space Link Extensions (SLE) forward and return services.
More discussion of the Cryptographic Service’s goals and design choices may be found in reference [11].
1.5 Document Structure
This document is organized as follows:
Section 1 presents the purpose, scope, applicability and rationale of this Experimental Specification 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 and procedures employed by the service provider.
Section 4 lists the managed parameters associated with this service.
Section 5 provides an overview of security concerns with using the Cryptographic Service.
Annex A lists all acronyms used within this document.
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.
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: (1) Verification of the identity of a user, device, or other entity in a computer system, often as a prerequisite to allowing access to resources in a system. (2) Verification of the integrity of data that have been stored, transmitted, or otherwise exposed to possible unauthorized modification.
Authorization: The granting of access rights to a user, program, or process.
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.
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.
Integrity Check Value (ICV): Algorithm-dependent authentication hash or Message Authentication Code (MAC). Its length is generally fixed according to the algorithm’s block size. ICV is computed over entire Security Header and Ciphertext including pad, if any
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 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.
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: the establishment of shared security information between two network entities to support secure communication. An SA may include cryptographic keys, initialization vectors, or digital certificates.
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 circumstance or event 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
1.8 References
The following documents are referenced in this Report. At the time of publication, the editions indicated were valid. All documents are subject to revision, and users of this Report 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] 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
[6] Security Architecture for Space Data Systems. Informational Report, CCSDS 350.5-G-x. Green Book. Washington, D.C.: CCSDS, ____.
[7] Space Missions Key Management Concept. Informational Report, CCSDS 350.6-G-x. Green Book. Washington, D.C.: CCSDS, ____.
[8] CCSDS Recommended Practice for a Key Management Scheme. Recommendation for Space Data System Standards, CCSDS 351.0-W-x. Magenta Book. Issue 1. Washington, D.C.: CCSDS, _____.
[9] CCSDS Recommended Practice for Authentication. Recommendation for Space Data System Standards, CCSDS 352.0-W-x. Magenta Book. Issue 1. Washington, D.C.: CCSDS, _____.
[10] CCSDS Recommended Practice for Symmetric Encryption. Recommendation for Space Data System Standards, CCSDS 353.0-W-x. Magenta Book. Issue 1. Washington, D.C.: CCSDS, _____.
[11] Cryptographic Service Concept of Operation. Experimental Specification, CCSDS xxx.x-O-x. Orange Book. Washington, D.C.: CCSDS, _____.
[12] Information Technology—Open Systems Interconnection—Basic Reference Model: The Basic Model. International Standard, ISO/IEC 7498-1. 2nd ed. Geneva: ISO, 1994.
2 Overview
2.1 Concept of Cryptographic Service
The Cryptographic Service is a data encapsulation method for space missions that need to apply authentication and/or encryption to the contents of transfer frames used by Space Data Link Protocols (references [1]-[3]) over a space link. A Security Header, similar in format to the existing TM Frame Secondary Header, is provided for transmitting certain Cryptographic Service parameters within transfer frames.