Calendar

Week Monday Tuesday Wednesday Thursday Friday
1/20
First class meeting 4:00p - 5:50p ECEB 1002
1/27
Second class meeting 4:00p - 5:50p ECEB 1002
CAD assignment due 11:59p
2/3
Add/Drop Deadline due 11:59p
Third class meeting 4:00p - 5:50p ECEB 1002
Project approval due 11:59p
2/10
First team meetings with TAs 4:00p ECEB 3081
Proposals due 11:59p
Initial Conversation With Machine Shop (required if using the shop) due 4:00p ECEB 1047
Team Contract due 11:59p
Proposal Review Sign-up due 11:59p
2/17
Proposal Review 8:00a - 6:00p With Instructor and TAs
Design Review
Fliflet: 2070
Design Review
Gruev: 2074
Design Review
Oelze: 5086
Proposal Review 8:00a - 6:00p With Instructor and TAs
Design Review
Fliflet: 2070
Design Review
Zhao: 2072
Design Review
Gruev: 2074
Design Review
Oelze: 5086
Proposal Review 8:00a - 6:00p With Instructor and TAs
Design Review
Fliflet: 2070
Design Review
Zhao: 2072
Design Review
Gruev: 2074
Design Review
Oelze: 5086
2/24
PCB Review 3:00p - 5:00p ECEB 3081
3/3
Design Document due 11:59p
3/10
Breadboard Demo 8:00a - 6:00p WIth Instructor and TA
Breadboard Demonstration
Fliflet: 2070
Breadboard Demonstration
Oelze: 2070
Breadboard Demonstration
Zhao: 2072
Breadboarrd Demo 8:00a - 6:00p With Instructor and TA
Breadboard Demonstration
Fliflet: 2070
Breadboard Demonstration
Oelze: 2070
Breadboard Demonstration
Zhao: 2072
Breadboard Demonstration
Gruev: 2074
Breadboard Demo 8:00a - 6:00p With Instructor and TA
Breadboard Demonstration
Fliflet: 2070
Breadboard Demonstration
Oelze: 2070
Breadboard Demonstration
Zhao: 2072
Breadboard Demonstration
Gruev: 2074
Last day for revisions to the machine shop due ECEB 1048
3/17
Spring Break
Spring Break
Spring Break
Spring Break
Spring Break
3/24
3/31
4/7
4/14
4/21
Mock demo During weekly TA mtg
Mock demo During weekly TA mtg
Mock demo During weekly TA mtg
Mock demo During weekly TA mtg
Mock demo During weekly TA mtg
4/28
Final Demo With Instructor and TAs
Demonstration
Fliflet: ECEB 2070
Demonstration
Gruev: ECEB 2070
Demonstration
Oelze: ECEB 2070
Demonstration
Zhao: ECEB 2072
Final Demo With Instructor and TAs
Demonstration
Fliflet: ECEB 2070
Demonstration
Gruev: ECEB 2070
Demonstration
Oelze: ECEB 2070
Demonstration
Zhao: ECEB 2072
Final Demo With Instructor and TAs
Demonstration
Fliflet: ECEB 2070
Demonstration
Gruev: ECEB 2070
Mock Presentation With Comm and ECE TAs
Mock Presentation With Comm and ECE TAs
Extra Credit Video Assignment due 11:59p
5/5
Final Presentation With instructor and TAs
Presentation
Fliflet: ECEB 2070
Presentation
Zhao: ECEB 2072
Presentation
Gruev: ECEB 2074
Presentation
Oelze: ECEB 5086
Final Presentation With Instructor and TAs
Presentation
Fliflet: ECEB 2070
Presentation
Gruev: ECEB 2074
Presentation
Oelze: ECEB 5086
Final papers due 11:59p
Lab checkout 3:00p - 4:30p With TA
Award Ceremony 4:30p - 5:30p Grainger Auditorium
Lab Notebook Due due 11:59p
5/12
5/19
5/26
6/2
Presentation
Zhao: ECEB 2072

Schnorr Protocol Key Fob

Michael Gamota, Vasav Nair, Pedro Ocampo

Featured Project

# Schnorr Identification Protocol Key Fob

Team Members:

- Michael Gamota (mgamota2)

- Vasav Nair (vasavbn2)

- Pedro Ocampo (pocamp3)

# Problem

Current car fobs are susceptible to different types of attacks. Rolling jam attacks are one of such attacks where an attacker jams and stores a valid "unlock" signal for later. Cars with passive keys/cards can be stolen using relay attacks. Since a car can be the most expensive item someone owns, it is unreasonable to allow people to steal them so discreetly by hacking the fob/lock combo.

# Solution

By leveraging public key cryptography, specifically the Schnorr identification protocol, it is possible to create a key fob which is not susceptible to either attack (rolling jam and relay) and also gives no information about the private key of the fob if the signal were to be intercepted.

# Solution Components

# Key Fob

## Subsystem 1

Random number generation - We will use a transistor circuit to generate random numbers. This is required by the Schnorr protocol to ensure security.

## Subsystem 2

Microcontroller - The MCU will run all the computation to calculate the messages. We will likely use an ATtiny MCU so we can use the Arduino IDE for programming. However, some group members have experience with the STM32 family so that is another option.

## Subsystem 3

Power - We plan on using either a 5V battery or 3.3V battery with a boost converter to power the fob.

## Subsystem 4

Wireless Communication - We plan on using the 315 MHz frequency band which is currently used by some car fobs. We will need a transmitter and receiver, since the protocol is interactive.

# Lock

## Subsystem 1

Random number generation - We will use a transistor circuit to generate random numbers. This is required by the Schnorr protocol to ensure security.

## Subsystem 2

Microcontroller - This MCU will also run all the computation to calculate the messages. We will likely use an ATtiny MCU so we can use the Arduino IDE for programming. However, some group members have experience with the STM32 family so that is another option. This MCU will need to have PWM output to control the lock.

## Subsystem 3

Linear Actuator - We plan on using a linear actuator as a deadbolt lock for demonstration purposes.

## Subsystem 4

Wireless Communication - We plan on using the 315 MHz frequency band which is currently used by some car fobs. We will need a transmitter and receiver, since the protocol is interactive.

## Subsystem 5

Power - This subsystem will also likely require 5V, but power sourcing is not an issue since this system would be connected to the car battery. During a demo I would be acceptable to have this plugged into a power supply or a barrel jack connector from an AC-DC converter.

# Criterion For Success

Describe high-level goals that your project needs to achieve to be effective. These goals need to be clearly testable and not subjective.

Our first criteria for success is a reasonably sized fob. There is some concern about the power storage and consumption of the fob.

The next criteria for success is communication between the fob and the lock. This will be the first milestone in our design. We will need to have a message sent from one MCU that is properly received by the other, we can determine this in the debug terminal.

Once we are sure that we can communicate between the fob and the lock, we will implement the Schnorr protocol on the two systems, where the fob will act as the prover and the lock as the verifier. If the Schnorr signature implementation is correct, then we will always be able to unlock the lock using the fob whose public key is associated with full privileges.

Project Videos