bitauth.bitjson.combitjson - BitAuth2017

Authentication with Bitcoin - Jason Dreyzehner Atlanta Blockchain & Bitcoin Meetup bitauth.bitjson.com universal identity and authentication protocol, based on bitcoin I'd like to show you how works, and how it could be used to solve some very interesting security problems. How bitcoin really works How bitcoin transactions are authenticated How we can adapt this for general use To explain how this works, we'll need to dive into some of bitcoin's technical details. Part 1: Authenticating bitcoin transactions How Bitcoin Works Send bitcoin to a bitcoin address . The person with the private key can spend the money. Most people understand bitcoin addresses to be like accounts. This is a bit of a simplification. Bitcoin addresses are programs Every bitcoin address is actually a little program. It defines one or more authentication requirements for spending. How Bitcoin Actually Works Send bitcoin to a locking script . The person with the unlocking script can spend the money. With this in mind, we get a slightly different picture of how bitcoin actually works. This will be a lot clearer with some examples. Pay to Public Key Hash (P2PKH) - Locking Script OP_DUP OP_HASH160 <PubkeyHash> OP_EQUALVERIFY OP_CHECKSIG Unlocking Script <Sig> <PubKey> The "canonical" bitcoin transaction is P2PKH. Here's what it looks like. Each of these operations has a very specific action it does, but it's simpler than it looks. We'll step through it on the next slide. unlocking + locking script <maybeSig> <maybePubKey> | OP_DUP OP_HASH160 <PubkeyHash> OP_EQUALVERIFY OP_CHECKSIG Script Stack <maybeSig> <maybeSig> <maybePubKey> <maybePubKey> <maybeSig> OP_DUP <maybePubKey> <maybePubKey> <maybeSig> OP_HASH160 <maybePubkeyHash> <maybePubKey> <maybeSig> <PubkeyHash> <PubkeyHash> <maybePubkeyHash> <maybePubKey> <maybeSig> OP_EQUALVERIFY <verifiedPubKey> <maybeSig> OP_CHECKSIG 1 (success) To validated this, we basically add the locking script after the unlocking script, and run it. Here you can see the full program executed. Pay to Script Hash (P2SH) Multisig - Locking Script OP_HASH160 <RedeemScriptHash> OP_EQUAL Redeem Script 2 <Pub A> <Pub B> <Pub C> 3 OP_CHECKMULTISIG Unlocking Script 0 <Sig A> <Sig C> <RedeemScript> Let's look at another example which really starts to demonstrate the power of this sort of scriptable authentication. unlocking (with redeem) + locking script Script Stack 0 0 <sig A> <sig A> 0 <sig C> <sig C> <sig A> 0 <RedeemScript> <RedeemScript> <sig C> <sig A> 0 OP_HASH160 <RedeemScriptHash> <sig C> <sig A> 0 <RedeemScriptHash> <RedeemScriptHash> <RedeemScriptHash> <sig C> <sig A> 0 OP_EQUAL <sig C> <sig A> 0 2 2 <sig C> <sig A> 0 <pub A> <pub A> 2 <sig C> <sig A> 0 <pub B> <pub B> <pub A> 2 <sig C> <sig A> 0 <pub C> <pub C> <pub B> <pub A> 2 <sig C> <sig A> 0 3 3 <pub C> <pub B> <pub A> 2 <sig C> <sig A> 0 OP_CHECKMULTISIG 1 Like the last time, our full script evaluates to true. P2ODorBoDorS Pay to Operations Department or Board of Directors or Supermajority One final example – here's a transaction type that is definitely not standard, but we can envision how it would with Bitcoin Script. P2ODorBoDorS 2 <Pub A> <Pub B> <Pub C> 3 OP_CHECKMULTISIG 3 <Pub D> <Pub E> <Pub F> <Pub G> <Pub H> 5 OP_CHECKMULTISIG OP_BOOLOR 13 <Pub M1> <Pub M1> [...] <Pub M20> 20 OP_CHECKMULTISIG OP_BOOLOR note: P2SH 520 byte limit Once again, this is non-standard, and actually won't work at all using P2SH due to the 520 byte script limit. Of note, P2SH-P2WSH would allow up to 10,000 bytes, so this may not be very far off. Bitcoin Script Flexible (with well-chosen constraints) Limited processing requirements Simple implementation Self-contained From the developers guide , "The script language is a Forth-like stack-based language deliberately designed to be stateless and not Turing complete. Statelessness ensures that once a transaction is added to the block chain, there is no condition which renders it permanently unspendable. Turing-incompleteness (specifically, a lack of loops or gotos) makes the script language less flexible and more predictable, greatly simplifying the security model." Part 2: Scriptable Authentication We've just seen the power of bitcoin's "scriptable authentication". Now, let's compare it to current standards. Static Authentication ("service-driven") Service provides many authentication options Service collects necessary information from the user (password, phone number, secret questions, email address, etc.) To login, service issues challenge(s) Service verifies user response This section applies to authentication standards in most protocols too, but to simplify, I'll discuss it as if we're only talking about web services. Most services use what could be described as a Static Authentication system. Problems all the way down Some user identities have higher security requirements than others Services must provide a variety of options to satisfy all identities Inconsistency across services (re-invented wheels) Ever increasing complexity Static authentication systems come with a lot of downsides. Security requirements – Grandma's Facebook vs. Microsoft's Facebook With complexity comes security problems. E.g. most "hacks" are password resets. Scriptable Authentication ("user-driven") User chooses authentication requirements Service collects users locking script To login, user provides unlocking script Service validates Here's an alternative. We can take Bitcoin's authentication system, and use it for everything. Why Scriptable Authentication? Aligning of security incentives Improved user experience by moving authentication to the (more competitive) consumer sphere Simplify development requirements for services Fewer systems, fewer attack surfaces This is a high-level overview, but we'll dig into the technical details in a minute. Note to readers: see the Motivation section of the BitAuth BIP for full details on this slide. Part 3: Scriptable Authentication & the Blockchain Why use Bitcoin Script? Before I describe the technical standard, we should address some of the underlying assumptions, so you can understand where it's coming from. Standardization is Hard Draft specification creation Standardization management Consensus, standard acceptance Rollout mechanisms Backwards compatibility management Before I describe the technical standard, we should address some of the underlying assumptions, so you can understand where it's coming from. Why use the Blockchain for identities? Why not just use Bitcoin Script, without storing identities on the chain? The Blockchain is designed to secure identities. The Blockchain is a secure directory of identities and their authentication requirements. We don’t usually think about it this way, but the entire purpose of the blockchain is to record – in a censorship resistant, tamperproof way – the authentication requirements for various identities. That is – in fact – it’s sole purpose. On a high level, when looking through the actual contents of the blockchain, if you scan through the files, the vast majority is simply a listing of "authentication requirement definitions" or "migrations" for millions of identities. Right now, we use those identities to manage funds, but we can do a lot more. How do we create an identity on the blockchain? This is where we get into the draft specification. You can find the whitepaper (Bitcoin Improvement Proposal) in the GitHub repo. a BitAuth Identity is defined by an Authbase (funding inputs) Identity/Signi...