Roy Bahian, Sean Maxon, Brian Seo,Michael Rojas, Daniel Sherry,Nor Rabi’ah Mohd Nawawi

Client: Dr. Ali Mostashari

Project Overview

SmartCity Hoboken is a multiyear research initiative between Stevens and the City of Hoboken. If the project is successful, Hoboken will become the first ‘Smart City’ in the United States.

Project Overview

As CS students in the first year of the project, our goals were to1.Develop the infrastructure for a SmartCity mobile

application.2.Implement a variety of widgets to give the

infrastructure some basic functionality.3.Implement security protecting the infrastructure.4.Have a mobile application which is ready to

release on the Android market as version 1.0.

Terminology

• Widget – Refers to an individual feature or service provided by the SmartCity mobile application.

• Query – Refers to information requests from a particular widget of the SmartCity mobile application to the server.

• Response – Refers to the information sent back to the application from the server after a query.

User Interface Design

• The Goal of our UI was to create a simple navigation process for the user.

• Horizontal Navigation Tabs were used to accomplish this goal.

• Tabs separated into categories. (Home, Commute, Emergency, Energy, Environment, MyCity, MyGov)

User Interface Design

• Widgets added into the categorized tabs.

• Much easier to find Widgets when they are categorized.

• Lowered the amount of clicks.

• Made Navigation Intuitive.

Challenge With Tabs

• ActionBar is not supported for Android Versions below Android 3.0.

• Requirements – Android 2.2 and Up.

• Solved with ActionBarSherlock – Allows use of ActionBar for Android below 3.0. Uses Google’s ActionBar when version is above 3.0.

• Allowed Seamless Integration of Tabs.

Voice Commands

• Tabs reduced number of selections.

• Searched for ways to reduce even more.

• Voice Commands added as navigation feature.

• Users who already know their widget can speak the name of the widget. Then transported to the widget without any selections.

Data Flow

Although the data being utilized in each widget varies, the architecture is the same set of client-server interactions for every widget.1.The user’s mobile device sends a query to the SmartCity

server.2.The server interprets the query and constructs a response.3.The server sends the response to the user’s mobile device.4.The mobile device parses the response to construct

viewable output in the form of a map, list, text, or confirmation message, depending on the widget.

5.The output is displayed for the user to view.

Data Sources

Although it depends on the widget, data used to construct query responses can come from a variety of sources.•Crowdsourcing – Information provided by SmartCity users in aggregate.•Historical Electronic Records – Such as Parking Meter usage.•Sensors – Such as those tracking noise, air pollution, and other things (sensors are not relevant to the widgets we developed, but will be in future development).

Widgets Developed

• Parking Availability Finder• Emergency Management• Energy Consumption• Hoboken311

Widgets - Parking

The ‘Parking Near Me’ widget is designed to help users find available metered parking.•Using the GPS coordinates of the user, the server finds parking meters in which it is probable the user can find parking.•Utilize GoogleMaps API to display information in an easy to interpret way.•Pins on the map colored in accordance to probability.

Widgets - Parking

<Screenshot here>

Widgets – Emergency

The ‘Emergency Management’ widget consists of several pieces. It utilizes crowdsourcing to help the city respond to the needs of the citizens in an intelligent way in the case of a disaster response scenario.•User Reporting Forms•City Overview

Widgets – Emergency

<Screenshot of User Report Form>

Widgets – Emergency

<Screenshot of Volunteer/Request forms>

Widgets – Emergency

<Screenshot of city overview>

Widgets - Energy

The ‘Energy Consumption’ widget is built with the simple purpose of making users more energy-conscious.•Users enter electricity/gas readings•AChartEngine API utilized to create graphs according to compare the daily usage of the user to their peers (SmartCity users, Hoboken, and Nationally)

Widgets - Energy

<Screenshot of Submission Form>

Widgets - Energy

<Screenshots of graphs>

Widgets – Hoboken311

The purpose of this widget is to serve as a mobile version of the Hoboken311 problem reporting system.•Simplified UI compared to the website•Voice commands to skip bulky menu navigation.•Ability to report via GPS or Map

Widgets – Hoboken 311

<screenshot of form and map here>

Security

It is our obligation to protect our users.• Protect and hide personally identifiable information (PII)– PII can include: name, address, email, GPS location, energy

consumption, etc– Aggregate public reports to protect individual users– Encrypt data stored on both mobile device and server

• Protect their user account– Encrypt network traffic– Store credentials in as little places as possible– Keep password and data safe if mobile device is stolen

Security

Authentication KeyHMAC(MK, “auth”)

Server Encryption KeyHMAC(MK, “server_enc”)

User Password

Master Key (MK)

Client Encryption KeyHMAC(MK, “client_enc”)

A hash that is computed from the user password using PBKDF2 (SHA-256, iterated 10,000 times) is used as the master key. The master key is never stored or transferred to the client or server. The master key is used to derive additional keys for different functions.

MK = PBKDF2(salt, password)

Derived keys are computed using the HMAC (SHA-256) of the master key and a designated string. With derived keys, we are able to use multiple keys for different functions, but only require the user to keep track of one password. The derived keys are stored on the server, and may be transferred to the client or server when requested.

Why this approach? The HKDF approach allows greater security for a few reasons:• Both the master key and the

password are not stored on the server or client

• Both the master key and the password are not sent over network traffic between the client and the server

• Only the salt that the server computed, the authentication key, and the client encryption key may be sent over the network.

• Only the authentication key is stored on the client.

SecurityClient Server

Request salt be re-computed, send password

Re-compute salt

Compute MK with new salt & user password

Compute derived keys using MK

Re-encrypt database record with new server encryption key

Verify password by computing authentication key with old salt and authenticating

Respond with success/failure

Proceed with first-time login

Security PrecautionsSince only the authentication key is stored on the device (and not the master key or password), the malicious user does not know the password. We can authenticate the legitimate user by using the password to compute an authentication key and verifying it against the one stored on the server.

Future Development

As mentioned before, this is a multi-year initiative. Future CS senior design groups will build on top of our infrastructure. Groups from other disciplines will be working on other aspects of the project as well.

Questions?