George Blank
University Lecturer
Java Security
Overview of Java Security features
Java Technology uses three mechanisms to ensure safety.
• Language design features(bounds checking on
arrays,legal type conversions etc).
• An access control mechanism that controls what the code
can do(file access, network access etc).
• Code signing: code authors can use standard
cryptographic algorithms to authenticate java
programming language code. Users of the code can
determine who created the code and whether the code is
altered or not after it was signed.
Java 2 Security Architecture
Bootstrap
class files
System
class files
User class
files
CodeSource(URL,
Certificates)
Bytecode Verifier
Policy Database
Bootstrap
ClassLoader
System
ClassLoader
Security Manager
Operating System
Hardware
ClassLoader
Permissions
Protection Domains
AccessController
Keystore
Byte Code Verifier
Checks a classfile for validity:
• Code should have only valid instructions and register
use.
• Code does not overflow/underflow stack.
• Does not convert data types illegally.
• Accesses objects correct types.
• Method calls use correct number and types of
parameters.
• References to other classes use legal names.
Class Loaders
• Is an important link in security chain and loads java byte
codes into the JVM.
• It works in conjunction with the security manager and
access controller to enforce security rules.
• It is involved in enforcing some security decisions earlier in
an objects lifetime than the security manager.
• Information about the URL from which the code is
originated and the code’s signers is initially available to the
ClassLoader.
Class Loaders
• Customized ClassLoader or a subclass from
java.security.SecureClassLoader provides security features
beyond the standard Java2 security model.
• ClassLoader loads classes into VM and is responsible for
the namespaces at runtime. Namespaces as identically
named identifiers can reference different objects.
• Primordial class loader loads bootstrap classes in a platformdependent manner.
• System classes, some classes in java.* package are
essential to the JVM and the runtime system are loaded by
System ClassLoader.
Code Source
• Java Code is downloaded over a network, so the
code's signature and author are critical to maintain a
secure environment.
• The object java.security.CodeSource describes a
piece of code.
• CodeSource encapsulates the code's origin, which is
specified as an URL.
• Set of digital certificates containing public keys
corresponding to the set of private keys are used to
sign the code
Security Policy Files
• SecureClassLoader assigns permissions
when loading classes, by asking policy
object to look up the permissions for the code
source of each class.
• Own Policy class can be installed to carry out
mapping from code sources to permissions.
Security Policy Files
• Example of a policy file:
grant codebase www.horstmann.com/classes
{ permission java.io.Filepermission “/tmp/*” , “read, write”;
}
The above file grants permission to read and write files in the
/tmp directory to all code that was downloaded from
www.horstmann.com/classes
Security Policy Files
Policy files can be installed in standard locations and
the two default locations are
• The file java.policy in the java platform home
directory.
• The file .java.policy in the user home directory.
The locations of these files in the java.security
configuration files can be changed
Security Policy Files
• During testing standard files are not modified and
hence policy file is required for each application.
• For this purpose place permissions into a separate
file such as MyApp.policy and start the interpreter as
java –Djava.security.policy=MyApp.policy MyApp
For applets
appletviewer –J-Djava.security.policy=MyApplet.policy
MyApplet.html
Security Policy Files
• In the previous example MyApp.policy file is
added to other policies in effect. If you add a
second equal sign, such as
java –Djava.security.policy==MyApp.policy MyApp
then your application uses only the specified
policy file and standard policy files are
ignored.
Security Policy Files
• Policy file contains a sequence of grant entries. Each
entry has the following form.
grant codesource
{ permission_1;
permission_2
……….. }
• The code source contains a code base and the names of trusted
certificate signers.
• The code base is specified as Codebase “url”
Security Policy Files
• If the code base url ends with a /, it refers to a
directory, otherwise it is taken as a JAR file.
grant codebase “www.horstmann.com/classes/”{…}
grant codebase “www.horstmann.com/classes/MyApp.jar” {…}
• The code base is an url and should always
contain forward slashes as file separators,
even for url’s in windows.
Permissions
• Permission classes represent access to various
system resources such as files, sockets and so on.
• Collection of permissions can be construed as a
customizable security policy for an installation.
• Permission classes represent approvals, but not
denials.
• Permissions granted to a ProtectionDomain also
called "privileges"
Permission Subclasses
File permission class.
• Gives rights to local files/directories.
• Path name/pattern.
Specific path:file,directory,directory/file.
All files in directory: directory/*.
All files recursively in directory: directory/-.
For current directory, omit "directory/."
For all files (dangerous), "<<All Files>>."
• Rights set (1+): read,write,execute,delete.
Socket Permission
• Host.
Local Machine: "local host."
Given machine: IP address or hostname.
All hosts in a domain: *.domain.
All hosts: *.
• Portrange.
Single port: portnumber.
Port range: port1-port2, port1-,-port2.
• Actions(1+): accept,connect,listen,resolve.
PropertyPermission
• Gives rights to properties.
Similar to OS environment variables.
• Target.
Specific property: os.name.
Pattern: java.*.
• Actions (1+): read,write.
Other Permission SubClasses
• Runtime Permission: string with permission name
- createClassLoader
- getClassLoader
- setSecurityManager
- exitVM
Policy Files for Homework
• On your homework assignments, you will want to think about
permissions for the client and server, and make sure you give
permissions for both the host name or IP address and the port
number. You may also need access to ports on the local host to
access utilities like HTTP for an applet. Example:
grant
{
permission java.net.SocketPermission
"afs1.njit.edu:1950-2000","connect,accept,resolve";
permission java.net.SocketPermission
"afs1.njit.edu:80","connect";
};
Security Manager
• The class java.lang.SecurityManager is the focal point of
authorization.
• SecurityManager is concrete, with a public constructor
and appropriate checks in place to ensure that it can be
invoked in an authorized manner.
• It consists of a number of check methods.
eg: CheckPermission method is used to check to see if
the requested access has the given permission based on
policy.
AccessController
The java.security.AccessController class is used for three
purposes.
• To decide whether access to a critical system resource
should be allowed or denied, based on the security policy
currently in effect.
• To mark code as privileged, thus affecting subsequent
access determinations.
• To obtain a snapshot of the current calling context, so
access-control decisions from a different context can be
made with respect to the saved context.
Keystore
• Keystore is a password-protected database that
holds private keys and certificates.
• The password is selected at the time of creation.
• Each database entry can be guarded by its own
password for extra security.
• Certificates accepted into the keystore are
considered to be trusted.
Core Security
Java 2's security pieces reside primarily in:
• java.lang
• java.security
• java.security.cert
• java.security.interfaces
• java.security.spec
Core Security
Java.lang.
• Contains the SecurityManager class, which allows
applications to implement a security policy.
• The SecurityManager determines the operation's
identity and whether it can be performed in its
security context.
Core security
java.lang
• The manager contains many methods that begin with
the word check.
Eg.
SecurityManager security =
System.getSecurityManager();
if (security != null) {
security.checkXXX(argument, . . . );
}
Core security
java.security.
• Contains most security classes and interfaces.
• It contains classes for access control, parameters for the
various cryptographic algorithms, code source, guarded
objects, key management, message digests, permission,
policy, protection domains, providers, secure class loaders,
random number generators, and digital signatures.
• The following Java code can be used to produce a
permission to read files in the /tmp directory.
FilePermission p = new FilePermission("/tmp/*", "read");
Core Security
java.security.
Entries in the policy file can also be used to achieve
similar results. The following is a sample entry in the
policy file that indicates the granularity of providing
access.
// Sample policy file
grant signedBy "signer_names", codeBase "URL" {
permission permission_class_name
"target_name", "action",
signedBy "signer_names";
};
Core Security
• Many classes provide a Service Provider Interface
(SPI) for providers to plug in their implementations.
Examples include MessageDigest, Signature,
KeyPairGenerator, and so on.
• The MessageDigest class supports the MD5 and
SHA algorithms.
Core Security
• The getInstance() method is invoked to select the
appropriate algorithm.
• The method update() is called to ready the input
buffer, while the digest() method generates a
message digest, the size of which (in this case, 128
bits, or 16 bytes) depends on the algorithm (in this
case, MD5).
• The digest() method would generate 160 bits (20
bytes) for the digest if the SHA algorithm was used.
Core Security
• The java.security.cert package deals with certificates. It
provides, for instance, an abstract class to import,
generate, and verify X.509 certificates.
• The java.security.interfaces package is a set of interfaces
used to generate DSA and RSA key pairs.
• The java.security.spec package may be used to control
the parameters for various algorithms, like DSA or RSA,
and their corresponding keys.
Authentication
• Authentication is tremendously important in
computer applications.
• The program or person you communicate with
may be in the next room or on another continent;
you have none of the usual visual or aural clues
that are helpful in everyday transactions.
• Public key cryptography offers some powerful
tools for proving identity.
Web Authentication
• There are several different ways that
authentication normally occurs on the
Internet.
• The next slide lists five methods, with slides
following it to describe those methods.
Understanding Login Authentication
• When you try to access a protected web resource,
the web container activates the authentication
mechanism that has been configured for that
resource. You can specify the following authentication
mechanisms:
• HTTP basic authentication
• Form-based login authentication
• Client certificate authentication
• Mutual authentication
• Digest authentication
HTTP Authentication
• With basic authentication, the following things occur:
• A client requests access to a protected resource.
• The web server returns a dialog box that requests the user
name and password.
• The client submits the user name and password to the
server.
• The server validates the credentials and, if successful,
returns the requested resource.
Form Authentication
• With form-based authentication, the following things
occur:
• A client requests access to a protected resource.
• If the client is unauthenticated, the server redirects the
client to a login page.
• The client submits the login form to the server.
• If the login succeeds, the server redirects the client to
the resource. If the login fails, the client is redirected to
an error page.
Certificate Authentication
• In certificate-based authentication, the following things
occur:
• A client requests access to a protected resource.
• The web server presents its certificate to the client.
• The client verifies the server's certificate.
• If successful, the client sends its certificate to the server.
• The server verifies the client's credentials.
• If successful, the server grants access to the protected
resource requested by the client.
•
•
•
•
•
•
Password
Authentication
In user name- and password-based mutual authentication,
the following things occur:
A client requests access to a protected resource.
The web server presents its certificate to the client.
The client verifies the server's certificate.
If successful, the client sends its user name and password to
the server, which verifies the client's credentials.
If the verification is successful, the server grants access to
the protected resource requested by the client.
Digest Authentication
• Like HTTP basic authentication, HTTP digest
authentication authenticates a user based on a user
name and a password. However, the authentication is
performed by transmitting the password in an
encrypted form which is much more secure than the
simple base64 encoding used by basic
authentication. Digest authentication is not currently
in widespread use.
Cryptographic Concepts
• Message digests produce a small "fingerprint"
of a larger set of data.
• Digital signatures can be used to prove the
integrity of data.
• Certificates are used as cryptographically
safe containers for public keys.
Message Digest
• A message is used to avoid transmitting a password
in clear text from a client to a server.
• A message digest takes an arbitrary amount of input
data and produces a short, digested version of the
data.
• Java Cryptography Architecture (JCA) makes it easy
to use message digests.
• The java.security.Message Digest class encapsulates
a cryptographic message digest.
Protected Password Login
• A basic problem in client/server applications is that the
server wants to know who its clients are.
• The obvious solution is to send the user's name and
password directly to the server.
• Most computer networks, are highly susceptible to
eavesdropping, so this is not a very secure solution.
• To avoid passing a clear text password from client to
server, we can send a message digest of the password
instead.
Protected Password Login
• The server can create a message digest of its copy of the
password. If the two message digests are equal, then the
client is authenticated.
• This simple procedure is vulnerable to a replay attack.
• To avoid this problem some session specific information like
random number and a time stamp are added to the
message digest.
• The server can use them to calculate a matching digest
value.
Message Digest Password
Double-Strength Password Login
• This is a stronger method for protecting password
information using message digests.
• Why is it Required?
– A message digest is one way function
– It takes less time to test a single password using dictionary
attack
– A dictionary attack is to try passwords one at a time and
attempting to login each time
• It increases the time required for a dictionary attack
Double-Strength Password Login
Signatures
• A signature provides two security services, authentication and
integrity.
• A signature is a message digest that is encrypted with the
signer's private key.
• Only the signer's public key can decrypt the signature, which
provides authentication.
• If the message digest of the message matches the decrypted
message digest from the signature, then integrity is assured.
• The Java Security API class, java.security.Signature
represents cryptographic signatures.
Signatures
• The basic procedure is very similar to the
password based.
• The client generates a timestamp and a
random number.
• The client creates a signature of this data and
sends it to the server.
• The server can verify the signature with the
client's public key.
Limitations with Signatures
• Signatures do not provide confidentiality. A
signature accompanies a plain text message.
Anyone can intercept and read the message.
• Creating and maintaining the public key
database is difficult.
• The server needs to obtain these public keys in
a secure way.
• Certificates solve this problem.
Certificates
• A certificate is a statement, signed by one person, that the
public key of another person has a particular value.
• It's like a driver's license.
• The license is a document issued by your state
government that matches your face to your name,
address, and date of birth.
• Note that the license only has value because you and your
local shopkeepers trust the authority of the state
government.
• Digital certificates have the same property.
Certificates
• Certificate associates an identity with a public
key.
• The identity is called the subject.
• The issuer that signs the certificate is the
signer.
Elements of a Certificate
•
•
•
•
Information about the subject.
The subject's public key.
Information about the issuer.
The issuer's signature of the above
information
Java Cryptography Overview
• The Java Cryptography Architecture is split into two different
packages
– JDK
– Java Cryptology Extension
• Sun had to split the architecture due to US export laws
which prohibits software encryption technology from being
released outside of the United States or Canada (certain
types of cryptographic software are considered "weapons"
by the U.S. government).
Service Classes
• Signature — Used to sign and verify digital signatures.
• Message Digest — Used to calculate the message digest
(hash) of specified data.
• KeyPairGenerator — Generate a pair of public and private
keys suitable for a specific algorithm.
• KeyFactory — Converts cryptographic keys of type 'key' into
key specifications.
• AlgorithmParameterGenerator — Generates parameters for
a particular algorithm.
Service Classes in JDK1.2
• AlgorithmParameters — Manages the parameters for a
particular algorithm.
• KeyStore — Used to create and manage a key store.
• SecureRandom — Generates pseudo random numbers.
Java Cryptography Extension
• The JCE removes users from the implementation of
cryptography, and the algorithms involved, making both easy to
use.
• A programmer can specify algorithms, or the JCE architecture
will choose the default algorithms.
• An application that uses an object that needs a specific CSP
service or algorithm will run through the installed providers, and
choose the first default provider with an appropriate service.
• Alternately programmers can choose specific providers for
specific services.
Cryptographic Service Providers
•
•
•
•
•
•
•
RSA Data Security Inc.
eSec Limited (formally Australian Business Access )
Forge Research.
DSTC
Entrust Technologies
Cryptix
IAIK
Enterprise Solutions
• This has been a rather basic introduction to
Java Security. When you get to large
applications with many users, there are
additional concerns, normally at the level of
Web servers and Java 2 Enterprise Edition.
• The following slides introduce those
concerns.
Too many users?
• Since Web Applications can have large
numbers of users, it may not be convenient to
control security at the user level.
• The following slide shows ways that this
complexity can be managed.
J2EE Security classifications
• User: An individual (or application program) identity that has
been defined in the Application Server. Users can be
associated with a group.
• Group: A set of authenticated users, classified by common
traits, defined in the Application Server.
• Role: An abstract name for the permission to access a
particular set of resources in an application. A role can be
compared to a key that can open a lock. Many people might
have a copy of the key. The lock doesn't care who you are,
only that you have the right key.
• Realm: A collection of users and groups that are controlled
by the same authentication policy.
References and Resources
• Inside Java 2 Platform Security, Li Gong,
Addison Wesley, 1999.
• Java Cryptology, Jonathon Knudsen, O'reily
and Associates, 1998.
• Java Security Handbook, Jamie Jaworski and
Paul Perrone, SAMS Publishing, 2000.