1 / 55

Secret Handshakes from Pairing-Based Key Agreements Dirk Balfanz, Glenn Durfee, Narrendar Shankar

Secret Handshakes from Pairing-Based Key Agreements Dirk Balfanz, Glenn Durfee, Narrendar Shankar Diana Smetters, Jessica Staddon, Hao-chi Wong Presented by Sen Xu, Feng Yue. A Scenario.

felice
Download Presentation

Secret Handshakes from Pairing-Based Key Agreements Dirk Balfanz, Glenn Durfee, Narrendar Shankar

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. Secret Handshakes from Pairing-Based Key Agreements Dirk Balfanz, Glenn Durfee, Narrendar Shankar Diana Smetters, Jessica Staddon, Hao-chi Wong Presented by Sen Xu, Feng Yue

  2. A Scenario • Alice want to authenticate herself to the server, but don’t want to reveal her credential until the server is authenticated. • Similarly, the server don’t want to authenticate itself until Alice is authenticated.

  3. Solution ? – Secret handshake! • non-members cannot recognize or perform the handshake. • What happen after a handshake: • A € G1, B € G2 • A, B don’t know anything about the other party if G1 != G2 • A, B know they belong to the same organization if G1 = G2 • They can choose only authenticate to members with certain roles • A third party won’t learn anything

  4. Applications of Secret Handshake • Securely discover restricted services • Privacy preserving authentication • Identify roles in a certain group.

  5. Group Background • Cyclic group: in a group, there is an x such that each element of the group may be written as xk for some integer k. • x is called the generator of the cyclic group. • Eg. {2, 4, 8} x = 2

  6. Order of a group, element • Order of a group G is simply the number of elements in G. misleading? • Order of an element g: least positive integer k such that gk is the identity element. In general, finding the order of the element of a group is at least as hard as factoring (Meijer 1996). • every group of prime order is cyclic.

  7. Identity Element • The identity element I (also denoted E, e) of a group or related mathematical structure S is the unique element such that I*a=a*I=a for every element a €S . The symbol "E" derives from the German word for unity, "Einheit." An identity element is also called a unit element. • For multiplication i = 1 • For addition i = 0

  8. Tate Pairing • Elliptic curves: a type of cubic curve whose solutions are confined to a region of space • Form: y2 = x3 + ax + b

  9. Y2 = x3 – x + 1 Y2 = x3 – x

  10. Tate Pairing continued • Bilinearity the most important property of Tate Pairing • e(aP, bQ) = e(P, Q)ab

  11. An example of secret handshake • Ministry of transportation: t (Master secrete) • Driver Alice: (“p65748392a”, TA) • TA = tH1(“p65748392a-driver”) = tP • Cop Bob: (“xy6542678d”, TB) • TB = tH1(“xy6542678d-cop”) = tQ

  12. Procedure “xy6542678d” • Bob Alice • Alice Bob • KA = e(H1(“xy6542678d-cop”), TA) = e(Q, tP) = e(P, Q)t • KB = e(H1(TB, “xy6542678d-driver”) = e(tQ, P) = e(P, Q)t • KA = KB “p65748392a”

  13. Another Example • Pro-democrocy movement master secret m • Alice: (“y23987447y”, MA) • MA = mH1(“y23987447y-member”) • Claire: (“k61932843u”, MC) • MC = mH1(“y23987447y-member”) • Check procedure is the same

  14. Imposter? • Dolores • Alice follows the procedure and generate a session key • Alice encrypt a number N with the session key, ask for N+1 • Reply is not N+1 • Dolores is not in the movement. • Dolores don’t know anything about the movement.

  15. Definitions of Secret-Handshake Scheme • A set U of possible users • A set G of groups • A set A of administrators (where do they come from?)

  16. Secret-handshake scheme • CreateGroup G {0,1}* (group secret generated by administrator) • AddUser: U x G x {0, 1}* {0,1}* (user secret given by administrator) • Handshake (A, B) • TraceUser: {0,1}* U • RemoveUser: {0, 1}* x U {0, 1}* (insert u into RevokedUserlist)

  17. Concrete Secret-Handshake Scheme • Computable, non-degenerate bilinear map e: G1 x G1 G2 • Example: Modified Weil or Tate pairings on supersingular elliptic curves. • H1: {0, 1}* G1 • H2 collision-resistant hash function

  18. Concrete Secret-Handshake Scheme • CreateGroup: SG € Zq • AddUser: “pseudonyms” list idU1, …, idUt € {0, 1}* for U. The administrator calculate: privUi = SGH1(idUi) • UserSecretU,G = id + priv

  19. Concrete Handshake idA, nA • A B • A B • A B • V0 = H2(e(privA, H1(idB)) ||idA||idB||nA||nB||0) (A) = H2(e(H1(idA), privB) ||idA||idB||nA||nB||0) (B) • V1 = H2(e(privA, H1(idB)) ||idA||idB||nA||nB||1) (A) = H2(e(privB, H1(idA)) ||idA||idB||nA||nB||1) (B) idB, nB, V0 V1

  20. Concrete Handshake Continued • If both verification succeed, then • SA = H2(e(privA, H1(idB)) ||idA||idB||nA||nB||2) • SB = H2(e(H1(idA), privB) ||idA||idB||nA||nB||2) • e(privA, H1(idB)) = e(H1(idA), privB) SA = SB • TraceUser: given a transcript of a handshake between A and B, the administrator can recover the pseudonyms idA and idB and their users.

  21. Concrete Secrete-Handshake scheme with Roles • CreateGroup • AddUser: “pseudonyms” list idU1, …, idUt € {0, 1}* for U. The administrator calculate: privUi = SGH1(idUi||R)

  22. Concrete Handshake with roles idA, nA • A B • A B • A B • V0 = H2(e(H1(idA||R’A), privB) ||idA||idB||nA||nB||0) (B) = H2(e(privA, H1(idB||R’B)) ||idA||idB||nA||nB||0) (A) • V1 = H2(e(privA, H1(idB||R’B)) ||idA||idB||nA||nB||1) (A) = H2(e(H1(idA||R’A), privB) ||idA||idB||nA||nB||1)(B) idB, nB, V0 V1

  23. Concrete Handshake Continued • If both verification succeed, then • SA = H2(e(privA, H1(idB||R’B)) ||idA||idB||nA||nB||2) • SB = H2(e(H1(idA||R’A), privB) ||idA||idB||nA||nB||2) • TraceUser and RemoveUser are identical to PBH.

  24. Security for Secret-Handshake Schema Some definitions: • Security Parameter: • Length of prime modulus (q) • Negligible: • for all polynomials p(·), e(t)<1/p(t) • Random Simulation: • R replaces all outgoing messages with uniformly-random bit strings of the same length.

  25. Definitions • Interaction: • Adversary modified SHS.Handshake(A,B) • A interacts with B: A.Handshake (A, B) • A interacts with a random simulation: A.Handshake (A, R)

  26. Group Member Impersonation • Adversary attempts to convince U* that A is a member of G* • If A not obtain secrets fro any U in G*, then it should remain unable to convince U* of its membership in G*. • Trace the user secrets a successful adversary might be using. ( by transcript of A’s interaction with U*)

  27. Group Member Impersonation Game • Randomized, polynomial-time adversary A • 1. A interacts with Us and obtains secrets for some users U’ in Us. • 2. A select a target user U* in G*. • 3. A attempts to convince U* that A belongs to G*. • SHS.Handshake (A, U*).

  28. Probability A Wins the Game • A wins if it engages correctly in SHS.Handshake (A, U*) • AdvMIGA:= Pr[ A wins Member Impersonation Game ]. • Conditional advantage restricted to E: AdvMIGEA:=Pr[ A wins Member Impersonation Game | E ].

  29. Impersonation Resistance • Impersonation Resistance • Suppose A never corrupts a member of the target group G*. Then U’ ^ G* = 0. The secret-handshake scheme SHS is said to ensure impersonation resistance if AdvMIGA (U0 ^ G* = 0) is negligible for all A.

  30. Impersonator Tracing • Let T be a transcript of the interaction of A and U. The secret-handshake scheme SHS is said to permit impostor tracing when |Pr[SHS.TraceUser(T) in U0 ^ G*]-AdvMIGA| is negligible for all A.

  31. Group Member Detection • Adversary A has as its goal to learn how to identify members of a certain group G* • A interacts with players of the system, corrupts some users, picks a target user U*, and attempts to learn if U* belongs to G.

  32. Group Member Detection Required property: • if A does not obtain secrets for any other U inG*, then it should remain clueless when detecting whether U* in G. In other words, the final interaction with U should yield no new information to the adversary unless it has already obtained secrets from another member of G.

  33. Member Detection Game • 1. A interacts with users of its choice, and obtains secrets for some users U’ in U. • 2. A selects a target user U* besides U. • 3. Flip a random bit, b <- {0.1}. • 4. b=0, A interacts with U; b=1, A interacts with R. • 5. A outputs a guess b* for b.

  34. Probability A Wins the Game • If b*=b, A wins the game. • AdvMDGA:=|Pr[A wins Member Detection Game]-1/2|. • Conditional Advantage restricted to occurrence of event E: AdvMDGEA:= |Pr[ A wins MDG|E ]-1/2| .

  35. Detection Resistance • Let GU* be the group to which U* belongs, and suppose A never corrupts a member in GU*, Then U0 ^ GU* = 0. • The secret-handshake scheme SHS is said to ensure detection resistance if AdvMDGa(U0 ^ GU*= 0) is negligible for all A.

  36. Detector Tracing • Let T be a transcript of the interaction of A and U*, and let GU* be the group to which U* belongs. • The secret handshake scheme SHS is said to permit detector tracing when |Pr[SHS.TraceUser(T) belongs to U’ ^ GU*]-AdvMDGA| • is negligible for all A.

  37. Security of Pairing-Based Handshake Hardness of BDH Problem: • We say that the Bilinear Diffie-Hellman Problem (BDH) is hard if, for all probabilistic, polynomial-time algorithms B, • AdvBDHB:= Pr[e(P,aP,bP,cP) = e(P, P)abc] is negligible in the security parameters.

  38. Security of Pairing-Based Handshake • Theorem 1 Suppose A is a probabilistic, polynomial time (PPT) adversary. There is an PPT algorithm B such that AdvMIGA <= Pr[ PBH.TraceUser(T) belongs to U’ ^ G* ] + e QH1QH2 ·AdvBDHB+ w, where wis negligible in the security parameter.

  39. Security of Pairing-Based Handshake • Corollary 2 (PBH Impersonator Tracing) • Suppose A is a probabilistic, polynomial time adversary If the BDH problem is hard, then |Pr[PBH.TraceUser(T) belongs to U’ ^ G*]-AdvMIGA| is negligible.

  40. Security of Pairing-Based Handshake • Corollary 3 (PBH Impersonation Resistance) • Suppose A is a probabilistic, polynomial time adversary. If the BDH problem is hard, then AdvMIGA (U’ ^ G* = 0) is negligible.

  41. Security of Pairing-Based Handshake • Theorem 4 Suppose A is a probabilistic, polynomial time (PPT) adversary. There is an PPT algorithm B such that AdvMDGA<= Pr[ PBH.TraceUser(T) belongs to U’ ^ G* ] + e QH1QH2 ·AdvBDHB+ w, where wis negligible in the security parameter.

  42. Security of Pairing-Based Handshake • Corollary 2 (PBH Detector Tracing) • Suppose A is a probabilistic, polynomial time adversary If the BDH problem is hard, then |Pr[PBH.TraceUser(T) belongs to U’ ^ G*]-AdvMDGA| is negligible.

  43. Security of Pairing-Based Handshake • Corollary 3 (PBH Detector Resistance) • Suppose A is a probabilistic, polynomial time adversary. If the BDH problem is hard, then AdvMDGA (U’ ^ G* = 0) is negligible.

  44. Additional Security Notions • Forward Repudiability • Optional • Any evidence shold not provide a noon-repudiable proof that U1 is a member. • Indistinguishability to Eavesdroppers. • AdvDSTA:= |Pr[A(TReal) = 1]-Pr[A(TRand) = 1]|.

  45. Additional Security Notions • Collusion Resistance and Traitor Tracing • Remain secure even if collections of users pool their secrets in an attempt to undermine the system. • If a coalition of users manages to detect or impersonate group members, detect at least one of them. • Traditional Diffie-Hellman based key exchange protocol broken down

  46. Additional Security Notions • Unlinkability • If an eavesdropper sees two different handshakes performed by Alice, the content of the handshakes alone are unlinkable. • A user obtains a list of pseudonyms • Reuse a single pseudonym

  47. SSL Handshake Protocol • Allow server and client to • authenticate each other • negotiate encryption and MAC algorithms • negotiate cryptographic keys to be used • Comprise a series of messages in phases • Establish Security Capabilities • Server Authentication and Key Exchange • Client Authentication and Key Exchange • Finish

  48. SSL Handshake Messages

  49. Implementation • Small modification of two of the TLS handshake messages. • Server_Key_Exchange message • An indication that PHB is the algorithm • Server’s identity idB • Client_Key_Exchange message • Indication: PHB scheme • Client’s identity idA

  50. Implementation Choices • Secure transport layer protocol • Security paramters • P = 12qr – 1 • P 1024bits, q 160bits • Curve E : y2 = x3 + 1. • Bilinear map: Tate Paring

More Related