Security in Java

Security in Java

Sunesh Kumra S-38.153

Security of Communication Protocols

Helsinki University of Technology

Sunesh Kumra / Feb 25, 2003 2

Contents Java Security Model in Java 1.0 , 1.1 and 1.2 [1] Cryptography Architecture Extensions [1] Terms and Tools [1] Exchanging signed code with help of running

example [1] Security in Java as a language [3] [4]


JDK 1.0 Security Model The "sandbox" model, existed in order to provide a very

restricted environment in which to run untrusted code obtained from the open network.

Local code is trusted to have full access to vital system resources but downloaded remote code (an applet) is not trusted and can access only the limited resources provided inside the sandbox.

A security manager is responsible in this and subsequent platforms for determining which resource accesses are allowed.


JDK 1.0 Security Model (contd.)


JDK 1.1 Security Model

JDK 1.1 introduced the concept of a "signed applet,"

A digitally signed applet is treated like local code, if the public key used to verify the signature is trusted.

Unsigned applets are still run in the sandbox.


JDK 1.2 Security Model All code, regardless of whether it is local or remote, can

now be subject to a security policy. The security policy defines the set of permissions

available for code from various signers or locations. Each permission specifies a permitted access to a

particular resource, such as read and write access to a specified file or directory or connect access to a given host and port.

The runtime system organizes code into individual domains, each of which encloses a set of classes whose instances are granted the same set of permissions.


Sample policy file keystore

"file:/c:/hut/security/java/receiverstore";

grant signedBy "sunesh" { permission java.io.FilePermission

"c:/hut/security/java/data/*", "read"; };


JDK 1.2 Security Model (contd.)


Cryptography Architecture Extensions In JDK 1.1 included support for:

digital signature generation message digest algorithms key generation algorithms

JDK 1.2 adds five more types of services: Keystore creation and management Algorithm parameter management Algorithm parameter generation Key factory support to convert between different key

representations


Cryptography Architecture Extensions (contd.)

Certificate factory support to generate certificates and certificate revocation lists (CRLs) from their encodings


Few Terms (Again !)

Certificate - This class is an abstraction for certificates that have various formats but important common uses. For example, various types of certificates, such as X.509 and PGP. (in the java.security.cert package).

A KeyStore class supplies well-defined interfaces to access and modify the information in a keystore, which is a repository of keys and certificates


Security related Tools

JDK 1.2 introduces three new tools: The keytool is used to create pairs of public

and private keys, to import and display certificate chains etc

The jarsigner tool signs JAR (Java ARchive format) files and verifies the authenticity of the signature(s) of signed JAR files.

The policyTool creates and modifies the policy configuration files that define your installation's security policy.


Running Example for Secure Code Exchange - Sender 1) Take any Java file you want to exchange securely.

For e.g. Count.java 2) Create a JAR File

jar cvf Count.jar Count.class

3) Generate Keys keytool -genkey -alias signFiles -keypass abc123 -keystore

suneshstore -storepass xyz123

4) Sign the JAR jarsigner -keystore suneshstore -signedjar sCount.jar

Count.jar signFiles


Running Example for Secure Code Exchange - Sender (contd.)

5) Export the Public Key Certificate keytool -export -keystore suneshstore -alias signFiles -file

Sunesh.cer


Running Example for Secure Code Exchange - Receiver 1) If the code is executed without Security Manager,

then there is no problem. 2) However if you run the application with the

Security Manager then we'd get an AccessControlException

java -Djava.security.manager -cp sCount.jar Count c:/hut/security/java/data/data.txt

3) Before setting the Policy files, we will have to import the certificate of the sender (person who has signed the code) and store it into the key repository


Running Example for Secure Code Exchange - Receiver(contd.)

keytool -import -alias sunesh -file Sunesh.cer -keystore receiverstore

4) You might want to verify if the certificate received is unmodified by comparing the finger prints. The sender can check the finger prints of his certificate by.

keytool -printcert -file Sunesh.cer

5) Set up the policy file 6) Run the signed code

java -Djava.security.manager -Djava.security.policy=receiverPolicy -cp sCount.jar Count c:/hut/security/java/data/data.txt


Security in Java as a Language The Java language compiler and run-time system

implement several layers of defense against potentially incorrect code.

The environment starts with the assumption that nothing is to be trusted, and proceeds accordingly.


Memory Allocation and Layout Java compiler's primary lines of defense. Memory layout decisions are not made by the Java

language compiler, as they are in C and C++. Rather, memory layout is deferred to run time, and will potentially differ depending on the characteristics of the hardware and software platforms on which the Java system executes.

Secondly, Java does not have "pointers" in the traditional C and C++ sense.

Java programmers can't forge pointers to memory, because the memory allocation and referencing model is completely opaque to the programmer.


The Byte Code Verification Process Because of the problem about the "hostile compiler",

the Java run-time system doesn't trust the incoming code, but subjects it to bytecode verification.

Verification includes checking if the format of a code fragment is correct, to passing each code fragment through a simple theorem prover to establish that it plays by the rules, like:

it doesn't forge pointers, it doesn't violate access restrictions, it accesses objects as what they are.


Byte Code verifier


Security Checks in the Bytecode Loader When a class is imported from across the network it is

placed into the private name space associated with its origin.

When a class references another class, it is first looked for in the name space for the local system , then in the name space of the referencing class. There is no way that an imported class can "spoof" a built-in class.

Built-in classes can never accidentally reference classes in imported name spaces. Similarly, classes imported from different places are separated from each other.


Byte Code verifier (contd.) The important point is that the Java bytecode loader

and the bytecode verifier make no assumptions about the primary source of the bytecode stream.

Once the verification is done, a number of important properties are known:

There are no operand stack overflows or underflows The types of the parameters of all bytecode instructions are

known to always be correct Object field accesses are known to be legal--private, public,

or protected.


Security in the Java Networking Package Java's networking package provides the interfaces

to handle the various network protocols. The networking package can be set up with

configurable levels of paranoia. You can Disallow all network accesses Allow network accesses to only the hosts from which the

code was imported Allow network accesses only outside the firewall if the

code came from outside

Allow all network accesses


References [1]http://java.sun.com/docs/books/

tutorial/security1.2/TOC.html [2]http://java.sun.com/j2se/1.4/docs/

guide/security/ [3] http://java.sun.com/security/ [4]

http://sunsite.ee/java/whitepaper/java-whitepaper-8.html

Security in Java

Documents

Transcript of Security in Java