A digital wallet is a software program or a hardware device that can store digital assets, through which users can access the assets for financial transactions such as viewing, trading, sending, receiving, and exchanging the assets which are supported by underlying functions like managing keys and addresses, tracking balances, and creating and signing transactions. The wallets protect digital assets by securely storing digital keys and generating wallet addresses for further external transactions. The digital wallets mainly refer to the ones for cryptocurrencies like Bitcoin, Ethereum etc. or money-transfer applications like Venmo, Alipay etc.
CBDC wallet as a bank agent CBDC wallet is essentially a small size of bank inside a pocket or a handbag in the form of a credit card, a token type, or just a software application in a mobile phone or browser expected to provide:
•User Authentication
•Transaction Authentication
•User Interface
Privacy and Transparency Balance A wallet for CBDC has no standard architecture and yet to be defined. CBDC wallet is essentially a small size of bank inside a pocket or a handbag in the form of a credit card, a token type, or just a software application in a mobile phone. As people accept CBDCs as their standard payment method, the activities with CBDC wallets gradually replace the traditional banking services such as saving, withdrawal, payment, money transfer, and loaning service since a device at hand will take care of the banking needs that would otherwise have been done with bank agent’s help in offline. The CBDC wallets are then expected to provide the following functions for secure monetary transactions.
•User Authentication: CBDC wallets must authenticate the user’s identity for device access. It can be done by a simple PIN, password, or by biometric authentication methods. The FIDO (Fast Identity Online) standard can be also used for user authentication purposes in various types of devices.
•Transaction Authentication: sending or receiving money using CBDC wallets. The wallets must ensure that the target transactions are issued authentically by the user who is authorized to access them. Security breaches usually occur during the transaction.
•User Interface providing users the information regarding the transaction
•A Balance between Privacy and Transparency: Not easy to protect user’s full privacy like in cash due to the traceability nature of CBDC. The recent trend shows a mix of those two that CBDC systems provide a certain level of privacy to users while also providing visibility or transparency to government authorities and law enforcement.
CBDC Wallet as self-sovereign identity CBDC wallets also serve as the self-sovereign identity for people. Users can collect attestations from participating institutions such as government, schools, hospitals, and banks about users themselves, and store them in the wallet securely. The users can later use the attestations selectively when identity proof is required. One of the self-sovereign identity features is to let people actively “control” which attributes in their identity to reveal and to whom to reveal rather than passively expose everything as we might do it today. Adopting the self-sovereign identity features into the CBDC ecosystem is not trivial due to the difference in underlying data structures, but it would bring a significant boost up in CBDC user experiences.
Under a two-tiered system, the proposed operational use models of CBDC wallets are summarized
Operational Use Models of CBDC Wallet Devices Offline Payment Support The offline payment support in the CBDC system would be the most beneficial feature for end–users when it comes to anonymity. After the Central bank issues CBDCs with serial numbers assigned to them, the CBDCs in offline transactions are not to be tracked to protect the privacy of the transaction. The CBDCs are authenticated with Central bank–issued certificates and wallet private keys before committing the money exchange in P2P or P2M mode. The offline transaction would mean a “cash-like” exchange among individual wallets. This is quite a challenging task to achieve under the CBDC context because protecting privacy may imply giving up tracing which is a conflicting concept with transaction safety point of view. The offline transaction must be free from the security concerns like “security weakness of hardware wallets” such as double spending, firmware attacks, and device tampering issues.
Hardware Security (PUF vs HSM vs TPM) •PUF uses random patterns in the silicon to differentiate chips from each other and creates a unique random number. This generated random number is used to seed a strong device ID and cryptographic keys to create a hardware root of trust.
•Security co-processors are physically separate chips offering true isolation of private keys. A TPM offers isolation and facilities for the secure generation of cryptographic keys, and limitation of their use, and true random number generation. It also includes capabilities such as remote attestation and sealed storage. However, these powerful security capabilities come at price, usually moving deployment to higher end IoT devices.
•A Hardware Security Module (HSM) is another physically separate chip and likely at a lower cost compared to a TPM. Like the TPM, it safeguards and manages digital keys for strong authentication and provides crypto processing. An HSM traditionally comes in the form of a large plug-in card or a separate external device attaching to the protected device, making it somewhat less suited to an IoT device. Depending upon the perceived and likely threat vectors, an HSM may provide an effective solution.
Trust Zone is another single chip solution segregating execution space into secure and insecure worlds. Insecure apps are not allowed to access security-critical assets. Those same security critical assets are isolated from tampering. Like a TPM, cost moves it to higher-end devices. Trust/Security in Silicon •Hardware is almost impossible to patch once it is fabricated, therefore, how to build Trust/Security in silicon and how to verify the security of the hardware components at design time become very important hardware security issues and challenges
•As a matter of fact, providing trusted execution environment (TEE) and embedding a hardware root of trust (HRoT) as the anchor are necessary to provide a firm foundation for electronic systems security.
There are several well-known techniques used to build security features into silicon including adding security extensions, implementing Trusted Platform Modules (TPMs), and incorporating a Physical Unclonable Function (PUF). All of these design principles and primitives are necessary to ensure that the resulting silicon has the tools in place for software to build a trusted computing environment. Root Of Trust of PSA
Root Of Trust The Root of Trust of a PSA (Platform Security Architecture) device is a multi-tier Root of Trust made up of immutable and updatable components working together to ensure:
The integrity of the device and its updatable components
The integrity of trust chains, both within the device and within an ecosystem
The privacy and integrity of secrets, and of operations performed using secrets
Separation and isolation of more trusted components from less trusted components
The PSA Root of Trust is itself partitioned into an immutable portion and an updatable portion. The immutable PSA Root of Trust is the initial Root of Trust for all PSA Root of Trust services and never changes on a production device. The updatable PSA Root of Trust represents all of the most trusted software components, providing a common trusted platform.
The Immutable Root of Trust consists of fixed and tamper resistant hardware security resources, such as boot ROM and root parameters. This is the true “anchor” on which all subsequent trust necessarily depends. It follows that the security of the complete system can only be as strong as this Immutable Root of Trust itself (weakest link principle).
In this picture above we see the most crucial ingredients to a Root of Trust: TRNG (True Random Number Generator), Boot ROM, Key derivation functions and Root Key. Let’s zoom in on the part that can be rightfully be considered the crown jewels: the Root Key. This Root Key is a value that determines what is device unique: compromise of this Root Key opens the way to potential cloning of the device as well as intercepting encrypted communications and spoofing authentication. It follows that the way this root key is stored is highly relevant to overall system security. Let’s therefore have a look at the options we have available for protecting this Root Key
Several methods for generating a Root Key and storing it on a device exist. Let’s discuss the most widely used traditional methods for getting keys on IoT devices.
Secure Elements
Secure Element (SE) as a tamper-resistant platform (typically a one-chip secure microcontroller) capable of securely hosting applications and their confidential and cryptographic data (for example cryptographic keys) in accordance with the rules and security requirements set by well-identified trusted authorities.
Secure elements destined for IoT devices are typically purchased from a silicon vendor with all required keys pre-provisioned on the chip by this vendor. This means that the IoT device maker does not need to deal with provisioning keys for his device, but the SE approach comes with significant downsides, such as increased costs and complexity in purchasing, supply chain and inter-chip interfacing.
Key Injection
Another option for storing keys on IoT devices is injecting keys into your device, which can happen at any of a number of places in the supply chain. Using this approach, the Root Key is generated outside the electronic device and injected during the production process. Typically, this needs to take place at an early stage in the supply chain (e.g. at the chip maker), because many parties in the supply will need to make use of the Root Key, for example at chip distribution or device manufacturing. After injection, the Root Key is stored on the device. Most widely used embedded key storage methods are based on Non-Volatile Memory (NVM) such as EEPROM and Flash, or on One-Time Programmable (OTP) memory such as fuses and anti-fuses. With these memory types, the provisioning of Root Keys comes with trade-offs among flexibility, key-exposure liability, cost, reliability and security.
Random Number Generation
The third method for provisioning keys for IoT devices is to use an internal random number generator (RNG) on the chip that requires a Root Key, let it derive a random secret and store this in NVM or OTP. This means key generation is handled internally, but key storage remains the same as with the method of key injection. Using this method increases the flexibility within the supply chain compared to key injection (assuming the target chip contains a random number generator), but it does not make any difference regarding how the Root Key is actually stored.
Each of the above methods comes with downsides in terms of cost (SE), flexibility (OTP/(anti-)fuses) or security (NVM/(anti-)fuses). They all have in common that some physical alteration is made to the silicon which represents the Root Key material. This implies a vulnerability to ever more powerful reverse-engineering attacks.
The Alternative: Securely Generating and Storing Keys with SRAM PUFs
An alternative approach (developed at Intrinsic ID) to these traditional methods of generating and storing Root Keys is an SRAM Physical Unclonable Function, or SRAM PUF. This uses the behavior of standard SRAM memory available in any digital chip, to extract a unique pattern or “silicon fingerprint.” They are virtually impossible to clone or predict. This makes them very suitable for applications such as secure key generation and storage, device authentication, flexible key provisioning and chip asset management.
Due to inherent deep sub-micron process variations in the production process, every transistor in SRAM cells has slightly random electric properties. This randomness is expressed in the start-up values of uninitialized SRAM memory. These values form a unique chip fingerprint, called the SRAM PUF response. Even though these values are slightly noisy between start-ups of the same device, they are turned into stable keys and form an excellent basis for the trust for your system.
Key Generation and Storage based on SRAM PUF
Intrinsic ID provides the IP, both as hardware IP and software library, that turns this slightly noisy fingerprint of the chip into a reliable Root Key. Whenever the Root Key is needed by the system, the IP reliably reconstructs it without the need for storing this Root Key in any form of memory. This means that when the device is powered off, no secret key can be found in any memory; in effect, the Root Key is “invisible” to hackers. So a tree of cryptographic keys (starting from the PUF Root Key) can be (re-)created without storing them in a memory, removing the need for a device to have any physical form of secure storage. This takes care of some of the problems inherent to the traditional key storage methods. More details about the basic functionality of SRAM PUF can be found in the White Paper “SRAM PUF The Secure Silicon Fingerprint”, while details about how to use this technology for key provisioning can be found in “Flexible Key Provisioning with SRAM PUF”.
As a recent example, NXP has announced 2 new chips based on Cortex-M33. In these devices, PSA-principles and SRAM PUF are combined to achieve a strong protection. These devices are perfect examples of how SRAM PUF can be used as solid foundation for PSA-based devices. For more background information on using the technology and its application for protecting the IoT please refer to the latest Whitepaper.
As an example of such immutable Root of Trust, consider the picture above
TrustZone with SRAM PUF TrustZone with SRAM PUF Securing IoT devices throughout their lifecycle is gaining more attention as the risks and penalty of compromise increase rapidly. To support this development, Arm has released TrustZone security extensions for Cortex-M: the Armv8-M architecture. TrustZone enables separation of processes and isolation of critical resources and brings the necessary hardware support for this to M-class CPU-based IoT devices. Let’s take a look at how SRAM PUF, enabled through software, is a powerful addition to the security features offered by TrustZone.
PSA and SRAM PUF
In previous slide we discussed how an SoC that is designed using Platform Security Architecture (PSA) guidelines can benefit from a strong physical root of trust that is immutable and intrinsic to the device. In this case, SRAM PUF (Physical Unclonable Function) provides the trust- and root key anchor for the device security. The main advantages of this approach are:
No need to store crypto keys in the plain — keys are extracted on a need-basis only
Entropy from the silicon provides strong random crypto keys, unique to the device
Only standard, digital components are needed (SRAM, typically on-chip)
Key provisioning and management are simplified, lowering TCO (Total Cost of Ownership)
Fundamentally, the approach uses the fact that every chip is unique, resulting in device-specific behavior of SRAM memory during power-up. This provides a device-unique pattern, or “silicon fingerprint”, that is impossible to clone or predict, and serves as a basis for secure key generation and storage. Please refer to the Intrinsic ID website for more information.
TrustZone-M and Root Key Protection
TrustZone components such as TZMA, TZPC and TZASC provide a basis to build a TEE, which is used to separate processes and prevent unauthorized access to resources such as crypto engines, protected memory regions, etc. Since this essentially constitutes a barrier between security domains, some security concerns can be only partially addressed. In particular, protecting secrets such as root keys typically relies on storing these in a secure flash region. It is well known that this protection has its limits, since physical attacks have been reported that allow the read-out of even protected flash.
As the “easier,” software-level attacks are becoming harder by virtue of protection mechanisms such as TrustZone, attackers will naturally look for other ways to compromise a system including physical attacks. Furthermore, while these physical attacks were once the exclusive domain of advanced hackers, technology advancements will inevitably result in more advanced, and more broadly available, tools over time.
SRAM PUF to the Rescue
The good news is that SRAM PUF technology can address these concerns. SRAM PUF can be implemented in two ways: via hardware (RTL design-in) or via software.
A hardware implementation is a good option when architecting a new chip. By integrating RTL (register-transfer level) and instantiating an SRAM, a secure storage capability is added that can be used to handle sensitive key material and directly feed this into a crypto engine. Good examples of recently announced products that integrate both SRAM PUF and TrustZone are LPC55S6x and i.MXRT600
When the design is already fixed, or silicon already exists, a software implementation is a feasible approach. This implementation makes use of a region of an existing SRAM structure that is dedicated to the PUF through TrustZone mechanisms. This is interesting if you think about it: by embedding a software library into the boot image, every chip is able to extract its own unique secret root key using the exact same code. Since the software code itself contains no secrets, it is sufficient to protect this code from modification — typically part of the secure boot flow. The software itself lives in the secure world and can be called from the normal, non-secure world, but the root key and secrets that are generated stay within the secure world.
Several products have been announced recently using this type of integration, including a Tyrion IIoT Gateway device and Nexell IoT device for medical and automotive.
At the 2018 TechCon event Intrinsic ID partnered with Nuvoton to demonstrate a software implementation on the M2351, and more recently we ported the PUF software to the MUSCA-A development platform. Expect to see more information on this in this community and at upcoming arm events.
Embedding SRAM PUF in TrustZone
Regarding a software implementation, the picture gives a high-level overview of the concepts discussed. The SRAM PUF software is part of the secure world, typically protected by secure boot. It has access to an SRAM region to “store” — or, more precisely, extract — its secrets as required. The normal world can access the PUF functionality through a controlled interface that prevents direct access to secret keys.
Security Level, Supply Chain and Cost Root Of Trust (RoT) The Root of Trust is a set of core functional elements in a hardware and software module that can be trusted and cannot be altered during the lifetime of the product. It is something that computer operating systems can rely on all the time. Something that cannot be copied or cloned. The silicon inborn unique identity embedded with the Via PUF technology (Physically Unclonable Function) is the Root of Trust, on top of which an ultimate trust can be built. Since a CBDC wallet must protect its private keys from hacking attempts, the wallet should be built based on the RoT. Any hacking attempts to steal the secret information would be denied by the silicon inborn Root of Trust
Hardware Wallet •A software wallet is an application program in mobile devices or personal computers.
•What about people without a mobile device or a PC?
•How would they make payments using CBDCs?
A hardware wallet in a smart card type or a dongle type would be the solution for them. The reason is not just because we need to cover non–mobile users, but because software alone is not secure enough against hacking attacks. Key Management Systems in CBDC Wallets Key Protection in PUF CBDC Wallets
•Private keys of CBDC wallet must remain secret all the time within the wallet, and never leave the device.
Recovering keys when lost
When a cold wallet device is lost or broken, we need to retrieve the asset by recovering the private key. “mnemonic seed phrase” is used in crypto currencies however recent study reported that about 3 or 4 million Bitcoins are lost forever because their private keys are lost. Multi-sig or multiple signature transactions using Shamir algorithm can be the solution for it (1) Key protection in PUF CBDC wallets
Private keys of CBDC wallet must remain secret all the time within the wallet, and never leave the device. A software wallet or hot wallet with secret information could be an easy target for malicious attackers. Once it is hacked and the private keys are stolen, the funds in the wallet may also be stolen permanently. Using a hardware wallet or a cold wallet can substantially boost up the level of security. However, even a hardware wallet could be exposed to security issues such as firmware modification or counterfeiting attacks in the supply chain. Injecting malware into the hardware device could end up revealing private keys to malicious attackers. The attacks can be done by external hackers or by insiders with malicious intentions. The PUF (Physically Unclonable Function) based Root of Trust (RoT) technology for the ultimate solution protecting private keys securely within the device.
(2) Recovering private keys when lost
When a cold wallet device is lost or broken, we need to retrieve the asset by recovering the private key. The cryptocurrency wallets like Bitcoin wallets provide a key recovery mechanism that users need to write down a “mnemonic seed phrase” on paper when the wallet is initialized for the first time. The users need to save the seed phrase safely in a safe place, which can be used as a key recovery seed when necessary. However, when the phrase is lost somehow, the funds are lost forever. A recent study reported that about 3 or 4 million Bitcoins are lost forever because their private keys are lost. All the burden is on users to keep the information safe.
Is there any other way to recover it while minimizing the user’s burden? Multi-sig or multiple signature transactions can be the solution for it. A private key can be split into multiple shares using the Shamir’s secret sharing algorithm where the shares can be used to reconstruct the original private key. The algorithm does not need all the shares to reconstruct the key but only a minimum number of shares are required which is called the “threshold” number.
Unlike the permissionless cryptocurrencies, however, the CBDC system maintains controls on digital money. To split a private key into 3 shares in the CBDC system and save 3 shares to 3 different entities: one for the owner of the wallet, the second one for the commercial bank where the user’s account is created, and the last one for a trusted third party running by government authority. When a CBDC asset needs to be recovered, the user needs to prove his/her identity to the trusted third party and the commercial bank for reconstructing the original private key. Dealing with banks and government authority may not be ideal for individual users, but the security concern is not small to overlook. The details of the recovery architecture can be developed to enhance the user experience.
Security Weakness of Hardware Wallets Issues
•Firmware
•Double spending
•Device tampering
•Wallets in PCs or mobile phones
A solution in PCs, mobile phones or USB dongle
USIM/eSIM cards or USB dongle embedded with the Via PUF technology, the silicon inborn Root of Trust, to protect the user’s secret credentials in PCs or mobiles Firmware issue: Hardware wallets may not be free from security issues due to the attacks targeting device firmware including firmware counterfeiting and the MITM (man-in-the-middle) attacks. If device firmware is compromised during device manufacturing or in shipping process, the digital asset in the impacted device could be stolen by attackers. A malware extracting the private key of a hardware wallet and rerouting payment address to the hacker’s address can be infiltrated into the original firmware resulting in sending the money to the hacker instead of the original intended recipient. Firmware protection must be guaranteed by CBDC wallet functions such as firmware encryption, authentication process as well as performing secure boot and secure firmware updates.
Double spending issue: Double spending means that the same single digital token can be spent more than once, which could break the entire CBDC system. The problem could be more serious when the transaction is in offline mode during which the Central bank has no immediate visibility. While the decentralized cryptocurrency system uses a consensus algorithm to address the issue, the CBDC system uses the controllability of the Central bank to revert any illegal transactions. However, the correction could be an expensive and unpleasant experience on the user side. Using a secure hardware wallet device at each user’s end can be the solution to address the double spending issue. The secure environment using secure devices like the Via PUF CBDC wallets, can be used to enforce one–time spending on each digital token.
Device tampering issue: Malicious users who possess their own hardware device can attack the device physically extracting secure information from the device. The extracted information can be used for adversary attacks like spending the same token an unlimited number of times. This will break the whole CBDC system. That is why using the right secure hardware wallet is crucial. For example, the Via PUF CBDC wallet uses the unique inborn identity chip where the secret information such as the device’s private key is securely stored and never leaves the chip to the external world, not even to the malicious owner.
Wallets in PCs or mobile phones: Hardware wallets in PCs or in mobile phones are relying on software implementation in the hardware platform. The wallet private keys are usually stored in PC hard disk or SSD memory in mobile phones which can be an easy target for hackers due to their low security level. Malware can be installed unintentionally by the user’s permission. When a user tries to send money to a friend for example by copying and pasting the friend’s wallet address, the malware can replace the address in the clipboard with another one. Since the address is usually a long and complicated string, the user does not know the money is going out to somewhere unintended. Careless users can also be tricked into a phishing website or a cloud where they may reveal secret information such as a password or private keys.
Proposed solution in PCs or mobile phones: How do we protect the “naive” users from the attacks on PCs or mobile devices? We propose USIM/eSIM cards embedded with the Via PUF technology, the silicon inborn Root of Trust, to protect the user’s secret credentials in PCs or mobiles. A USB dongle type of hardware wallet could be an alternative solution as described in the “Via PUF Wallet” section below.
Physically Unclonable Function (PUF) •The Via PUF (Physically Unclonable Function) technology is based on “Via” or “Contact” formation during the standard CMOS fabrication process.
•The sizes of Via or Contact smaller than the requirements in a controlled manner, resulting in the unpredictable or stochastic formation of Via or Contact where the 50% of randomness is achieved
•The property to establish the silicon “InbornID” PUF technology, where the “InbornID” means that the unique random number is self-generated within a chip, not injected
The unique InbornID characteristic enables the Hardware Root of Trust (RoT) technology in a silicon chip The Via PUF (Physically Unclonable Function) technology is based on “Via” or “Contact” formation during the standard CMOS fabrication process. The technology is the outcome of the reverse thinking process. Rather than meeting the design rules, it makes the sizes of Via or Contact smaller than the requirements in a controlled manner, resulting in the unpredictable or stochastic formation of Via or Contact where the 50% of randomness is achieved in a chip. Vendor use the property to establish the silicon “InbornID” PUF technology, where the “InbornID” means that the unique random number is self-generated within a chip, not injected . The unique InbornID characteristic enables the Hardware Root of Trust (RoT) technology in a silicon chip. The Via PUF characteristics are the core factors for satisfying the requirements of CBDC wallets. The security SoC (System on chip) products based on the Via PUF technology are currently in mass production
Keeping Secrets Secret
Technology Advantages of Via PUF The international standardization efforts on security requirements and test methods for PUF for generating non-stored cryptographic parameters are currently actively ongoing as of today under ISO/IEC 20897–1. As the standardization process is being finalized, we can expect that the PUF technology becomes more scalable and its market demands grow exponentially.
PUF Hardware Wallet A hardware wallet for CBDC applications can be built in many ways, where applying the Root of Trust technology is crucial to protect digital assets. Via PUF based hardware wallets whose variations are in a USB dongle type or a smartcard type for standalone applications), and a USIM/eSIM card type for mobile applications.
PUF Technology Overview •PUF provides an unbreakable security origin for the hardware Root of Trust (RoT) technology
•User authentication with USIM/eSIM PUF and FIDO also can be used
•Secure Wireless Connectivity
•User Interface and Experience (UI/UX)
(1) Why Via PUF technology?
The Via PUF provides an unbreakable security origin for the hardware Root of Trust (RoT) technology. The CBDC wallets need to use the hardware RoT for their own security protection. Since the private keys of CBDC wallets are stored in secure memory encrypted by an internally generated PUF key, and the PUF key is never stored in the chip but generated every time it is called, it is practically impossible to steal the key by hacking. Since all the security–related functions are executed within the security boundary, no sensitive information is exposed to the external world.
(2) User authentication with USIM/eSIM PUF
The Via PUF CBDC wallets use biometric fingerprint sensing technology for user authentication. The fingerprint templates are stored in the secure storage of the USM/eSIM PUF chip and never leave the chip. Only the matching results are sent to MCU for display. The authentication by HMAC algorithm or by certificates can also be used in the USM/eSIM PUF device. A PIN–based authentication method could be provided in case the fingerprint unlocking is not desired at the user end.
The FIDO (Fast Identity Online) technology could be the alternative option for user authentication. The wallet public key is pre-registered in the FIDO server at the “Relying” party and the user fingerprint is locally registered and authenticated. The technology allows users to access the device with their fingerprint credentials without typing ID and password. However, the wallet device should be connected online to use the technology.
(3) Secure wireless connectivity
The wallet device supports Bluetooth or NFC (Near Field Communication) short-range wireless communication with built-in PUF based security functions such as device authentication, secure boot, data integrity checking, secure firmware update, and secure access to the Tier-2 servers in the CBDC system. Using secure wireless connectivity, the CBDC wallets can communicate with other CBDC wallets for monetary transactions which include P2P mode and P2M mode.
(4) User-friendly interface and experience (UI/UX)
When sending a cryptocurrency asset like a Bitcoin to an incorrect address, it is impossible to retrieve the asset back. On the other hand, since the government authority or the commercial banks in the two-tiered CBDC system control the asset transactions, the misplaced CBDCs can be retrieved. The downside is that the government involved backing up process usually takes time which would be an undesirable experience for users. The better user interface design, the easier system acceptance by users and so the more enhanced system security it derives to. The Via PUF CBDC wallets provide a user-friendly interface helping to ensure the information user provided is indeed correct.
(5) Key recovery service
The private key is split into 3 shares and save the shares to 3 different entities each: one at the owner’s wallet, the second one at a commercial bank, and the third one at the government authority. When the shares are saved in each entity, they are encrypted for safety with a Via PUF chip.
Conclusion •The various aspects of the CBDC system are discussed. Unlike the decentralized ledger structure in the cryptocurrency system, most of the existing CBDC prototypes adopt a “semi-centralized” ledger system which allows partial or controllable anonymous privacy for users while the controllability of the Central bank is maintained.
•The security of the CBDCs is crucial for the entire system. The Via PUF CBDC wallets powered by the “silicon inborn unique identity” technology bring the ultimate security features to the CBDC system.
Man Behind Hard Work
