Status of MitID app

zfnmxt I noticed that the latest 20231023 release is no longer experimental for Pixel 8. Are you willing to upgrade to this release and test the two scenarios below?

1. checking if MitID 3.1.1 still works (I expect it will, there is no reason to break)
2. upgrading to MitID 3.2.1 to see if it works now

Naturally you may lose your MitID if step 2 does not work, will need to uninstall, reinstall 3.1.1 and re-enroll. I'm not sure if you're willing to do that.

Otherwise it would be nice if anybody who has a Pixel 8 + 20231023 could try installing MitID and reporting if it crashes or if it shows any error message during startup.

I can confirm that MitID login flow is currently broken in Vanadium: the MitID app itself works but when control is back to Vanadium, it does not redirect to the post-login page.

I could reproduce this when trying to login in mitid.dk and when trying to login in my bank app. Switching default browser to either Firefox or Chrome fixed the issue.

I tried to relax every possible setting in Vanadium but I could still not make it work.

Note that I am 100% certain that Vanadium used to work months ago. In fact, to login to my bank app I was forced to change default browser from Firefox to Vanadium because with Firefox it always got stuck in the post-login phase, in a similar way that it is happening now. Now the situation has reversed.

I am not quite sure if this is due to something changing in Vanadium, or due to the changes that happened with the MitID login flow when the barcodes were introduced. It used to be that you could login by entering your name and manually switching to the MitID app to authenticate; now you are forced to push the button to open the app from the login form. This change might have been the one that stopped working in Vanadium for whatever reason. I'm inclined to say that either way, this is a Vanadium bug.

GrapheneOS I'm a developer myself, so I completely agree with you on technical matters. That said, let me clarify.

What I wrote before:

I'm inclined to say that either way, this is a Vanadium bug.

Mea culpa. Re-reading this now, what I should have written to express what I had in mind was either way, this is a regression likely triggered by a Vanadium change. I did not really meant to lay the blame on Vanadium, I just wanted to express that:

• I'm completely sure that Vanadium used to work
• Then at some point it stopped working (not sure when, I re-tested when I saw the reports here)
• Other Chromium-based browsers still work
• I checked the commit log in Vanadium and I seemed possible that some of the changes from when it used to work may have upset MitID

I'm happy that you finally clarified that additional hardening in Vanadium regarding the headers is what triggered the change in behaviour from the MitID side. This proves that my hunch was right.

It's incredibly strange to start blaming something you say happened in Firefox with it before on Vanadium now.

No, it's not "incredibly strange". It's exactly what was happening:

• In the past, it was not possible to log in with MitID inside any app if Firefox was the default browser in the phone (as it becomes the default in-app browser as well). After authentication, when the control was sent back to the app, the app couldn't detect that the log-in succeeded. Note that this was only for apps; authentication in Firefox itself (for websites) was working.
• Changing the default browser to Vanadium (which became also the default in-app browser) fixed the authentication issue for apps. Authentication for websites also worked.
• At some point, Firefox started working, both in websites and as the in-app browser inside other apps.
• Now Vanadium no longer works, neither in websites, nor inside other apps.

This is not laying blame. I was just stating the facts: for authenticating with MitID, Firefox used to be broken and Vanadium used to work, and now the situation has reversed and Firefox works but Vanadium doesn't.

I have enough experience with MitID that 99% of the time the problem is with MitID. But more often than not, it's also true that changes elsewhere trigger some overzealous security theater MitID checks. When that's the case, even though the blame almost always lies with MitID, it's often important to understand what changed and how it upset MitID (to report it to them and to see what's the best workaround).

Ask them to fix their buggy software again. They seem to be willing to do that since they fixed all the other issues in the past eventually.

Report them problem to them and emphasize that supporting only specific browsers is anti-competitive.

I have done this multiple times and I am still doing it. But to get the message across, each time MitID stops working we need to understand (1) what broke this time and (2) why it broke now so we can formulate in some way that hopefully they can understand. Hence the discussions here.

To conclude, @GrapheneOS, I would like to express a few extra points:

• We all love GrapheneOS, that's why we use it and that's why we're here.
• This thread is for the community to find solutions, not a support request towards GOS developers, so please assume good intentions by default. Nobody is trying to blame GOS (even if poorly worded, see above) — and we do understand that almost every change made to GOS is to improve privacy for users — but at the same time I am trying to understand any GOS changes that may start tripping MitID: (1) because I'm a curious technical person and (2) to document this for other users.
• No matter how brain-dead MitID is (and I do completely agree with you regarding all technical points), it's very difficult for someone not living in Denmark to grasp how essential MitID is to daily life. It's not an app that you use simply for convenience. This is basically a digital version of your ID and you need it to authenticate with virtually every important local service, even offline ones (for example, if you try to call your bank they will not do anything before they validate your identity with MitID). The Nordic countries have almost completely moved towards a society that is cashless and almost every service is digital only, and you must be authenticated via a government-mandated authentication solution that is tied to your real identity (MitID in the case of Denmark).
  So it's not a question of stopping to use apps, or changing banks, or changing services, because all of them use MitID. That is why we're so eager to discuss any breakages here, because it impacts us strongly and at the same time we love GOS and want to keep using it if we can without having to carry an alternative device for the sake of MitID only.
  P.S.: Don't shoot the messenger, I'm just stating how things are, not that the should be this way. Unfortunately, I'm powerless to change this status quo and I have to live within these parameters.

To clarify how this app works, for whoever is not an user:

First you need to activate it, which binds that particular installation to your real life identity. To activate it you need to authenticate with MitID in a different device, or scan the chip your passport, or go in person to a government office and bring ID documents for them to validate who you are.

Then to authenticate, there may be requests that come out of band (from outside the phone) or in band (inside the phone).

Out of band requests can be two ways:

1. You trigger it by trying to login on a website in a different device, such as your computer. The login flow will show a QR code (which changes every few seconds) that you scan with the MitID app, then you authenticate, and the login flow detects it and continues.
2. Some entity like your bank can trigger an authentication request directly against MitID. For example you call them, they want to know that you are you, and then you open the app and the app shows an incoming request from your bank.

In-band requests involve MitID being launched by the requesting app via a specific intent. In practice the app will always be a browser (standalone or in-app view), because the MitID login flow always involves opening a browser pointing to their server-side login form. The difference is that this form will have a button to trigger the intent, instead of showing a QR code (that you obviously can't scan within the same device).

The reason for the ever-changing QR code and the intent is to decrease the chance of the user being tricked into authenticating on behalf of someone else: a specific action must be done by the user in the phone; requests won't be coming out of the blue (barring a few scenarios such as when you're in the middle of a phone call with your bank).

What has been discussed recently is that the in-band flow broke with Vanadium, since the MitID server-side form doesn't like it due to differences on the headers Vanadium sends. The app itself works, and you can authenticate normally if the request reaches it. So it's an inconvenience of not being able to use Vanadium when browsing to some websites that require MitID (minor concern, you can use a different browser for only those), nor using Vanadium as the default web browser because it is then used by all apps (bigger concern, if you want to use Vanadium for daily browsing).

Therefore, the current workarounds for using MitID app with GOS:

• login to the websites using a different device (computer, another phone), scan QR code using app
• when browsing in the phone, and need to authenticate, use a different browser for that website
• when using an app in the phone, and need to authenticate
  • do not set Vanadium as the default browser
  • change the browser temporarily to another one, authenticate, and then change back

Croak3114 Ever service uses their own relay server to validate requests, so its not possible to have a full wide-spread downtime by compromising some centralized service.

Is there more documentation somewhere about how this works? I'm confused about this statement, because although you do have the private part of the secret on your device, the relay server needs to verify the data coming from the client against the public part, and unless each relay has a copy/cache of everybody's public keys, then it must necessarily contact a central server, at the very least to fetch keys that it doesn't know about. What am I missing here?

de0u As an outsider, I'm curious... what happens if the system goes down for a few hours? Do people just freeze wherever they are and meditate?

Pretty much. But to be fair, in 10+ years I've never experienced an outage of the previous system (NemID) and the new one (MitID). If there was one, I was lucky enough not to need it while it was offline. Those are small countries with small populations, it's way easier to design and maintain systems that can cope compared to countries with much greater needs such as China, India, US, Brazil with 100+ million people and multiple timezones.

Croak3114

What? I know how asymmetrical encryption works. I am a professional software developer and I have implemented many systems using cryptography (including authentication schemes) for multiple companies.

You always have a private part and a public part. The public part is, well, public, and in real life the public key is not useful as an identity in itself so there is a mapping between a public key and some sort of identity (account, etc.). In the web that is a X.509 certificate binding the key to a domain name. In MitID the central server must necessarily map your public key to your real life identity (CPR number), otherwise they can't possibly know who is (as in: the person) authenticating.

Either the server fully maintains this mapping from public key to CPR number, or the client stores it but the central server must sign that mapping somehow for the client to store, because when the installation is first activated the client is not yet trusted, and it cannot simply claim it belongs to any particular CPR number. The client must send proof to the server (like the chip you can scan from your passport), or another party (like a bank or the government) has to vouch for it.

In both cases, the actual binding from the key to the identity happens at the server. It either stores the binding itself as a mapping by remembering which keys map to which CPRs, or sends the binding back to the client to store as a signed piece of data, or both.

It follows that if an attacker who manages to get the necessary access to MitID servers (inside job, implementation bugs), they could do the following:

• if MitID stores the mappings centrally, manage to insert a new key->CPR mapping to their database where the key is the public key of the attacker-generated key pair and the CPR is the CPR of the victim
• if MitID signs the bindings for the client, trick the server into signing a new key->CPR mapping (key=attacker, CPR=victim) for the attacker's client to store, which will be trusted later by the validation servers as it's a genuine binding signed by the official MitID server

Both cases would result in the attacker impersonating a specific person by enrolling a new key into their identity. You don't need to steal anybody's private key to do that.

No they cant, that's not how asymmetrical encryption works. I can only speak for how its implemented in my country, but the scenario you described is fully impossible.

This is mathematics, there's nothing country-specific about it. Fully impossible simply doesn't exist. The hardest part of cryptography is key management.

P.S.: And the simplest attack of all, is just the plain old denial-of-service: bring the servers offline and the whole country stops. Bonus points if the servers maintain the mappings, because if you find a way to delete the database then it's not enough to bring the service up again, the whole country needs to re-create their keys and re-activate.

lbschenkel WARNING: do not install this alpha; I just realized that all apps that use the webview broke: https://discuss.grapheneos.org/d/10493-vanadium-version-121061671010-released/2