enhancing the j2me platform viren shah, gary mcgraw (pi), frank hill cigital labs [email protected]
TRANSCRIPT
The Java VM rangeThe Java VM range
J2EE
J2SE
JavaCard
J2ME
MicroChai
TINI
More resources
How Sun sees itHow Sun sees it
J2ME = CDC or CLDC configurations
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
VMs and securityVMs 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– The Trinity:
• Bytecode Verifier• Class Loader• Security Manager
Is this a house of cards?Is this a house of cards?
What happens when we knock down a few of the cards supporting the structure?
?
J2ME security
JVM security mechanisms (in the middle)
Understanding J2MEUnderstanding J2ME
• Understand the JVM security mechanism range– Examine the different Java platforms from a
security perspective
• Build a framework for describing security model features
• Dig into J2ME security
The approachThe 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
Features relevant to securityFeatures 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.
J2ME security featuresJ2ME security features
Security feature J2ME/CLDC/MIDP
Applet isolation One logical VM per MIDlet suite (record store)
Security Manager None; restricted sandbox design (API availability); some applets are superusers (load time privilege grant)
Class loading No user defined class loaders; limited support for dynamic class loading (built in loader; limited to own JAR)
Verifier J2SE verifier split in half; off-line and on-line components; STACK_MAP (all stack states for all jump destinations)
Authorization Occurs at application level (some special applications)
Stack inspection None
Native functions No JNI support; set of native functions is closed
Reflection No support in CLDC (requires a Security Manager)
Threads Nearly complete support
Garbage collection Always implemented (mark and sweep)
Exceptions Mostly supported
The framework (writ small)The framework (writ small)
Security feature
Java 2 J2ME Java Card
Applet isolation SM, RM, CL Logical VM/suite
Heap separation
Sec. Manager Stack inspection None None
Class loading Userdef/delegation Limited (no user)
None (OP)
Verifier Complete/control flow
Limited (mix) Out of band *
Authorization Code signing/JAAS App level App level/ OP
Stack inspection
Essential for SM None None
Native functions Supported/user def No JNI/closed set
No support
Reflection Fully implemented No support No support
Threads Full support Nearly complete
None (app context)
Garbage collect Always implemented
Always impl None
Exceptions Full support Mostly supported
Allowed
Security risksSecurity risks
• Off-line verification bypassing
• Lack of MIDlet suite signing support
• MIDlet loading unclear
• MIDlet removal unspecified
• No specified end-to-end security
• Record store synchronization
• MIDlet masquerading• Access to OEM
libraries unspecified• Preloading classes
constraints not detailed
• Lack of finalization• Incomplete spec of
concurrently executing MIDlet behavior
• Lack of MIDlet signing verification
Current StatusCurrent Status
• Performed security analysis of J2ME– Examined JavaCard and J2SE security models
• Created a test harness for J2ME
• Mitigation strategies are possible– Open Platform helped Java Card immensely– Static and dynamic verification steps– Centralized security management
• Want to do more than just plug security holes:– Examine trade-offs involved in the potential solutions– Build flexible solution that will offer an informed tailored
security solution based on environment/scenario
Current Java PlatformsCurrent Java Platforms
Java
J2EE JavaCardJ2MEJ2SE
Same VM and security model KVM, configurations
and profiles
JCVM, OpenPlatform
Platforms based partly on usage patterns and libraries/functionality required
J2ME SplitsJ2ME Splits
Java
J2EE JavaCardJ2MEJ2SE
Configurations based on device type
Security models differ
CDC CLDC
ConnectedDevice Configuration
Connected LimitedDevice Configuration
J2ME ProfilesJ2ME Profiles
Java
J2EE JavaCardJ2MEJ2SE
Profiles based on “vertical markets”
Additional security requirements
CDC CLDC
MIDP
Customizable SecurityCustomizable Security
Java
J2EE JavaCardJ2MEJ2SE
Finer granularity security models
Security models differ based on usage scenario
of device
CDCCLDC/MIDP
Warehouse Inventory
JBI Client Intranet Only Personal phone
Why Customizable Security?Why Customizable Security?
• Our primary focus is “enhancing” the J2ME platform– “Enhancing” doesn’t just mean adding
• Customizing the security model is a natural extension of the various Java Platforms
• Why do we want customizable security models?– Limited resources– Need for trade-offs
A High-wire Act
Constraints & Trade-offs
Constraints in J2ME Environments
Constraints in J2ME Environments• Various attributes present in the J2ME
environment present constraints for a security solution– Battery power can limit the amount of
encryption possible– Processor speed can pose limits to real-time
behavior monitoring
• What kind of attributes do we have to consider for J2ME security?
Tangible AttributesTangible Attributes
• Resource-based– Battery/power– Memory– Processor cycles– Bandwidth
• Quantifiable
Tangible resources present hard constraints!
Non-tangible AttributesNon-tangible Attributes
• Qualitative, “ility”-based– Performance – Trust– Transparency– Usability– Versatility– Availability
Non-tangible attributes present soft constraints!
Trade-offsTrade-offs
• Numerous scenarios for use of resource-constrained devices
• Each scenario engenders different priorities for the attributes
• Priorities enable trade-offs within the constraint space
One size does NOT fit all!
Example Scenario: JBIExample Scenario: JBI
• Example: JBI client– Hostile environment– Device might be compromised– High trust threshold– Ease-of-use under stressful conditions
• An appropriate security solution might require:– High encryption?– Low performance?– High usability?
Overload with SecurityOverload with Security
• Let’s consider what you might want in a JBI client that’s not mobile or resource-constrained
• Full range of security mechanisms– On-device verification
• Additional instrumentation– Behavior monitoring/IRM
– Real-time sensor data collection• Debug API• System service tracing• BSM, strace
– Fine-grained access control• Security manager & Stack inspection
– High-grade encryption– Application Management
• Trust management
Security after Resource ConstraintsSecurity after Resource Constraints
• Now let’s consider reality with resource-constrained devices
• Full range of security mechanisms– On-device verification
• Additional instrumentation– Behavior monitoring/IRM
– Real-time sensor data collection• Debug API• System service tracing• BSM, strace
– Fine-grained access control• Security manager & Stack inspection
– High-grade encryption– Application Management
• Trust management
• Partial on-device verification
• Limited application-level data collection
• Black-n-white sandbox model
• Encryption
• Application Management– Trust Management
JBI Client: Possible Security Model
JBI Client: Possible Security Model• Pseudo-trusted server
– Creates proof based on device security policy
– Adds capability enforcement instrumentation
– Embed sensors
• Device– Verification of proof +
J2ME verifier– Application
management framework
• Trust management• High-grade encryption
Capability Policy Code w/ proof
SurvivabilityEngine
IDEngine
App. Mgmt
J2ME
Modified verifier, proof checker, additional runtime checks
CodeServer
Verification engine, proof creator
Device
Example Scenario: Warehouse Inventory Management
Example Scenario: Warehouse Inventory Management • Warehouse inventory management client
– Safe environment– Talk only to a single server (maybe through proximity)– Low trust threshold
• Extreme Security Solution:– No on-device verification (low battery/memory)– Low bandwidth– High performance
Warehouse Client: Possible Security Model
Warehouse Client: Possible Security Model
• Fully trusted server– Performs verification
and capability analysis– Possible behavior
monitoring instrumentation
• Device– No verifier– No runtime checks– Simplified Application
management framework
• Encryption
App. Mgmt
J2ME
No verifier
CodeServer
Verification engine, proof creator
Secure Channel
Database/StorageServer
Range of ScenariosRange of Scenarios
Simple security model Paranoid security model
Explore this space
Maximizing Trade-offsMaximizing Trade-offs
• Different scenarios require different solutions.
• How do you ensure that you get the best tradeoffs?
Multiple implementations of feature sets allow one to make trade-offs.
More vs. Less, Good vs. Evil = Free Will
Technical Approach
Current ApproachCurrent Approach
• Build a flexible security solution– Allows for making trade-offs– Provides most appropriate security model per
scenario– Integrates enhanced security techniques– Extension of the Java multiple platform concept
• Explore J2ME feature sets– Different degrees of functionality
One brand fits all?
Project tasksProject tasks
• Customizable JVM ( July 2002 - Nov 2002)
– Dynamically loadable modules and algorithms• Enhanced on- and off-device analysis (Oct 2002 - March 2003)
– IRM, PCC– Capability analysis– Server-based analysis
• Application Management Framework (Oct 2002 - Dec 2002) – Manage MIDlet lifecycle– Centralized security enforcement
• Example Security Model Implementations (Jan 2003 - April 2003)
• Validation metrics for security models (April 2003 - Jun 2003)
Customizable JVMCustomizable JVM
• Change KVM to allow for easily replaceable components
• Use for rapid prototyping of new techniques
• Possible use in production system
• Task is ongoing
KVM
Verifier
Runtime monitoring
Class Loader
Interchangeable
ConclusionConclusion
• Project focus on exploring flexible security model– Take scenario-based priorities into account
• Constraints + Priorities = Trade-offs
• Deliver tailor-made solutions without needing a tailor
No, I’m really done…No, I’m really done…
Viren Shah ([email protected])PI: Gary McGraw ([email protected])