SCEA1.5 - Security

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.
Code Source:A combination of a set of signers (certificates) and a code base URLBy default, Java 2 uses a policy file to associate permissions with code sources
Security Policy File:A permission is the right to access a protected resource or guarded objectFor Java 2 permissions are specified in the security policy fileOnly one policy is in effect at a timeA policy file consists of a number of grant entriesEach grant entry describes the permissions (one or multiple) granted to a code source
Policy class - You can use java.security.Policy to create your own security policy.
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.
Given an architectural system specification, identify appropriate locations for implementation of specified security features, and select suitable
technologies for implementation of those features.
Exposure to threats can be mitigated by using:
AuthenticationAuthorization (ACLs)Protecting MessagesAuditing

Web tier authentication :
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.
EJB/EIS tier authentication:
For EJBs can use protection domains. Thus the EJB tier could entrust the web tier to vouch for the identity of users.
Put a protected web resource in front of a protected EJB resource
Have every web resource that calls an EJB resource route through a protected web resource
For access to EIS tier resources authentication is usually carried out by the component accessing the EIS resource.
You can have the container manage the EIS resource authentication or have the app do this itself.
Authorization:
In J2EE a container serves as an authorization boundary between callers and its components. The authorization boundary is inside the authentication boundary
so authorization occurs within the context of successful authentication.
For component to component invocations inside the container the calling component must make its credentials available to the called component.
You can have file-based & code-based security in J2EE.
Access control policy is set a deployment time.
Controlling access to resources in the container (deployment descriptor)
To control access to web resources, specify constraint in the deployment descriptor.To control access to EJB, specify roles in the deployment descriptor.You can specify methods of the remote & home interface that each security role is allowed to invoke
Protecting Messages:
To ensure message integrity you can use:
Message signature – a enciphered digest of the message contents (costly in terms of CPU cycles)
Message confounder – ensures message authentication is useful only once
A deployer must configure the containers involved in a call to implement integrity mechanisms either because the call will traverse open or unprotected
networks or because the call will be made between components that do not trust each other.
Auditing
When security is breached it is usually more important to know who has been allowed access than who has not.
Audit records need to be well protected – tapes or logging to a printer vs disk drive

Firewalls:
Basic Services:• Block incoming data that might contain hacker attack.• Hide information about topology of the network. Make it seems like all requests come from one IP address.• Screen outgoing traffic.
3 basic types.
Packet Filter Firewall: Looks at the information related to IP address of a packet, types of connections, etc. and then provides filtering based on that.
Uses this info. to decide which packets to let through and which to deny. IP spoofing may fool some of these.
Application-Level Proxies: Work at the application level to provide proxy services. Allows more specific inspection of the packets. Can use application level
knowledge to decide what to filter. Usually requires separate proxy for each type of application you want to filter.
Stateful Packet Inspection Firewall: Examines and remembers outgoing packets so that when incoming packets come in, that information will be used to
determine whether or not to let the incoming packets through. For example, if an incoming packet wasn’t requested by any outgoing packets, it will be
filtered.

Security:
Java sandbox consists of following elements:• Byte code verifier• Access controller• Security manager• Class loader (applet class loader, url class loader, rmi class loader, default internal class loader, custom built class loaders)• Security package (security provider interface, message digests, keys, certificates, digital signatures, encryption)
AccessControllerChecking permission is done by checking the permissions associated with the protection domain for each method on the stack starting from the top. If each
protection domain on the stack allows access, then it is granted.
Using PrivilegedAction and PrivilegedExceptionAction, protection domains can grant privileges to code that has called it but not to code that it calls.
GuardedObjectAllows you to embed another object within it such that all access to that object will first have to go through a guard, usually the AccessController.
MessageDigestSmall sequence of bytes that represents the actual input data. In order to use the digest, you also need a copy of the original data so that you can
calculate the digest on it again and compare it to the digest that was given to you. For example, to do authentication, the user needs to enter his
id/password but you don’t want that to be sent in clear text over the network so they send you the digest instead. Then you take that and compare it to a
digest that you calculate on their password and if it matches the digest they sent to you, then you can authenticate them. Message digests do not need any
key to calculate. Also you can’t derive anything about the actual data from the digest.
Digital SignatureUsed to uniquely identify an entity, non-repudiation. The way it works is you calculate a message digest on some piece of data and then you encrypt that
digest with your private key. Then you send that data along with the encrypted digest to the other party. The other party then uses that data to calculate
another digest and then encrypts it with your public key. Then they compare it to the signature that you sent them and if it matches, then your identity is
verified.
CertificateContains 3 pieces of information:• Name of entity for whom certificate has been issued, known as the “subject”• Public key associated with the subject• Digital signature of the issuer (some CA) of the certificate which verifies the information in the certificate.
Java Security
AccessController introduced in 1.2.
In 1.2, classes on the CLASSPATH can also be subject to a security model.
Bytecode verifier verifies the Java language safety constraints of the bytre code:• In 1.1, all non-local classes are sent thru byte code verification.• In 1.2, all classes except core Java classes are sent thru verification.
Classloaders work with security manager to enforce security roles:• Classloader knows where class was loaded from.• Knows whether or not the class came with a digital signature.• Different instances of classloaders group classes into different namespaces based on which instance of the classloader loaded it.
In 1.2, SecureClassLoader was introduced.
In 1.2, URLClassLoader was introduced.
Classloaders have to load the system classes first.

Trusted vs. Untrusted Classes:
In JDK 1.0, classes loaded from CLASSPATH are considered trusted while those loaded from a class loader are untrusted.
In JDK 1.1, same rules apply but a class loaded from a jar file may have a digital signature giving it more privileges.
In JDK 1.2, classes form core API are trusted and other classes are given privileges based on where they were loaded (codebase, codesource?). However, this
requires special command-line args. BY default, classes from CLASSPATH are considered trusted.

Thread Security:
Threads are grouped into a hierarchy---in theory, the policy of security should be such that threads may only manipulate threads that are below them in the
hierarchy.
In JDK 1.1, this isn’t true, each applet is given an individual thread group and threads within that group can manipulate other threads within that group
without respect to any hierarchy.
In JDK 1.2, thread hierarch operates as expected.
Untrusted classes may only manipulate threads that they have created.Untrusted classes may only manipulate thread groups that they have created.
Threads of untrusted classes must belong to specified groups .
AccessController
CodeSource: encapsulation of location from which classes were obtained.
Permission: encapsulation of request to perform a particular operation.
Policies: encapsulation of all the specific permissions that should be granted to specific code sources.
ProtectionDomain: encapsulation of a codesource and the permissions granted to that particular code source.
Security Policy
Policy file:• Collection of policy entries.• Each entry is specific to one code source and should list all permissions for that code source.• Single policy file can have multiple entries.• May contain an additional entry to specify the location of the keystore in which public keys for the signers listed the policy file should be found.• Each grant entry represents a protection domain.
Protection Domain
Each class in the VM may belong to one and only one protection domain. Set by the class loader when the class is defined.
The permissions for any particular operation can be considered to be the intersection of all permissions of each protection domain on the stack at the time
the operation is called.
Using the “doPrivileged” method of the AccessController, you can temporarily allow a class to perform an action that it normally would not be allowed to do.
Keys
Key factory and key specifications available only in Java 1.2. They allow for exporting and importing keys using various specifications.
Keys from the Sun provider use DSA algorithm.
Key pair generation is done by KeyPairGenerator, a standard engine of Java security.
Key Management
KeyCertificateIdentities
“Keytool” stores individual private and public keys with retrieval subject to a password.
“Keystore” is the database of the keytool.
Keytool works on a file that contains a set of private keys and certificates for those keys.
Each entry in the keystore has:• Alias: name for referencing that entity• One or more certificates for that entity’s identify.• Optionally, a private key which can be protected by a password.
Represented by the “KeyStore” class.
There are 2 types of entries: Key entry and Certificate entry.
Key entries contain both public and private keys and may contain multiple certificates in a certificate chain.
Certificate entries contain only public keys in a certificate.

Signed Classes:
Delivered as signed jar files.
In JDK 1.1, use “javakey” to sign it.
In JDK 1.2, use “jarsigner” to sign it.
Each file in a jar file may be signed by a different group of identities and some may not be signed.
Encryption
“KeyGenerator” class used for generating new secret keys.
“SecretKeyFactory” converts from algorithmic or encoded key specifications to actual key objects and translates keys from one implementation to another.
“KeyAgreement” class can also be used to generate secret key between multiple people. SunJCE provider uses “Diffie-Hellman” protocol for generation.

Applet Security:
Most browsers limit a lot of things that applets can do. Sun’s appletviewer allows more access to applets.
Two ways in which applets can be considered trusted:• Applet is installed on local disk in a directory in the CLASSPATH.• Applet is signed by identity marked as trusted in your identity database (keystore?).
Applets cannot do the following things with files:• Check for the existence of the file.• Read the file• Write the file.• Rename the file.• Create a directory on the client file system• List the files in this file (as if it were a directory)• Check the file’s type.• Check the timestamp of when the file was modified.• Check the file’s size.
Using Sun’s appletviewer, you can grant applets special privileges to perform those file operations.
Applets cannot open network connection to any host other than the one it came from (the host where the html page was obtained or the host specified in the
codebase parameter of the applet tag.
To open network connection, the host name has to be specified exactly the same. If you used an IP address, you can’t use a name now and vice versa.
Applets loaded through client’s local file system using CLASSPATH can do the following:• Read and write files.• Load libraries on the client.• Execute processes.• Exit the VM.• Are not passed through bytecode verifier.