[Sls-sea-dls] Key Verification using CRC & OTAR Issue
Moury Gilles
Gilles.Moury at cnes.fr
Wed Apr 20 08:37:28 UTC 2016
I concur : OTAR procedure and baseline mode require additional discussion. Hopefully, we will be able to converge at the May 26 telecon.
Gilles MOURY
CNES Toulouse
-----Message d'origine-----
De : Ignacio.Aguilar.Sanchez at esa.int [mailto:Ignacio.Aguilar.Sanchez at esa.int]
Envoyé : mercredi 20 avril 2016 09:38
À : Daniel.Fischer at esa.int
Cc : Saba Bruno; Biggerstaff, Craig (JSC-CD221)[LOCKHEED MARTIN CORP]; Moury Gilles; Weiss, Howard; sls-sea-dls at mailman.ccsds.org; sls-sea-dls-bounces at mailman.ccsds.org
Objet : Re: [Sls-sea-dls] Key Verification using CRC & OTAR Issue
Dear all,
I have just talked to Daniel. We both suggest to handle this point on the already agreed telecon on the 26 May.
Kind regards,
Ignacio
(Embedded image moved to file: pic30836.jpg)
Ignacio Aguilar Sánchez
Communication Systems Engineer
Electrical Engineering Department
European Space Research and Technology Centre Keplerlaan 1, PO Box 299, 2200 AG Noordwijk, The Netherlands Tel. (31) 71 565 5695 Fax (31) 71 565 5418
Email: ignacio.aguilar.sanchez at esa.int
www.esa.int
From: Daniel.Fischer at esa.int
To: "Biggerstaff, Craig (JSC-CD221)[LOCKHEED MARTIN CORP]"
<craig.biggerstaff at nasa.gov>
Cc: "sls-sea-dls at mailman.ccsds.org" <sls-sea-dls at mailman.ccsds.org>,
sls-sea-dls-bounces at mailman.ccsds.org, "Weiss, Howard"
<Howard.Weiss at parsons.com>, "Saba Bruno" <Bruno.Saba at cnes.fr>,
"Moury Gilles" <Gilles.Moury at cnes.fr>
Date: 20/04/2016 08:42
Subject: [Sls-sea-dls] Key Verification using CRC & OTAR Issue
Sent by: sls-sea-dls-bounces at mailman.ccsds.org
Dear all,
In order to adopt the key verification that contains a computation of the CRC over the Key ID and the key instead of just the key, there is no change necessary in the PDU. Thus, I would almost make this an implementation specific thing. Some implementers may prefer to compute the CRC just over the key, others may want to compute it over the Key ID and the Key. We could cover this choice with a note. Regarding the latest mail from Craig, would the concerns not also be valid if only the key is used for the generation of the CRC?
I am not really in favour in formalising a "meta key" as well. In my opinion, the way how the key, key ID, and CRC are generated and stored is not something the blue book should address.
I have another problem that I want to share with you :):
In Cleveland, we have agreed that with OTAR the MAC is only computed over the set of [Key Id, Encrypted Key] blocks. This is fine. However, I now have problems with the baseline mode of the key encryption. If I choose AES-CTR (the recommended one as per algorithm BB) we need to transmit an IV for every key. I don't think that this is what we want, is it? Especially not for random data like a key. Any suggestions? The BB allows other modes if carefully considered. However, modes like CBC also require an IV. I am a bit reluctant to go for something as dangerous as ECB although it should not be a problem for keys.
Cheers,
Daniel
Dr. Daniel Fischer
----------------------------
Data Systems Manager
Ground Segment Engineering Support Office (OPS-GE) Ground Systems Engineering Department Directorate of Operations
European Space Agency - ESOC
Robert-Bosch-Str. 5
D-64293 Darmstadt - Germany
Tel: +49 (0) 6151 90 2718 - Fax: +49 (0) 6151 90 2718
Web: http://www.esa.int
From: "Biggerstaff, Craig (JSC-CD221)[LOCKHEED MARTIN CORP]"
<craig.biggerstaff at nasa.gov>
To: "Moury Gilles" <Gilles.Moury at cnes.fr>, "Weiss, Howard"
<Howard.Weiss at parsons.com>, "Saba Bruno" <Bruno.Saba at cnes.fr>, "Daniel.Fischer at esa.int" <Daniel.Fischer at esa.int>, "sls-sea-dls at mailman.ccsds.org" <sls-sea-dls at mailman.ccsds.org>
Date: 19/04/2016 15:49
Subject: RE: [Sls-sea-dls] Key Verification using CRC
Sent by: sls-sea-dls-bounces at mailman.ccsds.org
Bruno’s proposal is a good technical solution by itself, but I have concerns about introducing additional requirements into ground crypto systems for generation and storage of meta-keys.
The CRC may not itself be a critical security parameter in the FIPS 140 sense (I think it is not, but I defer to others’ judgment in this), but generation of the CRC requires access to critical security parameters, both the Key ID and the actual key itself. So CRC generation would have to be performed within a validated crypto system, even if it were permissible to transmit and store the CRC outside the crypto system.
If Bruno’s proposal were adopted as-is, it appears unlikely to me that any generic, commercially-available crypto systems could satisfy the requirement.
For flight systems, this may not be an issue since flight implementations tend to be custom by their very nature. On the other hand, ground systems that otherwise might be able to integrate commercially-available crypto systems would be forced into procuring custom implementations requiring e.g.
FIPS 140 validation along with its additional time and expense.
Craig
From: sls-sea-dls-bounces at mailman.ccsds.org [ mailto:sls-sea-dls-bounces at mailman.ccsds.org] On Behalf Of Moury Gilles
Sent: Tuesday, April 19, 2016 3:46 AM
To: Weiss, Howard <Howard.Weiss at parsons.com>; Saba Bruno <Bruno.Saba at cnes.fr>; Daniel.Fischer at esa.int; sls-sea-dls at mailman.ccsds.org
Subject: RE: [Sls-sea-dls] Key Verification using CRC
Shall we adopt Bruno’s proposal ? In that case, we probably do not need the challenge-response transaction.
Gilles
Gilles MOURY
CNES Toulouse
De : sls-sea-dls-bounces at mailman.ccsds.org [ mailto:sls-sea-dls-bounces at mailman.ccsds.org] De la part de Weiss, Howard Envoyé : lundi 18 avril 2016 19:27 À : Saba Bruno; Daniel.Fischer at esa.int; sls-sea-dls at mailman.ccsds.org Objet : RE: [Sls-sea-dls] Key Verification using CRC
I agree with Bruno.
Howie
Howard Weiss
Technical Director
PARSONS
7110 Samuel Morse Drive
Columbia, MD 21046
443-430-8089 (office)
410-262-1479 (cell)
443-430-8238 (fax)
howard.weiss at parsons.com
www.parsons.com
Please consider the environment before printing this message
From: sls-sea-dls-bounces at mailman.ccsds.org
[sls-sea-dls-bounces at mailman.ccsds.org] on behalf of Saba Bruno [Bruno.Saba at cnes.fr]
Sent: Monday, April 18, 2016 9:48 AM
To: Daniel.Fischer at esa.int; sls-sea-dls at mailman.ccsds.org
Subject: RE: [Sls-sea-dls] Key Verification using CRC Dear all,
One solution to avoid the use of a challenge-response system and stay with the simple CRC for on-board key checking is to compute the CRC on BOTH the Key-ID and the key itself.
Ideally, what we know as a “key” would be a “Meta-Key”, comprising :
- The Key ID, unique identifier of the key for the whole mission
duration,
- The Key itself (secret random data)
- The CRC, computed on the Key ID and the key itself.
This “Meta-Key” should be considered as an single entity, not splittable, being stored, transferred and distributed as is (on-board AND at ground level, from generation to destruction).
Cheers,
Bruno Saba
CNES
DCT/TV/IN
18 Avenue Edouard Belin
31401 TOULOUSE Cedex 9
Tel : + 33 (0) 5 61 28 28 76
Fax : + 33 (0) 5 61 28 19 96
De : sls-sea-dls-bounces at mailman.ccsds.org [ mailto:sls-sea-dls-bounces at mailman.ccsds.org] De la part de Daniel.Fischer at esa.int Envoyé : dimanche 17 avril 2016 13:13 À : sls-sea-dls at mailman.ccsds.org Objet : [Sls-sea-dls] Key Verification using CRC
Dear all,
I was discussing our new approach to key verification using the onboard-stored CRCs with David,
He came up with a keen observation.
The CRC-based key verification is somewhat weaker than one based on a challenge-response. The reason is that the CRC ensues you that the key at a certain slot is still OK in terms of integrity. In contrast to the challenge-response approach it DOES NOT tell you that the key is the same as the key with same key ID on ground.
Is this an issue for us? What do you think? The only way we have to check key synchronisation is to use a key for actual traffic protection and see if it works.
What do you think?
Cheers
Daniel
Dr. Daniel Fischer
----------------------------
Data Systems Manager
Ground Segment Engineering Support Office (OPS-GE) Ground Systems Engineering Department Directorate of Operations
European Space Agency - ESOC
Robert-Bosch-Str. 5
D-64293 Darmstadt - Germany
Tel: +49 (0) 6151 90 2718 - Fax: +49 (0) 6151 90 2718
Web: http://www.esa.int[esa.int]
This message and any attachments are intended for the use of the addressee or addressees only.
The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its content is not permitted.
If you received this message in error, please notify the sender and delete it from your system.
Emails can be altered and their integrity cannot be guaranteed by the sender.
Please consider the environment before printing this email.
_______________________________________________
SLS-SEA-DLS mailing list
SLS-SEA-DLS at mailman.ccsds.org
http://mailman.ccsds.org/cgi-bin/mailman/listinfo/sls-sea-dls
This message and any attachments are intended for the use of the addressee or addressees only.
The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its content is not permitted.
If you received this message in error, please notify the sender and delete it from your system.
Emails can be altered and their integrity cannot be guaranteed by the sender.
Please consider the environment before printing this email.
_______________________________________________
SLS-SEA-DLS mailing list
SLS-SEA-DLS at mailman.ccsds.org
http://mailman.ccsds.org/cgi-bin/mailman/listinfo/sls-sea-dls
This message and any attachments are intended for the use of the addressee or addressees only.
The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its content is not permitted.
If you received this message in error, please notify the sender and delete it from your system.
Emails can be altered and their integrity cannot be guaranteed by the sender.
Please consider the environment before printing this email.
More information about the SLS-SEA-DLS
mailing list