Security in Java 2 SDK 1.2

1. 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), 1997. (新月) • Element of the theory of Computation, By H.R.Lewis and C.H. Papadimitriou, (Prentice-Hall), 1998 (全華) • Papadimitriou, ComputationalComplexity (台北) • 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%

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):

5. JDK 1.1 Security Model:

6. JDK 1.2 Security Model:

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 arandom-number generation (RNG) algorithm.

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 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: • http://java.sun.com/docs/books/tutorial/ 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 • 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

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.

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

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