1 / 24

Security in Java

Security in Java. Sunesh Kumra S-38.153 Security of Communication Protocols Helsinki University of Technology. 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]

payton
Download Presentation

Security in Java

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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] 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 Sunesh Kumra / Feb 25, 2003

More Related