Security in Java Sunesh Kumra S-38.153 Security of Communication Protocols Helsinki University of...
-
Upload
wilfred-cameron -
Category
Documents
-
view
214 -
download
0
Transcript of Security in Java Sunesh Kumra S-38.153 Security of Communication Protocols Helsinki University of...
Security in Java
Sunesh Kumra S-38.153
Security of Communication Protocols
Helsinki University of Technology
Sunesh Kumra / Feb 25, 2003 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]
Sunesh Kumra / Feb 25, 2003 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.
Sunesh Kumra / Feb 25, 2003 4
JDK 1.0 Security Model (contd.)
Sunesh Kumra / Feb 25, 2003 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.
Sunesh Kumra / Feb 25, 2003 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.
Sunesh Kumra / Feb 25, 2003 7
Sample policy file keystore
"file:/c:/hut/security/java/receiverstore";
grant signedBy "sunesh" { permission java.io.FilePermission
"c:/hut/security/java/data/*", "read"; };
Sunesh Kumra / Feb 25, 2003 8
JDK 1.2 Security Model (contd.)
Sunesh Kumra / Feb 25, 2003 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
Sunesh Kumra / Feb 25, 2003 10
Cryptography Architecture Extensions (contd.)
Certificate factory support to generate certificates and certificate revocation lists (CRLs) from their encodings
Sunesh Kumra / Feb 25, 2003 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
Sunesh Kumra / Feb 25, 2003 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.
Sunesh Kumra / Feb 25, 2003 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
Sunesh Kumra / Feb 25, 2003 14
Running Example for Secure Code Exchange - Sender (contd.)
5) Export the Public Key Certificate keytool -export -keystore suneshstore -alias signFiles -file
Sunesh.cer
Sunesh Kumra / Feb 25, 2003 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
Sunesh Kumra / Feb 25, 2003 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.policy=receiverPolicy -cp sCount.jar Count c:/hut/security/java/data/data.txt
Sunesh Kumra / Feb 25, 2003 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.
Sunesh Kumra / Feb 25, 2003 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.
Sunesh Kumra / Feb 25, 2003 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.
Sunesh Kumra / Feb 25, 2003 20
Byte Code verifier
Sunesh Kumra / Feb 25, 2003 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.
Sunesh Kumra / Feb 25, 2003 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.
Sunesh Kumra / Feb 25, 2003 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
Sunesh Kumra / Feb 25, 2003 24
References [1]http://java.sun.com/docs/books/
tutorial/security1.2/TOC.html [2]http://java.sun.com/j2se/1.4/docs/
guide/security/ [3] http://java.sun.com/security/ [4]
http://sunsite.ee/java/whitepaper/java-whitepaper-8.html