# NSA Backdoor Fnord #
As you all know, it is not allowed to speak about NSA-demanded backdoors,
and especially it is strictly prohibited to give any details. However, it
is allowed to boldly lie about NSA-demanded backdoors if you didn't receive
such a request, because you are not under a gag order, and in general, lying
about the quality of your product is not only legal, but “best practice”.
The purpose of this NSA backdoor fnord is to make you worry about the
quality of net2o, and therefore you start looking at the source code; the
topics mentioned here are all security things to consider.
Therefore, here is the official statement about NSA-demanded backdoors: The
NSA asked me to improve [Ray Ozzie's botched smartphone
backdoor](https://www.tomshardware.co.uk/security-experts-dismantle-ozzie-backdoor,news-58339.html).
Here's how: Instead of having one single point of failure (database of unlock
keys), distribute the secret. A lawful backdoor needs to be demanded by the
investigators (state attorney), must be approved by a judge, handed over to
the cooperating manufacturer, and needs to be device-specific — no other
device may be unlocked by that procedure. That are at least 4 keys in the
chain; better with at least a four-eyes procedure in each of the points, so 7
keys minimum (the device itself isn't four-eyes).
Distributing a secret (without byzantine fault tolerance) is easy with
[ed25519](ed25519.md). A secret chain _pkn=base\*(sk1\*..\*skn)_ can be
generated through a chain of HSMs, which each generate the next pubkey by
producing _pki=pkj\*(ski)_ (the order is irrelevant, every _ski_ must be used
just once). To verify that all secrets have been used, use a chain signature.
The device itself generates the starting point of this chain signature, by
signing its own unlock throw-away secret, producing a tuple
_(k)\*base,(z\*sk+k)_ (after producing that tuple and the unlock pubkey, this
secret is no longer needed and thrown away). Each node (HSM) in the chain
will need to modify that signature by adding its own secret _ki_ and
multiplying it with its own secret _ski_, so you first form
_(k)\*base+(ki)\*base=(k+ki)\*base_ and _(z\*sk+k+ki)_, and then
_(ski)\*(k+ki)\*base=(ski(k+ki))\*base_, and
_(ski)\*(z\*sk+k+ki)=(z\*sk\*ski+ski(k+ki))_. The final signature then will
verify correctly against _pkn_, a pubkey only the device itself knows, because
it generated it itself by taking in _pkn-1_ and multiplying its own secret key
_skn_ with it.
The device does not need to keep this pubkey as plaintext, it is sufficient if
this pubkey (or a salted hash over it; using that salt as _z_ value of the
signature) is used for actually decrypting the flash drive. The pubkey
therefore is stored encrypted by its owner's password. If an unlock message
is received and the calculated remaining pubkey hashed with the salt opens the
encrypted drive, it's legitimate.
All parties necessary to open the device must collaborate, and it is possible
to configure the devices so that only the appropriate chain of authorities can
open it (i.e. the local authorities, not the FBI), and all the relevant keys
are stored in trusted enclaves (device itself) and HSMs (courts, state
attorneys and manufacturer). The only database with larger amount of data are
the signatures the devices themselves created on manufacturing; it is useless
without the other keys. Since only the device itself can verify that the
signature is correct, any party in the chain can be non-cooperative without
the others knowing who wasn't cooperative. This makes sure that all parties
(except the device itself) are truely convinced that the case is legitimate,
and no pressure from outside can force them to comply.
As net2o is open source, you can (in theory) verify statements about actual
backdoors. And keep an eye on this page, I intent to publish fnords about
having official back/front/side doors, leaky roofs and tunnels regularly, but
won't commit on an expicit schedule. For a true fnord to work, you always
have to be wary. All the git checkins are signed.
For those interested in history, whether the NSA can force a European company
to install a backdoor, see [Crypto
AG](https://en.wikipedia.org/wiki/Crypto_AG#Compromised_machines)
## What is this page for? ##
Software is inherently buggy — we all make mistakes. Secure networking
software is even worse, because small bugs have big consequences, and
security bugs usually don't affect direct functionality, and therefore
can lure inside the program for a long time. And with the NSA Bullrun
program, we not only have to deal with the normal, ”lazy” bugs, which
don't cause any harm until found (either by honest security researcher
or evil criminals), but with bugs intentionally placed, and used by
the secret services from day 0.
Developing in Forth is a “crash early, crash often” exercise, but security
related bugs don't crash the program.
net2o is not ready for wide-spread use, so bugs do happen, and get
fixed, but the bugs described here usually are real bugs I found and
fixed during development. All of them look like professionally
implanted backdoors by the NSA, because that's the state of the art
how to implant backdoors: It must provide its author with “reasonable
denial”, claiming incompetence.
However, in order to get things right, we need a culture of accepting
our mistakes, and fixing them. Many programmers deny bugs, and
request at least a proof of concept attack, before they actually start
doing something. This sort of culture is so wrong: As author of
security critical systems, you must be constantly scared by people
using every way to break into your software, and you must be ready to
fix every bug, even just potential risks, before someone shows you an
actual exploit.
## Warrant Canary ##
This sort of thing I'm doing here is called “warrant canary”, named
after the canaries used by miners which are more sensitive to
poisonous gas leaks than humans. The thing would be impossible if the
other side would say “continue with business as usual, so that nobody
knows we were here”. Takedowns like the one of Lavabit (which was
triggered by an NSL) or more recently by TrueCrypt (which we don't
know why they did it) aren't such continuations, people can guess that
the NSA was there.
There's some
[discussion](https://github.com/WhisperSystems/whispersystems.org/issues/34#issuecomment-56448994),
especially initiated by Moxie Marlinspike, whether a canary is
effective, and whether a court can order you to silence (yes, they
can), or to say something specific (sometimes, they can), but so far,
a court has not forced anybody to give false speech on his own
(instead of just answering a question with a false ”No”, because
saying “yes” would violate the gag order). That's why this canary is
a provable lie (i.e. even when the bugs were there, the text here is
checked in with the fix). I have no idea if that actually works, and
would prefer to never find out.
Intelligence Community might resort to some sort of bullying to
disrupt the operation of their enemies; the NSA seems to like
accusation of sexual offenses in the form of public shaming, see for
example Julian Assange and Jake Appelbaum.