[Bitcoin-development] Subject: Re: Proposal to address Bitcoin malware
constitutes collusion from a physical security standpoint. This is probably sufficient justification for not implementing such a model, especially given the cost and complexity of stealing and cracking a well-designed device. A device backup would provide comparable time to recover with far less complexity (and loss of privacy). Incidentally the hardware wallet idea breaks down once any aspect of the platform or network to which it connects must be trusted, so for these purposes I do not consider certain hybrid models as hardware wallets at all. For example one such device trusts that the compromised computer does not carry out a MITM attack between the signing device and a shared secret entered in parts over time by the user. This reduces to a single factor with no protection against a compromised platform. Of course these questions address integrity, not privacy. Use of a third party implies loss of privacy to that party, and with weak comsec to the network. Similarly, use of hardware signing devices implies loss of privacy to the compromised platforms with which they exchange transactions. e -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature -- Message: 3 Date: Mon, 2 Feb 2015 16:44:37 -0800 From: Pieter Wuille pieter.wui...@gmail.com Subject: Re: [Bitcoin-development] [softfork proposal] Strict DER signatures To: Gregory Maxwell gmaxw...@gmail.com Cc: Bitcoin Dev bitcoin-development@lists.sourceforge.net Message-ID: capg+sbjjylf4nz8ezk7ml_oo-e6c8_v1i12axejjrgp+wfb...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 On Sun, Jan 25, 2015 at 6:48 AM, Gregory Maxwell gmaxw...@gmail.com wrote: So I think we should just go ahead with R/S length upper bounds as both IsStandard and in STRICTDER. I would like to fix this at some point in any case. If we want to do that, we must at least have signatures with too-long R or S values as non-standard. One way to do that is to just - right now - add a patch to 0.10 to make those non-standard. This requires another validation flag, with a bunch of switching logic. The much simpler alternative is just adding this to BIP66's DERSIG right now, which is a one-line change that's obviously softforking. Is anyone opposed to doing so at this stage? -- Pieter -- Message: 4 Date: Tue, 3 Feb 2015 02:21:24 + From: Gregory Maxwell gmaxw...@gmail.com Subject: Re: [Bitcoin-development] [softfork proposal] Strict DER signatures To: Pieter Wuille pieter.wui...@gmail.com Cc: Bitcoin Dev bitcoin-development@lists.sourceforge.net Message-ID: CAAS2fgQKbsaU5f+UPp8z2nEgXOfNhsFJoY=2j76arxnbrsi...@mail.gmail.com Content-Type: text/plain; charset=UTF-8 On Tue, Feb 3, 2015 at 12:44 AM, Pieter Wuille pieter.wui...@gmail.com wrote: The much simpler alternative is just adding this to BIP66's DERSIG right now, which is a one-line change that's obviously softforking. Is anyone opposed to doing so at this stage? Thats my preference. -- Message: 5 Date: Mon, 02 Feb 2015 23:38:07 -0800 From: Eric Voskuil e...@voskuil.org Subject: Re: [Bitcoin-development] Proposal to address Bitcoin malware To: Brian Erdelyi brian.erde...@gmail.com Cc: Bitcoin Dev bitcoin-development@lists.sourceforge.net Message-ID: 54d07adf.8060...@voskuil.org Content-Type: text/plain; charset=utf-8 On 02/02/2015 11:58 AM, Brian Erdelyi wrote: Confusing or not, the reliance on multiple signatures as offering greater security than single relies on the independence of multiple secrets. If the secrets cannot be shown to retain independence in the envisioned threat scenario (e.g. a user's compromised operating system) then the benefit reduces to making the exploit more difficult to write, which, once written, reduces to no benefit. Yet the user still suffers the reduced utility arising from greater complexity, while being led to believe in a false promise. Just trying to make sure I understand what you?re saying. Are you eluding to that if two of the three private keys get compromised there is no gain in security? Although the likelihood of this occurring is lower, it is possible. No, that's not it. Sorry for not being clear. Independence of control is the central issue in the analysis of a multiple factor system. If an attack compromises one factor there must be no way for that attack to reduce the difficulty of obtaining the other factors. Some factors (secrets), like a fingerprint, aren't very secret at all. But getting someone's fingerprint doesn't also help the attacker get a PIN. That factor must be attacked independently. But if the PIN is encrypted with the fingerprint in a public store, then the PIN is not independent of the fingerprint and there is really only
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 -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Subject: Re: Proposal to address Bitcoin malware
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 a...@signal11.com Reply: Adam Weiss a...@signal11.com Date: February 3, 2015 at 12:25:20 PM To: Will will.mad...@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 -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Subject: Re: Proposal to address Bitcoin malware
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. Yes, X.509 is ... unfortunate. We'll have to wait and see how the TREZOR team get on with implementing it. TREZOR doesn't have any OS at all at the moment, so an implementation of PKIX will probably end up being larger than their existing codebase. That said, X.509 parsing is so security critical that the existing codebases for it are by now pretty robust. Touch wood. So just having a super stripped down OpenSSL implementation is probably good enough. W.R.T revocation, BIP70 doesn't support this. If your private key leaks you're currently hosed, identity wise, until the certificate expires. This is obviously suboptimal. In a world where we all have infinite time and resources the right fix will be to piggy back on an X.509 extension being proposed in the browser world called Must Staple. It's a bit in the certificate flags that tell the client to expect a stapled OCSP response and to hard-fail if none is provided. By requesting the CA set this flag when you get your certificate issued, you sign up for more pain but more security. An OCSP stapling extension to BIP70 would probably not be very hard to implement, but it'd be pointless today because the client has no idea whether to expect it or not. The absence of a certificate changes the UI by showing you a random Bitcoin address instead of a human readable name, but the absence of stapled OCSP would not result in any UI change. Regardless, I think a standard for passing partially signed transactions around might make sense I'm hoping that the hardware wallet world just standardises on the TREZOR protocol. It's well designed and these devices all have fairly similar capabilities. -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Subject: Re: Proposal to address Bitcoin malware
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. I think a standard for passing partially signed transactions is a great idea as well. This would support interoperability of wallets/clients and third-party services (if users choose to use them). Brian Erdelyi -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Subject: Re: Proposal to address Bitcoin malware
, then sends the transaction to a third party for a second of three signatures, and finally to a second platform for user verification, a HW thief needs to collude with the third party or the second platform before the owner becomes aware of the theft (notifying the third party). This of course implies that keeping both the fist and second platforms in close proximity constitutes collusion from a physical security standpoint. This is probably sufficient justification for not implementing such a model, especially given the cost and complexity of stealing and cracking a well-designed device. A device backup would provide comparable time to recover with far less complexity (and loss of privacy). Incidentally the hardware wallet idea breaks down once any aspect of the platform or network to which it connects must be trusted, so for these purposes I do not consider certain hybrid models as hardware wallets at all. For example one such device trusts that the compromised computer does not carry out a MITM attack between the signing device and a shared secret entered in parts over time by the user. This reduces to a single factor with no protection against a compromised platform. Of course these questions address integrity, not privacy. Use of a third party implies loss of privacy to that party, and with weak comsec to the network. Similarly, use of hardware signing devices implies loss of privacy to the compromised platforms with which they exchange transactions. e -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature -- Message: 3 Date: Mon, 2 Feb 2015 http://airmail.calendar/2015-02-02%2012:00:00%20MST 16:44:37 -0800 http://airmail.calendar/2015-02-03%2017:44:37%20MST From: Pieter Wuille pieter.wui...@gmail.com mailto:pieter.wui...@gmail.com Subject: Re: [Bitcoin-development] [softfork proposal] Strict DER signatures To: Gregory Maxwell gmaxw...@gmail.com mailto:gmaxw...@gmail.com Cc: Bitcoin Dev bitcoin-development@lists.sourceforge.net mailto:bitcoin-development@lists.sourceforge.net Message-ID: capg+sbjjylf4nz8ezk7ml_oo-e6c8_v1i12axejjrgp+wfb...@mail.gmail.com mailto:capg+sbjjylf4nz8ezk7ml_oo-e6c8_v1i12axejjrgp+wfb...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 On Sun, Jan 25, 2015 at 6:48 AM, Gregory Maxwell gmaxw...@gmail.com mailto:gmaxw...@gmail.com wrote: So I think we should just go ahead with R/S length upper bounds as both IsStandard and in STRICTDER. I would like to fix this at some point in any case. If we want to do that, we must at least have signatures with too-long R or S values as non-standard. One way to do that is to just - right now - add a patch to 0.10 to make those non-standard. This requires another validation flag, with a bunch of switching logic. The much simpler alternative is just adding this to BIP66's DERSIG right now, which is a one-line change that's obviously softforking. Is anyone opposed to doing so at this stage? -- Pieter -- Message: 4 Date: Tue, 3 Feb 2015 02:21:24 + http://airmail.calendar/2015-02-02%2019:21:24%20MST From: Gregory Maxwell gmaxw...@gmail.com mailto:gmaxw...@gmail.com Subject: Re: [Bitcoin-development] [softfork proposal] Strict DER signatures To: Pieter Wuille pieter.wui...@gmail.com mailto:pieter.wui...@gmail.com Cc: Bitcoin Dev bitcoin-development@lists.sourceforge.net mailto:bitcoin-development@lists.sourceforge.net Message-ID: CAAS2fgQKbsaU5f+UPp8z2nEgXOfNhsFJoY=2j76arxnbrsi...@mail.gmail.com mailto:CAAS2fgQKbsaU5f+UPp8z2nEgXOfNhsFJoY=2j76arxnbrsi...@mail.gmail.com Content-Type: text/plain; charset=UTF-8 On Tue, Feb 3, 2015 at 12:44 AM, Pieter Wuille pieter.wui...@gmail.com mailto:pieter.wui...@gmail.com wrote: The much simpler alternative is just adding this to BIP66's DERSIG right now, which is a one-line change that's obviously softforking. Is anyone opposed to doing so at this stage? Thats my preference. -- Message: 5 Date: Mon, 02 Feb 2015 http://airmail.calendar/2015-02-02%2012:00:00%20MST 23:38:07 -0800 http://airmail.calendar/2015-02-04%2000:38:07%20MST From: Eric Voskuil e...@voskuil.org mailto:e...@voskuil.org Subject: Re: [Bitcoin-development] Proposal to address Bitcoin malware To: Brian Erdelyi brian.erde...@gmail.com mailto:brian.erde...@gmail.com Cc: Bitcoin Dev bitcoin-development@lists.sourceforge.net mailto:bitcoin-development@lists.sourceforge.net Message-ID: 54d07adf.8060...@voskuil.org mailto:54d07adf.8060...@voskuil.org Content-Type: text/plain; charset=utf-8 On 02/02/2015 11:58 AM, Brian Erdelyi wrote: Confusing or not, the reliance on multiple signatures as offering greater security than single
