Technology Transfer from Security Research Projects A Personal Perspective N. Asokan Aalto University & University of Helsinki http://asokan.org/asokan/research
Five examples • Optimistic Fair Exchange • Generic Authentication Architecture • Channel Binding in Protocol Composition • Secure Device Pairing • On-board Credentials 2
Five examples • Optimistic Fair Exchange • Generic Authentication Architecture • Channel Binding in Protocol Composition • Secure Device Pairing • On-board Credentials 3
Fair Exchange How can two mutually distrusting parties exchange digital “items” on the Internet? Existing solutions: A-item B-item A-exp B-exp B-item A-item Gradual Exchange protocols Trusted Third Party protocols 4
Fair Exchange: design choices • Common case: both want to complete the exchange – design protocol that is efficient for the common case – but allows recovery in case of exceptions • Requirements – Effectiveness – Fairness – Timeliness – (Non-invasive) 5
Optimistic Fair Exchange A-exp A-item B-exp B-item generate generate A- B- permit permit A- permit B- permit A-item Bob Alice B-item ? Resolve http://www.semper.org/ 6
Optimistic Fair Exchange: Recovery B- A-item Resolve permit if A-item matches B-exp • extract B-item from B-permit Alice • store A-item B-item B-exp B-item extract B- permit 7
Optimistic Fair Exchange A-exp A-item B-exp B-item generate generate A- B- permit permit A- permit B- permit ? Abort A-item ? Bob Resolve Alice B-item ? Resolve http://www.semper.org/ 8
Optimistic Fair Exchange: Recovery A- Abort permit If not resolved , A- issue abort token permit Alice B- A-item Resolve permit If not aborted , and if A-item matches B-exp • extract B-item from B-permit Alice • store A-item B-item B-exp B-item extract Resolve for Bob is similar B- permit 9
Verifiable Encryption Analogy - jewelry in a glass box: can see but can’t touch secret secret desc verifyEnc recover True/False secret 10
Verifiable Encryption of discrete logs Setting: secret = s G1, desc d = g s (in G2) Prover Verifier TTP Verifier s0 R G1, v ← g s0 s1 ← s0 – s E Ei ← Enc(ri, si), i={0,1} v, E0, E1 b b R {0,1} s 𝑐 ← Dec( E b ) s b b s ← sb + s rb, sb b (d b . g sb = v?) && (Enc(rb, sb) = Eb?) Repeat n times (cut-and-choose) verifyEnc recover 11
From Verifiable Encryptions to Permits = desc. of B-item A-exp A- = Verifiable Encryption of + A-item A-exp permit [A SW00] “ Optimistic Fair Exchange of Digital Signatures ”, JSAC 18(4 ): 593-610 (2000) 12
Optimistic Fair Exchange: the aftermath • Someone has to run the Third Party – Wants to monetize every transaction! 13
Verifiable Encryption of discrete logs Setting: secret = s G1, desc d = g s (in G2) Prover Verifier TTP Verifier s0 R G1, v ← g s0 s1 ← s0 – s E Ei ← Enc(ri, si), i={0,1} v, E0, E1 b b R {0,1} s 𝑐 ← Dec( E b ) s b b s ← sb + s rb, sb b (d b . g sb = v?) && (Enc(rb, sb) = Eb?) Repeat n times (cut-and-choose) verifyEnc recover 14
Verifiable Encryption of discrete logs Setting: secret = s G1, desc d = g s (in G2) s0 R G1, v ← g s0 E0 ← Enc(r0, s0) Cert ← Sig TTP (v, E0) Prover Verifier TTP Verifier s1 ← s0 – s v, E0,Cert E0 s0 ← Dec( E0 ) s1 s0 s ← s0 + s1 (d . g s1 = v?) && verify(Cert) Repeat n times (cut-and-choose) verifyEnc recover Pre-paid coupons bought from the TTP to be used for every optimistic transaction! 15
Optimistic Fair Exchange: the aftermath • Someone has to run the Third Party – Wants to monetize every transaction! • 15 years on, current status: – Reputation systems – In-line TTP (e.g., E-bay escrow service) 16
Continuing “impact” in research circles! 17
Optimistic Fair Exchange: the aftermath • Someone has to run the Third Party – Wants to monetize every transaction! • 15 years on, current status: – Reputation systems – In-line TTP (e.g., E-bay escrow service) • Impact in academia vs. real world impact • Biggest impact of SEMPER? http://logging.apache.org/log4j/2.x/ 18
Optimistic Fair Exchange: lessons learned • Don’t just guess security requirements; Ask stakeholders • Desiderata for deployment and research can be different – “the more (independent) parties you require for your scheme, the less likely it will be deployed” • Capturing researcher interest (Tech transfer) Impact → / – MANETs anyone? • “90 - 10 rule” applies to deploying security – “Good enough beats perfect” 19 Skip to summary
Five examples • Optimistic Fair Exchange • Generic Authentication Architecture • Channel Binding in Protocol Composition • Secure Device Pairing • On-board Credentials 20
Generic Authentication Architecture Can we bootstrap a general-purpose global-scale authentication and authorization infrastructure from the existing cellular security infrastructure? • Need was evident: – “Global PKIs will not happen” • Ad-hoc bootstrapping already in use – e.g., Coke vending machine accepting payments via SMS, 1997 • Idea: Bootstrap short- lived certificates from “local PKIs” 21
Bootstrapping a “local PKI” K Home Security Server Authentication & Key Global Cellular Agreement (AKA) Authentication/authorization Serving Network Infrastructure RA IK, CK CA SP IK, CK Cert D K PK D /SK D 22
3GPP “Generic Authentication Architecture” HSS Two layer architecture - Generic Bootstrapping Credential Fetching Architecture (GBA) Protocol Bootstrapping Key distribution Application - Specialized Application Protocol Server Server Servers Bootstrapping - E.g., for “subscriber Protocol certificates” Bootstrapping client Application client Application User Equipment Protocol (UE) [HLGNA 08] “ Cellular Authentication for Mobile and Internet Services ”, Wiley, 2008 Relevant 3GPP documents: E.g., [33.919], [33.220] 23
GAA: the aftermath • Standardized in 3GPP – Variants: GBA and GBA_U (implemented in the smartcard, UICC) – GBA implemented for some services – none of which has taken off (e.g., Mobile TV), so far • Today’s solutions: – Bootstrapping: Facebook, Google, … • Some mobile carriers even deployed PKI-enabled SIM cards – Roaming: iPass , Shibboleth, … • Variants of the idea had more success – E.g., EAP SIM 24
GAA: lessons learned • (Standardization) Politics can suffocate a good idea • “90 - 10 rule” applies to deploying security 25 Skip to summary
Five examples • Optimistic Fair Exchange • Generic Authentication Architecture • Channel Binding in Protocol Composition • Secure Device Pairing • On-board Credentials 26
Channel Binding in protocol composition Composing two secure authentication protocols carelessly can lead to a man-in-the-middle vulnerability • Protocol composition can ease deployment • Examples: – Server auth. using TLS + user auth. with password – Authentication for VPN access using legacy credentials – Bootstrapping a “local PKI” 27
3G AKA K K Latest SQN: SQN H Latest SQN: SQN U Serving Network Home Security Server IMSI IMSI Rand K SQN H Rand, AUTN, XRES, IK, CK XRES AUTN IK CK RAND, AUTN Rand K AUTN RES SQN IK CK STOP i f SQN SQN U RES STOP i f RES XRES Provides mutual authentication 28
Bootstrapping certificate enrollment 1. Set up a (server-authenticated) TLS channel Serving Network Home Security RA Server IMSI IMSI 2. Run AKA Rand, AUTN, XRES, IK, CK RAND, AUTN STOP i f SQN SQN U RES STOP i f RES XRES Cert Request Cert Response 3. Do certificate enrollment via the (mutually) authenticated TLS channel 29
Bootstrapping certificate enrollment 1. Set up a (server-authenticated) TLS channel Serving Network Home Security RA Server MitM IMSI IMSI IMSI 2. Run AKA Rand, AUTN, XRES, IK, CK RAND, AUTN RAND, AUTN STOP RES RES i f SQN SQN U STOP i f RES XRES Cert Request Cert Response 3. Do certificate enrollment via the (mutually) authenticated TLS channel Channel binding: Use of cryptographic binding to compose two authenticated channels [ANN03] “ Man-in-the-middle in Tunnelled Authentication Protocols ”, Security Protocols, 2003 30
Channel binding: the aftermath • Fiery reception at Security Protocols workshop! – “But you are using the worst rackets in industry as a justification for what you’re doing. There are all sorts of people just generating garbage protocols, a couple of which you have already mentioned here. We’re trying to reverse their work, whereas you’re trying to advocate we use all these garbage protocols.” – For an entertaining read, see transcript of discussion during my talk at SPW ’03! • Impact in IETF – Closing down of ipsra working group; channel binding in IKEv2 – Continued attention: e.g., RFC 6813 31
Channel Binding: lessons learned • Negative results are useful for security practitioners • Standardization can make a good idea see light of day • (Tech transfer) Impact Capturing researcher interest → / 32 Skip to summary
Recommend
More recommend
