Cryptographic Security for Mobile Code Sean Kugele CS 6204, Spring - - PowerPoint PPT Presentation

cryptographic security for mobile code
SMART_READER_LITE
LIVE PREVIEW

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


slide-1
SLIDE 1

1 CS 6204, Spring 2005

Cryptographic Security for Mobile Code

Sean Kugele

slide-2
SLIDE 2

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

slide-3
SLIDE 3

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
slide-4
SLIDE 4

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
slide-5
SLIDE 5

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
slide-6
SLIDE 6

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

slide-7
SLIDE 7

7 CS 6204, Spring 2005

Model used for Mobile Code Protection

♦ Components:

  • Originator O
  • Hosts H1, ... , HL
  • Messages M0, ..., ML
slide-8
SLIDE 8

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

slide-9
SLIDE 9

9 CS 6204, Spring 2005

Generic (non-interactive) secure mobile computing

♦ Consists of 2L + 2 algorithms: A0,...,AL B1,...,BL,

and D

slide-10
SLIDE 10

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

slide-11
SLIDE 11

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
slide-12
SLIDE 12

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,
slide-13
SLIDE 13

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
slide-14
SLIDE 14

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
slide-15
SLIDE 15

15 CS 6204, Spring 2005

Constructing Encrypted Circuits (Transfer Protocol)

slide-16
SLIDE 16

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.

slide-17
SLIDE 17

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

slide-18
SLIDE 18

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

slide-19
SLIDE 19

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

slide-20
SLIDE 20

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

slide-21
SLIDE 21

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

slide-22
SLIDE 22

22 CS 6204, Spring 2005

Applications

♦ Comparison Shopper ♦ Generalized Auctions

slide-23
SLIDE 23

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

4.

Clear speed advantage in the trusted hardware approach