[RFC] The Identity Problem

[bitsanity]

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

[fikihafana]

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]

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]

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.