Верификација без позивања издаваоца: Зашто будућа дигитална МВД не сме да контактира издаваоца при сваком коришћењу

Опозив је најтежи проблем у свакој будућој дигиталној Међународној возачкој дозволи (МВД). Најједноставније решење овог проблема је уједно и најопасније: учинити издаваоца учесником у сваком појединачном представљању акредитива. Савремена прекогранична возачка исправа треба да подразумевано одбије овај пречац.

Готово сваки предлог дигиталног идентитета садржи исту умирујућу реченицу:

„Акредитив се може тренутно верификовати.”

Понекад та реченица описује стварни напредак. Понекад описује надзор са пријатнијим корисничким интерфејсом.

Тренутно објављени стандарди већ јасно показују да верификатор не мора да контактира издаваоца сваки пут када се акредитив предочи:

• Тренутна mDL архитектура NIST-а наводи да верификатор може да провери аутентичност и интегритет поверавањем издаваочевом потпису и јавним кључевима — без икаквог директног контактирања издаваоца.
• AAMVA потврђује да ISO/IEC 18013-5 захтева подршку за преузимање са уређаја и само опционо дозвољава преузимање са сервера.
• AAMVA такође упозорава да се при преузимању са сервера надлежни орган за издавање у реалном времену укључује при сваком коришћењу — што значи да технички може да евидентира када се акредитив користи, које податке дели, па чак и да закључи о локацији корисника анализом IP адресе.

То није споредна напомена. То је кључно питање архитектуре за следећу генерацију прекограничних возачких исправа.

Опасни пречац: Сабијање четири питања у један мрежни позив

Лоше архитектуре обједињују четири потпуно различита питања у један позив уживо упућен издаваоцу:

1. Да ли је овај акредитив аутентичан?
2. Да ли је особа која га предочава законити носилац?
3. Да ли је сам акредитив још увек важећи?
4. Да ли је основно национално право управљања возилом још увек на снази?

Лоше дизајниран систем одговара на сва четири питања позивом у реалном времену. Добро дизајниран систем их раздваја — јер то нису исти проблеми и не би требало да деле исти механизам.

Аутентичност треба верификовати локално, а не преко мреже

Акредитив може бити криптографски исправан а да издавалац никада не посматра трансакцију.

• NIST-ов модел поверења за mDL каже да се аутентичност и интегритет верификују на основу издаваочевог потпису и јавних кључева — без потребе за живим контактом са издаваоцем.
• AAMVA-ин Сервис дигиталног поверења постоји управо да би верификаторима омогућио приступ важећим јавним кључевима издаваоца без повратних позива по трансакцији.

Принцип пројектовања 1: Не користите живу везу за решавање проблема који потписи већ решавају.

Ако верификатор поседује поуздане кључеве издаваоца и прими представљање у складу са стандардима, провера аутентичности је локална криптографска операција, а не зависност од мреже.

Везивање носиоца треба да се докаже локално, а не да се пријављује глобално

Друго питање — да ли је ово законити носилац? — такође има одговор који не захтева мрежу.

Тренутна EUDI архитектура налаже везивање за уређај за PID-ове и ISO/IEC 18013-5 атестације. Верификатор тражи од новчаника да потпише свежи изазов коришћењем приватног кључа који одговара јавном кључу уграђеном у акредитив:

• У ISO/IEC 18013-5 ово се назива mdoc аутентикација.
• У SD-JWT VC то се назива везивање кључа.

У оба случаја, поседовање се доказује локално и криптографски. Нема потребе да лични подаци икада доспеју до издаваоца.

Принцип пројектовања 2: Доказујте поседовање локално. Немојте доказивати идентитет глобално.

Будућа МВД треба да исцрпи везивање за уређај, локалну аутентикацију носиоца и одговор верификатора на изазов пре него што размотри било какав механизам на страни издаваоца.

Статус акредитива и статус права управљања возилом су две различите ствари

Многи дизајни дигиталног идентитета замагљују ову разлику, и управо ту греше.

W3C спецификација Битстринг листе статуса јасно истиче ову тачку: информације о статусу приложене уз верификабилни акредитив примењују се на сам верификабилни акредитив — не нужно и на основну права у стварном свету. Дигитални акредитив може бити опозван јер је его механизам потписивања компромитован, dok основно право управљања возилом остаје потпуно важеће.

Стога будућа МВД захтева два различита слоја статуса:

• Слој статуса акредитива — за сам дигитални акредитив или канал презентовања.
• Слој права управљања возилом — за основно национално право на управљање возилом.

Понекад се ови слојеви мењају заједно. Најчешће се не мењају. Систем који их изједначава ће претерано реаговати, изложити више података него што је потребно, или и једно и друго.

Компромитовање новчаника треба да се прослеђује кроз статус — а не да покреће повратне позиве верификатора

Будућа МВД такође захтева јасан одговор на питање шта се дешава када је новчаник компромитован.

EUDI архитектура пружа такав одговор:

• Провајдер новчаника издаје Атестације јединице новчаника које садрже информације о опозиву.
• Интегритет новчаника се периодично поново верификује; ако новчаник више није безбедан, његова атестација се опозива.
• Провајдери PID-а морају редовно да проверавају да ли је новчаник опозван. Ако јесте, они опозивају PID.
• Верификацијом статуса PID-а, ослоњена страна имплицитно верификује статус новчаника.

Ово је слојевитост коју будућа МВД треба да усвоји. Немојте тражити од сваког верификатора да самостално проверава провајдера новчаника. Нека се компромитовање новчаника прослеђује кроз постојећи процес статуса акредитива, и нека верификатори консултују тај јединствени канал са заштитом приватности.

Три применљива обрасца опозива (без повратних позива)

EUDI захтева од провајдера употребу једне од три методе опозива:

• Краткотрајне атестације — важеће 24 сата или краће, тако да опозив постаје непотребан.
• Листа статуса атестације — јавно доступна листа коју верификатори могу да консултују.
• Листа опозива атестације — експлицитна листа опозваних акредитива.

За атестације важеће дуже од 24 сата, EUDI захтева уграђивање информација о опозиву које укључују:

• URL адресу са које ослоњене стране могу да преузму листу статуса.
• Идентификатор за лоцирање акредитива унутар те листе.

Ако поуздане информације о опозиву нису доступне — на пример, када је ослоњена страна ван мреже — EUDI упућује ослоњену страну да изврши анализу ризика пре прихватања или одбијања акредитива.

Закључак: опозив није јединствени механизам, и свакако није оправдање за обавезне повратне позиве издаваоцу.

Краткотрајно подразумевано, дуготрајно само тамо где је потребно

Једна од најефикаснијих мера заштите приватности у читавом систему је уједно и најједноставнија: задржати оно што се презентује краткотрајним.

• EUDI наводи да атестације важеће 24 сата или краће не захтевају инфраструктуру за опозив — истичу пре него што би опозив постао релевантан.
• W3C наводи да су верификабилне презентације обично краткотрајне и нису дизајниране за дугорочно чување.
• NIST изричито упозорава против поновљеног преношења идентификатора за вишекратну употребу у свакодневној употреби. Свакодневна аутентикација треба да се ослања на технологије грађене за ту сврху, као што су приступни кључеви, а не на поновљено предочавање акредитива богатог идентификационим подацима.
• NIST је такође одабрао локалну аутентикацију на уређају уместо биометријског поређења на серверу управо зато што локална аутентикација чува приватност и оперативно је ефикаснија.

Принцип пројектовања 3: Основни акредитив може имати средњи период важења, али само презентовање треба да буде краткотрајно, специфично за верификатора и неподобно за поновну употребу.

Листе статуса су прави подразумевани механизам

Када не можете да учините све краткотрајним, потребна вам је инфраструктура статуса — и листа статуса је прави подразумевани избор.

W3C-ов Битстринг листа статуса v1.0 описује механизам за објављивање података о статусу, попут суспензије или опозива, са заштитом приватности, просторно ефикасан и високих перформанси. Кључне особине укључују:

• Сваки издавалац управља листом за акредитиве које је издао.
• Формат се добро компресује, јер већина акредитива остаје неопозвана.
• Подразумевана величина листе је 131.072 уноса, за шта W3C каже да у просечном случају пружа одговарајућу групну приватност.
• Веће листе се могу употребити тамо где је потребна јача групна приватност.

Ово мења питање са:

„Могу ли да питам издаваоца о овом кориснику управо сада?”

на:

„Да ли већ имам довољно ажурну листу статуса са заштитом приватности да одлучим локално?”

То је далеко боље питање — и технички и политички.

„Без позивања издаваоца” је образац преузимања, а не слоган

Најважније правило у EUDI смерницама за приватност је процедурално, а не филозофско.

Ослоњене стране не смеју да захтевају листу статуса сваки пут када је акредитив предочен. Уместо тога, морају да:

• Преузму сваку нову верзију листе само једном.
• То ураде у времену и са локације непосредно везане за ниједно корисничко представљање.
• Листу дистрибуирају интерно унутар организације ослоњене стране.
• Преузму листу без аутентикације ослоњене стране.

То је оперативна суштина верификације без позивања издаваоца: освежавајте статус одвојено од корисничких представљања — никада по особи, никада по трансакцији.

Овај јединствени избор у пројектовању спречава издаваоца или провајдера статуса да сазна који је верификатор проверио који акредитив у ком тренутку.

Групна приватност: Захтев кога већина дизајна заборавља

Многи системи трубе о селективном откривању унутар самог представљања, а онда тихо занемарују приватност претрага статуса. То је значајна празнина.

EUDI захтеви за приватност одређују да:

• Индекси у листама статуса морају бити насумично додељени, тако да индекс сам по себи никада не постане сигнал за праћење.
• Свака листа мора да покрива довољно велики број акредитива ради обезбеђивања групне приватности.
• Ако би листа иначе била премала, провајдери треба да додају неискоришћене уносе ради прикривања стварног броја акредитива.

Будућа МВД не може да тврди да штити приватност само на основу селективног откривања. Ако механизам опозива открива догађај представљања, дизајн приватности је непотпун.

Рад ван мреже није рубни случај — то је основни захтев

Сваки путни систем који претпоставља савршену повезаност је лоше дизајниран.

• AAMVA потврђује да преузимање са уређаја ради без спољне повезаности и за уређај носиоца и за читач, и да ISO/IEC 18013-5 захтева да mDL-ови подржавају преузимање са уређаја.
• EUDI прихвата да ослоњене стране могу бити ван мреже и без кешираних листа статуса, у ком случају препоручује анализу ризика пре доношења одлуке.

Прихватите овај компромис унапред:

Не можете истовремено имати савршен рад ван мреже и савршену ажурност у реалном времену.

Свака архитектура која обећава и једно и друго без компромиса је или непрецизна или тихо поново уводи надзор. Прави одговор је учинити ажурност политичким параметром, а не универзалном мрежном зависношћу.

Евиденција је место где приватност тихо пропада

Чак и одлична архитектура статуса може бити поništена непажљивим евидентирањем.

• EUDI захтева да инстанце ослоњених страна одбацују јединствене елементе и временске ознаке чим нису више потребни, и забрањује њихово прослеђивање.
• AAMVA забрањује стејкхолдерима праћење носилаца mDL-а или употребе mDL-а осим где то захтева закон, захтева од надлежних органа за издавање да минимизују дељење статичких или дуговечних метаподатака, и ограничава приступ евиденцији активности на носиоца.
• AAMVA такође захтева да брисање на уређају уклони информације евиденције и метаподатке који би могли открити историју употребе — и да ово брисање буде могуће ван мреже.

Ово је понашање протокола, а не административно одржавање. Будућа МВД мора третирати дуговечне идентификаторе, временске ознаке и евиденцију као потенцијалне алате за праћење, осим ако није изричито доказано супротно.

Конкретна архитектура без позивања издаваоца за будућу МВД

Спајајући принципе, ево шта систем стварно треба да ради:

1. Издати основни акредитив везан за уређај. Везати акредитив за кључеве заштићене у безбедном окружењу новчаника — обавезно под EUDI-јем за PID-ове и ISO/IEC 18013-5 атестације.
2. Захтевати само оно што је потребно, са свежим изазовом. У OpenID4VP трансакцији, DCQL упит омогућава новчанику да покаже носиоцу које атрибуте се тражи, а верификатор издаје изазов ради спречавања поновне употребе (према тренутној mDL архитектури NIST-а).
3. Генерисати краткотрајно представљање, а не идентификатор за вишекратну употребу. Свако представљање треба да буде специфично за верификатора, захтев и тренутак.
4. Верификовати аутентичност локално. Валидирати потписе издаваоца и јавне кључеве ван мреже; AAMVA-ин сервис поверења је грађен управо за ово.
5. Проверавати статус из кешираних, засебно освежаваних листа. Тамо где акредитиви трају предуго да би се прескочио опозив, користити локално кеширане листе статуса освежаване по распореду који није везан за корисничка представљања.
6. Примењивати политику ризика када ажурност није доступна. Учинити одлуке ван мреже експлицитном политиком верификатора, а не неструктурисаним нагађањем.
7. Агресивно брисати податке за праћење. Одбацити јединствене елементе трансакције и временске ознаке када нису више потребни; не задржавати евиденцију која би могла реконструисати историју кретања.

Овако изгледа озбиљна архитектура без позивања издаваоца — слојевита, са заштитом приватности, криптографски локална и оперативно поштена у погледу стварности рада ван мреже.

Три обрасца која треба забранити пројектовањем

Зрели екосистем будуће МВД треба да их третира као архитектонске грешке, а не изборе оптимизације:

• Обавезни повратни позиви издаваоцу при сваком представљању. Сопствене смернице AAMVA за приватност објашњавају зашто је то штетно.
• Коришћење возачке исправе као рутинске пријаве. NIST изричито упозорава против поновљеног представљања акредитива са идентификационим подацима за свакодневну аутентикацију.
• Задржавање идентификатора, временских ознака и евиденција које могу реконструисати историју представљања. И EUDI и AAMVA захтевају супротно.

Основни аргумент у једној реченици

Тренутна верификација не сме постати дозвола за надзор на страни издаваоца.

Будућа МВД треба да буде у стању да:

• Докаже аутентичност локално.
• Докаже поседовање локално.
• Провери ажурност приватно.
• Толерише стварност рада ван мреже.
• Функционише беспрекорно када савршене информације нису доступне.

Ниједна од ових ствари не чини систем слабијим. Она га чини вредним за примену у великом обиму.

У тренутку када возачка исправа постане алат за евидентирање ко је шта показао, где и када, она престаје да буде безбеднија верзија папирног документа. Постаје инфраструктура за посматрање.

То је управо оно чиме будућа МВД не сме постати.

Често постављана питања

Шта је „верификација позивом издаваоца”?
То је сваки дизајн у ком верификатор у реалном времену контактира издаваоца ради валидације акредитива. Иако истовремено решава аутентичност и опозив, такође омогућава издаваоцу да посматра сваки догађај представљања.

Да ли ISO/IEC 18013-5 захтева онлајн контакт са издаваоцем?
Не. AAMVA потврђује да ISO/IEC 18013-5 захтева подршку за преузимање са уређаја и само опционо дозвољава преузимање са сервера.

Kako опозив може да функционише без контактирања издаваоца?
Путем краткотрајних акредитива, листа статуса атестације или листа опозива атестације — идеално уз преузимање података о статусу од стране ослоњене стране одвојено од корисничких представљања.

Зашто је „групна приватност” важна за листе статуса?
Ако је листа статуса премала или су јој индекси предвидљиви, захтев за статусом може открити који је конкретни акредитив управо представљен. Насумични индекси и велике листе то спречавају.

Да ли је верификација ван мреже заиста практична?
Да — и тела за стандарде укључујући AAMVA и EUDI то изричито захтевају. Компромис је у томе да савршена ажурност у реалном времену није спојива са савршеним радом ван мреже, па ажурност мора постати политичка одлука, а не чврста зависност.