1 / 15

Authentication Algorithm Trade Study CCSDS Security WG Fall 2005 Atlanta, GA USA

Authentication Algorithm Trade Study CCSDS Security WG Fall 2005 Atlanta, GA USA. Howard Weiss NASA/JPL/SPARTA hsw@sparta.com +1-410-872-1515 September 2005. Agenda. 14 September 2005

artie
Télécharger la présentation

Authentication Algorithm Trade Study CCSDS Security WG Fall 2005 Atlanta, GA USA

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Authentication Algorithm Trade StudyCCSDS Security WG Fall 2005 Atlanta, GA USA Howard Weiss NASA/JPL/SPARTA hsw@sparta.com +1-410-872-1515 September 2005

  2. Agenda • 14 September 2005 • 0900-0915: Welcome, opening remarks, logistics, agenda bashing, 0915-0930: Review results of Spring 2005 SecWG meeting in Athens Mtg Notes • 0930-1000: RASDS Review wrt Security Architecture (Kenny) • 1000-1030: coffee break • 1030-1200: Security Architecture Document Discussions (Kenny) • 1200-1330: Lunch • 1330-1400:Review CNES Mission Security Req Development using EDIOS (Pechmalbec/Belbus) • 1400-1500: Encryption Algorithm Trade Study (Weiss) • 1500-1530: coffee break • 1530-1700: Authentication/Integrity Algorithm Trade Study (Weiss) • 15 September 2005 • 0900-1000: Key management discussion (Kenny) • 1000-1030: Coffee break • 1030-1100: Identity Management, Spacecraft IDs (Weiss) • 1100-1130: CNES Interconnection Rules (Pechmalbec/Belbus) • 1130-1300: Lunch • 1300-1400: CNES Security Development Process (Pechmalbec/Belbus) • 1400-1500: Security Policy Document/Common Criteria (Weiss)

  3. Discussion Topics • Standard Authentication/Integrity Algorithm adoption by CCSDS • Previous proposal submitted (Montreal, Toulouse, Athens) to adopt Digital Signature Standard (FIPS PUB 186-2). • Athens resulted in creating an action item to perform an authentication algorithm trade study.

  4. Background Discussions • As previously discussed, 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

  5. NO AGREEMENT – perform Trade Study Previous Encryption Algorithm Proposal: • Propose FIPS PUB 186-2 – Digital Signature Standard (DSS) algorithm standard. • Consensus??? Agreement???

  6. Trade Study Background • Proposal in Montreal was pre-mature • Digital signature is one way to provide authentication • But NOT the only way • Two other kinds of Message Authentication Codes (MAC) in use: • Hash-based MACs • Encryption-based MACs

  7. Digital Signature Background • Digital Signature • Based on public/private key (asymmetric) cryptography • Hash/CRC performed over data, check-word encrypted using sender’s private key • Receiver re-calculates check-word, verifies transmitted check-word by decrypting with sender’s public key. • Requires generation of public/private key pairs • Requires “Certificate Authority” signing of generated public keys to guarantee their authenticity • Requires a means to distribute/populate public keys for every sender at every receiver. • Public Key Infrastructure (PKI) • Pre-loaded public keys or public key certificates requiring a potentially large on-board cache

  8. Hash-based Message Authentication Code Background • Based on the concept of a keyed hash • Shared secret key • Hash calculated over data and the shared secret key to create a check-word, for example: • H {0123456789 Mary had a little lamb} • where “0123456789” is the shared secret • Keyed hash is authenticated by the receiver (who possesses the shared secret) by re-calculating the check-word and comparing it with the one transmitted with the data.

  9. Encryption Based Message Authentication Code Background • A hash is calculated over the raw data to create a check-word. • The check-word is encrypted using a symmetric algorithm using a shared secret key. • The encrypted check-word is authenticated by the receiver by recalculating the check-word, then decrypting the transmitted check-word using the symmetric algorithm and the shared secret key, and then comparing the two check-words.

  10. Candidate Algorithms • Digital Signature candidates: • Digital Signature Algorithm (DSA) • RSA • Elliptic Curve Digital Signature (ECDSA) • Hash-based MAC • HMAC-SHA1-96 • HMAC-MD5-96 • Hashing algorithms • SHA (1,256,384,512) • MD5 • UMAC • RIPEMD-160 • TIGER • Encryption-based MAC • DES-CBC-MAC • CMAC • CCM

  11. Digital Signature Algorithms

  12. Hash Based MACs

  13. Encryption Based MACs

  14. Conclusions and Recommendations • Digital signature authentication might not be the universal, fit-all-missions solution • PKI and/or distribution, public/private key generation, key size, CPU intensive • Shared secret key technology might be more suitable • Small(er) key size, less CPU intensive, shared secret used many times requiring less caching and less lookups • Adopt dual standards: • DSA (FIPS PUB 186) • HMAC w/SHA1 (FIPS PUB 198)

  15. Discussion • Is digital signature the only right answer? • Should there be multiple “right answers” because of mission constraints? • For example, shared symmetric keys will be smaller, and may be easier to deal with than public keys. • Should CCSDS adopt both a digital signature AND a symmetric technology authentication algorithm?

More Related