Papers › Key Management Based on Ownership of Multiple Authenticators in Public Key Authentication
Key Management Based on Ownership of Multiple Authenticators in Public Key Authentication
Koudai Hatakeyama, Daisuke Kotani, Yasuo Okabe
The archive published only this paper's code-link row. Authors, date and abstract are from arXiv's metadata (CC0), read from the Kaggle arXiv metadata snapshot of 2026-09-12 where its title matched the archive's; the title is the archive's.
Public key authentication (PKA) has been deployed in various services to provide stronger authentication to users. In PKA, a user manages private keys on her devices called authenticators, and services bind the corresponding public keys to her account. To protect private keys, a user uses authenticators which never export private keys outside. On the other hand, a user regularly uses multiple authenticators like PCs and smartphones. She replaces some of her authenticators according to their lifecycle, such as purchasing new devices and losing devices. It is a burden for a user to register, update and revoke public keys in many services every time she registers new accounts with services and replaces some of her authenticators. To ease the burden, we propose a mechanism where users and services manage public keys based on the owner of authenticators and users can access services with PKA using any of their authenticators. We introduce a key pair called an Ownership Verification Key (OVK), which consists of the private key (OVSK) and the corresponding public key (OVPK). All authenticators owned by a user derive the same OVSK from the pre-shared secret called the seed. Services verify the ownership of the authenticators using the corresponding OVPK to determine whether binding the requested public key to her account. To protect user privacy while maintaining convenience, authenticators generate a different OVK for each service from the seed independently. We demonstrate the feasibility through the Proof of Concept implementation, show that our proposed mechanism achieves some security goals, and discuss how the mechanism mitigates threats not completely handled.
Code
Repository list and official/mentioned flags are the archive's, frozen 2025-07-28. Reachability, where shown, is from one Syntology probe window (2026-09-16 to 2026-09-18); repositories not probed show nothing. GitHub stars are not tracked.
Code Syntology ran Syntology
Not run by Syntology. Nothing on this page verifies that the listed code works.
Results from the paper archive 2025-07-28
No leaderboard rows for this paper in the archive.
Report a problem or propose a change · a person checks every report against the paper or source before anything changes; decisions are listed on /corrections