1

SecWG New Business DiscussionsSecWG New Business Discussions

CCSDS St-Hubert (Montreal) CanadaCCSDS St-Hubert (Montreal) Canada

Howard WeissNASA/JPL/SPARTA

hsw@sparta.com+1-410-872-1515

May 2004

2

Discussion TopicsDiscussion Topics

• CCSDS documents mandatory security section• Future Standards:

– Encryption– Authentication– Integrity– Key Management

• Future Documents as discussed at last meeting (Fall 2003)

• Others?

3

Mandatory Security SectionMandatory Security Section

• Background: – follow the lead of the Internet Engineering Task Force

(IETF) to mandate a serious “security considerations” section in all CCSDS documents

4

Rejected TextRejected TextRequired in every CCSDS Recommendation, Best Current Practice, and

Experimental Specification is a "Security Considerations" section. This section should describe any known vulnerabilities of the specification, possible threats, and mechanisms or strategies to address them. This section should not be taken lightly -- in particular, this section should not say, "here is the specification technology and it has no security implications." This is inadequate because it doesn't answer the question of how security affects the technology.

Authors MUST describe:• which attacks are out of scope (and why),• which attacks are in-scope,• what the specification technology is susceptible to,• what the specification technology protects against.

At least the following forms of attack MUST be considered: eavesdropping; replay; message insertion, deletion, modification; and man-in-the-middle. Potential denial of service attacks MUST be identified as well. The threat environment addressed by the Security Considerations section MUST, at a minimum, include deployment across multiple administrative boundaries without assuming that other security measures are in place, even if only to provide justification for why such consideration is out of scope.

5

Reasons for RejectionReasons for Rejection

• CESG rejected statement because:– They didn’t know what they were signing up for– What standards did they have to adhere to (e.g.,

encryption)?» If there were an encryption standard, for example,

then they could understand better what would have to be in such a security statement

6

What Was Really DesiredWhat Was Really Desired

• Ensure that ALL CCSDS WGs pay attention to security• Ensure that they pay “serious” attention to security

– Not with just a lip-service statement a la, “security plays no part of this specification.”

– Provide rationale and explanation as to why or why not security plays a role in the specification (or Green or Yellow book)

• Not necessarily a security “compliance” statement– Does not have to state compliance with security

standards as such (although that would be nice too)– Does need to show that thought and effort has gone

into the specification/document preparation process

7

Re-Wording ExerciseRe-Wording Exercise

• Propose to include a security section template for all CCSDS documents with headings and explanatory text to help authors fill in the blanks.

• Outline of security section:– Provide rationale and explanation as to why or why not security plays

a role in this CCSDS document.– Template headings:

» 1.0 Security Background/Introduction» 2.0 Statements of security concerns with respect to the CCSDS

document:• data privacy• data integrity• authentication of communicating entities• control of access to resources• availability of resources• auditing of resource usage

» 3.0 Potential threats and attack scenarios (how could someone break the technology and why)

» 4.0 Consequences of not applying security to the technology (e.g., loss of life, loss of mission).

8

Future Standards DiscussionsFuture Standards Discussions

• Currently CCSDS does not have standards for:– Encryption– Authentication– Integrity – (or much of anything security-wise)

• Previous discussions in the (old) P1A (link layer) panel to create such “link-layer” standards (Spring 2002 mtg in Darmstadt)

– Good discussion which didn’t lead to anything (P1A Security Briefing)

• Created a “draft” P1A Security White Book to address some “strawman” proposals

9

AuthenticationAuthentication

• Existing 1992 ESA standard: 5- byte signature w/4-byte counter for replay protection

• Proposed adoption of “modern” digital signature standard such as Digital Signature Standard (DSS) using SHA-1 hash algorithm.

– Propose FIPS 186-2 (DSS) as CCSDS standard– Certificate standard as well:

» X.509 profile to state which certificate fields are required and which are optional.

10

IntegrityIntegrity

• Existing 1992 ESA standard: 5- byte signature w/4-byte counter for replay protection

• Again propose adoption of a modern standard such as DSS

– Propose FIPS 186-2 as CCSDS Standard

11

EncryptionEncryption

• Several Security Green Book solutions to pick from depending on existing link layer chip sets versus entirely new design.

– Several algorithms should be supported for civilian missions such as AES and 3DES

– Propose FIPS 197 – AES with 128-bit key as minimum CCSDS encryption algorithm standard.

12

Key ManagementKey Management

• Always a problem child – – Symmetric keys (the good ol’ standby)

» Burned into spacecraft or need for secure distribution channels

– Public key agreement (e.g., Diffie-Hellman)» Removes the need for burned in keys or secure

distribution channel, but….» Lots of bits exchanged over the link» Can be problematic over narrow links or with short

passes– Public key encryption

» Use public/private key pairs to encrypt “content encryption keys” (a la PGP)

» Certificates containing public keys have to be “magically” distributed or obtained from a key server

• Internet Key Exchange (IKE) holds promise– Currently being revised by IETF (v1 too complicated w/too

much overhead)– Use key updating to minimize the number of round-trips

necessary to agree on a key

13

DiscussionDiscussion

• What do we want to propose??

14

Future DocumentsFuture Documents

• Some of the documents we talked about producing previously:

– Do we still think they are relevant?– What about ground systems?– Are we ready to get started?– Volunteers?

• Information Security Guide for Mission Planners to include threat/risk analysis, security planning, and contingency and disaster recovery

• Security policy framework for developing trust agreements, rules for operational engagement, ensuring security compliance of legacy systems, and standard, secure interfaces between systems and across security domains

• Use of Common Criteria for Information Technology Security Evaluation (ISO 15408) “Protection Profiles” to describe security requirements for use cases

15

Ground SystemsGround Systems

• SecWG has been (for the most part) concerned with security for space missions – aka, the spacecraft.

• Meeting in March at JPL turned my head around:– Spacecraft is, of course, a concern and an issue– But….. We can’t ignore the ground systems that also

have many, many security problems. – Many of the ground system security issues are not

unique to space systems» Mission (closed) networks vs. Internet/public

network interconnectivity» Connectivity between agencies with varying

security policies» Etc.

16

DiscussionDiscussion