Без проверка чрез връзка с издателя: Защо бъдещото цифрово МУП не трябва да се свързва с издателя при всяка употреба

Отнемането на валидност е най-трудният проблем при всяко бъдещо цифрово Международно удостоверение за правоуправление (МУП). Най-лесният начин за решаването му е и най-опасният: издателят да участва при всяко отделно представяне на документа. Съвременното трансгранично удостоверение за правоуправление следва да отхвърля това решение по подразбиране.

Почти всяко предложение за цифрова идентичност съдържа едно и също успокояващо изречение:

„Удостоверението може да бъде верифицирано мигновено.”

Понякога това изречение описва истински напредък. Понякога описва наблюдение с по-приятен потребителски интерфейс.

Действащите стандарти вече изясняват, че проверяващата страна не е длъжна да се свързва с издателя при всяко представяне на удостоверение:

• Текущата архитектура на NIST за mDL гласи, че проверяващата страна може да потвърди автентичността и целостта, като се довери на подписа и публичните ключове на издателя — без да е необходим пряк контакт с него.
• 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 Bitstring Status List изяснява въпроса: информацията за статуса, прикачена към верифицируемо удостоверение, се отнася до самото верифицируемо удостоверение — не непременно до основното реално право. Цифровото удостоверение може да бъде отнето, защото механизмът му за подписване е бил компрометиран, докато основното право на управление остава напълно валидно.

Поради това бъдещото МУП се нуждае от два отделни слоя за статус:

• Слой за статус на удостоверението — за самото цифрово удостоверение или канала за представяне.
• Слой за право на управление — за основното национално право за управление на МПС.

Понякога тези два слоя се променят едновременно. Често — не. Система, която ги смесва, ще реагира прекомерно, ще разкрива повече данни от необходимото, или и двете.

Компрометирането на портфейла трябва да се разпространява чрез статуса, а не да задейства обратни заявки към проверяващия

Бъдещото МУП се нуждае и от ясен отговор на въпроса какво се случва при компрометиране на портфейл.

Архитектурата на EUDI предлага такъв:

• Доставчикът на портфейл издава Удостоверения за единица портфейл, съдържащи информация за отнемане на валидност.
• Целостта на портфейла се проверява периодично; ако портфейлът вече не е защитен, неговото удостоверение се отнема.
• Доставчиците на PID трябва редовно да проверяват дали портфейлът е бил отнет. Ако е така, те отнемат и PID.
• Чрез проверка на статуса на PID разчитащата страна имплицитно проверява и статуса на портфейла.

Това е многослойността, която бъдещото МУП трябва да възприеме. Не искайте всяка проверяваща страна самостоятелно да проверява доставчика на портфейл. Оставете компрометирането на портфейла да се разпространи чрез съществуващия канал за статус на удостоверението и нека проверяващите страни се консултират с този единствен канал, запазващ поверителността.

Три работещи модела за отнемане на валидност (без обратни заявки)

EUDI изисква доставчиците да използват един от три метода за отнемане на валидност:

• Краткосрочни удостоверения — валидни 24 часа или по-малко, при което отнемането на валидност става излишно.
• Списък за статус на удостоверения — публикуван списък, с който проверяващите страни могат да се консултират.
• Списък за отнемане на удостоверения — изричен списък на отнети удостоверения.

За удостоверения с валидност над 24 часа EUDI изисква вграждане на информация за отнемане на валидност, включваща:

• URL адрес, от който разчитащите страни могат да изтеглят списъка за статус.
• Идентификатор, указващ местоположението на удостоверението в този списък.

Ако надеждна информация за отнемане на валидност не е налична — например когато разчитащата страна е офлайн — EUDI указва на разчитащата страна да извърши анализ на риска, преди да приеме или откаже удостоверението.

Изводът: отнемането на валидност не е единен механизъм и със сигурност не е обосновка за задължителни обратни заявки към издателя.

Краткосрочни по подразбиране, дългосрочни само при необходимост

Едната от най-ефективните мерки за поверителност в целия стек е и най-простата: представяното да бъде краткосрочно.

• EUDI посочва, че удостоверенията с валидност 24 часа или по-малко не се нуждаят от инфраструктура за отнемане на валидност — те изтичат, преди отнемането да придобие значение.
• W3C посочва, че верифицируемите представяния обикновено са краткосрочни и не са предназначени за дългосрочно съхранение.
• NIST изрично предупреждава срещу повторното предаване на многократно използваеми идентификатори при ежедневна употреба. Ежедневното удостоверяване трябва да разчита на технологии, създадени за тази цел, като например passkeys, а не на повторното представяне на удостоверение, богато на идентификационни данни.
• NIST също така избра локалното удостоверяване от устройство пред биометричното съпоставяне от сървър именно защото локалното удостоверяване опазва поверителността и е оперативно по-ефективно.

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

Списъците за статус са правилният механизъм по подразбиране

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

Bitstring Status List v1.0 на W3C описва механизъм, запазващ поверителността, пространствено ефективен и с висока производителност, за публикуване на данни за статус като спиране или отнемане на валидност. Основните му свойства включват:

• Всеки издател управлява списък за издадените от него удостоверения.
• Форматът се компресира добре, тъй като повечето удостоверения остават валидни.
• Размерът на списъка по подразбиране е 131 072 записа, което според W3C осигурява достатъчна групова поверителност в средния случай.
• Могат да се използват по-големи списъци, когато е необходима по-силна групова поверителност.

Това измества въпроса от:

„Мога ли да попитам издателя за този потребител точно сега?”

към:

„Разполагам ли вече с достатъчно актуален списък за статус, запазващ поверителността, за да вземам решение локално?”

Това е много по-добър въпрос — и технически, и политически.

„Без връзка с издателя” е модел за изтегляне, а не лозунг

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

Разчитащите страни не трябва да заявяват списъка за статус при всяко представяне на удостоверение. Вместо това те трябва да:

• Изтеглят всяка нова версия на списъка еднократно.
• Правят това по време и от местоположение, несвързани с никакво представяне от потребител.
• Разпространяват списъка вътрешно в рамките на организацията на разчитащата страна.
• Изтеглят списъка без да се удостоверяват като разчитаща страна.

Това е оперативното ядро на верификацията без връзка с издателя: обновявайте статуса отделно от представянията на потребителите — никога за конкретно лице, никога за конкретна транзакция.

Този единствен избор при проектирането не позволява на издателя или доставчика на статуса да разбере коя проверяваща страна е проверила кое удостоверение и в кой момент.

Групова поверителност: Изискването, което повечето проекти забравят

Много системи рекламират избирателното разкриване в рамките на самото представяне, а след това тихомълком пренебрегват поверителността при справките за статус. Това е съществен пропуск.

Изискванията на EUDI за поверителност конкретизират:

• Индексите в списъците за статус трябва да бъдат присвоявани произволно, за да не може самият индекс да се превърне в сигнал за проследяване.
• Всеки списък трябва да обхваща достатъчно голям брой удостоверения, за да гарантира групова поверителност.
• Ако даден списък иначе би бил твърде малък, доставчиците трябва да добавят неизползвани записи, за да скрият реалния брой удостоверения.

Бъдещото МУП не може да претендира, че опазва поверителността единствено въз основа на избирателното разкриване. Ако механизмът за отнемане на валидност разкрива събитието на представяне, проектът за поверителност е непълен.

Работата офлайн не е граничен случай — тя е основно изискване

Всяка система за пътуване, която предполага перфектна свързаност, е лошо проектирана.

• AAMVA потвърждава, че извличането от устройство работи без външна свързаност — както за устройството на притежателя, така и за четеца — и че ISO/IEC 18013-5 изисква mDL-овете да поддържат извличане от устройство.
• EUDI признава, че разчитащите страни може да са офлайн и да нямат кеширан списък за статус; в такъв случай препоръчва анализ на риска преди вземане на решение.

Приемете този компромис от самото начало:

Не можете едновременно да имате перфектна работа офлайн и перфектна актуалност в реално време.

Всяка архитектура, обещаваща и двете без компромис, е или неточна, или тихомълком въвежда отново наблюдение. Правилният отговор е актуалността да се превърне в параметър на политиката, а не в универсална мрежова зависимост.

Журналите са там, където поверителността тихомълком се проваля

Дори отличната архитектура за статус може да бъде подкопана от небрежно водене на журнали.

• EUDI изисква инстанциите на разчитащата страна да изтриват уникалните елементи и времевите марки веднага щом те вече не са необходими, и забранява препращането им.
• AAMVA забранява на участниците да проследяват притежателите на mDL или употребата на mDL, освен когато това се изисква по закон, задължава издаващите органи да ограничат споделянето на статични или дългосрочни метаданни и ограничава достъпа до журналите с активност само до притежателя.
• AAMVA също изисква изтриването от устройството да премахва информацията от журнала и метаданните, които биха могли да разкрият историята на употребата — и това изтриване трябва да е възможно и офлайн.

Това е поведение на протокола, а не административни домакински задачи. Бъдещото МУП трябва да третира дългосрочните идентификатори, времевите марки и журналите като потенциални инструменти за проследяване, освен ако изрично не е доказано обратното.

Конкретна архитектура без връзка с издателя за бъдещото МУП

Обединявайки принципите, ето какво трябва действително да прави системата:

1. Издаване на основно удостоверение, обвързано с устройство. Обвържете удостоверението с ключове, защитени в сигурната среда на портфейла — задължително съгласно EUDI за PID и удостоверения по ISO/IEC 18013-5.
2. Заявяване само на необходимото, с нова предизвикателна стойност. При транзакция по OpenID4VP DCQL заявката позволява на портфейла да покаже на притежателя кои атрибути се заявяват, а проверяващият издава предизвикателна стойност за предотвратяване на повторно използване (съгласно текущата архитектура на NIST за mDL).
3. Генериране на краткосрочно представяне, а не на многократно използваем идентификатор. Всяко представяне трябва да бъде специфично за проверяващия, заявката и момента.
4. Локална проверка на автентичността. Потвърждавайте подписите на издателя и публичните ключове офлайн; услугата за доверие на AAMVA е създадена именно за това.
5. Проверка на статуса от кеширани, отделно обновявани списъци. Когато удостоверенията са твърде дългосрочни, за да се пропусне отнемането на валидност, използвайте локално кеширани списъци за статус, обновявани по график, несвързан с представянията на потребителите.
6. Прилагане на политика за риска при липса на актуалност. Направете офлайн решенията изрична политика на проверяващия, а не неструктурирани предположения.
7. Агресивно изтриване на данни за проследяване. Изхвърляйте уникалните за транзакцията елементи и времевите марки, когато вече не са необходими; не запазвайте журнали, от които може да се възстанови историята на движението.

Така изглежда сериозната архитектура без връзка с издателя — многослойна, запазваща поверителността, криптографски локална и оперативно честна по отношение на офлайн реалността.

Три модела, които трябва да бъдат забранени по проект

Зрелата екосистема на бъдещото МУП следва да третира тези като архитектурни неуспехи, а не като избори за оптимизация:

• Задължителни обратни заявки към издателя при всяко представяне. Собственото ръководство на AAMVA за поверителност обяснява защо това е вредно.
• Използване на удостоверението за управление като рутинен инструмент за вход. NIST изрично предупреждава срещу многократното представяне на удостоверения с идентификационни данни за ежедневно удостоверяване.
• Запазване на идентификатори, времеви марки и журнали, от които може да се възстанови историята на представянията. Както EUDI, така и AAMVA изискват обратното.

Основният аргумент в едно изречение

Мигновената верификация не трябва да се превръща в разрешение за наблюдение от страна на издателя.

Бъдещото МУП трябва да може да:

• Доказва автентичност локално.
• Доказва притежание локално.
• Проверява актуалност поверително.
• Толерира офлайн реалността.
• Функционира безпроблемно, когато перфектната информация не е налична.

Нищо от това не прави системата по-слаба. Напротив — прави я достойна за внедряване в мащаб.

В момента, в който удостоверението за управление се превърне в инструмент за записване кой какво е показал, къде и кога, то престава да бъде по-сигурна версия на хартиен документ. То се превръща в инфраструктура за наблюдение.

Именно това бъдещото МУП трябва категорично да откаже да стане.

Често задавани въпроси

Какво е „верификация чрез връзка с издателя”?
Това е всеки проект, при който проверяващата страна се свързва с издателя в реално време, за да потвърди удостоверение. Макар да решава едновременно автентичността и отнемането на валидност, той позволява на издателя да наблюдава всяко събитие на представяне.

Изисква ли ISO/IEC 18013-5 онлайн контакт с издателя?
Не. AAMVA потвърждава, че ISO/IEC 18013-5 изисква поддръжка на извличане от устройство и само по избор допуска извличане от сървър.

Как може отнемането на валидност да работи без контакт с издателя?
Чрез краткосрочни удостоверения, списъци за статус на удостоверения или списъци за отнемане на удостоверения — в идеалния случай разчитащата страна изтегля данните за статуса отделно от представянията на потребителите.

Защо „груповата поверителност” е важна за списъците за статус?
Ако даден списък за статус е твърде малък или индексите му са предсказуеми, заявката за статус може да разкрие кое конкретно удостоверение е именно представено. Произволните индекси и големите списъци предотвратяват това.

Практична ли е наистина офлайн верификацията?
Да — и стандартизиращите органи, включително AAMVA и EUDI, изрично я изискват. Компромисът е, че перфектната актуалност в реално време е несъвместима с перфектната офлайн работа, поради което актуалността трябва да стане политическо решение, а не твърда зависимост.