From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YIjZq-0001pj-NX for bitcoin-development@lists.sourceforge.net; Tue, 03 Feb 2015 19:56:02 +0000 X-ACL-Warn: Received: from mail-ob0-f172.google.com ([209.85.214.172]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YIjZl-0003es-UO for bitcoin-development@lists.sourceforge.net; Tue, 03 Feb 2015 19:56:02 +0000 Received: by mail-ob0-f172.google.com with SMTP id nt9so20813583obb.3 for ; Tue, 03 Feb 2015 11:55:48 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=6njhhL/G9uy4bDkoutdxS+MRJAwkoH+hDRon1Izw8Ls=; b=YnF0Om7m5QPMkI/Xy64Q6r4J5yGVaG9eZteSPJGU4K8lfxU2w7QF0ivdUHdOqHtftZ 92gOJ9l/BsZxvAnBvwpnq5YVxiRL4I/+kuxpJyc5N6CVMOO2EeftUR1cALja7Y4HNS+M txSxfvSnhwblpzFfxVmmLRqTw4gV+zxUhzmKaBC50Xw8jUw7ao5KA8lNTVOCmcSYrl0S Up/TUD4P1R8k38ndeE8vrQDFpsSvAVm+aPFFp3ZtIKeeCo2dzufV3KHlrnMLQvO2C4gR xAm8S5ydFGPB5WTwLEqQOqMMbdCfkHC/0meuCyrjHM2D4go3fCDdyomcVK8MoJe7FzmB Hp+Q== X-Gm-Message-State: ALoCoQmP8Ll18yYyt6SpqHdoOLeV5KpEphRV63eUDjK7apwA6uuOmCsVm2vfGhpv3N27rqWaGX7h MIME-Version: 1.0 X-Received: by 10.60.15.198 with SMTP id z6mr2164211oec.84.1422991519848; Tue, 03 Feb 2015 11:25:19 -0800 (PST) Received: by 10.202.102.216 with HTTP; Tue, 3 Feb 2015 11:25:19 -0800 (PST) In-Reply-To: References: Date: Tue, 3 Feb 2015 14:25:19 -0500 Message-ID: From: Adam Weiss To: Will Content-Type: multipart/alternative; boundary=089e0149d0940f2d89050e3408d5 X-Spam-Score: 1.0 (+) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 1.0 HTML_MESSAGE BODY: HTML included in message X-Headers-End: 1YIjZl-0003es-UO Cc: bitcoin-development@lists.sourceforge.net Subject: Re: [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 19:56:02 -0000 --089e0149d0940f2d89050e3408d5 Content-Type: text/plain; charset=UTF-8 > > > Using a desktop website and mobile device for 2/3 multisig in lieu of a > hardware device (trezor) and desktop website (mytrezor) works, but the key > is that the device used to input the two signatures cannot be in the same > band. What you are protecting against are MITM attacks. The issue is that > if a single device or network is compromised by malware, or if a party is > connecting to a counterparty through a channel with compromised security, > inputing 2 signatures through the same device/band defeats the purpose of > 2/3 multisig. > Maybe I'm not following the conversation very well, but if you have a small hardware device that first displays a signed payment request (BIP70) and then only will sign what is displayed, how can a MITM attacker do anything other than deny service? They'd have to get malware onto the signing device, which is the vector that a simplified signing device is specifically designed to mitigate. TREZOR like devices with BIP70 support and third party cosigning services are a solution I really like the sound of. I suppose though that adding BIP70 request signature validation and adding certificate revocation support starts to balloon the scope of what is supposed to be a very simple device though. Regardless, I think a standard for passing partially signed transactions around might make sense (maybe a future extension to BIP70), with attention to both PC <-> small hardware devices and pushing stuff around on the Internet. It would be great if users had a choice of hardware signing devices, local software and third-party cosigning services that would all interoperate out of the box to enable easy multisig security, which in the BTC world subsumes the goals of 2FA. --adam --089e0149d0940f2d89050e3408d5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

U= sing a desktop website and mobile device for 2/3 multisig in lieu of a hard= ware device (trezor) and desktop website (mytrezor) works, but the key is t= hat the device used to input the two signatures=C2=A0cannot be in the same = band.=C2=A0 What you are protecting against are MITM attacks.=C2=A0 The iss= ue is that if a single=C2=A0device or network is compromised by malware, or= if a party is connecting to a counterparty through a channel with compromi= sed security, inputing 2 signatures through the=C2=A0same device/band defea= ts=C2=A0the purpose of 2/3 multisig. =C2=A0

Maybe I'm not following the conversation ver= y well, but if you have a small hardware device that first displays a signe= d payment request (BIP70) and then only will sign what is displayed, how ca= n a MITM attacker do anything other than deny service?=C2=A0 They'd hav= e to get malware onto the signing device, which is the vector that a simpli= fied signing device is specifically designed to mitigate.

TREZOR like devices with BIP70 support and third party cosigning se= rvices are a solution I really like the sound of.=C2=A0 I suppose though th= at adding BIP70 request signature validation and adding certificate revocat= ion support starts to balloon the scope of what is supposed to be a very si= mple device though.

Regardless, I think a standard= for passing partially signed transactions around might make sense (maybe a= future extension to BIP70), with attention to both PC <-> small hard= ware devices and pushing stuff around on the Internet.=C2=A0 It would be gr= eat if users had a choice of hardware signing devices, local software and t= hird-party cosigning services that would all interoperate out of the box to= enable easy multisig security, which in the BTC world subsumes the goals o= f 2FA.

--adam

=
--089e0149d0940f2d89050e3408d5--