Posted on

Team status update for 11/14/2020

This week, we were able to prevent our subsystems in our MVP during our project demo. Alex Li worked on Android app UI development and functionality, Alex Xu worked on lock mechanism and casing CAD design, and Michael worked on transitioning to REST API and developing its security. We met briefly for our project demo to show off our work so far to Vyas and Jiaqi, and we also talked about how to adhere to our remaining schedule as we wrap up the capstone project.

One risk we need to factor in is the delay in TechSpark services that may crop up as we approach the end of the semester. The self-serve 3D printers are mostly unaffected, but just to be safe, we’d like to get as much of the CAD designing done as soon as possible to avoid any pitfalls. The COVID-19 case at TechSpark unfortunately limits working as closely as we would have liked with TechSpark staff, but we will try our best to work with what we have left. We think that optimistically we’ll still be okay in following our schedule despite these potential delays.

A minor change to the existing design of the system was the addition of the REST API to our system. It will take the place of where we originally wanted to open a WebSocket connection. This change was necessary due to a couple of compatability issues WebSockets were causing to the remainder of our system, and we’re confident that this switch can be done within a fast timeframe and maintain the same level of security and speed we previously had aimed for.

Next week, we plan to finish the two aforementioned tasks related to REST API and CAD, and we’ll also develop functionality and implement a better UI to our Android application.

Posted on

Alex Li’s status report for 11/14/2020

This week I wasn’t able to get as much work done as I intended due to job interviews and coursework. I originally intended to complete the UI development + all the app functionality for this week, but was not able to. Today, tomorrow, and Monday, I expect to complete all the UI development.

Here is an image of the app so far. I have a simple home screen which should display all the locks by name as buttons to click on and get more information. Clicks on the lock buttons will bring up a new Activity, where Username and time of unlock will be provided in a list for the past 30 days. At the bottom of the home Activity, there will be 2 buttons, 1 being lock and the other being unlock. These will provide functionality to unlock and lock the door remotely. I have not yet implemented these portions yet, but they should all be complete in the next few days because I will be working extensively on these parts. There is a plus button in the top right representing lock registration, which will bring up the Register Lock activity.

Here is the lock registration. There are a few text fields to fill out. This sends HTTPS requests to the local AWS server for these fields to be created. This should create data fields on the AWS server for a specific lock. I have not yet tested out the HTTPS requests yet, but will get to that tomorrow when me and Michael will work together to verify that the correct information is being inputted. There can be multiple errors, which will cause an error message to pop up right above the register lock button. For example, if the fields are not all filled out or if the lock ID is already registered, there will be an error message. After the request, there will be a response from the server with success or fail, and the user will be sent back to the home screen. I will also add a back button, which should take minimal time.

Overall, I am a bit behind schedule, but I plan to catch up this weekend and on Monday. I should be done with everything soon, and I have a really clear picture of what to implement and how.

Posted on

Michael Chen’s status report for 11/14/2020

This week was a rough week for me since I got sick, so I was not able to get as much work done as I was hoping. Since we made the switch from WebSocket to REST API, I was able to implement a couple of endpoints for the RPi to communicate with the web server and retrieve a response letting it know if should open the door or not. I also worked on the REST API security to make it the same as it was for the WebSocket. We require that any request appends two IAM tokens that the server authenticates before doing any further processing.

Next week, I will be working with Alex Li to get the server communication set up from the phone. We will be implementing the phone and lock registration endpoints so the phone can contact the web server securely and register new phones and locks. Once registration is set up, the core functionality of the server should be complete and we can begin looking at any additional features we’d like to implement.

No risks to report for now, I believe we are on good track to finish and work on stretch goals as well.

 

Posted on

Alex Xu’s status report for 11/14/2020

This week I helped my group ensure that the demo went smoothly on Wednesday. After that, I had originally wanted to go into TechSpark to further discuss my 3D printing-related plans, but I was told that there was a positive COVID-19 case in TechSpark, so I instead went back to Autodesk CAD and watched tutorials. A friend of mine mentioned that making the parts may be more easily done in Autodesk Inventor and told me that connecting the motor horn could be done more easily by melting the plastic printed part and molding it with the motor horn base, and I plan on talking more with him about a better adhesion method as he’s done this before. I think running by the overall box housing by him as well would be a good idea too.

Open issues: going from CAD/Inventor to 3D printing. I’d like to create at least one of the two as a prototype, assuming the self-serve 3D printers still work. I’ll prioritize the motor horn/motor horn connector first, as that’d allow for a proper lock mechanism, and the aesthetics can come later.

Next week: 3D printing. Preferably both of these being done as prototypes so I will have images next week, but if not at least getting the motor horn (connector) will get us significantly closer to what our project will be.

Posted on

Michael Chen’s status update for 11/7/2020

This week, I worked with Alex Li and Alex Xu to integrate the server communication code onto the RPi with the NFC reader and servo motor code. We are now able to send information from the RPi that is received from scanning the phone to the server, and the server will reference this data against the database to see if the user is permitted to open the door. If they are, then the server sends a message telling the RPi that it should unlock the door, and it drives the motor to unlock the deadbolt. I also added IAM authentication to the WebSocket connection so that any client that wants to connect to the WebSocket must send valid and authorized IAM keys as query string parameters. If these keys are missing or invalid, then the WebSocket will reject the connection.

Now that our project is fully integrated, there is a lot of work to do for polishing the design. Next week, I plan to refine the server code to make it more robust in case of failure or unexpected parameters. I also plan on working with Alex Li on the WebSocket connection code to ensure that the connection is stable and reconnects on disconnect without overloading the WebSocket as well as the prototype design with everyone else.

Once again, there aren’t many major risks to report. We’ve been making good progress, and I believe we have more than enough time to refine our design and component housing prototypes by the time the end of the semester comes.

Posted on

Team status update for 11/7/2020

This week, we were able to finish our subsystems needed for MVP. Alex Li worked on finishing reader + host card emulation code, Alex Xu worked on motor code and combining the motor and the lock, and Michael worked on client server code for simple authentication. The project is mainly combined now for the demo, aside from the last client server code integration which Alex Li is working on to finish (should be done today).

Our potential MVP basically works by hardcoding a phone ID onto our phone (auth token will be given by server later on), swiping our phone to the reader which reads the token via NFC, then sending the token to the server for authentication, which will respond with yes or no, and starting the motor based on yes or no. Based of this MVP, we simply need to add layers of security for web/phone side, and for the lock side we just need to create a component housing.

The only changes were to the client server code, where Alex Li rewrote the client code in C, but using the same logic as the code in Python that Michael wrote. Because we set up everything correctly, adding layers of software security should not pose any significant risks. A potential risk is part failure, but we anticipated this so we bought a few extra parts.

Next week, we plan to finish security for web/phone app with secure authentication using certificates. The housing is also being worked on, so it should be complete by next week. Alex Li will work on the phone app UI as well, and by the end of next week, our project should be complete. In the weeks following, we have slack time to do things like polish our prototype or find and fix holes in security.

Posted on

Alex Li’s status report for 11/7/2020

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

Posted on

Alex Xu’s status report for 11/7/2020

This week I made significant progress on the locking mechanism. I finished the code part that actually causes the motor to turn the lock open, which means we’ll have a visual representation of the iDoorlock process going from phone tap to motor activation (which will represent the lock unlocking during our demo). I also talked to Jiaqi about the motor strength issue, and with the stronger motor coming in yesterday I was able to do a quick test and determine that the new motors are indeed strong enough to turn the locking mechanism. We have made precautions, though, and I’ve sent in an order request for a servo shield should the Raspberry Pi by itself not supply enough current for the mechanism.

Open issues: prepping demo and an actual adhesive mechanism for the lock mechanism. Demo is almost ready, we’ll probably need to run a few tests to make sure everything is in order though. As for the lock and motor, I’ll need to look into how I can actually connect the two together. I have a few ideas at the moment, some of which involve sanding down part of the lock so it’s flat enough to superglue a motor horn onto, but I’d like to come up with something more practical.

Next week will be about figuring out these two open issues. I’ll most likely communicate with TechSpark independently to see if they have scroll saws/belt grinders.

Media: testing lock mechanism (video was too large so only testbench shown), naive test mechanism with stronger motor that opened lock (temporarily held in place by wiring)

Posted on

Team status report for 10/31/2020

This week, we were able to work more on each of our individual parts. Michael researched security involving AWS communications, Alex Li worked on receiving NFC signals with the Raspberry Pi, and Alex began to troubleshoot the motor and lock combo. We also met in person to discuss future workloads and plans.

One critique of our design that was brought up was the unintended additional latency and redundancy of the Arduino Uno in our design. This week, we made significant process in detecting an NFC test card and an NFC chip in an Android device with the NFC Shield module and Raspberry Pi alone. This discovery has allowed us to cut the Arduino Uno from our design, which will hopefully help us better meet latency requirements and keep our final housing design small and lightweight. It also puts us closer to a potential MVP, involving receiving an NFC signal from the Shield, routing it to AWS with the Raspberry Pi, and then requesting it back from AWS.

Next week, we plan to finish the remaining parts of the MVP, which would involve finishing up the code connecting the Raspberry Pi to AWS and from the Raspberry Pi to the locking mechanism. We will also try to find a locking mechanism solution that will work for our current situation.

Posted on

Alex Li’s Status Report for 10/31/2020

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.