Cryptographic Security for Mobile Code Sean Kugele CS 6204, Spring 2005 1
Mobile Code ♦ A program produced by one entity, called the originator, and transferred to a different entity, called the host, where it is immediately executed – mobile code must arrive at the host ready to run; i.e. no installation required. – example: Java Applets CS 6204, Spring 2005 2
Security Problems in Mobile Code Protecting the host executing the code 1. from malicious mobile code • Sandboxing, Proof Carrying Code Protecting the mobile code from malicious 2. hosts • Far less developed • Concern of this paper CS 6204, Spring 2005 3
History of Mobile Code Protection Schemes ♦ Originally considered impossible until a 1998 paper by Sanders and Tschudin applied theoretical cryptography to allow code execution in encrypted form • Required multiple rounds of interaction between originator and host • Only works for a subset of possible programs ♦ More recently, a protocol was devised that only required one round of interaction and allowed efficient evaluation of encrypted code • Must not allow host to gain information about the computation • Only the originator may receive output CS 6204, Spring 2005 4
History of Mobile Code Protection Schemes ♦ Use of trusted hardware to allow “active code”. Mobile code runs exclusively within the trusted hardware, and is encrypted on exit • Hardware must be trusted to execute the code properly, and only once • Expensive CS 6204, Spring 2005 5
Purpose of this Paper ♦ Propose an architecture for secure execution of active mobile code that does not require additional client hardware – Introduced the concept of a Generic Secure Computation Service – Assuming that the trusted service does not collude with anyone the protocol guarantees the following: 1. Privacy of computation for both originator and hosts 2. Integrity of computation for both originator and hosts 3. The Computation Service learns nothing about the computation CS 6204, Spring 2005 6
Model used for Mobile Code Protection ♦ Components: • Originator O • Hosts H 1 , ... , H L • Messages M 0 , ..., M L CS 6204, Spring 2005 7
Host Computation ♦ X ≡ Set of All Possible Agent States ♦ Yj ≡ Set of All Possible Inputs from Hj ♦ Zj ≡ Set of All Possible Outputs to Hj ♦ Functions: – g j : X × Y j → X – h j : X × Y j → Z j CS 6204, Spring 2005 8
Generic (non-interactive) secure mobile computing ♦ Consists of 2L + 2 algorithms: A 0 ,..., A L B 1 ,..., B L , and D CS 6204, Spring 2005 9
Model using Generic Secure Computation Service ♦ T is a separate entity offered as a service for “secure mobile agent computation” ♦ Portions of the mobile code that need “protection” are executed by T, the rest of the mobile code is executed at Hj • Too computational expensive to execute all code in this way ♦ Based on the encryption of binary digital circuits CS 6204, Spring 2005 10
Constructing Encrypted Circuits ♦ First proposed in 1986 by A.C. Yao ♦ Overview Given • a binary function g(x,y) that outputs z • Two parties Alice (who supplies x) and Bob (who supplies y) Essential Components • construct algorithm for producing the encrypted circuit • A transfer protocol for communication between Alice and Bob • evaluate algorithm for allowing Bob to decipher g(x,y) Result • Bob learns z, but nothing else • Alice learns nothing at all CS 6204, Spring 2005 11
Constructing Encrypted Circuits ( construct algorithm) ♦ Input: a circuit C that computes g(x,y) ♦ Output: a tuple ( C , L , K , U ) • where C denotes the encrypted input circuit and, CS 6204, Spring 2005 12
Constructing Encrypted Circuits (Transfer Protocol) ♦ Oblivious Transfer: • Alice has two messages • Bob chooses to receive one of these messages, but gains no knowledge of the other message • Alice does not learn which message Bob received CS 6204, Spring 2005 13
Oblivious Transfer Example Alice generates two public/private key pairs and sends 1. both public keys to Bob Bob generates a symmetric key K Bob and choosing one of 2. Alice’s public keys he encrypts K Bob without telling Alice which public Key Alice decrypts K Bob using both of her private keys, 3. producing both K Bob and another key which is garbage. But Alice does not know which is K Bob and which is garbage Alice encrypts both of her message, one with K Bob and 4. the other with the garbage key, and sends both back to Bob Bob, using K Bob is able to decrypt on of Alice’s messages 5. but not both, and Alice has no idea which message Bob actually received - paraphrased from Applied Cryptography by Bruce Schneier CS 6204, Spring 2005 14
Constructing Encrypted Circuits (Transfer Protocol) CS 6204, Spring 2005 15
Constructing Encrypted Circuits ( evaluate algorithm) ♦ Input: ♦ Output: – Using this output Bob can recover z – How is this done? • Bob must have access to U, the set of output key pairs produced by construct . • For each key Bob compares this key with each key pair in U. If the protocol was executed properly each output key will match one of the keys from the corresponding pair. • If the key matches the first key of the pair then Bob sets z i = 0, otherwise z i = 1. CS 6204, Spring 2005 16
Basic Scheme (Single Host) The originator, O, must choose a string id, to uniquely 1. identify the mobile code O invokes construct (C) and obtains ( C,L,K,U ). 2. • U consists of n x + n z key pairs. U x denotes the first n x key pairs in U , and U z denotes the last n z key pairs in U O, using Key PubT , encrypts each key K i,b in K, along with 3. id generated in step 1 and the index i that identifies K i,b CS 6204, Spring 2005 17
Basic Scheme (Single Host) O chooses exactly one key from each key pair in L using 4. the input bit x i as the selector, and sends these keys, along will all the encrypted keys in K-bar , U z, and id to the host, H H chooses exactly one key from each key pair in K-bar , 5. using the input bit y i as the selector, and sends these keys, along with id , to T CS 6204, Spring 2005 18
Basic Scheme (Single Host) T decrypts these keys using Key PrivateT and verifies id and 7. the index i from each • Remember that O sent a copy of id with each encrypted key, and H sent another plaintext copy of id T sends the decrypted keys, which represent the inputs 8. y i , back to H CS 6204, Spring 2005 19
Basic Scheme (Single Host) H invokes the evaluate algorithm, and obtains z from 9. U z ′ by comparing these keys with the pairs in U z , which were sent to H in step 4 Note that if O had sent U x to H in step 4 then H could • have determined ξ H forwards U x ′ to O 10. 11. O determines the final state ξ by a similar comparison with U x CS 6204, Spring 2005 20
Extension for Multiple Hosts ♦ Similar to the basic scheme with the following differences: 1. O must generate an encrypted circuit for each of the hosts 2. A mechanism is added for transferring the state of the mobile code securely between each successive host CS 6204, Spring 2005 21
Applications ♦ Comparison Shopper ♦ Generalized Auctions CS 6204, Spring 2005 22
Trusted Service vs. Trusted Hardware Both require trust 1. – Trusted service model requires Generic Secure Computation Service not to collude – Trusted hardware model requires honest hardware manufacturers Trusted hardware has knowledge of all 2. computations GSCS learns nothing about the computations 3. other than that they take place Clear speed advantage in the trusted hardware 4. approach CS 6204, Spring 2005 23
Recommend
More recommend
