Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YIci4-0003hv-Pa for bitcoin-development@lists.sourceforge.net; Tue, 03 Feb 2015 12:36:04 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of novauri.com designates 209.85.213.178 as permitted sender) client-ip=209.85.213.178; envelope-from=will.madden@novauri.com; helo=mail-ig0-f178.google.com; Received: from mail-ig0-f178.google.com ([209.85.213.178]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YIci1-0003G6-Ou for bitcoin-development@lists.sourceforge.net; Tue, 03 Feb 2015 12:36:04 +0000 Received: by mail-ig0-f178.google.com with SMTP id hl2so23991414igb.5 for ; Tue, 03 Feb 2015 04:35:56 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:message-id:subject:mime-version :content-type; bh=1GL5pDu6C/PxW51QJObk+Kd1VrCkF+UsOPDtejYKXe0=; b=kh+qrssn18FZJ6hHI+FlyoSXyDJUMR9QO1HBHr8OOAEiqyPk7vgBajCWEPUwl4sxnc /NHGmZaFpdgTlNGr9yJv2gsnaLbqw6EkAvk6FSV0BfVJQbqwpyBDRSeBpkyd/MiubFf8 HHIpoahgaMVHdpljiYCRzoLYOxss1a3/dzzB1FpxJylK1CCTmB8TuyzBe4ZHha63/EY0 diqVHYeni5uI+b1ZHsDJYWNe1bFNMEhhptHGjN0sFhFp5LgDg8LZ6P2XL/3A2GI1/V6U /0gJmrqyJLcuTqqM+kuzwe34VcD803tzC/k9TyqS5Z5lqYNmOWkrTF2lVXt5b1RI8Yf8 7HlA== X-Gm-Message-State: ALoCoQko+fsdqqb7cbnVLqAqHxV50nFq99VrG01xUl2oOaS5nqQ8FWof7O+6jXRNU37I3ZSDdFEy X-Received: by 10.50.32.33 with SMTP id f1mr17368730igi.9.1422965063683; Tue, 03 Feb 2015 04:04:23 -0800 (PST) Received: from Williams-MBP (c-107-2-216-154.hsd1.co.comcast.net. [107.2.216.154]) by mx.google.com with ESMTPSA id r15sm2986418ioi.1.2015.02.03.04.04.22 for (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 03 Feb 2015 04:04:22 -0800 (PST) Date: Tue, 3 Feb 2015 05:04:21 -0700 From: Will To: bitcoin-development@lists.sourceforge.net Message-ID: X-Mailer: Airmail (286) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="54d0b945_3d1b58ba_7f23" X-Spam-Score: -0.5 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message X-Headers-End: 1YIci1-0003G6-Ou Subject: [Bitcoin-development] Subject: Re: Proposal to address Bitcoin malware X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2015 12:36:04 -0000 --54d0b945_3d1b58ba_7f23 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline An idea for the bitcoin malware proposal below, the idea is at the bottom= =E2=80=A6 Using a desktop website and mobile device for 2/3 multisig in lieu of a h= ardware device (trezor) and desktop website (mytrezor) works, but the key= is that the device used to input the two signatures=C2=A0cannot be in th= e same band. =C2=A0What you are protecting against are MITM attacks. =C2=A0= The issue is that if a single=C2=A0device or network is compromised by ma= lware, or if a party is connecting to a counterparty through a channel wi= th compromised security, inputing 2 signatures through the=C2=A0same devi= ce/band defeats=C2=A0the purpose of 2/3 multisig. =C2=A0This is the same = as how MITM defeats 2=46A via mobile phone if the token is entered into t= he same website as the password - the token is simply passed through by t= he attacker to the secure session with the provider, allowing unfettered = access or reuse of tokens for transactions other than those intended by t= he real user. Companies have=C2=A0found clever ways around MITM attacks using SSL sniff= and derivatives by embedding code in mobile apps that communicate not wi= th the website authenticating the user, but with 3rd party company that a= uthenticates the token and passes the authentication to the website throu= gh a different secure channel, making the MITM attack far much more diffi= cult. =C2=A0The trick here is that instead of one channel, we now have tw= o channels that must be compromised. =C2=A0Also, the second channel is be= tween a security company and a (hopefully) professionally run=C2=A0financ= ial=C2=A0services website. =C2=A0There are other approaches to defeat MIT= M, such as fingerprinting pages to detect spoofs. =C2=A0The former (secur= e 3rd party channel) is very secure but requires a trusted third party. =C2= =A0The latter (fingerprinting) is a crap shoot with very high=C2=A0false = positive rates. =C2=A0 Anyway, the exact same principles apply here to this conversation. =C2=A0= The second signature must be presented from a separate band to maintain a= higher=C2=A0degree of security. =C2=A0If one signature occurs via HTTP(s= ) from application 1, another should be SMS through a carrier network, et= c via application 2. The trick we need to look at is how to use the bitcoin network as a deliv= ery mechanism to bypass the need for the trusted third party in the examp= le above. =C2=A0Instead of the second factor routing through a 3rd party = to the intended recipient, we have another option - one that doesn=E2=80=99= t require core development either. 1) Sender > signs signature 1 via desktop > bitcoin network 2/3 P2SH 2) Mobile app also used by sender receives req. from bitcoin network to s= ign signature - not through the site in 1 (similar to the 2nd channel bet= ween the website and security company above) 3) Sender > signs signature 2 via mobile app (or any separate device=C2=A0= operating on a different network - heck could be radio) > 2/3 signatures,= =C2=A0transaction=C2=A0authorized Any wallet service provider can use this model,=C2=A0all they must do is = develop two independent applications=C2=A0such a secure browser plugin an= d a website, or a mobile app and a website that use 2/3 multisig to autho= rize transactions. =C2=A0No core development required - just better secur= ity design and execution by those developing wallets. =C2=A0If the protoc= ol could natively communicate via two=C2=A0separate=C2=A0networks, that m= ight be something to consider, but really developers should already=C2=A0= have all the tools they need, assuming they are competent. If there was a way to perform 2/3 multisig without requiring a second ban= d, performing the function safely by somehow knowing if the service is pe= rformed from a compromised device through some sort of on-blockchain anti= -malware check by validating the signature of the signing=C2=A0applicatio= n by comparing it to a signature recorded when the multisig address was f= unded, =C2=A0that would be a really neat breakthrough. =C2=A0=46ood for t= hought, but I can=E2=80=99t see how that could be executed in a way where= signatures couldn=E2=80=99t be spoofed from a compromised device. =C2=A0= If someone cracks that problem, it=E2=80=99s a really big advance for inf= ormation security. On 02/02/2015 02:54 PM, Eric Voskuil wrote:=C2=A0 >=C2=A0On =46eb 2, 2015, at 11:53 AM, Mike Hearn wrote:=C2=A0 >>=C2=A0 >> In sending the first-signed transaction to another for second=C2=A0 >> signature, how does the first signer authenticate to the second=C2=A0 >> without compromising the independence of the two factors=3F=C2=A0 >>=C2=A0 >> Not sure what you mean. The idea is the second factor displays the=C2=A0= >> transaction and the user confirms it matches what they input to the=C2= =A0 >> first factor. Ideally, using BIP70, but I don't know if BA actually=C2= =A0 >> uses that currently.=C2=A0 >>=C2=A0 >> It's the same model as the TREZOR, except with a desktop app instead=C2= =A0 >> of myTREZOR and a phone instead of a dedicated hardware device.=C2=A0 >=C2=A0 > Sorry for the slow reply, traveling.=C2=A0 >=C2=A0 > My comments were made in reference to this proposal:=C2=A0 >=C2=A0 >>>=C2=A0On =46eb 2, 2015, at 10:40 AM, Brian Erdelyi >> > wrote:=C2=A0 >>>=C2=A0 >>> Another concept...=C2=A0 >>>=C2=A0 >>> It should be possible to use multisig wallets to protect against=C2=A0= >>> malware. =46or example, a user could generate a wallet with 3 keys an= d=C2=A0 >>> require a transaction that has been signed by 2 of those keys. One=C2= =A0 >>> key is placed in cold storage and anther sent to a third-party.=C2=A0= >>>=C2=A0 >>> It is now possible to generate and sign transactions on the users=C2=A0= >>> computer and send this signed transaction to the third-party for the=C2= =A0 >>> second signature. This now permits the use of out of band transaction= =C2=A0 >>> verification techniques before the third party signs the transaction=C2= =A0 >>> and sends to the blockchain.=C2=A0 >>>=C2=A0 >>> If the third-party is malicious or becomes compromised they would not= =C2=A0 >>> have the ability to complete transactions as they only have one=C2=A0= >>> private key. If the third-party disappeared, the user could use the=C2= =A0 >>> key in cold storage to sign transactions and send funds to a new wall= et.=C2=A0 >>>=C2=A0 >>> Thoughts=3F=C2=A0 My comments below start out with the presumption of user platform=C2=A0 compromise, but the same analysis holds for the case where the user=C2=A0= platform is clean but a web wallet is compromised. Obviously the idea is=C2= =A0 that either or both may be compromised, but integrity is retained as=C2=A0= long as both are not compromised and in collusion.=C2=A0 > In the multisig scenario the presumption is of a user platform=C2=A0 > compromised by malware. It envisions a user signing a 2 of 3 output wit= h=C2=A0 > a first signature. The precondition that the platform is compromised=C2= =A0 > implies that this process results in a loss of integrity of the private= =C2=A0 > key, and as such if it were not for the second signature requirement,=C2= =A0 > the malware would be able to spend the output. This may be extended to=C2= =A0 > all of the keys in the wallet.=C2=A0 >=C2=A0 > The scenario envisions sending the signed transaction to an another=C2=A0= > (=22third=22) party. The objective is for the third party to provide th= e=C2=A0 > second signature, thereby spending the output as intended by the user,=C2= =A0 > who is not necessarily the first signer. The send must be authenticated= =C2=A0 > to the user. Otherwise the third party would have to sign anything it=C2= =A0 > received, obviously rendering the second signature pointless. This=C2=A0= > implies that the compromised platform must transmit a secret, or proof=C2= =A0 > of a secret, to the third party.=C2=A0 >=C2=A0 > The problem is that the two secrets are not independent if the first=C2= =A0 > platform is compromised. So of course the malware has the ability to=C2= =A0 > sign, impersonate the user and send to the third party. So the third=C2= =A0 > party *must* send the transaction to an *independent* platform for=C2=A0= > verification by the user, and obtain consent before adding the second=C2= =A0 > signature. The user, upon receiving the transaction details, must be=C2= =A0 > able to verify, on the independent platform, that the details match=C2=A0= > those of the transaction that user presumably signed. Even for simple=C2= =A0 > transactions this must include amount, address and fees.=C2=A0 >=C2=A0 > The central assumptions are that, while the second user platform may be= =C2=A0 > compromised, the attack against the second platform is not coordinated=C2= =A0 > with that of the first, nor is the third party in collusion with the=C2= =A0 > first platform.=C2=A0 >=C2=A0 > Upon these assumptions rests the actual security benefit (increased=C2=A0= > difficulty of the coordinated attack). The strength of these assumption= s=C2=A0 > is an interesting question, since it is hard to quantify. But without=C2= =A0 > independence the entire security model is destroyed and there is thus n= o=C2=A0 > protection whatsoever against malware.=C2=A0 >=C2=A0 > So for example a web-based or other third-party-provisioned=C2=A0 > implementation of the first platform breaks the anti-collusion=C2=A0 > assumption. Also, weak comsec allows an attack against the second=C2=A0= > platform to be carried out against its network. So for example a simple= =C2=A0 > SMS-based confirmation could be executed by the first platform alone an= d=C2=A0 > thereby also break the the anti-collusion assumption. This is why I=C2=A0= > asked how independence is maintained.=C2=A0 >=C2=A0 > The assumption of a hardware wallet scenario is that the device itself=C2= =A0 > is not compromised. So the scenario is not the same. If the user signs=C2= =A0 > with a hardware wallet, nothing can collude with that process, with one= =C2=A0 > caveat.=C2=A0 >=C2=A0 > While a hardware wallet is not subject to onboard malware, it is not=C2= =A0 > inconceivable that its keys could be extracted through probing or other= =C2=A0 > direct attack against the hardware. It's nevertheless an assumption of=C2= =A0 > hardware wallets that these attacks require loss of the hardware.=C2=A0= > Physical possession constitutes compromise. So the collusion model with= =C2=A0 > a hardware wallet does exist, it just requires device possession.=C2=A0= > Depending on the implementation the extraction may require a non-trivia= l=C2=A0 > amount of time and money.=C2=A0 >=C2=A0 > In a scenario where the user signs with HW, then sends the transaction=C2= =A0 > to a third party for a second of three signatures, and finally to a=C2=A0= > second platform for user verification, a HW thief needs to collude with= =C2=A0 > the third party or the second platform before the owner becomes aware o= f=C2=A0 > the theft (notifying the third party). This of course implies that=C2=A0= > keeping both the fist and second platforms in close proximity=C2=A0 > constitutes collusion from a physical security standpoint. This is=C2=A0= > probably sufficient justification for not implementing such a model,=C2= =A0 > especially given the cost and complexity of stealing and cracking a=C2=A0= > well-designed device. A device backup would provide comparable time to=C2= =A0 > recover with far less complexity (and loss of privacy).=C2=A0 >=C2=A0 > Incidentally the hardware wallet idea breaks down once any aspect of th= e=C2=A0 > platform or network to which it connects must be trusted, so for these=C2= =A0 > purposes I do not consider certain hybrid models as hardware wallets at= =C2=A0 > all. =46or example one such device trusts that the compromised computer= =C2=A0 > does not carry out a MITM attack between the signing device and a share= d=C2=A0 > secret entered in parts over time by the user. This reduces to a single= =C2=A0 > factor with no protection against a compromised platform.=C2=A0 >=C2=A0 > Of course these questions address integrity, not privacy. Use of a thir= d=C2=A0 > party implies loss of privacy to that party, and with weak comsec to th= e=C2=A0 > network. Similarly, use of hardware signing devices implies loss of=C2=A0= > privacy to the compromised platforms with which they exchange transacti= ons.=C2=A0 >=C2=A0 > e=C2=A0 -------------- next part --------------=C2=A0 A non-text attachment was scrubbed...=C2=A0 Name: signature.asc=C2=A0 Type: application/pgp-signature=C2=A0 Size: 473 bytes=C2=A0 Desc: OpenPGP digital signature=C2=A0 ------------------------------=C2=A0 Message: 3=C2=A0 Date:=C2=A0Mon, 2 =46eb 2015=C2=A016:44:37 -0800=C2=A0 =46rom: Pieter Wuille =C2=A0 Subject: Re: =5BBitcoin-development=5D =5Bsoftfork proposal=5D Strict DER= =C2=A0 signatures=C2=A0 To: Gregory Maxwell =C2=A0 Cc: Bitcoin Dev =C2=A0 Message-ID:=C2=A0 =C2=A0 Content-Type: text/plain; charset=3DISO-8859-1=C2=A0 On Sun, Jan 25, 2015 at 6:48 AM, Gregory Maxwell w= rote:=C2=A0 > So I think we should just go ahead with R/S length upper bounds as=C2=A0= > both IsStandard and in STRICTDER.=C2=A0 I would like to fix this at some point in any case.=C2=A0 If we want to do that, we must at least have signatures with too-long=C2=A0= R or S values as non-standard.=C2=A0 One way to do that is to just - right now - add a patch to 0.10 to=C2=A0 make those non-standard. This requires another validation flag, with a=C2= =A0 bunch of switching logic.=C2=A0 The much simpler alternative is just adding this to BIP66's DERSIG=C2=A0 right now, which is a one-line change that's obviously softforking. Is=C2= =A0 anyone opposed to doing so at this stage=3F=C2=A0 --=C2=A0 Pieter=C2=A0 ------------------------------=C2=A0 Message: 4=C2=A0 Date: Tue,=C2=A03 =46eb 2015 02:21:24 +0000=C2=A0 =46rom: Gregory Maxwell =C2=A0 Subject: Re: =5BBitcoin-development=5D =5Bsoftfork proposal=5D Strict DER= =C2=A0 signatures=C2=A0 To: Pieter Wuille =C2=A0 Cc: Bitcoin Dev =C2=A0 Message-ID:=C2=A0 =C2=A0 Content-Type: text/plain; charset=3DUT=46-8=C2=A0 On Tue, =46eb 3, 2015 at 12:44 AM, Pieter Wuille wrote:=C2=A0 > The much simpler alternative is just adding this to BIP66's DERSIG=C2=A0= > right now, which is a one-line change that's obviously softforking. Is=C2= =A0 > anyone opposed to doing so at this stage=3F=C2=A0 Thats my preference.=C2=A0 ------------------------------=C2=A0 Message: 5=C2=A0 Date:=C2=A0Mon, 02 =46eb 2015=C2=A023:38:07 -0800=C2=A0 =46rom: Eric Voskuil =C2=A0 Subject: Re: =5BBitcoin-development=5D Proposal to address Bitcoin malwar= e=C2=A0 To: Brian Erdelyi =C2=A0 Cc: Bitcoin Dev =C2=A0 Message-ID: <54D07AD=46.8060809=40voskuil.org>=C2=A0 Content-Type: text/plain; charset=3D=22utf-8=22=C2=A0 On 02/02/2015 11:58 AM, Brian Erdelyi wrote:>=C2=A0 >>Confusing or not, the reliance on multiple signatures as offering=C2=A0= >>greater security than single relies on the independence of multiple=C2=A0= >secrets. If the secrets cannot be shown to retain independence in the=C2= =A0 >>envisioned threat scenario (e.g. a user's compromised operating=C2=A0 >>system) then the benefit reduces to making the exploit more difficult=C2= =A0 >>to write, which, once written, reduces to no benefit. Yet the user=C2=A0= >>still suffers the reduced utility arising from greater complexity,=C2=A0= >>while being led to believe in a false promise.=C2=A0 >=C2=A0 >Just trying to make sure I understand what you=3Fre saying. Are you=C2=A0= >eluding to that if two of the three private keys get compromised there=C2= =A0 >is no gain in security=3F Although the likelihood of this occurring is=C2= =A0 >lower, it is possible.=C2=A0 No, that's not it. Sorry for not being clear. Independence of control is=C2= =A0 the central issue in the analysis of a multiple factor system. If an=C2=A0= attack compromises one factor there must be no way for that attack to=C2=A0= reduce the difficulty of obtaining the other factors.=C2=A0 Some factors (secrets), like a fingerprint, aren't very secret at all.=C2= =A0 But getting someone's fingerprint doesn't also help the attacker get a=C2= =A0 PIN. That factor must be attacked independently. But if the PIN is=C2=A0 encrypted with the fingerprint in a public store, then the PIN is not=C2=A0= independent of the fingerprint and there is really only one secret.=C2=A0= If multiple factors are coincident (located within the same security=C2=A0= perimeter) they are compromized coincidentally. Coincidence has the same=C2= =A0 effect as dependence. Consider a credit card with a =22security code=22=C2= =A0 printed on the back. A successful attack on the leather wallet yields=C2=A0= both secrets.=C2=A0 Individual environments can be compromised with some difficulty (e.g.=C2=A0= desktop malware, fingerprint lift, dictionary attack, brute force PIN,=C2= =A0 etc.). =46or the sake of simplicity, let that chance of successful=C2=A0 independent attack on any factor be 1 in 2 and the resulting probability=C2= =A0 of successful concurrent attack on any n factors be 1 in 2=5En. If m=C2=A0= factors are dependent/coincident on others the relation becomes 1 in=C2=A0= 2=5E(n-m).=C2=A0 Any multi-factor web wallet that handles the user's keys in the browser=C2= =A0 and authenticates the user in the browser to authorize service signing=C2= =A0 is effectively single factor. One attack may be launched by an insider,=C2= =A0 or externally, against the web app, executing in the browser, gaining=C2=A0= coincident access to two secrets. Browser/desktop malware can accomplish=C2= =A0 the same. The difficulty is 1 in 2 vs. the expected 1 in 4.=C2=A0 >As more malware targets bitcoins I think the utility is evident.=C2=A0 >Given how final Bitcoin transactions are, I think it=3Fs worth trying to= =C2=A0 >find methods to help verify those transactions (if a user deems it to=C2= =A0 >be high-risk enough) before the transaction is completed. The balance=C2= =A0 >is trying to devise something that users do not find too burdensome.=C2=A0= I'm not questioning the motive, I agree it's worth trying. But trying is=C2= =A0 not succeeding. Increasing user (and/or system) complexity without=C2=A0 increasing integrity or privacy is a poor trade, and worse if the user=C2= =A0 is misled.=C2=A0 e=C2=A0 -------------- next part --------------=C2=A0 A non-text attachment was scrubbed...=C2=A0 Name: signature.asc=C2=A0 Type: application/pgp-signature=C2=A0 Size: 473 bytes=C2=A0 Desc: OpenPGP digital signature=C2=A0 ------------------------------=C2=A0 -------------------------------------------------------------------------= -----=C2=A0 Dive into the World of Parallel Programming. The Go Parallel Website,=C2=A0= sponsored by Intel and developed in partnership with Slashdot Media, is y= our=C2=A0 hub for all things parallel software development, from weekly thought=C2=A0= leadership blogs to news, videos, case studies, tutorials and more. Take = a=C2=A0 look and join the conversation now.=C2=A0http://goparallel.sourceforge.ne= t/=C2=A0 ------------------------------=C2=A0 =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=C2=A0 Bitcoin-development mailing list=C2=A0 Bitcoin-development=40lists.sourceforge.net=C2=A0 https://lists.sourceforge.net/lists/listinfo/bitcoin-development=C2=A0 End of Bitcoin-development Digest, Vol 45, Issue 11=C2=A0 ***************************************************=C2=A0 --54d0b945_3d1b58ba_7f23 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline