Living in Norway, I can only comment on the service, that sounds more or less equivalent to MitId, called BankId. Outages for a few hours have occurred in the past. Moreover, I do not consider it inconceivable that some major technical issue, or even a coordinated cyberattack, would cause the BankId service to suffer longer downtime, perhaps for several days.

That would effectively block private individuals from accessing and communicating with public services and banks (organizations have other means of authentication). How likely this is I don't know, although to call it an impossible scenario is in all honesty, bordering on naivety. There is practically no offline backup service.

The Norwegian BankId app luckily has no issues on GrapheneOS, in my testing, except for their (non-phishing-resistant, and therefore useless) FIDO2 passkey implementation, but so far this is not necessary for anything.

I'm going to stop my semi-off-topic rant now, but want to express that this thread has been an interesting read, and I appreciate the efforts that has been made to convince MitId to patch their software, however fundamentally broken its very existence is.

lbschenkel 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.

    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.

    I asked a developer in Denmark to test this out and he reported that on Linux Desktop Chromium, if you fully disable the User Agent Client Hints ( see here how: https://www.chromium.org/updates/ua-ch/ ), MitID works for in the browser.

    Firefox does not support the sec-ch-ua-* headers, so apparently I believe that MitID either test if there is support for the Accept-CH request or API support in Javascript and if there is it also expects the high entropy client hints.

    You can read more about this here:
    https://browserleaks.com/client-hints
    https://developer.chrome.com/docs/privacy-security/user-agent-client-hints
    https://developer.mozilla.org/en-US/docs/Web/HTTP/Client_hints#user-agent_client_hints

    18 days later

    I'm not so good in English. Iam a graphenos user living in Denmark, can somebody danish speaking help me to use mitid on pixel 7a?

    14 days later

    FYI: latest version of Vanadium (121.0.6167.101.0, alpha channel as I write this) works again with MitID: the authentication form no longer closes prematurely.

    This confirms that the problem was indeed the client-side hints. MitID expected them to be there, which Vanadium didn't send. This latest version sends spoofed values, which are enough to satisfy MitID.

      lbschenkel I am still not able to install the version you are referring to but I will check later.
      Thank you for shearing the important news!

      I can confirm it works!
      Donation deserved

      8 days later

      MitID has seemed to stop working for me (asks me to scan a QR code when its a login on my phone)
      Im on:
      Pixel 8
      GOS Ver: UQ1A.240105.004.2024012600 (latest as of 1 feb 2024)
      MitID Ver: 3.2.3 (latest as of 1 feb 2024)
      Ive tried logging in with brave, chrome and vanadium which all gives me the same results.

      I see that GOS ver 2024011600 works, but i dont know how to roll back to that version - if someone could tell me, that would (hopefully) fix my problem.

        donovxn The problem is not with GrapheneOS nor Vanadium.

        The following message is on mitid.dk right now:

        Android users may be prompted to scan a QR code on the same device as MitID app. We are working on a solution. It is possible to use another device, Eg. PC or tablet, to login

          When I tried to login with MitID ,after clicking open the app I was not prompted with insert the password and no qr code.

            lbschenkel

            Thanks, i was thinking it was an app issue too since there were a lot of negative reviews the past week with the exact same issue that I had. Pretty insane that this is the case tho...

            Grkrz Can you explain further? I dont quite understand your issue.

            donovxn The message from mitid.dk has disappeared and I was able to log-in, so... yes? Didn't you try yourself?

            My MitID app doesn't work on my main profile (no GSF and SPS installed). When I try to sign-in with MitID from my PC and open my MitID app on my phone it never receives the request to authenticate the session. It just stays on the "Ready to use" screen for about one minute and then crashes.

            Does anyone have any ideas to thinks i coul'd / shoul'd try.

            MitID is installed with the following settings:

            Allowed permissions:
            • Camera
            • Network
            • Notifications
            • Sensors
            Not Allowed:
            • Phone
            Other settings:

            Alarms & reminders: Not allowed
            Exploit protection compatibility mode: Enabled
            Hardened memmory allocator: Disabled
            Native Code debugging: Allowed

            Phone: Pixel 7
            GOS version: 2024012600
            MitID version: 3.2.3

            15 days later

            And there's a new version of MitID in the Play Store: 3.3.1. Do we have any volunteers that are willing to risk their installation and upgrade to this version? Please report your findings.

              lbschenkel I just updated to 3.3.1 and hence my post above yours, I still hare trouble getting MitID to work in my main profile without Google Play.

              In my second profile with google play services, MitID version 3.3.1 works.

              Vanadium: 122.0.6261.43.0
              GOS: 2024020500

              Update: Actually it seems that 3.3.1 partially solves my problem in my non-GSF profile. Now I can at least approve login requests made from another device. Still no luck with login requests made from vanadium though.