[Sis-dtn] Bundle Signing And Encryption With CMS

Wed Jul 8 11:12:10 UTC 2015

Hello Everyone,

I've wrapped the "rough-around-the-edges" test program into a slightly more
usable variant, which now supports CMS envelope nesting. It is available at:
https://github.com/INSYEN/cmsproxy

Provided the correct command-line incantation, this program acts as a
bi-directional pseudo-tunnel, which will extract the payload block, run
whatever processing steps are required, and spit it out. On the far side,
the receiver will figure out the various CMS contenttypes, perform the
required actions, and send a new bundle to a specified endpoint.

This program now supports:

*	Signing/verifying
*	Compressing/decompressing
*	Encryption/decrypting
*	Diffie-Hellman exchange

Feel free to muck around with it!

As an aside, I was playing with ZLIB compression in CMS, using the U.S.
English dictionary, and had some awesome results... I like graphs, so here
we go!

This was only a test, but just in case we require the transmission of
dictionaries over space-links, we are well-prepared.

Thanks,
Jeremy

  _____  

From: sis-dtn-bounces at mailman.ccsds.org
[mailto:sis-dtn-bounces at mailman.ccsds.org] On Behalf Of Weiss, Howard
Sent: Montag, 6. Juli 2015 18:03
To: Pitts, Robert L. (MSFC-EO50)[HOSC SERVICES CONTRACT];
sis-dtn-bounces at mailman.ccsds.org
Cc: sis-dtn at mailman.ccsds.org
Subject: RE: [Sis-dtn] Bundle Signing And Encryption With CMS

FYI - I just "discovered" the attached MIT Master's Thesis that explored the
use of CMS in constrained networks and means by which overhead can be
reduced using a combination of ZLIB and an invention of CMS-Lite.
Interesting reading.....

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: sis-dtn-bounces at mailman.ccsds.org [sis-dtn-bounces at mailman.ccsds.org]
on behalf of Pitts, Robert L. (MSFC-EO50)[HOSC SERVICES CONTRACT]
[robert.l.pitts at nasa.gov]
Sent: Wednesday, July 01, 2015 2:31 PM
To: sis-dtn-bounces at mailman.ccsds.org
Cc: sis-dtn at mailman.ccsds.org
Subject: RE: [Sis-dtn] Bundle Signing And Encryption With CMS

I have been engaged in this activity for a while and have been listening to
the dialog.  I have not injected anything until this point because I am
trying to keep an open mind based on my experiences.  This includes low
overhead requirements and access requirements to infrastructure.  This
includes not only space systems like the ISS but also mirco and nano systems
whether spacebourne or seagoing systems and the like which may not routinely
check in.   I also am trying to reconcile the need for systems that drop
through different levels of protections and strips off layers of security to
maintain access as it goes deeper into protective modes.

All of these items push for simplicity which may be irreconcilable when
viewed with larger, more complex, and elaborate systems.

Lee

From: sis-dtn-bounces at mailman.ccsds.org
[mailto:sis-dtn-bounces at mailman.ccsds.org] On Behalf Of Scott, Keith L.
Sent: Tuesday, June 30, 2015 12:48 PM
To: Weiss, Howard; Mayer, Jeremy P. (JSC-OT/ESA)[EUROPEAN SPACE AGENCY];
sis-dtn at mailman.ccsds.org; Stephen Farrell; Edward Birrane
Subject: Re: [Sis-dtn] Bundle Signing And Encryption With CMS

Seconded, thanks Jeremy!

I think our big question is how to structure the security encapsulation(s),
in particular where the CMS 'wrapper' bits show up w.r.t. the block header
and block content.  As I understand it, your payload implementation is
essentially the 'CMS wraps block content' approach and you just know at the
receiver to undo that on receipt.  Ed had some concerns about the 'XXX eats
block' approach and in particular what happens when I want to assign the
integrity value HERE and implement confidentiality over THERE.  I'd like to
fully understand those, especially in light of CMS' explicit ability to
allow nested operations.

Just to suggest an approach, what if we go with the 'CMS Eats block content'
approach and (as I think Scott suggested) snag a bit in the block processing
control flags (ok, thereby increasing it to two bytes, ugh!) to indicate
that the block content is 'security-enabled' (i.e. A CMS-wrapped thing).
The CMS structure has an object identifier that identifies the content
information type, and the intro to the RFC explicitly talks about nested
operations, so we could impose integrity and security separately; we use
Bundle-in-bundle-encapsulation (pronounced 'tunneling') to decouple routing
and we're done except for the primary bundle block (because it needs its own
separate bit flag definition, and because we need to deal with mutability
there).

Pros

*	overall bundle block structure left alone 

*	allows for per-block granularity 

*	Could implement 'outer' signatures of all blocks for BAB-like
service?

Cons

*	per-block overhead 

*	It seems like it would be worth investigating a CMS implementation /
cipher suite so that multiple CMS-protected blocks referenced some sort of
common block containing key material, but such a block type would be easy
enough to define, I'd think.

*	'BAB-like' signature applied separately to all blocks would increase
overhead (even with a 'common key material' block type) - argues for 'secure
CL' approach? 

*	Content types are OIDs in the 1.2.840.113549.1 space (overhead)

If we were to like this (or, more specifically, whatever we DO end up
liking) I think we then need to try real hard to sell that to the IETF, and
preferably before they get too far down the path of security protocol
definition.  Either we're right and they'll like it too or we're missing
something.

I found this link[vocal.com]
<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.vocal.com_secure-2D
communication_cryptographic-2Dmessage-2Dsyntax-2Dcms_&d=BQMGaQ&c=Nwf-pp4xtYR
e0sCRVM8_LWH54joYF7EKmrYIdfxIq10&r=dT3K0y3n0RD9-56k-UVMPMP98PIQRd2Kzfa-AwqQO
ww&m=2UqU47bTvHvEWZLPWSqZ4NzMBUs4uSprRcOXFOD5eOc&s=eM-yjUU3v2FTAKVDYbIfDOLrw
Y0g8BelHq4uxYYLS5Q&e=>  (with the pictures below) sort of helpful.

-keith

From: "sis-dtn-bounces at mailman.ccsds.org" on behalf of Howie Weiss
Date: Tuesday, June 30, 2015 at 8: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
www.parsons.com

Please consider the environment before printing this message

  _____  

From: 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
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:

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:

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/20150708/c28deef7/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Outlook.jpg
Type: image/jpeg
Size: 48271 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20150708/c28deef7/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 96162 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20150708/c28deef7/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 59257 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20150708/c28deef7/attachment-0001.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.jpg
Type: image/jpeg
Size: 49880 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20150708/c28deef7/attachment-0002.jpg>