Ai-Fi Counterseal Wallet

Background

This is Part III of a three-part series, diving into our implementation of the crypto wallet that applies the latest Threshold Signature Technology to eliminate SPOF (Single Points of Failure) and the Krypton Tokens, detailed in Part II, to merge the recovery seed into an integrated secret preserving scheme.

The Counterseal wallet is neither a software wallet nor a hardware wallet, but a framework that allows you to construct your own wallet from your assembly of hardware and software according to your own personal risk profile. The traditional hardware wallets may be easily integrated into this Counterseal framework as one of the Signers or Seals and take advantage of the benefits made available to them through the framework.

In this increasingly decentralized cyber world and with the advent of Web 3.0, protecting your crypto assets effectively and securely is the crucial first step in meeting the upcoming challenges. You may find it useful to understand how this Counterseal Wallet has come about:

Part I: Crypto Wallets

Part II: Preserving Secrets

To try out the product, go to https://www.counterseal.net and press "Get Started" button on the top right.

At the last part of this writeup we offer a threat model for comparing the hardware wallet with our counterseal scheme.

You may be interested in taking a read of a brief historical background of the counterseal in the Appendix.

Counterseal for Redundancy

The nomenclature "counterseal" indicates the arrangement that at least two or more independent "signers" or "seals" are required to create any valid Bitcoin signatures. It is not based on the popular multi-signature scheme producing multiple signatures, but an application of the latest Threshold Signature technology to the Ai-Fi Counterseal Wallet. It is the modern software realization of the old counterseal method with the added advantage of placing those multiple logical seals separately and independently in order to avoid single points of failure or SPOF. We will be using the 2-seal construction to illustrate the counterseal design.

In the context of cryptography, the individual "seal" is implemented by a pair of crypto key "shares" each consisting of a private and a public component. The components of all linked seals jointly produce the public key for a single wallet account, whereas the independent shares of private keys remain physically distributed over multiple devices without ever being joined for producing the private key. Those private keys or key components are therefore never exposed simultaneously and used only for producing "signature shares", which are pieced together at the end of signing rounds to create the transaction signatures. Otherwise put, the private keys in a Counterseal Wallet is nowhere to be retrieved or stolen and transaction signatures are rendered without the need to explicitly reproduce the private keys. The initial key shares generation is described in the appendix.

The Hardware Wallet may be considered as the ancient single seal solution prior to the invention of the "counterseal" with all the perils in trusting a single piece of hardware. Among all the risks in relying on a single implement for secret hiding, the possible loss event of the hardware is the most severe. Additionally, although the recovery seed of the complete hardware wallet may be exported for recovery purposes, it is nonetheless still embedded in the wallet which may be exploited when the attackers manage to get their hands on the hardware. As an answer to those issues, the counterseal scheme splits a single key to the vault into multiple implements to avoid the potential catastrophe when the only key is compromised.

In the following we will describe how the Counterseal Wallet is configured at "unboxing" and how the signatures are obtained by applying both seals.

Hardware Wallet

Most popular hardware wallets are simple hardware devices designed for storing the secrets or signature keying materials required for signing cryptocurrency transactions. It typically works with a "front-end" wallet (e.g. Exodus, Electrum and other crypto wallets supporting back-end hardware wallet) that interacts with the blockchain directly over the Internet. The hardware wallet runs in the back-end as a key vault to reduce the direct exposure of keys to external elements, whereas the front-end wallet is kept passive without the capability of signing transactions.

Some low cost hardware wallets require USB wire or some other types of wired/wireless connectivity connecting to the host where the front-end wallet runs on. A device driver (e.g. Trezor Bridge) on the host mediates the traffic between the hardware wallet and the front-end wallet.

An air-gapped hardware wallet/vault is more sophisticated in its association with the blockchain-facing front-end wallet without needing any wires or network connectivities. It stores the seeds and all the private keys in an air-gapped arrangement that reads in the intended transactions manually, usually assisted by the displayed QR code or other facilities for easy copy/paste. It is naturally "cold" in the sense that its functions are not triggered until after receiving the correct PIN code and the manual entry of the transactions to sign. The signing involves at least one button press or other actions involving a human operator. It may still be operated remotely if the QR code images or imported/exported transaction-containing files are allowed to be interacted remotely.

Ai-Fi Counterseal

Counterseal Construction

The Ai-Fi Counterseal is also a key vault like those air-gapped hardware wallets, except that it splits the hardware key store into at least two independent parts. With two independent components running on separate devices, they work together to support a variety of front-end "watch-only" crypto wallets and offer up an unparalleled set of protection and usability through built-in redundancy. Note that the interface with the front-end wallets is taken on exclusively by the Primary Seal.

For interfacing with Bitcoin wallets, it follows the Bitcoin HWI (Hardware Wallet Interface) with the Primary Signer responsible for interfacing externally with those Bitcoin wallets, which is based on an air-gapped design relying primarily through manual QR code scanning in both directions across the air gap.

The Counterseal vault is to store the key materials of your crypto coins and to conduct transaction signings under the counterseal scheme or joint-signing involving multiple redundant signers (2 of 2 for now). The key information in the vault does not include any private keys as such, only independently distributed bits and pieces ("shares") sufficient to conduct the signing when combined.

The operations of Ai-Fi Counterseal Wallet are diagrammed above, with the Primary Seal working with the wallet and the Secondary Seal the cooperating partner on a separate device. The word "seal" adopted here indicates the protection afforded by the secret shares maintained by two independent signing parties. Both seals must be presented in order to successfully assemble the signatures for blockchain transactions. We use terms "seal" and "signer" interchangeably.

In the current implementation we designate our mobile phones as the "leading" partner, or the Primary, in the Threshold Signature logic. The Secondary Seal is to run on a separate device, "signature only", without the means to affect the terms of any transactions such as the transfer values or the "inputs/outputs". Even if the secondary seal was compromised (running on a shared platform such as Microsoft Windows), the worst damage inflicted would be the denial of service without the possibility of producing incorrect transactions or losing crypto coins.

We support the open source Electrum Wallet and BlueWallet in the first release with many more to come.

Pairing of 2 Counterseal Signers/Seals

The Primary and Secondary Signers or Seals work together to generate the full function set of Bitcoin transaction signing. The Primary takes care of all the interfaces to external front-end wallets. The combination of the Primary and Secondary Seals function identically as traditional hardware wallet.

To work together as an integrated crypto vault, the Secondary Seal must be securely bound to the Primary at the outset. This binding process starts out at the Secondary Seal displaying a QR code for the Primary to scan and "pair" if not yet bound to each other, following the TOFU (Trust On First Use) principle of authentication. Once paired and bound, the Primary and the Secondary will be mutually recognizable with each other through two ID key pairs, which are used later for establishing a TLS-strength secure connectivity needed for Threshold Signing. The Primary may be required to re-connect and re-authenticate itself if either of the network addresses changes, by repeating the process of the Primary scanning the QR code displayed by the Secondary. The Secondary only supports connectivity on local LAN through a private IP address connecting to the Primary without the capability to go on the Internet.

Uninitialized Secondary Seal will display the following pairing QR code to kick off the initialization:

Note that in the management panel of the Secondary Seal the "Display Transaction Details" option is turned on by default. More on this option will be described later.

Once the pairing completes, the vault of the supported crypto coins is represented as below:

The "Master Public Key" is displayed on the face of the "wallet card". Before the transaction signature can be carried, the primary and secondary must be "in sync" in order to be ready, under which condition the public keys on both signers are identical. The upper right icon is for displaying in QR code the public seed address for the key store of the supported coin type to be used in the binding process, which binds a crypto wallet (Electrum, BlueWallet) to the vault. The "QR scan" icon on the lower left is for importing the transactions from a supported wallet in an air-gapped fashion.

Each "credit card" looking diagram represents the vault for a specific cryptocurrencies. Currently in Rev 1.0 only Bitcoin is supported through either Electrum or Blue Wallet in their watch-only mode.

More details on the actual internal steps, or the Key Generation of the Threshold Signature Technology, conducted during pairing is provided here.

BIP32 Compatibility and Backup of Seeds

Ai-Fi Counterseal Wallet is BIP32 conformant and follows the BIP32 convention on the account level and supports multiple "accounts" through Extended Key, each of which is composed of a single external keypair chain. The top 4 levels supported are m/84'/0/0.

Internally the Ai-Fi Counterseal Wallet/Vault does not store any private keys and therefore provides no counterpart of standard BIP 32 Master Seed and Master Node in the counterseal scheme. As a consequence, an Ai-Fi Counterseal Wallet may not be exported to traditional wallets and vice versa.

Although not a standard deterministic wallet, Ai-Fi has a customized backup procedure for storing the counterseal "seeds", based on which the Counterseal Vault may be fully recovered. Both the Primary Seal and the Secondary Seal have their own seed for recovery purposes. Due to the complexity of the Threshold Signature scheme that dictates many rounds of cryptographic steps to guarantee its security, the backup data is much more involved and difficult to be condensed into straightforward mnemonic passphrase. For their safekeeping, it is recommended to store them (or one of them) as Ai-Fi Krypton Tokens in the Ai-Fi Incognito Cloud, which are based on the Ai-Fi pseudonymous cloud storage design, wherein your files are protected by a cryptographic key pair of similar or stronger strength than that of your Bitcoin accounts recorded in the Bitcoin blockchain. Since your dealings with Ai-Fi.net is account-less and keyless, the Ai-Fi Incognito Cloud is completely pseudonymous like your Bitcoin coins. Please refer to its documentation for more in-depth discussion of this scheme.

The backup scheme takes advantage of the inbuilt counterseal redundancy and generates two separate backup "tokens", one of which may be written down on paper (the "paper vault"), which you may rely on the safety of your home or a bank safe deposit box for its protection if so chosen. The other backup seed recovery file may be either maintained privately (in your local storages) or sent to the Ai-Fi Incognito Cloud as an Ai-Fi Crypton protected by a strong passphrase. Under this backup arrangement, there are no single points of failure and is completely trustless, eliminating even the possible concern about the involvement of Ai-Fi as a service provider in its management of the Ai-Fi Incognito Cloud.

Ai-Fi Counterseal Operations

Architecture

Architecturally there are three components in the Counterseal framework involved in the signing of crypto transactions:

The front-end crypto wallet (e.g. Electrum)
The Primary Signer
The Secondary Signer

The Primary and Secondary signer pair maintain their "sessions" based on the states stored in their respective Krypton Tokens.

The Primary and Secondary signers need to be "paired" in order to enter into a signing partnership, finding each other on a local LAN. The signing partnership are required to undertake a "key generation" process at the startup in order to form cooperatively a shared key pair with each party holding an independent "shares" of the keys.

The interfaces between the crypto wallet and the transaction signing parties (Primary and Secondary Signers) are air-gapped without relying on any network connectivity. There is no network connection required between the front-end wallet and the signers, which allows both of the signers to operate offline in order to ward off possible remote online attacks to the greatest extent. This also affords the flexible binding between the crypto wallets and the signers. Use Electrum as an example: the Electrum generates a transaction, which is represented either as a QR code or in a file format. The Primary Signer collects the transaction by scanning the QR code or accepting the transaction file from Electrum as an "export". After the signature is successfully rendered by the primary and secondary signer pair, the resulting signed transaction is imported back to the wallet in the reverse direction either through similar transfer mechanisms, which is then broadcasted to the Bitcoin blockchain by Electrum.

Note that the example wallets documented here (Electrum and BlueWallet in the first release) is "watch only", which is not able to sign transactions without the participation of both signing seals in generating the required signatures.

Counterseal Vault as the Last Line of Defense

Since the front-end wallet (e.g. Electrum or BlueWallet) is where the user typically gets their visual feedback and is subject to phishing or malware attacks, the actual transactions passed on to the Counterseal Vault may not match what is being displayed on the wallet. The transaction amount and sender/recipient addresses are prominently displayed on both Seals requiring the pressing of their respective confirmation buttons. Be sure to carefully examine the transfer amount and the transfer input/output Bitcoin addresses. Satisfy yourself that there are no discrepancies between what are displayed on the front-end wallet and the Counterseal apps on both of the Seals before pressing the confirmation buttons. Any inconsistent data displayed would indicate a phishing attack with possibly disastrous consequences.

Counterseal for Electrum Wallet

Electrum/Counterseal Configuration

For the popular Bitcoin wallet Electrum, the standard counterseal configuration is diagrammed below. The Secondary Seal may be placed on a Microsoft Windows PC or a separate platform (more details later) if the health of Windows is questionable.

The Electrum in its "watch only" mode is not too serious a security concern. The following is a convenient configuration with both the Electrum and the Secondary seal hosted on the same Windows platform. If the Secondary Seal is installed on a Windows 10, its management panel may be found in the Windows system tray.

However, if dealing with transactions of substantial value, you may want to beef up the security of the Secondary Seal by hosting it on a fortified clean platform without the risk of unknown extraneous elements. Counterseal framework offers a highly secured "live Linux" (e.g.TAILS-based) system on a USB stick for running the secondary seal in order to avoid possible tampering of the secondary device. This multi-factor secure setup is highly resistant to tampering (both hardware and software) due to the built-in redundancy and the live nature of the underlying highly defensive malware-free Linux. The link between the primary and the secondary is securely protected by TLS once the two signers are successfully paired. Obviously Electrum may be relocated to some other platform (e.g. Windows) without sharing the Live system with the Secondary Seal.

We foresee the Secondary Seal may be supported on many different hardware devices in the future. We highly recommend creating your own Secondary Seal in order to avoid the possibility of any "Supply Chain Attacks". TAILS Linux and many other Linux distributions have done trailblazing on the production of secure Live system with extensive documentation, tool set and easy-to-follow production steps. For your peace of mind, it is well worth the time to make your own Live Secondary Seal. We will outline the details in later sections.

Electrum Watch-Only Wallet

There are quite a bit of materials on the web explaining how to create the air-gapped Electrum "watch-only" wallet by importing the master key materials from external sources, which is the Counterseal Primary Signer in our case.

A tutorial on YouTube: https://bitcointalk.org/index.php?topic=4573616.0 This is a bit lengthy. (The actual introduction starts at around 15:00.) A shorter one: https://bitcoinelectrum.com/creating-a-watch-only-wallet/. For completeness, you may find an instruction outline in the Appendix.

Note that in terms of interfacing with the Electrum wallet this Counterseal scheme is quite similar to how the "offline paper wallet" is handled. Although involving more components due to inbuilt redundancy, the Counterseal signature scheme works similarly as those popular hardware wallets for interfacing with the Bitcoin wallets. Look up the documentation for the Electrum wallet for other relevant information.

Make your Own Secondary Live Seal

As previously introduced, the Secondary Seal/Signer can run conveniently on a generic PC, most popularly on Microsoft Windows 10. Since the Windows platform is heavily shared by a multitude of applications, the threat of malwares is real and frequently results in the loss of cryptocurrencies stored in the soft wallet running on the generic platform in traditional implementation of wallets. An improved idea is to produce a so-called Live system, booted from a USB stick when needed with a carefully configured Linux operating system supporting only the dedicated single-purpose software wallet. The issue is that although the USB stick functions similarly as a hardware wallet, the protection of its key materials and its interface to the front-end wallet become daunting rather quickly.

Counterseal framework offers a Secondary Seal supported through a Live Linux on a bootable USB stick. It removes all the traditional obstacles by making it "stateless", keeping all its key materials in a Crypton. Actually this stateless design is common to both the Primary Seal and the Secondary. As long as the users are certain the code on the stick matches the published constant code checksum, coupled with its segregation from the Internet, the malware as an attack vector is eliminated.

Counterseal for BlueWallet

The built-in air-gap between the wallet and the primary seal is not being utilized in this configuration. To adopt this configuration the user ought to rule out any concerns of malware or possible compromises on the mobile phone. The "Display Transaction Details" option is turned on by default on the Secondary Seal. You must apply the same validation of transaction details to both the BlueWallet and the the Secondary Seal for similar reason as described previously.

Deployment of Counterseal Signers

The Primary and Secondary Signer/Seal

For comparing with the hardware wallets, you may jump to the threat model sections for a discussion.

There are several advantages in adopting the Ai-Fi Counterseal Wallet:

No single points of failure.
Since the Primary runs from your smartphone, your Counterseal Wallet is practically next to you at all times without requiring you to carry yet another piece of hardware if you own a hardware wallet.
Non-custodial, trustless and provable security based on open source software.
The protection of the configuration data, if adopting the Ai-Fi Crypton mechanism, is of higher strength than the discrete logarithm problem in public-key cryptography while maintaining the usability of the proven MiniLock software ("File encryption software that does more with less.")

The actual deployment of the counterseal scheme involves some tradeoffs:

The Primary Seal is hosted on your mobile phone. The Apple iPhone is our top choice, with Android from reputable vendors a close second. We believe the carefully implemented Sandboxing, the iOS and iPadOS keychain in the Secure Enclave, the system level key entry, and the approval process of the Apple App Store are sufficiently strong to ward off almost all the malware on iPhone that are relevant to our wallet (even Norton, the security company, states "... thanks to Apple's safety precautions, it is extremely rare..."). Apple's attention to its security hardware is also fairly well recognized once its Secure Enclave Processor is "demystified". Needless to say some elementary precautions on owning the iPhone must be duly observed. A general understanding on the hacking risk on various device types may be found here.
Make sure the platform where the Primary Seal runs on is not "jailbroken", not under MDM, and is not managed through an Enterprise App Program that bypasses the rigorous Apple App Store review.
The Secondary Seal is given the following options, each requiring specific software implementation:
- Secondary seal on generic PC platforms
- Secondary seal installed on a USB stick running Live Linux TAILS
- Secondary seal installed on a standalone Raspberry Pi 4 in the Ai-Fi environment, aka the HomeServer in the context of Ai-Fi Central.
- Secondary seal installed on a tiny, portable, low-cost, dedicated device with LCD display that supports the secondary signer. There are many such DIY devices to choose from. The Raspberry Pi Zero W and the Orange Pi Zero LTS look attractive to us. (This is to avoid us becoming a suspect in the "Supply Chain Attack". We only offer the open source software that runs on it.)
These are examples of implementation platforms for the secondary signer, each having its specific vulnerabilities with malware being the primary concern. Clearly the live Linux on a USB stick (TAILS) and the Raspberry Pi hardware (Ai-Fi HomeServer) are much less likely to contract malware. However, the built-in redundancy has substantially enhanced the secondary signer's tolerance for faults or attacks. Unless both the primary and secondary components are totally compromised, the Zero Knowledge proof built into the Threshold Signature scheme would discover any attack incident and report/log accordingly.
For those secondary signers that have no attached display, a web server is built in natively so the secondary signer may be contacted through a browser interface, which helps in the initial pairing process (primarily the discovery of the secondary signer) and the connectivity reestablishment later on after pairing. All subsequent transactions between the primary and the secondary seals are conducted directly (authenticated and encrypted) and end to end.

We believe that the DIY route is the only way to bring you peace of mind. We recommend to all users of Ai-Fi Counterseal Wallet to create their own in order to eliminate the reliance on any third parties. The production is not complicated once they understand the architecture diagrammed in earlier sections. "In Open Source Software We Trust."

Note that both the primary and secondary seals may still be independently compromised regardless of how carefully they are managed. Nevertheless, the chance of success in hacking both seals individually at one time is extremely low, and less likely still where some attacks of physical nature are required if mobile devices are chosen to host those seals. The risk is lower than any other wallets on the market, be it software or hardware.

Threat Model for the Rich and Paranoid

The Low Hanging Fruits

The biggest physical bank robbery, which took place in Brazil in 2005, was worth “only” $69.8 million. On the other hand, in 2019 alone criminals got away with $4.26 billion worth of digital coins as widely reported. None of the hacks have taken place on the blockchain itself. As far as thieves are concerned, exchanges are where the money is. Most low hanging fruits for hacking nestles within popular exchanges and other cryptocurrency services. Protecting one's crypto assets is an exercise of how not to trust or rely unnecessarily in any institutions. Incidentally, trusting no one is what motivated the original invention of Blockchain after all.

Adopting blockchain technology requires taking control of our own finances, which comes with specific responsibility and potential pitfalls. If we decide not to entangle ourselves with any custodial services, we must face the task of safekeeping our keys stored in our crypto wallets and their recovery seed. Since seeds recovery is less frequently applied, it has not been given sufficient attention by the blockchain industry, whereas the hardware wallets have gained a large following. It doesn't take much to recognize that hardware wallet manufactures are low hanging fruits for hacking. On the personal level, targeting individual hardware wallet devices, the "Evil Maid Attack" and "Supply Chain Attack" are well-known attacks. This is not to mention that the manufacturers need to be trusted not to attempt the "Supply Chain Attack" themselves, countering to the "Trustless Principle" of the blockchain movement.

Tamper-Evident Hardware & Software

Some hardware wallets on the market touts Tamper Resistance or Tamperproof guarantee. The detection of tampering would sometimes even trigger the self-destruction of the wallet. Unfortunately unlike open source software, most of those tamper-resistance design is not publicly disclosed. The track record of "tamper-evident technology" are nowhere close to perfection, which is well documented here, here, here and here. The title of the last and most recent article on hardware vulnerability is titled "Intel SGX defeated yet again". Some would even go so far as to say that the risk of tampering is self inflicted due to the reliance on a piece of hardware. This dependency on hardware is further aggravated by the fact that the cryptographic seed resides physically on the device itself. It is game over and all your crypto assets are forever lost if this single point of failure is successfully perpetrated. A YouTuber "LiveOverflow" has dedicated a series of videos titled "Hardware Wallet Research" investigating this particular issue which we found illuminating and quite enjoyable to watch.

The never ending news about Intel SGX hacking just had a new report: "Stick a fork in SGX, it's done: Intel's cloud-server security defeated by $30 chip and electrical shenanigans". It stands to reason that those relatively inexpensive hardware wallets on the market are based on much less rigorous designs than SGX.

Obviously a software implementation does not remove the risk of hardware tampering, especially when the software is designed to run on public platforms (Windows, Mac, Linux, iOS, Android). However, the vulnerability to hardware/software tampering in our Counterseal scheme is greatly reduced by requiring joint actions from multiple devices (at least two "factors", or multiple points of services) based on the tried and true redundancy principle. Most notably, the Threshold Signature scheme adopts the "zero knowledge" proof in verifying critical exchanged messages, which actually proves that a maliciously broken party will not gain any useful information for launching subsequent attacks past compromise or be able to evade detection for any failed attempts. The Threshold Signature scheme is one of those glorious achievements of technology such that adding additional components to a system actually enhances its overall reliability and fault tolerance. This is not even to mention that Ai-Fi Counterseal Wallet is state-less when not running and does not store its seed within the wallet itself, which is the weakest link in the hardware wallet operations.

Anatomy of a Electrum Wallet Attack

Aug 31, 2020: "Bitcoin Holder Loses $16 Million in BTC to Well-Known Scam"

Nov 13, 2020: "Electrum Malware Scam Scalps $32,000 in Bitcoin"

It is hard to believe that the above two Bitcoin holders are victims of the same Malware scam. You can find out the details on their respective hacking reports. We just want to outline the defense mechanisms built into our Counterseal signature scheme. The attack scenario is fairly straightforward:

This documented attack involves a phishing exploit that injects malware to the platform where the soft Electrum wallet runs on under pretense of software upgrade. Once compromised, the Electrum wallet may be remotely controlled to generate Bitcoin transactions delivering coins to an attacker address.
The configured Bitcoin core nodes are modified and redirected to a malicious node, which eases the creation of the bogus transactions.

How is the Counterseal supposed to work in defending this fairly effective attack?

The Electrum wallet under Counterseal framework is only able to "watch" the transactions initiated by users without possessing any private keys. All signatures must be provided in a separate Counterseal construct involving two components, the primary and secondary signers. The malware attacking the Electrum wallet is not able to initiate unattended Bitcoin transactions.
There is an air gap between the Electrum wallet and the primary signer. The signature may not be procured without manual intervention bridging the Electrum wallet and the signers.
The Counterseal primary signer is only a piece of software running on the mobile phone, which is hackable in theory. The same applies to the Counterseal secondary signer. However, it is astronomically harder in compromising all three components without being detected.
Optionally, the Counterseal primary and secondary signer may be protected by the wall of Ai-Fi Krypton Token in the Ai-Fi Incognito Cloud. The address of a Krypton Token, its only publicly exposed component, is a formatted public key under PKI, much like that of Bitcoin itself on the blockchain, the strongest protection known in the field of cryptography.
It is worth mentioning that one crucial aspect of the attack requires the hackers being able to subvert victims from legitimate nodes to bad nodes controlled directly by the hackers themselves. The Counterseal users may adopt the HomeServer as the Bitcoin core node under the Ai-Fi Domain Security infrastructure, which effectively blocks this attack surface.

Counterseal under Ai-Fi Domain Security

The Counterseal Wallet may be further strengthened by integrating with the Ai-Fi Domain Security framework to gain the following functions:

Multi-factor confirmation of signature authorization: This is achieved by integrating Counterseal with Ai-Fi SecureEmail.
Secure reception of Krypton Token audit trails
Connecting to a full node: For Bitcoin, we will be able to operate a private full node on Ai-Fi HomeServer within the secure confines of an Ai-Fi Domain.
Since the Ai-Fi HomeServer is under the strict control of the Ai-Fi Domain Security, its running platform is closed and carefully configured with minimum or no exposure to malwares. It is well suited to host the Secondary Seal.

Appendix

Historical Notes

A seal is traditionally used to close records by any type of fastening that must be broken before access can be obtained, producing an impression upon wax, wafer, or some other substance capable of being impressed. The "hot knife" attack is common, by cleanly delaminating the wax seal for mold casting and illegal reproduction. The use of the counterseal, displayed above involving two separate stamps where a second stamp is imposed upon the reverse of a main or usually larger seal, is a robust improvement in preventing the obvious "hot knife" attack. Removal or incorrect application of any one of the two seals would invalidate the sealed record altogether. It is not a secret preserving (encryption) method but a tamper detection mechanism employed during the delivery of sealed sensitive information, against which there are many known attacks.

For history buffs, The picture below illustrates [how the pair of seal stamps on each side of the final wax seal are applied]:

Creation of Counterseal Wallet

The Ai-Fi Counterseal Wallet is a special "2 of 2" realization of the threshold signature technology, with the primary seal (signer) and the secondary seal belonging to the same owner or under the same administrative domain. Before the signing can be properly executed, both signers must first engage in the "Key Generation" process. Since all Counterseal wallet functions are based on the success of this process, it is recommended to conduct it in a "cleanroom" environment.

The secondary signer is equipped with a screen to display the QR code for various interactions with the primary, which is a mobile app running on either the iOS or Android phones. Both signing parties are on the same LAN (at least during the initial pairing rounds). The "pairing" of those two signers is established according to the principle of TOFU (Trust On First Use) by the primary scanning the pairing QR code displayed on the secondary signer if not already bound. After the successful completion of the pairing process the identities of both parties are mutually established, based on which a secure TLS channel may be constructed on demand between those two parties.

There are three steps involved in setting up a counterseal wallet (after the parties successfully bound to each other):

Secret Share Generation: Each signer independently generates its own sub-share (not private key) or segment for the aggregate counterseal assembly without revealing them to each other. All necessary data required for transaction signing are negotiated and synchronized during this phase.
The resulting public keys will be known to all parties but the private keys are never fully constructed or even required for signing. Only signature-related information are exchanged among the parties during subsequent rounds.
Secondary Signer Deployment: Once the involved parties are securely bound to each other and all key shares are integrated and synchronized, those two signing parties don't need to be online or connected until the signatures are required. We will discuss more on the placement of secondary signer.
Distributed Threshold Signing: Before the transaction initiation, the primary and the secondary signers need to reestablish their encrypted and authenticated counterseal channel. The crypto wallet (BlueWallet for the first release) would initiate the crypto transactions, which are formulated and passed around for partial signatures that are pieced together at the primary signer at the last stage of the signature round. Under normal network conditions, any incorrect move by either party would generate an alert/incident-report. The primary and secondary signers are only allowed to perform the signature without the ability to alter the transactions.

The crypto wallet (BlueWallet), the front end of the wallet, typically resides with the primary seal and operates effectively in watch-only mode, which relies on the backend Ai-Fi Counterseal Wallet (vault) for signatures exclusively. The interface between the crypto wallet and the primary signer follows the HWI standard.

Air-Gapped Watch-Only Electrum

In the Electrum application, when first creating a wallet:

Select "Standard wallet" and then,
"Use a master key" in the Keystore selection screen to indicate that the keys are from an external key vault.

On the next "Create keystore from a master key" screen, scan the QR code displayed on the Counterseal Primary Signer (by tapping the "wallet card" on the counterseal app on your mobile phone) in order to initialize the Electrum key store from the air-gapped Counterseal vault, as illustrated below:

Make sure you use the appropriate version of Electrum (Electrum or Electrum Testnet).

Electrum/Counterseal Transaction Validation

After the keystore is initialized, the normal flow of Bitcoin transactions may commence. For instance, the example "Send" transaction is formulated and "exported" (red circle below) to the Primary Signer through the QR code as illustrated below with the Electrum screen on the right and Primary Signer left:

The transaction signature request received by the Counterseal app will display its transaction outline (left) for your confirmation. Make sure the highlighted Electrum data (Inputs, Outputs and associated amounts) are identical to those in the confirmation screen of the Counterseal app. Be sure to verify every single digit displayed on both sides of the air-gap. This is one of the most important steps in the counterseal process. If successfully validated (visually), all three components (Electrum, Primary Signer, Secondary Signer) must all be compromised for our Counterseal application to be defeated, an extremely unlikely scenario. This is the strongest defense obtainable among all the wallet applications on the market.

The Primary Signer then requests the counterseal signature from the Secondary Signer and displays the QR code below when the counterseal signature is successfully constructed:

Depending on the complexity of the transaction, the counterseal signature may require several steps and trigger multiple frames of QR codes. After the successful signing of the transaction, Electrum collects this signed transaction (in QR code format) by going to the "Tools" ==> "Load transaction" ==> "From QR code" to read the transaction back. Once imported, the transaction is ready to be broadcasted to the Bitcoin Blockchain.