Data Link Layer Security for Spacecraft Communication Implementation on FPGA

Master of Science Thesis in Electrical Engineering Department of Electrical Engineering, Linköping University, 2020

Data Link Layer Security for Spacecraft Communication implementation on FPGA

Sarah Sundberg Master of Science Thesis in Electrical Engineering Data Link Layer Security for Spacecraft Communication implementation on FPGA Sarah Sundberg LiTH-ISY-EX--20/5332--SE

Supervisor: Niklas Johansson isy, Linköpings universitet Martin Rönnbäck Cobham Gaisler Anandhavel Sakthivel Cobham Gaisler Examiner: Jan-Åke Larsson isy, Linköpings universitet

Division of Information Coding Department of Electrical Engineering Linköping University SE-581 83 Linköping, Sweden

With increasing awareness of potential security threats there is a growing interest in communication security for spacecraft control and data. Traditionally commer- cial and scientiﬁc missions have relied on their uniqueness to prevent security breaches. During time the market has changed with open systems for mission control and data distribution, increased connectivity and the use of existing and shared infrastructure. Therefore security layers are being introduced to protect spacecraft communication. In order to mitigate the perceived threats, the Consul- tative Committee for Space Data Systems (CCSDS) has proposed the addition of communication security in the various layers of the communication model. This thesis describes and discuss their proposal and look into how this application should be implemented into the data link layer of the communication protocol to protect from timing attacks. An implementation of AES-CTR+GMAC is constructed in software to compare diﬀerent key lengths and another implementation is constructed in synthesized VHDL for use on hardware to investigate the impact on area consumption on the FPGA as well as if it is possible to secure it from cache-timing attacks.

iii

Acknowledgments

I would like to thank Cobham Gaisler for the opportunity to perform this thesis with such an interesting subject. I especially want to thank my supervisors Martin Rönnbäck and Anandhavel Sakthivel for all their guidance and support during this work. Also I want to thank my examiner Jan-Åke Larsson for all help and guidance. Lastly I would like to thank my friends and family for supporting me through this work and this special time.

Gothenburg, August 2020 Sarah Sundberg

Contents

Notation ix

1 Introduction 1 1.1 Background ...... 3 1.2 Problem Formulation ...... 3 1.3 Related Work ...... 4 1.4 Delimitations ...... 4

2 Cryptographic Algorithms 7 2.1 Message Authentication Code ...... 7 2.2 Galois Field ...... 8 2.3 Hash-based Message Autentication Code ...... 10 2.4 Cipher-based Message Authentication Code ...... 10 2.5 Advanced Encryption Standard ...... 11 2.6 Counter Mode ...... 13 2.7 Galois Counter Mode/Galois Message Authentication Code . . . . 14 2.8 Implementation weaknesses ...... 17 2.8.1 Timing Attacks ...... 17

3 Cryptography usage in Satellite Communication 19 3.1 Security Association ...... 22 3.1.1 General Parameters ...... 23 3.1.2 Encryption Parameters ...... 23 3.1.3 Authentication Parameters ...... 23 3.2 Cryptographic Keys ...... 24 3.2.1 Secret Keys vs. Public Keys ...... 24 3.2.2 Key Variants ...... 24 3.2.3 Key Hierarchy ...... 25 3.3 Security of Keys ...... 26 3.3.1 Master Key Generation ...... 26 3.4 Key Lifecycle ...... 27 3.5 Key Management ...... 28

vii viii Contents

4 Implementation 29 4.1 Key management ...... 29 4.1.1 Key storage ...... 30 4.1.2 Access of key storage ...... 30 4.2 Algorithm ...... 30 4.3 Architecture ...... 30 4.4 Software implementation ...... 32 4.4.1 Initial testing of software implementation ...... 32 4.4.2 Performance ...... 32 4.5 Hardware implementation ...... 33 4.5.1 FPGA ...... 33 4.5.2 VHDL ...... 33 4.5.3 Implementation ...... 34 4.5.4 Simulation ...... 35 4.5.5 Synthesis ...... 35 4.5.6 Initial testing of hardware implementation ...... 35 4.5.7 Performance ...... 35 4.6 Testing and validation ...... 35

5 Results and Discussion 37 5.1 Software implementation ...... 37 5.1.1 Initial testing of software implementation ...... 37 5.1.2 Performance ...... 37 5.2 Hardware implementation ...... 38 5.2.1 Implementation with no resource sharing in the algorithm 38 5.2.2 Implementation with the two-process method approach and resource improvement ...... 39 5.2.3 Implementation adjusted to improve area consumption . . 40 5.2.4 Synthesis of individual parts of the algorithm ...... 40 5.3 Software vs Hardware ...... 42 5.4 CMAC vs GMAC ...... 43 5.5 Resource sharing ...... 43 5.6 Key management ...... 44

6 Conclusion and future work 45 6.1 Conclusion ...... 45 6.2 Future work ...... 46

A Test vectors for software implementation 49 A.1 AES-128 ...... 49 A.2 AES-192 ...... 53 A.3 AES-256 ...... 57

Bibliography 63 ix x Notation

Notation

Abbreviations Abbreviation Meaning aes Advanced Encryption Standard amba Advanced Microcontroller Bus Architecture bram Block Random Access Memory ccsds Consultative Committee for Space Data Systems clb Control Logic Block cmac Cipher-based Message Authentication Code cpi Clocks per Instruction cpu Central Processing Unit ctr Counter Mode fpga Field Programmable Gate Array gcd Greatest Common Divisor gcm Galois Counter Mode gf Galois Field gmac Galois Message Authentication Code hmac Hash-based Message Autentication Code iv Initialization Vector lut Look Up Table mac Message Authentication Code mips Million Instructions per Second nist National Institute of Standards and Technology osi Open Systems Interconnection otar Over-The-Air-Rekeying ram Random Access Memory rom Read Only Memory sa Security Association sdls Space Data Link Security see Single Event Eﬀects spi Security Parameter Index tc Telecommand tm Telemetry vhdl VHSIC Hardware Description Language Notation xi

Operations Notation Meaning Bitwise Exlusive-OR ⊕ Concatenation k

1 Introduction

Security options are available for the physical layer, the data link layer, the network layer, the transport layer and the application layer. This master thesis will take an in-depth look at the proposed security measures for the data link layer. For the data link layer, CCSDS has suggested either encryption, authentication or a combination of both. Spacecraft security measures need to be software independent, wherefore an hardware accelerated mechanism will have to be presented and compared to a software implementation to see if the execution time can be independent of the key value. This hardware accelerated mechanism is also evaluated based on execution time, latency and area consumption.

Communication is handled through telemetry (TM) and telecommand (TC) which are implemented as IP cores, meaning reusable logic blocks, to be used on application specific integrated circuits (ASIC) or field programmable gate arrays (FPGA). To encrypt and decrypt messages being sent through TM/TC protocol, an encryption/decryption function is implemented to be used together with these already existing cores, which are viewed in figure 1.1 and figure 1.2.

1 2 1 Introduction

Figure 1.1: The telecommand IP core [16]

Figure 1.2: The telemetry IP core [16]

Where this function is interfaced exactly inside these cores was evaluated by taking consideration to the trade oﬀ between having a common function to share between TM/TC and having two separate functions for each. 1.1 Background 3

1.1 Background

When protecting the spacecraft communication from threats the most important part is to protect the actual spacecraft since successful attacks on it could lead to a loss of mission. The technology used for communication is getting cheaper and easier to use, also most communication protocols are usually based on open standards and are publicly available. This means authentication has come to be of big importance when sending commands to the spacecraft [15]. A successful attack can result in mission impact and these can be of various severity, from software crashes up to loss of mission. It is of big importance to secure the system from attacks that could reveal information about the data or information about the key. All implementations have a risk of information leakage of different sort and these weaknesses need to be considered when designing. The systems used for protection against relevant threats in the data link layer are confidentiality, integrity and authentication services. Authentication algorithms provides data integrity, source authentication and replay protection. En- cryption algorithms provide for confidentiality and authenticated encryption algorithms provides all the services listed above combined [21]. For applying security services on the transfer frames the SDLS protocol is used, which will be described further in section 3.

1.2 Problem Formulation

The recommendations regarding cryptography in space missions have been updated and the concept overall is relatively new to civil missions. An investigation of the recommendations must be done, evaluating suitability for diﬀerent scenarios. Throughput and area consumption must be taken in to consideration as well as the level of security. A solution that is good enough in both these areas needs to be found. The goal is to construct a recommendation regarding architecture for the algorithm as well as key management. A hardware accelerating mechanism (IP core) will be developed to demonstrate the impact on area consumption when implemented, latency and throughput. The goal is also to take in to consideration the implementation weaknesses and side channels. The side channel of special interest is timing leakage and how to protect the implementation from timing attacks. To achieve this goal the following questions will be answered:

1. When using AES-CTR+GMAC, what are the beneﬁts and disadvantages when using resource sharing of the encryption core between the telecommand cryptography unit and the telemetry cryptography unit?

2. Is it possible to implement AES-CTR+GMAC so that the encryption time is not dependent on the value of the key and therefore safe against timing attacks? 4 1 Introduction

3. How should the keys be stored and accessed on a space mission to utilize ﬂexibility as well as to not be accessible from other processes on the chip?

1.3 Related Work

Multiple implementations has been done to improve the performance and area consumption on the FPGA board. These implementations are done using different cryptographic algorithms, both for spacecraft implementations and general implementations. For example work has been done on implementing the CMAC algorithm on FPGA and trying to enhance the algorithm by utilizing resources better and a hardware implementation is proposed. The CMAC algorithm is described further in chapter 2.4. When using state machines to sequentially use the AES core to generate sub keys followed by encryption and CMAC generation this implementation uses 1209 CLB (control logic block) slices and a throughput of 2025,56 Mbps on a Xilinx Virtex II [19]. A CLB slice is a building block in the FPGA used to measure area consumption. Also the HMAC algorithm has been implemented using SHA-256. The HMAC algorithm is described further in section 2.3. For example when using SHA-256 in the HMAC algorithm this implementation uses 6832 CLB slices and a throughput of 4130 Mbps on a Xilinx Virtex II in one study specifically targeting SHA-256 [18]. In another study targeting all SHA-2 the implementation of SHA-256 in the HMAC algorithm this implementation uses 3608 CLB slices and a throughput of 234,97 Mbps on a Xilinx Virtex II [12]. When implementing the AES algorithm a specific part with impact on the hardware resources is the s-box which can either be implemented as a look-up table or calculated using multiplication in the Galois Field GF(28). Since there is a risk with having data in memory, due to SEE (single event effects) caused by radiation which can alter the data in the memory cell, there is a trade off in performance that is relevant for spacecraft implementations [20]. An investigation of the security against cache-timing attacks was done on the AES algorithm. The work describes how the attack is accomplished and how one could try to secure the implementation from such attacks. Specifically when implementing the AES algorithm in software it is known that the encryption time is dependent on which bits that are set or not set in the key, this is described further in section 2.8.1 [7].

1.4 Delimitations

The concept of spacecraft communication is very broad. Deliminations that has been made during the thesis work are hereafter stated and motivated. The CCSDS recommends many algorithms, and speciﬁes explicitly the AES- GCM algorithm for purposes where both encryption and authentication is used. In those cases where only authentication is used, only the authentication part of the algorithm is to be used. A brief comparison is made with the other algorithms but AES-GCM is the only one implemented. The reason for this delimination is 1.4 Delimitations 5 that it is the algorithm recommended from CCSDS in the baseline implementation. Also another implementation for comparison is not applicable in the thesis work time frame. When implementing the AES algorithm in software all key lengths were included to get an insight in how the key length were aﬀecting the performance. When implementing the algorithm in hardware the only key length used is 256 bit. The reason for this is since it is the most secure during a longer time period as well as it is the one being recommended for future missions from the CCSDS. The key management handled in this thesis only addresses the local key management. The management of how the keys are being sent, protecting against resend attacks by using either timestamps or a nonce is not included. To include that would have been too much time consuming.

2 Cryptographic Algorithms

CCSDS has recommended several algorithms suited for different requirements on the specific mission. The level of confidentiality and authentication/integrity needed may differ as well as the amount of hardware available, making one algorithm not suitable for every missions. The algorithm recommendation is that whenever using encryption on the space mission, AES using counter mode should be used, AES-CTR. Whenever authenticated encryption is used, the AES using galois counter mode should be used, AES-CTR+GMAC or also called AES-GCM. If AES-CTR is used for TM the recommendation for the authentication algorithm is CMAC for TC. If AES-GCM is used for TM the recommendation is GMAC for TC, since they use the same algorithms for creating the MAC. If only authentication is required for the mission, the algorithm recommended is HMAC [1]. Baseline recommendations for operational use on the data link layer is CMAC authentication algorithm to be used for TC and AES-GCM authenticated encryption algorithm to be used for TM [2]. The reason for this is that the baseline recommendation for TC is to only use authentication and not authenticated encryption, therefore recommending CMAC.

2.1 Message Authentication Code

For message authentication a Message Authentication Code (MAC) is typically used, with the intention to validate that the encrypted data has not been ma- nipulated. The MAC is a function of the message which is calculated with the encrypted data and the key, therefore a mismatch would be detected [24].

7 8 2 Cryptographic Algorithms

2.2 Galois Field

Finite fields are used in the AES algorithm and will here be described. The galois field (GF) is a form of finite field which is a subset of fields. Fields are a funda- mental element of abstract algebra which will not be described in detail in this thesis. Briefly explained, fields is a subset of the class rings and rings is a subset of the class groups. Finite field arithmetic is used both in the AES algorithm itself and in the GHASH operation of AES-GCM.

Figure 2.1: The elements of abstract algebra

A field is basically a set of elements where addition, subtraction, multiplication and division all can be done without leaving the set [24]. Division is defined 1 such that for every value a in the field except for 0 there is an element a− in the field that when these two are multiplied the result is 1.

One criteria of a finite field is that it has an order of a power of a prime pn where n is an integer, this is written as GF(pn). The simplest one is GF(2), where addition is equivalent to a logical XOR and multiplication is equivalent to a logical AND. One of the operations of AES is constructed to perform addition, multiplication and division over the finite field GF(28). When using operations in the finite field an irreducible polynomial is used. A polynomial a(x) is irreducible if it is not possible to factor with any smaller polynomial with binary coefficients other than itself or 1, meaning that gcd[a(x),b(x)] = 1. GF(28) uses the irreducible polynomial

x8 + x4 + x3 + x + 1.

The elements of GF(28) is described as polynomials with binary coeﬃciants. 2.2 Galois Field 9

An example of the arithmetics uses the two following polynomials that are also used in [24].

f (x) = x6 + x4 + x2 + x + 1 g(x) = x7 + x + 1

Then

f (x) + g(x) = x6 + x4 + x2 + x + 1 + x7 + x + 1 = x7 + x6 + x4 + x2 and

f (x) g(x) = x13 + x11 + x9 + x8 + x7 × +x7 + x5 + x3 + x2 + x +x6 + x4 + x2 + x + 1 = x13 + x11 + x9 + x8 + x6 + x5 + x4 + x3 + 1 = x13 + x11 + x9 + x8 + x6 + x5 + x4 + x3 + 1 (mod x8 + x4 + x3 + x + 1) = x7 + x6 + 1

The implementation technique used for multiplication is based on the obser- vation that x8 mod m(x) = [m(x) x8] = (x4 + x3 + x + 1). − To explain this technique another polynomial is used

7 6 5 4 3 2 f (x) = b7x + b6x + b5x + b4x + b3x + b2x + b1x + b0.

If this is multiplied by x, it gives

x f (x) = (b x8 + b x7 + b x6 + b x5 + b x4 + b x3 + b x2 + b x) mod m(x) × 7 6 5 4 3 2 1 0

If b7 = 0 the degree of the resulting polynomial is less than 8 and therefore it is in reduced form. If instead b7 = 1 the modulo reduction is necessary, giving

x f (x) = (b x7 + b x6 + b x5 + b x4 + b x3 + b x2 + b x) + (x4 + x3 + x + 1) × 6 5 4 3 2 1 0 In computers these polynomials is usually described using bit-vectors instead of as polynomials. Multiplication is then represented by ( (b b b b b b b 0) if b = 0 x f (x) = 6 5 4 3 2 1 0 7 × (b6b5b4b3b2b1b00) (00011011) if b7 = 1 ⊕ When using bit-vectors the previous example for addition is represented by (01010111) (10000011) = (11010100) and the previous example for multiplication is represented⊕ by several iterations of the technique just described. 10 2 Cryptographic Algorithms

(01010111) (10000011) = (01010111) [(00000001) (00000010) (10000000)] × × ⊕ ⊕ = (01010111) (10101110) (00111000) = (11000001) ⊕ ⊕ The GHASH function in AES-GCM uses the ﬁnite ﬁeld GF(2128) which instead uses the irreducible polynomial

x128 + x7 + x2 + x + 1.

which has similar arithmetics as described for GF(28) above.

2.3 Hash-based Message Autentication Code

Hash-based Message Autentication Code (HMAC) is basically an algorithm deriving a MAC from a cryptographic hash function. Since hash functions themself do not rely on a secret key and are not designed for it, they can not be used directly as a MAC. It is very easy to replace the hash function in HMAC with another one if desired [24].

The following parameters is used in this function

• B — block size in bytes

• opad — outher pad, the byte 0x5c repeated B times

• ipad — inner pad, the byte 0x36 repeated B times

• K — secret shared key

• K0 — key after pre-processing to form B bytes • H — approved hash function

When using HMAC to calculate the MAC over the data "message" the following function is used

HMAC(K, message) = H [(K opad ) H [(K ipad ) message]] 0 ⊕ k 0 ⊕ k

It is also possible to precompute the (K0 opad) and (K0 ipad) functions since they only need to be computed initially⊕ and every time⊕ the key changes. Therefore they can replace the initialization vector in the hash function [24].

2.4 Cipher-based Message Authentication Code

Cipher-based Message Authentication Code (CMAC) is an algorithm for authentication, deriving a MAC from the AES function. The operation of CMAC is deﬁned as follows When the message is an integer multiple n of the cipher block length 128 bits the message is divided in to n blocks (M1,M2,...,Mn). The algorithm uses 2.5 Advanced Encryption Standard 11

a 256-bit encryption key K and a 128-bit constant K1 when using the AES-256 algorithm [24]. When T is the MAC, E is the encryption function, AES-256, and MSB is the most signiﬁcant bits, the CMAC is calculated as follows

C1 = E (K,M1) C = E (K, [M C ]) 2 2 ⊕ 1 C = E (K, [M C ]) 3 3 ⊕ 2 ...

Cn = E (K, [Mn Cn 1 K1]) ⊕ − ⊕ T = MSBT len (Cn) If the message is not an integer multiple n of the cipher block length, the final block is padded with a 1 and as many 0s as necessary so that the final block is 128 bits long. Besides this the key K1 is replaced by the key K2 (which is also an 128-bit constant) [24]. The two keys K1 and K2 are derived as follows where the multiplication is done over the finite field GF(2128). In the first of the following equations the 0b indicates that there is b consecutive 0s. L = E K, 0b

K1 = L · x 2 K2 = L · x = (L · x)· x

Since CMAC is based on the AES algorithm, it can also be seen as an operation mode [24]. The AES algorithm and operation modes will be described further in chapter 2.5-2.7.

2.5 Advanced Encryption Standard

Advanced Encryption Standard (AES) is a symmetric block cipher. The cipher takes a plaintext block size of 16 bytes. The key length can be 16, 24 or 32 bytes. The algorithm is referred to as AES-128, AES-192 or AES-256 depending on the key length. The input to the encryption/decryption algorithms is always a single 128-bit block [24]. The recommendation from CCSDS is to use AES-256 when applying encryption on all missions being planned for the future. Since AES is a symmetric block cipher it can be used with different operation modes. The operation modes recommended by CCSDS are counter mode (CTR) for regular encryption and galois counter mode (GCM) for authenticated encryption [6]. These modes will be described further in section 2.6 and 2.7. AES operates through four different stages, substitute bytes, shift rows, mix columns and add round key. These stages are repeated for a number of rounds, 10 rounds for 128 bit key, 12 rounds for 192 bit key and 14 rounds for 256 bit key. The key is expanded in a key expansion function to generate different keys 12 2 Cryptographic Algorithms for each round. In figure 2.2 the keys are described using bytes, where 16 bytes represents 128 bits.

Figure 2.2: The encryption process for AES

In the last round the mix columns operation is not performed and in round 2.6 Counter Mode 13 zero the only operation used is the adding of the round key. In [7] this process is described such as that there is two s-box tables, one regular S and one inverted S0 which is combined in four tables T0,T1,T2,T3 which are deﬁned by

T0[b] = (S0[b],S[b],S[b],S[b] S0[b]) T [b] = (S[b] S [b],S [b],S[b⊕],S[b]) 1 ⊕ 0 0 T2[b] = (S[b],S[b] S0[b],S0[b],S[b]) T [b] = (S[b],S[b],S⊕ [b] S [b],S [b]) 3 ⊕ 0 0 The author of [7] continues to describe that AES then works with two arrays, input x and output y. The ﬁrst one is initialized to the key and the second one is initialized to the plaintext which is XOR’d with the key. The input x can be viewed as 4-byte arrays x0, x1, x2 and x3. After computing e = (S[x3[1]] 1,S[x3[2]],S[x3[3]],S[x3[0]]), one can replace (x , x , x , x ) with (e x , e x ⊕x , e x x x , e x x x x ). The 0 1 2 3 ⊕ 0 ⊕ 0 ⊕ 1 ⊕ 0 ⊕ 1 ⊕ 2 ⊕ 0 ⊕ 1 ⊕ 2 ⊕ 3 ouput y can be viewed as (y0, y1, y2, y3) and this can be replaced by

( T0 [y0[0]] T1 [y1[1]] T2 [y2[2]] T3 [y3[3]] x0, T [y [0]] ⊕T [y [1]] ⊕T [y [2]] ⊕T [y [3]] ⊕x , 0 1 ⊕ 1 2 ⊕ 2 3 ⊕ 3 0 ⊕ 1 T0 [y2[0]] T1 [y3[1]] T2 [y0[2]] T3 [y1[3]] x2, T [y [0]]⊕ T [y [1]]⊕ T [y [2]]⊕ T [y [3]]⊕ x ) 0 3 ⊕ 1 0 ⊕ 2 1 ⊕ 3 2 ⊕ 3 The author of [7] describes further that AES then modifies x again by calculating e, by using 2 instead of 1, which gives a new value for y. After that it modifies x again by⊕ calculating e⊕, but using 4, which gives yet another value for y. This pattern repeats 10 times. The constants⊕ used for these modifications are 1, 2, 4, 8, 16, 32, 64, 128, 27 and 54, the round constants. On the tenth round, the modification of y uses (S[],S[],S[],S[]) instead of T0[] T1[] T2[] T3[]. The resulting value of y is the ciphertext. This process is not dependent⊕ ⊕ on⊕ the plaintext.

2.6 Counter Mode

Counter mode (CTR) is a stream cipher mode, meaning that the input does not have to be a block of 128 bits. Since it is a stream cipher mode a random and unique nonce must be supplied. If the uniqueness of the nonce can be guaranteed the CTR mode is a good choice since it is easy to implement. The encryption and decryption functions are identical so there is only need to implement one [14]. The advantages of CTR mode is that it is eﬃcient to implement in hardware since it is not a chaining mode. This means that encryption or decryption can be done in parallel for several blocks of plaintext or ciphertext at the same time. Due to this there is not as much constraint on the throughput as for the chaining modes [24].

The encryption and decryption can be expressed as follows 14 2 Cryptographic Algorithms

Oj = CIPHK Tj for j = 1, 2 . . . n C = P O for j = 1, 2 . . . n 1 j j ⊕ j − C = P MSB (O ) n∗ n∗ ⊕ u n Oj = CIPHK Tj for j = 1, 2 . . . n P = C O for j = 1, 2 . . . n 1 j j ⊕ j − P = C MSB (O ) n∗ n∗ ⊕ u n where T1,T2 ...Tn are the counters, P is the plaintext, C is the ciphertext and u is the size of the last block that might be partial. The most signiﬁcant u bits of the last block are used for the ﬁnal exclusive-OR and the rest of the bits of the block are discarded [8].

2.7 Galois Counter Mode/Galois Message Authentication Code

Galois Counter Mode (GCM) is an operation mode for AES that also provides authentication added to the encryption. When it is used without the encryption function to only provide the Message Authentication Code (MAC) it is called Galois Message Authentication Code (GMAC). The function have three inputs, a plaintext denoted P , additional authenticated data denoted A and an initialization vector denoted IV . These inputs have restrictments regarding bitlength, stated below. The bitlengths shall also be multiples of bytes [9].

len(P ) 239 256 ≤ − len(A) 264 1 ≤ − 1 len(IV ) 264 1 ≤ ≤ − The function have two outputs, a ciphertext denoted C and an authentication tag denoted T . When decrypting there is one output, the plaintext denoted P or an error code. For encrypting the message a special variant of the CTR module is used, where the counter is incremented with 32. The authentication is a hash function featuring a multiplication of a 128-bit part of the input bitstring, X, and a fixed parameter within a binary galois field [9]. This fixed parameter is the hash subkey H, mentioned below. The binary galois field used is the finite field GF(2128). There is two functions inside AES-GCM, GHASH and GCTR [24].

• IV — initialization vector

• J0 — pre-counter block generated from IV

• P — plaintext

• A — additional authenticated data 2.7 Galois Counter Mode/Galois Message Authentication Code 15

• C — ciphertext

• T — authentication tag

• H — hash subkey

• X — input bit string

• Y — output bit string

• ICB — initial counter block

• CB — counter block

• K — secret key

Figure 2.3: The GHASH function

The GHASH function is basically a multiplication between two 128-bit vectors in the galois field. The galois field used for GHASH is GF(2128), which is defined by the polynomial x128 + x7 + x2 + x + 1. 16 2 Cryptographic Algorithms

Figure 2.4: The GCTR function

The GCTR function is the same as the AES-CTR function mentioned in the previous section about AES. K is the key used for the algorithm and CIPHK is the AES-CTR used with the key, K.

Figure 2.5: The Galois/Counter Mode 2.8 Implementation weaknesses 17

2.8 Implementation weaknesses

A security implementation could have weaknesses that depend on the implementation rather than the algorithm itself. These weaknesses could be used for an attack that is called a side channel attack. To design in a way that protects against side channel attacks can be very diﬃcult, since new side channels can be detected as time goes by [22]. A few examples of information that could leak is mentioned below.

• Timing • Power consumption

• Magnetic Fields and interference

For example the use of power consumption for a side channel attack could be very successful when the attacker have access to the chip or a smart card if such is in use, this is not a likely attack to be performed against a spacecraft due to the large distance and remoteness. The same goes for magnetic ﬁelds and interference, these are not likely to be used for an attack due to the remoteness of the chip.

2.8.1 Timing Attacks Cache-timing attacks on a cryptography algorithm uses timing to figure out the key. If one knows or can guess the plaintext and the encryption time varies with the key, this kind of attack could be successful. The reason for this leakage of information in the AES algorithm is the usage of s-boxes, which accesses input dependent adresses in a memory [7]. In the beginning of the algorithm there is the table look-up T0[k[0] n[0]], where n is the plaintext and k is the key. The equation for this can be seen⊕ in section 2.5. This leaks information about k[0] n[0] and one can figure out the exact value of k[0] from the AES distibution as a⊕ function of n[0]. This is also true for k[1] n[1] and k[2] n[2] etc [7]. For example⊕ when using⊕ AES-256 the attacker could watch several plaintext messages and total the time for all the messages up to n[13] and also figure out that the maximum time is when n[13] is 147. If the attacker also experiments with known keys on a computer with the same software and the same CPU one can figure out that the maximum time is when k[13] n[13] = 8 and conclude that k[13] is 147 8 = 155 [7]. ⊕ This approach⊕ of attack has been performed and proven that it can be successful if the execution time varies with the key. The fact that the number of set bits in the key affects timing in software implementations and therefore could leak information about the key is thereby known.

3 Cryptography usage in Satellite Communication

The space data link security protocol, SDLS, is a data processing method for space missions that need to apply authentication and/or conﬁdentiality to the contents of transfer frames over a space link, using the space data link protocol [2].

The two space data link protocols used for transferring frames are telecommand (TC) and telemetry (TM). When applying the SDLS protocol on these transfer frames the encrypted data is included within the frame, see ﬁgure 3.1.

Figure 3.1: Transfer frame with and without the SDLS protocol

The SDLS protocol is implemented within the data link protocol sublayer, which is within the data link layer in the OSI model, see ﬁgure 3.2.

19 20 3 Cryptography usage in Satellite Communication

Figure 3.2: The location of the SDLS protocol within ISO/OSI layers

The SDLS protocol is standardized to be usable for all the recommended security algorithms that are suitable for diﬀerent scenarios. If the algorithm requires an initialization vector/nonce (IV) or padding this is supported and if not, this can be disregarded. The security header is mandatory, including support for IVs or sequence num- bers to protect against replay attacks, and padding if necessary, see ﬁgure 3.3.

Figure 3.3: The security header

The security trailer is used when authentication is used, containing the MAC. See ﬁgure 3.4. 21

Figure 3.4: The security trailer

The security parameter index (SPI) is a transmittable value used to uniquely identify a security association (SA). The SA is a one-way cryptographic session where all frames that shares the same SA is called a secure channel. The SPI is considered a table index key to an SA database that store information about each SA. The SA must be associated to a key by both sender and receiver and activated before used on the channel. SAs can either be preloaded before launch or created dynamically as needed. The mechanism responsible for switching between SAs is located in the application layer [2].

The SDLS protocol is applied on the transfer frame by adding a function called ApplySecurity to the protocol entity for TM and TC, which takes a part of the frame as input and outputs the ciphertext/plaintext and the MAC.

Figure 3.5: The relationship between the protocols

ApplySecurity takes a part of the transfer frame as payload to use as the input according to what is seen in ﬁgures 3.6 and 3.7. Only the frame data is encrypted, while the MAC is calculated with the frame data and all the headers. 22 3 Cryptography usage in Satellite Communication

Figure 3.6: The TM transfer frame with the SDLS protocol

Figure 3.7: The TC transfer frame with the SDLS protocol

The ApplySecurity function is the one that is targeted in this thesis.

3.1 Security Association

The Security Associations, SAs, can either be preloaded before launch or created dynamically. Prior to start of the operation of the SDLS protocol the sending and the receiving side shall initialize a common SA database containing the parameters being used for the moment. Synchronization of the parameters in the database should be maintained during operation. When using an SA, for starters both the sender and receiver side shall create the SA, associate it to a key and to a GVCID/GMAP_ID. SAs can also be loaded statically, as mentioned before. After being loaded, or created, the connection between the SA and the GVCID/GMAP_ID is static. The GVCID/GMAP_ID is then used by the ApplySecurity function to associate the frames to the correct SA. On the sending side only one SA can be used at a time for a particular channel and they shall not be used for frames with only idle data (OID). 3.1 Security Association 23

3.1.1 General Parameters

Parameter Purpose GVCID Shall contain ID for global virtual channel. Consists of master channel ID and virtual channel ID. GMAP_ID Shall contain ID for global multiplier access point. Consists of GVCID or TC MAP ID. Only applicable for TC frames using segment headers. SPI Shall contain an index specifying the SA belonging to the frame. Each SA has unique SPI. SA_service_type Shall specify authentication, encryption or authenticated encryption. SA_length_SN Shall specify the length of the sequence number field. SA_length_IV Shall specify the length of the initialization vector field. SA_length_PL Shall specify the length of the pad length field. SA_length_MAC Shall specify the length of the MAC field.

3.1.2 Encryption Parameters

Parameter Purpose SA_encryption_algorithm Shall indicate algorithm and mode. SA_encryption_key Shall indicate key or index that refer to the key. SA_initialization_vector Shall indicate present value of the initialization vector.

3.1.3 Authentication Parameters

Parameter Purpose SA_authentication_algorithm Shall indicate algorithm and mode. SA_authentication_key Shall indicate key or index that refer to the key. SA_authentication_mask Shall indicate bit mask used to get the payload from the frame. SA_sequence_number Shall indicate present value of the sequence number. SA_sequence_window Shall indicate the amount of deviation from received sequence number and expected sequence number that is acceptable. 24 3 Cryptography usage in Satellite Communication

3.2 Cryptographic Keys

There is a draft version from CCSDS with a recommendation on key management for symmetric keys. This report is stating that the future recommendation should be to only use two categories of keys, master keys and session keys [5]. Further the implementation of the key management is left to the developer to decide, there are no recommendations for that purpose.

3.2.1 Secret Keys vs. Public Keys Keys that are used for symmetric encryption are called secret keys and keys that are used for asymmetric encryption are called public keys. The recommendation for usage on space applications are symmetric encryption and therefore secret keys. The reason behind this recommendation is that the channels are highly asymmetric, the up-link is working on a speed of 10-64 Kbit/s where as the down- link supports speed up to 2 Gbit/s. Also the bandwidth is a precious resource, implying that traﬃc intensive protocols need to be avoided. Due to the potential enormous distances between the communicating parts, there is a substantial propagation delay, meaning that key management protocols that require round- trips or time stamps are not suitable. The fact that the location of the spacecrafts is remote means that no physical access is possible, and therefore keys can be stored - this nulliﬁes the advantages of asymmetric keys. Last but not least the computational resources and memory are limited, so complex operations should be avoided and key management should minimize the memory usage [4]. These arguments combined concludes that the use of secret keys in cryptosys- tems for spacecrafts is recommended.

3.2.2 Key Variants There are only two types of keys recommended to be used besides the initially shared secret, they are master keys and session keys. These are described more thoroughly below.

Master Keys The master keys should be used for authenticated encryption when uploading new session keys to the spacecraft. The master keys are also called key encryption keys. The use of one key should not exceed the cryptoperiod, i.e. the time a key should be used before replaced, and should only be used for one single purpose during its lifetime [5].

Session Keys The session keys should be used for authenticating, encrypting or applying authenticated encryption on the data being transported. The session keys are also called traﬃc protection keys. The use of session keys should not be to protect 3.2 Cryptographic Keys 25 other session keys, and they should only be used for one single purpose during its lifetime [5].

3.2.3 Key Hierarchy Secret keys are handled in a hierarchial way. There are three levels of keys to be used during a mission: master keys, key encryption keys and traffic protection keys. These are shown in figure 3.8. The master keys are the initial shared secret, the key encryption keys are the ones mentioned in section 3.2.2 as master keys and traffic protection keys are the session keys. One way is to use master keys to derive key encryption keys to encrypt traffic protection keys, another way is to use key encryption keys to derive traffic protection keys [4].

Figure 3.8: The hierarchy of the keys

Master Keys The initially shared secret and what is allowing the secure sharing of lower level keys are here called master keys. This is the top level of the hierarchy and is always distributed manually, i.e. stored in memory before launch [4]. These keys are not mentioned in section 3.2.2 but is the initial shared secret used to derive the keys being used during mission.

Key Encryption Keys This level can be several levels in the hierarchy where a higher level key encryption key can be used to secure a lower level key encryption key for example. 26 3 Cryptography usage in Satellite Communication

These are the keys used for encrypting of the lower level keys. This is the key variant described as master keys in 3.2.2.

Trafﬁc Protection Keys

These are the keys being used to secure the channel and provide encryption and authentication. This is the lowest level of the key hierarchy and are generally not generated but negotiated using a key negotiation protocol [4]. This is also known as session keys.

3.3 Security of Keys

An important aspect of the keys is that they are generated from a random value. The measurement to randomness is called entropy. The deﬁnition of entropy of a variable X is shown below:

X H(X) = P (X = x) log2(P (X = x)) (3.1) − x

Here P (X = x) is the probability that the value of X is x. The value of the entropy measure the uncertainty of values. If one knows the value of several bits, the entropy decreases. A true random word has maximum entropy, for example a random key of 256 bits has 256 bits of entropy. Instead of using a real random value one could use a pseudorandom value, which is not random per se, but generated from an algorithm. When using such a value it must be made sure that the generation of these pseudorandom value generates a strong value. If a pseudorandom generator is not speciﬁcally stated as strong enough for generating random values for cryptography, they should not be used for this purpose.

3.3.1 Master Key Generation

The most secure way to generate random values to use for cryptography is to use a block cipher in counter mode, for example the AES-CTR with a 256 bit key [22]. When there is a need for new random values a number of bits is requested from the block cipher. The output from the block cipher is the random values that has been requested. These random values will be used as keys. There is also an additional output of 256 bits that will be used as a key to generate new random values when needed. Every time a new request for random values is given, the IV counter should still keep counting up. The maximum size of the output for each request with a single key is 220 bytes to make it harder to ﬁgure out the statistical deviation [22]. This process of generation of random values is as follows. The process is a generator G, which has the values of a key K, and a counter IV. 3.4 Key Lifecycle 27

Initialization

The ﬁrst step is to initialize the process and indicate that it has not been seeded. This is done by setting both the key and the IV to zero.

Reseed

When starting up the process a seed is needed. A seed is a random value from in example the operating system, this value could be saved to be able to generate the exact random values again when fault tracing the simulation. This seed is then used to generate a new key to use for generating new random values. To make sure that the new key is not easy to ﬁgure out, a hash function should be used for the value of the initial key and the seed. The IV is then counted up by one.

Generate Blocks

This function is an internal function and should not be reachable outside the process. It takes as input the state of the generator, i.e. the value of the key and the counter, and the number of 128 bit blocks of random values that is requested. This must make sure that the counter is not zero, which would mean that the generator has not been seeded, and therefore should not be used. Then the AES- CTR is used to generate the amount of requested random data.

Generate Random Data

This function uses the previous function to generate the random data, it takes as input the state of the generator and the number of random values that is requested which does not need to be an integer value of 128 bit blocks. The output is then the random values that is requested by the generator.

3.4 Key Lifecycle

The life of a key is shown in ﬁgure 3.9 and a key always begin in the pre-activation state and end in the destroyed state. Each key is only associated with one state at a time [3].

Figure 3.9: The lifecycle of each key 28 3 Cryptography usage in Satellite Communication

3.5 Key Management

The key management should at a minimum handle the following services: key activation, key deactivation, key destruction, key veriﬁcation and over-the-air- rekeying (OTAR) [3]. The use of a key is limited to a cryptoperiod which is decided based on the complexity of attacking the algorithm. NIST has a recommendation that a cryptoperiod of 1 day is suitable for large volumes of data and a cryptoperiod of 1 month is suitable for small volumes of data. This means that the payload sent by TM shall have a cryptoperiod of 1 day and housekeeping sent by TM as well as TC shall have a cryptoperiod of 1 month [13]. Housekeeping is the data being sent through TM that is not the payload, but the status of the spacecraft itself and its components. 4 Implementation

The method used to perform this thesis work was to study the existing recommendations of security protocols and cryptographic algorithms published by CCSDS. A brief evaluation of the recommendations were done with the help of literature and published articles regarding the application of security on spacecrafts and satellites. Also an investigation of key handling and key management were done with the aim to conclude a recommended approach for an implementation.

4.1 Key management

The keys have to be stored and accessed by the cryptographic algorithm. The cryptoperiod for TM as well as TC channels are different and a specific number of keys is needed for each specific purpose on each mission. The cryptoperiod for TC is 1 month and the cryptoperiod for TM is 1 day. This means that there will have to be a change in key with this frequency. Either all these keys can be preloaded in memory on the spacecraft or they can be sent to the spacecraft during the mission, called OTAR. If OTAR should be enabled, a key wrapping algorithm needs to be implemented. The interface for handling key management is recommended to be an AMBA bus master, connected to an AMBA bus and therefore it includes higher flexibility in storage of the keys. The AMBA bus is a bus architecture that is used widely in microcontrollers. When adding a bus master interface to the core it is possible to read and write from predisposed memory slots. The SPI in the frame is an index refering to the memory slot of a specific key and therefore a mapping from an SPI index must be done to the memory slots reachable from the AMBA bus.

29 30 4 Implementation

4.1.1 Key storage

The keys must be stored in a secure manner with no possible access from other parts than intended. If the mission is using only preloaded keys they should be stored in Read Only Memory (ROM) where they are secure from being overwritten or damaged by Single Event Effects (SEE). A key is 256 bits (32 bytes) long and to store keys for TC to use for 10 years the memory required is 3840 bytes (3,84kB), the equivalent for TM is 116800 bytes (116,8kB). The component se- lection is not in the scope of the thesis but the storage is easy realized using for example an 128kB ROM memory which is a size of memory commonly used in the space industry. Therefore it has a good feasibility for key storing purpose on a spacecraft. The size of memory used is also scalable for different length of scenarios and how many keys needs to be stored. When OTAR should be available, the storage needs to be handled in RAM instead, which has the benefit of less memory storage since the old keys can be overwritten.

4.1.2 Access of key storage

The access of the keys should be handled via a bus interface, preferably the AMBA bus which is widely used on spacecraft data systems. The access via AMBA bus interface gives the user of the IP core free hands on where to store the keys since the memory address can easily be changed in the core.

4.2 Algorithm

The algorithm recommended by CCSDS is AES-CTR+GMAC, also called AES- GCM, and therefore this is the algorithm implemented. The beneﬁts of this algorithm in comparison with HMAC and CMAC is that when using authenticated encryption both the AES-CTR and the GMAC is used. It is therefore beneﬁcial to use GMAC for pure authentication on the same mission since the functionality is already implemented. When comparing GMAC with CMAC for example it is shown that GMAC uses almost twice the size of code in software [25].

4.3 Architecture

An architecture design is investigated. Different approaches of implementing the algorithm are evaluated based upon area consumption and throughput etc. A comparison of shared resources for authenticated encryption and authentication versus multiple resources is also done, with the aspect of the same criteria. The architecture is chosen to give flexibility to where the keys and security association parameters are stored and handled in a higher level. In figure 4.1 an architecture of the desired IP core is shown. Since the OTAR has not been implemented it is still unsure whether to implement it in the controller or as a separate block. 4.3 Architecture 31

Figure 4.1: The architecture for desired IP core

In this thesis work only part of this architecture were implemented. The part used for telemetry were chosen to be implemented since the interface is easier to adjust and connect. The telecommand frames will vary in length and is not consistent when received, therefore more signals need to be taken in to consideration. The telemetry frame is consistent in length and is easier to interface to the existing core.

Figure 4.2: The architecture implemented in hardware

Looking at the existing core, the intended location for the new core is to connect it just before the All Frame Generation, shown in ﬁgure 4.3. 32 4 Implementation

Figure 4.3: The telemetry IP core [16]

4.4 Software implementation

The chosen algorithm has been implemented in software as a proof-of-concept solution using C-code. The algorithm is AES-GCM with varying key lengths. The key lengths are: 128 bits, 192 bits and 256 bits.

4.4.1 Initial testing of software implementation The initial testing of the algorithm were performed by ﬁrst testing all the individual parts of the algorithm based on the values presented in William Stalling’s book about cryptography [24]. After validating all parts of the algorithm, a number of test vectors were used to validate functionality. These test vectors were obtained from a list of vectors found on the NIST webpage, only a few of those were used [10]. The test vectors used is shown in Appendix A.

The test vectors were used to show that the algorithm works as intended with diﬀerent lengths of the header and the frame data.

4.4.2 Performance The C-code is compiled using RTEMS which is an open source real-time operating system. After the algorithm were compiled it were simulated using TSIM, a simulation tool for instruction-level simulation provided by Cobham Gaisler. The simulation tool emulates a LEON-based computer system. When using the simulation tool some performance values are collected when running the code on the emulated system. These include CPI (clocks per instruction) and CPU performance (MIPS) etc [11]. 4.5 Hardware implementation 33

The data used for simulating the algorithm is representing a frame to be sent from the telemetry core. This frame is of length 1115 bytes, where the ﬁrst 51 bytes are the header and the following 1042 bytes are the data to be encrypted. This gives a total of 1042 bytes as input to the encryption and 1093 bytes as input to the authentication. The rest of the 1115 bytes are the frame trailers not included in the operation, seen in ﬁgure 3.6 and 3.7 in section 3.

4.5 Hardware implementation

When the algorithm had been tested using software the implementation in VHDL started with the result from the software testing in mind. The implementation started with creating each part of the algorithm, testing functionality and putting together the complete function.

4.5.1 FPGA The area available on an FPGA is divided in to CLBs (control logic blocks). A CLB is containing a number of slices. Each slice contains look up tables (LUTs) and ﬂip ﬂops. The LUTs are what were compared when looking at the area utilization on the implementation. When designing for an FPGA the code written is in VHDL.

4.5.2 VHDL VHDL is a hardware description language, which is a short for Very High Speed Integration Circuit Hardware Description Language [23]. A synthesis tool then transform the written code in to hardware with the same functionality. The version of VHDL being used in this thesis is VHDL-93 which has fewer functionali- ties than newer versions. The language is parallell and not sequential as software languages are, meaning that code is executed when triggered by signals changing values and not in the order it is written. Usually each functionality is written as individual processes, having one separate process for an adder and one for a multiplier etc. When writing code in VHDL the code is written as an entity and as an architecture. The entity describes inputs and output of the code block and the architecture describes the behaviour of the entity.

Two-process method

Instead of writing the code with separate processes for each functionality, the complete code can be divided in to only two processes per entity, one combinational and one sequential. These two processes is shown in ﬁgure 4.4. When having numerous processes it is hard to follow the datapath since it is not executed in the order the code is written. When having only one combinational process this is easier since it behaves sequential rather than parallell. The ben- eﬁt of this approach is to generate more structured and readable code than the general approach. 34 4 Implementation

Figure 4.4: A generic two-process circuit

The implementation in this thesis were created using this two-process method.

4.5.3 Implementation The implementation of the code were done in several steps to improve the functionality, area consumption and throughput.

Implementation with no resource sharing in the algorithm The ﬁrst version is a direct conversion of the algorithm in software to the hardware implementation. Each part of the code was created in separate entities and tested individually as well as hierarchically. No consideration of resource sharing were done and the entire algorithm is performed in only one clock cycle.

Implementation with the two-process method approach The second version is a conversion of the ﬁrst version, converted in to the two- process method way of coding. This also made it easy to remove unwanted latches in the code as well as it created a more readable code where the datapath is not as hard to follow. It also includes resource sharing and improvement in the area consumption. One AES block is shared for all 128-bit blocks and each encryption takes 14 clock cycles. One 128-bit block is encrypted at a time parallell to the plaintext being inputted to the function.

Implementation adjusted to improve resource use and area consumption The third version is an improvement of the second version, reducing area consumption and parallelizing the functionality of the algorithm. Instead of storing 4.6 Testing and validation 35 entire frame before processing a register of 128-bits is used to store the input data before processing.

4.5.4 Simulation The simulation tool used is Mentor Modelsim which makes it possible to track the values of each signal and verify that the implementation model behaves in the intended way.

Testbench A testbench was created for simulation, which inputs 8-bit vectors with data every clock cycle to simulate the interface that the IP core will be using. The output of 8 bits per clock cycle are stored in a vector and compared to what the frame consisting of the ciphertext and the tag should be.

4.5.5 Synthesis The synthesis tool used is Synplify which compiles the code and converts it in to hardware. The FPGA targeted for synthesis is the Xilinx UltraScale XCKU040- 2FFVA1156E, the design is also synthesized targeting Microsemi RTG4 which is a radiation tolerant FPGA with stricter requirements checking for errors.

4.5.6 Initial testing of hardware implementation When testing the hardware implementation the tool Mentor Modelsim were used to simulate the functionality of the code. The initial testing of the algorithm were performed by ﬁrst testing all individual parts of the algorithm in the same manner as for the software implementation. After validating all parts of the algorithm a number of test vectors were used to validate functionality, these test vectors are a subset of the ones used for test of the software implementation. The purpose of this is to show that the algorithm works as intended with diﬀerent lengths of the header and the frame data.

4.5.7 Performance An initial test of the performance were done using the simulation tool. After the tests in Mentor Modelsim were performed the code was synthesized for an FPGA-board to test the utilization of the implementation.

4.6 Testing and validation

The diﬀerent parts of the algorithm were tested and validated individually using speciﬁcally created test benches to ease the fault searching during development. A complete test bench for the entire algorithm core was also created and the aim 36 4 Implementation was to implement it in the existing system in such a way that it was possible to test it with the existing test bench for the entire system. 5 Results and Discussion

The algorithm implemented is the AES-GCM with the interface for the telemetry core. The key length is 128, 192 and 256 bits for software implementation and 256 bits for hardware implementation.

5.1 Software implementation

The proof-of-concept solution created in C-code was tested using test vectors as well as for performance. The results of these testing are shown below.

5.1.1 Initial testing of software implementation The initial testing with test vectors shown in Appendix A shows that the algorithm works correctly in all cases.

5.1.2 Performance After simulating the use of authenticated encryption on the frame with a length of 1115 bytes the performance values were obtained from the program which are presented below.

AES-128 When using the algorithm with a key length of 128 bits the performance is an overall CPI of 1.94 and a CPU performance of 25.75 MIPS. Cycles : 11772 Instructions : 6063 Overall CPI : 1.94

37 38 5 Results and Discussion

CPU performance (50.0 MHz) : 25.75 MOPS (25.75 MIPS)

AES-192 When using the algorithm with a key length of 192 bits the performance is an overall CPI of 1.94 and a CPU performance of 25.83 MIPS. Cycles : 11737 Instructions : 6063 Overall CPI : 1.94

CPU performance (50.0 MHz) : 25.83 MOPS (25.83 MIPS)

AES-256 When using the algorithm with a key length of 256 bits the performance is an overall CPI of 1.94 and a CPU performance of 25.83 MIPS. Cycles : 11736 Instructions : 6063 Overall CPI : 1.94

CPU performance (50.0 MHz) : 25.83 MOPS (25.83 MIPS) This result indicates that there is not a significant difference in the encryption time with various length of the key. As described in chapter 2.8.1 it is known that the encryption time can vary depending on the key, especially on software implementations within a system that uses caching. The software implementation used here seems not to have such a dependence. While we have performed no explicit test for such a dependence during the development of the code, the variations due to key dependence should not be that large, because the variation between the different key lengths are so small, almost nonexistent. If different key lengths give basically the same execution times, then different keys at the same key length cannot differ too much either.

5.2 Hardware implementation

The implementation on the hardware is based on the implementation done in the software. This implementation were then adjusted to achieve more eﬀective code and more resource eﬃciency. The result from synthesis is presented through a few stages of the improvement process.

5.2.1 Implementation with no resource sharing in the algorithm The area consumption for the ﬁrst implementation is very large, especially when using long input data, synthesizing for a frame that is 1115 bytes long requires 5.2 Hardware implementation 39 more area consumption than the entire FPGA has to oﬀer. Instead it is synthesized with a shorter length of the frame, 218 bytes.

Figure 5.1: The frame representation for the version 1 implementation

Initial implementation of AES-GCM synthesis with 256 bit key, with encryption data length of 1336 bits and additional authentication data length of 408 bits. Resource Used Utilization ------LUTs 266310 97 % ------

Performance ------Execution Time 1 c.c. ------The reason for the massive area consumption is because the entire algorithm is completed in a single clock cycle. All parts of the algorithm are generated separately to achieve this and no resource sharing is applied. For example the key expansion algorithm generates the sub bytes function four times and the sub bytes function for every round is also generated multiple times at the same time that all the logic for every round is also generated at the same time. Each 128-bit input data generates 14 rounds that each generates an s-box table of its own.

5.2.2 Implementation with the two-process method approach and resource improvement After applying the two-process method of coding and adjusting the code to ﬁt with the interface it is intended to work in, the execution is no longer just one clock cycle. The input data to the core is 8 bits per clock cycle and the output from the core is also 8 bits per clock cycle. Additionally the code is better adjusted to synthesize without latches and translate the code well to hardware.

Resource Used Utilization ------BRAMs 5 0 % 40 5 Results and Discussion

Registers 53242 9 % LUTs 67615 24 % ------

Performance ------Execution Time 2290 c.c. Latency 1181 c.c. Throughput 8 bits/c.c. ------

5.2.3 Implementation adjusted to improve area consumption To improve the parallelization of the code and avoid large registers for storing the data in the algorithm a further improvement of the code was made. Buﬀers for incoming and outgoing data is added to store less data and reduce the look up tables and registers required. For example the complete frame is not stored before calculations begin, instead it starts calculation for each 128-bit block before the output of the encrypted frame begins. This reduces the latency considerably and therefore also the execution time. Resource Used Utilization ------BRAMs 5 0 % Registers 2390 0 % LUTs 10097 3 % ------

Performance ------Execution Time 1172 c.c. Latency 63 c.c. Throughput 8 bits/c.c. ------

5.2.4 Synthesis of individual parts of the algorithm Each diﬀerent part of the algorithm has been synthesized individually to improve the understanding of the area consumption for each part.

SubBytes The function for substitution of the bytes uses 512 look up tables in the FPGA, no memory and no registers. Resource Used ------5.2 Hardware implementation 41

BRAMs 0 Registers 0 LUTs 512 ------

ShiftRows

The function for shifting the bytes requires no look up tables, memory or registers. This is because the function translates to routing logic.

Resource Used ------BRAMs 0 Registers 0 LUTs 0 ------

MixColumns

The function for mixing the columns uses 130 look up tables, no memory and no registers.

Resource Used ------BRAMs 0 Registers 0 LUTs 130 ------

Key Expansion

The function for expanding the key uses 413 look up tables, no memory and no registers.

Resource Used ------BRAMs 0 Registers 0 LUTs 413 ------

AES-CTR

The complete AES-CTR function uses 914 look up tables, 4 memory cells and 514 registers. 42 5 Results and Discussion

Resource Used ------BRAMs 4 Registers 514 LUTs 914 ------

GHASH

The function for multiplication in the galois ﬁeld uses 7607 look up tables, no memory and 1556 registers.

Resource Used ------BRAMs 0 Registers 1556 LUTs 7607 ------

The AES-256 has a throughput of 14 clock cycles, or 9.14 bits per clock cycle.

5.3 Software vs Hardware

The most crucial aspect with this comparison is that from a security aspect an algorithm created in hardware is safer than one in software. The code is not accessible from other software routines and is completely separated from the system. Also the process does not use the same resources as other programs, making it more efficient. Furthermore, in the hardware implementation it is clear that the key does not have an impact on the encryption time, since the encryption time is constant with respect to both plaintext and key content. This ensures that attacks like the one described in chapter 2.8.1 are not possible on this implementation. When looking at the results from this thesis work the software implementation the CPU performance is 25.83 MIPS and takes 11736 cycles to complete. This is quite a long time to perform this operation. The implementation is not optimized so it is hard to compare with the synthesized version of the algorithm. But it is possible to say that there is a huge difference compared to the execution time of 1172 clock cycle in the synthesized version. In this version the resources are minimized and the input and output of the frames are also included. If looking at the implementation of the AES-CTR part of the AES-GCM separately the time it takes to complete on 128 bit block is 14 clock cycles, giving a throughput of 9.14 bits per clock cycle. If one would parallellize this operation by using more resources the throughput could be improved. But even with only one AES-CTR core for 128 bit blocks there is a significant difference from the software implementation. 5.4 CMAC vs GMAC 43

5.4 CMAC vs GMAC

When comparing GMAC to CMAC it is shown in previous research that a CMAC implementation uses 1822 CLB slices when implemented on an FPGA or even as low as 1209 CLB slices in one of the papers [19]. The GMAC implementation uses 9405 LUTs [17]. In this thesis work the GHASH function uses 7607 LUTs. Different FPGAs has different conversion for LUTs in to CLB slices, since the architecture is different. For example the Xilinx Ultrascale has 8 LUTs per CLB slice and the Xilinx Virex-II used in [19] has 2 LUTs per CLB slice. To compare the GMAC with the CMAC the CLB slices needs to be converted in to LUTs. 1209 and 1822 CLB slices on Virtex-II represents 2418 and 3644 LUTs respectively. These representations are not entirely correct since the slices also includes flip flops and other logic but the measurement is good enough to compare with. The fact that these designs are synthesized using different tools also means that they do not translate to hardware equally. Here it is shown that the CMAC uses between 2418 and 3644 LUTs depending on architectural solutions and that the GMAC uses 9405 LUTs. If one uses resource sharing of the AES-CTR+GMAC between the TM and the TC, the total area consumption should be close to the result in the final implementation. If not using the resource sharing there would need to be an additional core of the AES-CTR+GMAC and twice as much area consumption as in the result. If only using authentication there is a justification to have an additional core of CMAC if the core is not intended to be shared between them.

5.5 Resource sharing

The result from the synthesis shows that the AES-CTR part of the AES-GCM operation uses 914 LUTs per 128 bit parallell input. The execution time is 14 clock cycles. This gives a throughput of 9.14 bits per clock cycle when encrypting the plaintext. If adding another block making the operation handle a 256 bit parallell input the number of LUTs used would be 1828 and the throughput would be 18.28 bits per clock cycle. If the system has a frequency of 50 MHz this would be 457 Mbits/s or 914 Mbits/s. The core including the AES-CTR+GMAC algorithm consumes 10097 LUTs and 2390 registers, resource sharing would not make a major impact on this. If instead two cores would be needed the area consumption should be around the double of this. Having resource sharing is definitely a benefit when it comes to area consumption on an FPGA. But since all keys are only used for one single purpose it is diffi- cult to establish the safety levels for both TC and TM when having different keys. So that is a disadvantage when having resource sharing. Also the throughput is affected by resource sharing, especially since the security levels constantly needs to be updated. 44 5 Results and Discussion

5.6 Key management

Regarding key management the keys are by a first stage recommended to be stored before launch. More research needs to be done regarding how to man- age and implement the functionality of OTAR as well as creating and deleting SAs during missions. That means keys should be stored in ROM and should be accessed via the AMBA bus interface. This gives a flexibility when using this core for where the keys should be stored since there is a generic interface to the memory. The integration of the AMBA bus to the implementation is also easy since it includes an AMBA bus master component. Another benefit of the use of AMBA bus is the ability to use either internal or external memory on a separate bus, minimizing interference with other components and software. It is important to make sure that software does not have physical connection to the key storage and when using an external memory for instance, the FPGA developer does not have direct access to the stored keys which improves the security. 6 Conclusion and future work

6.1 Conclusion

In section 1.2 there are three questions raised. Based on the work done in this thesis these has been answered and the answers is stated below.

When using AES-CTR+GMAC, what are the beneﬁts and disadvantages when using resource sharing of the encryption core between the telecommand cryptography unit and the telemetry cryptography unit?

There is definitely a benefit in using resource sharing if it can be implemented in a way so that it can be useful. The difference in area consumption is quite large between having one shared core and two separate ones. The disadvantages is the impact on throughput as well as the added complexity in sharing safety levels on the same core.

Is it possible to implement AES-CTR+GMAC so that the encryption time is not dependent on the key and therefore safe against timing attacks?

Yes, when implementing the algorithm in hardware the encryption time is constant and not dependent on the key.

How should the keys be stored and accessed on a space mission to utilize ﬂexibility as well as to not be accessible from other processes on the chip?

The keys should be stored in ROM if there is no need for OTAR. The access to the ROM should be handled by an AMBA interface, further described in sections 4.1, 4.1.2 and 5.6.

45 46 6 Conclusion and future work

6.2 Future work

• To improve the safety against single event eﬀects (SEE) the s-box could be implemented as a function rather than in memory. The eﬀect in area consumption and complexity of such implementation could be investigated.

• The implementation of the GHASH function could be implemented diﬀer- ently to improve the area consumption on the FPGA. Instead of implementing it as a multiplication of 128-bits with 128-bits it can be parallelized and made more area consumption eﬃcient. • More work and investigation needs to be done on the OTAR and the management and security of such operations. Examine how the handling of the key life cycle should be managed in more detail. Also examine how protection against resend attacks should be done. Appendix

A Test vectors for software implementation

These test vectors are interpreted as such that the Key is used for encryption, IV is the value encrypted in AES-CTR, PT is the plaintext to be encrypted, AAD is the additional data, CT is the ciphertext and Tag is the MAC. Besides this the length of these vectors is described at the top of each pair of the vectors used.

A.1 AES-128

[Keylen = 128] [IVlen = 96] [PTlen = 0] [AADlen = 0] [Taglen = 128]

Key = 11754cd72aec309bf52f7687212e8957 IV = 3c819d9a9bed087615030b65 PT = AAD = CT = Tag = 250327c674aaf477aef2675748cf6971

Key = ca47248ac0b6f8372a97ac43508308ed IV = ffd2b598feabc9019262d2be PT = AAD = CT = Tag = 60d20404af527d248d893ae495707d1a

49 50 A Test vectors for software implementation

[Keylen = 128] [IVlen = 96] [PTlen = 0] [AADlen = 128] [Taglen = 128]

Key = 77be63708971c4e240d1cb79e8d77feb IV = e0e00f19fed7ba0136a797f3 PT = AAD = 7a43ec1d9c0a5a78a0b16533a6213cab CT = Tag = 209fcc8d3675ed938e9c7166709dd946

Key = 7680c5d3ca6154758e510f4d25b98820 IV = f8f105f9c3df4965780321f8 PT = AAD = c94c410194c765e3dcc7964379758ed3 CT = Tag = 94dca8edfcf90bb74b153c8d48a17930

[Keylen = 128] [IVlen = 96] [PTlen = 0] [AADlen = 160] [Taglen = 128]

Key = 2fb45e5b8f993a2bfebc4b15b533e0b4 IV = 5b05755f984d2b90f94b8027 PT = AAD = e85491b2202caf1d7dce03b97e09331c 32473941 CT = Tag = c75b7832b2a2d9bd827412b6ef5769db

Key = 952117048f77e276c2ef6580537c1403 IV = 070b8fb46a7ad52885be1b26 PT = AAD = 34b088f982818b5f07dabe2b62f9547f 4ed09912 CT = Tag = bedd4cf30fd7a4abc49bdcc3f3b248b1

[Keylen = 128] [IVlen = 96] [PTlen = 128] [AADlen = 0] A.1 AES-128 51

[Taglen = 128]

Key = 7fddb57453c241d03efbed3ac44e371c IV = ee283a3fc75575e33efd4887 PT = d5de42b461646c255c87bd2962d3b9a2 AAD = CT = 2ccda4a5415cb91e135c2a0f78c9b2fd Tag = b36d1df9b9d5e596f83e8b7f52971cb3

Key = ab72c77b97cb5fe9a382d9fe81ffdbed IV = 54cc7dc2c37ec006bcc6d1da PT = 007c5e5b3e59df24a7c355584fc1518d AAD = CT = 0e1bde206a07a9c2c1b65300f8c64997 Tag = 2b4401346697138c7a4891ee59867d0c

[Keylen = 128] [IVlen = 96] [PTlen = 128] [AADlen = 128] [Taglen = 128]

Key = c939cc13397c1d37de6ae0e1cb7c423c IV = b3d8cc017cbb89b39e0f67e2 PT = c3b3c41f113a31b73d9a5cd432103069 AAD = 24825602bd12a984e0092d3e448eda5f CT = 93fe7d9e9bfd10348a5606e5cafa7354 Tag = 0032a1dc85f1c9786925a2e71d8272dd

Key = 599eb65e6b2a2a7fcc40e51c4f6e3257 IV = d407301cfa29af8525981c17 PT = a6c9e0f248f07a3046ece12125666921 AAD = 10e72efe048648d40139477a2016f8ce CT = 1be9359a543fd7ec3c4bc6f3c9395e89 Tag = e2e9c07d4c3c10a6137ca433da42f9a8

[Keylen = 128] [IVlen = 96] [PTlen = 128] [AADlen = 160] [Taglen = 128]

Key = d4a22488f8dd1d5c6c19a7d6ca17964c IV = f3d5837f22ac1a0425e0d1d5 PT = 7b43016a16896497fb457be6d2a54122 AAD = f1c5d424b83f96c6ad8cb28ca0d20e47 52 A Test vectors for software implementation

5e023b5a CT = c2bd67eef5e95cac27e3b06e3031d0a8 Tag = f23eacf9d1cdf8737726c58648826e9c

Key = e8899345e4d89b76f7695ddf2a24bb3c IV = 9dfaeb5d73372ceb06ca7bbe PT = c2807e403e9babf645268c92bc9d1de6 AAD = fed0b45a9a7b07c6da5474907f5890e3 17e74a42 CT = 8e44bf07454255aa9e36eb34cdfd0036 Tag = 2f501e5249aa595a53e1985e90346a22

[Keylen = 128] [IVlen = 96] [PTlen = 104] [AADlen = 720] [Taglen = 128]

Key = e5b1e7a94e9e1fda0873571eec713429 IV = 5ddde829a81713346af8e5b7 PT = 850069e5ed768b5dc9ed7ad485 AAD = b0ce75da427fba93da6d3455b2b440a8 77599a6d8d6d2d66ee90b5cf9a33baaa 8329a9ffaac290e8e33f2af2548c2a8a 181b3d4d9f8fac860cc26b0d26b9cc53 bc9f405afa73605ebeb376f2d1d7fcb0 65bab92f20f295556ade CT = c211d9079d5562659db01e17d1 Tag = 884893fb035d3d7237d47c363de62bb3

Key = 1b96a8699f84058591f28590a5e63c0e IV = d437b28673240ddc63d22d2b PT = 802192b9c2d78e1df9ac223598 AAD = 0f985a66d350c153a4882d0a4fc6e1b8 b8450cd0825182358521b1be5fc73433 8af72a48170fde7512a8a92ac81d12e3 a7fdcf7d98933732a9893d92d9435fca ee6033b726d28f73c5f76fd6b93d13bc 8904d11cd4a713cd353f CT = 8c13cded61d08c1f2db878378e Tag = 43ee877c121d4a329e81e51d68a9d845

[Keylen = 128] [IVlen = 96] [PTlen = 256] [AADlen = 384] A.2 AES-192 53

[Taglen = 128]

Key = 48b7f337cdf9252687ecc760bd8ec184 IV = 3e894ebb16ce82a53c3e05b2 PT = bb2bac67a4709430c39c2eb9acfabc0d 456c80d30aa1734e57997d548a8f0603 AAD = 7d924cfd37b3d046a96eb5e132042405 c8731e06509787bbeb41f25827574649 5e884d69871f77634c584bb007312234 CT = d263228b8ce051f67e9baf1ce7df97d1 0cd5f3bc972362055130c7d13c3ab2e7 Tag = 71446737ca1fa92e6d026d7d2ed1aa9c

Key = 35a7eabe7de2d176e97cdb905c0b7f17 IV = 2fa0cfef89fd9849df559c98 PT = 08f23fc6fde45fe044cc2c397390bb36 2524bb16cfab7c548de89faf3ad98947 AAD = 314e0423ac429f43ed90d731fcb5bdc7 849595ee16553a1b7f91412bf98ac4cb 052ca91c62a33b3928ee2887ebc273b7 CT = cf040174f8e280d10aa65eb59db8bf3e 4e2a8aa01b1f320564314946b3749af2 Tag = 94f78c8ab96107437826050e1a89b9e2

A.2 AES-192

[Keylen = 192] [IVlen = 96] [PTlen = 0] [AADlen = 0] [Taglen = 128]

Key = aa740abfadcda779220d3b406c5d7ec0 9a77fe9d94104539 IV = ab2265b4c168955561f04315 PT = AAD = CT = Tag = f149e2b5f0adaa9842ca5f45b768a8fc

Key = 1bb1d6a3bfc748786f3951e43c18054b fc8ce6ab3dc3d398 IV = fea56a5ce5f7d4c81680195d PT = AAD = 54 A Test vectors for software implementation

CT = Tag = 0b0bc0768b02f126a29bcb144abc6e4b

[Keylen = 192] [IVlen = 96] [PTlen = 0] [AADlen = 128] [Taglen = 128]

Key = 41c5da8667ef725220ffe39ae0ac590a c9fca729ab60ada0 IV = 05ad13a5e2c2ab667e1a6fbc PT = AAD = 8b5c124bef6e2f0fe4d8c95cd5fa4cf1 CT = Tag = 204bdb1bd62154bf08922aaa54eed705

Key = aef760f0cb8811f4ab4a05faa35fe8b9 854ade548e040e7f IV = d5daedc1d4959a5d744bc5f2 PT = AAD = aea8ce76e3cf40d473f61a08d59e53f5 CT = Tag = 926c61def02ed30ed158e355ac5d5710

[Keylen = 192] [IVlen = 96] [PTlen = 0] [AADlen = 160] [Taglen = 128]

Key = 093ef7551ebbff8eb0c0a8a4a62b198f 0c2e838de10eeeee IV = e656e93930ed5210ba3f0322 PT = AAD = 3da22dacfd11b21b0a713157f60aec0c d22f1add CT = Tag = 1b2d2764573e20ae640bf29d48e5fe05

Key = 0863e6e0e9763a3021ed4945812becf2 7b8220d4b3297357 IV = adb4e4e629cf4a86540efe1e PT = AAD = 581424d633f3f969d1b4f835197a740a 695b2c3b A.2 AES-192 55

CT = Tag = 79475219e6349b68ac7127fb5511e920

[Keylen = 192] [IVlen = 96] [PTlen = 128] [AADlen = 0] [Taglen = 128]

Key = fbc0b4c56a714c83217b2d1bcadd2ed2 e9efb0dcac6cc19f IV = 5f4b43e811da9c470d6a9b01 PT = d2ae38c4375954835d75b8e4c2f9bbb4 AAD = CT = 69482957e6be5c54882d00314e0259cf Tag = 191e9f29bef63a26860c1e020a21137e

Key = 73c90f5d9b656b26e801f1efa6d31be5 39763677af6708e9 IV = b00a1df95bfe801b0b6644cc PT = 154c23d7ccdc5c064dd252510dc9c61c AAD = CT = 9450b5cadba412cbe47d2fa214ddb914 Tag = de48fd939ab87d5679045cfccf6cf146

[Keylen = 192] [IVlen = 96] [PTlen = 128] [AADlen = 128] [Taglen = 128]

Key = 6f44f52c2f62dae4e8684bd2bc7d16ee 7c557330305a790d IV = 9ae35825d7c7edc9a39a0732 PT = 37222d30895eb95884bbbbaee4d9cae1 AAD = 1b4236b846fc2a0f782881ba48a067e9 CT = a54b5da33fc1196a8ef31a5321bfcaeb Tag = 1c198086450ae1834dd6c2636796bce2

Key = a3bf9528a653fefa24722cd14ad2ab40 4b2a9c331043246c IV = e73189e7a0a78a62223139b5 PT = 684fa5d0de7252e14e968a547f6ae52e AAD = f583e7ea9845476026e0ba24b53fda85 CT = 2e0cb7ed444acebf4dff3963ce7cdcfc Tag = ef7e6addcf2b0e44ce62202daba65ef1 56 A Test vectors for software implementation

[Keylen = 192] [IVlen = 96] [PTlen = 128] [AADlen = 160] [Taglen = 128]

Key = 95e5c8dcee4ef17571e1becc3f2d4ac8 d5aa73e74b3f1115 IV = e3b91649120f92b4f712644b PT = eca3606b9e2a0c7a1c6c4b765176f643 AAD = 68b093733bd1e77448fe5687b7479683 4d1797cf CT = 0ff6d858cf0f5309c0f4b2747f6b551f Tag = 94d6ac2796a9b9901933a0f9e5377979

Key = 48b82b72fc81be86860f72065efa6218 6f9da596bdf95158 IV = 24da67aef74be3338589ccb6 PT = f86a57a30c06efb10ecbeb3d5a9d97b5 AAD = c1f7f5c8f8cc5137a53991941f388ffd 2b27f0dd CT = 4be58cd06378c03878d4f1659443c5d1 Tag = 84dd00b8b03acb9219ec5116e3de7362

[Keylen = 192] [IVlen = 96] [PTlen = 104] [AADlen = 720] [Taglen = 128]

Key = ea319c2f397022a0d1b011e59b6524df fc609a2970c39c21 IV = f88c737fd24ad5804c468bbb PT = c02dcc36a608b2d5e95f93821d AAD = f8ef7628b75b405a37a78959fedc0bd7 f8d0b38ec66f0cbd2aed154cb9240e21 02909855f0ddaa3f6805cba53b53826a cc49b8d9e66d6ba0df26506bfc1570dd 9634a56448568dd57a0a087b6f45f144 8d956d90b1d0eed8d271 CT = 7c7dbe434a8463e2779b12e430 Tag = 54d21140bd173e64f5932fbc3817654f

Key = f8ec3d87425b1a2050f8701eae0057ee 21e41a7f9545ce6d A.3 AES-256 57

IV = 63be167b73a59e8440dc6ff5 PT = c02d51c5f60f66858265f083ef AAD = d702f8f12448ac1699ac493551db8eb51 3537b34287f2894a53b600e444dd90b12 996b8704aa87e4e329a5018fa1da0699c 6977d7b7e49168b8ff390f05ee37c5b2e 7f2323fe884f27c708ce776a56a7771c6 ac2f29f76d1bdc9 CT = 38e52dbd1ee3dfa91e915486d3 Tag = a49bbc775a57319317fad5abe5617cfe

[Keylen = 192] [IVlen = 96] [PTlen = 256] [AADlen = 384] [Taglen = 128]

Key = d1007bd17c6c3ec9efba9baa7584a9c1 2f61bc36fd8fe95f IV = 9513f4473b2bd9410d2e2f1f PT = 17f5ccf5dbe6e97b277824f717d02f8b 5b199d014444f72d1a00fb831e1a9d6f AAD = ab9c76ff9b1de550cde5fd42c6aeae95 cbc0395a6c39ac3edf9db75b76a66884 61b8cf2fcaf2efcd8d8dd4265b30e291 CT = db6aee7f53b8627323e7e77e01553463 302effc19884553fcdca6d7d0c0ddd33 Tag = 8c413e2f67a4124f1ef9d7ab6c238784

Key = f73b8fe6738bf05880fcf699f3ad7c2b ef8b72321d88e28f IV = fa91f633d5dfa6211023fd54 PT = 2896217daa011da3c4087cfd47ae150d d3b9fb47f57eabb17e645666ad549c09 AAD = 4f3d033d841cd1457bfe74f26a14b5e9 971745295f8365b7549b6a5a033f835b 5ab0796abd3d9307949b9331b7078cff CT = 32822c5553ace19751a5609bca5dc82c 6586185243d5ead843ab6761860fa638 Tag = 8faaee1bedb448a456795ed479ee8cf5

A.3 AES-256

[Keylen = 256] [IVlen = 96] 58 A Test vectors for software implementation

[PTlen = 0] [AADlen = 0] [Taglen = 128]

Key = b52c505a37d78eda5dd34f20c22540ea 1b58963cf8e5bf8ffa85f9f2492505b4 IV = 516c33929df5a3284ff463d7 PT = AAD = CT = Tag = bdc1ac884d332457a1d2664f168c76f0

Key = 5fe0861cdc2690ce69b3658c7f26f845 8eec1c9243c5ba0845305d897e96ca0f IV = 770ac1a5a3d476d5d96944a1 PT = AAD = CT = Tag = 196d691e1047093ca4b3d2ef4baba216

[Keylen = 256] [IVlen = 96] [PTlen = 0] [AADlen = 128] [Taglen = 128]

Key = 78dc4e0aaf52d935c3c01eea57428f00 ca1fd475f5da86a49c8dd73d68c8e223 IV = d79cf22d504cc793c3fb6c8a PT = AAD = b96baa8c1c75a671bfb2d08d06be5f36 CT = Tag = 3e5d486aa2e30b22e040b85723a06e76

Key = 4457ff33683cca6ca493878bdc003738 93a9763412eef8cddb54f91318e0da88 IV = 699d1f29d7b8c55300bb1fd2 PT = AAD = 6749daeea367d0e9809e2dc2f309e6e3 CT = Tag = d60c74d2517fde4a74e0cd4709ed43a9

[Keylen = 256] [IVlen = 96] [PTlen = 0] [AADlen = 160] A.3 AES-256 59

[Taglen = 128]

Key = 886cff5f3e6b8d0e1ad0a38fcdb26de9 7e8acbe79f6bed66959a598fa5047d65 IV = 3a8efa1cd74bbab5448f9945 PT = AAD = 519fee519d25c7a304d6c6aa1897ee1e b8c59655 CT = Tag = f6d47505ec96c98a42dc3ae719877b87

Key = 6937a57d35fe6dc3fc420b123bccdce8 74bd4c18f2e7c01ce2faf33d3944fd9d IV = a87247797b758467b96310f3 PT = AAD = ead961939a33dd578f8e93db8b28a1c8 5362905f CT = Tag = 599de3ecf22cb867f03f7f6d9fd7428a

[Keylen = 256] [IVlen = 96] [PTlen = 128] [AADlen = 0] [Taglen = 128]

Key = 31bdadd96698c204aa9ce1448ea94ae1 fb4a9a0b3c9d773b51bb1822666b8f22 IV = 0d18e06c7c725ac9e362e1ce PT = 2db5168e932556f8089a0622981d017d AAD = CT = fa4362189661d163fcd6a56d8bf0405a Tag = d636ac1bbedd5cc3ee727dc2ab4a9489

Key = 460fc864972261c2560e1eb88761ff1c 992b982497bd2ac36c04071cbb8e5d99 IV = 8a4a16b9e210eb68bcb6f58d PT = 99e4e926ffe927f691893fb79a96b067 AAD = CT = 133fc15751621b5f325c7ff71ce08324 Tag = ec4e87e0cf74a13618d0b68636ba9fa7

[Keylen = 256] [IVlen = 96] [PTlen = 128] [AADlen = 128] 60 A Test vectors for software implementation

[Taglen = 128]

Key = 92e11dcdaa866f5ce790fd24501f9250 9aacf4cb8b1339d50c9c1240935dd08b IV = ac93a1a6145299bde902f21a PT = 2d71bcfa914e4ac045b2aa60955fad24 AAD = 1e0889016f67601c8ebea4943bc23ad6 CT = 8995ae2e6df3dbf96fac7b7137bae67f Tag = eca5aa77d51d4a0a14d9c51e1da474ab

Key = 7da3bccaffb3464178ca7c722379836d b50ce0bfb47640b9572163865332e486 IV = c04fd2e701c3dc62b68738b3 PT = fd671cab1ee21f0df6bb610bf94f0e69 AAD = fec0311013202e4ffdc4204926ae0ddf CT = 6be61b17b7f7d494a7cdf270562f37ba Tag = 5e702a38323fe1160b780d17adad3e96

[Keylen = 256] [IVlen = 96] [PTlen = 128] [AADlen = 160] [Taglen = 128]

Key = 83688deb4af8007f9b713b47cfa6c73e 35ea7a3aa4ecdb414dded03bf7a0fd3a IV = 0b459724904e010a46901cf3 PT = 33d893a2114ce06fc15d55e454cf90c3 AAD = 794a14ccd178c8ebfd1379dc704c5e20 8f9d8424 CT = cc66bee423e3fcd4c0865715e9586696 Tag = 0fb291bd3dba94a1dfd8b286cfb97ac5

Key = 013f549af9ecc2ee0259d5fc2311059c b6f10f6cd6ced3b543babe7438a88251 IV = e45e759a3bfe4b652dc66d5b PT = 79490d4d233ba594ece1142e310a9857 AAD = b5fe530a5bafce7ae79b3c15471fa683 34ab378e CT = 619443034e4437b893a45a4c89fad851 Tag = 6da8a991b690ff6a442087a356f8e9e3

[Keylen = 256] [IVlen = 96] [PTlen = 104] [AADlen = 720] A.3 AES-256 61

[Taglen = 128]

Key = ff9506b4d46ba54128876fadfcc673a4 c927c618ea7d95cfcaa508cbc8f7fc66 IV = 3742ad2208a0484345eee1be PT = 7fd0d6cadc92cad27bb2d7d8c8 AAD = f1360a27fdc244be8739d85af6491c76 2a693aafe668c449515fdeeedb6a90ae ee3891bbc8b69adc6a6426cb12fcdebc 32c9f58c5259d128b91efa28620a3a9a 0168b0ff5e76951cb41647ba4aa1f87f ac0d97ac580e42cffc7e CT = bdb8346b28eb4d7226493611a6 Tag = 7484d827b767647f44c7f94a39f8175c

Key = b65b7e27d552395f5f444f031d5118fb 4fb226deb0ac4e82784b901accd43c51 IV = 2493026855dd1c1da3af7b7e PT = 8adb36d2c2358e505b5d214ad0 AAD = b78e31b1793c2b758494e9c8ae7d3cee 6e3697d40ffba04d3c6cbe25e12eeea3 65d5a2e7b46c4245771b7b2eb2062a64 0e6090d9f81caf63207865bb4f2c4cf6 af81898560e3aeaa521dcd2c336e0ec5 7faffef58683a72710b9 CT = e9f19548d66ef3c16b711b89e2 Tag = e7efc91bbf2026c3519010d65628e85f

[Keylen = 256] [IVlen = 96] [PTlen = 256] [AADlen = 384] [Taglen = 128]

Key = dc776f0156c15d032623854b625c6186 8e5db84b7b6f9fbd3672f12f0025e0f6 IV = 67130951c4a57f6ae7f13241 PT = 9378a727a5119595ad631b12a5a6bc8a 91756ef09c8d6eaa2b718fe86876da20 AAD = fd0920faeb7b212932280a009bac9691 45e5c316cf3922622c3705c3457c4e9f 124b2076994323fbcfb523f8ed16d241 CT = 6d958c20870d401a3c1f7a0ac092c977 74d451c09f7aae992a8841ff0ab9d60d Tag = b876831b4ecd7242963b040aa45c4114 62 A Test vectors for software implementation

Key = 07b3b8735d67a05632c557076ac41293 f52540bac0521573e8c0414ec36f7220 IV = 0046420eee8d56de35e2f7d5 PT = 4835d489828325a0cb38a59fc29cfeed ccae25f2e9c399281d9b7641fb609765 AAD = d51cedf9a30e476de37c90b2f6088219 3630c7497a921ab01590a26bce8cb247 e3b5590e7b07b955956ca89c7a041988 CT = 46eb31cd98b6cc3ecafe1cd1fc2d45fa 693667cbd3a7d2c5f8c10296827ea83c Tag = 36cd4e76dd0679887477bfb96cf1c5f6 Bibliography

[1] CCSDS Cryptographic Algorithms. Issue 1. Report Concerning Crypto- graphic Algorithms (Green Book), CCSDS 350.9-G-1. Washington, D.C.: CCSDS, December 2014.

[2] CCSDS Recommended Standard. Issue 1. Recommendation for Space Data Link Security (Blue Book), CCSDS 355.0-B-1. Washington, D.C.: CCSDS, September 2015.

[3] CCSDS Space Data Link Security Protocol Extended Procedures. Issue 1. Recommendation for Space Data Link Security (Red Book), CCSDS 355.1- R-1. Washington, D.C.: CCSDS, June 2018.

[4] CCSDS Space Mission Key Management Concept. Issue 1. Report Concern- ing Space Data System Standards (Green Book), CCSDS 350.6-G-1. Wash- ington, D.C.: CCSDS, December 2011.

[5] CCSDS Symmetric Key Management. Issue 1. Draft Recommendation for Space Data System Practices (Red Book), CCSDS 354.0-R-1. Washington, D.C.: CCSDS, June 2018.

[6] CCSDS Cryptographic Algorithms. Issue 2. Recommendation for Space Data System Standards (Blue Book), CCSDS 352.0-B-2. Washington, D.C.: CCSDS, August 2019.

[7] Bernstein Daniel J. Cache-timing attacks on aes. 2005. URL https:// login.e.bibl.liu.se/login?url=https://search.ebscohost. com/login.aspx?direct=true&AuthType=ip,uid&db=edsbas& AN=edsbas.4C64F69D&lang=sv&site=eds-live&scope=site.

[8] Morris Dworkin. Recommendation for Block Cipher Modes of Operation: Methods and Techniques. National Institute of Standards and Technol- ogy Special Publication 800-38A. Gaithersburg, Maryland: NIST, December 2001.

[9] Morris Dworkin. Recommendation for Block Cipher Modes of Opera- tion: Galois/Counter Mode (GCM) and GMAC. National Institute of Stan-

63 64 Bibliography

dards and Technology Special Publication 800-38D. Gaithersburg, Mary- land: NIST, November 2007.

[10] NIST. Test Vectors for AES-GCM/GMAC in SP 800-38D mode. Ac- cessed on 2020-02-26. 2020. URL https://csrc.nist.gov/ Projects/cryptographic-algorithm-validation-program/ CAVP-TESTING-BLOCK-CIPHER-MODES#GCMVS.

[11] Cobham Gaisler AB. TSIM2 Simulator User’s Manual. A generic SPARC architecture simulator capable of emulating ERC32 and LEON based computer systems. 2020(2), 2020. URL https://www.gaisler.com/doc/ tsim2.pdf.

[12] Marcio Juliato and Catherine. FPGA Implementation of an HMAC Processor based on the SHA-2 Family of Hash Functions Gebotys. 02 2020.

[13] Marcio Juliato, Catherine Gebotys, and Ignacio Aguilar Sanchez. On the speciﬁcation of symmetric key management parameters for secure space missions. pages 1–6, 10 2012. ISBN 978-1-4673-4687-0. doi: 10.1109/ ESTEL.2012.6400149.

[14] Niels Ferguson Bruce Schneier Tadayoshi Kohno. Cryptography engineering : design principles and practical applications. Wiley Pub., Inc, Indianapolis, IN, 2010. ISBN 9780470474242.

[15] Michael Koller and Alvaro Manchado. Securing the link - ﬁtting authentication into an existing space link implementation. pages 17–24, 09 2014. doi: 10.1109/SMC-IT.2014.10.

[16] Cobham Gaisler AB. GRLIB IP Core User’s Manual. GRLIB VHDL IP Core Library. 2019(4), 2019. URL https://www.gaisler.com/products/ grlib/grip.pdf.

[17] Yang Lu, Guochu Shou, Yihong Hu, Zhigang Guo. The Research, and Ef- ﬁcient FPGA Implementation of Ghash Core for GMAC. 05 2009. doi: 10.1109/EBISS.2009.5138125.

[18] Harris Michail, George Athanasiou, Vasilios Kelefouras, George Theodoridis, and Costas. On the exploitation of a high-throughput SHA256 FPGA design for HMAC Goutis. ACM Transactions on Reconﬁgurable Technology and Systems - TRETS, 5:1–28, 03 2012. doi: 10.1145/2133352.2133354.

[19] Jahanzeb Pirzada, Abid Murtaza, and Jianwei. Implementation of CMAC Authentication Algorithm on FPGA for Satellite Communication Liu. 03 2019. doi: 10.1109/ITNEC.2019.8729231.

[20] Jahanzeb Pirzada, Abid Murtaza, and Jianwei. Single Event Eﬀects Tolerant AES-CTR Implementation for Authentication of Satellite Communication Liu. International Journal of Communication Networks and Distributed Systems, October:178, 10 2019. doi: 10.17706/IJCCE.2019.8.4.178-183. Bibliography 65

[21] The Application Of Security To CCSDS Protocols. Report Concerning Space Data System Standards (Green Book), CCSDS 350.0-G-3. Washington, D.C.: CCSDS, March 2019. [22] Niels Ferguson Bruce Schneie. Practical cryptography. Wiley Pub., Inc, In- dianapolis, IN, 2003. ISBN 9780471223573. [23] Stefan Sjöholm. VHDL för konstruktion. Studentlitteratur, Lund, 2014. ISBN 9789144093734.

[24] William Stallings. Cryptography and Network Security Principles and Prac- tice. Pearson Education Limited, seventh edition, 2017. ISBN 978-1-292- 15858-7. [25] CCM Szalachowski P Ksiezopolski B Kotulski Z. CMAC and GCM/GMAC: Advanced modes of operation of symmetric block ciphers in wireless sensor networks. INFORMATION PROCESSING LETTERS [Internet], 2010 cited 2020 Feb 11 (7):247.