Important Community Update on ic0.app domain being flagged by an anti-spam blocklist

[Denis]

@bjoern

The browser wallet will have the cryptographic key in memory every time you make transactions.

Okay, thanks for clarifying. I was aware of the risks at the user end, your post just got me worried there were risks at the NNS website / Internet Identity end that I was unaware of that were similar to the risks involved with browser wallets like Metamask.

[Roman]

Hi @bjoern,

Thank you for your answer.

@bjoern

We are currently designing a scheme that allows any canister on the Internet Computer to use the ICP hardware wallet app for securely displaying and signing transactions, and that would work as follows:

• The canister developer specifies for each pair of (canister id, method name) a schema for rendering the parameters. That would likely be a transaction name and a structure that specifies for each field of the Candid argument whether it should be displayed and the title that should be used. (We need to devise a format for this, this actually is the main open design task.)
• The canister then signs said schema with the IC’s threshold ECDSA signature method.
• The dapp front end sends the unsigned transaction along with the signed schema to the hardware wallet.
• The hardware wallet derives the canister’s ECDSA public key from the IC’s ECDSA root public key and the canister id, and verifies the signature on the schema. It then uses the schema to display the transaction to the user, and signs the transaction when the user approves.

Does this mean that we can hope hold our NFT through the Ledger Hardwallet soon ? If yes, it is marvelous, and what would the timeline be (approximatively of course) ?

[skilesare]

@lastmjs

I wish I had known/understood this back in 2021. I feel like the marketing/eduction around II vs hardware wallets wasn’t really present, or at least I missed it. Seems to me that most of the lay people in the community believe (believed?) II to be extremely secure. It’s only after digging in that we discover these flaws.

I also don’t understand why we still don’t have the signing of cbor messages with ledger available. we should be able to interact with certain sites with our ledger.

[hokosugi]

Among the authentication types of Internet Identity, Security key is the most secure because it never passes through the browser or memory, and biometric authentication is equally secure because it is stored in the hardware chip (TPM) in the PC. However, the seed phrase is less secure because it is temporarily stored in memory when it is generated and then deleted.

Security key >= biometric >> seed phrase

Seed phrase with low security is problematic, so security key is recommended, is that correct?

Even so, it is more secure than browser-based wallets like Metamask and Plug. Because,

• Seed phrase is a one-time use of memory (and then deleted), while browser-based wallets are stored in memory for each signature to tx.

• Browser-based wallets do not store the private key in the TPM like biometric authentication, but rather store it encrypted in the local storage of the browser, which is less secure ( I could be wrong).

However, the most secure one is a hardware wallet like Security key, which does not pass the private key through browser or memory, and verifies and displays the tx on the hardware, so we are considering to develop it so that we can use it. Is that correct?

hardware wallet(ongoing) > Security key >= biometric > seed phrase >> browser-based wallets

[lastmjs]

Depends on the application for II because of the ephemeral private key stored in local storage. This is even worse than MetaMask. That key can do anything that the II can do, so your WebAuthN device isn’t providing any security after you’ve logged in.

What would be amazing is if we could require additional verification from a WebAuthN device for certain actions.

[bjoern]

II never stores key material in local storage. That’s why you have to re-authenticate on every login.

[bjoern]

@blabagastered

The particular one, without attempting a detailed evaluation of the proposed solution, is that I worry about the timing (ie when might this be available for use in production, especially considering adopting this approach to security may require re-modelling an application’s flow, data structure, architecture, and extra work aside, it can really only begin once this is totally finished), and also worry about the reliance on threshold signing as currently implemented (see for example from 48:00 here https://twitter.com/i/spaces/1gqxvyREnwlJB?s=20 together with (Discord ) ), which sort of steps on the general:

It’s probably realistic to build this functionality in the Ledger application in a few months. The additional implementation effort is moderate, but such an update will have to go through a security review with Ledger, which will usually take a while.

Regarding the concerns with threshold ECDSA signing: We are following three different paths toward improving the security over time:

1. Diversifying the set of node providers (NPs). If you have been following NNS proposals recently, you must have seen several proposals registering new NPs. So the IC is getting more diversity in its nodes, which will allow the NNS to improve the diversity of nodes in the subnets that host the threshold keys, and also grow that subnet over time. As with anything organic, that just needs a bit of time to grow.
2. Supporting trusted execution environments (TEEs). We are building support for AMD’s SEV-SNP in the node deployments, which provide some additional security against potentially malicious NPs. This work is in progress, and will play well with the new “Gen 2” node architecture that the new NPs are rolling out.
3. Threshold trade-off: We can parameterize the protocol to achieve better security (meaning: improved resilience in terms of number of NPs that have to collude to create a signature) at the cost of weaker liveness (less misbehaving NPs could stop the subnet from issuing signatures). This is a protocol-level improvement that is orthogonal to the above two.

The general is that, without knowing the foundation’s work from within or the core protocol in any detail, my impression is that the number, breadth and depth of security vulnerabilities in the system, understood as broadly as possible, ie in the only way in which it makes sense to understand it in production, in “the real world”, appears to be large enough that perhaps all work should be suspended, on every sphere of the foundation’s technical efforts, until all major security concerns have been addressed and fixed to a point such that a dapp deployed on the IC, with its then existing implementation (not a future imagined one) is comparably secure to what is achieved by competing systems today.

I don’t think that this is fair, on multiple levels. First, there is (and has always been) ongoing work toward improving the security of ICP, in several components and aspects. We have made significant improvements since launch, and we will continue doing so. This work often receives less publicity, of course, since in many cases it is just invisible to users.

Second, you seem to imply that deploying on the IC was generally less secure than on “competing systems.” The statement is vague and thus hard to respond to, but I would guess that such comparisons are generally hard because they tend to compare apples with oranges. Anyway, I’d be interested to know what you had in mind.

Third, it would be infeasible (and not helpful either) to now stop all the work we are doing and focus on a single aspect, like security. Are there security aspects we have to work on? Absolutely! But so are aspects of scalability (e.g., number of neurons in the governance canister, number of canisters on a subnet, size of the state a subnet can handle), developer experience, and so forth.

[lastmjs]

The ephemeral keys must be stored somewhere accessible to the domain (accessible to its JS) so that signing can occur, I don’t understand this.

My understanding is there is a keypair created on every login that can sign for the II. That key is not protected by hardware and is accessible to JS and thus XSS or other similar attacks.

[blabagastered]

@bjoern

Anyway, I’d be interested to know what you had in mind.

I’ve got a page or two of notes on security concerns I’ve come across while building the prototype of Backed USD, but managed to make myself busy again and don’t have time to flesh it out now. I hope to within a week or so.

For now, I’ll just dispel a couple of possible misunderstanding, plus stating that the fact that there is no way to securely connect to a dapp is alone probably enough to concede that the system is not “as secure as competing systems” today.

First, as a relative newcomer I have no idea why the foundation has chosen to do the things it’s done: all I know is you’ve managed to create a groundbreaking system that mostly works. What I mean is only that, as you know, the world doesn’t care about how efficiently we allocate resources or how diligently we work: it only cares about the outcome, the concrete offering. What I mean is I don’t claim there haven’t been security improvements, perhaps massive ones that have required great effort and dexterity. I only claim that if those don’t amount to equal or better than the alternative, we’re in trouble. In particular, I mean no criticism of the foundation or its work (I don’t understand it well enough internally to comment): I only mean that the situation we’re in, the state of the network, is vulnerable to several attacks for a host of reasons, regardless of how much or how little work or improvements or what reasons have led to it.

1, 2, 3 above are important improvements (I understand 3 less well). They help.

Regarding

@bjoern

it would be infeasible (and not helpful either) to now stop all the work we are doing and focus on a single aspect, like security

Maybe, I don’t know, that’s why I say “perhaps”, and “appears to be”. But also, maybe not, and perhaps the situation is such that really an exclusive focus on security would make sense for a while. It is not at all obvious to me from what I’ve seen.

If all goes well I hope to be back with a more detailed response soon.

[bjoern]

@blabagastered

I’ve got a page or two of notes on security concerns I’ve come across while building the prototype of Backed USD, but managed to make myself busy again and don’t have time to flesh it out now. I hope to within a week or so.

That would be very helpful – looking forward to that!

[bjoern]

@lastmjs

The ephemeral keys must be stored somewhere accessible to the domain (accessible to its JS) so that signing can occur, I don’t understand this.

There is an ephemeral key that is kept in memory, which is created for each session. I just checked that we are currently using a key that is actually accessible to JS, it seems preferable to use a type of key where at least the private key cannot be extracted from JS. I’ll check with the team when they plan to migrate there. Either way, this is entirely in the origin of II, and we intentionally keep the codebase of II small and simple.

[dfisher]

Why is using an air gapped device more secure than a hardware wallet?

[diegop]

Not an expert like Bjoern is but i interpreted his statement that air gapped removes the potential of a bug in the hardware wallet.

Air gap has no internet connection so no potential for bugs (hardware wallets have very limited basic software, but still software) or hardware design flaws to affect you.

[apotheosis]

Hey - we switched all of our domains to icp0.io last week because of this warning… we come back after the weekend to find users complaining that domain throws errors on their browsers and the original domain ic0.app does not… what is going on here?

Which one should be used as of 2-28-2023?

[apotheosis]

For icp0.io domain…

[jwendling]

Hey apotheosis!

Unfortunately, we discovered that the domain icp0.io, which we recently introduced as an alternative default domain, has been used for malicious content.

As a result the following providers/products have flagged raw.icp0.io (only the subdomain raw) on their list as spam/phishing:

• Google Safebrowsing
• Netcraft
• Kaspersky
• Emisoft

We will work with the providers/products and were already able to remove the entry of Netcraft, Kaspersky and Emisoft.

Update: Sorry mixed the domains in my original post. It’s now updated to raw.icp0.io.

[apotheosis]

Thanks🙏 switching back to the old one.

[jwendling]

Depending on how much effort it is for you to switch and how much you rely on raw URL, I would suggest to not switch back yet, because the same risk also applies to ic0.app, as we experienced with the Spamhaus listing.
In general its highly recommended to use custom domains to not rely on either of them.

Update: Just double checked your canister id from the screenshot and Kinic is indeed a special use case. So in your case switching definitely makes sense.

[Denis]

@jwendling

Unfortunately, we discovered that the domain icp0.io, which we recently introduced as an alternative default domain, has been used for malicious content.

This will keep happening with every domain. It’s a trivially simple attack vector that is now widely known. I reiterate what I suggested upthread:
“Have a domain reserved for core services and apps. Perhaps an NNS vote could be required to have a site on that core services domain, making it a community whitelisted IC. That way, we avoid having to censor while also sealing off any nonsense that goes on in the wider network from systemically important services. Because making a malicious website or app is extremely easy. Now that this issue is public, people will do it just to sabotage the IC.”

[jwendling]

Good news: raw.icp0.io is not listed on Google Safe Browsing anymore and the red warning should disappear.