Presentation is loading. Please wait.

Presentation is loading. Please wait.

Mobile Code Security via Fragile Tamper Detection Marking Mike Jochen+, Lisa Marvel++, & Lori Pollock+ + University of Delaware {jochen,

Similar presentations


Presentation on theme: "Mobile Code Security via Fragile Tamper Detection Marking Mike Jochen+, Lisa Marvel++, & Lori Pollock+ + University of Delaware {jochen,"— Presentation transcript:

1 Mobile Code Security via Fragile Tamper Detection Marking Mike Jochen+, Lisa Marvel++, & Lori Pollock+ + University of Delaware {jochen, ++ U.S. Army Research Laboratory

2 Mobile Code Defined & Issues Definition: –A–Any code you didnt compile on your own machine –D–Differentiation between mobile code & mobile agents Issues: –A–Availability & use on the rise (thanks, Java) –M–Many benefits –B–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?

3 Addressing Security for Mobile Code Dont 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

4 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)

5 Steganography & Java, perfect together? Embed security info in the code –What sort of info? Enable user to verify code hasnt been altered Enable user to authenticate authors 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!!

6 Framework Java Framework Java Framework with TDM

7 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?

8 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)

9 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.

10 Embed Algorithm INPUT: 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 refs 3. 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 Algorithm INPUT: 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 refs 3. hash C_copy; 4. extract TDM from C; //inversePermutation 4. decrypt TDM; 5. return (hash = decrypted TDM); The Embed/Extract Process

11 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 MD b hash SHA b 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

12 import java.io.*; public class Hello { public static void main(String[] argv) { System.out.println(Hello World!); } public void () Code(max_stack=1, max_locals=1 code_length=5) 0: aload_O 1: invokespecial java.lang.Object. ()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

13 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 Constant Pool table Constant Pool Table with TDM Compare the Constant Pools

14 Embed = O(b) + O(nlogn) + O(hash(b)) + O(encrypt(h)) Extract = O(b) + O(n 3 ) + O(hash(b)) + O(decrypt(h)) Results/Evaluation Time analysis: b = # bits in classfile, n = # lines in constant pool table h = # bits in hash value

15 Average Execution Times

16 Total Execution Times

17 Evaluation We dont 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)?

18 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

19 References Appel & Felten. Proof-carrying authentication. CCS Proceedings. ACM, November Ghosh. On certifying mobile code for secure applications. SRE Proceedings. IEEE, November Lingholm & Yellin. The Java Virtual Machine. Addison- Wesley, Murray. Mobile code. Government Computer News. December Necula. Proof-carrying code. POPL Proceedings. ACM, January Sander & Tschudin. Towards mobile cryptography. RSP Proceedings. IEEE, May 1998


Download ppt "Mobile Code Security via Fragile Tamper Detection Marking Mike Jochen+, Lisa Marvel++, & Lori Pollock+ + University of Delaware {jochen,"

Similar presentations


Ads by Google