Transcript - W&L CS Web Application Server

Mobile Code Security via Fragile
Tamper Detection Marking
Mike Jochen+, Lisa Marvel++, & Lori Pollock+
+ University of Delaware
{jochen, pollock}@cis.udel.edu
++ U.S. Army Research Laboratory
[email protected]
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:
javaEnv.eps
Creator:
fig2dev Version 3.2 Patchlevel 1
Preview :
This EPS picture w as not saved
w ith a preview included in it.
Comment:
This EPS picture w ill print to a
PostScript printer, but not to
other ty pes of printers .
Java Framework with TDM
Java Framework
Title:
framew ork.eps
Creator:
fig2dev Version 3.2 Patchlevel 1
Preview :
This EPS picture w as not saved
w ith a preview included in it.
Comment:
This EPS picture w ill print to a
PostScript printer, but not to
other ty pes of printers .
Embedding Data in Classfiles
ClassFile {
unsigned int
unsigned short
unsigned short
unsigned short
cp_info
unsigned short
unsigned short
unsigned short
unsigned short
unsigned short
unsigned short
field_info
unsigned short
method_info
unsigned short
attribute_info
}
magic_number;
//oxCAFEBABE
minor_version;
major_version;
cp_size;
constant_pool[cp_size-1];
access_flags;
this_class;
super_class;
inter_count
interface[inter_count];
field_count;
field[field_count];
method_count;
method[method_count];
att_count;
attributes[att_count];
• 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.
The Embed/Extract Process
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 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
A Simple Example
import java.io.*;
public class Hello {
public static void main(String[] argv) {
System.out.println(“Hello World!”);
}
}
Java source code for Hello World!
public void <init>()
Code(max_stack=1, max_locals=1 code_length=5)
0: aload_O
1: 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
Method Table for Hello World!
Compare the Constant Pools
1)
2)
3)
...
16)
17)
18)
...
23)
24)
25)
...
CONSTANT_Methodref[10](class_index=6, name_and_type_index=15)
CONSTANT_Fieldref[9](class_index=16), name_and_type_index=17)
CONSTANT_String[8](string_index=18)
CONSTANT_Class[7](name_index=23)
CONSTANT_NameAndType[12](name_index=24, signature_index=25)
CONSTANT_Utf8[1](“Hello World!”)
Original
Constant
Pool
table
CONSTANT_Utf8[1](“java/lang/System”)
CONSTANT_Utf8[1](“out”)
CONSTANT_Utf8[1](“Ljava/io/PrintStream;”)
Constant
Pool
Table
with TDM
...
8)
9)
10)
11)
...
13)
14)
...
20)
21)
...
22)
...
CONSTANT_Methodref[10](class_index=3, name_and_type_index=1)
CONSTANT_Fieldref[9](class_index=14, name_and_type_index=20)
CONSTANT_String[8](string_index=21)
CONSTANT_Utf8[1](“out”)
CONSTANT_Utf8[1](“Ljava/io/PrintStream;”)
CONSTANT_CLass[7](name_index=23)
CONSTANT_NameAndType[12](name_index=11, signature_index=13)
CONSTANT_Utf8[1](“Hello World!”)
CONSTANT_Utf8[1](“java/lang/System”)
Results/Evaluation
• Time analysis:
b = # bits in classfile,
n = # lines in constant pool table
h = # bits in hash value
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
Permute
FindPerm
O(n)
Embed = O(b) + O(nlogn) +
O(hash(b)) +
O(encrypt(h))
Extract = O(b) + O(n3) +
O(hash(b)) +
O(decr(h))
O(decrypt(h))
O(n3)
Average Execution Times
0.8
0.7
0.6
0.5
0.4
0.3
0.2
0.1
0
Embed
Benchmark
Ch
ec
k
Co
m
pr
es
s
Db
Je
ss
it
Ch
ec
k
trt
Extract
M
Average TIme (secs)
Average Embed/Extract Times per Classfile
Total Execution Times
Total Embed/Extract Times per Benchmark
14
12
Time (secs)
10
8
Embed
Extract
6
4
2
0
Mtrt
Checkit
Jess
Db
Benchmark
Compress
Check
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. AddisonWesley, 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