Research
Technology Review
Wireless Proximity Technology
Proximity detection is a crucial element of our system, allowing users to interact effortlessly with nearby devices whilst also ensuring security. To determine the most suitable technology for this purpose, we evaluated several options, including Bluetooth Low Energy (BLE), Near-Field Communication (NFC), Radio Frequency Identification (RFID), and Wi-Fi Positioning System (WPS).
BLE was selected as the primary technology after careful consideration due to its optimal balance of cost-effectiveness, power efficiency, and broad compatibility. BLE signals provide an adequate range and signal strength variations, enabling accurate detection of a user's presence near a specific device [4]. The ESP32 microcontroller, recognized for its affordable and efficient BLE functionality, will serve as the primary BLE beacon. When paired with a Raspberry Pi, this system can analyze signal strength variations and infer directionality, allowing for precise proximity-based authentication.
NFC, although a good consideration for authentication, was rejected after a thorough analysis of our requirements indicated that it was not the best fit for our project. Given that our primary objective is to develop a seamless, proximity-based login system that is both secure and accessible, NFC's inherent limitations would hinder our ability to achieve this goal since it requires users to bring an NFC-enabled card or device into close contact of a reader to complete authentication [5]. While this provides a high level of security, it does not align with our vision of seamless authentication where users can be automatically detected as they approach a device. These constraints make NFC less practical for our intended application compared to BLE.
RFID was also explored as a potential alternative due to its ability to facilitate short-range authentication via electromagnetic fields. This technology operates by having a reader transmit a radio signal that activates passive RFID tags [6], enabling secure identification. Unlike BLE, RFID tags do not require a power source, making them highly efficient for authentication applications. However, RFID is primarily intended for close-range authentication, typically within just a few centimetres, which does not align with our need for seamless proximity detection across a workspace. Additionally, implementing RFID on a large scale would also necessitate deploying dedicated RFID readers in every interaction zone, significantly increasing both cost and complexity.
WPS was another alternative considered, leveraging signal strength (RSSI), triangulation, and fingerprinting to estimate a user's location relative to a device [7]. One notable advantage of Wi-Fi is that it does not require additional hardware, as modern buildings are already equipped with Wi-Fi infrastructure, and most devices support Wi-Fi connectivity. However, WPS is considerably less precise than BLE, and varies greatly depending on interference and network conditions. Another significant drawback is power consumption: Wi-Fi scanning requires substantially more energy than BLE, making it impractical for low-power IoT devices like the ESP32.
Ultimately, BLE's balance of affordability, efficiency, and compatibility makes it the most appropriate solution for efficient, profile-based authentication in real-world environments, which is why we selected this option for use in our QPG system.
Facial Recognition for Authentication
We chose facial recognition to be the primary authentication method for our system as it provides a reasonable compromise between security, usability, and accessibility. Implementing facial recognition within our system means that users can log in to devices without physical interaction, which makes it an ideal solution for accessible two-factor authentication (2FA).
Voice recognition was considered as an alternative authentication method but we decided against this due to several limitations. While voice authentication does provide a hands-free authentication method, it is a lot more susceptible to environmental noise, variations in a user's voice due to illness or stress, and spoofing attacks using recorded samples. Additionally, voice authentication systems require continuous model training to adapt to changes in a user's voice, making them less practical for seamless authentication. Facial recognition however, offers a higher level of security due to unique facial features and ensures a more reliable and user-friendly authentication experience.
Post-Quantum Cryptography (PQC) Algorithm
To secure user authentication and communication between devices, we considered it a necessity to use post-quantum cryptography (PQC), making our system future-proof from any quantum attack. While traditional encryption methods such as RSA-4096 and Elliptic Curve Cryptography (ECC) are adequately effective today, they may become vulnerable as quantum computing evolves, and so we took this into consideration while designing our system.
After research and evaluation of several PQC algorithms, we chose to implement the Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM), a standardised version of the CRYSTALS-Kyber algorithm, as the encryption standard for our system. CRYSTALS-Kyber is a lattice-based encryption algorithm that provides strong security against quantum attacks.
The KEM stage involves:
- 1. Key Pair Generation — Each party (sender/receiver) generates a public-private key pair using the Kyber algorithm.
- 2. Encapsulation — The sender uses the recipient's public key to generate a shared secret and a corresponding ciphertext.
- 3. Decapsulation — The recipient uses their private key to retrieve the shared secret from the ciphertext.
Alongside ML-KEM, we also implemented the Advanced Encryption Standard with Galois/Counter Mode (AES-GCM) symmetric encryption algorithm to ensure secure communication between devices. Our system's encryption process begins with KEM, which establishes a shared secret between communicating parties. Once the shared secret is established, AES-GCM is used to encrypt and decrypt messages.
Comparison of IoT Devices
Choosing the right hardware for proximity detection and facial recognition was essential to ensuring reliability and efficiency in our system. After considering several options, we selected the Raspberry Pi 5 as the primary processing unit for facial recognition, and proximity management, whilst the ESP32 microcontroller is used to function as a low-power BLE beacon.

Raspberry Pi 5

NVIDIA Jetson Nano
The Raspberry Pi 5 offers ample processing power to handle incoming BLE signals, run facial recognition algorithms, and communicate with our main server [8]. Furthermore, the Raspberry Pi Camera Module enables us to capture high definition video which is used in the facial recogntion algorithms. Whilst more advanced alternatives like NVIDIA's Jetson Nano provide superior AI capabilities [9], they come at a higher cost and exceed the requirements of our project. The Raspberry Pi 5 strikes a balance between performance and affordability.

ESP32

Raspberry Pi Pico W
The ESP32 was chosen for our low-power BLE beacon due to its cost-effectiveness, and efficiency in sending out BLE signals [10]. It continuously broadcasts signals so that it can be detected by our Raspberry Pi 5, facilitating proximity detection. Whilst a Raspberry Pi Pico W for example could also serve as a BLE beacon, we opted for the ESP32 due to our prior experience with the platform, and due to it being more established within the IoT community. By integrating the ESP32 with the Raspberry Pi 5, our system achieves an optimal balance of performance and cost to detect the presence and proximity of our users.
Programming Languages, Frameworks, and Libraries
Our system consists of many distinct parts which come together to form the quantum proximity gateway. For each part, we thought about the optimal programming languages which would strike a balance between development time and performance.
Python
Litestar
For our main server that manages user profiles, Python was chosen as the core language due to its simplicity and extensive library ecosystem. The Litestar framework was used to develop the API endpoints on our server. It was chosen over other renowned frameworks such as Flask or Django due to being asynchronous, highly performant, and lightweight out of the box [11]. Whilst there are more mature, tested frameworks such as Spring for Java, its verbosity and slower development cycle makes it less suitable for rapid prototyping. Moreover, Python bindings for liboqs were available and easy to use allowing us to implement post-quantum encryption without much friction.
Rust
Tauri
For our desktop application with the AI chatbot, we chose Rust with the Tauri framework to create the backend. Rust offers memory safety and high performance, making it ideal for a secure desktop application. Compared to the popular alternative Electron, Tauri is lightweight and more compact, reducing resource consumption [12]. It also enables direct access to native system APIs without the heavy resource consumption of bundling an entire Chromium engine, unlike Electron, which requires a full-fledged Chromium instance for rendering.
TypeScript
Next.js
Next.js is a react framework used across all of our frontends (i.e. Desktop app, Reigstration site, Report site, Raspberry Pi BLE proximity demo site) due to its popularity, and ease of use [13]. By using supported UI libraries such as Chakra UI and shadcn/ui, we were able to quickly develop impressive, robust frontends. Furthermore, TypeScript, which is the language we used with Next.js, provides a structured approach to JavaScript development, offering type safety and enhanced maintainability.
Python
Raspberry Pi
Python was chosen to be used on our Raspberry Pi due to its simplicity, and extensive library ecosystem, including Raspberry Pi libraries. Its ease of use allowed us to focus on the overall development of our system, without being bogged down by syntax and other considerations. It is well-suited for implementing facial recognition due to support for libraries like OpenCV and Dlib. Furthermore, its support for BLE communication via bluepy, UART, and USB HID libraries, makes it an excellent choice for IoT hardware.
C++
PlatformIO
C++ was chosen to program the ESP32 microcontroller to handle the constant BLE broadcasting, as it is highly performant, and enables low-level hardware control and efficient memory management. This is is crucial for real-time processing on constrained devices. Furthermore, C++ has a mature toolchain, and good support for the Arduino framework, and BLE libraries. Additionally, PlatformIO is used for ESP32 firmware management, streamlining development, debugging, and deployment.
Technical Decisions
Having extensively researched different technologies and methodologies, evaluating their strengths and limitations, we made the following decisions on how our Quantum Proximity Gateway should be implemented.
| Type | Decision |
|---|---|
| Wireless Proximity Technology | Bluetooth Low Energy |
| Proximity Detector & Authenticator | Raspberry Pi |
| BLE Beacon | ESP32 |
| Raspberry Pi | Python |
| ESP32 | C++ |
| Server | Python, Litestar |
| Desktop App | Rust, Tauri |
| Frontends | TypeScript, Next.js |
From our research, we concluded that a good proximity-based access control system would provide the following.
Utilise multi-factor authentication methods composed of facial recognition and BLE proximity detection, as well as post-quantum cryptographic encryption to prevent unauthorised access.
Automatically configure devices based on user proximity, ensuring effortless transitions between workstations, meeting rooms, and other shared spaces.
Implement BLE signal strength analysis for precise location tracking, ensuring users connect only to their intended devices.
References
- [1]Yubico, "Meet the YubiKey". [Online]. Available: https://www.yubico.com/why-yubico/. [Accessed March 26, 2025].
- [2]Alps Alpine, "Our Business". [Online]. Available: https://www.alpsalpine.com/e/company/business/. [Accessed March 26, 2025].
- [3]Alps Alpine, "Alps Alpine and Broadcom Collaborate on a Secure Distance Measurement Solution based on Bluetooth® Technology", Jan. 5, 2021. [Online]. Available: https://www.alpsalpine.com/e/news/detail/2021-0105-02/. [Accessed March 26, 2025].
- [4]Wikipedia, "Bluetooth Low Energy", March 1, 2025. [Online]. Available: https://en.wikipedia.org/wiki/Bluetooth_Low_Energy. [Accessed March 26, 2025].
- [5]Wikipedia, "Near-field communication", Feb. 4, 2025. [Online]. Available: https://en.wikipedia.org/wiki/Near-field_communication. [Accessed March 26, 2025].
- [6]Wikipedia, "Radio-frequency identification", March 18, 2025. [Online]. Available: https://en.wikipedia.org/wiki/Radio-frequency_identification. [Accessed March 26, 2025].
- [7]Wikipedia, "Wi-Fi positioning system", Jan. 19, 2025. [Online]. Available: https://en.wikipedia.org/wiki/Wi-Fi_positioning_system. [Accessed March 26, 2025].
- [8]Raspberry Pi, "Buy a Raspberry Pi 5". [Online]. Available: https://www.raspberrypi.com/products/raspberry-pi-5/. [Accessed March 26, 2025].
- [9]NVIDIA, "Jetson Nano Brings the Power of Modern AI to Edge Devices". [Online]. Available: https://www.nvidia.com/en-gb/autonomous-machines/embedded-systems/jetson-nano/product-development/. [Accessed March 26, 2025].
- [10]Espressif, "ESP32 Wi-Fi & Bluetooth SoC". [Online]. Available: https://www.espressif.com/en/products/socs/esp32. [Accessed March 26, 2025].
- [11]Litestar, "Litestar". [Online]. Available: https://litestar.dev/. [Accessed March 26, 2025].
- [12]Lőrik Levente, "Tauri VS. Electron - Real world application", Aug. 22, 2022. [Online]. Available: https://www.levminer.com/blog/tauri-vs-electron. [Accessed March 26, 2025].
- [13]Vercel, "Next.js by Vercel - The React Framework". [Online]. Available: https://nextjs.org/. [Accessed March 26, 2025].


