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.

    lbschenkel Documentation is pretty sparse, you can find some example code but you have to piece it together mostly yourself.

    you are correct, there are central lookup servers that the relay servers fetch public key information from, they have been ddosed in the past resulting in the entire system being inaccessible.

    Croak3114

    Well, you're right that an attacker can't really steal your keys from the central server since the keys are local to each installation, but the central server is the canonical mapping between the public part of your keys and your real identity. If an attacker can somehow compromise their system and find a way to add a new public key for your account in there (whose private part they are in control of), then they can authenticate/sign stuff pretending they are you.

    This would be functionally equivalent as stealing one of your private keys, since that by law the authentication/signatures you do with MitID are legally binding and have all the usual legal effects of a regular pen signature.

    I'm sure that they have all sorts of secure logs and a digital "chain of custody" for keys (for a new key to get in there, it must be signed by another vouched key — yours or a certified attester's) but all this is assuming that everything is implemented perfectly and there are no bugs. We all know there is not such a thing, so in theory it could be done if somebody gets in and there are implementation/process flaws.

    I'm not aware of any legal cases where someone went to court and repudiated some MitID authentication, claiming it was not them who did it. In that scenario it would be very interesting to see which kind of proof MitID would present to a court in terms of logs and chain of custody to prove that the person in question did indeed authenticate with a key that is in fact theirs.

      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?