Download 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 safely
 without 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
model
More 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 algorithmindependence .
 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 defining
 The 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
implemented
 such as digital signature algorithms, message digest algorithms, and
key conversion services.
 Random Number Generation algorithms (RNGs) are not providerbased; 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" pseudorandom 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 Code
We write the code supplying algorithm-specific
implementations of the cryptographic services we
want to support.
For each cryptographic service, we need to create a
subclass 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 ……………………..
Steps to Implement and Integrate a Provider
cont’d
 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")
Steps to Implement and Integrate a Provider
cont’d
 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")
Steps to Implement and Integrate a Provider
cont’d
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
Steps to Implement and Integrate a Provider
cont’d
 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.
Steps to Implement and Integrate a Provider
cont’d
 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.
Steps to Implement and Integrate a Provider
cont’d
 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.
Steps to Implement and Integrate a Provider
cont’d
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());
Steps to Implement and Integrate a Provider
cont’d
• 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());
Steps to Implement and Integrate a Provider
cont’d
VII.Run our Test Programs
Debug 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.
Steps to Implement and Integrate a Provider
cont’d
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 generation
Key agreement,
Message Authentication Code (MAC) algorithms.
 Support for encryption includes
symmetric,
asymmetric,
 block,
stream ciphers.
 The software also supports secure streams and
sealed objects.