| Virtual Machine Specification, Java Card Platform, v3.0.1, Connected Edition |    
|
| C H A P T E R 3 |
|
High-level Architecture and Security |
This chapter discusses the high-level architecture of a typical Java Card platform environment. This discussion serves as a starting point for more detailed specification requirements provided in later chapters.
The high-level architecture of a typical Java Card platform device is illustrated in FIGURE 3-1. At the heart of a Java Card platform implementation is the Java virtual machine, which, apart from specific differences defined later in this specification, is compliant with the Java Virtual Machine Specification and Java Language Specification. The virtual machine typically runs on top of a Host Operating System that is outside the scope of the Java Card platform.
On top of the virtual machine are the Java libraries. Some of these libraries are defined by the Java Card platform itself, as represented in FIGURE 3-1. In addition, Java Card platform framework layers define additional libraries and features that sit on top of the core platform layer.
FIGURE 3-1 High-level Architecture
The Java Card platform is capable of storing applications persistently and the Card Manager on the smart card device has capabilities for managing the applications that have been stored in the device. At the high level, application management refers to the ability to:
The Java Card platform allows multiple Java applications to execute concurrently. It is up to the particular Java Card platform implementation to decide if the execution of multiple Java applications is supported by utilizing the multitasking capabilities (if they exist) of the underlying host operating system, or by managing concurrent Java applications in the virtual machine layer.
Due to significant variations and feature differences among potential Java Card platform devices, the details of application management are highly device-specific and implementation-dependent. The responsibilities of the Card Manager and the application distribution format are described in Runtime Environment Specification, Connected Edition.
Due to its inherent security architecture, the Java technology-development platform is particularly well-suited to security-critical environments. The security model provided by the Java SE platform provides developers with a powerful and flexible security framework that is built into the Java platform. Developers can create fine-grained security policies and articulate independent permissions for individual applications, all while appearing transparent to the end user.
Retaining all the features devoted to security in the Java SE platform would require a memory budget which the Java Card platform can ill afford. Therefore, some simplifications are necessary when defining the security model for the Java Card platform. The security model of the Java Card platform is defined at the following three levels:
Low-level security, also known as virtual machine security, ensures that the applications running in the virtual machine follow the semantics of the Java programming language, and that an ill-formed or maliciously-encoded class file does not crash or in any other way harm the target device.
Application-level security means that a Java application running on a smart card device can access only those libraries, system resources and other components that the smart card device and the Java application environment allows it to access based on the security policy defined for the application.
End-to-end security refers to a model that guarantees that any transaction initiated on a device is protected along the entire path from the device to/from the entity providing the services for that transaction (e.g, a server located on the Internet). Encryption or other means may be necessary to achieve this. End-to-end security is defined in the Java Card platform framework layers of the Java Card platform that provide facilities for end-to-end software development. These facilities are described in Runtime Environment Specification, Connected Edition.
In addition to these security levels, the Java Card platform defines the application firewall and a secure transaction models as described in the Runtime Environment Specification, Connected Edition.
In the following sections, we take a more detailed look at each of these levels.
A key requirement for a Java virtual machine in a mobile information device is low-level virtual machine security. An application running in the virtual machine must not be able to harm the device in which the virtual machine is running or crash the device. In a standard Java virtual machine implementation, this constraint is guaranteed by the class file verifier, which ensures that the bytecodes and other items stored in class files cannot contain illegal instructions, cannot be executed in an illegal order, and cannot contain references to invalid memory locations or memory areas that are outside the Java platform-object memory (the object heap). In general, the role of the class file verifier is to ensure that class files loaded into the virtual machine do not execute in any way that is not allowed by the Java Virtual Machine Specification.
As will be explained in more detail in Section 5.3, Class File Verification the Virtual Machine Specification, Java Card Platform, v3.0.1, Connected Edition requires that a Java virtual machine conforming to the Java Card platform standard must be able to reject invalid class files. This is guaranteed by the class file verification technology presented in Section 5.3, Class File Verification.
Even though class file verification plays a critical role in ensuring the security of the Java platform, the security provided by the class file verifier is insufficient by itself. The class file verifier can only guarantee that the given program is a valid Java application and nothing more. There are still several other potential security threats that will go unnoticed by the verifier. For instance, access to external resources such as the file system, native libraries or the network is beyond the scope of the class file verifier. By application-level security, we mean that a Java application can access only those libraries, system resources and other components that the device and the Java application environment allows it to access based on the security policy defined for the application. The details of application-level security are discussed below.
In the Java Card platform, application-level security is accomplished by using a metaphor of a closed “sandbox.” An application must run in a closed environment in which the application can access only those libraries that have been defined by the Java Card platform and Java Card platform framework, extension libraries and other classes supported by the device. Java applications cannot escape from this sandbox or access any libraries or resources that are not part of the predefined functionality. The sandbox ensures that a malicious or possibly erroneous application cannot gain access to system resources.
More specifically, the Java Card platform sandbox model requires that:
Java Card platform framework layers may provide additional security solutions. Java Card platform framework layers also define which additional APIs are available to the application programmer.
A central requirement for the Java Card platform is the ability to support dynamic downloading of Java applications to the virtual machine. A possible application-level security hole in the Java virtual machine would be exposed if the downloaded applications could override or extend the set of the system classes provided in packages java.*, javax.* or other Java Card platform framework, or market-specific extension packages, or manufacturer-specific packages. A Java Card platform implementation MUST ensure that the application programmer cannot override, modify, or add any classes to these protected system packages.
For security reasons, it is also required that the application programmer is not allowed to manipulate the class file lookup order in any way. Class file lookup order is discussed in more detail in Section 5.4.3, Class File Lookup Order.
Dynamic loading of Java applications is a key feature of the Java Card platform. However, the Virtual Machine Specification, Java Card Platform, v3.0.1, Connected Edition defines the class loading mechanism of a virtual machine conforming to the Java Card platform to be implementation-dependent, with one important restriction: by default, a Java application can load application classes only from its own JAR file. This restriction ensures that Java applications on a device cannot interfere with each other or steal data from each other. Additionally, this ensures that a third-party application cannot gain access to the private or protected components of the Java class files that the device manufacturer or a service provider may have provided as part of the system applications. JAR files and applications representation formats are discussed in more detail in Section 5.4, Class File Format and Class Loading.
A device conforming to the Virtual Machine Specification, Java Card Platform, v3.0.1, Connected Edition is typically a part of an end-to-end solution such as a wireless network or a payment terminal network. These networks commonly require a number of advanced security solutions (such as encryption) to ensure safe delivery of data and code between server machines and client devices. Given the broad diversity of network infrastructure in the world, the Java Card platform does not mandate any specific end-to-end security mechanism. Specific end-to-end security solutions are assumed to be implementation-dependent. The Java Card platform framework layer includes infrastructure for implementing end-to-end security solutions and is described in the Runtime Environment Specification, Connected Edition.
| Virtual Machine Specification, Java Card Platform, v3.0.1, Connected Edition | 5-30-09 |
|
Copyright © 2009 Sun Microsystems, Inc. All rights reserved.