Mobile Code Security via Fragile Tamper Detection MarkingMike Jochen+, Lisa Marvel++, & Lori Pollock+

+ University of Delaware{jochen, pollock}@cis.udel.edu

++ U.S. Army Research Laboratorymarvel@arl.army.mil

Mobile Code Defined & Issues• Definition:

– Any code you didn’t compile on your own machine– Differentiation between mobile code & mobile agents

• Issues:– Availability & use on the rise (thanks, Java)– Many benefits– But can you trust running this code on your local

machine?• Who is the author, really?• Has this code been altered on its way to your machine?• Is this code going to be “well behaved?”

Addressing Security for Mobile Code• Don’t execute it! (Murray ‘99)• Use certificates to authenticate author

(Ghosh ‘98)• Sandbox (Lindholm ‘99, Hauswirth ‘00) • Encryption (Sander ‘98)• Proof carrying code (Appel ‘99, Necula ‘97)• Sign code with digital signature

Is there another way?• Have the executable image (code) serve as the

authentication medium– No central point of failure (cert. server)– Less cumbersome than sandbox policies– Less ‘obtrusive’ than encryption– No separation of code & authentication data (sigs.,

certs., & PCC)

Steganography & Java,perfect together?

• Embed security info in the code– What sort of info?

• Enable user to verify code hasn’t been altered• Enable user to authenticate author’s identity

– How?• Blind system

– User must be able to extract & verify info independently– User has no access to source code or original executable

image

• Can not change semantic meaning of code!!

Framework

Title:framework.epsCreator:fig2dev Version 3.2 Patchlevel 1Preview:This EPS picture was not savedwith a preview included in it.Comment:This EPS picture will print to aPostScript printer, but not toother types of printers.

Java Framework

Java Framework with TDM

Title:javaEnv.epsCreator:fig2dev Version 3.2 Patchlevel 1Preview:This EPS picture was not savedwith a preview included in it.Comment:This EPS picture will print to aPostScript printer, but not toother types of printers.

ClassFile { unsigned int magic_number; //oxCAFEBABE unsigned short minor_version; unsigned short major_version; unsigned short cp_size; cp_info constant_pool[cp_size-1]; unsigned short access_flags; unsigned short this_class; unsigned short super_class; unsigned short inter_count unsigned short interface[inter_count]; unsigned short field_count; field_info field[field_count]; unsigned short method_count; method_info method[method_count]; unsigned short att_count; attribute_info attributes[att_count];}

Embedding Data in Classfiles

• What info can we embed & where can we embed it?

Our Approach• Where is the ‘noise’ (appearance of randomness) in the

classfile?– Ordering of constant pool table– Can we change this order without adversely affecting the

code?

• What to embed?– Hash of classfile

• User can generate this same as server can• Need good one-way hash function with small chance for

collisions

– Encrypt hash value for added protection– We call this the Tamper Detection Mark (TDM)

Issues with Our Approach• Reordering constant pool entries re-indexing

references throughout classfile– Interface names– Attributes (Exception, Line Number, & Local Variable)– Methods (bytecode & attributes)– Fields– Constant pool objects which refer to other constant pool

entries• Reordering constant pool entries will change the hash

value• Re-indexing references to constant pool entries will

change the hash value• Last two issues mean we must find some sort of

canonical form of the classfile with which to start.

Embed AlgorithmINPUT: Java classfile, C;Output: Java classfile, C, with embedded TDM;1. make copy of C (C_copy)2. put C_copy in canonical form; //sorted Constant Pool

//update all CP refs3. hash C_copy;4. encrypt hash value;5. permute original CP in C given encrypted hash value;6. update refs to CP in C to reflect new CP order;

Extract AlgorithmINPUT: Java classfile, C;Output: Boolean (T/F) if C is validated;1. make copy of C (C_copy);2. put C_copy in canonical form; //sorted Constant Pool //update all CP refs3. hash C_copy;4. extract TDM from C; //inversePermutation4. decrypt TDM;5. return (hash = decrypted TDM);

The Embed/Extract Process

The Nitty Gritty• How does our system fit within JVM? Keep

separate?• What sort of encryption (DES, 3DES, RSA?)• Constant Pool Table size dictates capacity

– Using two hash algs• MD5 - 128b hash• SHA1 - 160b hash

– Let L = # lines in pool, H = # bits in hash• Given L, choose H such that: L! 2H (L-1)!• Need 35 pool entries to hide 128b number• Need 41 entries for 160b number

import java.io.*;public class Hello { public static void main(String[] argv) { System.out.println(“Hello World!”); }}

public void <init>()Code(max_stack=1, max_locals=1 code_length=5)0: aload_O1: invokespecial java.lang.Object.<init> ()V (1)4: return

public static void main(String[])Code(max_stack=2, max_locals=1 code_length=9)0: getstatic java.lang.System.out Ljava/io/PrintStream; (2)3: ldc “Hello World!” (3)5: invokevirtual java.io.PrintStream.println (Ljava/lang/String;)V (4)8: return

Java source code for Hello World!

Method Table for Hello World!

A Simple Example

1) CONSTANT_Methodref[10](class_index=6, name_and_type_index=15) 2) CONSTANT_Fieldref[9](class_index=16), name_and_type_index=17) 3) CONSTANT_String[8](string_index=18)...16) CONSTANT_Class[7](name_index=23)17) CONSTANT_NameAndType[12](name_index=24, signature_index=25)18) CONSTANT_Utf8[1](“Hello World!”)...23) CONSTANT_Utf8[1](“java/lang/System”)24) CONSTANT_Utf8[1](“out”)25) CONSTANT_Utf8[1](“Ljava/io/PrintStream;”)...

... 8) CONSTANT_Methodref[10](class_index=3, name_and_type_index=1) 9) CONSTANT_Fieldref[9](class_index=14, name_and_type_index=20)10) CONSTANT_String[8](string_index=21)11) CONSTANT_Utf8[1](“out”)...13) CONSTANT_Utf8[1](“Ljava/io/PrintStream;”)14) CONSTANT_CLass[7](name_index=23)...20) CONSTANT_NameAndType[12](name_index=11, signature_index=13)21) CONSTANT_Utf8[1](“Hello World!”)...22) CONSTANT_Utf8[1](“java/lang/System”)...

Original ConstantPooltable

ConstantPoolTablewith TDM

Compare the Constant Pools

Operation Embed Extract

Re- index O(b) O(b)

Sort CP O(nlogn) O(nlogn)

Hash O(hash(b)) O(hash(b))

Encrypt O(encr(h))

Decrypt O(decr(h))

Permute O(n)

FindPerm O(n3)

Embed = O(b) + O(nlogn) +O(hash(b)) +O(encrypt(h))

Extract = O(b) + O(n3) +O(hash(b)) +O(decrypt(h))

Results/Evaluation• Time analysis:

b = # bits in classfile,n = # lines in constant pool tableh = # bits in hash value

Average Embed/Extract Times per Classfile

00.10.20.30.40.50.60.70.8

Mtrt

Check

itJe

ss Db

Compr

ess

Check

Benchmark

Ave

rag

e T

Ime

(se

cs)

Embed

Extract

Average Execution Times

Total Embed/Extract Times per Benchmark

0

2

4

6

8

10

12

14

Mtrt Checkit Jess Db Compress Check

Benchmark

Tim

e (

secs

)

Embed

Extract

Total Execution Times

Evaluation• We don’t ‘break’ any classfiles• A one bit change in protected classfile signals

error• Encrypted TDM for added protection• If shared key is compromised, system breaks• Perhaps a little too sensitive (false positives)?

Conclusion/Future Work• Add small hash (UMAC/UHASH)• Add RSA

– Multi-cast– True authentication/non-refutiation– Simpler/more secure key management

• Turn fragile system into a robust one– Enables other uses like protection of intellectual

property rights

References• Appel & Felten. Proof-carrying authentication. CCS

Proceedings. ACM, November 1999.• Ghosh. On certifying mobile code for secure

applications. SRE Proceedings. IEEE, November 1998.• Lingholm & Yellin. The Java Virtual Machine. Addison-

Wesley, 1999.• Murray. Mobile code. Government Computer News.

December 1999.• Necula. Proof-carrying code. POPL Proceedings. ACM,

January 1997.• Sander & Tschudin. Towards mobile cryptography. RSP

Proceedings. IEEE, May 1998