Security in Java
Sunesh Kumra
S-38.153
Security of Communication Protocols
Helsinki University of Technology
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]
Sunesh Kumra / Feb 25, 2003
2
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.
Sunesh Kumra / Feb 25, 2003
3
JDK 1.0 Security Model (contd.)
Sunesh Kumra / Feb 25, 2003
4
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.
Sunesh Kumra / Feb 25, 2003
5
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.
Sunesh Kumra / Feb 25, 2003
6
Sample policy file




keystore
"file:/c:/hut/security/java/receiverstore";
grant signedBy "sunesh" {
permission java.io.FilePermission
"c:/hut/security/java/data/*", "read";
};
Sunesh Kumra / Feb 25, 2003
7
JDK 1.2 Security Model (contd.)
Sunesh Kumra / Feb 25, 2003
8
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
Sunesh Kumra / Feb 25, 2003
9
Cryptography Architecture
Extensions (contd.)

Certificate factory support to generate certificates and certificate
revocation lists (CRLs) from their encodings
Sunesh Kumra / Feb 25, 2003
10
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
Sunesh Kumra / Feb 25, 2003
11
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.
Sunesh Kumra / Feb 25, 2003
12
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


3) Generate Keys


jar cvf Count.jar Count.class
keytool -genkey -alias signFiles -keypass abc123 -keystore
suneshstore -storepass xyz123
4) Sign the JAR

jarsigner -keystore suneshstore -signedjar sCount.jar Count.jar
signFiles
Sunesh Kumra / Feb 25, 2003
13
Running Example for Secure Code
Exchange - Sender (contd.)

5) Export the Public Key Certificate

keytool -export -keystore suneshstore -alias signFiles -file
Sunesh.cer
Sunesh Kumra / Feb 25, 2003
14
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
Sunesh Kumra / Feb 25, 2003
15
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
Sunesh Kumra / Feb 25, 2003
16
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.
Sunesh Kumra / Feb 25, 2003
17
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
Sunesh
Feb 25, 2003
18
completely opaque
to Kumra
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.
Sunesh Kumra / Feb 25, 2003
19
Byte Code verifier
Sunesh Kumra / Feb 25, 2003
20
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.
Sunesh Kumra / Feb 25, 2003
21
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.
Sunesh Kumra / Feb 25, 2003
22
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
Sunesh Kumra / Feb 25, 2003
23
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/javawhitepaper-8.html
Sunesh Kumra / Feb 25, 2003
24