From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 9BFF5C13 for ; Thu, 10 Sep 2015 17:48:46 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mout.perfora.net (mout.perfora.net [74.208.4.196]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id AD814181 for ; Thu, 10 Sep 2015 17:48:44 +0000 (UTC) Received: from mail-ig0-f170.google.com ([209.85.213.170]) by mrelay.perfora.net (mreueus002) with ESMTPSA (Nemesis) id 0M7Zpp-1Yg5We2VtP-00xNKf for ; Thu, 10 Sep 2015 19:48:43 +0200 Received: by igbkq10 with SMTP id kq10so26145050igb.0 for ; Thu, 10 Sep 2015 10:48:42 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.50.118.71 with SMTP id kk7mr8719688igb.21.1441907322936; Thu, 10 Sep 2015 10:48:42 -0700 (PDT) Received: by 10.50.132.195 with HTTP; Thu, 10 Sep 2015 10:48:42 -0700 (PDT) Received: by 10.50.132.195 with HTTP; Thu, 10 Sep 2015 10:48:42 -0700 (PDT) In-Reply-To: References: Date: Thu, 10 Sep 2015 18:48:42 +0100 Message-ID: From: Adam Back To: Bitcoin Dev Content-Type: multipart/alternative; boundary=089e0118372ec86dad051f68355a X-Provags-ID: V03:K0:PFj7zOCl28qS6y+8n5B0+nzfz0fWNQcV1UmyEjCD02I812jCM17 b4e9ROJovU1xUMGkuvnGlSg4NpGeSFinhw244fPQ+wAFdJsS2II+7gbO/ADz2Xk/BJyi+tE 3IAo6Q1IX3JqzC2tfVXPxK09yebK0OddVjz0lweSTOCMIYSNPfjEaYwF6H+yfq1qwggJGxG 50W+K8xGMQ+sT9j5pv1ow== X-UI-Out-Filterresults: notjunk:1;V01:K0:aLXHMktba0Y=:h7M2WdXVfYUoWwCUARjfb4 UnvruIVuZH3eX9BgdSiNpGbHynuLOs13xjx0kXrBkErTchi6qE8FJm1JgxbERgoI/D9BmTwaE S7+a0V3MvWaapDoUPJFWnHylgAEhw+VpajPdtOxBI9ou5V+my9oUscXPLgztsRnILe0//iaJX lqYDKk0vtG9oZeUw6428UP1NXcUE8kxuyoQVdyUOUlSvekRHITtR2grL294nXON3twOIyDZSd wwZ9pVLkh0G0uyL5j/559fZhhNv8uepGNfoTuek48y5RBnqFCBzX6LUM7gZ4meSjm9y6/vOKz nrOlXDlPlSEcEnp6fmlG12EYb7qaSY5wzvfoQGjVtxsfSj4sS9PrgcuHdrQueVk+36l9iKGPg +TxpxTLpjDdPUJGXhWuzC/+z3eL6Yk4iFrpQdfMHP4P20si+3Hzr1G2buHuOsTQa+lX5tlejB DHUQX0x3hTwLSrIMkBIc7SgQ+Ggw52GKLQn1ZXEWcKYfntfKnQzjXW/1+r4oleaflfbzZ03xM jpvsF4lgcUAOI4F8/YRct4edCesqVFfvTCj+BmyQVSkjte9jmXl0eRZsKbuyhl+IiN4b0NuM9 urzC0Qtku4eViaDm1hR8tiR44422E4gtVdMU9v6PUhLLf/RC2i1mRJap2ujLgZXNvKaIhKEeZ CXknNJx6aVhQtg71eKTUluf0AS9WgNvqSW5VTI7/huofO+2M30xSDyN1vcP1kh8NWmBYpSFIS bvscGSq9YYJyDmNr X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: [bitcoin-dev] Bitcoin threat modelling thread X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2015 17:48:46 -0000 --089e0118372ec86dad051f68355a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Came across this https://groups.google.com/forum/m/#!topic/bitcoin-xt/zbPwfDf7UoQ useful thread discussing Bitcoin threat modelling may reach wider audience on this list. Text from Mike Hearn: think the next stage is to build a threat model for Bitcoin. This mail starts with background. If you already know what a threat model is you can skip to the last section where I propose a first draft, as the starting point for discussion. An intro to threat modelling In security engineering, a threat model is a document that informally specifies: Which adversaries (enemies) do you care about?What can they do?Why do they want to attack you?As a result: what threats do they pose?How do you prioritise these threats? Establishing a threat model is an important part of any security engineering project. In the early days of secure computing, threat modelling hadn't been invented and as a result projects frequently hit the following problem: Every threat looked equally serious, so it became impossible to prioritise Almost anything could become a threat, if you squinted right So usability, performance, code maintainability etc were sacrificed over and over to try and defend against absurd or very unlikely threats just because someone identified one, in an endless race The resulting product sucked and nobody used it, thus protecting people from no threats at all PGP is a good example of this problem in action. Making good threat models isn't easy (see The Economist article,New Threat Model Army ). It can be controversial, because a threat model involves accepting that you can't win all the time - there will exist adversaries that you realistically cannot beat. Writing them down and not worrying about them anymore liberates you to focus on other threats you might do a better job at, or to work on usability, or features, or other things that users might actually care about more. You can make your threat model too weak, so it doesn't encompass real threats your users are likely to encounter. But a much more common problem is making the model too strong: including *too many* different kinds of threats. Strangely, this can make your product *less* secure rather than more. One reason is that with too many threats in your model, you can lose your ability to prioritise: every threat seems equally important even if perhaps really they aren't, and then you can waste time solving "threats" that are absurd or incredibly unlikely. Even worse, once people add things in to a threat model they hate taking them out, because it'd imply that previous efforts were wasted. The Tor threat model A good example of this is Tor. As you my know I have kind of a love/hate relationship with Tor. It's a useful thing, but I often feel they could do things differently. The Tor project *does * have a threat model , and it is a very strong one. Tor tries to protect you against adversaries that care about very small leaks of application level data, like a browser reporting your screen size, because it sees its mission as making all traffic look identical, rather than just hiding your IP address. As a consequence of this threat model Tor is meant to be used with apps that are specifically "Torified", like their Tor Browser which is based on Firefox. If a user takes the obvious approach of just downloading and running the Tor Browser Bundle, their iTunes traffic won't be anonymised. The rationale is it's useless to route traffic of random apps via Tor because even if that hides the IP address, the apps might leak private data anyway as they weren't designed for it. This threat model has a couple of consequences: It's extremely easy to think you're hiding your IP address when in fact you aren't, due to using or accidentally running non-Torified apps. The Tor Browser is based on Firefox. When Chrome came along it had a clearly superior security architecture, because it was sandboxed, but the Tor project had made a big investment in customising Firefox to anonymise things like screen sizes. They didn't want to redo all that work. The end result of this is that Tor's adversaries discovered they could just break Tor completely by hacking the web browser, as Firefox is the least secure browser and yet it's the one the Tor project recommends. The Snowden files contain a bunch of references to this. Interestingly, the Tor threat model explicitly *excludes* the NSA because it can observe the whole network (it is the so-called "global passive adversary"). Tor does this because they want to support low latency web browsing, and nobody knows how to do that fast enough when your adversary can watch the traffic between all Tor nodes. So they just exclude such enemies from their threat model and that is why Tor is possible. But even more interestingly, it turned out that their threat model assumptions weren't quite correct. The NSA/GCHQ should, in theory, be able to totally deanonymise Tor. But in practice they can't. When the time finally came the 5 Eyes agencies attacked Tor by hacking the web browser, not by exploiting their global observation abilities. Tor has competitors - the commercial VPN providers. They have a rather different threat model, where they explicitly don't care about application level attacks like web sites looking at your screen size. They *only* care about hiding your IP address. As a result their products work for every app, and users can easily use Chrome or any other secure web browser. Additionally they only add one hop of latency because the VPN provider does not include itself in the threat model. This solves for a different set of adversaries, but for many users it's actually a more appropriate set and as a result VPNs are vastly more popular than Tor is. So to recap, we should build a threat model for Bitcoin because: We have limited manpower and therefore must prioritise, sometimes brutally Without a model anything can be a threat, so changes that are obvious or look like technical no-brainers can get shot down due to the risk of absurd or ridiculous attacks. This happens in Bitcoin Core *a lot*. It will bring more formality and rigour to our thinking about security. Proposed model This is *a suggestion only*. I expect vigorous debate and for some people to want a different (probably stronger) model. Models are just documents so they can always be tweaked later, there's no need for v1 to be perfect. OK. Adversaries I think we should care about in version 1, in priority order: Rational individuals and small groups, motivated by profit. The "global passive adversary" as defined by the IETF , motivated by a desire to map Bitcoin transactions to people in bulk. And that's it. *The GPA* The "global passive adversary" can mean intelligence agencies *but only sometimes*. Specifically, it assumes they only watch and they don't actively interfere. This assumption is of course not entirely valid - IAs do sometimes engage in active attacks. My suggested threat model doesn't include that activity because (1) it's hard to do anything about it and (2) they much prefer to stay stealthy anyway. Of course, in the Bitcoin system, there may be other GPAs. Anyone who watches the block chain can potentially be such an adversary. Note the careful wording: you have to be doing deanonymization *in bulk* to be an in-scope adversary. This is to avoid including block explorers that have notes features, people who build lists of well known addresses etc. We can't stop people doing that: it's up to Bitcoin users to avoid telling the world which transactions are theirs. It also excludes exchanges that are trying to monitor transactions going in and out of their platform for compliance purposes: they are not attempting to do this for the entire system, therefore, they are not adversaries in this threat model. *Individuals and small groups* They are assumed to have hacking skills that are considered good by the standards of ordinary hackers - they are not script kiddies. However they are also not state-level hackers: they do not have an endless bag of zero days that can exploit any imaginable device. These attackers are motivated by profit. An attack that yields only worthless pieces of data is not interesting to these adversaries: they want to monetise. Attacks that involve some incredibly convoluted process to turn data into money is also uninteresting: we assume a level of rationality that means they'll ignore attacks with very poor effort/reward ratios. *Examples* Here are some examples of attackers that would be in-scope for this threat model: =E2=9C=93 A hacker who is attempting to steal the contents of your Bitcoin = wallet =E2=9C=93 A mugger at a conference who is trying to identify rich targets t= o beat up =E2=9C=93 A business owner who is attempting to discover the revenue of his competitor =E2=9C=93 A government attempting to build a map of every Bitcoin transacti= on to people =E2=9C=93 Someone attempting to profit off a quick market panic by short se= lling BTC and then DoSing the network .... and would not be in scope ..... =E2=9C=98 An actor who learns IP addresses of people using Bitcoin (reason:= not profitable, mere fact of use is not enough to build a GPA map) =E2=9C=98 A short seller who needs to successfully root a specific, well ru= n server to cause problems (reason: without zero days it's hard to attack a fully patched and locked down machine) =E2=9C=98 A bitcoin exchange that demands proof of where your money came fr= om (reason: not global adversary) =E2=9C=98 A government who wants to shut down Bitcoin globally (reason: act= ive state adversary, can't realistically stop this as they can always mine a bogus chain) =E2=9C=98 A government who wants to shut down Bitcoin in their own territor= y (reason: active state adversary, can just find and arrest anyone advertising BTC acceptance) =E2=9C=98 A developer who wants to turn the block chain into a file sharing= network (reason: not rational, the resulting product would be terrible) =E2=9C=98 A random individual learning the balance of wallets on random IP addresses (reason: can't monetise with any reasonable effort) .... and could be argued either way ..... =E2=80=A2 A developer who wants to use the block chain for timestamping lot= s of data (can be seen as "motivated by profit", OTOH, actual threat is pretty low) =E2=80=A2 A miner who constantly tries to mine zero sized blocks or constan= tly double spends against high profile merchants (can be seen as "motivated by profit" but also not rational behaviour as it'd tank the price of BTC) Obviously this stuff is subjective. We can argue about what "rational" means for miners, for instance. The goal of the model is not to be 100% accurate or a perfect prediction of the future. It's just there to help people prioritise development efforts. Should I work on *this* new feature or addressing *that* threat? A threat model can help you decide whether it's worth it. People can still choose to work on threats that are outside of this model if they want to, and we can also choose to ignore threats that might be inside it, if the cost/benefit ratio is really bad. The exclusion of many types of government adversary might be controversial. It's for practical reasons: governments have lots of very effective ways to interfere with Bitcoin that we can't do anything about, like bank blockades, and so far most of them seem to be taking a wait-and-see stance anyway. --089e0118372ec86dad051f68355a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi

Came across this https://groups.google.com/forum/m/#!topic= /bitcoin-xt/zbPwfDf7UoQ useful thread discussing Bitcoin threat modelli= ng may reach wider audience on this list.=C2=A0

Text from Mike Hearn:

=C2=A0think the next stage is to build a threat model for Bi= tcoin.

This mail starts with background. If you already know what a= threat model is you can skip to the last section where I propose a first d= raft, as the starting point for discussion.


An intro to threat modelling

In security engineering, a=C2=A0threat model=C2=A0is a document that informa= lly specifies:

Which adversaries (enemies) do you care about?What can they = do?Why do they want to attack you?As a result: what threats do they pose?Ho= w do you prioritise these threats?

Establishing a threat model is an important part of any secu= rity engineering project. In the early days of secure computing, threat mod= elling hadn't been invented and as a result projects frequently hit the= following problem:

Every threat looked equally serious, so it became impossible= to prioritise

Almost anything could become a threat, if you squinted right=

So usability, performance, code maintainability etc were sac= rificed over and over to try and defend against absurd or very unlikely thr= eats just because someone identified one, in an endless race

The resulting product sucked and nobody used it, thus protec= ting people from no threats at all

PGP is a good example of this problem in action.

Making good threat models isn't easy (see The Economist = article,New Threat Model Army). It can be controversial, because= a threat model involves accepting that you can't win all the time - th= ere will exist adversaries that you realistically cannot beat. Writing them= down and not worrying about them anymore liberates you to focus on other t= hreats you might do a better job at, or to work on usability, or features, = or other things that users might actually care about more.

You can make your threat model too weak, so it doesn't e= ncompass real threats your users are likely to encounter. But a much more c= ommon problem is making the model too strong: including=C2=A0too many=C2=A0different kinds of threats. Strangely, this can make your product=C2= =A0less=C2=A0secure=C2=A0rather than more.

One reason is that with too many threats in your model, you = can lose your ability to prioritise: every threat seems equally important e= ven if perhaps really they aren't, and then you can waste time solving = "threats" that are absurd or incredibly unlikely.

Even worse, once people add things in to a threat model they= hate taking them out, because it'd imply that previous efforts were wa= sted.

The Tor threat model

A good example of this is Tor. As you my know I have kind of= a love/hate relationship with Tor. It's a useful thing, but I often fe= el they could do things differently.

The Tor project=C2=A0does= =C2=A0have a threat model, and it is=C2=A0a very strong one. To= r tries to protect you against adversaries that care about very small leaks= of application level data, like a browser reporting your screen size, beca= use it sees its mission as making all traffic look identical, rather than j= ust hiding your IP address. As a consequence of this threat model Tor is me= ant to be used with apps that are specifically "Torified", like t= heir Tor Browser which is based on Firefox. If a user takes the obvious app= roach of just downloading and running the Tor Browser Bundle, their iTunes = traffic won't be anonymised. The rationale is it's useless to route= traffic of random apps via Tor because even if that hides the IP address, = the apps might leak private data anyway as they weren't designed for it= .=C2=A0

This threat model has a couple of consequences:

It's extremely easy to think you're hiding your IP a= ddress when in fact you aren't, due to using or accidentally running no= n-Torified apps.

The Tor Browser is based on Firefox. When Chrome came along = it had a clearly superior security architecture, because it was sandboxed, = but the Tor project had made a big investment in customising Firefox to ano= nymise things like screen sizes. They didn't want to redo all that work= .

The end result of this is that Tor's adversaries discove= red they could just break Tor completely by hacking the web browser, as Fir= efox is the least secure browser and yet it's the one the Tor project r= ecommends. The Snowden files contain a bunch of references to this.

Interestingly, the Tor threat model explicitly=C2=A0exclu= des=C2=A0the NSA because it can observe the whole network (it is the so= -called "global passive adversary"). Tor does this because they w= ant to support low latency web browsing, and nobody knows how to do that fa= st enough when your adversary can watch the traffic between all Tor nodes. = So they just exclude such enemies from their threat model and that is why T= or is possible.

But even more interestingly, it turned out that their threat= model assumptions weren't quite correct. The NSA/GCHQ should, in theor= y, be able to totally deanonymise Tor. But in practice they can't. When= the time finally came the 5 Eyes agencies attacked Tor by hacking the web = browser, not by exploiting their global observation abilities.

Tor has competitors - the commercial VPN providers. They hav= e a rather different threat model, where they explicitly don't care abo= ut application level attacks like web sites looking at your screen size. Th= ey=C2=A0only=C2=A0care about hiding your IP address. As a result the= ir products work for every app, and users can easily use Chrome or any othe= r secure web browser. Additionally they only add one hop of latency because= the VPN provider does not include itself in the threat model.=C2=A0

This solves for a different set of adversaries, but for many= users it's actually a more appropriate set and as a result VPNs are va= stly more popular than Tor is.

So to recap, we should build a threat model for Bitcoin beca= use:

We have limited manpower and therefore must prioritise, some= times brutally

Without a model anything can be a threat, so changes that ar= e obvious or look like technical no-brainers can get shot down due to the r= isk of absurd or ridiculous attacks. This happens in Bitcoin Core=C2=A0a= lot.

It will bring more formality and rigour to our thinking abou= t security.



Proposed model

This is=C2=A0a suggestion only. I expect vigorous deb= ate and for some people to want a different (probably stronger) model. Mode= ls are just documents so they can always be tweaked later, there's no n= eed for v1 to be perfect.

OK. Adversaries I think we should care about in version 1, i= n priority order:

Rational individuals and small groups, motivated by profit.= =C2=A0

The "global passive adversary"=C2=A0as defined by the IETF, motivated by a desire to map Bitcoin= transactions to people in bulk.

And that's it.

The GPA

The "global passive adversary" can mean intelligen= ce agencies=C2=A0but only sometimes. Specifically, it assumes they o= nly watch and they don't actively interfere. This assumption is of cour= se not entirely valid - IAs do sometimes engage in active attacks. My sugge= sted threat model doesn't include that activity because (1) it's ha= rd to do anything about it and (2) they much prefer to stay stealthy anyway= .

Of course, in the Bitcoin system, there may be other GPAs. A= nyone who watches the block chain can potentially be such an adversary. Not= e the careful wording: you have to be doing deanonymization=C2=A0in bulk= =C2=A0to be an in-scope adversary. This is to avoid including block exp= lorers that have notes features, people who build lists of well known addre= sses etc. We can't stop people doing that: it's up to Bitcoin users= to avoid telling the world which transactions are theirs. It also excludes= exchanges that are trying to monitor transactions going in and out of thei= r platform for compliance purposes: they are not attempting to do this for = the entire system, therefore, they are not adversaries in this threat model= .

Individuals and small groups

They are assumed to have hacking skills that are considered = good by the standards of ordinary hackers - they are not script kiddies. Ho= wever they are also not state-level hackers: they do not have an endless ba= g of zero days that can exploit any imaginable device.

These attackers are motivated by profit. An attack that yiel= ds only worthless pieces of data is not interesting to these adversaries: t= hey want to monetise. Attacks that involve some incredibly convoluted proce= ss to turn data into money is also uninteresting: we assume a level of rati= onality that means they'll ignore attacks with very poor effort/reward = ratios.

Examples

Here are some examples of attackers that would be in-scope f= or this threat model:

=E2=9C=93 A hacker who is attempting to steal the contents o= f your Bitcoin wallet

=E2=9C=93 A mugger at a conference who is trying to identify= rich targets to beat up

=E2=9C=93 A business owner who is attempting to discover the= revenue of his competitor

=E2=9C=93 A government attempting to build a map of every Bi= tcoin transaction to people

=E2=9C=93 Someone attempting to profit off a quick market pa= nic by short selling BTC and then DoSing the network

.... and would not be in scope .....

=E2=9C=98 An actor who learns IP addresses of people using B= itcoin (reason: not profitable, mere fact of use is not enough to build a G= PA map)

=E2=9C=98 A short seller who needs to successfully root a sp= ecific, well run server to cause problems (reason: without zero days it'= ;s hard to attack a fully patched and locked down machine)

=E2=9C=98 A bitcoin exchange that demands proof of where you= r money came from (reason: not global adversary)

=E2=9C=98 A government who wants to shut down Bitcoin global= ly (reason: active state adversary, can't realistically stop this as th= ey can always mine a bogus chain)

=E2=9C=98 A government who wants to shut down Bitcoin in the= ir own territory (reason: active state adversary, can just find and arrest = anyone advertising BTC acceptance)

=E2=9C=98 A developer who wants to turn the block chain into= a file sharing network (reason: not rational, the resulting product would = be terrible)

=E2=9C=98 A random individual learning the balance of wallet= s on random IP addresses (reason: can't monetise with any reasonable ef= fort)

.... and could be argued either way .....

=E2=80=A2 A developer who wants to use the block chain for t= imestamping lots of data (can be seen as "motivated by profit", O= TOH, actual threat is pretty low)

=E2=80=A2 A miner who constantly tries to mine zero sized bl= ocks or constantly double spends against high profile merchants (can be see= n as "motivated by profit" but also not rational behaviour as it&= #39;d tank the price of BTC)

Obviously this stuff is subjective. We can argue about what = "rational" means for miners, for instance.

The goal of the model is not to be 100% accurate or a perfec= t prediction of the future. It's just there to help people prioritise d= evelopment efforts. Should I work on=C2=A0this=C2=A0new feature or a= ddressing=C2=A0that=C2=A0threat? A threat model can help you decide = whether it's worth it. People can still choose to work on threats that = are outside of this model if they want to, and we can also choose to ignore= threats that might be inside it, if the cost/benefit ratio is really bad.<= br>

The exclusion of many types of government adversary might be= controversial. It's for practical reasons: governments have lots of ve= ry effective ways to interfere with Bitcoin that we can't do anything a= bout, like bank blockades, and so far most of them seem to be taking a wait= -and-see stance anyway.

--089e0118372ec86dad051f68355a--