Project

# Title Team Members TA Documents Sponsor
69 Shamir Secret Self-Destruct USB
 Alex Clemens
Danny Metzger
Varun Sivasubramanian
 Michael Gamota design_document1.pdf
final_paper1.pdf
grading_sheet1.pdf
presentation1.pdf
proposal1.pdf
# Team Members
- Varun Sivasubramanian (vsiva4)
- Alex Clemens (clemens9)
- Danny Metzger (djm14)

# Problem

Traditional USB flash drives pose a security risk if lost or stolen, especially for highly sensitive data such as cryptographic keys, classified documents, or personal information. Even if encrypted, existing encrypted USBs rely on software-based security, which is vulnerable to forensic recovery or brute-force attacks. Some physical destruction, like crushing or snapping, may still leave recoverable data on the drive. Furthermore, USB devices often do not enforce security via the device itself.

# Solution
A custom USB flash drive with built-in cryptographic security and hardware self-destruction, ensuring that sensitive data cannot be recovered under any circumstances. The system will:
- Encrypt and split the drive's decryption key using Shamir’s Secret Sharing across multiple physical hardware keys.
Require a threshold number of shares (⅔) to reconstruct the key and decrypt the data.
- Trigger a hardware-based self-destruct mechanism under various circumstances.
- Ensure complete destruction by physically rendering the flash memory unreadable.

# Solution Components

## Subsystem 1: Shamir Secret & YubiKey Authentication
Purpose: Ensures multi-factor authentication and prevents software access by restricting key reconstruction to hardware.

Components:
- Microcontroller: ESP32, STM32 or similar. Should handle reading YubiKeys and managing key reconstruction along with triggering destruction.
- Secure Element: AES-256 Encryption capable. Handles all cryptographic operations and is tamperproof.
- 3 USB-C YubiKeys: Hold each share of the Shamir Secret in a ⅔ authentication.

Upon first connection, the user is able to set up Shamir Secrets by plugging in all YubiKeys and initiating the MCU and SE to create the shares.

## Subsystem 2: Storage System
Purpose: The flash drive should still have traditional storage and functionality. Conceals encrypted portion unless Shamir is reconstructed. With partitioning, an unencrypted partition should also be allowed.

Components:
- Flash NAND storage: Any small size (8-16GB) is good. Should support basic partitioning.
- USB Mass Storage Controller: Facilitates communication with the computer.
- External USB-C ports: Allow YubiKeys to be connected to the PCB
- USB-A or USB-C interface: Plugs into the computer.

The encryption of the storage will be done by the secure element.

## Subsystem 3: Hardware Self-Destruction
Purpose: Ensures that if there is a potential attacker, the storage is permanently destroyed. The exact method of self-destruction is contingent on circuit design, but a voltage overload is most feasible.

Components:
- Boost Converter: Steps voltage to create destruction.
- MOSFET: Switches from normal functioning to destruction voltage.
- 2 LiPo or CR2032 batteries: Allows destruction to take place even when unplugged.
- Tamper detection circuit: A circuit that detects when two pins are no longer in contact i.e. when the casing has been opened up.

Trigger Mechanisms:
There are multiple triggers that lead to frying the NAND. Multiple YubiKey fail attempts, opening the physical casing, or attempting to access the Secure Element should trigger the self-destruction. The MOSFET should direct high voltage directly to the NAND, irreversibly damaging memory.

# Criterion for Success
1. Shamir Secret: The Shamir key can only be reconstructed via firmware on the physical drive, not on a computer.
2. Irreversible: Destruction of the NAND is irreversible. Data should not be recoverable.
3. Tamper-Resistant: Removing casing or tampering with the SE should lead to destruction.

Cloud-controlled quadcopter

Anuraag Vankayala, Amrutha Vasili

Cloud-controlled quadcopter

Featured Project

Idea:

To build a GPS-assisted, cloud-controlled quadcopter, for consumer-friendly aerial photography.

Design/Build:

We will be building a quad from the frame up. The four motors will each have electronic speed controllers,to balance and handle control inputs received from an 8-bit microcontroller(AP),required for its flight. The firmware will be tweaked slightly to allow flight modes that our project specifically requires. A companion computer such as the Erle Brain will be connected to the AP and to the cloud(EC2). We will build a codebase for the flight controller to navigate the quad. This would involve sending messages as per the MAVLink spec for sUAS between the companion computer and the AP to poll sensor data , voltage information , etc. The companion computer will also talk to the cloud via a UDP port to receive requests and process them via our code. Users make requests for media capture via a phone app that talks to the cloud via an internet connection.

Why is it worth doing:

There is currently no consumer-friendly solution that provides or lets anyone capture aerial photographs of them/their family/a nearby event via a simple tap on a phone. In fact, present day off-the-shelf alternatives offer relatively expensive solutions that require owning and carrying bulky equipment such as the quads/remotes. Our idea allows for safe and responsible use of drones as our proposed solution is autonomous, has several safety features, is context aware(terrain information , no fly zones , NOTAMs , etc.) and integrates with the federal airspace seamlessly.

End Product:

Quads that are ready for the connected world and are capable to fly autonomously, from the user standpoint, and can perform maneuvers safely with a very simplistic UI for the common user. Specifically, quads which are deployed on user's demand, without the hassle of ownership.

Similar products and comparison:

Current solutions include RTF (ready to fly) quads such as the DJI Phantom and the Kickstarter project, Lily,that are heavily user-dependent or user-centric.The Phantom requires you to carry a bulky remote with multiple antennas. Moreover,the flight radius could be reduced by interference from nearby conditions.Lily requires the user to carry a tracking device on them. You can not have Lily shoot a subject that is not you. Lily can have a maximum altitude of 15 m above you and that is below the tree line,prone to crashes.

Our solution differs in several ways.Our solution intends to be location and/or event-centric. We propose that the users need not own quads and user can capture a moment with a phone.As long as any of the users are in the service area and the weather conditions are permissible, safety and knowledge of controlling the quad are all abstracted. The only question left to the user is what should be in the picture at a given time.

Project Videos