Transcript Viren Shah - Tolerant Systems

Enhancing the J2ME Platform
Viren Shah, Gary McGraw (PI), Frank Hill
Cigital Labs
[email protected]
The Java VM range
JavaCard
MicroChai
J2EE
More resources
TINI
J2ME
J2SE
How Sun sees it
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 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?
What happens when we knock down a few of the
cards supporting the structure?
?
J2ME security
JVM security mechanisms (in the middle)
Understanding 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 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 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 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)
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 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 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 Platforms
Java
J2EE
J2SE
Same VM and security model
J2ME
JavaCard
KVM,
configurations
and
profiles
JCVM,
OpenPlatform
Platforms based partly on usage patterns and
libraries/functionality required
J2ME Splits
Java
J2EE
J2SE
J2ME
CDC
Connected
Device Configuration
JavaCard
CLDC
Connected Limited
Device Configuration
Configurations based on device type
Security models differ
J2ME Profiles
Java
J2EE
J2SE
J2ME
CDC
JavaCard
CLDC
MIDP
Profiles based on “vertical markets”
Additional security requirements
Customizable Security
Java
J2EE
J2SE
Finer granularity
security models
Security models
differ based on
usage scenario
of device
J2ME
CLDC/
MIDP
CDC
JBI Client
JavaCard
Warehouse
Inventory
Intranet Only
Personal phone
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
Constraints & Trade-offs
A High-wire Act
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 Attributes
• Resource-based
–
–
–
–
Battery/power
Memory
Processor cycles
Bandwidth
• Quantifiable
Tangible resources present hard constraints!
Non-tangible Attributes
• Qualitative, “ility”-based
–
–
–
–
–
–
Performance
Trust
Transparency
Usability
Versatility
Availability
Non-tangible attributes present soft constraints!
Trade-offs
• Numerous scenarios for use of resourceconstrained 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: 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 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 Constraints
• Now let’s consider reality with resource-constrained devices
• Full range of security mechanisms
– On-device verification
•
Partial on-device verification
•
Limited application-level data
collection
•
Black-n-white sandbox model
•
Encryption
•
Application Management
• 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
– Trust Management
JBI Client: Possible Security Model
• Pseudo-trusted server
– Creates proof based on
device security policy
– Adds capability
enforcement
instrumentation
– Embed sensors
Code
Server
Capability Policy
• Device
– Verification of proof +
J2ME verifier
– Application management
framework
• Trust management
• High-grade encryption
Code w/ proof
App. Mgmt
ID
Engine
Verification
engine, proof
creator
J2ME
Device
Survivability
Engine
Modified
verifier, proof
checker,
additional
runtime
checks
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
• Fully trusted server
– Performs verification and
capability analysis
– Possible behavior
monitoring
instrumentation
Code
Server
Secure Channel
• Device
– No verifier
– No runtime checks
– Simplified Application
management framework
• Encryption
Verification
engine, proof
creator
App. Mgmt
Database/
Storage
Server
J2ME
No verifier
Range of Scenarios
Simple security model
Paranoid security model
Explore this space
Maximizing 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.
Technical Approach
More vs. Less, Good vs. Evil = Free Will
Current 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 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
2003)
• Validation metrics for security models
(Jan 2003 - April
(April 2003 - Jun 2003)
Customizable JVM
• Change KVM to allow for
easily replaceable
components
• Use for rapid prototyping
of new techniques
• Possible use in
production system
• Task is ongoing
Verifier
KVM
Runtime
monitoring
Class
Loader
Interchangeable
Conclusion
• 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
Questions?
Viren Shah ([email protected])
PI: Gary McGraw ([email protected])
No, I’m really done…
Viren Shah ([email protected])
PI: Gary McGraw ([email protected])