From Gilles.Moury at cnes.fr Sat Apr 2 15:47:38 2016 From: Gilles.Moury at cnes.fr (Moury Gilles) Date: Sat, 2 Apr 2016 15:47:38 +0000 Subject: [Sls-sea-dls] CCSDS Cleveland: SDLS / SLP joint session on Wednesday afternoon Message-ID: <442F062EBF46F247A96B8A50EF3EB6F42A215A82@TW-MBX-P04.cnesnet.ad.cnes.fr> Dear SDLS and SLP WG member, Please find attached 2 presentations to support our discussions during our joint session on Wednesday April 6, 13H30-15H30 Laelia room in Westin Cleveland : * Extended Procedures PDUs transmission over the spacelink * Need to further specify non protection of OID VCs Looking forward to a fruitful meeting, Best regards, Gilles Moury SDLS WG Co-Chair Gilles MOURY CNES Toulouse Expert senior "Plateforme Satellite" Sous-Direction "Techniques Véhicule, Architecture & Intégration" DCT/TV-RA - Bpi 1416 18, avenue Edouard Belin F-31401 TOULOUSE Cedex 9 http://www.cnes.fr tel : +33 (0)5 61 27 3790 fax : +33 (0)5 61 27 4099 sec : +33 (0)5 61 27 3882 mob : +33 (0)6 83 56 0485 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Transmission of EP PDUs.ppt Type: application/vnd.ms-powerpoint Size: 241664 bytes Desc: Transmission of EP PDUs.ppt URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SDLS wrt OID frames and VCs.ppt Type: application/vnd.ms-powerpoint Size: 245760 bytes Desc: SDLS wrt OID frames and VCs.ppt URL: From Gilles.Moury at cnes.fr Wed Apr 6 01:00:42 2016 From: Gilles.Moury at cnes.fr (Moury Gilles) Date: Wed, 6 Apr 2016 01:00:42 +0000 Subject: [Sls-sea-dls] slides for interoperability testing discussion on Thursday Message-ID: <442F062EBF46F247A96B8A50EF3EB6F42A217709@TW-MBX-P04.cnesnet.ad.cnes.fr> Dear SDLS WG member, Please find attached a short presentation to support our discussion on interoperability testing of SDLS Extended Procedures on Thursday: Looking forward to a fruitful meeting, Best regards, Gilles Moury SDLS WG Co-Chair Gilles MOURY CNES Toulouse Expert senior "Plateforme Satellite" Sous-Direction "Techniques Véhicule, Architecture & Intégration" DCT/TV-RA - Bpi 1416 18, avenue Edouard Belin F-31401 TOULOUSE Cedex 9 http://www.cnes.fr tel : +33 (0)5 61 27 3790 fax : +33 (0)5 61 27 4099 sec : +33 (0)5 61 27 3882 mob : +33 (0)6 83 56 0485 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SDLS EP interoperability testing.ppt Type: application/vnd.ms-powerpoint Size: 291328 bytes Desc: SDLS EP interoperability testing.ppt URL: From Gilles.Moury at cnes.fr Thu Apr 7 13:07:23 2016 From: Gilles.Moury at cnes.fr (Moury Gilles) Date: Thu, 7 Apr 2016 13:07:23 +0000 Subject: [Sls-sea-dls] TR: WebEx Link In-Reply-To: References: Message-ID: <442F062EBF46F247A96B8A50EF3EB6F42A218169@TW-MBX-P04.cnesnet.ad.cnes.fr> For our webconf with Bruno ... if I can reach him ... Gilles MOURY CNES Toulouse De : Ross, David (HQ-CG000)[Arctic Slope Technical Services, Inc.] [mailto:david.ross at nasa.gov] Envoyé : jeudi 7 avril 2016 14:54 À : Moury Gilles Objet : WebEx Link Good morning Gilles, You may use the following webex account for the next 12 hours. All the best, -David Spring 2016 Technical Plenary Thursday, April 7, 2016 8:55 am | Eastern Daylight Time (New York, GMT-04:00) | 12 hrs Join WebEx meeting Meeting number: 954 130 464 Join by phone 0800-051-3810 Call-in toll-free number (UK) +44-203-478-5289 Call-in toll number (UK) Access code: 954 130 464 Global call-in numbers | Toll-free calling restrictions -------------- next part -------------- An HTML attachment was scrubbed... URL: From Daniel.Fischer at esa.int Thu Apr 7 20:41:22 2016 From: Daniel.Fischer at esa.int (Daniel.Fischer at esa.int) Date: Thu, 7 Apr 2016 22:41:22 +0200 Subject: [Sls-sea-dls] SDLS TC for SDLS EP prototyping Message-ID: <19583_1460061686_5706C5F6_19583_63_1_OFD873AB86.B35EEE2B-ONC1257F8E.0071A67D-C1257F8E.0071A6E2@esa.int> Invitation: SDLS TC for SDLS EP prototyping 26/05/2016 - Daniel Fischer has invited you to a meeting. You have not yet responded. Required: sls-sea-dls at mailman.ccsds.org 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 1564 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pic28158.gif Type: image/gif Size: 2178 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: c224121.ics Type: application/octet-stream Size: 1564 bytes Desc: not available URL: From Daniel.Fischer at esa.int Thu Apr 7 20:45:59 2016 From: Daniel.Fischer at esa.int (Daniel.Fischer at esa.int) Date: Thu, 7 Apr 2016 22:45:59 +0200 Subject: [Sls-sea-dls] SDLS EP testing presentation Message-ID: <21337_1460061968_5706C70F_21337_178_1_OFFA5945A1.12D0F568-ONC1257F8E.0071CDC1-C1257F8E.0072130D@esa.int> 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 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: SDLS EP - Status of Prototype and Testing v2.pptx Type: application/octet-stream Size: 577913 bytes Desc: not available URL: From Gilles.Moury at cnes.fr Fri Apr 8 02:54:35 2016 From: Gilles.Moury at cnes.fr (Moury Gilles) Date: Fri, 8 Apr 2016 02:54:35 +0000 Subject: [Sls-sea-dls] TR: [Cesg-all] CCSDS Area / WG / Resource Statistics In-Reply-To: <4519_1460059834_5706BEBA_4519_22_1_OF161594C5.C864694C-ONC1257F8E.006E8F4D-C1257F8E.006ED275@esa.int> References: <4519_1460059834_5706BEBA_4519_22_1_OF161594C5.C864694C-ONC1257F8E.006E8F4D-C1257F8E.006ED275@esa.int> Message-ID: <442F062EBF46F247A96B8A50EF3EB6F42A218B41@TW-MBX-P04.cnesnet.ad.cnes.fr> FYI Gilles MOURY CNES Toulouse De : cesg-all-bounces at mailman.ccsds.org [mailto:cesg-all-bounces at mailman.ccsds.org] De la part de Nestor.Peccia at esa.int Envoyé : jeudi 7 avril 2016 22:10 À : CCSDS Management Council (CMC at mailman.ccsds.org) (CMC at mailman.ccsds.org); CCSDS Engineering Steering Group - CESG All Objet : [Cesg-all] CCSDS Area / WG / Resource Statistics Dear all, please find attached the CCSDS Area / WG / Resource Statistics as of 29th March 2016 @ WG Chairs: I count on you to distribute it within your WG ciao nestor 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: CCSDS-Resource-Matrix-29Mar2016.pdf Type: application/octet-stream Size: 117614 bytes Desc: CCSDS-Resource-Matrix-29Mar2016.pdf URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ATT00001.txt URL: From Ignacio.Aguilar.Sanchez at esa.int Fri Apr 8 13:18:39 2016 From: Ignacio.Aguilar.Sanchez at esa.int (Ignacio.Aguilar.Sanchez at esa.int) Date: Fri, 8 Apr 2016 15:18:39 +0200 Subject: [Sls-sea-dls] SDLS Green Book - uploaded to CWE Spring 2016 meeting material folder Message-ID: <24498_1460121528_5707AFB7_24498_348_1_OFBE09A597.06E6F0D7-ONC1257F8F.0048DF9B-C1257F8F.00491E89@esa.int> http://cwe.ccsds.org/sls/docs/Forms/AllItems.aspx?RootFolder=%2Fsls%2Fdocs%2FSLS-SEA-DLS%2FCWE%20Private%2Fmeeting%20material%2FSpring%202016%20meeting& Kind regards, Ignacio (Embedded image moved to file: pic23700.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 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 -------------- A non-text attachment was scrubbed... Name: pic23700.jpg Type: image/jpeg Size: 2001 bytes Desc: not available URL: From Gilles.Moury at cnes.fr Fri Apr 8 13:57:25 2016 From: Gilles.Moury at cnes.fr (Moury Gilles) Date: Fri, 8 Apr 2016 13:57:25 +0000 Subject: [Sls-sea-dls] SDLS WG report to SLS plenary Message-ID: <442F062EBF46F247A96B8A50EF3EB6F42A218D7D@TW-MBX-P04.cnesnet.ad.cnes.fr> Gian-Paolo, Please find attached the SDLS WG meeting report : Best regards, Gilles Gilles MOURY CNES Toulouse Expert senior "Plateforme Satellite" Sous-Direction "Techniques Véhicule, Architecture & Intégration" DCT/TV-RA - Bpi 1416 18, avenue Edouard Belin F-31401 TOULOUSE Cedex 9 http://www.cnes.fr tel : +33 (0)5 61 27 3790 fax : +33 (0)5 61 27 4099 sec : +33 (0)5 61 27 3882 mob : +33 (0)6 83 56 0485 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SLS-Report-to-CESG-Spring2016 SDLS.pptx Type: application/vnd.openxmlformats-officedocument.presentationml.presentation Size: 196322 bytes Desc: SLS-Report-to-CESG-Spring2016 SDLS.pptx URL: From Brandon.T.Bailey at nasa.gov Fri Apr 8 20:41:19 2016 From: Brandon.T.Bailey at nasa.gov (Brandon T. Bailey) Date: Fri, 8 Apr 2016 16:41:19 -0400 Subject: [Sls-sea-dls] Fwd: Cloud Action Response References: Message-ID: Passing on to Security WG and SDLS WG. Let me know if I missed something. Brandon Bailey NASA IV&V Got Secure Code? - https://nen.nasa.gov/web/coding 304-629-8992 brandon.t.bailey at nasa.gov Begin forwarded message: From: "Brandon T. Bailey" > Date: April 8, 2016 at 8:58:37 AM EDT To: "Shames, Peter M (312B)" >, "Howard.Weiss at parsons.com" >, "Gilles.Moury at cnes.fr" >, "Gilles.Moury at cnes.fr" > Cc: Daniel Fischer/esoc/ESA >, "David.Koisser at esa.int" >, "John P. Lucas" > Subject: Cloud Action Response For CESG / Plenary today…. Let me know if we should distribute to the sea-sec and sdls distro lists as well. Brandon Bailey NASA IV&V Got Secure Code? - https://nen.nasa.gov/web/coding 304-629-8992 brandon.t.bailey at nasa.gov -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Cloud-Pilot-Action-Response.pptx Type: application/vnd.openxmlformats-officedocument.presentationml.presentation Size: 826900 bytes Desc: Cloud-Pilot-Action-Response.pptx URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Update-CCSDS-Cloud-Testing.docx Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document Size: 1528396 bytes Desc: Update-CCSDS-Cloud-Testing.docx URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.m.shames at jpl.nasa.gov Fri Apr 8 21:48:18 2016 From: peter.m.shames at jpl.nasa.gov (Shames, Peter M (312B)) Date: Fri, 8 Apr 2016 21:48:18 +0000 Subject: [Sls-sea-dls] Re: [Sea-sec] Fwd: Cloud Action Response In-Reply-To: References: , Message-ID: <42FE89B9-A415-431E-A5F7-AFC643A69B33@jpl.nasa.gov> Thanks Brandon. Peter Sent from Peter's iPhone 6 Everything should be made as simple as possible, but not simpler. ~Albert Einstein > On Apr 8, 2016, at 4:43 PM, Brandon T. Bailey wrote: > > Passing on to Security WG and SDLS WG. > > Let me know if I missed something. > > Brandon Bailey > NASA IV&V > Got Secure Code? - https://nen.nasa.gov/web/coding > 304-629-8992 > brandon.t.bailey at nasa.gov > > Begin forwarded message: > > From: "Brandon T. Bailey" > > Date: April 8, 2016 at 8:58:37 AM EDT > To: "Shames, Peter M (312B)" >, "Howard.Weiss at parsons.com" >, "Gilles.Moury at cnes.fr" >, "Gilles.Moury at cnes.fr" > > Cc: Daniel Fischer/esoc/ESA >, "David.Koisser at esa.int" >, "John P. Lucas" > > Subject: Cloud Action Response > > For CESG / Plenary today…. > > Let me know if we should distribute to the sea-sec and sdls distro lists as well. > > Brandon Bailey > NASA IV&V > Got Secure Code? - https://nen.nasa.gov/web/coding > 304-629-8992 > brandon.t.bailey at nasa.gov > > > > _______________________________________________ > Sea-sec mailing list > Sea-sec at mailman.ccsds.org > http://mailman.ccsds.org/mailman/listinfo/sea-sec From craig.biggerstaff at nasa.gov Thu Apr 14 18:35:10 2016 From: craig.biggerstaff at nasa.gov (Biggerstaff, Craig (JSC-CD221)[LOCKHEED MARTIN CORP]) Date: Thu, 14 Apr 2016 18:35:10 +0000 Subject: [Sls-sea-dls] SDLS Green Book drawings Message-ID: <321CDC5F015F3B418419F05A79B668BA1C06E2D8@NDJSMBX101.ndc.nasa.gov> Dear Ignacio and all WG members, Attached is the Visio file for all the drawings I have contributed to the 350.5 SDLS Green Book so far, except for the ones that are duplicates from the 355.0 Blue Book. Please review especially the drawing named "Generic Rcv"; it is new, and answers my action from Cleveland to provide Ignacio with a receiving-end counterpart of the generic "factory" diagram already in the GB draft. If you see any errors, please let me know. (The other diagrams have been given minor edits for graphical consistency, but no modification of the overall flow.) Best regards, Craig JSC Security Analysis & Response Team 2101 NASA Parkway, Mail Code CD22, Houston, TX 77058 281-483-2027 File attachment: 350x5g1 drawings.vsd The file attached to this email was removed because the file extension is not allowed. -------------- next part -------------- An HTML attachment was scrubbed... URL: From craig.biggerstaff at nasa.gov Thu Apr 14 18:41:09 2016 From: craig.biggerstaff at nasa.gov (Biggerstaff, Craig (JSC-CD221)[LOCKHEED MARTIN CORP]) Date: Thu, 14 Apr 2016 18:41:09 +0000 Subject: [Sls-sea-dls] RE: SDLS Green Book drawings In-Reply-To: <321CDC5F015F3B418419F05A79B668BA1C06E2D8@NDJSMBX101.ndc.nasa.gov> References: <321CDC5F015F3B418419F05A79B668BA1C06E2D8@NDJSMBX101.ndc.nasa.gov> Message-ID: <321CDC5F015F3B418419F05A79B668BA1C06E303@NDJSMBX101.ndc.nasa.gov> Oops - I had forgotten that CCSDS mailing lists strip off any Visio attachments. Here is a PNG version of the new diagram for your amusement. From: sls-sea-dls-bounces at mailman.ccsds.org [mailto:sls-sea-dls-bounces at mailman.ccsds.org] On Behalf Of Biggerstaff, Craig (JSC-CD221)[LOCKHEED MARTIN CORP] Sent: Thursday, April 14, 2016 1:35 PM To: Ignacio.Aguilar.Sanchez at esa.int; sls-sea-dls at mailman.ccsds.org Subject: [Sls-sea-dls] SDLS Green Book drawings Dear Ignacio and all WG members, Attached is the Visio file for all the drawings I have contributed to the 350.5 SDLS Green Book so far, except for the ones that are duplicates from the 355.0 Blue Book. Please review especially the drawing named "Generic Rcv"; it is new, and answers my action from Cleveland to provide Ignacio with a receiving-end counterpart of the generic "factory" diagram already in the GB draft. If you see any errors, please let me know. (The other diagrams have been given minor edits for graphical consistency, but no modification of the overall flow.) Best regards, Craig JSC Security Analysis & Response Team 2101 NASA Parkway, Mail Code CD22, Houston, TX 77058 281-483-2027 File attachment: 350x5g1 drawings.vsd The file attached to this email was removed because the file extension is not allowed. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 350x5g1 Generic Rcv drawing.png Type: image/png Size: 44651 bytes Desc: 350x5g1 Generic Rcv drawing.png URL: From Daniel.Fischer at esa.int Sun Apr 17 11:13:24 2016 From: Daniel.Fischer at esa.int (Daniel.Fischer at esa.int) Date: Sun, 17 Apr 2016 13:13:24 +0200 Subject: [Sls-sea-dls] Key Verification using CRC Message-ID: <7573_1460891604_57136FD4_7573_170_1_OF8326DFD5.1D079D15-ONC1257F98.003D1987-C1257F98.003DA5FC@esa.int> 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 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: From Bruno.Saba at cnes.fr Mon Apr 18 13:48:31 2016 From: Bruno.Saba at cnes.fr (Saba Bruno) Date: Mon, 18 Apr 2016 13:48:31 +0000 Subject: [Sls-sea-dls] Key Verification using CRC In-Reply-To: <7573_1460891604_57136FD4_7573_170_1_OF8326DFD5.1D079D15-ONC1257F98.003D1987-C1257F98.003DA5FC@esa.int> References: <7573_1460891604_57136FD4_7573_170_1_OF8326DFD5.1D079D15-ONC1257F98.003D1987-C1257F98.003DA5FC@esa.int> Message-ID: <4F8A39C783C1444CA8BCE39101536CFE4924BD79@TW-MBX-P01.cnesnet.ad.cnes.fr> 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 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: From craig.biggerstaff at nasa.gov Mon Apr 18 14:02:25 2016 From: craig.biggerstaff at nasa.gov (Biggerstaff, Craig (JSC-CD221)[LOCKHEED MARTIN CORP]) Date: Mon, 18 Apr 2016 14:02:25 +0000 Subject: [Sls-sea-dls] Key Verification using CRC In-Reply-To: <7573_1460891604_57136FD4_7573_170_1_OF8326DFD5.1D079D15-ONC1257F98.003D1987-C1257F98.003DA5FC@esa.int> References: <7573_1460891604_57136FD4_7573_170_1_OF8326DFD5.1D079D15-ONC1257F98.003D1987-C1257F98.003DA5FC@esa.int> Message-ID: <321CDC5F015F3B418419F05A79B668BA1C06EB14@NDJSMBX101.ndc.nasa.gov> I think it depends on the threat against which key verification is intended to protect. If the threat is intentional tampering (however that might be carried out), then CRC verification is insufficient; an attacker easily could create a substitute key with CRC matching the original, if he knew it was necessary to match it. But if the threat is merely a failure in onboard key storage, then CRC verification should still provide reasonably high confidence that the key onboard is the same as what was sent. The OTAR directive already protects keys during transmission from the ground. Craig From: sls-sea-dls-bounces at mailman.ccsds.org [mailto:sls-sea-dls-bounces at mailman.ccsds.org] On Behalf Of Daniel.Fischer at esa.int Sent: Sunday, April 17, 2016 6:13 AM To: sls-sea-dls at mailman.ccsds.org Subject: [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 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: From Howard.Weiss at parsons.com Mon Apr 18 17:27:29 2016 From: Howard.Weiss at parsons.com (Weiss, Howard) Date: Mon, 18 Apr 2016 17:27:29 +0000 Subject: [Sls-sea-dls] Key Verification using CRC In-Reply-To: <4F8A39C783C1444CA8BCE39101536CFE4924BD79@TW-MBX-P01.cnesnet.ad.cnes.fr> References: <7573_1460891604_57136FD4_7573_170_1_OF8326DFD5.1D079D15-ONC1257F98.003D1987-C1257F98.003DA5FC@esa.int>, <4F8A39C783C1444CA8BCE39101536CFE4924BD79@TW-MBX-P01.cnesnet.ad.cnes.fr> Message-ID: 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Gilles.Moury at cnes.fr Tue Apr 19 08:46:10 2016 From: Gilles.Moury at cnes.fr (Moury Gilles) Date: Tue, 19 Apr 2016 08:46:10 +0000 Subject: [Sls-sea-dls] Key Verification using CRC In-Reply-To: References: <7573_1460891604_57136FD4_7573_170_1_OF8326DFD5.1D079D15-ONC1257F98.003D1987-C1257F98.003DA5FC@esa.int>, <4F8A39C783C1444CA8BCE39101536CFE4924BD79@TW-MBX-P01.cnesnet.ad.cnes.fr> Message-ID: <442F062EBF46F247A96B8A50EF3EB6F42A22127F@TW-MBX-P04.cnesnet.ad.cnes.fr> 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Daniel.Fischer at esa.int Tue Apr 19 09:24:00 2016 From: Daniel.Fischer at esa.int (Daniel.Fischer at esa.int) Date: Tue, 19 Apr 2016 11:24:00 +0200 Subject: [Sls-sea-dls] Key Verification using CRC In-Reply-To: <442F062EBF46F247A96B8A50EF3EB6F42A22127F@TW-MBX-P04.cnesnet.ad.cnes.fr> References: <7573_1460891604_57136FD4_7573_170_1_OF8326DFD5.1D079D15-ONC1257F98.003D1987-C1257F98.003DA5FC@esa.int>, <4F8A39C783C1444CA8BCE39101536CFE4924BD79@TW-MBX-P01.cnesnet.ad.cnes.fr> <442F062EBF46F247A96B8A50EF3EB6F42A22127F@TW-MBX-P04.cnesnet.ad.cnes.fr> Message-ID: <17516_1461057843_5715F933_17516_93_1_OF0B65448C.2C2287DA-ONC1257F9A.00337A04-C1257F9A.0033A2F7@esa.int> Dear all, I checked as well with our internal expert who provided the suggestion to change the key verification in the first place He is fine with the suggested change as well. Thus I would suggest we adopt it. 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: "Moury Gilles" To: "Weiss, Howard" , "Saba Bruno" , "Daniel.Fischer at esa.int" , "sls-sea-dls at mailman.ccsds.org" Date: 19/04/2016 10:46 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. 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: From Ignacio.Aguilar.Sanchez at esa.int Tue Apr 19 09:31:21 2016 From: Ignacio.Aguilar.Sanchez at esa.int (Ignacio.Aguilar.Sanchez at esa.int) Date: Tue, 19 Apr 2016 11:31:21 +0200 Subject: [Sls-sea-dls] Key Verification using CRC In-Reply-To: <442F062EBF46F247A96B8A50EF3EB6F42A22127F@TW-MBX-P04.cnesnet.ad.cnes.fr> References: <7573_1460891604_57136FD4_7573_170_1_OF8326DFD5.1D079D15-ONC1257F98.003D1987-C1257F98.003DA5FC@esa.int>, <4F8A39C783C1444CA8BCE39101536CFE4924BD79@TW-MBX-P01.cnesnet.ad.cnes.fr> <442F062EBF46F247A96B8A50EF3EB6F42A22127F@TW-MBX-P04.cnesnet.ad.cnes.fr> Message-ID: <26721_1461058286_5715FAEE_26721_202_1_OFD1F46ED7.B991937C-ONC1257F9A.00341ECC-C1257F9A.00344F41@esa.int> Following Daniel's and Craig's e-mails, I agree with Bruno's proposal. Kind regards, Ignacio (Embedded image moved to file: pic19718.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: "Moury Gilles" To: "Weiss, Howard" , "Saba Bruno" , "Daniel.Fischer at esa.int" , "sls-sea-dls at mailman.ccsds.org" Date: 19/04/2016 10:47 Subject: RE: [Sls-sea-dls] Key Verification using CRC Sent by: sls-sea-dls-bounces at mailman.ccsds.org 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. -------------- next part -------------- A non-text attachment was scrubbed... Name: pic19718.jpg Type: image/jpeg Size: 2001 bytes Desc: not available URL: From craig.biggerstaff at nasa.gov Tue Apr 19 13:49:01 2016 From: craig.biggerstaff at nasa.gov (Biggerstaff, Craig (JSC-CD221)[LOCKHEED MARTIN CORP]) Date: Tue, 19 Apr 2016 13:49:01 +0000 Subject: [Sls-sea-dls] Key Verification using CRC In-Reply-To: <442F062EBF46F247A96B8A50EF3EB6F42A22127F@TW-MBX-P04.cnesnet.ad.cnes.fr> References: <7573_1460891604_57136FD4_7573_170_1_OF8326DFD5.1D079D15-ONC1257F98.003D1987-C1257F98.003DA5FC@esa.int>, <4F8A39C783C1444CA8BCE39101536CFE4924BD79@TW-MBX-P01.cnesnet.ad.cnes.fr> <442F062EBF46F247A96B8A50EF3EB6F42A22127F@TW-MBX-P04.cnesnet.ad.cnes.fr> Message-ID: <321CDC5F015F3B418419F05A79B668BA1C06EDFA@NDJSMBX101.ndc.nasa.gov> 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 ; Saba Bruno ; 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Daniel.Fischer at esa.int Wed Apr 20 06:39:44 2016 From: Daniel.Fischer at esa.int (Daniel.Fischer at esa.int) Date: Wed, 20 Apr 2016 08:39:44 +0200 Subject: [Sls-sea-dls] Key Verification using CRC & OTAR Issue In-Reply-To: <321CDC5F015F3B418419F05A79B668BA1C06EDFA@NDJSMBX101.ndc.nasa.gov> References: <7573_1460891604_57136FD4_7573_170_1_OF8326DFD5.1D079D15-ONC1257F98.003D1987-C1257F98.003DA5FC@esa.int>, <4F8A39C783C1444CA8BCE39101536CFE4924BD79@TW-MBX-P01.cnesnet.ad.cnes.fr> <442F062EBF46F247A96B8A50EF3EB6F42A22127F@TW-MBX-P04.cnesnet.ad.cnes.fr> <321CDC5F015F3B418419F05A79B668BA1C06EDFA@NDJSMBX101.ndc.nasa.gov> Message-ID: <7847_1461134388_57172433_7847_5585_1_OF7597FB05.0CB07C5C-ONC1257F9B.00230177-C1257F9B.002498D2@esa.int> 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]" To: "Moury Gilles" , "Weiss, Howard" , "Saba Bruno" , "Daniel.Fischer at esa.int" , "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 ; Saba Bruno ; 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ignacio.Aguilar.Sanchez at esa.int Wed Apr 20 07:38:27 2016 From: Ignacio.Aguilar.Sanchez at esa.int (Ignacio.Aguilar.Sanchez at esa.int) Date: Wed, 20 Apr 2016 09:38:27 +0200 Subject: [Sls-sea-dls] Key Verification using CRC & OTAR Issue In-Reply-To: <7847_1461134388_57172433_7847_5585_1_OF7597FB05.0CB07C5C-ONC1257F9B.00230177-C1257F9B.002498D2@esa.int> References: <7573_1460891604_57136FD4_7573_170_1_OF8326DFD5.1D079D15-ONC1257F98.003D1987-C1257F98.003DA5FC@esa.int>, <4F8A39C783C1444CA8BCE39101536CFE4924BD79@TW-MBX-P01.cnesnet.ad.cnes.fr> <442F062EBF46F247A96B8A50EF3EB6F42A22127F@TW-MBX-P04.cnesnet.ad.cnes.fr> <321CDC5F015F3B418419F05A79B668BA1C06EDFA@NDJSMBX101.ndc.nasa.gov> <7847_1461134388_57172433_7847_5585_1_OF7597FB05.0CB07C5C-ONC1257F9B.00230177-C1257F9B.002498D2@esa.int> Message-ID: <5881_1461137912_571731F8_5881_1107_1_OF1D550811.71C93457-ONC1257F9B.0026D717-C1257F9B.0029F924@esa.int> 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]" Cc: "sls-sea-dls at mailman.ccsds.org" , sls-sea-dls-bounces at mailman.ccsds.org, "Weiss, Howard" , "Saba Bruno" , "Moury Gilles" 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]" To: "Moury Gilles" , "Weiss, Howard" , "Saba Bruno" , "Daniel.Fischer at esa.int" , "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 ; Saba Bruno ; 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. -------------- next part -------------- A non-text attachment was scrubbed... Name: pic30836.jpg Type: image/jpeg Size: 2001 bytes Desc: not available URL: From Gilles.Moury at cnes.fr Wed Apr 20 08:37:28 2016 From: Gilles.Moury at cnes.fr (Moury Gilles) Date: Wed, 20 Apr 2016 08:37:28 +0000 Subject: [Sls-sea-dls] Key Verification using CRC & OTAR Issue In-Reply-To: <5881_1461137912_571731F8_5881_1107_1_OF1D550811.71C93457-ONC1257F9B.0026D717-C1257F9B.0029F924@esa.int> References: <7573_1460891604_57136FD4_7573_170_1_OF8326DFD5.1D079D15-ONC1257F98.003D1987-C1257F98.003DA5FC@esa.int>, <4F8A39C783C1444CA8BCE39101536CFE4924BD79@TW-MBX-P01.cnesnet.ad.cnes.fr> <442F062EBF46F247A96B8A50EF3EB6F42A22127F@TW-MBX-P04.cnesnet.ad.cnes.fr> <321CDC5F015F3B418419F05A79B668BA1C06EDFA@NDJSMBX101.ndc.nasa.gov> <7847_1461134388_57172433_7847_5585_1_OF7597FB05.0CB07C5C-ONC1257F9B.00230177-C1257F9B.002498D2@esa.int> <5881_1461137912_571731F8_5881_1107_1_OF1D550811.71C93457-ONC1257F9B.0026D717-C1257F9B.0029F924@esa.int> Message-ID: <442F062EBF46F247A96B8A50EF3EB6F42A2228B3@TW-MBX-P04.cnesnet.ad.cnes.fr> 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]" Cc: "sls-sea-dls at mailman.ccsds.org" , sls-sea-dls-bounces at mailman.ccsds.org, "Weiss, Howard" , "Saba Bruno" , "Moury Gilles" 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]" To: "Moury Gilles" , "Weiss, Howard" , "Saba Bruno" , "Daniel.Fischer at esa.int" , "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 ; Saba Bruno ; 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. From Gilles.Moury at cnes.fr Fri Apr 29 08:59:00 2016 From: Gilles.Moury at cnes.fr (Moury Gilles) Date: Fri, 29 Apr 2016 08:59:00 +0000 Subject: [Sls-sea-dls] TR: [Cesg-all] CCSDS Technical Meeting Spring 2016-2017 Dates Message-ID: <442F062EBF46F247A96B8A50EF3EB6F42A22D978@TW-MBX-P04.cnesnet.ad.cnes.fr> Dear CCSDS SDLS WG member, As requested by the CESG chair, I forward to you the dates for the next two CCSDS technical meetings: Fall 2016: October 17-21, 2016 at ASI in Rome, Italy Spring 2017: May 8-12, 2017 at Southwest Research Institute, in San Antonio, Texas, USA Best regards, Gilles MOURY SDLS WG Co-Chair De : cesg-all-bounces at mailman.ccsds.org [mailto:cesg-all-bounces at mailman.ccsds.org] De la part de Nestor.Peccia at esa.int Envoyé : jeudi 28 avril 2016 16:00 À : CCSDS Engineering Steering Group - CESG All Objet : [Cesg-all] CCSDS Technical Meeting Spring 2017 Dates Dear all. herewith I would like to inform you about the CMC decision for the dates of the CCSDS Technical Meeting Spring 2017, to be hosted by the Southwest Research Institute, San Antonio, Texas, USA 1. Technical Meeting 8th May 2017 - 12th May 2017 1. CESG Meeting 15th May 2017 You will find attached all constraints considered during March / April / May 2017 i.e. 1. GSAW 1. Mid March is too early for meetings 1. IETF 1. ITU 1. Jewish and Easter Holidays 1. Fiesta in San Antonio 1. NAB Meeting 1. Japan Golden Week 1. European Holidays 1. Space Ops 2018 grand meeting 1. 1. The SwRI representative (Mike Epperly) was present at the CMC meeting and gave the attached presentation. I would like to ask all Chairs to distribute this within their WG members ciao Nestor 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: Spring 17 Meeting Schedule & Constraints.xls Type: application/vnd.ms-excel Size: 65536 bytes Desc: Spring 17 Meeting Schedule & Constraints.xls URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: CCSDS Spring 2017 Technical Meetings SwRI.pptx Type: application/octet-stream Size: 2054282 bytes Desc: CCSDS Spring 2017 Technical Meetings SwRI.pptx URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ATT00001.txt URL: From Gilles.Moury at cnes.fr Fri Apr 29 14:11:52 2016 From: Gilles.Moury at cnes.fr (Moury Gilles) Date: Fri, 29 Apr 2016 14:11:52 +0000 Subject: [Sls-sea-dls] CCSDS SDLS WG Minutes of Meeting, April 2016 Message-ID: <442F062EBF46F247A96B8A50EF3EB6F42A22DCF6@TW-MBX-P04.cnesnet.ad.cnes.fr> Dear SDLS WG member, Please find attached the draft minutes (with attachments) of our last meeting in Cleveland, for your comments: Best regards, Gilles Moury SDLS WG Co--Chair Gilles MOURY CNES Toulouse Expert senior "Plateforme Satellite" Sous-Direction "Techniques Véhicule, Architecture & Intégration" DCT/TV-RA - Bpi 1416 18, avenue Edouard Belin F-31401 TOULOUSE Cedex 9 http://www.cnes.fr tel : +33 (0)5 61 27 3790 fax : +33 (0)5 61 27 4099 sec : +33 (0)5 61 27 3882 mob : +33 (0)6 83 56 0485 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SDLS WG MoM - Apr2016.docx Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document Size: 74575 bytes Desc: SDLS WG MoM - Apr2016.docx URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SDLS April 2016 MoM attachment.7z Type: application/octet-stream Size: 5109760 bytes Desc: SDLS April 2016 MoM attachment.7z URL: From Gilles.Moury at cnes.fr Fri Apr 29 14:34:30 2016 From: Gilles.Moury at cnes.fr (Moury Gilles) Date: Fri, 29 Apr 2016 14:34:30 +0000 Subject: [Sls-sea-dls] SDLS WG : our upcoming telecons Message-ID: <442F062EBF46F247A96B8A50EF3EB6F42A22DDB1@TW-MBX-P04.cnesnet.ad.cnes.fr> Dear SDLS WG member, This mail to recall our 2 next webex/telecon as scheduled during the Cleveland meeting : - 26 May, 15:00 CEST : Objective : finalization of Extended Procedures White Book - 24 June, 15:00 CEST : Objective : finalization of SDLS Core Protocol Green Book In the mean time, a number of action items from our meeting (see attached MoM) need to be completed so we can reach our objectives. I hope actionees will find some time to progress them. Best regards, Gilles Gilles MOURY SDLS WG Co-Chair Gilles MOURY CNES Toulouse Expert senior "Plateforme Satellite" Sous-Direction "Techniques Véhicule, Architecture & Intégration" DCT/TV-RA - Bpi 1416 18, avenue Edouard Belin F-31401 TOULOUSE Cedex 9 http://www.cnes.fr tel : +33 (0)5 61 27 3790 fax : +33 (0)5 61 27 4099 sec : +33 (0)5 61 27 3882 mob : +33 (0)6 83 56 0485 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SDLS WG MoM - Apr2016.docx Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document Size: 74575 bytes Desc: SDLS WG MoM - Apr2016.docx URL: