[HN Gopher] Efficient blockchain architecture based on FIDO keys
___________________________________________________________________
Efficient blockchain architecture based on FIDO keys
Author : dandanua
Score : 47 points
Date : 2021-02-21 15:36 UTC (7 hours ago)
(HTM) web link (dandanua.github.io)
(TXT) w3m dump (dandanua.github.io)
| dieortin wrote:
| I find this a really interesting take. Wouldn't someone be able
| to produce his own FIDO key that can send two transactions with
| the same sequence number though?
| dandanua wrote:
| Yes, there should be a defense against device simulations. For
| example, a manufacturer can insert its root private key in the
| devices and use it for additional signing.
| spiorf wrote:
| So the manufacturer must have the private keys copied onto
| every device, so that key must be present and cleartext on
| every production line.
|
| And at the same time it must prevent leaking of such key.
|
| Not to mention that leaking of such key could happen from the
| hardware too.
| Kaknut wrote:
| What about in case key is lost or misplaced?
| cryptica wrote:
| > But we can assume that manufacturer has no incentives to make
| incorrect devices to harm the network.
|
| Whenever I hear about ideas to use hardware to ensure that some
| fact about the real world is accurate or to act as some kind of
| incorruptible source of truth, I just have to roll my eyes.
|
| It's wishful thinking to suggest that the manufacturer has
| absolutely no incentives to make incorrect devices to harm the
| network... Kind of like how the reserve bank has no incentives to
| print money and give their rich friends priority access to the
| new money... That doesn't harm society right? All my rich friends
| certainly agree!
|
| Once you get hardware involved, it forces people to trust a
| centralized entity even more than a pure software solution since
| the complexity and capital barriers go up.
|
| Besides, I don't even see how the hardware-generated ID solves
| the problem regarding the transaction order... There is still no
| guarantee that the transaction with the lowest ID will reach all
| the nodes before the one with the higher ID due to unpredictable
| network latency during the propagation... What if that lower ID
| transaction gets lost entirely? Will that account be locked
| forever (since the ID only increments) - How to recover from the
| situation where there are gaps between IDs? You would need to
| timebox it to decide how long to wait before we allow skipping a
| specific ID... How about we make one of the nodes decide when the
| time slot ends and maybe call that a 'block'? Wait, that already
| exists, it's called plain old blockchain.
| dandanua wrote:
| The hardware signing is not enough for transaction to be
| accepted. User signing is also required. You need two
| signatures, that are linked to each other.
|
| As for IDs, this is the right question :)
|
| You are not allowed to have gaps in transactions counter. You
| have to submit all of them to the network. Sure, you can have
| some transmission failure due to broken connection or computer
| failure. For such case a device can have memory of signed
| transactions (at least recent ones) and re-transmit them until
| they reach the network.
| [deleted]
| dgellow wrote:
| > I don't believe it's possible to find an efficient consensus
| algorithm, which would be truly decentralized
|
| Unless I misunderstand the meaning of "truly" decetnralized,
| there is one known. It's called Ouroboros, it's being used by
| both Polkadot and Cardano. It's a decentralized Proof-of-Stake
| protocol (currently ~80% of Cardano block generation is
| decentralized, the goal is to reach 100% in March).
|
| The 2019 paper: https://eprint.iacr.org/2016/889.pdf
|
| (Edit: the article is still an interesting read, thanks for
| sharing)
| Taek wrote:
| If the reward is being able to print money for yourself (that's
| what a double spend does), there will be very strong incentives
| to research a way to taper with a FIDO device and keep the
| results private.
|
| This threat model would not survive the real world even at low
| adoption rates.
| dandanua wrote:
| The threat model is heavily based on tamper-resistance of the
| devices. But I don't think it can't survive.
|
| Also, tampering the device can ruin the network, but it can't
| print new money.
| spiorf wrote:
| Who prints new money?
| dandanua wrote:
| This question is open for invention. A blockchain can have
| no money at all. People can just play games on it and
| everyone will agree on the objective history of all games
| played.
|
| For example, you can assume that there is a fixed amount of
| money initially distributed somehow (many cryptocurrencies
| do just that).
| neatze wrote:
| What happens if you lose FIDO key or key was destroyed in fire ?
| dandanua wrote:
| You can register another hardware key with your personal
| (software) key. It's mentioned in the article.
| blamestross wrote:
| How do you keep people from simulating a fido key? There is
| intrinsically no way to detect if the hardware signature was
| actually done by hardware.
| dandanua wrote:
| FIDO has a device attestation
| https://developers.yubico.com/U2F/Attestation_and_Metadata/ But
| their scheme indeed looks like flawed.
|
| There is a way to make it correct, though. Device manufacturer
| also has to inject its own root private key into the device. So
| the device will use additional, third signature on behalf of
| manufacturer.
| infofarmer wrote:
| Why do you feel there's a flaw? The <<root>> key signs the
| batch keypair. It's a normal certificate chain.
| dandanua wrote:
| According to this [1], keypairs are generated randomly on a
| registration request. To sign such keypairs root private
| key must be somewhere on the device. But I don't see a
| mention of this in the docs.
|
| [1] https://developers.yubico.com/U2F/Protocol_details/Key_
| gener...
| Rafert wrote:
| That is Yubico's flavor of U2F attestation. U2F has been
| succeeded by WebAuthn, you'll probably want to look at
| https://www.w3.org/TR/webauthn-2/#sctn-defined-
| attestation-f... instead.
| sodality2 wrote:
| Then the root private key gets extracted, because there's
| lots of money to be had from doing so
| dandanua wrote:
| If you are the manufacturer, who already know the root
| private key and can make some fake users, you still won't
| be able to print new money from nowhere. Yes, you CAN make
| double spending, but this will just split the network,
| because every participant will accept only one spend, not
| both.
| spiorf wrote:
| Who and how issues the new money? how do you decentralize
| that? Otherwise you have a central bank and a database is
| more efficient.
| dieortin wrote:
| That's a problem that has already been solved in various
| ways by existing cryptocurrencies. For example, NANO was
| premined and then distributed via a faucet that required
| solving CAPTCHAs. Other cryptos just award holders more
| coins, or use other solutions.
| zemnmez wrote:
| this article describes a centralised system with the fido2 key
| manufacturer as the source of truth
| dandanua wrote:
| The hardware isn't supposed to connect to manufacturer servers,
| so how manufacturer is going to make decisions?
| a1369209993 wrote:
| The manufacturer can deny service to undesirables[0], by
| refusing to provide them with fido2s (either initial or
| replacement when broken). If we're willing to accept targeted
| denial of service we might as well have the New York Times
| (or whoever) publish hashes and timechain-encrypted
| transactions for tick N alongside decrypted transactions for
| tick N-1; that requires less secrity and infrastructure from
| the central authority.
|
| 0: I could give a long list of historical examples
| demonstrating that is in fact a problem, but frankly, if you
| (think you) are not a member of any demographic that someone
| considers undesirables, then _I_ consider you a undesirable.
| zemnmez wrote:
| the fundamental assumption of the system as stated in the
| article is that the device manufacturer will simply never
| attempt to forge keys
| dandanua wrote:
| It has no incentives to do that. Device keys are second-
| factor keys. The user has its own, personal (software)
| keys. You need both to make a transaction.
| cortesoft wrote:
| The idea is that the device manufacturer would create a
| user, get a bit of the currency, and then spend it
| repeatedly.
| exabrial wrote:
| Just a random terrible incomplete idea in my head. What if
| instead of the device generating the transaction sequence number,
| the sequence numbers were provided to the client ahead of time
| and signed by a trusted third party? Essentially you get a
| sequence number ahead of time and a window in which to use it.
| dandanua wrote:
| If you know the sequence number ahead of time then you can
| attach any transaction to it, including two conflicting. The
| point of hardware counter is that you (your device, actually)
| sings a counter along with a transaction. You couple them
| together in a way, that you can't counterfeit, because you
| can't tamper the device.
| vecio wrote:
| This is a truly FIDO key producers centralized consensus network.
| nepthar wrote:
| In the current use case of FIDO keys, it's in the user's best
| interest to ensure that the hardware is genuine, not tampered
| with, etc. In this proposal, it's the reverse: the user benefits
| from tampering with/simulating the hardware.
| dandanua wrote:
| Not really. If someone will be able to tamper the device and
| submit conflicting transactions then this will just split the
| network. This will be seen and just ruin the network. He can't
| print additional money in this way.
| gruez wrote:
| related project from a few years ago:
| https://news.ycombinator.com/item?id=15382911
|
| (basically uses intel SGX instead of FIDO keys)
| StavrosK wrote:
| The author says that PoS algorithms are centralized at heart, but
| does anyone know how this applies to Nano? I read the paper a few
| years ago and couldn't find any obvious disadvantages or
| centralization to it, and it has PoS, no fees, and instant
| sending.
|
| It's always seemed too good to be true, but I've never seen
| anyone mention a big downside to it, so I've always wondered.
| mattwilsonn888 wrote:
| It's a bit of a strange comment. One could certainly argue that
| in a proof of stake system a dynamic naturally exists where
| those who stake more earn more, and can stake more to earn more
| to stake more...
|
| The thing is though is you could say the same for traditional
| crypto mining. In either situation one person holding too many
| opportunities to author new blocks is a chance to double spend
| (though highly mitigated by simply waiting longer for newer
| blocks to come through before accepting trades).
| charcircuit wrote:
| >One could certainly argue that in a proof of stake system a
| dynamic naturally exists where those who stake more earn
| more, and can stake more to earn more to stake more...
|
| Everyone grows at the same rate though. If someone stakes 1%
| of the total pool and someone stakes 99%, then after making
| more they will still be at a 1:99 ratio.
| StavrosK wrote:
| Would you say that the existing PoS systems (like Ethereum 2)
| aren't as centralized as he mentions, then?
| latchkey wrote:
| ETH2 doesn't 'exist'. There is a heartbeat chain right now,
| but it doesn't actually do anything. Getting to the next
| step(s) is the hard part.
|
| Full PoS decentralization does not exist yet. Many attempts
| exist. Some better than others. Sadly, the complexity (rube
| goldberg) of PoS far outweighs the simplicity of PoW.
| StavrosK wrote:
| > Full PoS decentralization does not exist yet.
|
| How do you define "full PoS decentralization"? That
| sounds a bit no-true-Scotsmany.
|
| > Sadly, the complexity (rube goldberg) of PoS far
| outweighs the simplicity of PoW.
|
| Yes, and the huge energy usage of PoW far outweighs the
| zero energy usage of PoS. That's the tradeoff.
| latchkey wrote:
| It doesn't exist because ETH2 doesn't exist. It is the
| one blockchain that I see as being focused on full
| decentralization, instead of just stopping at variations
| of tendermint and a bunch of "approved" validators.
|
| Contrary to popular belief, PoS isn't zero energy usage.
| My very very very large ETH1 gpu mining operation sits
| next door to the same large data centers powering all the
| cloud providers. All getting power from the same
| hydrodams that would just go to waste otherwise. It isn't
| like the power can be easily used in other ways...
| transmission of power is expensive and intrusive.
|
| Bitcoin is an issue because of supply/demand... when the
| reward goes away, so will the miners. Difficulty will
| drop to more acceptable levels to cover the loss.
| ETH1/ethash at least tries to peg to a specific type of
| hardware that actually has a better roi with older models
| and doesn't need the latest / greatest.
|
| The tricky bit to make ETH2 work will be the use of
| zkSnarks. What nobody talks about is how compute (energy)
| heavy they are currently. It is a bit of moving the goal
| post if we're going to just end up building asic's again.
| charcircuit wrote:
| Nano uses open representative voting. There is no staking.
| dandanua wrote:
| NANO has delegated Proof-of-Stake. It's the representatives who
| vote on transactions. And it's supposed they don't have
| incentives to ruin the network. It's true, but a single
| representative can be captured by villains, who CAN have
| incentives to ruin the network.
|
| I actually like NANO, their blockchain structure is certainly
| next level, but it also has vulnerabilities due to PoS
| consensus.
| StavrosK wrote:
| Hmm, does it guard against minority representatives being
| able to do damage? If you have thousands of representatives,
| capturing one won't do much, correct?
| charcircuit wrote:
| Yes, you have to control 51% of the online voting power.
| dandanua wrote:
| If his vote is not decisive then yes. But, in theory, a
| vote of the representative that has low stake can be
| decisive. The commitment of two conflicting votes can split
| the network, thereby ruining it.
| StavrosK wrote:
| Ahh, that's interesting, thank you. It sounds like a low
| probability scenario, but not impossible.
| dandanua wrote:
| You can try to raise this probability by DDoSing
| representatives with high stakes.
| a1369209993 wrote:
| > The commitment of two conflicting votes can split the
| network, thereby ruining it.
|
| Couldn't this be repaired (with probability something
| like 1-O(compromised stake) per attempt), by exhibiting
| (in, say, lexicographic order) the two conflicting blocks
| (thereby invalidating both), and continuing with the
| chain?
|
| Eg, crude sketch off the top of my head:
| A -> B1 A -> B2 A -> B2 -> C2 # built
| off conflicting chain A -> b1 -> b2 -> C3 #
| resolved chain (block b dead)
|
| The resolved chain would have more blocks initially (2 vs
| 1), and roughly twice the number of nodes supporting it
| (since the split chains would by construction be valid to
| only about half the network each.
|
| I'm not sure the logistics of this works out, so non-
| rhetorically: _could_ this work? I 'm cribbing some
| intuitions from proof-of-work designs, but it seems like
| it ought to be possible in principle.
| dandanua wrote:
| I'm not fully following your logic, but to resolve that
| problem you need another consensus algorithm over the
| votes of representatives. And I don't know how we can
| effectively use the fact, that a probability of harmful
| representative behavior is very small.
| charcircuit wrote:
| This is not how Nano works. You need to compromise 51% of
| the online voting weight. There is also no splits in the
| network. Once a transaction has been confirmed it is
| final.
| charcircuit wrote:
| Nano uses open representative voting, not DPoS and you would
| need much more than a single representative to hurt the
| network. The largest representative currently has 19.8% of
| the online voting weigh. An attacker would need to get above
| 50%.
___________________________________________________________________
(page generated 2021-02-21 23:01 UTC)