JCEA Part 1: Java Security

1. General
2. References
3. Syllabus
   1. Concepts
   2. Common architectures
   3. Legacy connectivity
   4. EJB
   5. EJB Container model
   6. Protocols
   7. Applicability of J2EE
   8. Patterns
   9. Messaging
   10. Internationalisation
   11. Security
4. Reference
   1. UML
5. Resources
6. Further Tips

• Identify security restrictions that Java 2 technology environments normally impose on applets running in a browser
• Given an architectural system specification, identify appropriate locations for implementation of specified security features and select suitable technologies for implementation of those features

Java 2 Security Model

The Java 2 security model is policy-based and has superseded the sandbox/trusted approach of Java 1.1.

In Java 1.1 remote code (applets, for example) that was not trusted was constrained to the sandbox. If the remote code was signed and trusted then it could access local resources. In Java 2 all class that are loaded from the classpath, i.e. not bootstrap classes, are subject to security constraints. These are set using a Java policy file and enforced using the Java Security Manager.

By default the Java Security Manager is not installed when running Java Applications. this behaviour can be changed by starting it using code:

System.setSecurityManager(new SecurityManager());

or when starting the application by using:

-Djava.security.manager

Applets

Applets are started using a restrictive Java policy file. Some examples of permitted activities are:

• Create a thread
• Manipulate AWT event queue
• Read but not modify some system properties
• Make network connections to the host from which it was loaded

Some example of denied operations are:

• Any operation that might compromise the host (excluding CPU, memory or bandwidth usage)
• Make network connections to arbitary hosts
• Access to the file system
• Restricted access to IO system so can't open top level windows (with no secuity warning)

The java.security package

The following are some of the classes in the java.security package:

CodeSource

This class extends the concept of a codebase to encapsulate not only the location (URL) but also the certificate(s) that were used to verify signed code originating from that location.

KeyStore

This class represents an in-memory collection of keys and certificates. It manages keys and trusted certificates

MessageDigest

The MessageDigest class provides applications the functionality of a message digest algorithm, such as MD5 or SHA.

Permission

Abstract class for representing access to a system resource

Policy

This is an abstract class for representing the system security policy for a Java application environment (specifying which permissions are available for code from various sources).

ProtectionDomain

The ProtectionDomain class encapulates the characteristics of a domain, which encloses a set of classes whose instances are granted the same set of permissions.

Security

Centralizes all security properties and common security methods.

Security Architectures

Foundations

A typical sucurity system will use the following techniques to keep information safe:

Identification

The principle (individual making a request) identifies themself to the system. Typically identified using a password

Authentication

The process of confirming that a principle is who they claim. Often using a password or PIN, but potentially using biometrics, e.g. fingerprints. Some options for doing this at the web tier are:

Basic HTTP

the web server authenticates a principal with user name & password from Web client

Form-based

lets developers customize the authentication user

HTTPS mutual authentication

the client and server use X.509 certificates to establish identity over a SSL channel.

Authorisation

Checking that the authenticated principle or their associated role has the privilages to do the work requested. Often enforced using Access Controll Lists (ACLs) or Resource Access Control (RAC)

Protecting messages

Messages can either be transmitted in encrypted form or in clear with a message signature attached (a enciphered digest of the message contents which is costly in terms of CPU cycles)

Auditing

Despite all other measures auditing is required to stop persistant attacks from breaking into a system

Cryptography

Cryptography is the name given to techniques that allow information to be temporarly transformed as it passes throgh public view making it unreadable.

There are two distinct forms of cryptography:

1. Symmetric
2. Asymmetric

1. Symmetric

The key used to transform a message between its original and encrypted form is shared by the sender and recipient. The major consequences of this are:

• The key must be securely shared between the sender and recipient which means that there is typically a significant overhead as the key is passed through some secure medium, e.g. a person to person meeting.
• The algorithm that uses the key to transform data is not considered a part of teh security syetem and may be made public
• Undemanding on system resources to encrypt and decrypt information

2. Asymmetric aka public key cryptography

• Removes the need for the keys to be privately shared as the public key can be sent to all potential senders of encryped information in clear. They then use the key to encrypt the information before sending it to the receipient who is the only holder of a private key which is required to decypher it.
• Demanding on system resources when encrpting and decrypting information
• Often used to exchange symmetric keys so that faster symmetric encryption can be used, but without the overhead of exchanging keys in person - or by some other secure form

Signatures and Certificates

By using a private key to encrypt a message (the opposite of asymmetric crptography) it is possible to verify that the sender of a message held the private key. If we know that the identity of the only holder of that key then we can assert to the identify of the message sender. Rather than applying this process to the whole message it is usually applied to representative section of it, called a digest..

The problem of knowing that the real identity of the holder of a private key is significant. To solve this problem it is possible to create a certificate that contains a public key and identity details. This certificate is in turn is signed by another entity who verifies the authenticity of the certificate. This entity is typically a certificate authority (CA), The CA will either have a certificate which in turn is signed by another authority or it will be a root certificate authority who who choose to trust.

It is intended that the effort of verifying that a root certificate authority is who they claim is worthwhile and pracical. In practice though they are trusted because they are set as defaults in software we use, e.g. internet browsers.

Certificate authorities will authenticate a certificate after verifying the identity of the certificate's owner using a set of rules set down in their Certification Practice Statement (CPS). These rules can be very casual checks and so an important part of trusting a certificate should be dependant on the CPS of the CA.

Security Tools

Secure Sockets Layer (SSL)

SSL is a framework for two hosts to set up encryption between themselves. It included negotation of

• The encryption algorithm to use
• How to exchange certificates
• Which keys to use

The encryption algorithm will typically be symmetric, e.g. DES and the keys will be exchanged using a short asymmetric session or more usually using the DIffie-Hellman key exchange which allows two parties to invent a key between themselves without making it available to any party that intercepted their complete exchange.

HTTPS

When HTTP is passed over a SSL infrastructure it is called HTTPS. This is different to the earlier SHHTP - which is usually o longer appropriate.

HTTPS will use the encryption chosen by SSL, which could potentially be weak. It also will exchange certificates if available. Although an increasing number of online vendors will have a certificate most consumers will not. This means that although a consumer can be reasonable sure that a vendor is who they claim, a vendor will ahve less confidence in the identity of a consumer.

Web Logins

One solution to identifying a consumer is by asking them to log in using a identifier and password. This process is only as secure as the process used to identify the consumer before providng them with a password.

In many cases a web login is used only to provide a tailored view of a system to the user and so little security is required when distributing passwords. In other cases the password will be distributed by a semi-secure medium (e.g. post) or a secure medium (e.g. by hand). Whatever the case the exchange protocol should be suitably secure for the level of trust that is required for a particular situation.

Network Topologies

Simple Firewall

Two Firewalls and a DMZ

A demilitarized zone (DMZ) contans all the services which are provided externally allowing a second , more restrictive, firewall to be used to secure the internal network.

In this topology the second firewall is typically very restrictive allowing no traffic through directly from the outside. Instead a proxy server may be used to forward appropriate requests.

This topology may be extended by utilising it inside the intranet to secure sensitive sections or data.

Tunneling

Tunneling through a network is a way of getting through firewalls by wrapping a particular service to make it appear to be a another, permitted, service. Wrapping as HTTP is often used.

Tunneling may be used to provide acecss to an external service. In this case the best solution is likely to be to open the firewall to allow the service rather than tunneling to get through an existing port.

Tunneling to get out a network is a more reasonable approach and may be used where you provide a service, e.g. an Applet, that is run inside of a network you have no authority over but which needs to conenct to an external service.

1. Sun's security FAQ
2. Netscape has a very nice white paper
3. One more goodie from Netscape is available. A very helpful resource.
4. A whitepaper on FireWalls & DMZ 
5. There is another whitepaper available on Enterprise Security on 3Com's website.
6. Another update from Dylan Walsh, is available
7. Security FAQ
8. Sun security example