Crypto Wallets

Introduction

This is Part I of a three-part series, looking into the age-old issues of safeguarding personal secrets and keeping them from malicious and deliberate cyberattacks, especially in the context of cryptocurrencies. They have become the central issues in the discussion of security, privacy and the push towards building a new, decentralized and trustless infrastructure. A fair amount of details are presented in this series with the belief that a thorough understanding of all aspects of these issues is critical in the design of next generation cryptocurrency wallets.

If you are only looking for a quick reference for Counterseal Wallet specifically, go straight to the set up manual. Come back to this series to fill in the details later.

Crypto Wallets

Many people think of Bitcoin wallets as the repository of Bitcoins. This mental image is inaccurate on many levels. In fact, there are no coins to be found in the wallet, only the "private keys" of coins are maintained within. More precisely, your Bitcoin wallet is merely a repository of copies of your "private keys", or "a wallet of private key copies". The Bitcoins themselves actually "live" on the blockchain, much like those account balances in bank ledgers.

Any other copies of them, even existing outside of your wallet, would work just the same in accessing "your" Bitcoins when presented to the blockchain in Bitcoin "transactions". As the guardian of your own crypto assets, you are better off considering it as a "wallet of secrets" which you want to keep hidden from other people.

Blockchain technology is a powerful game-changer for the storage and transfer of value. The new economy enabled by this revolutionary technology could eliminate a large number of intermediaries and usher in fair, ethical, and more efficient organizations. However, before we are able to reach those lofty goals promised by this new technology, we are confronted with the mundane task of managing our cryptocurrencies and shopping for crypto wallets. We quickly discover that our notion about value, secret, coins, vault, wallet, transactions, privacy, etc. all need to be readjusted to cope with the challenges posed by this brave new world of cryptocurrencies.

Part II: Preserving Secrets

Part III: Ai-Fi Counterseal Wallet

Keeping Secrets

Safeguarding Safe Combination

A secret is any piece of information that's intentionally hidden from others. Secret keeping is often built as a hierarchy. If a secret, such as your bank account password, is locked away in a safe, the safe combination becomes the "master secret" that is considered "stronger" and situated higher up on the pyramid for the purpose of protecting lesser secrets. As such, the combination to a safe is the best example of how the "top" personal secret is safeguarded.

These memorabilia on eBay depict how a safe combination was maintained in the past. The original messages are transcribed roughly as follows: "Only one person at each office is permitted to know Combination of Safe. Employee holding combination will enclose in envelope and seal with wax seal. Envelope to be enclosed in Express Envelope and way-billed to me as a valuable package. H.C. Abbey, Auditor Station Accounts".

- 1921 Missouri Pacific Railroad Safe Combination with Wax Seal Little Rock.

The typed instruction in the middle of the picture is the actual safe combination: turn right ..., left ..., right ... again. Both pieces of paper are to be put into an Express Envelope and carefully enclosed with a wax seal as in the last image according to the instruction. This was the then state of the art protection scheme for Safe Combination in 1921, a whole 100 years prior. In the intervening years between then and now, we saw the emergence of computers, the great age of Internet, the smartphones and wearables, the Perseverance rover landing on Mars, and the latest advent of blockchain technology proclaimed as the pillar of the Fourth Industrial Revolution. It is no small wonder how little has changed in our ways of hiding and protecting our Safe Combination:

The picture above displays one of the popular hardware wallets together with its "recovery seeds" recorded on a "paper vault" and also engraved on a steel plate, the technology behind which is not exactly groundbreaking. The well accepted wax seal or its contemporary counterpart is not being applied here, probably due to the fact that it would have been too late anyway when a wax seal was detected broken.

Our favorite is the one below, based on the technology tried and true for over 1000 years, sensibly DIY, and perfectly in keeping with the trustless/decentralized spirit of Web 3.0:

Safeguarding Cryptocurrencies

The 2-Minute Learning Curve

Cryptocurrencies, such as Bitcoin, Ethereum, Tether and XRP, are digital assets that apply strong cryptography to regulate the creation of crypto coins, to verify the transfer of coin ownership and to secure transaction records in a decentralized and trustless manner based on community consensus. The crypto investors have total control over their own transactions, which brings the cost savings and conveniences never before afforded to us in managing our financial assets. One of the bold visions of Bitcoin is a world where everyone could be their own bank. However, this pseudonymous, near instant and low-cost way of transacting one's assets comes at a huge personal cost.

The advantage of complete control over one's crypto affairs must be traded off against the lack of protection and little oversight from any governmental institutions. Our newly discovered financial freedom must be evaluated in its proper context:

Unbeknownst to the average crypto investors, this decentralized blockchain-based market exposes individuals to unprecedented financial perils without any safety net to mitigate the risk. In one fell swoop all the regulations and protection we've been paying taxes for are stripped away, replaced by those crypto wallets that we can educate ourselves in 2 minutes allegedly. A point of contrast on how much risk we expose ourselves to: The liability for your consumer accounts at the banks or credit unions is capped at $50, provided the fraud is detected and reported in time, thanks to Regulation E, whereas the aftermath of a crypto attack could be catastrophic and total. There is no wonder why hacking of crypto assets has exploded into a crime syndicate of late.

Losses from cryptocurrency crime surged to $4.52 billion in 2019 alone. In the unfortunate event that the private keys of your Bitcoins are leaked or exposed, the attacker can steal all your coins remotely and tracelessly without much backlash. Managing one's cryptocurrencies is not for the faint of heart. It all boils down to the protection of your private keys for your crypto holdings. The ghastly imagery below is no longer the no. 1 nightmare that keeps us up at night, having been replaced by the nagging anxiety about the traceless, borderless, vague but striking-at-any-time attacks on our crypto holdings.

The Custodian Options

Unsure about our ability in safeguarding our crypto assets, some of us fall back to the traditional approach and outsource the protection of their cryptocurrencies to some third-party custodian services like Coinbase, BitGo, Robinhood, Anchorage, Kingdom Trust, etc., by surrendering their private keys to their chosen custodians.

Unfortunately, setting aside the circular argument of entrusting one's trustless cryptocurrencies to third parties, we are not surprised that those custodian services quickly become the low hanging fruits for the swarm of hackers highly motivated to exploit this novelty in want of applicable defensive strategies in a regulatory vacuum. There is no shortage of usable attacks once those custodian services are marked as highly lucrative targets. They may leak your account data. They may be hacked themselves with collateral damages spilling over to their customers. Your custodian accounts may be stolen by hackers hijacking your email account or even your text messages. Although the attempted "scary good" heist at Coinbase was detected and blocked in time before any funds were stolen, details of the attack reflect capabilities on par with those of nation-state-sponsored attackers costing between half a million and a million dollars to launch. Those reported cryptocurrency hackings on custodian services further confirm the adage, Not your Keys, Not your Coins.

Some of the newer services, equipped with the latest technology such as Threshold Signature, may fare a bit better. In order to hack a user account protected by Threshold Signature technology, both the user and the service provider must be compromised in a coordinated way. However, most of the attacks listed above are exploits on vulnerabilities created exactly by this artificial need of keeping a relationship between the user and their service provider. There is no escape that some trust mechanism must be maintained between a user and those new third-party "financial services", which creates attack surfaces. (We will revisit this Threshold Signature technology later to see how it can be properly deployed for personal protection.)

Dare Questions

This report surveys the lay of the land and attempts to understand why there has been so little progress made in safeguarding our non-tangible digital secrets.

The newcomers in the Blockchain space must face the following "poof" challenges:

Your crypto wallet does not work the same as your bank passbook: The account balance of our crypto holdings is not maintained in our wallet or any bank ledger, but actually on the blockchain. Crypto wallet only stores copies of your private keys for retrieving the assets from the blockchain, not the actual "currencies". Even with the hardware wallet firmly held in your hand, you will never be sure of its net worth by staring at it.
Your crypto balance may go "poof" on you at any time: A casual peep or a single camera click over our private keys or recovery seed, either in text strings or mnemonics format, allows immediate access to our accounts on the blockchain. The assets guarded by the secrets can go poof on you instantly without a trace. How often should we check if it is "still there" on the blockchain? What is the modern counterpart of wax seal for forestalling silent attacks on coins?
There is no alarm substructure to counter the "Poof Effect": Currently the mechanism to forewarn the pending attacks on your crypto wallets is sorely missing. It is unclear how this need for early warning can be answered under the present public blockchain framework and the ad hoc nature of owning our cryptocurrencies through "wallets".

This "Poof Effect" has been exacerbated by the fact that the recovery seed is kept separately from its wallet, creating two attack vectors and doubling the "Poof Effect" as a result. All players in this space appear to have accepted this eventuality as part of the bargain for their newly acquired crypto independence. Hardware wallets has become the go-to solution that seemingly offers more comfort in this situation of total lack of physical access to our crypto holdings that exist only on the no-man's-land we call blockchain.

The Ai-Fi Counterseal Wallet, as will be detailed in Part II and III of this series, attempts to address these new challenges.

Threat Model

To figure out how our crypto holdings ought to be protected, we must first understand the nature of the beast. Although we are dealing with "digital assets" in the cryptocurrency market, similar to the digital fiat assets or the non-cash money, our exposure to risks and the crime prevention apparatus are radically different. We no longer deal with financial institutions through heavily regulated banking or investment accounts, but are confronted with the task of managing our private "ledgers" in terms of blockchain transactions and crypto trading accounts.

Minimally, we must understand how our crypto accounts may be maintained and protected without involving any third-party financial institutions. No amount of cryptographic power on one's computing devices or ability in publishing transactions on immutable ledgers would automatically offer an alternative safety net. Under the PKI (Public Key Infrastructure) the secrets mostly involve private keys of the PKI key pairs, which are the basic construct for conducting cryptographic key exchange or negotiation, producing crypto transaction signatures, authenticating the identity of the owner of the private keys, etc. Those private keys may be randomly generated, or derived through some algorithms based on the originating passwords. For ease of key derivation or administration in the crypto wallet application scenarios, a single "seed" secret or key may be utilized to derive a large number of the rest of the keys in the wallet through an algorithm. BIP 0032 is one such hierarchical key generation standard.

It is apparent that we are entering a brave new world of self-managed and decentralized markets of digital assets without the protective umbrella offered by various financial institutions we have been relying on traditionally. Regardless of how promising it may sound, for most of us this new reality is outside of our comfort zone. To find our way around it, we tend to relate those new crypto products and concepts to something we are accustomed to. But this attempt so far seems to have only misled rather than illuminated. When we first ventured into this field, as an introduction, we are told to acquire a "wallet", which can be "soft" running on standard PCs or mobile devices, or "hard" if we want to safeguard it with some "stronger" purposely-designed hardware to fend off "attacks". Then there is the notion of "Recovery Seeds", which would save you from ruin if your crypto wallet was lost, stolen or "compromised" by a plethora of devastating possibilities.

The description and naming of the concept of wallet and the recovery seed are largely inaccurate and problematic. Let's clarify. Crypto assets are intangible. They operate under the PKI (Public Key Infrastructure) framework. A crypto account for storing cryptocurrencies is protected by a key pair. Although we use the word "key" to describe them, they are not to be confused with the hardware objects we often refer to in the context of locks and keys in the real world. A casual glimpse of the private keys will confer the ownership upon the viewer if they choose to act on it. They are best described as "secrets", the mere sighting or viewing of which steals or cancels them with the "Poof Effect" mentioned previously. We tend to use words like "wallet", "safe", "vault" to describe how we store our private keys or valuables, which forms the wrong mental imagery for our non-tangible secrets. Consequently, as will become increasingly clear, misinformed concepts beget incorrect actions.

However, unlike traditional pocket wallets for holding paper money, credit/debit cards, drivers license, etc., a crypto wallet holds nothing tangible but those private keys and interface code for you to interact with the external blockchain. On the other hand, the "Hardware Wallet" is not a crypto wallet as just described, but a separate storage on dedicated hardware that pries off private keys and other limited function set from a regular crypto wallet for signing blockchain transactions. The hardware wallet is rarely standalone and almost always requires an external "soft wallet" or "bridge" (Trezor) for dealing with the blockchain and its consensus network, in which case that external "wallet" or bridge is described as "watch-only" (but not necessarily harmless). For fear of losing the secrets, they further create a "Recovery Seed", which is the passphrase/mnemonics based on which all secrets in the wallet may be reconstructed. So in addition to the need to secure your private keys in the wallet, you must also protect the recovery seeds as a necessary but separate task, which are usually "strongly suggested" to be kept in an unspecified safe place. This recovery seed effectively doubles the attack surface of the original wallet. It would be game over if either the hardware wallet was lost or the Recovery Seed compromised.

Protection of Secrets

A secret protection method is to preserve and protect certain undisclosed information, which is valuable only while not being revealed to unintended parties. The leaking of a secret will turn the secret into a non-secret and lead to irreparable damages which the secrecy is originally intended to prevent. Leaking a safe combination may cause the loss of the safe's content. Leaking one's password to a web service or computing device may lead to the loss of the digital content hidden behind the various application lock screens. Leaking the private keys within a Bitcoin wallet would potentially result in the theft of the bitcoins.

Secrets and Lies

The concept behind crypto wallets is more akin to the magical Aladdin lamps, the "rubbing" of which with a PIN code or password would touch off the appearance of the Genie inside. A casual glimpse of the released secrets may cause them to lose their magic power (or internal crypto values) without altering the bits and bytes of your wallet contents. There is no way to tell whether a wallet still retains its asset value or not by staring at its digital contents. The Genie might have gone while the lamp looks exactly the same as always.

With this more accurate imagery of the magic Aladdin lamp and the fragile PIN code, it allows us to evaluate our protection strategies in a new light. The hardware wallets are preferably portable and kept around like our smartphones, given that the PIN is usually inadequate to ward off persistent offline attacks, especially when the throttling logic for PIN code fails. The owner is best not to leave the hardware wallet out of sight. The "Recovery Seed", when stored separately, needs the same tender care. To do it right, for those risk-averse individuals or those with substantial crypto holdings, the correct practice is to carry their hardware wallets in their pockets alongside with their recovery seeds.

To store those Recovery Seeds in offline cold storage is fundamentally flawed. To convince yourself of this point of concern, just picture your leaving behind your Aladdin lamp at home with feeble rubbing tricks (PIN) that would allow the flighty Genie to appear before its new master unfettered. To top it off, some users leave two lamps (the wallet and the Recovery Seed) both in the "secure" confines of their home, with the "Recovery Seed" usually recorded on a suggested "acid-free" paper or notebook barely protected. Worst of all, even with your hardware wallets in your pocket and the only copy of your Recovery Seeds on hand, there is no guarantee that your crypto assets remain where you have left them. The "Poof Effect" may set in at any time.

Attack Targeting

There are two types of attack: untargeted and targeted. Untargeted attacks are generally online-only, lacking specificity and costing little to launch. Targeted attacks are specific to identified targets or individuals, potentially involving special background investigation and even offline spy operations (theft, home invasion, etc.) on high-value marks. Targeted attacks naturally entails higher cost, to be justified by the higher potential return on investment. Untargeted attacks may be launched to discover vulnerable or high-value targets before progressing into a targeted one in the follow-on stages. Phishing attacks and password guessing have much higher chance of success if the crosshair is squarely locked on the target, albeit at a higher cost.

Single Points of Failure

A single point of failure (SPOF) is a part of a system that, if failed, would endanger the entire system. SPOFs jeopardize the availability and reliability of any system, be it a business practice, software application, or other industrial system. It is a well-understood concept in reliability engineering.

Under the crypto wallet application scenarios, those keys in the wallet are protected by one of the following methods:

Software Wallet: This is the software that combines the PKI key materials with the crypto transaction signing functions into a single software package, which may run independently as an "app", or be embedded in a web page (web wallet).
Hardware Wallet: A crypto wallet may be separated into two parts: the software "front-end" wallet, which interfaces directly with the blockchain network, and a separate back-end "key vault", a custom hardware which hosts all the private keys and signs all the crypto transactions. Sometimes a hardware wallet may be built on a simple bootable device of USB or CDROM with similar or weaker protection if incorrectly implemented.
Front-End Wallet: As mentioned above, due to the complexity of blockchain interfaces and crypto transactions, the Front-End wallet is the assembly of functions that deal with the blockchain networks. The open-sourced Electrum is one such wallet that supports Bitcoin. It may be made into a "watch only" wallet as a conduit for passing crypto transactions to external hardware wallet containing keys and operating independently.

In the drawing above, the Front-End wallet runs on the smartphone. The hardware wallet is embodied in a dedicated device (Trezor One shown here). The interface between the Front-End wallet and its hardware back-end may be through some wired (USB as shown) or wireless (e.g. Wi-Fi, Bluetooth) means, in which case a "pairing" step needs to take place before both wallets may interoperate with each other. It may also be "air-gapped", in which case the the hardware wallet may be off the network altogether and the communication are conducted through some manual means such as copy-and-paste across devices, 2D barcodes or QR codes, etc., which reduces the attack surface but is by no means attack proof.

Presently all popular crypto wallets suffer a good many SPOF of one kind or another, defined as a vulnerability in a method which can be exploited to defeat the complete assembly of protection by focusing on attacking a single component, usually running on a single device. Once the targeted attackable component is breached, some or all secrets held and protected by the method may be revealed to the perpetrator in totality. After a SPOF of a crypto wallet was successfully exploited and some or all of the private keys are revealed, valuable cryptocurrencies stored inside the wallet could be instantly stolen. Some attacks don't result in the loss of secrets but inflicting a denial of service attack designed to hijack some resources (e.g. private keys) or make them unusable (e.g. by encrypting them) in order to effect a follow-on ransom demand.

The typical targets of attacks on crypto wallets are:

The password of the software wallet.
The PIN code of the software/hardware wallet.
The private keys stored in the wallet but exposed during transmission and/or during the operations for effecting a certain function set (transaction signing, status listing, outstanding balance display, etc.)
The recovery seed or passphrase, which is recorded outside of the wallet for recovery purposes. A successful attack on this recovery seed would spell the loss of all the private keys, hence the complete loss of the coins in the wallet. Although the recovery seed or passphrase may adopt certain external scheme to eliminate its single point of failure, such as the SSS (Shamir' Secret Sharing scheme) allowing splitting the seed into multiple "shares", it requires many more secrets to be hidden and substantially reduces the reliability of the whole method (combing the wallet with the SSS). Besides, storing a secret offline or offsite is inherently problematic, as there is generally no monitoring or auditing apparatus/method to guarantee its safety, as the loss event of a secret is usually not accompanied with a physically discernable symptom.
The wallet software or storage targeted by malwares on infected platforms.

Attacks and Exploits

The following is a list of example attacks or exploit vectors on various components of a secret preserving method:

Invasion of malware (virus, worms, etc.) on the devices which host the software wallet.
Supply Chain Attack: If the wallet or part of it is acquired through a third party or even Amazon, the acquisition and/or delivery process may be compromised such that the authenticity of the wallet may be in doubt. Although this is mostly aimed at hardware wallets, this risk may be generalized to include any scenarios where a third-party provider is entrusted to supply or service the wallet. The question is how to confirm that the received hardware wallet is genuine and has not been tampered with. This turns out to be a rather difficult question to answer, as the holographic tamper evident labels are not even resistant to hair dryers and the firmware verification "directly" with the vendor is not as straightforward as it sounds. This is the hardware equivalent of "phishing attack". It is difficult to reliably establish the trust relationship with the vendors. This is again where the circular practice of relying on third-party trust under a trustless infrastructure brings us trouble. Both Ledger and Trezor have their share of the attacks.
Attacks on the hardware wallet: This typically requires the physical possession of the device lasting for a period of time. It is a particularly dangerous vulnerability because it allows for consumer-grade attacks that theoretically anyone without any experience can perform simply by following a tutorial. Stories abound about easy hacking of the cold crypto wallets.
"Shoulder Surfing" attack: This is usually effected by spying on the user when they are entering the password of a software wallet (through ) or the PIN code of a hardware wallet.
"Evil Maid" attacks, which is the attack by physically breaking into the storage where the hardware wallet is stored. This is usually coupled with the ensuing side channel attack and other hardware exploitation after getting hold of the hardware device.
"PIN code attack": This can be as simple as the "shoulder surfing" attack or through "evil maid attack" followed by a side channel attack, which is usually required to defeat the time constraints (e.g. number of retries) when entering the PIN. Note that the strength of PIN code is grossly weaker than the private keys even taking into consideration possible hardware support and needs to be strengthened in commensurate with what it is designed to protect.
"Man In The Middle" attacks aimed at the communication channel between the front-end wallet and the back-end hardware wallet: This may result in the loss of private keys or transaction signatures. It may also operate as ransomware.

The above is just a rough collection of possible attacks on computing devices and on those methods running over them. All methods are vulnerable to attacks. As are well recognized, methods running on dedicated hardware are not immune to attacks and exploits either. Architecturally, those methods with certain inherent SPOFs are most vulnerable, as attacks concentrating on those critical "single points of failure" can take down the entire assembly of the method by compromising just a single identified weakness. The cyber world has become an intense battlefield and "a scene of constant chaos" not unlike that of conventional warfare keenly observed by Napoleon 200 years ago. "The winner will be the one who controls that chaos." Any secret preserving methods must be judged based on how well they help bring resilience and adaptation into the unavoidable chaos in cyber warfare. By eliminating single points of failure your standing on the chaotic scale is tremendously improved.

Note that an attack may take multiple steps, starting from attacking a single specific vulnerability. For instance, an attack may initially swap out the software or firmware in a device to an infected one that appears behaviorally identical as before but contains hidden reconnaissance logic so that follow-on attack may be launched based on the information newly and illegally collected. Any method running on a platform, perhaps based on popular operating systems, is easily attackable, regardless if it is on dedicated hardware or not. Any single point of failure quickly becomes the weakest link.

A method with no obvious single points of failure requires the attackers to compromise multiple vulnerabilities and to painstakingly synchronize those multiple attacks to break through the integrated defense, often across multiple computing platforms of different lineage, which is considerably more difficult to accomplish.

Scaling Out or Up

As cryptocurrency type multiples and users' crypto holdings grow, there is a need to expand the size and variety of their wallets. Many users purchase multiple hardware wallets for this reason. Unfortunately this "scale out" approach of owning many hardware devices increases the complexity of protecting their crypto assets. Each hardware wallet has its own recovery seed and embedded secrets, not mentioning the numerous physical devices to be stored and maintained. People may prefer a "scale up" approach, hopefully with enough built-in redundancy to eliminate all SPOFs. A "scale up" and integrated approach would open up other possibilities, such as adopting different wallets for different crypto applications or integrity constraints such as maximal spending limit, white recipient list, account classification, etc. Due to the portability requirement, it is difficult to picture how this need to scale can be addressed by hardware. The approach suggested by Ai-Fi Counterseal Wallet is exactly one such software scale-out solution.

The Loss Event

A crypto wallet may be lost or become inaccessible due to theft, physical damage, malfunction, misplacement, and a sleuth of other reasons. Once becoming inaccessible, all crypto assets managed through the wallet are at risk. Although a PIN code is usually required to open the wallet, it is no secret that offline attacks are readily available and inexpensive in breaking it. Unless the wallet is hosted on a smartphone, hardware wallet vendors don't have the infrastructure for the "remote wipe" function. Once the loss event occurs and is somehow discovered, the only option is to fetch the recovery seed, rebuild the wallet from scratch and transfer all your crypto assets to a new location. Recoverability is not an issue, except that it must be carried out before the lost wallet is breached if malfeasance is suspected, in which case it turns into a race in time. This is why the recovery seed looms large in the mind of wallet designers.

Although necessary, this curious design of placing the same set of secrets (private keys and recovery seed) in two separate and independent places has an unforeseen repercussion. It makes the hardware wallet design incompatible with the Secure Enclave or Secure Element architecture, at least conceptually. The SEP (Secure Enclave/Element Processor) design is grounded on the principle that the protected secrets are stored inside the SEP and isolated with a hardware filter so external applications cannot access them. They may be applied to perform various functions according to a rigid protocol or rules (e.g. thru "mailbox") but must not be retrieved or revealed. In the hardware wallet design, the need to create, maintain and recover from an externally readable recovery seed renders the SEP architecture largely ineffective.

Audit Trails

As have been pointed out previously, your crypto assets in your wallets may disappear for any number of reasons. This is particularly insidious if your wallet design suffers some SPOF (Single Points Of Failure). Any breaches on one of those SPOFs leaves you absolutely no recourse.

On the other hand, a design exposing no SPOF would force the attackers to compromise at least two unrelated weaknesses before scoring any gains, which buys you valuable early warning time. This is why elimination of SPOF is all critical to the protection of your crypto assets. This is also why a single hardware wallet by itself is by definition SPOF and therefore inherently risky. Besides eliminating all the SPOFs is only half of the story. There ought to be notifications or alarms in the first instance when your wallet was suspected of being under attack. Unfortunately this second half of the defense after eradicating SPOF is sorely missing. In Part III of this series we will introduce the Counterseal Wallet audit trail which monitors all activities conducted on the wallets as an alarm mechanism.

Cryptocurrency Wallets

Software Wallets

Let's review why we feel so uneasy about storing our private keys in a "software" wallet, even when the software running on some platforms is much more up to date with the latest hardware technology.

A hardware wallet has its own dedicated environment, which is more difficult to exploit aside from the risk of "supply chain attack". A software wallet, on the other hand, running on a generic platform such as iPhone, Android, Microsoft Windows or Apple Mac must share its operating environment with other applications that may be infected or malicious. The desktop or laptop are quite complicated and prone to exploits as the applications may be introduced to the platform without much quality assurance or safety guarantee. The smartphones such as iPhone or Android phones and many tablets all have their own digital App Store as the distribution channels, developed and maintained by their respective platform vendors, which improves this situation considerably.

Assuming the wallet is implemented in software, there are two popular attack vectors where the wallet software is most vulnerable. Although they come in a variety of capabilities, capacities and form factors, their security models can be similarly outlined as in the diagram below, based on their respective architectures. (This diagram uses the Android smartphone as an example.):

Applications run individually but share a well defined set of functions with other applications (screen, GPS, phone, camera, sound, accelerometer, VPN, keypads, notification, etc.). The interface between the applications and their intended functions is indicated by the "Function Sharing" arrow. Sandbox, permission, capabilities, intents, etc. are all constructs on this layer for this sharing of application functions. On the lower half of the layered design, all applications, shared functions and libraries access the foundational kernel services at the arrow of "Kernel Resource Sharing", notably for sharing virtual memory, caches, network buffers, files and disks. Under typical threat models, most of the attack surfaces situate at these two layers. For instance, keylogger takes advantage of Function Sharing (through the accessibility suite on Android, not so common on iOS). Stealing data and private keys across virtual memory is possible over the Kernel Resource Sharing layer. The usable data need not be raw data from the virtual memory, it may take the form of shared-memory side channel attack directly accessible from certain proc files. The reported ingenious "UI State Inference" attack combining a sneak peek at the shared memory with a follow-up phishing display is well explained by its discoverers. Fortunately this attack requires the display of a fake screen and immediately transmits the stolen keystrokes to an external accomplice. The attack is often obvious to spot, as the fake phishing screen would cause the screen to glitch when the real application displays the real and largely same screen. This forces the attacker to hasten the use of the stolen keys immediately before the user notices the unusual glitches and launches counter actions. The attack surface would be greatly reduced if an audit trail is available to trigger the generation of a new set of key materials.

The protection for this architectural sharing of the system functions is rigorously enforced by the platform itself, not unlike the situation of a jail where all prisons are monitored and controlled by the enforcer, namely the operating system. There are ways to break the rules of the operating system by "jailbreaking" it. Once broken, all rules and regulations are no longer faithfully enforced.

There are two other means of violating the enforcement of the resource sharing segregation rules:

MDM
Parental Control by installing various kinds of applications with severe influence on all running applications.

Generally speaking, a software wallet needs to run independently and securely on a shared platform without undue influence by other elements sharing the same platform. To protect one's crypto assets, the software wallet must depend on the platform for reliability and predictability, and the users themselves must make sure it is not jailbroken, not under MDM, and not allowing unrecognized applications sharing the same function set. Unfortunately this privacy and security guarantee oftentimes is beyond the grasp of many crypto owners. Consciously keeping up with all the software updates on the involved platform takes a bit of effort.

The recent head butting between Facebook and Apple over the ATT (App Tracking Transparency) issues is welcome news for those who want the built-in sandboxing more forcibly administered. In theory, there is little difference between a hardware wallet and a signed mobile wallet application running in a leak-proof sandbox under the App Tracking Transparency framework.

Hardware Wallets

Secure Enclave

Protection schemes based on Secure Element/enclave are old technology. They typically involve a secure crypto processor, which is a dedicated SOC (System On a Chip) for carrying out cryptographic operations, embedded in a packaging with multiple built-in isolation measures. The keys or secrets required by the defined cryptographic functions are physically implanted or locked within the device, usable through carefully designed interfaces or protocols but not retrievable or copyable from the device.

This picture outlines the latest Apple's SEP (Secure Enclave coprocessor), with its own on-chip resources such as ROM and crypto logic. The interfaces for entering into the SEP are meticulously guarded on the input side but allow liberal access on the output side for reaching the main processor resources. The most critical aspect of this design is to rigorously guard those keys or secrets stored within the SEP, typically enclosed in a tamper resistant packaging.

The above STM32/ST31 (Ledger Nano S) design is a cost-reduction design, in contrast with the sophisticated Apple SEP, with STM32 as the main processor and ST31 the low cost "SEP" which relies on STM32 for many crucial functions such as keypad input, output display and shared access to off-chip ROM/RAM. This "proxy" design has many serious defects. For instance, what is displayed on the device through STM32 is not necessarily what is produced or recognized by the SEP. The SEP may sign a crypto transaction of 100 Bitcoins, which is being displayed only as 2 for instance, an easy and standard phishing trick. The newer STM32/ST33 (Ledger Nano X) design has corrected a few defects of its predecessor, such as the IO of the ST33 which is now controlled directly by the secure element.

As it turns out, the adoption of a secure element in the hardware wallet design is also ill conceived. The most problematic requirement assumed by all hardware wallet designs is the common belief that any crypto wallet must provide the Recovery Seed to users explicitly in order to salvage the wallet when it is lost, damaged or stolen. Unfortunately, once the device allows the Recovery Seed to be retrieved and fed back to the wallet holder, the SEP design falls apart. If the secret or private keys are retrievable or directly reproducible from the device itself, there seems to be no reason to invoke the complexity of the SEP design at all. Recoverable SEP design is an oxymoron without gaining much functions. All the documented offline hackings on SEP-based hardware wallets stem from this design defect directly or indirectly. This is probably why the newer designs from popular vendors no longer rely on those SEP elements.

Since those SEPs on iPhone and Android phones are correctly designed and, therefore, the retrieval of recovery seed is not part of the bargain. This is probably why there hasn't been a decent wallet design using those correctly implemented SEPs on iPhone and Android phones, due to this lack of retrievability of the Recovery Seed.

Passphrases

Protection thru Passphrases

By now the uneasy thought niggling at the back of your mind all along might have taken root. Secrets are virtual, intangible, and inherently precarious when committing them to any hardware or software, be it cloud storage, encrypted files or those fancy secure enclaves. They are intensely individualistic and ought to remain as something best not to be outsourced. They are fundamentally cerebral or psychical. Forcing them onto any software or hardware apparatus is usually a compromise or dicey preposition.

Attacks on hardware and software wallets are remarkably commonplace. There is no reason to expect them to stop anytime soon. The original excitement around Secure Element/Enclave has all but dissipated, mostly due to the fundamental incompatibility between keeping all private keys in the Enclave and the unavoidable requirement to export the Recovery Seed from the Enclave, that unfortunately violates the central tenet of the Secure Element/Enclave.

The dominating hardware wallet vendors Trezor and Ledger both recognize the fact "no hardware is 100% safe", not to mention other critical benefits obtainable only through software means such as flexibility, deployability, redundancy, consensus building and elimination of SPOF (Single Points Of Failure). The suggested remedy is to introduce the concept of passphrase as quoted above. Instead of blindly trusting the hardware, with or without involving the instrumentation of Secure Element/Enclave, the passphrases allow the users to protect their secrets by creating, remembering and filling in a phrase privately and secretly to lock in their private keys. Once stripped off the illusion of Secure Element/Enclave, there is no reason to run the wallet on a piece of dedicated hardware at all. The construct of passphrases appears to match the concept of secret more cogently.

The hardware vendors suggest combining user passphrases with the base Recovery Seed in order to add an additional factor in protecting the new improved Recovery Seed. This scheme pretty much makes the SEP irrelevant. A clean environment (such as a "live" Linux) coupled with passphrases, sans SEP, would suffice.

The second part of this series describes a highly effective secret preserving construct, the Ai-Fi Crypton, which challenges the simplistic concept of wallets, recovery seeds and issues regarding their protection. It appears that there is no escape from maintaining our own critical secrets ourselves. This conclusion is comically tautological. Some people have unrealistic expectations on the possibility of biometrics in safekeeping our secrets, which is applicable only to the outsourcing arrangement. Fortunately, it doesn't take much to strengthen our memorization skill, which is a lost art and some simple mental exercise will quickly recover it.

Additional Materials

More materials on how to be your own bankers:

Part II: Preserving Secrets

Part III: Ai-Fi Counterseal Wallet