1. Java Security Pingping Ma Nov 2 nd, 2006

2. Overview Platform Security Cryptography Authentication and Access Control Public Key Infrastructure (PKI)

3. Platform Security Built-in language security features enforced by the Java compiler and virtual machine: Strong data typing Automatic memory management and garbage collection Bytecode verification Secure class loading  It defines a local name space to ensure that an untrusted applet cannot interfere with the running of other programs.

4. Cryptography overview Support for a wide range of cryptographic services  Digital signatures  Message digests  Encryption and decryption  Key generators and key factories Support for a variety of standard algorithms  RSA, DSA, AES  DES, SHA  PKCS#5, RC2, RC4

5. Major concepts Engine class: define a cryptographic service in an abstract fashion (without a concrete implementation). Some examples as follows:  MessageDigest: used to calculate the message digest (hash) of specified data. MessageDigest  Signature: used to sign data and verify digital signatures Signature  KeyPairGenerator: used to generate a pair of public and private keys suitable for a specified algorithm. KeyPairGenerator  KeyStore: a database used to manage keys and certificates KeyStore Service provider: a package or set of packages that implement one or more cryptographic services, such as digital signature algorithms, message digest algorithms.

6. Design principle The Java Cryptography is designed around these principles:  Implementation independence and interoperability  Algorithm independence and extensibility

7. Design principle Implementation independence means that different providers can implement the same engine class in different ways. A user may request an implementation from a specific provider or specify a preference order of the providers in which providers are searched for requested services when no specific provider is requested. Implementation interoperability means that various implementations can work with each other, use each other's keys, or verify each other's signatures.

8. Authentication and access control Sandbox Model

9. Protection mechanism Protection domain: a set of classes whose instances are granted the same set of permissions. It is a fundamental concept and building block of system security. Protection domains generally fall into two distinct categories: system domain and application domain.

10. Protection mechanism The Java application environment maintains a mapping from code (classes and instances) to their protection domains and then to their permissions.

11. Protection mechanism Problem: Two domains may interact with each other by method calling Basic rule: a less "powerful" domain cannot gain additional permissions as a result of calling or being called by a more powerful domain.

12. Protection mechanism Problem: A thread of execution may occur completely within a single protection domain or may involve multiple protection domains. The general rule for calculating permissions is the following:  The permission set of an execution thread is considered to be the intersection of the permissions of all protection domains traversed by the execution thread.

13. Permission class The permission classes represent access to system resources. The java.security.Permission class is an abstract class and is subclassed, as appropriate, to represent specific accesses. perm = new java.io.FilePermission("/tmp/abc", "read"); The implies method: a crucial abstract method that needs to be implemented for each new class of permission. Basically, "a implies b" means that if one is granted permission "a", one is naturally granted permission "b". This is important when making access control decisions.

14. Policy class The system security policy for a Java application environment, specifying which permissions are available for code from various sources, is represented by a Policy object. There could be multiple instances of the Policy object, although only one is "in effect" at any time. The policy can be specified within one or more policy configuration files.

15. Policy class A policy configuration file essentially contains a list of entries. It may contain a "keystore" entry, and contains zero or more "grant" entries. Each grant entry in a policy file essentially consists of a CodeSource and its permissions. The following grants a FilePermission to all code:  grant { permission java.io.FilePermission ".tmp", "read"; };

16. Public Key Infrastructure (PKI) Tools for managing keys and certificates and comprehensive, abstract APIs with support for the following features and algorithms:  Certificates and Certificate Revocation Lists (CRLs): X.509  Certification Path Validators and Builders: PKIX (RFC 3280), On-line Certificate Status Protocol (OCSP)  Certificate Stores (Repositories): LDAP, java.util.Collection

17. Basic concept A public key (or identity) certificate is a binding of a public key to an identity, which is digitally signed by the private key of another entity, often called a Certification Authority (CA). The X.509 standard defines what information can go into a certificate, and describes how to write it down (the data format). a public key infrastructure (PKI) is an arrangement that provides for trusted third party vouching for user identities.

18. Public Key Infrastructure (PKI) The Certificate API, in the java.security.cert package, includes the following:java.security.cert  The CertificateFactory class is used to generate certificate and certificate revocation list (CRL) objects.  the Certificate class is an abstract class for managing a variety of certificates. It is an abstraction for certificates that have different formats but important common uses.  the CRL class is an abstract class for managing a variety of Certificate Revocation Lists (CRLs).  Specific X. 509 classes: X509Certificate, X509Extension and X509CRL

19. Certification path The JavaTM Certification Path API consists of classes and interfaces for handling certification paths (also known as "certificate chains"). If the user does not have a trusted copy of the public key of the CA that signed the subject's public key certificate, then another public key certificate vouching for the signing CA is required. This logic can be applied recursively, until a chain of certificates (or a certification path) is discovered from a trust anchor or a most-trusted CA to the target subject

20. Certification path The figure illustrates a certification path from a most-trusted CA's public key (CA 1) to the target subject (Alice). The certification path establishes trust in Alice's public key through an intermediate CA named CA2.

21. Certification path class Java.security.cert package is used to handle certificates. The core classes can be broken up into 4 class categories: Basic, Validation, Building, and Storage:  Basic Certification path classes CertPath, CertificateFactory, CertPathParameters  Certification Path Validation Classes CertPathValidator, CertPathValidatorResult  Certification Path Building Classes CertPathBuilder, CertPathBuilderResult  Certificate/CRL Storage Classes CertStore, CertStoreParameters, CertSelector, CRLSelector