The session provides an overview of the security architecture of the Java platform in terms of its evolution throughout the versions of the JDK up to JDK 11 and beyond. The security utilities that fullfill the security portfolio of the JDK will be discussed briefly along with several guidelines in designing and implementing secure applications by following security best practices.

1. Security architecture
of the Java platform
Martin Toshev
@martin_fmi

2. @martin_fmi
Who am I
Software consultant (CoffeeCupConsulting)
BG JUG board member (http://jug.bg)
OpenJDK and Oracle RBDMS enthusiast

3. @martin_fmi

4. @martin_fmi
Agenda
• Evolution of the Java security model
• Security aspects of the new module system
• Outside the sandbox: APIs for secure coding
• Designing and coding with security in mind

5. Evolution of the Java security
model

6. @martin_fmi
Evolution of the
Java security model
• Traditionally - companies protect they assets
using strict physical and network access policies
• Tools such as anti-virus software, firewalls,
IPS/IDS systems facilitate this approach

7. @martin_fmi
Evolution of the
Java security model
• With the introduction of various technologies for
loading and executing code on the client
machine from the browser (such as Applets) - a
new range of concerns emerge related to client
security – this is when the Java security sandbox
starts to evolve …

8. @martin_fmi
Evolution of the
Java security model
• The goal of the Java security sandbox is to allow
untrusted code from applets to be executed in a
trusted environment such as the user's browser

9. @martin_fmi
Evolution of the
Java security model
• JDK 1.0 (when it all started …) – the original
sandbox model was introduced
Applet
(untrusted)
System code
(trusted)
JVM
Browser
http://codemotion.it/demoapplet

10. @martin_fmi
Evolution of the
Java security model
• Code executed by the JVM is divided in two
domains – trusted and untrusted
• Strict restriction are applied by default on the
security model of applets such as denial to
read/write data from disk, connect to the
network and so on

11. @martin_fmi
Evolution of the
Java security model
• JDK 1.1 (gaining trust …) – applet signing
introduced
Applet
(untrusted)
System code
(trusted)
JVM
Browser
Signed Applet
(trusted)
http://icodemotion.it/demoapplet
http://icodemotion.it/trustedapplet

12. @martin_fmi
Evolution of the
Java security model
• Local code (as in JDK 1.0) and signed applet code
(as of JDK 1.1) are trusted
• Unsigned remote code (as in JDK 1.0) is not
trusted

13. @martin_fmi
Evolution of the
Java security model
• Steps needed to sign and run an applet:
• Compile the applet
• Create a JAR file for the applet
• Generate a pair of public/private keys
• Sign the applet JAR with the private key
• Export a certificate for the public key
• Import the Certificate as a Trusted Certificate
• Create the policy file
• Load and run the applet

14. @martin_fmi
Evolution of the
Java security model
• JDK 1.2 (gaining more trust …) – fine-grained
access control
Applet
System code
JVM
Browser
grant codeBase http://codemotion.it/demoapplet {
permission java.io.FilePermisions “C:Windows”
“delete”
}
security.policy
SecurityManager.checkPermission(…)
AccessController.checkPermission(…)
http://codemotion.it/demoapplet

15. @martin_fmi
Evolution of the
Java security model
• The security model becomes code-centric
• Additional access control decisions are specified
in a security policy
• No more notion of trusted and untrusted code

16. @martin_fmi
Evolution of the
Java security model
• The notion of protection domain introduced –
determined by the security policy
• Two types of protection domains – system and
application

17. @martin_fmi
Evolution of the
Java security model
• The protection domain is set during classloading
and contains the code source and the list of
permissions for the class
applet.getClass().getProtectionDomain();

18. @martin_fmi
Evolution of the
Java security model
• One permission can imply another permission
java.io.FilePermissions “C:Windows” “delete”
implies
java.io.FilePermissions “C:Windowssystem32” “delete”

19. @martin_fmi
Evolution of the
Java security model
• One code source can imply another code source
codeBase http://codemotion.it/
implies
codeBase http://codemotion.it/demoapplet

20. @martin_fmi
Evolution of the
Java security model
• Since an execution thread may pass through
classes loaded by different classloaders (and
hence – have different protection domains) the
following rule of thumb applies:
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

21. @martin_fmi
Evolution of the
Java security model
• JDK 1.3, 1,4 (what about entities running the
code … ?) – JAAS
Applet
System code
JVM
Browser
http://codemotion.it/demoapplet
grant principal javax.security.auth.x500.X500Principal "cn=Tom"
{ permission java.io.FilePermissions “C:Windows” “delete” }
security.policy

22. @martin_fmi
Evolution of the
Java security model
• JAAS (Java Authentication and Authorization
Service) extends the security model with role-
based permissions
• The protection domain of a class now may
contain not only the code source and the
permissions but a list of principals

23. @martin_fmi
Evolution of the
Java security model
• The authentication component of JAAS is
independent of the security sandbox in Java and
hence is typically used in more wider context
(such as JavaEE application servers)
• The authorization component is the one that
extends the Java security policy

24. @martin_fmi
Evolution of the
Java security model
• Core classes of JAAS:
• javax.security.auth.Subject - an authenticated subject
• java.security.Principal - identifying characteristic of a subject
• javax.security.auth.spi.LoginModule - interface for
implementors of login (PAM) modules
• javax.security.auth.login.LoginContext - creates objects
used for authentication

25. @martin_fmi
Evolution of the
Java security model
• Up to JDK 1.4 the following is a typical flow for
permission checking:
1) upon system startup a security policy is set and a
security manager is installed
Policy.setPolicy(…)
System.setSecurityManager(…)

26. @martin_fmi
Evolution of the
Java security model
• Up to JDK 1.4 the following is a typical flow for
permission checking:
2) during classloading (e.g. of a remote applet)
bytecode verification is done and the protection
domain is set for the current classloader (along with
the code source, the set of permissions and the set
of JAAS principals)

27. @martin_fmi
Evolution of the
Java security model
• Up to JDK 1.4 the following is a typical flow for
permission checking:
3) when system code is invoked from the remote code
the SecurityManager is used to check against the
intersection of protection domains based on the
chain of threads and their call stacks

28. @martin_fmi
Evolution of the
Java security model
• Up to JDK 1.4 the following is a typical flow for
permission checking:
SocketPermission permission = new
SocketPermission(“codemotion.it:8000-
9000","connect,accept");
SecurityManager sm = System.getSecurityManager();
if (sm != null) sm.checkPermission(permission);

29. @martin_fmi
Evolution of the
Java security model
• Up to JDK 1.4 the following is a typical flow for
permission checking:
4) application code can also do permission checking
against remote code using a SecurityManager or an
AccessController

30. @martin_fmi
Evolution of the
Java security model
• Up to JDK 1.4 the following is a typical flow for
permission checking:
SocketPermission permission = new
SocketPermission(“codemotion.it:8000-9000",
"connect,accept");
AccessController.checkPermission(permission)

31. @martin_fmi
Evolution of the
Java security model
• Up to JDK 1.4 the following is a typical flow for
permission checking:
5) application code can also do permission checking
with all permissions of the calling domain or a
particular JAAS subject
AccessController.doPrivileged(…)
Subject.doAs(…)
Subject.doAsPrivileged(…)

32. @martin_fmi
Evolution of the
Java security model
• The security model defined by
java.lang.SecurityManager is customizable
• For example: Oracle JVM uses a custom
SecurityManager with additional permission
classes where the code source is a database
schema (containing e.g. Java stored procedures)

33. @martin_fmi
Evolution of the
Java security model
• JDK 1.5, 1.6 (enhancing the model …) – new
additions to the sandbox model (e.g. LDAP
support for JAAS)

34. @martin_fmi
Evolution of the
Java security model
• JDK 1.7, 1.8 (further enhancing the model …) –
enhancements to the sandbox model (e.g.
AccessController.doPrivileged() for checking
against a subset of permissions)

35. @martin_fmi
Evolution of the
Java security model
• JDK 1.9 and beyond … (applying the model to
modules …)
application module
system
module 1
JVM
Browser
http://codemotion.it/appmodule
security.policy
system
module 2

36. Security aspects of the new
module system

37. @martin_fmi
The Big Picture
37
JVM
Application
grant codeBase "jrt:/it.codemotion" {
permission java.io.FilePermisions
“C:Windows” “delete”
}
java.policy
SecurityManager.
checkPermission(…)
AccessController.
checkPermission(…)
java.base
java.logging
It.codemotion

38. @martin_fmi
Security implications
• The security model remains the same with Java
modules
• System code is split into modules and
applications can use a stripped down VM =>
improved security
• Application code can be split into modules with
stronger encapsulation at runtime => improved
security
38

39. @martin_fmi
Access control
• Access control is governed not by the class
loader(s) of the module’s classes but by the
module itself
• Access modifiers are fulfilled by another layer of
encapsulation: exported/opened packages
39

40. @martin_fmi
Runtime modules
• Modules can also be defined at runtime with
multiple classloaders and grouped into
module layers for that purpose:
40
obj.getClass().getModule().getLayer().defineModulesXXX(…)

41. Outside the sandbox:
APIs for secure coding

42. @martin_fmi
Outside the sandbox:
APIs for secure coding
• The security sandbox defines a strict model for
execution of remote code in the JVM
• The other side of the coin are the security APIs
that provide utilities for implementing the
different aspects of application security …

43. @martin_fmi
Outside the sandbox:
APIs for secure coding
• The additional set of APIs includes:
• JCA (Java Cryptography Architecture)
• PKI (Public Key Infrastructure) utilities
• JSSE (Java Secure Socket Extension)
• Java GSS API (Java Generic Security Services)
• Java SASL API (Java Simple Authentication and Security
Layer)

44. @martin_fmi
Outside the sandbox:
APIs for secure coding
• JCA provides utilities for:
• creating digital signatures
• creating message digests
• using cryptographic ciphers (symetric/asymetric,
block/stream)
• using different other types of cryptographic services and
algorithms

45. @martin_fmi
Outside the sandbox:
APIs for secure coding
• JCA has a pluggable architecture
• JCA is independent from particular
cryptographic algorithms
• JCA continues to evolve (especially by providing
stronger cryptographic algorithms)

46. @martin_fmi
Outside the sandbox:
APIs for secure coding
• PKI utilities provide means for working with:
• certificates
• certificate revocation lists (CRL)
• OCSP (Online Certificate Status Protocol)
• key stores and trust stores (also based on the PKCS -
public-key cryptography standards)

47. @martin_fmi
Outside the sandbox:
APIs for secure coding
• PKI certificate revocation check (revision):
• PKI utilities continue to evolve (especially in
providing more support for managing
certificates and keys)
certificate
authorityrevocation
checking
OCSP
CRL
certificate
certificate

48. @martin_fmi
Outside the sandbox:
APIs for secure coding
• JSSE provides an implementation of the TSL/SSL
sockets for working with remote communication
• JSSE continues to evolve (especially in the
support for additional features such as Server
Name Identication)

49. @martin_fmi
Outside the sandbox:
APIs for secure coding
• Java GSS API provides an alternative of JSSE for
secure communication
• Java GSS API is a framework for providing token-
based security services that is independent of
the underlying protocols

50. @martin_fmi
Outside the sandbox:
APIs for secure coding
• Java GSS API can be used along with JAAS for
authentication purposes
• Java GSS API continues to evolve (especially in
the support for Kerberos authentication)

51. @martin_fmi
Outside the sandbox:
APIs for secure coding
• Java SASL defines a protocol for exchange of
authentication data
• Java SASL is a framework where external
providers give concrete semantics to the
authentication data being exchanged

52. @martin_fmi
Outside the sandbox:
APIs for secure coding
• Java SASL continues to evolve (especially with
support for additional and enhanced properties
for exchanging authentication data)

53. Designing and coding
with security in mind

54. @martin_fmi
Designing and coding
with security in mind
• First of all - follow programing guidelines and
best practices - most are not bound to the Java
programming language (input validation, error
handling, type safety, access modifiers, resource
cleanup, prepared SQL queries and whatever
you can think of …)

55. @martin_fmi
Designing and coding
with security in mind
• Respect the SecurityManager - design libraries
so that they work in environments with installed
SecurityManager
• Example: GSON library does not respect the
SecurityManager and cannot be used without
additional reflective permissions in some
scenarios

56. @martin_fmi
Designing and coding
with security in mind
• Grant minimal permissions to code that requires
them - the principle of "least privilege"
• Copy-pasting, of course, increases the risk of
security flows (if the copied code is flawed)

57. @martin_fmi
Designing and coding
with security in mind
• Sanitize exception messages from sensitive
information - often this results in an unintended
exposal of exploitable information
• Let alone exception stacktraces … in many cases
they convey a wealth of information about the
system

58. Thank you

59. @martin_fmi
References
• Java Security Overview (white paper)
http://www.oracle.com/technetwork/java/js-white-
paper-149932.pdf
• Java SE Platform Security Architecture Spec
http://docs.oracle.com/javase/7/docs/technotes/guid
es/security/spec/security-spec.doc.html
• Inside Java 2 Platform Security, 2nd edition
http://www.amazon.com/Inside-Java%C2%BF-
Platform-Security-Implementation/dp/0201787911

60. @martin_fmi
References
• Java Security, 2nd edition, Scott Oaks
http://shop.oreilly.com/product/9780596001575.do
• Securing Java, Gary McGraw, Ed Felden
http://www.securingjava.com
• Secure Coding Guidelines for Java SE
http://www.oracle.com/technetwork/java/seccodegui
de-139067.html#0

61. @martin_fmi
References
• Java 2 Network Security
http://www.amazon.com/JAVA-Network-Security-
2nd-Edition/dp/0130155926
• Java Security Documentation
http://docs.oracle.com/javase/8/docs/technotes/guid
es/security/index.html

62. @martin_fmi
References
• Core Java Security: Class Loaders, Security
Managers and Encryption
http://www.informit.com/articles/article.aspx?p=1187
967
• Overview of Java Security Models
http://docs.oracle.com/cd/E12839_01/core.1111/e10
043/introjps.htm#CHDCEJGH