1. 1 Lecture 5 George Koutsogiannakis/ Summer 2011 CS441 CURRENT TOPICS IN PROGRAMMING LANGUAGES

2. Applet Security Browsers act as sandboxes to Applets thus preventing the execution of system calls. We can defeat the security restrictions by making the applet ‘trusted code” via the usage of a certificate. 2

3. 3 APPLET SECURITY Using Certificates –Certificates are issued by a Certificate Authority (CA) i.e VeriSign provides digital certificates besides other services. –A certificate is normally issued to: Authenticate a server to a client Makes code passed to a receiver “trusted code”. –It provides information about the sender of the code.

4. Using Digital Signatures- Possible Scenario 4 Developer CodePrivate Key Signature Algorithm Signed Code Certification Authority Certificate Includes information About the developer and a public key that the user can use to verify the code. User Verified Code

5. Encryption Encryption is the process of taking data (called cleartext) and a sort String (called the key), and producing data (called ciphertext) that is meaningless to someone who does not know the key. Decryption is the inverse process of getting back the so called cleartext 5

6. Encryption Two forms: –Symmetric Encryption: The same key is used for encryption and decryption –Asymmetric Encryption: Two different keys used, one for encryption and the other for decryption. 6

7. Message Digest Message Digest is the application of a hashing function on a message to produce a file called the message digest file. Goal: ensures data integrity Hashing algorithms used: –SHA-1 (Secure Hashing Algorithm- 160 bits) –MD5 (uses 128 bit) – Note: Newer algorithms SHA-256 and SHA-512 provide 256 and 512 bits encryption 7

8. Security Scenarios-Using a Message Digest #1 Scenario –Bob wants to send a message to Mary – Bob hashes the message and sends the original message and the message digest to Mary. –Mary applies the same hashing function to the original message and creates her own message digest for the original message. –Mary compares the message digest received from Bob and the one she generated. –If the two message digests match then the message was received unaltered (ensures integrity). –PROBLEM: A third party captures the original message and the digest sent by Bob. Third party sends its own version of the message with the corresponding digest for it (provided it knows the hashing algorithm agreed between Bob and Mary) 8

9. Notice that there is not an unhashing process. In other words reversing the hashing process to get the original message back is not possible. 9 Security Scenarios-Using a Message Digest

10. Security Scenarios-Using Secret Key (symmetric encryption) #2 Scenario –Bob wants to send a message to Mary. Both Bob and Mary share a secret key. –Bob encrypts the message with the secret key. –Mary decrypts the message with the same secret key. –This is symmetric encryption and ensures that a third party can not read or alter the message. –The key must be sent to the parties over some secure channel. PROBLEM: There is no guarantee that the encrypted message came from Bob. Other parties can get hold of the secret key. 10

11. Security Scenarios-Using Secret Keys (asymmetric encryption). # 3 Scenario –Suppose that Mary wants to verify that the message came from Bob –Bob uses a private key to sign the data and create a digital signature. –Mary uses a public key which she uses to verify Bob ‘s digital signature. 11

12. Security Scenarios-Using Message Digest and Asymmetric Encryption #4 Scenario –Combine scenario #1 (message digest) with scenario #3. –It ensures privacy, integrity and authentication. 12

13. Security Scenarios-add SSL #5 scenario –Use scenario #4 plus –Apply SSL (Secure Socket Extension) Client uses server’s certificate stored in a trust store (keystore) to verify the server. Server uses keystore that has the server’ s private and public keys. Client create san instance of SSLSocketFactory and SSLSocket and specifies the server’ s name and port. 13

14. Security Scenarios-Another Assymmetric Approach # 6 scenario (asymmetric) –Bob encrypts message with Mary’ s public key. Sends message to Mary. –Mary decrypts the message with her private key. –Mary sends a response message to Bob by encrypting the message with Bob’s public key. –Bob decrypts the message with his private key. –Public keys can be sent to anybody. RSA is the most popular asymmetric cipher. 14

15. Secure Web Transaction Using Certificates-(Scenario # 4- slide 12) 15 ClientServer 1.CA sends certificate and policy file to client -Certificate is stored in client’s keystore (i.e. cacerts) -Client requests connection to a server /receives html file/ html file calls for applet. 2. Server sends applet to client (signed jar file) 3.Applet can execute system calls on the client’s host and communicate with the server (based on the fact that the jar file that has the applet is signed with the keys listed in the certificate).

16. Digital Signatures The idea is the reverse process of using public/private keys (asymmetric - i.e. Opposite of scenario #6). –Mary uses her private key to encrypt her message (or code). –Anybody who has Mary’ s public key can decrypt Mary’s message. This approach does not secure the integrity of the message. It just ensures that the message came from Mary (otherwise her public key will not be able to decrypt it). Problem: How do we know that the public key actually came from Mary? Maybe a third party pretends to be Mary and sends out a public key. Then, the third party sends a message encrypted with the third party’s private key pretending that the message is coming from Mary. 16

17. Digital Certificate Someone has to verify that the public key actually comes from Mary. 17 Mary CA Bob 1 2 3 1.Mary sends CA her public key. 2.CA verifies public key and creates certificate. Sends certificate to Mary. 3. CA sends to Bob a public key that allows the reading of the certificate.. 4 5

18. Digital Certificate 4. Mary sends message and certificate to Bob. Bob verifies CA’s signature using CA’s public key. Bob can now read Mary ‘s public key from the certificate and trust that the public key is actually Mary’s public key. 5.Bob can now encrypt his message (i.e. his credit card number) using Mary ‘s public key and send it to Mary. Suppose that a third party has interrupted step 4 (getting hold of the certificate) and intersected in the certificate their own public key and send it to Bob. Bob’s verification of the certificate will fail based on CA’s public key. 18

19. Digital Signatures- Sender 19 Original Document Digital Signature Hash Function Private key encryption

20. Digital Signatures- Receiver 20 Message Digital Signature Public Key Message Digest Apply Hash Function Message Digest Compare The 2 digests

21. Steps to Create Certificate Follow the following steps to create a certificate 1. Use the command below (from DOS) to genearate keys. Use a name as alias and make sure that you record it. If you forget it you will have to generate the certificate again C:\Myprograms >keytool –genkey –keyalg RSA –alias youralias Keytool asks for : Keystore password: Personal Information Alias Password: Make note of the passwords and alias you entered. 2.Now export the certificate information into a file named by you with the extension.cer >keytool –export –alias youralias –file MyCertificateName.cer Enter the keystore password from above when asked. The certificate file MyCertificate.cer will be created. 21

22. Steps to Create Certificate 3.Go to Program Files/Java/jdk1.6.0_23/jre/lib/security. Place the certificate file MycertificateName.cer in that directory. 4.Execute the following command in a DOS window in the security directory: >keytool –import –alias MyTrustedCertificate –keystore cacerts –file MyCertificateName.cer This command will import the information from the certificate to the default keystore cacerts Note that the alias in this command is not youralias generated at the beginning of this process but rather the default alias required by the default keystore. When prompted enter keystore password: changeit (Note that changeit is the password for default keystore cacerts located in the security directory of the jdk). NOTICE THAT CERTIFICATES ARE ONLY GOOD FOR 6 MONTHS!!! 22

23. Steps to Create Certificate 5.Jar the applet class (or multiple files) >jar cf MyApplet.jar *.class (you have to be in the same directory as the applet class) 6.Create the signed jar now >jarsigner –signedjar sMyApplet.jar MyApplet.jar youralias A new jar file will be created under the name sMyAppletclass.jar The system will ask you for the first password entered (keyword password) when you created the certificate and then for the second password entered when you created the certificate (step 1 from this procedure). Changes to the applet code do not require re-issuance of the certificate but the jar file and the signed jar file have to be regenerated 7.The jar file will have to be placed in the proper directory in the web server. 23

24. Steps to Create Certificate The html file that the client is going to use to call the applet will have to have the archive attribute in the applet tag: OR YOU COULD ADD A CODEBASE LIKE: Note: MyApplat.jar represents the signed version of the jar file that has the applet code. 24

25. Example Programs Message Digest Encrypt Decrypt Login Client and Login Server Create Keys 25

26. 26 USING JAKARTA TOMCAT –INSTALL TOMCAT –HOW TO CREATE A CONTEXT ROOT –STRUCTURE OF WEBAPPS CONTEXT ROOT FOLDER –DEPLOYING A NEW CONTEXT ROOT APPLICATION. –USING THE WEB SERVER LOCALHOST. –DEMONSTRATION OF USING AN APPLET IN A CONTEXT ROOT.

27. 27 DEPLOYING A CONTEXT ROOT FIRST MAKE SURE THAT YOUR JDK DOES NOT HAVE ANY SERVLET JAR FILES IN THE DIRECTORY /Program Files/Java/jdk1.5/jre/lib/ext –THERE IS A CONFLICT WITH TOMCAT’S SERVLET ENGINE IF YOU LEAVE THE SERVLET JAR FILE IN THAT DIRECTORY. –TEMPORARILY REMOVE THAT JAR FILE WHILE YOU NEED TOMCAT. REINSERT THE JAR FILE IN THE EXT FOLDER WHEN YOU ARE WRITING SERVLET PROGRAMS AND YOU NEED TO COMPILE THEM –NOTE: PROBABLY YOU DON’T HAVE THE SERVLET FILE IN YOUR EXT DIRECTORY IF YOU NEVER USED SERVLETS BEFORE.

28. 28 DEPLOYING A CONTEXT ROOT FOR AN APPLET CREATE A NEW FOLDER UNDER TOMCAT’S WEB APPS DIRECTORY. GIVE THE FOLDER THE NAME OF THE WEB APPLICATION THAT YOU WANT TO CREATE. THAT IS CALLED THE “CONTEXT ROOT”. CREATE A FOLDER CALLED WEB-INF INSIDE YOUR CONTEXT ROOT FOLDER. INSERT A SIMPLE WEB.XML FILE IN THE WEB-INF FOLDER. CREATE A FOLDER NAMED CLASSES IN THE WEB-INF FOLDER. LEAVE IT EMPTY FOR NOW. PLACE ALL HTML AND APPLET CLASSESS DIRECTLY UNDER THE CONTEXT ROOT FOLDER.

29. 29 DEPLOYING A CONTEXT ROOT FROM YOUR BROWSER CALL: –http://lacalhost:8080/manager/deploy?path = / name_of_context_roothttp://lacalhost:8080/manager/deploy?path –IF EVERYTHING IS OK THE RESPONSE SHOULD BE: OK DEPLOYED APPLICATION AT PATH /context_root_name FROM BROWSER CALL TO VERIFY THE STATUS OF ALL APPLICATIONS ON TOMCAT –http://localhost:8080/manager/statushttp://localhost:8080/manager/status –YOUR CONTEXT ROOT NAME YOU PROVIDED SHOULD SHOW UP AS RUNNING. YOU CAN STOP IT, UNDEPLOY IT AND REDEPLOY IT FROM THE STATUS SCREEN. SEE DOCUMENT TomcatDeployment.txt IN THE EXAMPLES PAGE OF THE COURSE’ S WEB SITE FOR MORE DETAILS.

30. DEPLOYING A CONTEXT ROOT Note: A more dependable way for deploying a web application is to use a war file. This is described in a document posted on the course’ s web site that describes how to deploy on Tomacat. 30

31. Study Guide Study security examples posted on the web site. Search Internet for information on Digital Certificates. Download Tomcat and its documentation. Read documentation package for installation and usage. Tomcat comes with help files also. 31