Changes between Version 19 and Version 20 of doc/TorBOX/Trust

Sep 27, 2012, 11:48:40 PM (7 years ago)



  • doc/TorBOX/Trust

    v19 v20  
    1 [[TOC(noheading, depth=0)]]
     1TorBOX has been renamed to Whonix.
    3 [ aos Homepage]
     3This page has been moved. The History of this page might still be interesting.
    5 = How can I trust these download images? =
    6 Don't trust 'us'! You don't know us. Never trust people you don't know, especially not on the internet. But you can trust these binary images to some extent if you can verify that you get exactly the same code as hundreds of other users (you can check sourceforge how often the builds where downloaded) and no one found and publicly reported any security issue. In order to verify that we post the sha512sum (sha256sum for aos prior 0.2.0) of both .ova images [ here] and on sourceforge. The wiki ensures some trust and integrity through TLS (check the certificate) and the history feature that allows you to verify that the hashsum wasn't tampered with.
    8 If that's not good enough, build your own aos images using the [ Build Documentation].
    10 == TLS ==
    11 TLS/SSL/HTTPS with the CA model is flawed. We don't trust it and you shouldn't either. Even if all the implementation details (revocation not working, every CA can issue certs for anything, including "*") having to trust a 3rd party is a no go. But, we still have to rely on it to some extent for that lack of a widely used web of trust or other alternative.
    13 == GPG ==
    14 GPG: Usually you get a fingerprint on a web site (insecure, or secured with the broken TLS) and then download that from a key server (insecure, or secured with the broken TLS). Unless you have attended any key signing parties and have a trust path to everyone you need to connect with GPG is only as secure as TLS! To mitigate this, it is recommended to check GPG fingerprint from multiple "secure" sites. Bonus points for using different authentication systems such as:
    15 AND ttp://idnxcnkne4qt76tg.onion/docs/signing-keys.html.en. Note that hidden services do not offer very strong authentication (a powerful adversary is more likely than not able to impersonate a hidden service) but together with multiple sources it becomes increasingly costly and improbably that a single adversary can impersonate all of them.
    17 All current aos developers prefer to stay anonymous. There's no way to get gpg key signed (real life "key party") while remaining anonymous. For binary downloads we are currently only using hash sums posted to two sites (this wiki and sourcefourge) to assure authenticity. GPG would at least still have the advantage that you only need to verify the gpg fingerprint once and note it down, not verify a hash sum's authenticity each time there's a new release.
    19 aos developer [ adrelanos (proper)] published his GPG key on 05/29/12.
    21 The GPG key ensures, should the aos infrastructure ever be compromised by a powerful adversary (domain seizure/takeover etc.), that the original aos developers can at least prove, that they are the same people who owned the infrastructure.
    23 = aos developer GPG guidelines =
    24 All aos developers who use long term pseudonyms, are encouraged to:
    25  * Create a 4096/4096 RSA/RSA GPG key.
    26  * Get the latest gpg.conf (currently in T-W script) for stronger hashes, no-emit-version, etc.
    27  * Store the private key inside an encrypted file.
    28  * Make a backup of that encrypted file.
    29  * Remember the password, check yourself regularly.
    30  * Also upload the encrypted file to some (free) online cloud hosting, in case of thief, fire, tornado, etc.
    31  * Since the project started in 2012, the more early the gpg public key was published, the less likely is it, that the public key is effected from an evil developer attack. Adrelanos expects evil developer attacks not to happen against relatively new, unpopular and insignificant projects.
    33 = The Wiki =
    34 The wiki is hosted by Torproject and currently has a DigiCert TLS certificate. Everyone can edit and tamper with the aos pages. Use the history feature, verify all signatures and gpg keys in the shell scripts and at least quickly read through the scripts before running them.
    36 = evil developer attack =
    37 This is only a theoretical attack, as far as we know. We are not aware that it ever happened to any software project. This is not an aos specific problem. It applies to all open source software projects, but more to those where the developers stay anonymous. Examples for such anonymously developed software projects are TrueCrypt, Tails, i2p, aos... As of April 2012 all aos developers are also anonymous.
    39 The attack works like this: [[BR]]
    40 1. Start a new software project. Alternatively join an existing software project. [[BR]]
    41 2. Behave well, publish your sources. Gain trust. [[BR]]
    42 3. Build binaries directly from your sources and offer them for download. [[BR]]
    43 4. Make a great product, get a lot of users. [[BR]]
    44 5. Continue to develop it. [[BR]]
    45 6. Make a second branch of your sources and add malware. [[BR]]
    46 7. Continue to publish your clean sources, but offer your malicious binaries for download. [[BR]]
    47 8. Done! You infected a lot of users. [[BR]]
    49 It is very difficult for end users to notice this attack. Of course, if all users would be added to a botnet, there would be news about this incident very soon and everyone would know. On the other hand, if the backdoor is barely used, it may remain secret for a long time.
    51 The myth, that open source software is automatically more secure than closed source, is still strong and widespread. Yes, open source has advantages but certainly not for this thread model. Who checks if the binaries are made from the proclaimed source and publishes the results? That is called deterministic builds (google it) and it's quite complicated to archive that. We are not aware of any projects, who done that already. For example, the Tor developers also want to offer it but still struggle, see #3688. If you are interested on how complex it is, also google 'trusting trust'.
    53 All that is very difficult and it all comes back to trust. How can you trust anonymous developers? Even if they where not anonymous, you still do not know them and can not trust them? And even if you know them, can you trust them not to have made any mistakes?
    55 These are serious questions to think about. aos is also affected by this issue, just like TrueCrypt, Tails, i2p, etc. Most projects (such as TrueCrypt) do not even admit and inform about this fact. aos is just an ordinary software project, unfortunately we are unable to fix all problems in the world.
    57 aos doesn't distribute any binaries, only redistributes unmodified upstream binaries, shell scripts, we do not create our own binaries. That's what we claim, but it's a lot easier to verify than if we were distributing our own binaries from source code we wrote. Users should worry about the motives and internal security of everyone contributing to, all of the distro devs and maintainers and the hundreds of upstream devs and contributors. Trusted computing base size of a modern operating system today is so ridiculously big and so many people are involved we'd be really surprised if none of the "bugs" were intentional. And then there's the hardware. You think that even AMD could understand an Intel chip or vice versa? Of course one can't compare an anonymous contributor with no investment but time with a multi-national company. On the other hand, detection here is just ridiculously simple (diff the hash sums), while finding and then proving that something is not a bug but a backdoor in a compiler, well designed source code let alone a CPU is impossible. Anonymous or not no longer matters these days. We are in a more or less open "cyber war" or that's what media and lawmakers want us to believe. Fact is, today players are backed by governments, they can use their real identities without fear of repercussion, fake IDs can be created, trustworthy people can be coerced into giving up their gpg and ssh keys if projects even make use of any strong authentication. Judging by the lack of signatures on many open source upstream and even downstream downloads I'm sure many lack any internal security enforcement and still trust DNS to provide authenticity and clear text to provide integrity. About open source, yeah, you can bet Apple, Google and Microsoft have better internal security than the global open source community. However that doesn't make their code trustworthy or says anything about whether closed or open is more secure...
    59 = adrelanos's reasons to stay anonymous =
    60 For anyone curious to know... Protection and paranoia (depending on definition). Just a few examples...
    62 People failing to understand the software making death threats:
    63  *
    65 Making threats to "burn down his house", "pay him an overdue visit":
    66  *
    68 Harassment on border:
    69  *
    70  *
    72 Security and trust shouldn't depend on showing a face:
    73  *
    75 Other reasons:
    76  * Staying out of press with real name.
    77  * Separating private, professional and project's activities.
    79 = Also interesting =
    80  * Tails is a live CD or live USB that aims at preserving your privacy and anonymity. [ Tails about trust.]
    81  * I2p (anonymizing network) does also talk about [ development attacks].
    82  * [ Qubes: What do the Digital Signatures Prove and What They DO NOT Prove]
    83  * [ Miron’s Weblog: Attack Scenarios on Software Distributions]