Tech Stack

Technology & Stack

Listing of technologies, tools, software and hardware components used in your Cuvex 1.0

Listing of technologies,
tools, software and
hardware components used
in your Cuvex 1.0

We have compiled information with meticulous attention to detail, delving into the key aspects that make up this disruptive device: main features of the components, details on software workflows, and important notes on the implemented security.

In the spirit of providing complete transparency regarding the solution's implementation, we have included the manufacturer identifier for the hardware components. This will allow you to conduct your own research on each of them.

In the following image, we can observe the high-level diagram that brings together the main Hardware and Software components, as well as the external components and actors that make up the system.

Component_diagram_cuvex_33db3194-4c6e-44bd-bb2a-7a54a2f759fb

The heart of the system

Latest model in the STM32 series from STMicroelectronics, the STM32U585.

micro_1bdf0d25-f64f-4cac-8e52-c6fff4b2995b

This microcontroller is based on the ARM Cortex-M architecture, with a design specifically tailored to meet the highest security standards and focused on fulfilling the needs of the defense and aerospace industries. It offers efficient performance and minimal power consumption, among its main features we find:

- 2 AES coprocessor units.

- High resistance to Differential Power Analysis techniques.

- HASH hardware accelerator.

- Secured input/output and memory interfaces (Arm® TrustZone®).

- Trusted path thanks to the unique boot entry and Secure Hidden Protection Area (HDP).

- Secure firmware installation (SFI) with integrated Secure Root Services (RSS).

- Secure data storage with unique hardware key (HUK).

In summary, this military-grade component has been implemented into your Cuvex to provide the market's leading capabilities in cryptography and computer security. This endows your device with the capacity for cold encryption and highly secure data management.

Designed to not store
data on the device

Memory fully protected

Cuvex is designed to never store data on the device's memory. Your most prized secret only passes through the device temporarily to be processed and converted into a cryptogram, which is then sent to a card via NFC. As soon as any process is completed, the memory is cleared, and similarly, upon cutting the power or upon device startup, a complete memory reset is performed.

With TrustZone mode enabled, based on the security of non-volatile watermarking, access control securitization, and HDP protection concealment, the memory is entirely protected.

Moreover, for read protection, the RDP 2 level defined by the manufacturer itself has been established.

This implies that debugging functions, booting in RAM, and bootloader selection are disabled, which is irreversible and makes the device unable to be unlocked or tampered with, rendering the hardware unusable for any other purpose and all memory content inaccessible to any intruders.

In summary, data is never stored in non-volatile memory, volatile memory is protected, making it impossible to access its contents, which is also encrypted, and is cleared when any workflow is completed or power is cut/started. Added to this, the device is locked, which prevents any form of tampering.

Integration of secure components

Modelo de ST, el STM32WB5MMG

Continuing in the vein of incorporating the most secure components available on the market, for the Bluetooth communication module, we have chosen the ST model, the STM32WB5MMG. Among its notable security features, we find:

* Key management services/client key storage, PKA, 256-bit AES, TRNG, PCROP, CRC, 96-bit UID.

* The capability to derive 48-bit UEI from 802.15.4 and Bluetooth® Low Energy

* Bluetooth® Low Energy 5.4, Zigbee® 3.0 with OpenThread certification

Operationally, this module is only activated for the firmware update process of Cuvex, thus ensuring it is not available during any other process. In fact, the device itself checks before starting a process and if it finds the module turned on, it aborts the action.

The client can also verify the module's activity. With a blue light visible from the front of the CASE that symbolizes when Bluetooth is available, the user is always aware of the BL status. This LED is part of the Bluetooth module and lights up when powered, making it impossible to tamper with to give false negatives.

Regarding pairing, a specific protocol has been defined for packet communications with the Cuvex App, and it uses the LE Secure Connection mode, rejecting Legacy Pairing due to its potential insecurity.

For the link key exchange method, the "Just Works" option is rejected, and a requirement for MITM protection is established, based on an entropic PIN and forcing the deletion of exchanged keys once the connection is finished.

As for the signal strength, it has been set to a range of less than one meter, mitigating any attempt at remote access to the device. Lastly, although this module offers a secure Firmware installation system (SFI), this option is disabled by default, thus blocking the door to any potential security risk.

Module for "encrypt,
decrypt and clone"processes

Transducer CR95HF - RFID

For NFC card reading and writing, we have opted for the RFID transducer CR95HF (part of the ST25 family), specially designed for contactless solutions in the payment media industry. This component manages the encoding and decoding of frames for Near Field Communication (NFC) applications, enabling the detection, reading, and writing of NFC Forum Type 1, 2, 3, and 4 tags.

The NFC module is only activated in the final stages of the "Encrypt" and "Clone" processes, once the cryptogram is inside the secure memory element ready to be written to a CUVEX NFC TAG, or at the beginning of the "Decrypt" process when the content of a TAG is to be read. All this is managed by the microcontroller itself and works in conjunction with the security elements of the memory described previously.

It is worth noting that the content traveling between the NFC controller and the microcontroller (or vice versa) is always encrypted since it concerns the cryptogram generated in any of the functions offered by the Cuvex device. Thus, there is no risk of access to sensitive data in any case.

Two NFC-TAG versions

MIFARE DESFIRE EV1 8K and the other NTAG216 888 Bytes

The Cuvex cards on which you store your cryptograms come with two versions of NFC TAGs, one is of the MIFARE DESFIRE EV1 8K type and the other is an NTAG216 888 Bytes. These are passive NFC cards, hence, they do not have a battery or internal power source; the RFID transducer provides the necessary energy to activate the card. This happens at very short distances (on the scale of millimeters), preventing other devices outside the range from interacting with the TAG.

The card stores a series of metadata necessary for communications with a Cuvex device, and of course, the cryptogram with your secret encrypted with AES 256, making cryptographic attacks ineffective.

The durability of Cuvex cards is bolstered by several factors: the physical resistance of the material used, the quality of the printing, the storage method, and the handling in the real environment of use. All this gives us a lifespan of around 10 years, or 15,000 cycles, allowing a considerably good backup time versus its cost.

In any case, the App will take care of reminding you of the remaining time for your card, so that following best practices, you can periodically renew the copies.

To favor the health of the stored data, it is advisable to use a Faraday Cage for storing the NFC cards. This prevents electromagnetic interference, current induction, or electrical energy disturbances, whether by natural phenomena such as solar storms or malicious attempts by third parties.

Main communication interface

FT5446DQS capacitive touch controller

Screen_EN_cuvex_69774a1e-da3d-4fd7-9c30-5c1f3acff355

The screen serves as the primary communication interface with the customer, which is why we have chosen the capacitive touch controller FT5446DQS. It is a single-chip solution with an enhanced microcontroller unit (MCU) built-in. It offers the benefits of full-screen common-mode scanning technology, quick response time, and high level of accuracy.

The screen has a size of 4 inches to provide comfort to the customer, an intuitive UIX based on easy-to-navigate screens, and an alphanumeric keypad with a layout popular on mobile devices, allowing the customer to feel familiar with the interface from the first use.

In our first version of the Firmware, data capture is open to plain text or seeds under the BIP39 standard, so the auto-fill and dictionary validation contribute to the customer's peace of mind when entering their words. Updates for Monero and Shamir dictionaries will be published shortly.

Just like with any other system component, when the power is cut, the screen turns off, and everything in the memory is reset to ensure it cannot be recovered by intruders.

100% verifiable code

Firmware update via the Cuvex mobile app

The firmware acts as the master of ceremonies, orchestrating the functionalities made available to customers. From handling cards to the processes of encrypting, decrypting, and cloning, all these workflows are defined and executed based on the firmware's lines of code, which provide the appropriate instructions to each of the previously described components.

Worry not, the algorithm that encrypts your secret is not defined here, as we've mentioned before, this is done cold and hardware-based. What the firmware does is utilize the microcontroller's APIs to execute the cryptographic functions exposed by the microcontroller and follow the logical step sequence to: take the input data from the screen, convert it into a cryptogram (using your powerful STM32U585), and send it to your NFC card via the NFC/RFID CR95HF transducer.

If this explanation has left you wanting more, you are a true custodian. To verify for yourself what we say, you will find the entire source code of the Firmware at this link. Our code is 100% verifiable, visible, editable, and you can compile it yourself. We have also added a bit more information about this process in the "Cryptography" section of this document.

The Firmware update is done through the Cuvex mobile App, using the previously described Bluetooth channel. In this way, your mobile acts as a "Firewall," abstracting everything related to the update download from the internet. In summary, the App will notify you when there is a new update, it will be downloaded to the secure element of your mobile, so that, once you are paired via Bluetooth, the binary is sent securely to your Cuvex.

It is important to highlight that before writing the Firmware on the device, a validation of the software's integrity and authenticity is performed based on a digital signature. This ensures that no other software and/or alteration of it can be executed on your Cuvex. The moment the device detects an anomaly, it proceeds to restart and return to factory mode, requesting the installation of a valid binary again.

The Key Role of
the Bootloader

It acts as a gatekeeper

Bootloader_cuvex3_4b90c7fd-ec92-48cb-b927-998c3f97a3d7

If the Firmware is the pianist, the Bootloader is the piano tuner. This software is responsible for preparing the basic elements for the Firmware to operate, ensuring the hardware's integrity and preventing the installation of any unknown software.

One of its main features is that it is the only entity capable of managing the Bluetooth controller. With this, no software process outside of the Bootloader can power and/or use the Bluetooth module.

Upon booting, it checks if a valid instance of the Firmware exists. If not, it completely erases the memory partition designated for the Firmware App and activates update mode, turns on the Bluetooth module, and loops waiting for a new Firmware to be written to the dedicated memory.

Similarly, if the user initiates the update function, the installed Firmware erases the verified signature, which triggers the automatic deletion of all the memory housing the Firmware's own instance, forcing the device to operate again with the Bootloader.

Another function is to validate the digital signature of the software before proceeding with its execution, doing so through the RSA cryptographic function exposed by the microcontroller. If the content of the software to be installed has been altered and/or has not been signed with Cuvex's private key, the Bootloader will erase the binary and return to the initial factory state, waiting for a Firmware update.

In summary, we can say that the Bootloader acts as a factory recovery software that only allows updates to Firmware signed by Cuvex and isolates access to the Bluetooth communication channel.

20363d_adf38ca624b74338bbd06230c85f05ec_mv2

Firmware Update
Process - Activity Diagram

0 Knowledge policy

Fully developed with native source code.

Built under a zero-knowledge policy and designed to the highest standards of computer security, the Cuvex App offers a range of complementary functions for owners of a Cuvex device and anyone looking to migrate to true sovereign self-custody.

One of the app's main functions is to provide the Cuvex device with the latest Firmware updates, acting as an intermediary between the download services and the cold encryption device. It plays the role of a Firewall, ensuring communication with the official factory services and sending the binary file through an alternative BL channel with P2P encryption. This ensures that your Cuvex is never exposed to the internet and that conversations are securely conducted with the official app published on platform stores.

It is fully developed with native source code, leveraging the frameworks of iOS / Android platforms and following the best security practices. Among the implemented controls, we have the detection of BL / WiFi communication functions or the presence of a SIM card in the device. These controls are activated in key processes that block progress due to non-compliance with requirements.

Here are its other functions:

BTC Wallet Creation: Allows you to generate your seed's entropy yourself through the Dice and Coin process for the first 23 words. Additionally, it calculates the 24th word and generates the public/private keys. The result is a wallet not generated by third-party software and without any dependencies (real freedom). You need no more; with this, you have everything to start holding your Satoshis. Do not forget to encrypt your seed and keys with your Cuvex.

Wallet Balance Verification: This disruptive service will send you real-time notifications of any changes in the blockchain related to your wallets, a true guardian of your crypto assets. Best of all, you only need to register the public key (Xpub) of your Wallet. Moreover, in line with the zero-knowledge policy, it's impossible to establish a connection between the users and the public keys (actually, we have no data on our App users, haha).

Cuvex Card Management: These are support services for managing the cards where you store your secrets. With the App, you can associate identification information instead of having to physically label your cards, thus avoiding a bad security practice. It also offers scheduled reminder tasks to ensure the cryptogram's consistency and lifespan.

TOR Communications: The app has its own TOR network connection client to ensure comprehensive privacy in external calls. This strengthens processes like balance verification and Balance Alert services.

The robustness of AES256

Worldwide recognition, adopted by military and government entities.

The encryption and decryption flows made available to users utilize the symmetric cryptography algorithm AES 256 GCM, the most globally recognized encryption standard, adopted by the vast majority of military and governmental entities. AES has undergone extensive cryptographic scrutiny and analysis since its adoption as a standard in 2001, and its consistency and robustness have been continually revalidated. In fact, not even future quantum computers would achieve the quantum advantage necessary to break its security through brute force calculations.

In your Cuvex, this algorithm is implemented in the hardware itself. To this end, the microcontroller has specific AES power units, which not only provide accelerated processing of the calculations but also abstract the software from participating in these calculations.

20363d_c28474749d3b4a0b9f919189aa8d16c8_mv2

Encryption Process
- Activity Diagram

As for the digital signature of the Firmware, the asymmetric algorithm RSA has been chosen. Again, the implementation is hardware-based, capable of handling the key pair for Digital signature validation and CRC and HASH functions for fingerprinting. With the Private Key, Cuvex services sign the binary installed on the device. With the public key, the device itself can verify the software's authorship. Additionally, the integrity of the software is checked using SHA256.

It's worth mentioning that we are aware that RSA, like any other asymmetric encryption standard, has its days numbered with the advent of quantum computing, which has shown that brute force work is exponentially reduced when trying to find the private key from the public one. Knowing that Y2Q (Years to Quantum) is less than a decade away, our backlog already includes the implementation of the Crystal Dilithium algorithm, designed for the post-quantum era.

Another interesting feature to highlight is the ability to generate random data. The microcontroller has its own generator called RNG (True Random Number Generator) that provides entirely entropic outputs from an analog source, compliant with NIST SP 800-90B as a valid source of entropy and, therefore, can be used as a non-deterministic generator of random bits.

This is particularly relevant for processes like Bluetooth pairing, where the PassKey entry process is based on generating a PIN from the Cuvex device that, being truly entropic, prevents attacks based on dictionaries and/or brute force.