Download ISEC0511

ISEC0511
Programming for Information
System Security
Lecture Notes #5
Java Client-Side Security
1
Java




Java language derived much of its syntax from C and
C++, but the object model is much simpler and has
fewer low-level facilities.
As Java removes many of low-level facilities,
programmers can make less mistakes, resulting in
more secured programs.
Source code files (.java) are compiled into bytecode
that can run on any Java Virtual Machine (JVM),
which is independent of the operating systems.
Java is designed to write-once-run-anywhere.
2
Java Application Development
Java Source
Code (*.java)
JVM
(Windows)
Java
Compiler
JVM
(Linux)
Java Bytecode
(*.class)
JVM
(Solaris)
3
Java Example

Sample java code.
public class Hello {
public static void main(String[] args) {
System.out.println("Hello World!");
}
}
4
Java Framework

Main features of Java framework are:


Platform independent. One should be
able to write a code once and run it
anywhere, on any platform. JVM itself is a
native application that runs on a specific
platform.
Automatic memory management.
Programmers allocates memory for data,
but JVM’s garbage collection will collect
unused objects and free memory to the
operating system.
5
Java Framework

Java sandbox. Java differentiates
between trusted and untrusted code and
provides a restricted environment in which
the untrusted code can run while giving full
access to the trusted.
6
Java Security Infrastructure

Platform security.


Java includes built-in language security
features that are provided by the Java
compiler and runtime.
Cryptography.

Java includes a comprehensive application
programming interface (API) with support
for various cryptographic algorithms and
services.
7
Java Security Infrastructure

Authentication and access control.


Java includes the abstract authentication
APIs that can incorporate a wide range of
login and fine-grained access control
mechanisms.
Secure communication

Java includes APIs and implementations for
standards-based secure communication
protocols.
8
Java Platform Security

Java platform security features can be
categorized into two main groups:


Security features enforced by the compiler
in the static state.
Security features that are enforced by the
JVM at the runtime.
9
Java Compiler Security

Java compiler enforces the following
language rules to enforce security.



Private data and methods can be accessed only
from the same class.
Programs cannot access memory locations
directly.
Any entity that is declared “final” cannot be
changed.
final int strictData = 10;
…
strictData = 100;
// error
10
Java Compiler Security

Variables cannot be used unless they are
initialized.
String password;
…
System.out.println(password);

// error
Objects cannot be cast into other objects.
Integer
i;
i = new Integer(1);
…
String s = (String)i;
// error
11
Java Virtual Machine Security

Java bytecode verifier security.

To prevent invalid or crafted bytecode to
run on a virtual machine, bytecode verifier
inside the JVM will check also for errors.
12
Java Virtual Machine Security

Java runtime security enforcement

Additional security checks are performed
during runtime, for example checking array
index bounds.
void exceedIndex(int arr[], int n) {
for (int i = 0; i < n; i++) {
arr[i] = 0;
}
}

Violations will result in an exception.
13
JCA and JCE

Java offers a range of security tools and
services to develop a secured and safe
program.


Java Cryptography Architecture (JCA)
provides a set of APIs for digital signatures,
message digests, symmetric and asymmetric
encryption and decryption, session key generation
and management, and public key generation and
management.
Java Cryptography Extension (JCE) extends
the JCA API to include APIs for encryption, key
exchange, and Message Authentication Code
(MAC).
14
Java Cryptography Application
Programming Interface

Major principles of JCA

Implementation independence.
Applications can request services from that
platform. Thus, the application is
dependent of the implementation
Application
Application
Algorithm A
By Vendor P
Algorithm A
By Vendor Q
JVM
JVM
15
Java Cryptography Application
Programming Interface

Implementation interoperability.
Applications use the service though
standard interface, not specific to a
provider.
Application
Application
Encrypt()
Encrypt()
Algorithm A
By Vendor P
Algorithm A
By Vendor Q
JVM
JVM
16
Java Cryptography Application
Programming Interface

Algorithm extensibility. New security
providers can be added to the existing Java
platform
Algorithm A
JVM
Algorithm A
Algorithm B
Algorithm C
JVM
17
Message Digest

Hash or digest exhibit the following
characteristics:




Collision free. You cannot have two different
inputs that generate the same output.
One way. Given any input message, you can
generate a hashed output; however, given any
hash value, you cannot generate the original
message.
Unique. Any specific input will always generate
the same unique output all time.
Java supports MD5, SHA-1, SHA-256,
SHA-384, SHA-512 (Sun JDK-5)
18
Message Digest with Java
MessageDigest
md;
md = MessageDigest.getInstance(algorithmName);
md.update(text.getBytes(), 0, text.length());
byte[] digest = md.digest();
19
Message Authentication Codes




A message authentication code (often
MAC) is a short piece of information used to
authenticate a message.
MAC value protects both a message's data
integrity as well as its authenticity.
There are several types of MAC algorithms.
One way to create a MAC is by using the
hashed message authentication code (HMAC)
algorithm as described in RFC 2104.
20
Message Authentication Codes


MAC or HMAC is similar to message digest.
The difference is that you add a secret key
with the message to create a MAC.
21
Message Authentication Codes



MAC is used between two parties to check
the integrity of the message by verifying
whether the content that has been
transmitted between two parties has been
altered or not.
Two parties share a unique secret key.
HMAC can be used with any cryptographic
algorithm like MD5 or SHA-1.
22
HMAC with Java
// Generate secret key for HMAC-MD5
KeyGenerator kg = KeyGenerator.getInstance("HmacMD5");
SecretKey sk = kg.generateKey();
// Get instance of Mac object implementing HMAC-MD5, and
// initialize it with the above secret key
Mac mac = Mac.getInstance("HmacMD5");
mac.init(sk);
byte[] result;
result = mac.doFinal("This is the content".getBytes());
23
Digital Signatures




Signatures ensure integrity and nonrepudiation.
Content has not been tampered with in transit, and
also that it has been sent by the specified sender.
You take the message and then create a MAC and
then this MAC is signed by encrypting the MAC with
the private key of the signer (sender), which
produces a digital signature.
The signature can only be decrypted with the public
key of the sender, it guarantees the identity of the
sender proving non-repudiation.
24
Ciphers



Cryptographic ciphers are used to ensure
confidentiality so that the meaning of the
message cannot be derived by any adversary.
This is achieved through encryption and
decryption.
Java supports many modern algorithms which
can be used by programmers, including AES,
RSA, RC4, DES3.
25
Key Generation




The strength of a cipher is more dependent
on the size of the key and how difficult it is to
get the key.
Size of the key is generally called keyspace.
A key generator will get a key with a large
keyspace that is random and difficult to
guess.
Java can generate key pair and secure
random data for programmers.
26
Java Secure Sockets Extension



When data travels across a network, it is
possible that it might get intercepted
somewhere by someone who is not the
intended recipient.
It needs to be ensured that the data has not
been modified while in transit.
Protocols such as Secure Sockets Layer
(SSL) and Transport Layer Security
(TLS) have been designed to handle such
situations.
27
Java Secure Sockets Extension



SSL/TLS allows programs to tunnel any
program data inside an encrypted tunnel.
Java Secure Sockets Extension (JSSE)
provides a framework for developing
applications in Java that can use the SSL and
TLS protocols.
Java supports both secure and non-secure
sockets for applications.
28
SSL Connections with Java
// Client
sslsocketfactory = (SSLSocketFactory)
SSLSocketFactory.getDefault();
sslsocket = (SSLSocket)sslsocketfactory.createSocket
("localhost", 9999);
// Server
sslserversocketfactory = (SSLServerSocketFactory)
SSLServerSocketFactory.getDefault();
sslserversocket = (SSLServerSocket)
sslserversocketfactory.createServerSocket(9999);
sslsocket = (SSLSocket) sslserversocket.accept();
29
Authentication and Access Control



Java platform provides a pluggable
architecture for incorporating login and
access control mechanisms.
Application is independent of underlying
authentication mechanism.
Programmer can change the authentication
mechanism without changing the application
code.
30
Authentication and Access Control



Java achieves authentication and
authorization by using the Java
Authentication and Authorization Service
(JAAS).
JAAS was an optional package before JDK
1.4.
In JDK 1.4 onwards it was integrated as part
of the Java platform.
31
Java Sandbox



Java security model centers around the idea
of a sandbox.
A sandbox is a security enclosure for safely
running computer programs.
Sandbox typically provides a controlled set of
resources for guest or untrusted programs to
run in.
32
Java Sandbox


Java sandbox is responsible for protecting a number of
resources on your machine.
The user’s machine has access to many things such as:
 It has access to its local memory (the computer’s
RAM).
 It has access to its file system and to other
machines on the local network.
 For running applets, it also has access to a Web
server, which may be on its intranet or the Internet.
 Data flows through this network model, from the
user’s machine through the network and (possibly)
to the disk.
33
Java Sandbox



You may give the program certain
permissions but you would want to limit the
actions that the running program can take on
your machine.
Java’s sandbox started with a very restrictive
approach.
The concept is:


All trusted code can have access to all resources
on the machine.
All untrusted code can run in a very restrictive
environment, which is defined by the sandbox.
34
Java Sandbox


By default, local code (same machine) is
considered trusted.
Code from network is run inside sandbox.
35
Sandbox Policy File


Permissions inside Java sandbox can be
configured using policy file.
Policy file can control various types of
permission, including:




Disk access
Network access
Audio access
System information
grant codeBase "file:${java.home}/lib/ext/* " {
permission java.security.AllPermission;
};
grant {
permission java.util.PropertyPermission "java.version", "read";
permission java.util.PropertyPermission "java.vendor", "read";
permission java.io.FilePermission "${user.home}", "read";
};
36
Java Applets Security



Applets are small applications that are hosted
on an Internet server.
Applets are transported over the Internet
using a Web browser, automatically installed,
and run as part of a Web document at the
client machines.
Example of HTML file containing an applet.
<applet width=300 height=300 code="DrawingLines.class"></applet>
37
Basic Applet Lifecycle

What browser does includes:






reads the Hypertext Markup Language (HTML) page
and finds an <APPLET> tag.
parses the <APPLET> tag to find the CODE and
possibly CODEBASE attribute to know the location of
the applet to be downloaded.
downloads the .class file for the applet from the URL.
converts the raw bytes downloaded into a Java class.
instantiates the applet class to form an applet object.
starts the applet program (inside the sandbox).
38
What an Applet Can Do

Following is a list of functions that an
applet can perform.





Draw pictures on a Web page.
Create a new window and draw in it.
Play sounds.
Receive input from the user through the
keyboard or the mouse.
Make a network connection to the server
from which it came and can send to and
receive arbitrary data from that server.
39
Applet Security Policy

File Access Restrictions



No applet is allowed to access the local file system
in any way, not even in a read-only mode.
Otherwise someone could implant an invisible
applet on their Web page and they could snoop
your hard drive and copy files from it.
You may be allowed to read and write files if your
applets loaded from the local file system using a
URL of type “file:”.
40
Applet Security Policy

Network Restrictions



The general concept of network security is that
applets can only make network connections back
to the Web server from which they were
downloaded.
An applet is not allowed to listen for incoming
socket connections, nor can it listen for datagrams
from anywhere but its home server.
It also can only send datagrams back to its home
server from which it has been downloaded.
41
Applet Security Policy

Other restrictions




A local applet may read and write the system
properties.
System properties like information about the local
machine, which could include the host name and
IP address, are not accessible to an applet.
An applet is not allowed to call native methods.
Applets cannot execute commands on the local
system using the Runtime.exec method.
42
Signed Applets



A signed applet can access local system
resources as allowed by the local system’s
security policy.
You define the rights of the applet by
specifying in the policy file how much access
to local system resources this signed applet
or application can have.
If your applet requires access to local system
resources, the applet must be signed with a
valid certificate, and the local system must
have a policy file configured to allow the
43
access.
Readings

Java Client Side Security, Chapter 6.
44