Download Java Security Update

Java Security
Update
Charles Tipping
Sun Microsystems Inc
Java Security Framework
•
Overview
•
Principles
•
Sandbox Implementation
•
Enhancements in JDK 1.1
•
Future Directions
Overview
Security is not...
•
Security != cryptography
•
Correct security model != bug-free
implementation
•
Testing != formal verification
•
Component security != overall system security
•
JavaTM security != applet containment
Basics of Web Security
•
Know where it comes from
•
Know that it has not been
tampered with
•
Control what it can do
when you get it
Authenticate
Encrypt
Control
Principles
Secure Java Platform
•
Language, Verifier, VM safety features
•
Application-level Security Manager
• “Sandbox”, “Encapsulation”, “Containment”
• Limited execution environment for downloaded applets
• Standalone Java applications are free to define their
own security policies
Open
•
Publish public specifications
•
Publish full source code
•
Welcome feedback
•
Committed to open, interoperable standards
Public Specifications
•
Java Language Specification
•
Java Virtual Machine Specification
•
Java API Specification
•
Full source code can be inspected
•
Industry partners cooperate to extend the Java APIs
Simplicity
•
Clean design
•
Ease of development for
• custom security
•
Security Manager
• complex security
•
•
•
Key Management
Digital Signatures
Encryption
Completeness
•
Built-in language
security
• Safe language
• Extensive security
information available
• Flexible security
models
•
Security API
• Comprehensive
library for securityrelated functionality
• Customizable for
addressing differing
security needs
Security Standards
•
W3C Code Signing Initiative
•
SSL v3.0 & X.509
•
Tracking IETF standards bodies
•
•
•
•
IPSEC, SKIP, ISAKMP
SSL, TLS
SKIP
...
Sandbox Implementation
Sandbox Model
•
Remote Code (applet) is untrusted
•
Local code (application) is trusted
Construction of Sandbox
•
Java is designed to have extensive safety features
•
Java Virtual Machine and the bytecode verifier
together enforce language type safety even in the
presence of deliberate attacks
•
Built-in Security Manager enforces a default access
control policy, and is consulted before access to
critical system resources is granted
•
Extensible security policy, as demonstrated by the
HotJava Browser
Sandbox implementation:
verifier
•
Invoked on downloaded classes
•
java -verify
•
Verifier has 4 passes
•
•
•
•
•
Classfile verification
Type system verification
Bytecode verification
(runtime) Type and access checking
See http://java.sun.com/sfaq/verifier.html
Sandbox model: HotJava
•
Applets barred from client file system
•
Applets can only phone home
•
Applets cannot load libraries
•
Applets cannot exec processes
•
Applets cannot examine properties
Sandbox implementation: language
features
•
Classes declare and implement types
•
Strong typing
•
Access modifiers
•
Memory management
•
Misc: arrays, strings, no preprocessor, no
#define private public, no goto
Sandbox implementation:
classloader
•
Policy: applets can’t create classloader
•
Classloader invokes verifier
•
Classloader enforces namespaces
Writing a security manager
•
Decide policy
•
Minimize code for enforcing policy
•
Insert checks
•
Subclass java.lang.SecurityManager
•
Publish policy and tests
Bytecode Security
Java program
Java Byte-codes
Java compiler
Source Computer
The Internet
Verification
Java Byte Codes
Your Computer
Execution
Restricted
SM
Security Manager
JDK
{
awt
ioio
awt
net
util
net
util lang
lang
applet
application
applet
Solaris
Mac
Others
Java Virtual Machine
SM
JavaOS
Win32
Security manager enforces JVM Security Policies
Each applet has it’s own private address space
Java Security Framework
applet
application
servlet
Authentication & Authorization
Code Signing
Secure Channels
java.security API
Java System Security
No Sandbox?
•
Impossible (almost) to retrofit security mechanisms (no
clean separation between the OS and the apps)
•
Impossible to enforce any non-trivial security policy
(because you must trust that the software you get does
not contain a virus or malicious code)
•
Digitally signing software alone does not go far (due to
the lack of auditing facility and software liability)
Enhancements in JDK 1.1
Authentication & Authorization
•
Access Control List package (ACL)
•
Interfaces
• Principle, Group
• AclEntry, Acl, AclConfig
• Permission
•
Useful in security applications, and security
administration tools
Java Code Signing
•
Signed JAR files
• JAR is Java ARchive file format
• JAR may contain .class files, .gif, .jpeg, audio files,
other data files
•
Support for
• Multiple Schemes (DSA, RSA, …)
• Multiple Signatures
Java Code Signing: Steps
•
Create JAR file
•
Sign JAR with private key
•
Distribute signed JAR file
•
JAR header includes “who signed me”, signature and
certificate
•
JAR classloader extracts name, signature, certificate
•
System verifies signature
•
Depending on policy, signed code is granted limited
additional capability
Java Code Signing: Trust
•
Signature conveys identity
•
Application determines meaning of signature
•
Example: identity establishes the Principal, whose
capabilities are described by the ACL for that
Principal
•
ACLs are under control of user (browser) or
sysadmin (server)
Secure Channels
•
SSL v3.0 & X.509
•
SSL interface fits under Socket interface
•
SSL interface can be used by multiple protocols:
http, ftp, telnet, …
•
Other protocols can fit under the Socket interface,
e.g. to support UDP, multicast, VDP
Future Directions
Evolving the Sandbox:
Protection Domains
•
Protection domains as extended sandboxes
•
Automatic domain separation by class resolution
Protection Domains
•
Each class/object belongs to one and only one domain
•
Each domain is given permissions according to policy
Protection Domains
•
Access control decision is made depending on the
execution context (including protection domains
involved and their respective permissions)
Customizing Access Control
•
The built-in access control mechanism can be reused on
customized "new" permissions as long as they are subclassed
from the permission class
Secure Distributed Computing
•
Tools for building secure applications
•
Crypto APIs as Java Cryptography Extensions
•
Mechanisms and protocols for secure distributed
computing
•
Certificate management and administration support
Java Cryptography Architecture
•
Open standard (specification and source code)
•
Platform independence (free with Java)
•
Algorithm-neutral, concept-oriented framework
•
Completely open to crypto providers/toolkit
companies
•
No support for key-escrow or key-recovery
Protocols for Secure
Distributed Computing
•
User authentication and key exchange
•
Authorization and delegation
•
Secure communication (SSL, SKIP, secure
multicast)
•
Integration into applications such as RMI
•
Integration into the enterprise (legacy systems ...)
Certificate Management
and Tools
•
Deliver X.509v3, PKCS#7, #10, and IETF PKIX
(among other things) in Java
•
Produce Java-based CA servers and certificate
management systems
•
Provide certificate services to assist Java
deployment
Main Development Areas
•
Fine-grained, configurable access control applied to
Java applets as well as applications
•
Crypto APIs with selected built-in algorithms (DES,
3DES, MD-5, SHA-1, DSA, Diffie-Hellman)
•
Network/Web related security protocols (SSL,
SKIP)
•
Management and administration support (including
certificate infrastructure)
Security Roadmap
•
Right now -- crypto APIs (JCE 1.1 is EA)
•
This summer -- fine-grained, configurable access
control based on protection domains
•
Later in 1997 -- SSL, SKIP, and other protocols
•
1998 -- authentication, login, CA server
Resources and
Contact Information
Comments & Questions to:
[email protected]
http://www.javasoft.com/security
http://www.javasoft.com/nav/developer
Newsgroup - comp.lang.java.security
Java Security, by McGraw and Felten, 1997, Wiley