Eida Paper

Effective utilization of
Dr Riktesh Srivastava
Associate Professor, Information Systems
Skyline University College
Sharjah, UAE.
Abstract
The paper exhibits the procedure of Emirates ID for refining the university services, not only in terms of
enrollments, but also in day to day activities of the university. The paper proposed the model for
Implementation of Emirates ID in the University through the Authorization and Content Servers. The
anticipated model is on the identical grounds of n-tier Electronic Commerce architecture, wherein,
authorization to access the data of the card will be provided by the Emirates Identity Authority (EIDA)
and University continuously updates the academic profile of the enrolled student to the EIDA . The
comprehensive prototype is presented in the paper, which illustrates the implementation and working
of the model.
Keywords
Authorization Server, Content Server, ERP, EMS, AES, HRMS.
1. Introduction
Building the smart office [1], smart hospitals [2], [3] is the emergent inclination that incorporates ubiquitous
computing. Mark Weiser [4] oversees the continuous assimilation of technologies in human lives. The
motivation of the project is to provide the two way communication channel between universities in UAE
with EIDA. In other sense, the drive of this research is to examine the implementation of Emirates ID in
handling and supporting information services and activities in Universities in UAE and providing
information to EIDA on a real time basis.
The anticipated model for developing the thorough project is based on the grounds of n-Tier
electronic commerce architecture. The project comprises the integration of the ERP systems used in the
universities
zawith the EIDA systems, thus, providing the continuous information about the academic profile
of the registered students. The task determined in the project possesses gigantic challenges in terms of
integration of various modules of ERP, the kind of information to be accessed through EIDA system, and
security management. The project tries to elucidate these experiments, although, the project expansion
is still in its infancy state.
The comprehensive paper is disseminated into 8 fragments, as follows: Section 2 demonstrates
various modules of university ERP to be integrated with the EIDA system. The section demonstrates the
process flow diagram of each these modules of ERP to be implemented in the proposed model. Section
3 delivers the framework of the project along with the complete implementation diagram of the system.
Section 4 mentions the technical layout of the project along with the integration mechanism of various
modules of ERP with the EIDA system. The section depicts the WAN Layout for the complete system.
Blueprint for Improving University Services in UAE through Emirates ID: 360 Degree Approach
Section 5 describes the VPN setup of the system and argues the security management of the project.
Section 6 mentions the database elements and ER Diagram of the various module of the project. The
section also mentions the importance of Normalization and Query optimization for the complete project
development and implementation. Section 7 identifies the predictions of the complete project.
2. Modules of ERP
The attainment of firm and standard Information Systems are gradually mutual among firms and
businesses. The ERP system instigated in the project is developed from scratch and is used for online
integration of all the departments at the Skyline University College (SUC), Sharjah. Some part of the
systems are developed and implemented from early 2013, while other part of the system are in testing
phase, though the report generated from the system are already tested and verified.
The thorough ERP is divided into 4 sections:
1) Enrollment Management System (EMS)
2) Administration and Examination System (AES)
3) Institutional Research System (IRS)
4) Human Resource System (HRS)
The section targets to deliver the acumen of every ERP module to be used in the project in facet.
2.1 Enrollment Management System (EMS)

The EMS & CMS Module entails coordinating all aspects of enrolling and graduating students, including:
Working with administrative leaders to develop a strategic vision for shaping a first-year class of new
freshman and transfer students (e.g., demographic profile, preparedness) that is appropriate to the
mission and character of the SUC campus. The Enrollment Management/Registration System provides a
full range of functions related to student enrollment. Among these are course selection, pre-requisite
and requirement checking, availability of classes based on class size, assigning an advisor to a student,
and mail registration. The system also provides access to a students class schedule, class rolls, academic
calendar information, etc. A typical user of the system would be an employee who is involved in the
registration process.
Facilitating partnerships with higher secondary school counselors, and, in the case of transfer
students and other university / college advisors, to promote the university to qualified students;
Providing support and advice in the development of effective marketing tools and strategies to
encourage applications from qualified students;
Offering analytic support to facilitate recruitment strategies and admissions decisions, including
the development of financial assistance packages;
Supporting orientation and pre-enrollment services to maximize student enrollment and
preparation;
Collaborating with student services to ensure appropriate mentoring for students
Enrollment Management System (EMS) is the principal stage for the proposed project development and
interacts with the Authorization Server. EMS interacts with the Authorization Server, provides the
authentication code and access the records of the ID (every ID scanner provided by EIDA has an ID
attached) based on the authentication code. Authorization Server then interacts with the Content
server, process and stores the record in the EMS. The record provides the basic information required for
the enrollment of the student.
The complete process flow of the proposed implementation of EMS is indicated in Figure 1. As indicated
in the Figure, the EIDA systems provides the basic information of the student based on the
Authentication code for every EIDA Scanner. Once the record is retrieved in the ERP, EMS gets the basic
records of the students and starts further processing of the record.
As mentioned in the Figure 1, the complete EMS system requires four basic requirements:
1) Eligibility of the students for the enquired course
2) VISA requirements for International student
3) Hostel Requirement for International student
4) TOC cases
Enrollment Management System
No
Fill the Data Manually
Basic Data Available in EMS/CMS
through EIDA Systems
YES
1. BBA Major in IB
2. BBA Finance
3. BBA Information Syst.
4. BBA Marketing
5. BBA Travel & Tourism
6. MBA Emphasis on HRM
7. MBA Finance
8. MBA Marketing
9. MBA Strategic Mgmt.
YES - BBA
NO
VISA Required?
Intl or Local?
Program BBA / MBA ?

Select right Major/
Emphasis
YES VISA
HR
NO - MBA
Is Hostel
Required?
YES
YES HOSTEL
Is Hostel
Required?
NO
Admin
YES HOSTEL
NO
Admin
BBA
(Refer BBA
Admissions)
NO
YES VISA
VISA Required?
Intl or Local?
TOC Case?
MBA
(Refer MBA
Admissions)
NO
TOC - Case
IRO
Enter Data to
EIDA System
(Real-Time)
END
Figure 1: Enrollment Management System (EMS)
HR
2.1.1 Hostel Process Flow

Cited in the above-mentioned Process, the complete process flow for Hostel Requirements is illustrated
in Figure 2, as given below:
YES HOSTEL
Admin
Hostel Request
NO
Seats are available in

the hostel?
NO
YES
Boys Hostel?
YES
Check Jormand Girls Hostel
Details
Check Skyline Campus
Hostel Details
NO
Options - Message send to Sports

Dept
Email, SMS and Message pop up in
the Skyline ERP System
YES
Arrival of the student and picked up from Airport
Meeting with Marketing Dept & Sports Department (if the students arrives in day time else
next day morning
Sports Dept Checklist (Undertaking, Letter, Kit Collections Other formalities to be signed by
the students)
Sports Dept. updates the allocated room, policy manual, handbook handed over and linked
to Finance Dept
Student submit the Passport to HR & PRO
HR updates in the system for VISA and Passport collected

And message to Marketing Dept VISA & Passport Collected
END OF THE PROCESS
Figure 2: Hostel Process Flow
2.2 Administration and Examination System (AES)

Administration and Examination System (AES) is the core of the system, which generates the academic
profile of the student. The system checks the academic record of the student and automatically
transmits the record to Institutional Research office. , in case of any TOC verification. Once the academic
profile of the student is generated, the system automatically generates the graduation plan of the
student.
The complete process flow of AES is depicted in Figure 3 of the section. AES includes powerful central
database and control academic progression of the students and provides the information to content
server of EIDA on real-time basis.
AES is developed for administrative department to have a proper control and easy access to data.
System is fully integrated to allow proper flow of information and provides two-way communication
with all other departments, pertaining to student information.
The examination module of AES is developed to take care of students examination records. This is the
module for organizing examination, performance analysis and result publication. With this module of
ERP, one can view and edit students grades/marks and produce transcripts of the students. In other
words, the module provides the updated information about the enrolled student academic
performances.
As indicated in Figure 3, the complete AES part of ERP module includes the following initial setup
requirements:
1. Academic Semester Setup for the enrolled student. The setup is updated for every
student based on the academic performances of the student. It must be noted here that
the setup can be either Fall, Spring, Summer or Quarter based on the semester system
followed by university. For school, the academic setup would be completely different
and requires annual setup.
2. Academic Session Setup: The session setup mentioned in Figure 2 is for the academic
session setup followed by Skyline University College, Sharjah. From the master setup, it
can be changed as per the requirements of University/College.
3. Once setup 2 is completed, there are parallel actions which takes place and ERP now
requires Academic Elements setup and Degree program setup. The step may vary for
different universities and can be managed through the master setup of the
implemented system.
4. Academic Elements setup is followed minor other setups including Events setup,
Academic Calendar setup and all other academic related calendars.
5. Degree program setup is followed by Course details setup (part of Academic Elements
setup) and Students Evaluation and Grading setups.
6. Once all the setup are completed, the system generates the tentative graduation plan
for the student.
It must be also noted here that all the steps mentioned above are dynamic and depends upon the
academic performance of the student. The Graduation plan initially generated depends upon two
factors:
1. Performance of the students in the examination
2. Enrollment of the student in an accelerated program
For both the cases, the graduation plan varies completely.
Administration and Examination System
Academic Semester Setup

For the currently admitted student
Academic Session Setup

EX. WDM, WDE, WDA, WKD
Academic Elements Setup*

Continuous Mode of Assessments Quiz Date
Assignment
Case Study
Project Work
Mid Term
Final Term
Events Setup*
National Day Celebration
Introbash
Farewall etc..
Month
Degree Program Setup

BBI, BBM, BIB, BBF & BBT, AIPC & IELP
Class Code, Program Code, Faculty Code
MBF, MBM & MBH
MBA - MQP
Academic Elements Setup

Pre-requisite, P Protected, S - Senior Level
C Capstone, E - Elective
Academic Calendar Setup*

- Date From - Date to - Day - Particulars
All Other Calendars Setup for Different Dept at the start of the
Academic Year*
Operational Checklist, Pre-Semester Checklist (SSD & All Dept)
The system has provision of importing the above MAIN ACADEMIC
YEAR CALENDAR details and can be used in their calendar
Month - Date From - Date to - Day - Particulars
Student Evaluation & Grading Setup*

A, B+, B, C, C+, D+, D, F, W & I
Semester Grade Point Average
GP/SGPA/CGPA Calculation Setup and
CLASS SCHEDULE SETUP FOR STUDENT & FACULTY
Qualitative Requirements Setup (if 1-30 credits min. 1.5 CGPA etc)
TENTATIVE GRADUATION PLAN
Figure 3: Administration and Examination System (AES)

* As student progresses
through semesters
2.3 Institutional Research System (IRS)

Institutional Research System (IRS) offers the stand for a programmed testing of the student TOC cases.
The system matches the courses finished by the student with the already recorded universities and
grants or denies the TOC, whatever may be the instance. If the university is not listed in the system,
then, the same is checked manually and then university is listed in the system.
As indicated in Figure 4, the complete TOC process is divided into 6 stages:
1. Students
2. Marketing
3. Administration and Examination
4. Finance
5. IRO
6. Dean
The student submits the TOC application form to the Marketing and Registration Department. The EMS
ERP module at the Marketing and Registration department does the required checks (based on the preinstalled checklist). The Marketing and Registration Department upon receiving the required form,
forwards the form to Administration and Examination Department. The AES module of ERP debits the
TOC Processing Fees and performs the checklist required for the process. Once all the formalities are
completed, Institutional Research Office (IRO) evaluates the TOC process. Once the matching with the
courses are performed, the details are forwarded to Deans Office for final approval. The decision of the
complete process is intimated to the student, through Mail and SMS. The complete steps are illustrated
in Figure 4.
STUDENTS
MARKETING
ADMIN
FINANCE
IRO
Submit TOC application Forms
Receives TOC application

Forms
Debits TOC Processing Fees
Collects TOC Processing fee

from student
Evaluates the TOC

application form as per
TOC EVAL MODULE
Fills up the form and verifies

the document
Checklist, application form,
transcript & course
descriptions
Comply with other requirements
Checklist to be marked Tick
The official Transcript
Detailed Syllabi (Credit value,
level, course content etc
An Official letter from the
previous institution
All documents registration
requirements
Processing fees
Is complete?
No
Yes
Advice student to pay the

processing Fee to Finance
Department
Admin & Exam Dept

Transfer to Enrollment
Process with
Administration verifies the
ORIGINAL documents for
TOC
Prepares the graduation
plan and includes the
final TOC confirmation
letter
Graduation plan in the
admission kit
Nos. of courses
tentatively awarded
Fees Structure to be paid
by student
Makes photocopy of TOC

equivalency chart for filing
and hand-over to Admin the
Original Copy for preparation
of graduation plan
Informs the student about

the approval of TOC
application
Student will receive the

confirmation of TOC
application
Receives Mail & SMS
Auto mailer & SMS : Thank you

for your enquiry about TOC.
Kindly contact Marketing &
Registration Dept
Figure 4: Complete TOC Process

DEAN
Prepares draft TOC

equivalency Chart
Review the TOC application

Forms
Prepares final equivalency

chart
Approves the draft TOC

equivalency chart
Dean approves the final TOC

equivalency chart
IRO forwards to Marketing

Department
Figure 5 exemplifies the comprehensive TOC evaluation process in much facet. The TOC Policy for BBA,
MBA and MQP are demonstrated in the Figure 5.
Selects student
Populates the courses according to the

curriculum and program
TOC Policy:
BBA
1. Check for C grade and above.
2. Check for course equivalency of 70%
3. Check for equivalent credit (3/2/1)
4. If student coming from HCT, over all
CGPA should be >=2
5. Check for good standing, if not, only
student with different major to be
considered.
Evaluation of the courses according to

SUC TOC policy
MBA
1. Check for B grade and above.
3. Check for equivalent credit (3)
4. Check for good standing, if not, only
student with different emphasis to be
considered.
Link to TOC Module of IRO
MQP:
1. Check for B grade and above.
3. Check for equivalent credit (3)
End
Figure 5: IRO TOC Evaluation Process
2.4 Human Resource System (HRS)

The HR & Payroll Module System provides a full range of functions related to staff, faculty & VISA
student. Human Resource System (HRS) activates when the student requires the VISA to be processed
by the University.
The complete VISA processing by HRS is indicated Figure 6. The complete process is as follows:
1. The VISA application form is received by the Marketing and Registration Department through
EMS.
2. Marketing and Registration Department then transfers the form to the Administration and
Examination Department. Administration and Marketing Department access the form through
AES.
3. Administration and Marketing Department compiles the required files of the student and
transfers the file to the HRS.
4. HRD completes the VISA formalities, and, if approved transfers the required documents to the
Marketing and Registration Department for further processing.
Check Boxes - Refer VISA

process Check List
HR
Check Boxes:
Own VISA,
Parent Sponsored,
Company Sponsored,
UAE Local Others
NO
YES
Is it Skyline
VISA?
Complete Skyline VISA

Application Forms
NO
International
VISA?
Local VISA
YES
Complete ff forms:
A. Hostel Application Forms
B. Hostel Policy [Signature]
C. 3 months payment in advance
Hostel
Submit of docs of guardian:

A. Photocopy of Passport with VISA page
B. Undertaking duly signed by the guardian.
C. Tenancy Contract
D. Photocopy National ID or Labor Card
E. Contact Details : Present & Permanent
Stay in?
Guardian
Pay required fees Course,

hostel & VISA to Finance
Dept
Marketing Officer: Explain the guidelines

that he/she needs update these documents
as and when the expiry or on annual basis
visit and update.
Refer E
(BBA &
MBA)
YES
Guardian Docs
completes? And
Transport required ?
Marketing Dept will forward Student

file to Admin Dept.
NO
Admin Dept compile the docs for
VISA application then forward to
HRD. Furnished copy of hostel
application form to Sports Dept
HRD processed the VISA

application and once approved,
inform Marketing Dept
Mail about the student arrival to

student & HR, Marketing Dept
Admin
International Student Airport Pickup & VISA Deposit Marketing Dept to inform
about the VSA and student to forward travels details at least 3 working days before
his/her travel
END OF THE PROCESS
Figure 6: HRS-VISA Processing System

Once, the VISA of any student is about to expire, the automatic renewal process of VISA is done. The
complete VISA renewal process is illustrated in Figure 7.
Student fill-up VISA Renewal form online.

[Debit applies to student]
SSD validates student details i.e.

blocked, pending fees, etc
SSD inform student
NO
Is ok?
YES
Admin credit renewal fee
Admin Dept validate student

documents
YES
Stay with
guardian?
Admin verifies guardian docs & Students

credentials how many semester or year left
before finalizing VISA to be renewed:
C. Tenancy Contract
E. Contact Details
NO
YES
Guardian Docs
complete?
Student pay fees to Finance Dept

NO
Admin Dept compile the docs for

VISA renewal apllication then
forward to HRD.
Admin inform student submit the ff

guardian docs before renewing VISA:
C. Tenancy Contract
E. Contact Details
HRD processed the VISA

application and once approved,
inform student
END
Figure 7: VISA Renewal Process
2.5 Graduation Plan

The complete graduation plan is illustrated in Figure 8 below. All the steps of Tentative Graduation Plan
are self-explanatory.
Student
YES
NEW
WITH TOC?
CONTINUING
or NEW
CONTINUING
Admin generates Graduation Plan for

the remaining courses of the student
due to POSTPONEMENT/PROGRAM
TRANSFER/RE-ACTIVATION/
WITHDRAWN/SAP/FOU-TO-MAIN
NO
Admin generates Graduation Plan

based in the TOC equivalency
Chart made approve by Dean
Admin generates Graduation

Plan based in the SUC
Structured program.
Admin amends Fees Structure of Student

as per the outstanding balance and tenure
of study.
Admin hand-over graduation plan and New

Fees Structure SDD
Admin hand-over Graduation plan

to SSD
SDD Issue the Graduation Plan along with

the revised Fees Structure.
SDD Issue the Graduation Plan

along with the Admission Kit
Student receives Graduation Plan

Checklist Review for Registration of
Continuing Student:
1. Normal Student
2. Withdrawn Student
3. SAP Student cases
4. Finance Outstanding Student
5. Foundation to Main
6. MQP to Main
END
Figure 8: Graduation Plan

3. Framework of the proposed model

Complete integration of the university ERP and EIDA system provides the academic and financial profile
of the enrolled students. The section of the paper provides the complete framework along with the flow
chart of the system.
The section expounds the comprehensive framework of the projected model. The ample
model is portrayed in Figure 9, and is alienated into 10 steps. It is predicted that after
accomplishment of these 10 steps, EIDA will be knowledgeable of the registration
progression of the student. Also, the projected project hoards magnanimous time of the
university authorities (Investigate about the student minutiae and pile in the system as a
standalone system). The system works as a centralized system, where, EIDA systems are
updated on real-time and continuous basis about the number of registration per course
and progression of the enrolled student for each university.
8
10
Looks for
TOC
Case, if
Admin and
any
Examination
Enrolment
Management
System
2
1
Data
transferred
to AES
Gets the Data
Student gets to Registration

Department
System
Is there any
TOC?
5(A or B)
Yes
Scans Emirates
ID
Auto
Analyzing by
IRO
1(A)
Emirates ID
Scanner
No
1(B)
Gets connected to
Authorization Server
1(D)
6(A or B)
1(C)
Authorizes
the User ID
Accept the
Reject the
case Admin and
case
Examination
System
[Checks with User ID which data can be

accessed]
Does the
student
requires visa?
EIDA System
Pulls out the Data
from Content Server
7
GP generated
3(A)
Human Resource
Department
Figure 9: Complete Framework of the proposed model
The description of the 10 step procedure for the thorough application development and enactment is
depicted below:
Step 1: In the step, the student gets into the university Registration Department and presents
the Emirates ID card to the Registration Department.
Step 1(A-D): The Registration Department scans the Emirates ID Card at the Emirates ID Scanner
and enters the authorization card provided by EIDA. Based on the authorization code, the
authorization server defines the set of data to be provided. The system gets connected to the
Content Server of EIDA.
Step 2: The step pulls the data to be stored at the Enrollment Management Systems (EMS).
Step 3: After data being stored at EMS, it is pushed to the Administration and Examination
Systems (AES) for further verification.
Step 3(A): In this step AES pushes the part of data, for an International Students for VISA
processing.
Step 4: The step checks for any Transfer of Credit (TOC) case of the student. If the student is not
the case of TOC, Graduation plan of the student is automatically generated.
Step 5(A or B): The data is pushed to the IRO for verification of TOC.
Step 6(A or B): Depends of the case (being accepted, for the number of courses or rejected), the
record is again pushed back to AES, for the generation of the graduation plan.
Step 7: After verification of all the records, the Graduation plan of the student is generated.
Step 8: The record is send back to EMS, for registration purpose of the student.
Step 9: The complete updated recorded is pushed to the content server of EIDA.
Step 10: Student is informed of the registration process.
The implementation of 10 steps is illustrated as an Implementation Diagram in Figure 10 of the section:
Scans the Emirates

ID Card through ID
Scanner
(ID Scanner
provided by EIDA)
Enrollment
Management
System
(EMS)
Start
Based on the ID
Scanner, the
required fields are
populated in ERP
Yes
Student meets
admission criteria?
Admission record
gets stored in EMS
No
EMS module the
details provided by
EIDA systems and
other details
required
Recorded forwarded to
Administration and Examination
(AES)
Department
Verifies the
complete
admission
process
Admission and
Registration Department
generates the Student ID
No
Yes
AES completes the admission

process
TOC?
Institutional
Research office
VISA Case?
IR module
completes the
TOC process
Yes
No
End
Complete academic
profile (Graduation
plan and fees
payment plan)
pushed to EIDA
system
AES generates the complete

graduate plan of the student
Upon approval of
the complete
graduation plan,
data is published in
the portal
Figure 10: Implementation Diagram of the Proposed Project

HR Department
generates the complete
details for VISA
processing
4. WAN Extranet Layout

In order to ensure success of project, all the partnering organizations should be able to connect to
central EIDA cloud, using in-secured line, such as broadband, or internet leased lines. Securing the
connectivity of partnering organization using Virtual Private Network, irrespective of internet
communication technology deployed, standardized firewalls will be used, with a standardized policy,
whereas authentication keys will vary from organization to organization. Figure 11 expounds the
comprehensive layout of the WAN Extranet Layout; we had intended for the development.
Database
Application Server(APIs)
Database Cluster
Protected Zone
DMZ ZONE
EIDA Extranet Firewall
IP/MPLS
IP/MPLS
IPSEC TUNNEL
University Firewall
EIDA Scanner
EIDA Scanner
University Enrollment System
Database
School Admission System
Database
Students Academic Database
Students Academic Database
Figure 11: WAN Extranet Layout

The following segment delineates a comprehensive portrayal of recommended VPN Layout, which might
be applicable for efficacious employment of the EIDA prototypical.
5. Virtual Private Network Layout

In mandate to deliver a secured Extranet Tunnel between pairing institution and EIDAs Data Repository
Server, there will be two-phased VPN policy that will initiate the Connectivity. Though CISCO is
universally accepted leader in Firewall Technology, but through standardizing the tunneling policy the
project will gain more admiration and triumph as partnering EIDA organizations can use popular
firewalls such as Juniper, Fortinet, DELL, Sonic Wall etc.
Figure 12: IPSEC Tunnel

Based on Figure 12, the execution of security schemes for the proposed project encompasses two
phases, as specified:
5.1 Phase-1
Internet Key Exchange (IKE or IKEv2) is the protocol used to set up a security association (SA) in the IPsec
protocol suite. IKE builds upon the Oakley protocol and ISAKMP, and forms Phase-1 of VPN formation
process. The key protocols that are suggested to be used during Phase-1 are as follows:
5.1.1 Diffie-Hellman Key Exchange Algorithm
Diffie-Hellman (DH Group) is a public-key cryptography protocol. It consents two parties to establish a
shared secret key used by encryption algorithms over an insecure communication channel. In other
words, Diffie-Hellman key exchange bids the superlative of both worlds - it uses public key techniques to
allow the exchange of a private encryption key.
The section provides the mechanism of DH Algorithm works for the proposed project, from the
perspective of Participating EIDA Client (PEC) and EIDA System (ES), two users who wish to establish
secure communications. We can assume that PEC and ES know nothing about each other but are in
contact.
9 step process for DH Algorithm:
1. Communicating in the clear, PEC and ES agree on two large positive integers, n and g, with the
stipulation that n is a prime number and g is a generator of n.
2. PEC randomly chooses another large positive integer, XA, which is smaller than n. XA will serve as
PEC 's private key.
3. ES similarly chooses his own private key, XB.
4. PEC computes her public key, YA, using the formula YA = (g^XA) mod n.
5. ES similarly computes his public key, YB, using the formula YB = (g^XB) mod n.
6. PEC and ES exchange public keys over the insecure circuit.
7. PEC computes the shared secret key, k, using the formula k = (YB ^XA) mod n.
8. ES computes the same shared secret key, k, using the formula k = (YA ^XB) mod n.
9. PEC and ES communicate using the symmetric algorithm of their choice and the shared secret
key, k, which was never transmitted over the insecure circuit.
How the algorithm works:
Step 1:
The algorithm generates a public key and a private key for the client (say PEC)
KeyPairGenerator PECKpairGen=KeyPairGenerator.getInstance("DH");
PECKpairGen.initialize(dhSkipParamSpec);
KeyPair PECKpair = PECKpairGen.generateKeyPair();
The KeyPairGenerator class is used to generate pairs of public and private keys.
Key pair generators are constructed using the getInstance factory methods (static methods that
return instances of a given class).
A Key pair generator for a particular algorithm creates a public/private key pair that can be used
with this algorithm. It also associates algorithm-specific parameters with each of the generated
keys.
Step 2:
PEC then encodes her public key and sends it to ES, who then retrieves the DH parameters
associated with PECs public key and uses it to generate his own key pair.
DHParameterSpec dhParamSpec =((DHPublicKey)PECPubKey).getParams();
Step 3:
ES initializes his own DH key pair
KeyPairGenerator ESKpairGen = KeyPairGenerator.getInstance("DH");
ESKpairGen.initialize(dhParamSpec);
KeyPair ESKpair = ESKpairGen.generateKeyPair();
Step 4:
ES encodes his public key and sends it over to PEC

byte[] ESPubKeyEnc = ESKpair.getPublic().getEncoded();
At this stage, both ES and PEC have created their public and private keys, and have exchanged
their public keys. The will now generate a shared key.
PEC shared key:
PECKeyAgree.doPhase(ESPubKey, true);
int PECLen = PECSharedSecret.length;
ES Shared Key:
byte[] ESSharedSecret = new byte[PECLen];
Step 5:
ES and PEC write down their shared keys into a file, which are then read by the server and client
respectively.
The High Level Architecture for the Diffie-Hellman Key Generator Algorithm is depicted in Figure 13
given below:
Diffie-Hellman Key Generator Algorithm
Participating
EIDA Client
(PEC)
Encrypt Data using

DES+DH
Stores Decrypted Data
EIDA System
(Server)
Retrieving Data
Database
Generates shared key for

server
Figure 13: Higl Level Architecture of DH Algorithm

The following part elaborates about the individual modules of the Algorithm:
Participating EIDA Client (PEC) DH Algorithm:
The diagram mentioned in Figure 14 illustrates about the implementation of PEC DH algorithm. As
indicated in the diagram, the PEC first uses the Shared Key agreed by the systems and then generates
the DES Cipher to encrypt the text. Once the text is encrypted, complete information is send to the ES
for decryption and further action. Encrypting the text at this level secures the incoming requests from
each and every EIDA Scanner placed in the Universities/Schools.
Shared Key
(from the file into which the DH
algorithm writes the shared text)
To Server
Read Shared Key file
Generate DES Cipher

(Using Shared Key)
Encrypt Plaintext using

cipher
Figure 14: PEC Module of DH Algorithm

EIDA System (ES) DH Algorithm:
The diagram cited in Figure 15 exemplifies about ES DH algorithm. As designated in the illustration, the
ES uses the Shared Key agreed by the systems and then decrypts the message from the PEC using the
shared key. The algorithm then logs the data in the database (used for future security purposes) and
provides the information to the PEC, based on the authentication code.
Shared Key
(from the file into which the DH
algorithm writes the shared text)
Provides information
to PEC based on the
authentication
Read Shared Key file
Decrypt the message using the

Shared Key object and DES (in
DECRYPY mode)
Log the decrypted data into the database

Display the encrypted and decrypted data
as the output
Figure 15: ES Module of DH Algorithm

5.1.2 Advanced Encryption Standard
This section explains the AES algorithm suggested by Federal Information Processing Standards (FIPS) [5],
dispensed by the National Institute of Standards and Technology (NIST) which stipulates the Advanced
Encryption Standard. The specification called for a symmetric algorithm (same key for encryption and
decryption) using block encryption 128 bits in size, supporting key sizes of 128, 192 and 256 bits, as a
minimum.
The AES is a subset of a much loftier encryption algorithm identified as Rijndael, which was one of many
suggestions to the NIST competing for fetching a standard encryption algorithm.
The AES algorithm is a symmetric cipher. In symmetric ciphers, a single secret key is recycled for both
the encryption and decryption, while in asymmetric ciphers, there are two cliques of keys recognized as
private and public keys. The plaintext is encrypted by the public key and can only be decrypted
expending the private key.
In accumulation, the AES algorithm is a block cipher as it maneuvers on fixed-length collections of bits
(blocks), however in stream ciphers, the plaintext bits remain encrypted one at a time, and the set of
transformations pragmatic to continuous bits may diverge throughout the encryption process.
Inputs, Outputs and the State

The plaintext input and cipher text output for the AES algorithms are blocks of 128 bits. The cipher key
input could be a sequence of 128, 192 or 256 bits. In alternative words the length of the cipher key, Nk,
is either four, 6 or 8 words that represent the amount of columns within the cipher key. The AES
formula is categorized into 3 versions supported the cipher key length. The amount of rounds of secret
writing for every AES version depends on the cipher key size.
In the AES rule, the number of rounds is represented by Nr, wherever Nr = ten once Nk = four, Nr = 12
when Nk = 6, and Nr = 14 once Nk = 8. The subsequent table illustrated the variations of the AES
algorithm. For the AES algorithm the block size (Nb), that represents the quantity of columns comprising
the State is Nb = 4.
AES Version
Key Length
(Nk words)
Block Size
(Nb words)
Number of Rounds
(Nr rounds)
AES128
10
AES192
AES256
6
8
4
4
Table 1: AES Variations
12
14
The basic process unit for the AES algorithm is a byte. As a result, the plaintext, cipher text and
therefore the cipher key are arranged and processed as arrays of bytes. For associate input, an output
or a cipher key denoted by a, the bytes within the ensuing array are documented as an, wherever n is in
one in every of the subsequent ranges:
Block length = 128 bits, 0 <= n < 16
Key length = 128 bits, 0 <= n < 16
All byte values within the AES algorithm are bestowed as the concatenation of their individual bit values
between braces within the order. These bytes are understood as finite field elements employing a
polynomial representation:
As an example, (or in hexadecimal) identifies the polynomial. The arrays of bytes within the AES formula
area unit described as:
7
b7 x 7 b6 x 6 b5 x 5 b4 x 4 b3 x 3 b2 x b1 x b0 x bi x i
i 0
7
As an example, {10001001} (or {85} in hexadecimal) identifies the polynomial x x 3 1 . The arrays of
bytes in the AES algorithm are represented as a 0 a1 a 2 ...a n .
All the AES algorithm operations are performed on a 2 dimensional 4x4 array of bytes that is termed the
State, and any individual byte inside the State is stated as sr,c, where letter r represent the row and
letter c denotes the column. At the start of the encoding method, the State is inhabited with the
plaintext. Then the cipher performs a group of substitutions and permutations on the State. When the
cipher operations are conducted on the State, the final value of the state is traced to the cipher text
output as is shown within the Figure 16.
Input Bytes
State Array
Output Bytes
in0
in4
in8
in12
s0,0 s0,1 s0,2 s0,3
out0 out4 out8 out12
in1
in5
in9
in13
s1,0 s1,1 s1,2 s1,3
in2
in6
in10
in14
s2,0 s2,1 s2,2 s2,3
in3
in7
in11
in15
s3,0 s3,1 s3,2 s3,3
Figure 16: State Population and Results

At the commencement of the cipher, the input array is clichd into the State according the following
scheme:
s[r,c] = in [r + 4c]
for 0 r 4 and 0 c 4 ,
and at the end of the cipher the State is copied into the output array as shown below:
out[r+4c] = s[r,c]
for 0 r 4 and 0 c 4
Cipher Transformations
The AES cipher either operates on individual bytes of the State or an entire row/column. At the start of
the cipher, the input is copied into the State. Then, an initial Round Key addition is performed on the
State. Round keys are derived from the cipher key using the Key Expansion routine. The key expansion
routine generates a series of round keys for each round of transformations that are performed on the
State.
The transformations performed on the state are similar among all AES versions but the number of
transformation rounds depends on the cipher key length. The final round in all AES versions differs
slightly from the first Nr =1 rounds as it has one less transformation performed on the State. Each round
of AES cipher (except the last one) consists of all the following transformation:
1.
2.
3.
4.
SubBytes( )
ShiftRows( )
MixColumns( )
AddRoundKey ( )
The AES cipher is described as a pseudo code as follows:

Cipher(byte PlainText[4*Nb], byte CipherText[4*Nb], word w[Nb*(Nr+1)])
begin
byte state[4,Nb]
state = in
AddRoundKey(state, w[0, Nb-1])
for round = 1 step 1 to Nr1
SubBytes(state)
ShiftRows(state)
MixColumns(state)
AddRoundKey(state, w[round*Nb, (round+1)*Nb-1])
end for
SubBytes(state)
ShiftRows(state)
AddRoundKey(state, w[Nr*Nb, (Nr+1)*Nb-1])
out = state
end
As depicted in the pseudo code, all the Nr rounds are identical with the exception of the final round
which does not include the MixColumns transformation. The array w[] represents the round keys that
are generated by the key expansion routine. In the following sections, individual transformations that
are used in each encryption round are described.
5.1.3 Secured Hash Algorithm 1 (SHA-1)
Secure Hash Algorithm 1 (SHA-1) is a hash algorithm used to authenticate packet data. IKE, AH, and ESP
can use SHA-1 for authentication [6].
All hash functions operate using the following general principles:
1. The input string is viewed as a sequence of n-byte blocks.
2. The input is processed one block at a time in an iterative fashion to produce an n-bit hash
function.
The simplest hash function is the list-by-list XOR of every block, expressed as following:
Ci=bi1 bi2 bim
where,
Ci=ith list of the hash code, 1in
M=number of n-bit blocks in the input
Bij=ith list in jth block
=XOR operation.
This is depicted in Figure 17.
bit 1
b11
bit 2..
bit n
b21
bn1
..
b12
..
:
:
..
Block2
Block m
b1m
..
bnm
Hash code
C1
..
Cn
Block1
C2
bn2
Figure 17: Simple Hash Function using Bitwise XOR.
Note1:
Figure 17 produces a simple parity for each bit position, and is known as a longitudinal redundancy
check. It is reasonably effective for random data as a data integrity check.
Another scheme, originally proposed by NIST, used the simple XOR applied to 64 bit blocks of the
message and then an encryption of the entire message that used the cipher block-chaining (CBC) mode.
In other words, given a message consisting of a sequence of 64 bit blocks X1, X2, ., XN, define the hash
code C as the block and append the hash code as the final block:
C = XN+1 = X1 X2 . XN
Next, encrypt the entire message plus hash code, using CBC mode to produce the encrypted message Y1,
Y2, ., YN+1.
Note 2:
It was shown that the above scheme to produce a hash code is not secure.
Secure Hash Algorithm
A cryptographic hash function uses a cryptographic function as part of the hash function. An intruder or
opponent would presumably not have access to the cryptographic function. The intruder could modify
the data or the hash value or both but without knowing the Cryptographic relationship between the
data and the hash value, the intruder would be unlikely to be able to modify both in such a way that
they match. Thus, modifications could be detected at the recipients end, with a probability depending
on the strength of the cryptographic algorithm and on the degree to which the data was reduced.
The secure hash algorithm (SHA) was developed by NIST in 1993 (FIPS PUB180). A revised version
referred to as SHA-1 was issued in 1995 (FIPS PUB 180-1). The algorithm takes as input a message with a
maximum length of less than 2 64 bits
Figure 18: Message Digest Generating Using SHA-1

And produces as output a 160-bit message digest. The input is processed in 512 bit blocks. Figure 8
shows the overall processing of a message to produce a digest. The processing consists of the following
steps:
Step 1: Append Padding bits
The (plaintext message is padded so that its length is congruent to 448 module 512. Padding is always
added, even if the message is already of the desired length. Thus the number of padding bits is in the
range of 1 to 512. The padding consists of a single 1-bit followed by the necessary number of 0-bits.
Step 2: Append Length
A block of 64 bits is appended to the message. This block is treated as an unsigned 64-bit integer and
contains the length of the original message before the padding.
The outcome of these two steps yields a message that is an integer multiple of 512 bits in length. In
Figure 18 the expanded message is represented as the sequence of 512-bit blocks Y0, Y1, .., Y2-1, so
that the total length of the expanded message is
L x 512 bits. Equivalently, the result is a multiple of
16 32-bit words. Let M *0.N-1] denote the words of the resulting message, with N an integer multiple
of 16. Thus, N=Lx16.
Step 3: Initialize MD Buffer
160-bit buffer is used to hold intermediate and final results of the hash function. The buffer can be
represented as five 32-bit registers (A,B,C,D,E). These registers are initialized to the following 32-bit
integers (hexadecimal values):
A = 67452301
B = EFCDAB89
C = 98BADCFF
D = 10325476
E = C3D2E1F0
Step 4: Process Message in 512-bit (16-Word) Blocks
The heart of the algorithm is a module, known as compression function; that consists of four rounds of
processing 20 steps each. The logic is illustrated in Figure 19. The four rounds have a similar structure,
but each uses a different primitive logical function, which we call f1, f2, f3, and f4.
Each round takes as input the current 512-bit block being administered, Yq and the 160-bit buffer value
ABCDE and apprises the contents of the buffer. Each round also uses an additive constant Kt, where 0<=
t <= 79 indicates one of the 80 steps across five rounds.
Figure 19: SHA-1 Processing of a Single 512-Bit Block (SHA-1 Compression Function)
In fact, only four distinct constants are used. The values, in hexadecimal and decimal are depicted in
Table 2 as follows:
Step number
Hexadecimal
Take integer part
0<= t <= 19
Kt = 5A827999
[ 230 x 2 ]
20<= t <= 39
Kt = 6ED9EBA1
[ 230 x 3 ]
40<= t <= 59
Kt = 8F1BBCDC
[ 230 x 5 ]
60<= t <= 79
Kt = CA62C1D6
[ 230 x 10 ]
Table 2: Hexadecimal and Decimal values

The output of the fourth round (eightieth step) is added to the input to the first round, CVq , to produce
CVq+1. The addition is done independently for each of the five words in the buffer with each of the
corresponding words in CVq , using addition module 232.
Step 5: Output
After all L 512-bit blocks have been processed, the output from the Lth stage is the 160-bit message
digest.
Note 1:
The SHA-1 algorithm has the property that every bit of the hash code is a function of every bit of the
input. The complex repetition of the basic function of ft produces results that are well mixed. It is
unlikely that two messages chosen at random will have the same hash code.
Note 2:
The difficulty of coming up with two messages having the same message digest is on the order of 280
operations. The difficulty of finding a message with a given digest is on the order of 2160 operations.
Other Secure Hash Algorithms
There are other secure hash algorithms:
MD5: The MD5 message-digest algorithm was developed by Ron Rivest. It takes as input a message of
arbitrary length and produces as output a 128-bit message-digest. The input is processed in 512-bit
blocks. It is shown that MD5 is vulnerable to cryptanalysis.
RIPEMD -160: This algorithm was developed under the European RACE Integrity Primitive Evaluation
(RIPE) project, by a group of researchers, who launched partially successful attacks on MD4 and MD5.
RIPEMD-160 is quite similar to SHA-1. The algorithm takes as input a message of arbitrary length and
produces as output a 160-bit message digest. The input is processed in 512-bit blocks.
5.2 Phase-2
Once a Security Association is established in Phase 1, Phase 2 is IPSEC (ISAKMP) where we get into what
specifics the set up in the policies to have the keys set.
IPsec is an end-to-end security scheme operating in the Internet Layer of the Internet Protocol Suite,
while some other Internet security systems in widespread use, such as Secure Sockets Layer (SSL),
Transport Layer Security (TLS) and Secure Shell (SSH), operate in the upper layers of the TCP/IP model [7].
The section stipulates the base architecture for IPSEC as revealed in Figure 20 [8]. It pronounces how to
provide a set of security services for traffic at the IP layer, in both the IPv4 [9] and IPv6 [10] environments.
IPSEC is a set of protocols operating at the OSI architecture model Network Layer three by extending the
IP packet header to support secure exchange of packets and provides the ability to encrypt any higher
level messaging.
Architecture
ESP Protocol
AH Protocol
Encryption
Algorithm
Authentication
Algorithm
Domain of
Implementation
Key
Management
Figure 20: IPSEC architecture
Figure 20 defines how the various components of IPSEC interact. IPSEC supports two security services:
1. Authentication Header (AH) [11, 12,13],and
2. Encapsulating Security Payload (ESP) [12,13,14].
The former provides authentication of the sender and the latter provides both authentication of the
sender and encryption of the data.
IPSEC supports two encryption modes:

1. Transport, and
2. Tunnel.
The Transport mode encrypts just the upper layer headers and data payload of each packet. The more
secure Tunnel mode encrypts the IP header, upper layer headers, and data payload.
In order for IPSEC to function properly, the sender and receiver must share a public key. This is done
through a protocol known as Internet Key Exchange version 2 (IKEv2) [15]. The protocol allows the
receiver to get a public key and authenticate the sender.
A fundamental construct in IPSEC is the Security Association (SA), which establishes a basic connection
with security services. An SA is specified at a minimum with a 32-bit Security Parameter Index (SPI).
IPSEC has been deployed widely to implement Virtual Private Networks (VPNs). As such, segmented links
may be securely networked with IP using encrypted tunnels. Since the routers perform the
encryption/decryption, the secure applications need no local cryptographic support.
Authentication Header (AH)
The AH service is used to provide data integrity, data source authentication, and replay protection
capability. The entire packet is authenticated. The authentication header format is shown in Figure 21
below:
0
78
Next Header
15 16
Length
Security Parameter Index (SPI)
Sequence Number
Authentication data
Figure 21: Authentication Header
31
Reserved
The Next Header is an 8-bit field that specifies the type of data contained in the payload. The Length
field specifies header size in 32-bit words, minus two, and the reserved field is set to zero. The Security
Parameter Index is a 32-bit number that provides the SA related to this packet. The Sequence Number
keeps track of the number of packets incrementing by one for each packet. The Authentication Data is a
variable length field that contains the Integrity Check Value (ICV). The field size must be a multiple of
32-bits and may contain padding as needed. The sender authentication header works by calculating the
ICV based on the payload, portion of the IP header, a secret authentication key, and a hash function. The
receiver performs the same calculation, and if the two values match, integrity is verified. In addition,
the source address provides authentication, and the sequence number replay protection.
Encapsulating Security Payload (ESP)
Protocol suggested during IPSEC phase-2 for transferring the payload data is Encryption Security Payload
(ESP), as indicated in Figure 22.
Figure 22: Encryption Security Payload

The ESP service is used to provide data confidentiality, data integrity, data source authentication and
anti-play capability. The data and inner headers are encrypted and the entire packet is authenticated,
with the exception of the external IP header. The ESP header is shown in Figure 23 below:
31
Security Parameter Index (SPI)
Sequence Number
Initialization Vector
Protected Data
Padding
Padding Length
Next header
Authentication Data
Figure 23: Encapsulating Security Payload
The two main components of ESP header as indicated in Figure 23 are Security Parameter Index and
Sequence Number, which is elaborates as follows:
Security Parameters Index: Classifies, when used in amalgamation with the destination
address and the security protocol (AH or ESP), the exact security association for the
communication. The receiver uses this value to determine the security association with which
this packet should be identified.
Sequence Number: Delivers anti-replay protection for the SA. It is 32-bit, incrementally
increasing number (starting from 1) that indicates the packet number sent over the security
association for the communication. The sequence number is never allowed to cycle. The
receiver checks this field to verify that a packet for a security association with this number has
not been received already. If one has been received, the packet is rejected.
The ESP trailer contains the following fields:
Padding: 0 to 255 bytes is used for 32-bit alignment and with the block size of the block cipher.
Padding Length: Indicates the length of the Padding field in bytes. This field is used by the
receiver to discard the Padding field.
Next Header: Identifies the nature of the payload, such as TCP or UDP.
The ESP Authentication Trailer contains the following field:

Authentication Data Contains the Integrity Check Value (ICV), and a message authentication
code that is used to verify the sender's identity and message integrity. The ICV is calculated over
the ESP header, the payload data and the ESP trailer.
The Security Parameter Index is a 32-bit number that associates the inbound SA with this packet. The
sequence number is incremented by one for each packet in the SA. The Initialization Vector is provided if
needed by the encryption algorithm. The Padding field can vary in length from 0 to 255 bytes. The
Authentication data contains the integrity check vector for the header and payload. Encryption is
applied first then authentication takes place. The ESP does basically what the AH does except that it
does not authenticate the outer IP header. In addition, it encrypts the payload using a secret key.
Hence, only those who know the key can read the data, thus providing confidentiality.
IPSEC Modes
There are three basic IPSEC modes the transport, the tunnel, and the nested. The transport mode is
used to protect the payload of the packet only. The authentication or encryption and connection
endpoints are the same. The tunnel mode is used to protect the entire packet, which includes the
header. The authentication or encryption and connection endpoints may or may not be the same. The
nested mode is a combination of two or more tunnel modes. Normally a host can use transport or
tunnel mode and a router can use only tunnel mode.
Transport Mode
In the transport mode of operation, the TCP and Application layer data are authenticated or encrypted
between two hosts. Hence the connection and security endpoints are identical.
Figure 24 below illustrates the transport mode format using the ESP header.
IP Header
ESP Header
TCP (Encrypted)
Data (Encrypted)
Figure 24: Transport Mode Format

Tunnel Mode
In the tunnel mode of operation, the IP, TCP, and Application layer data are encapsulated and
authenticated or encrypted between two routers. A host is connected to each router that sends or
receives the authenticated or decrypted packet. The security and connection endpoints are different.
Figure 25 illustrates the tunnel mode format using the ESP header.
Router
Router
IP Header
ESP Header
Net
IP Header
(Encrypted)
Router
TCP
(Encrypted)
Data
(Encrypted)
Figure 25: Tunnel Mode Format

Figure 26 illustrates a tunnel mode established between two hosts connected to two outer routers in a
nested configuration for confidentiality. A second tunnel mode is established between the two inner
routers for integrity. As such the security and connection endpoints are different.
H
Outer
Router
In Router
IP Header
AH
Inner
Router
Out Router
IP Header
Net
Inner
Router
ESP
Outer
Router
IP Header
TCP
(Encrypted)
(Encrypted)
Figure 26: Nested Configuration
Data
(Encrypted)
Internet Key Exchange (IKE)

The IKE Protocol makes it possible for two nodes to negotiate a secure connection by creating a SA. The
SA set of parameters is only for one direction of data flow and for only one protocol. During the
negotiation, the IPSEC protocols are agreed upon, the hash function, authentication key, encryption
algorithm, and encryption key data are exchanged, and the duration of security association is set.
6. Key Table Structures with Sample Data (Location: EIDA Data

Centre)
Though the tables displayed above are the key tables that will be used to store transactions but
complete Entity Relationship diagram, Normalized table structure with attribute details will be
presented with the working model. Figure 27 (on the next page illustrates the sample Meta Data
structure of the project) and same strategies will be used for complete development of the project.
Figure 27: Data Base Structure for the project
Though the tables displayed above are the key tables that will be used to store transactions but
complete Entity Relationship diagram, Normalized table structure with attribute details will be
presented with the working model.
6.1.1 Importance of different forms of Normalization and its importance in Database Design
In relational databases the name normalization refers to a reversible step-by-step process in which an
agreed set of relations is replaced by successive collections of relations that have a progressively simpler
and more regular structure. Each step, referred to as a normal form, and defines a set of criterion (the
normal form test) that needs to be met by the different tables of the database. In this sense, to say that
a relation is in a particular normal form is an indication of the conditions that the table has met. Since
the process is reversible, the original set of relations can be improved with no loss of information. As the
normalization progresses to higher forms, the individual collection of relations becomes progressively
more restricted on the type of functional dependencies that they can satisfy and the data anomalies
that they can experience.
The objectives of the normalization process are:
To make it feasible to symbolize any relation in the database.
To find powerful relational retrieval algorithms based on a collection of primitive relational
operators.
To free relations from unwanted insertion, update, and deletion anomalies.
To decrease the need for restructuring the relations as new data types are introduced.
The first two objectives pertain specifically to the First Normal Form; the last two apply to all normal
forms.
The entire normalization process is based upon the analysis of relations, their schemes, primary keys
and functional dependencies. Whenever a relation does not meet a normal form test, the relation must
be decomposed or broken into some other relations that individually meet the criteria of the normal
form test. Initially, E. F. Codd proposed three normal forms that he called first, second, and third normal
form. These forms are generally abbreviated and referred to as INF, 2NF, and 3NF respectively. In
addition to these original normal forms there exist others such as the Boyce-Codd Normal Form (BCNF),
Fourth Normal Form (4NF), and Fifth Normal Form (5NF). The relationship between some of these
normal forms is shown in Figure 28. This figure is sometimes referred to as the normal form "onion".
Figure 28: Hierarchy of the Normal Forms

The complete project is developed keeping in mind the above-mentioned Normalization process,
although in some cases obtaining 4th and 5th normalization was practically impossible.
As the complete system works in an online mode, it is extremely important that the complete project
development follows the query optimization process. Query optimization is the technique, which
produces the results in the shortest duration. The importance of query optimization lies in the fact that
right from the stage where the student reaches Marketing and Registration Department of the
University and Emirates ID being scanned to the continuous real-time data updates and storage. All
these processes identifies the need of adequate query optimization techniques being implemented.
6.1.2 Query Optimization
The cost of CPU of course is always important and it is not uncommon for database applications to be
CPU bound than I/O bound as is normally assumed. In the present section, we assume a centralized
system where the cost of secondary storage access is assumed to dominate other costs although we
recognize that this is not always true. For example, system R uses
Cost = page fetches + w X CPU utilization
When a query is specified to a DBMS, it must choose the best way to process it given the information it
has about the database. The optimization part of query processing generally involves the following
operations.
1.
2.
3.
4.
A suitable internal representation

Logical transformation of the query
Access path selection of the alternatives
Estimate costs and select best
Internal Representation
A query posed in a query language like SQL must first be translated to an internal representation
suitable for machine representation. Any internal query representation must be sufficiently powerful to
represent all queries in the query language. The internal representation could be relational algebra or
relational calculus since these languages are powerful enough although it will be necessary to modify
them from what was discussed in an earlier chapter so that features like Group By and aggregations may
be represented. A representation like relational algebra is procedural and therefore once the query is
represented in that representation, a sequence of operations is clearly indicated.
Logical Transformations
It must be noted that the same query may be formulated in a number of different ways that are
semantically equivalent. It is clearly desirable that all such queries be transformed into the same query
representation. To do this, we need to translate each query to some canonical form and then simplify.
This involves transformations of the query and selection of an optimal sequence of operations. The
transformations that we discuss in this section do not consider the physical representation of the
database and are designed to improve the efficiency of query processing whatever access methods
might be available. An example of such transformation has already been discussed in the examples
given. If a query involves one or more joins and a restriction, it is always going to be more efficient to
carry out the restriction first since that will reduce the size of one of the relations (assuming that the
restriction applies to only one relation) and therefore the cost of the join, often quite significantly.
Heuristic Optimization In the heuristic approach, the sequence of operations in a query is

reorganized so that the query execution time improves.
Deterministic Optimization In the deterministic approach, cost of all possible forms of a

query are evaluated and the best one is selected.
Common Sub expression - In this technique, common sub expressions in the query, if any, are
recognized so as to avoid executing the same sequence of operations more than once.
Access Paths
Access Path is a software component of the DBMS maintains the physical storage of relations and
provides access paths to these relations. Often relations in a database are stored as collection of tuples
which may be accessed a tuple at a time along a given access path. The access paths may involve an
index on one or more attributes of the relation. The indexes are often implemented as B-trees. An index
may be scanned tuple by tuple providing a sequential read along the attribute or attributes in the index.
The tuples may of course be scanned using a sequential scan.
This involves selection of suitable access paths.
1. B-tree better for range queries.
2. Hashing is useless.
A relation may have one or more indexes available on it. In fact, a relation with many attributes could
well have many indexes such that the storage occupied by the indexes becomes as large as the storage
occupied by the relation. Indexes may use hashing or B- tree. They allow very efficient search when the
tuple with a given value of an attribute needs to be found.
The two steps are not separate and are often carried out together. The logical transformations may
involve using one or more of the following techniques:
A query may involve a number of operations and would often be a number of different ways these
operations could be processed. The DBMS must therefore estimate the cost of the different alternatives
and choose the alternative with the least estimate. The estimates of costs are often based on statistics
about the sizes of the relations and distribution of key values (or ranges).
Consider the task of estimating the cost of one of the options. The query optimizer needs to estimate
the cost of join of student and enrolment, the cost of restriction and the cost of joining the result with
subject. To estimate these costs, a DBMS would normally maintain statistics about the sizes of relations
and a histogram of the number of tuples within various key ranges. Given the statistics, the size of the
join of student and subject can be estimated as
n join S student , subject (nstudent Xnsubject )

where nstudent and nsubject are the number of tuples in student and subject respectively and S student , subject
called the selectivity of the join. It is clearly very difficult to estimate S student , subject and most query
optimizers use quite crude estimates. Fortunately, experiments have shown that selection of optimal
plan for processing a plan is not very sensitive to inaccurate estimation of join selectivitys.
Query optimization in a DBMS is carried out by a piece of software often called a query planner. The
query planner is given
1.
2.
3.
4.
5.
The query in canonical form

Information about cardinalities and degrees of relations involved in the query.
Information about the indexes
Information about any fields on which relations have been sorted
Estimates of selectivitys of joins involved in the query
The planner than produces a plan that presents a suggested sequence of operations as well as details of
how the operations should be carried out (for example, when an index is to be used).
Estimating Costs
It should by now be clear that most queries could be translated to a number of semantically
equivalent query plans. The process followed so far should eliminate most alternatives that are unlikely
to be efficient but one is still likely to have a number of plans that could well be reasonably efficient. The
cost of these alternatives must be estimated and the best plan selected. The cost estimation will of
course require the optimizer to consult the metadata.
The metadata or system catalog (sometime also called data dictionary) consists of descriptions of the
databases that a DBMS maintains. The following information is often available in the system catalog:
1. Name of each relation and all its attributes and their domains.
2.
3.
4.
5.
6.
7.
8.
9.
Information about primary key and foreign keys of each relation

Cardinality of each relation.
The number of pages in each relation.
Descriptions of views.
Descriptions of storage structures.
The number of distinct keys in each index.
The number of pages in an index.
Other information including ownership and security issues.
Often these statistics are updated only periodically and not at every update/insert/delete. Also, the
system catalog is often stored as a relational database itself making it easy to query the catalog if a user
is authorized to do so.
Information in the catalog is very important of course since query processing makes use of this
information extensively. Therefore more comprehensive and more accurate information is desirable but
maintaining more comprehensive and more accurate information also introduces additional overheads
for the complete system development and implementation.
6.1.3 Sample ER Diagram for the Project
The section presents the three sample ER Diagrams for the entire project. The sample ER diagram are
presented in Figure 29, 30 and 31 respectively. Figure 29 represents the ER diagram for EMS module of
ERP.
Figure 29: ER Diagram for EMS Module of ERP
Figure 30: AES Module of ERP
Figure 31: TOC Module of ERP
7. Predicted Outcomes of the complete project

The research proposal includes the continuous and real-time academic record of the enrolled student.
The project finds its importance in creating and replicating the data continuously, while they are being
modified. Records are updated from another location, but, through implementation of Authorization
and Content Server, ERP monitors records for changes in the background, using very little system
resources. As soon as a record change is detected, it gets automatically saved to Content Server, part of
EIDA systems.
Such a prediction involves enormous data accessing, storage and replication phenomenon. Query
optimization technique described in the paper expounds the notion in much detail. Implementing such a
system also necessitates massive security apprehensions, and we identified it from the start of ERP
development and implementation.
In nutshell, the project aims to generate the updated record of the students enrolled in various
universities and schools. This helps EIDA to work closely towards the employment of the students based
on the following criterias:
Providing work-ready students information

There are major modifications in the graduate recruitment market, a degree is no longer
sufficient to warranty a graduate a sustaining impending profession. Organizations are
now looking at 'work-ready' graduates with clear evidence of job specific skills in
addition to high level graduate attributes. Providing data of such a graduates helps
employability of the students.
Return on investment
One of the foremost motives students pick to study at university is to boost their career
forecasts. This becomes progressively significant in assessment of intensifying expenses
of education, so persons want to guarantee it has been money well paid. This is even
more of a driver for international students. Maintaining the record of such students,
EIDA can help private organizations operating in UAE for the employability of the
International students, who studied in UAE.
Implementing and maintaining such a system, demands huge challenge, in terms of:
Establishing Security
Maintaining real-time backup of the complete system
Continuous updating the EIDA systems
Development and Implementation of the common ERP systems in all educational institutions
Providing Information both to educational institutions and external agencies, if required
References
[1] C. Le Gal, J. Martin, A. Lux, J. L. Crowley, SmartOffice: design of an intelligent environment, IEEE Intelligent
Systems, vol 16, issue 4, pp. 60-66, August 2001.
[2] P. Fuhrer, and D. Guinard, Building a Smart Hospital using RFID technologies, Proceedings of ECEH06,
Fribourg, Switzerland, 2006.
[3] Huzaifa Al Nahas, Jitender S. Deogun, Radio Frequency Identification Applications in Smart Hospitals, in
proceedings of 20th IEEE international symposium on Computer-Based Medical Systems (CBMS 2007), pp. 337342, Maribor, Slovenia, June 2007.
*4+ Mark Weiser, The computer of the 21st century, Scientific American, vol 265(3), pp.66--75, September 1991.
[5] National Institute of Standards and Technology, Federal Information Processing Standards, Publication 197,
2001.
[6] http://www.ciscopress.com/articles/article.asp?p=25470&seqNum=7; 16/11/2013; 1115hrs.
[7] http://en.wikipedia.org/wiki/IPsec; 16/11/2013; 1145 hrs.
[8] RFC 4301 - Security Architecture for the Internet Protocol.
[9] RFC 2460 - Internet Protocol, Version 6 (IPv6) Specification.
[10] RFC 791 - Internet Protocol version 4 (IPv4); RFC 2474, Definition of the Differentiated Services Field (DS Field).
[11] RFC 4302 - IP Authentication Header (AH); RFC 4305, Cryptographic Algorithm Implementation Requirements
for Encapsulating Security Payload (ESP) and Authentication Header (AH).
[12] RFC 2403 - The Use of HMAC-MD5-96 within ESP and AH.
[13] RFC 2404 - The Use of HMAC-SHA-1-96 within ESP and AH.
[14] RFC 4303 - IP Encapsulating Security Payload (ESP); RFC 4305, Cryptographic Algorithm Implementation
Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH).
[15] RFC 4306 - Internet Key Exchange (IKEv2) Protocol.

Eida Paper

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Eida Paper

Uploaded by

Copyright:

Available Formats

Effective utilization of

2.1 Enrollment Management System (EMS)

Enrollment Management System

Program BBA / MBA ?

Figure 1: Enrollment Management System (EMS)

2.1.1 Hostel Process Flow

Seats are available in

Options - Message send to Sports

Student submit the Passport to HR & PRO

HR updates in the system for VISA and Passport collected

END OF THE PROCESS

Figure 2: Hostel Process Flow

2.2 Administration and Examination System (AES)

For both the cases, the graduation plan varies completely.

Administration and Examination System

Academic Semester Setup

Academic Session Setup

Academic Elements Setup*

Degree Program Setup

Academic Elements Setup

Academic Calendar Setup*

Student Evaluation & Grading Setup*

TENTATIVE GRADUATION PLAN

Figure 3: Administration and Examination System (AES)

2.3 Institutional Research System (IRS)

Submit TOC application Forms

Receives TOC application

Debits TOC Processing Fees

Collects TOC Processing fee

Evaluates the TOC

Fills up the form and verifies

Advice student to pay the

Admin & Exam Dept

Makes photocopy of TOC

Informs the student about

Student will receive the

Receives Mail & SMS

Auto mailer & SMS : Thank you

Figure 4: Complete TOC Process

Prepares draft TOC

Review the TOC application

Prepares final equivalency

Approves the draft TOC

Dean approves the final TOC

IRO forwards to Marketing

Populates the courses according to the

Evaluation of the courses according to

Link to TOC Module of IRO

Figure 5: IRO TOC Evaluation Process

2.4 Human Resource System (HRS)

Check Boxes - Refer VISA

Complete Skyline VISA

Submit of docs of guardian:

Pay required fees Course,

Marketing Officer: Explain the guidelines

Marketing Dept will forward Student

HRD processed the VISA

Mail about the student arrival to

END OF THE PROCESS

Figure 6: HRS-VISA Processing System

Student fill-up VISA Renewal form online.

SSD validates student details i.e.

SSD inform student