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-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from <will.madden@novauri.com>) id 1YImQE-0001y8-I5 for bitcoin-development@lists.sourceforge.net; Tue, 03 Feb 2015 22:58:18 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of novauri.com designates 209.85.213.179 as permitted sender) client-ip=209.85.213.179; envelope-from=will.madden@novauri.com; helo=mail-ig0-f179.google.com; Received: from mail-ig0-f179.google.com ([209.85.213.179]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YImQD-0002OY-1F for bitcoin-development@lists.sourceforge.net; Tue, 03 Feb 2015 22:58:18 +0000 Received: by mail-ig0-f179.google.com with SMTP id l13so2157iga.0 for <bitcoin-development@lists.sourceforge.net>; Tue, 03 Feb 2015 14:58:11 -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:cc:message-id:in-reply-to :references:subject:mime-version:content-type; bh=EcN0dOaLX7reJGFDBYd60nnVweBGpJHnDWB6u97neDc=; b=dIzIvk1G/lsIobA40NaKjZBqWWIv3V0zcZP2XAEGVUW72qn00m/MHpTpkidReYcNKy 0YQdZGWXR5cqF4U2mrwM7bzkGxI6N9z0KfuMa+A5M+9Lt0DDeclWQFKwQkbeaMvPVOyU giJGR3+8N5v37CMu4siak2Zh0cnH75uWfbaMbiqbqdEDw0dwSR8qNFWOhmTga9C8YUS4 PreM+5L1Kz9xNthXvc4iJfrCUMO0iGn1g4rCt4DQSp5dEm57aEXrj23R2w28vW9dbcg4 JhYZBUV5AVfJwzfDQpugu0E/WuSmzO+qmhh1XlrE1rFrgRfT3Llv5T3eGKO7jrFxoGl3 4SAg== X-Gm-Message-State: ALoCoQkv+tTi3VntLyo2njNzvKsdrebxkwXzCgWXtnTMY/9Ttrosazgmw9+w0eNtckTRm1fiqKPq X-Received: by 10.42.95.12 with SMTP id d12mr26681315icn.12.1423004291707; Tue, 03 Feb 2015 14:58:11 -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 kz4sm8644185igb.17.2015.02.03.14.58.10 (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 03 Feb 2015 14:58:11 -0800 (PST) Date: Tue, 3 Feb 2015 15:58:10 -0700 From: Will <will.madden@novauri.com> To: Adam Weiss <adam@signal11.com> Message-ID: <etPan.54d15282.3352255a.8c05@Williams-MBP> In-Reply-To: <CAFVoEQQHVcY0Ad-4c2wnH+WF_7M-o5SNwVr-nce_9bQ794cwDQ@mail.gmail.com> References: <etPan.54d0b945.46e87ccd.7f23@Williams-MBP> <CAFVoEQQHVcY0Ad-4c2wnH+WF_7M-o5SNwVr-nce_9bQ794cwDQ@mail.gmail.com> X-Mailer: Airmail (286) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="54d15282_109cf92e_8c05" 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: 1YImQD-0002OY-1F 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: <bitcoin-development.lists.sourceforge.net> List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, <mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe> List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development> List-Post: <mailto:bitcoin-development@lists.sourceforge.net> List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help> List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, <mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe> X-List-Received-Date: Tue, 03 Feb 2015 22:58:18 -0000 --54d15282_109cf92e_8c05 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Adam - the conversation was pretty open regarding the factor / channel= used to sign at the bottom. =C2=A0No argument from me and I agree comple= tely that hardened single purpose computers are more secure than desktop = browsers, browser extensions, SMS, or mobile apps when involved in multis= ig authorization. =C2=A0The point below was that risks with other channel= s are far higher if auth data is input from two channels through one, suc= h as entering a 2=46A phone token and desktop password into the same desk= top browser session - MITM phishing attack on websites that bypasses phon= e 2=46A as an example, serendipitously timed yet tragic example of this s= cam with coinbase today:=C2=A0https://www.reddit.com/r/Bitcoin/comments/2= ungby/fuck=5Fi=5Fjust=5Fgot=5Fscammed/ On the topic of hardened single purpose computers, and I mean no offense = to our friends at Trezor, Case, or similar but I think the future of this= type of security approach with bitcoin is extremely bright. =C2=A0It=E2=80= =99s just far more likely to involve chips integrated directly in PC / Ma= c motherboards and mobile devices / wearables where signing is done in th= e hardware inaccessible to the OS or BIOS. =C2=A0This is a way for mainst= ream users to use bitcoin securely, integrate it with apps running from p= opular OS=E2=80=99s and get bitcoin into the internet on a very granular = level, and Joe six pack and Sally soccer mom never even know they are usi= ng multisig. =C2=A0It took 20+ years for people to get used to cards vs. = cash. =C2=A0The telephone took 50 years to catch on and become cost compe= titive. I think the key is making it invisible to the user. =46rom:=C2=A0Adam Weiss <adam=40signal11.com> Reply:=C2=A0Adam Weiss <adam=40signal11.com>> Date:=C2=A0=46ebruary 3, 2015 at 12:25:20 PM To:=C2=A0Will <will.madden=40novauri.com>> Cc:=C2=A0bitcoin-development=40lists.sourceforge.net <bitcoin-development= =40lists.sourceforge.net>> Subject:=C2=A0 Re: =5BBitcoin-development=5D Subject: Re: Proposal to add= ress Bitcoin malware =20 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=A0 What you are protecting against are MITM attacks.=C2=A0= The issue is that if a single=C2=A0device or network is compromised by m= alware, or if a party is connecting to a counterparty through a channel w= ith compromised security, inputing 2 signatures through the=C2=A0same dev= ice/band defeats=C2=A0the purpose of 2/3 multisig. =C2=A0 Maybe I'm not following the conversation very well, but if you have a sma= ll hardware device that first displays a signed payment request (BIP70) a= nd then only will sign what is displayed, how can a MITM attacker do anyt= hing other than deny service=3F=C2=A0 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.=C2=A0 I suppose though that a= dding BIP70 request signature validation and adding certificate revocatio= n 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 attenti= on to both PC <-> small hardware devices and pushing stuff around on the = Internet.=C2=A0 It would be great if users had a choice of hardware signi= ng devices, local software and third-party cosigning services that would = all interoperate out of the box to enable easy multisig security, which i= n the BTC world subsumes the goals of 2=46A. --adam --54d15282_109cf92e_8c05 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline <html><head><style>body=7Bfont-family:Helvetica,Arial;font-size:13px=7D</= style></head><body style=3D=22word-wrap: break-word; -webkit-nbsp-mode: s= pace; -webkit-line-break: after-white-space;=22><div id=3D=22bloop=5Fcust= omfont=22 style=3D=22font-family:Helvetica,Arial;font-size:13px; color: r= gba(0,0,0,1.0); margin: 0px; line-height: auto;=22>Hi Adam - the conversa= tion was pretty open regarding the factor / channel used to sign at the b= ottom. No argument from me and I agree completely that hardened sin= gle purpose computers are more secure than desktop browsers, browser exte= nsions, SMS, or mobile apps when involved in multisig authorization. &nbs= p;The point below was that risks with other channels are far higher if au= th data is input from two channels through one, such as entering a 2=46A = phone token and desktop password into the same desktop browser session - = MITM phishing attack on websites that bypasses phone 2=46A as an example,= serendipitously timed yet tragic example of this scam with coinbase toda= y: <a href=3D=22https://www.reddit.com/r/Bitcoin/comments/2ungby/fuc= k=5Fi=5Fjust=5Fgot=5Fscammed/=22>https://www.reddit.com/r/Bitcoin/comment= s/2ungby/fuck=5Fi=5Fjust=5Fgot=5Fscammed/</a></div><div id=3D=22bloop=5Fc= ustomfont=22 style=3D=22font-family:Helvetica,Arial;font-size:13px; color= : rgba(0,0,0,1.0); margin: 0px; line-height: auto;=22><br></div><div id=3D= =22bloop=5Fcustomfont=22 style=3D=22font-family:Helvetica,Arial;font-size= :13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;=22>On the = topic of hardened single purpose computers, and I mean no offense to our = friends at Trezor, Case, or similar but I think the future of this type o= f security approach with bitcoin is extremely bright. It=E2=80=99s = just far more likely to involve chips integrated directly in PC / Mac mot= herboards and mobile devices / wearables where signing is done in the har= dware inaccessible to the OS or BIOS. This is a way for mainstream = users to use bitcoin securely, integrate it with apps running from popula= r OS=E2=80=99s and get bitcoin into the internet on a very granular level= , and Joe six pack and Sally soccer mom never even know they are using mu= ltisig. It took 20+ years for people to get used to cards vs. cash.= The telephone took 50 years to catch on and become cost competitiv= e. I think the key is making it invisible to the user.</div><div id=3D=22= bloop=5Fcustomfont=22 style=3D=22font-family:Helvetica,Arial;font-size:13= px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;=22><br></div>= <div style=3D=22color:black=22>=46rom: <span style=3D=22color:black=22= >Adam Weiss</span> <a href=3D=22mailto:adam=40signal11.com=22><adam=40= signal11.com></a><br>Reply: <span style=3D=22color:black=22>Adam = Weiss</span> <a href=3D=22mailto:adam=40signal11.com=22><adam=40signal= 11.com>></a><br>Date: <span style=3D=22color:black=22>=46ebrua= ry 3, 2015 at 12:25:20 PM</span><br>To: <span style=3D=22color:black= =22>Will</span> <a href=3D=22mailto:will.madden=40novauri.com=22><will= .madden=40novauri.com>></a><br>Cc: <span style=3D=22color:blac= k=22>bitcoin-development=40lists.sourceforge.net</span> <a href=3D=22mail= to:bitcoin-development=40lists.sourceforge.net=22><bitcoin-development= =40lists.sourceforge.net>></a><br>Subject: <span style=3D=22co= lor:black=22> Re: =5BBitcoin-development=5D Subject: Re: Proposal to addr= ess Bitcoin malware <br></span></div><br> <blockquote type=3D=22cite=22 c= lass=3D=22clean=5Fbq=22><span><div><div></div><div> <title></title> <div dir=3D=22ltr=22> <div class=3D=22gmail=5Fextra=22> <div class=3D=22gmail=5Fquote=22> <blockquote class=3D=22gmail=5Fquote=22 style=3D=22margin:0 0 0 .8ex;bord= er-left:1px =23ccc solid;padding-left:1ex=22> <div style=3D=22word-wrap:break-word=22> <div style=3D=22font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0= ,0,1.0);margin:0px;line-height:auto=22> <span style=3D=22font-family:'helvetica Neue',helvetica;line-height:19.5p= x=22><br></span></div> <div style=3D=22margin:0px=22><font face=3D=22helvetica Neue, helvetica=22= ><span style=3D=22line-height:19.5px=22>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. </span></font></div> </div> </blockquote> <div><br></div> <div>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=3F They'd have to get malware onto the signing device, which is the vector that a simplified signing device is specifically designed to mitigate.</div> <div><br></div> <div>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.</div> <div><br></div> <div>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 2=46A.</div> <div><br></div> <div>--adam<br></div> <div><br></div> </div> </div> </div> </div></div></span></blockquote></body></html> --54d15282_109cf92e_8c05--