[Sis-dtn] [EXT] RE: SIS-DTN BPsec Profile

Tue Nov 22 21:40:28 UTC 2022

In principle, following NIST guidelines..

A one-way, cryptographic hash algorithm maps arbitrarily long inputs into a fixed-size output such that it is very difficult (computationally infeasible) to find two different hash inputs that produce the same output. 

Approved hash algorithms (e.g., SHA-384) can be used to indicate the integrity of the data. However, since any entity that has access to the data could have computed the integrity value, it does not provide any authentication. 

An approved keyed Hash Message Authentication Code (HMAC) utilizes a symmetric (secret) key. It authenticates the integrity of the data since a symmetric key was utilized, but does not provide provenance (anyone possessing the symmetric key in the network could have potentially changed the underlying data and calculated the HMAC value). 

In this context, provenance is defined as: The chronology and ownership of the associated data.

An approved digital signature algorithm (e.g., ECDSA P-384) will provide provenance since it utilizes private/public keys. With ECDSA the hash of the payload data is used in generating the signature. Thus, we can infer the integrity, authenticity and the provenance of the data with digital signatures

v/r,

mehmet

From: SIS-DTN <sis-dtn-bounces at mailman.ccsds.org> on behalf of "Dr. Keith L Scott via SIS-DTN" <sis-dtn at mailman.ccsds.org>
Reply-To: "Dr. Keith L Scott" <kscott at mitre.org>
Date: Tuesday, November 22, 2022 at 1:07 PM
To: "sburleig.sb at gmail.com" <sburleig.sb at gmail.com>, "sis-dtn at mailman.ccsds.org" <sis-dtn at mailman.ccsds.org>, "sea-sec at mailman.ccsds.org" <sea-sec at mailman.ccsds.org>
Cc: 'Peter Shames' <peter.shames at jpl.nasa.gov>
Subject: Re: [Sis-dtn] [EXT] RE: SIS-DTN BPsec Profile

Yeah, I think that’s mostly right.  I’d add ‘if I exchange a shared secret with the peer out-of-band’ then I can get integrity (if they encrypt something in that shared secret and it decrypts correctly (assuming I can KNOW that) then they are the one who encrypted it).

                                --keith

From: sburleig.sb at gmail.com <sburleig.sb at gmail.com>
Date: Tuesday, November 22, 2022 at 2:33 PM
To: Dr. Keith L Scott <kscott at mitre.org>, sis-dtn at mailman.ccsds.org <sis-dtn at mailman.ccsds.org>, sea-sec at mailman.ccsds.org <sea-sec at mailman.ccsds.org>
Cc: 'Peter Shames' <peter.shames at jpl.nasa.gov>
Subject: [EXT] RE: [Sis-dtn] SIS-DTN BPsec Profile

My sense of integrity vs authority, which may well be wildly wrong, is that integrity can be provided by a checksum or CRC or by a signature computed in a symmetric key that everybody knows, but authority can only be provided by a signature computed in the sender’s private key (verified in the sender’s known public key).  I strongly suspect it’s not that simple, though.

Scott

From: SIS-DTN <sis-dtn-bounces at mailman.ccsds.org> On Behalf Of Dr. Keith L Scott via SIS-DTN
Sent: Tuesday, November 22, 2022 11:04 AM
To: sis-dtn at mailman.ccsds.org; sea-sec at mailman.ccsds.org
Cc: Peter Shames <peter.shames at jpl.nasa.gov>
Subject: [Sis-dtn] SIS-DTN BPsec Profile

Greetings,

We have a joint meeting scheduled on Friday Dec 2.  This is nominally one of the monthly meetings to discuss the new BPsec Green Book, but I’d like to propose taking the December 2 meeting to discuss the BPsec Blue Book Profile.

I had a discussion w/ Howie the other day that resulted in a number of changes to the document:

Authenticity

Antonias had several comments around authenticity and whether or not it made any sense to provide integrity without authenticity.  I could envision a mission that wanted to provide data integrity on the science data it was returning, but might not need/want to provide authenticity.  The assumption here would be (I suppose) that it wouldn’t make sense for anyone to fake the data (e.g. a faked image purportedly from Pluto Express showing a sign on the surface “I want to be a planet again.”?)

That said, it seems like the services missions might want to choose from / implement are:
Integrity
Authenticity
Confidentiality

[I’ll admit to being a bit confused by this; MY model for authenticity would be to use some sort of signed hash on the primary bundle block (which includes the source EID), though I suppose other mechanisms are possible].

In the document I tried to use “authenticity / integrity” where appropriate, and to otherwise mention authenticity where I thought it was appropriate.  I’d be interested if folks think I got close to right.

I still need to add some text around the ‘pick-list’ notion of integrity / authenticity / confidentiality above.

Security Contexts

I added some text about security contexts and moved other text around so that security contexts now show up earlier than they used to.

Default Security Contexts

RFC9173 contains a set of default security contexts for BPsec:
Integrity Security Context BIB-HMAC-SHA2
Security Context BCB-AES-GCM

I think the questions I’d like to get at at next week’s telecon is:
Do we need a set of default security contexts for the CCSDS Profile of BPsec?
I think so.  Maybe not even mandatory to implement but at least a defined set that can be used for testing?
If the answer to the above is in fact ‘yes’ – what should we use for the default profiles?  The current book has (I think) essentially RCC9172 pulled in, but then it looks like somebody (apologies, the changes are only marked as ‘Author’) seems to have suggested changing some of the recommended key sizes.
So, if we could at least start talking about a nominal set of security contexts for the profile I think that would get us a LOT further down the road to getting the book out.

                                v/r,

                                --keith

_______________________________________________ SIS-DTN mailing list SIS-DTN at mailman.ccsds.org https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-dtn 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20221122/cb26eec2/attachment-0001.htm>