Mobilt kørekort QR-koder: ISO/IEC 18013-5

Hvad er standarden

ISO/IEC 18013-5:2021, Personlig identifikation, ISO-kompatibelt kørekort, Del 5: Mobilt kørekort (mDL) applikation. Den internationale standard, der specificerer, hvordan digitale kørekort udstedes, opbevares, overføres til en verifikator og verificeres offline. QR-kodens overflade (den del, de fleste mennesker ser) er afsnit 8.2 "Enhedshentning, QR-kodekoblingsmodul". En ledsagestandard, ISO/IEC 18013-7, dækker online-hentning (verifikatoren forespørger udstederen direkte med indehaverens samtykke).

Anvendelsen er godt i gang: et dusin amerikanske stater har produktions- eller pilot-mDL'er i Apple Wallet og Google Wallet; Californiens mDL er i fuld tilgængelighed; TSA accepterer mDL'er ved sikkerhedskontrollen på de fleste større amerikanske lufthavne; EU indfører sin variant i EUDI Wallet under eIDAS 2.0 (forordning trådte i kraft sidst i 2024, punge forfalder 2026-2027). Standarden er også grundlaget for ISO/IEC 23220 (generelt mobil-legitimationsramme, der dækker mere end bare kørekort).

Hvad der faktisk er inde i QR-koden

mDL QR-koden koder en DeviceEngagement CBOR-struktur. CBOR (Concise Binary Object Representation, RFC 8949) er et kompakt binært alternativ til JSON. Den afkodede struktur ser omtrent sådan ud:

{
  0: "1.0",                         // version
  1: [1, 2, [eDeviceKey bytes]],    // security: cipher suite 1, EC P-256 key
  2: [                              // device retrieval methods
    [1, 1, {...NFC options...}],
    [2, 1, {...BLE options...}],
    [3, 1, {...Wi-Fi Aware options...}]
  ],
  3: {...optional server retrieval...}
}

Nøglefelter, afkodet:

Hvad adskiller dette fra AAMVA PDF417 på plastikkortet?

Det er en anden kategori af legitimation. AAMVA PDF417-stregkoden på bagsiden af et amerikansk plastikkort indeholder alle kortets attributter i klartekst – navn, adresse, fødselsdato, kørekortnummer, højde, vægt, øjenfarve, begrænsninger, organdonor-flag. Enhver scanner kan læse alt. Kortet er en "alt eller intet"-legitimation: du overgiver det enten og afslører alt, eller også gør du det ikke.

Et mDL vender det om. QR-koden indeholder ingen attributter – kun et håndtryk. Verifikatoren skal bede om specifikke attributter (given_name, family_name, birth_date, age_over_21, portrait, document_number, driving_privileges osv.), pungen viser dig anmodningen, og kun de attributter, du godkender, overføres. Overførslen er også kryptografisk underskrevet af udstedermyndigheden (din statens DMV), så verifikatoren kan bekræfte, at attributterne er ægte uden at ringe hjem – offline-verifikation virker.

Det er grunden til, at de, der bekymrer sig om privatlivets fred, foretrækker mDL'er, selv om standarden er mere kompleks: den muliggør videregivelse afpasset transaktionen. En dørmand behøver ikke din adresse; en TSA-betjent behøver ikke din organdonor-status; en 7-Eleven-ekspedient behøver ikke dit kørekortnummer.

Selektiv videregivelse: den egentlige pointe

mDL-standarden definerer et sæt afledte attributter, der lader verifikatoren stille et ja/nej-spørgsmål i stedet for at få en råværdi. De vigtigste:

• age_over_18, age_over_21, age_over_65 – til aldersgatedede køb uden at afsløre fødselsdato.
• resident_state – til spørgsmålet "er du statsborger?" uden at afsløre adresse.
• driving_privileges – licens-klasse og begrænsninger; til biludlejning.

En veldesignet verifikatorapp til en bar beder kun om age_over_21. Pungen viser "Bar XYZ ønsker at vide, om du er over 21." Du trykker Godkend, og en enkelt underskrevet boolsk ("sandt") sendes tilbage. Barens app verificerer signaturen mod din statens offentliggjorte mDL-tillidsrod. Færdig. Ingen fødselsdato, intet navn, intet kørekortnummer, intet foto. Sammenlignet med at overlevere plastikkortet er dette en massiv privatlivsforbedring.

Fjendtlige verifikatorer: den nye trusselmodel

Trusselmodellen for plastikkortet var enkel: mist det, få det kopieret, få det kigget over skulderen. mDL-trusselmodellen er anderledes. Formatet er stærkt; kryptografien er solid; risikoen skifter til verifikatorappen på den anden side af transaktionen.

Hvem som helst kan bygge en verifikatorapp. Der er ingen central licensmyndighed. Så en bar kan køre en standardverifikator konfigureret til at bede om fuld fødselsdato, fuldt navn og foto, selv om den kun har brug for age_over_21. En bilудlejnings-ekspedient kan bede om alt "til sagsakten". En butiksekspedient kan bede om adressen. Intet af dette er teknisk forbudt ifølge standarden – standarden siger blot, at pungen skal vise indehaveren, hvad der anmodes om, og kræve eksplicit godkendelse.

Forsvaret ligger altså på indehaverens side: læs anmodningsprompten. Hvis verifikatoren beder om mere, end transaktionen kræver, afvis. Visse punge advarer, når verifikatoren ikke er på en kendt tillidsiste; ISO/IEC 18013-5 understøtter verifikatorautentificering via certifikater, men tillidslisteinfrastrukturen modnes stadig (per-stats lister i USA; EU-tillidsiste under eIDAS 2.0).

Værd at vide: verifikatoren ser din eDeviceKey, cipher suiten og hvilke overførselsmetoder du understøtter – det er alt. De får ikke attributter fra QR-koden alene. Så at scanne en QR-kode fra et klistermærke eller en andens skærm og gå derfra giver en angriber intet nyttigt. Attributterne rejser kun inden i den krypterede session efter håndtrykket.

Hvad vores scanner viser dig

Slip en mDL DeviceEngagement QR-kode (billede, indsæt eller kamera) ind i vores scanner. Resultatet viser:

• Standard – ISO/IEC 18013-5 §8.2 DeviceEngagement (CBOR).
• Version – normalt 1.0.
• Cipher suite – den navngivne cipher suite (P-256 / brainpool / osv.).
• Overførselsmetoder – hvilke kanaler pungen tilbyder (NFC, BLE, Wi-Fi Aware).
• Server-hentningsvært – hvis pungen tilbyder 18013-7-tilstand, hvilken udsteder-URL der ville håndtere attributanmodninger.
• eDeviceKey-længde – bekræfter at nøglen er til stede og velformet, uden at gentage bytesne.

Vi afkoder IKKE nogen attributter – der er ingen attributter i QR-koden, af design. De faktiske licensdata ville rejse krypteret via den valgte overførselsmetode til en rigtig verifikator.

Afkodning sker i din browser; kun de strukturelle metadata sendes til vores server til sikkerhedsklassificering.

Inden du godkender en verifikatorsanmodning

• Læs anmodningsprompten. Din pung er ifølge standarden forpligtet til at vise dig den fulde liste over anmodede attributter. Læs den.
• Matcher anmodningen transaktionen? En bartender, der beder om den fulde fødselsdato i stedet for age_over_21 = afvis eller spørg hvorfor. En bilудlejnings-ekspedient, der beder om organdonor-status = afvis.
• Er verifikatoren på en tillidsiste? Visse punge viser et flueben for kendte verifikatorer (udstedte certifikater fra din statens DMV-tillidsrod). Ukendte verifikatorer bør give dig anledning til eftertanke.
• Online-hentning (18013-7) er mere kraftfuld og mere invasiv. Hvis pungen spørger, om du vil lade verificereren forespørge din statens DMV direkte, opretter det et revisionsspor hos DMV. Fint til visse transaktioner (TSA, officielle ID-checks), unødvendigt til andre (køb af øl).
• Du kan altid sige nej. Hele pointen med selektiv videregivelse er, at du styrer, hvad der forlader din telefon. Hvis en verifikator ikke vil acceptere en reduceret videregivelse, kan du falde tilbage til plastikkortet eller gå fra transaktionen.

Relateret

• AAMVA kørekort PDF417 – plastikkortet stregkode, dette format erstatter.
• FIDO2 adgangsnøgle QR – endnu en krydsenheds-håndtryk-QR.
• QR-svindel at holde øje med i 2026
• Alle QR-standarder vi tjekker
• Fuld dækning