1 / 35

CS 5950/6030 Network Security Class 11 ( M , 9/ 26 /05)

CS 5950/6030 Network Security Class 11 ( M , 9/ 26 /05). Leszek Lilien Department of Computer Science Western Michigan University [Based on Security in Computing. Third Edition by Pfleeger and Pfleeger. Using some slides courtesy of: Prof. Aaron Striegel — at U. of Notre Dame

alana-fulton
Download Presentation

CS 5950/6030 Network Security Class 11 ( M , 9/ 26 /05)

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. CS 5950/6030 Network SecurityClass 11 (M, 9/26/05) Leszek Lilien Department of Computer Science Western Michigan University [Based on Security in Computing. Third Edition by Pfleeger and Pfleeger. Using some slides courtesy of: Prof. Aaron Striegel — at U. of Notre Dame Prof. Barbara Endicott-Popovsky and Prof. Deborah Frincke — at U. Washington Prof. Jussipekka Leiwo — at Vrije Universiteit (Free U.), Amsterdam, The Netherlands]

  2. Class 10 2. Cryptology ... 2H. The Uses of Encryption 2H.1. Cryptographic Hash Functions – PART 1 2H.1. Cryptographic Hash Functions – PART 2 2H.2. Key Exchange 2H.3. Digital Signatures 2H.4. Certificates – PART 1

  3. Cryptographic Hash Fcns (10) Keyed vs. Keyless Crypto Checksum (1) • Keyedcrypto checksum • Key needed to computechecksum • Keyed hash fcns DES, AES • Use it in chaining mode: link next msg block to value of the previous msg block • Example chaining: E(current block) XOR E(previous block) => connects block to all previous blocks • If file sent, file’s checksum could be the last block • If chaining used, file checksum (=last block) depends on all previous blocks => depends on all bits of the file

  4. 2H.2. Key Exchange (1) • Motivation: • X and Y don’t know each other • X needs to send protected msg to Y • E.g., shopping on a web site • can do it if can securely exchange KE • This is the problem of key exchange • Important • Hard • Circular (chicken-’n-egg) problem? „To establish secure session need secure channel” • Circle can be broken – by public key cryptography • Can send public key even on insecure channel

  5. Key Exchange (2) Deriving Symmetric Key via PKE (1) • Given • S and R / kPRIV-S, kPUB-S -- kPRIV-R, kPUB-R • Solution 1: • S determines secret key K • S encrypts K with kPRIV-S : C = E(kPRIV-S, K) • S sends C to R • R decrypts C to get K: D(kPUB-S, C) = K • S & R communicate using secret (symmetric) key K • BUT: Solution 1 is not good!!! • Question: Why?

  6. 2H.3. Digital Signatures (1) • Outline: • a. Problem Definition • b. Properties of Electronic Signatures • c. Using PKE for Digital Signatures • d. Using Hash Fcns for Digital Signatures

  7. 2H.4. Certificates (1) • Outline • a. Introduction • ...

  8. Certificates (2) a. Introduction (1) • Need for trust in human interactions • Trust w.r.t.: • Individuals • Institutions (e.g., bank, hospital, car dealer) • Artifacts (e.g., car, Internet browser, software house) • Trust in small village vs. big city • Small village: implicit trust • Everybody knows everybody • Mr. X „feels” how much to trust Ms. Y • Big city: need to consider trust explicitly • Ask around to find trusted entities • Inquire friends, office mates, etc. about good car dealer, dentist, etc. • Check „reputation databases” E.g., BBB=Better Business Bureau

  9. Certificates (3) Introduction (2) • Selected trust characteristics • Trust comes in degrees of trust • vs. binary trust (with a single trust threshold) • Ubiquity of trust in social and artificial systems • Many users/computer systems err by trustingblindly (trust without evidence or verification!) • E.g., OS trusts all application pgms – any one allowed to run • E.g., sers trust unknown web sites with personal data

  10. Class 10 Class 11 2. Cryptology ... 2H. The Uses of Encryption 2H.1. Cryptographic Hash Functions – PART 1 2H.1. Cryptographic Hash Functions – PART 2 2H.2. Key Exchange 2H.3. Digital Signatures 2H.4. Certificates • a. Introduction – PART 1 • a. Introduction – PART 2 • b. Trust Through a Common Respected Individual • c. Certificates to Authenticate Identity • d. Trust Without a Single Hierarchy

  11. Certificates (4) Introduction (3) • Basic means of building trust toward person / institution / artifact X • Familiarity with X • Person: face, voice, handwriting, etc. • Institution: company name, image, good will, etc • Artifact: manufacturer name, perceived quality, etc • First-hand experience wih X’s activities/performance • Good or bad experience (trust or distrust grows) • Reputation of X determined by evidence / credentials Reputation = second-hand knowledge of X’s actions/perf. • Reputation databases (e.g., BBB, industry organizations, etc.) with „good” evidence or lack of „bad” evidence) • Credentials: X’s driver license, library card, credit card • Affiliation of X with person/institution/artifact Y • Trust/distrust toward Y rubs off on X

  12. Certificates (5) Introduction (4) • Basic means of verifying trust toward person / institution / artifact X „Dovyeryay noh provyeryay” („Trust but verify”, a Russian proverb) — Ronald Reagan (at the start of historic negotiations withGornachev) • Verify one’s experience • Check own notes about X’s activities/performance • Verify reputation evidence / credentials • Call back to verify phone number • Check user feedback about quality of artifact (online) • Check reputation DB (e.g., consumer reports, BBB) for data • Verify affiliation • Check with employer if X still employed • Check reputation of Y with which X is affiliated

  13. Certificates (6) Introduction (5) • Often trust is based on appearance of authenticity, without careful verification • E.g., business order from Company A sent to company B • Order sent w/o careful verification of A by B • Why? • Verification is expensive • Trust prevails in business • Risk of fraud or swindle is low • B might be „insured” against being cheated • A trusted third-party intermediary assumes transaction risk • E.g., buyer’s bank guarantees a transaction payment • Appearance of authenticity can be used by fraudster

  14. Certificates (7) Introduction (6) • Need similarly common and efficient/effective trust mechanisms in the Cyber Space • Need somebody or something to: assume risks OR vouch for the other party • A trusted third party is a basis for trust • When two interacting parties do not trust each other sufficiently

  15. b. Trust Through Common Trusted Individual (1) • Hierarchical structure of organizations • CEO / Divisions/ Departments / Groups / Projects • CEO doesn’t know engineers directly • Still, CEO controls all via intermediate managers => hierarchy as basis for trust in an organization • Example • Ann meets Andy • Andy claims he works for the same company • Ann can verify via common trusted individual / trusted third party (TTP) • via Bill and Betty if Bill knows/trusts Betty • via Bill and Camilla, otherwise Camilla Betty Bill Ann Andy

  16. Trust Through Common Trusted Individual (2) • Analogous approach for crypto key exchange • Example • Ann and Andy want to comm- unicate • Ann gives KPUB-Ann to Bill • Bill passes KPUB-Ann to Camilla (or to Betty if he trusts her) • Camilla passes KPUB-Ann to Betty • Betty passes KPUB-Ann to Andy • Camilla is TTP(trusted third party) Camilla Betty Bill Ann Andy

  17. Trust Through Common Trusted Individual (3) • In reality need to pass more than just KPUB-Ann • Every sender attaches an evidence of identity • Ann: Statement of Identity (SoI) • Bill, Camilla Betty: Transmittal of Identity (ToI) • Andy receives KPUB-Ann with: • Ann’s proof of identity • Proof of identity for all intermediaries • Proof that each inter- mediary received KPUB-Ann from trusted sender • E.g., Betty sends KPUB-Ann with the stmt: „I am Betty and I received this key, SoI, and 2 ToIs from a person I know to be Camilla” Camilla KPUB-Ann +SoI +2 ToIs KPUB-Ann+SoI+ToI Betty Bill KPUB-Ann +SoI +3 ToIs KPUB-Ann+SoI Ann Andy

  18. Trust Through Common Trusted Individual (4) • In reality need to pass more than just KPUB-Ann – CONT. • Andy can verify chain of evidence(SoI + ToI’s) • This assures Andy that key was sent by Ann and not forged • Public key authentication (delivered by trusted people) • Binding of key to Ann • Trustworthy Ann’s identification as sender of this key Camilla KPUB-Ann +SoI +2 ToIs KPUB-Ann+SoI+ToI Betty Bill KPUB-Ann +SoI +3 ToIs KPUB-Ann+SoI Ann Andy

  19. Trust Through Common Trusted Individual (5) • Works pretty well within an org • There’s always sb common & trusted for any 2 employees(at the top or below) • Problems: • If Bill, Camilla, or Betty out of town, Ann & Andy have to wait for keyexchange • Person at the top works too hard to exchange all keys quickly Camilla KPUB-Ann +SoI +2 ToIs KPUB-Ann+SoI+ToI Betty Bill KPUB-Ann +SoI +3 ToIs KPUB-Ann+SoI Ann Andy

  20. Trust Through Common Trusted Individual (6) • Protocol Solving Problem 1 (TTP absence): • Idea: preauthenticated public key for (single) future use • Ann asks Bill for complete chain from top down to her • Bill provides chain: <Camilla, Bill, Ann> • Ann requests for TOIs for her SOI ahead of time • Ann receives from Bill 2 TOIs: • TOI#637: “I, Bill, gave this TOI to Ann to confirm her identity for SOI#27” + Bill’s signature • TOI#5492: “I, Camilla, gave this TOI to Bill to confirm his identity for TOI#637” + Camilla’s signature • Ann can use SOI+TOIs any time • Think about full scenario Hint: Andy prepares his SOI+TOIs ahead of time Camilla Betty Bill Ann Andy

  21. Trust Through Common Trusted Individual (7) • Protocol Solving Problem 2 (TTP’s heavy workload): • Idea: preauthenticated public key for unlimited future use • Top TTP (e.g., a CEO) sends his TOIs to all Division Mgr • “I, Sushil, company CEO, attest to the identity of the Auto Division Mgr Diana, and I entrust Diana with attesting identities of her subordinates.” • Each Division Mgr sends TOIs to all Dept Mgrs • E.g., “I, Diana, Auto Division Mgr, attest to the identity of the Engine Dept Mgr Debbie, and I entrust Debbie with attesting identities of her subordinates.” • Note: Division Mgr is a TTP for all people working in her Division • …<intermediate levels>...

  22. Trust Through Common Trusted Individual (8) • Protocol Solving Problem 2 (TTP’s heavy workload):—CONT • …<intermediate levels>... • Each Group Leader sends TOIs to all Task Leaders • E.g., “I, Camille, Piston Group Leader, attest to the identity of the Piston Rings Task Leader Bill, and I entrust Bill with attesting identities of his subordinates.” • Note: Group Leaderis a TTP for all people working in her Group • Each Task Leader sends TOIs to all his employees • E.g., “I, Bill, Piston Rings Task Leader, attest to the identity of Piston Rings Engineer Ann.” • Note: Task Leaderis a TTP for all people working on his Task • Chain: Sushil—Diana—…—Camilla—Bill—Ann • Good exercise: Think aboutprotocol details – work out full scenario

  23. c. Certificates to Authenticate Identity (1) • Certificate for X • TTP’s signature certifies trustworthiness of binding KPUB-X with X’s identity • I.e., states that KPUB-X is really X’s public key • How are certificates created? Identifier of X KPUB-X TTP’s Signature

  24. Certificates to Authenticate Identity (2) • Creating certificates for the company example • Sushil (CEO) (chain: Sushil—Diana—…—Camilla—Bill—Ann) • Establishes <KPRIV-Sushil, KPUB-Sushil> • Posts KPUB-Sushil for every Division Mgr to copy • Receives request for certificate (encoded with KPUB-Sushil ) from Division Mgr X • Creates MX = <X, KPUB-X> (knows KPUB-X) • E.g., MDiana = <‘Diana’, KPUB-Diana > • Signs MX with SgSushil SgSushil= D(MX, KPRIV-Sushil) SgSushil ‘Diana’ ‘Diana’ KPUB-Diana KPUB-Diana

  25. Certificates to Authenticate Identity (3) • Creating certificates ... example—CONT. • Sushil encrypts MXand SgSushil with KPRIV-Sushil, producing certificate for Div.Mgr X: CertX = E(<MX, SgSushil>, KPRIV-Sushil) • Note: Others can read certificate, but only its issuer can update it! • E.g., produces certificate for Diana: CertDiana = E(<MDiana, SgSushil>, KPRIV-Sushil) • Sends certificate to Div. Mgr X SgSushil ‘Diana’ KPUB-Diana ‘Diana’ KPUB-Diana SgSushil CertDiana (shading indicates encryption)

  26. DIGRESSION—Note and understand these distinctions: • Using asymmetric cryptosystems: encrypt msg / sign msg / encrypt certificate • Encrypt msg – S encrypts (E) with R’s public key • R decrypts msg with R’s private key • Sign msg – to sign a msg, S uses decryption algorithm D with S’s private key • R authenticates signature using encryption algorithm E with S’s public key • Encryptcertificate – after signing a (pre-)certificate, its issuer encrypts (E) the whole (pre-) certficate with his own private key • Anybody who receives certificate can verify it by using decryption alg. D with certificate issuers’ public keys • But only certificate issuer can update a certificate she issued!

  27. Certificates to Authenticate Identity (4) • Creating certificates ... example – CONT. • Diana (Div. Mgr)(chain: Sushil—Diana—…—Camilla—Bill—Ann) • Establishes <KPRIV-Diana, KPUB-Diana> • Posts KPUB-Diana for every subordinate to copy • Sends request for certificate to her boss (Sushil) — as mentioned above (request encoded with KPUB-Sushil) • Receives certificate from her boss CertDiana = E(<MDiana, SgSushil>, KPRIV-Sushil) ‘Diana’ KPUB-Diana SgSushil

  28. Certificates to Authenticate Identity (5) • Creating certificates ... example – CONT. • Diana receives request for certificate from Y, one of her Dept Mgrs • Creates MY = <Y, KPUB-Y> (knows KPUB-Y) • E.g., MDebbie = <‘Debbie’, KPUB-Debbie> • Signs MY withSgDiana • Encrypts MYand signature with KPRIV-Diana, producing pre-certificate for Dept Mgr X: preCertY = E(<MY, SgDiana>, KPRIV-Diana) • E.g., produces pre-certificate for Debbie: preCertDebbie = E(<MDebbie, SgDiana>, KPRIV-Diana) ‘Debbie’ KPUB-Debbie SgDiana preCertDebbie

  29. Certificates to Authenticate Identity (6) • Creating certificates ... example – CONT. • Diana attaches to preCertY her own certificate, producing certificate for Y: CertY = preCertY || CertDiana • E.g., produces certificate for Debbie: CertDebbie = preCertDebbie || CertDiana • Sends Y’s certificate to Y • ... <procedure repetead by all mgrs from the chain below Diana and above Bill>... ‘Diana’ KPUB-Diana SgSushil ‘Debbie’ ‘Debbie’ KPUB-Debbie KPUB-Debbie SgDiana SgDiana preCertDebbie CertDebbie —incl. Debbie’s preCert (top half encr. with KPRIV-Diana) and Diana’s Cert (bootom half encr. with KPRIV-Sushil)

  30. Certificates to Authenticate Identity (7) • Creating certificates ... example – CONT. • Bill (Task Leader)(chain: Sushil—Diana—…—Camilla—Bill—Ann) • Establishes <KPRIV-Bill, KPUB-Bill> • Posts KPUB-Bill for every subordinate to copy • Sends request for certificate to his boss (Camilla) (request encoded with KPUB-Camilla) • Receives certificate from his boss (Camilla) CertBill = E(<MBill, SgCamilla>, KPRIV-Camilla) ‘Bill’ KPUB-Bill SgCamilla

  31. Certificates to Authenticate Identity (8) • Certificates for the company example – CONT. • Bill receives request for certificate from Z, one of his Engineers • Creates MZ = <Z, KPUB-Z> (knows KPUB-Z) • E.g., MAnn = <‘Ann’, KPUB-Ann> • Signs MZ withSgBill • Encrypts MZand signature with KPRIV-Bill, producing pre-certificate for Engineer Z: preCertZ = E(<MZ, SgBill>, KPRIV-Bill) • E.g., produces pre-certificate for Ann: preCertAnn = E(<MAnn, SgBill>, KPRIV-Bill) ‘Ann’ KPUB-Ann SgBill preCertAnn

  32. Certificates to Authenticate Identity (9) • Certificates for the company example – CONT. • Bill attaches his CertBill to preCertZ, producing certificate for Z: CertZ = preCertZ || CertBill • Can become loooong! CertBill = preCertBill || CertCamilla = preCertBill || preCertCamilla || Cert... = preCertBill || preCertCamilla || ... || CertDebbie = preCertBill || preCertCamilla || ... || preCertDebbie || CertDiana (cont.) ‘Ann’ KPUB-Ann SgBill preCertAnn

  33. Certificates to Authenticate Identity (10) • Certificates for the company example – CONT. • E.g., if the full certification chain is: Sushil—Diana—Debbie—Ahmet—Camilla—Bill—Ann then the certificate for Ann is: CertAnn = preCertAnn || preCertBill || preCertCamilla || preCertAhmet || preCertDebbie || CertDiana • Notes: - Diana has Cert defined by CEO => no preCertDiana - Cert’s become longer closer to the bottom of hierrarchy • After creating CertZ, Bill sends it to Z • E.g., sends CertAnn to Ann ‘X’ KPUB-X SgTTP_of_X preCertX

  34. Certificates to Authenticate Identity (10) • We don’t want such loooong certificates! • Note:The taller hierarchy the longer certificates • Solution: Flatten the certificate hierarchy • The ultimate: 1-level „hierarchy: Everybody (in a given organization) gets certificates from a single trusted Certificate Authority (CA) Note: If there is only single CA (not a chain of certifiers), there are no pre-certificates, only (flat) certificates (signed by CA only)

  35. End of Class 11

More Related