This article will first explain wallet recovery interoperability and how to check if your existing wallet is interoperable in case you lose your wallet and need to recover from the backup file. Then, we will go through the steps to use Wasabi for your Coldcard (or other hardware wallets) through a USB cable connection and in the air-gapped method.

What is Bitcoin Wallet Recovery Interoperability?

Bitcoin is a decentralized network, so there’s no one else responsible for your funds besides you. For this reason, when setting up a Bitcoin wallet, you must create a backup. There are many backup formats, ranging from rare methods like .dat files for Bitcoin Core to the popular BIP39 mnemonic seed phrases.

If you ever lose your hardware wallet, you want to ensure you can recover your funds on a new wallet. Bitcoin Wallet recovery interoperability is the ability to recover a wallet from your backup phrase into another wallet. Remember that you should avoid recovering the backup of a hardware wallet in another wallet unless it’s strictly necessary. When backing up your hardware wallet, you will notice that they all use the most common backup standard, a BIP39 mnemonic seed phrase. However, this isn’t sufficient enough data because there’s a follow-up concept called the wallet derivation path.

Modern Bitcoin wallets are Hierarchical Deterministic (BIP32), meaning they have many addresses that can be derived from the master key by specifying a path. A wallet derivation path is a sequence of fields used to organize a wallet in a multi-currency, multi-account, and multi-address system.

m / purpose’ / coin_type’ / account’ / change / address_index

Wasabi Wallet uses BIP39 mnemonic seed phrases as a backup method and the derivation path can be either m/84’/0’/0′ or m/86’/0’/0′ (since version 2.0.3).

How to Check if My Existing Wallet Backup is Interoperable?

In the past, the process of checking wallet backup interoperability was very complex: you had to check the documentation or sometimes the codebase of each wallet to find the wallet derivation path. Thankfully, this data is all documented nowadays on Wallets Recovery maintained by Rodolfo Novak (NVK), CEO at Coinkite, Coldcard’s manufacturer.

Most Bitcoin wallets and their respective information on the supported derivation paths, bip39 passphrase support, and links to their documentation are on the website. For example, we can observe that Blue Wallet and Green Wallet’s recovery is interoperable with Wasabi’s. On the other hand, Electrum isn’t because it doesn’t use BIP 39 mnemonic seed phrase as its backup method.

Now that we’ve defined wallet recovery interoperability and how to check for it, we want to accentuate the importance of backing up correctly your bitcoin wallet. We can proceed to the tutorial on connecting your hardware wallet to Wasabi Wallet.

How to Connect Your Hardware Wallet to Wasabi Wallet

For this section, we will show two methods of integrating your hardware wallet into Wasabi Wallet, in this case, Coldcard. The first one is with the hardware wallet connected to the computer, basically the same for other hardware wallets such as Trezor or Ledger. The second one is with the Coldcard air-gapped.

Method 1: How to Connect your Coldcard (or other Hardware Wallets) to Wasabi Wallet

We assume you have downloaded and installed Wasabi which you can do by following the steps listed here for Windows, Linux, and MacOS. There’s no need to check for recovery interoperability; you only need to ensure Wasabi Wallet supports your hardware wallet (list here). Here are all the steps to accomplish this:

1. Open Wasabi Wallet by clicking on its Application Icon, which looks like this.

2. When the Application opens, click ‘Add Wallet’ on the sidebar.

3. Click on ‘connect to hardware wallet‘ when the new smaller window opens.

4. Give a name of your choosing to your new wallet. Click on ‘Continue’ when done.

5. Connect your Coldcard (or another hardware wallet) to your computer and unlock it with the PIN. Click on Rescan when your device is ready.

6. Wasabi will detect your hardware wallet. Click on Yes if it’s correct.

7. A success confirmation message will appear. Click on Done.

You have successfully integrated Wasabi Wallet with your Coldcard (or another hardware wallet). You simply have to wait for syncing to complete. Let’s proceed to the Coldcard air-gapped tutorial.

Method 2: How to air-gap your Coldcard transactions with Wasabi Wallet

To complete this method, first, export a wallet file from Coldcard onto a MicroSD. Then, you need to import this file into Wasabi Wallet. Exporting it this way ensures that there’s never a physical connection between your Coldcard hardware wallet and your computer.

Steps to reproduce on Coldcard

1. Insert a microSD into your Coldcard’s slot.
2. Power the Coldcard and unlock it with the PIN.
3. On the main menu, select Advanced.
4. Select MicroSD card.
5. Select Export Wallet.
6. Select Wasabi Wallet.
7. Follow the instructions shown on the screen to complete the file export.
8. Safely remove the microSD from your Coldcard.

Steps to reproduce on Wasabi Wallet

1. Insert the microSD into your computer’s slot.
2. Open Wasabi Wallet by clicking on its Application Icon, which looks like this.

3. When the Application opens, click ‘Add Wallet‘ on the sidebar.

4. When the new smaller window opens, click on ‘Import a Wallet‘.

5. You will be prompted to select the wallet file from your microSD.

6. A success confirmation message will appear. Click on Done.

You’ve successfully integrated Wasabi Wallet with your Coldcard air-gapped. You simply have to wait for syncing to complete.

Conclusion

This article explains that Bitcoin wallet recovery interoperability applies not only on the wallet backup level but also on the wallet derivation path. Wallets Recovery is a tool to check if your existing wallet backup is interoperable with Wasabi Wallet.

This article presents all the steps to the two methods that exist to connect your Coldcard (or another hardware wallet), through a USB cable connection or the air-gapped method, to Wasabi Wallet.

The post How to Connect Your Hardware Wallet to Wasabi Wallet appeared first on Wasabi Wallet - Blog.

If you’re considering using Wasabi or already have, installing malicious software from a scam website that can steal your bitcoin is the last thing you want. So what are Wasabi’s code signature strategies which can allow you to verify the authenticity of the software? For Windows and Mac, Wasabi uses the respective code signing standards that depend on centralized certificate authorities for signature validation. For every OS (Linux included), you can verify the release signature using PGP but should validate that the PGP key is really in the hands of Wasabi by leveraging a concept called Web of Trust.

This article will explain how Wasabi Wallet’s three code signing strategies (Windows, MacOS, and PGP) work and how they compare in terms of user experience, trust models, cryptography, and certificate subscription/expiry. Then, we will explain deterministic builds, why they are important, and how MacOS code signing ruins it for their platform. Finally, we will touch on Wasabi Wallet’s automatic software updater, which is only available for MacOS and Windows and employs code signature verification before installing the new release.

What is Code Signing, and Why is it Important?

The power of code is limitless. It can be used for good or malicious intent, so you should always be careful what software you install on your devices. This applies particularly if you’re interested in bitcoin, privacy, and security, which we assume you are, given that you’re reading this. This section will explain code signing and its cruciality for secure software development and distribution.

When you install open-source software on your machine, you can do it by compiling it from the source code, and you can read every code line to ensure that you understand what is happening on your machine. However, this is an extremely long and complicated process. In most cases, you might trust the open-source software development process and the team behind it, so you accept to install their compiled releases. The question now becomes, how can you ensure that you’re installing the original release?

Code signing fixes software authenticity validation by leveraging cryptography. It allows you, as a user, to verify that the binary you’re about to install on your device matches the one released by the software development team by comparing code signatures. We will examine how it works in Wasabi Wallet strategies: Windows, MacOS, and PGP.

How does Wasabi Wallet’s Windows Code Signing Work?

Operating system platforms like Microsoft’s Windows have a standard format to code signing, and Wasabi Wallet’s security engineering management team follows that. Authenticode is the platform’s code-signing technology to identify the publisher of signed software.

When a new version is released, the team uses SignTool to sign the .msi installer with an EV (Extended Validation) digital certificate issued to zkSNACKs LTD, the company maintaining Wasabi Wallet’s software development by Digicert Inc, a renowned CA (Certificate Authority).

To obtain the hardware token-protected certificate, zkSNACKs LTD underwent a multi-step identity verification process. The release gets signed with the SHA-256 algorithm, and this action is timestamped to Digicert’s servers. The current certificate was issued on February 15th, 2023, and expires on February 15th, 2025.

Now that we’ve established Wasabi Wallet’s Microsoft code signing strategy, let’s move forward to the other proprietary operating system platform, MacOS.

How does Wasabi Wallet’s MacOS Code Signing Work?

MacOS code signing policies are even stricter than Windows; there’s only one option available for Wasabi Wallet’s team. They have an Apple developer account on Xcode, where Apple Inc issues a developer ID certificate that signs every release. The signed package of files is sent to Apple, which signs it, too, creates a .dmg binary, and sends it back.

zkSNACKs signs the newly created .dmg binary, and it’s sent back to Apple for a final signature and notarization, in which they run many security tests on the code. Every signature uses the SHA-256 hashing algorithm.

The final code signature strategy Wasabi Wallet’s team employs is PGP code signing, which we’ll look at now.

How Does Wasabi Wallet’s PGP Code Signing Work?

Since Linux is a libre open-source operating system, there’s no standard code-signing method for your software to pass the system’s security checks. Wasabi Wallet uses the PGP (Pretty Good Privacy) standard for code signing on Linux, but it’s also available as an additional security verification step on MacOS and Windows.

PGP is an encryption program to sign, encrypt, or decrypt text, files, e-mails, etc. In this case, Wasabi Wallet’s security engineering management team uses PGP to sign their releases for all three major operating system platforms with RSA 2048-bit keys. Wasabi Wallet’s current PGP key fingerprint is 6FB3872B5D42292F59920797856348328949861E, and it is valid from the 22nd of August 2019 to the 24th of February 2028.

A user verifies the code signature by importing zkSNACKs PGP public key, downloading the latest version and the corresponding signature file, and verifying that everything matches. Find out more on how to do this here. Now that the details of each code signing strategy employed by Wasabi Wallet’s team are understood, let’s compare them.

How Do Wasabi Wallet’s Code Signature Strategies Compare Between Them?

This section will compare all three code signing strategies regarding cryptography, user experience, trust models, and certificate subscriptions/expiry. First, for Windows and Mac, Wasabi Wallet uses SHA-256 as a hashing algorithm to sign the releases. For PGP, it is RSA 2048-bit keys that sign the code binary.

As a user, your experience is about the same when verifying signed releases; it’s all done automatically by your operating system during installation. On the other hand, PGP requires manual verification by importing zkSNACKs public key because it doesn’t depend on a CA (Centralized Authority) for certificate issuance, which brings us to the next point.

The trust model of PGP makes it unique compared to the other two code-signing strategies employed by Wasabi Wallet. Windows and Mac code signing depend on a CA for certificate issuance, so a user must trust that centralized entity’s legitimacy. Wasabi had a choice between many CAs on Windows, but on MacOS, you have to use the computer manufacturer and operating system developer, Apple Inc, for certificate issuance.

For PGP, the trust model simply relies on the legitimacy of the public key. How can you be sure the software development team behind Wasabi’s Wallet owns this key? To answer this question, the Web of Trust model comes into play; users must sign each other’s public keys to establish trust. Many developers have signed zkSNACKs public key with their own PGP key, so if you can physically verify the ownership of one of those PGP keys, you can trust the legitimacy of zkSNACKs PGP key. This step is optional, but you can never be sure by skipping it, and you’re under a false sense of security.

Finally, since PGP doesn’t rely on a centralized authority, it requires no permission, and its expiry date is fully customizable: in Wasabi’s case, it lasts eight years, six months, and two days. Companies like zkSNACKs can buy DigiCert-issued windows code signing certificates for 1, 2 (Wasabi’s case), or three years, costing 570 to 699 USD a year. MacOS developer accounts cost 99 to 299 USD for a yearly membership, and the key expiry date is not on the binary signature.

Now that we’ve compared the three code signing strategies used at Wasabi for releases, let’s explain what a deterministic build is, why it is important, and how MacOS code signing limits it for their platform.

What is a Deterministic Build, And Why is it Important?

Open-source software released as binaries, such as Wasabi Wallet, is signed to ensure its authenticity to the users. However, how can a user or a security auditor ensure that the binary releases match the code repository? Deterministic builds fix precisely that, and they’re essential to an open-source community to create an independently-verifiable path from source to binary code.

To build Wasabi Wallet deterministically, you must follow many steps, such as asserting the correct environment by having the same operating system and installing identical software package versions. You must then reproduce and verify builds by comparing them with the binary code. The deterministic build process works well for Windows and Linux releases, but users can’t do it for macOS because of the code signing.

How does MacOS Code Signing Limit Deterministic Build?

Unlike Windows, the binary file stores the MacOS code signature. When trying to build Wasabi Wallet on macOS deterministically, a user won’t be able to verify that the source code matches the .dmg release because he doesn’t have the certificate to sign it. However, since Wasabi Wallet’s version 2, every release includes a macOS .zip folder that one can reproducibly build with the source code.

We proceed to the final section before concluding this article: Wasabi Wallet’s automatic software updater.

What is Wasabi Wallet’s Automatic Software Updater?

On Windows and MacOS, you can turn on Wasabi Wallet’s automatic software updater. When a new update is available, the latest version will automatically download and install by the update manager. Since this isn’t a fresh install, Wasabi Wallet’s three code signing strategies aren’t employed. However, this remains safe because the code’s signature is cryptographically verified before the update.

How does the Update Manager Validate the Code it Installs?

The update manager downloads the SHA256SUMS.asc and SHA256SUMS.wasabisig files, and on line 215 of this code file WasabiSignerHelpers.VerifySha256SumsFileAsync is called to validate the signature. Then on that function in the WasabiSignerHelpers code file, the content and signature files are read and evaluated to match the constant Wasabi’s Public Key on line 38.

In simple terms, the binary hash and the digital signature are downloaded, and then, the code verifies that Wasabi’s signature matches the hash, and matches the public key saved in the previously installed version. This key set differs from all other code-signing keys used; it uses the same cryptography as Bitcoin.

Conclusion

In this article, we explained what code signing is, why it is essential, and what the three code signing strategies used for Wasabi Wallet’s releases are, which we compared in terms of cryptography, user experience, trust models, and certificate subscription/expiry. Then, we defined what a deterministic build is, why it is important, and how MacOS code signing clashes with it. Finally, we describe the code signature verification happening when automatically updating Wasabi.

PGP code signature verification is recommended to all users, even those on Windows and Mac, because, unlike the other code signature strategies, it is trustless if employed correctly by leveraging the Web of Trust and physically validating a key that has validated the zkSNACKs key. It is also essential to be wary of scam websites, which might resemble the domain name.

You should only install software from the official website https://wasabiwallet.io and the official onion service.

The post What are Wasabi Wallet’s Code Signature Strategies? appeared first on Wasabi Wallet - Blog.

But regardless of how they’re built and to which extent their security is transparent and auditable, all hardware wallets should work very well with Wasabi. Not necessarily because the wallet software is maintained in a way which adds support for every new hardware release (though you can find separate optimizations for the Ledger Nano and the Coldcard), but by virtue of Andrew Chow’s HWI (Hardware Wallet Interface) library.

As described by Max Hillebrand on the Bitcoin Takeover Podcast, HWI is a powerful tool which allows Wasabi to keep up with the latest hardware developments wallet and provide privacy by default to a greater number of users. Unlike popular user interfaces such as Ledger Live, Trezor Suite and BitBoxApp, Wasabi wallet offers Tor routing by default, easy UTXO management (also referred to as “Coin Control”), and a trustless onboarding via automatic full node connectivity or block filter download. No other popular hardware wallet interface comes with all of these features enabled by default and there always seem to be tradeoffs and compromises involved – yet Wasabi is perfect to manage your single-sig setup.

But what about the future of hardware wallets? The devices that anyone can build and are 100% auditable? In the case of the Trezor, we expect the Tropic Square project to deliver transparent open source secure element chips by the end of 2022 – a rather ambitious promise which, if executed well, can turn into a game changer for the entire industry. And given Trezor’s excellent documentation and support, it’s very likely that the HWI libraries will get updated to support the new Trezor as soon as it gets launched.

In the case of DIY hardware wallets like Specter, SeedSigner and Bowser, there should be no compatibility issues. Specter uses PSBT, which means that you can use the wallet in the same way you would do with a Coldcard or a KeyStone. On the other hand, SeedSigner and Bowser are air gapped devices which deal with QR codes and offline signatures. You shouldn’t have any kind of problem when you plan to send or receive to Wasabi.

We’re living truly remarkable and exciting times when free markets prove their efficiency in making hardware wallets more efficient, more affordable, and accessible to non-technical people. Anyone who can afford a $5 Raspberry Pi Zero can build his own SeedSigner, while M5Stack enthusiasts can put together a Bowser wallet in only a few minutes. But as Trezor co-founder and CEO Slush mentioned, hardware will always lag behind software development. And Wasabi, as a software wallet which integrates the right tools to support hardware wallets, is part of this trend of being ahead of the curve. No matter what the future of hardware wallets holds, Wasabi will provide a stable and privacy-friendly interface which maximizes user sovereignty.

The post Wasabi and the Future of Hardware Wallets appeared first on Wasabi Wallet - Blog.

The Wasabi Wallet team’s timeline as well as explanations given to address the issue are detailed in this post.

The problem has been resolved, and the system servers are back online.

What happened?

Wasabi Wallet team received an alert email from the hosting server on June 6th, 2021, or approximately 16 UTC, informing us that we were experiencing a massive DDoS attack and that, for security reasons, traffic will be analysed to assess the extent of the attack.

In a Distributed Denial of Service attack, the incoming traffic flooding the victim originates from many different sources (like a botnet). This effectively makes it impossible to stop the attack simply by blocking a single source or IP.

Timeline (UTC)

• About 16:00:00 – DDoS attack started
• 16:02:17 – We received a message from our server host regarding Denial of Service Notification
• About 16:04:00 – Due to the size and scale of the DDoS, network connectivity of the server was automatically and temporarily suspended for 3 hours in an effort to mitigate the attack
• 16:05:31 – Received a “Connection timeout” alert about a period of downtime from Uptime Robot
• 16:08:26 – Wasabi team detects DDoS attack and starts communication in a private channel
• 16:13:13 – Server shutdown
• 17:23:28 – Wasabi team started an Emergency meeting
• 19:03:18 – Server goes back online after 3 hours as scheduled – Wasabi Wallet team starts to implement security measures to mitigate the DDoS and cut off the attacker
• 19:04:02 – Received alert about partial restoration of services from Uptime Robot
• Between 19:04:02 and 20:45:38 – Wasabi Wallet team heroically defends the server by implementing security measures while still being attacked by the botnets of zombie computers
• 20:46:03 – The security measures seemed to stop the attack, but later investigation found no causal relationship between the attack stopping and the hotfixes

Some data about the DDoS attack:

Attack intensity: several million packets per second (Mpps)
Bandwidth involved: several Gigabits per second (Gbps)
Total downtime: 4 hours and 42 minutes

Conclusion

Wasabi Wallet is a well known non-custodial wallet. This means that the users are always in control of their private keys and thus, their funds. When running Wasabi for the first time, the user is given a piece of information called a “seed” and is instructed to write it down to recover their funds in case of an emergency. Also, the user can always export single private keys belonging to single addresses to recover specific UTXOs (Unspent Transaction Outputs). Users always have complete control over their funds through their private keys.

Hence, Wasabi Wallet users’ funds were always safe throughout the entire attack,. The downtime only affected Wasabi Wallet backend services like:

• wasabiwallet.io website
• CoinJoin feature
• BIP-158 Block Filters sync
• Fee estimation
• In-software USD dollar exchange rate

DDoS attacks are a serious thing and it’s really difficult to fully defend against this type of attack.
Satoshi Nakamoto left the Bitcoin community ten years ago on December 12, 2010, with his final message about adding some DoS (Denial of Service) features saying that “there’s more work to do on DoS”.

Cyber attacks are an inevitability. They will always exist and sadly, no one has the ability to halt or control them. There is still a lot of work to be done to continue maintaining the security of Wasabi Wallet. Wasabi Wallet makes it a top priority to protect users from similar threats and thus, Wasabi Wallet’s team is constantly working to provide the highest level of security and privacy.

The post WVE–006 DDoS Attack Report appeared first on Wasabi Wallet - Blog.

Usually, a Bitcoin node broadcasts not just the transactions of its user, but it also gossips all of the other transactions that it has received from its peers. Thus it is very difficult to find out which transactions originated from which node.

However, when a node does not gossip all transactions, but only the transactions of its user, like in the case of a light wallet, then it is easier to find out which node has sent those specific transactions.

Bitcoin Full Nodes

When you run your own full node, you can precisely verify if the bitcoin you receive are actually valid. When you do not verify this for yourself, then you need to ask another trusted third party how much money you have.
Regardless how you ask this other server, there is now more metadata available to potentially link your coins to your identity.

There are bad ways to communicate, like querying a block explorer over clearnet, and good ways to communicate, like using BIP 158 block filters over Tor. But regardless, running your own full node means that you don’t need to communicate with anyone about your specific coins and this is strictly better.

Bitcoin Transactions

When you make a Bitcoin transaction, you are essentially creating a message on your device and sending it to the Bitcoin network. Someone operating a large number of nodes on the Bitcoin network might be able to match some of your transactions to your IP address, then deanonymize your stack of bitcoin.

It is relatively easy to avoid this on a computer by relaying all transactions through the Tor network. Wasabi routes all traffic via Tor’s SOCKS5 proxy, by default. This means that by default, all network communication is secured from outside snooping and the IP address is hidden.

Wasabi and Tor

Even if no full node is installed, Wasabi has a light client mode based on BIP 158 block filters. The Wasabi coordinator’s v3 onion service sends a filter of all the transactions in each block to all the users over Tor. Then, users check locally if the block contains any transactions with their addresses. If not, then the filter is stored for later reference, and no block is downloaded.

However, if there is a user transaction in that block, then Wasabi connects to a random Bitcoin P2P node over Tor and asks for this entire block, not just one transaction. This block request is indistinguishable from the regular P2P gossip, and thus nobody, neither the server nor the full node, knows which addresses belong to the user.

All Wasabi traffic is tunneled through Tor. Wasabi connects only to onion nodes, so end-to-end encryption is enforced between the wallet and peers. All this without involving any exit node. Wasabi connects to each peer through a different Tor stream. A new Bitcoin peer is chosen for every transaction broadcast.

Tor Consensus Issues

On January 10, 2021, due to an implementation bug, Tor’s v3 onion services experienced instability. A bug fix is already on the way, but until the update you may experience connection problems and delays.

Normal Tor circuits (using exit relays) still work, and v2 onion services still work, but v3 onion services (like the one used for the Wasabi coordinator) are affected and may not publish descriptors, and clients won’t fetch them.

Fallback Scenario

As we said before, all Internet traffic goes through Tor, and by default all this traffic stays inside the onion network. This means that, in Wasabi coordinator’s case, as v3 services are used to coordinate the CoinJoin transactions, there may have been (or there may be) connection and communication problems.

To ensure service availability, Wasabi Wallet is equipped to offer a fallback scenario where exit nodes are involved. For example, if the Tor onion service of the backend becomes unavailable for the user, the wallet falls back to communicating with the backend’s clearnet endpoint, still over Tor. Wasabi also frequently utilizes multiple Tor streams where applicable.

This allows the user to continue to operate, even in unusual/offline onion backend conditions.
The Tor label inside Wasabi Wallet shows the status of the Tor daemon. You can check that your connection is active by keeping an eye on it.

Who have been affected

Most of our users haven’t noticed any interruptions because Wasabi was able to recover automatically. There were a few users who encountered intermittent Tor connection issues. But in most of these cases, restarting the Tor client solved the problem.

The post Wasabi Wallet and Tor Consensus Issues appeared first on Wasabi Wallet - Blog.

Given the huge correlation between Bitcoin and Tor, the news quickly reached major social media, chat rooms and forums; but there is still a lot of confusion about it.
This article will explain if Wasabi Wallet is affected by the issue and how the technology behind Wasabi guarantees security for its users.

TLDR

1. Bitcoin replacement attacks are not possible due to the architecture of Wasabi.
2. Even if they’d be Wasabi stays inside Tor, except in fallbacks.
3. Even if fallbacks, Wasabi enforces HTTPS traffic, so exit nodes still cannot read or replace the traffic.

Summary of the attack

The entire operation is an MITM (man-in-the-middle) attack to Tor users. This attack tries to manipulate traffic as it flows through (malicious hacker controlled) Tor exit relays. The attackers selectively remove HTTP-to-HTTPS redirects to gain full access to plain unencrypted HTTP traffic without causing TLS certificate warnings.

Specifically, hackers attacked multiple bitcoin mixers. They replaced bitcoin addresses in HTTP traffic to redirect transactions to their addresses instead of the user provided bitcoin ones. By replacing the destination address at the HTTP traffic level, the attackers hijacked the user’s funds without the users’ or the Bitcoin mixer’s knowledge.

Why Wasabi is safe and how it defends itself against this type of attack

It’s simple: because Wasabi Wallet is a non-custodial privacy-focused Bitcoin wallet that implements trustless CoinJoin, there are no addresses sent to a server when sending money.
Also, unlike many other “traditional” mixers where users must give control of their coins to another party and trust that this party will return the bitcoin to them, Wasabi Wallet does not take custody of assets.

When sending money, there is no network traffic saying something like send 1 BTC to bc1qar0srrr7xfkvy5l643lydnw9re59gtzzwf5mdq, so there is no amount or address that can be intercepted and replaced.
In Wasabi Wallet, the user broadcasts Signed transactions. In fact, the wallet broadcasts it to the P2P network using random nodes on the Tor onion network.

During CoinJoin phases, however, an exchange of information about addresses involved takes place.
Specifically, during the input registration phase, this is the data that is exchanged:

• The input coins that you want to register, together with the input proof signature.
• The cleartext change address.
• The cryptographically blinded anonset CoinJoin output.

And subsequently, during the output registration phase, this is the data that is exchanged:

• The cleartext address for the anonset CoinJoin output.
• The coordinator signature over that output.
• The round hash of all the inputs.

But even if an attacker were to carry out an MITM attack by breaking the cryptography that certifies the coordinator signed outputs and replacing an address, the client would not sign the transaction, so no one would be able to hijack the funds.

On the network side, by default and under normal conditions, Wasabi Wallet never leaves Tor onion network and it never uses Tor exit relays.
All Wasabi Wallet’s traffic stays inside the onion network, and most Tor attacks are not possible if exit nodes are not involved.
In Wasabi, exit nodes are only involved in fallback scenarios.

Fallback scenario? What are you talking about?

Let’s give an example: if the Tor onion service of the backend becomes unavailable for the user, the wallet falls back to communicating with the backend’s clearnet endpoint, still over Tor. This allows the user to continue to operate, even in unusual/offline onion backend conditions.
Regarding the website itself, connections are SSL-enforced and HSTS enabled.

Yes, I know, all these acronyms can seem difficult to understand. But just keep reading, and you will see that we will simplify them in the best possible way:

HTTP Strict Transport Security (HSTS) is a web security policy mechanism that helps to protect websites against man-in-the-middle attacks such as protocol downgrade attacks and cookie hijacking. It allows web servers to declare that web browsers (or other complying user agents) should automatically interact with it using only HTTPS connections, which provide Transport Layer Security (TLS/SSL), unlike the insecure HTTP used alone.
(Source: Wikipedia)

Don’t Trust, Verify!

As we mentioned earlier, Wasabi’s fallback servers (Mainnet and Testnet) make use of encrypted connections and enable HTTP Strict Transport Security.

Let’s start Wasabi Wallet, open the config file from the wallet GUI, go to File>Open>Config File.

The first lines should look like this:
"Network": "TestNet",
"MainNetBackendUriV3": "http://wasabiukrxmkdgve5kynjztuovbg43uxcbcxn6y2okcrsg7gb6jdmbad.onion/",
"TestNetBackendUriV3": "http://testwnp3fugjln6vh5vpj7mvq3lkqqwjj3c2aafyu7laxz42kgwh2rad.onion/",
"MainNetFallbackBackendUri": "https://wasabiwallet.io/",
"TestNetFallbackBackendUri": "https://wasabiwallet.co/",

MainNetFallbackBackendUri and TestNetFallbackBackendUri are, respectively, the two clearnet backends for Mainnet and Testnet to which Wasabi Wallet connects in case the two .onion backends are inaccessible.

As you can see, both of them are using secure HTTPS connections.
What about HSTS? For this, we can rely on one of the many tools online that allow you to test if a specific domain/ip has HSTS enabled.
Both of them have HSTS enabled, check for yourself:

• Fallback Mainnet backend test
• Fallback Testnet backend test

Your security, like your privacy, is our top priority

Wasabi Wallet is safe in both, Tor onion network and clearnet.
In addition to this, exit nodes are only involved in fallback scenarios. This type of scenario is extremely rare; and should it happen, we have still adopted all the best practices to ensure the safety of your funds.

Additionally, in a custodial mixer, a passive network attack is really dangerous because the attacker can deanonymize all the users and see all their activity. With Wasabi Wallet, this is not possible because even the Wasabi coordinator cannot deanonymize its users.

Learn more about how Tor works within Wasabi

Using Tor within Wasabi has several facets:

• Wasabi frequently utilizes multiple Tor streams where applicable and registration of CoinJoin inputs and outputs is done through different Tor streams to avoid linking.
• The backend server serves block filters to all the clients over Tor. From those filters, the clients figure out which blocks they are interested in and downloads them [and some false positive blocks] from random peers. One block per peer, and always over a fresh Tor stream.
• Wasabi connects to each peer through a different Tor stream. A new random Bitcoin peer is used for every transaction broadcast.
• Wasabi broadcasts transactions to only one peer over Tor, and immediately after that, the peer is disconnected.
• Every fee query happens over Tor with a new Tor identity.

Do you want to learn more? Visit our documentation pages!

The post Wasabi Wallet and Tor SSL stripping attacks appeared first on Wasabi Wallet - Blog.

If you’re a Wasabi Wallet user with a Trezor device, please don’t update your current Wasabi Wallet installation and Trezor devices to version 2.3.1 (Trezor Model T) and version 1.9.1 (Trezor One) yet or you may get locked out of your bitcoins until we fix the issue. Please update both when we’ve published a new version of Wasabi Wallet through our official channels.

Last Wednesday, SatoshiLabs s.r.o., the makers of the popular Trezor hardware wallet, has disclosed a security vulnerability in the Partially-Signed Bitcoin Transaction specification (BIP-174) that can potentially exfiltrate a victim’s bitcoins by paying too high mining fees, if the vulnerability is exploited.

The vulnerability was fixed on Trezor devices but it broke the compatibility with HWI and other 3rd party software, like Wasabi and BTCPay server. As a result, Trezor devices updated with the newest firmware version 2.3.1 (Trezor Model T) and version 1.9.1 (Trezor One) are not working with Wasabi and other software wallets.

How does this affect Wasabi Wallet users with a Trezor device?

First, before we go into the gory details of the vulnerability, we need to have a primer on how your Wasabi Wallet interacts with your Trezor hardware wallet.

In a nutshell, a Hardware Wallet’s primary function is to hide all the necessary Bitcoin secrets like your private keys away from systems that is inherently more insecure like your PC, Laptop or Smartphone while also allowing the user to receive and spend the coins as they see fit.

It does that by utilizing a Software Wallet that can communicate with the Bitcoin network. Whenever a user wants to spend their coin, Wasabi Wallet will construct a Partially-Signed Bitcoin Transaction (PSBT) and it sends the request to the Trezor device to be authenticated by the user.

After authentication, it sends back a fully signed PSBT to Wasabi Wallet, which in turn broadcasts it to the Bitcoin network, effectively completing the spending transaction.

The latest firmware upgrade of Trezor has deviated from the normal implementation of the PSBT specification in BIP-174. The hardware wallet now expects that all inputs of a PSBT include its prior transaction data. This information is then used to verify the fees paid to the miner, and thus eliminates the attack.

However, this poses a multitude of problems:

• Because the original specification did not specifically allow for additional prior transaction data; The interface layer between Wasabi and Trezor devices strips down that prior transaction data from the PSBT, which in turn makes the Trezor wallet think that the PSBT it received is invalid because of the missing data, hence rejecting its authentication and effectively preventing the user in spending their bitcoin.
• The software wallet may also not have the required previous transaction data from the Bitcoin blockchain and thus it may need to acquire that whilst preserving the privacy of the user. This may be impossible or resource-intensive.
• The PSBT file size might increase significantly in case the input coins was from a CoinJoin or any other large transaction. Imagine if you’ve included 2 coins from your recent Wasabi CoinJoin, the wallet will then need to include the large CoinJoin transaction data twice. The enlarged PSBT could cause problems in transmission to the Trezor device or other hardware wallets that may not necessarily support the large PSBT sizes.

In light of the aforementioned problems, we at Wasabi Wallet are urging our users with Trezor hardware wallets to hold off updating their devices to firmware version 2.3.1 (Trezor Model T) and version 1.9.1 (Trezor One) and also avoid updating their Wasabi Wallet installation until the team can make a proper fix to this issue.

Until then, we hope for your continued patience amidst this issue. Thank you.

Addendum: We are advising users to not update Wasabi Wallet until the fixes are out due to the potential of bad actors distributing a malicious copy of Wasabi Wallet and exploiting the vulnerability.

The post Wasabi Wallet’s advisory for Trezor users appeared first on Wasabi Wallet - Blog.