1 CS 6204, Spring 2005
Cryptographic Security for Mobile Code Sean Kugele CS 6204, Spring - - PowerPoint PPT Presentation
Cryptographic Security for Mobile Code Sean Kugele CS 6204, Spring - - PowerPoint PPT Presentation
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
2 CS 6204, Spring 2005
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
3 CS 6204, Spring 2005
Security Problems in Mobile Code
1.
Protecting the host executing the code from malicious mobile code
- Sandboxing, Proof Carrying Code
2.
Protecting the mobile code from malicious hosts
- Far less developed
- Concern of this paper
4 CS 6204, Spring 2005
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
5 CS 6204, Spring 2005
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
6 CS 6204, Spring 2005
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
7 CS 6204, Spring 2005
Model used for Mobile Code Protection
♦ Components:
- Originator O
- Hosts H1, ... , HL
- Messages M0, ..., ML
8 CS 6204, Spring 2005
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: – gj: X × Yj → X – hj: X × Yj → Zj
9 CS 6204, Spring 2005
Generic (non-interactive) secure mobile computing
♦ Consists of 2L + 2 algorithms: A0,...,AL B1,...,BL,
and D
10 CS 6204, Spring 2005
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
11 CS 6204, Spring 2005
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
12 CS 6204, Spring 2005
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,
13 CS 6204, Spring 2005
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
14 CS 6204, Spring 2005
Oblivious Transfer Example
1.
Alice generates two public/private key pairs and sends both public keys to Bob
2.
Bob generates a symmetric key KBob and choosing one of Alice’s public keys he encrypts KBob without telling Alice which public Key
3.
Alice decrypts KBob using both of her private keys, producing both KBob and another key which is garbage. But Alice does not know which is KBob and which is garbage
4.
Alice encrypts both of her message, one with KBob and the other with the garbage key, and sends both back to Bob
5.
Bob, using KBob is able to decrypt on of Alice’s messages but not both, and Alice has no idea which message Bob actually received
- paraphrased from Applied Cryptography by Bruce Schneier
15 CS 6204, Spring 2005
Constructing Encrypted Circuits (Transfer Protocol)
16 CS 6204, Spring 2005
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 zi = 0, otherwise zi = 1.
17 CS 6204, Spring 2005
Basic Scheme (Single Host)
1.
The originator, O, must choose a string id, to uniquely identify the mobile code
2.
O invokes construct(C) and obtains (C,L,K,U).
- U consists of nx + nz key pairs. Ux denotes the first nx key pairs in
U, and Uz denotes the last nz key pairs in U
3.
O, using KeyPubT , encrypts each key Ki,b in K, along with id generated in step 1 and the index i that identifies Ki,b
18 CS 6204, Spring 2005
Basic Scheme (Single Host)
4.
O chooses exactly one key from each key pair in L using the input bit xi as the selector, and sends these keys, along will all the encrypted keys in K-bar ,Uz, and id to the host, H
5.
H chooses exactly one key from each key pair in K-bar, using the input bit yi as the selector, and sends these keys, along with id , to T
19 CS 6204, Spring 2005
Basic Scheme (Single Host)
7.
T decrypts these keys using KeyPrivateT and verifies id and 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
8.
T sends the decrypted keys, which represent the inputs yi, back to H
20 CS 6204, Spring 2005
Basic Scheme (Single Host)
9.
H invokes the evaluate algorithm, and obtains z from Uz′ by comparing these keys with the pairs in Uz, which were sent to H in step 4
- Note that if O had sent Ux to H in step 4 then H could
have determined ξ
10.
H forwards Ux ′ to O
- 11. O determines the final state ξ by a similar
comparison with Ux
21 CS 6204, Spring 2005
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
22 CS 6204, Spring 2005
Applications
♦ Comparison Shopper ♦ Generalized Auctions
23 CS 6204, Spring 2005
Trusted Service vs. Trusted Hardware
1.
Both require trust
– Trusted service model requires Generic Secure Computation Service not to collude – Trusted hardware model requires honest hardware manufacturers
2.
Trusted hardware has knowledge of all computations
3.
GSCS learns nothing about the computations
- ther than that they take place