Verifying the code of the Internet Identity service (a walk-through)

You probably have used to log into various applications (the NNS UI, OpenChat etc.) before, and if you do that, you are trusting this service to take good care of your credentials. Furthermore, you might want to check that the Internet Identity is really not tracking you. So you want to know: Is this really running the code we claim it to run? Of course the following applies to other canisters as well, but I’ll stick to the Internet Identity in this case.

I’ll walk you through the steps of verifying that.

I wanted to post this here directly, but somehow the forum website didn’t like the post (maybe some XSS protection filter got triggered?), so I put it on my blog:

It has since also been published on the official DFINITY medium blog:


Hey, really helpfull feature. Is it on the roadmap to implement a history of all the hashes of all the wasm modules deployed to one canister (every update of the code). If this would be possible then one have guaranties that an malicious canister owner can’t update the canister with malicious code for some short time and then update again with good code.

Good question. The Internet Computer generally doesn’t store a lot of history, and that’s by design.

In most cases, you would look at who the controller is and whether you can trust them. For example, if it’s another canister that would keep such a history.

Eventually I could imagine the system keeping a module version counter. That way, new installations are noticable, and even an untrustworthy party could keep a trustworthy record of previously installed code versions.

1 Like

So I followed your blog to verify the internet identity service code. (docker version 20.10.11 on Ubuntu 20.04). The two methods of producing sha256sum for the CURRENT wasm do not seem to match.

FROM THE PAST: I was able to reproduce the build from the commit mentioned in your 5 month old article. i.e. the SHA256SUM was the same as mentioned in your article: d4af92…c04.

I used the Update (3 days ago) with the commit 1373a5876d2fe0b32d98de3b3d52d62c792b7cc1 as it seemed to have the latest commit.

The dfx reported hash:
through dfx canister --no-wallet --network ic info rdmx6-jaaaa-aaaaa-aaadq-cai

The docker build reported hash:
through sudo docker build -t internet-identity-service .

Since the hashs are different, I conclude that I am running a different commit when I am building internet identity service. Can you please let me know which, more recent commit should I be using?

1 Like

Reproducibility with docker isn’t perfect, because it’s not a hermetic build environment, and other effects, so it might be that it’s the right commit. I’ll let the II devs comment, though.

Yes…from II github…" We try to achieve some level of reproducibility using a Dockerized build environment. The following steps should build the official Wasm image."

The word should has been emphasized in github. However how does a third party (me) verify deployed wasm is true to intent is the key question.

1 Like

Hope :slight_smile:

And, as you did, complain if it didn’t! It would be good if others try to do the same, and see if they get your hash or the deployed one, this way we can narrow down whether it’s a problem with your local setup (no offense, of course!), or reproducing in general, or if someone tampered with the source. (Can’t do it myself right now, I’m away from a computer.)

I’m general, making builds reproducible is hard, and even more so with non-hermetic build systems. Nix fares better, but unfortunately reproducibility wasn’t valued enough to make the org stick to it despite it’s downsides.


@diegop could you please mark ii devs into this…they might not reading each post. It is important to have third party verified builds ; not just for core nns and ii canisters; but at large. I can start with core ii canister.

icdev2dev has already created an issue at the appropriate repo: