1 / 27

על מפתחות ופרוטוקולים

על מפתחות ופרוטוקולים. על מפתחות. פרמטרים לבחירה אורך המפתח תלוי באלגוריתם ההצפנה זמן החיים של המפתח נמדד בזמן או בכמות תעבורה מוצפנת שיקולים בבחירת אורך המפתח סוג המידע המוצפן מידע שעובר על קו תקשורת לעומת מידע מאוחסן בקובץ זמן החיים של המסמך המוצפן תכנית התקפה על יעד למחר

Download Presentation

על מפתחות ופרוטוקולים

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. על מפתחות ופרוטוקולים

  2. על מפתחות • פרמטרים לבחירה • אורך המפתח • תלוי באלגוריתם ההצפנה • זמן החיים של המפתח • נמדד בזמן או בכמות תעבורה מוצפנת • שיקולים בבחירת אורך המפתח • סוג המידע המוצפן • מידע שעובר על קו תקשורת לעומת מידע מאוחסן בקובץ • זמן החיים של המסמך המוצפן • תכנית התקפה על יעד למחר • מסמך משפטי שתקף עשר שנים Prof. Ehud GudesSecurity Ch3

  3. על מפתחות • שיקולים בבחירת זמן חיים של מפתח • משך הזמן שבו המפתח נמצא בשימוש • ברור שצריך להיות קטן משמעותית מה-work factor • כמות המידע שמוצפן בעזרת אותו מפתח • ברור שצריך להיות קטן משמעותית ממספר בלוקי הקלט האפשריים • הנזק שיגרם במידה ומפתח ייחשף Prof. Ehud GudesSecurity Ch3

  4. ניהול מפתחות • יצור בטוח של מפתחות • מפתחות חייבים להיות אקראיים (ולא אקראיים-לכאורה) • רצוי לייצר מפתח פרטי (מתוך זוג מפתחות) באמצעי פיסי מאובטח. רצוי שהמפתח הפרטי לעולם לא יעזוב את האמצעי הפיסי. • המפתח הציבורי חייב להיות מלווה ב-Certificate • הפצה של מפתחות • אחסון בטוח של מפתחות Prof. Ehud GudesSecurity Ch3

  5. ניהול מפתחות (המשך) • עדכון מפתחות • במערכות מפתח ציבורי, יש לאמת את המפתח הציבורי • במערכות סימטריות, דרוש פרוטוקול הסכמה על מפתחות • במידת הצורך, מפתחות צריכים להיות מגובים • Revocation - שלילת מפתחות • במערכות מפתח ציבורי, ליוצר המפתח בד”כ אין שליטה על מספר העותקים המופצים של המפתח הציבורי. דרוש ליצר “רשימה שחורה” של מפתחות. • CRL – Certificate Revocation List Prof. Ehud GudesSecurity Ch3

  6. הסכמה על מפתחות • אלגוריתם מפתח ציבורי • לכל אחד מהצדדים מפתח ציבורי ומפתח פרטי • כל אחד מהצדדים יוצר סוד משותף, על ידי שימוש במפתח הפרטי שלו, ובמפתח הציבורי של הצד השני • Diffie-Hellman Prof. Ehud GudesSecurity Ch3

  7. Diffie-Hellman • אלגוריתם להסכמה על מפתחות • טכנולוגית מפתח ציבורי • יהי pמספר ראשוני • יהי gיוצר של *(GF(p, החבורה הכפלית של (GF(p • אליס ובוב המשתתפים באלגוריתם • מסתמכים על הקושי לחשב לוגריתם דיסקרטי Prof. Ehud GudesSecurity Ch3

  8. בוב אליס y,gy(mod p) x,gx(mod p) 1) gy(mod p) gx(mod p) 2) (gy)x=gyx(mod p) (gx)y=gxy(mod p) 3) DH Protocol (agree on secret symmetric key) Prof. Ehud GudesSecurity Ch3

  9. Diffie-Hellman Algorithm

  10. Diffie-Hellman Example • have • prime number q = 353 • primitive root  = 3 • A and B each compute their public keys • A computes YA = 397 mod 353 = 40 • B computes YB = 3233 mod 353 = 248 • then exchange and compute secret key: • for A: K = (YB)XA mod 353 = 24897 mod 353 = 160 • for B: K = (YA)XB mod 353 = 40233 mod 353 = 160 • attacker must solve: • 3a mod 353 = 40 which is hard • desired answer is 97, then compute key as B does

  11. פרוטוקול Diffie-Hellmanחשוף להתקפת “האיש שבאמצע” (מחליף גם את אליס וגם את בוב ) • פתרון : • שימוש ב-Certificatesעבור מפתחות DH • חתימה על המפתח הציבורי באמצעות אלגוריתם חתימה דיגיטלית (RSAאו DSA) Prof. Ehud GudesSecurity Ch3

  12. - Authenticationאימות זהוי • Authenticationהוא תהליך שבאמצעותו ניתן לוודא לגבי מידע מסוים • את זהות השולח (או יוצר המידע) • את מקוריות המידע - Authenticity • את שלימות המידע - Integrity • את הזמן שבו נשלח המידע Prof. Ehud GudesSecurity Ch3

  13. סוגי Authentication • Authentication של אדם או קבוצה (עסק) • Authentication של מכונה (מחשב, IP, URL ) • Authentication של הודעה – שימוש ב -MAC ראינו כבר • בפרק זה נדבר על אמות זהוי באמצעות פרוטוקולים קריפטוגרפיים. אמצעים אחרים בפרק הבא. Prof. Ehud GudesSecurity Ch3

  14. Protocols for Authentication and Key Distribution • The goal of the protocol is usually the mutual authentication of the two parties and the exchange of a new symmetric key • The particular algorithm is usually not important Prof. Ehud Gudes Security Ch 4

  15. Protocols for Key Distribution • Symmetric, only Two Parties. • Secure channel or Diffie-Helman 2. Symmetric, using third party – Key Distribution Center – KDC (Needham protocol next) P likes to communicate with R KP and KR are symmetric keys with KDC P sends to KDC (P, R, ID) KDC to P: E((ID, R, KPR, E((KPR,P),KR)), KP) P sends to RDisadvantage: every new session needs KDC, replay. Prof. Ehud Gudes Security Ch 4

  16. Needham Protocol (symmetric)Problem - replay step 3 Prof. Ehud GudesSecurity Ch3

  17. Denning’s Protocol 1. A KDC: IDAIDB 2. KDC A: Eka[KSIDBTEKb[KSIDAT]] 3. A B: Ekb[KSIDAT] 4. B A: Eks[N1] - Challenge 5. A B: Eks[f(N1)] - Response B can check the difference between his clock and the timestamp in step 3 Problem – synchronizing clocks Prof. Ehud GudesSecurity Ch 3

  18. Protocol Newman 1. A B: IDANa 2. B KDC: IDBNbEkb[IDANaTb] 3. KDC A: Eka[IDBNaKsTb]EKb[IDA KSTb]Nb 4. A B: Ekb[IDAKsTb]Eks[Nb] All protocols until now used symmetric keys Prof. Ehud GudesSecurity Ch3

  19. Protocols For Key Distribution 3. Asymmetric, without third party P to R: ER (DP(K) R to P: E(n, K) P to R E(n+1, K)disadvantage: need to know public keys!Solution – send your key?No! man in the middle problem! Prof. Ehud GudesSecurity Ch3

  20. Protocols For Key Distribution 4. Using third party to get public keys. KDC to P: EP(DC(R public key)) KDC to R: ER(DC(P public key)) continue as before! How both P and R know that Dc is the signature of KDC? Answer: Certificates! Prof. Ehud Gudes Security Ch 4

  21. Protocol Woo-Lam 1. A -> KDC: IDA IDB Aקיבלמפתח ציבורי שלBחתום ע"י KDC 2. KDC-> A: EKRauth [IDB KUb] Aשולח אתגר ל-3. A -> B: EKUb [Na || IDa] B 4. B-> KDC: IDBIDAEKUauth[NA] 5. KDC-> B: EKRauth[IDAKua]EKUb[EKRauth[NaKsIDB]] Bמקבל מ- KDC את המפתח הסימטרי ואת האתגר של A מוצפן במפתח שלו 6. B -> A: EKUa[EKRauth[NaKsIDB]Nb] Bשולח חזרה ל- A את האתגר של A וכן שולח אתגר שלו 7. A -> B: Eks[Nb] A שולח ל- B את האתגר שלו מוצפן במפתח הסימטרי שים לב שצעדים 6, 5, 4, 3 מבטיחים ל- A שהתקשורת בין B ו- KDC היא עכשוית ואוטנטית ושהוחזר האתגר ש- A שלח ל- B. Prof. Ehud GudesSecurity Ch3

  22. Other Protocols 1. Mental poker 2. Electronic voting 3. Oblivious transfer 4. Secret sharing Prof. Ehud GudesSecurity Ch3

  23. Mental Poker Prof. Ehud GudesSecurity Ch3

  24. Mental Poker – Key Distribution Suppose Bill wants to update its public key Without the KDC knowing the pair ((Kb,Kb-1 KDC will send a stream of encrypted pairs. Bill will select a pair encrypt it with old key and send to KDC. KDC will decrypt it and send back to Bill who will decrypt it Prof. Ehud GudesSecurity Ch3

  25. Electronic Voting Prof. Ehud GudesSecurity Ch3

  26. Oblivious Transfer Prof. Ehud GudesSecurity Ch3

  27. Zero Knowledge proofs Zero knowledge example Fiat-Shamir proof of identity A trusted center chooses n=pq, and publishes n but keeps p and q secret. 2. Each proverA chooses a secret s with gcd(s,n)=1, and publishes v=s2 mod n. 3. A proves knowledge of s to B by repeating: (a) A chooses random r and sends r2 mod n to B. (b) B chooses random e in {0,1}, and sends it to A. (c) A responds with a=rse mod n. (d) B checks if a2 = ve r2 mod n. 1. if A follows the protocol and knows s, then B's check will always work 2. if A does not know s, then they can only answer the question with probability 1/2. x Prof. Ehud Gudes Security Ch 4

More Related