java Security

Transparency No. 1

Security in Java 2 SDK 1.2

Cheng-Chia Chen

September 1999

Java Security

Transparency No. 2

Course Information

Textbook: No.

References: Introduction to the theory of Computation, by Sipser (PWS), 1997. (新月 )

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. 1997. Introduction to Automata Theory, Language and Computation, by J.E. H

opcroft and J.D. Ullman, 1979.

Grading: homework 20~30% two examinations 60% performance 10~20%

Java Security

Transparency No. 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.

Java Security

Transparency No. 4

Security Architecture Extensions

JDK 1.0 Security Model (sandbox model):

Java Security

Transparency No. 5

JDK 1.1 Security Model:

Java Security

Transparency No. 6

JDK 1.2 Security Model:

Java Security

Transparency No. 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.

Java Security

Transparency No. 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 repre

sentations Certificate factory support to generate certificates and cert

ificate revocation lists (CRLs) from their encodings also enables a provider to supply a random-number gener

ation (RNG) algorithm.

Java Security

Transparency No. 9

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 dig

est algorithms, a certificate factory for X.509 certificates and certificate re

vocation lists, a pseudo-random-number generation algorithm, and a keystore implementation.

Java Security

Transparency No. 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.

Java Security

Transparency No. 11

JCA modules

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

Java Security

Transparency No. 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.

Java Security

Transparency No. 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.

Java Security

Transparency No. 14

Certificate Interfaces and Classes JDK 1.2 provides an X.509 v3 implementation of the c

ertificate 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 f

actory, 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.

Java Security

Transparency No. 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 t

hat for a particular type of keystore. A keystore type defines the storage and data format of the keystore i

nformation.

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.

Java Security

Transparency No. 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 a

ccess each key material value individually.

keytool: A tool for managing keys and certificates.

Java Security

Transparency No. 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 certif

ication 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 def

ine your installation's security policy.

Java Security

Transparency No. 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

Java Security

Transparency No. 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 p

erform resource access control checks. Most browsers install a security manager, so applets typic

ally 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: http://java.sun.com/docs/books/tutorial/ security1.2/tour

1/example-1dot2/WriteFile.html

Java Security

Transparency No. 20

/** 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); } } }

writefile.java

Java Security

Transparency No. 21

Set up a Policy File to Grant the Required Permission

policy file: 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 erro

rs. 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

Java Security

Transparency No. 22

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.

Java Security

Transparency No. 23

Grant the Required Permission

choose the Add Policy Entry button in the main Policy Tool window.

http://java.sun.com/docs/books/tutorial/security1.2/tour1/example-1dot2/

left empty

Java Security

Transparency No. 24

Glossary in Java Security

Certificate (憑證 ) A certificate is a digitally signed statement from one entity (person, co

mpany, 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 messa

ge digital signature algorithm (2,3,4) message digest algorithms (2) encryption and decryption (1) (JCE)

Java Security

Transparency No. 25

Decryption Decryption is the inverse of encryption; the process of taking cipherte

xt (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 "sign

ed") and the private key of an entity. can be used to verify that the data came from the entity and was not m

odified 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 s

ignature for other data as well. The signed data cannot be changed; if it is, the signature will no longe

r verify as being authentic.

Java Security

Transparency No. 26

Domain or Protection Domain A protection domain ("domain" for short) encloses a set of classes wh

ose instances are granted the same set of permissions. In addition to a set of permissions, a domain is comprised of a CodeS

ource, 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.

Java Security

Transparency No. 27