Inside GNSS Media & Research

JUL-AUG 2019

Issue link: https://insidegnss.epubxp.com/i/1148308

Contents of this Issue

Navigation

Page 31 of 67

32 Inside GNSS J U L Y / A U G U S T 2 0 1 9 www.insidegnss.com WORKING PAPERS Receiver operation for secure navigation (Class 3 devices): The receiver needs to have a rough time estimation from the internal hardware or a trusted source. e signal can be acquired by the receiver and local replica can be generated by the session keys. In order to track the full signal the receiver needs to combine both early and delayed authentication codes and secure navigation code. is can be achieved by a concat- enation of the code generated by the authentication keys and the code generated of the secure navigation keys. Analytical Description e following paragraph provides an analytical description of the cryptosystem and a hypothetical protocol implementation. Again it is stressed that this is just an example and not the results of a specifi c design implementations of the authors in a specifi c activity. e details of key generations and productions are only given as reference: a system designer might implement any cryptographic primitives that are most suitable to its own environment and security or policy requirements. A Master Key is generated and maintained secret- ly at system level. It is assumed that it is generated by any Key Derivation Function (KDF) that is most relevant to the solution. generates the operational keys and the Key Encryption base keys required to generate session keys that are changed on a specifi c crypto period via other KDF. e operational keys and its Initialization Vector are valid for a crypto period , and they are generated by secure hashing functions and secure random number generators at system level: (1) (2) (3) (4) Session keys are then generated that will be used during the entire pre-defi ned crypto period , this could be for example 1 month or 1 year. Each session key is valid only for a crypto period of the specifi c session crypto period ( ), that is the period of the session that could last for example 10 minutes. e session keys for the entire period are pre-generated and encrypted. (5) (6) Where F is a stream cipher function or equivalent capable to generate all and for the period . ese keys remain valid for all unless a re system rekeying is requested. System rekeying and key revocation is not covered in this paper and implementation options are le to the system designer. e stream cipher function F will generate session keys that will be used by the system to generate the signal. e generated keys will appear as a vector of keys: (7) (8) (9) e session keys are encrypted before transmission in space, where an encrypted key will be transmitted: (10) Where E is an encryption function that encrypts all vector with the vector keys. All the are transmitted by the system with some anticipation for every crypto period , which is the period that each session last. So for example [ ] could be tran- smitted during -1. Authentication implementations of is left to the system designer, they could be embedded on an existing Navigation Message Authentication (NMA) scheme or imple- ment a specifi c authentication subsystem. Preloading in hardware security modules Based on the hardware security module, the keys are uploa- ded via a hardware authentication mechanism not discussed in this article (Public Key Infrastructure or other) directly in the devices. For Class 2 devices (low end HSM), only encrypted keys are allowed ( ) as these hardware categories are at risk of key leakage. In case they are compromised, only the session key would be revealed. ese devices would require connecti- vity if rekeying is requested by the system. For Class 3 devices (high end HSM), operational keys are allowed ( , ) as this hardware category assumes a stronger protection from key leakage. Generation of authentication and secure navigation functions For every period, once are decrypted they can be used to generate the authentication function. Two type of keys for authentication are generated. • Key Delayed Authentication (KDA) Keys • Key Early Authentication (KEA) Keys e KDA Keys are generated by: (11) (12) (13) (14) Similarly, e KEA Keys are generated by: (15) (16) (17) (18) Where for both cases H is an optional secure hash function to introduce complexity against cryptanalysis and F is a stream cipher function or equivalent that generates a number of KEA and KDA keys. Both Nonce_1 and Nonce_2 are assumed to be transmitted in the broadcast messages.

Articles in this issue

Links on this page

view archives of Inside GNSS Media & Research - JUL-AUG 2019