DKMS – Key Recovery Summit: Biometric Recovery, Cold Storage, Social Recovery

From IIW

DKMS – Key Recovery Summit: Biometric Recovery, Cold Storage, Social Recovery


Thursday 4A

Convener: Drummond, Jack, Kent

Notes-taker(s): Lily Bragg


Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:


Distributed Key Management System (DKMS)

DHS – Science and Tech division – phase one SBIR on DID, phase two is working on DKMS.  Goal is an open standard.  Key Management Interoperability Protocol – KMIP is an existing standard for vendors to manage keys in an enterprise.  We need the equivalent for decentralized key management. Should meet the best practice and requirements.  800-130 Framework for designing cryptographic key management systems, we think that is the best. We are about 6 months into it.  BYU Internet Security Research Lab specialized in usability. Ken ___ from BYU. Yearlong project in 4 phases 1) Analyze requirement – going through 800130 – 230+ requirements that any key management system must meet to sell to US gov. agency.  We analyzed all those and how they will apply to decentralized.  About 60% of the requirements are exactly the same.  Another 36% needed to be modified.  Only 4% we said do not apply.  We identified 12 additional requirements. Summary of all of that was published a couple weeks ago.

Phase 2, we are designing an architecture for decentralized key management.  The big hard problem is key recovery.  There is no central authority to go to in order to get a new key. With Ken and his lab, we said probably the hardest part is usability.  How will it actually work. We all learned how to manage passwords (kind of) … will now have to learn how to manage keys.   This session will be 1) a survey, 2) one option – ‘cold storage’, where someone keeps it, 3) another option biometric option being worked on, and 4) key recovery. We want to focus on usability.


Jack Callahan, CTO, Veridium

IBV – initial biometric vector – your fingerprint, voiceprint, etc.  

BOPS2 – Biometric Open Protocol Standard IEE 2410 – covers collection, storage, etc.  Today talking about modes and shares. Local mode – the IBV is split (I think sharded) into two or more ‘shares’, both resident on a mobile device. Like FIDO UAF.  BOPS uses the IBV to generate a private key, using a TPM if its available on that device. FIDO is adamant that the private keys are only on the local device.  BOPS is a super set, it also has remove configuration, though controversial, some customers want it.  Your CBV (?Current? biometric vector) is sent across for checking remotely.  BOPS does not prescribe which one to use.  You can also split it with a shard locally and another shard on server – then bring it across and check it locally or remotely.

So, now the thought is, what if the shard is given to a friend, instead of another institution.  Could put these shares on a blockchain. Now how to coalesce – might use ring signatures? (RingCT),

So, when someone comes with just a biometric, how do I discover the list of who might have the shares?

Still a lot of unanswered questions – usability, security. These live in our phones right now.  Right now ___?New Mexico? doing server side matching for KYC.

Drummond – general architecture. Diagram with DIDs on blockchain on bottom – talking to cloud agent/wallet, connected to edge agent/wallet.

Biometrics will be entered at edge, but IBV can be stored at edge or cloud. The edge device is where the human physically interfaces.

One point, IoT devices may have some biometrics, that could be used as a ‘fog’ of devices that can do a face recognition, or fingerprint for authenticating you.  But If your house burns down, those are gone. IoT manufacturers will often choose the cheapest chip. However, there is a spectrum of devices, just need sufficient density of devices with those that can ID you.

Key Ring = set of keys on one device. With Apple iCloud, potentially can be shared.

Trust Ring = Set of agents participating in key/credential backup and recovery.

Key expiration is important, for many use cases. But some keys I want to last a very long time.

Still need to test the concept of trust rings with individuals. Will people get the concept? Is it a common concept – or can there be a universal set of ways to do things.

Discussion on naming, maybe a Trust Ring should be called a Recovery Group.

Possibility for the group to be arbitrarily open ended.

Very little research and literature on decentralized key management.

Th4A1.png

Th4A2.png

Th4A3.png

Th4A4.png

Th4A5.png