Standardy · Mobilní řidičský průkaz (mDL)

QR kódy mobilních řidičských průkazů: ISO/IEC 18013-5

Když barman, pracovník TSA nebo pracovník půjčovny aut naskenuje QR kód z aplikace průkazu vašeho telefonu, nevidí vaše data. Vidí handshake. Tato stránka vysvětluje protokol, co je v QR kódu zakódováno a jak selektivní zveřejnění skutečně funguje.

Zkontrolovat QR kód mDL → Všechny standardy →

Co je standardem

ISO/IEC 18013-5:2021, Osobní identifikace, Řidičský průkaz v souladu s ISO. Vypracovaný pracovní skupinou ISO TC204 (Inteligentní dopravní systémy) za účasti AAMVA, orgánů vydávajících průkazy v Evropě, USA a Asii a výrobců mobilních peněženek (Apple, Google, Samsung).

Přijetí je v plném proudu: tucet amerických států má produkční nebo pilotní vydávání mDL (AZ, CO, GA, HI, IA, KY, MD, MO, OH, UT, VA, WA). Podpora Apple Wallet a Google Wallet je dostupná v produkci. Přijetí TSA pro vstupenky na lety probíhá.

Co je skutečně uvnitř QR kódu

QR kód mDL kóduje strukturu DeviceEngagement CBOR. CBOR (Concise Binary Object Representation) je binární formát podobný JSONu, zvolený pro jeho kompaktnost. Struktura DeviceEngagement říká verifikátoru: "Tady je způsob, jak navázat zabezpečený kanál k mé peněžence."

{
  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...}
}

Klíčová pole, dekódovaná:

Verze

Pro aktuální nasazení vždy "1.0". Budoucí revize mohou toto číslo zvýšit.

Šifrovací sada

Aktuálně vždy 1: ECDH klíčová dohoda na P-256, AES-GCM šifrování relace. Budoucí revize mohou přidat brainpool P-256 nebo P-384 pro jurisdikce vyžadující tyto křivky.

eDeviceKey

Efemérní veřejný klíč EC generovaný pro každou relaci peněženkou. Ověřitel ho použije k navázání šifrované relace. Po transakci se zneplatní. Náš skener zobrazuje délku tohoto pole, ale nikdy nezrcadlí samotné bajty klíče – jsou efemérní a mají smysl jen pro právě probíhající relaci ověřovatele.

Metody přenosu

Peněženka říká verifikátoru, které kanály je ochotna použít pro skutečný přenos dat atributů: BLE (Bluetooth), NFC nebo WiFi Aware. QR kód sám o sobě žádná data atributů nepřenáší.

Načítání ze serveru (volitelné)

Pokud je přítomno, peněženka podporuje režim 18013-7: verifikátor může požádat o atributy přes HTTPS místo BLE/NFC. Tato část nese základní URL peněženkového serveru.

Jak se liší od AAMVA PDF417 na plastové kartě?

Jde o jinou kategorii přihlašovacích údajů. Plastový průkaz PDF417 vašeho státu kóduje úplné atributy přímo do čárového kódu — jméno, adresu, datum narození, číslo průkazu, fotografii — vše najednou. Kdokoli, kdo naskenuje tento čárový kód, přečte vše.

mDL to obrací. QR kód neobsahuje žádné atributy, pouze handshake. Ověřovatel musí požádat o konkrétní atributy (given_name, family_name, birth_date, age_over_21, portrait, document_number, driving_privileges atd.), peněženka vám žádost zobrazí a přeneseny jsou pouze atributy, které schválíte. Přenos je navíc kryptograficky podepsán vydávajícím orgánem (vaším státním DMV), takže ověřovatel může potvrdit pravost atributů bez volání domů – ověření funguje offline.

Proto lidé, kteří dbají na soukromí, dávají přednost mDL, i když je standard mladší a přijetí je nerovnoměrné.

Selektivní zveřejnění: skutečný smysl

Standard mDL definuje sadu odvozených atributů, které umožňují peněžence odpovídat na konkrétní otázky, aniž by odhalila příslušné pole nezpracovaných dat. Jsou to:

Dobře navržená verifikátorská aplikace pro bar žádá pouze age_over_21. Peněženka odpoví booleovskou hodnotou. Verifikátor nikdy nevidí vaše datum narození, fotografii ani číslo průkazu.

Nepřátelští verifikátoři: nový model hrozby

Model hrozeb plastové karty byl jednoduchý: ztratíte ji, zkopírují ji, přečtou ji přes rameno. Model hrozeb mDL je jiný. Formát je silný, kryptografie je spolehlivá; riziko se přesouvá na aplikaci ověřovatele na druhé straně transakce.

Aplikaci ověřovatele může vytvořit kdokoli. Neexistuje žádný centrální licenční úřad. Bar tedy může provozovat hotový ověřovatel nakonfigurovaný tak, aby žádal o úplné datum narození, celé jméno a fotografii, přestože potřebuje pouze age_over_21. Pracovník půjčovny aut může žádat o vše „pro spis“. Prodavač může žádat o adresu. Nic z toho standard technicky nezakazuje – standard jen říká, že peněženka musí držiteli ukázat, co je požadováno, a vyžadovat výslovný souhlas.

Obranou je proto na straně držitele: přečtěte si výzvu k žádosti. Pokud žádost neodpovídá transakci, odmítněte.

Je také dobré vědět: verifikátor vidí váš eDeviceKey, šifrovací sadu a metody přenosu z QR kódu ještě předtím, než schválíte jakoukoli žádost. To je nevyhnutelné na úrovni protokolu — handshake musí proběhnout. Samotný QR kód atributy nenese.

Co náš skener zobrazuje

Vložte QR kód DeviceEngagement mDL (obrázek, vložit nebo kamera) do našeho skeneru. Verdikt zobrazí:

NEDEKÓDUJEME žádné atributy — v QR kódu žádné atributy záměrně nejsou. Celá výměna atributů probíhá přes šifrovaný BLE/NFC/WiFi kanál poté, co bylo navázáno DeviceEngagement.

Dekódování probíhá ve vašem prohlížeči; na náš server se dostane pouze strukturální metadata. Atributy nejsou nikdy přenášeny, protože QR kód žádné neobsahuje.

Před schválením žádosti verifikátora

Viz také

Zkontrolovat QR kód DeviceEngagement mDL

Vložte QR kód (obrázek, vložit nebo kamera). Verdikt zobrazí verzi, šifrovací sadu, metody přenosu, přítomnost eDeviceKey a přítomnost nebo nepřítomnost načítání ze serveru.

Otevřít skener →