Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
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])