<font size=2 face="sans-serif">Dear all,</font>
<br>
<br><font size=2 face="sans-serif">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?</font>
<br>
<br><font size=2 face="sans-serif">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. </font>
<br>
<br>
<br>
<br><font size=2 face="sans-serif">I have another problem that I want to
share with you :):</font>
<br><font size=2 face="sans-serif">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<u> baseline mode</u>
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.</font>
<br>
<br>
<br><font size=2 face="sans-serif">Cheers,<br>
Daniel</font>
<br><font size=2 face="sans-serif"><br>
<br>
<br>
<br>
Dr. Daniel Fischer<br>
----------------------------<br>
Data Systems Manager<br>
Ground Segment Engineering Support Office (OPS-GE)<br>
Ground Systems Engineering Department<br>
Directorate of Operations<br>
<br>
European Space Agency - ESOC<br>
Robert-Bosch-Str. 5<br>
D-64293 Darmstadt - Germany<br>
Tel: +49 (0) 6151 90 2718 - Fax: +49 (0) 6151 90 2718<br>
Web: </font><a href=http://www.esa.int/><font size=2 face="sans-serif">http://www.esa.int</font></a>
<br>
<br>
<br>
<br><font size=1 color=#5f5f5f face="sans-serif">From:
</font><font size=1 face="sans-serif">"Biggerstaff,
Craig (JSC-CD221)[LOCKHEED MARTIN CORP]" <craig.biggerstaff@nasa.gov></font>
<br><font size=1 color=#5f5f5f face="sans-serif">To:
</font><font size=1 face="sans-serif">"Moury Gilles"
<Gilles.Moury@cnes.fr>, "Weiss, Howard" <Howard.Weiss@parsons.com>,
"Saba Bruno" <Bruno.Saba@cnes.fr>, "Daniel.Fischer@esa.int"
<Daniel.Fischer@esa.int>, "sls-sea-dls@mailman.ccsds.org"
<sls-sea-dls@mailman.ccsds.org></font>
<br><font size=1 color=#5f5f5f face="sans-serif">Date:
</font><font size=1 face="sans-serif">19/04/2016 15:49</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:
</font><font size=1 face="sans-serif">RE: [Sls-sea-dls]
Key Verification using CRC</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Sent by:
</font><font size=1 face="sans-serif">sls-sea-dls-bounces@mailman.ccsds.org</font>
<br>
<hr noshade>
<br>
<br>
<br><font size=2 color=#004080 face="Calibri">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.</font>
<br><font size=2 color=#004080 face="Calibri"> </font>
<br><font size=2 color=#004080 face="Calibri">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.</font>
<br><font size=2 color=#004080 face="Calibri"> </font>
<br><font size=2 color=#004080 face="Calibri">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.</font>
<br><font size=2 color=#004080 face="Calibri">
</font>
<br><font size=2 color=#004080 face="Calibri"> </font>
<br><font size=2 color=#004080 face="Calibri"> </font>
<br><font size=2 color=#004080 face="Calibri">Craig</font>
<br><font size=2 color=#004080 face="Calibri"> </font>
<br><font size=2 face="Calibri"><b>From:</b> sls-sea-dls-bounces@mailman.ccsds.org
[</font><a href="mailto:sls-sea-dls-bounces@mailman.ccsds.org"><font size=2 face="Calibri">mailto:sls-sea-dls-bounces@mailman.ccsds.org</font></a><font size=2 face="Calibri">]
<b>On Behalf Of </b>Moury Gilles<b><br>
Sent:</b> Tuesday, April 19, 2016 3:46 AM<b><br>
To:</b> Weiss, Howard <Howard.Weiss@parsons.com>; Saba Bruno <Bruno.Saba@cnes.fr>;
Daniel.Fischer@esa.int; sls-sea-dls@mailman.ccsds.org<b><br>
Subject:</b> RE: [Sls-sea-dls] Key Verification using CRC</font>
<br><font size=3 face="Times New Roman"> </font>
<br><font size=2 color=#004080 face="Calibri">Shall we adopt Bruno’s proposal
? In that case, we probably do not need the challenge-response transaction.</font>
<br><font size=2 color=#004080 face="Calibri"> </font>
<br><font size=2 color=#004080 face="Calibri">Gilles</font>
<br><font size=2 color=#004080 face="Calibri"> </font>
<br><font size=2 color=#004080 face="Arial">Gilles MOURY</font><font size=3 color=#004080 face="Times New Roman">
</font><font size=2 color=#004080 face="Arial"><br>
CNES Toulouse</font><font size=3 color=#004080 face="Times New Roman">
</font>
<br><font size=2 face="Tahoma"><b>De :</b> </font><a href="mailto:sls-sea-dls-bounces@mailman.ccsds.org"><font size=2 color=blue face="Tahoma"><u>sls-sea-dls-bounces@mailman.ccsds.org</u></font></a><font size=2 face="Tahoma">
[</font><a href="mailto:sls-sea-dls-bounces@mailman.ccsds.org"><font size=2 color=blue face="Tahoma"><u>mailto:sls-sea-dls-bounces@mailman.ccsds.org</u></font></a><font size=2 face="Tahoma">]
<b>De la part de</b> Weiss, Howard<b><br>
Envoyé :</b> lundi 18 avril 2016 19:27<b><br>
À :</b> Saba Bruno; </font><a href=mailto:Daniel.Fischer@esa.int><font size=2 color=blue face="Tahoma"><u>Daniel.Fischer@esa.int</u></font></a><font size=2 face="Tahoma">;
</font><a href="mailto:sls-sea-dls@mailman.ccsds.org"><font size=2 color=blue face="Tahoma"><u>sls-sea-dls@mailman.ccsds.org</u></font></a><font size=2 face="Tahoma"><b><br>
Objet :</b> RE: [Sls-sea-dls] Key Verification using CRC</font>
<br><font size=3 face="Times New Roman"> </font>
<br><font size=2 face="Tahoma">I agree with Bruno.<br>
<br>
Howie</font>
<br><font size=2 face="Tahoma"> </font>
<br><font size=2 face="Tahoma"> </font>
<div align=center>
<hr></div>
<br><font size=2 face="Tahoma"><b>Howard Weiss</b></font><font size=1 face="Tahoma"><br>
Technical Director</font><font size=2 face="Tahoma"><br>
<b><br>
PARSONS</b></font><font size=1 face="Tahoma"><br>
7110 Samuel Morse Drive<br>
Columbia, MD 21046<br>
443-430-8089 (office)<br>
410-262-1479 (cell)<br>
443-430-8238 (fax)</font><font size=1 color=blue face="Tahoma"><u><br>
</u></font><a href=mailto:howard.weiss@parsons.com><font size=1 color=blue face="Tahoma"><u>howard.weiss@parsons.com</u></font></a><font size=1 color=blue face="Tahoma"><u><br>
</u></font><a href=http://www.parsons.com/><font size=1 color=blue face="Tahoma"><u>www.parsons.com</u></font></a><font size=1 face="Tahoma"><br>
</font><font size=1 color=#3f8080 face="Tahoma"><br>
Please consider the environment before printing this message</font>
<div align=center>
<hr></div>
<br><font size=2 face="Tahoma"><b>From:</b> </font><a href="mailto:sls-sea-dls-bounces@mailman.ccsds.org"><font size=2 color=blue face="Tahoma"><u>sls-sea-dls-bounces@mailman.ccsds.org</u></font></a><font size=2 face="Tahoma">
[sls-sea-dls-bounces@mailman.ccsds.org] on behalf of Saba Bruno [Bruno.Saba@cnes.fr]<b><br>
Sent:</b> Monday, April 18, 2016 9:48 AM<b><br>
To:</b> </font><a href=mailto:Daniel.Fischer@esa.int><font size=2 color=blue face="Tahoma"><u>Daniel.Fischer@esa.int</u></font></a><font size=2 face="Tahoma">;
</font><a href="mailto:sls-sea-dls@mailman.ccsds.org"><font size=2 color=blue face="Tahoma"><u>sls-sea-dls@mailman.ccsds.org</u></font></a><font size=2 face="Tahoma"><b><br>
Subject:</b> RE: [Sls-sea-dls] Key Verification using CRC</font>
<br><font size=2 color=#004080 face="Calibri">Dear all,</font>
<br><font size=2 color=#004080 face="Calibri"> </font>
<br><font size=2 color=#004080 face="Calibri">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.</font>
<br><font size=2 color=#004080 face="Calibri"> </font>
<br><font size=2 color=#004080 face="Calibri">Ideally, what we know as
a “key” would be a “Meta-Key”, comprising :</font>
<br><font size=2 color=#004080 face="Calibri"> </font>
<br><font size=2 color=#004080 face="Calibri">-</font><font size=1 color=#004080 face="Times New Roman">
</font><font size=2 color=#004080 face="Calibri">The
Key ID, unique identifier of the key for the whole mission duration,</font>
<br><font size=2 color=#004080 face="Calibri">-</font><font size=1 color=#004080 face="Times New Roman">
</font><font size=2 color=#004080 face="Calibri">The
Key itself (secret random data)</font>
<br><font size=2 color=#004080 face="Calibri">-</font><font size=1 color=#004080 face="Times New Roman">
</font><font size=2 color=#004080 face="Calibri">The
CRC, computed on the Key ID and the key itself.</font>
<br><font size=2 color=#004080 face="Calibri"> </font>
<br><font size=2 color=#004080 face="Calibri">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).</font>
<br><font size=2 color=#004080 face="Calibri"> </font>
<br><font size=2 color=#004080 face="Calibri">Cheers,</font>
<br><font size=2 color=#004080 face="Calibri"> </font>
<br><font size=2 color=#004080 face="Calibri"> </font>
<br><font size=2 color=#004080 face="Arial">Bruno Saba</font><font size=3 color=#004080 face="Times New Roman">
</font><font size=2 color=#004080 face="Arial"><br>
CNES</font><font size=3 color=#004080 face="Times New Roman"> </font><font size=2 color=#004080 face="Arial"><br>
DCT/TV/IN</font><font size=3 color=#004080 face="Times New Roman"> </font><font size=2 color=#004080 face="Arial"><br>
18 Avenue Edouard Belin</font><font size=3 color=#004080 face="Times New Roman">
</font><font size=2 color=#004080 face="Arial"><br>
31401 TOULOUSE Cedex 9</font><font size=3 color=#004080 face="Times New Roman">
</font>
<br><font size=2 color=#004080 face="Arial">Tel : + 33 (0) 5 61 28 28 76</font><font size=3 color=#004080 face="Times New Roman">
</font><font size=2 color=#004080 face="Arial"><br>
Fax : + 33 (0) 5 61 28 19 96</font><font size=3 color=#004080 face="Times New Roman">
</font>
<br><font size=2 color=#004080 face="Calibri"> </font>
<br><font size=2 color=#004080 face="Calibri"> </font>
<br><font size=2 face="Tahoma"><b>De :</b> </font><a href="mailto:sls-sea-dls-bounces@mailman.ccsds.org"><font size=2 color=blue face="Tahoma"><u>sls-sea-dls-bounces@mailman.ccsds.org</u></font></a><font size=2 face="Tahoma">
[</font><a href="mailto:sls-sea-dls-bounces@mailman.ccsds.org"><font size=2 color=blue face="Tahoma"><u>mailto:sls-sea-dls-bounces@mailman.ccsds.org</u></font></a><font size=2 face="Tahoma">]
<b>De la part de</b> </font><a href=mailto:Daniel.Fischer@esa.int><font size=2 color=blue face="Tahoma"><u>Daniel.Fischer@esa.int</u></font></a><font size=2 face="Tahoma"><b><br>
Envoyé :</b> dimanche 17 avril 2016 13:13<b><br>
À :</b> </font><a href="mailto:sls-sea-dls@mailman.ccsds.org"><font size=2 color=blue face="Tahoma"><u>sls-sea-dls@mailman.ccsds.org</u></font></a><font size=2 face="Tahoma"><b><br>
Objet :</b> [Sls-sea-dls] Key Verification using CRC</font>
<br><font size=3 face="Times New Roman"> </font>
<br><font size=2 face="Arial">Dear all,</font><font size=3 face="Times New Roman">
<br>
</font><font size=2 face="Arial"><br>
I was discussing our new approach to key verification using the onboard-stored
CRCs with David,</font><font size=3 face="Times New Roman"> <br>
</font><font size=2 face="Arial"><br>
He came up with a keen observation. </font><font size=3 face="Times New Roman">
<br>
</font><font size=2 face="Arial"><br>
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.</font><font size=3 face="Times New Roman"> <br>
</font><font size=2 face="Arial"><br>
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.</font><font size=3 face="Times New Roman"> <br>
</font><font size=2 face="Arial"><br>
What do you think?</font><font size=3 face="Times New Roman"> <br>
</font><font size=2 face="Arial"><br>
Cheers</font><font size=3 face="Times New Roman"> </font><font size=2 face="Arial"><br>
Daniel</font><font size=3 face="Times New Roman"> </font><font size=2 face="Arial"><br>
<br>
<br>
<br>
<br>
Dr. Daniel Fischer<br>
----------------------------<br>
Data Systems Manager<br>
Ground Segment Engineering Support Office (OPS-GE)<br>
Ground Systems Engineering Department<br>
Directorate of Operations<br>
<br>
European Space Agency - ESOC<br>
Robert-Bosch-Str. 5<br>
D-64293 Darmstadt - Germany<br>
Tel: +49 (0) 6151 90 2718 - Fax: +49 (0) 6151 90 2718<br>
Web: </font><a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__www.esa.int_&d=BQMFAw&c=Nwf-pp4xtYRe0sCRVM8_LWH54joYF7EKmrYIdfxIq10&r=dT3K0y3n0RD9-56k-UVMPMP98PIQRd2Kzfa-AwqQOww&m=KmN17nxUMzCwV8w34kOrcf_v-AiSW05d3ZrGT3WEwEk&s=mA6vGF_WMAaO1e4I2x3Pnor6OGmfWEXhPWqN5MXu0eE&e=" target=_blank><font size=2 color=blue face="Arial"><u>http://www.esa.int</u></font><font size=3 color=blue face="Times New Roman"><u>[esa.int]</u></font></a>
<br><font size=2 face="Courier New">This message and any attachments are
intended for the use of the addressee or addressees only.</font>
<br><font size=2 face="Courier New">The unauthorised disclosure, use, dissemination
or copying (either in whole or in part) of its</font>
<br><font size=2 face="Courier New">content is not permitted.</font>
<br><font size=2 face="Courier New">If you received this message in error,
please notify the sender and delete it from your system.</font>
<br><font size=2 face="Courier New">Emails can be altered and their integrity
cannot be guaranteed by the sender.</font>
<br><font size=2 face="Courier New"> </font>
<br><font size=2 face="Courier New">Please consider the environment before
printing this email.</font><tt><font size=2>_______________________________________________<br>
SLS-SEA-DLS mailing list<br>
SLS-SEA-DLS@mailman.ccsds.org<br>
</font></tt><a href="http://mailman.ccsds.org/cgi-bin/mailman/listinfo/sls-sea-dls"><tt><font size=2>http://mailman.ccsds.org/cgi-bin/mailman/listinfo/sls-sea-dls</font></tt></a><tt><font size=2><br>
</font></tt>
<br>
<br><PRE>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.
</PRE>