* [Bitcoin-development] Subject: Re: Proposal to address Bitcoin malware
@ 2015-02-03 12:04 Will
2015-02-03 19:25 ` Adam Weiss
2015-02-04 1:03 ` Eric Voskuil
0 siblings, 2 replies; 6+ messages in thread
From: Will @ 2015-02-03 12:04 UTC (permalink / raw)
To: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 18586 bytes --]
An idea for the bitcoin malware proposal below, the idea is at the bottom…
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. This is the same as how MITM defeats 2FA via mobile phone if the token is entered into the same website as the password - the token is simply passed through by the attacker to the secure session with the provider, allowing unfettered access or reuse of tokens for transactions other than those intended by the real user.
Companies have found clever ways around MITM attacks using SSL sniff and derivatives by embedding code in mobile apps that communicate not with the website authenticating the user, but with 3rd party company that authenticates the token and passes the authentication to the website through a different secure channel, making the MITM attack far much more difficult. The trick here is that instead of one channel, we now have two channels that must be compromised. Also, the second channel is between a security company and a (hopefully) professionally run financial services website. There are other approaches to defeat MITM, such as fingerprinting pages to detect spoofs. The former (secure 3rd party channel) is very secure but requires a trusted third party. The latter (fingerprinting) is a crap shoot with very high false positive rates.
Anyway, the exact same principles apply here to this conversation. The second signature must be presented from a separate band to maintain a higher degree of security. If one signature occurs via HTTP(s) from application 1, another should be SMS through a carrier network, etc via application 2.
The trick we need to look at is how to use the bitcoin network as a delivery mechanism to bypass the need for the trusted third party in the example above. Instead of the second factor routing through a 3rd party to the intended recipient, we have another option - one that doesn’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 sign signature - not through the site in 1 (similar to the 2nd channel between the website and security company above)
3) Sender > signs signature 2 via mobile app (or any separate device operating on a different network - heck could be radio) > 2/3 signatures, transaction authorized
Any wallet service provider can use this model, all they must do is develop two independent applications such a secure browser plugin and a website, or a mobile app and a website that use 2/3 multisig to authorize transactions. No core development required - just better security design and execution by those developing wallets. If the protocol could natively communicate via two separate networks, that might be something to consider, but really developers should already have all the tools they need, assuming they are competent.
If there was a way to perform 2/3 multisig without requiring a second band, performing the function safely by somehow knowing if the service is performed from a compromised device through some sort of on-blockchain anti-malware check by validating the signature of the signing application by comparing it to a signature recorded when the multisig address was funded, that would be a really neat breakthrough. Food for thought, but I can’t see how that could be executed in a way where signatures couldn’t be spoofed from a compromised device. If someone cracks that problem, it’s a really big advance for information security.
On 02/02/2015 02:54 PM, Eric Voskuil wrote:
> On Feb 2, 2015, at 11:53 AM, Mike Hearn wrote:
>>
>> In sending the first-signed transaction to another for second
>> signature, how does the first signer authenticate to the second
>> without compromising the independence of the two factors?
>>
>> Not sure what you mean. The idea is the second factor displays the
>> transaction and the user confirms it matches what they input to the
>> first factor. Ideally, using BIP70, but I don't know if BA actually
>> uses that currently.
>>
>> It's the same model as the TREZOR, except with a desktop app instead
>> of myTREZOR and a phone instead of a dedicated hardware device.
>
> Sorry for the slow reply, traveling.
>
> My comments were made in reference to this proposal:
>
>>> On Feb 2, 2015, at 10:40 AM, Brian Erdelyi <brian.erdelyi@gmail•com
>>> <mailto:brian.erdelyi@gmail•com>> wrote:
>>>
>>> Another concept...
>>>
>>> It should be possible to use multisig wallets to protect against
>>> malware. For example, a user could generate a wallet with 3 keys and
>>> require a transaction that has been signed by 2 of those keys. One
>>> key is placed in cold storage and anther sent to a third-party.
>>>
>>> It is now possible to generate and sign transactions on the users
>>> computer and send this signed transaction to the third-party for the
>>> second signature. This now permits the use of out of band transaction
>>> verification techniques before the third party signs the transaction
>>> and sends to the blockchain.
>>>
>>> If the third-party is malicious or becomes compromised they would not
>>> have the ability to complete transactions as they only have one
>>> private key. If the third-party disappeared, the user could use the
>>> key in cold storage to sign transactions and send funds to a new wallet.
>>>
>>> Thoughts?
My comments below start out with the presumption of user platform
compromise, but the same analysis holds for the case where the user
platform is clean but a web wallet is compromised. Obviously the idea is
that either or both may be compromised, but integrity is retained as
long as both are not compromised and in collusion.
> In the multisig scenario the presumption is of a user platform
> compromised by malware. It envisions a user signing a 2 of 3 output with
> a first signature. The precondition that the platform is compromised
> implies that this process results in a loss of integrity of the private
> key, and as such if it were not for the second signature requirement,
> the malware would be able to spend the output. This may be extended to
> all of the keys in the wallet.
>
> The scenario envisions sending the signed transaction to an another
> ("third") party. The objective is for the third party to provide the
> second signature, thereby spending the output as intended by the user,
> who is not necessarily the first signer. The send must be authenticated
> to the user. Otherwise the third party would have to sign anything it
> received, obviously rendering the second signature pointless. This
> implies that the compromised platform must transmit a secret, or proof
> of a secret, to the third party.
>
> The problem is that the two secrets are not independent if the first
> platform is compromised. So of course the malware has the ability to
> sign, impersonate the user and send to the third party. So the third
> party *must* send the transaction to an *independent* platform for
> verification by the user, and obtain consent before adding the second
> signature. The user, upon receiving the transaction details, must be
> able to verify, on the independent platform, that the details match
> those of the transaction that user presumably signed. Even for simple
> transactions this must include amount, address and fees.
>
> The central assumptions are that, while the second user platform may be
> compromised, the attack against the second platform is not coordinated
> with that of the first, nor is the third party in collusion with the
> first platform.
>
> Upon these assumptions rests the actual security benefit (increased
> difficulty of the coordinated attack). The strength of these assumptions
> is an interesting question, since it is hard to quantify. But without
> independence the entire security model is destroyed and there is thus no
> protection whatsoever against malware.
>
> So for example a web-based or other third-party-provisioned
> implementation of the first platform breaks the anti-collusion
> assumption. Also, weak comsec allows an attack against the second
> platform to be carried out against its network. So for example a simple
> SMS-based confirmation could be executed by the first platform alone and
> thereby also break the the anti-collusion assumption. This is why I
> asked how independence is maintained.
>
> The assumption of a hardware wallet scenario is that the device itself
> is not compromised. So the scenario is not the same. If the user signs
> with a hardware wallet, nothing can collude with that process, with one
> caveat.
>
> While a hardware wallet is not subject to onboard malware, it is not
> inconceivable that its keys could be extracted through probing or other
> direct attack against the hardware. It's nevertheless an assumption of
> hardware wallets that these attacks require loss of the hardware.
> Physical possession constitutes compromise. So the collusion model with
> a hardware wallet does exist, it just requires device possession.
> Depending on the implementation the extraction may require a non-trivial
> amount of time and money.
>
> In a scenario where the user signs with HW, 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 16:44:37 -0800
From: Pieter Wuille <pieter.wuille@gmail•com>
Subject: Re: [Bitcoin-development] [softfork proposal] Strict DER
signatures
To: Gregory Maxwell <gmaxwell@gmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Message-ID:
<CAPg+sBjjYLf4NZ8ezK7ML_OO-e6C8_V1i12AXejjrgp+wFB-pg@mail•gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Sun, Jan 25, 2015 at 6:48 AM, Gregory Maxwell <gmaxwell@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 +0000
From: Gregory Maxwell <gmaxwell@gmail•com>
Subject: Re: [Bitcoin-development] [softfork proposal] Strict DER
signatures
To: Pieter Wuille <pieter.wuille@gmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Message-ID:
<CAAS2fgQKbsaU5f+UPp8z2nEgXOfNhsFJoY=2j76ArXnBRsiV6g@mail•gmail.com>
Content-Type: text/plain; charset=UTF-8
On Tue, Feb 3, 2015 at 12:44 AM, Pieter Wuille <pieter.wuille@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 <eric@voskuil•org>
Subject: Re: [Bitcoin-development] Proposal to address Bitcoin malware
To: Brian Erdelyi <brian.erdelyi@gmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Message-ID: <54D07ADF.8060809@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 one secret.
If multiple factors are coincident (located within the same security
perimeter) they are compromized coincidentally. Coincidence has the same
effect as dependence. Consider a credit card with a "security code"
printed on the back. A successful attack on the leather wallet yields
both secrets.
Individual environments can be compromised with some difficulty (e.g.
desktop malware, fingerprint lift, dictionary attack, brute force PIN,
etc.). For the sake of simplicity, let that chance of successful
independent attack on any factor be 1 in 2 and the resulting probability
of successful concurrent attack on any n factors be 1 in 2^n. If m
factors are dependent/coincident on others the relation becomes 1 in
2^(n-m).
Any multi-factor web wallet that handles the user's keys in the browser
and authenticates the user in the browser to authorize service signing
is effectively single factor. One attack may be launched by an insider,
or externally, against the web app, executing in the browser, gaining
coincident access to two secrets. Browser/desktop malware can accomplish
the same. The difficulty is 1 in 2 vs. the expected 1 in 4.
>As more malware targets bitcoins I think the utility is evident.
>Given how final Bitcoin transactions are, I think it?s worth trying to
>find methods to help verify those transactions (if a user deems it to
>be high-risk enough) before the transaction is completed. The balance
>is trying to devise something that users do not find too burdensome.
I'm not questioning the motive, I agree it's worth trying. But trying is
not succeeding. Increasing user (and/or system) complexity without
increasing integrity or privacy is a poor trade, and worse if the user
is misled.
e
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
------------------------------
------------------------------------------------------------------------------
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
End of Bitcoin-development Digest, Vol 45, Issue 11
***************************************************
[-- Attachment #2: Type: text/html, Size: 72505 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Bitcoin-development] Subject: Re: Proposal to address Bitcoin malware
2015-02-03 12:04 [Bitcoin-development] Subject: Re: Proposal to address Bitcoin malware Will
@ 2015-02-03 19:25 ` Adam Weiss
2015-02-03 20:09 ` Brian Erdelyi
` (2 more replies)
2015-02-04 1:03 ` Eric Voskuil
1 sibling, 3 replies; 6+ messages in thread
From: Adam Weiss @ 2015-02-03 19:25 UTC (permalink / raw)
To: Will; +Cc: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 1742 bytes --]
>
>
> 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: 2419 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Bitcoin-development] Subject: Re: Proposal to address Bitcoin malware
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
2 siblings, 0 replies; 6+ messages in thread
From: Brian Erdelyi @ 2015-02-03 20:09 UTC (permalink / raw)
To: Adam Weiss; +Cc: Bitcoin Dev
> 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Bitcoin-development] Subject: Re: Proposal to address Bitcoin malware
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
2 siblings, 0 replies; 6+ messages in thread
From: Mike Hearn @ 2015-02-03 21:01 UTC (permalink / raw)
To: Adam Weiss; +Cc: Bitcoin Dev, Will
[-- Attachment #1: Type: text/plain, Size: 1997 bytes --]
>
> 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.
[-- Attachment #2: Type: text/html, Size: 2656 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Bitcoin-development] Subject: Re: Proposal to address Bitcoin malware
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
2 siblings, 0 replies; 6+ messages in thread
From: Will @ 2015-02-03 22:58 UTC (permalink / raw)
To: Adam Weiss; +Cc: bitcoin-development
[-- 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 --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Bitcoin-development] Subject: Re: Proposal to address Bitcoin malware
2015-02-03 12:04 [Bitcoin-development] Subject: Re: Proposal to address Bitcoin malware Will
2015-02-03 19:25 ` Adam Weiss
@ 2015-02-04 1:03 ` Eric Voskuil
1 sibling, 0 replies; 6+ messages in thread
From: Eric Voskuil @ 2015-02-04 1:03 UTC (permalink / raw)
To: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 20886 bytes --]
On 02/03/2015 04:04 AM, Will wrote:
> An idea for the bitcoin malware proposal below, the idea is at the bottom…
> ...
> The trick we need to look at is how to use the bitcoin network as a
> delivery mechanism to bypass the need for the trusted third party in the
> example above.
Using the Bitcoin network would be a convenience, certainly not a
requirement. Any public store (or other channel accessible to all
signers) would do.
> Instead of the second factor routing through a 3rd party
> to the intended recipient, we have another option - one that doesn’t
> require core development either.
Absolutely, there is no need for a trusted third party in the case of
MFA unless that party has independent judgement in the decision to sign.
For example, if the third party is the trustee of a fund from which a
beneficiary wants to withdraw.
If you are just routing a decision back to yourself a third party makes
no sense. Oddly most of the services in operation today are doing just
that. You will end up authenticating to the third party from a platform
you control, which means that the platform must be trusted as much as
the third party. Why not just trust the platform and no third party? It
doesn't reduce the number of factors but it certainly reduces the attack
surface.
> 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
> sign signature - not through the site in 1 (similar to the 2nd channel
> between the website and security company above)
> 3) Sender > signs signature 2 via mobile app (or any separate
> device operating on a different network - heck could be radio) > 2/3
> signatures, transaction authorized
There's no need for the devices to be on independent networks. You can
safely remove that constraint. The partially-signed transaction can be
encrypted to the other signatories (for privacy) or it can be sent in
the clear. And ultimately all platforms in the scheme are connected to
the Internet, even if it's via sneakernet.
The important requirement is that the signing platforms are independent
and that the signers inspect the transactions on those platforms. This
preserves the benefit of MFA, which is that the signing platforms must
be compromised independently.
> ...
> If there was a way to perform 2/3 multisig without requiring a second
> band, performing the function safely by somehow knowing if the service
> is performed from a compromised device through some sort of
> on-blockchain anti-malware check by validating the signature of the
> signing application by comparing it to a signature recorded when the
> multisig address was funded, that would be a really neat breakthrough.
> Food for thought, but I can’t see how that could be executed in a way
> where signatures couldn’t be spoofed from a compromised device. If
> someone cracks that problem, it’s a really big advance for information
> security.
Once you've done this you are talking about two independent signing
platforms. Plug two trustworthy signing devices into a PC and you've
done it. This is because the host environment (the PC in this case) is
not trusted in the first place. Two untrusted environments are no better
than one. It's only if the environments are trusted that they must be
independent.
But therein lies the problem. The physical proximity of two trusted
hardware devices exposes them to a single attack in the case of physical
theft or loss. So to guard against that threat the devices must be
independently stored. This presents a problem when it comes to usage.
This is the central problem of MFA. It's not possible to control
multiple factors while not exposing them to compromise. This is true
whether we are talking about multiple physical devices or a remote
service, since in the remote case the secret must still be accessible to
the person in control.
In the case of truly independent decisions MFA is strongest. But short
of that there's no reason for a remote third party. One can probably
accept the risk of securing multiple devices with the home, etc - and
needs to do this even if using a third party. On the other hand, walking
around with all necessary factors, or keeping them in the same safe, is
tantamount to having just one factor.
e
> On 02/02/2015 02:54 PM, Eric Voskuil wrote:
>> On Feb 2, 2015, at 11:53 AM
> <http://airmail.calendar/2015-02-02%2011:53:00%20MST>, Mike Hearn wrote:
>>>
>>> In sending the first-signed transaction to another for second
>>> signature, how does the first signer authenticate to the second
>>> without compromising the independence of the two factors?
>>>
>>> Not sure what you mean. The idea is the second factor displays the
>>> transaction and the user confirms it matches what they input to the
>>> first factor. Ideally, using BIP70, but I don't know if BA actually
>>> uses that currently.
>>>
>>> It's the same model as the TREZOR, except with a desktop app instead
>>> of myTREZOR and a phone instead of a dedicated hardware device.
>>
>> Sorry for the slow reply, traveling.
>>
>> My comments were made in reference to this proposal:
>>
>>>> On Feb 2, 2015, at 10:40 AM
> <http://airmail.calendar/2015-02-02%2010:40:00%20MST>, Brian Erdelyi
> <brian.erdelyi@gmail•com <mailto:brian.erdelyi@gmail•com>
>>>> <mailto:brian.erdelyi@gmail•com>> wrote:
>>>>
>>>> Another concept...
>>>>
>>>> It should be possible to use multisig wallets to protect against
>>>> malware. For example, a user could generate a wallet with 3 keys and
>>>> require a transaction that has been signed by 2 of those keys. One
>>>> key is placed in cold storage and anther sent to a third-party.
>>>>
>>>> It is now possible to generate and sign transactions on the users
>>>> computer and send this signed transaction to the third-party for the
>>>> second signature. This now permits the use of out of band transaction
>>>> verification techniques before the third party signs the transaction
>>>> and sends to the blockchain.
>>>>
>>>> If the third-party is malicious or becomes compromised they would not
>>>> have the ability to complete transactions as they only have one
>>>> private key. If the third-party disappeared, the user could use the
>>>> key in cold storage to sign transactions and send funds to a new wallet.
>>>>
>>>> Thoughts?
>
> My comments below start out with the presumption of user platform
> compromise, but the same analysis holds for the case where the user
> platform is clean but a web wallet is compromised. Obviously the idea is
> that either or both may be compromised, but integrity is retained as
> long as both are not compromised and in collusion.
>
>> In the multisig scenario the presumption is of a user platform
>> compromised by malware. It envisions a user signing a 2 of 3 output with
>> a first signature. The precondition that the platform is compromised
>> implies that this process results in a loss of integrity of the private
>> key, and as such if it were not for the second signature requirement,
>> the malware would be able to spend the output. This may be extended to
>> all of the keys in the wallet.
>>
>> The scenario envisions sending the signed transaction to an another
>> ("third") party. The objective is for the third party to provide the
>> second signature, thereby spending the output as intended by the user,
>> who is not necessarily the first signer. The send must be authenticated
>> to the user. Otherwise the third party would have to sign anything it
>> received, obviously rendering the second signature pointless. This
>> implies that the compromised platform must transmit a secret, or proof
>> of a secret, to the third party.
>>
>> The problem is that the two secrets are not independent if the first
>> platform is compromised. So of course the malware has the ability to
>> sign, impersonate the user and send to the third party. So the third
>> party *must* send the transaction to an *independent* platform for
>> verification by the user, and obtain consent before adding the second
>> signature. The user, upon receiving the transaction details, must be
>> able to verify, on the independent platform, that the details match
>> those of the transaction that user presumably signed. Even for simple
>> transactions this must include amount, address and fees.
>>
>> The central assumptions are that, while the second user platform may be
>> compromised, the attack against the second platform is not coordinated
>> with that of the first, nor is the third party in collusion with the
>> first platform.
>>
>> Upon these assumptions rests the actual security benefit (increased
>> difficulty of the coordinated attack). The strength of these assumptions
>> is an interesting question, since it is hard to quantify. But without
>> independence the entire security model is destroyed and there is thus no
>> protection whatsoever against malware.
>>
>> So for example a web-based or other third-party-provisioned
>> implementation of the first platform breaks the anti-collusion
>> assumption. Also, weak comsec allows an attack against the second
>> platform to be carried out against its network. So for example a simple
>> SMS-based confirmation could be executed by the first platform alone and
>> thereby also break the the anti-collusion assumption. This is why I
>> asked how independence is maintained.
>>
>> The assumption of a hardware wallet scenario is that the device itself
>> is not compromised. So the scenario is not the same. If the user signs
>> with a hardware wallet, nothing can collude with that process, with one
>> caveat.
>>
>> While a hardware wallet is not subject to onboard malware, it is not
>> inconceivable that its keys could be extracted through probing or other
>> direct attack against the hardware. It's nevertheless an assumption of
>> hardware wallets that these attacks require loss of the hardware.
>> Physical possession constitutes compromise. So the collusion model with
>> a hardware wallet does exist, it just requires device possession.
>> Depending on the implementation the extraction may require a non-trivial
>> amount of time and money.
>>
>> In a scenario where the user signs with HW, 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.wuille@gmail•com
> <mailto:pieter.wuille@gmail•com>>
> Subject: Re: [Bitcoin-development] [softfork proposal] Strict DER
> signatures
> To: Gregory Maxwell <gmaxwell@gmail•com <mailto:gmaxwell@gmail•com>>
> Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net
> <mailto:bitcoin-development@lists•sourceforge.net>>
> Message-ID:
> <CAPg+sBjjYLf4NZ8ezK7ML_OO-e6C8_V1i12AXejjrgp+wFB-pg@mail•gmail.com
> <mailto:CAPg+sBjjYLf4NZ8ezK7ML_OO-e6C8_V1i12AXejjrgp+wFB-pg@mail•gmail.com>>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Sun, Jan 25, 2015 at 6:48 AM, Gregory Maxwell <gmaxwell@gmail•com
> <mailto:gmaxwell@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 +0000
> <http://airmail.calendar/2015-02-02%2019:21:24%20MST>
> From: Gregory Maxwell <gmaxwell@gmail•com <mailto:gmaxwell@gmail•com>>
> Subject: Re: [Bitcoin-development] [softfork proposal] Strict DER
> signatures
> To: Pieter Wuille <pieter.wuille@gmail•com
> <mailto:pieter.wuille@gmail•com>>
> Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net
> <mailto:bitcoin-development@lists•sourceforge.net>>
> Message-ID:
> <CAAS2fgQKbsaU5f+UPp8z2nEgXOfNhsFJoY=2j76ArXnBRsiV6g@mail•gmail.com
> <mailto:CAAS2fgQKbsaU5f+UPp8z2nEgXOfNhsFJoY=2j76ArXnBRsiV6g@mail•gmail.com>>
> Content-Type: text/plain; charset=UTF-8
>
> On Tue, Feb 3, 2015 at 12:44 AM, Pieter Wuille <pieter.wuille@gmail•com
> <mailto:pieter.wuille@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 <eric@voskuil•org <mailto:eric@voskuil•org>>
> Subject: Re: [Bitcoin-development] Proposal to address Bitcoin malware
> To: Brian Erdelyi <brian.erdelyi@gmail•com
> <mailto:brian.erdelyi@gmail•com>>
> Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net
> <mailto:bitcoin-development@lists•sourceforge.net>>
> Message-ID: <54D07ADF.8060809@voskuil•org
> <mailto:54D07ADF.8060809@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 one secret.
>
> If multiple factors are coincident (located within the same security
> perimeter) they are compromized coincidentally. Coincidence has the same
> effect as dependence. Consider a credit card with a "security code"
> printed on the back. A successful attack on the leather wallet yields
> both secrets.
>
> Individual environments can be compromised with some difficulty (e.g.
> desktop malware, fingerprint lift, dictionary attack, brute force PIN,
> etc.). For the sake of simplicity, let that chance of successful
> independent attack on any factor be 1 in 2 and the resulting probability
> of successful concurrent attack on any n factors be 1 in 2^n. If m
> factors are dependent/coincident on others the relation becomes 1 in
> 2^(n-m).
>
> Any multi-factor web wallet that handles the user's keys in the browser
> and authenticates the user in the browser to authorize service signing
> is effectively single factor. One attack may be launched by an insider,
> or externally, against the web app, executing in the browser, gaining
> coincident access to two secrets. Browser/desktop malware can accomplish
> the same. The difficulty is 1 in 2 vs. the expected 1 in 4.
>
>>As more malware targets bitcoins I think the utility is evident.
>>Given how final Bitcoin transactions are, I think it?s worth trying to
>>find methods to help verify those transactions (if a user deems it to
>>be high-risk enough) before the transaction is completed. The balance
>>is trying to devise something that users do not find too burdensome.
>
> I'm not questioning the motive, I agree it's worth trying. But trying is
> not succeeding. Increasing user (and/or system) complexity without
> increasing integrity or privacy is a poor trade, and worse if the user
> is misled.
>
> e
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 473 bytes
> Desc: OpenPGP digital signature
>
> ------------------------------
>
> ------------------------------------------------------------------------------
> 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
> <mailto:Bitcoin-development@lists•sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
> End of Bitcoin-development Digest, Vol 45, Issue 11
> ***************************************************
>
>
>
>
> ------------------------------------------------------------------------------
> 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
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2015-02-04 1:03 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-02-03 12:04 [Bitcoin-development] Subject: Re: Proposal to address Bitcoin malware 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
2015-02-04 1:03 ` Eric Voskuil
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox