From: Will <will.madden@novauri•com>
To: Adam Weiss <adam@signal11•com>
Cc: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Subject: Re: Proposal to address Bitcoin malware
Date: Tue, 3 Feb 2015 15:58:10 -0700 [thread overview]
Message-ID: <etPan.54d15282.3352255a.8c05@Williams-MBP> (raw)
In-Reply-To: <CAFVoEQQHVcY0Ad-4c2wnH+WF_7M-o5SNwVr-nce_9bQ794cwDQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3675 bytes --]
Hi Adam - the conversation was pretty open regarding the factor / channel used to sign at the bottom. No argument from me and I agree completely that hardened single purpose computers are more secure than desktop browsers, browser extensions, SMS, or mobile apps when involved in multisig authorization. The point below was that risks with other channels are far higher if auth data is input from two channels through one, such as entering a 2FA phone token and desktop password into the same desktop browser session - MITM phishing attack on websites that bypasses phone 2FA as an example, serendipitously timed yet tragic example of this scam with coinbase today: https://www.reddit.com/r/Bitcoin/comments/2ungby/fuck_i_just_got_scammed/
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. It’s just far more likely to involve chips integrated directly in PC / Mac motherboards and mobile devices / wearables where signing is done in the hardware inaccessible to the OS or BIOS. This is a way for mainstream users to use bitcoin securely, integrate it with apps running from popular OS’s 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 multisig. It took 20+ years for people to get used to cards vs. cash. The telephone took 50 years to catch on and become cost competitive. I think the key is making it invisible to the user.
From: Adam Weiss <adam@signal11•com>
Reply: Adam Weiss <adam@signal11•com>>
Date: February 3, 2015 at 12:25:20 PM
To: Will <will.madden@novauri•com>>
Cc: bitcoin-development@lists•sourceforge.net <bitcoin-development@lists•sourceforge.net>>
Subject: Re: [Bitcoin-development] Subject: Re: Proposal to address Bitcoin malware
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
[-- Attachment #2: Type: text/html, Size: 5939 bytes --]
next prev parent reply other threads:[~2015-02-03 22:58 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-03 12:04 Will
2015-02-03 19:25 ` Adam Weiss
2015-02-03 20:09 ` Brian Erdelyi
2015-02-03 21:01 ` Mike Hearn
2015-02-03 22:58 ` Will [this message]
2015-02-04 1:03 ` Eric Voskuil
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=etPan.54d15282.3352255a.8c05@Williams-MBP \
--to=will.madden@novauri$(echo .)com \
--cc=adam@signal11$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox