[Sls-sea-dls] Key Verification using CRC

[Moury Gilles]

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<mailto:howard.weiss at parsons.com>
www.parsons.com<http://www.parsons.com>

Please consider the environment before printing this message
________________________________
From: sls-sea-dls-bounces at mailman.ccsds.org<mailto: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<mailto:Daniel.Fischer at esa.int>; sls-sea-dls at mailman.ccsds.org<mailto: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> [mailto:sls-sea-dls-bounces at mailman.ccsds.org] De la part de Daniel.Fischer at esa.int<mailto:Daniel.Fischer at esa.int>
Envoyé : dimanche 17 avril 2016 13:13
À : sls-sea-dls at mailman.ccsds.org<mailto: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]<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=>

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sls-sea-dls/attachments/20160419/62e70547/attachment.html>