[Sis-dtn] Bundle Signing And Encryption With CMS

Wed Jul 1 15:57:19 UTC 2015

Hi Scott,

Certainly the least overhead we manage to bring in the better it is. My question is whether do we have specific space mission requirements (based on the next missions to fly) on the bundle size so that we can have a kind of target for the protocol design. Further to this, I think it would be also worth addressing where security should/could be applied. For instance, if we think of the current uplink used for telecommand, certainly the resources are already so scarce that probably the transport of large digital signatures could become a real issue.

Regards,

Tomaso

------------------------
Deutsches Zentrum für Luft- und Raumfahrt (DLR)
German Aerospace Center
Institute of Communications and Navigation | Satellite Networks | Oberpfaffenhofen | 82234 Wessling | Germany
Tomaso de Cola, Ph.D.
Telefon +49 8153 28-2156 | Telefax  +49 8153 28-2844 | tomaso.decola at dlr.de<mailto:tomaso.decola at dlr.de>
http://www.dlr.de/kn/institut/abteilungen/san

From: sis-dtn-bounces at mailman.ccsds.org [mailto:sis-dtn-bounces at mailman.ccsds.org] On Behalf Of Burleigh, Scott C (312B)
Sent: Tuesday, June 30, 2015 21:07
To: Weiss, Howard; Iannicca, Dennis C. (GRC-LCA0); Mayer, Jeremy; sis-dtn at mailman.ccsds.org
Subject: RE: [Sis-dtn] Bundle Signing And Encryption With CMS

Hi, Howie.  Yes, as I said, I am sure there easy ways to reduce these numbers.

But maybe I'm confused.  My understanding is that a SHA256 digest is 256 bits, 32 bytes.  While that is not trivial, I don't think I'd call it huge; it's a lot less than 686 bytes, and it might be tolerable for 1KB bundles even if not truncated.

Again, as I said, I am by no means saying that CMS is the wrong way to go.  I just want us to bear in mind that the sort of overhead Jeremy was seeing might be a non-starter for some use cases that we might want to support with DTN.

Scott

From: Weiss, Howard [mailto:Howard.Weiss at parsons.com]
Sent: Tuesday, June 30, 2015 11:49 AM
To: Iannicca, Dennis C. (GRC-LCA0); Burleigh, Scott C (312B); Mayer, Jeremy P. (JSC-OT/ESA)[EUROPEAN SPACE AGENCY]; sis-dtn at mailman.ccsds.org<mailto:sis-dtn at mailman.ccsds.org>
Subject: RE: [Sis-dtn] Bundle Signing And Encryption With CMS

Scott

The SHA256 authentication/integrity digest results in a huge overhead regardless of the protocol used.  While we don't usually 'encourage' people to truncate SHA digests, it can be done when wire overhead is a major issue.  See NIST SP 800-107 for info on truncation (http://csrc.nist.gov/publications/nistpubs/800-107-rev1/sp800-107-rev1.pdf)

And as Dennis says, elliptic curve saves many bits over RSA.

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: Iannicca, Dennis C. (GRC-LCA0) [dennis.c.iannicca at nasa.gov]
Sent: Tuesday, June 30, 2015 2:23 PM
To: Burleigh, Scott C (JPL-312B)[Jet Propulsion Laboratory]; Weiss, Howard; Mayer, Jeremy P. (JSC-OT/ESA)[EUROPEAN SPACE AGENCY]; sis-dtn at mailman.ccsds.org<mailto:sis-dtn at mailman.ccsds.org>
Subject: Re: [Sis-dtn] Bundle Signing And Encryption With CMS
On 6/30/15 1:26 PM, "Burleigh, Scott C (312B)" <scott.c.burleigh at jpl.nasa.gov<mailto:scott.c.burleigh at jpl.nasa.gov>> wrote:

I agree, Jeremy, it's terrific that you could do this so quickly.  And I agree that the overheads are not bad, but to my mind they are still a little troubling.  I can imagine an SBSP Block Integrity Block ciphersuite that would use a one-time, randomly generated SHA256 key to generate a SHA256 digest over the payload (shipped in the BIB's results field); would include that key in the BIB's ciphersuite parameters; and would also provide an elliptic-curve digital signature for that key (computed using the sender's private key, to be verified using the sender's pre-placed public key) as an additional ciphersuite parameter.  I think that would come to 256 bits for the SHA256 digest plus 256 bits for the SHA256 key, plus 320 bits for the ECDS, for a total of 832 bits = 104 bytes.  Even allowing for a little additional BIB structural overhead, this is still less than a sixth of the overhead measured for the CMS signing option.

Scott,
CMS would allow you to use ECDSA for signatures in lieu of RSA if you wanted to reduce the overhead seen in these examples.

--
Dennis Iannicca
NASA Glenn Research Center
21000 Brookpark Road, MS 54-1
Cleveland, OH 44135
216-433-6493
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20150701/b57a41eb/attachment.html>