Technical Stream Session 2: Security in Java RMI

1. Distributed Systems Technical Stream Session 2:Security in Java RMI CSC 253 Gordon Blair, François Taïani, Paul Grace, Phil Greenwood

2. Overview of the Session • Warning: Security is Hard • Security and Java RMI • RMI and Mobile Code • Java’s Sandboxing Mechanism • Class loaders • The bytecode verifier • The security manager • Authentication • Symmetric keys and challenge response protocol G. Blair/ F. Taiani

3. Application Today: what you need to know to start working with RMI. Special Security Lecture on Week 7 Middleware Libraries OS Warning: Security is Hard • The weakest link breaks it all • Having a armoured door is no use is your walls are of straw • And software complexity does not help • Having a secure system is a bit like making sure a cask does not leak ... • ... where the cask is made of stacked rings that do not necessarily fit G. Blair/ F. Taiani

4. Today Security and Java RMI • It’s possible to use RMI without any security • You must then distributed the necessary classes manually • (stubs, skeleton, clients, passed parameters, etc..) • But it is usually not advisable • Java won’t allow RMI code to be automatically distributed • Anybody sniffing the network can see what you are doing • Worse: Anybody can invoke your service • Either by using an appropriate Java client • Or by forging a request (never underestimate attackers!) • Three different problems, a wide range of possible solutions • Protection against malicious mobile code: sandboxing • Secure communication: encryption • Access control: authentication, domains, capacities, etc. G. Blair/ F. Taiani

5. implemented by ChatServerImpl.java javac Registry 1 chatServer, host:port ChatServerImpl.class rmic ChatServerImpl_Skel.class chatServer? 2 ChatServerImpl_Stub.class ChatServerImpl ChatServer ChatServer stub skel 3 RMI and Mobile Code • Why use mobile code in Java RMI? • To easily distributed stub and skeleton classes • Without mobile code: For each new service implementation ChatServer.java (interface) Client G. Blair/ F. Taiani

6. 1 chatServer, host:port, codebase:url stub 3 chatServer? 2 4 RMI and Mobile Code • The stub can directly be downloaded from an ad-hoc location • Must use -Djava.rmi.server.codebase=url option on the server • Dynamic stub deployment! ChatServer.java (interface) implemented by ChatServerImpl.java javac Registry url ChatServerImpl.class rmic ChatServerImpl_Skel.class ChatServerImpl_Stub.class Client ChatServerImpl ChatServer ChatServer stub skel G. Blair/ F. Taiani

7. Other Uses of Mobile Code • Same mechanism can be used to pass objects from client to server for which the server has no local implementation • The server dynamically download the object’s class from a remote location (specified by the client) • See SUN’s RMI on-line Tutorial for a step-by-step example http://java.sun.com/docs/books/tutorial/rmi/ • Also works from the server to the client for return parameters • But mobile code is a big security threat! • Malicious mobile code can compromise the server or the client • Java disallows mobile code unless sandboxing is activated G. Blair/ F. Taiani

8. Sandboxing • Goal of Sandboxing • Distinguish trusted from untrusted code and all hues in-between • Limit (“sandbox”) what untrusted code can do • Sandboxing in java is based on three components • the class loaders • the byte-code verifier • the security manager G. Blair/ F. Taiani

9. Class Loaders • All classes come from a class loader: • Local class loaders load local classes • A bootstrap class loader for system classes, a “system class loader” (misleading name!) for application classes... etc. • Non-local classes must be loaded by specialised loaders • In RMI remote classes are loaded by the RMIClassLoader • This happens transparently • Class loaders are essential for Java’s security • they tag classes according to where they come from • they can shield classes from different sources from one another • Each class loader creates its own implicit namespace • I.e. namespaces enable 2 classes “bar.com.foo” from different sources to execute in the same JVM • They provide a “birth certificate” to classes • Where from? Signed by whom? G. Blair/ F. Taiani

10. The Byte-Code Verifier • TheByte-Code Verifier checks the bytecode obtained by class loaders before it is allowed to execute • all classes are checked the first time they are loaded. The only exception are system classes (java.*, etc...). • the byte-code verifier is internal to the JVM, you can’t see it • simple checks: byte code format, valid instruction, ... • more complex checks: no stack overflow, data protection, ... • The byte-code verifier is the gatekeeper of the JVM boundary • Does not check your passport (comes later) • But checks whether you carry dangerous weapons • strange instruction, potential stack overflows, etc. G. Blair/ F. Taiani

11. The Security Manager (1) • The real enforcer of sandboxing • By default no security manager is active • No mobile code is allowed. Only local classes can be loaded. • Local classes can do everything (no sandbox) • To activate a security manager: • You can use a command line option when starting java:java -Djava.security.manager=RMISecurityManager MyProgram • Or you can set a security manager at the start of your program:if (System.getSecurityManager() == null) {System.setSecurityManager(new RMISecurityManager()); } • By default only one security manager can be set in the JVM’s lifetime • No point in a lock if it can be unscrewed easily G. Blair/ F. Taiani

12. The Security Manager (2) • The security manager protects potentially dangerous operations inside the JVM • file I/O,network access, creation of new class loaders, etc. SecurityException  untrusted code  not ok! Security Manager ok? dangerous operations JVM ok! operation’s implementation • Decision can be based on information about the code attempting the access (“birth certificate” from the class loaders) • Different types of sandboxes can be enforced simultaneously! G. Blair/ F. Taiani

13. The Security Manager (3) • The security manager is a bit like an internal police force • It enforces zones of different security levels inside the JVM • The JVM provides two security managers • java.lang.SecurityManager: The “default” security manager • java.rmi.RMISecurityManager: a specialised variant optimised for RMI • They do not allow any dangerous operations to anybody (even to the local application classes) • a security policy must be provided in a policy file to change this G. Blair/ F. Taiani

14. The Policy File (1) • Describes what is to be enforced • A bit like a code of law • Organised as a sequence of “grant” statements • Anything that is not allowed is forbidden! • Examples: • grant codeBase "http://ftaiani.ouvaton.org/*" { permission java.io.FilePermission "/tmp/*", "read"; permission java.io.SocketPermission "*", "connect";}; Allows code downloaded from http://ftaiani.ouvaton.org to read any file in tmp and to open any socket connection • grant { permission java.security.AllPermission; };Allows everything to everybody (only if you trust remote code!) G. Blair/ F. Taiani

15. The Policy File (2) • Is specified with -Djava.security.policy command line option • java -Djava.security.manager=RMISecurityManager \ -Djava.security.policy=myGrantAllPolicy myProgram • java -Djava.security.policy=myGrantAllPolicy myProgram • For coursework and practical sessions • Use a “grant all” policy (you will be the only one providing code) • Use a refined policy if you allow “third party” code in your application G. Blair/ F. Taiani

16. Authentication • To do the 1st coursework you will need to authenticate to an RMI server • Two ways of authentication will be offered • Password • Symmetric key • The password will use a very naive approach • Passwords will transit in clear text as RMI arguments • You will see how to do better in the security lecture • In the next few slides some explanation about the use of symmetric keys for authentication G. Blair/ F. Taiani

17. Authentication • A symmetric key allows you to encrypt and decrypt data with a symmetric encryption algorithm • We will use DES as algorithm (Data Encryption Standard) • until 2002 the encryption algorithm used by the American Government • DES provides two functions DES_encrypt and DES_decrypt to encrypt and decrypt data • DES_encrypt(myKey, “Hello There”)= 117:202:74:50:126:120:125:26: • DES_decrypt(myKey, 117:202:74:50:126:120:125:26)= “Hello There” • It is very hard (almost impossible) to get myKey or “Hello There” from the encrypted message • This can be used for authentication using a challenge-response protocol G. Blair/ F. Taiani

18. I would like to authenticate as Bill OK then encrypt number X with your key Here it is: DES_Encrypt(K[bill],X) Challenge/Response Protocol • Identify a user without exchanging the secret key • Requires the server to know all secret keys • Real applications use asymmetric keys to avoid this issue < Bill: K[bill]> K[bill] Y  DES_Encrypt(K[bill],X)DES_Decrypt(K[bill],Y)= X? yes  this can only be bill!  no  this is not bill!  authentication server client • X is the challenge. Used only once. • Sniffing DES_Encrypt(K[bill],X)is useless: X won’t be reused. G. Blair/ F. Taiani

19. Using DES with Java • Packages to use import javax.crypto.*; import javax.crypto.spec.*; • Converting a string into a DES SecretKey object DESKeySpecdesKeySpec = new DESKeySpec(“xjhg6sa8”.getBytes()); SecretKeyFactory keyFactory = SecretKeyFactory.getInstance("DES"); SecretKeyskey = keyFactory.generateSecret(desKeySpec); • Enciphering a string Cipher cipher = Cipher.getInstance("DES/ECB/PKCS5Padding"); cipher.init(Cipher.ENCRYPT_MODE, skey); byte[] encrypted = cipher.doFinal("Hello".getBytes()); • Deciphering cipher.init(Cipher.DECRYPT_MODE, skey); byte[] decrypted = cipher.doFinal(encrypted); String result = new String(decrypted) ; G. Blair/ F. Taiani

20. References • Securing Java: Getting Down to Business with Mobile Code 2nd Edition (Paperback) by Gary McGraw, Edward W. Felten, Wiley, 1999, available online at http://www.securingjava.com • SUN’s RMI on-line Tutorial • http://java.sun.com/docs/books/tutorial/rmi/ • Very well explained with a advanced example of code mobility • SUN’s Tutorial on Dynamic code downloading using RMI • http://java.sun.com/j2se/1.4.2/docs/guide/rmi/codebase.html • Further explanation of the use and meaning of code-bases G. Blair/ F. Taiani

21. Expected Learning Outcomes After this session • You should understand how mobile code works with RMI • You should have some basic understanding of the secutiy mechanisms used in the Java JVM • You should understand how a symmetric key is • You should know what a challenge response protocol is G. Blair/ F. Taiani