UNIT 8: SECURITY Lecture-36 Topic: (i) Introduction of Security (ii)Class Loaders (i)Introduction of security:we're going to be concerned primarily with

how Java operates on things that are in memory on a particular machine. Within a Java program, every entity--that is, every object reference and every primitive data element--has an access level associated with it. To review, this access level may be: private: The entity can only be accessed by code that is contained within the class that defines the entity. Default (or package): The entity can be accessed by code that is contained within the class that defines the entity, or by a class that is contained in the same package as the class that defines the entity. protected: The entity can only be accessed by code that is contained within the class that defines the entity, by classes within the same package as the defining class, or by a subclass of the defining class. public: The entity can be accessed by code in any class.

(ii) Class Loader: Java compiler converts source into the machine language of a hypothetical machine, called the v i r t u a l m a c h i n e . The virtual machine code is stored in a class file with a . class extension. Each class file contains the definition and implementation code for one class or interface. These class files must be interpreted by a program that can translate the instruction set of the virtual machine into the machine language of the target machine. Note that the virtual machine loads only those class files that are needed for the execution of a program. For example, suppose program execution starts with MyProgram. class. Here are the steps that the virtual machine carries out. 1 . The virtual machine has a mechanism for loading class files, for example, by reading the files from disk or by requesting them from the Web; it uses this mechanism to load the contents of the MyProgram class file. 2. If the MyProgram class has instance variables or superclasses of another class type, these class files are loaded as well. (The process of loading all the classes that a given class depends on is called r e s o l v i n g the class.) 3. The virtual machine then executes the main method in MyProgram (which is static, so no instance of a class needs to be created). 4. If the main method or a method that main calls requires additional classes, these are loaded next.

Class loaders have a p a r e n t / c h i l d relationship. Every class loader except for the bootstrap class loader has a parent class loader. A class loader is supposed to give its

parent a chance to load any given class and only load it if the parent has failed. For example, when the system class loader is asked to load a system class (say, j ava. util. ArrayList), then it first asks the extension class loader. That class loader first asks the bootstrap class loader. The bootstrap class loader finds and loads the class in rt. j ar, and neither of the other class loaders searches any further.

Lecture-37 Topic:Bytecode Verification

The Bytecode Verifier Okay, the compiler has produced a Java program for us, and we're about to run the Java bytecode of that program. But if the program came from an unknown source, how do we know that the bytecodes we've received are actually legal? Bytecode Verification of Other Languages Throughout this section, we're discussing the bytecode verifier as if it were tied to the Java language. This is somewhat imprecise: the bytecode verifier is actually independent of the original source language of the program. If we had a C++ compiler that generated Java bytecodes from C++ source, the bytecode verifier would still be able to verify (or not) the bytecodes. Class Definition public class CreditCard { public String acctNo = "0001 0002 0003 0004"; } public class Test { public static void main(String args[]) { CreditCard cc = new CreditCard(); System.out.println("Your account number is " + cc.acctNo); } } The above example shows an innocent mistake, but a malicious programmer could use just this technique to produce illegal Java bytecodes. In order to modify the contents of a string, for example, all we need to do is: 1. Copy the java.lang.String source file into our CLASSPATH. 2. In the copy of the file, modify the definition of value--the private array that holds the actual characters of the string--to be public. 3. Compile this modified class, and replace the String.class file in the JDK. 4. Compile some new code against this modified version of the String class. The new code could include something like this:

Inside the bytecode verifier: The bytecode verifier is an internal part of the Java virtual machine and has no interface: programmers cannot access it and users cannot interact with it. The verifier automatically examines most bytecodes as they are built into class objects by the class loader of the virtual machine (see Figure 2-1). We'll give just a brief overview of how the bytecode verifier actually works

Lecture-38 Topic: (i)Security Managers (ii) Permissions

1. 2. 3. 4.

(i) Security Manager: The security manager can be considered a partnership between the Java API and the implementor of a specific Java application or of a specific Java-enabled browser. There is a class in the Java API called SecurityManager (java.lang.SecurityManager) which is the linchpin of this partnership--it provides the interface that the rest of the Java API uses to check whether particular operations are to be permitted. The essential algorithm the Java API uses to perform a potentially dangerous operation is always the same: The programmer makes a request of the Java API to perform an operation. The Java API asks the security manager if such an operation is allowable. If the security manager does not want to permit the operation, it throws an exception back to the Java API, which in turn throws it back to the user. Otherwise, the Java API completes the operation and returns normally.

(ii)Permissions The basic entity that the access controller operates on is a permission object--an instance of the Permission class (java.security.Permission). The Permission class itself is an abstract class that represents a particular operation. The nomenclature here is a little

misleading, because a permission object can reflect two things. When it is associated with a class (through a code source and a protection domain), a permission object represents an actual permission that has been granted to that class. Otherwise, a permission object allows us to ask if we have a specific permission. The Permission Class Permissions have three properties: A type All permissions carry a basic type that identifies what the permission pertains to. A permission object to access a file will have a type of FilePermission; an object to create a window will have a type of AWTPermission; permission to use the XYZ company payroll application would have a type of XYZPayrollPermission. A name All permissions have a name that identifies the specific object that a permission relates to. A FilePermission has a name that is the name of the file to be accessed; an AWTPermission to create a window has a name of showWindowWithoutWarningBanner; permission to access a particular employee's payroll record would have the name of that employee. Names are often based on wildcards, so that a single file permission object may represent permission to access several files, and so on. The name of a permission is fairly arbitrary. In the case of file permissions, the name is obviously the file. Actions Some permissions carry with them one or more actions. The presence of these actions is dependent upon the semantics of the specific type of permission. A file permission object has a list of actions that could include read, write, and delete; an XYZ payroll permission object could have a list of actions that includes view and update. On the other hand, a window permission does not have an action: you either have permission to create the window, or you don't. Actions can also be specified by wildcards.The terms used to specify a list of actions are also arbitrary and handled by convention. Permissions can serve two roles. They allow the Java API to negotiate access to several resources. Permissions of the Java API There are some standard permissions in the Java API, each of which is implemented as a class: 1. The FilePermission class (java.io.FilePermission) This class represents permissions for files. This class implements two wildcard patterns for filenames: an asterisk matches all files in a given directory, and a hyphen matches all files that reside in an entire directory hierarchy. Valid actions for file permissions are read, write, delete, and execute. File permissions must be constructed with their platform-specific name. Hence, /myclasses/xyz is a valid name for a file permission on a Unix system, but not on a Macintosh (where an equivalent name might be System Disk:myclasses:xyz). When these

strings are specified programmatically, they are not too difficult to construct (using the file separator property); when these strings need to be specified in an external file, an appropriate syntax must be used. 2.The SocketPermission class (java.net.SocketPermission) This class represents permissions to interact with network sockets. The name of a socket permission is hostname:port, where each component of the name may be specified by a wildcard. In particular, the hostname may be given as a hostname (possibly DNS qualified) or an IP address. The leftmost position of the hostname may be specified as an asterisk, such that the host piccolo.East.Sun.COM would be matched by each of these strings:

Lecture-39 Topic:Digital Signatures

Digital Signatures: applets were what started the craze over the Java platform. In practice, people discovered that although they could write animated applets like the famous nervous text applet, applets could not do a whole lot of useful stuff in the JDK 1 .0 security model. For example, because applets under JDK 1 .0 were so closely supervised, they couldn't do much good on a corporate intranet, even though relatively little risk attaches to executing an applet from your company's secure intranet. It quickly became clear to Sun that for applets to become truly useful, it was important for users to be able to assign d i f f e r e n t levels of security, depending on where the applet originated. If an applet comes from a trusted supplier and it has not been tampered with, the user of that applet can then decide whether to give the applet more privileges. This added control is now possible because of the applet-signing mechanism in Java 1.1 . To give more trust to an applet, we need to know two things: 1 . Where did the applet come from? 2. Was the code corrupted in transit? In the past 50 years, mathematicians and computer scientists have developed sophisticated algorithms for ensuring the integrity of data and for electronic signatures. The j ava. security packagehe second property consider the following message by the billionaire father: Uponmydeath,mypropertyshallbedividedequallyamongm ychildren;however,myson Georgeshallreceivenothing. That message has an SHA1 fingerprint of 2D 8B 35 F3 BF 49 CD B1 94 04 E0 66 21 2B 5E 57 70 49 E1 7E The distrustful father has deposited the message with one attorney and the fingerprint with another. Now, suppose George can bribe the lawyer holding the message. He wants to change the message so that Bill gets nothing. Of course, that changes the fingerprint to a completely different bit pattern: 2A 33 0B 4B B3 FE CC 1C 9D 5C 01 A7 09 51 0B 49 AC 8F 98 92 Can George find some other wording that matches the fingerprint? If he had been the proud owner of a billion computers from the time the Earth was formed, each computing a million messages a second, he would not yet have found a message he could substitute. A number of algorithms have been designed to compute these message digests. The Java programming language implements both SHA1 and MD5. The MessageDigest class is f a c t o r y for creating objects that encapsulate the fingerprinting algorithms. It has a static method, called getInstance, that returns an object of a class that extends the MessageDigest class.

Lecture-40 Topic: (i)Code Signing, (ii)Encryption

(i)Code Signing:one of the most important uses of authentication technology is signing executable programs. If you download a program, you are naturally concerned about damage that a program can do. For example, the program could have been infected by a virus. If you know where the code comes from a n d that it has not been tampered with since it left its origin, then your comfort level will be a lot higher than without this knowledge. In fact, if the program was also written in the Java programming language, you can then use this information to make a rational decision about what privileges you. eb server. However, no desktops need to be touched as the programs evolve. We think this is a reasonable scenario that can be an attractive alternative to deploying corporate applications on every desktop. In the second scenario, software vendors obtain certificates that are signed by certificate authoritiessuch as VeriSign. When an end user visits a web site that contains a signed applet, a pop-up dialog box identifies the software vendor and gives the end user two choices: to run the applet with full privileges or to confine it to the sandbox. However, system administrators can carry out these tasks in preparation for distributing intranet programs. Suppose ACME Software wants its users to run certain programs that require local file access, and it wants to deploy the program through a browser, as applets or web start applications. Because these programs cannot run inside the sandbox, ACME Software needs to install policy files on employee machines. As you saw earlier in this chapter, ACME could identify the applets by their code base. But that means that ACME would need to update the policy files each time the applet code is moved to a different web server.

(ii)Encription: one important cryptographic technique that is implemented in the Java security API, namely, authentication through digital signatures. A second important aspect of security is e n c r y p t i o n . When information is authenticated, the information itself is plainly visible. The digital signature merely verifies that the information has not been changed. In contrast, when information is encrypted, it is not visible. It can only be decrypted with a matching key. Authentication is sufficient for code signingthere is no need for hiding the code. However, encryption is necessary when applets or applications transfer confidential information, such as credit.

card numbers and other personal data. Until recently, patents and export controls have prevented many companies, including Sun, from offering strong encryption. Fortunately, export controls are now much less stringent, and the patent. once you have a cipher object, you initialize it by setting the mode and the key: int mode = . . . ; Key key = . . .; cipher.init(mode, key) ; The mode is one of Cipher.ENCRYPT_MODE Cipher.DECRYPT_MODE Cipher.WRAP_MODE Cipher.UNWRAP_MODE The wrap and unwrap modes encrypt one key with anothersee the next section for an example. Now you can repeatedly call the update method to encrypt blocks of data: int blockSize = cipher. getBlockSize() ; byte[] inBytes = new byte[blockSize] ; . . . // read inBytes int outputSize= cipher. getOutputSize(inLength) ; byte[] outBytes = new byte[ outputSize] ; int outLength = cipher. update(inBytes, 0, outputSize, outBytes) ; when you are done, you must call the doFinal method once. If a final block of input data is available (with fewer than blockSize bytes), then call outBytes = cipher. doFinal(inBytes, 0, inLength) ; If all input data have been encrypted, instead call outBytes = cipher. doFinal() ; The call to doFinal is necessary to carry out p a d d i n g.