Order a Pcb

Custom Printed Circuit Boards (PCBs)

In this course, you will be creating and ordering a PCB to use in your project. The primary method for ordering PCBs is to order them through PCBWay. With the help of your TA, you can order a simple, 2-layer, 100mm x 100mm PCB through PCBWay at no cost to you. This PCB will simply be fabricated, as opposed to assembled, so a major portion of this class will be soldering and assembling the PCB you order. This means that you will need to source your components either through the course or other means. See the getting parts page for more details.

Alternatively, you can order a PCB from any outside vendor (including PCBWay) and pay for the cost of the board out of pocket. By paying for a PCB yourself, you are not required to meet the deadlines imposed by the course and can sometimes get your board more quickly.

In rare cases, some teams will be allowed to order PCBs through the Electronics Services Shop in ECEB. If you have need of special board layouts or require a PCB very early in the semester, please discuss this option with your TA as early as possible.

PCBway Orders Through the Course

Orders through PCBway can be submitted and paid for by the ECE department with the help of your TA. Orders will be uploaded to PCBway by your TA and paid for on the dates listed on the course calendar. Please note that the PCBway orders will not be manufactured or shipped until they are paid for so please be aware of the lag time between order submission and payment. In addition, your order must pass PCBway's audit before the payment date for your order to be processed. In order to help students pass audit more quickly, we have provided a DRC file that can be imported in to EagleCAD to verify that your board meets PCBway's capabilities. Passing the DRC does not guarantee that your board will pass audit but it does greatly increase the probability of that event.

Electronic Services Shop

Orders placed through the Electronic Services Shop will require TA approval so please discuss with your TA before contacting the Services Shop. The software most commonly used is EagleCAD. Contact a technician in the Electronic Services Shop with questions.

Please be aware of the PCB deadlines posted on the course calendar. If you are unable to meet these deadlines, you will not be able to order a PCB through the the Electronic Services Shop. You will still be able to order PCBs through third party vendors, just be aware that rushed orders can become expensive.

Commercial quality boards

The most commonly used programs for board layout are Eagle and Orcad Layout. The two software packages below allow a schematic to be drawn and translated into a board layout.

Once the board has been laid out, some companies will manufacture small quantities for a very reasonable price.

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