Towards Mobile Cryptography

1. Towards Mobile Cryptography Thomas Sander and Christian Tschudin International Computer Science Institute Berkeley, California

2. Mobile Code • Mobile computing: • Applications have to handle extended off-line periods • Mobile agents – carry request to server, execute, return results

3. Mobile Code • Active networks: • A packet carries info telling the network how to process the data in the packet • The custom communication architecture pays for the overhead (e.g. data filtering) • Shift info processing from end nodes to internal nodes

4. Mobile Code • E-commerce: • New products, new providers, new customers join the system at any time • The mobile agent can keep up with the changes but needs to operate securely

5. Security Problems • Hosts have to be protected from malicious agents • The mobile agent’s code and data is at the full mercy of the executing host

6. Security Problems • Clear text data can be read and changed • Clear text programs can be changed • Clear text messages (e.g. to the originator) can be faked

7. Security Problems • Can a mobile agent protect itself against tampering by a malicious host? (code and execution integrity) • Can a mobile agent remotely sign a document without disclosing user’s private key? (computing with secrets in public) • Can a mobile agent conceal the program it wants to have executed? (code privacy)

8. Constraints • Mobile agents should be allowed to execute on untrusted hosts but still have guarantees for their correct execution • Mobile agents should not require interactive protocols with their originator • Protection mechanisms should be provably secure

9. Mobile Cryptography • The secure execution environment usually includes the computing base that provides the physical storage and execution environment • We want to extract the computing base from the secure premises

10. The Linking Problem Execute y = P(x) Compute the signature z = S(y) Output the pair (y,z) • An adversary separates the signing routine and signs arbitrary documents • How can cryptographic primitives be irremovably attached to the data to which they are supposed to be applied?

11. The Linking Problem – Idea • The output of function f has to be signed using function s • Compute h = s o f on the originating host • Send h to be evaluated remotely • The key is the difficulty of decomposing h into s and f

12. Non-Interactive Evaluation of Encrypted Functions Alice encrypts f => E(f) Alice creates the program P(E(f)) which implements E(f) Alice sends P(E(f)) to Bob Bob executes P(E(f)) on x Bob sends to Alice P(E(f))(x) Alice decrypts P(E(f))(x) and obtains f(x) Computing with Encrypted Functions

13. Evaluation w/ Encrypted Functions via Homomorphic Functions Definition: Let R and S be rings. We call an (encryption) function E : R -> S Additively homomorphic if there’s an efficient algorithm PLUS to compute E(x+y) from E(x) and E(y) and does not reveal x and y Mixed multiplicatively homomorphic if there’s an efficient algorithm MIXED-MULT to compute E(x*y) from E(x) and y that does not reveal x Proposition: Let E : R -> S be the function defined above. We can implement non-interactive EEF for polynomials pR[X1, … Xn] with E Computing with Encrypted Functions

14. Evaluation w/ Encrypted Functions via Homomorphic Functions Let p be the polynomial  ai1…is X1i1, … Xnis Alice creates P(X) that implements p like this: Each coefficient ai1…is of p is replaced by E(ai1…is) The monomials of p are evaluated on the input x1, …, xs and stored in a list L := […, E(x1i1, …, xsis), …] The list M := […, E(ai1…is x1i1, …, xsis), …] is produced by calling MIXED-MULT for elements of L and coefficients E(ai1…is) The elements of M are added up using PLUS Computing with Encrypted Functions

15. Evaluation w/ Encrypted Functions via Homomorphic Functions Alice sends the program P to Bob Bob runs P on its private input x1…xs and obtains P(x1…xs) Bob sends the result P(x1…xs) = E(p(x)) back to Alice Alice applies E-1 and obtains p(x) Computing with Encrypted Functions

16. Z/NZ Cryptosystems Computing with Encrypted Functions HORROR

17. EEF via Composition Techniques Assume f is the computation function and s is a rational function that Alice is able to invert efficiently Let E(f) := s o f The protocol goes as previously described Decomposition problem: Given the function h that is known to be decomposable, find f such that exists s with h = s o f Composition Based Approaches

18. Undetachable signatures s = function used by Alice to sign an arbitrary message m m = the result of a function f applied to some data x v = function that Alice publishes to let others verify the validity of a signature (z is a valid signature of m if v(z) = m) Composition Based Approaches

19. Undetachable signatures fsigned = s o f Send (f, fsigned) and get (f(x), z:=fsigned(x)) Applying v to z a user can check that f(x) is valid Composition Based Approaches

20. Undetachable signatures - attacks Left decomposition attack – given h:= s o f and f, determine s Interpolation attack I – the adversary is able to produce (z, v(z)) (z, v(z)) = (s(v(z)), v(z)) s is a low degree rational scheme (otherwise s o f is hard to calculate on dense sets) s is discoverable using interpolation techniques Composition Based Approaches

21. Undetachable signatures - attacks Interpolation attack II – the adversary is able to produce (l, s(l)) s is a low degree rational scheme (otherwise s o f is hard to calculate on dense sets) s is discoverable using interpolation techniques Inversion attack – if the adversary is able to find a pre-image x of n under f, i.e. f(x) = n, he can produce a valid signature for n using fsigned(x) Composition Based Approaches

22. Undetachable signatures – better approach s = (s1…sk) : Rk -> Rk a bijective function called bi-directional map v = (v1…vk) : Rk -> Rk the inverse function of s, i.e. s o v = v o s = idRk Let f : Rl - > Rt be the function whose output we want to be signed G2,…Gk: Rt -> R public functions Composition Based Approaches

23. Undetachable signatures – better approach Public key – the public key for signature verification is v2…vk ( !!!! NO v1) Construction of the signed program Chose a random rational function r : Rl->R Build the map fsigned:Rl->Rk with components given by fsigned,I := si(r, G2o f, …Gko f), i = 1 … k Send (f, fsigned) Composition Based Approaches

24. Undetachable signatures – better approach Execution - Get the result (y:=f(x), z:=fsigned(x)) Verification – Compute Gi(y) and vi(z) ,i = 2..k z is a signature of y iff vi(z)=Gi(y) for all i Composition Based Approaches

25. Undetachable signatures – explanations The key is that the adversary doesn’t know r and v1 Because the adversary doesn’t know r, the left decomposition attack to find si from the ith component of fsigned is even harder Because the adversary doesn’t know v1 he cannot compute I/o pairs for the interpolation of si Composition Based Approaches

26. Undetachable signatures – explanations Because the adversary doesn’t know r, he cannot compute i/o pairs for the interpolation of si (second interpolation attack) Even if the adversary is able to invert f, the scheme is not broken: without r he cannot compute pre-images of (r, G2o f, …Gko f):Rl->Rk Composition Based Approaches

27. Conclusions