Download presentation
Presentation is loading. Please wait.
Published byJulius Fields Modified over 9 years ago
1
1 SecWG New Business Discussions CCSDS CNES, Toulouse FR Howard Weiss NASA/JPL/SPARTA hsw@sparta.com +1-410-872-1515 November 2004
2
2 Discussion Topics CCSDS documents mandatory security section Future Standards: – Encryption – Authentication – Integrity – Key Management Future Documents as discussed at previous meetings Others?
3
3 Mandatory CCSDS Document Security 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)FCLTU-Security- Section
4
4 Success – CESG/CMC Adopts Mandatory 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
5 Future 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)P1A Security Briefing Created a “draft” P1A Security White Book to address some “strawman” proposals
6
6 Authentication 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)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
7 Integrity 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
8 Encryption 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
9 Key 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
10 Discussion What do we want to propose??
11
11 Future 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
12 Ground 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
13 Discussion
Similar presentations
© 2024 SlidePlayer.com. Inc.
All rights reserved.