1

Document StatusDocument StatusCCSDS Security Working GroupCCSDS Security Working Group

March 2008March 2008

2

AGENDAAGENDA• Document Status

– Security Green Book wording revisions– Security Architecture– Key Management– Mission Planners Guide– Encryption– Authentication

» Proposals for HMAC replacement?

3

Security Green Book RevisionsSecurity Green Book RevisionsSection 4.2 Authentication Many digital signature generation mechanisms require the use of an asymmetric cryptographic algorithm where sender and receiver do not hold the same cryptographic keys (as described in 4.1). Rather, a pair of public and private keys that are mathematically related to one another are used. At the origin of the data, the cryptographic algorithm generates a digital signature using the sender’s private key. The signature may be generated from the data itself and is of a specific length depending on the algorithm used. Data origin authentication is achieved when the digital signature is successfully verified by the receiver using the sender’s public key. Remove this section: Encryption of the data itself can also provide implicit authentication when using a symmetric cryptographic algorithm. Authentication is achieved because the recipient must have and use the correct key to decipher the digital signature appended to the data. This assumes there is an assured key distribution mechanism. Also, encryption provides implicit authentication when using an asymmetric (public key) system if there is assurance that the public key is bound to the originator (e.g., signed by a certificate authority). However, caution must be used because authentication may be compromised if the encrypted data is captured and later replayed without replay protection. Add this section: Alternatively, a Message Authentication Code (MAC) may be used with a symmetric shared secret to achieve authentication. This may be accomplished by the use of a hash algorithm (e.g., SHA-1, SHA-256, RIPE-MD) over data which has been concatenated with the shared secret. Alternatively, a hash may be generated over data and then the resulting hash word (sometimes called a message digest), is encrypted using the shared secret.

4

Revisions per teleconRevisions per teleconSection 4.2 Authentication Many digital signature generation mechanisms require the use of an asymmetric cryptographic algorithm where sender and receiver do not hold the same cryptographic keys (as described in 4.1). Rather, a pair of public and private keys that are mathematically related to one another are used. At the origin of the data, the cryptographic algorithm generates a digital signature using the sender’s private key. The signature may be generated from the data itself and is of a specific length depending on the algorithm used. Data origin authentication is achieved when the digital signature is successfully verified by the receiver using the sender’s public key. Remove this entire section: Encryption of the data itself can also provide implicit authentication when using a symmetric cryptographic algorithm. Authentication is achieved because the recipient must have and use the correct key to decipher the digital signature appended to the data. This assumes there is an assured key distribution mechanism. Also, encryption provides implicit authentication when using an asymmetric (public key) system if there is assurance that the public key is bound to the originator (e.g., signed by a certificate authority). However, caution must be used because authentication may be compromised if the encrypted data is captured and later replayed without replay protection. Add this section: Alternatively, a Message Authentication Code (MAC) may be used with a symmetric shared secret to achieve authentication. This may be accomplished by the use of a hash algorithm (e.g., SHA-1, SHA-256, RIPE-MD-160) or a cipher-based algorithm (e.g., CMAC, CBC-MAC, XCBC, OMAC) over data which has been concatenated with the shared secret. Alternatively, a hash may be generated over data and then the resulting hash word (sometimes called a message digest), is encrypted using the shared secret.

Rationale: Add words about cipher-based MAC

5

Security Green Book Revisions (cont)Security Green Book Revisions (cont)Section 5.2 Bulk Encryption Current section: Bulk encryption provides confidentiality to all of the communication system data structure. It is implemented at the physical layer and provides the highest possible level of data confidentiality available on a point-to-point basis—often this is termed “link encryption.” However, this is not to imply encryption at the link layer but rather over the physical link. No separate integrity, authentication or access control services are implied other than those implicitly provided by encryption. For example, if symmetric key encryption is used, authentication is implicitly achieved, because the receiving end must have the correct key, which has been distributed by an assured key distribution system, in order to decipher the data. Proposed new section: Bulk encryption provides confidentiality to all of the communication system data structure. It is implemented at the physical layer and provides the highest possible level of data confidentiality available on a point-to-point basis – often this is termed “link encryption.” However, this is not to imply encryption at the link layer but rather over the physical link. Via secure key management, a form of authentication can be achieved with bulk encryption. If the only entities sharing a key are A and B share a secret, and if B can decrypt and use data supposedly sent from A, then B can reasonably assume that it could have only come from A. But, this does not provide strong mathematical authentication as would be achieved by the use of a digital signature or a message authentication code (MAC).

Red = Susanna Spinsante changes

6

Revisions per teleconRevisions per teleconSection 5.2 Bulk Encryption Current section: Bulk encryption provides confidentiality to all of the communication system data structure. It is implemented at the physical layer and provides the highest possible level of data confidentiality available on a point-to-point basis—often this is termed “link encryption.” However, this is not to imply encryption at the link layer but rather over the physical link.

Rationale: this section discusses “bulk encryption” so why muddy the waters talking about authentication which has nothing to do with the subject.

7

Green Book ESA CommentsGreen Book ESA CommentsDear all, We have discussed internally again the issue of bulk encryption and implicit authentication in the Green Book. To be crisp and 100% correct from a cryptographic point of view, the following paragraph in question should just be deleted without replacement: "Via secure key management, a form of authentication can be achieved with bulk encryption. If only entities A and B share a secret, and if B can decrypt and use data supposedly sent from A, then B can reasonably assume that it could have only come from A. But, this does not provide strong mathematical authentication as would be achieved by the use of a digital signature or a message authentication code (MAC)." The weakening of the implicit authentication statement using fuzzy and undefined terms like "a form of authentication" and "strong mathematical authentication" is not seen to be a good approach. We may discuss that in the telecon. Daniel Fischer Assistant / Ph.D. student UNIVERSITE DU LUXEMBOURG CAMPUS Kirchberg 6, rue R. Coudenhove-Kalergi L-1359 Luxembourg T +352-466644-5321 F +352-466644-5500 M +49 179 6460648 Daniel.Fischer@uni.lu www.uni.lu www : http://wiki.uni.lu/secan-lab/Daniel+Fischer.html

8

Security ArchitectureSecurity Architecture

Draft Specification Concerning Space Data System Standards

MAGENTA BOOK

Issue 1.8 Draft January 2008

CCSDS Security Working Group

SECURITY ARCHITECTURE FOR

SPACE DATA SYSTEMS

Everyone needs to read the document and provide comments to Nick Shave as soon as possible. Also, please provide agency mission profiles.

9

Key ManagementKey Management

• Implemented changes based on the discussion in Heppenheim.

• Waiting for comments as per action before issuing the next draft.

A request for review and comment had been sent out in Dec. Another reminder will be sent out. Please review and send comments to Daniel Fischer.

10

Mission Planners GuideMission Planners Guide

• 1st draft shown in Heppenheim, Oct. 2007• 2nd draft will be e-mailed to sea-sec list by middle of

Feb. 2008– Will replace 1st draft security plan template with a new

one according to ISO 27002 controls– Will add more material specific to space environment &

CCSDS protocols

11

EncryptionEncryption

• Changes made to the Magenta book per the Heppenheim meeting

• Changes made to the ‘trade survey’ green book• No comments received to date

– Are we ready to send these to the secretariat to be published?

One last chance to look at the “final” documents. Any and all comments to Howie Weiss by 4 Feb 2008. Then documents will be forwarded to the Secretariat for publication.

12

AuthenticationAuthentication

• Changes made per Heppenheim meeting• Awaiting any HMAC replacement proposals.• Changes made to Green Book (‘trade survey’)

– Awaiting comments – none received to date– Are we ready to send this to the secretariat to be

published?

ESA’s study will complete in Feb. Since we’d like to factor in the outcome of that study, we will discuss any replacement proposals for HMAC at the March meetings in Washington. As for the ‘trade survey,’ any final comments should be sent to Howie Weiss by 4 Feb 2008 – the document will then be forwarded to the Secretariat.

13

March MeetingsMarch Meetings

• Plans:– Security implementation experiences with SLE?

» Problems with its use?» How its used?

– Discuss proposed authentication & encryption algorithm application specific parameters

– Review of CCSDS books for security sections» Martin Pilgrim will provide books that need to be reviewed

– As time permits - CC usage to create mission security profiles– Threat review (review issued document)– How do we integrate all the individual docs into something

that someone can really use (knit it all together).– Agency security implementations – how do individual

agencies approach, require, and use security services/mechanisms