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 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 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 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 T hese 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,  s pecifying 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 \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.