Offline secure e-paper vault with biometric access

Abstract

Systems and devices for biometric authentication and encrypted storage in accordance with various embodiments of the invention are illustrated. One embodiment includes a vault device, including a biometric sensor, wherein when enrollment data, belonging to a prospective user, is input into the biometric sensor, the prospective user is authorized and the enrollment data is securely transmitted to a processing device, configured to store the enrollment data as authentication data for the authorized user, and when one of the authorized users inputs biometric data, matching some of the authentication data, into the biometric sensor, a set of access permissions enables access to an encrypted document during a user session duration. The processing device stores a secure dataset including the authentication data for the authorized user, encryption data for each encrypted document, and parameters for the vault device, and memory stores the encrypted documents.

Description

Offline Secure E-Paper Vault with Biometric AccessCROSS-REFERENCE TO RELATED APPLICATIONS

[0001] The current application claims the benefit of and priority under 35 U.S.C. § 119(e) to U.S. Provisional Patent Application No. 63 / 721,377 entitled “Offline Secure E-Paper Vault with Biometric Access and Redundant Storage System,” filed November 15, 2024, and U.S. Provisional Patent Application No. 63 / 919,247 entitled “Digilock Vault Tablet,” filed November 17, 2025. The disclosures of U.S. Provisional Patent Application Nos. 63 / 721,377 and 63 / 919,247 are hereby incorporated by reference in their entireties for all purposes.FIELD OF THE INVENTION

[0002] The present invention generally relates to access management and, more specifically, to secure biometric access protocols and secure digital vaults.BACKGROUND

[0003] Cryptography is generally used to provide security for (e.g., cryptographic token) transactions, for example, through facilitating card-based transactions and creating immutable ledgers known as blockchains. Many cryptosystems incorporate sets of algorithms used to encrypt and decrypt communications for privacy, using encryption and decryption algorithms. These systems are divided into two main types: symmetric and asymmetric. While symmetric cryptography uses the same secret key for both encryption and decryption, and asymmetric cryptography uses a pair of keys: a public key (generally used) for encryption and a private key (generally used) for decryption.SUMMARY OF THE INVENTION

[0004] Systems and devices for implementing secure digital vault devices with biometric authentication and encrypted storage in accordance with various embodiments of the invention are illustrated. One embodiment includes a secure digital vault device, including at least one biometric sensor, wherein when a biometric enrollment data, belonging to at least one prospective user, is input into the at least one biometric sensor, the at least one prospective user is authorized as at least one authorized user and the biometric enrollment data is securely transmitted to at least one secure tamper-resistantprocessing device, configured to store the biometric enrollment data as authentication data for the at least one authorized user, and when one of the at least one authorized user inputs biometric data, matching at least some of the authentication data, into the at least one biometric sensor, a particular set of access permissions enables access to at least one encrypted document during a user session duration, at least one secure element, including a secure tamper-resistant processing device, wherein the secure tamper-resistant processing device stores a secure dataset including the authentication data for the at least one authorized user, encryption data for each of the at least one encrypted document, and a plurality of parameters for the secure digital vault device, and at least one memory, configured to store the at least one encrypted document, wherein a first user of the at least one authorized user is associated with a first set of access permissions, corresponding to the at least one encrypted document.

[0005] In a further embodiment, the at least one authorized user includes a plurality of authorized users and a particular document of the at least one encrypted document is accessed using a Boolean combination of at least some of the plurality of authorized users.

[0006] In another embodiment, when the first user of the plurality of authorized users is authenticated using the at least one biometric sensor, a given document of the at least one encrypted document is only accessible when a second user of the plurality of authorized users is also authenticated using the at least one biometric sensor during the user session duration.

[0007] In a further embodiment, accessing the particular document requires sequential biometric authentication of each user specified in the Boolean combination during the user session duration and verification by the secure tamper-resistant processing device that all required users in the Boolean combination have been successfully authenticated before granting document access to the particular document.

[0008] In a still further embodiment, the secure tamper-resistant processing device maintains an authentication state for each of the plurality of authorized users and only permits the document access when the authentication state satisfies requirements corresponding to the Boolean combination for the particular document.

[0009] In another embodiment, the secure tamper-resistant processing device facilitates user authentication for the secure digital vault device through a secure channel.

[0010] In another embodiment, the secure digital vault device further includes a complex processor including a plurality of processor cores, wherein the complex processor runs at least one operating system for the secure digital vault device.

[0011] In a further embodiment, the plurality of processor cores includes a secure core that is directed to implementing a set of device security operations and a less secure core that is directed to a set of user-facing operations, and the secure core communicates with the less secure core using inter-process communication.

[0012] In a still further embodiment, the complex processor includes a microcontroller unit (MCU).

[0013] In a still further embodiment, the less secure core activates a plurality of logical zones, to perform the set of user-facing operations, the plurality of logical zones including a secure zone configured to perform a cryptography-based subset of the plurality of logical zones and an insecure zone configured to perform a user-interface-based subset of the plurality of logical zones.

[0014] In a further embodiment, the secure zone includes a trusted execution environment (TEE).

[0015] In another further embodiment, a Linux operating system operates exclusively in the insecure zone.

[0016] In another further embodiment, the secure core hosts a security enclave.

[0017] In another further embodiment, the complex processor is configured to securely encrypt at least one new document into the at least one encrypted document based upon the authentication data of the at least one authorized user and store the at least one encrypted document in the memory.

[0018] In another embodiment, the at least one biometric sensor includes at least one of a fingerprint sensor or a camera.

[0019] In another embodiment, the at least one memory includes volatile memory configured to store the at least one encrypted document that are accessible by the at least one authorized user and non-volatile memory configured to store a plurality of confidential document backups.

[0020] In a further embodiment, the volatile memory is further configured to store checksums for each of the at least one encrypted document.

[0021] In another embodiment, the secure digital vault device is exclusively operable offline.

[0022] In another embodiment, the plurality of parameters includes at least one selected from the group consisting of a password, the first set of access permissions, a set of cryptographic keys, and an authentication state for the secure digital vault device.

[0023] In another embodiment, the secure digital vault device further includes a backup secure tamper-resistant processing device including a copy of the secure dataset from the secure tamper-resistant processing device of the secure digital vault device.

[0024] In a further embodiment, the backup secure tamper-resistant processing device is configured so that when the backup secure tamper-resistant processing device is input into a secondary device, the secondary device is capable of accessing the secure dataset and decrypting the at least one encrypted document.

[0025] In a further embodiment, the secure digital vault device further includes at least one hardware-based data transmission interface, wherein an interaction between an encrypted flash drive and the at least one hardware-based data transmission interface of the secure digital vault device enables an encrypted backup of the at least one encrypted document stored in the at least one memory to the encrypted flash drive.

[0026] In a still further embodiment, at least one of the backup secure tamperresistant processing device and the encrypted flash drive is configured to transfer data to the secondary device to the secure digital vault device.

[0027] In another further embodiment, the backup secure tamper-resistant processing device and the encrypted flash drive in tandem enable restoration of the at least one encrypted document and the plurality of parameters to the secondary device by authenticating the backup secure tamper-resistant processing device with a second secure tamper-resistant processing device of the secondary device using public key infrastructure and transferring the authentication data, the encryption data, and the plurality of parameters from the backup secure tamper-resistant processing device to the secure tamper-resistant processing device of the secondary device via a secure channel protocol.

[0028] In another embodiment, the secure digital vault device further includes at least one hardware-based data transmission interface, wherein for the secure digital vault device, the at least one hardware-based data transmission interface provides an exclusive source for both power input to the secure digital vault device and file transfers to and from the secure digital vault device.

[0029] In a further embodiment, each of the at least one hardware-based data transmission interface is a USB-C port.

[0030] In another further embodiment, the secure digital vault device includes network threat detection functionality that monitors the at least one hardware-based data transmission interface to detect unauthorized network connectivity attempts and triggers a security response when a disallowed connection type is detected.

[0031] In a still further embodiment, the security response includes at least one selected from the group consisting of device lockdown, data zeroization, session termination, and alert generation.

[0032] In another embodiment, the secure digital vault device further includes a touchscreen display, wherein the first set of access permissions enables the first user of the at least one authorized user to modify and annotate the at least one encrypted document.

[0033] In a further embodiment, the secure digital vault device is an e-paper touchscreen tablet.

[0034] In another embodiment, storing the biometric enrollment data as the authentication data is performed using a biometric enrollment process including establishing a secure channel between the at least one biometric sensor and the secure tamper-resistant processing device using pre-provisioned cryptographic keys stored in both the at least one biometric sensor and the secure tamper-resistant processing device, capturing the biometric enrollment data from the at least one prospective user via the at least one biometric sensor, encrypting the biometric enrollment data using a session key derived from the pre-provisioned cryptographic keys, and storing the biometric enrollment data as part of the authentication data in the secure tamper-resistant processing device, wherein the pre-provisioned cryptographic keys are embedded during a secure provisioning process that occurs prior to device deployment.

[0035] In a further embodiment, establishing the secure channel includes performing a mutual authentication between the at least one biometric sensor and the secure tamper-resistant processing device using the pre-provisioned cryptographic keys, generating ephemeral session keys for the biometric enrollment process, and verifying cryptographic certificates pinned to both the at least one biometric sensor and the secure tamper-resistant processing device during the secure provisioning process.

[0036] In another further embodiment, the secure provisioning process includes loading root certificates and private / public key pairs into the at least one biometric sensor and the secure tamper-resistant processing device in a secure facility, establishing a hardware root of trust using cryptographic keys permanently stored in the secure digital vault device, and configuring secure boot processes that verify system component integrity using the pre-provisioned cryptographic keys before allowing biometric enrollment operations.

[0037] In another embodiment, the secure tamper-resistant processing device is a smart card.

[0038] One embodiment includes a secure digital vault backup and restoration system, including a first secure digital vault device including a first smartcard and a first encrypted data partition stored in non-volatile memory, a second secure digital vault device capable of securely recovering encrypted data backed up by the first secure digital vault device, the second secure digital vault device including a second smartcard, a backup smartcard configured to store authentication and cryptographic data extracted from the first smartcard via a secure channel of communication, and an encrypted flash drive configured to store a copy of the first encrypted data partition from the first secure digital vault device, wherein the second secure digital vault device is configured so that when both the backup smartcard and the encrypted flash drive are inserted into the second secure digital vault device, the backup smartcard transfers a set of authentication and cryptographic data to the second smartcard using a secure channel protocol.

[0039] In a further embodiment, the set of authentication and cryptographic data includes biometric data corresponding to at least one user of the first secure digital vault device.

[0040] In another embodiment, when both the backup smartcard and the encrypted flash drive are inserted into the second secure digital vault device, the second secure digital vault device copies a subset of data from the encrypted flash drive onto a data partition of the second secure digital vault device.

[0041] In another embodiment, when both the backup smartcard and the encrypted flash drive are inserted into the second secure digital vault device, the backup smartcard and the second smartcard authenticate each other via public key infrastructure (PKI).

[0042] In another embodiment, the secure channel protocol is performed using a trusted execution environment (TEE).

[0043] In another embodiment, transferring the set of authentication and cryptographic data to the second smartcard enables the second secure digital vault device to access a set of documents restored from the first secure digital vault device, using the same authentication credentials as for the first secure digital vault device.

[0044] In another embodiment, the set of authentication and cryptographic data includes first secure digital vault device information selected from the group consisting of biometric fingerprint templates, cryptographic keys, user permissions, and authentication states.

[0045] In another embodiment, the encrypted flash drive stores the first encrypted data partition in LUKS2 format, and cryptographic keys for decrypting the LUKS2 format are transferred from the backup smartcard to the second smartcard.

[0046] In another embodiment, at least one of the first secure digital vault device or the second secure digital vault device is a touchscreen device including a biometric sensor.

[0047] In still another embodiment, the backup smartcard is stored on the first secure digital vault device.

[0048] One embodiment includes a method for performing biometric authentication in a secure digital vault device, including initiating, using a biometric sensor, a secure channel between a microcontroller unit (MCU) and the biometric sensor, wherein initiating the secure channel includes generating a session nonce and transmitting the session nonce from the biometric sensor to the MCU, generating, using the MCU, a session key, uniquely corresponding to the secure channel, using the session nonce and a KeyEncapsulation Mechanism (KEM) payload that encapsulates the session key, producing, using the MCU, a digital signature over the session nonce, the KEM payload, and a transcript hash using a private key of the MCU, transmitting the digital signature to the biometric sensor using the MCU, verifying, by the biometric sensor, the digital signature using a cryptographic key certificate of the MCU, decapsulating the KEM payload with the biometric sensor to derive the session key, and authenticating, using the session key and the MCU, a set of biometric data in a session corresponding to the secure channel.

[0049] In a further embodiment, authenticating the set of biometric data includes capturing the set of biometric data using the biometric sensor, encrypting the set of biometric data using the session key and a unique message nonce to produce a ciphertext, authenticating, using the biometric sensor, a message dataset including the ciphertext and a message header, wherein the message header includes the unique message nonce, transmitting the message dataset to the MCU, and decrypting, with the MCU, the set of biometric data using the session key.

[0050] In a further embodiment, the message header further includes a timestamp corresponding to when the set of biometric data is captured and a counter quantifying messages between the MCU and the biometric sensor.

[0051] In a still further embodiment, decrypting the set of biometric data further includes verifying the set of biometric data and checking replay protection, using the counter, the timestamp, and the unique message nonce, for transmitting the message dataset to the MCU.

[0052] In a still further embodiment, the message header further includes a session ID corresponding to the session key, and capturing the set of biometric data includes confirming, using the MCU, that the session nonce corresponds to the session ID.

[0053] In another embodiment, the method further includes processing, by the MCU, the set of biometric data within a trusted execution environment to perform biometric matching.

[0054] In a further embodiment, the method further includes terminating the secure channel by erasing the session key and session context from both the biometric sensor and the MCU.

[0055] In another embodiment, terminating the secure channel includes cryptographically attesting, using the biometric sensor, to a hardware state by transmitting a digitally signed attestation block to the MCU.

[0056] In another embodiment, the biometric sensor includes a fingerprint reader.

[0057] In another embodiment, the MCU communicates with the biometric sensor using a trusted execution environment.

[0058] Additional embodiments and features are set forth in part in the description that follows, and in part will become apparent to those skilled in the art upon examination of the specification or may be learned by the practice of the invention. A further understanding of the nature and advantages of the present invention may be realized by reference to the remaining portions of the specification and the drawings, which form a part of this disclosure.BRIEF DESCRIPTION OF THE DRAWINGS

[0059] The description and claims will be more fully understood with reference to the following figures and data graphs, which are presented as exemplary embodiments of the invention and should not be construed as a complete recitation of the scope of the invention.

[0060] FIG. 1 illustrates an example of a secure device that executes instructions for information storage in accordance with various embodiments of the invention.

[0061] FIGS. 2A - 2B illustrate specific examples of an e-paper touchscreen device, implemented in accordance with miscellaneous embodiments of the invention.

[0062] FIGS. 3A - 3B illustrate specific examples of an e-paper tablet, implemented in accordance with certain embodiments of the invention.

[0063] FIGS. 4A - 4C conceptually illustrate a process for applying biometric scanners to facilitating cryptosystems via authentication in accordance with many embodiments of the invention.

[0064] FIGS. 5A - 5B conceptually illustrate examples of microcontroller units (MCUs) constructed in accordance with multiple embodiments of the invention.

[0065] FIG. 6 illustrates a process of secure provisioning, performed in accordance with several embodiments of the invention.

[0066] FIG. 7 illustrates a specific hardware implementation variant used for e-paper tablets configured in accordance with numerous embodiments of the invention.DETAILED DESCRIPTION

[0067] Turning now to the drawings, systems and methods for implementing electronic storage devices, implementing encrypted data storage and transfer, network interference detection, and (multi-)biometric access permissions are illustrated. Devices implemented in accordance with miscellaneous embodiments of the invention may utilize secure digital vaults for storing confidential information including but not limited to sensitive documents, seed phrases, private keys, and passwords. Devices may, additionally or alternatively, utilize additional safety elements, including but not limited to biometric authentication, persistent storage, secret sharing protocols, and offline operation configurations. As such, systems in accordance with various embodiments of the invention may address these problems by creating secure e-paper-based offline vaults that minimize data breach and memory loss risk through advanced security features. Such implementations may effectively operate in settings including but not limited to Web3 systems, managing sensitive credentials (e.g., private keys for cryptocurrencies) and documents without relying on internet-connected devices. Moreover, devices implemented in accordance with many embodiments of the invention may minimize risk of security breach through circumventing most, if not all, network connectivity functionality.

[0068] Systems in accordance with many embodiments may prevent unauthorized data access by utilizing secure components and internal transfers of encrypted data. In particular, secure devices in accordance with some embodiments may ensure that data is consistently encrypted by default (e.g., when not being processed), through means including but not limited to AES-XTS encryption via LLIKS2 and Post-Quantum Cryptography. Further, the use of multiple user partitions (each with separate encrypted storage) may efficiently limit the possibility of data breaches. Secure devices may carry the ability to cipher arbitrary large volumes of data (e.g., data-at-rest) in internal storage and / or in backup drives. Additionally or alternatively, secure devices in accordance with miscellaneous embodiments of the invention may facilitate data-in-motion via trusted,encrypted secure channels and / or biometric data encryption to ensure end-to-end encryption. This may confirm that (individual) system documents are only fully unencrypted during brief periods (i.e., active viewing / editing by authenticated users) and / or that data is only ever unencrypted within a trusted execution zone of a secure processor. In many embodiments of the invention, secure processors (e.g., microcontroller units) may section responsibilities with constituent cores and / or zones separating critical operations from user interface functions.

[0069] Systems and methods in accordance with various embodiments of the invention may function based on the paradigm of maximal security and preventing unauthorized access to confidential documents stored on the secure devices. Secure devices configured in accordance with several embodiments may operate based on PostQuantum Cryptography (PQC). For example, secure devices may utilize unique PQC stream encryption algorithms created based on multivariate cryptography (and may use components certified by the National Institute of Standards and Technology). Additionally or alternatively, PQC capabilities may be enabled / disabled. Potential PQC operations may be performed using ciphers including but not limited to Gimli (a symmetric permutation-based cipher, inherently resistant to Shor's algorithm, which targets asymmetric crypto). Implementations of Gimli are disclosed in D. J. Bernstein et al., “Gimli: a cross-platform permutation,” in Cryptographic Hardware and Embedded Systems-CHES 2017: 19th International Conference, Taipei, Taiwan, September 25-28, 2017, Proceedings. Springer, 2017, pp. 299-320, the disclosure of which, specifically those portions describing the system’s response to quantum collision attacks is hereby incorporated by reference in its entirety. In accordance with various embodiments, secure devices may be developed based on languages including but not limited to RUST and C / C++. Linux, or other secure OSes, may be used for embedded systems, which gives additional insurance in the security robustness of built-in features of RUST compilers. Additionally or alternatively, aggressive Al-boosted watchdogs may be used to protect secure devices based on Runtime application self-protection (RASP) through methods including but not limited to locking decryption and zeroization.

[0070] There are several use cases for secure devices (including but not limited to e-paper tablets) implemented in accordance with many embodiments of the invention, including but not limited to individual, familial, corporate and government usage.

[0071] (1) Individual: these secure devices may be used by the person who wants the safest way to store seed phrases for digital / crypto wallets (there are no ways to do this today as safe as this tablet), passwords, digital secrets and important documents including but not limited to property deeds, official certificates of any kind, will, and trusts.

[0072] (2) Familial: these secure devices may find a perfect use case in the inheritance and sharing of secrets with heirs without any counterparty risks (e.g., banks, lawyers) and / or can be used by multiple individuals among the same household when needed.

[0073] (3) Corporate: these secure devices may be used to share corporate secrets among executives (for instance requiring the fingerprints of both the CEO and the CTO to access the company's bank account); and / or to store certain sensitive (e.g., HR) files with access rights exclusive to certain entities (e.g., managers and / or HR execs).

[0074] (4) Government: these secure devices may greatly simplify and secure the handling of secret documents for government officials and can prevent the all-too-common leaks occurring on a regular basis. In such cases, the complex Boolean rules of access rights to various people or groups would be very useful.

[0075] An example of a secure device that executes instructions for information storage in accordance with various embodiments of the invention is illustrated in FIG. 1. Secure devices 100 in accordance with many embodiments of the invention can include (but are not limited to) one or more of mobile devices, sensors, and / or computers. Secure devices 100 configured in accordance with many embodiments of the invention may facilitate offline storage of confidential data (e.g. , sensitive documents, passwords, private keys, and credentials). Systems may ensure maximum security through components including but not limited to exclusive offline operations, fully encrypted communication protocols between components, permission-based access, and redundant storage. Secure devices 100 includes processors 105, peripherals 110, interfaces 115, and memory 120. One skilled in the art will recognize that a secure device 100 may excludecertain components and / or include other components that are omitted for brevity without departing from this invention.

[0076] Potential processors 105 can include (but are not limited to) a processor, microprocessor, controller, microcontroller, or a combination of (micro)processors and / or (micro)controllers that performs instructions (e.g., stored in the memory 120) to manipulate data (e.g., stored in the memory 120). Processor instructions can configure the processor(s) 105 to perform processes in accordance with certain embodiments of the invention. In various embodiments, processor instructions can be stored on a non-transitory machine-readable and / or computer-readable medium. Additionally or alternatively, processors 105 may, in various cases, utilize RISC instruction set architectures to optimize security (e.g., ARM processors). In accordance with many embodiments of the invention, processor(s) 105 may operate based on functions facilitated through one or more Trusted Execution Environments (TEEs), for example, Open Portable TEEs, as described below. Systems and methods in accordance with some embodiments may utilize supplementary microcontrollers in the form of smartcards 140.

[0077] Smartcards 140 may be used to facilitate a wide variety of security-critical operations and decisions, including but not limited to maintaining (e.g., authentication) state(s), parameters (e.g., user permissions, passwords, biometric data), and (e.g., cryptographic) keys for the corresponding device. However, in accordance with many embodiments, smartcard secrets can be transferred to any other (compatible) device, allowing users to maintain the same states, parameters, keys, etc. Specifically, systems in accordance with various embodiments may manage encryption keys using smartcards. For example, systems may implement a smartcard-based key derivation scheme where Key Encryption Keys (KEKs) are derived from symmetric master keys provisioned in personalization machines and / or smartcards 140. The derivation may be based on a unique tablet identifier, allowing any authorized smartcard to unlock any compatible device while maintaining security isolation. In various cases, KEKs may correspond, but are not limited, to disk encryption specifications such as Linux Unified Key Setup 2 (LUKS2). On a secure host, final root filesystem may be created and then encrypted withthe KEKs, ensuring that the operating system remains protected even when the storage medium is physically compromised.

[0078] Smartcard(s) 140 configured in accordance with numerous embodiments of the invention may function utilizing operating systems including but not limited to JavaCard OS, Native NXP JCOP OS, MULTOS, ... . Smartcards 140 may, in accordance with numerous embodiments of the invention, (be authorized to) perform functions including but not limited to storing biometrics, matching biometrics for authentication, changing permissions, storing keys and secrets, and deciphering documents (beyond the security layers). In some cases, the above functionality may be exclusive to the smartcards 140. Additionally or alternatively, smartcards 140 may be configured to access data including but not limited to: Application data storage (application+smartcard-based) libraries to maintain persistent data storage in the smartcard memory; State machine (application+smartcard-based) libraries to maintain application state machines in the smartcard; and Java Card applets that provide functions that operate on high-security environments (e.g., cryptographic computation, key storage, secure decisionmaking), such as the above functionality.

[0079] Memory 120 may include but is not limited to volatile 135 and / or non-volatile 130 memory. In accordance with many embodiments of the invention, memory 120 may be configured with various storage capabilities, including but not limited to categories of volatile 135 (e.g., random access memory like DRAM, SRAM, ...) and / or non-volatile memory 130 (e.g., flash memory, FRAM, ROM, ...), possibly with ECC (error correcting codes) which may ensure data integrity and longevity (e.g., when part of the memory component fails). In various cases, multiple different types of memory are used in tandem (e.g., NOR flash memory, Ferroelectric RAM, Magnetoresistive RAM). For example, secure devices 100 may be equipped with non-volatile memory 130 that is chosen for providing (long-lasting and high-reliability) storage to safeguard against data loss due to hardware failure (i.e., via backup). Additionally or alternatively, the secure devices 100 may include volatile memory 135 for processing and short-term storage of files. In many cases, individual files stored in the memory 120 may be associated with a checksum, which can be verified (e.g., via periodic scan of OS files)to ensure file integrity. In many cases, checksums may be stored in non-volatile memory 130.

[0080] In various embodiments of the invention, partitions of the memory 120 may be used to store various components including but not limited to an unencrypted boot partitions containing encrypted U-Boot binaries, encrypted (e.g. LUKS2 encryption) OS partitions, and optional encrypted partitions for user documents and other system functions. These encrypted partitions may require smartcard secret (key) to decrypt. Once decrypted, the operating system may be loaded into RAM as a temporary filesystem, cannot be persistently modified. The boot partition may remain read-only to prevent tampering while allowing signature verification. With respect to document access, memory 120 allows for multiple user profiles, with individual users having permissionbased access to specific files and / or folders. For highly sensitive files, secure devices 100 may use collaborative joint authentication requirement (e.g., Shamir's secret sharing scheme, a trusted set feature), requiring multiple users to present their credentials (e.g., simultaneously) to unlock access. This prevents any single person from compromising critical data. Additionally or alternatively, different permissions may exist for writing, reading and listing (knowing the existence of) files.

[0081] In accordance with several embodiments of the invention, categories of memory 120 may include but are not limited to non-volatile memory 130 used to store authentication data and facilitate encryption for all files (e.g., via secure elements). Nonvolatile memory 130 configured in accordance with some embodiments of the invention may incorporate, but is not limited to, functionality / instructions for smartcards 140.

[0082] Peripherals 110 in accordance with many embodiments of the invention can be used to gather inputs that can be used to perform various functions including but not limited to implementing cryptographic algorithms, and keeping secrets like private keys for encryption purposes (e.g., on secure elements). Peripherals 110 can include any of a variety of components for capturing and / or presenting data, such as (but not limited to) displays and / or sensors directed to a variety of input and output modalities. Secure devices 100 configured in accordance with various embodiments may, additionally or alternatively, incorporate touchscreen and / or electronic paper (e-paper) displays, enabled via thin form factor. In various cases, panels may be placed on top of displays to capture data, including but not limited to EMR (Electro-Magnetic Resonance) panels for stylus input and CTP (Capacitive Touch Panels) for touch input. Some embodiments of thedevice may employ other display technologies, including but not limited to organic lightemitting diodes (OLEDs) and liquid-crystal displays (LCDs), depending on the intended application, ambient lighting conditions, and / or user preference. In accordance with many embodiments of the invention, potential peripherals may include biometric (e.g., fingerprint) sensors / readers. Devices may utilize touch and / or stylus input (e.g., in tandem with e-paper) to allow users to interact with and annotate documents (e.g., without needing additional components). Further, the stylus input allows for creation of personal, very secure and confidential offline documents that will only exist on the device (e.g., crypto private keys or seeds mnemonics, important memos). Additionally or alternatively, secure devices 100 can include cameras for optical input, enabling functions such as QR code scanning for secure data retrieval and document import as pictures (or later converted to text via OCR). Additionally or alternatively, secure devices 100 can include microphone-based input for voice commands and / or speech-to-text functionality, supporting flexible and multimodal interactions that align with different access and operational scenarios.

[0083] Secure devices 100 can utilize interface(s) 115 (e.g., interface buses) to transmit and receive data based upon the instructions performed by processor(s) 105. In various embodiments, the interface(s) 115 may utilize synchronous serial communication (e.g., via serial peripheral interfaces sending byte arrays). Additionally or alternatively, systems in accordance with some embodiments may rely on USB ports for power and file transfers (e.g., to and from the vault / memory 120). Moreover, USB ports implemented in accordance with certain embodiments of the invention may specifically have limited network connectivity capabilities. In many cases, networks may be monitored by software specifically configured to identify when the secure devices have been accessed. For example, in cases when a USB key is used to connect to the secure device to act as a (e.g., pre-determined) disallowed form of connection (e.g., a network card), systems in accordance with many embodiments of the invention may detect the connection as a security breach by the RASP and trigger defense protocols. In some cases, secure devices 100 may not include internal batteries, drawing power exclusively from the USB bus when connected to an external source, and ensuring that the secure devices 100 are operational only when deliberately connected. However, secure devices 100 mayincorporate batteries in certain embodiments, allowing users to operate them independently of an external power source. Secure devices 100 in accordance with miscellaneous embodiments of the invention may operate exclusively in offline mode. In such cases, the devices will not feature any data transmission interfaces / communication modules (e.g., Wi-Fi, Bluetooth, Ethernet) besides USB (e.g., USB-C) ports, used solely for transferring files when a user connects the device to a computer and / or external drive, and minimizing the attack surface and preventing remote exploitation. The USB-C port may enable the copy of the device encrypted content from a master device to a copy device (e.g., via smartcard) to have a duplicate (useful for redundancy and location diversity in case of disaster).

[0084] While specific architectures, assemblies, components and / or systems are described above, any of a variety of assemblies, components and / or systems can be utilized as appropriate to the requirements of specific applications in accordance with multiple embodiments of the invention.

[0085] Specific examples of e-paper tablets, implemented in accordance with miscellaneous embodiments of the invention, are illustrated in FIGS. 2A - 3B. E-paper tablets (“tablets”) may include, but are not limited to e-paper touchscreen devices. E-paper tablets (“tablets”) may include, but are not limited to e-paper touchscreen devices. FIG. 2A exhibits an example of the e-paper touchscreen device 1 showing fingerprint sensor 2, stylus 3, USB-C ports 4 and 5, and secure element I smart card connector 6 and 7. Meanwhile, FIG. 2B illustrates a block diagram of the system architecture, including secure element 6, storage components 7, 8, e-paper display 9, USB-C ports 10, 11 and MCU 12.

[0086] FIGS. 3A - 3B illustrate general examples of e-paper tablets configured in accordance with many embodiments of the invention. E-paper tablets may include, but are not limited to several principal hardware components: a secure element (SE 320), at least one sensor (e.g., video camera 330, fingerprint sensor 340), at least one internal storage disk 350, at least one external port 360 (e.g., USB / USB-C ports), and an electronic paper (e-paper 370) display. E-paper tablets configured in accordance with some embodiments may control many of the above components using a MCU 310, whichmay (additionally or alternatively) be used to run tablet operating systems (OSs) in addition to functions described below.

[0087] Systems and methods in accordance with various embodiments of the invention may use touchscreen functionality including but not limited to e-paper 370 touchscreen displays. The use of e-paper 370 may allow for viewing and interacting with stored files as well as natural writing as if it was paper when combined with a stylus, including but not limited to PDF and Microsoft Word documents. As suggested above, interacting with the e-paper device may be performed via hand and / or using styluses 380. Moreover, secure devices in accordance with some embodiments of the invention may incorporate physical keyboards for user input, offering a tactile option that complements (or replaces) the e-paper 370 touchscreen and stylus 380 input for certain use cases. The keyboard may be integrated and / or detachable, and allows for data entry without the need for on-screen touch interaction, which some users may find beneficial for extended usage and / or specific applications.

[0088] In accordance with multiple embodiments of the invention, fingerprint sensors 340 may be used for biometric authentication purposes. Specifically, fingerprint sensors 340 may be used by users to enroll themselves by providing an accepted biometric scan (e.g., of a certain number of their fingers). This biometric scan may be stored in the secure element 320 as an enrollment reference (e.g., via smartcard applet). Further, enrollment reference data may be stored for multiple users independently of each other. In accordance with many embodiments, any subset of fingers may be used, by the fingerprint sensors 340, to obtain biometric data applied by the secure element 320 to determine a match.

[0089] Additionally or alternatively, other forms of validation may be used, including but not limited to textually / vocally (e.g., as a backup case when enabled by the user). In the latter case, users may be asked to select a certain number n of questions Q1 ,..., Qn, chosen among a list pre-installed and specially generated by Al using various criteria. They provide the answersAn to these questions. The authentication involves the user answering the registered questions by Ai*, i = 1 ,...,n. A match Ai==Ai* may occur when a sufficient amount of “matching information” is obtained (e.g., may accept small‘deformations’ of the answers). When a quorum r of n successful questions are answered, the authentication may be granted, and otherwise it is denied.

[0090] In various embodiments of the invention, SEs 320, including but not limited to smartcards, may describe certified security chips with cryptographic boundaries. In various embodiments of the invention, (e.g., biometric) matching may operate based on on-card matchers, with the secure authentication technology that stores biometric data (e.g., fingerprint templates) being stored directly on smartcards that perform the matching. SEs 320 within devices configured in accordance with some embodiments may store authentication data and help facilitate (i.e. , store the cryptographic keys needed for) encryption for all files. In some embodiments of the invention, after several consecutive denials, the stored information may be made inaccessible (e.g., self-deleted, transferred to another location, secured with additional scrutiny) to avoid the possibility of brute force access. Smartcards keeping track of authentication states may utilize secure channels to facilitate authentication. These secure channels may operate based on secure channel protocols (e.g., SCP03).

[0091] Systems and methods in accordance with many embodiments may preface authentication with a similarly secure biometric (e.g., fingerprint) authentication. Biometric (e.g., fingerprint) modules may be configured such that the sensor itself communicates with a secure MCU also inside the module via SPI (serial peripheral interface). This is not encrypted but since they are both within the same packaged module, people interfering with the device would have to break it apart and it would be obvious if it was tampered with. The secure (fingerprint sensor) MCU may then communicate with a OP-TEE via a secure channel that transits through the M33 core (used as a relay). The M33 is used as a relay to keep all drivers outside the OP-TEE for security reasons. During registration, users will record as many fingerprints as possible (typically, but not necessarily, all 10 for enhanced security) that can be stored inside of smartcard non-volatile memory (limited amount) which is inside that ultra-secure component.

[0092] During authentication, the biometric (e.g., fingerprint) modules securely (e.g., over encrypted channels) may communicate with the OP-TEE which can itself then securely communicate with the smartcard (via the M33 core used as a relay - again for security reasons related to the drivers). The smartcard may then carry a matchcomputation with all the existing fingerprints recorded during the registration phase and then send back the response to the OP-TEE.

[0093] In accordance with many embodiments of the invention, authentication can be carried via secure channels with matching requests. When the matching is successful, smartcards configured in accordance with some embodiments may be configured to generate (authentication) tokens for user session embeddings and / or user IDs (e.g., one possible session at a time). Systems in accordance with various embodiments may utilize trusted execution environments (TEEs) to open user secure channels using that authentication token (passed by user interface controllers). Additionally or alternatively, individual sessions may be returned back to the TEE which allow user interface controllers to perform authenticated calls. In many cases, user authentication processes may be determined during enrollment, at initialization time. During the lifetime of the tablet, users may authenticate themselves using the enrollment reference data, such that a match between fingerprint sensor input and existing stored enrollment reference data may grant the authorization (e.g., maintain an authenticated state) for the duration of a session.

[0094] Authentication may be performed using a multi-layer system in accordance with various embodiments of the invention directed to steps for device authentication and user authentication. Both may be based on a secure channel to the smartcard which holds the authentication state. Most system functions may depend on device and / or user authentication: for instance, some functions may require no authentication at all (information access), some features may require device authentication (e.g., matching, enrolling as a prime user), and various functions may require user authentication (e.g., encryption unlocking, file ciphering / deciphering, permissions editing). Since the (authentication) states are stored in the smartcard, in many cases, critical decisions can be precluded unless the smartcard has set a corresponding authentication flag. In various embodiments, the smartcards may be configured to possess the maximal possible security (e.g., EAL AVA.VAN), ensuring the authentication flags cannot be tampered with.

[0095] Device authentication may be used to establish that a device / processor which contacts the smartcard is specifically the secure device. This may be done via the global platform SCP03, between the TEE and the smartcard built-in global platform layer(e.g., using the secure core as an intermediary). Systems may, in some cases, use External Authenticate commands to create a base secure channel for the authentication.

[0096] User authentication may be used to establish that a user interacting with the device is an authorized user. Devices may allow user authentication through (e.g., biometric) sensor input and / or password mechanisms (i.e. , touchscreen input, answering questions). In some cases, dual authentication may be used to ensure secure access. In accordance with various embodiments of the invention, biometric authentication may be performed using fingerprint matching. When a given matching is positive, systems may transmit unique session token to the main program(s), unlocking the resources, fetching decryption keys, establishing an authentication state, and providing access to a corresponding user (subject to associated / personalized access rights). When the user fails the authentication too many times in a row, systems can be configured to perform a series of potential Runtime Application Self-Protection responses, including but not limited to rebooting the secure device, pausing the secure device for a set duration, locking the secure device, and (in extreme cases) complete zeroization where the system self-erases all its data to prevent any brute force attack. The form of authentication (e.g., the choice and order of the fingers presented) may be decided at the time of initialization by the authentication module and owner.

[0097] A process for applying biometric scanners to perform authentication in accordance with many embodiments of the invention is conceptually illustrated in FIGS.4A - 4C. Underlying secure devices may be configured in accordance with some embodiments of the invention to implement cryptosystems including but not limited to Rivest-Shamir-Adleman (RSA) and / or Elliptic-Curve Cryptography (ECC) based cryptosystems.

[0098] Authentication may be performed based on data transfers between biometric sensor(s) 410 (including but not limited to fingerprint readers) and MCU(s) 420. In several embodiments of the invention, these data transfers may operate over secure channels between the biometric sensor(s) 410 and the MCU(s) 420. Therefore, the process may include (but is not limited to) subprocess steps for initiating the secure channel (as described in FIG. 4A), processing the biometric input (as described in FIG.4B), and terminating the secure channel (as described in FIG. 4C). In many embodimentsof the invention, a TEE (e.g., OP-TEE) configured by the MCU 420 may be utilized in performing the authentication as described above. Additionally or alternatively, publicprivate key pairs associated with the MCU 420 and / or the biometric sensor 410 may be accessed by both parties to the authentication. The public-private key pair(s) may be generated using components including but not limited to public key infrastructure and / or root of trust. In various embodiments of the invention, device certificates corresponding to the public-private key pairs may be pinned and / or preloaded to the biometric sensor(s) 410 and / or the MCU(s) 420 as of initialization / secure provisioning (thereby circumventing a requirement for runtime certificate exchange and / or online validation).

[0099] FIG. 4A illustrates the initiating of a secure channel in accordance with some embodiments of the invention. In accordance with many embodiments, this subprocess may ensure that both parties have access to the same transient (“session”) key to encrypt and decrypt data for a single secure communication session. The biometric sensor 410 can begin the subprocess by generating a session nonce. In doing so, the session nonce may be generated in a manner that is fresh and / or random (e.g., via random number generator). The biometric sensor 410 can start the handshake for the secure connection with the MCU 420 based on the nonce (e.g., via programmable controller bus). The MCU 420 can generate the (unique) session key for the exchange (e.g., using the session nonce). The MCU 420 can also build a Key Encapsulation Mechanism (KEM) payload, encapsulating the session key using the biometric sensor’s 410 public key information (e.g., via the sensor’s pinned certificate). Using its own private key, the MCU 420 can create a (e.g., digital) signature over the session nonce, the payload, and a transcript hash, transmitting the signature back to the biometric sensor 410. The biometric sensor 410 can then verify the signature (e.g., via the MCU’s pinned certificate) and decapsulates the KEM in order to derive the session key built by the MCU 420. Once the session key has been successfully derived, the biometric sensor 410 sends back a key confirmation, proving possession of the session key. This confirmation may (additionally) include the session nonce and the (updated) transcript hash. After verifying the confirmation, the MCU finalizes the session key. The freshness established ensures that, even when serial communication is compromised, such as a (spy) microdevice onan Inter-Integrated Circuit / l2C, observation of the data (e.g., I2C frames) would only reveal ciphertext and signed control messages, also blocking replay value.

[0100] Once the secure channel has been established, the process facilitates the transfer the biometric data for authentication (illustrated in FIG. 4B). The subprocess disclosed in FIG. 4B may be repeated for each new capture of biometric data (e.g., fingerprint read) by the biometric sensor 410. Further, each message / exchange associated with a new biometric data transfer over the secure channel may involve (but is not limited to) the generation of a unique (message-based) nonce, a timestamp (e.g., corresponding to when the biometric data is captured), and a counter (e.g., quantifying message exchanges between the biometric sensor 410 and the MCU 420. The biometric sensor 410 can encrypt the payload (producing a corresponding ciphertext) using the session key and the unique message nonce. Before transmitting the complete encrypted payload, the biometric sensor 410 can sign / authenticate the header of the message (including the counter, timestamp, message nonce, and / or a session ID for the current session) and / or the payload. After receiving the captured biometric data, the MCU 420 can check to confirm that the session nonce also corresponds to the session ID (i.e. , that the session is consistent). Further, the MCU 420 can use the counter, the timestamp, and / or the message nonce to enforce replay protection for the transfer; and can verify the signature / authentication tag using the session key. The MCU 420 can decrypt and process the biometric data. In several embodiments of the invention, the MCU 420 may specifically utilize the OP-TEE for decryption and / or processing.

[0101] After the data has been transferred in full, the process may terminate the secure channel (illustrated in FIG. 4C). The biometric sensor 410 may, additionally or alternatively, cryptographically attest to the state of the device hardware and / or software after the exchange by transmitting a digitally signed attestation block to the MCU 420. The MCU 420 can send a close request to the biometric sensor 410 in reference to the secure channel. Once the secure channel has been closed, acknowledgment may be sent from the biometric sensor 410 to the MCU 420. Finally, in response to the closed channel, both parties may erase the session key and / or session context (e.g., Session ID), to ensure there are not unnecessary stored references to the exchange.

[0102] While specific processes for biometric authentication are described above, any of a variety of processes can be utilized for cryptosystem management as appropriate to the requirements of specific applications. In certain embodiments, steps may be executed or performed in any order or sequence not limited to the order and sequence shown and described. In a number of embodiments, some of the above steps may be executed or performed substantially simultaneously where appropriate or in parallel to reduce latency and processing times. In some embodiments, one or more of the above steps may be omitted. Although the above embodiments of the invention are described in reference to biometric authentication, the techniques disclosed herein may be used in any type of authentication processes, including question / answer challenges.

[0103] Examples of microcontroller units (MCUs) constructed in accordance with multiple embodiments of the invention are conceptually illustrated in FIGS. 5A - 5B. MCUs configured in accordance with several embodiments may utilize integrated circuits that combine multiple processor cores 520, 540; memory; and programmable input / output (I / O) peripherals to control specific tasks performed by secure devices. In various embodiments of the invention, the processor cores (e.g., ARM processors) may be used to run tablet operating systems (OS). In many cases, the operating system of a given secure device can be based on a (e.g., light-weight) Linux distribution. Additionally or alternatively, in many embodiments of the invention, multiple processor cores may be located on (but are not limited to singular integrated circuits. In accordance with some embodiments of the invention, the processor cores may include but are not limited to a first (relatively) less secure core 520 and a second, (relatively) secure core 540. Additionally or alternatively, the various processor cores may communicate using mechanisms including but not limited to a layered system of inter-core inter-process communication (IPC), allowing exchanges of data and coordination of activities.

[0104] The less secure core(s) 520 may, in many cases, be designed for optimizing display functionality over security (e.g., Cortex A-35 processors). As such, in some embodiments, the less secure core 520 may primarily guide implementation of operations including but not limited to user interface operations. In some cases, this processor may be considered the “main processor,” as even the less secure core(s) 520 may possess a level of security, through performing various critical operations within secure / trustedexecution environments. Using hardware security extension technology (e.g., TrustZone), the less secure core 520 may nevertheless be used to hardware-activate logical zones including (but not limited to) a secure zone 510 (e.g., Trusted Execution Environment / TEE) and an insecure zone 515. In various embodiments, these zones may be communicatively linked using an API (e.g., to facilitate IPC). Security devices may judiciously use the separation between secure zone 510 and insecure zone 515 to separate critical software (e.g., cryptography) and non-critical software (Ul). However, in some cases, cryptography may be performed using the secure zone 510 and / or the insecure zone 515. As suggested above, secure zones 510 may be better protected than insecure zones 515, with the latter connected to the outside world, and therefore carrying more potential attack surfaces. In various cases, traditional Linux OS may exclusively run in the insecure zone 515, while responsibilities such as storing secrets and / or performing trusted environment computations may be exclusive to the secure zone 510. Additionally or alternatively, hardware of the secure device can be interfaced directly with the secure zone 510 and / or the insecure zone 515. For example, USB flash drives may be accessed directly via Linux, while the filesystem(s) inside may use the Linux LUKS2 driver mechanism. Moreover, the user interface may be prevented from (1) directly accessing certain hardware (e.g., the fingerprint reader, the smartcard reader) and / or (2) handling information that is sent / returned. In particular, they may be encrypted into an end-to-end secure channel between the hardware and the trusted application in the OP-TEE (as described below).

[0105] Additionally or alternatively, the secure zone 510 may be configured to facilitate a Linux-compatible trusted secure world (e.g., an Open Portable Trusted Execution Environment / OP-TEE) while the Linux OS operates directly (and solely) via the insecure zone 515. In some cases, the OP-TEE may initialize first and then transfer control to the normal world / insecure zone 515 OS (e.g., Linux) kernel. Trusted Applications (TAs) may be used in the OP-TEE to handle processes including but not limited to smartcard communication and key retrieval operations. In some cases, the insecure zone 515 may include Linux OS-support components including but not limited to board support packages (BSPs). As such, in many embodiments of the invention typical workflows may include (but are not limited to) using trusted applications, operatingon the secure zone 510 to call the driver(s) of the Linux OS in the insecure zone 515. This may be done using secure channels including but not limited to remote procedure call (RPC) APIs, with the answers to the calls received by the trusted applications. As suggested above, secure devices may (in many cases) exclusively communicate with secure channels. As such, systems may be configured to use secure channels exclusively from the secure zone 510 (with the insecure zone 515 not having have the keys used to deal with the secure channel).

[0106] In accordance with multiple embodiments of the invention, the secure core 540 may, in many cases, be designed for optimizing security (e.g., Cortex M33 processors). Secure cores 540 may host one or more built-in roots of trust, including but not limited to a secure enclave 530. Additionally or alternatively, the secure enclave 530 may be kept separate from either core and / or be accessible by both cores. In many cases, the secure enclave 530 may be non-programmable (designed as a pre-configured, autonomous subsystem providing a service, typically around cryptography and security). Additionally or alternatively, secure enclaves may incorporate, but are not limited to nonvolatile (e.g., read-only) and volatile memory. Additionally or alternatively, the secure enclave may use a co-processor, such as cryptographic accelerator and signaling processing engines (e.g., NXP CASPER crypto-engines). The secure enclave could also be a peripheral secure element like a Java smartcard or other secure elements that can perform similar functions. The secure enclave 530 may be used to help facilitate security services including but not limited to the secure provisioning, services of attestation, secure boots, and cryptographic primitives.

[0107] A process of secure provisioning, performed in accordance with several embodiments of the invention, is conceptually illustrated in FIG. 6. Processes performed in accordance with various embodiments of the invention may include but are not limited to certificate management, key distribution, secure boot mechanisms, trusted execution environments, and continuous monitoring to prevent unauthorized access, tampering, or compromise during the provisioning phase. In doing so, systems may secure communication channels, authenticating all parties involved, encrypting sensitive data during transmission and storage, implementing proper access controls and permissions, and ensuring that authorized configurations and software are deployed to target systems.

[0108] As suggested above, to facilitate system security, certificates and private / public keys may be preloaded and pinned on various (in many cases, all) components of the secure device to enable secure communication between them. This may prevent any spy software from deciphering the messages going back and forth. This first step is crucial and must be done in a secure facility. Secure provisioning may include a step wherein the tablet boots up from a secure boot (i.e., verifying hardware integrity and authenticating firmware / OS at startup using cryptographic signatures, ensuring only trusted code runs). Systems may load OSes into RAM from appointed partitions of the (e.g., ROM) memory. In many cases, OS-directed partitions may be read-only (i.e., not writable) so that it is immutable and unmodifiable. Additionally or alternatively, the OS partitions may be encrypted (e.g., via LUKS2).

[0109] In accordance with multiple embodiments of the invention, secure boot processes may be described as multi-layered security architectures that establish chains of trust from hardware to fully-operational encrypted OSs (e.g., Linux). In many cases, secure boot processes may utilize a chain of trust between each stage of the boot. This means that it is not possible for an adversary to make the tablet boot from something else (for example an USB disk) as the signatures would be checked at each stage. Systems in accordance with various embodiments of the invention may utilize Advanced High Assurance Boot (AHAB) processes executed by processor (e.g., secure core 440) on-chip Boot read-only memory.

[0110] In doing so, systems may establish at least one hardware root of trust through asymmetric cryptographic keys including but not limited to Super Root Key (SRK) and OS Signing Key pairs. A Super Root Key (SRK) pair may serve as the primary key for the hardware root of trust, where the private SRK may be used exclusively to sign Command Sequence Files (CSFs) that validate a universal bootloader (e.g., U-Boot). In some embodiments, a (e.g., SHA-256 cryptographic) hash of the public SRK may be permanently stored on-chip (e.g., via electronic fuse) to prevent key poisoning attacks, thereby enabling AHAB and establishing the immutable hardware root of trust. This (provisioning) process may ensure that each device maintains its security properties while allowing interoperability within the secure device ecosystem through a shared master key derivation scheme. An OS Signing Key pair may serve as a secondary key pair used tosign all other boot-stage software components. During U-Boot compilation, the public OS Signing Key may be embedded directly into the U-Boot binary via device tree source file. This may allow U-Boot to verify subsequently loaded components without requiring external key storage. Additionally or alternatively, compiled U-Boot binaries may be signed with the private SRK.

[0111] As suggested above, boot processes configured in accordance with many embodiments of the invention may involve sequential verification stages where each component validates the next in the chain. For example, Boot ROM may verify U-Boot using the SRK, U-Boot may verify a FIT (Flattened Image Tree) image containing the kernel and other components using an embedded OS signing key, and subsequent stages may continue the verification chain.

[0112] The secure core 540 may, additionally or alternatively, host a variety of components directed to system security, as disclosed in FIG. 5B. The secure core’s 540 components may interact with modules, data structures, and / or applications including but not limited to:• disk encryption specification libraries, (e.g., Linux Unified Key Setup 2 / LUKS2) libraries to perform encryption interactions;• biometric modules to provide functions related to biometric authentications, such as interacting with various sensors (e.g., cameras, fingerprint biometric readers), templates, and / or smartcard (e.g., cryptographic) data;• background tablet service applications (e.g., daemons) to perform various operation-based tasks, including starting the application / user interface;• Runtime Application Self-Protection (RASP) modules to perform miscellaneous active / real-time security functions;• Smartcard modules to facilitate communication with smartcards (e.g., via Application Protocol Data Units, Transport Protocol Data Units), provide communication standards (T=0 / T=1, ISO7816-3, ISO7816-4), and interact with smartcard authentication values (e.g., Personal Identification Numbers) using the above;• Public Key Infrastructure (PKI) modules to provide functions for secure communication (including storing PKIs certificates including but not limited to x.509); and• Cryptography modules to concentrate the cryptographic routines needed by the OS (e.g., ciphering, deciphering, signature, signature verification, hashing, random number generation and key management), for operating the tablet, and / or for interacting with cryptographic functions from the smartcard.The operation of these components may be described for more extensively in U.S. Provisional Patent Application No. 63 / 919,247 entitled “Digilock Vault Tablet,” filed November 17, 2025, the disclosures of which, specifically the portions directed to MCU architecture and secure booting, are incorporated by reference in their entireties.

[0113] In accordance with many embodiments, the first user of a secure device may be appointed owner of the system. As such, the first user can allow other users to register their fingerprints, create / access documents, and / or give ownership permission to any other users specifically authenticated to use the system.

[0114] Users (with permissions) can thereby create documents in ways including but not limited to writing on the user interface (e.g., display) using the stylus, typing characters using a virtual keyboard, importing supported file (e.g., PDF, TXT) documents via the USB-C port (i.e., by plugging in a USB flash drive), using the camera and extracting data from a QR code (e.g., static QR code and / or animated QR code - for large files), and / or taking pictures of a document with the camera and collating the pages together. Created documents may be stored in non-volatile memory in the encrypted data partition. This partition may be writable and used to save all documents. Additionally or alternatively, secure devices may provide the option to use post-quantum encryption (when the option is enabled - since it significantly slows down the writing / reading of documents).

[0115] Upon the creation of a document, creators may decide which authenticated sets of people have (certain types of) access rights. Access rights may be determined on a per document basis by the respective creators. The different access rights that exist with respect to a document may include: “Write,” allowing the document to be modified, erased, renamed, and / or altered in any other way (e.g., access rights modified); “Read,”allowing the content of the document to be viewed with the appropriate built-in reader; and “List,” allowing the documents existence to be shown in the file browser (but not allowing its content to be seen). When none of these access rights is available, then even authenticated users may have no idea that the document exists.

[0116] A set of people may be deemed authenticated (with respect to a document) when they individually pass the biometric authentication for the device (e.g., sequentially), granting them access for a given authenticated session only. An authenticated session ceases to exist when the tablet is powered down, or the authenticated user(s) log out. As an example, a user could have “list” access to a document, but require the authentication of an additional user to be able to view the document, and possibly even a third user to modify it (with “write” access). All these permissions / access rights may be stored inside the most secure element of the entire system, the smartcard, which cannot be tampered with in any known ways. The definition of an authenticated set of people for a given access right for a given document (as all access rights are on a per document basis) may, in some embodiments, be defined by a Boolean rule. This Boolean rule can be defined by the document creator and, so that can be as complex as the document owners wants. It is a combination of Boolean operations (AND / OR / NOR / ...) on authenticated users. Example Boolean rules may be selected from the group consisting of: AND operations requiring simultaneous authentication of multiple users, OR operations allowing alternative user authentication paths, and nested Boolean expressions combining multiple logical operations. For instance, assuming users A, B, C, D and E, one could imagine the following reads: “access rule: A OR (B AND C) OR (B AND D AND E)” or “((A AND B) OR (C AND D)) AND E.” As suggested above, system implementations may vary in accordance with many embodiments of the invention.

[0117] A specific hardware implementation variant used for e-paper tablets configured in accordance with numerous embodiments of the invention is illustrated in FIG. 7. Systems may be centered around, but are not limited to a complex processor, a fingerprint module, at least one smartcard, and a set of supplemental devices. In many embodiments of the invention, the complex processor is the NXP i.MX8 ULP, which may include 2 ARM Cortex-A35 cores, an ARM Cortex-M33 core, and an EdgeLock Secure Enclave (ELE). The complex processor may, additionally or alternatively, incorporate(e.g., processing) components including but not limited to a graphics processing unit (GPU) and a digital signal processor (DSP). As suggested above, the M33 core is generally considered more secure than the A35 cores because it has a simpler architecture, reducing attack surfaces. It lacks a memory management unit (MMU), limiting OS complexity, and often runs isolated firmware (e.g., for security functions). The A35 cores, being application processors with MMUs, can handle richer OSes (e.g., Linux), but may (relatively speaking) have increased vulnerability to software exploit. E-paper tablets configured in accordance with various embodiments of the system may, additionally or alternatively, operate a secure execution environment (e.g., OP-TEE) in the i.MX8 ULP processor via at least one of the A35 cores. This can isolate sensitive operations (e.g., cryptographic functions, key management) from the main OS, using the processor's TrustZone technology for hardware-enforced security.

[0118] Systems in accordance with many embodiments may similarly utilize secure enclaves for security operations. An EdgeLock Secure Enclave (ELE) in the i.MX8 ULP may operate as physically isolated security sub-system. In various cases, the ELE may operate with its own (e.g., RISC-V) CPU core. The ELE may be a pre-configured autonomous security subsystem, physically isolated from the system on a chip (SoC) for reasons including but not limited to root of trust, key management and attack resistance. The ELE may be used for operations including but not limited to the secure enclave functions described above; and / or secure boot enforcement, trust provisioning and attestation. In many embodiments, the OP-TEE accesses ELE APIs via Message Unit (MU) driver for inter-processor communication.

[0119] Systems may, additionally or alternatively, incorporate various data transmission / storage components. For instance, e-paper tablets may utilize, but are not limited to non-volatile (e.g., SLC NAND Flash) and volatile (e.g., LPDDR4 RAM) memory. In particular, the former may be especially effective for better retention and longevity. In several embodiments, two (or more) USB ports may be utilized (e.g., as the sole data transmission and / or power interfaces). For example, one USB port may be used to supply the power to the board, while a second port may be connected to a flash drive to import specific documents. The flash drive port may, additionally or alternatively, be used to the encrypted data partitions of non-volatile memory to a USB flash drive.

[0120] This process can later be used for restoration of the documents to a new tablet using the system smartcard(s). In particular, (in addition or alternative to the smartcard functionality described above - e.g., authentication), e-tablets may use an (optional) secondary smartcard to back up authentication keys. When an optional smartcard is loaded on a new tablet with the proper keys, systems in accordance with some embodiments may use the encrypted data partition described above for restoration of the documents to the new tablet.

[0121] As every piece of hardware eventually fails, an easy way to handle backups is crucial, especially given risk of adverse events that would destroy the tablet (e.g., fires) and / or make it disappear (e.g., lost, stolen). Systems in accordance with many embodiments of the invention may configure system backups to be as secure as the tablet itself. These backups can thus be stored in friendly or adversarial locations alike since it would be impossible for an attacker to use to decrypt the documents using brute-force. In accordance with many embodiments of the invention, system backups may be made of two elements: the encrypted data partition that can be saved on a flash drive via the USB-C port and a copy of the smartcard (e.g., a backup SIM). The backup of the encrypted data partition containing all the documents is trivial. The duplication of the smartcard must be done using the secure channel of communication between the OP-TEE and the first smartcard that must be copied, extracting the relevant information from it and storing it on the second smartcard using another secure channel of communication.

[0122] When both the (backup) smartcard and the encrypted flash drive are inserted in a new tablet hardware (of the same classification / brand), the flash drive and smartcard may then be identified. The user may be prompted for a restoration operation and / or proper authentication. The new tablet hardware may be configured to copy the encrypted flash drive onto the data partition of the new tablet, extract the relevant secrets from the backup smartcard, and copy the secrets to the new tablet (main) smartcard (e.g., using SCP03 secure channel via the OP-TEE) after a smartcard-to-smartcard authentication has taken place. This procedure may require the implementation of a specific setup, during which the new tablet is provided with an additional partition allowing it to perform the operation (equivalent to recovery OS partition in PCs). The smartcards (i.e. , the backup smartcard from the first device and the main smartcard of the new device)may authenticate each other via PKI. Once authenticated, the backup smartcard can transfer all authentication and cryptographic data (including the biometric fingerprints) to the main smartcard card. Additionally or alternatively, a backup flash may then be transferred to non-volatile storage, and the cryptographic (e.g., LLIKS2) keys may be deciphered by the new smartcard.

[0123] As mentioned above, various supplemental devices may be included in accordance with some embodiments. For example, the user interface may operate using panels including but not limited to a Capacitive Touch Panel (CTP) and an Electro-Magnetic Resonance (EMR) panel. A CTP, sensitive to multi-finger touches, may be used to interact with the user interface. An (e.g., WACOM) EMR may be used to digitize the position of the stylus. Further, the e-Paper display (EPD) may operate as the main user interface to display documents and create documents with stylus and / or virtual keyboard.

[0124] In accordance with many embodiments, the first user of a secure device may be appointed owner of the system. As such, the first user can allow other users to register their fingerprints, create / access documents, and / or give ownership permission to any of those users.

[0125] In accordance with many embodiments of the invention, sensor modules including but not limited to camera modules and / or fingerprint modules may be incorporated into e-paper tablets. The camera module may be used for digitizing important documents and / or creating documents from QR codes. The fingerprint module may be a hardware entity manufactured as one component that contains, but is not limited to the fingerprint sensor (i.e. , fingerprint capacitive sensor hardware) and a high-security MCU with 3rd party certifications. The fingerprint sensor may communicate with the corresponding MCU inside the module via SPI (serial peripheral interface).

[0126] In many embodiments of the invention, secure devices may have specific protocols to address issues of invasion / unauthorized access.

[0127] Secure devices in accordance with many embodiments of the invention may prevent USB attacks by ensuring that only genuine flash USB drives can be inserted, with gadgets being denied authorization on the USB bus. The secure devices can tightly control USB ports and prevent any USB device driver which is not a flash drive from being loaded, blocking all known USB attack vectors.

[0128] The secure devices may implement anti-spyware measures including antikeylogger protection by using only virtual 'on-screen' keyboards instead of physical keyboards, preventing unauthorized (non-signed) applications from running on the secure devices, and preventing non-signed drivers from operating on the secure devices.

[0129] The secure devices configured in accordance with several embodiments may prevent supply chain attacks where components are replaced by counterfeited copies containing malwares and / or spy firmware, where additional alien components are inserted for MITM attacks, through end-to-end bus / signal encryption, systematic utilization of attestation to detect alien components, and bus scans to detect alien components.

[0130] In case of physical coercion, the secure devices may implement a hidden self-destruct sequence known only to the secure device users, where optionally a passphrase is asked at boot and if anything is inserted three times consecutively, the secure devices self-destructs, simulating a kernel panic with no error message. Additionally or alternatively, a hidden filesystem and dummy filesystem can co-exist, with the dummy file system activated when the thumb is not scanned during fingerprint authentication.

[0131] In various cases, anti-Side-Channel Attacks (SCA) in the MCU may be based on actual sensors present in the target MCU including stash modification and temperature monitoring, with software-based randomization of energy consumption (antidifferential power analysis) used as basic protection against differential power attacks. Random delay registers are used in the KMU to prevent several types of power consumption SCA. The smartcard must be security evaluated (e.g., via EAL4+, via high AVA.VAN profile) and be payment (e.g., EMV) compliant, making SCA attacks ineffective against such smartcards.

[0132] The secure devices may be equipped with tamper-evident protection such as seals, with the serial number engraved on the secure devices and a seal bearing the same serial number attached to detect unauthorized physical access.

[0133] Additional biometric authentication can be obtained using silent, background, "behavioral" biometrics based on the frequency and style of keystroke on the on-screen keyboard to detect unauthorized users through behavioral analysis.Exemplary Embodiments

[0134] Systems and devices for implementing secure digital vault devices with biometric authentication and encrypted storage in accordance with various embodiments of the invention are illustrated. A first embodiment comprises a secure digital vault device including at least one biometric sensor, wherein when a biometric enrollment data, belonging to at least one prospective user, is input into the at least one biometric sensor, the at least one prospective user is authorized as at least one authorized user and the biometric enrollment data is securely transmitted to at least one secure tamper-resistant processing device, configured to store the biometric enrollment data as authentication data for the at least one authorized user, and when one of the at least one authorized user inputs biometric data, matching at least some of the authentication data, into the at least one biometric sensor, a particular set of access permissions enables access to at least one encrypted document during a user session duration, at least one secure element, comprising a secure tamper-resistant processing device, wherein the secure tamper-resistant processing device stores a secure dataset comprising the authentication data for the at least one authorized user, encryption data for each of the at least one encrypted document, and a plurality of parameters for the secure digital vault device, and at least one memory, configured to store the at least one encrypted document, wherein a first user of the at least one authorized user is associated with a first set of access permissions, corresponding to the at least one encrypted document.

[0135] A second embodiment including the features of the first embodiment, wherein the at least one authorized user comprises a plurality of authorized users and a particular document of the at least one encrypted document is accessed using a Boolean combination of at least some of the plurality of authorized users.

[0136] A third embodiment including the features of the second embodiment, wherein when the first user of the plurality of authorized users is authenticated using the at least one biometric sensor, a given document of the at least one encrypted document is only accessible when a second user of the plurality of authorized users is also authenticated using the at least one biometric sensor during the user session duration.

[0137] A fourth embodiment including the features of the second embodiment, wherein accessing the particular document requires sequential biometric authentication of each user specified in the Boolean combination during the user session duration and verification by the secure tamper-resistant processing device that all required users in the Boolean combination have been successfully authenticated before granting document access to the particular document.

[0138] A fifth embodiment including the features of the fourth embodiment, wherein the secure tamper-resistant processing device maintains an authentication state for each of the plurality of authorized users and only permits the document access when the authentication state satisfies requirements corresponding to the Boolean combination for the particular document.

[0139] A sixth embodiment including the features of any of the first to fifth embodiments, wherein the secure tamper-resistant processing device facilitates user authentication for the secure digital vault device through a secure channel.

[0140] A seventh embodiment including the features of any of the first to sixth embodiments further comprises a complex processor comprising a plurality of processor cores, wherein the complex processor runs at least one operating system for the secure digital vault device.

[0141] An eighth embodiment including the features of the seventh embodiment, wherein the plurality of processor cores comprises a secure core that is directed to implementing a set of device security operations and a less secure core that is directed to a set of user-facing operations, and the secure core communicates with the less secure core using inter-process communication.

[0142] A ninth embodiment including the features of the eighth embodiment, wherein the complex processor comprises a microcontroller unit (MCU).

[0143] A tenth embodiment including the features of the ninth embodiment, wherein the less secure core activates a plurality of logical zones, to perform the set of user-facing operations, the plurality of logical zones comprising a secure zone configured to perform a cryptography-based subset of the plurality of logical zones and an insecure zone configured to perform a user-interface-based subset of the plurality of logical zones.

[0144] An eleventh embodiment including the features of the tenth embodiment, wherein the secure zone comprises a trusted execution environment (TEE).

[0145] A twelfth embodiment including the features of the tenth or eleventh embodiments, wherein a Linux operating system operates exclusively in the insecure zone.

[0146] A thirteenth embodiment including the features of any of the tenth to twelfth embodiments, wherein the secure core hosts a security enclave.

[0147] A fourteenth embodiment including the features of any of the seventh to thirteenth embodiments, wherein the complex processor is configured to securely encrypt at least one new document into the at least one encrypted document based upon the authentication data of the at least one authorized user and store the at least one encrypted document in the memory.

[0148] A fifteenth embodiment including the features of any of the first to fourteenth embodiments, wherein the at least one biometric sensor comprises at least one of a fingerprint sensor or a camera.

[0149] A sixteenth embodiment including the features of any of the first to fifteenth embodiments, wherein the at least one memory comprises volatile memory configured to store the at least one encrypted document that are accessible by the at least one authorized user and non-volatile memory configured to store a plurality of confidential document backups.

[0150] A seventeenth embodiment including the features of the sixteenth embodiment, wherein the volatile memory is further configured to store checksums for each of the at least one encrypted document.

[0151] An eighteenth embodiment including the features of any of the first to seventeenth embodiments, wherein the secure digital vault device is exclusively operable offline.

[0152] A nineteenth embodiment including the features of any of the first to eighteenth embodiments, wherein the plurality of parameters comprises at least one selected from the group consisting of a password, the first set of access permissions, a set of cryptographic keys, and an authentication state for the secure digital vault device.

[0153] A twentieth embodiment including the features of any of the first to nineteenth embodiments further comprises a backup secure tamper-resistant processing device comprising a copy of the secure dataset from the secure tamper-resistant processing device of the secure digital vault device.

[0154] A twenty-first embodiment including the features of the twentieth embodiment, wherein the backup secure tamper-resistant processing device is configured so that when the backup secure tamper-resistant processing device is input into a secondary device, the secondary device is capable of accessing the secure dataset and decrypting the at least one encrypted document.

[0155] A twenty-second embodiment including the features of the twenty-first embodiment further comprises at least one hardware-based data transmission interface, wherein an interaction between an encrypted flash drive and the at least one hardwarebased data transmission interface of the secure digital vault device enables an encrypted backup of the at least one encrypted document stored in the at least one memory to the encrypted flash drive.

[0156] A twenty-third embodiment including the features of any of the twenty-second embodiment, wherein at least one of the backup secure tamper-resistant processing device and the encrypted flash drive is configured to transfer data to the secondary device to the secure digital vault device.

[0157] A twenty-fourth embodiment including the features of any of the twenty-second to twenty-third embodiments, wherein the backup secure tamper-resistant processing device and the encrypted flash drive in tandem enable restoration of the at least one encrypted document and the plurality of parameters to the secondary device by authenticating the backup secure tamper-resistant processing device with a second secure tamper-resistant processing device of the secondary device using public key infrastructure and transferring the authentication data, the encryption data, and the plurality of parameters from the backup secure tamper-resistant processing device to the secure tamper-resistant processing device of the secondary device via a secure channel protocol.

[0158] A twenty-fifth embodiment including the features of any of the first to twentyfourth embodiments further comprises at least one hardware-based data transmissioninterface, wherein for the secure digital vault device, the at least one hardware-based data transmission interface provides an exclusive source for both power input to the secure digital vault device and file transfers to and from the secure digital vault device.

[0159] A twenty-sixth embodiment including the features of the twenty-fifth embodiment, wherein each of the at least one hardware-based data transmission interface is a USB-C port.

[0160] A twenty-seventh embodiment including the features of the twenty-fifth or twenty-sixth embodiments, wherein the secure digital vault device comprises network threat detection functionality that monitors the at least one hardware-based data transmission interface to detect unauthorized network connectivity attempts and triggers a security response when a disallowed connection type is detected.

[0161] A twenty-eighth embodiment including the features of the twenty-seventh embodiment, wherein the security response comprises at least one selected from the group consisting of device lockdown, data zeroization, session termination, and alert generation.

[0162] A twenty-ninth embodiment including the features of any of the first to twenty-eighth embodiments further comprises a touchscreen display, wherein the first set of access permissions enables the first user of the at least one authorized user to modify and annotate the at least one encrypted document.

[0163] A thirtieth embodiment including the features of the twenty-ninth embodiment, wherein the secure digital vault device is an e-paper touchscreen tablet.

[0164] A thirty-first embodiment including the features of any of the first to thirtieth embodiments, wherein storing the biometric enrollment data as the authentication data is performed using a biometric enrollment process comprising establishing a secure channel between the at least one biometric sensor and the secure tamper-resistant processing device using pre-provisioned cryptographic keys stored in both the at least one biometric sensor and the secure tamper-resistant processing device, capturing the biometric enrollment data from the at least one prospective user via the at least one biometric sensor, encrypting the biometric enrollment data using a session key derived from the pre-provisioned cryptographic keys, and storing the biometric enrollment data as part of the authentication data in the secure tamper-resistant processing device, wherein the pre-provisioned cryptographic keys are embedded during a secure provisioning process that occurs prior to device deployment.

[0165] A thirty-second embodiment including the features of the thirty-first embodiment, wherein establishing the secure channel comprises performing a mutual authentication between the at least one biometric sensor and the secure tamper-resistant processing device using the pre-provisioned cryptographic keys, generating ephemeral session keys for the biometric enrollment process, and verifying cryptographic certificates pinned to both the at least one biometric sensor and the secure tamper-resistant processing device during the secure provisioning process.

[0166] A thirty-third embodiment including the features of the thirty-first or thirty-second embodiments, wherein the secure provisioning process comprises loading root certificates and private / public key pairs into the at least one biometric sensor and the secure tamper-resistant processing device in a secure facility, establishing a hardware root of trust using cryptographic keys permanently stored in the secure digital vault device, and configuring secure boot processes that verify system component integrity using the pre-provisioned cryptographic keys before allowing biometric enrollment operations.

[0167] A thirty-fourth embodiment including the features of any of the first to thirty-first embodiments, wherein the secure tamper-resistant processing device is a smartcard.

[0168] A thirty-fifth embodiment comprises a secure digital vault backup and restoration system including a first secure digital vault device comprising a first smartcard and a first encrypted data partition stored in non-volatile memory, a second secure digital vault device capable of securely recovering encrypted data backed up by the first secure digital vault device, the second secure digital vault device comprising a second smartcard, a backup smartcard configured to store authentication and cryptographic data extracted from the first smartcard via a secure channel of communication, and an encrypted flash drive configured to store a copy of the first encrypted data partition from the first secure digital vault device, wherein the second secure digital vault device is configured so that when both the backup smartcard and the encrypted flash drive are inserted into the second secure digital vault device, the backup smartcard transfers a set of authentication and cryptographic data to the second smartcard using a secure channel protocol.

[0169] A thirty-sixth embodiment including the features of the thirty-fifth embodiment, wherein the set of authentication and cryptographic data comprises biometric data corresponding to at least one user of the first secure digital vault device.

[0170] A thirty-seventh embodiment including the features of the thirty-fifth or thirtysixth embodiments, wherein when both the backup smartcard and the encrypted flash drive are inserted into the second secure digital vault device, the second secure digital vault device copies a subset of data from the encrypted flash drive onto a data partition of the second secure digital vault device.

[0171] A thirty-eighth embodiment including the features of any of the thirty-fifth to thirty-seventh embodiments, wherein when both the backup smartcard and the encrypted flash drive are inserted into the second secure digital vault device, the backup smartcard and the second smartcard authenticate each other via public key infrastructure (PKI).

[0172] A thirty-ninth embodiment including the features of any of the thirty-fifth to thirty-eighth embodiments, wherein the secure channel protocol is performed using a trusted execution environment (TEE).

[0173] A fortieth embodiment including the features of any of the thirty-fifth to thirtyninth embodiments, wherein transferring the set of authentication and cryptographic data to the second smartcard enables the second secure digital vault device to access a set of documents restored from the first secure digital vault device, using the same authentication credentials as for the first secure digital vault device.

[0174] A forty-first embodiment including the features of any of the thirty-fifth to fortieth embodiments, wherein the set of authentication and cryptographic data comprises first secure digital vault device information selected from the group consisting of biometric fingerprint templates, cryptographic keys, user permissions, and authentication states.

[0175] A forty-second embodiment including the features of any of the thirty-fifth to forty-first embodiments, wherein the encrypted flash drive stores the first encrypted data partition in LUKS2 format, and cryptographic keys for decrypting the LLIKS2 format are transferred from the backup smartcard to the second smartcard.

[0176] A forty-third embodiment including the features of any of the thirty-fifth to forty-second embodiments, wherein at least one of the first secure digital vault device orthe second secure digital vault device is a touchscreen device comprising a biometric sensor.

[0177] A forty-fourth embodiment including the features of any of the thirty-fifth to forty-third embodiments, wherein the backup smartcard is stored on the first secure digital vault device.

[0178] A forty-fifth embodiment comprises a method for performing biometric authentication in a secure digital vault device, comprising initiating, using a biometric sensor, a secure channel between a microcontroller unit (MCU) and the biometric sensor, wherein initiating the secure channel comprises generating a session nonce and transmitting the session nonce from the biometric sensor to the MCU, generating, using the MCU, a session key, uniquely corresponding to the secure channel, using the session nonce and a Key Encapsulation Mechanism (KEM) payload that encapsulates the session key, producing, using the MCU, a digital signature over the session nonce, the KEM payload, and a transcript hash using a private key of the MCU, transmitting the digital signature to the biometric sensor using the MCU, verifying, by the biometric sensor, the digital signature using a cryptographic key certificate of the MCU, decapsulating the KEM payload with the biometric sensor to derive the session key, and authenticating, using the session key and the MCU, a set of biometric data in a session corresponding to the secure channel.

[0179] A forty-sixth embodiment including the features of the forty-fifth embodiment, wherein authenticating the set of biometric data comprises capturing the set of biometric data using the biometric sensor, encrypting the set of biometric data using the session key and a unique message nonce to produce a ciphertext, authenticating, using the biometric sensor, a message dataset comprising the ciphertext and a message header, wherein the message header comprises the unique message nonce, transmitting the message dataset to the MCU, and decrypting, with the MCU, the set of biometric data using the session key.

[0180] A forty-seventh embodiment including the features of the forty-sixth embodiment, wherein the message header further comprises a timestamp corresponding to when the set of biometric data is captured and a counter quantifying messages between the MCU and the biometric sensor.

[0181] A forty-eighth embodiment including the features of the forty-seventh embodiment, wherein decrypting the set of biometric data further comprises verifying the set of biometric data and checking replay protection, using the counter, the timestamp, and the unique message nonce, for transmitting the message dataset to the MCU.

[0182] A forty-ninth embodiment including the features of the forty-seventh or fortyeighth embodiments, wherein the message header further comprises a session ID corresponding to the session key, and capturing the set of biometric data comprises confirming, using the MCU, that the session nonce corresponds to the session ID.

[0183] A fiftieth embodiment including the features of any of the forty-fifth to fortyninth embodiments further comprises processing, by the MCU, the set of biometric data within a trusted execution environment to perform biometric matching.

[0184] A fifty-first embodiment including the features of the fiftieth embodiment further comprises terminating the secure channel by erasing the session key and session context from both the biometric sensor and the MCU.

[0185] A fifty-second embodiment including the features of any of the forty-fifth to fifty-first embodiments, wherein terminating the secure channel comprises cryptographically attesting, using the biometric sensor, to a hardware state by transmitting a digitally signed attestation block to the MCU.

[0186] A fifty-third embodiment including the features of any of the forty-fifth to fifty-second embodiments, wherein the biometric sensor comprises a fingerprint reader.

[0187] A fifty-fourth embodiment including the features of any of the forty-fifth to fifty-third embodiments, wherein the MCU communicates with the biometric sensor using a trusted execution environment.

[0188] Although specific secure device configurations are discussed above, many different methods of facilitating document confidentiality can be implemented in accordance with many different embodiments of the invention. It is therefore to be understood that the present invention may be practiced in ways other than specifically described, without departing from the scope and spirit of the present invention. Thus, embodiments of the present invention should be considered in all respects as illustrative and not restrictive. Accordingly, the scope of the invention should be determined not by the embodiments illustrated, but by the appended claims and their equivalents.

Claims

WHAT IS CLAIMED IS:

1. A secure digital vault device, comprising:at least one biometric sensor, wherein:when a biometric enrollment data, belonging to at least one prospective user, is input into the at least one biometric sensor:the at least one prospective user is authorized as at least one authorized user; andthe biometric enrollment data is securely transmitted to at least one secure tamper-resistant processing device, configured to store the biometric enrollment data as authentication data for the at least one authorized user; andwhen one of the at least one authorized user inputs biometric data, matching at least some of the authentication data, into the at least one biometric sensor, a particular set of access permissions enables access to at least one encrypted document during a user session duration;at least one secure element, comprising a secure tamper-resistant processing device, wherein the secure tamper-resistant processing device stores a secure dataset comprising:the authentication data for the at least one authorized user; encryption data for each of the at least one encrypted document; and a plurality of parameters for the secure digital vault device;andat least one memory, configured to store the at least one encrypted document, wherein a first user of the at least one authorized user is associated with a first set of access permissions, corresponding to the at least one encrypted document.

2. The secure digital vault device of claim 1 , wherein:the at least one authorized user comprises a plurality of authorized users; and a particular document of the at least one encrypted document is accessed using a Boolean combination of at least some of the plurality of authorized users.

3. The secure digital vault device of claim 2, wherein, when the first user of the plurality of authorized users is authenticated using the at least one biometric sensor, a given document of the at least one encrypted document is only accessible when a second user of the plurality of authorized users is also authenticated using the at least one biometric sensor during the user session duration.

4. The secure digital vault device of claim 2, wherein accessing the particular document requires:sequential biometric authentication of each user specified in the Boolean combination during the user session duration; andverification by the secure tamper-resistant processing device that all required users in the Boolean combination have been successfully authenticated before granting document access to the particular document.

5. The secure digital vault device of claim 4, wherein the secure tamper-resistant processing device maintains an authentication state for each of the plurality of authorized users and only permits the document access when the authentication state satisfies requirements corresponding to the Boolean combination for the particular document.

6. The secure digital vault device of any of claims 1-5, the secure tamper-resistant processing device facilitates user authentication for the secure digital vault device through a secure channel.

7. The secure digital vault device of any of claims 1-6, further comprising a complex processor comprising a plurality of processor cores, wherein the complex processor runs at least one operating system for the secure digital vault device.

8. The secure digital vault device of claim 7, wherein:the plurality of processor cores comprises:a secure core that is directed to implementing a set of device security operations; anda less secure core that is directed to a set of user-facing operations; and the secure core communicates with the less secure core using inter-process communication.

9. The secure digital vault device of claim 8, wherein the complex processor comprises a microcontroller unit (MCU).

10. The secure digital vault device of claim 9, wherein the less secure core activates a plurality of logical zones, to perform the set of user-facing operations, the plurality of logical zones comprising:a secure zone configured to perform a cryptography-based subset of the plurality of logical zones; andan insecure zone configured to perform a user-interface-based subset of the plurality of logical zones.

11. The secure digital vault device of claim 10, wherein the secure zone comprises a trusted execution environment (TEE).

12. The secure digital vault device of claim 10 or claim 11 , wherein a Linux operating system operates exclusively in the insecure zone.

13. The secure digital vault device of any of claims 10-12, wherein the secure core hosts a security enclave.

14. The secure digital vault device of any of claims 7-13, wherein the complex processor is configured to:securely encrypt at least one new document into the at least one encrypted document based upon the authentication data of the at least one authorized user; and store the at least one encrypted document in the memory.

15. The secure digital vault device of any of claims 1-14, wherein the at least one biometric sensor comprises at least one of a fingerprint sensor or a camera.

16. The secure digital vault device of any of claims 1-15, wherein the at least one memory comprises:volatile memory configured to store the at least one encrypted document that are accessible by the at least one authorized user; andnon-volatile memory configured to store a plurality of confidential document backups.

17. The secure digital vault device of claim 16, wherein the volatile memory is further configured to store checksums for each of the at least one encrypted document.

18. The secure digital vault device of any of claims 1-17, wherein the secure digital vault device is exclusively operable offline.

19. The secure digital vault device of any of claims 1-18, wherein the plurality of parameters comprises at least one selected from the group consisting of: a password; the first set of access permissions; a set of cryptographic keys; and an authentication state for the secure digital vault device.

20. The secure digital vault device of any of claims 1 -19, further comprising a backup secure tamper-resistant processing device comprising a copy of the secure dataset from the secure tamper-resistant processing device of the secure digital vault device.

21. The secure digital vault device of claim 20, wherein the backup secure tamperresistant processing device is configured so that, when the backup secure tamperresistant processing device is input into a secondary device, the secondary device is capable of accessing the secure dataset and decrypting the at least one encrypted document.

22. The secure digital vault device of claim 21, further comprising at least one hardware-based data transmission interface, wherein an interaction between an encrypted flash drive and the at least one hardware-based data transmission interface of the secure digital vault device enables an encrypted backup of the at least one encrypted document stored in the at least one memory to the encrypted flash drive.

23. The secure digital vault device of claim 22, wherein at least one of the backup secure tamper-resistant processing device and the encrypted flash drive is configured to transfer data to the secondary device to the secure digital vault device.

24. The secure digital vault device of any of claims 22-23, wherein the backup secure tamper-resistant processing device and the encrypted flash drive in tandem enable restoration of the at least one encrypted document and the plurality of parameters to the secondary device by:authenticating the backup secure tamper-resistant processing device with a second secure tamper-resistant processing device of the secondary device using public key infrastructure; andtransferring the authentication data, the encryption data, and the plurality of parameters from the backup secure tamper-resistant processing device to the secure tamper-resistant processing device of the secondary device via a secure channel protocol.

25. The secure digital vault device of any of claims 1-24, further comprising at least one hardware-based data transmission interface, wherein, for the secure digital vault device, the at least one hardware-based data transmission interface provides an exclusive source for both:power input to the secure digital vault device; andfile transfers to and from the secure digital vault device.

26. The secure digital vault device of claim 25, wherein each of the at least one hardware-based data transmission interface is a USB-C port.

27. The secure digital vault device of claim 25 or claim 26, wherein the secure digital vault device comprises network threat detection functionality that monitors the at least one hardware-based data transmission interface to detect unauthorized network connectivity attempts and triggers a security response when a disallowed connection type is detected.

28. The secure digital vault device of claim 27, wherein the security response comprises at least one selected from the group consisting of: device lockdown, data zeroization, session termination, and alert generation.

29. The secure digital vault device of any of claims 1-28, further comprising a touchscreen display, wherein the first set of access permissions enables the first user of the at least one authorized user to modify and annotate the at least one encrypted document.

30. The secure digital vault device of claim 29, wherein the secure digital vault device is an e-paper touchscreen tablet.

31. The secure digital vault device of any of claims 1-30, wherein storing the biometric enrollment data as the authentication data is performed using a biometric enrollment process comprising:establishing a secure channel between the at least one biometric sensor and the secure tamper-resistant processing device using pre-provisioned cryptographic keys stored in both the at least one biometric sensor and the secure tamper-resistant processing device;capturing the biometric enrollment data from the at least one prospective user via the at least one biometric sensor;encrypting the biometric enrollment data using a session key derived from the preprovisioned cryptographic keys; andstoring the biometric enrollment data as part of the authentication data in the secure tamper-resistant processing device, wherein the pre-provisioned cryptographic keys are embedded during a secure provisioning process that occurs prior to device deployment.

32. The secure digital vault device of claim 31, wherein establishing the secure channel comprises:performing a mutual authentication between the at least one biometric sensor and the secure tamper-resistant processing device using the pre-provisioned cryptographic keys;generating ephemeral session keys for the biometric enrollment process; and verifying cryptographic certificates pinned to both the at least one biometric sensor and the secure tamper-resistant processing device during the secure provisioning process.

33. The secure digital vault device of claim 31 or claim 32, wherein the secure provisioning process comprises:loading root certificates and private / public key pairs into the at least one biometric sensor and the secure tamper-resistant processing device in a secure facility;establishing a hardware root of trust using cryptographic keys permanently stored in the secure digital vault device; andconfiguring secure boot processes that verify system component integrity using the pre-provisioned cryptographic keys before allowing biometric enrollment operations.

34. The secure digital vault device of any of claims 1-31 , wherein the secure tamper-resistant processing device is a smartcard.

35. A secure digital vault backup and restoration system, comprising:a first secure digital vault device comprising a first smartcard and a first encrypted data partition stored in non-volatile memory;a second secure digital vault device capable of securely recovering encrypted data backed up by the first secure digital vault device, the second secure digital vault device comprising a second smartcard;a backup smartcard configured to store authentication and cryptographic data extracted from the first smartcard via a secure channel of communication; andan encrypted flash drive configured to store a copy of the first encrypted data partition from the first secure digital vault device;wherein the second secure digital vault device is configured so that, when both the backup smartcard and the encrypted flash drive are inserted into the second secure digital vault device, the backup smartcard transfers a set of authentication and cryptographic data to the second smartcard using a secure channel protocol.

36. The secure digital vault backup and restoration system of claim 35, wherein the set of authentication and cryptographic data comprises biometric data corresponding to at least one user of the first secure digital vault device.

37. The secure digital vault backup and restoration system of claim 35 or 36, wherein, when both the backup smartcard and the encrypted flash drive are inserted into the second secure digital vault device, the second secure digital vault device copies a subset of data from the encrypted flash drive onto a data partition of the second secure digital vault device.

38. The secure digital vault backup and restoration system of any of claims 35-37, wherein, when both the backup smartcard and the encrypted flash drive are inserted into the second secure digital vault device, the backup smartcard and the second smartcard authenticate each other via public key infrastructure (PKI).

39. The secure digital vault backup and restoration system of any of claims 35-38, wherein the secure channel protocol is performed using a trusted execution environment (TEE).

40. The secure digital vault backup and restoration system of any of claims 35-39, wherein transferring the set of authentication and cryptographic data to the second smartcard enables the second secure digital vault device to access a set of documents restored from the first secure digital vault device, using the same authentication credentials as for the first secure digital vault device.

41. The secure digital vault backup and restoration system of any of claims 35-40, wherein the set of authentication and cryptographic data comprises first secure digital vault device information selected from the group consisting of biometric fingerprint templates, cryptographic keys, user permissions, and authentication states.

42. The secure digital vault backup and restoration system of any of claims 35-41 , wherein the encrypted flash drive stores the first encrypted data partition in LUKS2 format, and cryptographic keys for decrypting the LLIKS2 format are transferred from the backup smartcard to the second smartcard.

43. The secure digital vault backup and restoration system of any of claims 35-42, wherein at least one of the first secure digital vault device or the second secure digital vault device is a touchscreen device comprising a biometric sensor.

44. The secure digital vault backup and restoration system of any of claims 35-43, wherein the backup smartcard is stored on the first secure digital vault device.

45. A method for performing biometric authentication in a secure digital vault device, comprising:initiating, using a biometric sensor, a secure channel between a microcontroller unit (MCU) and the biometric sensor, wherein initiating the secure channel comprises:generating a session nonce; andtransmitting the session nonce from the biometric sensor to the MCU; generating, using the MCU:a session key, uniquely corresponding to the secure channel, using the session nonce; anda Key Encapsulation Mechanism (KEM) payload that encapsulates the session key;producing, using the MCU, a digital signature over the session nonce, the KEM payload, and a transcript hash using a private key of the MCU;transmitting the digital signature to the biometric sensor using the MCU; verifying, by the biometric sensor, the digital signature using a cryptographic key certificate of the MCU;decapsulating the KEM payload with the biometric sensor to derive the session key; andauthenticating, using the session key and the MCU, a set of biometric data in a session corresponding to the secure channel.

46. The method of claim 45, wherein authenticating the set of biometric data comprises:capturing the set of biometric data using the biometric sensor;encrypting the set of biometric data using the session key and a unique message nonce to produce a ciphertext;authenticating, using the biometric sensor, a message dataset comprising the ciphertext and a message header, wherein the message header comprises the unique message nonce;transmitting the message dataset to the MCU; anddecrypting, with the MCU, the set of biometric data using the session key.

47. The method of claim 46, wherein the message header further comprises:a timestamp corresponding to when the set of biometric data is captured; and a counter quantifying messages between the MCU and the biometric sensor.

48. The method of claim 47, wherein decrypting the set of biometric data further comprises:verifying the set of biometric data; andchecking replay protection, using the counter, the timestamp, and the unique message nonce, for transmitting the message dataset to the MCU.

49. The method of claim 47 or claim 48, wherein:the message header further comprises a session ID corresponding to the session key; andcapturing the set of biometric data comprises confirming, using the MCU, that the session nonce corresponds to the session ID.

50. The method of any of claims 45-49, further comprising processing, by the MCU, the set of biometric data within a trusted execution environment to perform biometric matching.

51. The method of claim 50, further comprising terminating the secure channel by erasing the session key and session context from both the biometric sensor and the MCU.

52. The method of any of claims 45-51, wherein terminating the secure channel comprises cryptographically attesting, using the biometric sensor, to a hardware state by transmitting a digitally signed attestation block to the MCU.

53. The method of any of claims 45-52, wherein the biometric sensor comprises a fingerprint reader.

54. The method of any of claims 45-53, wherein the MCU communicates with the biometric sensor using a trusted execution environment.

Images