Preserving Secrets

This is Part II of a three-part series. After reviewing many wallet implementations in Part I, we are convinced that "secrets" in wallets are virtual, intangible, and inherently unsafe when fastened to any specific hardware or software apparatus. Secret passphrase of sufficient entropy reliably committed to our memory is the preferred approach to safeguard our secrets. The wallet industry seems to have started to converge on this passphrase-based design.

Instead of jumping directly into the actual implementation of Counterseal Wallet, we'd like to dig deeper into a specific scheme on how our secrets can be safely and anonymously protected by a construct called Cryptons. Taking responsibility for managing our own personal secrets is the first step in preserving our privacy and financial wellbeing in the upcoming trustless and decentralized cyber reality. Cryptons are simple, reliable, configurable and most notably trustless.

Feel free to jump directly to Part III on the actual implementation of Counterseal Wallet and return here later when you want to learn more about it.

Part I: Crypto Wallets

Part III: Ai-Fi Counterseal Wallet

Hidden in Plain Sight

Introduction

It doesn't take a genius to recommend that when adopted the selected secret passphrase must be long and strong to adequately protect your crucial secret. The tough question is how to memorize those strong but long passphrases. It is commonly recognized that our "memory muscle" is grossly under-developed and underutilized. Most of us since childhood have not grown much in improving our ability to memorize words, digits, cards and other random symbols. There are many proven techniques and exercises which may be adopted to strengthen our memory muscle and to help recall our passphrases. However, even if we invest time and effort in strengthening it, the manageable passphrase tops out at around 100 bits of entropy strength.

In this Part II of the series we will lay the foundation of secret keeping by introducing the Cryptons, which can safely generate strong keys based on memorizable passphrases with the additional instrumentation of "Entropy Extender" to elevate their entropy to any required strength. The configurable strength meter and access auditability, serviced by a trustless Incognito cloud, will lay the groundwork for an integrated wallet architecture with minimal exposure to attacks.

We will also offer a tool set to help exercise and recall your passphrases.

The Separation of Powers

A large part of the vulnerabilities and SPOFs built into almost all crypto wallets stems from the fact that the involved secrets are too numerous and too long to commit to memory. Not able to be easily and securely stored, those secrets become cryptographical hot potatoes, not only embedded within the wallet itself but also encoded into the recovery seeds requiring two separate vaults and doubling the attack surfaces in the process.

However, let's assume for a moment that a mechanism could be found that stores and retrieves those secrets on demand, we would then be able to peel off the secrets (key materials) from the logic that signs the crypto transactions, in which case the wallet becomes a code-only "live" set of logic containing no secrets while the secrets are kept in another secured place (brain) to be retrieved as a secured token. It is attackable only while they are briefly enabled to sign the transactions based on the dynamically loaded secrets. The crypto transactions could be cleanly carried out in a single thread: download the code, verify the constant code-checksum, abracadabra the key materials, sign, update the key materials and wallet context, clear the key materials, and finally exit.

This mechanism of Crypton, separating secrets from code, is our way to realize this clean approach. It is based on the insight that we don't need to commit the whole key length to memory. We just need to maintain the abracadabra passphrase in manageable length, say, around 70 bits of entropy, and leave the remaining 50 or more bits as "extenders" protected by a separate mechanism to get a total of over 120 bits of entropy. This passphrase plus its extender provides the key materials for a base key pair which in turn protects the whole stash of secrets including the recovery seed and the context of the wallet operations.

The shorter version of BIP39 recovery seed of 12 words is 128 bits in entropy. Realistically, even this 12-word mnemonic is about 268 million times exceeding our capacity of reliable memory in dealing with symbols, which is at most 100 bits. It is perfectly sensible to only memorize a substantial portion of the key, say, around 67-bit entropy that would cost over $1B in the year 2030 dollars to crack, and leave the rest in "paper vault" or written down functioning as an "entropy extender", which does not need to be protected as rigorously as the memorized passphrase. A Post-it note in the secure confine of your home recording the entropy extender may be perfectly acceptable as long as you are confident your abracadabra passphrase is in the right place (read: brain).

Cryptons

In this section we will get into the details on how the base key pair is to be derived. The PKI (Public Key Infrastructure) as the cornerstone of the cryptographic technology may be explained roughly as below:

In cryptocurrencies, the encoded Public Keys are published on the blockchain as the crypto addresses representing and protecting their associated crypto assets. In the context of Ai-Fi Counterseal Wallet, the base key pair created as a Crypton protects the secrets and contexts associated with the wallet. The secret content of the Crypton is usually encoded text strings collected and stored in a blob opaque to the Crypton mechanism. The secrets protected by Cryptons are as secure and indestructible as those key-pair-protected Bitcoin accounts on the blockchain as long as the private keys of the Cryptons are not compromised.

The passphrase is the syntactic sugar designed to help memorize those long private keys.

The Crypton is partially based on a prior technology by the name of Minilock, which is fairly well documented, to create a passphrase-based authentication mechanism with key derivation logic based on Scrypt. It is offered as an alternative authentication tool to PGP, with the obvious application in the creation of a key pair in order to produce an identity certificate. The entropy of the construct is limited by the "memorizability" of the passphrase, which has an upper bound around 100-bit of entropy. Its entropy strength in Minilock is not expandable as it is designed to be a convenient and "portable" form of key pairs to be retrieved from memory. On the other hand, the Crypton scheme is not aimed to only create a memorizable passphrase for identifying or authenticating users themselves. It is offered as the method of creating a key pair of arbitrary entropy bits, comprising a passphrase of defined entropy strength, memorizable as the critical part of the keys and then complemented by an Entropy Extender for extra strength in generating the final key pair. The public keys created become the main part of the file/Crypton identification string for storing secrets or any contents associated with the Crypton. The retrieval of the content requires proof of ownership by demonstrating the possession of the matching private key through, say, some standard challenge-response protocol.

Part of the "Crypton" functionality are also described in a separate document, which mainly focuses on applying the mechanism through a cloud service (Ai-Fi Incognito Cloud). Its applicability extends to other storage arrangements other than the cloud as well, such as storing the Cryptons to users' PC, disks, USB thumb drive, SD card (e.g. on Raspberry Pi) mobile platforms, or even IPFS externally. Much like the Bitcoin addresses and their public-private key pairs that protect the Bitcoin users' crypto assets, the placement of those Cryptons are highly flexible without affecting their cryptographic strength. In the case of storing Cryptons in the Ai-Fi Incognito Cloud, which is password-less and account-less with the requests submitted through Tor pseudonymously, the Cryptons are not directly discoverable or targetable, by even the Ai-Fi.net as the cloud provider, which thwarts all targeted attacks because there is no cue available to confirm the success or failure of any guessed password and Entropy Extender. Since the Cryptons are solely designed for protecting personal secret, unlike those Bitcoin addresses which are tied to key pairs involved in crypto transactions, they are strictly private without the need to publish them in any public ledgers. This makes it possible to hide them in an incognito cloud (password-less and account-less). The "personal" nature of this secret storage method implies that a Crypton may be committed to and owned by a single user privately. However, it doesn't rule out other possibilities of utilizing this construct for administrative purposes in shared settings for effecting teamwork.

The content or the protected secret is encrypted by a symmetric encryption key which is "negotiated" (self contained) by an ECDHE scheme with the ephemeral public key attached unencrypted in the Crypton itself, which can be combined with the Crypton private key to decrypt the protected content.

The generation of the key pair for a Crypton is depicted below, with the Curve25519 key pair as part of the example construction. Other embodiments of any key pair schemes or standards under the PKI framework can be similarly constructed for any key length.

This method starts at 3, where the user is invited to enter a passphrase which is delivered to an evaluator at 4 through path 13. The evaluator 4 evaluates the entropy strength based on a configured strength requirement (100+ bits in the example drawing) with an adopted strength meter. The open source "zxcvbn" is a well known entropy meter in the public domain. If the entered passphrase failed to pass the strength evaluation, the user is sent through 14 and 15 to retry the data entry for a passphrase of sufficient strength. An automatically generated passphrase of sufficient strength may be requested in 5.

The user exits the evaluation loop at 16 only when a passphrase of sufficient strength passes the evaluation. The user augments and appends their passphrase with additional entropy source with many possibilities, such as personal email address, additional word list, arbitrary text strings or have the software suggest a random string of specified entropy. The original Minilock scheme is to create a passphrase-based authentication mechanism with key derivation logic through Scrypt. Its obvious application is the construction of a key pair as part of an identity certificate. The entropy of the Minilock construct is limited by the memorizability of the passphrase, as the first passphrase in steps 13, 14, 15 has satisfied that requirement. Entropy Extender is not considered.

The entropy string created in 7 may be separately protected. It may be written down and stashed away in notebooks or over multiple locations. It may also be safeguarded by some secret sharing scheme like the Shamir's Secret Sharing. It may even be stored in another Crypton, as it is just a text string that complements the base passphrase. When both combined it creates a multi-factor protection. It is suggested to have at least 90 bits of entropy sealed into this extender.

Once the complete passphrase and its entropy extender are formed satisfactorily, the logic moves on to the key derivation, which adopts Argon2 presently, with Curve25519 key pairs generated in the last phase 9.

To summarize, the Crypton is "personal" in the sense that a passphrase is required and to be provided by individuals when requested. This suggested "personal" involvement can serve as an important aspect of identity proof when the generated key pair is used for authentication purposes. It is extendable to arbitrary entropy strength by combining with the construct of Entropy Extender. This Entropy Extender, independent from the passphrase, may be separately stored, copied and managed (e.g. through Shamir Secret Sharing) without catastrophic fallout when compromised, since it does not constitute a single point of failure (unlike the recover seed in traditional wallet implementation). Note that the Entropy Extender, sometimes referred to as Entropy Salt, is not the same construct as the traditional cryptographic salt (on either client or server side) in the conventional account password setting for authenticating purposes. It is effectively part of the password/passphrase (Passphrase + Entropy Extender) and not to be publicly disclosed or shared with the server (unlike salt). Its designed function is to extend the cryptographic strength of the passphrase for creating the key pair and not used as a defense against dictionary or rainbow attacks. The goal is to break apart the key generation material into 2 separate components, each of which may be independently protected.

From Mnemonic to Seed

BIP-0039 also defines a passphrase construct that bears some similarities with that in Crypton, with the following notable differences:

1. BIP-0039 defines a process for deriving a binary seed from a mnemonic sentence, which has no minimum crypto strength requirement. The result of the PBKDF2 key generation is later used to generate deterministic wallets based on BIP-0032 and not used to generate an index for an encrypted file stored in an incognito cloud as in the case of Crypton, which is not necessarily tied to a crypto wallet. If Crypton is utilized to support deterministic wallets, the recovery seed is safeguarded by a single mechanism without creating two SPOFs in the traditional approach.
2. The passphrase in BIP-0039 needs not to be present. In that case the mnemonic sentence is the only element for safekeeping the seed. In the Crypton scheme, both the mnemonic passphrase and the Entropy Extender must be present and each must satisfy the minimal entropy strength that is measured and enforced. No empty string "" is allowed to either element.
3. Although the passphrase in BIP-0039 was originally defined to "protect" the mnemonic, there isn't any mechanism to figure out if an entered passphrase is correct or not due to the trustless nature of the blockchain technology. So, instead of using the passphrase as a verifier, the latest Trezor implementation, as an example, no longer uses it to protect but to index into different wallets. The only means to figure out if a passphrase is "correct" or not is to generate a few crypto account addresses and get on the blockchain to look for their respective transaction histories. Since transaction history is not part of the wallet implementation, the user can never be sure if a recovery seed is valid or not.

The Ai-Fi Incognito Cloud

The Crypton

As previously mentioned, a Crypton may be stored anywhere as long as the users are confident that its associated passphrase and Entropy Extender may be kept securely and correctly applied as part of the abracadabra act. Without the passphrase and the Entropy Extender, the Crypton is just a blob of bytes protected by at least 128 bits of entropy costing over $1B to crack in 2030 money.

The Ai-Fi Incognito Cloud

On the other hand, the users may take advantage of the Ai-Fi Incognito Cloud services for additional functions. The Crypton may be stored anonymously to the Ai-Fi Cloud with extended cloud storage functions such as redundancy, backup, and global retrievability. Taking advantage of the bulk storage and the aggregation of a large number of Cryptons, the Ai-Fi Incognito Cloud further hinders any targeted attacks by obstructing the focus of any attack aiming at a particular Crypton.

The anonymous nature of the service effectively rules out Ai-Fi the service provider of the Incognito Cloud, from any suspicion of being a bad actor in the service infrastructure. This is made possible due to the fact that Ai-Fi service infrastructure is purpose-built without relying on accounts or needing any "stinking badges".

Since it is account-less, there is no account database or password/salt records maintained per user. To launch an attack on Ai-Fi services, the attacker must aim at individual Cryptons. The dictionary or rainbow attack is infeasible as the dictionary is too large to construct due to the high entropy introduced by the Entropy Extender.

The requests made to Ai-Fi are through the untrackable Tor anonymity network. The service fees, if charged, are on a pay-as-you-go model without needing an account, accepting many different cryptocurrencies to address varied anonymity requirements.

Multi-Factor Authentication

Another magic happens when outsourcing your Cryptons to Ai-Fi Incognito Cloud: The creator of the Crypton may impose certain access rules such as:

1. Trigger a multi-factor approval process when the Crypton is later on being requested: This is realized by attaching an email address or some IM account at their creation.
2. Leave an audit trail when retrieved: The access to any Cryptons may leave an audit trail as an option of the service if requested. This is extremely useful when coupled with the redundancy supported by the Counterseal Wallets.

Clearly without redundancy the leaking of a single Crypton will ruin the whole wallet even with an audit trail. For instance, in the 2 out of 2 Threshold Signature configuration, both the primary and second Cryptons must be breached in order to compromise the integrity of the wallet. This turns the notification of an unidentified or unintended access to the first Crypton of the two into an effective early warning alarm mechanism.

The users may balance the usability of these Crypton access rules against the risks involved in selecting their preferred mechanism. The multi-factor approval process during transaction signing is obviously more intrusive, probably appropriate only when a considerable fortune is at stake.

No Account and Therefore No Tracking

Whenever an Internet service asks for you to set up an account, it should raise a red flag if you value your privacy and refuse to be tracked. Even some paid services like LastPass are suspected of recording their users' behavior.

As the Cryptons in incognito cloud are account-less, indexed and retrieved through encoded public keys of arbitrary entropy strength, the protection of Cryptons in the cloud is further extended by obscuring the focus of any attack aiming at a particular owner or Crypton. The incognito cloud is initially pre-populated with dummy Cryptons based on randomly generated public keys. Currently, Ai-Fi Incognito Cloud randomly fills the Crypton storage with around 300-million dummy Cryptons (roughly one per US population) and adds around 28 bits of entropy strength. The following picture offers another perspective on the protection scheme for Cryptons (picture taken from the Love Lock bridge in Paris):

In order to open a lock, even in possession of the key material (partially, such as the Entropy Extender or the passphrase, but not both, through theft, hacking or other illicit means), one needs to first locate the target lock, which appears as inconspicuous as any others amongst all those openly displayed on the bridge. Absent any metadata, the only option left for attackers is to brute-force over the complete "search space" in order to overcome the first hurdle of 28 bits of entropy. It gets expensive very quickly after paying the access charges to Ai-Fi.

As a comparison, on Bitcoin blockchain, all Bitcoin addresses may be enumerated by traversing through the Blockchain. They are interrelated by various transaction records. These two pieces of background information about the Bitcoin addresses leak a tremendous amount of information about those Bitcoin accounts and have made the anonymity unachievable. In the case of Cryptons in the Ai-Fi Incognito Cloud, they are personal, individually packaged and completely impenetrable.

The Brute-force Attack on Ai-Fi Cloud

As an account-less cloud service, it is not possible to throttle the attack traffic on a specific Crypton. There is no way for Ai-Fi to know which Crypton is being targeted under any attack scenarios. Fortunately, as a foundational support for crypto wallet, Ai-Fi charges a nominal fee on any service requests. This fee scale is small and reasonable for any legitimate request, but will amount to an unaffordable sum when a brute-force attack is launched.

The only way to circumvent paying for the service fees is to get hold of the whole Crypton database, in which case to break a password of 67-bit entropy would cost over $1B in year 2030 dollars according to the above table. This may be easily protected by the Entropy Extender of a Crypton alone, the default of which is around 10-all printable characters.

The Distributed & Decentralized Trustless Cloud Storage

There is another angle in conceptualizing the Crypton service by the Ai-Fi Incognito Cloud. Since the service is rendered incognito in terms of the requester for the service, a user plays the role of both the client and the server in maintaining their secrets. Apparently a user need not to authenticate themselves, hence there is no account set-up required. The Entropy Extender works almost the same as the conventional "salt", usually kept with the server, but in the Ai-Fi Cloud Service it is kept with the individual users when they play the role of a server randomizing the passphrase for the client who happens to be the same entity as the server. In the case of ECDHE negotiation for deriving the encryption key for the Crypton, the protocol is greatly simplified as well when both sides of the Diffie Hellman key agreement process are actually played by the same user maintaining identical key pairs.

Auditability of Cryptons in Ai-Fi Cloud

If the Crypton requests anonymously sent to the Ai-Fi Incognito Cloud are successfully validated and served, the Crypton server in the Ai-Fi Incognito Cloud, as an option, will produce an audit trail record and delivered to an email address specified when the Crypton was first created. If Ai-Fi Secure Email is employed and associated with the Crypton requests, the audit trail records will be delivered to the specified Secure Email mailbox fully encrypted. This audit trail mailbox will be bound to the Crypton only at the instance when the Crypton is first successfully created. Afterwards, only successful operations associated with the Crypton will trigger audit trail recording. The purpose of this audit trail function is to rule out any silent attacks.

Of note, since the Crypton requests are anonymous, the Ai-Fi Incognito Cloud as a provider would not be able to launch targeted attacks on any specific users. This anonymity is preserved even when the audit trail is requested if the user provides a new unidentified email address not directly tied to any of their PII (Personally Identifiable Information). The only possible attack is for the Ai-Fi Incognito Cloud to delete Cryptons randomly in order to trigger random denial of service incidents without earning any rewards, as the content of a successfully retrieved Crypton is decryptable only by the user who holds the private key for the Crypton.

Where the Rubber Meets the Road

The Passphrase-Driven Stateless Wallet

Once we have created the secret safekeeping mechanism through Cryptons, a recommended approach to operate the crypto transactions is to architect the crypto wallet as a stateless device driven only through the Cryptons in a series of sessions as depicted below:

This represents the arrivals/departures of transactions to a wallet in a serialized fashion on the time axis "t". We will use an implementation of Counterseal signer based on bootable "live" Linux as an example (to eliminate concerns of hacking). Before the "live" Seal/Signer (one of the signers in the context of Counterseal Wallet) starts its operation after boot-up, the user must carry out a login procedure by entering the passphrase and the Entropy Extender of a Crypton at 401. Once successfully logged in, the operation comprises a series of sessions. The session starts as the first arrival of a transaction 421 or 451 when the wallet is not in session. The session, once started, lasts until some termination criteria are met, for instance, at the expiration of "idle timer" which counts the time without receiving or handling transactions or the user input or at receiving user commands forcing the termination of the current session, at 429 and 459. There are typically many transactions received and serviced between 421 and 429, and between 451 and 459. The operations structure as sessions may simply terminate at 491 by turning off the power, unplugging the "live" system, leaving it unattended for a defined period of time, etc. Between sessions, such as between 429 and 451, there is no transaction being processed and the "live" system is free to checkpoint its "states" and write it out to permanent storage for the next session. If the transaction processing logic needs to be "fail-safe", some state recovery scheme must be implemented to preserve the integrity of the system. In the crypto wallet applications where the method is primarily designed to perform crypto signatures on received transactions, the state recovery is not critical as the signature operation is either completed or uncompleted. The transaction signature can always be re-applied to complete a previously unfinished transaction.

Phishing and Keylogger

As described in the previous section, we recommend the applications driven by Cryptons be structured cleanly, separating the logic from its session states maintained in the Cryptons. The threats are primarily coming from those attacks that steal the key pairs, either through some kind of keylogger or something sinister such as the "UI State Inference" phishing attack. Both issues were touched upon in the first part of this series "Secret and Attacks".

The attacks through keyloggers on infected devices are mitigated by our offering a virtual keypad specific to our application. On Windows 10, our virtual keypad is integrated into the Secure Enclave on hardware platforms where the SGX is supported, which pretty much resolves vulnerabilities on inputs. On iOS and Android, we'd rely on the sandboxing provided by their respective mobile platforms.

In the case of the phishing attack through "UI State Inference", if the Entropy Extender is cached locally at the device and auto-filled at the Crypton interface prompts, then the phishing attack would only steal the passphrase and not be able to reach those Entropy Extender values. The other anti-phishing measure is simply to run one of the Signers (Threshold Signature signers) from a "live" platform or "cleanroom", described in the next section.

Manufacturing Cleanroom

As explained in Part I, most popular hardware wallets don't utilize the hardware secure enclave any more even when it is available on the device. Now the only reason to adopt a hardware wallet and risk the Supply Chain attack is to make sure our wallet applications are running on a clean environment without worrying about potential malwares sharing the same device. This concern is actually quite easy to address by producing our own wallet in a cleanroom environment, in perfect keeping with the spirit of self reliance in the trustless decentralized world we thrust ourselves into.

Although fully runnable on dedicated hardware devices, the general operating mode of Counterseal Wallet may accommodate a variety of hardware platforms. As mentioned previously, in a shared operating environment the construction and operation of the Counterseal Wallet may be interfered with by other applications sharing the same computing platform. Although it takes a few extra steps, a carefully configured running environment may be made to run Counterseal in a dedicated setup. For instance, a typical approach is to start out from a "live" Linux environment built on a bootable USB stick or CD ROM, running stateless between sessions with all state variables dynamically loaded in through Cryptons. For the deployment of Threshold Signature scheme, all or a selected subset of signers may run from a dedicated "live" system.

There are several critical junctions during the Counterseal Wallet construction and operations that require a "cleanroom" environment to radically reduce the attack surfaces on Counterseal Wallet:

1. When a Crypton is first created: Once created, it is platform independent and may be accessed over multiple computing devices. The auditing capability of the Crypton kicks in as well after its creation. It is imperative to have a reliable foundation to build up and preserve the security of all passphrases and other secrets.
2. At the Key Generation phase of creating and configuring all the signers for deploying the configured Threshold Signature scheme

In both cases, during the cleanroom run, all external networks are shut off and shared applications are stopped. Unlike the threat of the Supply Chain Attacks for hardware wallets, Counterseal Wallet users create their own wallets from ground up based on an open source with constant verifiable code checksum without relying on any other third parties. Once the build process completes in the "cleanroom", the users themselves are suppliers and there is no external Supply Chain to fiddle with and the Supply Chain attacks no longer apply.

Obviously all Counterseal signers may start from a cleanroom build and continue on to sign transactions based on the same set of signers grown out of the original cleanroom lineage. However, for usability, the most typical configuration is to run the Primary signer on your smartphone, Secondary on your desktop or laptop after it is "manufactured" within a cleanroom. Away from their cleanroom environment, the users must carefully assess their security parameters and risk exposure before settling on a configuration. A Counterseal may configure and support multiple deterministic hierarchical wallets each with its own configuration choices.