Author: mzchen

This week, I worked on the integration with both Alex’s and we completed the housing integration with the locking mechanism and RPi + NFC reader. I also began working on the final report and presentation slide deck as the presentation is coming up next week.

Next week, I’ll be delivering the final presentation and working on the video and final report. We have no more work for integration so I will be able to focus all of my time into both deliverables. We will definitely be able to get those done by their respective deadlines.

No issues to report, integration is done and we just have to complete the deliverables now, which should be simple. As we have already recorded the locking mechanism for the video, there shouldn’t be any need for us to meet in person anymore, which is good timing as we are all going home this weekend.

This week, I completed integration of the REST API endpoints with the Android phone application. The phone is now able to register a new lock and other users are able to get permissions for the lock if they have the secret lock ID. The phone is assigned a unique phone ID that it passes to the RPi whenever it scans the reader, and it is sent securely to the server to see if the user has permissions to open the lock. Now that the Android app is integrated with the server, the server integration is complete. For next week, I will be working on the overall system integration to hopefully complete our project before Thanksgiving. We just need the 3D printed case to be completed and then we can integrate everything together. I will also be working on verifying the security setup we currently have for the REST API. AWS API Gateway provides our REST API calls with HTTPS protocol, and we will be using the same method with authenticating with secret keys, so the security setup should be as secure as it was with the previous WebSocket iteration.

No issues to report. The server side is complete and everything is working properly per the tests that Alex Li and I have run on the API calls.

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.

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.

This week, I met up with Alex and Alex to go over the Raspberry Pi side of the locking mechanism. I also wrote up a short Python test script that connects to the WebSocket and sends some test messages to ensure that we can receive messages from the “server”. Since WebSocket requires a persistent connection, I’ll have to migrate the code later on once we get the other features up and running so that the WebSocket connection is properly maintained.

I also did some extra research on the security architecture of the system and was able to conclude that using IAM keys to authenticate the Raspberry Pi to the server was the best available solution, as AWS API Gateway does not support mutual TLS for WebSocket APIs. Many of the articles that I read such as this Heroku one (https://devcenter.heroku.com/articles/websocket-security) suggest having the user authenticate with secret information such as a username and password to retrieve a token that will authenticate all future requests. However, since the RPi is handling the server communication and the user is not able to directly interface with the RPi, we decided that we would need to use the IAM keys since the user would not have to enter them and the permissions on the associated IAM role would only allow any adversary to invoke the API if the keys were compromised.

There aren’t any major risks at the moment. My work has been pretty straightforward and standalone, so integrating with the other code should be simple. Next week, I plan to work with both Alex’s again to get all of the server communication set up on the RPi. I also plan to work with Alex Li to get the WebSocket communication up and running on the Android.

This week, I finally managed to get back on track with the schedule. I was able to complete the Lambda that handles all of the request logic and set up the WebSocket API. I tested each of the different API endpoints and Lambda handlers using the wscat tool and the Lambda successfully integrates with the DynamoDB tables. There may be small tweaks that I need to make later on, but those changes should be very simple since all of the infrastructure is already in place.

There are a couple of changes of note that I made to the AWS infrastructure. One change that I made to the system is that I picked up the Serverless framework (https://www.serverless.com/) to manage the AWS deployments. Serverless greatly simplified the deployment process since it manages API Gateway and Lambda configuration in an easy-to-edit configuration file. I also did not use the pynamodb library as originally planned because boto3, the Python AWS SDK, already has methods that allow me to read and write to DynamoDB tables.

Now that all of the AWS functionality works, I need to begin working on the integration with the RPi and Android phone app to ensure that they can communicate with AWS. Since we plan to use IAM authentication to secure our API requests, I need to figure out how to set up the access keys on the RPi and the Android app so that they can make requests to the API. I plan to meet up with both Alex’s to figure that out. One risk associated with this is that it may not be possible to actually manage the access keys securely. In this case, I would likely have to change the authentication method to use a Lambda authorizer instead, which would add additional work of writing the authorizer.

This week was busy with working on the design document, so I wasn’t able to spend as much time on working on AWS as I had hoped. I did more research into API Gateway and set up a simple WebSocket API that I connected to a test Lambda. After setting up the AWS CLI on my Mac, I was able to query the API and invoke the Lambda function.

Next week, I plan to start writing the actual Lambda function that will control all of the information processing between the RPi and the phone app. I will also start working on the DynamoDB integration with the Python Lambda using the pynamodb library. I’ll need to do some research on how the pynamodb library works as well.

Due to the upcoming design presentation, I wasn’t able to get much work done on setting up any AWS infrastructure. I was able to upload some sample code to Lambda and test it out in the console. The next steps for this week are to set up the API Gateway configuration to route all requests from that WebSocket URL to the Lambda and to familiarize myself with the pynamodb library in order to manipulate DynamoDB data from the Lambda.

No major open issues to report for this week. One thing to note is that our parts arrived somewhat late, so setting up the communication between the board and AWS will be slightly delayed, but it shouldn’t have too big of an impact on our schedule. I’m confident that I’ll be able to get the AWS setup working next week so that we can test communication from the board.