G11: Secure TOTP - shalan/CSCE4301-WiKi GitHub Wiki
Project Title: (A clear, descriptive name for your system.)
| Name | GitHub |
|---|---|
| Ali Elkhouly | khoulykd |
| Peter Aziz | peter-aziz |
| Moaz Hafez | justagoat21 |
Github Repo: https://github.com/Khoulykid/Secure-TOTP
1. The Proposal
Abstract / Elevator Pitch:
Modern two-factor authentication (2FA) is one of the most effective defenses against unauthorized account access, yet most people interact with it only through their smartphones. This project brings that mechanism down to the hardware level by building a standalone TOTP (Time-Based One-Time Password) token from scratch — a physical embedded device that generates the same 6-digit codes used by Google Authenticator and similar apps, with no internet connection required.
The core problem is that traditional passwords are static and easily compromised. TOTP solves this by generating a new password every 30 seconds using a shared secret key and the current Unix timestamp, meaning the code is useless after it expires. Our system implements this on a microcontroller paired with a real-time clock (RTC) module, running the HMAC-SHA1 cryptographic algorithm in embedded C. A companion Python script running on a PC independently computes the same codes — if both match, the system works.
The engineering challenge lies in the synchronization and drift management between the hardware clock and real-world time, implementing a non-trivial cryptographic function in a resource-constrained environment, and demonstrating a complete hardware-software co-design with a meaningful security application.
Project Objectives & Scope:
Minimum Viable Product:
- Microcontroller reads current time from an RTC module (DS3231 via I2C)
- HMAC-SHA1 implemented or ported to embedded C
- TOTP code computed per RFC 6238 and displayed on OLED/LCD every 30 seconds
- PC-side Python script generates identical codes from the same shared secret
- Codes match consistently across both devices
Stretch Goals:
- QR code generation on PC side for easy secret sharing
- Button-triggered manual resync via UART between device and PC
- Multiple accounts / secrets stored on device
- Visual countdown timer showing seconds remaining before code refresh
- Tamper detection (wrong PIN locks the device)
2. System Architecture
2.1 High-Level Block Diagram:

Subsystem Breakdown:
The system is organized into five interacting modules: secure key provisioning, time synchronization, OTP generation, user display, and PC-side validation. Before operation, the same shared secret is loaded onto both the MCU and the Python script, and it is never transmitted during runtime. At startup (or during manual resync), the PC sends a Unix timestamp to the MCU over UART, and the MCU programs the DS3231 RTC over I2C. During normal operation, the MCU reads RTC time every 30 seconds, applies HMAC-SHA1 with the shared secret, and generates the 6-digit TOTP value defined by RFC 6238. The code is shown on the OLED over SPI/I2C, while the PC script independently computes its own TOTP from system time and the same secret; matching outputs confirm correct synchronization and implementation.
3. Hardware Design
Component Selection:
Schematics & Wiring:
Circuit diagrams, pinout tables, and breadboard layouts.
Bill of Materials (BOM):
A table listing component names, part numbers, quantities, costs, and links to datasheets.
Power Budget:
Calculations ensuring your power supply can handle the peak current draw of all components combined.
4. Software Implementation
4.1 Software Architecture:
Description of the firmware design (e.g., Bare-metal Superloop, Interrupt-driven, or RTOS).
4.2 Flowcharts & State Machines:
Visual diagrams mapping out the core logic, state transitions, and interrupt service routines (ISRs).
4.3 Key Algorithms:
Explanations of any complex logic used (e.g., PID control loops, digital filtering, sensor fusion).
4.4 Development Environment:
Compilers, IDEs, and toolchains used (e.g., Keil, PlatformIO, STM32CubeIDE).
5. Testing, Validation & Debugging
5.1 Unit Testing:
How individual hardware components and software functions were tested in isolation.
5.2 Integration Testing:
How the system was tested as a whole.
5.3 Challenges & Solutions:
A log of major bugs, hardware failures, or design flaws you encountered, and the engineering steps you took to solve them.
6. Results & Demonstration
6.1 Final Prototype:
High-quality photos of the completed build.
6.2 Video Demonstration:
A link to a short video showing the system working in real-time under various conditions.
6.3 Performance Metrics:
Data showing how well the project met its initial objectives (e.g., "Response time was measured at 12ms, well within our 50ms goal").
7. Project Management
7.1 Division of Labor:
A clear breakdown of who worked on what (professors usually require this to grade individual contributions).
7.2 Timeline:
| Date | Milestone | Status |
|---|---|---|
| Apr 14, 2026 | Team formation finalized and submitted | ✅ Completed - Apr 14, 2026 |
| Apr 15, 2026 | Proposal presentation and requirements validation | 🔄 In progress |
| Apr 20, 2026 | Wiki deployment with system architecture and proposal | ⏳ Pending |
| Apr 22-25, 2026 | RTC driver (I2C), OLED driver, HMAC-SHA1 implementation | ⏳ Pending |
| Apr 26-28, 2026 | TOTP logic, 30-second window, code display on hardware | ⏳ Pending |
| Apr 29, 2026 | Progress demo: hardware displays matching code vs PC script | ⏳ Pending |
| May 1-5, 2026 | Full integration, drift compensation, edge-case testing | ⏳ Pending |
| May 6, 2026 | Integration update and technical documentation on wiki | ⏳ Pending |
| May 8-12, 2026 | Robustness testing, demo prep, final polish | ⏳ Pending |
| May 13, 2026 | Final demo and presentation | ⏳ Pending |
8. Appendices & References
8.1 Source Code Repository:
Link to your GitHub/GitLab repo.
8.2 References:
Links to datasheets, tutorials, academic papers, and course materials used during development.