Bitcoin Forum
December 17, 2017, 03:36:50 AM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: [RFC] The Identity Problem  (Read 501 times)
bitsanity
Newbie
*
Offline Offline

Activity: 4


View Profile
December 15, 2016, 05:28:09 PM
 #1

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
1513481810
Hero Member
*
Offline Offline

Posts: 1513481810

View Profile Personal Message (Offline)

Ignore
1513481810
Reply with quote  #2

1513481810
Report to moderator
1513481810
Hero Member
*
Offline Offline

Posts: 1513481810

View Profile Personal Message (Offline)

Ignore
1513481810
Reply with quote  #2

1513481810
Report to moderator
1513481810
Hero Member
*
Offline Offline

Posts: 1513481810

View Profile Personal Message (Offline)

Ignore
1513481810
Reply with quote  #2

1513481810
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1513481810
Hero Member
*
Offline Offline

Posts: 1513481810

View Profile Personal Message (Offline)

Ignore
1513481810
Reply with quote  #2

1513481810
Report to moderator
1513481810
Hero Member
*
Offline Offline

Posts: 1513481810

View Profile Personal Message (Offline)

Ignore
1513481810
Reply with quote  #2

1513481810
Report to moderator
1513481810
Hero Member
*
Offline Offline

Posts: 1513481810

View Profile Personal Message (Offline)

Ignore
1513481810
Reply with quote  #2

1513481810
Report to moderator
fikihafana
Sr. Member
****
Offline Offline

Activity: 462



View Profile
December 18, 2016, 02:17:27 PM
 #2

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.
bitsanity
Newbie
*
Offline Offline

Activity: 4


View Profile
December 20, 2016, 06:00:37 PM
 #3

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.
bitsanity
Newbie
*
Offline Offline

Activity: 4


View Profile
December 31, 2016, 08:02:38 PM
 #4

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.
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!