1

SecWG New Business DiscussionsSecWG New Business Discussions

CCSDS CNES, Toulouse FRCCSDS CNES, Toulouse FR

Howard WeissNASA/JPL/SPARTA

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

November 2004

2

Discussion TopicsDiscussion Topics

• CCSDS documents mandatory security section• Future Standards:

– Encryption– Authentication– Integrity– Key Management

• Future Documents as discussed at previous meetings• Others?

3

Mandatory CCSDS Document Mandatory CCSDS Document Security SectionSecurity Section

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

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

FCLTU-Security-Section)

4

Success – CESG/CMC Adopts Success – CESG/CMC Adopts Mandatory Security Section ProposalMandatory Security Section Proposal

• Proposal submitted to CESG/CMC for mandatory security section in all forthcoming CCSDS documents

• Wording accepted by CESG/CMC:

– 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).

5

Future Standards DiscussionsFuture Standards Discussions

• As discussed in Montreal, 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

6

AuthenticationAuthentication

• Existing 1992 ESA standard: 5- byte signature w/4-byte counter for replay protection– Recently examined as part of NASA study

» Weak algorithm as originally believed – based on “hard knapsack” problem which has been found to be flawed. (ESA Authentication)

• 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.

7

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

8

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.

9

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

10

DiscussionDiscussion

• What do we want to propose??

11

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

12

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.

13

DiscussionDiscussion