<Insert Picture Here>

Java Secure Coding Guidelines

Sean Mullan, JDK Security Tech Lead
Jeff Nisewanger, JDK Security Architect
Frances Ho, JDK Security Manager
 Agenda

• Goal <Insert Picture Here>

• Java Security Team Charter

• Java SE Security Overview
• Java SE Security Components
• Vulnerabilities
• Antipatterns – guidelines & examples
• Summary

 2011 Oracle Corporation – Proprietary and Confidential 2

 Goal

• Provide a high level overview of Java SE

security
• Reduce vulnerabilities by avoiding insecure Java
coding patterns (antipatterns)
• Target audience
• SPOCs
• Interested Java programmers

 2011 Oracle Corporation – Proprietary and Confidential 3

 Java Security Team Charter

• Owner of Java security architecture

• Design, implementation and evolution
• Enhance and maintain Java SE Security Components
and APIs
• Advise on security issues in other JDK components
• Analyze/fix vulnerabilities, conduct security audits and
publish/evangelize Java Secure Coding Guidelines
• Collaborate with other teams – GPS, Java EE, ME,
Solaris Security
• Participate in standards organizations (JCP, IETF,
W3C XML Security, TCG)
 2011 Oracle Corporation – Proprietary and Confidential 4
 Java Security Overview

• Runtime Security
• Behavior enforced by the Java
Runtime
• Enables applications to be run Applications
safely in a restricted environment
• Security Libraries Security Tools
Security
Libraries
• Standard APIs for Crypto, PKI, Runtime
Security
Authentication, Policy & Secure
Communication
• Pluggable implementations
• Security Tools
• keytool, jarsigner, policytool
 2011 Oracle Corporation – Proprietary and Confidential 5
 Java SE Security Components

• Security Manager & Policy

• Java Cryptography Extension (JCE)
• Public Key Infrastructure (PKI)
• Java Authentication and Authorization Service (JAAS)
• Java Secure Socket Extension (JSSE)
• Java GSSAPI and Kerberos
• Java SASL
• XML Signature and Encryption
• Tools
• See Appendix for more info

 2011 Oracle Corporation – Proprietary and Confidential 6

 Java Security Manager and Policy
Local or Remote Security Policy
Code

Domain Domain Domain

Full Access to Domain

Resource

Security Manager

System Resources (Files,

Network, Connections,
etc.)

 2011 Oracle Corporation – Proprietary and Confidential 7

 The Big Picture

CertPath
JAAS Java SASL
Digital Signature

CRLs

X.509 JNDI NT Kerberos UNIX GSS-API CRAM Digest

Encryption

Java GSS
JSSE
PKI

Kerberos

Kerberos
XML

JCE

SW Crypto PKCS 11

Certificate Directory
Server Server HW Crypto Smart Card
Accelerator

 2011 Oracle Corporation – Proprietary and Confidential 8

 Vulnerability

• Definition
• A weakness in a system allowing an attacker to
violate the integrity, confidentiality, access control,
availability, consistency or audit mechanism of the
system or the data and applications it hosts
• Causes
• Faulty assumptions in the application architecture
• Errors in configuration
• Insecure programming practices (antipatterns)

 2011 Oracle Corporation – Proprietary and Confidential 9

 Secure Coding Antipatterns

• Programming practices one should avoid

• Negative counterpart to a design pattern
• E.g. implementing methods that don’t validate input
params
• Antipatterns not set in stone
• Generally should avoid them, but there are
exceptions
• Make sure you understand the consequences
• Vulnerabilities may exist in various locations
• Application code, shared libraries, Java™ platform
core libraries
 2011 Oracle Corporation – Proprietary and Confidential 10
 Antipatterns in C vs. Java
Programming Language
• C-based antipatterns often exploit buffer overflows
• Java runtime environment safely manages memory
• Performs automatic bounds checks on arrays
• No pointer arithmetic
• The Java runtime environment often executes
untrusted code
• Must protect against access to unauthorized
resources
• Results in a different set of coding antipatterns than C

 2011 Oracle Corporation – Proprietary and Confidential 11

 How This Presentation is Organized

• List common Java coding antipatterns

• For each antipattern:
• Show real example from an older JDK release
• Explain the problem and attack scenario
• Describe the proper secure coding guidelines
• URLs pointing to specific guidelines in our Secure Coding
Guidelines document with more information:
• http://www.oracle.com/technetwork/java/seccodeguide-139067.html

• Content are from lessons learned over the years by

our team, not part of GPS Secure Coding Standards

 2011 Oracle Corporation – Proprietary and Confidential 12

 Antipattern 1: Assuming Objects Are
Immutable - Example
• Example from JDK 1.1 software

package java.lang;
public class Class {
private Object[] signers;
public Object[] getSigners() {
return signers;
}
}

 2011 Oracle Corporation – Proprietary and Confidential 13

 Antipattern 1: Assuming Objects Are
Immutable - Example
• Attacker can change signers of classes

package java.lang;
public class Class {
private Object[] signers;
public Object[] getSigners() {
return signers;
}
}

Object[] signers = this.getClass().getSigners();

signers[0] = <new signer>;

 2011 Oracle Corporation – Proprietary and Confidential 14

 Antipattern 1: Assuming Objects Are
Immutable - Problem
• Mutable input and output objects can be modified by
the caller
• Modifications can cause applications to behave
incorrectly
• Modifications to sensitive security state may result in
elevated privileges for attacker
• e.g. altering the signers of a class can give the
class access to unauthorized resources

 2011 Oracle Corporation – Proprietary and Confidential 15

 Antipattern 1: Assuming Objects Are
Immutable - Guidelines
• Make a copy of mutable output parameters
• Make a copy of mutable input parameters
public Object[] getSigners() {
// signers contains immutable type
// X509Certificate.
// shallow copy of array is OK.
return signers.clone();
}

public MyClass(Date start, boolean[] flags) {

this.start = new Date(start.getTime());
this.flags = flags.clone();
}
• Perform deep cloning on arrays if necessary

 2011 Oracle Corporation – Proprietary and Confidential 16

 Antipattern 1: Assuming Objects Are
Immutable - Guidelines
• For more information, see Secure Coding Guidelines:
• Guideline 2-1 Prefer immutable classes
• Guideline 2-2 Create copies of mutable outputs
• Guideline 2-2a Create safe copies of mutable and subclassable input
s

 2011 Oracle Corporation – Proprietary and Confidential 17

 Antipattern 2: Basing Security Checks
on Untrusted Sources - Example
• Example from JDK 5.0

public RandomAccessFile openFile(final java.io.File f) {

askUserPermission(f.getPath());
...
return AccessController.doPrivileged<RandomAccessFile>() {
public RandomAccessFile run() {
return new RandomAccessFile(f.getPath());
}
}
}

 2011 Oracle Corporation – Proprietary and Confidential 18

 Antipattern 2: Basing Security Checks
on Untrusted Sources - Problem
• Attacker can pass in subclass of java.io.File that
overrides getPath()
public RandomAccessFile openFile(final java.io.File f) {
askUserPermission(f.getPath());
...
return new RandomAccessFile(f.getPath());
...
}

public class BadFile extends java.io.File {

private int count;
@Override public String getPath() {
return (++count == 1) ? “/tmp/foo” : “/etc/passwd”;
}
}

 2011 Oracle Corporation – Proprietary and Confidential 19

 Antipattern 2: Basing Security Checks
on Untrusted Sources - Problem
• Security checks can be fooled if they are based on
information that attackers can control
• It is easy to assume input types defined in the Java
core libraries (like java.io.File) are secure and can be
trusted
• Non-final classes/methods can be subclassed
• Mutable types can be modified

 2011 Oracle Corporation – Proprietary and Confidential 20

 Antipattern 2: Basing Security Checks
on Untrusted Sources - Guidelines
• Don’t assume inputs are immutable
• Make defensive copies of non-final or mutable inputs
and perform checks using copies

public RandomAccessFile openFile(File f) {

final File copy = f.clone();
askUserPermission(copy.getPath());
...
return new RandomAccessFile(copy.getPath());
}

 2011 Oracle Corporation – Proprietary and Confidential 21

 Antipattern 2: Basing Security Checks
on Untrusted Sources - Guidelines
• WRONG: clone() copies attacker’s subclass
public RandomAccessFile openFile(java.io.File f) {
final java.io.File copy = f.clone();
askUserPermission(copy.getPath());
...
}
• RIGHT
java.io.File copy = new java.io.File(f.getPath());

 2011 Oracle Corporation – Proprietary and Confidential 22

 Antipattern 2: Basing Security Checks
on Untrusted Sources - Guidelines
• For more information, see Secure Coding Guidelines:
• Guideline 2-1 Prefer immutable classes
• Guideline 2-2 Create copies of mutable outputs
• Guideline 2-2a Create safe copies of mutable and subclassable inputs
• Guideline 2-3 Support copy functionality for a mutable class

 2011 Oracle Corporation – Proprietary and Confidential 23

 Antipattern 3: Ignoring Changes to
Superclasses - Example
• Example from JDK 1.2 software

java.util.Hashtable put(key, val)

remove(key)
extends

java.util.Properties
extends

java.security.Provider put(key, val) // security check

remove(key) // security check

 2011 Oracle Corporation – Proprietary and Confidential 24

 Antipattern 3: Ignoring Changes to
Superclasses - Example
java.util.Hashtable put(key, val)
remove(key)
extends Set entrySet()

java.util.Properties

extends

java.security.Provider put(key, val) // security check

remove(key) // security check

 2011 Oracle Corporation – Proprietary and Confidential 25

 Antipattern 3: Ignoring Changes to
Superclasses - Example
• Attacker bypasses remove method and uses
inherited entrySet method to delete properties

java.util.Hashtable put(key, val)

remove(key)
extends Set entrySet() // supports removal

java.util.Properties

extends

java.security.Provider put(key, val) // security check

remove(key) // security check

 2011 Oracle Corporation – Proprietary and Confidential 26

 Antipattern 3: Ignoring Changes to
Superclasses - Problem
• Subclasses cannot guarantee encapsulation
• Superclass may modify behavior of methods that
have not been overridden
• Superclass may add new methods
• Security checks enforced in subclasses can be
bypassed
• Provider.remove security check bypassed if
attacker calls newly inherited entrySet method to
perform removal

 2011 Oracle Corporation – Proprietary and Confidential 27

 Antipattern 3: Ignoring Changes to
Superclasses - Guidelines
• Avoid inappropriate subclassing
• Subclass when the inheritance model is well
specified and well understood
• Monitor changes to superclasses
• Identify behavioral changes to existing inherited
methods and override if necessary
• Identify new methods and override if necessary
java.security.Provider put(key, value) // security check
remove(key) // security check
Set entrySet() // immutable set

 2011 Oracle Corporation – Proprietary and Confidential 28

 Antipattern 3: Ignoring Changes to
Superclasses - Guidelines
• For more information, see Secure Coding Guidelines:
• Guideline 1-3 Understand how a superclass can affect subclass behavior

 2011 Oracle Corporation – Proprietary and Confidential 29

 Antipattern 4: Neglecting to Validate
Input - Example
• Example from JDK 1.4 software

package sun.net.www.protocol.http;

public class HttpURLConnection extends

java.net.HttpURLConnection
{
/**
* Set header on HTTP request
*/
public void setRequestProperty(String key, String value) {
// no input validation on key and value
}
}

 2011 Oracle Corporation – Proprietary and Confidential 30

 Antipattern 4: Neglecting to Validate
Input - Example
• Attacker crafts HTTP headers with embedded requests
that bypass security
package sun.net.www.protocol.http;
public class HttpURLConnection extends
java.net.HttpURLConnection
{
public void setRequestProperty(String key, String value) {
// no input validation on key and value
}
}

urlConn.setRequestProperty
("Accept",
"*.*\r\n\r\nGET http://victim_host HTTP/1.0\r\n\r\n");

 2011 Oracle Corporation – Proprietary and Confidential 31

 Antipattern 4: Neglecting to Validate
Input- Example
GET http://origin_host HTTP/1.0
Accept: *.*

Applet GET http://victim_host HTTP/1.0

client
host GET http://origin_host HTTP/1.0
Accept: *.*
Web Applet
proxy origin
host

Victim
host GET http://victim_host HTTP/1.0

Intranet Internet

 2011 Oracle Corporation – Proprietary and Confidential 32

 Antipattern 4: Neglecting to Validate
Input - Problem
• Creative inputs with out-of-bounds values or escape
characters can be crafted
• Affects code that processes requests or delegates to
subcomponents
• Implements network protocols
• Constructs SQL requests
• Calls shell scripts
• Additional issues when calling native methods
• No automatic array bounds checks

 2011 Oracle Corporation – Proprietary and Confidential 33

 Antipattern 4: Neglecting to Validate
Input - Guidelines
• Validate inputs
• Check for escape characters
• Check for out-of-bounds values
• Check for malformed requests
• Regular expression API can help validate String
inputs
• Pass validated inputs to sub-components
• Wrap native methods in Java programming
language wrapper to validate inputs
• Make native methods private

 2011 Oracle Corporation – Proprietary and Confidential 34

 Antipattern 4: Neglecting to Validate
Input - Guidelines
• For more information, see Secure Coding Guidelines:
• Guideline 2-4 Generate valid formatting
• Guideline 2-4a Validate inputs
• Guideline 3-3 Define wrappers around native methods

 2011 Oracle Corporation – Proprietary and Confidential 35

 Antipattern 5: Misusing Public Static
Variables - Example
• Example from JDK 1.4.2 software

package org.apache.xpath.compiler;

public class FunctionTable {

public static FuncLoader m_functions;
}

 2011 Oracle Corporation – Proprietary and Confidential 36

 Antipattern 5: Misusing Public Static
Variables - Problem
• Attacker can replace function table

package org.apache.xpath.compiler;

public class FunctionTable {

public static FuncLoader m_functions;
}

FunctionTable.m_functions = <new_table>;

 2011 Oracle Corporation – Proprietary and Confidential 37

 Antipattern 5: Misusing Public Static
Variables - Problem
• Sensitive static state can be modified by untrusted
code
• Replacing the function table gives attackers access to the
XPathContext used to evaluate XPath expressions
• Static variables are global across a Java runtime
environment
• Can be used to attack different application domains (e.g. by
code loaded into different class loaders)

 2011 Oracle Corporation – Proprietary and Confidential 38

 Antipattern 5: Misusing Public Static
Variables - Guidelines
• Reduce the scope of static fields
private static FuncLoader m_functions;

• Treat public statics primarily as constants

• Consider using enum types
• Make public static fields final

public class MyClass {

public static final int LEFT = 1;
public static final int RIGHT = 2;
}

 2011 Oracle Corporation – Proprietary and Confidential 39

 Antipattern 5: Misusing Public Static
Variables - Guidelines
• Define accessor methods for mutable static state
• Add appropriate security checks

public class MyClass {

private static byte[] data;

public static byte[] getData() {

return data.clone();
}

public static void setData(byte[] b) {

securityCheck();
data = b.clone();
}
}

 2011 Oracle Corporation – Proprietary and Confidential 40

 Antipattern 5: Misusing Public Static
Variables - Guidelines
• Don't pass internal data to untrusted objects
• Input parameters may act as outputs

public class MyClass {

private static byte[] data;

public static void write(OutputStream out)

throws IOException
{
out.write(data.clone());
}

 2011 Oracle Corporation – Proprietary and Confidential 41

 Antipattern 5: Misusing Public Static
Variables - Guidelines
• For more information, see Secure Coding Guidelines:
• Guideline 1-1 Limit the accessibility of classes,interfaces, methods, and fie
lds
• Guideline 2-2b Create copies of mutable objects passed to untrusted objec
ts
• Guideline 3-1 Treat public static fields as constants
• Guideline 3-2 Define wrapper methods around modifiable internal state

 2011 Oracle Corporation – Proprietary and Confidential 42

 Antipattern 6: Believing a Constructor
Exception Destroys the Object - Example
• Example from JDK 1.0.2 software

package java.lang;

public class ClassLoader {

public ClassLoader() {
// permission needed to create class loader
securityCheck();
init();
}
}

 2011 Oracle Corporation – Proprietary and Confidential 43

 Antipattern 6: Believing a Constructor
Exception Destroys the Object - Example
• Attacker overrides finalize to get partially initialized
ClassLoader instance
public class MyCL extends ClassLoader {
static ClassLoader cl;
package java.lang;
@Override protected void finalize() {
cl = this;
public class ClassLoader {
}
public ClassLoader() { public static void main(String[] s) {
securityCheck(); try {
init(); new MyCL();
} } catch (SecurityException e) {}
} System.gc();
System.runFinalization();
System.out.println(cl);
}
}

 2011 Oracle Corporation – Proprietary and Confidential 44

 Antipattern 6: Believing a Constructor
Exception Destroys the Object - Problem
• Throwing an exception from a constructor does not
prevent a partially initialized instance from being
acquired
• Attacker can override finalize method to obtain the
object
• Constructors that call into outside code often naively
propagate exceptions
• Enables the same attack as if the constructor
directly threw the exception

 2011 Oracle Corporation – Proprietary and Confidential 45

 Antipattern 6: Believing a Constructor
Exception Destroys the Object - Guidelines
• Make class final if possible
• If finalize method can be overridden, ensure partially
initialized instances are unusable
• Do not set fields until all checks have completed
• Use an initialized flag
public class ClassLoader {
private volatile boolean initialized = false;

protected ClassLoader() {
securityCheck();
init();
initialized = true; // check flag in all relevant
// methods
}
}
 2011 Oracle Corporation – Proprietary and Confidential 46
 Antipattern 6: Believing a Constructor
Exception Destroys the Object - Guidelines
• For Java SE 6 and later only, exceptions thrown before
super() is invoked do destroy the object
• Use -target 1.6 or higher
• Does not work with Java SE 5.0 or earlier
public class ClassLoader {
protected ClassLoader() {
this(securityCheck());
}
private ClassLoader(Void ignored) { // not accessible
super();
init();
}
// no flag to check
}

 2011 Oracle Corporation – Proprietary and Confidential 47

 Antipattern 6: Believing a Constructor
Exception Destroys the Object - Guidelines
• For more information, see Secure Coding Guidelines:
• Guideline 1-2 Limit the extensibility of classes and methods
• Guideline 4-2 Prevent the unauthorized construction of sensitive classes
• Guideline 4-3 Defend against partially initialized instances of non-final clas
ses
• Guideline 4-4 Prevent constructors from calling methods that can be overr
idden

 2011 Oracle Corporation – Proprietary and Confidential 48

 Antipattern 7: Assuming Exceptions Are
Harmless - Example
• Exceptions may contain sensitive data such as
directory paths that imply user identity

 2011 Oracle Corporation – Proprietary and Confidential 49

 Antipattern 7: Assuming Exceptions Are
Harmless - Problem
• Attacker can learn sensitive data

public class PersonalData {

public InputStream load() throws IOException {
return AccessController.doPrivileged(...
String homedir = System.getProperty(“user.dir”);
File f = new File(homedir, “personal.dat”);
return new FileInputStream(f);
...);
}
}
try { personal.load(); } catch (IOException e) {
String homedir = parsePath(e.message());
String username = parseUser(homedir);
}
 2011 Oracle Corporation – Proprietary and Confidential 50
 Antipattern 7: Assuming Exceptions Are
Harmless - Guidelines
• Sanitize or mask exceptions

public class PersonalData {

public InputStream load() throws IOException {
try {
...
} catch (Exception e) {
throw new IOException(“Could not load data”);
}
}
}

 2011 Oracle Corporation – Proprietary and Confidential 51

 Antipattern 7: Assuming Exceptions Are
Harmless - Guidelines
• For more information, see Secure Coding Guidelines:
• Guideline 0-6a Purge sensitive information from exceptions

 2011 Oracle Corporation – Proprietary and Confidential 52

 Antipattern 8: Believing Deserialization
Is Unrelated to Constructors - Example
• Example from JDK 1.1 software

package java.math;

public class BigInteger extends Number {

private int signum;

public BigInteger(int signum, byte[] magnitude){

if (signum < -1 || signum > 1) {
throw new NumberFormatException()
...
}
}
}

 2011 Oracle Corporation – Proprietary and Confidential 53

 Antipattern 8: Believing Deserialization
Is Unrelated to Constructors - Example
• Attacker can deserialize a stream with invalid field
data
public class BigInteger extends Number {
private int signum;
public BigInteger(int signum, byte[] magnitude){
if (signum < -1 || signum > 1) {
throw new NumberFormatException()
...
}
}
}

ObjectInputStream in = new ObjectInputStream(

new ByteArrayInputStream(badByteArray));
BigInteger bigBadInt = (BigInteger)in.readObject();

 2011 Oracle Corporation – Proprietary and Confidential 54

 Antipattern 8: Believing Deserialization
Is Unrelated to Constructors - Problem
• The default deserialization mechanism cannot
automatically apply the same invariant and parameter
checking present in the constructor
• Attacker can create a malicious serialization stream
with invalid field values

 2011 Oracle Corporation – Proprietary and Confidential 55

 Antipattern 8: Believing Deserialization
Is Unrelated to Constructors - Guidelines
• Create a custom readObject() method that shares the
same validation checking as the class constructors

private transient volatile initialized;

private void readObject(ObjectInputStream in)
throws IOException, ClassNotFoundException
{
in.defaultReadObject();
// Validate signum
if (signum < -1 || signum > 1)
throw new StreamCorruptedException();
initialized = true;
}

 2011 Oracle Corporation – Proprietary and Confidential 56

 Antipattern 8: Believing Deserialization
Is Unrelated to Constructors - Guidelines
• Intermediate state may be avoided

private void readObject(ObjectInputStream in)

throws IOException, ClassNotFoundException
{
GetField fields = in.readFields();
int signum = fields.get(“signum”, 0);
// Validate signum
if (signum < -1 || signum > 1)
throw new StreamCorruptedException();
...
}

 2011 Oracle Corporation – Proprietary and Confidential 57

 Antipattern 8: Believing Deserialization
Is Unrelated to Constructors - Guidelines
• For more information, see Secure Coding Guidelines:
• Guideline 5-3 View deserialization the same as object constru
ction

 2011 Oracle Corporation – Proprietary and Confidential 58

 Antipattern 9: Believing Deserialized
Field Values are Unshared - Example
package java.math;

public class BigInteger extends Number {

private byte[] magnitude;

public BigInteger(int signum, byte[] magnitude){

this.magnitude = (byte[])magnitude.clone();
...
}
}

 2011 Oracle Corporation – Proprietary and Confidential 59

 Antipattern 9: Believing Deserialized
Field Values are Unshared - Example
• Attacker can deserialize a stream with malicious
“extra” references to mutable fields
public class BigInteger extends Number {
private byte[] magnitude;

public BigInteger(int signum, byte[] magnitude){

this.magnitude = (byte[])magnitude.clone();
...
}
}

ObjectInputStream in = new ObjectInputStream(

new ByteArrayInputStream(badByteArray));
BigInteger bigBadInt = (BigInteger)in.readObject();
byte[] magnitudeCopy = (byte[])in.readObject();

 2011 Oracle Corporation – Proprietary and Confidential 60

 Antipattern 9: Believing Deserialized
Field Values are Unshared - Problem
• The default deserialization mechanism assumes
object references in a stream might have multiple
legitimate references
• Attacker can create a malicious serialization stream
with unintended extra references to a mutable field
object instance

 2011 Oracle Corporation – Proprietary and Confidential 61

 Antipattern 9: Believing Deserialized
Field Values are Unshared - Guidelines
• Create a custom readObject() method that creates an
unshared private copy of mutable field instances

private void readObject(ObjectInputStream in)

throws IOException, ClassNotFoundException
{
GetField fields = in.readFields();
...
byte[] magnitude =
(byte[])fields.get(“magnitude”, null);
this.maginitude = (byte[])magnitude.clone();
}

 2011 Oracle Corporation – Proprietary and Confidential 62

 Antipattern 9: Believing Deserialized
Field Values are Unshared - Guidelines
• For more information, see Secure Coding Guidelines:
• Guideline 5-3 View deserialization the same as object constru
ction

 2011 Oracle Corporation – Proprietary and Confidential 63

 Summary

• Vulnerabilities are a concern for all developers

• Can have severe impacts on security and privacy
• Follow Secure Coding Guidelines to reduce
vulnerabilities
• Encourages secure programming from the outset
• Helps limit bad assumptions that might be made
• Avoids common antipatterns

 2011 Oracle Corporation – Proprietary and Confidential 64

 Next Steps

• Ongoing updates
• v3.0 for JDK 7 GA
• Integration into Oracle Secure Coding Standards
(SCS)
• Possible OU training course material

 2011 Oracle Corporation – Proprietary and Confidential 65

 For More Information

• Secure Coding Guidelines

• Secure Coding Guidelines for the Java Programming Langua
ge
• The CERT Oracle Secure Coding Standard for Java
• Tools
• Fortify
• Parfait
• FindBugs

 2011 Oracle Corporation – Proprietary and Confidential 66

 <Insert Picture Here>

Appendix

 2011 Oracle Corporation – Proprietary and Confidential 67

 Acronyms

• ECC: Elliptic Curve Cryptography

• ECDSA: Elliptic Curve Digital Signature Algorithm
• ECDH: Elliptic Curve Diffie-Hellman Algorithm
• GSSAPI: Generic Security Services API
• SPNEGO: Simple and Protected GSSAPI
Negotiation mechanism
• JAAS: Java Authentication and Authorization Service
• JCE: Java Cryptography Extension
• JSSE: Java Secure Socket Extension

 2011 Oracle Corporation – Proprietary and Confidential 68

 Acronyms

• MSCAPI: Microsoft Crypto API

• PKCS: Public-Key Cryptography Standards
• PKCS #11: Cryptographic Token Interface
Standard
• PKI: Public-Key Infrastructure
• SASL: Simple Authentication and Security Layer
• SSR: Synchronized Security Release
• TCG: Trusted Computing Group
• TLS: Transport Layer Security

 2011 Oracle Corporation – Proprietary and Confidential 69

 References

• Java SE Security home page

• http://www.oracle.com/technetwork/java/javase/tech/index-jsp-136007.html
• Java Security Guides
• http://download.oracle.com/javase/6/docs/technotes/guides/security/
• Security White Paper

 2011 Oracle Corporation – Proprietary and Confidential 70

 2011 Oracle Corporation – Proprietary and Confidential 71