Krypton Wallet

General

Your Crypto Keys and Secrets

To protect your crypto assets, you need to hide a few secrets associated with your crypto wallets and to reconstruct them in the event of a loss. Those secrets are crucial in protecting your digital assets. In the context of cryptocurrencies, the following is the typical variety of keys:

1. Mnemonic Recovery Passphrase: This is the seed mnemonic for recovering a deterministic wallet based on BIP 32/39. Your wallet may be recovered in a loss event only if this recovery passphrase is provided.
2. Crypto Account Private Keys: You can conduct crypto transactions for a particular crypto account only if you are in possession of its associated private key.
3. PIN for your hard or soft crypto wallets: This is for entering the logic modules (hard/soft) for conducting your crypto transactions.

Clearly the Mnemonic Recovery Passphrase has the strongest impact on your crypto assets. Its loss or theft is catastrophic. Due to its length (typically 12 or 24 words), it is unrealistic to reliably commit it to memory and therefore is almost always recorded on physical media. It is the crypto equivalent of "hot potatoes" regardless of whether you have a hardware or software wallet.

The private keys to your specific crypto accounts are usually hidden in your wallets. In the case of the hardware wallet, those private keys are purposely stored externally away from your signing software in a hardware device functioning as a scaled-down version of HSM (Hardware Security Module), in which case its physical possession and the simple entry PIN are the only barriers keeping them from harms. Note that those mnemonic recovery passphrases are often stored in the hardware wallet as well in order to generate new crypto accounts on demand. This obviously produces a "double jeopardy" situation.

The Ai-Fi Advantages

Ai-Fi.net offers a different approach to protect your digital assets, including your crypto coins. It takes advantage of the most recent advances of cryptography and the unique architecture of Ai-Fi service infrastructure, which is pseudonymous, account-less, and providing an Incognito storage cloud, with the following hallmark features:

• It is account-less and therefore "designs out" any possibility of being a cloak & dagger "free" service. Our business model is straightforward: cash only, pay as you go, over the counter. Currently the payment is made through the Stellar XLM coins (, which is not exactly anonymous. In the next release we will implement an anonymous payment scheme).
• The Ai-Fi Incognito Cloud Services are anonymous, taking advantage of the fact that your subscribed cloud storages are not tethered to any accounts. It is secure, private and staying current as long as the payments are kept up to date. We have a Bounty Program to show off this privacy-centric and hardened cloud storage.
• We offer a variety of secret sharing schemes. We've all heard about multisig wallets, which are based on the "secret sharing" by splitting your keys/secrets into multiple segments distributed over many parties or devices. The Shamir Secret Sharing is supported as SuperLock in Ai-Fi, allowing the reconstruction of your secret. The Threshold Signature scheme is supported through our Ai-Fi Wallet (Krypton Wallet), supported distributed transaction signing without leaking the secret at any point of the signing process.
• Ai-Fi Digital Asset Management combines the blockchain immutability with the self-managed auditing to protect your public digital assets. The Ai-Fi SecureEmail is one such management scheme.

Multisig is an attractive scheme until the time to deploy it. To DIY your multisig wallet is complicated and error prone. Most people and institutions hire a third party for its deployment at the expense of privacy. Copay is one such wallet with the multisig beautifully implemented and backed by the BitPay serves. This is not to mention the extra cost involved in conducting the multisig transactions.

In this document we will only describe the part of our services relevant to protecting your crypto assets, adopting the Threshold Signature technology. Please follow the various links above for details on other Ai-F facilities.

Ai-Fi Krypton Wallets and Protection

Based on our unique design and integration with the latest technologies, the following wallet-specific functions are offered:

1. The "hot potato" issues of your mnemonic recovery passphrase may be addressed as below:

   • Secure your recovery passphrase in an Ai-Fi Krypton Token. This scheme is as sure or even more secure than holding your crypto assets in a blockchain with their public keys exposed to the world.
   • Split your passphrase into multiple segments and protect those segments individually (Shamir Secret Sharing). This mechanism is called Ai-Fi Superlock, which may also take advantage of the Ai-Fi Krypton Token for some of the segment storage.

2. Keyless crypto accounts: Ai-Fi Krypton Wallet allows individual accounts to be "keyless", or "signing only" without being a dedicated store for private keys. Gone is the need for a hardware wallet, as there is no longer private keys to protect. This is accomplished through the Threshold Signature technology. Note that keyed crypto accounts are still supported for backward compatibility.

Keyless Accounts with Threshold Signature

Threshold Signature as "Software HSM"

Threshold signature is a powerful tool with many applications, one of which is to replace the need of HSM by incorporating multiple signers in its deployment. Obviously "Software HSM" is a silly oxymoron. We will refer to it as KSM, or Krypton Security Module from now on, indicating its reliance on the foundational Ai-Fi construct of Krypton Tokens. However, some of our users are adopting it as a convenient soft apparatus for achieving redundancy and defense against online hackings. The threshold signature does not implement the HSM protocol (e.g. PKCS #11). It only focuses on achieving the following functionality:

1. The wallet alone is not enough to carry out the crypto transactions. It must work with some external modules or secondary signers for signing. It acts as a "bridge" to the crypto servers, similar to that for the hardware wallet.
2. The external module may be separately and independently protected with an attack surface inherently different/independent from the wallet itself.
3. The wallet itself is not vulnerable to hacking, as it is not in possession of the private key (keyless).

Note that the signer under this context of "KSM" needs not be a "person". A software agent created for the purpose of managing a key share remotely by the wallet owner is sufficient without involving a third party (more on this later). Ai-Fi Wallet, based on the Threshold Signature scheme, has accomplished all the functions above without requiring our users to acquire a dedicated hardware, which sticks out like the proverbial sore thumb or hot potatoes. Stealthiness is a good thing in the problem space of secret keeping.

Traditional HSM creates the vulnerability of a single point of failure, for the whole set of private keys physically reside on the HSM (in addition to the mnemonic seed on a piece of paper). Getting hold of it physically may be sufficient to compromise it (side-channel attacks). The PIN protection will not survive offline hacking by any reasonably skilled engineers. Threshold Signature does not have this vulnerability.

Besides, Ai-Fi also solves the issue of backing up and protecting the Recovery Seed Passphrase to boot.

Threshold Signature Deployment

There are three steps involved in setting up a KSM scheme:

1. The Ai-Fi Counterseal Wallet is a special "2 of 2" configuration of threshold signature scheme, with the primary seal (signer) and all secondary signer (seal) under the same administrative domain. Each signer has its own identity key pair and generates its own sub-share or segment for the whole group independently. The resulting secret is only implied based on individual segments. For ease of management, KSM allows this Secret Shares Generation to be done centrally if there is no danger of getting spied on at this stage (of the virus or Trojan variety). If done centrally, this is the only scenario that your secret may be hacked with all signers congregate in the same server. When in doubt, distribute it out.
2. The generated signer modules are assigned to a primary signer platform, which resides with the Ai-Fi Central app, and to multiple secondary signer platforms, configured in the previous steps and distributed over many locales.
3. Once deployed in this distributed fashion, the threshold signature may then be conducted as described in the next section.

Threshold Signature and Wallet Configuration

We have integrated a Threshold Signature scheme with our Ai-Fi Wallet such that:

1. Your Ai-Fi Wallet by itself is not able to initiate crypto transactions or carry out any crypto transactions, which must be conducted jointly with other "signers". The exact required number of signers depends on how it is configured.
2. Each of the signers holds only a "share" or segment of the private key. Those partial shares are used only to sign the initiated transactions jointly (and not used to reconstruct the private key, hence keyless). None of the signers has the whole private key and therefore is not vulnerable to any attempt of theft for the private key.

With this demo release, we support the scheme of two signers, both of which must sign the transactions before sending them to the blockchain for execution.

Note that the threshold signature is not compatible with the BIP 32/39 wallets, unlike the multisig scheme that involves multiple "whole" private keys for signing. This is the logical consequence of not storing the whole private keys (for selected accounts) on a single wallet and only keeping a "shares/segments" (aka partial key) of the private key. The threshold signature is completely transparent to the blockchain with the obvious cost savings for Bitcoin, for instance. This also implies that the recovery seed mnemonic becomes ineffective in its ability for recover the complete wallet. Our implementation currently supports both the BIP 32/39 wallets and the threshold signatures. The recovery of those threshold signatures is rather complicated. It is supported outside of the wallet via the secret Krypton Tokens in the Ai-Fi Incognito cloud.

Ai-Fi KSM

The KSM emulates the operational procedure of your familiar HSM without the hassle of plugging in and out of your HSM device:

1. Bring up the KSM module from within the wallet app in Ai-Fi Central App. This is the primary signer.
2. Locate the crypto account and turn on the threshold signing process.
3. Bring up the interface screen for the secondary signer, which displays a QR code. Connect the primary signer to the secondary either through the QR code or by acknowledging the secondary signer by specifying the configuration data. Primary signer identifies itself as being the owner of the wallet. The secondary signer initializes its operational environment and follows the instructions issued by the primary signer.
4. The primary signer conducts its transactions and acquire the necessary signatures independently issued by the secondary signer.
5. If the threshold signing process ends up in error, the primary signer logs the error and exit.
6. If the threshold signing process succeeds, the primary signer reports the success and close the link with the secondary signer or signers.

KSM Deployment

Threshold Signature Threat Model

Threshold signature is a powerful tool with many applications. The nature of the application determines how the individual signers and the majority of the signatures are to be configured and administrated. In many situations the signers are independent signing agents or authorized parties in a commercial or contractual settings, each of whom makes their own signing decisions.

In the application of threshold signature for "KSM" described previously, it is adopted to effect redundancy and recovery against loss or theft. In that case all signers are under the control of a single owner of the crypto account and the private key as the secret is segmented into multiple independent pieces dedicated for signature only and distributed to many locales. It must be emphasized that the authenticity of the primary signer owning the Ai-Fi Wallet is most critical in this scheme, while as a safeguard any misbehaving secondary signers will be detected by the primary signer during the signing process without compromising any secrets. Since the primary signer is in control of the Ai-Fi Central wallet app, all other secondary signers may be outsourced to some third parties without risking the security or the validity of the final transactions (correctness of the crypto transactions). The worst case scenario is the potential denial of service when some secondary signers are compromised and not able to perform as defined. "Bad" secondary signers or imposters will be detected in all cases.

Let's examine a few threat scenarios:

• Hijacking of the primary signer: To conduct illegal transactions, the hijacker must mobilize multiple secondary signers, each requiring a PIN to unlock its configuration file which they don't have.
• Hijacking of a secondary signer: The hijacker needs to compromise the primary signer as well, which is considered more difficult (The loss PIN code in this case is not catastrophic). If multiple secondary signers are deployed, the hijacker need to compromise a few more secondary signers as well.
• Losing the primary signer: In this situation the wallet owner must carry out the recovery process to get the wallet back.
• Losing a secondary signer: The configuration for the secondary signer must be recovered. If multiple secondary signers are deployment, the loss of a single secondary signer may not be critical.

Outsourcing Signers to Ai-Fi

A secondary KSM signer is to perform the following:

1. To receive requests from the primary signer. At the outset of the threshold signing session, the primary signer makes request to the secondary signer carrying the "identity" public keys of both the primary signer and the secondary signer

2. To authenticate the primary signer

3. To retrieve the assigned/defined configuration based on the public key of the secondary signer, which contains:

   • Secondary signer's identity key pair
   • The primary signer's identity public key
   • The crypto account public key
   • The assigned secret share (private key, partial)

   A PIN must be independently provided to enable the retrieval of the configuration (to prevent the unauthorized requests from a compromised primary signer)

4. To respond to the challenge of its own identity

5. To carry out the signing in corporation with all other signers

Note that the threshold signature configuration for the primary signer is stored in a Portable Krypton Token, protected by a passphrase of arbitrary entropy, which is considered indestructible. The secondary signer expects an independent PIN to defend the unlikely event of the primary signer being compromised.

A secondary signer may be hosted on different platforms, including the Ai-Fi HomeServer and other mobile devices for full privacy and protection. The Ai-Fi.net also provides the hosting for the secondary signers as a service, assisted by the Ai-Fi Incognito Cloud supporting all variety of Krypton Tokens for tremendous usability. This flexibility in its deployment without being constrained by a piece of hardware, to be held in person when needed, is just one of the nice features of our "KSM".

Krypton Wallet Recovery

TBD

Trezor

Initialization

1. Bring up the web wallet through:

   • Web wallet app, or
   • Trezor extension for Chrome.

   Enter device label.

   Since there is no secret kept in the (software) web wallet, it is not considered vulnerable to virus or Trojans on PCs.

2. Plug in the Trezor USB device. Define the PIN.

3. Create the wallet by having the device create the 12-word or 24-word recovery passphrase; verify it.

Note that the PIN is entered through the web wallet, and therefore attackable. (Newer version defines and enters the PIN on the device itself directly). The recovery passphrase is displayed on the device only. The obvious vulnerability is the side channel attacks in case the hardware wallet is stolen or lost. "Initial product delivery Phishing" is also a known threat.

Access of Wallet

1. Bring up the Trezor web wallet
2. Enter the PIN for the device to enable the "software wallet" (Chrome extension or independent app).
3. The Trezor Wallet is now accessible, with private keys stored in the Trezor device itself.

Aside from the physical security of the device itself, the PIN is the only protection.

Krypton Wallet

(I will re-design this pic more to suit our Threshold Signature, such as make the transactions more "Blockchain". Let me know if you have better ideas.)

Threshold Signature Settings (Key Generation)

1. Bring up the Endorsement app for the secondary signing agent through:

   • Web wallet app, or
   • Krypton Wallet extension for Chrome.

   Enter device label.

2. (First time) Within the Endorsement app, enter the Passphrase for protecting the signer secrets either in the Incognito cloud or a HomeServer. Display "Waiting to be initialized by the Primary Signer", which needs to be confirmed with a QR code.

3. On Ai-Fi Central Wallet app, the primary signer triggers the key generation process and initializes (Key-Gen) the endorsement configuration for the secondary signer agent.

This secret sharing process may be renewed by deleting the existing secret shares and carry out the key generation again.

Threshold Signature Signing

1. Bring up the Endorsement app for the secondary signing agent through:

   • Web wallet app, or
   • Krypton Wallet extension for Chrome.

   Enter device label.

2. Within the Endorsement app, enter the Passphrase for opening the signer secrets. Display "Waiting to sign transactions" with a QR code.

3. On Ai-Fi Central Wallet app, conduct the crypto transactions. The signing processes on both the wallet app and the Endorsement app must be independently acknowledged and "signed".

Krypton Vault Interfaces

Krypton Vault Desktop

Krypton Vault Under Ai-Fi Central

Cobo Vault App (Wallet App)

1. Bind to a Krypton Vault (Desktop)

BlueWallet

1. Import the Cobo wallet from Cobo Vault
2. "This wallet is not being used in conjunction with a hardware wallet ....": Enable the Krypton Vault

Threshold Signatures via a Dealer

General

There are two components in the Ai-Fi Threshold Signature scheme:

1. The Ai-Fi Krypton Vault app in Ai-Fi Central as the entry to the Threshold Signature logic

2. For the 2-party case, the secondary signer may be self-managed or delegated to Ai-Fi Incognito Cloud.

3. The Krypton Vault Desktop: This is the component that bridges the primary and secondary signer with three configuration options:

   • The Krypton Vault storage (protected by a Krypton Token) hosted on Ai-Fi Home Server
   • The Krypton Vault storage (protected by a Krypton Token) hosted on Ai-Fi Incognito Cloud
   • The Krypton Vault storage (protected by a Krypton Token) hosted on a user disk

4. The Krypton Vault storage (protected by a Krypton Token) hosted on a bootable USB stick

   Note that there are two separate vault storages, one for the primary signer and another for the secondary signer, each protected by their respective passphrase for protecting their Krypton Tokens. Both passphrases must be presented in order to recover the vault.

Assumptions

1. Only the 2-party or 3-party case is considered, both owned and operated on by a single "dealer".
2. During the key-gen stage, the shares for the private key are independently created by the participating parties. The private key itself is never fully formed at any time during the operation of the scheme, including the key-gen phase. The backup of this Threshold Signature scheme involves all the data sourced from individual participants collected by a central agent without formally forming the common private key itself. The Threshold Signature scheme would guarantee the integrity of the key pairs (the public key and its distributed shares).
3. All participants are interconnected privately and securely. The "dealer" relies on an authentication scheme for identifying the participants.

Threat Model

• Loss of primary signer due to theft
• Loss of secondary signer due to theft

Key Generation and Backup

At the successful completion of this phase, Each participant creates their respective Krypton containing:

• The identity (public) key of their counterparts (for authentication)
• The public key of the protected Bitcoin.
• The respective local (secondary) key share for the corresponding Bitcoin private key.

Krypton Vault Backup

TBD

Signing (2-party)

The primary signer is hosted in Ai-Fi Central. The secondary signer is implemented in a standalone bootable USB stick.

1. Boot up the secondary signer, which requests for the passphrase for the Krypton Token. Once the Token is successfully opened, the secondary signer displays the "binding" QR code.
2. The primary signer scans the binding QR code to authenticate the bond established during the Key Generation.

Hardware Wallet Threat Model

======================================================================================

Counterseal Wallet & Threshold Signature Technology

Counterseal

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 use of a counterseal, involving two separate seals where a second seal is imposed upon the reverse of a main or usually larger seal, was doubtless to prevent the removal of a seal from one document and its transfer to another for fraudulent purposes. Removal or incorrect application of any one of the two seals would invalidate the sealed records.

Our application of the latest Threshold Signature technology to the Ai-Fi Counterseal Wallet is the modern software realization of the ancient counterseal scheme where the two associated seals are kept separate and independent in order to avoid single points of failure. In the context of the cryptography, the individual "seal" is implemented by a pair of crypto key shares each consisting of a private and a public components. The public components of all seals jointly produce the public key for the wallet, whereas the private key shares are physically distributed in multiple locations or devices without ever being joined for producing the private key. Those private key shares are therefore never exposed and used only for producing "signature shares" which are pieced together at the end of signing rounds to create the transaction signatures for the wallet.

The Hardware Wallet may be considered as the ancient single seal solution prior to the invention of "counterseal" with all the perils in over-relying the hardware. In the following we will first describe how the Counterseal Wallet is configured at start-up and how the signatures are obtained by applying both seals. After the operation description, we offer a threat model for comparing the hardware wallet with out counterseal scheme.

Ai-Fi Counterseal Wallet Architecture

The Ai-Fi Counterseal Wallet is actually a "vault", which supports various Bitcoin wallets through HWI (Hardware Wallet Interface). Currently we offer a working version supporting the open source BlueWallet as a demo by taking advantage of its support for HWI.

The operations of Ai-Fi Counterseal Wallet is diagramed above, with the Primary Seal working with the wallet and secrets kept in the leading part of the Vault and Secondary Seal the cooperating partner on a separate device. The word "seal" is adopted here to indicate the protection afforded by the secret shares kept by two separate signing parties, which is not to be confused with the crypto key pairs. Both seals must be present and online in order to successfully assemble a signature for conducting blockchain transactions. We sometimes use "seal" and "signer" interchangeably.

We use the mobile phone as the "leading" partner in our version of the Threshold Signature logic. Note that the wallet diagramed here (BlueWallet in the first release) is "watch only", which is not able to conduct transactions without the participation of both seals in generating the required signatures. The Secondary Seal is to run on a separate device, "signature only" without the means to affect the terms of any transactions. Even if the secondary seal was compromised, the worst damage would be the denial of service without the possibility of producing incorrect transactions or losing crypto tokens.

The software for the Secondary Seal runs on standard PCs or desktops. For peace of mind, we also offer a highly secured "live Linux" 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 OS. The link between the primary and the secondary is further protected by TLS.

Configuring Counterseal Wallet

The Ai-Fi Counterseal Wallet is a special "2 of 2" realization of the threshold signature scheme, with the primary seal (signer) and the secondary signer belonging to the same owner or under the same administrative domain. The secondary signer is equipped with a screen to display the QR code for various interactions with the primary, which is an mobile app running on either the iOS or Android mobile phones. Both signing parties are on the same LAN (at least during the initial binding rounds). The "binding" of those two signers is established according to the principle of TOFU (Trust On First Use) by the primary scanning the binding QR code displayed on the secondary signer if not already bound. After the successful completion of the binding 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):

1. Secret Share Generation: Each signer independently generates its own sub-share 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 required for signing. Only signature-related information are exchanged among the parties during subsequent rounds.

2. Secondary Signer Deployment: Once the involved parties are securely bound to each other and all key shares are synchronized, those two signing parties don't need to be online or connected until the signatures are required. The following are popular configuration options, each requiring specific software implementation:

   • Secondary signer on generic PC platforms
   • Secondary signer installed on a USB stick running live Linux TAILS
   • Secondary signer installed on a standalone Raspberry Pi Zero. This is the lowest cost DIY device with a LCD display on the open market that supports the secondary signer. We don't want to become a suspect in the "Supply Chain Attack".

   These are examples of implementation platforms for the secondary signer, each with its specific vulnerabilities. However, the built-in redundancy has substantially enhanced the tolerance for faults or attacks. Unless it is thoroughly compromised, the Zero Knowledge proof built into the Threshold Signature scheme would discover the incident and report/log accordingly.

3. 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. 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 front end of the counterseal vault and operates 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.

The Primary and Secondary Signer/Seal

As far as the risks go, you may want to examine part of the risk model involved in our choice of signer placement.

BIP32 Compatibility and Backup of Seeds

Ai-Fi Counterseal Wallet is not completely BIP32 conformant, but it follows the BIP32 convention on the account level and supports multiple "accounts", each of which is composed of a single external keypair chains. Only hardened keys are supported.

Internally the Ai-Fi Counterseal Wallet/Vault does not store any private keys and therefore there exists no counterpart of BIP 32 Master Seed and Master Node in the counterseal scheme. As a consequence an Ai-Fi Counterseal Wallet may not be exported. Ai-Fi does support a backup procedure based on a backup Ai-Fi Krypton Token including secrets from both the primary signer and the secondary signer.

Connecting to a Full Node

TBD (Ai-Fi Central required?)

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, according to one report. None of the hacks have taken place on the blockchain itself. As far as thieves are concerned, exchanges are where the money is. All low hanging fruits for hacking are concentrated with popular exchanges and other commercial enterprises offering cryptocurrency services. Protecting one's crypto assets is an exercise of how not to trust or rely unnecessarily on 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 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 seeds. Since recovery seeds are less frequently applied, they have 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 Tamper-Proof 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 "taper-evident technology" is nowhere close to perfection, which is well documented here, here, and here. 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 compromised. A YouTuber has dedicated a series of videos titled "Hardware Wallet Research" investigating this particular issue which we found illuminating and quite enjoyable to watch.

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 tampering in our Counterseal scheme is greatly reduced by requiring joint actions from multiple devices (at least two "factors", or multiple points of services). 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. The Threshold Signature scheme is one of those glorious achievement of technology such that adding additional components to a system actually enhances its overall reliability and fault tolerance. This is not to mention that Ai-Fi Counterseal Wallet does not store its seed within the wallet itself, which is the weakest link in the hardware wallet operations.

We will demonstrate in later sections how the Ai-Fi Counterseal Wallet answers the requirement of Tamper Resistance.

The Standard Configuration

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

• No single points of failure
• Trustless and provable security based on open source software
• The protection of the configuration data, if adopting the Ai-Fi Krypton Token mechanism, is of a 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.")
• Having one's own Bitcoin Full Node if the Ai-Fi HomeServer is adopted.

The actual deployment of the counterseal scheme involves some tradeoff consideration:

1. There is no choice on where the Primary Seal is placed. The 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 strong enough to ward off almost all the malware on iPhone that are critical to our wallet (even Norton, the security company, states "... thanks to Apple's safety precautions, it is extremely rare...").

2. Make sure the platform where the Primary Seal runs on is not "jailbroken", and not managed through an Enterprise App Program that bypasses the rigorous Apple App Store review.

3. 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 Zero. This is the lowest cost DIY device with a LCD display on the open market that supports the secondary signer. (We don't want to become a suspect in the "Supply Chain Attack".)

   These are examples of implementation platforms for the secondary signer, each with its specific vulnerabilities. Obviously the live Linux on a USB stick and the Raspberry Pi hardware are much less likely to contract malware.

We believe that the DIY route is the only way to gain your peace of mind. "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 independently at one time is extremely low, and less likely still when certain attacks of physical natures are required if mobile devices are chosen to host both seals. We are in the opinion that this risk is lower than most other wallets on the market, be it software or hardware.

That's why we recommend to all users of Ai-Fi Counterseal Wallet creating their own wallet in order to eliminate our reliance on any third parties. The production is not complicated once they understand the architecture diagramed in previous section.

###

###

; when the wax was impressed on one side only it was possible to cut away the face of the seal with a heated knife, but when the wax was impressed on both sides this process was rendered considerably more difficult.