Theft-protected Proprietary Certificates Jinhae Kim Graduate Student University of Minnesota
Contents Introduction Building blocks Proprietary certificates Theft protection Alarm techniques and policies
Introduction Proprietary certificate Proprietary and collateral key A way of implementing digital certificate that discourages unwanted sharing of resources Proprietary and collateral key Vulnerabilities of proprietary certificate Theft protection (real and CPU time delay)
Example Subscribe web site (e.g. PCQuote.com, IEEE) Users pay per subscription (not pay per view) As we did before (all as we may want to do for expensive services), we can share password and payment How do we prevent this? (Do you want to?)
Building Blocks (RSA/DL Keys) RSA Setting Public key: (N, e) , secret key: (N, d) N: product of two k-bit primes (p , q) e ∈ ZN, coprime to φ(n), ed ≡ 1 mod φ(n) DL Setting Public key: (p,q,g,y) , secret key: (p,q,g,x) p: k-bit prime , q: prime such that q|p-1 g: a generator of the group of order q y = gx (x is element of Zq)
Building Block (Verifiable Enc.) Verifiable encryption Protocol between P and V V knows pk1, p (public value), R (binary relation) V Epk1(x) Accept if R(x, p) = True Note that x is never revealed to V
Building Block (Fair Encryption) A verifiable encryption where the relation is true if x = sk2 and pk2 = p with sk2 is a private key of pk2 If one know sk1, it can decrypt sk2 If not, nothing about sk2 is known
Intuitive Explanation When user A wants to subscribe site1, a certificate from CA1 should be issued to A To get the certificate, A shows a certificate from site2 where Revealing secret information for A results in revealing of important information at site 2 Examples of the important information: Criminal history, Bank password, credit card number
And then… When A wants to log in to site 1, Site 1 sends a random nonce to A A signs the nonce and sends it along with the certificate Site 1 verifies the signature and let A in
System Overview CA1 (proprietary) CA2 (collateral) User Wants to certify pk1 CA1 (proprietary) CA2 (collateral) User
Request the collateral certificate and F System Overview Wants to certify pk1 Request the collateral certificate and F CA1 (proprietary) CA2 (collateral) CA2 (collateral) User
System Overview CA1 (proprietary) CA2 (collateral) User Wants to certify pk1 Request the collateral certificate and F Send collateral certificate and F CA1 (proprietary) CA2 (collateral) User
System Overview CA1 (proprietary) CA2 (collateral) User Wants to certify pk1 Request the collateral certificate and F Send collateral certificate and F Verify validity of the collateral certificate by checking the signature of CA2 and validity of the fair encryption CA1 (proprietary) CA2 (collateral) User
System Overview CA1 (proprietary) CA2 (collateral) User Wants to certify pk1 Request the collateral certificate and F Send collateral certificate and F Verify validity of the collateral certificate by checking the signature of CA2 and validity of the fair encryption Send certificate of pk1 CA1 (proprietary) CA2 (collateral) User
System Overview CA1 (proprietary) CA2 (collateral) User Wants to certify pk1 Broadcast the updates to the list of valid public keys Request the collateral certificate and F Send collateral certificate and F Verify validity of the collateral certificate by checking the signature of CA2 and validity of the fair encryption Send certificate of pk1 Broadcast the updates CA1 (proprietary) CA2 (collateral) User
Proprietary Certificates I Non-transferablility With knowing secret key of C1, one can compute the SK of C2 Cryptosystem agility Proprietary and collateral services can use different cryptosystems Locality CA1 does not need to interact with CA2 directly Only the “light” version necessary: Broadcasting authentic public keys to CA2
Proprietary Certificates II Efficiency C1 is not larger than a regular certificate of its type The computational and communication requirements in establishing the proprietary/collateral relationship are resonable Security Any party does not learn any information about the SK2 of C2 No party besides CA1 learns what other certificates the user has
Proprietary Certificates III CA1: proprietary certification authority CA2: collateral certification authority C1, C2: proprietary, collateral certificate FEpk1(sk2): fair encryption of the sk2 under pk1
Proprietary Certificates IV Certify the public key pk1 by CA1 User present the certificate of pk2 contained in C2 issued by CA2 and F to CA1 F = FEpk1(sk2) CA1 verifies validity of the collateral certificate Check the signature of CA2 and validity of the fair encryption CA2 must broadcast the updates to the list of valid public keys
Is this enough? What if I lost my secret key for site 1 accidentally? This results in revealing more important information Easy solution: report when we lost it? How long does it take to detect it? So, we have to delay the secret key exposure of site 2
Theft Protection involuntary proprietary key exposure the user has time to detect the fact of theft and to contact proprietary and collateral service providers CPU delay: Time lock puzzle Real time delay: Delayed response to collateral information
Time-lock Puzzle (RiShWa) Symmetric encryption scheme using short key Time taking exhaustive key search This does not work since exhaustive key search on block cipher is parallelizable need serialized (unparallelizable) solution Time-lock puzzle: (n, a, t, CK, CM) n = pq, φ(n) = (p – 1)(q – 1) t = T S (S: # of squarings modulo n / sec) CM: Ciphertext of M using K CK = K + a2t mod n (a: random, 1 < a < n)
Time-Lock Puzzle (Why works?) When Alice encrypts first, she knows f(n) If one knows f(n), one can compute 2t mod f(n) easily, and therefore, can compute a2t easily Others have to compute 2t in integer compute “t” modular squaring Therefore, all others need t second to get K, and M also
Implementing a CPU Delay I IDU: identity info of user U (pk1, sk1), (pk2, sk2): proprietary and collateral public and secret key pairs FE: fair encryption algorithm SE: semantically-secure symmetric encryption algorithm T: desirable time delay in seconds S: # of squarings required to unlock the puzzle
Implementing a CPU Delay II Certification protocol U sends (IDU, pk1, F, C2) to CA1: F = FSpk1(sk2) CA1 verifies IDU, C2 and F Pick 2 primes p, q and computes n = pq Pick random k-bit string and computes EF= SEK(F) Compute values a, b as a function of pk1 Compute EK = K + a2t mod n (t = TS) C1 = (IDU, pk1, EF , EK , n, t , b) return to U with a valid signature CA1 sends f(n) to U secretly so that U can verify EK and EF efficiently
Implementing a CPU Delay III Use of RSA keys Public key: (N, e) , Secret key: (N, d) a ∈ Z*N , b = ae mod N Use of DL keys Public key: (p, g, q, gx) , secret key: x b = gr (r ∈ Zq ), a = yr = grx (mod p)
Implementing Real Time Delay Certification Protocol Similar to CPU delay CA stores F along with user’s information Derivation of collateral secret After verifying the signature, CA waits the necessary time period and returns F
References A. Boldyreva and M. Jakobsson, "Theft-protected proprietary certificates," ACM workshop on DRM '02 M. Jakobsson, A. Juels and P. Nguyen, “Proprietary Certificates,” Proceedings of The Cryptographers’ Track at the RSA Conference 2002, LNCS Vol. 2271, Springer-Verlag, 2002 Jan Camenisch, Ivan Damgard, “Verifiable Encryption, Group Encryption, and Their Applications to Group Signatures and Signature Sharing Schemes,” Advaces in Cryptology – ASIACRYPT ’00, LNCS Vol. 1976, T. Okamoto ed., Springer-Verlag, 2000 G. Poupard and J. Stern, “Fair encryption of RSA keys,” Advaces in Cryptology – Curocrypt ’00, LNCS Vol. 1807, B. Preneel ed., Springer-Verlag, 2000 R. Rivest, A. Shamir and D. Wagner, “Time-lock puzzles and timed-release crypto,” LCS technical memo MIT/LCS/TR-684, February 1996