SECURITY ASSESSMENT ON THE ACADEMIC INFORMATION SYSTEM AND ARCHITECTURE DEVELOPMENT USING WEB SERVICE AT UNIVERSITY AL AZHAR INDONESIA

FINAL PROJECT In Partial Fulfillment of the Requirements for Bachelor of Engineering Degree in Electrical Engineering Studies

By: Marion Renaldo Rotensulu Electrical Engineering 0103505009

DEPARTMENT OF ELECTRICAL ENGINEERING UNIVERSITY Al AZHAR INDONESIA JAKARTA 2009

LETTER OF THESIS AGREEMENT

Thesis Title

: Security Assessment on The Academic Information System and Architecture Development Using Web Service at University Al Azhar Indonesia.

Name NIM Major Date

: Marion Renaldo Rotensulu : 0103505009 : Electrical Engineering : 26th August 2009

Approved By:

Thesis Advisor

(Dr. Ade Jamal)

Head of Elecrtical Engineering Department

(Dr. Ary Syahriar, DIC)

LETTER OF THESIS CONFIRMATION

Thesis Title

: Security Assessment on The Academic Information System and Architecture Development Using Web Service at University Al Azhar Indonesia.

Name NIM Major Date

: Marion Renaldo Rotensulu : 0103505009 : Electrical Engineering : 26th August 2009

Approved By:

Examiner I

: Ir. Endang Ripmiatin, MT.

: _____________Date: _______

Examiner II

: Ikhwan Zarkasi, M.Sc.

: _____________Date: _______

Examiner III

: Anto Satriyo Nugroho, Dr.Eng. : _____________Date: _______

Thesis Advisor

: Dr. Ade Jamal

: _____________Date: _______

ii

DECLARATION OF AUTHORSHIP

I am, Name : Marion Renaldo Rotensulu NIM : 0103505009

Major : Electrical Engineering

Declare that the thesis with the title:

Security Assessment on The Academic Information System and Architecture Development Using Web Service at University Al Azhar Indonesia

and the works presented in it are my own. I confirm that the thesis is based on work done by myself jointly with others; I have made clearly what was done by others and what I have contributed myself. Jakarta, June 29th 2009

( Marion Renaldo Rotensulu )

iii

ACKNOWLEDGEMENTS

Assalamualaikum Wr. Wb.

Alhamdulillah, Allah has given me healthy and power until today to finish the undergraduate thesis as one of the requirements to complete the bachelor degree in major electrical engineering at University Al Azhar Indonesia with research topic is security assessment on academic information system and architecture development using web service at University Al azhar Indonesia. I dont forget to say sholawat and Salam to our last prophet and Rasul Nabi Muhammad SAW.

I would like to thanks to all people who help and guide me during the settlement of my Undergraduate Theses to: 1. Prof. Dr. Zuhal, M.Sc.EE as the Rector of University Al Azhar Indonesia for giving me the opportunity to carry out my undergraduate studies, as well as for the opportunity to be granted scholarship to complete my study in the field of electrical engineering. It has given me precious opportunities to meet many brilliant peoples during my study. 2. Dr. Ary Syahriar, DIC as our Head of Electrical Engineering Department has given chance to finish my undergraduate theses until the end of this academic year. 3. Dr. Ade Jamal as my theses advisor who has given his time and direction to me during my process to finish my project. 4. Mrs. Dina Nurul Fitria who has helped me to correct my theses scripts and UML Diagram. 5. My Mom and Dad who has give me spirit, support and invocation. Insya

Allah, Allah will always give his rahmat and hidayah to them. 6. Rifa Nurrizqi Djuuna who has given me a spirit, support, invocation and accompanied authors during fulfillment this undergraduate theses every day. iv

7.

Yan Yonathan Rotinsulu (Authors Brother) who has given me a spirit and support to authors during the fulfillment these theses.

8.

Zulkarnaen Arsi, Bobby Khrisna (GenID), Gunawan W. Tangahu (GenID), Tri Wahyudi (GenID), Iwan Setiawan (GenID), Akbar Putra Baculu (IF 2006 Student at Northern Malaysia University), Angga Aditya Praswara(IF 2006 Student at Northern Malaysia University), Disra Agifral (EL UAI 2005), Faisal Hardi (IF UAI 2005) and Desmiansah (IF UAI 2005) as my sharing partner to find a solution at this research project.

9.

Magdalena Baga, M.Si. and Arief Monarfa, ST who has lent me their computer during this research project.

10. My entire friends in Engineering Faculty UAI 2002, 2003, 2005, 2006, 2007, and 2008 wherever you are and whatever you do.

I believe there are many paucities on this research, therefore I hope some inputs and advises from a lot of parties to get the improvement in the future. This research is expected to bring some benefits especially for writer and generally for the readers, and could bring new discussions especially on the research improvement.

Wassalamualaikum Wr. Wb. Jakarta, 9th August 2009 Author,

Marion Renaldo Rotensulu

TABLE OF CONTENTS
ACKNOWLEDGEMENTS.................................................................................. iv TABLE OF CONTENTS...................................................................................... vi LIST OF FIGURES .............................................................................................. ix LIST OF TABLES ................................................................................................ xi ABSTRAK ............................................................................................................. xii CHAPTER I BACKGROUND ............................................................................ 1 1.1. 1.2. 1.3. 1.4. 1.5. 1.6. Background............................................................................................. 1 Problem Statement .................................................................................. 2 Objective................................................................................................. 2 Scope ...................................................................................................... 2 Writing Systemacy ................................................................................. 2 Research Methodology ........................................................................... 4

CHAPTER II BASIC THEORY ......................................................................... 5 2.1. 2.1.1. 2.1.2. 2.1.3. 2.1.3.1. 2.1.3.2. 2.1.3.3. 2.1.3.4. 2.2. 2.2.1. 2.2.2. 2.2.3. 2.2.4. 2.2.5. 2.2.6. Web Service ............................................................................................ 5 Definition of Web Service ...................................................................... 5 Concept and Usability of Web Service................................................... 5 Components of Web Service .................................................................. 7 Extensible Markup Language ................................................................. 7 Simple Object Access Protocol .............................................................. 8 Web Service Description Language ....................................................... 9 Universal Description, Discovery, and Integration ................................ 9 Open System Interconnection (OSI) Model ........................................... 9 Physical Layer ........................................................................................ 10 Data Link Layer ...................................................................................... 10 Network Layer ........................................................................................ 11 Transport Layer ...................................................................................... 11 Session Layer.......................................................................................... 11 Presentation Layer .................................................................................. 12 vi

2.2.7. 2.3. 2.3.1. 2.3.2. 2.3.3. 2.3.4. 2.4. 2.4.1. 2.4.2. 2.4.3. 2.5. 2.5.1. 2.5.2. 2.5.2.1. 2.5.2.2. 2.5.3.

Application Layer ................................................................................... 12 Representational State Transfer .............................................................. 12 Definition ................................................................................................ 12 Concepts ................................................................................................. 13 Characteristics ........................................................................................ 14 Principles ................................................................................................ 15 Remote Procedure Call(RPC) ................................................................. 16 Basic RPC Operation .............................................................................. 16 Passing Parameter ................................................................................... 17 Extended RPC Model ............................................................................. 17 Security and Encryption ......................................................................... 19 Hypertext Transfer Protocol Secure (HTTPS) ....................................... 19 Encryption .............................................................................................. 19 Symmetric Key Algorithm ..................................................................... 19 Asymmetric Key Algorithm ................................................................... 23 Firewall ................................................................................................... 24

CHAPTER III ANALYSIS AND DESIGN ........................................................ 26 3.1. 3.1.1. 3.1.1.1. 3.1.1.2. 3.1.2. 3.1.3. 3.1.4. 3.2. 3.2.1. 3.2.2. 3.3. 3.4. 3.4.1. 3.4.2.

Web Service Technology Selection ........................................................ 26 Strength and Weakness ........................................................................... 26 Strength................................................................................................... 26 Weakness ................................................................................................ 27 Principles Comparison ............................................................................ 27 Conceptual Comparison ......................................................................... 28 Technology Comparison......................................................................... 30 Existing Academic Information System ................................................. 32 Existing Architecture .............................................................................. 32 Existing Security..................................................................................... 33 Propose System Architecture.................................................................. 34 Security ................................................................................................... 35 Authentication ........................................................................................ 36 Confidentiality ........................................................................................ 38 vii

3.4.2.1. 3.4.2.2. 3.5. 3.5.1. 3.5.2. 3.5.3.

Selecting Encryption/Decryption Method .............................................. 38 AES Work............................................................................................... 39 System Design ........................................................................................ 40 Registering ApplicationID ...................................................................... 40 Authentication Process ........................................................................... 41 Getting Information ................................................................................ 44

CHAPTER IV TESTING AND IMPLEMENTATION .................................... 49 4.1. 4.2. 4.3. 4.3.1. 4.3.1.1. 4.3.1.2. 4.3.2. 4.3.3. 4.3.3.1. 4.3.3.2. 4.3.3.3. System Environment............................................................................... 49 Limitation of Implementation ................................................................. 49 Implementation Process.......................................................................... 50 Implementation of Encryption/Decryption ............................................. 50 Client ...................................................................................................... 50 Server ...................................................................................................... 51 Implementation of Web Service ............................................................. 52 Testing .................................................................................................... 53 Encryption/Decryption Test Function .................................................... 53 SIN Request Client To Re-authenticate Test .......................................... 56 Response Time of New Architecture to Give Information Test ............. 57

4.3.3.3.1. Testing at Local Computer ..................................................................... 59 4.3.3.3.2. Testing at Real Environment .................................................................. 59 CHAPTER V CONCLUSIONS AND RECOMMENDATIONS ..................... 62 5.1. 5.2. Conclusions ............................................................................................ 62 Recommendations .................................................................................. 64

REFERENCES ...................................................................................................... 65 BIBLIOGRAPHY ................................................................................................. 66 APPENDIX A-1 - LIST OF FUNCTION IN ENCRYPTION CLIENT LIBRARY .............................................................................................. 68 APPENDIX A-2 - LIST OF FUNCTION IN ENCRYPTION SERVER LIBRARY .............................................................................................. 69 APPENDIX B - AUTHENTICATION SERVICE ............................................. 70 APPENDIX C - CONFIRMATION STATUS.................................................... 71 viii

APPENDIX D - SOAP REQUEST AND RESPONSE FORMAT ................... 72 APPENDIX E - APPLICATION PROGRAMMING INTERFACE ............... 74

ix

LIST OF FIGURES
Figure 2.1. Service accessed by various types of applications ............................... 6 Figure 2.2. Web Service as "Bridge" ...................................................................... 6 Figure 2.3. Request and Response process using SOAP ........................................ 8 Figure 2.4. SOAP Document Schema ..................................................................... 8 Figure 2.5. Layers, interfaces, and protocols in the OSI model .............................. 10 Figure 2.6. Block Diagram of DES ......................................................................... 20 Figure 2.7(a). 3DES Encryption Diagram Using two keys ..................................... 21 Figure 2.7(b). 3DES Encryption Diagram Using three keys .................................. 21 Figure 2.8(a). Diagram of Encryption Process Using AES .................................... 23 Figure 2.8(b). Diagram of Decryption Process Using AES .................................... 23 Figure 2.9. Packet Filtering Firewall....................................................................... 25 Figure 2.10. Application Layer Firewall ................................................................. 25 Figure 2.11. Circuit Level Firewall ......................................................................... 25 Figure 3.1. Design of New SIA Architecture.......................................................... 32 Figure 3.2. Detailed Design of Security at New SIA Architecture ......................... 33 Figure 3.3. Diagram of MEZO................................................................................ 34 Figure 3.4. Registering ApplicationID .................................................................... 37 Figure 3.5. Authentication Process ......................................................................... 38 Figure 3.6. Send ApplicationID/AppID .................................................................. 39 Figure 3.7. Get RegisterID/RegID .......................................................................... 40 Figure 3.8. Receive RegisterID/RegID and TransactionKey/TransactKey ............ 40 Figure 3.9. Use Case Diagram of Getting Information ........................................... 41 Figure 3.10. Send RegisterID/RegID and Data ....................................................... 42 Figure 3.11. Receive RegisterID/RegID and Data .................................................. 43 Figure 3.12. Validate RegisterID ............................................................................ 43 Figure 3.13. Send Session Flag/SessFlag. Encryption Flag/Enc Flag and Information ................................................................................................................................. 44

Figure 3.14. Receive Session Flag/SessFlag. Encryption Flag/Enc Flag and Information.............................................................................................................. 45 Figure 4.1. Application has re-authenticated .......................................................... 51 Figure 4.2. Chart of response time for JAVA vs. PHP for getting information from SIN Server at local environment ............................................................................. 60 Figure 4.3. Chart of response time for JAVA vs. PHP for getting information from SIN Server at real environment ............................................................................... 61

xi

LIST OF TABLES
Table 2.1. Number of Rounds at AES .................................................................... 22 Table 3.1. Principal Comparison Summary ............................................................ 27 Table 3.2. Conceptual Comparison Summary ........................................................ 29 Table 3.3. Technology Comparison Summary ....................................................... 30 Table 3.4. Definition of Actors Process Registering ApplicationID ...................... 38 Table 3.5. Definition of Use Case Process Registering ApplicationID .................. 38 Table 3.6. Use Case Definition of Client Application at Authentication Process .. 38 Table 3.7. Use Case Definition of Security Server at Authentication Process ....... 39 Table 3.8. Use Case Definition of client Application for Getting Information ...... 41 Table 3.9. Use Case Definition of Client Application for Getting Information ..... 42 Table 3.10. Use Case of Security Server for Getting Information .......................... 42 Table 4.1. Specification and tools is used at development environment ................ 46 Table 4.2. Name of encryption and decryption library ........................................... 47 Table 4.3. Name of methods Encryption and Decryption at Security Library Client Side.......................................................................................................................... 48 Table 4.4. Name of methods Encryption and Decryption at Security Library Server Side.......................................................................................................................... 49 Table 4.5. Name of methods Encryption and Decryption at Security Library Server Side.......................................................................................................................... 50 Table 4.6. Result of Testing getting Information from SIN Server at Local Computer ................................................................................................................................. 53 Table 4.7. Result of Testing getting Information from SIN Server at Real Environment ............................................................................................................ 53

xii

ABSTRACT
Academic Information System (SIA) University of Al Azhar Indonesia (UAI) at this time only uses client-server (two tier system). The existing system is difficult to be expanded if it will be developed to multi-tier systems. However, UAI would like to integrate all of information systems there have. Based on these problems, it needs to design a new architecture which is capable to handle drawbacks of the existing problems. One of the solutions is by using web service systems. Web Service is decided to use on the new architecture, due to the ease in the process of data exchange and integrate the system. In the new architecture, security aspect is going to get more attention especially to guarantee the authentications and confidentiality aspects. Authentication process is designed as an authentications system is called MEZO. To guarantee the confidentiality aspect of information is used Advanced Encryption Standard (AES) as symmetric key encryption/decryption technology.

Key Words: Academic Information Systems, Web service, Integrity, Interoperability, Secure.

xiii

CHAPTER I BACKGROUND
1.1. Background University Al Azhar Indonesia has implemented Academic Information System (AIS), which consists of modules such as, Study Plan Card, Time Table, and Study Result Card. The existing AIS have been developed based on client-server system, which make the existing system rigid to be improved and extended. In order to improve the client-server system to a multi tier system, it is compulsory to plan a new architecture. Furthermore it is important to pay more attention on security of the system, because the current architecture is unreliable in the sense of security. Objective of this work is to improve quality of information service and reliability of the system to keep the validity of data when the migration occurred. Furthermore, improvement in accessibility and adaptability of future change is also desired. In Network security planning, it is compulsory for the architect to conduct a trade-off between user comfortability and the level of the security asked. The solution architecture approach for decrease the gap between comfortability is always equal with the reverse of security. The new architecture that will be implemented in University Al Azhar Indonesia will use Web Services as the middleware for data exchange. Furthermore, this system has to be able to keep the validity of data and the security of central database while transactions occur.

1.2. Problem Statement Based on the background which we have mentioned above, there are some problems that will be discussed in this thesis. The main problem is how the academic information system in University Al Azhar Indonesia can have wide range of access (at Cell phone, Web, Desktop Application, etc), easy to expand, while the data security is kept safely. This problem can be specified into 2 specific problems: 1. How to improve the current AIS of University Al Azhar Indonesia? 2. What is the security design of the new architecture of AIS?

1.3. Objective The objective of this work is to produce a new architecture which able to guarantee the security of transaction and easy to expand in future.

1.4. Scope These are the boundaries that going to be the guidelines in this thesis: 1. Network Design and Securing Data Technique during transaction that going to be implemented in AIS. 2. The development of security library web services will serve for study final result information only.

1.5. Writing Systemacy The systemacy of writing this thesis is going to be as follows: Chapter I: Background Consist of problem background, problem statement, research objective, and writing systemacy. Chapter II: Principles Consist of principles that support the development of new architecture of AISK of University Al Azhar Indonesia, involve OSI Layer, Web Service as the protocol that going to be used and the System Security in Internetwork.

Chapter III: Analysis and Design Consist of analysis and design of the architecture of AISK that able to guarantee the security of data while transaction. Analysis will involve a general system description, architecture of academic information system that being developed, system requirements, library requirements and system protocol, and analysis of the security that going to be implemented. Result of the analysis will be used as the resources for designing the new architecture of AIS. Analysis and design of the system shall use object oriented method with Unified Modelling Language (UML) tool. Chapter IV: Implementation and Testing This chapter will talk all about the implementation and testing of the system that produced based on the analysis and design in the chapter III. Chapter V: Conclusion and Future Work Consist of the conclusion of the thesis and the future work that has to be studied and developed based on the implementation of this thesis.

1.6. Research Methodology 1. Literature Study: Read and Learn all information resource (textbook, journal, paper, article, etc) which is correlated with Web Service and AIS Development. 2. Analyze standard communication protocols used by web services for AIS. 3. Produce a new architecture of AIS that have wide range accessibility. 4. Plan a security system of AIS that can guarantee the security of transaction. 5. Implement the new architecture in a testing environment simulating current running AIS. 6. Test and debug the new architecture.

CHAPTER II BASIC THEORY

In this chapter basic theory will be discussed. There are explanation of Web Service, Representational State Transfer (Rest), Remote Procedure Call, OSI Layer, and Information System Security.

2.1. Web Service (WS) Explanation about web service is including the definition of web service, concept and usability of web service and explanation about several supporting components of web service.

2.1.1. Definition of Web Service Refer to World Wide Web Consortium (W3C), web service is software system that developed to support the interaction between machines through a network. Refer to Lucky, web service is an application that developed in order to be called/accessed by another application through either internet or intranet using XML as the message format [1].

2.1.2. Concept and Usability of Web Service Nowadays, hardware, operating system, application and programming language is various. This condition drives to the difficulties of data exchange between each hardware/software that using an application that builds upon different programming language and different platform. Web Service can solve these problems. Actually, web service is a collection of methods or function provided by server that can be called by client from a long distance. The calling/using of these functions can be done by application that builds upon every programming language and platform.
5

Figure 2. 1. Service accessed by various types of applications.

The usabilities of web service are as follow: a. Cross Platform. Web service makes the data exchange between different operation system possible. b. Language Independent. Web service can be accessed using wide range programming language. Web service that build upon PHP can be accessed by various language like PHP, JAVA, .net (dot Net), Delphi, etc. c. Bridge with database Web service can make an application independent on a database driver, kind of database used and what is the structure of the database. The application only needs to know which methods/functions that provided by web service to use its database facilities. By using web service, phonecell application that actually cannot possibly to connect to database can access it.
WEB SERVICE RESULT DATABASE QUERY

Method-1 Method-2 Method-n

RESPONSE

APPLICATION
REQUEST

Figure 2. 2. Web Service as "Bridge".

d. Exchange Data Process is easy. Web service can ease and accelerate the speed of data exchange without adapt the application and database used that consume more time, energy, and cost. As an example, there are two companies that separated by a very long distance and using a very different operation system and database. They want to exchange data. They can do it more efficiently by using web service. e. Re-use of application components By using web service, we do not need to write the same function/method for two different applications. As an example, academic information system in an academic institution will have a web application and mobile to view student grades. For that purposes, instead of writing two same functions for getting the same results, it is enough to write the view grades method on web service to fulfill the need of these two applications.

2.1.3. Components of Web Service Web service has supporting components that form basic building blocks of web service. Following is the explanation of these components.

2.1.3.1. Extensible Markup Language (XML) Extensible markup language (XML), known as XML, is an universal language for communicating and exchanging data. XML is one part of markup language. XML gives a freedom to its user on the definition of tags that going to be used by them. E.g.:
<mahasiswa> <nim>0103505009</nim> <nama>Marion Renaldo Rotinsulu</nama> </mahasiswa>

XML is platform independent, so the application that run on any platform can read the exchange data or information as long as that application can read the information between the XML tags. XML is chosen to be used in web service because the format of XML is text, so it is easy to transport by HTTP protocol.

2.1.3.2. Simple Object Access Protocol (SOAP) SOAP is a standard format of an XML document that used deals with the request&response process between web service and the calling application. SOAP request is produced by an application when it request something to web service. SOAP response is produces by WS server sent back to the requesting application.

Figure 2. 3. Request and Response process using SOAP.

SOAP has the standard document structure that formed by single SOAP Envelope. SOAP Envelope is divided as SOAP Header and SOAP Body. SOAP Header carries the additional information. SOAP Body carry the information that going to be exchange between the web service and application.

Figure 2. 4. SOAP document schema.

2.1.3.3. Web Service Description Language (WSDL) Web Service Description Language known as WSDL, is an XML document which provides detail information on methods that provided by web service. These details are parameters that needed to call the methods, data type that return by methods which called.

2.1.3.4. Universal Description, Discovery, and Integration (UDDI) Universal Description, Discovery and Integration, known as UDDI, is a directory service which used to register and trace the web service. UDDI is made so web service can be found and traced by user that wanted to use the web service.

2.2. Open System Interconnection(OSI) Model At 1977, International Standard Organization formed a committee to develop architecture which produce a standard model, called Open System Interconnection (OSI). This model also known as Seven Layers OSI. OSI model was constructed to make the system communicate openly. Open system communicate using the standard rules that rule the format, content, mean and message that exchanged. This rules also known as protocol. In OSI model, communication is divided into seven levels or layers like shown at figure 2.5. Those are Physical Layer, Data Link Layer, Network Layer, Transport Layer, Session Layer, Presentation Layer, and Application Layer. Each layer has their function.

10

Figure 2. 5. Layers, interfaces, and protocols in the OSI model

OSI protocol is not really popular at its development. But OSI Protocol is used as a basic for the development of internet, like TCP and IP that used widely nowadays. 2.2.1. Physical Layer Physical layer is the most basic for the entire network. Its function is to convert the exchange packet into machine language which known as bit.

2.2.2. Data Link Layer Data link layer main role is to convert several bit stream into the form of frame stream. There are a lot of methods that can be used to convert bits to frame, like character count, byte stuffing dan bit stuffing. Following is the explanation about three methods above. a. Character count, makes a frame determine the amount of character in one frame. The transmission fault can ruin this method b. Byte stuffing makes a frame by locate the byte with some pattern as a flag at the beginning and at the end of a frame. Byte of a flag at the beginning and the end is the same value. If there is a fault in transmission, receiver send which flag that has a problem to the sender, so the sender will re

11

send that frame. Problems arise when the transmitted data has a binary data like source code of a program or numbers with float type. Prevention of this problem is by locatinf the escape byte (empty byte, so the byte will be ignored) before the flag of the data. c. Bit stuffing method makes a framre by locating bit 0 if in the data, bit 1 is found 5 times in a row. Mechanism of Bit stuffing is actually the same with byte stuffing, which is by locatin escape byte before flag, that differentiate between data and flag. If there is no longer a synchronization between receiver and sender, just check the flag.

2.2.3. Network Layer Main role of network layer is to determine the best path to transmt the data from source to the destination [2]. Service that provided by this layer depends on transport connection that used, either connectionless or connectionoriented.

2.2.4. Transport Layer Main role of transport layer is providing a reliable connection to receive data from session layer. Data received will be segmented and given a list number in order to prevent a mistake while received. Transport layer also has to guarantee that the message transmitted is errorfree, in a row, no missing data and there is no duplication while sent/received. One protocol that operate in this layer is Transmission Control Protocol (TCP).

2.2.5. Session Layer Session layer main role is to manage the communication being held between applications and keep the communication still and synchronize. This layer provide 3(three) main service, there are [8]: a. Dialog Discipline: by using session layer, full duplex or half duplex is able to exist.

12

b. Grouping: session layer allow the transmitted data can be marked. These mark define the data owner. c. Recovery: session layer provide the mechanism of checkpoint. Checkpoint is really useful if there is a very big size of data is being transmitted. If the data is crashed, no need to transmit it from the start, its enough to transmit from the checkpoint.

2.2.6. Presentation Layer Presentation layer main role is to translate the exchanged data between systems. Usually, data being exchanged is not a random bits, it already has a certain format or syntax.

2.2.7. Application Layer Application layer contain several standard protocol such as http, smtp, ftp, etc. Application layer allow the application program work in the network by accessing OSI Environment [STA04]. Hypertext Transfer Protocol or usually called as http is an example of this standard protocol. Http constructed to manage the long distance webpage transmission. Nowadays, http also widely used by various systems that are not a web basic. Like RMI by JAVA which use http for request invocation to the remote objects [2].

2.3.

Representational State Transfer (REST) The explanation of Representational State Transfer (REST), include the definition, concept, characteristic, and the principles of REST.

2.3.1. Definition Representational State Transfer (REST) is a term which introduced by Roy T. Fielding in his Ph.D. dissertation, which explain the architecture style for distributed computing model. REST is constructed to give a brief picture of a good construction for a proper web application [3].

13

2.3.2. Concepts REST is formed by 3(three) words that represents the mechanism of this architecture itself, that are Representational, State, dan Transfer. To explain the connectivity each other of these three, let see the following case. Universitas al Azhar Indonesia provide student biography information resource. students To with get this number information we need we to just access type
http://www.uai.ac.id/mahasiswa/nim_mahasiswa or if we want the biography of

0103505009,

http://www.uai.ac.id/mahasiswa/0103505009 at the browser.

When we input this URI at some application (e.g. browser), the request process from client to server will be conducted. Request process is using HTTP GET. When the needed data is found, resource will be return to the client with the form that the client wanted in example xml or html format. These returned data along with the form is called Representation. If we give more attention, there is a level changing in the browsere itself, from the condition when the browser did not get the representation (assumed as the beginning point/zero condition) to the condition when the browser already get the representation from the server. This different condition is called state, and the moving form one state to another is called transfer. The development of REST is conducted in order to model an architecture which can help to understand how the web should be work, which furthermore will be the basic guide for web protocol standardization. Beside that, REST architecture also developed to minimize communication in the network (reduce bandwidth consuming). REST is just an architecture style, so it does not have standardization like SOAP or XML-RPC. So, if you want to use it in web service, it is necessary to get a proper knowledge about its architecture then implement it just like the

14

principals and characteristics of the REST itself. System which implemented the principals and characteristics of REST is called RESTful. RESTful doesnt need layer messaging like other systems such as SOAP or XML-RPC. SOAP or XML-RPC is need RPC Style to communicate each other. RESTful is a resource oriented system. Like the example of URI above, everyone can access information freely, no further security applied to the provided data. The REST system developer was already think about this problem and came out with several alternatives solutions, one of these is the implementation of basic access authentication or as known as htaccess in the IT environment. Examples of the implementation of htaccess are following: a. authentication header which sent by client
GET /books/underground HTTP/1.0 Host: tokobuku-gedex.com Authentication: Basic Z2VkZXg6YXNkZg==

b. response header from server if authtentication valid

HTTP/1.0 200 OK Server: Apache/2.2.8 (Win32) DAV/2 mod_autoindex_color PHP/5.2.5 Date: Mon, 21 Apr 2008 06:02:12 GMT Content-Type: text/html Content-Length: 10512 mod_ssl/2.2.8 OpenSSL/0.9.8g

Resource network system at REST actually can be implemented using several way, like secure http (https), data transmitted is encrypted so the key of application is needed to read the data (encryption method) or network security with using firewall to limit the methods from HTTP (GET,POST,PUT, and DELETE) that allowed to communicate with outer system. . 2.3.3. Characteristics Following are the characteristics of REST: Client-Server: pull-based interaction: using components to take a representation

15

Stateless: each request from client to server must contain all the information needed by server in order to understand the request, and request cannot use the server to memorize/save any context.

Cache: to increase the network efficiency, respon must be able to label data as cache or non-cache. Uniform interface: all the resources that able to access are through the usual interface (HTTP GET, POST, PUT, DELETE). Connected Representation resource: the representation of resources is connected, so the client can move from one state to another. Layered components: middleware like proxy server, cache server, gateway and et cetera can be assumed as components between client and resource to support the performance, security and etc.

2.3.4. Principles The following principles must be included in the system that is going to apply REST in its implementation: Key point in making a web services in some REST network (like web) is identify all the form of concepts which we want to expose as service. Makes an URI for each resource. Resource must be in noun, not verb. At this point, this is the difference between REST and RPC-style. For more explanation, take a look at example below. In order to get the resource of certain student, do not use URI like this:
http://www.uai.ac.id/mahasiswa/getMahasiswa?id=010305009

There is a verb (getMahasiswa) at URI above. Instead, Use noun like:

http://www.uai.ac.id/mahasiswa/0103505009

Group the resources based on the permission for client. Either client can just read (HTTP GET) or edit and delete (HTTP POST dan DELETE). All the resources that able to access by HTTP GET does not effect another resources. Resources just give resource representation, no modification in the resources itself.

There is no representation that contains all the information is not connected with other resources. Use the hyperlink in each resource

16

representation so client can get more detail information or another connected similar information. System is designed to provide the data segmentally. Do not provide all the information in one response document, but provide hyperlinks to get the further details. Describe the format of data response using scheme (DTD, W3C scheme, RelaxNG atau Schematron). For services that need a POST or PUT to edit the resources, provide the scheme to describe the response format. Explain how our service has to be executed using WDSL file or simple HTML document.

2.4. Remote Procedure Call (RPC) Most of the distributed system is work based on the message exchange. When a process in computer A call the process in computer B, calling process in computer A is stopped temporarily, and execution process is execute to the procedure which called at the computer B. information that moved from caller to callee is located in the parameters and the execution result is returned to the caller with procedure that handle the return of the execution result. All the processes just explaimed is called Remote Procedure Call or RPC. Remote Procedure Call has already being a de facto communication standard in distributed system [2]. Development of the RPC is based on the idea to make the RPC be the proccess which work on the local computer itself. In other word, procedure which called another procedure does not need to know that the procedure called is being executed at another computer.

2.4.1. Basic RPC Operation In RPC there are two terms, client stub and server stub. Client stub is a procedure that packaged the parameters which received from client local procedure in the form of message, then send to server to be executed. Server stub is a process that transformed the received message into the parameters, then send it to local procedure to be executed.

17

Simply, the mechanism of RPC is following [2]: 1. Client Procedure called the client stub. 2. Client stub package the message and call the local operation system. 3. Client operation system sent the operation remote/server system messages. 4. Server operation system send message to server stub. 5. Server stub unpackage the parameters and called the server. 6. Server executes and returned it to the server stub. 7. Server stub do the packaging message, call the server local operation system. 8. Server operation system sent the message in the form of execution result to clien operation system. 9. Client operation system returns the message to client stub. 10. Client stub do the unpackage message and returned it to the client.

2.4.2. Passing Parameter In the implementation of Remote Procedure Call, there is a process called passing parameter from client to server. This process needs a same message fomat which will be exchanged. In other words, between client and server there is a need of protocol. This protocol is known as RPC Protocol. The purpose of RPC protocol is to similar the format to prevent the mistaken representation data structure like integer, boolean, float, character, and et cetera. This also make the RPC can be done in two different machines so there will be no fault in understanding the parameter representation, in order to get the valid result.

2.4.3. Extended RPC Model RPC is developed into two types, Doors and Asynchronous RPC. This development is conducted to overcome the problems which along in the implementation of RPC. Following is a brief description of Doors dan Asynchronous RPC.

18

Door Door is a technique which allowed the RPC process to run on the same computer by using Interprocess Communication which along with the computer operation system. Main advantage of using door is allowed only one kind of mechanism, which known as procedured call. Unfortunately, to use this procedure, the application developer need to really understand either the calling door is conducted on same process in the same machine, different process on the same machine, or do the remote process.

Asynchronous RPC The mechanism of Remote Procedure Call (RPC) happened when client do the remote procedure, client will be blocked temporarily until received the reply as the result of the previous request. Obviously, thte mechanism like this is not effective. To make it effective, RPC provide the facility called asynchronous RPC. By using asynchronous RPC, server will send the reply soon as the RPC Request is received from client. erver dan will be executed shortly. By this, RPC client can send another request to server without waiting for the server to send the result of the previous request. For more explanation, the following figure will show how the client and server interact in Asynchronous RPC. The given Reply is in the form of acknowledge which notify that the RPC Request from client is received by

19

2.5. Security and Encryption 2.5.1. Hypertext Transfer Protocol Secure (HTTPS) HTTPS is a combination of the Hypertext Transfer Protocol and a Network Security Protocol. Generally, the network security protocol used is Secure Socket Layer (SSL) or Transport Layer Security (TLS). The stack protocol of HTTPS showed at Picture below.. HTTPS ensures two things: and

Authentication

confidentiality.

Authentication is process to ensure the client is being talked with the server as an authorized client. Confidentiality is process to guarantee the data has transported between client and server. To perform Authentication process, client must obtain a certificate has a digital signature from the guarantor (certificate authority). Certificate has some data, such as: company name, web address and public key, expire date. If all data on certificate has valid, the public key would be used by client to encrypt the data, and sent to server.

2.5.2. Encryption Encryption is process of transforming information (plaintext) into encrypted information (chipertext) with algorithm. Based on similarity keys, it has divided into 2(two): Symmetric key algorithm and asymmetric key algorithm. 2.5.2.1. Symmetric Key Algorithm Symmetric key algorithm mostly used in cryptography. The key to encrypt the message exactly identic with the key to decrypt it. In other words, the sender and receiver message, have an identic key. The problem is often found from using symmetric key is how to send the key to receiver. An example from symmetric algorithm is Data Encryption Standard (DES), Advanced Encryption Standard (AES), Encryption Standard (3DES), etc. Triple Data

20

1. Data Encryption Standard (DES) DES is an algorithm most widely used in the world. DES algorithm derived from Lucifer Algorithm by IBM. DES has been adopted by NIST (Nasional Institute of Standard and Tecnology) as the standard U.S Federal Information processing. The lack of DES lies at the length of key. Length of DES key is only 56 bits, so that it is vulnerable to brute force attacks. Globally, DES works with three steps: a. Plaintext Block permuted with initial permutation (IP). b. Next step is enciphering process. Result from Initial Permutation, enchipered until 16 times/rounds. Each round use difference internal key and it work using feistel network. c. The ciphertext is the result from enciphering process permuted with inversed inititial permutation matrix (IP-1). Block Digram of Data Encrypted Algorithm. Blok Plainteks

IP

Enciphering

IP-1

Blok Cipherteks
Figure 2.6. Block Diagram of DES.

2. Triple Data Encryption Standard (TDES) Triple Data Encryption Standard (TDES) is development from DES Algorithm. TDES algorithm is a DES algorithm was repeated 3 times. Sequence steps of the process are Encrypt-Decrypt-Encrypt (EDE). EDE

21

can be done by using 2 or 3 keys. Compared to DES, TDES more reliable to hold brute force attack. On TDES, we can use two keys or three keys for doing the process. If choose to use two keys, the key sequence to encrypt and decrypt is K1K2-K1 (has shown at Figure 2.7(A)). If we choose to use three keys, the key sequence to encrypt is K1-K2-K3 and the key sequence to decrypt is K3-K2-K1 (has shown at Figure 2.7(B)).

Figure 2.7(A).3DES Encryption Diagram Using two keys.

Figure 2.7(B). 3DES Encryption Diagram Using three keys.

3. Advanced Encryption Standard (AES) NIST create a contest to found a new encryption standard. They called it Advanced Encryption Standard (AES), where to close the lack of DES. The winner of this contest is Rijndael Algorithm, because it kept the equilibrium of security and flexibility. Rijndael algorithm use a number of rounds, where each round, use a different key is called round key. On AES, The block size is fixed at 128 bits, and the length of key must 128 bits, 192 bits or 256 bits.

22

Table 2.1. A Number of Rounds at AES

In the reality, there are only two variants of AES: AES-128 and AES-256. User rarely to use the key with length 192 bits [4]. Generally, Rijndael works with three steps : a. AddRoundkey: Joining plaintext and cipher key with XOR operand. This is an initial step. b. Rounding until Nr 1 times. At this step, each round will do : i. SubByte: a non-linear substitution step where each byte is replaced with another according to a lookup table (S-box table). ii. ShiftRows: a transposition step where each row of the state is shifted cyclically a certain number of steps. iii. MixColumns: a mixing operation which operates on the columns of the state, combining the four bytes in each column. iv. AddRoundKey: each byte of the state is combined with the round key; each round key is derived from the cipher key using a key schedule. c. Final Round : on this step, system will do: i. ByteSub. ii. ShiftRow. iii. AddRoundkey.

23

Figure 2.8(A). Diagram of Encryption Process Using AES.

Figure 2.8(B). Diagram of Decryption Process Using AES.

2.5.2.2. Asymmetric Key Algorithm Asymmetric Cryptography is an algorithm that use different key for encryption and decryption process. It usually called as a Public key cryptography system. The key for encryption a message is made public and anyone known but the key for decrypt the message only the authority person have it (private key). This algorithm is rarely used by people for encrypt the data, because the process for encrypt the data is running very slowly [5]. Usually this algorithm is used to encrypt the symmetric key will be exchanged [6]. One example algorithm that used this encryption method is RSA. 1. RSA. RSA come from three initials name of the inventors: Ron Riverst, Adi Shamir, and Lend Adleman [STA95, ref di baca di makalah aulia_report]. RSA algorithm has been classified into asymmetric cryptography category, because it has two different keys for encryption and decryption process. The security level on RSA algorithm lies in the difficulty to divide the large number (n) into prime factors(a and b).

24

The RSA algorithm involves three steps: key generation, encryption and decryption. RSA involves a public key and a private key. The public key can be known to everyone and is used for encrypting messages. Messages encrypted with the public key can only be decrypted using the private key. The keys for the RSA algorithm are generated the following way: 1. Choose two distinct prime numbers a and b 2. Compute n = ab. (n is used as the modulus for both the public and private keys) 3. Compute the totient () = (a-1)(b-1). 4. Choose an integer e such that 1 < e < , and e and share no factors other than 1 (i.e. e and are coprime), (e is released as the public key exponent) 5. Determine d (using modular arithmetic) which satisfies the congruence relation de 1(mod ). Result of this process is private key and public key. The public key used to encrypt the message with equation: C Me (mod n) To read the message using the private key with equation: M Cd (mod n) Notes : C = Ciphertext; M = Plaintext.

2.5.3. Firewall Firewall is a part of a computer system or network was designed to filtering information and blocking unauthorized access was come over internet connection to private network or computer system. Firewall can be hardware or software which is configured to permit, denying, and can be configured based on organization's security policy. Firewall has a several function, there is Regulate and Controll traffic of network; Authentication Access; and protect the resource on Private Network.

25

All messages entering or leaving the intranet pass through the firewall, which it will examines each message and blocks those that do not meet the specified security criteria. There are several types of firewall techniques: 1. Packet filter: Looks at each packet entering or leaving the network and accepts or rejects it based on user-defined rules. Packet filtering is fairly effective and transparent to users, but it is difficult to configure. In addition, it is susceptible to IP spoofing. 2. Application gateway: Applies security mechanisms to specific applications, such as FTP and Telnet servers. This is very effective, but can impose a performance degradation. 3. Circuit-level gateway: Applies security mechanisms when a TCP or UDP connection is established. Once the connection has been made, packets can flow between the hosts without further checking. 4. Proxy server: Intercepts all messages entering and leaving the network. The proxy server effectively hides the true network addresses.

Figure 2. 9. Packet Filtering Firewall

Figure 2. 10. Application Layer Firewall

Figure 2. 11 Circuit Level Firewall

CHAPTER III ANALYSIS AND DESIGN

In this chapter analysis and design of AIS architecture will be discussed. Analysis includes web serbice technology selection, system architecture, security, functional necessary and architectural limitation. The result will be used as reference at architecture design.

3.1.

Web Service Technology Selection In this section would be selected web service technology to be used. Web service technology has mostly used today is two: REST and SOAP. It would be selected one of two types of this web service technolgy. Selection is based on several factors: Strength and Weakness Analysis, Principle, Conceptual, and Technology. This selection is using a published paper with a title: RESTful Web Service vs. Big Web Services : Making the Right Architectural Decission by Cesare Pautasso, Olaf Zimmermann, and Frank Leyman.

3.1.1. Strength and Weakness In this section, the strength and weakness of SOAP and REST will be discussed. 3.1.1.1. Strength SOAP(Simple Object Access Protocol) SOAP message format has gained widespread adoption as the gateway technologies capable of delivering interoperability between heterogeneous middleware systems [7]. Advantage of SOAP is protocol transparency and independence. In protocol transparency, SOAP has a same message format that can be transported across a variety of middleware systems, which may rely on HTTP, but also on many other transports. In the indenpendece, SOAP has the quality of service (QoS) aspects such as encryption and reliable transfer can be made independent from the transports used along the path.
26

27

REST(Representational State Transfer) REST leverages existing well-known W3C/IETF standards (HTTP, XML, URI, MIME) and the necessary infrastructure has already become pervasive. HTTP clients and servers are available for all major programming languages and operating system/hardware platforms, and the default HTTP port 80 is commonly left open by default in most firewall configurations. Services can be built with minimal tooling. The effort required to build a client to a RESTful service is very small as developers can begin testing such services from an ordinary Web browser, without having to develop custom client-side software. Deploying a RESTful Web service is very similar to building a dynamic Web site. 3.1.1.2. Weakness SOAP(Simple Object Access Protocol) Interoperability problems can occur when, for instance, native data types and language constructs of the service implementation are present in its interface. This weakness can be mitigated by stating and enforcing certain design and coding guidelines such as contract-first development.

REST(Representational State Transfer) To implement a Restful Web Service, generally use 4 HTTP verbs: GET, PUT, POST, DELETE. In fact, proxies and firewalls may not always allow http connection that used any other verb except GET and POST. Thus, if want to use restful web services require additional development and testing effort.

3.1.2. Principles Comparison Table below summarizes the architectural principles comparison from RESTWS and SOAP-WS. The comparator in this section is Protocol Layering and Dealing with heteroginity system.
Table 3.1. Prinsipal Comparison Summary

No

Comparator

REST-WS

SOAP-WS

a. Protocol Layering a.1. HTTP as application-level protocol a.2. HTTP as transport-level protocol

28

b. Dealing with heteroginity b.1. Enterprise Computing Middleware In protocol layering, the architectural principles will clarifies the HTTP will be used as an application protocol or as a transport protocol. In the context of REST-WS, the HTTP is seen as the universal medium for publishing globally accessible information. In other words, HTTP is used as an application protocol. In the context of SOAP-WS, the HTTP is seen as the universal transport medium for messages, which are exchanged between web services endpoints of published application. In other words, HTTP protocol is used as a tunneling protocol to enable remote communication through firewalls. REST is a rather uniform client/server environment, where all components (client, server, and browser) speak at same protocol: HTTP. SOAP is originated from a more complex and heterogenous domain, the one of enterprise computing. The heteroginity addressed by SOAP standardization efforts goes beyond the synchronous client/server protocols used in specific RPC middleware products.

3.1.3. Conceptual Comparison Table below summarizes the architectural conceptual comparison of RESTWS and SOAP-WS. The comparator in this section is Integration Style, Contract Design, Resource Identification, Resource Interaction Semantics, Resource Relationship, Data Representation and Message Exchange Patterns.
Table 3.2. Conceptual Comparison Summary.

No

Comparator

REST-WS

SOAP-WS

a. Integration Style a.1. Remote Procedure Call a.2. Messaging Bus b. Contract Design b.1. Contract First b.2. Contract Last b.3. Contract Less c. Resource Identification c.1. Do-it-yourself d. Resource Interaction Semantics

29

d.1. POST d.2. GET d.3. PUT d.4. DELETE e. Resource Relationship e.1. Do-it-yourself f. Data Representation/Modeling f.1. XML Schema f.2. Do-it-yourself g. Message Exchange Patterns g.1. Request-Response g.2. One-way Many types of integration style such as Remote Procedure Call, Messaging, etc. On REST-WS only Remote Procedure Call can be used as Integration Style. However, SOAP can be used remote procedure call and messaging as the integration style. In contract design, has a 3 (three) types of contract: Contract-first, Contractlast, and Contract-less. Contract-first prescribes to begin the development of a service from the specification of its interface. Contract-last, when an existing service implementation is published with an automatically generated contract. Contract-less apparently no decision has to be made concerning what are the available operations. To develop a web service using SOAP-WS, it is need have a contract, contract-first or contract-last. Whereas, to develop a web service using RESTful-WS, it is not need a contract (contract-less). In resource identification we talk about what are the resource abstractions exposing an application as a web service? In resource interaction semantics, want to decide which of the 4(four) verbs are applicable to the resource. Generally, this decision can be constrained by distinguishing whether accessing a resource is a read-only operation, input operation, update operation or delete operation. On RESTful web service a right design will use four verbs of HTTP to each operation (GET for read, POST for update, PUT for input, and DELETE for delete). However, SOAP web service only use POST for the all operation (read, update, input, delete).

30

It is caused by the request and response message are exchange with POST, and the resource was enveloped by itself with WS standardization. In resource relationships, The Restfull web service is useful to incrementally discover the interface of a RESTful web service by transversing hyperlinks between each of its resource representations. Likewise, the content of a resource can be revealed gradually, allowing interested clients to follow links to drill-down for more details. In data representation, the contet-type of a resource must be chosen among a set of standard formats. If an XML-based representation is chosen, it is not mandatory to constrain the content using a schema. In message exchange patterns will determine whether each operation uses a synchronous or an asynchronous interaction pattern.

3.1.4. Technology Comparison Table below summarizes the architectural conceptual comparison of RESTWS and SOAP-WS. The comparator in this section is Transport Protocol, Payload Format, Service Description and Security.
Table 3.3. Technology Comparison Summary

No

Comparator

REST-WS

SOAP-WS

a. Transport Protocol a.1. HTTP a.2. SMTP a.3. TCP b. Payload Format b.1. XML(SOAP) b.2. XML(POX) b.3. XML(RSS) b.4. JSON b.5. YAML b.6. MIME c. Service Description c.1. Textual Documentation c.2. XML Schema c.3. WSDL c.4. WADL d. Security d.1. HTTPS

31

d.2.

WS-Security

The web is defined by its protocol: HTTP, thus when choosing to build a RESTful Web service, there is no choice. One of the properties of SOAP is its transport independence, which allows SOAP messages to be exchanged using a variety of transport protocol. The WSDL binding element is used to select an appropriate transport protocol (HTTP being one possibility) to bind the operation messages. With this approach, messages in a standardized format can be transported using the most suitable protocol. Since a SOAP message could be routed both over secure and non-secure communication channels, it has been suggeste that the message itself should be protected in order to guarantee certain end-to-end security properties of the communication [7]. In the Payload format, SOAP Web Service is a single standardized message format that is SOAP. On the other hand, RESTful web service, currently do not used a single format for representing resources such RSS, JSON, MIME, etc. The WSDL tools can automatically generate client stub code for most programming languages, maskin the complexity of remotely interacting with a service. For RESTful web service, developers have to manually write the code to assemble the resource URIs and correctly encode/decode the exchanged resource representation. In the security, The SOAP web service contains a set of optional specifications covering the QoS properties of messages exchanged (have a standardised on security: WS-Security). These help to a certain quality level in the communication. The basic guarantees of protocol such as HTTP and HTTPS are shared by REST-WS and SOAP-WS styles. Considering the results on the comparison and development of information systems at University of al-Azhar Indonesia for the future, we decide to use the SOAP web service.

32

3.2.

Existing Academic Information System In this section would be discussed architecture and security is being implemented at University Al Azhar Indonesia. Existing AIS is use two-tier system or client-server system.

3.2.1. Existing Architecture Academic information system architecture (AIS) at the University of Al Azhar Indonesia is a client-server or a two-tier system. The connection between the client and the server is connected directly in point to point. Figure below shows the architecture.

Figure 3.1. Design of existing AIS Architecture

Architecture has several problems: AIS difficult to extend, and security has being implemented is poorly. AIS development difficulty is in creating new applications in order to improve the quality of information services such as online krs (web based application). Existing krs online is based on client-server system and only running at local area network) or application to enter values lecturer directly into the AIS. This happens because the existing AIS has some major issues:

33

the security level of system architecture is poor and database systems work isnt maximal. In existing architecture, AIS isnt blocked by firewall. At 11th August 2009 is schedule to observe PKSI-UAI (Pusat Komputer dan Sistem Informasi Universitas Al Azhar Indonesia). Observations are obtained: 1. AIS Server placed under the table system administrators. It should be placed at rackmount server NOC-PKSI. The AIS placed under the table of system administrator due to it is under maintenance (according to Mr. Rahmat, ST.). 2. According to Mr. Rahman Pujianto, ST. AIS server is not protected by a firewall so the server can be moveable. At 26th August 2009, interviews conducted with Mr. Ade Jamal as one of AIS user. According to him, the existing AIS is running slowly. It caused all the applications in University Al Azhar Indonesia connected into a AIS server. To prevent errors in entering the data value of students, and facilitate the development of future information services, therefore needs a new designed architecture to handle the problems that exist.

3.2.2. Existing Security In figure 3.1 has shown the client connected to the AIS server directly. Firewall is not used to protect the AIS. Therefore, the existing architecture is vulnerable. AIS should be protected by physical and logical, because the AIS keeps valuable data such as student values, student financial information and others. The physical security overlooked in University Al Azhar Indonesia. In accordance with chapter 3.2.1 on exposure to the visititation at PKSI-UAI on 11th August 2009, AIS placed on the server under the table Ary Kuncoro father. This shows that have not PKSI-UAI maintain the server that contains

34

the AIS berharaga data security standards issued by NIST (National Institute of Standards and Technology). In logical, AIS servers placed in the DMZ (Demilitarized Zone). DMZ is an area protected by a firewall. Protection is given because the server is considered to have an important function of an institute/company. Topology is obtained as shown in figure 3.1, connectivity between clients and servers connect directly without going through the firewall. Therefore, every computer that was connected to the LAN-AIS UAI can find the server. In AIS application side, sending a username and password to the AIS server for authentication process is very vulnerable. Username and password sent to the AIS server in plain text form. When a message is sent in the form of plaintext, anyone could read the message and can know the content of information transmitted from client to server.

3.3.

Propose System Architecture The new system architecture proposed in this project considers only the line of system for student grade system (called SIN). The proposed system architecture will need a new server that will work based on WS technology. The existing system which based on two tier system or client-server technology will be changed into multi tier system or using WS Technology. Hence, the existing centralized database does not have to be changed or modified. Due to the problems above, the system architecture will be developed work as middleware between the current AIS with the Sistem Informasi Nilai (SIN) server and the third party application (such as Lecturer Application, SAP Application, etc.). If the data is needed and it is doesnt have at SIN Server; SIN will be get the data from the Current AIS. The communication rule at this architecture is followed the rule has implemented at UAI. To protect and improve the security aspect to be more reliable, it needs a security system.

35

Detailed information about security system will be implemented in new architecture is shown on 3.3.

Figure 3.2. Design of New AIS Architecture

The web service technology will be implemented on new architecture is SOAP-WS refer to analysis on 3.2.

3.4.

Implemented Security at Propose System Architecture In the new system architecture, security aspect is going to get more attention. Security system must be able to guarantee two things: authentication and confidentiality. The following figure shows the security system that going to be applied at the development of system architecture.

Demilitarized Zone Security System

WebService
Security Server
Current System

Firewall Aplikasi Dosen Bluetooth Server Aplikasi SAP

SIA Server

Remarks:
Third Party Application First Time checked for authentication process

Sistem Informasi Nilai (SIN)

Figure 3.3. Detailed Design of Security at New AIS Architecture

36

Security server is needed to make sure that the client is communicating with AIS is an authenticated client. This authentication process will be explained in 3.3.1. Firewall is needed to protect and manage that outside systems communicate with the AIS only throughSIN server that uses the web service through http. Description in paragraph above, just guarantee the authentication aspect and does not include the confidentiality aspect. The confidentiality aspect is important to protect and keep secret the confidential data or information. Due to statement above, we will use an encryption technology to guarantee the confidentiality of data/information.

3.4.1. Authentication Authentication is needed to identify user and checking the user as an authenticated user. An authentication process being developed (as a part of security system) has an own policy. It is called MEZO. Each application has an application identity (ApplicationID) and it must be registered at authentication server. The ApplicationID is registered manually to the security server by System Administrator. MEZO works using ApplicationID. A picture below has shown how MEZO works.

37

Figure 3.4. Diagram of MEZO.

If application need information from AIS, it must have a RegisterID and Transaction Key. To get the RegisterID and TransactionKey, applications need to send the ApplicationID to authentication server. If the ApplicationID is registered at authentication server, the server would be sent back the RegisterID, Transaction Key, and Timer to countdown how long the system is permitted to establish a connection with Sistem Informasi Nilai Server (SIN Server). If the ApplicationID is not registered, the connection would be closed. RegisterID and data are sent to SIN server to get information. On SIN server, the received RegisterID would be checked, is sent to the security server, to make sure the RegisterID has registered and get the TransactionKey and Timer Security server will send back the status. If the RegisterID are registered, security server will send back confirmation status, transaction key and timer. The connection can be established during certain time limit. The picture above has shown the simple scheme of detailed of this process.

Checking the register ID are registered Sent Status, Transaction Key and Timer

38

RegisterID used in MEZO is Timestamp. Timestamp is selected because of the thoroughness of his time to 1 millisecond, and unique. The TransactionKey and the ClientKey has made with own random key generator, with length 16 characters (A-Z, a-z, 0-9) and the keys are different every time. The key generator for TransactionKey and ClientKey using different patterns.

3.4.2. Confidentialilty Confidentiality is needed to guarantee the data would be exchanged is secure. Encryption is a method to keep the confendiality. In Section 2.5.2 has explained many methods of modern encryption technique. In this section, want to analyze and choose one of them.

3.4.2.1. Selecting Encryption/Decryption Method Based on similiraty keys, it has divided into two kinds: Symmetric key and Asymmetic key. An example of symmetric key is DES, 3DES, AES, and example of asymmetric key is RSA. In symmetric key, AES is the latest technology.In asymmetric key RSA is most popular encryption method is used. Each of them has a profit and loss. The lack of using symmetric key is to distribute the key is need a private channel. The profit is process to encrypt and decrypt is faster than asymmetric key. In other side, profit of using asymmetric key is each user has a private key and to distribute it doesnt need a private channel. Furthermore, RSA has length of key 1024-2048bit and it has maked it more secured. As is known, the length of key has a positive reaction to security level. Beside the length of key, the security of RSA is difficulty to factorize the integer.The lack is process to encrypt and decrypt is slowly and data become biggest. The process is going slowly because the key is used at encryption has a long 1024 2048 bit. Some application (such as mobile application) difficult to handle a big file is being transferred.

39

After analyzed the loss and profit of symmetric and asymmetric key, the result is Symmetric key is selected to encrypt and decrypt the messages on the new architecture. It choosed based on the architecture needed. The symmetric key would be used is AES as the latest encryption technology. AES has three types of key: AES-128, AES-192, and AES-256. AES-128 is mostly used in the world and it would be used on this architecture. As explaination above, in symmetric key, the key would be used is distributed from the server to the client. However, the key wouldnt distributed to prevent the key is discovered by non-authorized people. We prefer to serve this encryption method such a packet/library, where it is provided in many programming language. The key has included in a packet/library. Due to this policy, each application want to be connected with the system require the library before. The library is not used for all transmitting information, but it would be used in confidential information was determined by user. 3.4.2.2. AES Work AES work using rijndaell algorithm. Generally, Rijndaell works with three steps: a. AddRoundkey: Joining plaintext and cipher key with XOR operand. This is an initial step. b. Rounding until Nr1 1 times. At this step, each round will do : v. SubByte: a non-linear substitution step where each byte is replaced with another according to a lookup table (S-box table). vi. ShiftRows: a transposition step where each row of the state is shifted cyclically a certain number of steps. vii. MixColumns: a mixing operation which operates on the columns of the state, combining the four bytes in each column.

Nr=Anumberofrounds(NrAES128=10,AES192=156,AES256=14).

40

viii. AddRoundKey: each byte of the state is combined with the round key; each round key is derived from the cipher key using a key schedule. c. Final Round : on this step, system will do: iv. ByteSub. v. ShiftRow. vi. AddRoundkey.

3.5.

System Design After analyzed system woks as explained in 3.1., 3.2., and 3.3., the next step is design the system. To design the system, UML is used as a tool to modeling the system. Only Use case diagram and Sequence diagram is used from UML to modeling it. Process want to model with UML are Registering ApplicationID, Authentication Process, and Getting Information.

3.5.1. Registering ApplicationID

Figure 3.5. Registering ApplicationID

Definition of actors
Table 3.4. Definition of Actors Process Registering ApplicationID

No. Actor 1. Administrator 2. Developer

Description Actors who have contact with security server and using the system directly. Actors who will serve or develop application and it will use security service and information system from UAI.

41

Definition of use case

Table 3.5. Definition of Use Case Process Registering ApplicationID

No. Use Case 1. Login 2. Register ApplicationID 3. Send ApplicationID 4. Logout

Description Login into application and security server, to registeri ApplicationID. Generate and Register ApplicationID into security server. After ApplicationID is registered, the ApplicationID is sent to Developer to put it into application is being developed. Exit from security server and application

3.5.2. Authentication Process Use Case Diagram

Figure 3.6. Authentication Process.

Definition of use case a. Client Application

Table 3.6. Use Case Definition of Client Application at Authentication Process.

No. Use Case 1. Send AppID

Description Client Send Application ID (AppID) to security server for authentication process. The AppID sent is encrypted. 2. Receive RegID Client Receive Register ID (RegID) and Transaction Key (TranKey) from security server. and TranKey RegID is needed at signing up process to SINServer and TranKey for encrypting confidential data will be exchanged.

b. Security Server
Table 3.7. Use Case Definition of Security Server at Authentication Process.

No. Use Case 1. Get RegID

Description The AppID needs to decrypt and to compare with registered AppID. Returned information contains as RegisterID and TransactionKey.

42

Sequence Diagram 1. Send AppID

Figure 3.7. Send ApplicationID/AppID.

User is requests some datas from ClientWS. ClientWS check if it has RegisterID or not. If it hasnt, ClientWS will request RegisterID from Security Server. To do that process, client key is needed to encrypt the ApplicationID will be transferred to AuthenticationWS. To get client key, it need EncryptionClient Library. After that, the next process is to encrypt ApplicationID and ClientKey and Send it to Security Server.

43

2. get RegID

Figure 3.8. Get RegisterID/RegID.

To read the information sent by Client, it needs EncryptionServer library. If ApplicationID is registered, Security Server creates TransactionKey and RegisterID (RegID). After TransactionKey and RegisterID were created, it will encrypt and send to the Client as a Response from Security Server.

3.

Receive RegID & TransactKey.

Figure 3.9. Receive RegisterID/RegID and TransactionKey/TransactKey.

44

Response from Security Server is decrypt to get the RegisterID. TransactionKey is decrypted first. The decrypted TransactionKey, is used to decrypt RegisterID and save the RegisterID and TransactionKey into database.

3.5.3. Getting Information. Use Case Diagram

Figure 3.10. Use Case Diagram of Getting Information.

Definition of use case a. Client Application

Table 3.8. Use Case Definition of client Application for Getting Information

No. Use Case 1. Send RegID and Data

Description SIN Server receives RegisterID and Data sent by Client. The RegID is sent in encrypted condition. Returned information from SIN Server is containing Timer Flag (TimFlag), Encryption Flag (EncFlag), and Information. TimFlag notice client is need to authentication again or not. EncFlag notice the information returned is in encrypted condition or not. 2. Receive TimFlag, Client receives information from SIN EncFlag, & Information Server contain TimFlag, EncFlag, and Information.

b. SIN Server
Table 3.9. Use Case Definition of Client Application for Getting Information

No. Use Case 1. Receive RegID and Data

Description SIN Server receives RegID and Data were sent from Client. After RegID is received from client, it forwards to security server for validating and geting Timer and TranKey. If it has validated, it will receive true or false notification. TranKey is needed to encypt some confidential

45

information and Timer notice how long this client is authorized to get information from SIN server. 2. Send TimFlag, EncFlag, After information needed from SIN server is proceeded, SIN server send TimeFlag is & Information sign the Client need to authentication again or not, EncFlag is sign the data is encryption or not and Information. c. Security Server
Table 3.10. Use Case of Security Server for Getting Information

No. Use Case 1. validate RegID

Description Receive RegID is sent from SIN Server. Check RegID is received by SIN Server is valid or not. If the RegID valid, security server will retusrn timer, TranKey and Code is sign the RegID valid or not.

Seqeunce Diagram 1.1. Send RegID and Data

Figure 3.11. Send RegisterID/RegID and Data.

Client needs information from SIN Server. The information is sent to the SIN Server containing RegisterID (in an encrypted condition). To encrypt RegisterID, client needs EncryptionClient Library.

46

1.2. Receive RegID and Data

Figure 3.12. Receive RegisterID/RegID and Data.

RegisterID (RegID) send by Client to SIN Server is forwarded to security server. It was forwarded to validate the RegisterID. Information will return from security server containing Timer and TransactionKey. Timer notices how long client is allowed to get information from SIN Server. TransactionKey is needed to encrypt the confidential information from SIN Server, or to decrypt the confidential information is sent by Client to SIN Server.

1.3. Validate RegisterID

Figure 3.13. Validate RegisterID.

Decrypting the received RegisterID need EncryptionServer Library. RegisterID from client compares with registered RegisterID. If the RegisterID from Client is valid, the Security server will return information containing Timer and TransactionKey.

47

1.4. Send SessFlag, EncFlag and Information

Figure 3.14. Send Session Flag/SessFlag. Encryption Flag/Enc Flag and Information.

After validating the RegisterID, SIN Server will check the data is received from client was encrypted or not. If the data was encrypted, it will decrypt first and needs EncryptionServer Library. After that SIN Server will get the information is needed by client and returned it to client. If the data is confidential, SINServer will encrypt it. The information will return to client is added with Session Flag, Encryption Flag.

Session Flag as information to the client, that is need or not to authentication again. Encryption Flag as a sign the information is returned to client is encryption or not.

48

1.5. Receive SessFlag, EncFlag and Information

Figure 3.15. Receive Session Flag/SessFlag. Encryption Flag/Enc Flag and Information.

Returned information from SIN Server should be checked (Session is active or not, returned information is null or not). If session is active and information is not null, check the received information is encrypted or not. If information in encrypted condition, it needs EncryptionClientLibrary to decrypt the information using TransactionKey from database.

CHAPTER IV TESTING AND IMPLEMENTATION

In this chapter the implementation of system such as the limitation of implementation, system environment, and implementation based on the results of design phase, that is built on the results of the analysis and design of the Chapter III will be explained.

4.1. System Environment At list below has shown the specification of operating system, hardware specification, software, and tools were developed system architecture:
Table 4.1. Specification and tools is used at development environment.

Operating System

Hardware Specification

Software is Used
Web Server: JAVA Application Server 9.0.1 with Glassfish v2ur2. Apache 2.2.6 with PHP 5.2.5. Database server : MySQL 5.0.51 Software Development KIT: JAVA Software Development KIT 1.6.0_11.

Tools
Netbeans version 6.7. AdobeDreamweaver version Creative Suite(CS) 3. PHPmyadmin version 2.11.3. MySQL Administrator version 1.2.12

Windows XP Intel Core 2 Professional (NT Duo CPU T7100 5.1. Build 2600) @ 1,80 GHz. Service Pack 3. RAM DDR II 2,49 GB

4.2. Limitation of Implementation Architecture is built at this final project followed limitations: 1. Security Library is developed only for application based on PHP and JAVA. 2. Security of this system architecture only includes the authentication and confidentiality.

49

50

4.3. Implementation Process Based on planning and analysis at chapter III, the web service and encryption/decryption testing will be conducted in two programming language, which are JAVA dan PHP. 4.3.1. Implementation of Encryption/Decryption In the implementation of encryption technology, a library which contained the methods for encryption and decryption will be constructed. Generally, this library is divided into two: client dan server (See Table below).
Table 4.2. Name of encryption and decryption library.

No 1 2

Class Name Client Server

Source Code File JAVA client.JAVA server.JAVA PHP client.PHP server.PHP

To implement in PHP, library mcrypt is needed. Installed PHP in server need reconfigure. On this experiment library mcrypt 2.2.6 will be used, which is downloaded from sourceforge.net [9]. Table below show the functions that provided for client and server. 4.3.1.1. Client At table below, you find summarize description of function was available in client library. Detailed information about library of encryption function in a server side such as parameter, data types and returned information, you could find at Appendix page A-1.
Table 4.3. Name of methods Encryption and Decryption at Security Library Client Side.

No 1

Function Name GenerateKey()

Description This function will create key, as a key to encrypt ApplicationID will send to Security Server.

EncryptAppID(ApplicationID, This Password)

function

will

be

encrypted

ApplicationID with client key as a Password.

51

EncryptKey(Key)

This function will encrypt the hashed Key and will send together with Encrypted ApplicationID to the server.

DecryptKey(EncryptedKey, Key)

This function will be decrypted the Key from the Authentication Server. We called it TransactionKey. To get the Key will used clientKey. The Transaction key will be used to encrypt the data, to get an information From the Sistem Informasi Nilai (SIN).

DecryptRegID(RegID, Key1, This Function will be decrypted the Key2) RegistrationID (RegID). To Decrypt te RegistrationID it would be used two keys (Key1 and Key2). Key1 is an transaction Key. Key2 is a ClientKey.

6 7

EncryptRegID(RegID) EnkripData(Message)

This function to encrypt the RegID before sent to the SIN with the Data. This function to Encrypt the important information from the client to the SIN server.

DekripData(Message)

This function to Decrypt an important information where is returned from the server to the client.

4.3.1.2.Server At table below, you find summarize description of encryption function was available in server library. Detailed information about library of encryption function in a server side such as parameter, data types and returned information, you could find at Appendix page A-2.
Table 4.4. Name of methods Encryption and Decryption at Security Library Server Side.

No 1

Function Name getPassword(Key)

Description Fungsi ini akan mendekrip client key

52

yang dikirimkan ke server. 2 getAppID(Message, Password) 3 GenerateKeyTransact() Fungsi ini akan mendekrip ApplicationID yang dikirimkan oleh klien, dengan menggunakan client key. This function will generate a transaction key is used as a Key to enkrip the vulnerable data. 4 EnkripRegID(RegID, Password_1, Password_2) This function will encrypt the RegisterID with a Password_1 is client key and Password_2 is a transaction key. 5 hashKeyTransact(GenKey, AppID, RegID) 6 EnkripKey(Message, Password) 7 DecryptRegID(Message) This Function will hash the transaction key was generated by Authentication server with AppID and RegID. This function will encrypt the hashed transaction key from Authentication server to the client with client key. This function will decrypt the RegID from client, to check is the RegID was Registered in Authentication server?

4.3.2. Implementation of Web Service Before web service has served an authentication process work, the first step is registration process of ApplicationID. Administrator will register the ApplicationID is used into authentication server over an internal software is running only at administrator computer. Generally, web services that serve the authentication process serve 2 things: 1. Give a RegisterID. 2. Give a time limit for client to be able to communicate with the sistem informasi nilai (SIN).

53

Getting process of the RegisterID, in authentication web services is used method getRegID(AppID, Password). AppID and Password is provided. Parameters at this method in mode cipher text. Process of constructing the cipher text, will be using the encryption functions which is provided in client library. The result of this calling method is Array that contained RegisterID and TransactionKey in a form of bentuk cipher text. Next process is giving the time limit to the sistem informasi nilai (SIN). To give the time limit, authentication web services is provide method getTimer(RegID). Register ID (RegID) as parameter in this method in mode cipher text. Result of this calling method is an array that contained the transaction key, time limit, and confirmation code. Detailed description about method getRegID and getTimer, you could find at Appendix page B. List of table and description of confirmation code, you could find at Appendix page C.

4.3.3. Testing The purpose of new architecture of academic information system tests is to prove the system is running as goal is desired.

4.3.3.1. Encryption/Decryption Tests Function The objective of encryption/decryption test function is to prove it will be running as expected. The expected result is the function of encrypt/decrypt which provided will translate the encrypted plaintext become plaintext exactly. In other words, plaintext as an output is same with plaintext was input on it.
Table 4.5. Name of methods Encryption and Decryption at Security Library Server Side.

INPUT
(Data to be Encrypted) Marionganteng

ENCRYPTED DATA
e09cf33b29d24e5da45e3ae73a73 b4f44f55fa43341df7b87f5e8aac7 4407896c127758d05cc9e4b6f4b5 7d617f46c51 d492f70c6b496606c0445a6bfd71

OUTPUT
(Data to be Decrypted) Marionganteng

17ZVsqU6IZkJRd9C

17ZVsqU6IZkJRd9C

54
9afa46f12d8cd00227a1ce45b745 3532f47d 99cc26800b5af0fe71c0987faed3e 9451bb43dbec5b26554afcca97bc 115c444510e660969ca252fe1067 82c1b740b3fe9c0a6908ce589dc7 d04cea23b8328786107cf40bc957 c4d70ea09c451e1e022e12acefe4d 5c556a027dc107f9f335a87636eb 92e19fcab4314cf3384b1763d4 57abf32b69679e9c2e84fd0ee028 66d677b9ecfcfa7847c0a3c8beda7 2551bf9ecf5ab16336e84741e20bf af63babfa1

1244472032000

1244472032000

Discussion of Result: The table above shows the testing process conducted in the encryptiondecryption function is developed at this project (is served at encryption library/package). Testing method is used at this testing section is the sample data (as an input at table 4.5) will encrypt and then decrypt with some set of function is served at encryption library/package and corresponding with the sample of input data. First, the encryption process carried out on a string Marionganteng. Assumed Marionganteng is ApplicationID of an application. Function used to encrypt is EncryptAppID (ApplicationID, password) which has been provided in the encryption library/package. The output of this EncryptAppID function is encrypted data

(e09cf33b29d24e5da45e3ae73a73b4f44f55fa43341df7b87f5e8aac74407896 c127758d05cc9e4b6f4b57d617f46c51). Using function getAppID (Message, Password), the encrypted data will be decrypted. Result of the decrypting data is Marionganteng. Due to the data input is equal to the data ouput, then function of encryption-decryption for ApplicationID is running well. The next testing process is the encryption process carried out on a string "1244472032000" that can be assumed as Clientkey (Key is produced by the client for encrypt the message). Function used to encrypt is EncryptKey (Key) which has been provided in the encryption library/package.

55

The

output

of

function

EncryptionKey(Key)

is

encrypted

data

(d492f70c6b496606c0445a6bfd719afa46f12d8cd00227a1ce45b7453532f47 d). For decrypting the encrypted data, can be used function getPassword (Key). Due to, the output of decrypting process is equal to an input at encrypting process, then the encryption-decryption function for ApplicationID is running well. The other sample data is tried to encrypt and decrypt with function is served at encryption library/package, such as: EncryptRegID-DecryptRegID for encrypt-decrypt the RegisterID and EnkripData-DekripData. In example RegisterID is 1244472032000 as an Input at EncryptRegID. The Encrypted Data as an output of EncryptRegID is (99cc26800b5af0fe71c0987faed3e9451bb43dbec5b26554afcca97bc115c444510e660969ca252fe10 6782c1b740b3fe9c0a6908ce589dc7d04cea23b8328786107cf40bc957c4d70 ea09c451e1e022e12acefe4d5c556a027dc107f9f335a87636eb92e19fcab431 4cf3384b1763d4). The result of decrypt using DecryptRegID is equal with RegisterID (as an Input). Due to there is equal then the encryption-decryption of RegisterID is running well. The data will be exchanged is A as an Input at function EnkripData (Message, Password). The encrypted data as result of function EnkripData is 99cc26800b5af0fe71c0987faed3e9451bb43dbec5b26554afcca97bc115c44 4510e660969ca252fe106782c1b740b3fe9c0a6908ce589dc7d04cea23b8328 786107cf40bc957c4d70ea09c451e1e022e12acefe4d5c556a027dc107f9f335 a87636eb92e19fcab4314cf3384b1763d4. The encrypted data is Decrypt to get the data using function DekripData (Message, Password). The Result of this function is A again. Due to the data as input at function EnkripData is equal with data as output at function DekripData then the EnkripDataDekripData of the datas exchanged is running well.

56

From the above test results and discussion, encryption-decryption function is run as expected result.

4.3.3.2. SIN Request Client To Re-authenticate Test The objective of SIN request client to re-authenticate test is to prove timelimit will be running as expected result. The expected result is when the time is over time-limit, client is enforced by SIN to re-authenticate (get a new RegisterID).

Figure 4.1. Application has re-authenticated.

Discussion of Result: Figure above shows the log file at SIN Server. Applications that have ApplicationID "marionphp-app" require data from SIN Server. Marionphpapp will send RegisterID "1248066824546" to SIN server. RegisterID as markers that marionphp-app has been obtain permission to gain access at SIN server. SIN server will ensure RegisterID sent by marionphp-app is valid and is registered in the security server. If it has registered, SIN Server will be given timer (30) and the transaction key (CPCmJQciefHS8CCC) by the security server. Timer is time-limit of an application to connect to the server SIN. Transaction key is the key for encryption and decryption the confidentiality messages. When the time-limit has passed, SIN server will provide notification to marionphp-app to re-authentication. Re-authentication process is done to the security server. When authentication is successful, application-php will get a new RegisterID (1248067365671). RegisterID were sent back by marionphp-app; SIN Server will return to RegisterID Validating the security

57

server. If the RegisterID is valid, SIN Server will receive the timer (30) and transaction key (1T2HifmDLQVbaWES). From the above test results (has shown at Figure 4.1), time-limit is run at SIN Server and client has done the re-authenticated process.

4.3.3.3. Response Time of New Architecture to Give Information Test The objective of response time test is to get how long the response time of new system architecture to give information to the client. Testing is done with 2(two) ways: 1. Testing at local computer. 2. Testing at real environment. In order to test the new designed architecture needs dummy SIN, which provides students grade as a service of this SIN (Real SIN is under developing). To get the RegisterID dan transaction key, client will do the Authentication process to Authentication server. Firstly, clien has to make a client key to encrypt the ApplicationID that will be used for Authentication process.
client cli = new client(); //Generate ClientKey String Key = cli.GenerateKey(); //Encrypted AppID String ApplicationID = cli.EncryptAppID(AppID, Key); //Encrypted ClientKey String Password = cli.EncryptKey(Key, AppID); autentikasiwebservice.Autentikasi port = service_1.getAutentikasiPort(); JAVA.lang.String appID = ApplicationID; JAVA.lang.String passwd = Password; //Process to call a method getRegID. JAVA.util.List<JAVA.lang.Object> result = port.getRegID(appID, passwd); //Retrieve RegID from Authentication server (encrypted) String RegIDEncrypted = (String) result.get(0); //Retrieve TransactionKey from Authentication server (encrypted) String KeyEncrypted = (String) result.get(1); // Transaction Key Keys = cli.DecryptKey(KeyEncrypted, Key); //RegisterID RegID = cli.DecryptRegID(RegIDEncrypted, Keys, Key);

58

After that, TransactionKey and RegisterID will be used to get the data from SIN Server.
client klien = new client(); id.ac.uai.sin.SisNilai port = service.getSisNilaiPort(); regID = klien.EncryptRegID(RegID); kodeMK = KodeMK; Result = port.getNilai(regID, kodeMK);

At the SIN server side, there has a process to verify RegID.

autentikasiwebservice.Autentikasi port = service.getAutentikasiPort(); // put RegisterID is received from client. JAVA.lang.String regID = RegID; //verivication process. JAVA.util.List<JAVA.lang.Object> result = port.getTimer(regID); //TransactKey TransactKey = (String) result.get(0); //Timer Timer = (String) result.get(1); //Status (Verified or Not) Status = (String) result.get(2);

If RegisterID is valid, client will get the informations needed from SIN Server. If dont the SIN Service will be return a code thats mean the RegisterID is not valid. Detailed information about format of SOAP-Request and Response on Each Process will see at Appendix-D. To calculate the response time process is used: For JAVA :
long start = System.currentTimeMillis(); long end = System.currentTimeMillis(); long elapsedTime = end-start;

For PHP :
$start = microtime(true); $end = microtime(true); $selisih = $end-$start;

59

4.3.3.3.1. Testing at Local computer Table below has shown testing result from local computer with JAVA as a client to get the information.
Table 4.6. Result of Testing getting Information from SIN Server at Local Computer.

Seq. 1. 2. 3. 4. 5. 6. 7. 8. 9. 10.

JAVA (ms) 2312 109 125 125 125 109 109 125 125 125

PHP (ms) 164 108 107 111 115 121 113 113 101 124

4.3.3.3.2. Testing at Real environment Table below has shown testing result from real environment with JAVA as a client to get the information.
Table 4.7. Result of Testing getting Information from SIN Server at Real Environment.

Seq. 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Analysis of Result :

JAVA (ms) 2712 575 540 540 540 540 540 540 540 540

PHP (ms) 1312 1311 1311 1311 1330 1330 1331 1331 1331 1330

Table 4.6 and 4.7 shows the response time of testing performed on two different environment: local environment and real environment. Client that uses java platform takes considerable time for the startup: 2312 milli-second (ms). The response time become bigger caused by the application server

60

needs time for startup initialize the system software. Beside that, it becomes bigger than the response time of the other sequences caused the application server is running above Java Virtual Machine (JVM).

TimeResponseJavavsPHPforGettingInformationfromSIN ServeratLocalEnvironment
TimeResponse(ms) 3000 2000 1000 0 1 2 109 108 3 125 107 4 125 111 5 125 115 6 109 121 7 109 113 8 125 113 9 125 101 10 125 124

JAVA 2312 PHP 164

Sequence

Figure 4.2. Chart of Time Response for Java vs PHP for Getting Information from SIN Server at Local Environment.

In figure 4.2 is shown charts of response time for JAVA vs. PHP for Getting Information at local environement. The graph is not show significant differences response time between JAVA and PHP. Try to compare the average of response time of JAVA and PHP. Average response time for JAVA is 338,9 milli-seconds and for PHP is 117,7 milliseconds. At local environment, the response time of JAVA is bigger than the PHP. Several problems caused the different response time of JAVA and PHP: 1. PHP and JAVA is a two different language; PHP is scripting languages and JAVA is programming languages. 2. PHP is consumes physical memory and processor smaller than JAVA. 3. JAVA and PHP use different type of translator; JAVA use compiler and PHP use interpreter. Compiler used to translate the JAVA source, consume a big resource of memory and processor. Interpreter is used to

61

translate the PHP script doesnt need a big resource of memory and processor.
TimeResponseJavavsPHPforGettingInformationfromSINServer atRealEnvironment
3000 2500 2000 1500 1000 500 0 JAVA PHP 1 2712 565 2 510 509 3 526 508 4 526 511 5 526 516 6 510 522 7 510 514 8 526 514 9 526 502 10 526 525

TimeResponse(ms)

Sequence

Figure 4.3. Chart of Time Response for Java vs PHP for Getting Information from SIN Server at Real Environment.

The testing result at real environment showed no significant difference with the result at local testing environment (the graph at figure 4.2 shows no significant difference with figure 4.3). However, response time is obtained in real environment is much larger than the local environment. Several problems that can cause differences in response time are: 1. The transport medium. Medium of transportation plays an important role to transport the data. Various existing medium such as air for wireless communication, copper wire, and fiber optic. Each medium has own transportation characteristic and problems. Fiber optic is the best-used of wire. In this testing environment RJ wire (consist of eight copper wires) we used as a medium of transportation. 2. The quality of network. Many factors determining quality of networks such as quality used equipment (hub, cable, routers, and switches) and network configuration. Actually the system is running well and accordance with goal is expected. System need a response time arround 1 seconds to response the request from client.

CHAPTER V CONCLUSIONS AND RECOMMENDATIONS

In this section, it will be presented the conclusions and recommendations from the final project. Conclusions and Recommendations obtained, after developing of a new architecture for academic information system and testing process is done.

5.1.

Conclusions. The conlusion are obtained from the implementation and testing of the final project is: 1. To improve the current AIS at University Al Azhar Indonesia need to design new architecture with ability to carry-out the data-exchange from many clients application to the server. Using web service technology is an option to improve the current AIS. In recent web service technology, there are two types of web service technologies mostly used today: REST-WS and SOAP-WS. To decide which one (REST-WS or SOAP-WS) want to use at this architecture, refering to comparison those type of web service technology, according to four categories: strength and weakness, principle comparison, implemented. 2. The new security design is implements: cryptography technology for guarantee the confidentiality of data, MEZO technology as an authentication system is developed for authenticating process and network-security. In Cryptography Technology, based on similarity of keys, there are two types, namely symmetric and asymmetric cryptography. After analyzed the strength and weakness of symmetric and asymmetric key, the result is Symmetric key is powerful to encrypt and decrypt the messages on the new architecture. The AES symmetric key is the
62

conceptual

comparison

and

technology

comparison,

therefore result is SOAP-WS is strongly recommended to be

63

best-used. AES has three types of key: AES-128, AES-192, and AES256. AES-128 is mostly used in the world and it would be used on this architecture. For the documentation purpose development system, this security system also provides a packet/library, in JAVA and PHP programming language. MEZO is works to validate client application with ApplicationID they have and give the RegisterID and TransactionKey to the authenticated client application. RegisterID will send every client application getting data from SIN Server and TransactionKey is used as a key to encrypt the confidential data from client application.

Some weaknesses of MEZO are: o Parameters are sent for authentication process is ApplicationID and ClientKey. The sent ApplicationID, is encrypt using static key and ClientKey (static key is a key which has saved in the client library and server library). The sent ClientKey, is put into a pattern. After put it into pattern, the pattern is encrypted with static key. If the pattern used to insert ClientKey was known, then the information sent from client to server security could be read. Security which is applied to the security server must be reliable. Thing to be avoided is left the ports open except HTTP port (usually port). If this is not addressed properly, it easily obtained RegisterID from the security server.

In network security, the system use firewall to block a server from other computers with implementing access permit list and port blocking for a several vulnerable ports.

64

3. Testing is done at three ways: encryption/decryption tests function, SIN request client to re-authenticate test, and response time of new architecture to give information test. The objective of encryption/decryption tests function is proving the function is running as expected. Result is the function is run as expected. The objective of SIN request client to re-authenticate test is proving time-limit is run as expected (when the client want to get information from SIN, and it was over from time-limit, SIN will enforce client to re-authenticate or get a new RegisterID). Result is SIN successfully enforcing client to reauthenticate. Last, The objective of response time of new architecture to give information test is how long time is needed to give information even it with authentication process and it was authenticated. Result is the response time is around 1 second to give the information from SIN to the client.

65

5.2.

Recommendations. 1. In the development of Authentication service, the IP block system should be implemented. The mechanism of IP Block system is blocking the IP address that tries to enter a wrong ApplicationID until three times. 2. The development of privileges system of user access rights to the services provided by the SIN needs to be developed. This restriction as a form of security services that are provided so that only users that authorized can access the service.

3. At some other time a mission critical situation can be happened. It caused by the server crash, system down, or got damage to the hardware. Therefore, their needs to design a fail over clustering system. With using this fail over, when server got a problem there has a backup server to support the main server whenever it is being troubled. So the system still running.

4. Applying the encryption technique of current AIS would be performed better if further study on confidentiality risk information is conducted.

REFERENCES

[1] Lucky.2008.XML Web Service Aplikasi Desktop, Internet & Hanpdhone. Jasokom:Jakarta. [2] Andrew S. Tannembaum.2002.Distributed System Principal and Paradigms.Prentice Hall:New Jersey. [3] Roy T. Fielding dan Richard N. Taylor. 2002. Principled Design of the Moder Web Architecture. ACM Transactions on Internet Technology:New York. [4] Chan Lung.2004.Studi dan Implementasi Advanced Encryption Standard dengan Empat Metode Block Cipher. Institut Teknologi Bandung:Bandung. [5] Primananda Aulia.2006.Keamanan Data Pada Sistem Penyimpanan Data Jaringan Komputer. Institut Teknologi Bandung:Bandung. [6] Ade Susanto. 2009. Kunci Simetris dan Asimetris. http://one.indoskripsi.com/judul-skripsi-makalah-tentang/kunci-simetrisasimetris. [7] Cesare Pautasso, Olaf Zimmermann, Frank Leymann.2004.RESTful Web Service vs. Big Web Services: Making the right architectural decision.University of Lugano:Switzerland. [8] William Stallings.2008.Data and Computer Communications. Prentice Hall:New Jersey. [9] Scheneimi. 2008. AES 128 Bit Encryption Between Java and PHP. http://schneimi.wordpress.com/2008/11/25/aes-128bit-encryption-betweenjava-and-php/

66

BIBLIOGRAPHY

Bofandra. 2009. Implementasi Data Encryption Standard Untuk Enkripsi Dekripsi Berkas PDF. Institut Teknologi Bandung:Bandung. Castello, Roger L. 2002.

REST

(Representational

State

Transfer)

http://www.xlfront.com/REST.ppt Lucky.2008.XML Web Service Aplikasi Desktop, Internet & Hanpdhone. Jasokom:Jakarta. Martha, Revi Fajar. 2006. Studi, Implementasi dan Perbandingan Algoritma Kunci Simetri Triple Data Encryption Standard dan Twofish. Insititut Teknologi Bandung:Bandung. Pantek. 2007.

Firewall:

Apa

Itu

Dan

Bagaimana

Kerjanya.

http://pantek.wordpress.com/2007/02/19/firewall/. Prescod, Paul.2002.

REST

and

The

Real

World.

http://www.xml.com/pub/a/2002/02/20/rest.html. Prescod, Paul.2002.

Second

Generation

of

Web

Service.

http://www.xml.com/pub/a/2002/02/06/rest.html. Rahardjo, Budi.2005.Kemaanan Sistem Informasi Berbasis Internet.Insan InfoneAIS:Bandung. Riftadi, Mohammad. 2009. Studi Perbandingan Algoritma Simetri Blowfish dan Advanced Ecryption Standard. Institut Teknologi Bandung:Bandung.

67

68

SecureWorks.

2007.

What

is

Firewall

Security?.

http://www.secureworks.com/research/articles/firewall-security. Stallings, William.2004.Data and Computer Communications.Prentice Hall:New Jersey Tannembaum, Andrew S. and van Steen, Marten.2002.Distributed System Principal and Paradigms.Prentice Hall:New Jersey. Tanenbaum, Andrew S.2003.Computer Networks.Prentice Hall:New Jersey. Wicaksono, Rizki. 2009.

Understanding

HTTPS.

http://www.ilmuhacking.com/cryptography/understanding-https/. Zagrodzki, ml. Krzysztof. 2004. Firewall in IT System.

http://www.windowsecurity.com/articles/A_firewall_in_an_IT_system.ht

APPENDIX A-1 LIST OF FUNCTION IN ENCRYPTION CLIENT LIBRARY

No
1. 2. 3.

Function Name
GenerateKey() EncryptAppID(ApplicationID, Password) EncryptKey(Key) NONE

Parameter

Description
Fungsi ini akan membuat key untuk membungkus ApplicationID yang akan dikirimkan dari klien ke server. We called it ClientKey. This function will be encrypted ApplicationID with client key as a Password. This function will encrypt the hashed Key and will send together with Encrypted ApplicationID to the server. This function will be decrypted the Key from the Authentication Server. We called it TransactionKey. To get the Key will be used clientKey. The Transaction key will be used to encrypt the data, to get information From the Sistem Informasi Nilai (SIN). This Function will be decrypted the RegistrationID (RegID). To Decrypt the RegistrationID it would be used two keys (Key1 and Key2). Key1 is an transaction Key. Key2 is a ClientKey. This function to encrypt the RegID before sent to the SIN with the Data. This function to Encrypt the important information from the client to the SIN server. This function to Decrypt an important information where is returned from the server to the client.

Result
Key type String AppID type String Key type String

Application ID type String, Password Type String Key type String

4.

DecryptKey(EncryptedKey, Key)

EncryptedKey Type Sring, Key Type String

Key Type String

5. 6. 7. 8.

DecryptRegID(RegID, Key1, Key2) EncryptRegID(RegID) EnkripData(Message) DekripData(Message)

RegID type String, Key1 Type String, Key2 Type String RegID type String Message Type String Message Type String.

RegID type String RegID type String Data Type String Data type String

69

70

APPENDIX A-2 LIST OF FUNCTION IN ENCRYPTION CLIENT LIBRARY

No
1. 2. 3. 4. 5. 6. 7.

Function Name
getPassword(Key) getAppID(Message, Password) GenerateKeyTransact() EnkripRegID(RegID, Password_1, Password_2) hashKeyTransact(GenKey, AppID, RegID) EnkripKey(Message, Password) Decrypt RegID(Message)

Parameter
Key type String Message type String Password type String NONE RegID type String Password_1 type String Password_2 type String GenKey type String AppID type String RegID type String Message Type String Password Type String Message Type String

Description
This function will decrypt the Client Key is sent to the server. This function will decrypt the ApplicationID is sent by client, with a clien key. This function will generate a transaction key is used as a Key to enkrip the vulnerable data. This function will encrypt the RegisterID with a Password_1 is client key and Password_2 is a transaction key. This Function will hash the transaction key was generated by Authentication server with ApplicationID and RegisterID. This function will encrypt the hashed transaction key from Authentication server (as a message) to the client with client key (as a password). This function will decrypt the RegID from client to check is the RegID was Registered in Authentication server.

Result
Key type String ApplicationID type String Key type String RegID type String Key type String Key type String RegID type String

APPENDIX B AUTHENTICATION SERVICE

1. Detailed description about getRegID function in Authentication Service. Format Method: getRegID(AppID, Passwd) Function Parameter
AppID type String, Passwd type String

Description

Result

RegisterID type This method will receive String. ApplicationID (AppID) and Transaction Key Client Key (Passwd) as type String. parameters. Parameters are encrypted. This method will The results are return the results in the form encrypted. of an array with the contents of the array are RegisterID and transaction key.

2. Detailed description about getTimer function in Authentication service. Format Method: getTimer(RegID) Function Parameter
RegID type String

Description
This method will receive RegID as parameter. Parameter is encrypted. This method will return the results in the form of an array with the contents of the array are TransactionKey, Timer and Confirmation Status.

Result
Transaction Key type String Timer Type String Confirmation Status Type String. The results are encrypted.

71

APPENDIX C CONFIRMATION STATUS

Table below has shown list of confirmation status. Code 300 301 400 401 402 403 Description Data is Encrypt Data is PlainText The RegisterID is valid ApplicationID is not valid RegisterID is not valid No Data Return.

72

APPENDIX D SOAP REQUEST AND RESPONSE FORMAT

getRegID(AppID, Passwd) SOAP Request

<?xml version="1.0" encoding="UTF-8"?> <S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"> <S:Header/> <S:Body> <ns2:getRegID xmlns:ns2="urn:AutentikasiWebService"> <AppID>f2d32aa52a4750c45a2e2f6eefa9be762f3f45b3751e05e034afc5e36b76ed21e719420d18439fb 13ea34ff091e353c6</AppID> <Passwd>6a4ef02d344806dc75e70c62603bfe4716cca58d4a9eb2def7bcae7b152a674f</Passwd> </ns2:getRegID> </S:Body> </S:Envelope>

SOAP Response
<?xml version="1.0" encoding="UTF-8"?> <S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"> <S:Body> <ns2:getRegIDResponse xmlns:ns2="urn:AutentikasiWebService"> <return xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">bfc2ba125726a5d307482866abffc258b073066d55c308690e376a896389307f3618 2cedcbc5ff59907a8f09a5179ddca048d54a1cc29f09a7dad908415b69d66f6ee34a69258ca6a0c8ba81f40 427fb40d50e016395ebc80e557f54ba3162379fcd49c42f437a8a33ab6bccae14d52c</return> <return xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">cacc478b6799f3f9719d3e035443fb09b3da56b072062b9e529c9a81c564c9ba29fa0 baae7d60d9163c71bf5d38c69d374c1d4fe1d6bec97304f6b27297f6298348953e960e5ebba47c2fa23bb1 3d7f4</return> </ns2:getRegIDResponse> </S:Body> </S:Envelope>

73

74

getTimer(RegID)
SOAP Request
<?xml version="1.0" encoding="UTF-8"?> <S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"> <S:Header/> <S:Body> <ns2:getTimer xmlns:ns2="urn:AutentikasiWebService"> <RegID>5a8d6d7e6e1cadf5bbacc450ff05f94c9100d460ae2ab0483232931abc394a0de5940fd34ea036c e31fee2f54570660e </RegID> </ns2:getTimer> </S:Body> </S:Envelope>

SOAP Response
<?xml version="1.0" encoding="UTF-8"?> <S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"> <S:Body> <ns2:getTimerResponse xmlns:ns2="urn:AutentikasiWebService"> <return xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">LnANUOMR4P6MNDWF</return> <return xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">30</return> <return xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">400</return> </ns2:getTimerResponse> </S:Body> </S:Envelope>

APPENDIX E APPLICATION PROGRAMMING INTERFACE

1. Client
/* * If data in database is empty then do authentication and get data from SIN Server. * If dont, get Data from SIN Server. if the Data returned from SIN server is Null and Timer Flag SESSION TIMED OUT then Client is forced to do authentication again. Else it is showing the data. */ if(checkData.equals("0")){ } else { if(Result.get(1).equals("Null") && Result.get(0).equals("SESSION_TIMED_OUT")){ } else { } }

2. SIN Server
//get data from DB, and check if RegID is exist or not. String checkData = isDataExist(RegisterID); Date thisTime = new Date(); long t = thisTime.getTime(); if(checkData.equals("0")){ // today variable to count the time. long today = t+m; // Call Security Server Web Service. method Name = getTimer // Return information, Transaction Key, Timer, Status. long m = Timer*60*1000; try { } catch (Exception ex) { } } else { long dataDiDB = getTimestampFromDB(RegisterID); long sel = dataDiDB-t; // If sel > 0 then it doesnt need authentication, just get the data from DB. // If dont it will push the client need authentication again. if(sel>0){ } else { } }

75