Ні для кого не секрет, що один із загальнопоширених допоміжних інструментів, без якого неможливий захист даних у відкритих мережах, це технологія цифрових сертифікатів. Втім, не є секретом і те, що головний недолік цієї технології — безумовна довіра до центрів, які випускають цифрові сертифікати. Директор з технологій та інновацій компанії ENCRY Андрій Чмора запропонував новий підхід до організації інфраструктури загальнодоступних ключів (Public Key Infrastructure, PKI), який допоможе усунути існуючі в даний час недоліки і використовує технологію розподіленого реєстру (блокчейна). Але про все по порядку.
Якщо ви знайомі з принципами роботи інфраструктури загальнодоступних ключів і знаєте її ключові недоліки, то можете відразу перейти нижче до опису того, що ми пропонуємо змінити.
Що таке цифрові підписи та сертифікати?Взаємодія в Інтернеті завжди має на увазі передачу даних. Усі ми зацікавлені у тому, щоб дані передавалися безпечним чином. Але що таке безпека? Найбільш потрібні послуги безпеки – це конфіденційність, цілісність та справжність. Для цього в даний час застосовуються методи асиметричної криптографії або криптографії з загальнодоступним ключем.
Почнемо з того, що для використання цих методів суб'єкти взаємодії повинні мати два індивідуальні парні ключі — загальнодоступний і секретний. З їхньою допомогою і забезпечуються послуги безпеки, про які ми згадали вище.
Як досягається конфіденційність передачі? Перед надсиланням даних абонент-відправник зашифровує (криптографічно перетворює) відкриті дані з використанням загальнодоступного ключа одержувача, а той розшифровує отриманий шифртекст парним секретним ключем.
Як досягається цілісність і справжність інформації, що передається? Для вирішення цього завдання було створено інший механізм. Відкриті дані не шифруються, але разом з ним передається результат застосування криптографічної хеш-функції - "стислий" образ вхідної послідовності даних - в зашифрованому вигляді. Результат такого хешування називається «дайджестом», яке зашифрування проводиться на секретному ключі абонента-відправника (“завірителя”). В результаті зашифрування дайджесту виходить цифровий підпис. Вона разом із відкритим текстом передається абоненту-одержувачу (“перевіряючому”). Той розшифровує цифровий підпис на відкритому ключі засвідчувача та порівнює з результатом застосування криптографічної хеш-функції, який перевіряє обчислює самостійно на основі прийнятих відкритих даних. Якщо вони збігаються, то це свідчить про те, що дані були передані у справжньому та цілісному вигляді саме абонентом-відправником, а не видозмінені зловмисником.
Більшість ресурсів, що працюють із персональними даними та платіжною інформацією (банки, страхові компанії, авіаперевізники, платіжні системи, а також державні портали, такі як податкова служба) активно використовують методи асиметричної криптографії.
До чого тут цифровий сертифікат? Все просто. І в першому, і в другому процесі задіяні загальнодоступні ключі, а оскільки вони відіграють центральну роль, дуже важливо переконатися, що ключі справді належать відправнику (завірителю, у разі перевірки підпису) чи одержувачу, а чи не підмінені на ключі зловмисників. Для цього існують цифрові сертифікати, які дозволяють забезпечити справжність і цілісність загальнодоступного ключа.
Примітка: справжність і цілісність загальнодоступного ключа підтверджується таким же чином, що і справжність і цілісність відкритих даних, тобто з використанням електронного цифрового підпису (ЕЦП).
Звідки беруться цифрові сертифікати?За випуск та обслуговування цифрових сертифікатів відповідають довірені центри сертифікації або посвідчувальні центри (УЦ). Заявник запитує випуск сертифікату в УЦ, проходить ідентифікацію в Центрі реєстрації (ЦР) та отримує сертифікат в УЦ. УЦ гарантує, що загальнодоступний ключ із сертифікату належить саме тому суб'єкту, для якого його було випущено.
Якщо не підтверджувати справжність загальнодоступного ключа, то зловмисник під час передачі/зберігання ключа може замінити його на свій власний. Якщо підміна відбулася, то зловмисник зможе розшифрувати все, що абонент-відправник передає абоненту-отримувачу, або змінити відкриті дані на власний розсуд.
Цифрові сертифікати використовують скрізь, де є асиметрична криптографія. Один із найпоширеніших цифрових сертифікатів – це SSL-сертифікати для захищеного режиму взаємодії за протоколом HTTPS. Емісією SSL-сертифікатів займаються сотні компаній, зареєстрованих у різних юрисдикціях. Основна частка припадає на п'ять-десять великих довірених центрів: IdenTrust, Comodo, GoDaddy, GlobalSign, DigiCert, CERTUM, Actalis, Secom, Trustwave.
УЦ та ЦР – це компоненти PKI, до якої також входять:
- Відкритий довідник – загальнодоступна база даних, яка забезпечує надійне зберігання цифрових сертифікатів.
- Список відкликаних сертифікатів – загальнодоступна база даних, яка забезпечує надійне зберігання цифрових сертифікатів анульованих загальнодоступних ключів (наприклад, компрометація парного секретного ключа). Суб'єкти інфраструктури можуть самостійно звертатися до цієї бази даних, а можуть скористатися спеціалізованим протоколом Online Certificate Status Protocol (OCSP), який спрощує процес перевірки.
- Користувачі сертифікатів – суб'єкти PKI, що обслуговуються, уклали з УЦ угоду користувача та здійснюють перевірку цифрового підпису та/або зашифрування даних на основі загальнодоступного ключа із сертифіката.
- передплатники - суб'єкти PKI, що обслуговуються, володіють секретним ключем, парним загальнодоступному ключу з сертифіката, і уклали з УЦ угоду передплатника. Передплатник може бути одночасно користувачем сертифіката.
Таким чином, довірені суб'єкти інфраструктури загальнодоступних ключів, до яких належать УЦ, ЦР та відкриті довідники, відповідають за:
1. Перевірку справжності особи заявника.
2. Профіль сертифіката загальнодоступного ключа.
3. Випуск сертифіката загальнодоступного ключа заявника, достовірність особи якого достовірно підтверджена.
4. Зміна статусу сертифіката загальнодоступного ключа.
5. Надання інформації про поточний статус сертифіката загальнодоступного ключа.
Недоліки PKI, які вони?Фундаментальний недолік PKI — наявність довірених суб'єктів.
Користувачі повинні безумовно довіряти УЦ та ЦР. Але, як показує практика, безумовна довіра загрожує серйозними наслідками.
За останні десять років у цій галузі сталося кілька великих скандалів, пов'язаних із уразливістю інфраструктури.
— у 2010 році в мережі став поширюватися шкідливість Stuxnet, який був підписаний з використанням вкрадених цифрових сертифікатів від RealTek та JMicron.
— 2017 року компанія Google звинуватила Symantec у видачі великої кількості фальсифікованих сертифікатів. На той момент Symantec був одним із найбільших УЦ за обсягами випуску. У браузері Google Chrome 70 було припинено підтримку сертифікатів, емітованих цією компанією та афілійованими з нею центрами GeoTrust та Thawte до 1 грудня 2017 року.
УЦ були скомпрометовані, внаслідок чого постраждали всі — і самі УЦ, а також користувачі та передплатники. Довіра до інфраструктури була підірвана. Крім цього, цифрові сертифікати можуть бути заблоковані в умовах політичних конфліктів, що також позначиться на роботі багатьох ресурсів. Саме цього побоювалися кілька років тому в адміністрації російського президента, де у 2016 році обговорювали можливість створення державного центру, що засвідчує, який би видавав сайтам у рунеті SSL-сертифікати. Поточний стан справ такий, що навіть державні портали в Росії цифрові сертифікати, видані американськими компаніями Comodo або Thawte (дочка Symantec).
Існує ще одна проблема - питання первинної автентифікації користувачів. Як без безпосереднього особистого контакту ідентифікувати користувача, який звернувся до УЦ із запитом на видачу цифрового сертифіката? Наразі це вирішується ситуативно залежно від можливостей інфраструктури. Щось береться з відкритих реєстрів (наприклад, інформація про юросіб, які запитують сертифікати), у випадках, коли заявники — фізособи, можуть використовуватися офіси банків або поштові відділення, де їх особу підтверджують за документами, що засвідчують, наприклад, паспортом.
Проблема фальсифікації облікових даних для імперсоніфікації належить до розряду фундаментальних. Зауважимо, що повноцінного вирішення цієї проблеми не існує через теоретико-інформаційні причини: не маючи достовірної інформації апріорі, неможливо підтвердити або спростувати справжність того чи іншого суб'єкта. Як правило, для перевірки необхідно надати набір документів, що засвідчують особу заявника. Існує безліч різних методик перевірки, але жодна з них не надає повноцінної гарантії достовірності документів. Відповідно, справжність особи заявника також не може бути гарантовано підтверджена.
Як можна усунути ці недоліки?Якщо проблеми PKI у її нинішньому становищі можна пояснити централізацією, то логічно припустити, що децентралізація допомогла б частково усунути ці недоліки.
Децентралізація не передбачає наявності довірених суб'єктів, якщо створити децентралізовану інфраструктуру загальнодоступних ключів (Decentralized Public Key Infrastructure, DPKI), то не потрібні ні УЦ, ні ЦР. Відмовимося від концепції цифрового сертифіката та скористаємося розподіленим реєстром для зберігання інформації про загальнодоступні ключі. Реєстром у разі ми називаємо лінійну базу даних, що складається з окремих записів (блоків), що з технології блокчейн. Замість цифрового сертифіката введемо поняття нотифіката.
Як у пропонованій DPKI буде виглядати процес отримання, перевірки та анулювання нотифікатів:
1. Кожен заявник надсилає заявку на отримання нотифікату самостійно через заповнення форми під час реєстрації, після чого формує транзакцію, що зберігається у спеціалізованому пулі.
2. Інформація про загальнодоступний ключ разом із реквізитами власника та іншими метаданими зберігається у розподіленому реєстрі, а не в цифровому сертифікаті, за емісію якого у централізованій PKI відповідає УЦ.
3. Перевірка справжності особи заявника виконується постфактум спільними зусиллями спільноти користувачів DPKI, а не ЦР.
4. Змінити статус загальнодоступного ключа може лише власник такого нотифіката.
5. Кожен може отримати доступ до розподіленого реєстру та перевірити поточний статус загальнодоступного ключа.
Примітка: на перший погляд, перевірка справжності особи заявника спільнотою може здатися надто ненадійною. Але треба пам'ятати, що зараз всі користувачі цифрових послуг неодмінно залишають цифровий слід, і цей процес тільки продовжить набирати чинності. Відкриті електронні реєстри юросіб, карти, оцифрування зображень місцевості, соцмережі – це загальнодоступні інструменти. Вони вже успішно застосовуються під час розслідувань як журналістами, так і правоохоронними органами. Наприклад, досить згадати розслідування Bellingcat або спільної слідчої групи JIT, яка займається вивченням обставин катастрофи малайзійського Boeing.
Отже, як на практиці працюватиме децентралізована інфраструктура загальнодоступних ключів? Зупинимося на описі самої технології, яку ми запатентували у 2018 році і по праву вважаємо за своє ноу-хау.
Уявіть, є певний власник, якому належить безліч загальнодоступних ключів, де кожен ключ — це транзакція, яка зберігається в реєстрі. Як без УЦ зрозуміти, що всі ключі належать саме цьому власнику? Щоб вирішити це завдання, створюється нульова транзакція, в якій міститься інформація про власника та його гаманця (з якого списується комісія за розміщення транзакції у реєстрі). Нульова транзакція - це своєрідний "якір", до якого будуть прикріплюватися наступні транзакції з даними про загальнодоступні ключі. Кожна така транзакція містить спеціалізовану структуру даних, чи інакше — нотифікат.
Нотифікат – структурований набір даних, що складається з функціональних полів та включає інформацію про загальнодоступний ключ власника, персистентність якого гарантується розміщенням в одному із зв'язаних записів розподіленого реєстру.
Наступне логічне питання – як формується нульова транзакція? Нульова транзакція - як і наступні - є агрегацією шести полів даних. У ході формування нульової транзакції задіяна ключова пара гаманця (загальнодоступний та парний секретний ключі). Ця пара ключів з'являється в той момент, коли користувач реєструє свій гаманець, з якого списуватиметься комісія за розміщення в реєстрі нульової транзакції та згодом операції з нотифікатами.
Як показано на малюнку, дайджест загальнодоступного ключа гаманця формується шляхом послідовного застосування хеш-функцій SHA256 та RIPEMD160. Тут RIPEMD160 відповідає за компактне представлення даних, розрядність яких не перевищує 160 біт. Це важливо – адже реєстр не дешева база даних. Сам загальнодоступний ключ заноситься до п'ятого поля. У першому полі містяться дані, які встановлюють зв'язок із попередньою транзакцією. У нульової транзакції це полі нічого не містить, що відрізняє її від наступних транзакцій. Друге поле – це дані для перевірки зв'язності транзакцій. Для стислості називатимемо дані першого і другого полів “зв'язкою” і “перевіркою” відповідно. Вміст цих полів формується методом ітеративного хешування так, як це показано на прикладі зв'язування другої та третьої транзакцій на малюнку нижче.
Дані з перших п'яти полів засвідчуються ЕЦП, що формується за допомогою секретного ключа гаманця.
Все, нульова транзакція вирушає до пулу і після успішної перевірки заноситься до реєстру. Тепер до неї можна "підв'язувати" наступні транзакції. Розглянемо, як відбувається формування транзакцій, відмінних від нульової.
Перше, що вам, напевно, впало в око — це безліч ключових пар. Крім вже знайомої ключової пари гаманця використовуються ординарна та службова ключові пари.
Ординарний загальнодоступний ключ - це те, заради чого все, власне, і починалося. Цей ключ задіяний у різних процедурах і процесах, що розгортаються в навколишньому світі (банківські та інші транзакції, документообіг тощо). Наприклад, секретний ключ із ординарної пари може використовуватися для формування ЕЦП різних документів — платіжних доручень тощо, а загальнодоступний — для перевірки цієї ЕЦП із подальшим виконанням цих доручень за умови її валідності.
Службова пара видається зареєстрованому суб'єкту DPKI. Назва цієї пари відповідає її призначенню. Зауважимо, що для формування/перевірки нульової транзакції службові ключі не застосовуються.
Ще раз уточнимо призначення ключів:
- Ключі гаманця застосовуються для формування/перевірки як нульової, так і будь-якої іншої, відмінної від нульової транзакції. Секретний ключ гаманця відомий лише власнику гаманця, який одночасно є власником множини ординарних загальнодоступних ключів.
- Ординарний загальнодоступний ключ за своїм призначенням аналогічний загальнодоступному ключу, для якого випускається сертифікат централізованої PKI.
- Службова пара ключів належить DPKI. Секретний ключ видається зареєстрованим суб'єктам і використовується для формування ЕЦП транзакцій (крім нульової). Загальнодоступний застосовується для перевірки ЕЦП транзакції перед розміщенням у реєстрі.
Таким чином, є дві групи ключів. У першу входять службові ключі та ключі гаманця – мають сенс лише у контексті DPKI. До другої групи входять ординарні ключі — їх сфера застосування може відрізнятися обумовлена тими прикладними завданнями, у яких використовуються. При цьому DPKI забезпечує цілісність та справжність ординарних загальнодоступних ключів.
Примітка: Службова ключова пара може бути відома різним суб'єктам DPKI. Наприклад, може бути єдиною всім. Саме з цієї причини при формуванні підпису кожної ненульової транзакції застосовується два секретні ключі, один з яких ключ гаманця — він відомий лише власнику гаманця, який одночасно є власником безлічі ординарних загальнодоступних ключів. Усі ключі мають власний сенс. Наприклад, завжди можна довести, що транзакція була занесена до Реєстру зареєстрованим суб'єктом DPKI, оскільки підпис був сформований у тому числі і на секретному службовому ключі. І тут не може бути зловживань, наприклад, DOS-атаки, адже власник оплачує кожну транзакцію.
Всі транзакції, які йдуть за нульовою, формуються схожим чином: загальнодоступний ключ (але не гаманця, як у випадку з нульовою транзакцією, а з ординарної ключової пари) проганяється через дві хеш-функції SHA256 і RIPEMD160. Так формуються дані третього поля. У четверте поле заноситься супроводжуюча інформація (наприклад, інформація про поточний статус, терміни дії, тимчасова позначка, ідентифікатори криптоалгоритмів тощо). У п'ятому полі — загальнодоступний ключ із службової ключової пари. З його допомогою потім перевірятиметься ЕЦП, тому він тиражується. Обґрунтуємо необхідність такого підходу.
Нагадаємо, що транзакція заноситься в пул і зберігається там доти, доки не буде оброблена. Зберігання в пулі пов'язане з певним ризиком – ці транзакції можуть бути сфальсифіковані. Власник запевняє дані транзакції ЕЦП. Загальнодоступний ключ для перевірки цієї ЕЦП вказується в одному з полів транзакції у явному вигляді і згодом заноситься до Реєстру. Особливості обробки транзакції такі, що зловмисник здатний змінити дані на свій розсуд і потім завірити їх за допомогою свого секретного ключа, а загальнодоступний парний ключ для перевірки ЕЦП вказати в транзакції. Якщо справжність і цілісність забезпечується виключно за допомогою ЕЦП, то така фальсифікація залишиться непоміченою. Однак, якщо крім ЕЦП існує додатковий механізм, що забезпечує одночасно архівування і персистентність інформації, що зберігається, то підробку можливо виявити. Для цього достатньо занести до Реєстру справжній загальнодоступний ключ власника. Пояснимо, як це працює.
Нехай зловмисник виконує фальсифікацію даних транзакції. З погляду ключів та ЕЦП можливі такі варіанти:
1. Зловмисник розміщує у транзакції свій загальнодоступний ключ за постійної ЕЦП власника.
2. Зловмисник формує ЕЦП на своєму секретному ключі, але залишає загальнодоступний ключ власника без змін.
3. Зловмисник формує ЕЦП на своєму секретному ключі та розміщує у транзакції парний загальнодоступний ключ.
Очевидно, що варіанти 1 і 2 безглузді, оскільки завжди будуть виявлені під час перевірки ЕЦП. Сенс має лише варіант 3, і якщо зловмисник формує ЕЦП на своєму власному секретному ключі, він змушений зберігати в транзакції парний загальнодоступний ключ, відмінний від загальнодоступного ключа власника. Для зловмисника це єдиний спосіб нав'язати сфальшовані дані.
Припустимо, що власник має в своєму розпорядженні фіксовану пару ключів - секретний і загальнодоступний. Нехай дані засвідчуються ЕЦП за допомогою секретного ключа цієї пари, а загальнодоступний ключ вказується в транзакції. Припустимо також, що цей загальнодоступний ключ був раніше занесений до реєстру і його достовірно підтверджено. Тоді на фальсифікацію буде вказувати та обставина, що загальнодоступний ключ із транзакції не відповідає загальнодоступному ключу з реєстру.
Підведемо підсумок. При обробці даних першої транзакції власника необхідно підтвердити справжність занесеного в реєстр загальнодоступного ключа. Для цього слід прочитати ключ із реєстру та виконати його звірення з істинним загальнодоступним ключем власника в межах периметра безпеки (область відносної невразливості). Якщо достовірність ключа підтверджена і його персистентність гарантується за фактом розміщення, то справжність ключа з наступної транзакції легко підтвердити/спростувати шляхом звірення ключа з ключем з реєстру. Іншими словами, ключ із реєстру використовується як еталонний зразок. Аналогічно обробляються всі інші транзакції власника.
Транзакція засвідчується ЕЦП — тут і знадобляться секретні ключі, і не один, а одразу два — службовий та гаманець. Завдяки використанню двох секретних ключів забезпечується необхідний рівень безпеки - адже службовий секретний ключ може бути відомий іншим користувачам, тоді як секретний ключ гаманця відомий лише власнику ординарної ключової пари. Ми назвали такий двох ключовий підпис “консолідованим” ЕЦП.
Перевірка транзакцій, відмінних від нульової, виконується з використанням двох загальнодоступних ключів: гаманця та службового. Процес перевірки можна розділити на два основні етапи: перший – це перевірка дайджесту загальнодоступного ключа гаманця, а другий – перевірка ЕЦП транзакції, тієї самої, консолідованої, яка була сформована за допомогою двох секретних ключів (гаманця та службового). Якщо валідність ЕЦП підтверджена, то після додаткової перевірки транзакція заноситься до Реєстру.
Може виникнути логічне питання: як перевірити чи належить транзакція конкретного ланцюжка з “коренем” як нульової транзакції? Для цього процес перевірки доповнено ще однією стадією – перевіркою зв'язності. Тут нам і знадобляться дані з перших двох полів, які поки що ми обходили своєю увагою.
Уявімо, що нам треба перевірити, чи справді транзакція №3 йде після транзакції №2. Для цього методом комбінованого хешування обчислюється значення хеш-функція для даних третього, четвертого і п'ятого полів транзакції №2. Потім виконується конкатенація даних першого поля транзакції №3 і раніше отримане значення комбінованої хеш-функції для даних з третього, четвертого і п'ятого полів транзакції №2. Все це теж проганяється через дві хеш-функції SHA256 та RIPEMD160. Якщо отримане значення збігається з даними другого поля транзакції №2, перевірку пройдено і зв'язність підтверджено. Наочно це показано на рисунках нижче.
Загалом технологія формування та занесення нотифікату до Реєстру виглядає саме таким чином. Наочна ілюстрація процесу формування ланцюжка нотифікатів представлена на малюнку:
У цьому тексті ми не зупинятимемося на деталях, які, безперечно, існують, і повернемося до обговорення ідеї децентралізованої інфраструктури загальнодоступних ключів.
Отже, оскільки заявник сам надсилає заявку на реєстрацію нотифікатів, які зберігаються не в базі даних УЦ, а в реєстрі, то основними архітектурними компонентами DPKI слід вважати:
1. Реєстр чинних нотифікатів (РДН).
2. Реєстр відкликаних нотифікатів (РВН).
3. Реєстр призупинених нотифікатів (РНН).
Інформація про загальнодоступні ключі зберігається у РДН/РОН/РПН у вигляді значень хеш-функції. Варто також зауважити, що це можуть бути як різні реєстри, так і різні ланцюжки або навіть один ланцюжок у складі єдиного реєстру, коли інформація про статус ординарного загальнодоступного ключа (відкликання, призупинення дії тощо) заноситься до четвертого поля структури даних у вигляді відповідного кодового значення. Існує безліч різних варіантів архітектурної реалізації DPKI та вибір того чи іншого залежить від ряду факторів, наприклад такого критерію оптимізації як витрати довготривалої пам'яті для зберігання загальнодоступних ключів та ін.
Таким чином, DPKI може виявитися якщо не простіше, то щонайменше можна порівняти з централізованим рішенням щодо складності архітектури.
Залишається головне питання - який реєстр підійде реалізації технології?
Головна вимога до реєстру – можливість формування транзакцій довільного типу. Найвідоміший приклад застосування реєстру – це мережа Біткойн. Але в ній при реалізації описаної вище технології виникають певні труднощі: дається взнаки обмеженість існуючої мови сценаріїв, відсутність необхідних механізмів для обробки довільних наборів даних, способів формування транзакцій довільного типу, а також багато іншого.
Ми в компанії ENCRY спробували вирішити сформульовані вище проблеми та розробили реєстр, який, на наш погляд, має низку переваг, а саме:
- підтримує кілька типів транзакцій: у ньому можна як обмінюватися активами (тобто виконувати фінансові транзакції), так і формувати транзакції з довільною структурою,
- розробникам доступний пропрієтарний мовою програмування PrismLang, що забезпечує необхідну гнучкість при вирішенні різних технологічних завдань,
- передбачено механізм обробки довільних наборів даних.
Якщо підходити спрощено, має місце наступна послідовність дій:
- Заявник реєструється в DPKI та отримує цифровий гаманець. Адреса гаманця — це значення хеш-функції від загальнодоступного ключа гаманця. Секретний ключ гаманця відомий лише заявнику.
- Зареєстрованому суб'єкту надається доступ до службового секретного ключа.
- Суб'єкт формує нульову транзакцію та засвідчує її ЕЦП з використанням секретного ключа гаманця.
- Якщо формується відмінна від нульової транзакція, то запевняє її ЕЦП із використанням двох секретних ключів: гаманця та службового.
- Суб'єкт відправляє транзакцію в пул.
- Вузол мережі ENCRY зчитує транзакцію з пулу та перевіряє ЕЦП, а також зв'язність транзакції.
- Якщо ЕЦП валідна та зв'язність підтверджена, то готує транзакцію для занесення до Реєстру.
Тут реєстр виступає в ролі розподіленої бази даних, в якій зберігається інформація про діючі, анульовані та призупинені нотифікати.
Звісно, децентралізація не панацея. Фундаментальна проблема первинної аутентифікації користувачів нікуди не зникає: якщо в даний час перевіркою заявника займаються ЦР, то в DPKI перевірку пропонується делегувати учасникам спільноти та використовувати фінансову мотивацію для стимуляції активності. Технологія перевірки відкритих джерел добре відома. Ефективність такої перевірки підтверджена практично. Знову ж таки згадаємо ряд резонансних розслідувань інтернет-видання Bellingcat.
Але загалом складається така картина: DPKI — це можливість виправити, якщо не всі, то багато недоліків централізованої PKI.
Підписуйтесь на наш Хабраблог, ми плануємо і надалі активно висвітлювати наші дослідження та розробки, та стежте за , якщо не бажаєте пропустити інші новини про проекти ENCRY.
Джерело: habr.com