390 likes | 547 Views
Enhancing the J2ME Platform. Viren Shah, Gary McGraw (PI), Frank Hill Cigital Labs viren@cigital.com. The Java VM range. JavaCard. MicroChai. J2EE. More resources. TINI. J2SE. J2ME. How Sun sees it. J2ME = CDC or CLDC configurations. CLDC Constrained CPU 16 or 32 bit 512K or less
E N D
Enhancing the J2ME Platform Viren Shah, Gary McGraw (PI), Frank Hill Cigital Labs viren@cigital.com
The Java VM range JavaCard MicroChai J2EE More resources TINI J2SE J2ME
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
Applet isolation Security manager Class loading Verifier Authorization Stack inspection Native functions Reflection Threads Garbage collection Exceptions Features relevant to security These features are architected and implemented differently throughout the JVM range.
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 Security risks
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 J2ME JavaCard KVM, configurations and profiles Same VM and security model JCVM, OpenPlatform Platforms based partly on usage patterns and libraries/functionality required
J2ME Splits Java J2EE J2SE J2ME JavaCard CDC CLDC Connected Device Configuration Connected Limited Device Configuration Configurations based on device type Security models differ
J2ME Profiles Java J2EE J2SE J2ME JavaCard CDC CLDC MIDP Profiles based on “vertical markets” Additional security requirements
Customizable Security Java J2EE J2SE J2ME JavaCard Finer granularity security models Security models differ based on usage scenario of device CDC CLDC/ MIDP JBI Client 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 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: 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 • 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 Verification engine, proof creator • 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 Code Server Capability Policy Code w/ proof App. Mgmt Modified verifier, proof checker, additional runtime checks ID Engine J2ME Device Survivability Engine
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 • Device • No verifier • No runtime checks • Simplified Application management framework • Encryption Verification engine, proof creator Code Server Secure Channel No verifier App. Mgmt Database/ Storage Server J2ME
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 (Jan 2003 - April 2003) • Validation metrics for security models (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 (viren@cigital.com) PI: Gary McGraw (gem@cigital.com)
No, I’m really done… Viren Shah (viren@cigital.com) PI: Gary McGraw (gem@cigital.com)