Secrets in Plain Sight

Secrets in Plain SightThe Ai-Fi Incognito CloudAi-Fi Krypton Token TypesCloud Storage and Metadata The Account-less Ai-Fi ChallengesThe Ai-Fi Krypton TokensKrypton Token TypesManaging Portable TokensAi-Fi Cloud Privacy GuaranteeTokenization of Ai-Fi Cloud StorageSummary of Security PropertiesBIP-38Private Log for Krypton Token OperationsKrypton LogsTerms of ServiceProtecting Your TokensThe Care of Your Krypton TokensAi-Fi Bug Bounty for Krypton TokensDictionary or Rainbow Table Attacks Online vs. Offline AttacksThe SuperLockWallet Protection MechanismsGeneralOnline WalletsOffline WalletsProtection of Wallet PassphraseMobile App Hacks

The Ai-Fi Incognito Cloud

Among all its no-nonsense advises and lines of thought, brax.me advocates the adoption of the public Cloud Services for convenience and, most importantly, safety. It agrees with just about all IT experts in the recognition that the advent of cloud computing will continue to march forward and take over the bulk of our computing requirements. There is a strong parallel between our money management relying on the banks and financial institutions, and the management of our digital assets outsourced to cloud services. However, although we don't hide our monies under our mattress any more (taking advantage of their "fungibility"), cloud services still offer no counterpart to the anonymous safe deposit boxes in a bank vault. All cloud services are account based, which pretty much rules out the offering of anonymous services.

Our Ai-Fi Incognito Cloud is laying the first stone in advancing the cloud services to include privacy protection by taking advantage of our "account-less" architecture in combination with a decentralized digital asset registry based on the latest blockchain technology.

Ai-Fi Krypton Token Types

Ai-Fi Krypton Tokens are a file storage type supported by the Ai-Fi Incognito Cloud. They take advantage of the account-less pseudonymity afforded by Ai-Fi.net. They facilitate a novel cloud storage technology wherein the content, ownership, and all metadata pertaining to the tokenized data are shielded and untraceable.

Cloud Storage and Metadata

The picture above is how we perceive our files stored in a public "cloud" traditionally. We first sign up to a service provider (AWS, Azure, Dropbox, etc.) for a subscriber account and then we submit our data and files to the service provider for varied levels of services under our account. We may also encrypt the content in order to prevent other unsavory characters, including even the service providers themselves, from peeking into our files. We typically share with the cloud providers our "metadata", namely the ownership, account identity, and time-stamped operations applied to those files, etc.

Invariably, files in the cloud are labeled and attributed to identifiable parties. Data theft in many cloud services are common occurrences. Many data breaches, including Dropbox concerning encrypted passwords and details of around two-thirds of cloud providers' customers, have been reported frequently. In addition to the threat of exposing one's file content, oftentimes the metadata associated to cloud storages may also subject to attacks. The risk of losing office files in the cloud or leaking file content is sometimes manageable, especially when business owners by and large follow reasonably stringent data protection practices, oftentimes mandated by regulations, and backs up them periodically as a matter of course. However, in the case of high-value personal assets, the loss event or even the exposure of owners' identity may not be acceptable. Such is the case for Bitcoin assets, even the metadata of which is highly guarded in order to maintain the anonymity of Bitcoin transactions. Unfortunately, this protection of metadata for personal digital assets is not always guaranteed.

The Account-less Ai-Fi Challenges

Traditional service providers require your signing up for an account for the purpose of either collecting payments or conducting surveillance on private data to feed its business model.

In the case of Ai-Fi.net, since there is no "account" required for a user to interface with Ai-Fi services, it is difficult for hackers (or even the provider itself) to target at any one individual. Even in the unlikely event that a file stored with the Ai-Fi Incognito Cloud is cracked, there is nothing in the encrypted content that would lead back to the originating owner. This is why the attack on Ai-Fi facilities involves the most arduous of conditions without any specific targets to aim at.

To further take advantage of this hallmark feature of account-less services, Ai-Fi.net serves any file storage requests without knowing the people behind them. This is a much more strict requirement than any other popular cloud storage services. By design, Ai-Fi eliminates even the services itself from being a suspect when compromises are discovered. Ai-Fi.net simply is not capable of recognizing any owners behind those files and data stored in its cloud. With strong encryption, enforced with crypto key pairs of high entropy, all files in Ai-Fi Incognito Cloud look alike without specific registered accounts to attribute to.

The Ai-Fi Krypton Tokens

Krypton (from Ancient Greek: κρυπτός, romanized: kryptos "the hidden one") is a chemical element ... a colorless, odorless, tasteless noble gas that occurs in trace amounts in the atmosphere.

- Wikipedia

The Krypton Token represents an Ai-Fi storage type, taking advantage of the pseudonymity offered by the account-less Ai-Fi storage services. (There are many other Ai-Fi Cloud applications in the works, all tempting to take advantage of the same pseudonymity built into the Ai-Fi Incognito Cloud.) Behind the Krypton Token is a text file (currently supported file type), which are typically segmented by labels for different sub-contents.

A Portable Krypton Token has only 2 fields that determine how it is stored:

Quite a bit of flexibility is given to the setting of Entropy Salt. Our users may adopt a simple email address to thwart the dictionary attacks, or opt for a set of random bits to increase the entropy, in which case the salt may need be written down. Some users apply for a brand new email address for this express purpose of secrecy without resorting to their usual primary email address used daily. The selection of Entropy Salt should be commensurate with usability consideration and the value of the contents to be protected.

A Krypton Token is produced from the public key of a cryptographic key pair. To the storage server, the public key or token appears as a random sequence of 256 bits (with some housekeeping characters), which has similar, and optionally higher, cryptographic strength as the Bitcoin addresses. Users submit the token (with payment as per situation) in order to store or retrieve the associated content, which is decryptable only by having the private key of the originating key pair. The Krypton Tokens are usually submitted through the Tor anonymity network along with their associated files to further obscure their original sources and make it difficult to guess their owner based on any kind of heuristics.

To take an example, say your file or data is packaged and encrypted with a key pair, of which the public key becomes the token ID: "GA5WNW6RGHQNNXICILLYDMEYO6NLATJP2C7WAHTGQFVGYQXLSLSAF46C". The challenge to any adversary trying to hack the content of this token is to render the matching private key, which is proven mathematically intractable. The Ai-Fi Krypton Tokens have the added advantage of not requiring the publication of the public key (or the token ID). This may be contrasted with the privacy issues of Bitcoin addresses, which are inherently public as they are designed to conduct transactions involving multiple parties, whereas the Ai-Fi Krypton Tokens are private and stay stealth. Short of obtaining the list of all existing token IDs, the entropy for the combination of the key pairs and the hidden ID space of all the tokens afford us at least 120 bits of entropy. For this reason, Ai-Fi Incognito Cloud takes pains not to reveal the list of token IDs under its care. This protection of the token IDs through obscurity, built as an independent architectural layer above the public key infrastructure, enhances the resilience and security of the Ai-Fi cloud services for Krypton Tokens.

Krypton Token Types

There are primarily two types of Ai-Fi Krypton Tokens:

  1. Hosted Tokens: This is the token type based on the public key of ED25519 keypairs. A token name is mapped and hashed from a pubic key of around 160 bits of entropy (similar to the "unspent" Bitcoin account). The original keypairs for this class of hosted tokens are dedicated for this purpose and maintained in the Ai-Fi Wallet without involving in any other cryptocurrency transactions (unspent). The DigiVault offered in Ai-Fi Central, if opted to "Auto-Sync", will be entered into the Incognito Cloud as a Hosted Token. The collection of SecureEmail keys is also stored as hosted token if opt-in is enabled. Hosted Tokens live and die with their associated wallet.
  2. Portable Tokens: Unlike the hosted tokens described above, which can be deleted or become inaccessible, Portable Tokens are based on passphrases, which are to be memorized, with optionally the (client-side) Entropy Salt for both thwarting the rainbow-table/dictionary attack and increasing the entropy. This Entropy Salt may be set as weak as the email address, cell#, ssn#, etc. for creating trivial variability or as something fully random and unique, to be automatically generated by the app. The portable token is independent from your wallet and retrievable outside of your Ai-Fi Central App as long as the passphrase and salt are precisely tendered. This concept of token is originally inspired by the MiniLock scheme and has at least 100 bits of entropy without counting the extra randomness injected into the salt. The user is not expected to memorize the salt, which may be jotted down on a piece of paper or in a notebook and rely on the physical security to attain reasonable degree of protection.

The Ai-Fi Incognito Cloud of Krypton Tokens may be visualized as a herd of anonymous animals, each individually camouflaged and largely indistinguishable to the hackers. Most animals are seemingly wild, nameless and owner-less with mysterious origination. There is a large number of Krypton Tokens randomly distributed in the Ai-Fi Incognito Cloud like those inscrutable animals in the herd:

The following picture offers another perspective on the protection scheme for Krypton Tokens:

In order to open a lock, even in possession of the correct key (through stealing or other means), one needs to first locate the target lock, which appears as inconspicuous as any others amongst all those openly displayed on the Love Lock bridge. Absent of any metadata, the only option left for attackers is to brute-force through the complete "search space".

The Ai-Fi Incognito Cloud is implemented through a key-value store with configurable redundancy options behind a dedicated firewall.

The Ai-Fi.net Incognito Cloud only sees the token ID submitted as a storage request for entering into the Ai-Fi Cloud. It sees neither the "salt" nor any ties to any identifiable users or email addresses. This is why the portable Krypton Tokens are popular among Ai-Fi users for safekeeping their seed passphrases for various types of crypto wallets. It is customizable to the desired level of security and made stronger than any Bitcoin addresses but with elevated anonymity guarantee.

Managing Portable Tokens

Each portable token generated based on a unique passphrase. With 100 bits of entropy, it is practically untraceable and untrackable.

Specifically, an anonymous Ai-Fi user submits a request for storing a token file in Ai-Fi's cloud with the following information:

  1. A passphrase for controlling the access of the submitted file: A minimal strength of 100-bit entropy is measured and enforced. Insufficient level of strength is not allowed.
  2. An Entropy Salt is used for "salting" the generation of key pairs for protecting your files as a partial measure against dictionary attacks. It is scrambled/hashed prior to becoming part of the file identifier, on the client side, without leaking it to even Ai-Fi.net. The salt may be a simple string, something unique to your identity (email, SSN, cell #, etc.), the individual nature of this salt strengthens Ai-Fi protection against offline dictionary/rainbow-table attacks. You can also ask for an automatically generated random string that injects many bits of entropy. As the name "salt" implies, unlike the highly confidential nature of the passphrase, it can be written down without much concerns for its loss.
  3. Label: This is a reminder for yourself and is part of the file content, which is not visible externally.
  4. The file content is encrypted securely by taking advantage of the availability of your public/private key pairs, which is the composite of your passphrase with the email address as the salt.

The information provided will be combined and scrambled through a rigorous key derivation function (Script or Argon2d, with a large number of hash rounds) to generate a PKI key pair, which in turns mapped to a file name and a content encryption key. Take a look of the following examples:

These two tokens appear totally different even with the same passphrase but different salts (email addresses). It is nearly impossible to uncover the original passphrases and email addresses of around 100 bits of entropy. It is even more difficult to track down the owner of the file.

The request is submitted to the Ai-Fi Cloud through an end-to-end TLS session. The service charges are paid through one of the pseudonymous accounts from the requester's wallet. The stored files will be kept securely and anonymously in the Ai-Fi cloud as long as the payments are kept up (from anyone able to identify the file and authenticate themselves by submitting the correct passphrase hash). The only way to retrieve the file is to render a proof of your possession of the corresponding private key through your passphrase and salt, which is not stored anywhere and generated every time when needed through your passphrase.

Ai-Fi Cloud Privacy Guarantee

Tokenization of Ai-Fi Cloud Storage

To answer the challenges of inbuilt anonymity, Ai-Fi Incognito Cloud as a storage service reinvents the cloud as a tokenized file access facility, which has a lot of similarity in its pseudonymity handling to that of Bitcoin. Bitcoin adopts the scheme of cryptographic key pairs for conducting Bitcoin transactions on the Bitcoin Blockchain. Only the public key is made public and the demonstrated possession of the private key is the only proof of ownership. To conduct any Bitcoin transactions, the public key as a token is first presented to identify the Bitcoin "account" (which is not tied to any PII, or the Personally Identifiable Information), followed by the demonstration of ownership of the private key, which authenticates the Bitcoin account and authorizes the transactions. The cost of service is charged to the involved Bitcoin accounts (addresses) directly or indirectly without involving any real person (or PII).

In the case of Krypton Tokens, Ai-Fi Cloud elevates the privacy protection a step further. Any token storage operations are between the owner of the tokens and the Ai-Fi Incognito Cloud, without the need for a publicly viewable blockchain for recording transactions involving multiple parties.

Summary of Security Properties

  1. No need to publish the file name (or "public" key), as tokens are not designed to be shared or transacted (which may change under different application scenarios). Unlike the "spent bitcoin accounts" that cost 32 bits reduction of entropy for conducting Bitcoin transactions, Krypton tokens may utilize the whole 100 bits of entropy.
  2. Since Krypton Tokens are designed primarily as keys to high-value file contents and seldom needed in real time, they may be reinforced by additional entropy through "client salt", which is a string of random bits that may be copied and stored offline. The secret passphrase is the last line of defense and therefore needs to be memorized, whereas its accompanied "client salt" needs not be. It is suggested to write it down to a notebook or lock it away in a drawer and rely on the physical security of their premises to prevent its theft.
  3. The Ai-Fi Incognito Cloud only provides storage space for submitted Krypton Tokens and not a publication service for file exchange. A token is retrievable from the collection of all tokens only if the correct key pair is presented. Even if the Ai-Fi Incognito Cloud is compromised, losing all the token files as a consequence, there is no way to tie a specific file to any individuals. This further increases the entropy of the Krypton Token scheme based on the number of token files as the control parameter. For around 1 million file, we increase the entropy 20 bits.
  4. The entropy of the Krypton Token scheme may be summed up by 100 + entropy(salt) + entropy(file collection), or 248 bits with 16 bytes of random salt and 1 million token files, stronger even than the unspent Bitcoin addresses (160), with both the random salt and the number of token files tunable to manage the entropy. The users may adjust their selection of salt to strike a balance between the convenience and high entropy, calibrated based on the security requirement of the contents to be protected.
  5. All the entropy calculations above presume the feasibility of offline attack, which is not a hurdle for hacking Bitcoin accounts as all materials for hacking (brute force) are publicly available on the blockchain. In contrast, for conducting offline attacks on any Krypton token, the hacker must first obtain or steal the catalog of all token files from the Ai-Fi Incognito Cloud. Since the logic for managing Krypton tokens is extremely simple, the Ai-Fi Incognito Cloud is not likely to be compromised easily. Even if the Krypton token database is compromised, there will still be 164 bits of entropy to contend with, tougher than attacking any Bitcoin accounts. Furthermore, for targeted attack, if the hacker successfully invaded the home of a high value individual and got hold of their salt, he will still be struggling with 100 bits of entropy, on a par with the effort required to crack a miniLock. I hope you are convinced that Ai-Fi Krypton Tokens are the opposite of low-hanging fruits.

BIP-38

BIP38 is a standard process to encrypt Bitcoin and crypto currency private keys that is less susceptible to brute force attacks thus protecting the user. There are a few issues with this scheme:

  1. The entropy of the private key is reduced to that of the password if there is any chance in memorizing it. The minimum strength of the password is not suggested or enforced. It may be prone to dictionary/rainbow-table attacks.
  2. It is a hassle to figure out where to store the encrypted private key. If it is written down on a sheet of paper, the physical damage to the paper would be a likely hazard. If it is kept on a PC, then the issue of backup and redundancy must be considered.

The Portable Krypton Tokens may be considered an improvement over BIP-38, especially for issue 2 above if users opt for Filecoin decentralized storage as the repository. For issue 1, users may determine their own acceptable risk exposure and customize their parameters accordingly. The Ai-Fi Superlock mechanism offers additional options in protecting your password or private keys.

Private Log for Krypton Token Operations

(The content of this section has been deprecated. Ai-Fi will rely on third-party storage services such as Filecoin for token repositories.)

Krypton Logs

Although a token operation is paid via a specific cryptocurrency, the token transaction itself is not recorded on its associated payment blockchain to ensure the anonymity of the service request. The integrity of the token operations and the service guarantee is provided by getting a transaction receipt from the Ai-Fi cloud service per submitted request and a private auditing mechanism to be conducted by users themselves.

Ai-Fi Incognito Cloud Service maintains an append-only log file containing all the request/response status logs. When a user requests for a token service, at the completion of fulfilling the request a receipt is returned to indicate the successful operation of the request and prove the Ai-Fi's possession of the submitted token file if the operation is a Create or Write. The receipt describes the corresponding entry created in the log in response to the request.

Terms of Service

Although there are some metadata embedded in the receipt or the descriptor of the Krypton transaction, they are not stored anywhere within the Ai-Fi Incognito Cloud as part of the Terms of Service for Krypton Token Storage Services, explicitly committed to by Ai-Fi as a service provider. In substitution for a publicly viewable blockchain, the Krypton Token Root Log is open for inquiry by anyone when the log serial# (or the "Next" after the cursor) and a nominal payment for the service charges are presented. This allows the owner of the token to conduct auditing on the integrity of the log. For non-owners, the descriptor on the log is not penetrable without the background and transaction details which are privy only to their original owners once committed to the log.

The private token log does not store any Token IDs, only their hashes, which reduces the entropy of the protection scheme if leaked out.

The receipt or the descriptor of a token transaction is the contractual claim to a token file. If it is not found, Ai-Fi cloud service must render a different receipt with newer timestamp to counter the claim, or be responsible for the loss of token file. The owner of the token may also discover any illicit activities launched against the token.

Protecting Your Tokens

To help evaluate the security quality of various Ai-Fi Krypton Tokens, we list a few of their characteristics below, incorporating the Bitcoin in the comparison:

The Care of Your Krypton Tokens

Due to their anonymity, Ai-Fi.net is not able to attribute ownership of tokens to their originating parties or serve notification of any kind of activities or events occurred. To guarantee the highest level of recoverability of their posted tokens, an Ai-Fi users may adopt a combination of the following strategies:

Ai-Fi Bug Bounty for Krypton Tokens

Ai-Fi Krypton Tokens are a novel idea. Although the implementation is straightforward, Ai-Fi users need a bit of push to start adopting them. For encouraging their adoption and convincing their reliability, a bug bounty program is launched with details here.

Dictionary or Rainbow Table Attacks

Once the files or their metadata are stolen, offline dictionary attacks and Rainbow Table (pre-computed hash table) attacks are effective means of hacking for passwords in order to steal their content. Password hackings are based on the observation that people are experiencing difficulties in choosing their passwords or file names and tend to select texts easy to memorize. Oftentimes passwords are simply words straight out of a dictionary or some variations of those from the dictionary. As most of the cloud storages are indexed under account identifiers, the loss of passwords or their equivalents can be disastrous. Successful password hacking attacks are commonplace and we are increasingly concerned about the potential compromises on password-based account access to our cloud resources.

A typical safeguard against dictionary attacks is to incorporate a random salt into the password hashes. The randomness and uniqueness of the salt is critical to ward off some parallel schemes of offline hacking into a large collection of passwords. Random salts are effective means to multiplex a standard hashing scheme into a large hash mapping space, which makes pre-computation of hashes impractical.

Online vs. Offline Attacks

Online password attacks are difficult to pull off, as the number of tries is limited. Offline attacks are much more effective when the hackers manage to get access to a large collection of passwords by hacking into the authentication servers where the passwords or their hashes are kept. This kind of attacks is becoming more prevalent as many of the established service providers (LinkedIn, Dropbox, Facebook, Twitter, etc.) have been compromised in many a situation.

The attack scenarios in password or credential cracking are almost always aimed at identifiable accounts, which are easily reconstructed based on simple triangulation scheme (DOB+Zip+Sex, typically). A successful password cracking would spell disaster for the account after opening up a target account with access to any information or funds stored within under the account identifier.

The SuperLock

All your cloud storages and other valuable Ai-Fi assets are protected based on the many key pairs in your Ai-Fi Wallet. To guard against the possible loss of your mobile phone where your wallet resides, we suggest the setup of an Ai-Fi SuperLock, which split any text string that requires the most strict protection into multiple parts or shares. To unlock the original secret string requires a majority of parts or shares working jointly. It is fail-safe against any single-point failure. The property of anonymity of Ai-Fi Incognito Cloud described here is a handy option for storing one of the key shares without the concern of losing or exposing the key. Once entered into the Ai-Fi Incognito Cloud as a protected token, no one is able to relate the stored key share with your the owner.

A SuperLock involves at least 3 key shares, some of which may require your memorization. For your protection against accidental memory lapses, there is an option to schedule a periodic reminder for "rehearsing" your SuperLock recovery process on the phone where the SuperLock is hosted.

During the scheduled SuperLock recovery rehearsing, if any one of the shares failed to respond correctly, the entire SuperLock must be reset in order to recover from that unexpected failure.

Wallet Protection Mechanisms

General

There is a lot of misinformation around regarding the protection of crypto wallets. Most of the hardware wallets are only feel-good solutions if we examine their security issues carefully and logically:

  1. To achieve ideal protection, the wallet software and the destination crypto-transaction server must be secured end to end. In the case that the wallet software runs on a mobile phone (Android or iPhone), the following must all function correctly:

    • the application sandboxing mechanism on the phone
    • the hardware protection or secure enclave of the cryptographic keys
    • the end-to-end network transport secrecy
  2. All hardware or cold wallets (Ledger/Trezor and the like) add one extra network hop to the end-to-end connectivity without necessarily enhancing any of the required functions list above. Worst yet, it adds extra vurability to hacking.

  3. As most hardware wallets are difficult and prone to errors in their upgrades, and their wallets generally are not in lockstep with the latest cryptocurrency technologies, oftentimes they rely on a secondary software "client" running on a separate and more popular platforms such as iPhone or Android. In that case, all security and reliability considerations are weakened due to the extra network hops and additional endpoints that may fail. An extra piece of hardware is not necessarily a plus, and worse yet, it may turn out to be a liability. One of the well documented vulnerability is reported here. This is not to mention the counterfeit problem, or the hardware equivalent of trojan horse or virus:

    When it comes to hardware supremacy and accumulated experience against attacks, I'd place my bet on Apple's secure enclave or Google's equivalent.

  4. Any standalone hardware is vulnerable to so-called "Evil Maid Attack" by getting stolen, or simply losing it. Once the hardware is lost to a hacker, there is no shortage of offline attacks available to exploit the wallet. Even a-TPM fortified device is vulnerable.

  5. Some of the "air gap" implementations use visual aids to handle the inevitable passing of transaction information, such as QR code or other cut/paste variety. This sneaker net in 21st century doesn't accomplish much as the proxy software on the receiving end of the communication path are vulnerable to all the attacks with or without the "air gap".

  6. To follow the "end-to-end secrecy" doctrine, it is actually more lucrative to strengthen a reliable end point on the server side of the connectivity, namely the acquisition and administration of a Bitcoin Core node without relying on any other third party or Bitcoin exchanges. Ai-Fi's HomeCloud may actually serve as the Bitcoin Core node (see the Ai-Fi Roadmap).

The cardinal rule of Internet security dictates simplicity, which encourges shorter communication path or network hops, and fortification of the weakest link. All those hardware wallets on the market violate a few of those commonsensical practices. The primitive nature of their UI is also less than helpful in carrying out straightforward data entry on a miniature device.

Granted, the "Secure Enclave" hardware in iPhone has not been fully utilized for the moment. The mobile wallets taking full advantage of the Secure Enclave should appear on the market soon. Ai-Fi.net has also laid out on its roadmap an Ai-Fi hardware wallet on the same device as its private Bitcoin Core server (on a closed device, but running open-sourced software, residing on the Home Server behind the firewall as depicted below) without involving any network hops. It has all the advantage of hardware wallet and eliminates all the MITM (Man In The Middle) attack surfaces with the added convenience of graphical UI and input devices we all have grown used to.

 

Online Wallets

Solutions vs AttacksSoftware WalletsLedger/TrezorSandboxed WalletsAi-Fi Wallet
browser extension -hacksXVVV
mobile app hacksXVVV
Theft, detectableXX *1VV
Hacking, onlineXV *2XX
Theft, shoulder surferingXXXX
Fire/Flood/ShockXXXX

*1 Those hardware wallets like Legers and Trezors reduce substantially their online exposure. However, as any physical devices, they've created a new complication in their physical protection. Not all their owners would carry them in their pockets at all times. Like hot potatoes, the self-inflicted issues of safekeeping and speedy detection of any loss event are troublesome to say the least. In the event of a loss, the GPS tracking and "remote wipe" options are not available either.

*2 As long as it must be hooked up, regardless how brief it is, in theory the exposure to online hacking, including their proxies, is unavoidable.

Offline Wallets

A popular practice of cryptocurrency protection is to employ multiple wallets and keep most of the assets offline until the need arises. As all the public/private key pairs of a wallet are recoverable from its seed passphrase, with the content of individual account addresses publicly recorded on various blockchains, the offline wallets are functionally equivalent to their seed passphrases. Hence, managing and protecting the offline wallets is equivalent to the task of safekeeping those seed passphrases.

Solutions vs AttacksPaper RecordsMetal Seed StoragesPassword ManagersAi-Fi SuperLock
Fire/Water/ShockX   
browser extension hacks  X 
mobile app hacks  X 
Theft, detectableX  
Theft, shoulder surfingXXXX
Redundancy XX 

Protection of Wallet Passphrase

Regardless how well the wallets are protected, there is always the "cryptographic hot potato" issue to grapple with, namely how the seed passphrase is to be protected. On this issue of passphrase protection, the general tendency is to safekeep it offline, on a sheet of paper, in a notebook, with the above Billfodl, and many other options away from any linkage with the Internet. The general mindset is to rely on (offline) the physical security for safety when a large amount of monies are at stake. This preference is almost visceral in its appeal. However, regarding the daily trading volume of Bitcoin, around $10B, all of the transactions rely solely on the cryptographical strength of the Bitcoin key pairs. It is not logical to avoid any online solutions for maintaining your own seed passphrases.

 

Mobile App Hacks

Assuming the installation of an mobile application is sound, any attempt of hacking into the app must penetrate the sandbox built into the hardware platforms. The sandboxing for mobile devices on Apple iOS or Google Android platforms is the most technologically sophisticated around, much stronger than, say, Windows or other PCs. Those dedicated hardware wallets such as Ledger Nano, Trezor, and the like, only substitute physical security for online soft protections and often lose critical usability in the process, albeit exposing a smaller attack surface. Those hardware wallets offer no protection to the recovery/seed passphrases and their conspicuous presence attracts unwanted attentions.