Security-Privacy-Centric Solution For Anonymous DASH (Masternode) Local Wallet Based On Debian GNU/Linux, VirtualBox, Whonix GNU/Linux Including Tor And Tails – VERSION 0.1.7 [2016-12-03] – STATUS: NOT REVIEWED YET (waiting for APPROVAL/REJECTION)

Dedicated to the 99 percent who don't have the (material) resources but vivid imagination which is more important. Annuit Coeptis Novus Ordo Seclorum dim as exp(i*pi) + 1 = 0

Author: Anonymous https://www.dash.org/ http://www.dashorg64cjvj4s3.onion/ https://dashpay.atlassian.net/wiki/display/DOC/Dash+Security-Privacy+Paper

Copyright: This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License (CC BY-NC-SA 4.0). http://creativecommons.org/licenses/by-nc-sa/4.0/

PREFACE P1 – About this article 1. For clarification purposes you are strongly advised to read the full article. It is quite possible that your questions have already been answered in this document. 2. Do not run software you do not understand. Always ask the community if you have any questions. 3. DASH used to be called Darkcoin (and Xcoin [https://en.wikipedia.org/wiki/Dash_ 1

%28cryptocurrency%29] beforehand). From now on we only talk about DASH [https://www.dash.org/news/darkcoin-is-now-dash/]. 4. Due to formatting restrictions and other reasons no reference list is attached at the end of this article as it is common use. All sources are mentioned directly at the appropriate text passages and are usually indicated with rectangular brackets [source] or highlighted clearly otherwise. 5. This guide is a work in progress and therefore far away from perfect by definition. Please help to improve it. P2 – DASH Mission and Motivation According to the objectives of the DASH Foundation [https://www.dashfoundation.io/about/objectives/] and consequently the long-term goals of the DASH project in general, this article accomplishes the following tasks. - Support Development - Empower the Community - Educate and Promote - Represent DASH The following provides an incomplete list of complex background information with the intend to motivate the average user to actively take part in shaping our future. [(1)] Money is such a routine part of everyday living that its existence and acceptance ordinarily are taken for granted. A user may sense that money must come into being either automatically as a result of economic activity or as an outgrowth of some government operation. But just how this happens all too often remains a mystery. [(2)] In the United States neither paper currency nor deposits have value as commodities. Intrinsically, a dollar bill is just a piece of paper, deposits merely book entries. Coins do have some intrinsic value as metal, but generally far less than their face value. What, then, makes these instruments - checks, paper money, and coins - acceptable at face value in payment of all debts and for other monetary uses? Mainly, it is the confidence people have that they will be able to exchange such money for other financial assets and for real goods and services whenever they choose to do so. [(3)] Changes in the quantity of money may originate with actions of the Federal Reserve System (the central bank), depository institutions (principally commercial banks), or the public. The major control, however, rests with the central bank. The actual process of money creation takes place primarily in banks. As noted earlier, checkable liabilities of banks are money. These liabilities are customers' accounts. They increase when customers deposit currency and checks and when the proceeds of loans made by the banks are credited to borrowers' accounts. In the absence of legal reserve requirements, banks can build up deposits by increasing loans and investments so long as they keep 2

enough currency on hand to redeem whatever amounts the holders of deposits want to convert into currency. This unique attribute of the banking business was discovered many centuries ago. It started with goldsmiths. As early bankers, they initially provided safekeeping services, making a profit from vault storage fees for gold and coins deposited with them. People would redeem their "deposit receipts" whenever they needed gold or coins to purchase something, and physically take the gold or coins to the seller who, in turn, would deposit them for safekeeping, often with the same banker. Everyone soon found that it was a lot easier simply to use the deposit receipts directly as a means of payment. These receipts, which became known as notes, were acceptable as money since whoever held them could go to the banker and exchange them for metallic money. Then, bankers discovered that they could make loans merely by giving their promises to pay, or bank notes, to borrowers. In this way, banks began to create money. More notes could be issued than the gold and coin on hand because only a portion of the notes outstanding would be presented for payment at any one time. Enough metallic money had to be kept on hand, of course, to redeem whatever volume of notes was presented for payment. Transaction deposits are the modern counterpart of bank notes. It was a small step from printing notes to making book entries crediting deposits of borrowers, which the borrowers in turn could "spend" by writing checks, thereby "printing" their own money. [(4)] Such expansion cannot continue beyond the point where the amount of reserves that all banks have is just sufficient to satisfy legal requirements under our "fractional reserve" system. For example, if reserves of 20 percent were required, deposits could expand only until they were five times as large as reserves. Reserves of $10 million could support deposits of $50 million. The lower the percentage requirement, the greater the deposit expansion that can be supported by each additional reserve dollar. Thus, the legal reserve ratio together with the dollar amount of bank reserves are the factors that set the upper limit to money creation. [(5)] All banks together have $10,000 of deposits and reserves that they did not have before. However, they are not required to keep $10,000 of reserves against the $10,000 of deposits. All they need to retain, under a 10 percent reserve requirement, is $1000. The remaining $9,000 is "excess reserves." This amount can be loaned or invested. If business is active, the banks with excess reserves probably will have opportunities to loan the $9,000. Of course, they do not really pay out loans from the money they receive as deposits. If they did this, no additional money would be created. What they do when they make loans is to accept promissory notes in exchange for credits to the borrowers' transaction accounts. Loans (assets) and deposits (liabilities) both rise by $9,000. Reserves are unchanged by the loan transactions. But the deposit credits constitute new additions to the total deposits of the banking system. [(6)] The multiple expansion is possible because the banks as a group are like one large bank in which checks drawn against borrowers' deposits result in credits to accounts of 3

other depositors, with no net change in the total reserves. [Federal Reserve Bank of Chicago, “Modern Money Mechanics - A Workbook on Bank Reserves and Deposit Expansion”, (1994), https://archive.org/details/ModernMoneyMechanics, p. 1, 2, 3, 4, 6, 8] A purely peer-to-peer version of electronic cash would allow online payments to be sent directly from one party to another without going through a financial institution. [Nakamoto, S., “Bitcoin: A Peer-to-Peer Electronic Cash System”, (2008), https://bitcoin.org/bitcoin.pdf, p. 1] The Bitcoin software is completely open-source and anybody can review the code. Bitcoin is changing finance the same way the web changed publishing [and communication as a whole]. [”What is Bitcoin? (v1)”, (2011), https://www.youtube.com/watch?v=Um63OQz3bjo, (00:00:58)] Centralized monetary organizations which are controlling the money supply, the total amount of money and therefore the value of any single monetary unit are way more vulnerable by design in comparison to decentralized systems which do not include a central authority and therefore do not include a single point of failure. The inherent problems resulting through centralization have been shown consistently over the past centuries and have to be fixed now or never since we finally have the revolutionary technology available replacing the inefficient trust based model with a new system based on cryptographic proof solely. The concept of a distributed ledger cannot be uninvented and shutdown so easily. The underlying technology liberates the individual and also enables us to deal with great power which is directly tied to great responsibility, most of us will still have to learn how to handle correctly over the next decades in order to restore natural equilibrium. . We will continue to work together on this basis and we will explore all the vast amount of possibilities we currently cannot even recognize and understand entirely in order to build a better future for everyone and not just a few. [Anonymous] As stated in the documentaries below, Bitcoin is not just a currency but unfolds its extremely powerful potential if you look at it as a platform in a more general way. [(1)] People have this mythology of money that is based on very little fact and one of the nice things of Bitcoin is that it forces people to start to ask questions about the fundamentals of money. Bitcoin is an attempt to adopt the advanced computerized system that we have, the Internet, to resurrecting what money used to be all about. [(2)] In other words all new money is debt [in our current "fractional reserve" system] […]. The entire system is based on trust […]. If all bank customers demanded just 3% of 4

their deposits right now in cash this run on the banks would reveal the truth. Almost none of that paper currency you think is in your bank account exists, it never did. [(3)] My aunt sisters in Greece talked about the corrupting influence of power and nothing has changed in these 3000 years. When you give control of a massive amount of money to a few individuals they will take advantage of that control. [(4)] Science and mathematics have essential truth that stands alone, irrespective of its inventors and irrespective of their motives. Well, Bitcoin is a system based on mathematical truth and this mathematical truth stands alone. We can read the source code in Bitcoin and understand it and it will be true whether Satoshi Nakamoto is a man, a woman, a collection of individuals, a government agency or aliens from the future. [(5)] The free exchange of information and currency can fuel revolutions, help in a [natural] disaster but our money is shackled to the 21st century. Manipulated by governments and banks, the champions of Bitcoin ask us to imagine payments without a middleman, investments without a broker, loans without a bank, insurance without an underwriter, charity without a trustee, escrow without an agent, betting without a bookie, record keeping without an accountant. Global, secure, nearly instant and free. Is is fantasy or the future of money and commerce? . “I'm sure that in twenty years there will either be very large Bitcoin transaction volume... or none.” - Satoshi Nakamoto [“Bitcoin: The End of Money As We Know It”, (2015), https://www.kickstarter.com/projects/bitcointheendofmoney/bitcoin-the-end-of-money-as-we-know-it, (00:18:44), (00:27:40), (00:30:21), (00:39:29), (00:56:54)] [(1)] In a system of debt one of the two parties is always the slave. And that is the architecture of money we live in, that is the architecture of money we use in our civilization, an architecture of money where you have no control, an architecture of money where every interaction is mediated by a third party. A third party that has absolute control over that money. Bitcoin is fundamentally different because in Bitcoin you don't owe anyone anything and no one owes you anything. It is not a system based on debt, it is a system based on ownership and no one can censor it, no one can seize it, no one can freeze it. And what they will tell you is they're worried, they're very worried. They're worried that criminals will use Bitcoin. But the truth is that they're far more terrified that all of the rest of us will. [(2)] It looked very different to me, I mean as soon as I heard the word decentralized and the fact there was a network powering this currency, rather than a central issuer that immediately captured my interest […]. What it meant for people who are libertarians in particular is that the government couldn't come in and shutdown a server and end Bitcoin. It would have to shutdown the entire Internet or turn off the electricity grid to 5

stop Bitcoin. [(3)] And suddenly now we have this tool that separates money from state. Like everybody today thinks that separating church and state "yeah of course they should be separated" but a couple of hundred years ago it was heresy to say that church and state should be separated. And today it sounds maybe a little bit crazy to say that money and state should be separated but I think in another decade or two people are gonna think "oh what the heck were we thinking letting governments be in charge of money, that caused so many problems and so many mis-allocations of resources around the world". Of course Bitcoin is better. [(4)] What's happening right now in a lot of the banking scene is this move towards a cashless society. But if you think about what that actually means, that means every single payment that you undertake has to go via a commercial bank. Now that means every single transaction you ever do will be monitored and recorded in a database somewhere. It means you're always be giving fees to various credit card companies and so on. So there's potentially huge amount of surveillance, there's all sorts of problems that come with a cashless society. In that world something like Bitcoin, which is an electronic equivalent to cash becomes quite important. [(5)] You may think that Bitcoin is just another way to pay for a cup of coffee, but it's not. Bitcoin is just a denomination used to pay the toll to put stuff on this global ledger. Now if you think about it, timestamp recordings of deaths, births, property, transactions, of votes this is the entire fabric of our civilization which makes the block chain, one of our profound human innovations of our time, because having a massive global ledger as a public utility can completely reorganize the way that we run our societies. Fundamentally, block chain is a database sort of mechanism, it's a standard, it's a protocol. And one of the problems we have in an increasingly globalized system is that everyone is operating their systems on their own local standards. And getting people to do everything in a uniform way that benefits all of us, like bringing in the metric system, that is really, really hard. [(6)] The decentralized block chain makes it possible to share data publicly without a single party controlling the system. In the block chain all participants in the network are equal. [“Documentary: The Bitcoin Gospel (VPRO Backlight)”, (2015), https://www.youtube.com/watch?v=8zKuoqZLyKg, (00:03:45), (00:18:06), (00:21:26) (00:28:30), (00:41:34), (00:42:57)] The following is an introduction to Bitcoin at a really high technical level of all the basic concepts of the technology. How Bitcoin Works Under the Hood (22:24 mins) https://www.youtube.com/watch?v=Lx9zgZCMqXE 6

As stated by Mr. Evan Duffield (lead developer of DASH) Bitcoin is a revolutionary technology, but it is not perfect. Bitcoin problems addressed by DASH: - Fungibility - Transaction Privacy - Transaction Speed - Network Participation - Project Governance - Project Funding - First Virtual Corporation [”Introduction to Dash from Founder Evan Duffield”, (2016), http://www.youtube.com/watch? v=dUptDHw1Lq0, (00:01:34)] Decentralization and blockchain technology, will result in a revolution of high-value, lowcost services ran in a way that no centralized entity could possibly compete against. [Evan Duffield, (2016-06-22), https://twitter.com/d10e_con/status/745758793540247552] Talking about the transparent public ledger of Bitcoin “versus” the anonymity features implemented in DASH you should compare this discussion with the more general discussion related to “What tools do we have available today and how should they be used?”. According to the abstract definition of technology, technology is neutral at its core: Think about how useful a search engine and an encyclopedia are and think about how easily those technologies might also be used for evil purposes in mind even if there are already protections installed to minimize abuse. It is up to us whether to forbid the usage of a specific tool at all or to try to confront the advantages with the disadvantages resulting for a society and judge on this basis afterwards. There's an entry point in the [Bitcoin] ecosystem and usually the identity of that person is known at that point and then once you get your money into the ecosystem you have a public ledger and all of the transactions that you do are completely available for anyone to look at. And what we're getting to with technology in the Bitcoin ecosystem is where anyone with enough computing power can go through and try to correlate all these addresses and figure out who's doing what and who's transferring money to who and then eventually sell that data which is a gross invasion of privacy. And I would rather get everyone more privacy rather than take it away from everybody because it's really you can only give it to everybody or you have to take it away from everybody in a system like this. And I know that there are going to be things that happen in the ecosystem that are illegal and this is just part of having rights. We have the right to privacy and some people will abuse that and I think there's a fine line to walk but we have to acknowledge that we want these rights and there's gonna be money like this that is on the Internet where everyone can see everything that's going on and I would rather [want] that money have an attribute of privacy for everybody useful. 7

[”Dash Talk Barcelona BTC Group - May 26 2015”, (2015), https://www.youtube.com/watch? v=wj-5sBFHQAU, (00:41:32)] (1) I feel very strongly that it's not enough to just live in the world as it is, to just kind of take what you are giving, follow the things that adults told you to do and your parents told you to do and then society tells you to do. I think we should always be questioning. I take this very scientific attitude that everything you have learned is just provisional, it's always open to recantation and refutation and re-questioning and I think the same applies to society. Once I realized that there are real serious problems, fundamental problems that I could do something to address, I didn't see a way to forget that and see a way not to. (2) You literally ought to be asking yourself all of the time what is the most important thing I could be working on in the world right now and if you're not working on that why aren't you. [”The Internet's Own Boy: The Story of Aaron Swartz”, (2014), https://www.youtube.com/watch? v=gpvcc9C8SbM, (00:25:22), (01:40:03)] According to the description published on YouTube, refer to [https://www.qubesos.org/news/2016/03/12/logan-cij-2016-future-of-os/] creating a secure operating system (OS) is a real tough challenge. “In an era of mass surveillance the need for independent, reliable and usable Operating Systems is fundamental. In previous times, political movements needed their own printing press for circumventing propaganda and repression. In the digital age we need independent Operating Systems to protect our freedom of speech and freedom of action. The creation of independent OS is both a technological challenge and a social, political and economic challenge. To protect and encrypt yet offer transparency of control, and make it easy to use for all of us, is a great challenge. Trusting hardware, software and organisational structure is an issue from building all the way to using the OS.” We're trying to make personal computing devices secure and trustworthy. Why the hell would anybody want to have secure and trustworthy personal devices you might think now? Well, just because we people are actually moving our lives to those personal devices. These are becoming extensions of our brains, so at least for me it feels some uncomfortably that my extension of my brain might not be trustworthy, that it might be spying on me, conspiring against me. [”Logan CIJ Symposium 2016 - Future of OS”, (2016), https://www.youtube.com/watch? v=Nol8kKoB-co, (00:57:37)] Experience has shown that "security through obscurity" [https://en.wikipedia.org/wiki/Security_through_obscurity] does not work. Public disclosure allows for more rapid and better solutions to security problems. [https://www.debian.org/security/] As stated by Christopher Soghoian (Principal Technologist, ACLU) in a documentary released by EPIX 8

in response to the Snowden leaks [https://en.wikipedia.org/wiki/Edward_Snowden]. Of all the Snowden disclosures that have come out to date, the one that will have the greatest long term impact is the revelation that the NSA has been subverting cryptographic standards and making the Internet less secure. That disclosures, those articles have radicalized a new generation of cryptographers, a new generation of computer scientists who are now intend upon building tools and services that can withstand pervasive government surveillance. [“Deep Web”, (2015), http://press.epixhd.com/programming/deep-web/, (01:15:27)] The challenge of the new cypherpunk movement is to make secure and verified end-toend encryption accessible to everyone, and turned on by default. [Lee, M., “Encryption Works – How to Protect Your Privacy in the Age of NSA Surveillance”, (2013), https://freedom.press/encryption-works, p.29] Arguing that you don't care about the right to privacy because you have nothing to hide is no different than saying you don't care about free speech because you have nothing to say. [Edward Snowden, (2015-12-22), https://twitter.com/Snowden/status/679319304828018689] Great Britain's George Orwell warned us of the danger of this kind [data collection] of information. The types of collection in the book, microphones and video cameras, TVs that watch us are nothing compared to what we have available today. We have sensors in our pockets that track us everywhere we go. Think about what this means for the privacy of the average person. A child born today will grow up with no conception of privacy at all. They'll never know what it means to have a private moment to themselves an unrecorded, unanalyzed thought. And that's a problem because privacy matters, privacy is what allows us to determine who we are and who we want to be. The conversation occurring today will determine the amount of trust we can place both in the technology that surrounds us and the government that regulates it. Together we can find a better balance, end mass surveillance and remind the government that if it really wants to know how we feel asking is always cheaper than spying. [Edward Snowden, (2013-12-25), http://www.channel4.com/news/edward-snowden-nsa-gchqwhistleblower-surveillance-spying] People willing to trade their freedom for temporary security deserve neither and will lose both. [Benjamin Franklin] As stated by Paul Rosenberg (“The freeman's perspective”) in a documentary released by Zygote Films and Upian in response to the need for privacy. 9

The reason we want privacy fundamentally is it because it allows free human action according to our own will. Humans develop when they use their own mind and make their own choices – god or bad – and they deal with their own consequences, that's how we grow. You have to be able to screw up without getting slammed and when there's somebody looking down at you, when you have to be afraid, when you have to lower your voice to talk about certain things you are squeezing out human development, human evolution. [“Down the Deep Dark Web”, (2016), http://www.zygotefilm.com/in-production.html, (00:22:56)] Mr. Matthew Schutte (VoiceAndExit) gave a talk about why “Each of us depends on varying degrees of privacy for our personal flourishing.”. Why the Future Of Innovation Depends On Privacy (13:48 mins): https://www.youtube.com/watch?v=RFVlzmomBPU On September 15th, 2016, CoinTelegraph published a short article about 4 Reasons Why Your Nation Will Kill Cash For A Digital Currency [https://cointelegraph.com/news/4-reasons-why-your-nationwill-kill-cash-for-a-digital-currency]. Keep in mind that the removal of cash does not automatically mean that any country will adopt a free and open-source decentralized cryptographic currency (cryptocurrency) [https://en.wikipedia.org/wiki/Cryptocurrency] which is run by the community and not by a centralized authority instead. As of today it is very likely that the exact opposite of a free system will be introduced. This has some serious consequences due to the fact that such a closed-source and centralized cryptocurrency would allow massive and unimaginable abuse of power by design. Empirical analysis of human history has shown that such a framework only allows totalitarianism to flourish. The community should always be asked first whether they want to live in a surveillance-state with no liberties and no freedom granted, where every citizen and any of their daily activities is suspicious by definition until he/she can repeatedly prove the exact opposite on a daily basis. Or if the people want the exact opposite: To life in an open, free and transparent democracy where the public is well educated and able to decide on their own rather than discriminated, divided and frightened on a daily basis. Since this discussion is more relevant than ever you should research this topic for now in great detail. You should also pay attention to controversial opinions and statements as indicated below. “You have to take into account the mechanics of the currently running "fractional reserve" system which has been designed by very few people in secret without the full awareness of the public. In addition this system has never been explained to the large public repeatedly enumerating all of its benefits and disadvantages for all of the participants. Anyway, is the public allowed at all to vote for an alternative monetary system within the current framework if they would wish to do so? Especially pay attention to those who confuse the truth, who try to distract, who try to mislead with full awareness and who refuse to argue based on neutral facts but emotions instead simply not allowing any kind of logical analysis which leads to the truth.”

10

It is well that the people of the nation do not understand our banking and monetary system, for if they did, I believe there would be a revolution before tomorrow morning. [Henry Ford] ABSTRACT This guide does not provide sufficient information about the setup of a Masternode (MN) server itself, for further information refer to the Dash Forum [https://www.dash.org/forum/topic/masternodeguides.66/]. Anyway the result is an additional MN in the two-tier DASH MN network by outsourcing the setup of a secure remote Linux server to a skilled third party, called the Masternode-serviceprovider (MNSP). The main part of this guide describes the download and verification process of all necessary files and consequently the setup of a secure and private OS in order to store the 1000 DASH deposit for the new MN in a reasonably secure environment. In addition the solution is not limited to the setup of a DASH MN local wallet exclusively. It is also designed for a standard DASH local wallet setup (with no intention to setup a MN at all) or any other cryptocurrency supporting the proposed solution. TABLE OF CONTENTS PREFACE P1 – About this article P2 – DASH Mission and Motivation ABSTRACT TABLE OF CONTENTS LIST OF FIGURES LIST OF TABLES INTRODUCTION I. PREPARATION I.1 Requirements I.2 General overview and software information I.2.1 Debian GNU/Linux I.2.2 VirtualBox I.2.3 Whonix GNU/Linux I.2.4 Tails I.2.5 Whonix-On-Debian vs. Tails vs. Subgraph OS vs. Qubes OS? I.2.6 Tor I.2.6.1 Tor downloads controversy 11

I.3 Precautions and Security I.3.1 General Warning I.3.1.1 Trust I.3.1.2 Overall Fingerprint and ISP I.3.2 Wallet and MNSP information – Security chain analysis I.3.3 Tor Onion Services I.4 Explicit exclusion of certain... I.4.1 Behavior I.4.2 Ideas I.4.3 Software I.4.3.1 Why cryptocurrencies might not work at all on the long run I.4.3.1.1 Counter-measures I.4.4 Hardware I.4.4.1 USB drives requirements I.5 Recommended software to get you started I.5.1 How to download sensitive files with Tor Browser – An approach I.5.1.1 Accumulated downloads – Risk analysis I.5.2 How to compare data with checksum tool GtkHash I.5.3 How can I verify my download is correct and exactly what has been created by author X? I.5.3.1 Background information I.5.3.2 Verification techniques in practice I.5.4 Get Tails I.5.4.1 Get Tor Browser I.5.4.2 Get Tails with Tor Browser I.5.5 How to work with Tails I.5.5.1 How to download files with Wget I.5.5.2 Get Debian I.5.5.2.1 Verify Debian download I.5.5.2.1.1 Debian Signing Key I.5.5.2.1.1.1 From a public key server I.5.5.2.1.1.2 Debian Keyring (Web of Trust) I.5.5.2.1.2 Debian & PGP I.5.5.2.1.3 Debian & Checksums I.5.5.3 Get Whonix I.5.5.3.1 Verify Whonix download I.5.5.3.1.1 Whonix Signing Key I.5.5.3.1.1.1 Tor Onion Service download I.5.5.3.1.1.2 From a public key server I.5.5.3.1.1.3 Debian Keyring (Web of Trust) I.5.5.3.1.1.4 Additional resources I.5.5.3.1.2 Whonix & PGP I.5.5.3.1.3 Whonix & Checksums I.5.5.4 Get DASH wallet software I.5.5.4.1 Verify DASH wallet download I.5.5.4.1.1 DASH Signing Key 12

I.5.5.4.1.1.1 Several HTTPS downloads I.5.5.4.1.1.2 Tor Onion Service download I.5.5.4.1.2 DASH wallet & PGP I.5.5.4.1.3 DASH wallet & Checksums I.5.5.5 Copying data to CDs/DVDs I.5.5.5.1 Debian I.5.5.5.2 Whonix and DASH wallet software archives II. DEBIAN II.1 Strategy II.2 Installation of Debian II.3 Boot into Debian II.3.1 Installation of Apt-Transport-Tor II.3.1.1 Updating & Upgrading Debian II.3.2 Different users on Debian? II.3.3 Installation of VirtualBox III. VIRTUALBOX III.1 General overview III.2 Tails VM III.2.1 BACK-UP-HDD III.2.1.1 Partition 1 – Whonix-VOLUME III.2.1.2 Partition 2 – Tails-VOLUME III.3 Import Whonix Images III.4 Whonix-VMs III.5 Whonix-Gateway III.6 Whonix-Workstation III.6.1 Installation of DASH wallet software IV. DASH IV.1 DASH wallet IV.1.1 Preparation of secure cold wallet IV.1.1.1 DASH wallet software IV.1.1.1.1 Save wallet file IV.1.1.1.2 Dumpprivkey IV.1.1.2 DASH paper wallet IV.1.1.2.1 Download and Verify IV.1.1.2.2 Applying BIP38 encryption IV.1.2 Start DASH wallet software IV.1.3 Encrypt wallet IV.1.4 Backup wallet #1 IV.1.4.1 BACK-UP-HDD: Whonix-VOLUME IV.1.5 Import funds IV.1.5.1 Backup funds IV.1.6 Mixing Funds 13

IV.2 Test-DASH IV.2.1 Faucet V. MASTERNODE V.1 Masternode Preparation V.2 Backup wallet #2 V.3 Feed new MN V.4 Masternode-service-provider V.4.1 Tails VM and MNSP V.4.2 Contacting Masternode-service-provider V.4.3 Final backup V.5 Masternode Launch V.6 Going back online VI. CONCLUSION AND FORECAST APPENDIX A1 – Testing Results A2 – DASH (NON-Masternode) Local Wallet A3 – Miscellaneous A3.1 Quality of the guide A3.2 Give back LIST OF FIGURES Figure 1: Overall design of DASH MN Local Wallet Figure 2: Fingerprints of the SSL certificate of https://www.torproject.org/ Figure 3: Fingerprints of the SSL certificate of https://tails.boum.org/ Figure 4: Fingerprints of the SSL certificate of https://www.debian.org/ Figure 5: Fingerprints of the SSL certificate of https://www.whonix.org/ Figure 6: Fingerprints of the SSL certificate of https://pgp.mit.edu/ Figure 7: Fingerprints of the SSL certificate of https://github.com/ Figure 8: Fingerprints of the SSL certificate of https://www.dash.org/

{I.2} {I.5.4.1} {I.5.4.2} {I.5.5.2} {I.5.5.3} {I.5.5.4.1.1.1} {I.5.5.4.1.1.1} {IV.1.1.2.1}

LIST OF TABLES Table 1: Overview of accumulated encrypted data {I.3.2} Table 2: Different USB drives and required sizes (estimations) {I.4.4.1} Table 3: Probability of downloading infected files in a row {I.5.1.1} Table 4: Helpful arrangement of checksums in a text editor {I.5.2} Table 5: Tails verification with checksums (documentation sample) {I.5.4.2} Table 6: Comparison of bootable mediums for Tails and download procedure discussion {I.5.5} 14

Table 7: Debian verification with signatures (documentation sample) {I.5.5.2.1.2} Table 8: Comparison of publicly available checksums vs. personally calculated checksums (scheme) {I.5.5.2.1.3} Table 9: Debian verification with checksums (documentation sample) {I.5.5.2.1.3} Table 10: Comparison of downloaded Whonix signing keys (documentation sample) {I.5.5.3.1.1.1} Table 11: Whonix verification with signatures (documentation sample) {I.5.5.3.1.2} Table 12: Whonix verification with checksums (documentation sample) {I.5.5.3.1.3} Table 13: DASH verification with signatures (documentation sample) {I.5.5.4.1.2} Table 14: DASH verification with checksums (documentation sample) {I.5.5.4.1.3} Table 15: Archive information for Whonix and DASH wallet software {I.5.5.5.2} Table 16: Partition information of BACK-UP-HDD {III.2.1} Table 17: DASH paper wallet verification with checksums (documentation sample) {IV.1.1.2.1} Table 18: Typical MN setup process {V.4.2} INTRODUCTION DASH [https://www.dash.org/what-is-dash/] which stands for “digital cash” is an open-source privacycentric decentralized cryptocurrency launched in 2014 with various improvements in comparison to Bitcoin [https://www.dash.org/wp-content/uploads/2015/04/Dash-WhitepaperV1.pdf] which is based on the work of Satoshi Nakamoto who introduced Bitcoin, A Peer-to-Peer Electronic Cash System [https://bitcoin.org/bitcoin.pdf] in 2008. DASH has implemented a two-tier MN network allowing to conduct special features, e.g. instant transaction confirmation, trustless transaction mixing, selfsustainable decentralized governance and funding by block chain [https://en.wikipedia.org/wiki/Block_chain_(database)], etc. which are all not possible on the current architecture of the Bitcoin network, compare with [https://www.dash.org/binaries/evo/DashPaper-v13v1.pdf]. One significant advantage of DASH is the Masternode Reward Program [https://www.dash.org/wpcontent/uploads/2015/04/Dash-WhitepaperV1.pdf, pp. 2-3]. This approach tries to get rid of a very dangerous effect the Bitcoin network and a lot of other Altcoins [https://en.bitcoin.it/wiki/Altcoin] are exposed to: The decrease of full nodes over long time periods. Since any peer-to-peer network [https://en.wikipedia.org/wiki/Peer-to-peer] relies strongly on (full) nodes all of its users must have a strong interest in the health of those nodes resulting in a correctly operating network. The more (honest) nodes available, the higher the decentralization, the higher the stability and the higher the security on a peer-to-peer network. Frequent DASH software updates introduce a maintenance factor to the DASH MN network most people do not want to mess up with. Sometimes the ordinary user with sufficient funds (1000 DASH) in position to run a MN does not have the time and/or knowledge to setup and/or keep the MN constantly up-to-date. As in any other context software updates should be installed as soon as possible due to the risk of upcoming security problems, network instabilities, etc. Because of the fact that the user will only manage the local part of the MN with the never-leaving deposit of 1000 DASH on the personal machine the user has to contact a third party. This third party is 15

called the MNSP who takes full care of the new MN. The proposed solution gains maximum control to the user and minimizes common risks of different nature by a dedicated setup of security- and privacy-in-mind software and very detailed instructions in order to be able to work in a secure (computing) environment. In addition all (sensitive) network traffic is routed over the Tor anonymity network [https://en.wikipedia.org/wiki/Tor] which allows for anonymity online. The goal is to provide a comprehensive step-by-step guide in order to work with DASH securely. Furthermore the article contains additional information and sources with beneficial use motivating for further studying of various related subjects. I. PREPARATION I.1 Requirements In order to expand the current DASH MN network the following list of minimal requirements has to be accomplished. MN specific requirements: - 1000 DASH (deposit to run a MN, a technical condition) - equivalent amount of ~10 USD in DASH per month to pay the MNSP General requirements: - << 1 DASH (network fees for sending coins, PrivacySend (formerly known as DarkSend) mixing fees, compare with chapter IV.1.6) - medium computer skills (it is more important that you are open-minded and willing to learn new subjects rather than being an expert) - free weekend (the setup takes a lot of time and even if you are familiar with all the software more than 5 GB of different files had to be downloaded at the time of writing) - 2 bootable USB drives, compare with chapter I.4.4.1 (read chapter I.5.5, Table 6 to find out if this requirement is needed in your specific situation otherwise you only need one bootable USB drive) - CDs/DVDs/USB drives for getting started and backing up important data (chapter I.5.5.5, IV.1.4.1, V.2 and V.4.3) It is strongly recommended to work with two computers in order to have a better overview of the whole situation. Preferably use one to read the guide (GUIDE computer) and to download the required software as explained in chapter I.5. The second computer is reserved for the whole setup and installation of the various components (DASH computer). For obvious reasons the DASH computer should be the one with better performance. However at least 4 GB of RAM and a 4 GHz processor should be considered as minimal technical requirements. Of course it is also possible to only work with one computer (therefore the DASH computer would also be the GUIDE computer). But we will stick to 16

the two different computers model for the whole guide. I.2 General overview and software information In order to provide a secure and private working environment for DASH [https://www.dash.org/], [http://www.dashorg64cjvj4s3.onion/] the proposed solution is based on Debian GNU/Linux [https://www.debian.org/], VirtualBox [https://www.virtualbox.org/], Whonix GNU/Linux [https://www.whonix.org/], [http://kkkkkkkkkk63ava6.onion/] including Tor [https://www.torproject.org/] and Tails [https://tails.boum.org/]. Figure 1 gives a schematic overview of the overall design, please note that assumptions have been made in order to concentrate on the very basics of the design. The highlighted Tor connections (red color) do not show the exact path of the connection but rather the starting point and destination. For example DASH wallet will connect to Whonix-Workstation (VM) first which is connected to Whonix-Gateway (VM) in conjunction with the HOST (Debian) in order to establish a connection to the two-tier DASH Masternode network and the new Masternode which is part of the overall network.

17

Figure 1: Overall design of DASH MN Local Wallet The core security approach of the whole setup is derived from the proven concept “security by isolation”. Because of this all relevant downloads related to DASH except the block chain (compare with chapter I.2.6.1) will be performed outside of the Whonix-Workstation. As an additional security feature all downloads will be performed with a live OS called Tails (compare with chapter I.2.4 and I.5.5) on another computer, the GUIDE computer and therefore physically separated from the system where Debian is supposed to be installed on, the DASH computer. Due to the fact that the whole setup relies strongly on Whonix, a stable and trustworthy host OS has to be chosen. According to the Whonix Pre Install Advice, GNU/Linux hosts are recommended explicitly. “Debian GNU/Linux is recommended as a reasonable compromise of security and usability (popularity, documentation).” [https://www.whonix.org/wiki/Pre_Install_Advice#Host_Operating_System] The goal is to sandbox everything what happens inside the virtual machines (VMs), effectively separating the actions inside the VMs from the Debian OS standing outside for various reasons of security (e.g. security by isolation). 18

I.2.1 Debian GNU/Linux “Debian is a Unix-like computer operating system and a Linux distribution that is composed entirely of free and open-source software [https://en.wikipedia.org/wiki/Free_and_open-source_software], most of which is under the GNU General Public License, and packaged by a group of individuals known as the Debian Project.” [https://en.wikipedia.org/wiki/Debian] Read the Introduction to Debian on the About Debian website [https://www.debian.org/intro/about]. I.2.2 VirtualBox We will install VirtualBox on Debian which is an open-source x86 and AMD64/Intel64 virtualization product [http://www.virtualbox.org/wiki/Virtualization] with the ability to run various OSes, so-called VMs. Always keep in mind that the virtualization software and the Debian host OS are both able to monitor what happens inside any VM. I.2.3 Whonix GNU/Linux Whonix requires Debian to run two VMs simultaneously in a virtualization software. “Whonix is a desktop operating system designed for advanced security and privacy. It realistically addresses attacks while maintaining usability. It makes online anonymity possible via fail-safe, automatic, and desktop-wide use of the Tor network. A heavily reconfigured Debian base is run inside multiple virtual machines, providing a substantial layer of protection from malware and IP leaks. Preinstalled applications, pre-configured with safe defaults are ready for use. Additionally, installing custom applications or personalizing the desktop will in no way jeopardize the user. Whonix is the only actively developed OS designed to be run inside a VM and paired with Tor. […] Whonix benefits anyone who does sensitive work on their desktop or online.” [https://www.whonix.org/] “Whonix is an operating system focused on anonymity, privacy and security. It's based on the Tor anonymity network [https://www.torproject.org/about/overview.html.en], Debian GNU/Linux [https://en.wikipedia.org/wiki/Debian] and security by isolation. Whonix consists of two parts: One solely runs Tor and acts as a gateway, which we call WhonixGateway. The other, which we call Whonix-Workstation, is on a completely isolated network. Only connections through Tor are possible. With Whonix, you can use applications and run servers anonymously over the internet. DNS leaks are impossible, and not even malware with root privileges can find out the user's real IP. To learn more about security and anonymity under Whonix, please continue to the About Whonix [https://www.whonix.org/wiki/About] page.” 19

[https://www.whonix.org/wiki/Portal] Therefore we will only install the DASH wallet software permanently on the Whonix-Workstation (chapter III.6.1) to be able to work with sensitive information at all. I.2.4 Tails “Tails is a live system that aims to preserve your privacy and anonymity. It helps you to use the Internet anonymously and circumvent censorship almost anywhere you go and on any computer but leaving no trace unless you ask it to explicitly. It is a complete operating system designed to be used from a DVD, USB stick, or SD card independently of the computer's original operating system. It is Free Software [https://tails.boum.org/doc/about/license/index.en.html] and based on Debian GNU/Linux [https://www.debian.org/]. Tails comes with several built-in applications pre-configured with security in mind: web browser, instant messaging client, email client, office suite, image and sound editor, etc.” [https://tails.boum.org/about/index.en.html] “Using Tails on a computer doesn't alter or depend on the operating system installed on it. So you can use it in the same way on your computer, a friend's computer, or one at your local library. After shutting down Tails, the computer will start again with its usual operating system. Tails is configured with special care to not use the computer's hard-disks, even if there is some swap space on them. The only storage space used by Tails is in RAM, which is automatically erased when the computer shuts down. So you won't leave any trace on the computer either of the Tails system itself or what you used it for. That's why we call Tails "amnesic". This allows you to work with sensitive documents on any computer and protects you from data recovery after shutdown. Of course, you can still explicitly save specific documents to another USB stick or external hard-disk and take them away for future use.” [https://tails.boum.org/about/index.en.html#index2h1] “[...] as other Linux systems, Tails doesn't require an antivirus to protect itself from most malwares, such as viruses, trojans, and worms. There are various reasons why Linux operating systems generally don't need antivirus softwares, including the permission design of Linux systems. Refer to the Wikipedia page on Linux malware [https://en.wikipedia.org/wiki/Linux%5Fmalware] for further details.” [https://tails.boum.org/support/faq/index.en.html#index38h2] Tails provides the features we need for the upcoming tasks because of the strength of this OS. For more information visit the respective Tails press and media information website 20

[https://tails.boum.org/press/index.en.html]. I.2.5 Whonix-On-Debian vs. Tails vs. Subgraph OS vs. Qubes OS? It might look confusing for a beginner why not to work out a solution within Tails solely. At first the user has to make sure, he/she understands well the differences between an OS installed onto a medium where data can be stored on permanently and therefore survive reboots. This feature cannot be achieved by Tails since it is amnesic by design and leaves no traces unless you ask it explicitly (compare with [https://tails.boum.org/about/index.en.html]). “We do not currently provide a solution for running a virtual machine inside a Tails host. See ticket #5606 [https://labs.riseup.net/code/issues/5606].” [https://tails.boum.org/doc/advanced_topics/virtualization/index.en.html#index1h1] “The packages included in Tails are carefully tested for security. Installing additional packages might break the security built in Tails.” [https://tails.boum.org/doc/advanced_topics/additional_software/index.en.html] While working with a substantial amount of DASH it is simply too dangerous to work with a live OS even for experienced users. Since a reboot will always cause the loss of all coins immediately if steps for preventing this scenario have not been applied correctly. Anyway, Tails is an essential tool in order to get started at all. Due to the fact that the core motivation is to protect the user on a vast amount of levels, a secure, easy to use, well documented, extensively reviewed, stable, etc. host OS is needed. It is strongly recommended to try to understand well the decisions made in this guide, they are mainly based on the work available on the Whonix Comparison with Others website [https://www.whonix.org/wiki/Comparison_with_Others#General]. Due to the fact that we will use the Whonix-Workstation (chapter III.6.1) only for the DASH wallet software (chapter IV) and nothing else there is no need to introduce another security concept such as Qubes OS [https://en.wikipedia.org/wiki/Qubes_OS] for a beginner. This decision is perfectly fine since the whole setup is already strongly based on security by isolation, compare with chapter I.2, Figure 1. The absence of such a tool makes life easier for new users and reduces the overall complexity. In addition to this the Subgraph OS [https://en.wikipedia.org/wiki/Subgraph_(operating_system)] approach is very interesting but not used as a host OS instead of Debian due to the fact that it has just been launched. Anyway read the full statement regarding Tails, Qubes OS and Subgraph OS in chapter VI. For further information refer to the Logan CIJ Symposium 2016 [https://www.qubesos.org/news/2016/03/12/logan-cij-2016-future-of-os/] discussing about Qubes OS, Subgraph OS and Tails. As stated as practical advantage, Tails and Subgraph OS are intended to work on almost any hardware (with all its implications). In comparison to Qubes OS special hardware requirements [https://www.qubes-os.org/doc/system-requirements/] have to be met in order to be able to work with Qubes OS at all and to also get the highest degree of security by design. Mr. Jacob Appelbaum [https://en.wikipedia.org/wiki/Jacob_Appelbaum], independent journalist, computer security 21

researcher, artist and hacker summarizes the core differences between those three OSes starting from (00:18:24) to (00:21:25) at the symposium to give you an overview about the decisions made in this guide. Logan CIJ Symposium 2016 - Future of OS (01:12:57 hours): https://www.youtube.com/watch?v=Nol8kKoB-co According to the setup discussed in this guide the user is instructed in how to work with Debian and Tails (which is based on Debian) since the very beginning (chapter I.5) and he/she will benefit from the previous Tails instruction chapters and apply the knowledge while working with the Tails VM (chapter III.2). I.2.6 Tor For a general definition of anonymity (not only technically related) you should read [https://en.wikipedia.org/wiki/Anonymity] and [https://www.whonix.org/wiki/DoNot] to get a better idea and to understand well the inherent limitations. You should be well aware of the differences of pseudonymity [https://en.wikipedia.org/wiki/Pseudonymity] in comparison to anonymity. “Tor is free software for enabling anonymous communication. The name is an acronym derived from the original software project name The Onion Router.” [https://en.wikipedia.org/wiki/Tor] “David Kaye, the United Nations Special Rapporteur on freedom of opinion and expression, last week [May 2015] issued his first report to the UN Human Rights Council addressing the relationship between secure online communication, the freedom of expression, and regulation of these by States and governments. The report draws on submissions by UN member states as well as advocacy groups and non-governmental organizations, including the Tor Project. […] David Kaye also identified Tor by name as an example of essential anonymity software in an interview with the Washington Post [http://www.washingtonpost.com/blogs/the-switch/wp/2015/05/28/un-report-encryption-is-importantto-human-rights-and-backdoors-undermine-it] following the release of his report.” [https://blog.torproject.org/blog/tor-weekly-news-%E2%80%94-june-3rd-2015] People are increasingly using anonymity networks such as Tor which allows for privacy online in order to protect themselves from prying eyes. Brief introductory video of Tor, released in 2015 (02:18 mins): https://blog.torproject.org/blog/releasing-tor-animation The Electronic Frontier Foundation (EFF) provides an easy to understand Tor and HTTPS overview: https://www.eff.org/pages/tor-and-https “Tails uses Tor because it is the best available anonymity network. [...] Tor is the anonymity network 22

with the largest user base.” [https://tails.boum.org/doc/about/tor/index.en.html] Additionally you are encouraged to read the statement of Whonix Why does Whonix use Tor [https://www.whonix.org/wiki/Why_does_Whonix_use_Tor]. The following is an extract of [https://tails.boum.org/about/index.en.html#index1h2].

the

Tails

About

website

“Tor is an open and distributed network that helps defend against traffic analysis, a form of network surveillance that threatens personal freedom and privacy, confidential business activities and relationships, and state security. Tor protects you by bouncing your communications around a network of relays run by volunteers all around the world: it prevents somebody watching your Internet connection from learning what sites you visit, and it prevents the sites you visit from learning your physical location. Using Tor you can: - be anonymous online by hiding your location, - connect to services that would be censored otherwise; - resist attacks that block the usage of Tor using circumvention tools such as bridges [https://tails.boum.org/doc/first_steps/startup_options/bridge_mode/index.en.html]. To learn more about Tor, see the official Tor website [https://www.torproject.org/], particularly the following pages: - Tor overview: Why we need Tor [https://www.torproject.org/about/overview.html.en#whyweneedtor] - Tor overview: How does Tor work [https://www.torproject.org/about/overview.html.en#thesolution] - Who uses Tor? [https://www.torproject.org/about/torusers.html.en] Understanding and Using Tor — An Introduction for the Layman [https://trac.torproject.org/projects/tor/wiki/doc/TorALaymansGuide]” You have to understand that the more people use a certain anonymity network they have agreed to use over a long time period the higher the degree of anonymity for all of its users over a long time period. Therefore everyone using a certain anonymity network should always have a strong interest in expanding the network on all of its levels starting with the user base just because this expands the degree of anonymity exponentially. It is strongly recommended to use the Tor network for almost all of your online communications (compare with chapter I.2.6.1). Another very important side effect is that by utilizing the Tor network on a daily basis you are actively taking part in protecting yourself while you are also helping to protect others which are connected to the Tor network at the same time as you are connected to. This is true since the number of people which are connected to the Tor network at the same time has increased by +1 (yourself) and it becomes exponentially harder for any adversary to distinguish between all the “different” Tor users, in case their anonymous network traffic over Tor is somehow “similar”. Especially compare with the Tails Warning website 23

[https://tails.boum.org/doc/about/warning/index.en.html#index10h1]. For further information especially refer to Tor Metrics, “the primary place to learn interesting facts about the Tor network, the largest deployed anonymity network to date.” [https://metrics.torproject.org/] By downloading and using Tor you can also protect the people who need anonymity like activists, journalists and bloggers. [”Tor Animation [English]”, (2015), https://www.youtube.com/watch?v=JWII85UlzKw, (00:01:56)] As stated by Dr. Joss Wright (University of Oxford Internet Institute) in a documentary released by the BBC. Part of anonymity is having a large number of people who are also anonymous because you can't be anonymous on your own. [“Inside the Dark Web”, (2014), http://www.bbc.co.uk/news/technology-29032399, (00:28:00)] I.2.6.1 Tor downloads controversy It is hereby mentioned explicitly that there is no intention to somehow weaken the Tor network on purpose. We understand quite well that downloading the proposed software (in the current configuration) and especially the block chain puts quite a lot of load on the Tor network. From the view point of the Tor network this is far away from ideal. But on the other hand if you compare the overall results you might see the recommended path from another point of view. The core motivation is to protect the individual and to teach new users how to work with security- and privacy-in-mind tools. This is not an easy task. If you feel uncomfortable with this guide, please continue with Appendix A3.1 instead. Additionally read the full statement and forecast in chapter VI providing future solutions to fix the problem of downloading and syncing the block chain by a simplified payment verification (SPV) approach which is currently in research and development. HINT: According to the information provided by Whonix, there are no bad intentions recognizable associated in downloading large files over Tor in general. “If you download Whonix over Tor, using the Tor Browser Bundle, the fact that you are using Whonix will be hidden.” [https://www.whonix.org/wiki/Hide_Tor_and_Whonix_from_your_ISP] Compare with [https://www.whonix.org/wiki/FAQ#You_should_not_waste_the_Tor_network.27s_bandwith_by_dow nloading_operating_system_updates_over_Tor.21]. As of writing the accumulated size of the WhonixGateway and Whonix-Workstation VM images are about 4 GB. By default Tails also downloads its OS updates via Tor (if NOT booted from a DVD or another read-only device) in case the user decides to update the Tails device automatically. When it comes to downloading the block chain this process is comparable with the usage of BitTorrent [https://en.wikipedia.org/wiki/BitTorrent] over Tor. Please read the Whonix File Sharing website [https://www.whonix.org/wiki/File_Sharing] for further discussion. As drafted in Appendix A3.2 we have shown an approach to somehow compensate for the massive use of the Tor infrastructure and 24

software projects in general. I.3 Precautions and Security I.3.1 General Warning At this point it is very important to understand the necessity of all the precautions. (1) If you do not take care of your funds it is very likely that you will get rid of them either by mistake on your side or by a sophisticated hacking attack. (2) If you do not take care of a well configured and properly used OS it is very likely that you will loose your privacy and anonymity which might cause serious harm even to other people around you, too. It is strongly recommended to read the Whonix Security Guide [https://www.whonix.org/wiki/Security_Guide/] to get an overview of the potential threats before continuing with this guide. Additionally the Whonix Documentation [https://www.whonix.org/wiki/Documentation/] contains a lot of information, not only about Whonix, but precautions and security on the Internet in general. It provides a crash course in anonymity, privacy, and security on the Internet which might help you a lot. HINT: All those precautions do not result from the usage of the Tor anonymity network and/or free software at all but remain valid in general for any interaction with the Internet and/or any other computer systems and/or networks. Usually almost all of those precautions are simply ignored and/or not well known/understood which explains the current drastic state of vulnerability and privacy issues for the average user. I.3.1.1 Trust Due to the fact that it is impossible for a single person to successfully develop, maintain and audit the whole software projects mentioned in this guide (and of course in general), (1) talented people have to work together over a period of time to achieve certain goals of desire. This has all been proven empirically. Additionally, (2) developers have to trust each other to make all this happen which is also a very difficult social and technological aspect in some cases, especially in the security and anonymity environment (see below). The second condition is also true for the average users who simply make use of the final software but are not directly involved in the development of the software. Generally speaking the average user has to trust the developers and/or the community surrounding any project. Because of the fact that Trust is a crucial condition while working on security-related systems you are strongly encouraged to read the Tails Trust website [https://tails.boum.org/doc/about/trust/index.en.html] such as the Whonix Trust website 25

[https://www.whonix.org/wiki/Trust] before continuing with this guide. It is obvious that as far as a status of trust is assured it is possible for a single person to verify the downloaded files and build their own work on top of the currently available knowledge. I.3.1.2 Overall Fingerprint and ISP Please read the Whonix Fingerprint website [https://www.whonix.org/wiki/Fingerprint] for clarification, additionally read the corresponding discussion about Tails [https://tails.boum.org/doc/about/fingerprint/index.en.html]. According to the Whonix Hide Tor and Whonix from your ISP website [https://www.whonix.org/wiki/Hide_Tor_and_Whonix_from_your_ISP] “All traffic from Whonix-Workstation and Whonix-Gateway is routed over Tor.”. “Whonix is itself exclusively generating Tor activity on the network. Both, all traffic from Whonix-Workstation (TBB [Tor Browser Bundle], updates, timesync, etc.) and Whonix-Gateway (updates, timesync) goes through Tor.” [https://www.whonix.org/wiki/Fingerprint] Anyway (1) not encrypted traffic and (2) Tor traffic (which is encrypted data) originating from the Debian host OS is visible to your ISP [https://en.wikipedia.org/wiki/Internet_service_provider] and/or local network administrator. Be advised that the amount of (encrypted) data arriving/leaving your machine in dependence of time might be tracked by an adversary (if strong encryption is applied an adversary is NOT able to see its decrypted content). This is comparable to a chart logging the network history against time such as any system monitor/task manager does, compare with Tails Confirmation attacks on their Warning website [https://tails.boum.org/doc/about/warning/index.en.html#index7h1] and Tor doesn't protect you from a global adversary [https://tails.boum.org/doc/about/warning/index.en.html#index10h1]. I.3.2 Wallet and MNSP information – Security chain analysis Always keep in mind that the security of any system always and only depends on its weakest point. This is the typical starting point for any adversary since attacking resources are always limited while dealing with complex systems. As outlined in chapter IV.1.4.1 you are strongly encouraged to backup the BACK-UP-HDD file (chapter III.2.1) to another medium (CD/DVD/USB drive/SD card, etc.) since it contains important data which can be restored easily in case of a serious system crash. Table 1 gives an overview about the different objects and their default encryption status. Keep in mind that the wallet.dat (identical to Documents.dat) and the MNSP information file are the most important assets you really have to take care of. Any adversary will usually only be interested in those two files for various reasons. For the following we will only discuss those scenarios where the files are stored on permanently with the lowest number of accumulated encryption steps. Looking at CASE 1 (Table 1) it is obvious that the wallet.dat file is protected by the encrypted Debian OS installation plus an encryption passphrase for the wallet itself (double-encryption is granted). CASE 1: STANDARD 26

# medium 1.

medium name medium Debian OS +

CASE 2: BACK-UP-HDD # medium medium name medium 1. Debian OS + 2. CD/DVD -

wallet.dat + BACK-UP-HDD + +

wallet.dat + +

MNSP information + +

where: + indicates object is encrypted by design - indicates object is NOT encrypted by design Table 1: Overview of accumulated encrypted data Looking at CASE 2, burning the wallet.dat and MNSP information file to another medium can only be done by burning the BACK-UP-HDD file to a CD/DVD/USB drive/SD card, etc. because there is no other comparable secure file transfer [https://www.whonix.org/wiki/File_Transfer] available within the Whonix concept and this procedure is also recommended. Since the BACK-UP-HDD file (including the wallet.dat file plus an encryption passphrase for the wallet itself) is encrypted the content of the wallet.dat file is also encrypted two times at all. Since the BACK-UP-HDD file (including the MNSP information file plus an encryption passphrase for the file itself) is encrypted the content of the MNSP information file is also encrypted two times at all. Generally speaking it is no problem if the backup medium (e.g. CD/DVD) is not encrypted by design simply because the BACK-UP-HDD file and its content is protected by passphrases. There are even two different passphrases needed which lead to one partition, respectively including the encrypted wallet.dat file on one partition and the MNSP information file on the other encrypted partition. Therefore the two important files which are stored on the BACK-UP-HDD will always be encrypted (at least) two times at all regardless of the type of the backup medium. Speaking from a technical point of view the files should be considered safe if the user follows the instructions carefully in order to minimize the upcoming risks which are also introduced by the human factor while interacting with complex systems. I.3.3 Tor Onion Services “Tor can also provide anonymity to websites and other servers. Servers configured to receive inbound connections only through Tor are called hidden services. Rather than revealing a server's IP address (and thus its network location), a hidden service is accessed through its onion address [https://en.wikipedia.org/wiki/.onion], usually via the Tor Browser [https://en.wikipedia.org/wiki/Tor_(anonymity_network)#Tor_Browser]. The Tor network understands these addresses and can route data to and from hidden services, even those hosted behind firewalls [https://en.wikipedia.org/wiki/Firewall_(computing)] or network address translators [https://en.wikipedia.org/wiki/Network_address_translator] (NAT), while preserving the anonymity of 27

both parties. Tor is necessary to access hidden services.” [https://en.wikipedia.org/wiki/Tor_%28anonymity_network%29#Hidden_services] “.onion is a special-use top level domain [https://en.wikipedia.org/wiki/Top_level_domain] suffix designating an anonymous hidden service [https://en.wikipedia.org/wiki/Tor_(anonymity_network)#Hidden_services] reachable via the Tor [https://en.wikipedia.org/wiki/Tor_(anonymity_network)] network. Such addresses are not actual DNS names [https://en.wikipedia.org/wiki/DNS_name], and the .onion TLD is not in the Internet DNS root [https://en.wikipedia.org/wiki/DNS_root_zone], but with the appropriate proxy software installed, Internet programs such as web browsers [https://en.wikipedia.org/wiki/Web_browser] can access sites with .onion addresses [https://en.wikipedia.org/wiki/Url] by sending the request through the network of Tor servers. The purpose of using such a system is to make both the information provider and the person accessing the information more difficult to trace, whether by one another, by an intermediate network host, or by an outsider.” [https://en.wikipedia.org/wiki/.onion] Mr. Roger Dingledine [https://en.wikipedia.org/wiki/Roger_Dingledine], President, Director and cofounder of the Tor Project gave a talk about various security properties of Tor Onion Services at 32C3 [https://en.wikipedia.org/wiki/Chaos_Communication_Congress] in 2015. Tor Onion Services: More useful than you think (01:00:39 hours): https://www.youtube.com/watch?v=oh9D2r-ck40 Starting from (00:03:56): “So some of these cool security properties […] is that that onion name […] with the [...] big pile of 16 characters, that is the hash of the public key which is the onion service which is the onion address. So they're self-authenticating meaning if I have the right onion address I can be sure that I'm connecting to the website/to the service that's associated with that key. So I don't need some sort of certificate authority model where I trust Turkish Telecom [certificate authority] to not lie to me. It's all build-in, self-authenticating. I don't need any external resources to convince myself that I am going to the right place. Along with that is they are end-to-end encrypted, so I know that nobody between my Tor client and the Tor client on the service side is able to read or intercept or manin-the-middle the traffic.” From now on talking we have shifted to the term Tor Onion Service replacing the common term Tor Hidden Service. As of writing the motivation is not limited to hide the real IP address of a given web server (such as the client connecting to the server) but to also expand the security while communicating. It is obvious that once you are connected to the right onion address the download security without applying any verification of the files you downloaded is higher in comparison to a Transport Layer Security (TLS) connection [https://en.wikipedia.org/wiki/Secure_Sockets_Layer]. Anyway we explicitly recommend to ALWAYS verify any download if possible or apply other techniques to convince yourself that you are in possession of a clean and uncorrupted file. “Major web sites use TLS to secure all communications between their servers and web browsers [https://en.wikipedia.org/wiki/Web_browser]. The primary goal of the TLS protocol is to provide 28

privacy and data integrity between two communicating computer applications. [https://tools.ietf.org/html/rfc5246]” [https://en.wikipedia.org/wiki/Secure_Sockets_Layer] You are also encouraged to always check the fingerprints of the SSL certificates for a given important website with those ones provided in this article, compare with Figures 2 to 8 and [https://tails.boum.org/doc/about/warning/index.en.html#index6h1]. You have to read the short Secure Website Certificate article [https://support.mozilla.org/en-US/kb/secure-website-certificate] on the Mozilla Support pages to learn more about this very important topic. Additionally you are encouraged to read the Whonix Hidden Services [https://www.whonix.org/wiki/Hidden_Services], [https://www.whonix.org/wiki/Hidden_Services#Notes_about_End-toend_security_of_Hidden_Services].

documentation especially

Keep in mind that Tor Onion Services are censorship-resistant by design (if additional important security rules are satisfied continuously). To learn more about them visit the Tor documentation website [https://www.torproject.org/docs/tor-hidden-service.html.en]. I.4 Explicit exclusion of certain... I.4.1 Behavior The whole setup has to be judged totally senseless and a waste of time if attacks from outside the computer are still possible. Therefore it is your task to work out and take care of a safe physical environment you are willing to trust before even thinking about to boot a computer. Think about the following example. It is not smart at all to use sophisticated encryption techniques if someone* is still able to look over your shoulder and is able to monitor your entire screen in clear. This might happen in a local library or at any other (public) place. *someone: A person or a device (e.g. surveillance camera) Things you might want to think about BEFORE working on sensitive material (compare with chapter I.5.1). - Switch off your mobile phone which is close to you (e.g. pressure sensor: microphone, optical sensor/s: camera/s, GPS & WiFi: tracking location and the differential change of location which is called movement, etc.) - Switch off any Smart TV [https://en.wikipedia.org/wiki/Smart_TV#Security_and_Privacy] which is close to you (e.g. pressure sensor: microphone, optical sensor/s: camera/s, etc.) - Switch off your (build-in) microphone of your computer and cover/tape/disable your webcam which is close to you (if available) - Switch off your (build-in) Wi-Fi (if available) for security reasons 29

- Switch off additional devices with similar properties and especially those with network access ATTENTION 1: Since we have learned that it is even possible to remotely switch on devices [https://en.wikipedia.org/wiki/WARRIOR_PRIDE] which have claimed to be powered OFF you should always ban those devices of your working environment. For this example we have applied the natural assumption that only the user who physically “owns” the device (bought from a merchant) is capable to turn on/off the device. On June 1st, 2016, The Independent published a short article talking about “Google could have a record of everything you have said around it for years, and you can listen to it yourself.” and also explains how to access and delete those files [http://www.independent.co.uk/lifestyle/gadgets-and-tech/news/google-voice-search-records-stores-conversation-people-have-aroundtheir-phones-but-files-can-be-a7059376.html]. Think about what that means if this amount of data suddenly becomes searchable due to a hacking incident in a huge indexed public database allowing anyone to filter for a specific person, geographic location, time, etc. (especially compare with ATTENTION 5). HINT 1: On September 15th, 2016, Ars Technica published a short aricle about FBI director says tape is the best way to defeat webcam hacks [http://arstechnica.com/tech-policy/2016/09/fbi-urges-low-techsolution-to-high-tech-webcam-hacking-tape/] to raise attention about the increasing problems relating to webcams. Especially, avoid all optical devices because they have a huge potential to violate your privacy due to sophisticated pattern recognizing algorithms, refer to [https://en.wikipedia.org/wiki/Facial_recognition_system]. We have even seen attacks against webcams monitoring the (surface of) the human eye mirroring the entire computer screen plus the area of the screen the person is currently looking at including the differential change of the iris at high frequencies allowing to follow the point of interest of the person quite accurately. Preferably, do not use any wireless connection. Refer to the following Wi-Fi and OPSec guide [https://www.deepdotweb.com/2015/09/01/wi-fi-and-opsec/] for further details. ATTENTION 2: Under any circumstances DO NOT USE the current Internet connection available on Whonix-Gateway, Whonix-Workstation, Tails, Tails VM and especially Debian clearnet access FOR OTHER PURPOSES than explicitly mentioned in this guide. This should protect you against drive-by downloads [https://en.wikipedia.org/wiki/Drive-by_download] and other serious problems. Keep in mind that Tor or any other pieces of software cannot protect you magically against all different kinds of threats like [https://tails.boum.org/doc/about/warning/index.en.html#index10h1] or [https://tails.boum.org/doc/about/warning/index.en.html#index11h1] just to name a few. HINT 2: Do not simply continue with your usual behavior patterns while working with sensitive data on computers and similar devices, especially those with Internet access. ATTENTION 3: Read the instructions about Want Tor to really work? on the Tor website [https://www.torproject.org/download/download-easy.html.en#warning]. ATTENTION 4: You are strongly advised to read the article Passphrases That You Can Memorize — 30

But That Even the NSA Can’t Guess published by The Intercept [https://theintercept.com/2015/03/26/passphrases-can-memorize-attackers-cant-guess/] mentioning Diceware [https://en.wikipedia.org/wiki/Diceware] since you will have to set up several passphrases which are all of high importance. “A passphrase is like a password, but longer and more secure.” ATTENTION 5: Refer to the following short article about web vulnerability search engines [https://www.deepdotweb.com/2016/09/11/5-hacker-friendly-search-engines-must-use/] to get an idea about the drastic state of vulnerability related to internet-connected devices not only including “computers and smartphones. It [web vulnerability search engine] can find such things as wind turbines, traffic lights, license plate readers, refrigerators, and practically anything else with an internet connection. […] Many of these devices that we rely on every day have little to no security protecting them. For a hacker, that’s a dream come true (is it not?).”. “If, by chance, one of your personal devices shows up in a Shodan [web vulnerability search engine] search, and reveals information you’d rather not have made public, then that’s your opportunity to patch up the holes! For pen [penetration] testers, this sort of data is just as valuable.” I.4.2 Ideas You should not work with the VirtualBox guest additions [http://www.virtualbox.org/manual/ch04.html] in order to somehow get rid of the BACK-UP-HDD volume which is described in chapter III.2.1 in great detail. The usage of the guest additions usually introduces a security issue we do not want to deal with. Anyway there are no Shared Folders established between Debian and Whonix by default. Refer to [https://www.whonix.org/wiki/VirtualBox_Guest_Additions#Warning] for further information. Do not try to skip strategic steps which might seem unreasonable at first sight. Do your own research and try to understand the different aspects of the whole setup. Keep in mind that this guide is addressed at the ordinary user who is willing to learn. Do not expect there will not occur any issues while assembling all the parts. It takes time and a lot of patience. The more you have tested, the more details you know, the better your results. If there will occur unknown errors you might want to close the current program, restart it again or even reboot the OS, otherwise refer to Appendix A3.1. We will not use the “Tor Browser (AnonDist)” or other crucial software provided by the WhonixWorkstation due to a strict “security by isolation” approach which is described in chapter I.2. I.4.3 Software In general and under any circumstances you should only install additional software in case you cannot establish a clean and stable workaround for a given problem with the basic software which is already installed on your system. Or on the other hand if the additional amount of work and/or time for such a workaround is untenable at all. Always try to work out a minimalistic approach to handle complex systems. Anyway, this guide mentions all additional software you have to install step-by-step in great detail. 31

Do not believe in “bullet-proof” solutions. Try to find out who maintains the software you (have to) trust (chapter I.3.1.1) and review the source code if possible or read security audits if available for best practice. It is very important to only work with the latest reviewed software in order to minimize the attacking surface as much as possible, this is very important you have to understand and agree too. I.4.3.1 Why cryptocurrencies might not work at all on the long run ATTENTION 1: Bitcoin and related cryptocurrencies are just a technology build on top of the Internet using TCP/IP [https://en.wikipedia.org/wiki/Internet_protocol_suite] meaning they are highly vulnerable to all kinds of computer problems (software and hardware) which are already known and of course especially to those problems only very few people know of and understand so far. Under any circumstances always try to avoid using closed-source software. “Microsoft Windows and Mac OS X being proprietary software, they cannot be considered trustworthy.“ [https://tails.boum.org/doc/advanced_topics/virtualization/virtualbox/index.en.html] Especially, be instructed about the huge privacy and security issues in Windows 10 [https://en.wikipedia.org/wiki/Windows_10#Privacy_and_data_collection] such as Windows 8. You are strongly encouraged to read the Free Software Foundation's statement on Windows 10 [https://www.fsf.org/news/the-fsfs-statement-on-windows-10] such as a list from the GNU project discussing Microsoft's Software is Malware [https://www.gnu.org/proprietary/malwaremicrosoft.en.html]. Read about the fundamental problems relating to Windows OSes and Microsoft in general according to Whonix [https://www.whonix.org/wiki/Pre_Install_Advice#Windows_Hosts]. “Microsoft 'silently' updates users' machines even if they have Windows Update disabled. [http://voices.washingtonpost.com/securityfix/2007/09/microsofts_stealth_update_come.html], [http://www.zdnet.com/blog/hardware/confirmation-of-stealth-windows-update/779] [...] Additional privacy risks have been introduced with Windows 8. One example is the smartscreen filter, which reports to Microsoft what software you are running on your computer. [http://log.nadim.cc/?p=78] This feature includes a kill switch that can allow Microsoft (or any one with an exploit for this mechanism) to delete programs on your machine without your consent. [http://www.pcmag.com/article2/0,2817,2400985,00.asp] Windows 10 takes surveillance of users to a whole new level. It snoops on the users' files, text input, voice input, location info, contacts, calendar records and web browsing history, as well as automatically connecting the machines to open hotspots and showing targeted ads. [...] Before patching Windows, Microsoft is known to consult with intelligence agencies and provide information on security holes before they inform the public and fixes are produced. [https://www.techdirt.com/articles/20130614/02110223467/microsoft-said-to-give-zeroday-exploits-to-us-government-before-it-patches-them.shtml] Since the NSA also buys security holes from software companies [https://threatpost.com/nsa-bought-exploit-service-from-vupen-contractshows/102314] and uses them to gain unauthorized access into computer systems, [http://www.theguardian.com/world/2013/oct/04/tor-attacks-nsa-users-online-anonymity] it is 32

reasonable to assume that the NSA also uses information supplied by Microsoft and that Windows users are at a higher risk. Microsoft updates use weak cryptographic verification such as MD5 and SHA-1. [compare with chapter I.5.2#HINT 2, 3] […] As of Windows 10 (and beyond), you completely forfeit your privacy by using this OS.” In 2015, CoinTelegraph published a short article about Windows 10 – A Serious Threat To Bitcoin Privacy and therefore other cryptocurrencies [http://cointelegraph.com/news/115134/windows-10-aserious-threat-to-bitcoin-privacy] as well. On June 30th, 2016, CoinTelegraph published a short article about the current drastic state of vulnerability related to mobile devices. Why Smartphone Wallets Are Insecure, And How to Protect Your Bitcoin [https://cointelegraph.com/news/why-smartphone-wallets-are-insecure-and-how-toprotect-your-bitcoin]. “Smartphone wallets are completely insecure. There have been over 500 million downloads of emoji keyboards: keyloggers, spyware disguised as friendly emoticon keyboards. When you startup your smartphone wallet the first time, you may enter bitcoin info or add username/password credentials. These are shipped off to criminal servers remotely because of this kind of keyboard malware.” Mr. John McAfee [https://en.wikipedia.org/wiki/John_McAfee], an internationally-renowned information security pioneer, businessman and politician was present at the D10E Conference 2016 at the DASH table and discussed the very basics of insecure smartphone wallets (starting from the second minute in the video documentation below). He predicts that one day there will be a concerted large scale attack emptying most of the users mobile device wallets simultaneously if appropriate countermeasures will not have been applied in order to fix this serious problem. This would damage the reputation of all cryptocurrencies irrevocably. This fundamental problem has to be taken into account seriously while developing DASH Evolution (compare with chapter VI) due to the fact that this approach brings cryptocurrency to the large public very effectively. Not very far in the future a significant amount of people on the planet will be fitted with mobile devices and will also conduct financial services on those devices for sure. As of writing those devices currently available cannot be considered as reasonably secure but highly vulnerable. Therefore they are inappropriate to conduct any kind of serious activities, especially for financial services. DASH Soda Machine Goes to San Francisco D10E Conference, John Mcafee Calls it Fkn Awesome (7:47 mins) https://www.youtube.com/watch?v=q0gexrg4ED4 ATTENTION 2: It is hereby mentioned explicitly that a large scale attack will not be limited at all to weak mobile devices with Android [https://en.wikipedia.org/wiki/Android_(operating_system)] installed or iPhone [https://en.wikipedia.org/wiki/iPhone] devices running Apple's iOS mobile OS. You are encouraged to read about the drastic security and privacy issues relating to Android [https://en.wikipedia.org/wiki/Android_(operating_system)#Security_and_privacy] such as recent events relating to iPhone security [http://motherboard.vice.com/read/government-hackers-iphonehacking-jailbreak-nso-group]. ““This indicates the incredible power of the voices of journalists and activists who attract this kind of extremely expensive spyware,” Railton said. Ultimately, this could be 33

a sign of things to come. “The people that we see being targeted by these texts today—dissidents, activists—these are kind of the people on the frontlines of what is to come for all of us tomorrow, these guys are sort of the canaries in the coal mine,” Marczak said. “The threats that they are facing today are threats that perhaps ordinary users will face tomorrow.”” You can easily imagine that zero-day exploits [https://en.wikipedia.org/wiki/Zero-day_attack] and other attacking vectors for emptying the users wallets on desktop computers like Microsoft Windows and Mac OS X systems will be applied too with high probability in order to launch this attempt successfully. Never forget that there is also an interest in attacking Debian (and related) systems. Especially, read chapter I.4.1 again and try to avoid serious errors. ATTENTION 3: For purposes of researching mobile device online payment methods you should only work with clean devices with just the software installed you really need. Always use proxies (e.g. Tor) to protect yourself and never use money you cannot afford to loose entirely. First of all, read about CyanogenMod [https://en.wikipedia.org/wiki/CyanogenMod], F-Droid [https://en.wikipedia.org/wiki/F-Droid] and related subjects to get an idea of the underlying problems and the free and open-source alternatives available today. I.4.3.1.1 Counter-measures As of writing the most successful solution to secure your cryptographic applications is to secure your cryptographic keys correctly. Usually, it is much easier to simply steal a private key than cracking a strong cryptographic message instead. This is because most computer systems are never up-to-date and/or protected and configured correctly but they are still connected to the Internet or any other insecure network allowing anyone with sufficient knowledge to scan for data, attack and exploit. Therefore encryption alone cannot solve the problem. Encryption works. Properly implemented strong crypto systems are one of the few things that you can rely on. Unfortunately, endpoint security is so terrifically weak that NSA can frequently find ways around it. [http://www.guardian.co.uk/world/2013/jun/17/edward-snowden-nsa-files-whistleblower] One idea to this problem is to consequently isolate different working areas from each other and only allow restricted access on different domains, compare with discussion in chapter I.2.5. In the future we have to take a much closer look at the hardware we use every day and we will also have to refuse to work with hardware which is not open-source hardware [https://en.wikipedia.org/wiki/Opensource_hardware] as a solution to protect against backdoors, etc. which are currently build in as default on almost any computing device. If you can't hack your device, you don't own it. Another very intuitive solution is to further educate yourself and the community on a regular basis to protect against serious computer and social engineering [https://en.wikipedia.org/wiki/Social_engineering_%28security%29] attacks with the attempt to steal 34

your (online/electronic) identity, coins, private files, etc. You can only make good use of any technology if you understand its core principles. We furthermore have to expand our research and development activities and explain our products to the general public with the help of effective campaigns. I.4.4 Hardware The Tails project maintains a list of known issues such as problematic USB sticks, computers, etc. which can be found here [https://tails.boum.org/support/known_issues/index.en.html]. Any of those USB sticks mentioned in this source should not be used as a dedicated USB drive where any OS is supposed to be installed on. Therefore such a device should never be purchased for the installation of Debian and Tails. The Debian project maintains a so-called DebianOn archive [https://wiki.debian.org/InstallingDebianOn] which “[...] is an effort to document how to install, configure and use Debian on some specific hardware. Therefore potential buyers would know if that hardware is supported and owner would know how [to] get the best out of that hardware.” Those two websites are also the first starting point in the case of hardware (and usually firmware) problems. I.4.4.1 USB drives requirements Table 2 gives an overview about the technical conditions for the required USB drives, mainly the required sizes. Keep in mind that regarding the way you will use the Debian system and everything which will be installed (and tested) on it and therefore saved to the drive you might end up with even higher values for the required size of the drive. The overview below only takes a standard installation and setup into account as outlined in the guide and does not cover extensive testing which reduces free disk space remarkably. In order to work without any restrictions it is highly recommended to work with two different USB drives as it is recommended to work with two different computers (read chapter I.5.5, Table 6 to find out if this requirement is needed in your specific situation). Only purchase USB 3.0 drives if your hardware can handle this additional performance feature otherwise you will pay for features you are unable to use at all. # drive drive name OS [GB] 1. Tails 2.6 2. Debian 7.5

INSTALL [GB] 14

BC [GB] SUM [GB] 2.6 1 22.5

REQ DRIVE [GB] 4 32

where: OS – OS size after installation (including all partitions [https://en.wikipedia.org/wiki/Disk_partitioning] such as additional swap areas; defined as total 35

capacity of the drive minus free space available directly after installation) INSTALL – size of additional software, etc. BC – block chain size REQ – required USB drive size (at least) The data of drive #2 is derived from a Debian test installation with a 32 GB USB drive. Table 2: Different USB drives and required sizes (estimations) As outlined in the First Steps category on the Tails website [https://tails.boum.org/doc/first_steps/media/index.en.html], USB drives are treated equally in comparison to SD cards therefore you are not forced to only use USB drives. Anyway, you should still prefer USB drives over SD cards, since there are known compatibility problems with SD cards. You have to find this out on your own and in your specific situation. I.5 Recommended software to get you started After reading the whole guide it is recommended to read this whole chapter again as it contains a list of software you have to download in advance. The software has been tested carefully and the whole setup runs smoothly, refer to APPENDIX A1 for detailed information. I.5.1 How to download sensitive files with Tor Browser – An approach ATTENTION 1: Even if this might be confusing, from now on we will assume you already have a clean (malware-free, etc.) OS and Tor Browser installed, preferably you already are a Tails user (Tails already includes the Tor Browser as default Internet Browser). Keep in mind that the whole setup expands the overall security while working on sensitive files. But in order to start you already need a secure starting point (mainly clean computer). This is comparable to a chicken-and-egg problem and a possible solution is discussed in chapter I.5.4. Definition: sensitive file A file containing important information which will be used in a later step/situation again. It represents some kind of certain value. If the user is not the original author of this file the user has to somehow make sure he/she receives an uncorrupted version of this file of course. Typical examples of sensitive files are PGP public keys (signing keys), verification checksums, etc. How can I make sure I have not downloaded a malicious file? First of all you have to understand the underlying problem. The Tails download website gives you a rough idea [https://tails.boum.org/download/index.en.html#index3h1]. Since the solution to this problem is complex you have to read and understand chapter I.5.2 and chapter I.5.3, too. Working with Tor there is always the low possibility (empirically derived) you connect to a malicious 36

Exit Node and/or website you might get corrupted files from (in case you are not connected with a Tor Onion Service, read chapter I.3.3 which has not been hacked by a third party). There exists no perfect solution which protects the user each time he/she connects with a Tor Exit Node (and a web server) but we will discuss some practical approaches to minimize the risks in a remarkable way. In addition to this there is always a comprehensive discussion for each approach in this guide to allow for a better understanding. In order to get a file correctly from a web server onto your computer we will discuss the procedure of multiple downloads of a sensitive file in this chapter, simply by downloading the file several times via different Tor Exit Nodes and compare those files/data afterwards against each other (chapter I.5.2). Since this technique is only a general approach you cannot rely on it absolutely. Read the Tails Download and verify using OpenPGP website [https://tails.boum.org/install/download/openpgp/] especially OpenPGP Web of Trust for a better understanding of this subject and also chapter I.5.3. This idea is based on [https://archive.org/, https://tails.boum.org/doc/get/trusting_tails_signing_key/index.en.html#index1h1] and the fact that Tor Exit Nodes can eavesdrop on communications [https://tails.boum.org/doc/about/warning/index.en.html#index4h1] and they are also able to behave in a way the user usually does not want to. Read about Tor malicious Exit Nodes on the threatpost website [https://threatpost.com/researcher-finds-tor-exit-node-adding-malware-to-binaries/109008] to get an idea of the fundamental problems we have to deal with. Also read [http://boingboing.net/2016/07/01/researchers-find-over-100-spyi.html]. Furthermore read about the Tails Man-in-the-middle attacks explanation [https://tails.boum.org/doc/about/warning/index.en.html#index6h1]. ATTENTION 2: Once you have opened the Tor Browser you should always click on the onion icon and select Privacy and Security Settings... at first, compare with [https://tails.boum.org/doc/anonymous_internet/Tor_Browser/index.en.html#index3h2]. A new window pops up. In the majority of cases (in this guide) you are fine in selecting High instead of Low (Default) in the Security Level section. HINT 1: A new identity within the Tor Browser can be achieved by clicking on Tor Browser → Onion icon → New Identity [https://tails.boum.org/doc/anonymous_internet/Tor_Browser/index.en.html#index4h2]. Make sure you have read and well understood the corresponding Tails Warning [https://tails.boum.org/doc/about/warning/index.en.html#index11h1] documentation. Repeat this step each time a download has completed and before downloading the same file again. You might want to think about downloading a sensitive file several times but on different days with different Tails sessions respectively. Compare with chapter I.5.5, Table 6 to get an idea of where to store the downloads and how to handle this approach in practice. HINT 2: To avoid being redirected to the Tails News website [https://tails.boum.org/news/index.en.html] every time you open the Tor Browser again, enter the following address [about:preferences] in the address bar of the Tor Browser (alternatively: File → Edit → Preferences) and change the entry General → Startup → When Tor Browser starts: to Show a blank page. 37

I.5.1.1 Accumulated downloads – Risk analysis For the following we make the fundamental assumption that the majority of all Tor Exit Nodes are acting honestly and only a few of them have to be considered as bad actors. We define the case of ending up at a malicious Tor Exit Node as X and therefore the probability of such an event as p(X). We furthermore assume the probability p(X) of selecting a random Tor Exit Node to be constant. Index n indicates the number of accumulated X cases. Downloading 2 infected files in a row is represented by the formula p(X=2) = (p(X))^2 (I.5.1.1a) and generally speaking p(X=n) := (p(X))^n (I.5.1.1b) For obvious reasons the probability of downloading infected files in a row caused by bad Tor Exit Nodes drops exponentially with n due to the fact that p(X) < 1, compare with (I.5.1.1b). Since it is very hard to find representative values of p(X) we will assume a randomly chosen value to be able to point out the convergence of the hyperbola function (Table 3) in an easy way. With a theoretical value for p(X) = 0.01 we get the following distribution. Note that the actual value of p(X) might be much smaller. n [-] 1 2 3 4 5

p(X=n) [%] 1 0.01 0.0001 0.000001 0.00000001

Table 3: Probability of downloading infected files in a row HINT: The approach of downloading with different identities is not limited to the Tor Browser exclusively. You can achieve the same effect by downloading with Wget (chapter I.5.5.1) for example or any other software configured to use Tor but this usually comes with challenges since there is no simple New Identity button in other software than the Tor Browser available. In such a case you should simply shutdown and restart Tails and consequently start your second download. I.5.2 How to compare data with checksum tool GtkHash Assuming you have downloaded a sensitive file (definition in chapter I.5.1) several times you can compare each file (or more generally speaking: data) against each other by hashing each file with a dedicated cryptographic hash function [https://en.wikipedia.org/wiki/Cryptographic_hash_function], [https://en.wikipedia.org/wiki/Cryptographic_hash]. The result will be a short and unique checksum [https://en.wikipedia.org/wiki/Checksum] representing the whole file. We will discuss this process with 38

the very powerful tool GtkHash available under Tails. ATTENTION: Checksums and signature files (which will be discussed later in this guide) are two very different topics. Both of the respective benefits can even be combined in an intelligent way but you have to understand the core differences in order to make good use of both techniques. The following is true for Tails. 1. Open a text editor: Applications → Accessories → gedit 2. Open GtkHash: Applications → Accessories → GtkHash 3. GtkHash → Edit → Preferences: Check MD5, SHA1, SHA256 and SHA512 (or whatever hash functions are needed) and close the preferences window again; (default configuration of digest format Lowercase Hexadecimal is fine) 4. Only select one of the multiple files in the file menu by clicking on the folder icon and finally click on the Hash button once the file is loaded into GtkHash 5. Write down the relevant calculated checksums of the actual file in gedit text editor as shown in Table 4 and pay attention to a correct alignment of the strings (this helps you while comparing the checksums) 6. Close GtkHash and repeat steps 2 to 6 for the remaining files File of interest: filename.abc SHA256 of 1st file: SHA256 of 2nd file: ... SHA256 of nth file:

YYY YYY

SHA512 of 1st file: SHA512 of 2nd file: … SHA512 of nth file:

ZZZ ZZZ

YYY

ZZZ

Table 4: Helpful arrangement of checksums in a text editor If the checksums are not always the same for a given hash function respectively, an error occurred and you should not continue to work with one of those files. An error might have various reasons. Go back to chapter I.5.1 and download the files again and repeat the integrity analysis as described in this chapter. HINT 1: It might look confusing to use several hash functions and not to only stick to one instead. In short: It is safer plus if you only use one hash function you really have to make sure you cleared your clipboard correctly (e.g. copy and paste some random characters to another line which looks different to your checksums) after pasting the checksum of file n to a text editor. In not doing so there is a 39

plausible possibility of pasting the previous checksum of file n to the corresponding line n+1. You definitely DO NOT want to enter a wrong measurement in your table (simple text file) since this compromises the whole security analysis and finally makes the analysis worthless. HINT 2: You should always prefer the cryptographically stronger SHA256 and SHA512 hash functions. - “For newer releases, newer and cryptographically stronger checksum algorithms (SHA1 [sic!], SHA256 and SHA512) are used [...]” [https://www.debian.org/CD/verify] - “The SHA256 checksums should be favored as the MD5 algorithm must be treated as insecure!” [http://www.virtualbox.org/wiki/Downloads] - “The CMU Software Engineering Institute said about MD5 in 2009, it "should be considered cryptographically broken and unsuitable for further use". [https://en.wikipedia.org/wiki/MD5#cite_note-11] In 2012, the Flame malware exploited the weaknesses in MD5 to fake a Microsoft digital signature. [http://arstechnica.com/security/2012/06/flame-crypto-breakthrough/]” [https://www.whonix.org/wiki/Pre_Install_Advice#Host_Operating_System] HINT 3: Due to recent events (compare with blog post “Backdoored Linux Mint, and the Perils of Checksums” [https://micahflee.com/2016/02/backdoored-linux-mint-and-the-perils-of-checksums/]) you should pay even more attention to chapter I.5.3 regarding the following statements. - “MD5 should never be relied on for verifying that you have the legitimate version of a file.” - “Wikipedia’s SHA1 article [https://en.wikipedia.org/wiki/SHA-1] says: “SHA-1 is no longer considered secure against well-funded opponent.”” - “It would be great if the Linux Mint project can completely stop relying on MD5 and started using a checksum algorithm that is considered secure today, like SHA256.” Those arguments are also true for the Debian release team and should be changed as soon as possible since the additional efforts for this step are nonexistent. The discussion above has serious consequences relating to chapter I.5.5.2.1.3. I.5.3 How can I verify my download is correct and exactly what has been created by author X? I.5.3.1 Background information In order to solve this problem you additionally have to get familiar with a software called “Pretty Good Privacy” also known as PGP [https://en.wikipedia.org/wiki/Pretty_Good_Privacy/] since you already know about checksums/hash functions. While talking about PGP we usually work with GNU Privacy Guard/GnuPG also known as GPG [https://en.wikipedia.org/wiki/GNU_Privacy_Guard]. PGP and GPG are usually not clearly distinguished from each other meaning you will find both expressions for the identical meaning (they are practically used interchangeably). In addition to this we usually refer to OpenPGP while talking about PGP/GPG [https://www.whonix.org/wiki/OpenPGP]. OpenPGP is a standard for data encryption that provides cryptographic privacy and 40

authentication through the use of keys owned by its users. [https://www.whonix.org/wiki/VirtualBox#cite_note-3] The Debian verify website [https://www.debian.org/CD/verify] gives a great overview about this topic and explains how to work with it very efficiently. Keep in mind, not only OSes but any file can be signed and verified by any user on the planet. This verification process can be done locally without any Internet connection and no need for any central authority but just applied cryptography, especially public-key cryptography [https://en.wikipedia.org/wiki/Public-key_cryptography] as shown in the following examples. “There are files here (SHA1SUMS, SHA256SUMS, etc.) which contain checksums of the [Debian] images. These checksum files are also signed - see SHA1SUMS.sign, SHA256SUMS.sign, etc. Once you've downloaded an image, you can check: - that its checksum matches that expected from the checksum file; and - that the checksum file has not been tampered with.” [http://cdimage.debian.org/debian-cd/8.6.0/amd64/iso-cd/] “Official releases of Debian CDs come with signed checksum files; look for them alongside the images in the iso-cd, jigdo-dvd, iso-hybrid etc. directories. These allow you to check that the images you download are correct. First of all, the checksum can be used to check that the CDs have not been corrupted during download. Secondly, the signatures on the checksum files allow you to confirm that the files are the ones officially released by the Debian CD / Debian Live team and have not been tampered with. To validate the contents of a CD image, just be sure to use the appropriate checksum tool. [...] To ensure that the checksums files themselves are correct, use GnuPG to verify them against the accompanying signature files (e.g. MD5SSUMS.sign [sic!]). The keys used for these signatures are all in the Debian GPG keyring [http://keyring.debian.org/] and the best way to check them is to use that keyring to validate via the web of trust. To make life easier for users, here [https://www.debian.org/CD/verify] are the fingerprints for the keys that have been used for releases in recent years.” [https://www.debian.org/CD/verify] I.5.3.2 Verification techniques in practice At first read the Whonix Download Security website [https://www.whonix.org/wiki/Download_Security] in order to understand why this whole chapter is necessary and fundamental. Subsequently, read an introduction to public key cryptography and PGP on the EFF website [https://ssd.eff.org/en/module/introduction-public-key-cryptography-and-pgp]. Since almost every file integrity check slightly differs from another one we will discuss those techniques for the download of Debian (chapter I.5.5.2.1), Whonix (chapter I.5.5.3.1) and the DASH 41

wallet software (chapter I.5.5.4.1) for clarification purposes in great detail. This will motivate the beginner and increases the learning success because of the possibility to compare the personal results with those results provided in the instructions in conjunction with the theoretical knowledge available. To avoid repetition of exact explanations for the three verification processes, the Verify Debian chapter will be the biggest one to work through and the following ones only discuss the substantial differences in comparison to each other, respectively. Anyway, no important steps are ever skipped in each chapter. HINT 1: It is very likely that the three verification chapters will cause a lot of confusion and frustration if you are a beginner. It might be an option to start with Debian at first. Afterwards try DASH wallet software and later on finish with Whonix which allows to verify a lot of different files. Below is a draft from Launchpad of how to use PGP in practice. In this short guide we make the assumption that the PGP public key is always available on a public key server [https://en.wikipedia.org/wiki/Key_server_%28cryptographic%29]. Keep in mind that this is not always true, but in most of the cases. Launchpad: https://launchpad.net/+help-registry/verify-downloads.html Additionally, the Tor project published a short guide [https://www.torproject.org/docs/verifyingsignatures.html.en] explaining how to verify GPG signatures. It is strongly recommended to read the instructions to get a better understanding of the challenges every user has to face and to understand. HINT 2: In order to achieve a high working quality it is strongly recommended to document your integrity checks. This will help you a lot and makes things comprehensible later. Simply create a text file (Applications → Accessories → gedit) and write down the steps you executed. Each integrity documentation file should contain a chronological order of the principal steps (1) core question/planned analysis, (2) measurements and (3) conclusions. I.5.4 Get Tails I.5.4.1 Get Tor Browser ATTENTION 1: Before starting to work seriously with Tor (and Tails) you should be familiar with all the different PGP (public key) verification techniques and also cryptographic verification checksums techniques as discussed in this guide. Once you have understood the core principles return to this chapter. You are also advised to read chapter I.5.5.2.1 again and pay special attention to I.5.5.2.1.1#ATTENTION 1 such as I.5.5.2.1.1.1 (malicious PGP private key discussion). Always check the integrity of the Tor Browser and other important downloads as described in each download section on their respective website and in this guide. Always consider the following warning which is not valid for the Tor software exclusively. How do you know that the Tor program you have is really the one we made? Many Tor users have very real adversaries who might try to give them a fake version of Tor — and it doesn't matter how secure and anonymous Tor is if you're not running the real Tor. 42

[https://www.torproject.org/docs/verifying-signatures.html.en] ATTENTION 2: Exclusively download from those web servers we have mentioned explicitly in this guide. Do NOT download from dubious websites/mirrors since they usually contain malware and other risks and they are also NOT under the control of the original authors of the respective software. Usually it is advised to visit the Tor project website [https://www.torproject.org/] in advance and download the Tor Browser because this software is less suspicious to an adversary than Tails for example. Another layer of security is to check the fingerprints of the SSL certificate of https://www.torproject.org/ against those provided in this article, compare with Figure 2.

Figure 2: Fingerprints of the SSL certificate of https://www.torproject.org/ You are strongly encouraged to check the downloaded PGP public key of the Tor Browser Developers (available here [https://www.torproject.org/docs/signing-keys.html.en]) against the one provided in this article and AFTERWARDS apply a PGP verification to the downloaded Tor Browser before actually start working with the Tor Browser. Keep in mind that this also requires you to download the respective signature file of the Tor Browser. Especially read the corresponding documentation here [https://www.torproject.org/docs/verifying-signatures.html.en]. In case you are already running a Linux based OS this makes life much easier in order to start working with PGP since GPG is installed on all major Linux distributions by default. pub 4096R/0x4E2C6E8793298290 2014-12-15 Tor Browser Developers (signing key) Key fingerprint = EF6E 286D DA85 EA2A 4BA7 DE68 4E2C 6E87 9329 8290 sub 4096R/0x7017ADCEF65C2036 2014-12-15 [expires: 2017-08-25] sub 4096R/0x2E1AC68ED40814E0 2014-12-15 [expires: 2017-08-25] sub 4096R/0x2D000988589839A3 2014-12-15 [revoked: 2015-08-26] Visit [https://www.torproject.org/docs/signing-keys.html.en]) several times (as already discussed in chapter I.5.1) and search the website for the key “EF6E 286D DA85 EA2A 4BA7 DE68 4E2C 6E87 9329 8290” which is the key fingerprint of the Tor Browser Developers. In comparison to the PGP public key of the Tails developers (chapter I.5.4.2) there is no single file of the Tor Browser Developers available on their website to download. Instead, use the gpg --recv-keys command as shown in chapter I.5.5.2.1.1.1, (I.5.5.2.1.1.1a) and below. 43

Open a terminal and run gpg --recv-keys EF6E286DDA85EA2A4BA7DE684E2C6E8793298290

(I.5.4.1a)

You have to get back the following output (showing up in Tails as of writing). gpg: requesting key 0x4E2C6E8793298290 from hkps server hkps.pool.sks-keyservers.net gpg: key 0x4E2C6E8793298290: public key "Tor Browser Developers (signing key) " imported gpg: no ultimately trusted keys found gpg: Total number processed: 1 gpg: imported: 1 (RSA: 1) Now, you are able to first verify the Tor Browser download before actually start working with it. Since the verification process of the Tor Browser is similar to the one of Debian, feel free to read chapter I.5.5.2.1.2 again to get the basic idea. I.5.4.2 Get Tails with Tor Browser Equipped with the Tor Browser you are now fine to download the latest version of Tails [https://tails.boum.org/install/download/index.en.html] (compare with chapter I.2.6.1) with the Tor Browser and burn the tails-i386-XXX*.iso Tails ISO image [https://en.wikipedia.org/wiki/ISO_image] to a DVD with your current (better: newly installed) OS. Another layer of security is to check the fingerprints of the SSL certificate of https://tails.boum.org/ against those provided in this article, compare with Figure 3.

Figure 3: Fingerprints of the SSL certificate of https://tails.boum.org/ For your convenience the Tails project suggests to install a browser add-on for the Tor Browser (/Firefox Browser) allowing you to download the Tails ISO image securely while automatically applying a checksum verification. Anyway the XPI add-on file [https://developer.mozilla.org/enUS/docs/Mozilla/XPI] is received via SSL connection, compare with chapter I.3.3 mentioning SSL technology. Be advised that visiting the Tails website [https://tails.boum.org/] in clear (NOT using the Tor Browser, e.g. Firefox Browser without changing any proxy settings) might get you into serious trouble 44

depending on the country and region you live in for now. You have to do your own research depending on the risk you are willing to take. If you experience problems connecting to Tor (or also for other reasons) you might want to try if bridge relays [https://www.torproject.org/docs/bridges.html.en] work in your specific situation. “Tor bridges are most of the time a good way of hiding the fact that you are connecting to Tor to a local observer.” [https://tails.boum.org/doc/about/fingerprint/index.en.html] You are strongly encouraged to check the downloaded PGP public key of the Tails developers (available here [https://tails.boum.org/news/signing_key_transition/index.en.html#index1h1]) against the one provided in this article and AFTERWARDS apply a PGP verification to the downloaded Tails ISO image before actually start working with Tails. Keep in mind that this also requires you to download the respective signature file of the Tails ISO image. Especially read the corresponding documentation here [https://tails.boum.org/install/download/openpgp/index.en.html]. Again, you should NOT simply download the tails-i386-XXX*.iso Tails ISO image directly from the web server but rather use the dedicated browser add-on and also avoid the BitTorrent alternative. pub 4096R/0xDBB802B258ACD84F 2015-01-18 Tails developers (offline long-term identity key) Key fingerprint = A490 D0F4 D311 A415 3E2B B7CA DBB8 02B2 58AC D84F uid Tails developers sub 4096R/0x98FEC6BC752A3DB6 2015-01-18 [expires: 2018-01-11] sub 4096R/0x3C83DCB52F699C56 2015-01-18 [expires: 2018-01-11] sub 4096R/0xAA9E014656987A65 2015-01-18 [revoked: 2015-10-29] sub 4096R/0xAF292B44A0EDAA41 2016-08-30 [expires: 2018-01-11] As described in great detail in chapter I.5.5.2.1.3 you are encouraged to also calculate the checksums of the Tails download against those provided in this article as an additional layer of security. As of writing there are no additional sources rather than in this guide available to check the tails-i386-XXX*.iso Tails ISO image checksums against. Table 5 shows an example of how to document your results in a simple text file. File of interest: tails-i386-2.7.1.iso 7457e7ef97d99e881e8ac233a095a51ab12495406125d8a43392e5b7b8d16d12 SHA256 dash-published 7457e7ef97d99e881e8ac233a095a51ab12495406125d8a43392e5b7b8d16d12 SHA256 gtkhash => OK 89f24a719dfc9ee4b96b1365972b36b8844c725c6853c3015b74755c8adc90598ec3dc7d8d664 5c4113c370db73ac1f7b3e3a2f58f6d3eb3cb840632d3caf0a6 SHA512 dashpublished 45

89f24a719dfc9ee4b96b1365972b36b8844c725c6853c3015b74755c8adc90598ec3dc7d8d664 5c4113c370db73ac1f7b3e3a2f58f6d3eb3cb840632d3caf0a6 SHA512 gtkhash => OK => ALL CHECKSUMS OK Table 5: Tails verification with checksums (documentation sample) Always keep in mind that there is no ultimate or “bullet-proof” solution of how to get an 100% uncorrupted version of the Tor Browser and Tails (or any other file) in an easy way and to do this without any person knowing about this. You always have to start from a not-infected machine and OS you (have to) trust, Debian GNU/Linux for example. If you do not keep your system up-to-date the probability of attacks and other risks rise exponentially. ATTENTION 1: The worst case scenario you definitely do not want to end up with would be a fake version of the Tor Browser installed or any other software we need, downloaded from a malicious source very early in the whole setup and you do not notice there went something wrong exposing you to all kinds of serious risks. If you now feel uncomfortable at this point, ask a friend to help you out with a fresh OS installation to get you started in order to somehow download Tails or directly ask someone you trust for a copy of Tails. “For example, you can start by contacting a local Linux User Group [https://en.wikipedia.org/wiki/Linux%5FUser%5FGroup], an organization offering Tails training [https://tails.boum.org/support/learn/index.en.html], or other Tails enthusiasts near you [...].” [https://tails.boum.org/install/download/openpgp/, slightly different context] Those people are more than happy to help you out. Anyway, even if your current (not live-) OS is/might be infected (on a harddisk level) you could simply bypass this problem by obtaining a clean copy of Tails on a DVD from a person you trust and simply start from this point without any need to care about your infected hard-disk (read chapter I.2.4 again for clarification). ATTENTION 2: If you cannot assure to start from a clean beginning point you should NOT continue with anything else. This is the most important fact you have to understand and agree too in order to work seriously on the whole setup. I.5.5 How to work with Tails “[...] Tails is designed to leave no trace on the computer you're using unless you ask it explicitly. It is important to understand some of the consequences of that.” [https://tails.boum.org/doc/encryption_and_privacy/your_data_wont_be_saved_unless_explicitly_aske d/index.en.html] Tails needs at least 2 GB of RAM to work smoothly [https://tails.boum.org/doc/about/requirements/index.en.html]. HINT 1: There is no need to somehow prepare a computer to work with Tails in advance in comparison 46

to the installation of Debian as emphasized in chapter II.1. You only have to make sure to be able to boot from a DVD or USB stick. Due to the fact that we will separate the download session in Tails entirely from the subsequent installation session of and on the Debian machine (DASH computer), the downloaded files have to be saved somewhere permanently. It is important to understand the restrictions while downloading files with the Tor Browser in Tails. To avoid confusion, please read the following for clarification [https://tails.boum.org/doc/anonymous_internet/Tor_Browser/index.en.html#index1h1]. The most secure way to exchange files between two sessions and preferably two computers is to burn those files to a CD/DVD therefore the files cannot be modified later. We will discuss the full procedure below. Keep in mind that (DVD+/-R)s are read-only, (DVD+/-RW)s are NOT read-only (similar to CD+/-R and CD+/-RW). If you have to install Tails on a USB drive you should only use a USB drive you can exclude that this device has already been used on dubious machines and you cannot handle to burn data to a CD/DVD as described in CASE 1 (Table 6) for a specific reason. HINT 2: As already mentioned in chapter I.4.4, the Tails project maintains a list of problematic hardware. Be informed about the limitations of securely deleting files and cleaning disk space [https://tails.boum.org/doc/encryption_and_privacy/secure_deletion/index.en.html#index2h1] if you do not want to use newly purchased USB drives. ADVANCED: This is optional. Anyway you might want to format a device at least and encrypt [https://tails.boum.org/doc/encryption_and_privacy/encrypted_volumes/index.en.html] it with a very strong random encryption key you are fine to forget and afterwards clean the available disk space [https://tails.boum.org/doc/encryption_and_privacy/secure_deletion/index.en.html#index5h1] in the encrypted partition before using it (afterwards you have to format the device again). This reduces the chances of getting data back while applying computer forensic tools by an adversary. Keep in mind that administration privileges are required for this additional step of security, refer to [https://tails.boum.org/doc/first_steps/startup_options/administration_password/index.en.html]. Additionally read about the limitations related to SSDs and USBs [https://www.whonix.org/wiki/Advanced_Security_Guide#Special_Advice_for_SSDs]. In general Tails is booted directly from a DVD, this is the most secure way to work with this live OS. But this comes with certain restrictions especially in this guide. Refer to “First steps with Tails” [https://tails.boum.org/doc/index.en.html] for further information and compare with Table 6 helping you to decide which is the best solution in your specific case. CASE 1: Most secure choice (might be unlikely) If your computer counts 2 optical drives and has sufficient* amount of RAM, this is the best choice to work with Tails. This way you boot Tails from a DVD, download a file to the RAM and directly burn it to a DVD (once available integrity checks of the download have been successful). specifications: => 2 x optical drive => sufficient* RAM *sufficient: compare with 47

[https://tails.boum.org/doc/anonymous_internet/Tor_Browser/index.en.html#index1h1] CASE 2: Secure choice (good compromise) Assuming there is NOT sufficient* RAM available you have to boot Tails from a DVD (recommended) first and afterwards copy Tails on a USB drive or SD card. For detailed instructions, read [https://tails.boum.org/doc/first_steps/installation/index.en.html]. The downloaded files will be stored in the Tails persistent volume* [https://tails.boum.org/doc/first_steps/persistence/configure/index.en.html]. Make sure you have read the warnings about persistence [https://tails.boum.org/doc/first_steps/persistence/warnings/index.en.html]. specifications: => 1 x optical drive => 1 x bootable USB drive or SD card, persistent volume* enabled persistent volume*: “This requires a USB stick or SD card of at least 4 GB.” [https://tails.boum.org/doc/first_steps/persistence/index.en.html]. Additionally, keep in mind that the remaining free space left on the persistent volume has to be at least as big as the size of the downloaded files. CASE 3: Hybrid scenario (recommended and suitable in most cases) This scenario is similar to CASE 2 but slightly more secure. You have the choice to boot Tails from a (A) DVD which is recommended or (B) USB drive or SD card. In both cases you download a file directly to a storage device* (compare with chapter I.5.5.1) you trust in case there is NOT sufficient* RAM available. This storage device* should preferably be encrypted [https://tails.boum.org/doc/encryption_and_privacy/encrypted_volumes/index.en.html] to protect your sensitive data. Due to the fact that you only have one optical device available to burn data onto a DVD you are forced to boot Tails from a USB drive or SD card sooner or later. According to choice (A) you have to shutdown your current Tails session and reboot from a USB drive or SD card again. If you have selected choice (B) you are ready to directly burn the downloaded files to a DVD without the need for a reboot (once available integrity checks of the download have been successful). specifications: => 1 x optical drive => 1 x bootable USB drive or SD card, NO persistent volume* enabled => 1 x storage device* (external hard-disk drive, external SSD, another USB drive, another SD card, etc.) storage device*: (1) the capacity has to be at least as big as the size of the downloaded files storage device*: (2) if your computer counts sufficient* RAM (but only one optical drive available) there is no need to use a storage device at all, compare with CASE 1 (this increases the security) according to CASE 3, choice (B) if you want to burn files directly to a DVD. Table 6: Comparison of bootable mediums for Tails and download procedure discussion HINT 3: There exist more possible combinations than those discussed above but they are less secure. HINT 4: “While shutting down [Tails], the data stored in RAM [https://en.wikipedia.org/wiki/Random %2Daccess%5Fmemory] is erased to protect from cold boot attacks 48

[https://tails.boum.org/doc/advanced_topics/cold_boot_attacks/index.en.html].” [https://tails.boum.org/doc/first_steps/shutdown/index.en.html] Also refer to [https://www.whonix.org/wiki/Advanced_Security_Guide#Cold_Boot_Attacks]. You can see such an attack in action and its implications published on YouTube. Lest We Remember: Cold Boot Attacks on Encryption Keys (5:22 mins): https://www.youtube.com/watch?v=JDaicPIgn9U I.5.5.1 How to download files with Wget Regardless of the way you are currently running Tails (compare with chapter I.5.5, Table 6) we suggest to only download files of large size (starting from ~100 MB) with a download manager tool such as Wget [https://en.wikipedia.org/wiki/Wget] which is installed by default. Please do not download CD or DVD images with your web browser the way you download other files! The reason is that if your download aborts, most browsers [such as the Tor Browser] do not allow you to resume from the point where it failed. [https://www.debian.org/CD/http-ftp/] According to the Tails About website [https://tails.boum.org/about/index.en.html] “all software is configured to connect to the Internet through Tor”, therefore you do not have to rely on the Tor Browser explicitly to be able to download files via Tor at all. Keep in mind that it is also possible to download files available on *.onion websites [https://en.wikipedia.org/wiki/.onion] as shown in chapter I.5.5.3 and already discussed in chapter I.3.3. To download a file with Wget simply follow the instructions below. Open a terminal (Applications → Utilities → Terminal) and run a command similar to wget -c URL -P DIRECTORY where: -c, --continue (resume getting a partially-downloaded file) [this is very helpful in case your download aborts] -P, --directory-prefix=PREFIX (save files to PREFIX/...) [wget --help] URL: the URL [https://en.wikipedia.org/wiki/Url] of the file you intend to download DIRECTORY: directory where you want to save your download to (preferably avoid folder names containing white space “ ” since this will not be resolved correctly if you simply copy and paste the path of a directory and do not adjust the full name of the path) HINT 1: If you just skip the -P argument (wget -c URL) the download will arrive in the /home/amnesia directory in Tails. In doing so make sure you have sufficient amount of RAM available 49

as discussed in chapter I.5.5, Table 6 beforehand. Saving a file directly to an external storage device, the command might look like in this example. wget -c http://cdimage.debian.org/debian-cd/8.6.0/amd64/iso-cd/debian-8.6.0-amd64-CD1.iso -P /media/My-USB-Drive/downloads/Debian HINT 2: If you receive an error in the terminal indicating that the host is unreachable and therefore the download does not progress simply re-run the exact command again. This can be done even days later. In theory the download will continue from the last bit where it stopped before. Anyway, be advised that this might lead to corrupt files which will force you to download the whole file again. I.5.5.2 Get Debian It is time to start the first Tails session and download Debian. Open the download section on the Debian website [https://www.debian.org/CD/http-ftp/#stable] with the Tor Browser (Applications → Internet → Tor Browser) and search the left column “CD” for the correct architecture of your DASH computer, this is usually amd64. HINT 1: If you do not know the bit-version (32 or 64) of your DASH computer you can find this out very easily by booting Tails on the machine you are interested in. Once booted click on Applications → System Tools → Settings and select Details. Under Overview you will find an entry called Base system indicating 32-bit or 64-bit (compare with [https://tails.boum.org/support/faq/index.en.html#index6h2]). Another layer of security is to check the fingerprints of the SSL certificate of https://www.debian.org/ against those provided in this article, compare with Figure 4. The download of the CD ISO is smaller in size compared to the DVD ISO and contains already all relevant packages plus a graphical desktop environment. Click on the corresponding link and scroll down to the bottom of the next page (Debian download directory).

Figure 4: Fingerprints of the SSL certificate of https://www.debian.org/ ATTENTION: Note that Debian ISO downloads are performed via a HTTP and not a HTTPS connection. This makes your download vulnerable to malicious Tor Exit Nodes (compare with chapter I.5.1). Therefore you have to pay special attention while verifying the downloaded files as shown in chapter I.5.5.2.1. 50

“Initially, you will only need to download and use the first image of a set (labelled as debiansomething-1 to be able to start the Debian installer and set up Debian on your computer.” [http://cdimage.debian.org/debian-cd/8.6.0/amd64/iso-cd/] “There are different versions of CD #1 here to allow for a choice of default desktop on installation, e.g. debian-something-kde-CD-1 contains the core pieces of the KDE desktop and will default to installing that desktop when used. The default desktop installed using debian-something-CD-1 is Gnome.” [http://cdimage.debian.org/debian-cd/8.6.0/amd64/iso-cd/] Grab the URL of the latest “stable” Debian ISO release, e.g. “http://cdimage.debian.org/debiancd/8.6.0/amd64/iso-cd/debian-8.6.0-amd64-CD-1.iso” copy it to your clipboard and continue with Wget (chapter I.5.5.1). HINT 2: From now on talking we assume the DASH computer is a 64-bit machine. I.5.5.2.1 Verify Debian download First of all you should read chapter I.5.3.2 again. There are several X.sign files with the corresponding X files in the Debian download directory available. Since the authors made different kinds of checksums available and for exercise reasons we will download all of them and run all of the possible integrity checks. Keep in mind that due to the possibility of malicious Tor Exit Node attacks (chapter I.5.1) and further reasons of security you should not simply download the files in a row. Instead click on Tor Browser → Onion icon → New Tor Circuit for this Site each time you intend to download a new file. Alternatively you may also save the URL first, then click on Tor Browser → Onion icon → New Identity and visit the website again. Scroll down to the files available on the Debian download directory, right-click on a specific file and select “Save Link as...”. As of writing the Debian download directory provides different files to download. The following ones are required to download. - MD5SUMS - SHA1SUMS - SHA256SUMS - SHA512SUMS - MD5SUMS.sign - SHA1SUMS.sign - SHA256SUMS.sign - SHA512SUMS.sign If you did not change the download folder your files are saved to /home/amnesia/Tor Browser.

51

As already mentioned in chapter I.5.3.1 you have to somehow make sure to get correct checksum files. If the correctness of those files is assured (by checking against its corresponding signature files) you have quite a good source of checksums published by the author. In the next step you will compare those checksums with your own measurements performed with GtkHash (chapter I.5.2). Since a calculated checksum is not dependent of a person or a geophysical location but only the data itself the following argument is true. If a user calculates the same checksum as the author calculated in the past the user can be sure he/she has got the correct file the author intended to receive at the user. Below we will discuss the verification process for Debian in great detail. I.5.5.2.1.1 Debian Signing Key The Debian signing key is needed in order to be able to verify the downloaded checksums. Since there are several ways of how to obtain the Debian signing key we will only discuss the most popular ones (two approaches are discussed). Anyway you are strongly encouraged to repeat both processes on your own. Both approaches are based on the simple idea of deriving the PGP public key (of the signer) from a downloaded signature file respectively. It is recommended to work with different Tails sessions while applying both techniques. You only have to download the required files until the end of the previous chapter once and save it to a storage device (preferably encrypted) in order to survive a reboot of Tails and to work with the different approaches provided below. The following is valid for both approaches. Open a terminal and run something like this gpg --verify SHA512SUMS.sign SHA512SUMS HINT 1: To simplify the process type in “gpg --verify ” (take care of the white space “ ” at the end of --verify). Afterwards drag and drop a X.sign file of choice and the corresponding X file directly from the file explorer inside the terminal. The correct file directories will be inserted automatically. Do not change the order of the files: (1) X.sign and (2) X. If both (1) X.sign and (2) X are saved to the same directory you may simplify the verification and only drag and drop (1) X.sign to the terminal resulting in “gpg --verify SHA512SUMS.sign” for example (GPG will search for (2) X automatically in the background). You are not restricted to the SHA512SUMS.sign at all, any of the other downloaded signature files also work fine (e.g. run the command “gpg --verify SHA256SUMS.sign” instead). You will get an output similar to this one. gpg: Signature made Sun 18 Sep 2016 04:23:45 PM UTC gpg: using RSA key 0xDA87E80D6294BE9B You will get an additional line 52

(I.5.5.2.1.1a)

gpg: Can't check signature: public key not found

(I.5.5.2.1.1b)

That is no problem at all as explained in chapter I.5.3.2#Launchpad and usual to Tails users since the Debian CD signing key (available in the Debian GPG keyring [http://keyring.debian.org/]) is not shipped and imported in your keyring by default which would allow to skip this chapter and to instantly verify the downloaded Debian files reducing potential errors significantly (this is also true for the Tor Browser Developers signing key, compare with chapter I.5.4.1) and should be fixed in a more recent version since Tails already heavily relies on Debian GNU/Linux such as Tor. HINT 2: In comparison to this the Tails OS itself makes use of the interesting fact that the PGP public key of the Tails developers (offline long-term identity key) for signing purposes is imported to your keyring by default in each Tails version (compare with chapter I.5.4.2). This means that once you own a genuine version of Tails you can always verify a new Tails release with the help of the PGP public key which is already available in the current Tails release without the need to always download and trust a new key again. Again, this is also comparable to a chicken-and-egg problem. In order to verify the integrity of the Debian checksum files you first have to get the PGP public key of the person/group who signed the file. The RSA key of the signer is expressed as 0xDA87E80D6294BE9B in this example, see above (I.5.5.2.1.1a). ATTENTION 1: Before importing any key into your keyring found via the gpg --verify command above make sure you have already seen those 16 alphanumerical characters somewhere else. Those characters are an extract of the full fingerprint [https://en.wikipedia.org/wiki/Public_key_fingerprint] of the PGP public key (here: type RSA) and called key ID. “Make sure to verify the keys that you download, because there are several fake and maybe malicious Tails [and maybe also DASH, Debian, Tor, Whonix, etc.] keys on the key servers.” [https://tails.boum.org/doc/about/openpgp_keys/] If you are working with malicious keys in general and run a verification process which returns Good Signature this means that you have infected yourself successfully. Avoid this issue and apply different techniques to lower the inherent risks. ATTENTION 2: Do not simply copy and paste the commands provided in this and the following chapters. In order to fully benefit from this guide you should always be very sceptical about running commands with a “random” key ID you do not know and/or have not seen on your machine, too. Edit those commands and work with the key ID you get back on your own machine. This guide should only be used to check your own measurements against. Keep in mind that this version of the guide might also be corrupted in case you received it via an untrusted and/or vulnerable path such as HTTPS [https://tails.boum.org/doc/about/warning/index.en.html#index6h1], [https://tails.boum.org/support/faq/index.en.html#index5h2], etc. I.5.5.2.1.1.1 From a public key server This chapter describes the first approach of how to obtain the Debian signing key.

53

Visit https://www.debian.org/CD/verify several times (as already discussed in chapter I.5.1) and search the website for the key “DA87 E80D 6294 BE9B” which is the output of the terminal in this example, displayed in (I.5.5.2.1.1a). Another layer of security is to check the fingerprints of the SSL certificate of https://www.debian.org/ against those provided in this article, compare with Figure 4 (chapter I.5.5.2). Note the space holders after each 4 alphanumerical characters. Keep in mind you put trust in the displayed website (standard HTTPS) in not showing you corrupted key fingerprints. The same problem is discussed on the Trusting Tails signing key website [https://archive.org/, https://tails.boum.org/doc/get/trusting_tails_signing_key/index.en.html] including various solutions. In the lucky case of a series of matches you may now run the receive-keys command inside a terminal in order to receive the PGP public key from a public key server. gpg --recv-keys DA87E80D6294BE9B (I.5.5.2.1.1.1a) Another layer of security is to check the fingerprint of the Debian PGP public key against those provided in this article. DF9B 9C49 EAA9 2984 3258 9D76 DA87 E80D 6294 BE9B (Debian expires: Never) [hkp://pool.sks-keyservers.net]

CD

signing

key,

The following provides a discussion about the general approach of how to get the correct PGP public key of the signer and the fundamental underlying non-trivial problem. Since we have already presented the first approach of how to obtain the Debian signing key you now have a much better understanding of the overall idea (in comparison to reading the following discussion in the introduction for example). Definition: malicious PGP private key A person in possession of a PGP private key claiming to be the Debian CD / Debian Live team (or another crucial developer) but he/she is actually NOT the Debian CD / Debian Live team. The deviation can be shown easily by comparing the different fingerprints against each other. The fingerprints of all PGP keys which have ever been created is different in comparison to each other with extremely high probability as of writing. Note that any user does not know the fingerprint of the correct Debian CD / Debian Live team a priori unless they met in person or have other failsafe communication channels available. Anyway, we assume that if the key ID derived from the gpg --verify command originates from a malicious signature file and a corresponding malicious checksum file (signed with a malicious PGP private key) this would be noticed during the comparison process with the Debian Verify website with a high probability. Since all the different checksums are signed and created with the PGP private key of the (correct) Debian CD / Debian Live team and the fact that it is very unlikely that you downloaded only malicious signature files and the corresponding malicious checksum files (compare with chapter I.5.1) and you also cannot figure this out by visiting the Debian Verify website several times due to a permanent Man-in-the-middle attack [https://en.wikipedia.org/wiki/Man-in-the-middle_attack] you 54

would probably notice something went wrong in the next chapter I.5.5.2.1.2. According to Table 7 (in conjunction with chapter I.5.1) the probability is quite high that at least one message would NOT be Good signature but gpg: Can't check signature: public key not found (error message) instead again as demonstrated in chapter I.5.5.2.1.1, (I.5.5.2.1.1b). This would indicate that the current signature file from which the error message appeared from was not derived from a PGP private key you imported the corresponding PGP public key with the gpg --recv-keys command just beforehand, (I.5.5.2.1.1.1a). Additionally, if the downloaded Debian ISO image file is poisoned or somehow corrupted you would calculate OTHER checksums than an attacker shows you in his malicious checksum file which might have been arrived on your machine (as another layer of security but this is not directly related to PGP but to checksums itself, compare with the next chapter I.5.5.2.1.3). I.5.5.2.1.1.2 Debian Keyring (Web of Trust) This chapter describes the second approach of how to obtain the Debian signing key. Generally speaking this is the safer approach in comparison to standard HTTPS because “[...] you already trust apt-get, the APT [https://en.wikipedia.org/wiki/Advanced_Packaging_Tool] repository of your distribution.” [https://www.whonix.org/wiki/Whonix_Signing_Key#Web_of_Trust] Also compare with chapter II.3.1 and especially I.3.1.1. ATTENTION: “Installing additional software is at your own risk. Most additional software requires extra configuration to be able to connect to the network through Tor, and will not work otherwise. Some other software might, for example, modify the firewall and break the security built in Tails. Software not officially included in Tails is not tested for security.” [https://tails.boum.org/doc/first_steps/persistence/configure/index.en.html#index14h2] We will need administrative privileges for this task. Anyway, after finishing the download of the Debian keyring (this chapter) and the subsequent PGP verification process (chapter I.5.5.2.1.2) you should shutdown Tails immediately and you should not continue to work with the current Tails session anymore for better security (afterwards you are fine to reboot and start a new session). Start Tails and wait for the Tails [https://tails.boum.org/doc/first_steps/startup_options/index.en.html#index2h1].

Greeter

More options? Click on Yes and afterwards click on Forward Enter a temporary administration password [https://tails.boum.org/doc/first_steps/startup_options/administration_password/index.en.html] (at least 10 characters) for the current Tails session in order to perform administrative tasks. After doing so click on Login. If you forget to set a password or even forget the password itself you have to reboot and start from the beginning again because you will not be able to perform administrative tasks as a measure of security.

55

HINT 1: The administration password is only valid for one Tails session respectively and becomes meaningless once Tails has been powered off. The following is based on the Tails Trusting Tails signing key website [https://archive.org/, https://tails.boum.org/doc/get/trusting_tails_signing_key/index.en.html#index3h1] and describes the procedure of working with the Debian Keyring. 1. Open Root Terminal: Applications → System Tools → Root Terminal 2. Run: apt-get update 3. Run: apt-get install debian-keyring 4. Close the Root Terminal: exit This will download the following keyrings to your /usr/share/keyrings directory. (A) debian-keyring.gpg (B) debian-maintainers.gpg (C) debian-nonupload.gpg (D) debian-role-keys.gpg Go back to chapter I.5.5.2.1.1. The key ID you get back from the gpg --verify command (“DA87E80D6294BE9B” in this example, (I.5.5.2.1.1a)) should be inside the (D) debian-role-keys.gpg keyring. If this is true you can be sure that the signature file you downloaded was really created by the (correct) Debian CD / Debian Live team, compare with chapter I.5.5.2.1.1.1 (malicious PGP private key discussion). Execute the following steps to verify that you have derived the correct key ID. 5. Open (general) terminal: Applications → Utilities → Terminal 6. Run: gpg --keyring=/usr/share/keyrings/debian-role-keys.gpg --list-key DA87E80D6294BE9B You should get an output like this. pub 4096R/0xDA87E80D6294BE9B 2011-01-05 Key fingerprint = DF9B 9C49 EAA9 2984 3258 9D76 DA87 E80D 6294 BE9B uid [unknown] Debian CD signing key sub 4096R/0x642A5AC311CD9819 2011-01-05 Note that step 6 is similar to the already discussed approach of visiting the Debian Verify website several times (chapter I.5.5.2.1.1.1) but more secure because you do not have to trust HTTPS which might show you corrupted data since you already trust APT. If you get an error like this instead you might be a victim of a poisoned download, do NOT continue to work with the signature file you downloaded and derived the key ID from beforehand. gpg: error reading key: public key not found Assuming the process went fine you will have to import the PGP public key at first before being able to verify the checksum file is correct which means you downloaded the (correct) signature file published by the (correct) Debian CD / Debian Live team. 56

7. Run: gpg --keyring=/usr/share/keyrings/debian-role-keys.gpg --export DA87E80D6294BE9B | gpg --import HINT 2: Be instructed about the possibility of privacy leaks while working with the Web of Trust [https://en.wikipedia.org/wiki/Key_server_(cryptographic)#Privacy_concerns] in general if you are willing to provide personal information. Anyway, we do not have to face this potential danger in the whole guide in order to setup the security environment because we are never forced to somehow provide any personal information at all. HINT 3: Due to the fact that Tails already routes all of its traffic through the Tor network by design there is no need to install a workaround just like Apt-Transport-Tor (chapter II.3.1) before actually running commands like apt-get update and apt-get install just to name a few (starting from step 2 above). I.5.5.2.1.2 Debian & PGP Finally, re-run the first command already mentioned above gpg --verify SHA512SUMS.sign SHA512SUMS You should get an output similar to this. gpg: Signature made Sun 18 Sep 2016 04:23:45 PM UTC gpg: using RSA key 0xDA87E80D6294BE9B gpg: Good signature from "Debian CD signing key " [unknown] gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: DF9B 9C49 EAA9 2984 3258 9D76 DA87 E80D 6294 BE9B The most important indicator is the judgment of the signature in line 3, saying Good signature. If the message shows “BAD signature” instead, an error occurred or you might be a victim of a poisoned download. Do not continue to work with those files you just downloaded and repeat the integrity check after the new downloads have completed, again. Additionally, check line 1 against the Debian website [https://www.debian.org/] and look for latest stable release of Debian and also the Debian Wikipedia website [https://en.wikipedia.org/wiki/Debian]. Feel free to ignore the last 3 lines and read about Verify the virtual machine images using the command line [https://www.whonix.org/wiki/Verify_the_virtual_machine_images_using_the_command_line] for even more related information. Repeat the verification process for the remaining X.sign files with the corresponding X files. Any of those X.sign files must have been created by the same (correct) Debian CD / Debian Live team, refer to 57

chapter I.5.5.2.1.1.1 (malicious PGP private key discussion). Table 7 shows an example of how to document your results in a simple text file. gpg --verify MD5SUMS.sign => Good signature gpg --verify SHA1SUMS.sign => Good signature gpg --verify SHA256SUMS.sign => Good signature gpg --verify SHA512SUMS.sign => Good signature => ALL SIGNATURES GOOD Table 7: Debian verification with signatures (documentation sample) In the lucky case you always get a Good signature you are now ready to calculate the appropriate checksums on your own as described in the following chapter. I.5.5.2.1.3 Debian & Checksums ATTENTION: As emphasized at the end of chapter I.5.2, MD5 and SHA1 checksums cannot be considered trustworthy anymore. Instead refer to SHA256 and SHA512. The difference of Table 8 in comparison to Table 4 (chapter I.5.2) is the fact that you will only face 2 lines of checksums for each hash function you have to compare against each other. XXX XXX

hash function Z: checksum published by Debian CD team hash function Z: checksum personal GtkHash calculation

where: XXX – checksum hash function Z with Z = {MD5, SHA1, SHA256, SHA512} Table 8: Comparison of publicly available checksums vs. personally calculated checksums (scheme) Compare with chapter I.5.2 in order to calculate the four checksums with GtkHash. Note, you only have to run steps 1 to 5, because there is only one file (Debian *.iso image) to hash respectively. 58

Table 9 shows an example of how to document your results in a simple text file. File of interest: debian-8.6.0-amd64-CD-1.iso a4ea44bf44f6bf1a45ab37c58ba3c2e8 a4ea44bf44f6bf1a45ab37c58ba3c2e8 => OK

MD5 debian-published MD5 gtkhash

d0e0a19f9890201c0171f9f13473f62fbf908f69 d0e0a19f9890201c0171f9f13473f62fbf908f69 => OK

SHA1 debian-published SHA1 gtkhash

e9cb144e486409b2ea1454dceae8d46e0ebab88435cf0b6e7a18f3aa3a51c538 SHA256 debian-published e9cb144e486409b2ea1454dceae8d46e0ebab88435cf0b6e7a18f3aa3a51c538 SHA256 gtkhash => OK 2e5446789c6900617278a15319a34243d55471eba79e30bdd26685eae16aa80d09d46a867c3 97c37753404e087a2ee654fe22cac2ca7d5b2d22c5b36224605ce SHA512 debianpublished 2e5446789c6900617278a15319a34243d55471eba79e30bdd26685eae16aa80d09d46a867c3 97c37753404e087a2ee654fe22cac2ca7d5b2d22c5b36224605ce SHA512 gtkhash => OK => ALL CHECKSUMS OK Table 9: Debian verification with checksums (documentation sample) I.5.5.3 Get Whonix Open the Whonix website [https://www.whonix.org/] with the Tor Browser (Applications → Internet → Tor Browser) and select (Download) in the Linux → newcomer → VirtualBox (Download) section [https://www.whonix.org/wiki/VirtualBox#Landing]. Another layer of security is to check the fingerprints of the SSL certificate of https://www.whonix.org/ against those provided in this article, compare with Figure 5.

59

Figure 5: Fingerprints of the SSL certificate of https://www.whonix.org/ Click on [Expand] on the right available under 1) Download for Windows, Mac and Linux... to get an overview about the upcoming downloads. There are two main columns, one for Whonix-Gateway and the other one for Whonix-Workstation with various files available on the left hand side. As of writing there are no Tor Onion Service download links (compare with chapter I.3.3) provided to checksums and signature files in the standard Download Whonix section such as the VM files itself although they are available on the official Whonix Tor Onion Service [http://whonix4iscgg7zzk.onion/]. In order to expand the overall security we will not download from the standard Whonix website [https://www.whonix.org/] but rather from the Whonix Tor Onion Service. Therefore you are strongly encouraged to close the Tor Browser and restart it with a new identity (chapter I.5.1) and access the official Whonix Tor Onion Service. Currently, Whonix is available in stable version 13.0.0.1.1 [https://www.whonix.org/], which means the necessary files are located in this directory [http://whonix4iscgg7zzk.onion/13.0.0.1.1/]. Take a look at the directory, then grab the URL of the latest Whonix-Gateway file (Whonix-Gateway-XXX.ova) and continue with chapter I.5.5.1. Repeat for Whonix-Workstation file (Whonix-Workstation-XXX.ova) in the same way. Preferably create two different folders for the two VM images because there are a lot of files you have to deal with later on for each VM, respectively. HINT: As of writing checksum files are also available on the second official Whonix Tor Onion Service [http://kkkkkkkkkk63ava6.onion/download/13.0.0.1.1/] but not the important VM images for unknown reasons. It might be an option to also implement a browser add-on for the Whonix downloads as already shown in chapter I.5.4.2 already allowing the user to download the Tails ISO image securely while automatically applying a checksum verification. ATTENTION: The following overview might look frustrating at first. Keep in mind that this list is ordered by different file types and there meaning in the verification process and not in an alphabetical way as it is ordered on the web server of the Tor Onion Service. As of writing, Whonix provides different files to download. The following ones are required to download. (A) Whonix-Gateway-XXX.ova.asc (B) Whonix-Gateway-XXX.sha256sums (C) Whonix-Gateway-XXX.sha512sums 60

(D) Whonix-Gateway-XXX.sha256sums.asc (E) Whonix-Gateway-XXX.sha512sums.asc (A') Whonix-Workstation-XXX.ova.asc (B') Whonix-Workstation-XXX.sha256sums (C') Whonix-Workstation-XXX.sha512sums (D') Whonix-Workstation-XXX.sha256sums.asc (E') Whonix-Workstation-XXX.sha512sums.asc where: XXX represents the latest stable Whonix version (A) signature file of the Whonix-Gateway VM image ending with *.ova (B) SHA256 checksums of Whonix-Gateway (both VirtualBox and KVM provided) (C) SHA512 checksums of Whonix-Gateway (both VirtualBox and KVM provided) (D) signature file of the SHA256 checksums of Whonix-Gateway ending with *.sha256sums (E) signature file of the SHA512 checksums of Whonix-Gateway ending with *.sha512sums (A') signature file of the Whonix-Workstation VM image ending with *.ova (B') SHA256 checksums of Whonix-Workstation (both VirtualBox and KVM provided) (C') SHA512 checksums of Whonix-Workstation (both VirtualBox and KVM provided) (D') signature file of the SHA256 checksums of Whonix-Workstation ending with *.sha256sums (E') signature file of the SHA512 checksums of Whonix-Workstation ending with *.sha512sums I.5.5.3.1 Verify Whonix download The verification process of the Whonix-Gateway is identical for the Whonix-Workstation. Anyway, you have to verify both of the two VM images since skipping a single verification process (generally speaking Whonix-Gateway verification process with sub-verification processes and WhonixWorkstation verification process with sub-verification processes) is very likely to have disastrous consequences if already one file is poisoned in which you put trust in. HINT: There are several possibilities available of how to verify the Whonix VM images. It is strongly recommended not to only run one of those possibilities, but all of them since the Whonix OSes you are about to download and install will be responsible for your overall privacy and anonymity online. I.5.5.3.1.1 Whonix Signing Key This chapter is strongly related to chapter I.5.5.2.1.1. First, you are advised to read about the Debian 61

signing key again. Due to the fact that the Whonix Signing Key is only another name for the PGP public key of Whonix which will be used in a later process to verify the integrity of the downloaded files you also have to ensure that the PGP public key of Whonix will arrive uncorrupted on your machine. Compare with [https://www.whonix.org/wiki/Whonix_Signing_Key] for further details. I.5.5.3.1.1.1 Tor Onion Service download This chapter describes the first approach of how to obtain the Whonix signing key. You have to download the Whonix signing key which is available on the second official Whonix Tor Onion Service [http://kkkkkkkkkk63ava6.onion/wiki/Whonix_Signing_Key#Download_the_key]. You might even want to download it several times with different identities but this is not required at all in comparison to the upcoming chapter I.5.5.4.1.1.1 for example (compare with I.3.3). Since all the downloaded PGP public keys should always be the same it is up to you how to ensure this condition is true. Due to the fact that those files are simple PGP keys it is possible to skip chapter I.5.2 and compare them against each other in an easier way as described below in great detail. HINT: You might also want to download from the Whonix Signing Key website [https://www.whonix.org/wiki/Whonix_Signing_Key#Download_the_key]. This is a crucial step, so make sure you understand well the limitations of the Tor Browser, see chapter I.5.1 how to deal with this issue and download it several times with different identities. Open a terminal and run the command gpg patrick.asc HINT: Simply drag and drop the PGP public key “patrick.asc” to the terminal after you have typed in “gpg ” (take care of the white space “ ” at the end of the gpg command). You have to get back the following output. pub 4096R/0x8D66066A2EEACCDA 2014-01-16 Patrick Schleizer Key fingerprint = 916B 8D99 C38E AF5E 8ADC 7A2A 8D66 066A 2EEA CCDA sub 4096R/0x3B1E6942CE998547 2014-01-16 [expires: 2021-04-17] sub 4096R/0x10FDAC53119B3FD6 2014-01-16 [expires: 2021-04-17] sub 4096R/0xCB8D50BB77BB3C48 2014-01-16 [expires: 2021-04-17] Save the line of the output with the Key fingerprint = XXX to a new text file (gedit) and repeat this for each of the downloaded PGP public keys and compare the different lines, representing the different downloaded versions of the Whonix signing key as shown in Table 10. Key fingerprint: gpg patrick.asc 62

916B 8D99 C38E AF5E 8ADC 7A2A 8D66 066A 2EEA CCDA 916B 8D99 C38E AF5E 8ADC 7A2A 8D66 066A 2EEA CCDA 916B 8D99 C38E AF5E 8ADC 7A2A 8D66 066A 2EEA CCDA

download #1 download #2 download #3

=> ALL FINGERPRINTS IDENTICAL Table 10: Comparison of downloaded Whonix signing keys (documentation sample) ATTENTION 1: Remember to clear the clipboard correctly as already explained in chapter I.5.2#HINT 1. If the output of the terminal looks differently you should not continue to use one of the PGP public keys since the whole integrity check of Whonix is build on top of this. Once you have convinced yourself that you have received the correct PGP public key, right-click on the file and select “Open With Import Key”. ATTENTION 2: If you have already imported a key accidentally (double-click or right-click and select Open With Import Key) BEFORE checking against the other ones that is no problem at all. Undo by opening Applications → Utilities → Passwords and Keys and navigate to GnuPG keys. Select the PGP key of interest, right-click on it and select Delete. It is very important to only import a key after you got several matches beforehand. I.5.5.3.1.1.2 From a public key server This chapter describes the second approach of how to obtain the Whonix signing key. This approach is strongly related to chapter I.5.5.2.1.1 and chapter I.5.5.2.1.1.1 subsequently. Below, we will follow the same steps as already discussed in the Debian signing key chapter but with the Whonix-Gatway VM image instead. Open a terminal and run something like this gpg --verify SHA512SUMS.sign SHA512SUMS You will get an output similar to this one. gpg: Signature made Sat 14 May 2016 06:43:45 PM UTC gpg: using RSA key 0xCB8D50BB77BB3C48

(I.5.5.3.1.1.2a)

In order to verify the integrity of the checksum files you will first have to get the PGP public key of the person/group who signed the file. The RSA key of the signer is expressed as 0xCB8D50BB77BB3C48 in this example, see above (I.5.5.3.1.1.2a). Visit [http://kkkkkkkkkk63ava6.onion/wiki/Whonix_Signing_Key] such as [https://www.whonix.org/wiki/Whonix_Signing_Key] several times (as already discussed in chapter I.5.1) and search the website for the key “CB8D50BB77BB3C48” which is the output of the terminal 63

in this example, displayed in (I.5.5.3.1.1.2a). Another layer of security is to check the fingerprints of the SSL certificate of https://www.whonix.org/ against those provided in this article, compare with Figure 5 (chapter I.5.5.3). HINT: Note that this key ID (I.5.5.3.1.1.2a) actually is a subkey but related to the key fingerprint (compare with chapter I.5.5.3.1.1.1). In the lucky case of a series of matches you may now run the receive-keys command inside a terminal in order to receive the PGP public key from a public key server. gpg --recv-keys CB8D50BB77BB3C48 (I.5.5.3.1.1.2b) Another layer of security is to check the fingerprint of the Whonix PGP public key against the one provided in this article, compare with chapter I.5.5.3.1.1.1 and I.5.5.3.1.1.4. I.5.5.3.1.1.3 Debian Keyring (Web of Trust) The following is strongly related to chapter I.5.5.2.1.1.2. This chapter should be understood as a sub chapter of both I.5.5.3.1.1.1 and I.5.5.3.1.1.2, respectively and not as an independent one because there will be no download of the signing key executed. It will help you to verify the integrity of the Whonix signing key you are about to work with which has already been downloaded to your computer in a previous chapter. Start Tails and enter a temporary administration password. We will have to download the Debian Keyring. 1. Open Root Terminal: Applications → System Tools → Root Terminal 2. Run: apt-get update 3. Run: apt-get install debian-keyring 4. Close the Root Terminal: exit As mentioned on the Whonix Signing Key website [http://kkkkkkkkkk63ava6.onion/wiki/Whonix_Signing_Key#Web_of_Trust] “A few people signed Patrick Schleizer's [http://kkkkkkkkkk63ava6.onion/wiki/Patrick_Schleizer] (adrelanos') OpenPGP key in The OpenPGP Web of Trust [http://kkkkkkkkkk63ava6.onion/wiki/OpenPGP#The_OpenPGP_Web_of_Trust].” Below we will discuss how to verify the signatures of the people (exclusively from the Debian keyring) who signed this OpenPGP key. 5. Open (general) terminal: Applications → Utilities → Terminal 6. Run: gpg --keyring=/usr/share/keyrings/debian-keyring.gpg --export | gpg --import Step 6 will cause the import of 982 keys (unchanged: 7, Debian keyring (2013.04.21) last modified: Mon 22 Apr 2013 02:32:58 AM UTC) at the time of writing. 64

7. Import the Whonix signing key (should 916B8D99C38EAF5E8ADC7A2A8D66066A2EEACCDA, compare with chapter I.5.5.3.1.1.1)

be

8. Run: gpg --keyid-format long --list-sigs 916B8D99C38EAF5E8ADC7A2A8D66066A2EEACCDA Step 8 gives back a list of the signatures made by other people on Patrick Schleizer's (adrelanos') OpenPGP key. 9. Run: gpg --keyid-format 916B8D99C38EAF5E8ADC7A2A8D66066A2EEACCDA

long

--check-sigs

“On the output, the status of the verification is indicated by a flag directly following the "sig" tag. A "!" indicates that the signature has been successfully verified, a "-" denotes a bad signature and a "%" is used if an error occurred while checking the signature (e.g. a non supported algorithm).” [https://archive.org/, https://tails.boum.org/doc/get/trusting_tails_signing_key/index.en.html#index3h1] For example, in the following output the signature of Jan Dittberner on the Whonix signing key has been verified successfully: pub 4096R/8D66066A2EEACCDA 2014-01-16 [expires: 2016-10-05] Key fingerprint = 916B 8D99 C38E AF5E 8ADC 7A2A 8D66 066A 2EEA CCDA uid [unknown] Patrick Schleizer sig!3 8D66066A2EEACCDA 2014-01-16 Patrick Schleizer sig! A73E0055558FB8DD 2014-10-04 Jan Dittberner sig!3 8D66066A2EEACCDA 2014-10-06 Patrick Schleizer sub 4096R/3B1E6942CE998547 2014-01-16 [expires: 2016-10-05] sig! 8D66066A2EEACCDA 2014-10-06 Patrick Schleizer sub 4096R/10FDAC53119B3FD6 2014-01-16 [expires: 2016-10-05] sig! 8D66066A2EEACCDA 2014-10-06 Patrick Schleizer sub 4096R/CB8D50BB77BB3C48 2014-01-16 [expires: 2016-10-05] sig! 8D66066A2EEACCDA 2014-10-06 Patrick Schleizer 10 signatures not checked due to missing keys Another layer of security is to check the fingerprint of the PGP public key belonging to Jan Dittberner against the one provided in this article. B2FF 1D95 CE8F 7A22 DF4C F09B A73E 0055 558F B8DD Never) [https://jan.dittberner.info/] I.5.5.3.1.1.4 Additional resources 65

(Jan Dittberner, expires:

Another layer of security is to additionally check the downloaded PGP public key against the key fingerprint of Patrick Schleizer available on the official Whonix Tor Onion Service available as an image format. (1) http://whonix4iscgg7zzk.onion/WikiBackups/mediafiles/Patrick_schleizer_gpg_fingerprint_readable_r esized.jpg (2) http://whonix4iscgg7zzk.onion/WikiBackups/mediafiles/Patrick_schleizer_gpg_fingerprint_unreadable _resized.jpeg You may also check against social media websites [https://www.whonix.org/blog/whonix-signing-keyon-social-media]. Be advised: Due to their special privacy policies you should pay additional attention. (3) https://twitter.com/Whonix/status/684752774823841792 [https://twitter.com/Whonix/ on January 6th, 2016] (4) https://www.facebookcorewwwi.onion/Whonix/posts/1023794537662801 [https://www.facebook.com/Whonix on January 6th, 2016] I.5.5.3.1.2 Whonix & PGP There are three signature files for Whonix-Gateway such as three signature files for WhonixWorkstation available respectively we will check against the accompanying files. (A) Whonix-Gateway-XXX.ova.asc (D) Whonix-Gateway-XXX.sha256sums.asc (E) Whonix-Gateway-XXX.sha512sums.asc (A') Whonix-Workstation-XXX.ova.asc (D') Whonix-Workstation-XXX.sha256sums.asc (E') Whonix-Workstation-XXX.sha512sums.asc Open a terminal and run: gpg --verify Whonix-Gateway-XXX.ova.asc Whonix-Gateway-XXX.ova You should always get a Good signature output otherwise you should not continue to work with those files. Continue with (D) Whonix-Gateway-XXX.sha256sums.asc XXX.sha512sums.asc and also (A'), (D'), (E') on your own.

and

(E)

Whonix-Gateway-

Finally this verification will tell us in case you get a Good signature output that (1) the WhonixGateway-XXX.ova/Whonix-Workstation-XXX.ova VM image, (2) the (B) SHA256 checksums of 66

Whonix-Gateway/Whonix-Workstation and (3) the (C) SHA512 checksums of Gateway/Whonix-Workstation are the ones the author intended to arrive on your machine.

Whonix-

Table 11 shows an example of how to document your results in a simple text file. gpg --verify Whonix-Gateway-13.0.0.1.1.ova.asc => Good signature gpg --verify Whonix-Gateway-13.0.0.1.1.sha256sums.asc => Good signature Whonix-Gateway-13.0.0.1.1.sha512sums.asc => Good signature gpg --verify Whonix-Workstation-13.0.0.1.1.ova.asc => Good signature gpg --verify Whonix-Workstation-13.0.0.1.1.sha256sums.asc => Good signature gpg --verify Whonix-Workstation-13.0.0.1.1.sha512sums.asc => Good signature => ALL SIGNATURES GOOD Table 11: Whonix verification with signatures (documentation sample) HINT: This verification approach is slightly different to the Debian verification process (chapter I.5.5.2.1) where actually the calculated checksums of the Debian-XXX.iso file where signed and not the Debian-XXX.iso itself (Debian-XXX.iso is comparable to the VM images ending with *.ova, respectively). The Whonix verification approach additionally allows to check directly against (A) signature file of the Whonix-Gateway VM image and not only against its signed checksums which is beneficial. I.5.5.3.1.3 Whonix & Checksums Launch GtkHash (chapter I.5.2) and calculate the checksums of the Whonix-Gateway/WhonixWorkstation with the SHA256 and SHA512 hash functions. Enter your measurements inside a text file (gedit) and also enter the checksums you just downloaded before. Afterwards compare them against each other and document your results for each hash function.

67

Table 12 shows an example of how to document your results in a simple text file. File of interest: Whonix-Gateway-13.0.0.1.1.ova (Whonix-Gatway) 25fc5c6cc19f24a9bc10fb9c80dc03437ae413b96d39872ef6e0fdb9e9291152 whonix-published 25fc5c6cc19f24a9bc10fb9c80dc03437ae413b96d39872ef6e0fdb9e9291152 gtkhash => OK

SHA256 SHA256

9e5372e5f09ec7539b614453367ff60a1790d22ac49da398912d8a75ea5380d58dfa13444980 beaed66d216961aa1d9762129e59b74d5bff2cb370819fca2cec SHA512 whonixpublished 9e5372e5f09ec7539b614453367ff60a1790d22ac49da398912d8a75ea5380d58dfa13444980 beaed66d216961aa1d9762129e59b74d5bff2cb370819fca2cec gtkhash => OK => ALL CHECKSUMS OK File of interest: Whonix-Workstation-13.0.0.1.1.ova (Whonix-Workstation) fe8191e54c0284979b3b4be68fcb409d0e196e3e5708f4499a2fe41f09bab4c1 whonix-published fe8191e54c0284979b3b4be68fcb409d0e196e3e5708f4499a2fe41f09bab4c1 gtkhash => OK

SHA256 SHA256

573931cefd34d8778af6e1c4606aae9c6562d8bb9dac7b9e7e3ed4a10fdb6b4797657e631cee1 595bd29dd88e6d711c0ee34d3174374c5752011e49f40367f36 SHA512 whonixpublished 573931cefd34d8778af6e1c4606aae9c6562d8bb9dac7b9e7e3ed4a10fdb6b4797657e631cee1 595bd29dd88e6d711c0ee34d3174374c5752011e49f40367f36 gtkhash => OK => ALL CHECKSUMS OK Table 12: Whonix verification with checksums (documentation sample) I.5.5.4 Get DASH wallet software 68

ATTENTION: As of writing there is NOT the latest version of the DASH wallet software available on the official Tor Onion Service [http://www.dashorg64cjvj4s3.onion/]. This download method should always be favored over the HTTPS alternative as far as the files are available on the Tor Onion Service. But for now you have to download from [https://www.dash.org/]. Another layer of security is to check the fingerprints of the SSL certificate of https://www.dash.org/ against those provided in this article, compare with Figure 8 (chapter IV.1.1.2.1). Open the official DASH website [https://www.dash.org/] with the Tor Browser (Applications → Internet → Tor Browser). The website provides different files to download. The following ones are required to download. Choose from “Linux 32” platform which is required for Whonix-Workstation. (A) DASH Core wallet software (“Download tgz”) (B) hash file (“Hash”) (C) wallet corresponding PGP signature (“PGP”) (D) PGP public key of DASH developer (“Key 1”, “Key 2”), located in line “Verify Signatures” → currently the PGP public keys of (1) Holger Schinzel and (2) Evan Duffield are available HINT: You should also download all the relevant files (A), (B) and (C) relating to the “Linux 64” platform according to chapter I.5.5.5.2#ATTENTION 2 and IV.1.1.1. I.5.5.4.1 Verify DASH wallet download There are two different possibilities available of how to verify the DASH wallet software (chapter I.5.5.4.1.2 and I.5.5.4.1.3). It is strongly recommended to not only run one of the possibilities but both of them since the DASH wallet software you are about to download and install will handle your 1000 DASH collateral. I.5.5.4.1.1 DASH Signing Key If you take a closer look at the required files you have to ensure that the (D) PGP public key will arrive uncorrupted on your machine. This is a crucial step so make sure you understand well the limitations of the Tor Browser, see chapter I.5.1 how to deal with this issue and download it several times with different identities. Currently there are no other possibilities available to receive and verify the DASH signing key securely which have been made public (compare with the different procedures available for Debian and Whonix, especially in chapter I.5.5.3.1.1.4 which are very easy to additionally implement). Anyway, the fingerprint of the (D) PGP public key (“Key 1” and “Key 2”) is provided at the end of this chapter. The (D) PGP public key is the most important file due to the fact that the (A) DASH Core wallet software is (C) cryptographically signed by the owner of the PGP private key who made his mathematically related (D) PGP public key public and therefore available to everyone else on the planet. In doing so everyone in possession of the (D) PGP public key is able to verify that the (A) DASH Core wallet software download is valid if the verification process of the (A) DASH Core wallet software and the (C) wallet corresponding PGP signature returns the output Good Signature. Otherwise there was an error and you should start from the beginning again. 69

Why are there several PGP public keys? Usually the files are signed by Holger Schinzel (Key 1). Just in case Evan Duffield (Key 2) signs the files head over to his PGP public key. The procedure is exactly the same you only need one PGP public key to verify the integrity of a file as already shown in the previous chapters. So how do I know which PGP public key to download? Open a terminal and run a command similar to gpg dash-XXX-linux32.tar.gz.asc A line similar to gpg: using RSA key 0xXXXXXXXXXXXXXXXX will occur. Compare this extract of the full fingerprint with the two PGP public key fingerprints provided at the end of this chapter in order to decide who signed the (A) DASH Core wallet software and download the required key (as discussed in the following chapters). Since all the downloaded (D) PGP public keys (downloads of “Key 1” OR “Key 2” respectively) should always be the same it is up to you how to ensure this condition is true. Due to the fact that those files are simple text files it is possible to skip chapter I.5.2 and compare them in a more intuitive way as described below. Navigate to the signing key you downloaded first and right-click the (D) PGP public key and select Open With → gedit. Repeat this step for all the remaining signing keys. gedit will open a new tab for each file. You can easily switch between the various tabs and compare the content of each file (directory of each file is indicated on top of the window). ATTENTION: Compare with chapter I.5.5.3.1.1.1#ATTENTION 2. Another layer of security is to check the fingerprint of the (D) PGP public key (“Key 1” and “Key 2”) against those provided in this article. AF1A E13F 33D0 6F48 7F23 DC81 4B88 269A BD8D F332 (Holger Schinzel, “Key 1”, expires: 2018-01-23) [https://pgp.mit.edu/pks/lookup?op=vindex&search=0x4B88269ABD8DF332] C226 7E44 74EA 2EE9 D739 4900 BABF F6FC 986F F288 (Evan Duffield, “Key expires: Never) [https://github.com/dashpay/dash-binaries/blob/master/pgp/evan-darkcoin-io.asc] [https://raw.githubusercontent.com/dashpay/dash-binaries/master/pgp/evan-darkcoin-io.asc]

2”,

HINT: In comparison to the first verification process of the Whonix signing key (chapter I.5.5.3.1.1.1) you could also repeat the technique already discussed there again for DASH. But if you want to apply the technique mentioned for DASH also for Whonix you have to expand the optical comparison because of the higher key strength and therefore the size of the RSA key (DASH: 2048 bits, respectively vs. Whonix: 4096 bits). Open the different signing keys with gedit and click on Search → 70

Find... and paste the alphanumerical characters in the search field in each gedit tab and compare against each other. I.5.5.4.1.1.1 Several HTTPS downloads If you intend to download the (D) PGP public key of Holger Schinzel (Key 1) directly from the DASH downloads directory via right-click Save Link As... you will actually download the HTML file of the MIT website [https://pgp.mit.edu/pks/lookup?op=vindex&search=0x4B88269ABD8DF332] (which is NOT a Tor Onion Service, compare with chapter I.3.3) but not the signing key itself in which you are interested in. Avoid this issue by directly visiting the MIT website, then right-click on “pub 2048R/BD8DF332 2014-08-22” (line 3) and select Save Link As... and save it to a directory labeled “1” in the Tor Browser directory /home/amnesia/Tor Browser. Repeat this step several times with a New Identity (chapter I.5.1), respectively and save each file to another folder “2”, “3”, etc. Another layer of security is to check the fingerprints of the SSL certificate of https://pgp.mit.edu/ against those provided in this article, compare with Figure 6.

Figure 6: Fingerprints of the SSL certificate of https://pgp.mit.edu/ Speaking of the (D) PGP public key of Evan Duffield (Key 2) you are fine to download from GitHub [https://github.com/dashpay/dash-binaries/blob/master/pgp/evan-darkcoin-io.asc]. Again, pay attention to NOT download the HTML file accidentally. Another layer of security is to check the fingerprints of the SSL certificate of https://github.com/ against those provided in this article, compare with Figure 7.

Figure 7: Fingerprints of the SSL certificate of https://github.com/ Avoid the issue as already shown above by directly visiting the GitHub website, then righ-click on Raw (top of the website) and select Save Link As... and save it to a directory labeled “1” in the Tor Browser directory /home/amnesia/Tor Browser. Repeat this step several times with a New Identity (chapter 71

I.5.1), respectively and save each file to another folder “2”, “3”, etc. HINT: Keep in mind that the official DASH Tor Onion Service only refers to the “outdated” (D) PGP public key of Holger Schinzel (Key 1) which has already expired [https://github.com/dashpay/dashbinaries/blob/master/pgp/holger-darkcoin-qa.asc], anyway the key has been expanded and you should only download from the MIT website. I.5.5.4.1.1.2 Tor Onion Service download As of writing a (meaningless) PGP signature BUT NOT the (D) PGP public key of Holger Schinzel (Key 1) is available on the official DASH Tor Onion Service [http://www.dashorg64cjvj4s3.onion/] accessible via About → Team → Holger Schinzel [http://dashorg64cjvj4s3.onion/wpcontent/uploads/2015/11/holger-schinzel.txt]. Additionally the (D) PGP public key of Evan Duffield (Key 2) is NOT available on the official DASH Tor Onion Service. This download method should always be favored over the HTTPS alternative as far as the keys are available on the Tor Onion Service, compare with chapter I.5.5.3.1.1.1. I.5.5.4.1.2 DASH wallet & PGP Open a terminal and run a command similar to gpg signaturefilename.asc signaturefilename The output has to be Good Signature. Table 13 shows an example of how to document your results in a simple text file (for both bit versions, compare with chapter I.5.5.5.2#ATTENTION 2). gpg --verify dash-0.12.0.58-linux32.tar.gz.asc => Good signature gpg --verify dash-0.12.0.58-linux64.tar.gz.asc => Good signature Table 13: DASH verification with signatures (documentation sample) HINT: This verification approach is slightly different to the Debian verification process (chapter I.5.5.2.1) where actually the calculated checksums of the Debian-XXX.iso file where signed and not the Debian-XXX.iso itself (Debian-XXX.iso is comparable to the (A) DASH Core wallet software). The DASH verification approach additionally allows to check directly against the (C) wallet corresponding PGP signature and not only against its signed checksums in comparison to the Debian verification process. This is similar to the verification process of Whonix as discussed in chapter I.5.5.3.1 but the DASH verification process provides less options in comparison to Whonix.

72

I.5.5.4.1.3 DASH wallet & Checksums Another way how to verify the DASH wallet software download is to compare the personally calculated checksums with GtkHash (chapter I.5.2) against those publicly available. Due to the fact that the (B) hash file is very important you should download it several times in general (since the user cannot find out easily if the file has been manipulated during the download, in general). But in this case the (B) hash file is not just a simple text document but a signed text document which contains SHA256 checksums of the (A) DASH Core wallet software for different platforms. (1) As mentioned in chapter I.5.5.4.1.1 you can easily check the several (B) hash file downloads against themselves in different tabs inside of gedit again. Compare the checksums and once they match, those checksums are the source you acknowledge and compare against your personally calculated ones, too. (2) Because of the fact that you already trust the (D) PGP public key (compare with chapter I.5.5.4.1.2) you might only have to download the (B) hash file once. Open the file called “SHA256SUMS.asc” with gedit and mark the full text inside the window. Talking about Tails: In the top right corner you will mention a seal, click on it and select “Decrypt/Verify Clipboard”. The output has to return Good Signature. Also refer to the Tails Decrypt or verify a text created using OpenPGP Applet website [https://tails.boum.org/doc/encryption_and_privacy/gpgapplet/decrypt_verify/index.en.html]. Table 14 shows an example of how to document your results in a simple text file (for both bit versions, compare with chapter I.5.5.5.2#ATTENTION 2). File of interest: dash-0.12.0.58-linux32.tar.gz (32 bit version) 59a4221c58d03fd321a4b4fb7b9bd58004f32c3bb67bc4b5e2978f0a94ea6179 SHA256 dash-published 59a4221c58d03fd321a4b4fb7b9bd58004f32c3bb67bc4b5e2978f0a94ea6179 SHA256 gtkhash => OK File of interest: dash-0.12.0.58-linux64.tar.gz (64 bit version) 07f1294402b22ae6416554c126173f0d7e8b8481d5ce0579b94a1d164ee1b1bf SHA256 dash-published 07f1294402b22ae6416554c126173f0d7e8b8481d5ce0579b94a1d164ee1b1bf SHA256 gtkhash => OK Table 14: DASH verification with checksums (documentation sample)

73

I.5.5.5 Copying data to CDs/DVDs Once the downloads and integrity checks have been finished successfully you are now ready to burn the relevant data to CDs/DVDs. As already mentioned in chapter I.5.5 you are encouraged to use simple read-only compact discs (CD+/-R, DVD+/-R) due to the fact that once the burning process has finished the files on the discs cannot be modified later. I.5.5.5.1 Debian The Debian ISO image can be burned to a single CD very easily simply by right-clicking on the *.iso file and selecting “Write to Disc...” after a blank CD was inserted and recognized by Tails. Note that this CD will be bootable as intended. Of course it is also fine to use a DVD instead. I.5.5.5.2 Whonix and DASH wallet software archives It is perfectly fine to burn the (1) Whonix-Gateway (Whonix-Gateway-XXX.ova), the corresponding (2) Whonix-Workstation (Whonix-Workstation-XXX.ova) and the (3) DASH wallet software (dashXXX-linux32.tar.gz) to one single DVD. Due to the fact that burning (1), (2) and (3) directly to a DVD would tell anyone with physical access to this DVD that you are dealing with very special software which might be dangerous in your specific situation. Therefore it is highly recommended to encrypt those three files in advance and only burn an encrypted archive to a DVD which will only be decrypted on the intended machine to work with those files. Therefore the DVD will become meaningless for anybody not knowing the decryption keys. ATTENTION 1: Be advised that you really have to pay attention to the instructions provided below. In not doing so this might cause serious danger which will result in an archive anyone with physical access to the DVD you burned the archive to will be able to see its content (1), (2) and (3) in clear. In order to be compatible with the third version of the ISO9660 standard [https://en.wikipedia.org/wiki/ISO9660] we will have to create several archives to not create files bigger than 2 GB, compare with Table 15. Once the encrypted archive parts (/volumes) have been created they can be burned to a single DVD afterwards. # archive archive size [GB] archive name files stored 1. 1 archive.7z.001 2. 1 archive.7z.002 3. 1 archive.7z.003 4. 0.6 archive.7z.004 ---------------------------------------------------------------------------------------------------------------------------TOTAL 3.6 / Whonix-Gateway-XXX.ova, Whonix-WorkstationXXX.ova, dash-XXX-linux32.tar.gz (dash-XXX-linux64.tar.gz)

74

Table 15: Archive information for Whonix and DASH wallet software 1. Start Archive Manager: Applications → Utilities → Archive Manager 2. Drag and drop the files to the window, according to Table 15 (compare with HINT and ATTENTION 2 below) 3. Do you want to create a new archive with these files?: Click on Create Archive 4. Filename: archive (choose neutral filename) 5. File Format: Extension: Select 7-Zip (.7z); compare with [https://en.wikipedia.org/wiki/7z] 6. Location: Select a folder to save the file to; the folder should preferably be located on an encrypted storage device for security reasons; compare with chapter I.5.5, table 6 7a. Other Options: Password: Choose a very strong password (at least 10 characters) 7b. Other Options: Check “Encrypt the file list too”; this is extremely important and prevents an adversary not knowing the password from learning the file names such as the content of this archive in clear 7c. Other options: Split into volumes of 1000 MB (randomly chosen) 8. Click on Save (might take a while) HINT: Usually it is no problem to close the Archive Manager once a single file/several files have/has been added successfully. To re-open simply double-click on archive.7z.001, enter the password and continue to add the remaining file(s). ATTENTION 2: In case you want to work through chapter IV.1.1.1 (highly recommended) and your GUIDE computer base system is 64 bit (high probability) you additionally have to add the dash-XXXlinux64.tar.gz file to the archive. Once you have added all the three (/four) files to the archive successfully start the Brasero Disc Burner by clicking on Applications → Sound & Video → Brasero and create a new “Data project” and select the four archive files you wish to burn to a DVD. II. DEBIAN II.1 Strategy Physically disconnect the hard-disk drive(s) and/or SSD(s) and/or other (external) storage devices of your DASH computer after plugging off any power supply (this also includes batteries on notebooks). It is strongly recommended to disconnect all drives because you do not need them. In not doing so you simply introduce a security risk. Another very practical reason is that you might end up in destroying the current master boot record [https://en.wikipedia.org/wiki/Master_boot_record] on your device where your regular OS is installed on and therefore you will be unable to boot into your regular OS again. Install the latest version of Debian on a dedicated USB drive. For security reasons the whole drive will be encrypted during the installation. You are advised to read the article Encrypting Your Laptop Like You Mean It published by The Intercept [https://theintercept.com/2015/04/27/encrypting-laptop-like75

mean/] to get a better idea of this purpose. In this context also refer to [https://www.eff.org/wp/defending-privacy-us-border-guide-travelers-carrying-digital-devices] and read about secure passphrases. Finishing the installation you can simply plug off your encrypted USB drive once you are done with the whole setup, store it in a safe place, insert your main drive again and you are back on your old OS. Additionally, there exists no obvious link between the encrypted USB drive and your main drive which is usually used for daily stuff and vice versa which is an important fact. HINT 1: Keep in mind that we will only refer to the term “USB drive” for the Debian host OS installation. It is also possible to install the OS onto a SD card, as it is possible for Tails, compare with chapter I.4.4.1. HINT 2: As already mentioned in chapter I.5.5 be aware of the selection of a clean USB drive and only select a USB drive according to chapter I.4.4 and chapter I.4.4.1. You might want to additionally prepare the USB drive as discussed in chapter I.5.5#ADVANCED. II.2 Installation of Debian First of all insert the Debian installer CD and wait until the Debian welcome screen appears, afterwards plug in your empty USB drive and follow the installation instructions. Due to the fact that all other drives have been disconnected there should not be any issues with the boot device priority. Eventually, you have to enable the optical drive in BIOS [https://en.wikipedia.org/wiki/BIOS] (or UEFI [https://en.wikipedia.org/wiki/Uefi]) in the Boot section menu in advance to be able to boot from the Debian installer CD. HINT 1: If the DASH computer is unable to boot from a given USB drive at all go back to chapter I.4.4 and look up BIOS → Boot → USB or similar. Additionally you should search the BIOS for entries like webcam, microphone, Bluetooth, etc. and cover/tape/disable/deactivate them on purpose. If available: Plug off the Wi-Fi adapter cable connected to the motherboard [https://en.wikipedia.org/wiki/Motherboard] or switch off the Wi-Fi slider on your notebook (if available). HINT 2: If the DASH computer is unable to boot from any USB drive in general you might want to install the OS onto a dedicated hard-disk drive or SSD even if this does not sound like the smartest solution as it is more expensive (equal capacity size discussion in chapter I.4.4.1). Remember, you really do NOT want to install this Debian setup on your regular/daily drive like to another partition. HINT 3: Usually an English installation is preferred in any case since the user can follow this English guide very easily and is never in trouble looking for the corresponding translation and does not know which button to click next on. Do not forget to change the settings of the keyboard if you are not familiar with the default English (US) keyboard. The numbers below only indicate the order of the most important settings, not every single step during the installation is taken into account. Use the arrow keys, TAB and ENTER of your keyboard to 76

navigate through the menu in case there is no mouse pointer available and remain patient during the installation. According to the connection speed (read/write) of the selected USB drive, the accumulated time for a Debian installation can differ a lot. If you need further assistance during the installation process, open the Debian Installation Guide [https://www.debian.org/releases/stable/installmanual] and search for an entry “Using the Debian Installer”. 1. Debian GNU/Linux installer boot menu: Choose Graphical install from the menu entry 2a. Connect your dedicated USB drive to your DASH computer 2b. Connect ethernet cable to your DASH computer 3a. Configure the network: Preferably use cable-connection eth0 and NOT wireless connection (if available), compare with chapter I.4.1; this step will be skipped in case only one connection is available and eth0 will be selected automatically 3b. Configure the network: Hostname: debian or debian-pc or user or should be satisfying 3c. Configure the network: You can leave the field Domain name empty 4a. Set up users and passwords: Use at least 10 characters for the root (administration) account because the whole security of your host OS depends STRONGLY on it, compare with chapter I.3.2 4b. Set up users and passwords: Full name of the new user: debian or debian-pc or user should be satisfying; preferably use the same name as already chosen in step 3b. 4c. Set up users and passwords: Username of your account: debian or debian-pc or user should be satisfying; preferably use the same name as already chosen in step 3b/4b. 4d. Set up users and passwords: Preferably use 10 characters for the general user (non-administration) account 5a. Partition disks: Choose Guided – use entire disk and set up encrypted LVM 5b. Partition disks: Select your USB drive to partition; there should only appear one entry 5c. Partition disks: Partitioning scheme: Choose All files in one partition (recommended for new users) 5d. Partition disks: Write the changes to disks and configure LVM?: Choose Yes 5e. Partition disks: Erasing data on the USB drive; This process might take a while depending on the connection speed of the USB drive 5f. Partition disks: Use a complex encryption passphrase because the whole security of your host OS depends STRONGLY on it, compare with chapter I.3.2 5g. Partition disks: Write the changes to disks?: Select Yes 6a. Configure the package manager: Scan another CD or DVD?: Choose No 6b. Configure the package manager: Use a network mirror?: Choose Yes; this is extremely important in order to keep your system up-to-date 6c. Configure the package manager: Debian archive mirror country: Choose whatever you like, default setting is already fine 6d. Configure the package manager: Retrieving files from the network mirror; This process might take a while depending on the connection speed of the USB drive and the Internet connection speed of both 77

you and the Debian archive mirror 7. Configuring popularity-contest: Participate in the package usage survey?: Choose No since there is no beneficial use for anyone in conjunction with this guide 8. Software selection: Choose only Debian desktop environment and ...GNOME and disable all the remaining options 9. Select and install software: Retrieving files from the network mirror; This process might take a while depending on the connection speed of the USB drive and the Internet connection speed of both you and the Debian archive mirror 10a. Install the GRUB boot loader on a hard disk: Install the GRUB boot loader to the master boot record?: Choose Yes 10b. Install the GRUB boot loader on a hard disk: Select your drive and click on Continue II.3 Boot into Debian As far as the installation has finished (might take a long time) you can boot into the new Debian OS. Enter your encryption passphrase (“Please unlock disk sda#_crypt:”, chapter II.2, step 5f), hit ENTER and log in to your general account (chapter II.2, step 4d). Since this is your first boot you should think about the following configurations and read chapter I.4.1, I.4.2 and I.4.3 again. 1. Cover/tape/disable webcam for better security (if available) 2. Disable microphone for better security (if available): Activities (top left of screen) → search for “Settings” → Sound → Input 3. Disable Bluetooth for better security (if available): Activities (top left of screen) → search for “Settings” → Bluetooth 3. Disable WiFi for better security (if available): Activities (top left of screen) → search for “Settings” → Network → Wi-Fi II.3.1 Installation of Apt-Transport-Tor The Debian community is a very active one so you should check for (security) updates and upgrades each time you boot into your new Debian OS starting from chapter II.3.1.1. According to the Whonix Advanced Security Guide [https://www.whonix.org/wiki/Advanced_Security_Guide#apt-transport-tor] APT traffic should be torrified for many reasons. “[(1)] Each machine has its own unique selection of packages that can be used to fingerprint a system across physical networks as system updates are performed, allowing location tracking. [(2)] System updates leak sensitive security information like package versions and 78

the patch levels for a system. This information aids targeted attacks.” According to the Debian apt-transport-tor package description [https://packages.debian.org/jessie/apttransport-tor] “Please note that this approach is only as secure as Tor itself - this software cannot protect you from an attacker who has access to your local machine. In addition, attackers may be able to correlate your network traffic with the packets coming out of an [Tor] exit node, so do be careful.”. To install the Apt-Transport-Tor package in order to protect against those common problems, follow the steps below. 1. Open a terminal: Activities (top left of screen) → search for “terminal” and run the commands in quotation marks below 2. Super user who can execute administrative tasks: “su” and enter the administrative password (chapter II.2, step 4a) once you are asked for 3. Install Apt-Transport-Tor: “apt-get install apt-transport-tor” 4. Follow screen instructions 5. Close super user who has administration privileges: “exit” 6. Close terminal So far we have just installed Apt-Transport-Tor. In the following steps we still have to configure APT only once to download updates via Tor exclusively in the future. Once this configuration has been applied, Tor will be started automatically each time before actually starting to download any updates and the user will not notice any difference. 7. Open Synaptic Package Manager: Activities (top left of screen) → search for “Synaptic Package Manager” and enter your root (administration) password (chapter II.2, step 4a) to gain access to the Synaptic Package Manager 8. Click on Settings → Repositories and maximize the window (double-click) for a better overview 9. Click on the first line and simply add “tor+” to the existing URL in the “URI” menu and repeat for all the remaining lines, respectively like this “tor+http://security.debian.org/”. 10. You might want to disable the two entries with Type (1) ”deb” and (2) “deb-src” which are cdrombased (URI column) since we do not need them and to also avoid annoying interruptions while installing additional software. 11. Click on “OK” and close the Synaptic Package Manager Based on [https://www.whonix.org/wiki/Advanced_Security_Guide#apt-transport-tor]. HINT 1: Nobody has to seriously worry about connecting and downloading from a malicious Tor Exit Node (chapter I.5.1). Just in case you have already downloaded bad code which is NOT signed with a proper PGP key, this malicious update will never be applied by default anyway. First of all, you will always be notified about this, just like this “WARNING: The following packages cannot be 79

authenticated! […] Install these packages without verification [y/N]?”. “Don't proceed! Press N and . Running apt-get update again should fix it.”, refer to [https://www.whonix.org/wiki/Security_Guide#Updates, #3. Never install unsigned packages!]. According to step 9 we will only add the “tor+” prefix but do not change the following URL at all. Neither Tails nor Whonix GNU/Linux use Tor Onion Services as a network mirror for downloading updates as of writing. The Tor Onion Service Debian package repository has been mentioned at 32C3 [https://www.youtube.com/watch?v=oh9D2r-ck40], compare with chapter I.3.3. HINT 2: As of writing Debian does not provide the possibility to select the option to download updates via Tor exclusively during the installation process. It would be great to see this feature implemented in Debian future releases and should be enabled by default as it is more secure than the current implementation. To give people the freedom to choose whether they want to download via Tor it might be an option to place a simple checkbox in step 6b, chapter II.2. II.3.1.1 Updating & Upgrading Debian After booting your system you should always run the following commands for reasons of security before doing anything else. 1. Open a terminal: Activities (top left of screen) → search for “terminal” and run the commands in quotation marks below 2. Super user who can execute administrative tasks: “su” and enter the administrative password (chapter II.2, step 4a) once you are asked for 3. Update OS: “apt-get update” 4. Upgrade OS: “apt-get dist-upgrade” 5. Close super user who has administration privileges: “exit” 6. Close terminal HINT: Since this is your first boot and you just installed Debian using a network mirror (chapter II.2, step 6b) there will not appear any update news just because all relevant updates have already been applied during the installation process. Again, you should repeat those steps each time you start Debian again. II.3.2 Different users on Debian? After booting Debian you have logged in into your general account. The name of this account is the username which has been chosen in step 4c, chapter II.2. For security reasons this account only has limited rights [https://wiki.debian.org/sudo]. If you intend to do administrative tasks such as installing additional software, updating and upgrading the OS, etc. you will have to enter your root (administration) password (chapter II.2, step 4a) after entering “su” in a terminal. This can always be done very easily while being logged in with the general account and was already shown in chapter II.3.1.1, step 2.

80

III.3.3 Installation of VirtualBox 1. Open Synaptic Package Manager: Activities (top left of screen) → search for “Synaptic Package Manager” and enter your root (administration) password (chapter II.2, step 4a) to gain access to the Synaptic Package Manager 2. Click on Settings → Repositories and maximize the window (double-click) for a better overview 3a. Search for entries in the Distribution column containing only “jessie”. There should only appear two entries with Type (1) ”deb” and (2) “deb-src” which are not cdrom-based (URI column). Edit those two lines and add “ contrib” after “main” in the Section(s) menu, respectively like this “main contrib”. 3b. Click on “OK” and close the Synaptic Package Manager 4a. Open a terminal: Activities (top left of screen) → search for “terminal” and run the commands in quotation marks 4b. Super user who can execute administrative tasks: “su” and enter the administrative password once you are asked for 4c. Update the list of available packages: “apt-get update” 4d. Install linux-headers and VirtualBox: “apt-get install virtualbox linux-headers-$(uname -r)” 4e. Follow screen instructions 5a. Close super user who has administration privileges: “exit” 5b. Close terminal Based on [https://wiki.debian.org/VirtualBox] and [https://www.whonix.org/wiki/VirtualBox]. HINT 1: If you are facing problems with step 4d, try the virtual keyboard (Activities (top left of screen) → search for “Settings” → Universal Access, under Typing activate “Screen Keyboard” indicating ON) and move your mouse pointer to the bottom of the screen to activate the virtual keyboard. HINT 2: A serious vulnerability in qemu, called VENOM was discovered and fixed in 2015 [https://lists.debian.org/debian-lts-announce/2015/06/msg00015.html], [https://securitytracker.debian.org/tracker/CVE-2015-3456]. III. VIRTUALBOX III.1 General overview From now on talking every step has to be executed inside a specific VM. At any time make sure you have switched to the correct VM when changes are required. There have to be 3 VMs configured in total. Please keep in mind that any VM will have less computational power than the host OS itself. Therefore 81

things will usually work slower. Remain patient and wait until previous jobs are done. HINT: When it comes to VirtualBox it is very important to know how to switch easily between the host and the guest OS(es). By default push the right Ctrl key to liberate your mouse pointer again. III.2 Tails VM ATTENTION: There are known compatibility issues running Tails 2.7.1 as a VM. This will likely be fixed within the next Tails release 2.8. Due to reasons of simplicity the first VM you have to configure is Tails. This VM is special because there will be no hard drive to boot from but one to save important data to, the so-called BACK-UPHDD (chapter III.2.1). This chapter is already preparing the crucial steps for the following chapter but only within the VirtualBox environment. Since VirtualBox is very easy to use this setup does not take much time. Launch the VirtualBox software which can be found under Activities (top left of screen), search for “VirtualBox” and follow the steps below. Refer to [https://tails.boum.org/doc/advanced_topics/virtualization/virtualbox/index.en.html] for additional detailed information if necessary. Be advised that the following instructions differ slightly from those provided by the Tails documentation. 1a. Click on New: A new VM will be created 1b. Name: Tails 1c. Type: Linux 1d. Version: Other Linux (32 bit) 2. Memory size: at least 1024 MB is [https://tails.boum.org/doc/advanced_topics/virtualization/virtualbox/index.en.html]

recommended

3a. Hard drive: Choose Create a virtual hard drive now 3b. Hard drive: Hard drive file type: Choose VDI (VirtualBox Disk Image) 3c. Hard drive: Storage on physical hard drive: Choose Dynamically allocated 3d. Hard drive: File location and size: Name it BACK-UP-HDD and enter 100 MB (we do not need more size, this has been shown empirically) 4a. Select the Tails VM and click on Settings (VirtualBox overview) 4b. Settings → System → Motherboard → Boot Order: Check only CD/DVD and disable all the remaining options 4c. Settings → Storage → Controller: IDE → Select “Empty”: CD/DVD Drive: Click on the CD/DVD icon with down-arrow on the right hand side of the window and select Host Drive XXX-XXX-XXX (this is actually the optical drive of the Debian host OS) 4d. Settings → Network → Adapter 1: Uncheck Enable Network Adapter (see HINT 1 for clarification) 4e. Settings: Finally click on OK to save changes 82

So far the Tails VM is ready to use. Insert the Tails DVD into the DASH computer. Every time you start the Tails VM you will boot directly from the Tails DVD inserted into the optical drive of the Debian host OS. This is even more secure and recommended than booting from an *.iso file located on the USB drive and also saves disk space. This approach also allows to always work with the latest version of Tails very easily once a new Tails release is available because you only have to insert a new Tails DVD and nothing else. Simply select the Tails VM and click on Start in order to boot the VM. HINT 1: In the current situation there is no need to use the Internet on the Tails VM. Due to the fact that Tails will always connect to the Internet to synchronize time and to provide a Tor connection once it is started we have switched off the network beforehand (step 4d). HINT 2: The BACK-UP-HDD will be attached to both the Tails VM such as the Whonix-Workstation (chapter III.6). Since both VMs are able to connect to the Internet and subsequently to Tor at the same time (in case both VMs are running and no precautions have been taken) this might raise suspicion (being connected to Tor two times). VirtualBox prevents this scenario due to the fact that the BACKUP-HDD will always be attached to both VMs allowing to only boot from one VM with the BACKUP-HDD attached. III.2.1 BACK-UP-HDD The BACK-UP-HDD will be used to store important data permanently. Since the BACK-UP-HDD is a single file on the Debian host the user is strongly encouraged to save this file to a CD/DVD additionally, as described in chapter IV.1.4.1. Refer to chapter I.3.2 for a detailed security analysis about this topic. Because of the fact that it is easier to work within Tails to configure the BACK-UP-HDD than under KDE in Whonix-Workstation we will use Tails for this specific task. Refer to chapter I.2 and also Figure 1 for further information of how the BACK-UP-HDD is used actually. In order to use the BACK-UP-HDD the virtual hard disk has to be formatted at first and configured subsequently. There will be two partitions created allowing to only access restricted information: One partition (Whonix-VOLUME) holds the wallet.dat file and the other partition (Tails-VOLUME) only provides the MNSP information file. Refer to Table 16 for an overview, keep in mind that this extends Table 1 of chapter I.3.2. The names of the partitions already indicate on which VM they should be mounted [https://en.wikipedia.org/wiki/Mount_%28computing%29] exclusively for best security. # partition partition size [MB] 1. 90 2. 10

partition name Whonix-VOLUME Tails-VOLUME

file stored on wallet.dat MNSP information

Table 16: Partition information of BACK-UP-HDD ATTENTION 1: It is up to the user not to break the concept of only opening the Whonix-VOLUME 83

partition to be intended to be opened on Whonix-Workstation only (such as Tails-VOLUME on Tails only) as a measure of security. There is no need to expose the information saved to the Tails-VOLUME partition on the Whonix-Workstation VM such as information saved to the Whonix-VOLUME on the Tails VM. Anyway, both partitions have to be created on Tails VM beforehand but this should be no problem since sensitive information will only be copied to the Whonix-VOLUME when this partition is mounted in Whonix-Workstation, the same argument is valid for copying sensitive information to the Tails- VOLUME partition (the data will not escape from Tails VM). Anyway be instructed about the virtualization security considerations published by Tails [https://tails.boum.org/doc/advanced_topics/virtualization/index.en.html#index1h1]. ATTENTION 2: It is extremely important to choose two different strong encryption passphrases (at least 10 characters respectively) because the BACK-UP-HDD file will contain a backup of your wallet and other sensitive information relating to your MN which you really do not want to expose. Start the Tails VM, wait for the Tails Greeter and enter a temporary administration password (refer to chapter I.5.5.2.1.1.2). You may want to maximize the Tails VM window for a better view. III.2.1.1 Partition 1 – Whonix-VOLUME The following is based on the Tails Create and use encrypted volumes guide [https://tails.boum.org/doc/encryption_and_privacy/encrypted_volumes/index.en.html] which you might want to read first. 1. Start Disk Utility: Applications → Utilities → Disks 2a. Select the BACK-UP-HDD: Left column → Size > 100 MB Hard Disk (Model: ATA VBOX HARDDISK) and click on the small gear icon (top right): Format... 2. Format Disk: Erase: Don't overwrite existing data (Quick) & Partitioning: Compatible with modern systems and hard disks > 2 TB (GTP) is fine and click on Format... 2c. Again, click on Format once the warning message appears 2d. Authentication is required to modify the device: Enter your temporary password you entered after the Tails Greeter appeared 3a. Click on Create Partition (bottom left with the plus icon) 3b. Partition Size: 90 MB 3c. Type: Encrypted, compatible with Linux systems (LUKS + Ext4) this step is extremely important, refer to chapter I.3.2 3d. Name: Whonix-VOLUME (this will be displayed inside a VM once the HDD with this partition has been mounted) 3e. Enter a passphrase and verify in the next line (use at least 10 characters) 3f. Click on Create 3g. Authentication is required to create a partition [...]: Enter your temporary password you entered after the Tails Greeter appeared

84

Be patient and wait until the disk is ready to use. To access a partition, click on Places (right next to Applications, top left of screen) → Computer and select Whonix-VOLUME. If not mounted, the name of the partition will not be visible but its size and encryption status, 90 MB Encrypted in this example. III.2.1.2 Partition 2 – Tails-VOLUME Follow the exact steps from chapter III.2.1.1 again and take care of the differences provided below (i' indicates changes in comparison to i). In order to select the remaining free space of the disk click on Free Space under Volumes and start from step 3a on. 3a. Click on Create Partition (bottom left with the plus icon) 3b'. Partition Size: do not change 3c. Type: Encrypted, compatible with Linux systems (LUKS + Ext4) this step is extremely important, refer to chapter I.3.2 3d'. Name: Tails-VOLUME (this will be displayed inside a VM once the HDD with this partition has been mounted) 3e'. Enter a passphrase and verify in the next line (use at least 10 characters) 3f. Click on Create 3g. Authentication is required to create a partition [...]: Enter your temporary password you entered after the Tails Greeter appeared You may now shutdown the Tails VM because the BACK-UP-HDD is ready to store files on. Click on the big shutdown button which will appear as soon as you have clicked in the top right corner. III.3 Import Whonix Images Insert the DVD with the respective Whonix-Gateway (GATEWAY) file and Whonix-Workstation (WORKSTATION) file. First you will have to extract the GATEWAY and the WORKSTATION file to a temporary folder. For example navigate to the /home/debian directory (the name might differ according to chapter II.2, step 4c) and right-click on the free space and select New Folder. Name it tmp_Whonix_images. Open the protected archive called archive001.7z and copy GATEWAY to the temporary folder. Afterwards copy only WORKSTATION to the temporary folder. So far we do not need the DASH wallet software. There is no need to also copy the archive files on the DVD to your encrypted Debian USB drive in advance, this also saves disk space. 1. Start VirtualBox: Activities (top left of screen) → search for “VirtualBox” 2. Click on File → Import Appliance → Click on the folder icon and select GATEWAY from your temporary folder 3. Checkbox enabled: Reinitialize the MAC address of all network cards 4. Agree to the terms and conditions; the import might take a while Repeat steps 2 to 4 for WORKSTATION, too.

85

Anyway, VirtualBox will create several files for GATEWAY and WORKSTATION in the /home/debian/VirtualBox VMs directory which are also extracted files from the original *.ova files you just copied to the /home/debian/tmp_Whonix_images directory beforehand. Once imported you do not need the original Whonix-Gateway-xxx.ova and Whonix-Workstation-xxx.ova files located in the /home/debian/tmp_Whonix_images directory anymore. Feel free to delete the whole folder after the import has succeeded. III.4 Whonix-VMs Your new GATEWAY and WORKSTATION OSes will never be up-to-date as far as you have just imported them. Because of the fact that Whonix (a derivative of Debian GNU/Linux) is under permanent development, both VMs should be updated now. This process is the same in both VMs. Simply follow the screen instructions. In the unlikely case there will not pop up the WhonixCheck window on startup, click on the corresponding shortcut on the desktop and continue afterwards as described in chapter II.3.1.1 (steps 2 to 6) both inside GATEWAY and WORKSTATION. Keep in mind that a shortcut to the terminal (step 1) is located on the desktop, respectively and called “Konsole”. Pay special attention to NOT enter the administrative password of Debian (chapter II.2, step 4a) inside any Whonix VM but “changeme” instead. The default login on Whonix is provided below. default user account: user default root account: root default password (for administrative tasks): changeme HINT: Keep in mind that changing the passwords does not provide real security in case an attacker has already gained access to your Debian host OS. Anyway it is always possible to mount [https://en.wikipedia.org/wiki/Mount_%28computing%29] the Whonix HDD (where the Whonix OS is actually installed on) with another VM easily and see its entire content in clear, e.g. use Tails VM, compare with chapter III.2 (pay attention to HINT 2) and chapter III.6. III.5 Whonix-Gateway First, you have to start the GATEWAY VM. Select the corresponding entry in VirtualBox and click on “Start”. Follow the instructions on the screen carefully. On the first run WhonixCheck (also available as shortcut on the desktop) will be launched automatically. Always run this task as soon as the VM is available in order to check if your system is up-to-date and if there are any other important news relating to the installed software. HINT: If you cannot connect to Tor you might want to adjust the time on your Debian host OS. Deviation of your geophysical time is tolerable within a small interval of hours.

86

III.6 Whonix-Workstation Before starting the Whonix-Workstation VM, the BACK-UP-HDD has to be connected to the VM within VirtualBox as already mentioned in chapter III.2#HINT 2. 1. Select the Whonix-Workstation VM and click on Settings 2. Settings → Storage → Controller: Whonix-Workstation-sas: Click on the green icon with the harddisk symbol indicating “Add Hard Disk” 3. VirtualBox – Question: Select Choose existing disk and navigate to the /home/debian/VirtualBox VMs/Tails directory and select BACK-UP-HDD.vdi 4. Settings → Storage → Controller: Whonix-Workstation-sata → Select “Empty”: CD/DVD Drive: Click on the CD/DVD icon with down-arrow on the right hand side of the window and select Host Drive XXX-XXX-XXX (this is actually the optical drive of the Debian host OS) 5. Settings: Finally click on OK to save changes HINT 1: Step 4 allows to directly copy the DASH wallet software from the encrypted archive burned on a DVD and inserted in Debian into the WORKSTATION. ATTENTION: It is essential that the GATEWAY is already running before you start the WORKSTATION, otherwise you cannot establish a connection inside the WORKSTATION through the GATEWAY and therefore to the Tor Network by design. The setup of the WORKSTATION is pretty much the same as described in the previous GATEWAY chapter. Again, run WhonixCheck and follow the instructions carefully. HINT 2: If you have hardware virtualization support on your host system available you may want to increase the number of processors for your WORKSTATION to increase performance (VirtualBox: Settings → System → Processor: # Processor(s)). Anyway, the default amount of RAM allocated (768 MB) works fine. Empirical analysis have shown that there is no need to increase this value at the time of writing. III.6.1 Installation of DASH wallet software The following describes the process of how to copy the DASH wallet software into the WhonixWorkstation VM. The DASH wallet software has already been downloaded and verified as described in chapter I.5.5.4 and burned on a DVD (chapter I.5.5.5.2). 1. Insert the CD/DVD containing the DASH wallet software into your Debian host optical drive 2. Open the Dolphin File Manager on your WORKSTATION by clicking on the shelf icon located bottom, left in the taskbar 3. Look for Devices (bottom, left) and click on Data disc (XXX) 4. Open archive.7z.001, enter password and select dash-XXX-linux32.tar.gz 5. Click on Extract and choose the following directory home/user and click on OK 6. Navigate to home/user/archive and right-click on dash-XXX-linux32.tar.gz and select Extract → 87

Extract Archive Here IV. DASH There are two chapters explaining how to work with the DASH wallet software in great detail. Chapter IV.1 describes the usage of the wallet on the mainnet and therefore working with real DASH coins and chapter IV.2 shows how to work with the testnet and therefore with test-DASH (tDASH) coins which are free of charge. Before doing anything which leads to real-world-implications make sure you have tested everything carefully on your own as described. Any serious mistakes could cause the loss of all your coins and/or your privacy and anonymity immediately. IV.1 DASH wallet Before even working with the DASH wallet itself you should think about strategic backup processes and general settings. To get the basic idea refer to chapter I.3.2 again. IV.1.1 Preparation of secure cold wallet Due to the fact that you are about to deal with a lot of coins you are strongly encouraged to create a secure cold wallet [https://en.bitcoin.it/wiki/Cold_storage] just in case you will experience some unknown errors, etc. In such an event you should send your coins immediately to this secure address to protect them against any threat but remain calm. As far as you are done with that you should continue with chapter IV.1.2. Definition: cold A “cold” system is powered-down, stopped, offline. To this end what we really mean when we say “cold storage” is that we’re storing Bitcoins [or any other cryptocurrency] somewhere that’s not connected to the Bitcoin network or, in most cases, even connected to the internet or even on a computer at all. [http://codinginmysleep.com/bitcoin-cold-storage-in-plain-english/] In addition to this you can read about a terminology discussion here [http://codinginmysleep.com/paper-wallets-arent-cold-storage/] resulting in “See, paper wallets aren’t cold storage – they’re offline key storage.”. In the following chapters we will discuss different approaches derived from two tools of how to create a reasonable secure cold wallet. Anyway you are strongly encouraged to only store coins on a cold storage device [https://en.bitcoin.it/wiki/How_to_set_up_a_secure_offline_savings_wallet], e.g. a paper wallet at any time in case you really do not actively need them in your wallet just like working on 88

a MN for example. Read the extract Why Set up an Offline Savings Wallet? on the Bitcoin Wiki website [https://en.bitcoin.it/wiki/How_to_set_up_a_secure_offline_savings_wallet] and also [http://codinginmysleep.com/bitcoin-cold-storage-in-plain-english/] for further background information. From now on talking we associate the term cold wallet only with those techniques available in chapters IV.1.1.1 and IV.1.1.2 to differentiate from special hardware wallet systems designed to also create cold wallets. ATTENTION: You should only create a cold wallet on a machine which is NOT connected to the Internet while creating the cold wallet as a measure of security. This is regardless of how “safe” your OS is. Additionally, you should have read and well understood chapter I.3.1 and I.4.1. As already mentioned in chapter II.1 you are advised to physically disconnect all storage devices in case you do not need them to furthermore reduce the attacking surface. It is recommended to create a cold wallet on the GUIDE computer. Before starting on your own you are encouraged to refer to the following video samples (1), (2) published on YouTube. They might seem to be out of date and contain security risks but they give you a general idea of how to create cold wallets and especially allow to watch the process in action and therefore under real conditions which are usually hard to describe in great detail. Keep in mind that they provide different solutions of varying levels of security. (1) Cold Storage Wallet Presentation (01:07:35 hours): https://www.youtube.com/watch?v=dQ7a-WZzJas (2) How To Store Your Bitcoins Safely (Offline, paper wallets) (14:39 mins): https://www.youtube.com/watch?v=rYjH16zbf38 Always make sure you accomplish at least the following list of minimal requirements before creating a secure cold wallet. Due to obvious reasons we will use Tails again to create a cold wallet. - take care of a safe physical environment - remove all non-necessary devices (e.g. hard-disk drive(s), etc.) on the machine which is intended to create the cold wallet - use a tool for creating the cold wallet you have digitally verified and downloaded in another computer session (e.g. store the tool on an encrypted device, this also protects it against subsequent manipulation by an attacker having access to your device) - disable all networking (offline mode) during the cold wallet creation process [https://tails.boum.org/doc/first_steps/startup_options/offline_mode/index.en.html]) - save the cold wallet properly - shutdown Tails immediately once you have finished in order to wipe data to prevent computer forensic discovery of your files (compare with chapter I.5.5#HINT 4) HINT 1: If you are willing to trust a printer you do not need to enter an administration password on Tails anymore (compare with https://labs.riseup.net/code/issues/8443). Keep in mind that modern printers are at high risk exposing information (they have a memory and usually network access). Be 89

advised that Tails might not recognize any printer. You have to figure this out in advance. HINT 2: So far the creation of a secure cold wallet can be really time consuming and frustrating and remains a difficult topic but this is true for all (very) secure crypto applications (compare with the creation of PGP key and also compare with chapter V.4.1, mentioning KeePassX as a potential helpout and/or leverage) and read chapter I.4.3.1.1 again. For the following chapters we assume that you are already running a clean session of Tails (without network functionality disabled). IV.1.1.1 DASH wallet software The first solution allows you to instantly start working since you already have the tool available which will create your DASH private and public key (DASH keypair) – the DASH wallet software – you downloaded and verified back in chapter I.5.5.4 which is preferably available on a read-only disc (compare with chapter I.5.5.5.2). The following is similar to chapter III.6.1 and the upcoming chapter IV.1.2. You only have to extract the files stored in dash-XXX-linux64.tar.gz (64 bit version) OR dash-XXX-linux32.tar.gz (32 bit version) according to your base system (compare with chapter I.5.5.5.2#ATTENTION 2 and I.5.5.2#HINT 1) to a directory (e.g. /home/amnesia/Tor Browser) and start the DASH wallet software from the terminal with the “./dash-qt” command. The default data directory /home/amnesia/.dash (invisible because of a hidden folder) is fine. Anyway the download of the block chain will not take place since you have disabled all networking in advance. Below we will discuss two different sub processes you are free to choose from. As far as you have chosen one sub process execute the steps and also take care of the public key – also known as (DASH) address – of the DASH keypair where you are going to send funds to. As soon as you have finished any process navigate to the /home/amnesia directory. Select Show Hidden Files (alternatively: Ctrl + H), then right-click on .dash and select Wipe. Afterwards you can shutdown Tails to protect yourself against any kind of computer forensic discovery of your sensitive data. IV.1.1.1.1 Save wallet file The idea of this sub process is to create an encrypted wallet file containing both the private and public key and to save it on an external device. This is very similar to the core strategy of the guide while backing up the MN relevant files (compare with chapter IV.1.4 and V.2). First of all you have to encrypt your wallet (chapter IV.1.3). Keep in mind that if you save the wallet file without encryption anyone with access to this file is able to control and send any of your coins toh his/her own wallet stored in this file. You might want to store the encrypted wallet file in an encrypted 90

KeePassX database, compare with chapter V.4.1 for even higher security. Anyway you are strongly encouraged to save files only on encrypted devices (compare with chapter I.5.5, Table 6) for best practice. Also read chapter I.3.2 again. Refer to chapter IV.1.4, step 4 and IV.1.4 to create and backup the wallet file correctly. IV.1.1.1.2 Dumpprivkey The idea of this sub process is to create a DASH keypair but to write down the public key and the private key on a piece of paper you will store somewhere safe. This is similar to chapter IV.1.4 but you will skip step 4 and execute the following commands instead. 4'. Click on Copy Address in the request payment information window 5. Click on Tools → Debug Console and enter the following command: “dumpprivkey ” where: dumpprivkey – command to reveal the private key corresponding to – the address you copied to the clipboard in step 4' Example: dumpprivkey XdavTpNGhoe3HMhtVQ5wCcCzSaiu5LFyWj resulting in... 7s8y9MfP756SKSaurf3dgzGWfmbdMRvWougGh6rs7dSi3p86AJK 6. Write down the (1) public key and (2) private key ATTENTION: Be advised that this solution is only as secure as the (secret) location you store the private key in due to the fact that the private key is visible in clear text. The common analogy to this method is the locking of cash in a safety deposit box. IV.1.1.2 DASH paper wallet This is the most secure way to create your DASH keypair since we will apply BIP38 encryption [https://github.com/bitcoin/bips/blob/master/bip-0038.mediawiki] to protect the private key with an additional passphrase. You can think of this as a two-factor authentication system [https://en.wikipedia.org/wiki/Two-factor_authentication] to further protect your DASH coins. Simply imagine you write down 58 alphanumerical characters which somehow represent your private key (base58 format, starts with '6P') in an encrypted format. To be able to spend coins which have been send to the public key of the DASH keypair you additionally have to enter a passphrase after you have entered the 58 alphanumerical characters resulting back in the typical 51 alphanumerical character representation of your private key (WIF – wallet import format, starts with a '7', compare with IV.1.5, step 3) as a measure of security. For obvious reasons you are strongly encouraged to NOT USE the outdated Brain Wallet feature available on the Dash PaperWallet Generator anymore. 91

“User story: As a Bitcoin user who uses paper wallets, I would like the ability to add encryption, so that my Bitcoin paper storage can be two factor: something I have plus something I know.” [https://github.com/bitcoin/bips/blob/master/bip-0038.mediawiki] In case you have several copies of the BIP38 paper wallet available in different geographic locations and you loose one of them either by mistake on your side or by any form of attack you are not exposed to the risk of loosing any funds with high probability in case you have chosen a strong passphrase which the attacker cannot derive easily but you are able to memorize correctly. HINT: As of writing this solution requires you to download and verify an additional file. IV.1.1.2.1 Download and Verify ATTENTION 1: Even if it might sound confusing to visit an online version of the Dash PaperWallet Generator this approach allows you to start from the official DASH website (Figure 8) in order to get directed to the official GitHub Repository (Figure 7) since the file is not yet available to download on the official DASH website such as the official DASH Tor Onion Service [http://www.dashorg64cjvj4s3.onion/]. We will download and verify the paper wallet file, save it somewhere permanently and boot into another safe offline Tails session (chapter IV.1.1.2.2). Anyway never create a DASH keypair online (refer to chapter IV.1.1, especially ATTENTION). HINT: In contrast to chapter I.5.1#ATTENTION 2 you should not change the Privacy and Security Settings... configuration and leave Low (Default) in the Security Level section as it is such as any other settings relating to the Tor Browser. Start a new Tails session (NEVER on Tails VM anyway) on the GUIDE computer, open Tor Browser (Applications → Internet → Tor Browser) and navigate to the DASH paperwallet website [https://paper.dash.org/] and click on GitHub Repository [https://github.com/dashpay/paper.dash.org] at the bottom of the page. Another layer of security is to check the fingerprints of the SSL certificate of https://www.dash.org/ against those provided in this article, compare with Figure 8. Download the ZIP file several times (chapter I.5.1) and compare against each other. Afterwards, verify the checksum file and calculate your own checksums you have to check against those ones provided by the DASH developers. Table 17 shows an example of how to document your results in a simple text file. Keep in mind that the whole zip archive has been analyzed.

92

Figure 8: Fingerprints of the SSL certificate of https://www.dash.org/ File of interest: paper.dash.org-master.zip

[Latest commit 043ce63 Apr 8, 2016]

db8f8dd9a7a057dc8872ffd83f451a8854a24f7474a29682c05b47d099594d0f anon-published db8f8dd9a7a057dc8872ffd83f451a8854a24f7474a29682c05b47d099594d0f gtkhash download #1 db8f8dd9a7a057dc8872ffd83f451a8854a24f7474a29682c05b47d099594d0f gtkhash download #2 db8f8dd9a7a057dc8872ffd83f451a8854a24f7474a29682c05b47d099594d0f gtkhash download #3 => OK

SHA256 SHA256 SHA256 SHA256

d7a390b03eef69105712311660c003c79a51b9734c02045f1ff01686f6a1904249877bfad3716f b17834c422ee6d61ef43981d46d3d063cb9224ea65933ffb96 SHA512 anon-published d7a390b03eef69105712311660c003c79a51b9734c02045f1ff01686f6a1904249877bfad3716f b17834c422ee6d61ef43981d46d3d063cb9224ea65933ffb96 SHA512 gtkhash download #1 d7a390b03eef69105712311660c003c79a51b9734c02045f1ff01686f6a1904249877bfad3716f b17834c422ee6d61ef43981d46d3d063cb9224ea65933ffb96 SHA512 gtkhash download #2 d7a390b03eef69105712311660c003c79a51b9734c02045f1ff01686f6a1904249877bfad3716f b17834c422ee6d61ef43981d46d3d063cb9224ea65933ffb96 SHA512 gtkhash download #3 => OK => ALL CHECKSUMS OK Table 17: DASH paper wallet verification with checksums (documentation sample) ATTENTION 2: As of writing the DASH developers have not published SHA256 such as SHA512 checksums for the paper.dash.org-master.zip file which can be accessed easily. In addition to this 93

the paper wallet zip file has not been cryptographically signed (chapter I.5.3) to allow for strong verification (additionally compare with chapter I.5.5.3.1 incl. HINT). The existence of a cryptographically signed paper wallet file would make the DASH paper wallet solution the most secure solution for a cold wallet at all. Keep in mind that a cold wallet might contain a lot of coins. You really have to make sure that the DASH keypair has been created with a trustworthy tool. IV.1.1.2.2 Applying BIP38 encryption ATTENTION: As of writing the following warning can be reproduced with the Tor Browser. “Oh no! Some synchronous unit tests DID NOT pass. You should find another browser to use with this generator.” Since there is no further documentation available to this warning you should NOT use this method for serious tasks and therefore only for experimenting purposes for now. HINT: In contrast to chapter I.5.1#ATTENTION 2 you should not change the Privacy and Security Settings... configuration and leave Low (Default) in the Security Level section as it is such as any other settings relating to the Tor Browser. In order to create a secure DASH keypair you have to execute the following steps. 1. Copy the paper.dash.org-master.zip file to a directory (e.g. /home/amnesia/Tor Browser) and disconnect the source device where the paper wallet generator is saved to 2. Right-click on the file and select Extract Here 3. Navigate to paper.dash.org.html and double-click on the file 4. Tor Browser message pops up: “Tor is not ready”: Click on Start Tor Browser (might take a while) 5. Follow the screen instructions “[...] to add some extra randomness...” 6. Click on the Paper Wallet tab 7. Click on the checkbox Hide Art? for an better overview 8. You have to click on the checkbox BIP38 Encrypt? and enter a strong passphrase (10 characters at least) 9. Eventually you want to change the amount of Addresses to generate 10. Hit Generate (might take a while) and DO NOT stop the script once a warning message appears (click on Continue) 11. Write down several times: (1) Dash Address, (2) Encrypted Private Key (Password required) 12. Memorize: (3) Passphrase Due to the fact that it is crucial to memorize the passphrase to unlock the private key again you really have to make sure you memorize it (and also type on the keyboard/virtual keyboard: Applications → Universal Access → Florence Virtual Keyboard) correctly. 13. Click on the Wallet Details tab 14. Enter Private Key section: Enter the full 58 characters of step 11 (2) 15. Enter BIP38 Passphrase: Enter the full characters of step 12 (3) 16. Hit Decrypt BIP38 (might take a while) and DO NOT stop the script once a warning message appears (click on Continue) 94

You will see two lines showing Private Key WIF and 51 characters base58, starts with a '7' including the secret DASH private key in the next line. You are fine in closing the Tor Browser now since you can successfully reconstruct the wallet import format (WIF). Remember you are at higher risk in case you decide to additionally write down the WIF of the private key meaning you will loose the additional properties of the BIP38 encryption technology. IV.1.2 Start DASH wallet software 1. Navigate to home/user/archive/dash-XXX/bin and right-click inside this window into the white/blank area and select Actions → Open Terminal Here in the drop down menu (alternatively: use the change directory command [https://wiki.debian.org/ShellCommands] to navigate to the folder directory) 2. Start DASH wallet software from the terminal by launching the “./dash-qt” command Read the information on the welcome screen carefully. The default data directory /home/user/.dash (invisible because of a hidden folder) is fine, keep in mind that >1 GB should be reserved for this folder (at the time of writing ) and this will increase over time the bigger the block chain becomes. Due to the fact that the full block chain has to be downloaded this will also determine the size of the USB drive which is currently in use, refer to chapter I.4.4.1. For reasons of simplicity the full block chain download will be stored on the same drive where Debian is installed on. As far as you are connected to the DASH network the download of the block chain should begin immediately. This might take a while depending on the connection speed of the USB drive and the Internet connection speed of both you and the other clients on the network. Do not try to skip the syncing process by copying and pasting the block chain to the DASH directory you downloaded somewhere else on the Internet for various reasons of security (compare with chapter I.2.6.1). HINT: There is no need to configure network options in Settings → Options → Network in the DASH wallet software because all network traffic is already forced to go through the Tor network since we are working inside of the Whonix-Workstation VM, refer to chapter I.2.3. ADVANCED: You may want to configure Tor itself to only connect to certain Tor Exit Nodes, etc. This has not been well documented and reviewed extensively yet. Generally speaking it is not advised to modify the torrc file unless you understand exactly about the consequences. Refer to the Tor FAQ [https://www.torproject.org/docs/faq#torrc] for a general discussion. In addition to this, Tails does not recommend this, too (refer to the Tails FAQ website [https://tails.boum.org/support/faq/index.en.html#index22h2]). IV.1.3 Encrypt wallet Assuming the download of the block chain has finished you should hold on and manage some important settings. Always encrypt your new wallet before depositing any coins to it. There is no rational excuse why not to do so. For better security always use a virtual keyboard (KDE start button 95

→ Applications → Utilities → Virtual Keyboard) for entering a complex passphrase (10 characters at least). Compare the number of stars (***) you entered on the screen with the length of the wallet passphrase you memorize. 1. Click on Settings → Encrypt Wallet... This will protect your wallet with a passphrase. Read the instructions on the screen carefully and wait until the final message “Dash will close now to finish the encryption process. [...]” is displayed. 2. Restart DASH wallet software from the terminal with the “./dash-qt” command (chapter IV.1.2, step 2) You will mention a lock at the bottom right of the Dash core – Wallet window: “Wallet is encrypted and currently locked”. 3. Unlock the wallet: Click on Tools → Debug Console and enter the following command: “walletpassphrase timeout” where: walletpassphrase – command to unlock wallet – your passphrase to unlock the wallet timeout – amount of time [seconds] the wallet will be unlocked Example:

walletpassphrase h*&E#87y(EY#(yduheu(E*u3^NDLw( 60

Now it is time to check if you can unlock your wallet again. This step allows you to verify the wallet has not been damaged and is accessible by entering the correct passphrase. For better security always use a virtual keyboard (KDE start button → Applications → Utilities → Virtual Keyboard). After entering the command you will see an open lock at the bottom right of the Dash core – Wallet window: “Wallet is encrypted and currently unlocked”. Once the value of timeout is reached the wallet will be locked again automatically. Click on the big red minus button in the Debug Console on the right (or enter CTRL + L) to clear the screen/console. Close the Tools window by pressing the ESC-key. IV.1.4 Backup wallet #1 So far we have downloaded the full block chain and also encrypted the wallet. Before even importing any funds to the new wallet you should definitely make a backup of the new wallet once important precautions have been made. ATTENTION: Below we will discuss the process of backing up the wallet according to a strategy which allows to recover any coins from a backup wallet file saved to an external medium in case the original wallet file cannot be utilized anymore and/or the Whonix-Workstation/Debian host, etc. gets damaged seriously and cannot be accessed anymore for whatever reason. Keep in mind that the backup-ed wallet file itself will NOT be attached to the DASH wallet software at the time of importing funds to it and also sending funs since there is no need for this. Technically speaking the user first manages to (1) create a new DASH keypair, afterwards he/she (2) saves a backup of the wallet file 96

including the new DASH keypair. Finally the user has to (3) send the funds to the public key of the new DASH keypair as far as the coins have been imported to the wallet. The coins will be available on the running wallet such as the backup-ed wallet file. Therefore there is no chance of ever loosing any coins while applying this backup strategy correctly (since you can re-import the same private key several times on different systems to protect against hardware and software failure, also refer to chapter IV.1.5.1#ATTENTION). 1. Click on the Receive tab in the Dash core – Wallet window 2. Type in “ME” in the Label section of the form 3. Click on the Request payment button; a new DASH keypair will be created 4. Click on File → Backup Wallet... and select a folder directory and a name for the encrypted wallet file which will result in a ~1 MB *.dat file. HINT 1: The DASH software will create backups of the wallet on a regular basis which are located in /home/user/.dash/backups. Since the whole .dash folder is hidden, start Dolphin File Manager by clicking on the shelf icon located bottom, left in the taskbar, look for View → Show Hidden Files in order to be able to see its content in the appropriate directory (if needed). HINT 2: Never access files and/or copy/edit them located in the .dash folder while the DASH wallet software is running to avoid serious errors such as damaging files. IV.1.4.1 BACK-UP-HDD: Whonix-VOLUME In order to save the new encrypted wallet file to the Whonix-VOLUME of the BACK-UP-HDD start the Dolphin File Manager first. 1. Open the Dolphin File Manager by clicking on the shelf icon located bottom, left in the taskbar 2. Look for Devices and click on 90 MiB Encrypted Drive 3. A window called KDE Wallet Service pops up: Click on Cancel 4. A window called Password – KDE Daemon pops up: Enter your password for the WhonixVOLUME (compare with chapter III.2.1.1, step 3e) 5. DO NOT check Remember password as a measure of security 6. A window called Authentication is required to unlock the encrypted device VBOX HARDDISK (/dev/sdb1) - PolicyKit1-KDE pops up: Enter your Whonix administration password: changeme (compare with chapter III.4) 7. Save a backup of the wallet file directly from the DASH wallet software to the Whonix-VOLUME of the BACK-UP-HDD (compare with chapter IV.1.4, step 4) 8. Close the DASH wallet software and make sure the exit warning disappears after some time, afterwards close the terminal, too. 9. Make sure that no processes are running anymore and shutdown the Whonix-Workstation VM Working on the Debian host. 10. Navigate to the /home/debian/VirtualBox VMs/Tails directory and look for a file called BACK-UP97

HDD.vdi 11. Start Brasero: Activities (top left of screen) → search for “Brasero” and create a new “Data project” 12. Burn BACK-UP-HDD.vdi to a blank CD/DVD 13. Make sure the BACK-UP-HDD.vdi was burned correctly to a CD/DVD HINT: You are not restricted to copy the BACK-UP-HDD.vdi to a CD/DVD exclusively. Anyway, a CD/DVD is the safest choice at all. If you want to copy the file to a USB drive or SD card make sure the medium is clean and CANNOT attack the Debian host OS in an obvious way (compare with chapter I.5.5). IV.1.5 Import funds Due to the fact that you have made a secure backup of your wallet it is now safe to import funds. For better security always use a virtual keyboard (KDE start button → Applications → Utilities → Virtual Keyboard). 1. Start DASH wallet software from the terminal 2. Make sure your wallet is unlocked for a certain amount of time before importing the DASH private key (chapter IV.1.3, step 3) 3. Import funds: Click on Tools → Debug Console and enter the following command: “importprivkey ” where: importprivkey – command to import the private key of a DASH keypair (WIF required) – DASH private key Example: importprivkey 7s8y9MfP756SKSaurf3dgzGWfmbdMRvWougGh6rs7dSi3p86AJK HINT 1: To lock the wallet at any time simply run the walletlock command in the Debug Console. HINT 2: Alternatively you may want to send some DASH coins from another system (e.g. another wallet, exchange, etc.) to your wallet without the need of entering any private key. Click on the Receive tab in the DASH wallet software. Double-click on the label called “ME” and you will see the address (public key, e.g. XdavTpNGhoe3HMhtVQ5wCcCzSaiu5LFyWj). Go ahead and send your coins to this address you have already created a secure backup of. In comparison to sending coins the import of the private key does not charge you any fees by default. You also have to read and apply the steps mentioned in chapter IV.1.5.1 to backup your funds, finally in case HINT 2 (chapter IV.1.5) is not relevant to you. IV.1.5.1 Backup funds ATTENTION: For now you have imported/added the private key of a DASH keypair representing 98

some coins to your wallet. Be instructed that it is still possible that any other person knowing the private key of the DASH keypair you just imported is still able to repeat the exact import command on another system. This can even be done at a later time regardless of the fact that the private key has already been imported to another wallet – your wallet. To really make sure you are in possession of the coins and to make sure your backup file (chapter IV.1.4 and IV.1.4.1) works as intended you will have to send your coins to another address, this will be the address labeled “ME” you just created in chapter IV.1.4, steps 1 to 3. This process is also known as sweeping. 1. Click on the Receive tab in the DASH wallet software 2. Double-click on the label called “ME” and you will see the address (public key, e.g. XdavTpNGhoe3HMhtVQ5wCcCzSaiu5LFyWj) 3. Copy address to the clipboard by clicking on Copy Address and close the window 4. Click on the Send tab in the DASH wallet software 5. Paste the address of “ME” to line Pay To; Label “ME” will be auto-completed immediately 6. Select Amount: Enter the full amount available under Balance you find bottom, right of the window (pay attention to additional fees) 7. Preferably, check InstantX [https://www.dash.org/wp-content/uploads/2015/04/DashWhitepaperV1.pdf, pp. 13-14] to receive your coins in an instant transaction 8. Click on the Send button IV.1.6 Mixing Funds The mixing of your funds will be performed with the help of the PrivacySend (formerly known as DarkSend) protocol [https://www.dash.org/wp-content/uploads/2015/04/Dash-WhitepaperV1.pdf, pp. 7-13]. This process will anonymize your DASH coins by mixing your coins with those of other users (incl. additional steps) which are also running PrivacySend at the same time as you do. It is highly recommended to mix your coins because the transaction history tells a story about the past (transaction chain) of the coins and therefore has a huge potential to violate the privacy of the user especially in the future if NO anonymization techniques have been applied. 1. Before mixing any coins click on Settings → Options. 2. For the highest degree of privacy set Darksend [PrivacySend] rounds to use to the maximum value of 8 3. Threshold modification: Select the value of Amount of Dash to keep anonymized higher than 1000, preferably 2000 (max. value) is fine because you really want to anonymize all of your coins (compare with chapter I.1). 4. Click on OK to save changes 5. Click on the Start Darksend [PrivacySend] Mixing button (available under the Overview tab) and enter your wallet passphrase once you are asked for 6. The whole mixing process might take a while HINT 1: You will be charged a small fee for using the mixing service which is currently provided by the MNs. For more information about transaction fees click on the Send tab of the wallet which allows 99

to adjust settings. Usually the default configuration is fine. HINT 2: In order to prevent the DASH wallet software from crashing (“Segmentation fault”, etc.) you should always wait until the block chain has fully synchronized with the network and also wait for full MN synchronization. Inside of the DASH wallet software simply click on Tools → Information to view progress. ATTENTION: Due to the fact that once the PrivacySend mixing process has been started your wallet software will deal with a lot of DASH keypairs simultaneously and will also send coins to those new addresses over a period of time. Those coins which have been initially send to the single “ME” backup address beforehand (chapter IV.1.5.1) will NOT be there anymore meaning you cannot restore any coins from only the “ME” backup address as soon as PrivacySend has been started. Keep in mind that once the DASH wallet software has been launched for the first time, a lot of DASH keypairs are created and saved to the wallet file automatically. In reality there exists the plausible risk of losing all of your coins in a system crash due to the fact that coins might have been automatically send to new addresses which have been created during the mixing process which have NOT been available at the time when the DASH wallet software has been launched for the first time. Since a backup of the wallet file has only been made as far as the wallet has been created successfully (chapter IV.1.4.1). To overcome this serious problem it is strongly recommended to simply increase the number of DASH keypairs created automatically by the software in future software releases or otherwise give an alert in case the user wants to use PrivacySend but not sufficient (based on deterministic PrivacySend behavior assumption) DASH keypairs are available. This would decrease the risk of loosing coins due to a serious system crash while being mixed significantly. Anyway, as of writing you are strongly encouraged to backup your (partially) mixed coins on a regular basis. Click on Settings → Options → Wallet and check Enable coin control features. Afterwards click on the Send tab and select Inputs... under Coin Control Features to see a list of all DASH keypairs which are currently in use. IV.2 Test-DASH ATTENTION: The steps mentioned in chapter IV.1 are identical for this chapter. It is up to the user to decide whether you want to do some testing first but it is highly recommended for anyone. This chapter is optional but it is highly recommended to work through this before working with real DASH coins. You do not have to download additional software due to the fact that you can use the regular DASH wallet software to work with publicly available tDASH coins which are free of charge. The additional amount of work is almost zero and chances are very high that you can learn a lot about the practical usage of cryptocurrencies in general while working with tDASH. The tDASH block chain on the testnet is much smaller than the one on the mainnet. This will result in a much faster download of the tDASH block chain. First of all make sure you have closed the DASH wallet software (mainnet). If you have already started the DASH wallet software in the past navigate to the /home/user directory and save a copy of the .dash folder and name the copy .dash_orig. Navigate to the DASH directory /home/user/.dash where you will 100

find a file called dash.conf. Edit this file with a text editor (double-click and select from Known Applications: Utilities → KWrite) and write down: testnet=1 Once you have started the software you will be informed immediately that you are currently working on the testnet and vice versa. Leaving this file empty will cause the DASH wallet software to connect to the mainnet again. HINT: There is no explicit need to make a backup of the DASH folder but it is recommended to avoid later confusion. IV.2.1 Faucet A faucet allows to work with coins for free. Open a Test Faucet website with the Tor Browser (Applications → Internet → Tor Browser) which can be found easily on the Dash Forum [https://www.dash.org/forum/threads/testnet-tools-resources.1768/] such as other helpful tools. You are encouraged to work with the Tails VM (chapter III.2). Make sure you have enabled the network adapter for this task (chapter III.2, step 4d). Create a receiving address on the testnet, then shutdown Whonix Workstation and preferably send tDASH with Tails VM to your address. It might be an option to mount Whonix-VOLUME on both VMs (Whonix-Workstation and Tails VM) to exchange (1) receiving addresses for personal testing and (2) to send back coins to the faucet once you have finished testing to keep the faucet running. This does not introduce serious problems to the WhonixWorkstation, compare with chapter III.2.1#ATTENTION 1 and chapter I.3.2. Refer to chapter V.4.1 mentioning KeePassX to exchange information between two OSes securely. HINT: Once you are done with extensive testing on the testnet you should close the DASH wallet software and rename the current .dash folder in the /home/user directory to .dash_testnet. Afterwards rename .dash_orig to .dash and you are back again on the (regular) mainnet easily. V. MASTERNODE We will only discuss the fastest and easiest way of setting up a new single MN which is the typical process as of writing. V.1 Masternode Preparation In order to setup a new MN the following steps are necessary. MN specific requirements: - 1000 DASH (deposit to run a MN, a technical condition) - equivalent amount of ~10 USD in DASH per month to pay the MNSP - MNSP has been selected (chapter V.4) 101

General requirements: - << 1 DASH (network fees for sending coins) - secure cold wallet created (chapter IV.1.1) V.2 Backup wallet #2 This chapter is strongly related to chapter IV.1.4 and IV.1.4.1. In order to work with a MN, an additional DASH keypair has to be created which will be tied to your wallet such as the MN, the MNSP itself and the public. (A) MN public key of a DASH keypair called “0” where: (A) the personal address where the 1000 DASH deposit will be send to and where future payments for providing the MN service (incentiviced node) are automatically paid to (this address will be shared with the MNSP) 1. Click on the Receive tab in the Dash core – Wallet window 2. Type in “0” in the Label section of the form 3. Click on the Request payment button; a new DASH keypair will be created 4. Click on File → Backup Wallet... and select a folder directory and a name for the encrypted wallet file which will result in a ~1 MB *.dat file. Continue with the exact steps mentioned in chapter IV.1.4.1 to backup the wallet correctly. HINT 1: There is no need to follow the proposed name “0” for (A) mentioned in step 2. But for historical reasons we will stick to the label description “0” for the whole guide. ATTENTION: In case the “0” DASH keypair has NOT already been created before backup #1 has been executed the following statement is true: It is of crucial importance to backup your wallet once again because the backup #1 (chapter IV.1.4) will not represent the current situation anymore once you have moved your coins to the (A) MN public key called “0” (chapter V.3) and therefore backup #1 should be replaced immediately. In addition to this the coins even cannot be restored anymore from backup #1 since the coins have moved to another address. Keep in mind that the private key of the MN public key of a DASH keypair might not be available in the backup #1 file because it has been created AFTER backup #1 has been executed. You will have to do a second backup and should not skip this process due to the fact that backup #1 was only meant to be responsible for backing up the imported funds and to make the strategy of backup #1 work at all (chapter IV.1.5.1). Again, read chapter IV.1.6#ATTENTION. In comparison to this, coins which have been sent to the “0” address after the backup #2 has been executed can always be fully restored from the backup #2 file (on any computer) due to the fact that coins will not leave the “0” address by design as long as the user is interested in running a MN, compare with chapter V.6.

102

HINT 2: In following the steps mentioned above you will create the MN DASH keypair inside the Whonix-Workstation inside of your Debian host. In order to get rid of the usual process of backup wallet #2 you may also create the MN DASH keypair in advance on another system (e.g. Tails on GUIDE computer, NOT Tails VM) instead and then execute the importprivkey command (chapter IV.1.5, step 3) inside the Whonix-Workstation inside of your Debian host. It is recommended to refer to chapter IV.1.1.1.2 and IV.1.1.2.2 to create the DASH keypair securely (WIF needed, finally). This is allows for high security since you have an alternative medium – the paper wallet – of the MN DASH keypair available which is intended to be responsible for a large amount of coins. V.3 Feed new MN This chapter is strongly related to chapter IV.1.5.1. Anyway, pay attention to some fundamental differences. 1. Click on the Receive tab in the DASH wallet software 2. Double-click on the label called “0” ((A) MN public key) and you will see the address (public key, e.g. XdavTpNGhoe3HMhtVQ5wCcCzSaiu5LFyWj) 3. Copy address to the clipboard by clicking on Copy Address and close the window 4. Click on the Send tab in the DASH wallet software 5. Paste the address of “0” to line Pay To; Label “0” will be auto-completed immediately 6. Select Amount: Enter exactly 1000 (pay attention to additional fees) 7. Disable Darksend [PrivacySend] and also disable InstantX sending option (this is very important) 8. Click on the Send button As far as this transaction has been confirmed at least 15 times (15*2.5 mins = 37.5 mins) you are ready to start a new MN. The block confirmation time is 2.5 minutes on average. V.4 Masternode-service-provider This chapter describes which kind of information has to be exchanged between the MNSP and your system. Additionally, you are instructed in how to contact the MNSP via the Tails VM. Please refer to the MarketPlace on the Dash Forum [https://www.dash.org/forum/topic/marketplace.9/] to get an overview of the currently publicly available MNSPs and read the respective reviews. V.4.1 Tails VM and MNSP To some extent the following steps are comparable to chapter IV.2.1. To save the contact information of the MNSP you should save your important information in an encrypted database file. This will be done with KeePassX (Applications → Accessories → KeePassX) on the Tails VM. To learn more about KeePassX visit the corresponing Tails Manage passwords with KeePassX website [https://tails.boum.org/doc/encryption_and_privacy/manage_passwords/index.en.html]. The file should be saved to the Tails-VOLUME (chapter III.2.1.2). 103

To update the dash.conf file (will be mentioned in chapter V.4.2) you are fine in using the WhonixVOLUME (chapter III.2.1.1) of the BACK-UP-HDD (chapter III.2.1) and use an encrypted database file created with KeePassX to exchange information between two OSes securely. Due to the fact that KeePassX is not available on Whonix-Workstation by default you additionally have to install this software with this command sudo apt-get install keepassx. Keep in mind that a shortcut to the terminal (step 1) is located on the desktop, respectively and called “Konsole”. Pay special attention to NOT enter the administrative password of Debian (chapter II.2, step 4a) inside any Whonix VM but “changeme” instead (refer to chapter III.4). V.4.2 Contacting Masternode-service-provider At first you have to contact a MNSP (usually register an account on a website). The provider will usually be paid in advance and takes full care of your MN for a certain amount of time (typically on a monthly basis) and is therefore responsible for the setup of a secure remote Linux server. You and the provider only have to exchange very few information, for example the IP address of the new server which will act as the new MN. Refer to Table 18 showing a typical MN setup process. According to step 1, refer to chapter V.2, (A) MN public key of a DASH keypair called “0”. 1. Enter your MN public key 2. Select payment option for your new MN 3. dash.conf information will be created for you 4. MNSP deposit address will be generated for you 5. Pay the MNSP to the address displayed in step 4 6. Configurations of your MN will be finalized to be ready to work with Table 18: Typical MN setup process It is hereby mentioned explicitly that the outsourcing of the setup of a secure remote Linux server (the MN itself) does not introduce any danger because you always keep in control of your funds. Technically speaking: The private key of the deposit of the MN remains on the DASH computer. The funds (private key) are stored on the secure local wallet at any time and will not leave. The MNSP such as any other person will never have access to the local wallet installed on the DASH computer. The setup of a MN does not require the withdrawal of the 1000 DASH to a third party by design, therefore the user always keeps in control of his/her coins which provides a high level of security. ATTENTION: You have to copy the content of step 3 to your local dash.conf file in the DASH directory before continuing with the following steps. HINT: Only pay the MNSP with coins you have already anonymized properly (compare with chapter IV.1.6).

104

V.4.3 Final backup Due to the fact that all important information is saved to Whonix-VOLUME and Tails-VOLUME you should shutdown all VMs and backup the file called BACK-UP-HDD.vdi on the Debian host as shown in chapter IV.1.4.1, steps 10-13. V.5 Masternode Launch 1. Start MN: Click on Tools → Debug Console and enter the following command: “masternode start ” where: masternode start – command to start the MN in conjunction with configuration details in dash.conf file – your passphrase to unlock the wallet Example:

masternode start h*&E#87y(EY#(yduheu(E*u3^NDLw(

2. You have to get back the following message. Successfully started masternode 3. Close the DASH wallet software as far as you have convinced yourself that the new MN is running and shutdown both Whonix VMs and also shutdown the Debian host. According to step 3, refer to [https://www.dashninja.pl/] and verify the status of your new MN. Also run the “masternode status” command in the console to get the current MN status information. The output should return “ENABLED”. HINT: There is no need to let the DASH wallet software run 24/7. You are fine in shutting down all systems due to the fact that you only started your MN which is located at the MNSP via a remote command in step 1. Keep in mind that the MNSP manages the server which runs 24/7/365. Be advised that you might have to repeat the remote masternode start command in the future again in case important changes occur to the remote client, etc. Refer to your MNSP for detailed information. V.6 Going back online Once you have booted into Whonix Workstation and started DASH wallet software again you can do the following tasks. MN specific tasks: Masternode Voting; Self-sustainable Decentralized Governance by Blockchain [https://www.dash.org/forum/threads/self-sustainable-decentralized-governance-by-blockchain.4708/]

105

General tasks: - send coins HINT: If you do not want to run your MN anymore you can simply withdrawal the 1000 DASH deposit from the address labeled “0” (compare with chapter V.3) to another address of choice. The MN will stop working immediately once the deposit is not available anymore. VI. CONCLUSION AND FORECAST The proposed solution closes the continuously rising security gap most people are exposed to while working with cryptocurrencies and computers at all. This is achieved by the usage of carefully selected software, a dedicated step-by-step guide build on top of a security-privacy-centric approach and the compilation of lots of additional background information for further studying. The main benefits are the use of free and open-source software. There is no need to work with and thereby trust closed-source software with also a price tag attached just like Microsoft Windows or Mac OS X, etc. Because the solution is based entirely on Debian GNU/Linux, a free Linux distribution and other free and open-source software which are all actively developed and reviewed by the research community distributed all over the planet. In addition to the privacy features already implemented in the DASH cryptocurrency, the user will be anonymous online which is an important fact (if additional important security rules such as not providing personal information, etc. are satisfied continuously) in terms of anonymizing network traffic over Tor protecting against traffic analysis. This is guaranteed as long as the user works with Whonix and Tails which are pre-configured to connect to the Internet over Tor exclusively. Therefore data leaks such as “user is connecting to the DASH network at date X, time Y and building connections with DASH nodes K, L, M, ...” caused by very different reasons leading to fundamental violation of privacy are reduced drastically. From now on the DASH software can be utilized anonymously because the user even hides the fact that he/she is using the DASH software behind Whonix which routes all network traffic over Tor. In NOT doing so it is obvious to an adversary to figure out very easily what websites the user visits on a regular basis, which programs on the target's machine interact with the Internet and more generally speaking in what the user is interested in at all over long time periods. Gathering all this information together can be used to de-anonymize and to target a specific user very easily. The new MN will help to further stabilize, increase the security, increase the decentralization and expand the two-tier DASH MN network. Install-and-forget solution: After finishing the setup of the new MN you can simply shutdown the computer, plug off the encrypted USB drive, store it somewhere safe and continue to work with your usual OS installed onto your computer. There is no need to take care of the new MN on a daily basis due to the outsourcing of this work to a third party. Anyway, you are strongly encouraged to support the DASH project by voting with your MN on specific long term decisions relating to DASH and its future. There is no need for a high performance DASH computer. In most cases a standard computer is already 106

fine because we will not put extraordinary stress on this machine. Furthermore, no special USB drive is required. In addition, the solution is not limited to the setup of a DASH MN local wallet exclusively. It is also designed for a standard DASH local wallet setup (with no intention to setup a MN at all) or any other cryptocurrency supporting the proposed solution but this has not been well tested and documented yet and is outside the scope of this guide. The user is instructed in how to use Debian, Whonix and Tails – all including the Tor anonymity network – effectively and furthermore motivated to use those OSes on a regular basis due to obvious benefits in comparison to other closed-source OSes. In following all of the proposals and studying the different subjects the user gets quite a good understanding of how to interact with the Internet in an anonymous and secure way. This allows to enter a lot of different projects which are all of high importance as of writing. This is another very important beneficial side-effect. Keep in mind that the 1000 DASH collateral is not as safe as storing it on a cold storage device, e.g. a paper wallet. But the deposit is still secured extremely well because the USB drive will not go online that often plus the security environment is build up in a very sophisticated way. The funds are stored on your secure local wallet at any time and will not leave. The MNSP such as any other person will never have access to the local wallet installed on the DASH computer. It is of crucial importance to understand well the various steps in the guide in order to achieve a secure and reliable environment. In doing so the whole setup and interaction with the DASH wallet software should be considered almost failsafe. As outlined by Whonix, “Whonix VirtualBox support is a leftover from previous times, where no other supported platforms were supported. [...] Grave security issues are unlikely due to Whonix's design. Rudimentary testing of new images and updates is being done by Patrick [Schleizer, Whonix developer] on a Debian host. [...] That's why the supported platforms table lists VirtualBox in the column 'security' with 'testing' for Linux [...]” [https://www.whonix.org/wiki/VirtualBox#Security_and_Support_Status]. For the very future, the guide should be adjusted to replace VirtualBox with KVM [https://www.whonix.org/wiki/KVM] entirely. This should not be that hard because the guide is written in a general way which allows for different hypervisors [https://en.wikipedia.org/wiki/Hypervisor]. There are already detailed installation instructions available on the Whonix KVM website of how to set up KVM easily. Pay attention to the critical fact that it is not always possible to install KVM instead of VirtualBox especially if you have an older processor available. There has to be done more research relating to the Qubes OS in order to fully replace Debian in the future since this security approach looks more promising and is currently only addressed at advanced users. “Qubes-Whonix is the seamless combination of Qubes OS and Whonix for Security + Anonymity. […] With Qubes-Whonix, you install Qubes as a hypervisor onto your physical host computer, and then install Whonix as two separate TemplateVMs on top of Qubes.” [https://www.whonix.org/wiki/Qubes] This is also true for Subgraph OS. Anyway, speaking of a replacement most of the current setup would still remain valid. As it is true for the replacement of 107

VirtualBox and KVM you might run into problems getting started with Qubes OS in case your system is “outdated” (chapter I.2.5). Keep in mind that the guide was written with the aim in mind to be able to install the proposed setup on almost any machine. In your personal case it might already be an option and also a recommendation to replace VirtualBox and install KVM instead and to also replace Debian with Qubes OS if possible. It might be an option to adopt I2P [https://en.wikipedia.org/wiki/I2P] in a later version of this guide to reduce loads on the Tor network, compare with [https://tails.boum.org/doc/anonymous_internet/why_tor_is_slow/index.en.html]. As of writing there are no official I2P links published for those files we need. It might be an option to download Tails (chapter I.5.4.2), Debian (chapter I.5.5.2) and Whonix (chapter I.5.5.3) via different channels than Tor since those are the biggest files. Be advised that it is not recommended to skip the download of the DASH block chain with the standard client, like downloading the file somewhere else manually and import it back to the DASH directory later. Generally speaking, keep in mind that downloading in clear, e.g. (1) direct HTTP or (2) BitTorrent without applying sophisticated precautions will not provide anonymity. Working with Tails the user is forced to download via Tor. Keep in mind that (centralized) VPNs [https://en.wikipedia.org/wiki/Virtual_private_network] require you to put massive trust in the companies who are running those systems which are usually even not free of charge and transparent relating to their business activities in comparison to Tor [https://tails.boum.org/doc/about/tor/index.en.html] which is free of charge, open-source and also decentralized in addition for example. In the future the standard DASH client will be replaced by the DASH Electrum client as soon as this software supports the mixing of funds (chapter IV.1.6). The usage of the DASH Electrum client allows to instantly start working with the wallet without the need of downloading the block chain in advance. This feature would also reduce the current loads on the Tor network and also waiting time for the user significantly (compare with chapter IV.1.2) but also increases centralization on the other hand (compare with general Electrum and simplified payment verification approaches). In case the Tails developers will add the DASH Electrum client to the standard Tails software packages, the use of Debian host, Whonix, etc. in the current configuration would become totally obsolete, compare with the Tails Exchange bitcoins using Electrum website [https://tails.boum.org/doc/anonymous_internet/electrum/index.en.html] to get a full list of potential benefits. This would imply that a Tails user would be able to work with DASH instantly once Tails has been booted. In addition to this the DASH Evolution [https://www.dash.org/evolution/] approach will accomplish the following tasks (currently in research and development phase). “Using Satoshi-style decentralized networks, users have limited options to consider when using a network. Such options include running a full node, which can be cost prohibitive, difficult to setup/maintain, or light clients that historically have been serviced through centralized SPV installations. When scaling a decentralized network, administrators of the network desire to keep as much decentralization and scalability as possible. We propose a network topology that acts with the efficiency and speed of centralized services, but is in 108

fact entirely decentralized and controlled by the network’s proof-of-work. No one can control the topology of the network at any given time, therefore we can perform secure tasks such as reading/writing user data and serving data to users.” [Duffield, E., “DAPI: Decentralized Application Programming Interface”, (2016), https://www.dash.org/binaries/evo/DAPIDecentralizedApplicationProgrammingInterface-v1.pdf, p. 2] “This design will offer even greater anonymity than before, because you will only access your wallet through the Masternode network. When you want to do anything on the network, you will access the network through the decentralized API. Each request will go to one of over 3,300 Masternodes [as of January 22th, 2016], so your network footprint will be spread out. For even more security and privacy, a user could access the network through proxies [e.g. Tor]. All requests will be done through a restful API or through websockets, which are very easy to protect by using proxies. [...] With this system your money is not stored on the network, it’s in your seed phrase [http://docs.electrum.org/en/latest/seedphrase.html], so only you have access to it.” [Duffield, E., “DashPay and Social Wallet”, (2016), https://www.dash.org/binaries/evo/DashPayDecentralizedWallet-v1.pdf, p. 8] Currently, the full setup takes a lot of time and personal resources. There is no reliable way to automate the setup without introducing mechanisms which require a lot of trust the user has to put into those automated systems, known to the author. Anyway, the whole setup only has to be done once and for all. For future usages the system only has to be updated when important security updates are available. APPENDIX A1 – Testing Results The whole setup has been tested carefully with the specific software versions mentioned below and works without any grave (security) issues known to the author at the time of writing. - DASH wallet 0.12.0.58 (32 bit and 64 bit) [https://www.dash.org/], [http://www.dashorg64cjvj4s3.onion/] - Debian 8.6.0 “Jessie”, “stable” release (amd64) [https://www.debian.org/] - Tails 2.7.1 [https://tails.boum.org/] - VirtualBox 4.3.36_Debian r105129 [https://wiki.debian.org/VirtualBox] - Whonix 13.0.0.1.1 [https://www.whonix.org/], [http://kkkkkkkkkk63ava6.onion/], [http://whonix4iscgg7zzk.onion/] Due to the fact that the Whonix-Workstation is only available as a 32 bit guest machine it is very unlikely that the user will ever face problems relating to virtualization. EXPERIMENTING: If you are interested in experimenting with 64 bit guest machines in general, first 109

read [https://www.virtualbox.org/manual/ch03.html#intro-64bitguests]. If you are unsure or having problems to configure the BIOS properly to enable this feature (if available), simply continue to work with 32 bit guest OSes. This should work for most of the users and has been tested successfully in various configurations. It is also possible to torify any network traffic for a specific OS of choice (not limited to the default pre-configured Whonix-Workstation which is based on Debian GNU/Linux), refer to [https://www.whonix.org/wiki/Other_Operating_Systems]. A2 – DASH (NON-Masternode) Local Wallet If you do NOT have the intention to run a MN at all and you simply want to use the DASH wallet software on your computer like most users want to, simply follow the instructions below. You can achieve the same high security level like those people achieve with the intention to run a MN by following the exact steps in this guide, too. You only have to skip the MN relevant chapters V. and III.2.1.2 which will result in slightly less effort for a standard DASH local wallet setup. In addition to this there is no necessity as a standard user to somehow follow any MN specific requirements as emphasized in chapter I.1 for example. In following the instructions provided in this guide, there is always the easy and fast possibility to migrate from a standard DASH user to a DASH MN user and vice versa since the security environment is build up identically. A3 – Miscellaneous A3.1 Quality of the guide This guide is a work in progress, please help to improve it. If you discover and/or experience any problems feel free to contact. Additional steps for hardening the host OS, etc. are greatly appreciated. The more feedback we have the more likely it is to discover any mistakes, misunderstandings, etc. If you want to share this guide feel free to do so. This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License (CC BY-NC-SA 4.0). [http://creativecommons.org/licenses/by-nc-sa/4.0/] Please refer to the exact URL of this website and give credit to the DASH project [https://www.dash.org/], [http://www.dashorg64cjvj4s3.onion/]. Keep in mind that only THIS source [https://dashpay.atlassian.net/wiki/display/DOC/Dash+SecurityPrivacy+Paper] will always provide the latest version of the guide. A copy of an outdated version somewhere else on the Internet will never be up-to-date and might contain errors which have already been discovered and fixed in a more recent version on THIS website. A3.2 Give back Donations are always greatly appreciated. Since all of the proposed software is free of charge it is up to 110

you to decide whether you profit a lot of them or only use those software occasionally. Keep in mind that almost all of the developers work during their spare time on those free software projects you intend to work with. It is an honorable step to give back if you appreciate their work and efforts. Additionally, web hosting servers and Tor relays [https://www.torproject.org/docs/tor-doc-relay.html] which are almost all run by volunteers cost money. Rented hardware has to be paid for such as upcoming costs for electricity, etc. in order to keep all the systems running. But no one expects you to donate money you had to work hard for. For further ways of contributing visit their websites to learn more about how to help out in general. Finally, once the setup was successful you can help out other people around you by distributing clean and free OSes on CDs/DVDs, educating and promoting the different technologies presented in this guide (such as the guide itself). List of important projects (alphabetical order). DASH: Debian: Tails: Tor: Whonix:

https://www.dashfoundation.io/donate/ https://www.dash.org/ http://www.dashorg64cjvj4s3.onion/ http://www.debian.org/intro/help https://tails.boum.org/contribute/how/donate/index.en.html https://www.torproject.org/getinvolved/volunteer.html.en https://www.whonix.org/wiki/Donate http://kkkkkkkkkk63ava6.onion/wiki/Donate

Tools which might help you while working with cryptocurrencies. BitMixer.io: Blockchain.info: ShapeShift:

https://bitmixer.io/, http://bitmixer2whesjgj.onion/ https://blockchain.info/, https://blockchainbdgpzk.onion/ https://www.shapeshift.io/

111