[Sis-dtn] Bundle Signing And Encryption With CMS

[Burleigh, Scott C (312B)]

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.

I am sure there easy ways to reduce these numbers, and I am by no means saying that CMS is the wrong way to go.  I'm just saying that I would like to keep the bar fairly high here, as we can't necessarily count on bundles transmitted over the Solar System Internet being so large that 686 bytes of security overhead is insignificant.

Scott

From: sis-dtn-bounces at mailman.ccsds.org [mailto:sis-dtn-bounces at mailman.ccsds.org] On Behalf Of Weiss, Howard
Sent: Tuesday, June 30, 2015 5:34 AM
To: Jeremy Pierce-Mayer; sis-dtn at mailman.ccsds.org
Subject: RE: [Sis-dtn] Bundle Signing And Encryption With CMS

Jeremy

This is very cool!  Thanks for spinning this up so quickly.  Its very neat that you could use an off-the-shelf standard and open source software to provide bundle security services in such an expedited manner.  And the fact that the overheads are not bad makes it even nicer.

Regards

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: sis-dtn-bounces at mailman.ccsds.org<mailto:sis-dtn-bounces at mailman.ccsds.org> [sis-dtn-bounces at mailman.ccsds.org] on behalf of Jeremy Pierce-Mayer [jeremy.mayer at dlr.de]
Sent: Tuesday, June 30, 2015 6:02 AM
To: sis-dtn at mailman.ccsds.org<mailto:sis-dtn at mailman.ccsds.org>
Subject: [Sis-dtn] Bundle Signing And Encryption With CMS
Hey Everyone,

During the Bundle Security telecom last week, I took the action to wedge the Cryptographic Message Syntax (CMS) into BP, for use in signing and encryption. Here are the results:

Software Implementation:
For this testing, I used a random payload, passed that through the CMS implementation (OpenSSL), using a pre-shared 1024b RSA key in an X509 certificate. The enveloped data was outputted in DER encoding (Base64). It is important to note that this is not S-MIME. The DER-ified data was added as a bundle payload. For future testing, it should be possible to update (or dynamically generate) the X509 stuff, where we can set the FROM/TO addressed to the src/dest EID's.

I ran two tests, signing and verification...

Measurement Methodology:

All of the numbers below were taken from the receiver side. In other words, the "pre-signing/encryption" sizes were based upon successfully decrypting or verifying the data at the end of the pipe.

Results - Signing:
[cid:image001.jpg at 01D0B319.0C8D5E50]

There are two subtests here, one where I carried the CMS signer cert within the data, and one where I didn't. As you can see, the overhead isn't terrible, especially when you consider that (in some of the tests) I was carrying the cert down the wire. You can also stack signer certificates within a single CMS message, though I opted to not do that (for simplicity) until we have a further plan for CMS.

Results - Encryption:
I'm going to prefix this by saying that I really didn't need a graph for this one, but graphs are cool, and if I write enough here, it will look like a proper headline... So, graphs:
[cid:image002.jpg at 01D0B319.0C8D5E50]

Once again, the overhead isn't awful, at 349 bytes.

Where Do We Go From Here:
I have no idea, though I'm tempted to say that this is a discussion for Darmstadt.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20150630/85b81384/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 59257 bytes
Desc: image001.jpg
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20150630/85b81384/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 49880 bytes
Desc: image002.jpg
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20150630/85b81384/attachment-0001.jpg>