1. Cheng-Chia Chen September 1999
Security in Java 2 SDK 1.2
Cheng-Chia Chen
September 1999

2. Course Information
Textbook:
No.
References:
Introduction to the theory of Computation, by Sipser (PWS), (新月)
Element of the theory of Computation, By H.R.Lewis and C.H. Papadimitriou, (Prentice-Hall), 1998 (全華)
Papadimitriou, Computational Complexity (台北)
Automata and Computability, By D.C. Kozen, Springer-Verlag,Feb
Introduction to Automata Theory, Language and Computation, by J.E. Hopcroft and J.D. Ullman, 1979.
Grading:
homework 20~30%
two examinations 60%
performance 10~20%

3. Security Features Overview
JDK 1.2 contains substantial security features enhancements:
policy-based, easily-configurable, fine-grained access control;
new cryptographic services and certificate and key management classes and interfaces;
three new tools.
These topics are discussed in the following sections:
Security Architecture Extensions
Cryptography Architecture Extensions
Security-Related Tools.

4. Security Architecture Extensions
JDK 1.0 Security Model (sandbox model):
local code: have full access to vital system resources,
downloaded remote code (an applet): is not trusted and can 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.

5. JDK 1.1 Security Model:
A digitally signed applet is treated like local code, with full access to resources, if the public key used to verify the signature is trusted.
Unsigned applets are still run in the sandbox.
Signed applets are delivered, with their respective signatures, in signed JAR (Java ARchive) files.

6. JDK 1.2 Security Model:
All code ( local or remote) subject to a security policy.
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.
Each permission specifies a permitted access to a particular resource, such as read and write access to a specified file or directory or connect access to a given host and port.
A domain is a set of classes whose instances are granted the same set of permissions.

7. Cryptography Architecture Extensions
Java cryptography architecture (JCA),
introduced since JDK1.1
a framework for accessing and developing cryptographic functionality for the Java platform.
The JCA includes a provider architecture that allows for multiple and interoperable cryptography implementations.
Cryptographic service provider (CSP), or simply provider:
a package (or a set of packages) that supplies a concrete implementation of a subset of the cryptography aspects of the JDK Security API.

8. What a provider could provides
JDK 1.1:
digital signature algorithms,
message digest algorithms, and
key-generation algorithms.
JDK 1.2 adds five more types of services:
Keystore creation and management
Algorithm parameter management
Algorithm parameter generation
Key factory support to convert between different key representations
Certificate factory support to generate certificates and certificate revocation lists (CRLs) from their encodings
also enables a provider to supply a random-number generation (RNG) algorithm.

9. Default provider of Sun's JRE. Includes implementations of
The SUN provider
Default provider of Sun's JRE.
Includes implementations of
a number of DSA (Digital Signature Algorithm) services,
MD5 (RFC 1321) and SHA-1 (NIST FIPS 180-1) message digest algorithms,
a certificate factory for X.509 certificates and certificate revocation lists,
a pseudo-random-number generation algorithm, and
a keystore implementation.

10. Java Cryptography Extension (JCE)
Extends the JDK to include APIs for
encryption,
key exchange, and
message authentication code (MAC).
JCE and the cryptography aspects of the JDK provide a complete, platform-independent cryptography API.
JCE is released separately as an extension to the JDK, in accordance with U.S. export control regulations.

11. JCA modules
The SPI (service provider interface) layer are methods to be implemented by cryptographic service providers (CSPs)

12. Cryptographic Services
An engine class defines a cryptographic service(API) without a concrete implementation.
defines API methods that allow applications to access the specific type of cryptographic service it provides, such as a digital signature algorithm.
The actual implementations, from one or more providers, are those for specific algorithms.
implemented in terms of a service provider interface (SPI).
each engine class has a corresponding abstract SPI class that defines the service provider interface methods that cryptographic service providers must implement.

13. Example
an API client may request and use an instance of the Signature engine class to access the functionality of a digital signature algorithm to digitally sign a file.
The actual implementation supplied in a SignatureSpi subclass would be that for a specific kind of signature algorithm, such as SHA-1 with DSA or MD5 with RSA.
Each instance of an engine class encapsulates an instance of the corresponding SPI class as implemented by a cryptographic service provider.
Each API method of an engine class invokes the corresponding SPI method of the encapsulated SPI object.

14. Certificate Interfaces and Classes
JDK 1.2 provides an X.509 v3 implementation of the certificate interfaces.
A certificate is
a digitally signed statement from one entity (issuer), saying that the public key of another entity(subject) has some particular value.
Certificate-related classes (all in the java.security.cert package):
Certificate - an abstraction for certificates of various types X.509, PGP, and SDSI
CertificateFactory - defines the functionality of a certificate factory, which is used to generate certificate and certificate revocation list (CRL) from their encodings.
X509Certificate - an abstract class for X.509 certificates providing a standard way to access all the attributes of an X.509 certificate.

15. Key Management Classes and Interfaces
JDK 1.1 introduced
abstract Key interfaces.
keystore:
a repository of keys and certificates.
Multiple implementations are possible, where each implementation is that for a particular type of keystore.
A keystore type defines the storage and data format of the keystore information.
JDK 1.2 adds
A KeyStore class (an engine class):
supplies well-defined interfaces to access/modify the information in a a keystore.
A default KeyStore implementation:
implements the keystore as a file,
using a proprietary keystore type (format) named JKS.
password-protected for each private key and the entire keystore.

16. Key Management Classes and Interfaces (cont’d)
Key specification interfaces:
used for "transparent" representations of the key material that constitutes a key.
may consist of the key itself and the algorithm parameters used to calculate the key value.
A transparent representation of keys means that you can access each key material value individually.
keytool:
A tool for managing keys and certificates.

17. Security-Related Tools
JDK 1.2 introduces three new tools:
The keytool
is used to create pairs of public and private keys,
to import and display certificate chains,
to export certificates, and
to generate X.509 v1 self-signed certificates and
to generate certificate requests that can be sent to a certification authority.
The jarsigner tool
signs JAR (Java ARchive format) files and verifies the authenticity of the signature(s) of signed JAR files.
The Policy Tool
creates and modifies the policy configuration files that define your installation's security policy.

18. Lesson: Quick Tour of Controlling Applets
a brief introduction to some of the new security features.
It shows how resource accesses, such as reading or writing a file, are not permitted for applets unless explicitly allowed by a permission in a policy file.
The steps for this lesson:
1. Observe Applet Restrictions
2. Set Up a Policy File to Grant the Required Permission
3.See the Policy File Effects

19. Observe Applet Restrictions
the Java platform provides protection from attack through the use of a security manager.
JDK system code invokes security manager methods to perform resource access control checks.
Most browsers install a security manager, so applets typically run under the scrutiny of a security manager. Each
such applet is not allowed to access resources unless it is explicitly granted permission to do so by the security policy in effect.
the permission must be granted by an entry in a policy file.
Type this command in your browser’s location:
security1.2/tour1/example-1dot2/WriteFile.html

20. writefile.java
/** By default, this applet raises a security exception, unless you configure your policy
* to allow applets from its location to write to the file "writetest". */
import java.awt.*; import java.io.*; import java.lang.*; import java.applet.*;
public class WriteFile extends Applet {
String myFile = "writetest"; File f = new File(myFile); DataOutputStream dos;
public void init() { String osname = System.getProperty("os.name"); }
public void paint(Graphics g) {
try {
dos = new DataOutputStream(new BufferedOutputStream(new FileOutputStream
(myFile),128));
dos.writeChars("Cats can hypnotize you when you least expect it\n");
dos.flush();
g.drawString("Successfully wrote to the file named " + myFile + " -- go take a look at it!", 10, 10);
} catch (SecurityException e) { g.drawString("writeFile: caught security exception: " + e, 10, 10);
} catch (IOException ioe) {
g.drawString("writeFile: caught i/o exception", 10, 10); } } }

21. Set up a Policy File to Grant the Required Permission
an ASCII text file,
can be composed via a text editor or the graphical Policy Tool utility demonstrated in this section.
The Policy Tool
saves you typing and
no need to know the required syntax of policy files, thus reducing errors.
use the Policy Tool to create a policy file,
named mypolicy,
add a policy entry that grants code from the directory where WriteFile.class is stored permission to write the writetest file.
The steps are as follows:
1. Start Policy Tool
2. Grant the Required Permission
3. Save the Policy File

22. Type the command to start the tool: > policytool
Start Policy Tool
Type the command to start the tool:
> policytool
The user policy file is by default a file named .java.policy in your home directory.

23. Grant the Required Permission
choose the Add Policy Entry button in the main Policy Tool window.
left empty

24. Glossary in Java Security
Certificate (憑證)
A certificate is a digitally signed statement from one entity (person, company, etc.), saying that the public key of some other entity has some particular value.
If you trust the signature on the certificate, you trust that the association in the certificate between the specified public key and the other entity is authentic.
Cryptography Algorithm: an algorithm used to help ensure one or more of the following:
1. the confidentiality of data
2. authentication of the data sender
3. integrity of the data sent
4. nonrepudiation; a sender cannot deny having sent a particular message
digital signature algorithm (2,3,4)
message digest algorithms (2)
encryption and decryption (1) (JCE)

25. Decryption Digital Signature
Decryption is the inverse of encryption; the process of taking ciphertext (encrypted data) and a cryptographic key, and producing cleartext (the original unencrypted data).
Digital Signature
a string of bits that is computed from some data (the data being "signed") and the private key of an entity.
can be used to verify that the data came from the entity and was not modified in transit.
Useful characteristics:
Its authenticity can be verified, via a computation that uses the public key corresponding to the private key used to generate the signature.
It cannot be forged, assuming the private key is kept secret.
It is a function of the data signed and thus can't be claimed to be the signature for other data as well.
The signed data cannot be changed; if it is, the signature will no longer verify as being authentic.

26. Domain or Protection Domain
A protection domain ("domain" for short) encloses a set of classes whose instances are granted the same set of permissions.
In addition to a set of permissions, a domain is comprised of a CodeSource, which is a set of PublicKeys together with a codebase (in the form of a URL). Thus, classes signed by the same keys and from the same URL are placed in the same domain.
Classes that have the same permissions but are from different code sources belong to different domains.
Currently in JDK 1.2, protection domains are created "on demand" as a result of class loading.
Today all code shipped as part of the JDK is considered system code and runs inside the unique system domain.
Each applet or application runs in its appropriate domain, determined by its code source.