Improve security of CREATE transactions

[diminator]

Currently, CREATE transactions can issue assets for every public key and they are only validated by a single node.

What would be better:

• only create assets for your personal key
• have the asset creation signed off by at least n / 2 + 1 nodes

The proposed workflow could be as follows:

1. A client sets up a CREATE transaction.
2. The CREATE transaction has an implicit condition, as there is no input to the transaction:
   • n / 2 + 1 out of n threshold condition for the nodes
   • The above output goes into a 2 - 2 threshold condition together with the signature of the client
3. The fulfillment of the CREATE transaction fulfills the implicit condition above and the nodes validate whether the public key matches the one of the client.
4. The output condition only requires the public key of the client

[TimDaub]

I just discussed this with @r-marques. Makes sense!
We could implement it in the bigchaindb-driver soonish.

[ttmc]

Issue #327 has some similar ideas to improve security of CREATE transactions.

[TimDaub]

This is blocked as long as ThresholdSha256 Fulfillments cannot be signed partially.
See:

• [WIP] Allow partial signing of Threshold condition cryptoconditions#25
• Signing of transaction should be possible with partial set of keys bigchaindb-common#13

[diminator]

This is blocked as long as ThresholdSha256 Fulfillments cannot be signed partially.

Not exactly. The fulfillment + message can go around off-chain. No need to store it on-chain: you just want to gather signatures. In many cases the contract negotiation is done on a layer above

[sohkai]

Based on a discussion I had with @ttmc, I think the motivation for this was:

1. Previously, federation nodes were the ones minting assets
2. Even if clients were the ones to sign nodes, a federation node could "steal" a CREATE transaction getting passed through by replacing the signature and public keys to its own.

I don't think what's proposed is the right approach (though let me know if I've misunderstood anything).

---

only create assets for your personal key

I believe this has already been accomplished by the Transaction model (you need to at least know the private key before you can create something for its public key)?

have the asset creation signed off by at least n / 2 + 1 nodes

Not a big fan of this approach; I think this just skirts around the topic but still leaves the system vulnerable. The root problem here is to enable end users to trust the transactions they're getting as inputs. Rather than using a majority-signing approach to tackle this problem, I'd rather keep it simple and let trust be established through publicly advertised trust networks off-chain (i.e. users advertising their public keys to other users, like how gpg works). Using a majority-signing approach doesn't solve the counterfeiting, or "stealing," since anyone, at any time, can duplicate an asset that's in the DB and register it as their own.

There's two parts to this trust issue:

1. As the minter, it's obviously not ideal if the federation node I'm using to send my CREATE transactions can "steal" my assets. However, I can double check that I'm getting my assets created properly and simply report and switch federation nodes if one becomes problematic. Nobody can counterfeit my assets, since I'm the only one in control of my public key.
2. As the end user who may be receiving an asset, I can look up its creator's public key (note that every BDB asset has an implicit "creator": the public key that was assigned for its CREATE transaction) and match it to the public key of who I'm assuming it to be. If it doesn't match, I should ignore the transfer if given the choice (e.g. not paying for it).

[sbellem]

Currently, CREATE transactions can issue assets for every public key and they are only validated by a single node.

I am a bit confused by the above statement. The voting mechanism is such that all nodes of the federation will vote on the validity of a proposed block, which entails that every transaction in that block will go though a validation step.

[r-marques]

This is probably related to #327 and we should move the discussion there

[ttmc]

Resolved (indirectly) by pull request #794 (a pull request which also resolved issue #327).

[diminator]

@ttmc how is this resolved by #794?
I mean, the problems remains that:

• anyone can mint assets
• anyone can mint assets in the name of someone else

[TimDaub]

I agree with @diminator.

Especially when IPDB wants to bill on a transaction-base, the proposal in outlined in the original post should be considered.

I'd recommend to reopen this ticket.

[ttmc]

@diminator @TimDaub

PR #794 included a change that makes it so that CREATE transactions must be signed by all "owners_before".

Yes, anyone can mint assets, but they can only use their own private key(s) when signing to generate the fulfillments in the CREATE transaction.

For example, suppose TicketBaron.com has a set of public/private keypairs. They share their public keys with the public. Only TicketBaron.com can create ticket assets signed with their private key(s). Sure, others can create counterfeit TicketBaron.com tickets, but it's easy to check the authenticity of tickets (CREATE transactions): are they signed by TicketBaron.com's private key(s)? If yes, then they are authentic.

In other words, it's left up to clients to detect counterfeit assets.

That needs to be documented.