Deep Java Virtual Machine (3)--Security

Because the network allows multiple computers to share data and distributed processing, it provides a potential way to invade a computer system, allowing others to steal information, change or destroy information, steal computer resources, and so on. To address security issues caused by the network, the Java architecture employs an extended, built-in security model that continues to evolve with the major versions of the Java platform:

Basic Sandbox for version 1.0
1.1 Version of code signing and authentication
Fine-grained access control for version 1.2

The Java security model focuses on protecting end-users from malware downloaded from unreliable sources, malicious programs (and bugs in well-intentioned programs). To do this, Java has implemented a sandbox environment (the basic sandbox) starting with JDK 1.0, which restricts unreliable activities, and the program can do anything within the sandbox's security boundaries, but not any move across those boundaries.

But because the initial sandbox restrictions are too restrictive, well-intentioned (but unreliable) code often fails to work effectively. In version 1.1, improvements have been made to introduce a trust model based on code signing and authentication. This allows the receiving terminal system to be able to confirm that a series of class files (in a jar file) have been digitally signed (valid and trustworthy) by an entity, and that the class files have not changed after the signature, This allows end users and system administrators to reduce restrictions on some code in the sandbox, but the code must already be digitally signed by a trusted community.

Although the security APIs released in version 1.1 contain support for authentication, in fact, there is no practical help beyond providing full trust and full-trust policies (in other words, the code is either completely trusted or I am completely untrusted). The following 1.2 releases provide APIs that can help establish granular security policies.

Here's a closer look at basic sandbox, code signing and authentication, and how granular access control is implemented.

Basic sandbox

Java sandbox security is based on three basic aspects of the Java Runtime Environment: bytecode Verifier (bytecode validator), Security Manager (Safety Manager), and ClassLoader (class loader).

Bytecode Verifier: It ensures that the downloaded code is properly formatted, that the bytecode ("Java virtual machine" directive) does not violate the security restrictions of the language or virtual machine (no illegal data conversions), that no pointer addressing is performed, that the internal stack cannot overflow or underflow, and bytecode directives will have the correct type parameters.

Security Manager: It attempts to perform file I/O and network I/O, create new ClassLoader, manipulate threads or thread groups, start processes on the underlying platform (operating system), terminate "Java virtual machines", load non-Java libraries (native code) into the JVM, Run-time access control is initiated when a type of window system operation is completed and a class of classes is loaded into the JVM.

The Classloader:java program (class file) is not a local executable program. When running a Java program, the JVM (the Java Virtual machine) is run first, and then the Java class is loaded into the JVM, and the part that loads the Java class is called Class Loader. When running a program, the JVM starts, runs Bootstrapclassloader, and the ClassLoader loads the Java Core API (Extclassloader and Appclassloader are also loaded at this time), Then call Extclassloader to load the extension API, and finally Appclassloader load the class defined in the Classpath directory, which is the most basic loading process for a program.

Code Signing and authentication

The authentication strategy introduced in Java1.1 's Java.security package enables users to build multiple security policies by implementing a sandbox. Authentication allows users to believe that class files secured by certain groups have a high degree of confidence and that these class files are not changed in the network transmission before they reach the Java virtual machine. This simplifies the sandbox's restrictions on the Certified Code and establishes different security restrictions for code that is signed by different groups.

To secure a signature for a piece of code, you first generate a public/private key pair. The user wants to expose the public key and keep the private key. The class file and other files that will be signed are then placed in a jar file, and the entire JAR file is signed with the Jarsigner tool, such as the SDK. This signature tool will first hash the jar file with a single hash, then sign the hash with the private key and add the signature to the end of the jar file to complete your digital signature of the jar file.

A large amount of input in a hash calculation of a digital signature is the byte stream that makes up the contents of the jar file, resulting in a small amount of data that cannot contain all of the input information. This calculation is one-way: from large to small, from input to hash. To enhance security, use the private key for encryption. Because private key encryption is a very time-consuming process, we only encrypt the private key of the hash. A public/private key pair has the following characteristics: It is very difficult to generate a private key in the case of a public key only, and any code encrypted with the private key can be decrypted with the paired public key. Because different inputs can produce the same hash, the probability of generating the same hash depends primarily on the size of the hash. In practice, hashing mainly uses 64-bit or 128-bit, so it is not feasible to calculate the length of the same hash from different inputs. The encrypted hash value is then added to the same jar file, which also contains the file that you originally generated the hash.

The recipient must decrypt the signature hash with the public key, and verify that a signed JAR file can be validated by obtaining the same result as the hash computed from the jar file. If the resulting hash value matches the decrypted hash value, it indicates that the recipient received the jar file is indeed guaranteed by the sender, and the transmission process has not been modified, this file security is guaranteed. This allows the jar file to be placed in a general sandbox that is not very secure, and this sandbox trusts the sender's signature.

Fine-grained access control

One of the main goals of the security architecture for version 1.2 is to make it easier and less error-prone to establish fine-grained access control policies based on signed code. In version 1.2 of the security architecture, an access control policy that corresponds to an entire Java application is represented by a single instance of a subclass of the abstract class Java.security.Policy.

A security policy is a mapping from a collection of properties that describe the running code to the permissions that the code has. In version 1.2 of the security architecture, the properties that describe running code are always referred to as the source of the code. A source of code is represented by an Java.security.CodeSource object that contains a Java.net.URL that represents the code base and an array of 0 or more certificate objects representing the signer. A certificate object is an instance of a subclass of abstract class Java.security.cert.Certificate, a Certificate object abstraction that represents a binding from one person to a public key, and another that guarantees the binding (the certificate authority previously mentioned). The Codesource object contains an array of certificate objects, because the same piece of code can be signed by multiple groups (vouch for). This signature is usually obtained from the jar file.

Permissions are represented by an instance of a subclass java.security.Permission the abstract class. A Permission object has three properties: type, name, and optional action.

In the policy object, each codesource is associated with one or more permission objects. The permission object associated with a codesource is encapsulated in a subclass instance of Java.security.PermissionCollection.

Resources:
"Deep Java Virtual Machine Second Edition"
Http://www.2cto.com/Article/201210/162438.html
Http://www.1k2k.net/ligongkeji/2012/0507/52776.html

Deep Java Virtual Machine (3)--Security