|
Title: [RFC] The Identity Problem Post by: bitsanity on December 15, 2016, 05:28:09 PM Dear Forum
How does a computer or network service know who is at the keyboard? Is there a better way than the name and password approach? I created a project to demonstrate how elliptic-curve keys and signatures can be used to control access to physical locks and network services. The work is my own unsponsored effort and is released open-source. It works without network access and needs no central service or authority to function. The approach employs secp256k1, so the keys are bitcoin-compatible. Anyone interested in reviewing, contributing and reusing is invited to look into it. I am not a cryptography expert so my approach could be faulty. It is also possible I made some mistake in the code. More eyes are welcome. The project is called ADILOS (A DIgitial LOck System) and includes these subsystems: keymaster - an Android app, like a wallet gatekeeper - operates a physical lock (e.g. door, safe) kgserver - a network service something like a webserver kgagent - a bridge between keymaster and kgserver My hope is that adoption of the underlying message protocol will enable any and all interested parties to make workalikes and extensions that all cooperate and remove the need for users to manage more than one app/device. Best regs Bryan Project: https://github.com/bitsanity/ADILOS Videos: Overall concept, keymaster+gatekeeper: presentation - https://youtu.be/ZR_fEknTFFE demonstration - https://youtu.be/Uzi3Tbkvagg Updated protocol enabling network access, kgagent+kgserver: presentation - https://youtu.be/uUx9jQOyqf8 demonstration - https://youtu.be/ahdL_3taBQQ Title: Re: [RFC] The Identity Problem Post by: fikihafana on December 18, 2016, 02:17:27 PM Dear Forum How does a computer or network service know who is at the keyboard? Is there a better way than the name and password approach? I created a project to demonstrate how elliptic-curve keys and signatures can be used to control access to physical locks and network services. The work is my own unsponsored effort and is released open-source. It works without network access and needs no central service or authority to function. The approach employs secp256k1, so the keys are bitcoin-compatible. Anyone interested in reviewing, contributing and reusing is invited to look into it. I am not a cryptography expert so my approach could be faulty. It is also possible I made some mistake in the code. More eyes are welcome. The project is called ADILOS (A DIgitial LOck System) and includes these subsystems: keymaster - an Android app, like a wallet gatekeeper - operates a physical lock (e.g. door, safe) kgserver - a network service something like a webserver kgagent - a bridge between keymaster and kgserver My hope is that adoption of the underlying message protocol will enable any and all interested parties to make workalikes and extensions that all cooperate and remove the need for users to manage more than one app/device. Best regs Bryan Project: https://github.com/bitsanity/ADILOS Videos: Overall concept, keymaster+gatekeeper: presentation - https://youtu.be/ZR_fEknTFFE demonstration - https://youtu.be/Uzi3Tbkvagg Updated protocol enabling network access, kgagent+kgserver: presentation - https://youtu.be/uUx9jQOyqf8 demonstration - https://youtu.be/ahdL_3taBQQ Thanks for your work bryan, i also research in public identity. And my concept almost same with your work. The diffrence is i used more encryption and biometric authentication as extended key. For now i still unpublish prototype and project. Title: Re: [RFC] The Identity Problem Post by: bitsanity on December 20, 2016, 06:00:37 PM Sounds interesting @fikihafana !
For adilos I used bitcoin keys and signatures because of the possible extended uses, for example: Attend concert: 1. Prior to event I sweep a key from keymaster into a bitcoin wallet and add funds 2. I send bitcoin from that key/address to organizer to pay for my ticket 3. On the night of the event I go to the venue and use keymaster to sign in using same key 4. Venue's system converts the public key in my response to bitcoin address 5. System checks the blockchain to confirm payment 6. Gate lets me in This "paperless tickets" approach could simplify and reduce costs for organizers. It could also reduce counterfeiting and scalping. Title: Re: [RFC] The Identity Problem Post by: bitsanity on December 31, 2016, 08:02:38 PM Oops. Made an error in the first presentation video: I mistakenly claimed signatures to be 32 bytes.
In fact, ECDSA signatures are composed of two 32-byte parts (r, s) plus a few bytes for encoding. So each 'message part' contains 33 bytes of compressed key plus signature plus encoding for a result around 100 bytes. |