Presentation is loading. Please wait.

Presentation is loading. Please wait.

Small Java VM’s and Security Gary McGraw, Ph.D.

Similar presentations

Presentation on theme: "Small Java VM’s and Security Gary McGraw, Ph.D."— Presentation transcript:

1 Small Java VM’s and Security Gary McGraw, Ph.D.

2 2 Project goals Year one –Understand the JVM security mechanism range –Build a framework for describing security model features –Dig into J2ME security Year two –Research application of advanced security mechanisms to constrained platforms –Use J2ME devices as a real world target

3 3 The classic security tradeoff How do resource constraints impact Java’s standard security mechanisms? Strategy: understand the range –Classic Java Security Architecture –J2ME security –Java Card Security

4 The JVM Range Provide a scientific framework for understanding VM security mechanisms

5 5 The Java VM range J2EE J2SE JavaCard J2ME MicroChai TINI More resources

6 6 How Sun sees it

7 The original sandbox The Byte Code Verifier Enforce type safety (some progress on Java Card) The Class Loader System Namespace management, dynamic loading The Security Manager API-level access control and enforcement

8 8 VMs and security Different resource constraints support different language and VM features –Features removed to save memory/time/battery –Little formal impact analysis Java’s security architecture is a set of interconnected blocks –Meant to work in concert –Mutually dependant

9 9 Is this a house of cards? What happens when we knock down a few of the cards supporting the structure? ?

10 Defining a Framework JVM security mechanisms (in the large)

11 11 The approach Examine security models of the Java language and VMs –Bytecode verifier, Class loader, Security Manager, Stack Inspection –Multi-threading, Garbage Collection, etc Examine select implementations of smaller Java VMs –Java Card (leveraging commercial work for Visa/MasterCard) –J2ME Understand how physical constraints impact security –Memory –Power (both computational and battery) –Connection –Environment

12 12 Features relevant to security Applet isolation Security manager Class loading Verifier Authorization Stack inspection Native functions Reflection Threads Garbage collection Exceptions These features are architected and implemented differently throughout the JVM range.

13 13 The framework (writ small) Security featureJava 2J2MEJava Card Applet isolationSM, RM, CLLogical VM/suiteHeap separation Sec. ManagerStack inspectionNone Class loadingUserdef/delegationLimited (no user)None (OP) VerifierComplete/control flowLimited (mix)Out of band * AuthorizationCode signing/JAASApp levelApp level/ OP Stack inspectionEssential for SMNone Native functionsSupported/user defNo JNI/closed setNo support ReflectionFully implementedNo support ThreadsFull supportNearly completeNone (app context) Garbage collectAlways implementedAlways implNone ExceptionsFull supportMostly supportedAllowed

14 J2ME security JVM security mechanisms (in the middle)

15 15 J2ME = CDC or CLDC configurations CLDC –Constrained CPU –16 or 32 bit –512K or less J2ME environment –JVM layer –Configuration layer –Profile layer (API) Vertical markets Apps written to profile layer MID profile

16 16 J2ME devices exist today (Japan)

17 17 Not just phones KVM (40-80K) –Offline bytecode verification –No Security Manager –No Garbage Collection CLDC –No app lifecycle –No user interface/ app model –No event handling MIDP –Application behavior and support –MIDlets (MIDlet suite) –Nothing on: app management, app level security, channel security

18 18 J2ME security features Security featureJ2ME/CLDC/MIDP Applet isolationOne logical VM per MIDlet suite (record store) Security ManagerNone; restricted sandbox design (API availability); some applets are superusers (load time privilege grant) Class loadingNo user defined class loaders; limited support for dynamic class loading (built in loader; limited to own JAR) VerifierJ2SE verifier split in half; off-line and on-line components; STACK_MAP (all stack states for all jump destinations) AuthorizationOccurs at application level (some special applications) Stack inspectionNone Native functionsNo JNI support; set of native functions is closed ReflectionNo support in CLDC (requires a Security Manager) ThreadsNearly complete support Garbage collectionAlways implemented (mark and sweep) ExceptionsMostly supported

19 19 J2SE feature relations

20 20 J2ME feature relations

21 21 Attacks and defenses Invalid byte code –STACKMAP is new Trust problems –User decides how much trust to give a MIDlet MIDlet masquerading –User interface issues! –Web spoofing revisited Inter-MIDlet interactions –Attacking barriers –Corrupting the record store –Locking the interface –Changing MIDlet suite state Denial of service –Disruptive and easy to do

22 22 Security strategy Development 1.Valid tools 1.Compiler 2.Stack map 2.Trusted MIDlet suites 3.Unit and System Testing Deployment 1.Trust of source and signee (big hole in this stage) Execution 1.Load time verification 2.Dynamic runtime checking 3.Careful privilege API design 4.MIDlet suite sandbox

23 23 Security risks I 1.Off-line verification bypassing –No trusted channel –Subvert STACKMAP 2.Lack of MIDlet suite signing support 3.MIDlet loading unclear –Unspecified in CLDC/MIDP 4.MIDlet removal unspecified 5.No specified end-to-end security –No requirements or guidelines for vendors –No crypto API 6.Synchronization of record store may cause starvation –Locking issues 7.MIDlet masquerading –Web spoofing attacks

24 24 Security risks II 8.Access to OEM libraries unspecified –Device specific –Vendor mistakes possible 9.Constraints on preloading classes not detailed (what/security) 10.Lack of finalization –DoS –Privacy leaks 11.Incomplete spec of concurrently executing MIDlet behavior –Concurrency issues between vendors 12.Lack of MIDlet signing verification –Trust propagation

25 25 Moving forward Mitigation strategies are possible –Open Platform helped Java Card immensely –Additional static and dynamic analysis –Carefully specify OEM library security requirements We intend to probe real devices against these risks –Test suite for J2ME –Attacks against J2ME devices –Create or borrow mechanisms to address risks (especially OASIS technologies)

26 26 Questions J2ME security has yet to receive much security attention –Java Card was in a similar state in 1997

Download ppt "Small Java VM’s and Security Gary McGraw, Ph.D."

Similar presentations

Ads by Google