Aegon праверыў 4 млрд ключоў — аўдытар мэсэнджару больш не патрэбны

19 кастрычніка 2026 года Microsoft Research апублікавала прэзентацыю Aegon Хасейна Хафезі і Кім Лэйн: даследчыкі паказалі рэалізацыю для каталога з 4 млрд запісаў, у якой абнаўленне эпохі займае менш за хвіліну. Aegon дазваляе кліенту правяраць змены ў каталогу адкрытых ключоў без пастаяннай працы глабальнага аўдытара. Гэта вынік выпрабавання даследчай рэалізацыі, а не паведамленне пра ўкараненне схемы ў мэсэнджар.

У прэпрынце Aegon апісана рэалізацыя на Rust: пры 1250 абнаўленнях за секунду доказ для аўдыту меў памер менш за 30 КБ, а яго праверка займала менш за 65 мс. Даследчыкі параўналі яе з адкрытым кодам сістэмы празрыстасці ключоў WhatsApp. Вымярэнні паказваюць, што кліенцкі аўдыт вялікага каталога тэхнічна магчымы; хуткасць працы ў гатовым дадатку і паводзіны яго карыстальнікаў гэтым эксперыментам не вымяраліся.

Як падмена ключа трапляе ў размову

Пры скразным шыфраванні адпраўніку патрэбны адкрыты ключ суразмоўцы. Звычайна ён запытвае гэты ключ у сэрвісу, які вядзе каталог уліковых запісаў і адпаведных ім ключоў. Калі сервер падмяняе адказ ключом нападніка, адпраўнік усё роўна шыфруе паведамленне, але ўжо для чалавека, якому яно не прызначалася. Таму праблема ўзнікае яшчэ да перадачы зашыфраванага тэксту: кліенту трэба ведаць, ці можна давяраць выдадзенаму ключу.

Празрыстасць ключоў звязвае адказ сервера з правяральным станам каталога. Для гэтага сервер фіксуе стан крыптаграфічным абавязацельствам і дае доказ, што ключ сапраўды належыць паказанаму запісу. Аднак аднаго правільнага адказу пры запыце недастаткова для кантролю гісторыі. Калі ключ уліковага запісу мяняўся, важна выявіць і змену, якая магла адбыцца, пакуль яго ўладальнік быў па-за сеткай.

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

Як кліент правярае сервер у Aegon

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

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

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

Адкуль узяўся маштаб у мільярды запісаў

Aegon развівае папярэднюю схему IronDict, якая зрабіла аўдыт вялікага каталога дастаткова лёгкім для звычайнага камп’ютара. У публікацыі IronDict на USENIX Security апісана праверка каталога з 1 млрд запісаў за 35 мс на звычайным ноўтбуку пры памеры аўдытарскага доказу 8 КБ. Гэта вынікі IronDict, а не вымярэнні Aegon. Яны паказваюць крыптаграфічную аснову, на якой даследчыкі будавалі наступную сістэму.

У Aegon істотна змянілі серверную частку. Праца пры чарговай эпосе залежыць ад колькасці абноўленых запісаў, а не ад памеру ўсяго каталога. Калі пераважная частка ключоў засталася ранейшай, серверу не трэба нанова апрацоўваць кожны запіс дзеля наступнага аўдытарскага доказу. Гэта тлумачыць, як кароткі інтэрвал паміж версіямі каталога сумяшчаецца з яго вялікім памерам.

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

Што вынік змяняе для мэсэнджараў

Для распрацоўшчыкаў зашыфраваных сэрвісаў Aegon паказвае магчымасць праектаваць вялікі каталог ключоў так, каб праверка яго гісторыі была даступная самому кліенту. Глабальны аўдытар у такой канструкцыі ўжо не з’яўляецца абавязковым пастаянным удзельнікам праверкі. Пры гэтым сэрвіс па-ранейшаму павінен падтрымліваць каталог, своечасова публікаваць яго новыя станы і выдаваць доказы; гэтыя абавязкі не пераходзяць да карыстальніка.

Выпрабаваны маштаб апісвае ёмістасць каталога ў даследчай рэалізацыі. Ён не азначае, што мільярды людзей карысталіся Aegon або што кожны ключ уручную правяраў асобны чалавек. Публікацыя не называе мэсэнджар, які ўжо ўкараніў схему. Таму наступнай істотнай праверкай будзе інтэграцыя з канкрэтным сэрвісам: яна пакажа, ці захоўваюцца хуткасць абнаўлення і магчымасць кліенцкага аўдыту пры яго рэальнай нагрузцы і на яго прыладах.

Чытайце таксама:

• Bumble прадаюць за $1,3 млрд — пасля падзення платных карыстальнікаў на 16,4%
• Muse Spark Open адкрыты, але для свайго сервера патрэбна да 2 ТБ VRAM
• Axiom атрымала $2 млрд, але Flex гарантуе дарагі выкуп пры зрыве spin-off