-
StatusOngoing
-
Status date2013-03-01
Taking advantage of the upgrading of the Spacecraft Computer Unit (SCU) towards a more optimized architecture, for Eurostar 3000 (E3000) Satellite platform and supported by ESA ARTES4 R&D funding, EADS Astrium has designed and developed a new security function for the Telecommand (TC) link between the Ground and Space segments.
The aim of the new security function is to provide better confidentiality protection for the TC data and to provide at the same time all the guarantees about the authentication of the source of the data, and their integrity.
This security function is based on the use of the AES algorithm, for the protection of the data and on the use of the GCM mode for the implementation of the upper security layer, more dedicated to the authentication and to the integrity aspects.
Security methods, AES and GCM modes are based on the NIST standards; FIPS 197 and SP800-38D, and are implemented within the dedicated module of E3000 Data Handling Subsystem (DHS), named AES CDU.
The main benefits of this product and its associated services are:
- Confidentiality: security service to keep the content of information accessible to only those authorized to access it - encryption,
- Integrity: security service to make sure that data is not modified, deleted or inserted with other data by unauthorised users - checksum or signature,
- Authentication: service assuring that origin of messages is correctly identified - signature.
- New Hardware definition and design with entailing a minimum the SW design,
- Complete non regression tests shall validate modification and their side effects,
- Complete qualification of the AES EQM with a SCU EM.
- The new AES will provide more confidentiality and more robustness in the security layer, and is a non-ITAR alternative to the more expensive ITAR CDU Centurion,
- The Proposed evolution is the AES_CDU plug based on AES algorithm:
- SCU Mk1 & Mk2 compatible (same I/F as the CDU Centurion),
- Over The Air Re-keying (OTAR) compatible,
- Algorithm Astrium propriety, evolution possible,
- Reduce US dependency,
- Reduce recurrent cost,
- Reduce ground cost,
- Compatible with Centurion = AES + Centurion on the same S/C (request from some customers).
- Architecture overview
The on-board TC processing chain includes a specific unit, the AES CDU, which interfaces the SCU. Redundancy is provided by implementing one AES CDU together with each SCU (no cross-strapping). The AES CDU is accommodated as an independent mechanical module, on a wall of the Satellite structure. Two insulated modules are required for nominal operations; they will be mechanically stacked together. One AES CDU module is associated to one SCU and connected to it via a dedicated harness. One non-volatile memory is implemented for storing initial and fallback parameters. Volatile memory is provided as working area and temporary storage of data. Both memory areas are protected in integrity by EDAC, scrubbing or triplication.
- Core function
The AES CDU implements the Advanced Encryption Standard (AES) symmetric block cipher algorithm. The algorithm is public; the security strength relies on the properties of the keys: randomness, uniqueness, secrecy, … The Galois-Counter Mode (GCM) is recommended by NIST. The main advantage of this mode, compared to other operation modes of the algorithm, is its efficiency, in particular the need for one single key for both encryption (or decryption, that is the same operation) and authentication.
- Keys
The key management is based on a Key hierarchy: traffic encryption key (TEK) used for telecommand security, key encryption key (KEK) used for TEK transfer security. At launch time the AES CDU contains initial keys in PROM, of each type. The operational keys are generated on ground in accordance with required properties (randomness, uniqueness, confidentiality). Those session keys are to be uploaded in accordance to the operational scenario (for example; only one for immediate use or a set of keys for future use), through an over-the-air re-keying (OTAR) mechanism, for storage in AES CDU volatile memory.
- System Protocol and AES CDU process
In secure mode any ground command is transferred using dedicated control blocks in the CLTU, which contains auxiliary data (anti-replay counter, authentication tag, key index, initialisation vector, number of blocks) to be used by the AES CDU for further processing, but not used by the SCU. Using the auxiliary data, the AES CDU first checks the received anti-replay counter by comparison with its internal counter, then deciphers the block and returns the deciphered data block to the SCU, and finally computes the authentication tag and compares it to the received one.
In case of failed anti-replay counter check or authentication, the AES CDU blocks the data returning to the SCU, which triggers a time-out in the SCU and telecommand abandoning. The AES CDU provides all necessary telemetry for report to the ground segment.
The design and development plan of the AES covers the following activities:
- Specification, design definition & qualification of the equipment, and hardware manufacturing (EM, EQM),
- AES accommodation on the E3000 spacecraft,
- Avionic validation of the unit inside its platform environment (Avionic test bench campaign),
- On-board software development & non-regression tests of AES evolutions,
- Specification & definition of the Harness & Database for AES product in the satellite process,
- Satellite AIT EGSE & test procedures upgrades,
- Flight procedures upgrades.
To run these activities, the development plan was a standard development logic separated in several phases (Kick Off, BDR (internal), MTR, QRR, Final review).
The validation of each phases and the passage to the next phase being made through formal reviews, and consolidated through a risk mitigation action plan. Building and successful testing of an Engineering Qualification Model (EQM) was mandatory to demonstrate the compliance to the unit technical requirements, but also for the functional chain validation and notably the compatibility with E3000 Flight Software.
- Option 3 of the Contract formalised between ESA and Astrium in March 2007,
- Kick Off held in December 2009,
- Assembly of first EM achieved in June 2010,
- AES BDR held in June 2010,
- AES MTR held in October 2010,
- AES FR held in June 2011,
- First Proto Flight AES: Launched in September 2011