Master’s Project Report
Transform Secure Data Discovery SDD into
An IPhone application
Roshnee Ravikumar
A Project
Submitted to the Graduate School Faculty of the
University of Colorado at Colorado Springs
In Partial Fulfillment of the Requirements
For the Degree of Master of Engineering in Computer Science
Department of Computer Science
Spring 2013
1
This project for the Master of Engineering in Information Assurance degree by
Roshnee Ravikumar
Has been approved for the
Department of Computer Science
By
_______________________________________________________________________
Dr. C. Edward Chow
Date
_______________________________________________________________________
Dr. Chua Yuan
Date
________________________________________________________________________
Dr. Jia Rao
Date
2
Abstract:
The Project deals with developing an IOS APP for the secure delivery discovery project.
The Project emphasis on how web based interface can be integrated into an IOS APP.
The service allows users to browse and download applications from the iTunes Store
that were developed with the iOS SDK published through Apple Inc.
The Project is developing an App for the attorneys for the district attorney office
Colorado Springs. Application has the functionality for registering for a new account on
the iPhone and set up a framework in place for extending the existing capabilities for
adding more screens.
The application uses a simple client server model where the client is the IPhone. The
Server is developed using a RESTful API’s which has resulted in ease of development and
helps with maintainability.
One of the main challenges in developing an application is to authenticate a user and to
maintain the state of the clients accessing the system. In this project, I have
implemented a mechanism to authenticate users using a stateless authentication
technique. This technique forms the foundation of any extensibility that could be done
on this project.
3
TABLE OF CONTENTS
1. Introduction to Discovery Project
1.1 Motivation for Discovery Project
1.2 General Description of SDD web Application
1.3 Motivation for developing a mobile application
2. Prior Work
2.1 Identifying changes and the reasons for change in the Existing System
3. Design Guiding Principle
4. Architecture Decisions:
4.1 Domain Layer:
4.1.1 Overview of REST Service and ASP .NET Web A
4.1.2 REST Web Service in .NET
4.1.3 SDD and REST
4.1.4 Server Side Statelessness:
4.2 Data Layer:
4.3 Presentation Layer:
5. Design
5.1 Securing the Password:
5.2 Routing and URL
5.3 Data Transfer Objects
5.4 Content Type for HTTP Response
5.5. Authenticating User
5.6 Class Diagram:
6. Developing an IPhone Application
7.Future Work
8.References
4
1. Introduction to Discovery Project
Discovery is the term used to describe the information, facts, documents, and other
materials the District Attorney’s Office will rely upon to prosecute a case. The
accused person or defendant in a case has the right to obtain access to this
information to prepare their defense. After a case has been referred to the office by a
law enforcement agency and charges have been filed, the office will open a case
against the defendant. All investigative reports and other information are placed in
the case file as it is received and will become discovery in the case. The discovery will
then be available for purchase by defense counsel or the defendant. The District
Attorney has an “all or nothing” policy with regard to discovery. All requests for
discovery will be treated as continuing requests until a case is closed. Additional
discovery received in a case will be processed, provided, and must be paid for until
the case is closed or counsel notifies us they have withdrawn.
1.1 Motivation for Discovery Project.
Historically discovery technicians burn a CD or DVD of discovery information
pertinent to a case. Only one case of information is put on a disk at a time. Then
these technicians have had to in person at our office sell and deliver the disk. This
forces the customer to also come to our office.
The introduction of the discovery eliminates the requirement for the customer to go
to the office, eliminate the interaction time to sell and deliver the information to the
customer, thus saving time and labor(money). It provides a large convenience for the
customer in providing availability 24x7.
1.2 General Description of SDD web Application
A secure web page will be created where invited customers can apply for an account
with the Discovery department. They will fill in their entire name, business name, and
complete contact information. They will "Apply". Our Discovery technicians will
receive an email of the Application information. An internal web page will allow the
5
technicians to manage applications by either approving or disapproving. If approved
all information will be saved into a membership database table. Applicants are to
receive an acknowledgment via email to that effect. An FTP public file directory tree
will be supplied to the Discovery technicians. They will have full ownership rights over
this. Discovery technicians will encrypt discovery information before publishing. On a
DAO case-by-case basis, they will create a folder (case number) and place all
discovery information that was historically put on a CD / DVD into that folder,
Customer cannot access information until Discovery paid for. Additionally, customer
cannot pick up any discovery until acknowledgement of all discovery cases ready
(must check Y N still want for every case ready) before proceeding into any case
folder for discovery pick up. This is to meet our needs to know if they are not going to
pick up any discovery. Technicians will set permission to only allow that club member
to read that folder for a case they were notified is ready. The eDiscovery Application
will send an auto email to the customer that the information is6eady for pickup from
that site. The customer will have 72 hours to go to the secure web site and login for
pickup. The customer login page will be a secure web site page. Once validated, it will
take the customer to their directory tree of case(s). Every case of discovery ready will
be listed on that page. They must acknowledge that they still want or are rejecting
each case of discovery is ready. Once they acknowledge all cases, they can simply
drag and drop their discovery from the secure FTP server to their local PC. A traveller
TrueCrypt copy will be placed with the encrypted discovery for the customer to
decrypt it. An email will be generated that they logged into the site to our discovery
department. In addition this will set an auto delete flag on the database server which
will auto delete the FTP case folder one hour after customer access. All information
that is 72 hours old will be automatically deleted if not picked up before then. Daily
and weekly automatic emails will go to leadership reporting what cases where placed
for pick up, what customers logged in to pick up, and what cases were auto deleted
due to no pickup. Customers can pick-up unlimited number of their cases ready for
pickup by simply browsing from case number to case number folders.
1.3 Motivation for developing a mobile application
Mobile applications are changing the way the World Wide Web is accessed. It also
unleashes a wide variety of problems as compared to traditional web applications.
6
Since SDD already has a web application in place, it would be interesting in
investigating how the design of a web application system would need to change to
ensure that it is mobile ready. This project also gives me an opportunity to investigate
the importance of Software as a Service and separating the API from the client to
make it available to multiple kinds of client.
2. Prior Work
The SDD project started off as developing a web application. As part of this process,
the SDD project team clarified the requirements and solved some important research
hurdles like secure file transfer and one version of authentication.
2.1 Identifying changes and the reasons for change in the Existing System
A traditional ASP web site was developed earlier in 2012 to address the main
requirements listed in the SDD requirement specification. The application was
designed and developed only to cater for a web interface. The following shortcoming
makes it very difficult to use the same code via mobile application.

No Clearly defined API’s for server side functionality: With only access to the
Login scripts and the databases, my first step was to understand the login scripts
and the overall design of the code. I realized that the logic for authentication was
not centralized and could not be reused via objects.

Coupling of Presentation, domain and data layers: The existing design had a
conceptual. All the code that interacted with the presentation logic and the
domain logic were interspersed in the same place.

No ability to mock data and logic: There was no ability to mock out parts of the
system. It is a all or nothing approach.

Less Maintainable: With all the code written in one place, it makes it very difficult
to maintain the code. One change in the code will result in the need for testing
the whole system
7
3. Design Guiding Principle
In developing an application used by multiple kinds of clients, it is important to
conform to the following principle

Separation of Concern: The Principle of Separation of Concerns states that
system elements should have exclusivity and singularity of purpose. That is to
say, no element should share in the responsibilities of another or encompass
unrelated responsibilities. The establishment of boundaries achieves separation
of concerns. A boundary is any logical or physical constraint which delineates a
given set of responsibilities

Loosely coupled: With separation of concern in place it is easily possible to
achieve loose coupling between objects.

API driven: With the industry moving towards service oriented development,
driving the application through good strong API would result in multiple uses of
the code

Light weight client operations: With the API proving strong interaction and
functionality, the client operations would only need to worry about presentation
and give complicated operation on server side. In mobile we do not have the
luxury to have the same computational capabilities as on the server. Moving
operations to server side would help in improving performance.

Better extensibility and maintainability: With software, the one thing constant is
change. Hence the system and the classes that compose the system must me
open to extensions. This makes it easy to add more functionality and maintain
the system
4. Architecture Decisions:
The architecture of the system consists of a three tiers
1. Domain Layer: Web Server
2. Data Layer: MS SQL Server
3. IPhone: Presentation Layer
8
4.1 Domain Layer:
Domain layer is mainly wrapped into a web service. The web service is a ASP.Net
Web API REST service.
4.1.1 Overview of REST Service and ASP .NET Web API:
REST defines a set of architectural principles by which you can design Web services
that focus on a system's resources, including how resource states are addressed and
transferred over HTTP by a wide range of clients written in different languages.
REST stands for Representational State Transfer. (It is sometimes spelled "ReST".) It
relies on a stateless, client-server, cacheable communications protocol -- and in
virtually all cases, the HTTP protocol is used.
A REST API is a set of operations that can be invoked by means of any the four verbs,
using the actual URI as parameters for your operations. For example you may have a
method to query all your accounts which can be called from /accounts/all/ this
invokes a HTTP GET and the 'all' parameter tells your application that it shall return
all accounts.
REST Web service follows four basic design principles:

Use HTTP methods explicitly.

Be stateless.

Expose directory structure-like URIs.

Transfer XML, JavaScript Object Notation (JSON), or both.
One of the key characteristics of a RESTful Web service is the explicit use of HTTP
methods in a way that follows the protocol as defined by RFC 2616. HTTP GET, for
instance, is defined as a data-producing method that's intended to be used by a
client application to retrieve a resource, to fetch data from a Web server, or to
execute a query with the expectation that the Web server will look for and respond
with a set of matching resources.
9
REST asks developers to use HTTP methods explicitly and in a way that's consistent
with the protocol definition. This basic REST design principles establishes a one-toone mapping between create, read, update, and delete (CRUD) operations and HTTP
methods. According to this mapping:

To create a resource on the server, use POST.

To retrieve a resource, use GET.

To change the state of a resource or to update it, use PUT.

To remove or delete a resource, use DELETE.
4.1.2 REST Web Service in .NET
Using the REST concepts in a providing an API for the web will help in creating
lightweight web services. . NET used REST in its template, which is called Web API. A
RESTful web service consists of the following

A Base URL. For Example: www.example.com

Type of data transfer either by XML or JSON

Operations like GET, POST, PUT and DELETE
4.1.3 SDD and REST
In SDD, we do not have any new complicated requirements that would need
anything more complicated than a REST service. Hence the choice was made to use
WEB API and the REST behavior that comes with it. All the code is modularized and
reengineered to be included in the web service. Multiple presentation layers like the
IPhone, Android or even a web site can use the service. This provides for a more
extensible and a scalable design which will be easy to maintain.
4.1.4 Server Side Statelessness:
Stateless server-side components, on the other hand, are less complicated to design,
write, and distribute across load-balanced servers. A stateless service not only
performs better, it shifts most of the responsibility of maintaining state to the client
application. In a RESTful Web service, the server is responsible for generating
responses and for providing an interface that enables the client to maintain
10
application state on its own. A stateless Web service generates a response that links
to the next page number in the set and lets the client do what it needs to in order to
keep this value around. Authentication is one aspect in SDD which has bee
maintained stateless on the Server side. More on stateless authentication is
provided in the authentication section.
4.2 Data Layer:
The Data layer mainly consists of a SQL server database. The decision to use SQL
server was done as part of a legacy decision that was done as part of the initial
development of the SDD web site. This decision still holds strong since SQL has
provided the users with query capabilities and a strong data store. SQL server works
very well with .NET technologies especially ASP.NET Web API.
4.3 Presentation Layer:
XCode for IPhone device handles the interaction logic for this project. IPhone app
development is done using Objective C and using the design principle of Model View
and Controller. The Controller delegates complex actions by doing a simple REST
web service call. The Server side handles all the complicated domain and data layer
operations.
Xcode is tightly integrated with the Cocoa and Cocoa Touch frameworks, creating a
productive and easy-to-use development environment that is powerful enough to be
the same tools used by Apple to produce OS X and iOS.
Since the server is stateless, it becomes the responsibility of the presentation layer
to maintain the state of the user. Every request send to the server would need to
attach a authentication token to it before sending the request. Any response that it
gets from the server would need to update the authentication token which would be
used the next time a request is sent.
11
5. Design
5.1 Securing the Password:
In any web-based application, one of the crucial steps in ensuring security is by
having a system of authenticating a valid user. In SDD, we achieve this by proving
every user unique User Id and a password of user’s choice. The password is private
to a user and hence it is encrypted before storing it in the database. A cryptographic
salt technique [1] is used before storing the password in the database. Every
password is encrypted with a new randomly generated Salt. The Salt is also stored in
the database for decryption purposes.
Figure 1: User Authentication using User Name and Password
12
Figure 1 visually explains the process of authenticating a user using a user name and
a password. When the user first creates an account, the system generates a random
salt that is used to encrypt the password. Both the salt and the encrypted password
is stored in the database.
When the user returns, the password entered by the user is now hashed with the
salt that was stored for that user. If the passwords in the database and the newly
hashed passwords match, then the user is authenticated.
Using a secure HTTP protocol ensures the security of the password reroute
5.2 Routing, URL and
One of the central concepts of web API design is the URL with which the resource is
accessed. In this project the service provided and the URL are listed in the table
below
Table 1: Service provided and corresponding URL
Service Provided
URL
Details
{HOST} /api/Client/Details?{Query}
Login
{HOST} /api/Client/LogIn
Register
{Host} /api/Client/Register
As we can see in the above table, the URL design is representative of the service that
it is providing. Login and Register services use HTTP Post and Details service uses
HTTP Get to query domain. [4]
In ASP.NET Web API, a controller is a class that handles HTTP requests. The public
methods of the controller are called action methods or simply actions. When the
Web API framework receives a request, it routes the request to an action. To
determine which action to invoke, the framework uses a routing table.
13
Each entry in the routing table contains a route template. The default route
template for Web API is "api/{controller}/{id}". In this template, "api" is a literal path
segment, and {controller} and {id} are placeholder variables.
When the Web API framework receives an HTTP request, it tries to match the URI
against one of the route templates in the routing table. If no route matches, the
client receives a 404 error.
The reason for using "api" in the route is to avoid collisions with ASP.NET MVC
routing. That way, you can have "/contacts" go to an MVC controller, and
"/api/contacts" go to a Web API controller. Thought we do not need this for our API
implementation, conforming to the standard recommended by MSDN will be
prudent considering the enhancements that could be done to this project.
In this project, instead of using the naming convention for HTTP methods, I have
explicitly specified the HTTP method for an action by decorating the action method
with the HttpGet, HttpPut, HttpPost, or HttpDelete attribute.
5.3 Data Transfer Objects
Data transfer object [3] is an object that carries data between processes in order to
reduce the number of method calls. In SDD, we want to be able to send group of
logical data like client information in one service call. In order to avoid multiple
server calls for composing one object, the possible results are encapsulated into a
Data Transfer object. The fields in the Data transfer objects are very primitive.
The Data transfer objects in SDD are not aware of how it is composed. The object
does not depend upon any of the domain related objects.
5.4 Content Type for HTTP Response
The data that is transmitted between client and server needs to be serialized. This
specified in the default Media type formatter. Web API provides two options for
formatting data: XML and Java Script Object Notation (JSON).
14
In SDD we will be using JSON serialization [7] since it is easier and is turning out to be
one of the top used serialization technique for Web API’s. In order for Web API to
support JSON only, it is required to remove the XML serialization containers.
Here is the sample of the JSON result.
{
"Id": 1,
"FirstName": "Roshnee",
"LastName": "Ravikumar",
"Email": "[email protected]",
"Address": "1420 Austin Bluffs",
"City": "Colorado Springs",
"State": "CO",
"ZipCode": "80918",
"BarLicenseNumber": "LIC123",
"ContactNumber": "123-123-1234",
"CompanyName": "UCCS"
}
5.5. Authenticating User
In the Architecture section, I had introduced the concept of stateless authentication.
This means that the server does not store any information about the state of the
clients that are using the API. This is achieved as follows
1. Client provides user credentials like User Name and Password
2. The Server authenticates the request and sends an Authentication token
3. The Client stores the Authentication token in memory and uses this for every
request it sent to the server.
4. Even request sent to the server is intercepted and checked for the
authentication token. The Authentication token sent my client includes
information required by server to recreate the Authentication token in entirety.
5. If the token generated by server matches the one by client, then the request is
authenticated.
15
In SDD, we use string-signing method to provide data that could be used for
stateless authentication. The data that is signed is a combination of the User Name
and the Time when the server would expire that said token.
Signed Token = SIGN (UserName + ExpirationTimeStamp)
The signing algorithm computes a Hash-based Message Authentication Code
(HMAC) using the SHA1 hash function [2]. This is also called HMACSHA1.
HMACSHA1 is a type of keyed hash algorithm that is constructed from the SHA1
hash function and used as an HMAC, or hash-based message authentication code.
The HMAC process mixes a secret key with the message data, hashes the result with
the hash function, mixes that hash value with the secret key again, and then applies
the hash function a second time. The output hash is 160 bits in length.
An HMAC can be used to determine whether a message sent over an insecure
channel has been tampered with, provided that the sender and receiver share a
secret key. In SDD the server acts as the sender and the receiver since it
authenticates the same token it send. The server computes the hash value for the
original data and sends both the original data and hash value as a single message.
When the server receives an authentication token, it recalculates the hash value on
the received message and checks that the computed HMAC matches its own signing.
Any change to the data or the hash value results in a mismatch, because knowledge
of the secret key is required to change the message and reproduce the correct hash
value. Therefore, if the original and computed hash values match, the message is
authenticated.
In SDD, the secret key is initialized during bootstrapping of the server. This method
was selected in contrast to having it stored in the database, which is less secure. We
use a Global unique Identifier a.k.a. GUID as the secret key.
The SHA-1 (Secure Hash Algorithm, also called SHS, Secure Hash Standard) is a
cryptographic hash algorithm published by the United States Government. It
produces a 160-bit hash value from an arbitrary length string.
16
HMACSHA1 accepts keys of any size, and produces a hash sequence that is 160 bits
in length.
In SDD, since we are using the timestamp as one of the components of the data to
be signed in Authentication, it is important to have a reasonable timeout, which is
configurable. This time out is currently configured at fifteen minutes.
Figure 2: Authentication of Multiple Requests
5.6 Class Diagram:
The classes and the objects instances have been used by carefully considering some
basic design concepts in place. The classes and its responsibility is listed below
SDDDataAccessLayer: This is a Singleton object i.e. only one instance of the
object exists in the lifetime of the process. This object manages the interaction
of the domain layer with the underlying data, which resides in the SQL server.
AuthenticationProvider: This is a helper class that provides functionality used by
its client to Create Salt, Encrypt and check equality of the password.
17
ClientDetailsDTO: This is a Data Transfer object that stores all the client details
used by the Clients
AuthenticationToken: Used for authenticating requests sent by the user
ClientCredentialsDTO: This is another Data transfer object that stores the client
credential information like User name, encrypted password and the salt used for
encryption
Figure 3 Class Diagram for Server
18
6. Developing an IPhone Application
IPhone development starts with installing XCode [5]. XCode provides with basic
utilities required to perform basic programming tasks. All the interaction logic
happens using the IDE and operations are programmed using Objective C.
Similar to C, Objective C contains a header file (.h) and an implementation file (.m).
In SDD and especially in IPhone development, it is recommended to follow the
Model View Controller Pattern. It is a high-level pattern in that it concerns itself with
the global architecture of an application and classifies objects according to the
general roles they play in an application. In MVC there are three kinds of objects [6]

Model objects represent special knowledge and expertise. They hold an
application’s data and define the logic that manipulates that data

A view object knows how to display, and might allow users to edit, the data
from the application’s model. The view should not be responsible for storing
the data it is displaying

A controller object acts as the intermediary between the application's view
objects and its model objects. Controllers are often in charge of making sure
the views have access to the model objects they need to display and act as
the conduit through which views learn about changes to the model
In traditional MVC, the view interacts with the model to display model data
elements. In Cocoa version of MVC, the controller acts as a mediator between model
and the view. This is an important distinction since it changes the paradigm from
tradition web development, which uses a more traditional MVC pattern. Below
Diagrams lists the difference.
In SDD, the development started by having a base login view. I followed the cocoa
version of MVC pattern and did most of the programming only in the Controller. To
navigate through views, I added a navigation controller that starts with the Login
View, but the different Controller then stacks up screens like Register or Landing
page based on user input or server response.
19
7.Future Work
In this project, one of the main topics or challenge that I faced was to decide to
refactor the existing SDD web application code. With some practical implementation
of RESTful API’s, I believe while developing a web application, extensibility need to
be considered. I would recommend that as an exercise, the SDD web application be
refactored to give two API’s ASP MVC for web and a REST API for the mobile world.
The underlying logic can be encapsulated in a Domain Layer which uses a data layer
to interact with the database. Below diagram, visually depicts this.
Figure 4: Future Work
20
References:
1. Guide to Cryptography:
https://www.owasp.org/index.php/Guide_to_Cryptography
2. HMACSHA: http://msdn.microsoft.com/enus/library/system.security.cryptography.hmacsha1.aspx
3. Martin Fowler, 2003, Patterns of Enterprise Application Architecture, Pearson’s
publishing
4. ASP. Net Web API: www.asp.com/web-api
5. XCode and Cocoa: https://developer.apple.com
6. Concepts in Objective C Programming : developer.apple.com
7. JSON serialization: www.json.org
21