Java and Security

Java and Security

Cryptography, Symmetric Key, Public Key, Authentication, Digital

Signatures, Message Digests

What is Security?

The Java platform is emphasized as dynamic, extensible security architecture, standards-based and interoperable environment

The Java security model is based on a customizable "sandbox"

Java software programs can run safelywithout potential risk to systems or users

Evolution of Java Security: JDK 1.0 Sandbox Model is the original security model

provided by the Java platform Provided virtually no flexibility on a very restricted environment

Run untrusted code obtained from the open network.

Local code is trusted to have full access to vital system resources, such as the file system.

BUT: Downloaded remote code (an applet) is not trusted

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.

JDK 1.0 Security Model

Evolution of Java Security: JDK 1.1 JDK 1.1 introduced the signed applet to overcome the problem A signed applet is an applet packaged as a Java

Archive (JAR) file signed with a private key.

The signed applet enjoys unlimited access, just like a local application,

provided the corresponding public key is trusted in the executing environment.

Unsigned applets default back to the sandbox model JDK 1.1's security model is less restrictive than the sandbox

modelMore consistent treatment of applets and applications are provided.

This model have one major disadvantage Applets either received unlimited access or Confined to the sandbox

There is no option for selective access to resources.

The JDK 1.1 Security Model

Evolution of Java Security: JDK 2

The Java 2 Security model, provides for a consistent and flexible policy for applets and applications.

While applications still run unrestricted by default, they can be subjected to the same policy as applets.

The security policy defines the set of permissions available for code from various signers or

locations and can be configured by a user or a system administrator.

The runtime system organizes code into individual domains

each of them run in a restricted environment if the user or the administrator so chooses.

Applications run unrestricted, as before, by default but can optionally be subject to a security policy

Java 2 Security Model

Overview Java 2 Security

Java 2 Security Concepts Byte-code verifier (referred to as a mini-theorem prover) tries to

prove that a given series of Java byte codes are legal

In short, the verifier confirms or denies that the class file is consistent with the specifications.

Java code can be imported from anywhere in the network, it is critical to screen the code to be sure that it was produced by a

trustworthy compiler.

ClassLoader loads Java byte codes into the JVM It is an important link in the security chain. It works in conjunction with the SecurityManager and the access controller

to enforce security rules Information about the URL from which the code originated and the code's

signers is initially available to the ClassLoader. It is possible to implement a customized ClassLoader or a subclass from

java.security.SecureClassLoader to provide security features beyond those offered by the standard Java 2 Security model.

Java 2 Security Concepts CodeSource

Since Java code can be downloaded over a network, the code's origin and author are critical to maintaining a secure environment.

Consequently, the object java.security.CodeSource fully describes a piece of code.

The CodeSource encapsulates the code's origin, which is specified as an URL,

The set of digital certificates containing public keys corresponding to the set of private keys used to sign the code.

Permissions Permission classes represent access to various resources such as files, sockets, and so on. For example, permission may be given to read and write files in the /tmp

directory. Permission classes are additive in that they represent approvals, but not

denials. It's possible to explicitly permit the reading of a particular file, but not to

explicitly deny the reading of that file. A number of permission classes are subclasses of the abstract

java.security.Permission class, include FilePermission, AWTPermission, and even customized protections

like SendMailPermission

Java 2 Security Concepts Protection Domains: It is flexible to group classes into

protection domains and associate permissions with those domains.

.For instance, system classes can be effectively grouped under the system domain.

This relationship between the class and the permissions via the protection domain provides for flexible implementation mechanisms.

Policy: The numerous mappings of permissions to classes are collectively referred to as policy.

A policy file is used to configure the policy for a particular implementation.

SecurityManager is concrete, with a public constructor and appropriate checks in place to ensure that it can be invoked in an authorized manner.

SecurityManager consists of a number of check methods. For example, checkRead (String file) can determine read access to a

file. The checkPermission (Permission perm, Object context) method

can check to see if the requested access has the given permission based on the policy.

Java 2 Security Concepts 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

• The 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. Keystore information can be used and updated by the security tools

provided with the SDK.

Java Cryptography Architecture (JCA) A framework for accessing and developing

cryptographic functionality for the Java platform.

In JDK 1.1, the JCA included APIs for digital signatures and message digests.

Design principles are: Implementation independence Algorithm independence Algorithm extensibility Implementation interoperability

The Java 2 SDK significantly extended the JCA.

Java Cryptography Architecture(JCA) cont’d

Implementation independence and algorithm independence are complementary

We can use cryptographic services, such as digital signatures and message digests,

We don’t worry about the implementation details or even the algorithms that form the basis for these concepts.

JCA provides standardized, algorithm-specific APIs in case of impossibility of any complete algorithm-independence .

JCA allows the developers to indicate a specific implementation in case of the undesirability of implementation-independence.

Algorithm Independence & Algorithm Extensibility

Algorithm Independence is achieved by definingThe types of cryptographic "engines" (services), Defines classes that provide the functionality of these cryptographic engines.

These classes are called engine classes. For example:MessageDigest

The functionality of cryptographically secure message digests such as SHA-1 (Secure Hash Algorithm) or MD5 is provided.

Signature: The functionality of a cryptographic digital signature algorithm such as DSA

(Digital Signature Algorithm) or RSA (most commonly used public-key algorithm developed in 1997 by MIT professors Ron Rivest, Adi Shamir and Leonard Adleman) with MD5 is provided.

KeyFactory: Designed to provide conversions between opaque cryptographic keys (of

type Key) and key specifications (transparent representations of the underlying key material).

KeyPairGenerator Generate pairs of public and private keys

Algorithm extensibility means that new algorithms that fit in one of the supported engine classes can be added easily.

Engine Classes Added into Java 2 SDK CertificateFactory : Create public key certificates and

Certificate Revocation Lists (CRLs). KeyStore: create and manage a keystore.

A keystore is a database of keys. Private keys in a keystore have a certificate chain associated with

them,Authenticates the corresponding public key.

A keystore also contains certificates from trusted entities.

AlgorithmParameters: Manage the parameters for a particular algorithm, including parameter encoding and decoding.

AlgorithmParameterGenerator: used to generate a set of parameters suitable for a specified algorithm.

SecureRandom: used to generate random or pseudo-random numbers.

…………………………….. ………………………………

Implementation Independence Achieved using a "provider"-based architecture. Cryptographic Service Provider (or only provider)

supplies a concrete implementation of a subset of the cryptography aspects of the Security API

Cryptographic Service Provider refers to a package or a set of packages One or more cryptographic services in JDK1.1 are

implementedsuch as digital signature algorithms, message digest algorithms, and

key conversion services. Random Number Generation algorithms (RNGs) are not provider-

based; a particular algorithm was hard-coded in the JDK. Java 2 SDK adds five additional types of services:

key factories, keystore creation and management, algorithm parameter management, algorithm parameter generation, and certificate factories.

Enables a provider to supply a RNG algorithm.

Implementation Independence cont’d

A program may simply request a particular type of object (such as a Signature object) Implementing a particular service (such as

the DSA signature algorithm) Can get an implementation from one of the installed

providers.

A program may instead request an implementation from a specific provider. Providers may be updated transparently to

the application,

The SUN Provider Package An implementation of the Digital Signature Algorithm (DSA),

described in NIST FIPS 186. An implementation of the MD5 (RFC 1321) and SHA-1 (NIST

FIPS 180-1) message digest algorithms. A DSA key pair generator for generating a pair of public and

private keys suitable for the DSA algorithm. A DSA algorithm parameter generator. A DSA algorithm parameter manager. A DSA key factory providing bi-directional conversions between

(opaque) DSA private and public key objects and their underlying key material.

An implementation of the proprietary "SHA1PRNG" pseudo-random number generation algorithm, following the recommendations in the IEEE P1363 standard

…………………………………………. …………………………………………

Security Providers The cryptographic engines in Java that provide for

digital signatures, message digests are provided as a set of abstract classes in the Java security package

Concrete implementations of these classes are provided by Sun in the JDK

The security provider abstracts two ideas: engines and algorithms

An algorithm defines how a particular operation should be executed.

An algorithm can be thought of as an implementation of an engine,

But there may be several implementations of an algorithm.

Security Providers cont’d The Java security package knows about message digests. A message digest is an engine:

it is an operation a programmer can perform. The idea behind a message digest is independent of how any

particular message digest may be calculated. All message digests share certain features, and the class that abstracts

These common features into a single interface is termed an engine. Engines are generally abstract, and are always independent of any particular

algorithm. A message digest may be implemented by a particular

algorithm, such as MD5 or SHA (Secure Hash Algorithm ) . An algorithm is generally provided as a concrete class that

extends an abstract engine class, completing the definition of the class.

However, there may be many classes that provide a particular algorithm Both classes should provide the same results, but their internal

implementations may be vastly different.

The Provider Class

public abstract class Provider extends Properties

This class forms the basis of the security provider architecture

There is normally a standard subclass that implements a default security feature set;

other classes can be installed to implement other security algorithms.

The default provider class that comes with the reference JDK is the class Sun in the sun.security.provider package.

Steps to Implement and Integrate a Provider I.Write the Service Implementation CodeWe write the code supplying algorithm-specificimplementations of the cryptographic services wewant to support. For each cryptographic service, we need to create asubclass of the appropriate SPI class: SignatureSpi, MessageDigestSpi,KeyPairGeneratorSpi, SecureRandomSpi,AlgorithmParameterGeneratorSpi,AlgorithmParametersSpi, KeyFactorySpi,CertificateFactorySpi, or KeyStoreSpi.

Steps to Implement and Integrate a Provider cont’d

II.Give the Provider a Name Decide on a name for the provider. This is the name to be used by client applications to refer to our provider.

III: Write the "Master Class", a subclass of Provider Create a subclass of the Provider class. Our subclass should be a final class, and its constructor should call super,

specifying the provider name, version number, a string of information about the provider and algorithms it supports.

super ("ACME", 1.0, "ACME provider v1.0, implementing " + "RSA signing and key generation, SHA-1 and MD5 message digests.");

Set the values of various properties that are required for the Java 2 Security API to look up the cryptographic services implemented by the provider . For example: Signature.algName , MessageDigest.algName , KeyPairGenerator.algName , SecureRandom.algName , KeyFactory.algName , CertificateFactory.certType KeyStore.storeType ……………………..


As an example, the default provider named "SUN" implements the Digital Signature Algorithm (standard name is "SHA1withDSA") in a class named DSA in the sun.security.provider package

Its subclass of Provider (which is the Sun class in the sun.security.provider package) sets the

Signature.SHA1withDSA property to have the value "sun.security.provider.DSA"

as follows:

put("Signature.SHA1withDSA","sun.security.provider. DSA")


As an another example, the default provider named "SUN" implements the SHA1withDSA Digital Signature Algorithm in software.

In the master class for the provider "SUN", it sets the

"Signature.SHA1withDSA ImplementedIn"

to have the value "Software" via the following:

put("Signature.SHA1withDSA ImplementedIn",

"Software")


IV.Compile the Code After we have created our implementation code (Step 1),

given our provider a name (Step 2), and created the master class (Step 3), we use the compiler to compile the files.

V.Prepare for Testing: Install the Provider We ship our provider classes as a JAR (Java ARchive) or

ZIP file. Place a zip or JAR file containing the classes anywhere on your

CLASSPATH.

The next step is to add the provider to our list of approved providers.

This is done statically by editing the security properties file <java-home>\lib\security \java.security


For the provider, this file should have a statement of the following form:

security.provider.n= masterClassName This declares a provider, and specifies its preference order n. The preference order is the order in which providers are

searched for requested algorithms when no specific provider is requested.

The order is 1-based; 1 is the most preferred, followed by 2, and so on.

• masterClassName must specify the fully qualified name of the provider's "master class", which we implemented in Step 3.

• This class is always a subclass of the Provider class.


Whenever the Java 2 SDK is installed, it contains some built-in (default) providers, including the provider referred to as "SUN".

The java.security file includes the following provider specification for the "SUN" provider:

security.provider.1=sun.security.provider .Sun

The "SUN" provider's master class is the Sun class in the sun.security.provider package.


Suppose that our master class is the Acme class in the COM.acme.provider package, a

We would like to make our provider the second preferred provider.

To do so, add the following line to the java.security file below the line for the "SUN" provider, and increment the preference order numbers for all other providers whose numbers were greater than or equal to 2 before your addition:

security.provider.2=COM.acme.provider. Acme Providers may also be registered dynamically. To do so, a program (such as your test program, to be written

in Step 7 can call either the addProvider or insertProviderAt method in the Security class.

This type of registration is not persistent and can only be done by "trusted" programs.


VI: Write and Compile our Test Programs The first tests are ones to ensure that our provider is found,

and that its name, version number, and additional information is as expected.

To do so, you could write code like the following, substituting your provider name for "MyPro":

import java.security.*; Provider p = ssecurity. getProvider ("MyPro");System.out.println("MyPro provider name is " + p.getName());

System.out.println ("MyPro provider version # is " + p.getVersion()); System.out.println ("MyPro provider info is " + p.getInfo());


• Next, we should ensure that our services are found.

• For instance, if we implemented a SHA-1 message digest algorithm, we could check to ensure it's found when requested by using the following code (again substituting your provider name for "MyPro"):

MessageDigest sha = MessageDigest. getInstance ("SHA",

"MyPro");System.out.println ("My MessageDigest algorithm

name is” +sha.getAlgorithm());


VII.Run our Test ProgramsDebug the code and continue testing as needed. If the Java 2

Security API cannot seem to find one of your algorithms, review the steps above and ensure they are all completed.

VIII: Document your Provider and its Supported Services The next-to-last step is to write documentation for our

clients. At the minimum, we need to specify

the name programs should use to the name programs should use to refer to our provider.

the types of algorithms and other services implemented by our provider.

instructions for installing the provider, similar to those provided in Step 5, except that the information and examples should be specific to your provider.


IX:Make the Class Files and Documentation Available to Clients

The final step is to make our class files and documentation available to clients in whatever form

(.class files, zip files, JAR files, ...) and methods (web download, floppy, mail, ...)

How Provider Implementations are Requested and Supplied

For each engine class in the API, a particular implementation is requested and instantiated by calling a getInstance method on the engine class

specifying the name of the desired algorithm and, optionally, the name of the provider (or the Provider class)

whose implementation is desired.

If no provider is specified, getInstance searches the registered providers

for an implementation of the requested cryptographic service associated with the named algorithm.

In any given Java Virtual Machine (JVM), providers are installed in a given preference order,

the order in which the provider list is searched if a specific provider is not requested.

How Provider Implementations are Requested and Supplied cont’d

For example, suppose there are two providers installed in a JVM:

PROVIDER_1 and PROVIDER_2. Assume that:

PROVIDER_1 implements SHA1withDSA, SHA-1, MD5, DES, and DES3. PROVIDER_1 has preference order 1 (the highest priority).

PROVIDER_2 implements SHA1withDSA, MD5withRSA, MD2withRSA, MD2, MD5, RC4, RC5, DES, and RSA. PROVIDER_2 has preference order 2.

The Java Cryptography Extension (JCE)

A set of packages that provides a framework and implementations for

Encryption, Key generationKey agreement, Message Authentication Code (MAC) algorithms.

Support for encryption includes symmetric, asymmetric, block, stream ciphers.

The software also supports secure streams and sealed objects.

Documents

Java and Security