Author: alexl3

This week I worked on the final features and integrations for the app. For functionality, I tested and made changes to the phone to server interactions. This includes being able to register a lock with a lock ID, where a POST request will be sent to the server and a phone’s unique ID will be added to the lock’s accepted phone IDs. Phone IDs are generated by the server, where upon opening of the app, a GET request will be sent to the server for a randomly generated phone ID (unique). Anyone with a link can get a phone ID, but actual authentication passes the phone ID  to the NFC reader for authentication, which sends phone ID and lock ID to server for authentication. This ensures that anyone with the app will need to register a lock ID before authenticating. Because HTTPS is used, middlemen should not be worried about. Another feature planned was to do remote lock/unlock, where a similar scheme of exchanges are used, except instead of using NFC to send the phoneID, an endpoint will be set up for the Raspberry Pi and the phone will make HTTPS requests to send the phone ID. The endpoint still needs to be set up, we are trying to configure certificates and setting up to accept HTTPS requests. This feature may not be included in our final product, because functionally if the user wanted to lock the door using this feature, he/she would need to open the app and it would defeat the whole purpose of NFC’s quick and easy message passing. We considered a separate PN532 chip on the other side of the lock for locking, but this is not feasible as RPi does not support this. We are finally considering a button used as a lock measure, which will be easy to add because we are done with all of basic work and integration. For the remote lock, to elaborate, using it remotely also may cause problems with power consumption, because setting up the raspberry pi as an endpoint is wasteful in terms of energy.

We are on track because we are done with a prototype aside from the component housing. Next week we should have the final product ready, and will be considering additional features to improve the ease of use of our product.

This week I have finished writing the NFC reader code and the host card emulation code. Both work well, and the reader can retrieve a simple token from the phone, which I designated as “1234321” (registering a phone ID is not implemented yet). The reader code basically does 3 things: (1) set up the connection with the pn532 chip using the i2c ports, (2) send and receive information between the pn532 and an Android phone, and (3) send this information to an AWS server using a web socket connection. The sending and receiving of information on the pn532 works by sending a packet called APDU to the phone, which the phone will the use to find what type of request it is, and send back a response APDU to acknowledge or respond with data. Because we only have one type of data (just the phone ID), we decided to just have one exchange (select application->phone ID), but this will be changed later. The response is therefore just the phone ID. A typical smart card reader execution will send a first APDU to select the application (phone responds with success), then another APDU to retrieve any type of data from the phone (phone responds with data). This will be fully implemented today or tomorrow.

To clarify, for our MVP, we simply request a phone ID from the raspberry pi, and send this ID to the server for authentication. The raspberry pi will request the server to authenticate this ID. If the server has this ID in the database, then it will respond with yes, otherwise no. This is a simple implementation, but obviously more layers of security will be added in the coming weeks.

The web socket is done in C. Originally, Michael had code written in Python, but that would mean I would need to start 2 processes and have some sort of inter process communication using a file or stdout. This is not ideal, so I decided to rewrite the client side program in C, which does a simple socket connection and send and receive commands with the APDU response from the phone. The client server code is not completely finished yet, but it should be done by today or tomorrow.

This week is mainly on schedule if I can finish the client server code by today or tomorrow. The only missing work is to implement more security, but I expect to combine that work with the work I had planned for next week (UI development, which should not take long).

This week I wrote the Host Card Emulation portion for the phone app. Because the HCE is designed to work no matter what application is open, the HCE is implemented as a Service that runs when APDU (Application Protocol Data Unit) is detected (basically detect when reader is trying to talk with the phone). To register the Service class, the application Manifest (ApplicationManifest.xml, XML file containing various information about the application and its context) needs to be updated with the Service and its NFC permissions. An Intent Filter is added in the manifest so the phone knows to run the service when APDU detected from reader. Also, a new XML file containing APDU specific information is added, and the Service is updated to route to this new XML file, dubbed apduservice.xml. The most important information in this file is the AID filter (Application ID), which is basically information that the reader must send and the app must have to know what to run when communicating. Finally, a class extending the HostApduService class made specifically for APDU was created. This class defines functions to process APDUs, which is basically a byte stream decoder. To process an APDU, I needed to look at sets of bytes in the APDU, which has various data fields. The format for APDU is defined, so I just needed to check indices of the APDU, which is a byte[] (byte array) as exposed by the HostApduService interface. Finally, another byte[] is returned from this function as a response, but I have not yet implemented what this byte [] will be. It should be secure and unique. UID (NFC) should not be used because another NFC tag could easily mimic the same UID. The security options should include some phone specific unique token, possible distributed by the server. I am looking into several security options, but this should be work for next week. For the near future (Sunday, Monday, and Tuesday), I am working on getting the NFC Reader code and this code to communicate correctly.

I also worked on wiring the Raspberry Pi and the NFC reader, which was work planned for next week. This portion was fairly straightforward, but required some time to debug some hardware specific components. I also tested the NFC reader with both a smart card and an Android phone using a downloaded tool that reads bytes from i2c pins. The NFC + RPi interface worked for both the smartcard and the Android.

I also started on writing the NFC reader code, which needs to precisely send the APDU to the phone, and respect the protocols needed (ISO…). There isn’t a lot of information about this online, so I am basically just testing by trial and error. For example, the mentioned AID filter needs to include a first byte that defines what type of AID it is. Online example use “registered” AIDs, instead of proprietary ones that don’t need registration. If they use registered AIDs, then won’t another application with the same AID be problematic because they are both defined to have the same AID filter on the Android phone? Thus I will probably need to define my own “proprietary” AID. I am still fairly confused about this, so I will work to understand and implement this portion of the reader tomorrow.

I believe by next week, I will have working reader and phone code, and I will implement the security for the reader/phone. The security should simply be some overhead for each component, so it should not take that long. After this work is finished, the following week will be working on the UI features for the phone app (HCE is more like a background service). This will include simple features like registering a lock (will probably work with Michael on that). This will not take more than a few days because I did sufficient learning on basic Android App Development in the previous week, and already have basic XML layouts. I will be done with my portion of the project then, so will help out on other portions or continue to improve my portion of the project.

Based on the Gantt Chart, I am on task. Some of the tasks are currently being done concurrently, so the schedule may be slightly off for some of the tasks. This is because I need to develop each component at the same time to get a better understanding of the tools and frameworks surrounding the whole system. Also, being able to test the components is necessary.

 

Sorry for the image quality. Here, a tool called nfc-poll is being used to detect NFC reader input. The NFC reader had to be registered in the Raspberry Pi config (I2C), then running this tool allowed for the UID, ATQA, and SAK to be read (NFC specific information). The text is blurry but I ran the tool twice to check if the smartcard had the same UID to make sure the NFC was working correctly. I also tested with the smartphone when we were working as a team earlier, but I forgot to take a photo.

This week I worked a lot on understanding Android App development. I am behind on schedule due to recent interviews, but I will have this whole week to catch up. I think the challenge for me was that although the design and conceptual parts of the app and development were easy to think through and develop, actually working in Android Studio has a steep learning curve. Trying to compile even a simple app can cause a lot of errors if you don’t understand the Android development framework. For example, without refactoring, using the XML tool (view the app’s GUI while editing) to add or remove a simple button can cause a lot of dependency errors. The great thing about the Android Studio though is that there are a lot of visual tools like the XML tool, or even an Android emulator whenever you run the code. For Android app development, I learned a lot more about Java, fragments (behavior or portion of UI), and activity (general term for single thing users are focused on) lifestyle. Finally, I put together some draft app layouts (with the add button for the home screen) and routed it to a lock registration screen. I am still working on how to save the data using text input with the developer tools I have. In summary, there were practical challenges that I didn’t expect to have, but I expect to be back on track next week because I will have a lot more time.

This week I worked on the design presentation and report for the App and NFC portion of our project. There was a lot of NFC specific research I needed to do in order to figure out how our project was going to work. NFC on Android has some specific tools and functionality to assist with peer to peer NFC communication such as the tag dispatch system and host based card emulation. I also drew up the wireframes for the app, worked out app to server communication, and sketched a plan for app to NFC interaction.

Next week I will be working on early development of the Android app. I was going to work on development this week, but we had to do the design presentation and the design report which took up more time than expected.