Security in Java

1
Security in Java

• Sunesh Kumra
• S-38.153
• Security of Communication Protocols
• Helsinki University of Technology

2
Contents

• Java Security Model in Java 1.0 , 1.1 and 1.2 1
• Cryptography Architecture Extensions 1
• Terms and Tools 1
• Exchanging signed code with help of running
  example 1
• Security in Java as a language 3 4

3
JDK 1.0 Security Model

• The "sandbox" model, existed in order to provide
  a very restricted environment in which to run
  untrusted code obtained from the open network.
• Local code is trusted to have full access to
  vital system resources but downloaded remote code
  (an applet) is not trusted and can access only
  the limited resources provided inside the
  sandbox.
• A security manager is responsible in this and
  subsequent platforms for determining which
  resource accesses are allowed.

4
JDK 1.0 Security Model (contd.)
5
JDK 1.1 Security Model

• JDK 1.1 introduced the concept of a "signed
  applet,"
• A digitally signed applet is treated like local
  code, if the public key used to verify the
  signature is trusted.
• Unsigned applets are still run in the sandbox.

6
JDK 1.2 Security Model

• All code, regardless of whether it is local or
  remote, can now be subject to a security policy.
• The security policy defines the set of
  permissions available for code from various
  signers or locations.
• Each permission specifies a permitted access to a
  particular resource, such as read and write
  access to a specified file or directory or
  connect access to a given host and port.
• The runtime system organizes code into
  individual domains, each of which encloses a set
  of classes whose instances are granted the same
  set of permissions.

7
Sample policy file

• keystore "file/c/hut/security/java/receiverstore
  "
• grant signedBy "sunesh"
• permission java.io.FilePermission
  "c/hut/security/java/data/", "read"

8
JDK 1.2 Security Model (contd.)
9
Cryptography Architecture Extensions

• In JDK 1.1 included support for
• digital signature generation
• message digest algorithms
• 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

10
Cryptography Architecture Extensions (contd.)

• Certificate factory support to generate
  certificates and certificate revocation lists
  (CRLs) from their encodings

11
Few Terms (Again !)

• Certificate - This class is an abstraction for
  certificates that have various formats but
  important common uses. For example, various types
  of certificates, such as X.509 and PGP. (in the
  java.security.cert package).
• A KeyStore class supplies well-defined
  interfaces to access and modify the information
  in a keystore, which is a repository of keys and
  certificates

12
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 etc
• The jarsigner tool signs JAR (Java ARchive
  format) files and verifies the authenticity of
  the signature(s) of signed JAR files.
• The policyTool creates and modifies the policy
  configuration files that define your
  installation's security policy.

13
Running Example for Secure Code Exchange - Sender

• 1) Take any Java file you want to exchange
  securely. For e.g. Count.java
• 2) Create a JAR File
• jar cvf Count.jar Count.class
• 3) Generate Keys
• keytool -genkey -alias signFiles -keypass abc123
  -keystore suneshstore -storepass xyz123
• 4) Sign the JAR
• jarsigner -keystore suneshstore -signedjar
  sCount.jar Count.jar signFiles

14
Running Example for Secure Code Exchange - Sender
(contd.)

• 5) Export the Public Key Certificate
• keytool -export -keystore suneshstore -alias
  signFiles -file Sunesh.cer

15
Running Example for Secure Code Exchange -
Receiver

• 1) If the code is executed without Security
  Manager, then there is no problem.
• 2) However if you run the application with the
  Security Manager then we'd get an
  AccessControlException
• java -Djava.security.manager -cp sCount.jar Count
  c/hut/security/java/data/data.txt
• 3) Before setting the Policy files, we will have
  to import the certificate of the sender (person
  who has signed the code) and store it into the
  key repository

16
Running Example for Secure Code Exchange -
Receiver(contd.)

• keytool -import -alias sunesh -file Sunesh.cer
  -keystore receiverstore
• 4) You might want to verify if the certificate
  received is unmodified by comparing the finger
  prints. The sender can check the finger prints of
  his certificate by.
• keytool -printcert -file Sunesh.cer
• 5) Set up the policy file
• 6) Run the signed code
• java -Djava.security.manager -Djava.security.polic
  yreceiverPolicy -cp sCount.jar Count
  c/hut/security/java/data/data.txt

17
Security in Java as a Language

• The Java language compiler and run-time system
  implement several layers of defense against
  potentially incorrect code.
• The environment starts with the assumption that
  nothing is to be trusted, and proceeds
  accordingly.

18
Memory Allocation and Layout

• Java compiler's primary lines of defense.
• Memory layout decisions are not made by the Java
  language compiler, as they are in C and C.
  Rather, memory layout is deferred to run time,
  and will potentially differ depending on the
  characteristics of the hardware and software
  platforms on which the Java system executes.
• Secondly, Java does not have "pointers" in the
  traditional C and C sense.
• Java programmers can't forge pointers to memory,
  because the memory allocation and referencing
  model is completely opaque to the programmer.

19
The Byte Code Verification Process

• Because of the problem about the "hostile
  compiler", the Java run-time system doesn't trust
  the incoming code, but subjects it to bytecode
  verification.
• Verification includes checking if the format of a
  code fragment is correct, to passing each code
  fragment through a simple theorem prover to
  establish that it plays by the rules, like
• it doesn't forge pointers,
• it doesn't violate access restrictions,
• it accesses objects as what they are.

20
Byte Code verifier
21
Security Checks in the Bytecode Loader

• When a class is imported from across the network
  it is placed into the private name space
  associated with its origin.
• When a class references another class, it is
  first looked for in the name space for the local
  system , then in the name space of the
  referencing class. There is no way that an
  imported class can "spoof" a built-in class.
• Built-in classes can never accidentally
  reference classes in imported name spaces.
  Similarly, classes imported from different places
  are separated from each other.

22
Byte Code verifier (contd.)

• The important point is that the Java bytecode
  loader and the bytecode verifier make no
  assumptions about the primary source of the
  bytecode stream.
• Once the verification is done, a number of
  important properties are known
• There are no operand stack overflows or
  underflows
• The types of the parameters of all bytecode
  instructions are known to always be correct
• Object field accesses are known to be
  legal--private, public, or protected.

23
Security in the Java Networking Package

• Java's networking package provides the interfaces
  to handle the various network protocols.
• The networking package can be set up with
  configurable levels of paranoia. You can
• Disallow all network accesses
• Allow network accesses to only the hosts from
  which the code was imported
• Allow network accesses only outside the firewall
  if the code came from outside
• Allow all network accesses

24
References

• 1http//java.sun.com/docs/books/tutorial/securit
  y1.2/TOC.html
• 2http//java.sun.com/j2se/1.4/docs/guide/securit
  y/
• 3 http//java.sun.com/security/
• 4 http//sunsite.ee/java/whitepaper/java-whitepa
  per-8.html