1. Roy Bahian, Sean Maxon, Brian Seo, Michael Rojas, Daniel Sherry, Nor Rabi’ah Mohd Nawawi Client: Dr. Ali Mostashari

2. 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.

3. Project Overview As CS students in the first year of the project, our goals were to 1. 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.

4. 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.

5. Widgets Developed Parking Availability Finder Emergency Management Energy Consumption Hoboken311

6. 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)

7. 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.

8. 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.

9. 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.

10. 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.

11. 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).

12. 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.

13. Widgets - Parking

14. 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

15. Widgets – Hoboken 311

16. 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

17. Widgets – Emergency

20. 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)

21. Widgets - Energy

23. 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 user-submitted 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

24. Security Authentication Key HMAC(MK, “auth”) Server Encryption Key HMAC(MK, “server_enc”) User Password Master Key (MK) Client Encryption Key HMAC(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 The password is not sent over network traffic between the client and the server The master key is only sent over during registration and password resets Only the salt that the server computed, the authentication key, and the client encryption key may be sent over the network during login Only the authentication key is stored on the client.

25. 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.

26. Questions?