EXPERT RESPONSE
Before I compare the security architectures of Java Enterprise Edition (Java EE -- previously referred to as J2EE) and Java Micro Edition (Java ME -- previously referred to as J2EE), I would like to highlight the key differences between Java EE and Java ME platforms. Although both architectures build on the core Java platform, Java EE platform is intended for developing and deploying multi-tier enterprise applications. Java ME provides the runtime environment and API technologies for addressing the needs of microdevices and embedded systems such as phones, PDAs and other consumer electronic devices with limited constraints on their resources, such as memory size, display size, processing power, network bandwidth and battery life. For this reason, the core security mechanisms offered by Java EE and Java ME are different from each other in terms of supporting their target deployment environment and its associated risks and vulnerabilities.
In general, the Java EE security architecture builds on the core Java Standard Edition (Java SE, previously referred to as J2SE) platform security. The Java EE security services ensure that all deployed components (ex. JSPs, EJBs) and the application is protected over different logical tiers, between the requests and responses and across the components and underlying enterprise resources. The Java EE infrastructure takes much of the burden of securing the application from the application developers, allowing them to concentrate on implementing the business logic of the application.
In general, most Java EE server providers offer security services by facilitating authentication and authorization mechanisms, SSL/TLS support for transport layer security, pluggable authentication and authorization support using Java Authentication and Authorization Services (JAAS) and JACC, support for Java extensible security mechanisms like Java Cryptography Extension (JCE), Java Secure Socket Extension (JSSE) etc, logging and auditing of events for identifying login attempts and failures and so forth.
Some of these mechanisms are mandated by Java EE specification and it is the responsibility of the application server vendor to ensure that these technologies are integrated into the Java EE server environment. In addition to the Java EE server provided security services, the Java EE specification dictates a standardized security model applied to Java EE components via "Container-based Security" and "Component/Tier-level Security." The Java EE container-based security services primarily address the security requirements of the application tiers and components. They provide authentication and authorization mechanisms by which callers and service providers prove each other's identities, and then they provide access control over the resources to which an identified user or system has access. A Java EE container supports two kinds of security mechanisms:
- Declarative security allows enforcement of security using a declarative syntax applied during the application's deployment
- Programmatic security allows expressing and enforcing security decisions at the application's invoked methods and its associated parameters.
The Java EE component/tier-level security addresses the security privileges and access control rights are defined by linking users, groups, roles, and realms to JSP/Servlet/EJB methods, URLs, or Web-service endpoints. This allows applying security privileges either at the application level, by mapping privileges to deployed components and their implemented methods, or at the system environment level, by mapping privileges to the operational environment and services.
Compared to Java EE, the Java ME is a slimmed-down version of Java SE platform. To enable Java ME applications to meet the device resource constraints and to run efficiently, many API components have been removed from the core Java platform. Java ME defines the notion of configurations and profiles to represent the characteristics of supported devices. Configurations are defined based on the device limitations and the characteristics of memory, display, processing power, network connectivity, and so forth.
The current Java ME specification defines two types of configurations: Connected Device Configuration (CDC) and Connected Limited Device Configuration (CLDC). CDC targets high-end consumer devices with TCP/IP network connectivity and higher bandwidth. It requires at least 2Mb memory available for the Java platform. It defines a full-featured Java virtual machine (JVM) that includes all the functionality of a Java runtime environment residing on a standard desktop system. CDC provides a full-featured Java security model and associated mechanisms of a J2SE environment including the Java sandbox security with full byte-code verification, support for Signed classes to verify the integrity and originating source of the Java classes, security policy to support fine-grained access control, and support for Java cryptography to secure programs, data, communication and retrieval.
CLDC targets low-end consumer devices, with only 128–512 kilobytes of memory required for the Java platform and running applications. It features a subset of a standard JVM with limited API and supporting libraries. In comparison to CDC security, CLDC provides a limited security model defining two levels of security. Low-level KVM security guarantees the application by a pre-verification process that rejects invalid class files and ensures that a class does not contain any references to invalid memory locations and application-level security that defines a sandbox which requires that all Java classes are verified and guaranteed to be valid Java applications.
Java ME also defines a notion of Profiles. Profiles are built on top of Java ME configurations and define API libraries that enable specific types of applications that are suitable for the target devices. Each Java ME configuration supports one or more Java ME profiles. For the smallest of devices, the Mobile Information Device Profile (MIDP) is one such profile that is built on top of the CLDC configuration. The other class of devices is based on CDC configuration use the Foundation Profile. MIDP is designed for the family of limited computing devices that have wireless network connectivity and mechanisms for user input display. A MIDlet is a Java ME application designed to run on a mobile device in compliance to a specific MIDP. To support securing MIDlet application, The MIDP 1.0 specification introduced the basic security feature that restricts all MIDlet suites to operate within a sandbox-based security model. This was primarily done to ensure that MIDlets prevent access to sensitive APIs and functions of devices, and to avoid any risks to the device resources.
|
|
 |
The MIDP 2.0 introduced the notion of trusted MIDlets to provide a flexible and consistent security model with access-control mechanisms defined by a domain policy. The device enforces access control on a MIDlet suite as trusted MIDlets in accordance with the defined domain policy. A MIDlet suite is identified as untrusted when the origin and integrity of the MIDlet suite's JAR file cannot be verified and trusted by the device. The MIDP 2.0 also specifies how MIDlet suites can be cryptographically signed so that their authenticity and originating source can be validated. Since MIDP 2.0, a MIDlet suite can be cryptographically signed and its authenticity and originating source can be validated as trusted. This is an enhanced security model for MIDP applications, which is handled via digital signatures and PKI support. In addition, The Java ME platform also provides mechanisms for using cryptographic algorithms and securing network communication using SSL/TLS protocols as well as ensuring source authentication, integrity, and confidentiality.
As noted above, both Java EE and Java ME offer full-fledged security models to support their target application environments. The most common compromises and related vulnerabilities in both the environments occur due to security development and deployment failures related to detecting the risks and choosing appropriate security mechanisms specific to the target application deployment environment. In particular, you would explore how to bake in essential security features of your target application environment using Java EE or Java MW in terms of capturing the end-to-end security requirements and addressing confidentiality, integrity, availability at all levels. To gain expertise, I would strongly suggest adopting a proactive and holistic approach in your security development process by practicing the use of security patterns, identifying applied techniques, implementation strategies and understanding the best practices and pitfalls related to your target application environment.
|
