ESA PSS Authentication Standard The PSS authentication layer as defined in PSS Telecommand Decoder Specification provides the

possibility to add authentication procedures to a CCSDS based packet Telecommand stack. Although obsolete and not secure any more, this standard is the ideal candidate for a study that investigates the operational impact of authentification.

The Authentication Algorithm

The ESA PSS authentication processor algorithm is based on the hard knapsack problem. The method consists of generating a 40 bit digital signature using a transformation under a secret key applied to the message (i.e. the TC segment). The receiving end authenticates a TC segment by performing the same transformation made by the transmitting end, and by then comparing the received signature with the onboard-computed one. The figure below shows a functional diagram of the authentication processor.

There are four main parts:

The Hashing Function The Hard Knapsack The Deletion Box The Signature Comparator

At the transmitting end, the system is identical to the one shown in the figure above except for the signature comparator which is only present on the receiving end. The Hashing Function One purpose of the hashing function is to compress the variable amount data bits in the message x into a hash value H of fixed length (60 bit). But the most important task of the hashing function is to keep H secret, so that there is as much uncertainty about the input of the hard knapsack as possible. To keep the transformation secret, an authentication key is part of the input. The hashing function is realized through a 60 bit linear feedback shift register (LFSR) as shown in Figure 3. The 60 feedback coefficients C0, C1 C59 are secret and part of the authentication key. The LFSR must be initialized to the 60 bit value H=100000 (bit 0=1). H will be the value of the LFSR after the last bit of x has been shifted in. The LFSR is shown in the figure below.

The extended message x= [m,l,z] consists of the following elements, placed after each other in that order:

Received message m i.e. the TC segment Received logical authentication channel (LAC) value (4 octets =2 bit LAC Id + 30 bit LAC count) Three octets of virtual fill z, consisting of 24 zeros

The purpose of z is to ensure that the hashing function is provided with a minimum number of bits. The required minimum is 60 bits. As [m,l] has a minimum size of 40 bits, it is ensured that the minimum input for the hashing function is always at least 64 bit in length. The Hard Knapsack The purpose of the hard knapsack, as shown in is to make the overall system nonlinear and to serve as a true one-way function, so that it is not possible to deduce the hash value H from the signature S. The hard knapsack is based on the concept of the modular knapsack shown in the figure below. It consists of 60 weights W0W59 and is defined by the following transformation: with Q=2^48 and the bits Pj (j=059) of the hash value H select the corresponding weights of the knapsack to form the integral sum S. The result is the 48-bit knapsack sum S.

Deletion Box and Signature Comparator The deletion box deletes the 8 least significant bits of S producing the final 40 bit authentication signature S. The signature comparator compares the received 40 bit signature s with the onboard computed

signature S. The resulting validation result is sent to the Supervisor for final authorization of the TC segment (comparison of received LAC contents with onboard LAC registers). The Authentication Key The authentication key consists of 60x48 bit Hard knapsack weights=2880 bit and 60x1 bit Hashing function coefficients=60 bits. Therefore the length of the full authentication key is 2880+60=2940 bit=268 octets. Two such keys exist in the system:

The fixed key: This key is required and reserved for start-up and emergency operations. The contents of the fixed key are permanently stored in the AU (ROM). he programmable key: This key is required for normal operations. Its contents reside in the AU(RAM) where they can be modified by means of authentication control commands. These control commands allow any 5-octet block to be modified starting at any of the 370 (75x5) octet boundaries.

The Supervisor
The supervisor consists of four main parts:

The Logical Authentication Channel (LAC) Registers The Final Authorization Function The Control Command Processor The Deletion Function

They are briefly described in the next four subsections. The LAC Registers Three different LACs shall be provided:

A Principal LAC register (LAC ID = 00) A Auxiliary LAC register (LAC ID = 01) A Recovery LAC register (LAC ID = 10)

Each register is a 32 bit memory with 2 bit of the LAC ID (bits 0 and 1) are fixed. The purpose of the LAC ID is to identify the LAC used by the sending end and, consequently, the LAC registers to be selected for the final authorization of the TC segment. The 30 bit of non-fixed memory of the principal and auxiliary registers shall be fully in-flight programmable by means of control commands. The cold start of these registers shall be all bits set to 1. The recovery register is stored in non-volatile memory and only the 8 LSBs are programmable. The remaining 22 bits are fixed to 1. The Final Authorisation Function If the received signature s of a TC segment is found to be identical to the computed signature S, the signal Signature valid is sent to the Final Authorization Function, where the contents of the received LAC count field shall be compared with the contents of the indicated LAC register. If they are found to be equal there are two cases.

The TC segment was transferred on a MAP with MAP ID 0 to 62. In this case, the TC segment shall be authorized for transfer to the segmentation layer

The TC segment was transferred on MAP 63 which means that it contains an authentication unit control command. In this case the TC segment is further processed by the control command processor

In both cases the LAC register shall be incremented by one. The Control Command Processor The control command processor processes the special TC segments called authentication control commands (i.e. having MAP ID 63) and execute the instructions they contain. Any TC segment not conforming to the specified formats is rejected. The Deletion Function The deletion function is responsible for deleting the authentication tail from all TC segments that have been authorized by the final authorization function.

Formats of the Authenticated TC Segments

The authentication tail of a TC segment has a length of 9 octets (5 for the signature + 4 for the LAC value). Therefore the maximum length of a TC segment shall be 240 octets, it minimum length shall be 10 octets. Specific Formats TC segments with sequence flag set to unsegmented (11) and MAP ID set to 63 (111111) are identified as authentication control commands. They are organised in three groups as follows:

One octet of TC segment header One octet following the segment header to specify the command identifier Zero, four or eight octets of control command data field

The table below contains a list of all authentication control commands. Dummy Segment Control Command The purpose of this group 1 control command is to serve as a blank or NOP (no operation) for testing purposes, as required during operations. Select Key Control Commands There are two such commands defined: The Select fixed key command shall mandatory be encrypted with the fixed key. The AU, which monitors the control command identifier, shall select the fixed key prior to authenticating the TC segment. If authenticated successful, the fixed key shall remain selected, otherwise the previously used key shall remain selected. The Select programmable key command shall mandatory be encrypted with the programmable key. The AU, which monitors the control command identifier, shall select the programmable key prior to authenticating the TC segment. If authenticated successful, the programmable key shall remain selected, otherwise the previously used key shall remain selected. Load Fixed Key in Programmable Memory Control Command The purpose of this command is to load the 2940 bit fixed key (which can be relied upon at all times) in the programmable key memory with a single instruction control command. The key used for encrypting the TC segment will be whatever key was selected in the AU at the time the command was transmitted.

Set new LAC value Control Command This command sets the value of any of the three programmable LAC registers. As soon as the TC segment is authorised by the authentication process, the specified LAC count value shall be forced into the appropriate LAC register. The key used for encrypting the TC segment will be whatever key was selected in the AU at the time the command was transmitted. Change Programmable Key Control Command Two such control commands are provided to cover the full size of the 2940 bit programmable key. This is because the start address specified by the third octet of the control command allows any 5 octet block to be modified at any of the 268 octet boundaries as follows:

Command A concerns the first 256 octet boundaries Command B concerns the last 112 octet boundaries

It is possible to load a 5 octet (40 bit) block from any of the 268 boundaries. In practise, the operational procedure shall consist of loading the 74 consecutive blocks of 40 bit required for the complete 2940-bit programmable key. The key used for encrypting the TC segment will be whatever key was selected in the AU at the time the command was transmitted. Once the TC segment has been authorised, the TC segment, minus the 40-bit signature s (i.e. [m,l]) shall be complemented and passed once more through the authentication processor. The result is a 40 bit pseudo signature which is then loaded into the programmable key memory at the indicated location instead of being sent to the comparator.

Operational Procedures
Prcedures for changing the Programmable Key Cryptanalysis studies have shown that each authentication key must be selected according to severe cryptographic criteria. So each key has to be validated from a cryptographic point of view. Therefore, in practise, always the whole programmable key shall be replaced. The loading of the 2940 bit programmable key shall be done with the smallest amount of authentication control commands in a standard way. Therefore, only 74 control commands shall be uplinked containing 74 change block A and 22 change block B commands. For detailed information on the uplink process, please refer to the PSS telecommand decoder document. Recovery Cases This subsection covers the recovery procedures envisaged during various emergency situations. The emergency situations likely to be encountered can be listed as follows:

Emergency A: One TC decoder fails to deliver command data because of a malfunction of the AU Emergency B: A power-down event occurred on the spacecraft and destroys the AU volatile memory meaning the programmable key and the two programmable LAC registers are replaced by their cold start values Emergency C: A telemetry subsystem failure has resulted in the telemetry downlink to be interrupted Emergency D: The contents of the programmable key have been corrupted

Reporting Mechanisms
Aside from the Command Link Control Word (CLCW), the Telecommand decoder provides two different non-standard reporting mechanisms, the AU status report and the Frame Analysis Report (FAR).

AU Status Report The AU status report consists of 80 bit of status data containing information on the current authentication key and the values of the LAC registers. The AU status report is then forwarded to the telemetry interface. There it is placed in a telemetry source packet for transfer to the ground via one of the mission-specific telemetry virtual channels. Frame Analysis Report (FAR) The FAR consists of 32 bits of survey data containing information if and why a frame has been discarded or accepted. This can be seen as a more detailed version of the CLCW report. Amongst others, the FAR contains information on the authentication process of a frame. It says whether and why the frame has passed authentication or not. The concrete formatting of the FAR can is shown in the PSS telecommand decoder specification document. After generation, the FAR is forwarded to the telemetry interface. There it is placed in a telemetry source packet for transfer to the ground via one of the mission-specific telemetry virtual channels.