Long Term R&D: Internet Identity (proposal)

[diegop]

1. Summary

This is a motion proposal for the long-term R&D of the DFINITY Foundation, as part of the follow-up to this post: Motion Proposals on Long Term R&D Plans (Please read this post for context).

This project’s objective

Internet Identity is a blockchain authentication system built for and on the Internet Computer. Internet Identity enables users to authenticate toward each dapp with a pseudonymous identity, which is consistent across multiple user devices but unlinkable across different dapps. Internet Identity has been launched together with the Internet Computer, and is used by many users of the Internet Computer to authenticate toward their favorite dapps.

While Internet Identity as it is today already provides secure authentication and works seamlessly across multiple user devices – building on both web authentication (for secure key storage on client devices) and on the Internet Computer’s threshold cryptography (for supporting multiple ones) – several key features can still be improved. This motion suggests focusing R&D efforts in the following years to the following topics:

• Improve security of recovery method management in the II canister.
• Provide stronger, cryptographic unlinkability guarantees with weaker trust assumptions.
• Performance improvement in generating delegations.
• Secure account recovery using external identity verification providers.
• Decentralized anonymous credential-based authentication.
• Better mechanisms against bots, e.g. based on web auth attestations.
• Support for devices without web authentication.
• Support Internet Identity use in native apps.

2. Discussion lead

Björn Tackmann, Maria Dubovitskaya

3. How this R&D proposal is different from previous types

Previous motion proposals have revolved around specific features and tended to have clear, finite goals that are delivered and completed. They tended to be measured in days, weeks, or months.

These motion proposals are different and are defining the long-term plan that the foundation will use, e.g., for hiring and organizational build-out. They have the following traits and patterns:

1. Their scope is years, not weeks or months as in previous NNS motions
2. They have a broad direction but are active areas of R&D so they do not have an obvious line of execution.
3. They involve deep research in cryptography, networking, distributed systems, language, virtual machines, operating systems.
4. They are meant to match the strengths of where the DFINITY foundation’s expertise is best suited.
5. Work on these proposals will not start immediately.
6. There will be many follow-up discussions and proposals on each topic when work is underway and smaller milestones and tasks get defined.

An example may be the R&D for “Scalability” where there will be a team investigating and improving the scalability of the IC at various stages. Different bottlenecks will surface and different goals will be met.

3. How this R&D proposal is similar to what we have seen

We want to double down on the behaviors we think have worked well. These include:

1. Publicly identifying owners of subject areas to engage and discuss their thinking with the community
2. Providing periodic updates to the community as things evolve, milestones reached, proposals are needed, etc…
3. Presenting more and more R&D thinking early and openly.

This has worked well for the last 6 months so we want to repeat this pattern.

4. Next Steps

Developer forum intro posted
1-pager from the discussion lead posted
NNS Motion proposal submitted

5. What we are asking the community

• Ask questions
• Read 1-pager
• Give feedback
• Vote on the motion proposal

Frankly, we do not expect many nitty-gritty details because these are meant to address projects that go on for long time horizons.

The DFINITY foundation’s only goal is to improve the adoption of the IC so we want to sanity-check the projects we see necessary for growing the IC by having you (the ICP community) tell us what you all think of these active R&D threads we have.

6. What this means for the existing Roadmap or Projects

In terms of the current roadmap and proposals executed, those are still being worked on and have priority.

An intellectually honest way to look at this long-term R&D project is to see them as the upstream or “primordial soup” from which more baked projects emerge from. With this lens, these proposals are akin to asking, “what kind of specialties or strengths do we want to make sure DFINITY foundation has built up?”

Most (if not all) projects that the DFINITY foundation has executed or is executing are borne from long-running R&D threads. Even when community feedback tells the foundation, “we need X” or “Y does not work”, it is typically the team with the most relevant R&D area that picks up the short-term feature or project.

[diegop]

Please note:

Some folks gave asked if they should vote to “reject” any of the Long Term R&D projects as a way to signal prioritization. The answer is simple: “No, please, ACCEPT”

These long-term R&D projects are the DFINITY’s foundation’s thesis at R&D threads it should have across years (3 years is the number we sometimes use internally). We are asking the community to ACCEPT (pending 1-pager and more community feedback of course). Prioritization can come at a separate step.

[wpb]

This proposal will be a strong Yes from me. I think these improvements are needed and Dfinity should have a lead role since the implementation of many of the improvements/features will need to occur at the core protocol level. There is probably an opportunity for collaboration with other developers working on related projects as well, but Dfinity definitely needs to take the lead in my opinion.

[maria]

Internet Identity features (One-pager)

Summary

Internet Identity is a blockchain authentication system built for and on the Internet Computer. Internet Identity enables users to authenticate toward each dapp with a pseudonymous identity, which is consistent across multiple user devices but unlinkable across different dapps. Internet Identity has been launched together with the Internet Computer, and is used by many users of the Internet Computer to authenticate toward their favorite dapps.

While Internet Identity as it is today already provides secure authentication and works seamlessly across multiple user devices – building on both web authentication (for secure key storage on client devices) and on the Internet Computer’s threshold cryptography (for supporting multiple ones) – several key features can still be improved. This motion suggests focusing R&D efforts in the following years to the following topics:

• Improve security of recovery method management in the II canister.
• Provide stronger, cryptographic unlinkability guarantees with weaker trust assumptions.
• Performance improvement in generating delegations.
• Secure account recovery using external identity verification providers.
• Decentralized anonymous credential-based authentication.
• Better mechanisms against bots, e.g. based on web auth attestations.
• Support for devices without web authentication.
• Support Internet Identity use in native apps.

Background

The core component of Internet Identity is a canister that manages the mapping between a user’s identity anchor and the public keys associated with the devices of the user. More technically, the users authenticates toward the canister from their devices, and upon successful authentications, the canister issues delegations with which the users can authenticate themselves toward dapps.

The Internet Identity canister also serves the Internet Identity front end into the users’ browsers. The front end is a light, Javascript-based application that manages the user’s identity anchor in the canister and that builds on web authentication as a mechanism for storing the user’s cryptographic keys in secure hardware. The front end also interacts with dapps that support Internet Identity for authenticating their users.

Topics

Secure management of recovery methods and keys

Currently, all devices and recovery methods associated with a user’s identity anchor have the same level of privileges. In particular, each device or recovery method can be used to delete or add any other device or recovery methods. This does not allow for reflecting the actual security properties of different devices, such as a USB security key that can be activated by a simple touch, a key stored on a phone or laptop that requires the user to authenticate via biometrics for each use, or a seed phrase stored in a secure locker. In the future, Internet Identity shall support different privilege levels for different devices, allowing a user to designate certain devices or recovery methods as more trusted and, e.g., make them non-deletable by lower-level devices and methods.

Cryptographic unlinkability under weaker assumptions

The unlinkability of pseudonyms that are related to the same identity anchor but issued for different dapps currently depends on the secrecy of a seed stored within the Internet Identity canister. (No other security property is affected.) A better method of storing such a seed would be in a threshold secret-sharing across all nodes of the subnet running the Internet Identity canister, since then no small subset of nodes can reconstruct the secret. It is proposed to develop new cryptographic protocols for the secure derivation of unlinkable pseudonyms based on threshold cryptography.

Performance improvement in generating delegations

The delegations that the Internet Identity canister issues toward dapp front ends (and that allow the user to always authenticate under the same pseudonym for that dapp) are authenticated via the Internet Computer’s certified variables mechanism. Certifications of variables require finalization on the block containing the request, which leads to a noticeable delay in creating the delegation. In the future, and in line with the previous topic on securely deriving unlinkable pseudonyms, the Internet Computer shall be able to issue the delegations without the need for finalization in consensus.

Secure account recovery based on external identity providers

Internet Identity provides two recovery mechanisms: additional (e.g. USB) security devices – which require additional expenses – and recovery phrases – which are difficult to manage securely for most users. In the future, Internet Identity shall provide an additional recovery method in which users associate (in encrypted form) personal information with their identity anchor, and designate specific identity verification services for recovering access to the account, based on validation of documents proving the associated personal information.

Decentralized anonymous credential-based authentication

Authentication of users on the Internet Computer is based on their principal, which serves as a pseudonym for the user. The Internet Identity does not yet support additional attributes such as age, citizenship, residence, bonus program membership, and so forth. In the future, Internet Identity shall support a self-sovereign and privacy-friendly implementation of attribute-based authentication based on anonymous credentials.

Improve protection from bots

The current implementation of Internet Identity uses proofs of work to protect from bots, which have been proven insufficient and will soon be amended by a CAPTCHA. Yet, also the CAPTCHA-based protection may be insufficient as a protection from bots at some point in time. An additional measure can be based on web authentication attestations, which attest the device used for the registration, and thereby require the involvement of a person. In the future, this and similar mechanisms shall be scrutinized and implemented.

Support for devices without web authentication

The current implementation of the Internet Identity front end requires web authentication to be supported by the user’s device. Various users have devices that do not support web authentication, which they would still like to use to access the Internet Computer. In the future, Internet Identity shall improve support for such cases, with possible directions including delegated authorization from a web-authentication-enabled device, or software-based solutions if they can provide a similar level of security.

Support for Internet Identity in native apps

Internet Identity was designed primarily with focus on web-browser-based front ends served from dapp canisters, and it is difficult to integrate with native applications (e.g. installed on the user’s phone). In the future, Internet Identity shall provide better interoperability with such native applications.

Discussion leads

The motion proposal is driven by @bjoern, @maria and other team members who will also be available for discussion.

What we are asking the community

• Review comments, ask questions, give feedback
• Vote accept or reject on NNS Motion

[nomeata]

@maria

In the future, and in line with the previous topic on securely deriving unlinkable pseudonyms, the Internet Computer shall be able to issue the delegations without the need for finalization in consensus.

Would this simply use the Threshold-ECDSA support, or something else?

[maria]

This is independent of the tECDSA feature. This is related to a protocol that a user can run with multiple ICP nodes to derive an unlinkable pseudonym (hence, weaker assumptions mentioned earlier). Once such protocol starts shaping up the details will be shared with the community.

[diegop]

Proposal is live: Internet Computer Network Status

[Roman]

Hi @maria ! How are you ? Good, I hope. And hope you are enjoying holidays.

Could we be kept in touch about shorter term progression about security improvement of recovery tools. A lot of ideas and counter ideas had been advocated in this thread : Internet Identity Lack Of Security

I precise that I ask this, because until today, we were several to use the Ledger Hardwallet FIDO(U2F) app to minimize our risk, but one won’t be able to use this app anymore in a couple of weeks :

U2F API deprecation

So one has to surrender to use devices one did not want to use before having to do it, and the risk problem became more important. I know that some developers worked on personal solutions to limit ASAP their risks, like @Icdev2dev & @mparikh setting some neuron management in order to merge maturity without having to use their « financial » Internet Identity.

Thanks !

[bjoern]

I think this is a misunderstanding. What is removed is the Javascript “U2F” API that applications (like, e.g., the NNS frontend dapp) can use to communicate with the Ledger hardware wallets. There are alternatives, namely WebHID and WebUSB, and the NNS frontend dapp actually uses WebHID for the integration. As WebHID is only supported in Chromium-based browsers, the use of the Ledger hardware wallets in the NNS frontend dapp is restricted to those.

This is not referring to the “FIDO U2F” application running on the Ledger devices. The FIDO U2F application does not depend on the Javascript U2F API, instead, it makes the Ledger hardware wallet behave as a FIDO token that can be used in the browser via the Web Authentication API.

[Roman]

Thank you so much . For everything.

[Roman]

So distrikt’s iPhone version is from now on out. We really need to start the brainstorming about the recovery’s security improvements to allow people to use this dApp and the next ones to come without being afraid of losing their funds. Me, and a lot of other people won’t use distrikt until this moment. So I think the fast progression of ICP makes us have to discuss and improve this matter sooner than later, for the whole ecosystem wellness !

[jzxchiang]

Wait, why would using Distrikt on an iPhone jeopardize your ICP funds?

[Roman]

Because to use the Internet Identity (II) jeopardizes your II and then your funds if you used II to hold your funds.

You can read this thread about it : Internet Identity Lack of Security.

One of the most important messages in this thread, from Timo, Principal Researcher at Dfinity :

@timo

Let’s make some analogies before you ditch II entirely . How much money would you store in or access through MetaMask, MEW, etc. (without connecting a hardware wallet to them)? About the same you can store in II. Both depend on browser security. If the browser/OS is compromised then you can lose funds.

The point I made is that II is a software wallet. Software wallets have the advantage that they can store key material and you don’t have to confirm every single interaction on an external device and display. But if the browser/OS is compromised then the key material is at risk. Hardware wallets protect against that at the cost of having to approve every single interaction on an external device and display. Fundamentally there are only these two options, software wallet or hardware wallet and it is up to the user’s judgement to make the trade off.

Here, to illustrate, “browser compromised” means for example that your browser can swap out an URL under the hood and display a green padlock when there shouldn’t be one.

Now, in some further detail, II actually tries to improve over wallets like MetaMask. Where those wallets store key material permanently on disk (at least encrypted), II doesn’t. II only creates session keys that are valid for 30 min. The permanent keys are inside the biometric sensor or Yubikey. That is an improvement because it shortens the attack window for certain attacks.

And this :

@timo

I think there is a major misunderstanding here. The II was not meant to be used for holding stake in the amounts that are thrown around here. It is not about having one II or two different ones. You simply don’t use II at all for these kind of amounts.

II is a convenience feature for everyday use. It is not a security feature for long-term storage.

II is and remains a “software wallet” no matter how you use it, even if you use it with a Yubikey and even if your FIDO device is PIN protected. When you connect a FIDO device it is only used once to sign the browser’s session keys. After that all interaction is initiated and signed by the browser alone. Hence II is only as secure as your browser, regardless of how secure your phrase, biometric sensor or Yubikey is. You cannot entrust significant value to this environment.

The only safe ways to hold significant value is with an air-gapped computer and the proper tools such as quill or with a Ledger Nano connected to the NNS dapp as a hardware wallet. In the latter case every single transaction gets confirmed on the hardware wallet’s display and signed inside the hardware wallet. The browser is then untrusted. There is no II at play with the hardware wallet.

Using a hardware wallet is different from using a FIDO device to log into your II. The former is a true hardware solution, the latter is still essentially a software wallet. The two are not to be confused.

I think because of this misunderstanding the discussion is getting derailed. Whales don’t ask if they can have one or two IIs. Whales don’t use II for storing value.

I am not saying that II can’t be improved or that the discussion here doesn’t have value. I am just saying we are getting derailed if we’re discussing using II for long-term/cold/high value staking or storage.

[Zane]

As it currently is Internet Identity is quite tedious to use if the device you’re using doesn’t have biometrics and in my opinion this is one of the biggest limiting factors for IC dApps adoption.
Personally I rarely access IC dApps on my desktop cause connecting my hw wallet everytime is a pain in the ass and I don’t want to enable Windows Hello cause I’d rather use a password than a PIN and even if I wanted the problem would persist when I dual boot into a Unix system.

In my opinion it would be nice if we could use a smartphone to authenticate other devices via QR code, kinda like Binance allows to login if you scan the QR code in the mobile app, a metamask like login flow (set a password and import seed just once) would also be nice, I know its not as safe, but considering you can bypass the need for biometrics or security key by using the “recover lost anchor” option everytime, I’d rather have that than type my seed phrase everytime I want to login.

Browser compatibility should also be increased, especially on mobile it can be annoying when your default browser isn’t Chrome and apps require a login, in that case you have to switch the default browser back to Chrome, login and then reset it to your preference, this has to be done everytime the auth token expires.

I also noticed a strange behaviour when removing a seed phrase, not sure if its a bug, here is what happens: if I delete a seed phrase from an II, the seed becomes invalid and can’t be used to recover the anchor, but if I open a tab to the recover identity anchor option, insert the identity anchor before removing its seed phrase and keep the tab open with the seed phrase input field the deleted seed will work, but only in that specific tab until I either use it or refresh the page.

[diegop]

Thanks for all your feedback, I will make sure folks see it.

@Zane

I also noticed a strange behaviour when removing a seed phrase, not sure if its a bug,

That is peculiar. I know the team is following this thread closely for all the advice and feedback but I wanted to proactively tell you that I am escalating this to the team.

[Maxfinity]

@Zane

Browser compatibility should also be increased, especially on mobile it can be annoying when your default browser isn’t Chrome and apps require a login, in that case you have to switch the default browser back to Chrome, login and then reset it to your preference, this has to be done everytime the auth token expires.

This is great feedback IMO. The. mobile scanner option makes a lot of sense. Biometrics tied to mobile would be much more widely applicable, coupled with a QR code.

[paulyoung]

@Zane maybe this will help in the meantime.

ani betts

Discord isn’t showing the image from the tweet in the preview, so here it is:

[nmattia]

hi, thanks for the feedback!

@Zane

Browser compatibility should also be increased, especially on mobile it can be annoying when your default browser isn’t Chrome and apps require a login, in that case you have to switch the default browser back to Chrome, login and then reset it to your preference, this has to be done everytime the auth token expires.

Can you clarify this? What is your default browser and what is the issue when you’re trying to authenticate with a browser other than chrome? do you mean that the authenticate window always opens the default browser?

[nmattia]

@Zane

if I delete a seed phrase from an II, the seed becomes invalid and can’t be used to recover the anchor, but if I open a tab to the recover identity anchor option, insert the identity anchor before removing its seed phrase and keep the tab open with the seed phrase input field the deleted seed will work, but only in that specific tab until I either use it or refresh the page.

Ah, yes! We were able to reproduce this. Looks like the frontend doesn’t fail on a bad seed phrase, and will only error out later once you make your next authenticated call (for instance adding a new device). Will fix this asap!

[Zane]

@nmattia

do you mean that the authenticate window always opens the default browser?

Correct, my main browser on mobile is Brave, everytime Distrikt requires me to login again I have to switch to Chrome, login and switch back to Brave.