Единна проверима идентичност за цялата ви организация.

Не само компанията: всеки отдел, всяко устройство, всяка услуга и всеки агент, проверими от институциите, с които работите, без споделен доставчик по средата.

Обсъдете тази архитектура за организацията си

Четири структурни ограничения на стандартните инструменти за самоличност

OpenID Connect, OAuth и инфраструктурата на публичния ключ (PKI) са отлични инструменти в границите на една организация. Федерирането не премахва тази граница, а я премества: или в споразумения, договорени предварително между всяка двойка организации, или в централен посредник, който никоя от тях не контролира. Това не са дефекти, а архитектурни ограничения, които излизат наяве в момента, в който доверието трябва да обхване няколко организации.

Доверие в токените

Докъде стигат стандартните инструменти

Токените за достъп се ползват с доверие в границите на този, който ги е издал. През границите между организациите това се разпада: получаващата организация няма как да провери правомощията на издаващата.

Решение с DKMS / Verimesh

DKMS изгражда криптографска идентичност, която се удостоверява сама: идентичността на всяка организация е проверима от всяка друга организация, без да зависи от споделен удостоверяващ орган.

Прецизност на достъпа

Докъде стигат стандартните инструменти

Обхватите (scopes) са едрозърнести: създадени са за разрешения на ниво приложение. Съгласието на ниво граф от ресурси през организационните граници изисква друг модел.

Решение с DKMS / Verimesh

Механизмът за политики на Verimesh (Open Policy Agent, OPA) дава програмируем и фино гранулиран контрол на достъпа, който работи през границите на доверие между организациите.

Одитируемост

Докъде стигат стандартните инструменти

Дневниците за удостоверяване спират при организацията, която ги е написала. Междуорганизационните одитни следи (кой до какво е получил достъп, кога и с чие разрешение) изискват криптографско свързване, което локалното удостоверяване никога не е било създадено да осигурява.

Решение с DKMS / Verimesh

KERI (Key Event Receipt Infrastructure) осигурява одитни следи, в които всяка намеса остава откриваема. Всяко събитие с идентичността е криптографски свързано и независимо проверимо, което прави одита възможен през границите между организациите.

Архитектура на доверието

Докъде стигат стандартните инструменти

Тези модели предполагат централен орган: доставчик на идентичност, на когото всички се доверяват. Разпределеното институционално доверие между суверенни организации не може да зависи от нито един отделен орган.

Решение с DKMS / Verimesh

DKMS прави възможно суверенното управление на идентичността: всяка организация контролира собствените си криптографски корени. Доверието се установява двустранно, а не се делегира на централен координатор.

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

KERI identity infrastructure architecture diagram showing key event log, witnesses, watchers, and cross-organisational trust establishment
Инфраструктурата за идентичност KERI: самоудостоверяващи се идентификатори, разписки за ключови събития и двустранно доверие без централен орган

Това е нова възможност. Доставчикът ви на идентичност и протоколите зад него (OpenID Connect, OAuth, SAML) са доказани за удостоверяване в рамките на една организация и остават на мястото си. DKMS (Decentralized Key Management System) прави онова, за което те никога не са били създадени: дава на всяка организация самоудостоверяваща се идентичност, която всяка друга институция може да провери директно, без споделен доставчик между тях. Verimesh доставя DKMS и общува със системите, които вече използвате, така че разширявате наличното, вместо да мигрирате от него.

В термините на Zero Trust NIST SP 800-207 очаква доверие никога да не се предоставя имплицитно, а за сътрудничество между предприятията (§4.4) предлага федерация като удобство, не като задължение. DKMS поема по другия път. Насрещните страни, които проверяват спрямо Key Event Log-ове, сами проверяват идентификаторите една на друга, което дава на Zero Trust установяването на доверие, от което се нуждае между организациите, без централен посредник. Когато насрещната страна проверява само по X.509, както днес в HIN, мостов удостоверяващ орган свързва двете.

Надграждане върху националните програми за електронна идентичност

Програмата swiyu е федералната инфраструктура на Швейцария за електронна идентичност. Първото удостоверение в нея, електронното разрешение за учебно шофиране, работи във всички кантони от декември 2025 г., като са издадени около 27 000. Въвеждането в експлоатация на инфраструктурата на доверие за e-ID е планирано за първата половина на 2027 г., докато въвеждането на самата e-ID е отложено, без да е обявена нова дата. Идентификаторите на издателите и изявленията за доверие се публикуват в централни федерални регистри, а удостоверението се съхранява на собственото устройство на гражданина. Очаква се същата инфраструктура да носи удостоверения от кантони, университети и работодатели, след като бъде отворена и за други издатели.

Vereign участва в швейцарския процес за e-ID от самото начало, чрез срещите по него и двустранен обмен, а Georg Greve беше член на Technical Advisory Circle, който fedpol свика и чиито изводи бяха взети предвид при технологичното решение от януари 2024 г.

Европейският съюз следва същия път. Регламент (ЕС) 2024/1183 задължава всяка държава членка да осигури поне един европейски портфейл за цифрова идентичност (EUDI), а основното удостоверение за самоличност на човека се издава от определени от държавата доставчици. И двете програми отговарят на един и същ въпрос, и то добре: как един човек доказва пред институция кой е. Нито една от тях не определя идентичността на отделите, устройствата, услугите и агентите, които организацията реално използва, и двете закрепват доверието в централни регистри. Затова нито една не поддържа регистър на доверяващите се страни, които проверяват удостоверения: в рамките на Съюза те биха били твърде много, за да бъдат изброени.

За организациите, които внедряват Verimesh, swiyu и EUDI се превръщат в основа, върху която можете да надграждате. Мостът днес е проектиран, а не доставен: след като тези системи влязат в продукция, приемате държавна e-ID при регистрацията, използвате я като корен на доверие и оставяте Verimesh да пренесе това доверие през институциите, юрисдикциите и системите, които един реален работен процес докосва, като издавате свои собствени удостоверения обратно в същия портфейл.

Verimesh реализира тази архитектура

Verimesh (по-рано проектът Stargate) е внедряването в реална експлоатация на описаната по-горе архитектура на доверието. Работи с удостоверяването, което вече използвате, и добавя онова, за което този слой никога не е бил създаван: организационна идентичност с корен в DKMS за доверие между институциите, програмируем policy engine (Open Policy Agent), общо значение на данните чрез Overlays Capture Architecture (OCA) и доставка на съобщения с откриване на манипулации чрез SEAL.

Verimesh е в продукция в швейцарското здравеопазване: шлюзът и централният удостоверяващ орган в HIN работят напълно в продукция в по-голямата част от мрежата на HIN, а миграцията е в заключителна фаза, като завършването ѝ се очаква до края на първото тримесечие на 2027 г.

Разгледайте Verimesh

Единна организационна идентичност, чак до мрежовия слой.

Verimesh пренася трафика си през WireGuard, а ключът на тунела има корен в същата организационна идентичност като приложенията над него. Ключовете Curve25519 за тунелите на всяка организация се извеждат от собствения ѝ материал за децентрализирано управление на ключове (DKMS): никой централен орган не ги издава и няма разминаване между идентичността на мрежовия и на приложния слой. Смяната на ключовете се координира с DKMS (предварителна ротация, изградена върху KERI), а всяко изграждане на тунел може да бъде одитирано спрямо Key Event Log. Никой посредник не притежава потока от данни.

Безшумен по замисъл

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

Около 4 000 реда, които можете да прочетете

WireGuard е около 4 000 реда код срещу около 100 000 за OpenVPN и 400 000 за IPsec. Проверимостта сама по себе си е свойство за сигурност.

Без преговори, без понижаване

Фиксирани съвременни примитиви: Curve25519, ChaCha20-Poly1305, BLAKE2s, ръкостискането Noise_IKpsk2. Пълната права секретност със смяна на ключовете приблизително на всеки две минути и скриването на идентичността са вградени, а не конфигурирани.

Суверенитет до самия кабел

Open Source от край до край, самостоятелно хостван, без SaaS контролна равнина по пътя. Суверенитетът се простира от приложението чак до самия транспорт.

Изпитана, доказана инфраструктура

В основното ядро на Linux от 2020 г. Тук няма нова криптография, а точно този слой носи днешното внедряване на Verimesh с HIN.

Готов за квантовата миграция

Слоят с предварително споделен ключ на WireGuard вече намалява риска от атаки от типа „запази сега, дешифрирай по-късно“ върху днешния трафик. А тъй като ключовете на тунелите се извеждат от DKMS, преминаването към post-quantum алгоритми е рутинна смяна на ключове върху съществуващия Key Event Log, а не еднократно преиздаване на всичко.

Вижте пълния жизнен цикъл на връзката

Прилагането на съгласието е основното предназначение на DKMS

Член 71(8) от EHDS създава структурно ограничение, което никой централен орган не може да изпълни: когато дадено лице оттегли съгласието си за вторична употреба, това оттегляне трябва да достигне до всяка институция, която притежава или е извлякла данни от оригиналния източник. Никой certificate authority не може да ко-подпише оттеглянето; никой identity provider не може да каскадира отмяната. Това ограничение е архитектурно несъвместимо с централизирана идентичност.

DKMS удовлетворява пет изисквания, поставени от EHDS Article 71: идентификатори, обвързани с лицето, които оцеляват при повторна регистрация; верифицируеми записи за opt-out с времеви печат, закрепени в Key Event Log; обратимост без повторна идентификация; разпространение между администратори без двустранни споразумения между всяка двойка институции; и невъзможност за свързване между записа за съгласие и данните, които покрива.

След като данните вече са разкрити (споделени в болнична мрежа, изследователски консорциум или верига от платци), последващият отказ трябва да достигне до всеки администратор надолу по веригата. DKMS разпространява отмяната криптографски чрез Key Event Log: в регистъра на всеки администратор записите само се добавят и се удостоверяват от свидетели, така че отмяна, вписана от страната на самия човек, става проверима във всяка институция, която притежава производен запис.

Прочетете тезата за архитектурата на съгласието

Доказана в швейцарското здравеопазване, избрана за внедряване на национално ниво

HIN (Health Info Net) е швейцарската здравноинформационна мрежа, която свързва болници, общопрактикуващи лекари и специализирани доставчици през кантоналните граници. SEAL, входният продукт върху този слой на доверие, вече пренася над 1 000 000 защитени доставки месечно. Verimesh е в продукция в швейцарското здравеопазване: шлюзът и централният удостоверяващ орган в HIN работят напълно в продукция в по-голямата част от мрежата на HIN, а миграцията е в заключителна фаза, като завършването ѝ се очаква до края на първото тримесечие на 2027 г.

HIN (Health Info Net)

1 000 000+

проверени доставки месечно, в цялото швейцарско здравеопазване

Архитектура на доверието: често задавани въпроси

Какво е DKMS?
DKMS (Decentralised Key Management) е категорията инфраструктура за идентичност, при която криптографското доверие има корен в периферията на организацията, а не в централен удостоверяващ орган. Всяка организация контролира собствения си ключов материал и собствен Key Event Log (KEL), в който записите само се добавят. Vereign е съосновател на DKMS Alliance с цел DKMS да бъде формализиран като категория наред с PKI и OAuth.
По какво DKMS е различен от PKI?
PKI закрепва доверието в централни удостоверяващи органи, затова компрометирането на един такъв орган засяга всеки субект, който той е подписал. DKMS закрепва доверието в собствения Key Event Log на всяка организация: отказът остава ограничен до един контролер на идентичността, смяната на ключове е вградена и атомарна чрез предварителни обвързвания за следващия ключ (pre-rotation), а доверието между юрисдикции не изисква договори за взаимно признаване между удостоверяващи органи. DKMS е PKI в периферията, без единна точка на отказ.
DKMS замества ли OAuth?
Не. OAuth е правилният избор за локални потоци с токени в рамките на една организация и трябва да продължи да се използва там. DKMS решава проблем, за който OAuth никога не е бил проектиран: изграждане на проверимо доверие между организации без споделен посредник. Запазете доставчика си на идентичност и добавете DKMS за доверието между институциите.
DKMS готов ли е за post-quantum?
Да. DKMS третира смяната на ключове като основна операция. Когато станат необходими post-quantum алгоритми, миграцията се свежда до рутинна смяна на ключове върху съществуващия Key Event Log, вместо до еднократно преиздаване на всички сертификати. Свойството pre-rotation на KERI означава, че следващият ключ може да използва произволен алгоритъм, към който контролерът на идентичността се обвързва, включително post-quantum схема, без това да прекъсва вече изградените отношения на доверие.
Кой поддържа DKMS?
DKMS е отворена спецификация. Спецификацията се координира от DKMS Alliance, чийто съосновател е Vereign. Референтната имплементация на KERI (протоколът, който стои в основата на DKMS) се поддържа с отворен код от по-широката общност около KERI. Verimesh на Vereign е реализация на слоя DKMS под AGPLv3+: шлюзът и централният му удостоверяващ орган работят напълно в реална експлоатация в HIN, в по-голямата част от мрежата на HIN. SEAL е системата на Vereign за криптирана swarm доставка под AGPLv3+ и е архитектурно независима от DKMS.
DKMS изисква ли блокчейн?
Не. DKMS използва Key Event Log (KEL) със свързани чрез хешове записи, които само се добавят, но няма слой за консенсус, няма токен и няма разпределен регистър. Решението блокчейн да се избегне е целенасочено: регулираната инфраструктура изисква детерминистична проверка, а не вероятностна финалност.
Може ли Vereign да ми помогне да се интегрирам с портфейла swiyu или EUDI?
Да, по замисъл, но още не в продукция: компонентите на моста днес са архитектурни, а не доставени. След като тези системи заработят, приемате държавна e-ID (swiyu, EUDI) при регистрацията и я използвате като корен на доверие, а след това оставяте Verimesh да пренесе това доверие нататък: през институциите, юрисдикциите и системите, които един реален работен процес докосва, включително хората, ролите и агентите, които действат в тях, и през това, което се случва с решение за съгласие, след като данните вече са споделени.
Vereign конкурент ли е на националните портфейли?
Не. Националният портфейл дава проверима идентичност на човека. Verimesh дава такава на организацията и обхваща отделите, устройствата, услугите и агентите, които тя използва, така че двете работят на различни слоеве и се допълват, вместо да се дублират. Verimesh запазва собствения си слой на доверие и е създаден да общува по протоколите на портфейлите в периферията.
В продукция ли е Verimesh мостът към swiyu или EUDI?
Не. Компонентите на моста (доставчик по OID4VCI/VP, експорт на удостоверения, съответствие между идентификатори) са архитектурни: демонстрирани са на ниво проект, но не са доставени. Самият Verimesh е в продукция в швейцарското здравеопазване: шлюзът и централният удостоверяващ орган в HIN работят напълно в продукция в по-голямата част от мрежата на HIN, а миграцията е в заключителна фаза, като завършването ѝ се очаква до края на първото тримесечие на 2027 г.

Заявете преглед на архитектурата. Съотнасяме я към вашите граници на доверие.

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

Резервирайте архитектурен преглед
Швейцарска защита на данните GDPR съвместимост Open Source AGPLv3+ Швейцарски хостинг
Вижте как архитектурата работи стъпка по стъпка