Праверка без зваротнага выкліку: чаму будучы лічбавы МДК не павінен звяртацца да эмітэнта пры кожным выкарыстанні

Адкліканне — гэта найскладанейшая праблема любога будучага лічбавага Міжнароднага дазволу на кіраванне (МДК). Найпросты спосаб яе вырашэння з’яўляецца адначасова найбольш небяспечным: зрабіць эмітэнта ўдзельнікам кожнай асобнай прэзентацыі. Сучасны трансгранічны ўліковы дакумент кіроўцы павінен адмаўляцца ад гэтага скарачэння па змаўчанні.

Амаль кожная прапанова па лічбавай ідэнтычнасці змяшчае адно і тое ж суцяшальнае сцвярджэнне:

«Уліковы дакумент можна праверыць імгненна.»

Часам гэта сцвярджэнне апісвае сапраўдны прагрэс. Часам — назіранне з больш зручным карыстальніцкім інтэрфейсам.

Дзейныя апублікаваныя стандарты ўжо выразна сцвярджаюць, што верыфікатару не патрэбна кантактаваць з эмітэнтам кожны раз, калі прад’яўляецца ўліковы дакумент:

• Бягучая архітэктура mDL NIST сцвярджае, што верыфікатар можа пацвердзіць аўтэнтычнасць і цэласнасць, давяраючы подпісу эмітэнта і адкрытым ключам, без непасрэднага кантакту з эмітэнтам.
• AAMVA пацвярджае, што ISO/IEC 18013-5 патрабуе падтрымкі атрымання з прылады і толькі неабавязкова дазваляе серверны зварот.
• AAMVA таксама папярэджвае, што пры серверным зваце органы-эмітэнты ўдзельнічаюць у рэальным часе ў кожным выкарыстанні — а значыць, тэхнічна могуць фіксаваць, калі выкарыстоўваецца ўліковы дакумент, якія дадзеныя перадаюцца, і нават вызначаць месцазнаходжанне праз аналіз IP.

Гэта не нязначная зноска. Гэта цэнтральнае пытанне праектавання для наступнага пакалення трансгранічных уліковых дакументаў кіроўцы.

Небяспечны скарачаны шлях: аб’яднанне чатырох пытанняў у адзін сеткавы выклік

Дрэнныя архітэктуры аб’ядноўваюць чатыры розных пытанні ў адзін жывы выклік да эмітэнта:

1. Ці з’яўляецца гэты ўліковы дакумент аўтэнтычным?
2. Ці з’яўляецца асоба, якая яго прад’яўляе, законным уладальнікам?
3. Ці застаецца сам уліковы дакумент сапраўдным?
4. Ці захоўваецца ў сіле базавае нацыянальнае права на кіраванне?

Дрэнна спраектаваная сістэма адказвае на ўсе чатыры пытанні, выклікаючы дадому ў рэальным часе. Добра спраектаваная сістэма аддзяляе іх — таму што гэта не адна і тая ж праблема і яны не павінны мець агульны механізм.

Аўтэнтычнасць павінна правярацца лакальна, а не праз сетку

Уліковы дакумент можа быць крыптаграфічна сапраўдным без таго, каб эмітэнт наогул назіраў за транзакцыяй.

• Мадэль даверу mDL NIST сцвярджае, што аўтэнтычнасць і цэласнасць правяраюцца па подпісу эмітэнта і адкрытых ключах — прамы кантакт з эмітэнтам не патрэбен.
• Служба лічбавага даверу 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: Базавы ўліковы дакумент можа мець сярэдні тэрмін дзеяння, але сама прэзентацыя павінна быць кароткатэрміновай, спецыфічнай для верыфікатара і аднаразовай.

Спісы статусаў — гэта правільны механізм па змаўчанні

Калі немагчыма зрабіць усё кароткатэрміновым, патрабуецца інфраструктура статусаў — і спіс статусаў з’яўляецца правільным варыянтам па змаўчанні.

W3C Bitstring Status List v1.0 апісвае механізм публікацыі статусных дадзеных (напрыклад, прыпынення або адклікання), які захоўвае канфідэнцыяльнасць, эфектыўна выкарыстоўвае прастору і высокапрадукцыйны. Ключавыя ўласцівасці:

• Кожны эмітэнт вядзе спіс выдадзеных ім уліковых дакументаў.
• Фармат добра сціскаецца, паколькі большасць уліковых дакументаў застаецца неадкліканай.
• Памер спіса па змаўчанні складае 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 дае кашальку магчымасць паказаць уладальніку, якія атрыбуты запытваюцца, а верыфікатар выдае выклік для прадухілення прайгравання (паводле бягучай архітэктуры mDL NIST).
3. Генераваць кароткатэрміновую прэзентацыю, а не паўторна выкарыстоўваемы ідэнтыфікатар. Кожная прэзентацыя павінна быць спецыфічнай для верыфікатара, запыту і моманту.
4. Правяраць аўтэнтычнасць лакальна. Правяраць подпісы эмітэнта і адкрытыя ключы аўтаномна; служба даверу AAMVA створана менавіта для гэтага.
5. Правяраць статус па кэшаваных, асобна абноўленых спісах. Там, дзе ўліковыя дакументы маюць занадта вялікі тэрмін дзеяння для таго, каб абысціся без адклікання, выкарыстоўваць лакальна кэшаваныя спісы статусаў, якія абнаўляюцца па графіку, не звязаным з прэзентацыямі карыстальнікаў.
6. Ужываць палітыку рызык пры адсутнасці актуальных дадзеных. Рабіць аўтаномныя рашэнні відавочнай палітыкай верыфікатара, а не неструктараванымі здагадкамі.
7. Актыўна выдаляць дадзеныя адсочвання. Ліквідаваць унікальныя элементы транзакцый і метазнакі часу, калі яны больш не патрэбны; не захоўваць журналы, якія могуць аднавіць гісторыю перамяшчэнняў.

Вось як выглядае сур’ёзная архітэктура без зваротнага выкліку — узроўневая, якая захоўвае канфідэнцыяльнасць, крыптаграфічна лакальная і аперацыйна сумленная адносна рэальнасці аўтаномнай работы.

Тры схемы, якія павінны быць забаронены па канструкцыі

Сталая экасістэма будучага МДК павінна разглядаць наступнае як архітэктурныя адмовы, а не выбар у мэтах аптымізацыі:

• Абавязковыя зваротныя выклікі да эмітэнта пры кожнай прэзентацыі. Уласныя рэкамендацыі AAMVA па канфідэнцыяльнасці тлумачаць, чаму гэта шкодна.
• Выкарыстанне ўліковага дакумента кіроўцы як звычайнага ўваходу ў сістэму. NIST відавочна папярэджвае аб небяспецы шматразовага прад’яўлення ўліковых дакументаў, якія ўтрымліваюць ідэнтыфікацыйную інфармацыю, для штодзённай аўтэнтыфікацыі.
• Захоўванне ідэнтыфікатараў, метазнакаў часу і журналаў, якія могуць аднавіць гісторыю прэзентацый. І EUDI, і AAMVA патрабуюць адваротнага.

Асноўны аргумент у адным сказе

Імгненная праверка не павінна станавіцца дазволам на назіранне з боку эмітэнта.

Будучы МДК павінен умець:

• Даводзіць аўтэнтычнасць лакальна.
• Даводзіць валоданне лакальна.
• Правяраць актуальнасць канфідэнцыйна.
• Адаптавацца да аўтаномнай рэальнасці.
• Нармальна функцыянаваць пры адсутнасці ідэальнай інфармацыі.

Нічога з гэтага не робіць сістэму слабейшай. Гэта робіць яе вартай разгортвання ў маштабе.

Як толькі ўліковы дакумент кіроўцы становіцца інструментам фіксацыі таго, хто, дзе і калі прад’явіў яго, ён перастае быць больш бяспечнай версіяй паперовага дакумента. Ён становіцца інфраструктурай для назірання.

Менавіта гэтым будучы МДК не павінен станавіцца.

Частыя пытанні

Што такое «праверка з зваротным выклікам»?
Гэта любая канцэпцыя, пры якой верыфікатар звяртаецца да эмітэнта ў рэальным часе для праверкі ўліковага дакумента. Хаця яна адначасова вырашае праблемы аўтэнтычнасці і адклікання, яна таксама дазваляе эмітэнту назіраць за кожнай падзеяй прэзентацыі.

Ці патрабуе ISO/IEC 18013-5 анлайн-кантакту з эмітэнтам?
Не. AAMVA пацвярджае, што ISO/IEC 18013-5 патрабуе падтрымкі атрымання з прылады і толькі неабавязкова дазваляе серверны зварот.

Як магчыма адкліканне без кантакту з эмітэнтам?
Праз кароткатэрміновыя ўліковыя дакументы, спісы статусаў атэстацый або спісы адкліканняў атэстацый — у ідэале пры ўмове, што давярачы бок загружае статусныя дадзеныя асобна ад прэзентацый карыстальнікаў.

Чаму «групавая канфідэнцыяльнасць» важна для спісаў статусаў?
Калі спіс статусаў занадта малы або яго індэксы прадказальныя, запыт статусу можа раскрыць, які канкрэтны ўліковы дакумент быў толькі што прэзентаваны. Выпадковыя індэксы і вялікія спісы прадухіляюць гэта.

Ці сапраўды аўтаномная праверка практычна мажлівая?
Так — і такія арганізацыі па стандартызацыі, як AAMVA і EUDI, відавочна патрабуюць яе. Кампраміс заключаецца ў тым, што ідэальная актуальнасць у рэальным часе несумяшчальная з ідэальнай аўтаномнай работай, таму актуальнасць павінна стаць палітычным рашэннем, а не жорсткай залежнасцю.