Transcript JDK12Security

java Security
Security in Java 2 SDK
1.2
Cheng-Chia Chen
September 1999
Transparency No. 1
Java Security
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.
Hopcroft and J.D. Ullman, 1979.
Grading:
 homework 20~30%
 two examinations 60%
 performance 10~20%
Transparency No. 2
Java Security
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.
Transparency No. 3
Java Security
Security Architecture Extensions
 JDK 1.0 Security Model (sandbox model):
Transparency No. 4
Java Security
JDK 1.1 Security Model:
Transparency No. 5
Java Security
JDK 1.2 Security Model:
Transparency No. 6
Java Security
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.
Transparency No. 7
Java Security
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.
Transparency No. 8
Java Security
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.
Transparency No. 9
Java Security
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.
Transparency No. 10
Java Security
JCA modules
 The SPI (service provider interface) layer are methods to be
implemented by cryptographic service providers (CSPs)
Transparency No. 11
Java Security
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.
Transparency No. 12
Java Security
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.
Transparency No. 13
Java Security
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.
Transparency No. 14
Java Security
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.
Transparency No. 15
Java Security
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.
Transparency No. 16
Java Security
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.
Transparency No. 17
Java Security
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
Transparency No. 18
Java Security
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:
 http://java.sun.com/docs/books/tutorial/
security1.2/tour1/example-1dot2/WriteFile.html
Transparency No. 19
writefile.java
Java Security
/** 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); } } }
Transparency No. 20
Java Security
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
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
Transparency No. 21
Java Security
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.
Transparency No. 22
Java Security
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
Transparency No. 23
Java Security
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)
Transparency No. 24
Java Security
 Decryption
 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.
Transparency No. 25
Java Security
 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.
Transparency No. 26
Java Security
Transparency No. 27