DPKI: ухіляем недахопы цэнтралізаванай PKI пры дапамозе блокчейна

DPKI: ухіляем недахопы цэнтралізаванай PKI пры дапамозе блокчейна

Ні для каго не сакрэт, што адзін з агульнараспаўсюджаных дапаможных інструментаў, без якога немагчыма абарона дадзеных у адкрытых сетках, – гэта тэхналогія лічбавых сертыфікатаў. Зрэшты, не з'яўляецца сакрэтам і тое, што галоўны недахоп гэта тэхналогіі – безумоўны давер да цэнтраў, якія выпускаюць лічбавыя сертыфікаты. Дырэктар па тэхналогіях і інавацыях кампаніі ENCRY Андрэй Чмара прапанаваў новы падыход да арганізацыі інфраструктуры агульнадаступных ключоў (Public Key Infrastructure, PKI), які дапаможа ліквідаваць існуючыя ў цяперашні час недахопы і які выкарыстоўвае тэхналогію размеркаванага рэестра (блокчэйна). Але пра ўсё па парадку.

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

Што такое лічбавыя подпісы і сертыфікаты?Узаемадзеянне ў Інтэрнеце заўсёды мае на ўвазе перадачу даных. Усе мы зацікаўлены ў тым, каб дадзеныя перадаваліся бяспечным чынам. Але што такое бяспека? Найбольш запатрабаваныя паслугі бяспекі - гэта канфідэнцыйнасць, цэласнасць і сапраўднасць. Для гэтага ў наш час ужываюцца метады асіметрычнай крыптаграфіі, ці крыптаграфіі з агульнадаступным ключом.

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

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

DPKI: ухіляем недахопы цэнтралізаванай PKI пры дапамозе блокчейна

Як дасягаецца цэласнасць і сапраўднасць перадаванай інфармацыі? Для рашэння гэтай задачы быў створаны іншы механізм. Адкрытыя дадзеныя не шыфруюцца, але разам з ім перадаецца вынік ужывання крыптаграфічнай хэш-функцыі - «сціснутая» выява ўваходнай паслядоўнасці дадзеных - у зашыфраваным выглядзе. Вынік такога хэшавання завецца "дайджэстам", а яго зашыфраванне вырабляецца на сакрэтным ключы абанента-адпраўніка ("заверителя"). У выніку зашыфравання дайджэста атрымліваецца лічбавы подпіс. Яна разам з адкрытым тэкстам перадаецца абаненту-атрымальніку (“правяраючым”). Той расшыфроўвае лічбавы подпіс на адчыненым ключы заверителя і параўноўвае з вынікам ужывання крыптаграфічнай хэш-функцыі, які правяраючы вылічае самастойна на аснове прынятых адчыненых дадзеных. Калі яны супадаюць, то гэта сведчыць аб тым, што дадзеныя былі перададзены ў сапраўдным і цэласным выглядзе менавіта абанентам-адпраўніком, а не перайначаны зламыснікам.

DPKI: ухіляем недахопы цэнтралізаванай 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 годзе і па праве лічым сваім ноў-хаў.

Уявіце, ёсць некаторы ўладальнік, якому належыць мноства агульнадаступных ключоў, дзе кожны ключ - гэта нейкая транзакцыя, якая захоўваецца ў рэестры. Як у адсутнасці УЦ зразумець, што ўсе ключы належаць менавіта гэтаму ўладальніку? Каб вырашыць гэтую задачу, ствараецца нулявая транзакцыя, у якой змяшчаецца інфармацыя аб уладальніку і яго кашальку (з якога спісваецца камісія за размяшчэнне транзакцыі ў рэестры). Нулявая транзакцыя - гэта своеасаблівы "якар", да якога будуць прымацоўвацца наступныя транзакцыі з дадзенымі аб агульнадаступных ключах. Кожная такая транзакцыя змяшчае спецыялізаваную структуру дадзеных, ці па-іншаму - натыфікат.

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

Наступнае лагічнае пытанне - як фармуецца нулявая транзакцыя? Нулявая транзакцыя - як і наступныя - уяўляе сабой агрэгацыю шасці палёў дадзеных. У ходзе фарміравання нулявой транзакцыі задзейнічана ключавая пара кашалька (агульнадаступны і парны сакрэтны ключы). Гэтая пара ключоў з'яўляецца ў той момант, калі карыстач рэгіструе свой кашалёк, з якога будзе спісвацца камісія за размяшчэнне ў рэестры нулявой транзакцыі і - пасля - аперацыі з натыфікатамі.

DPKI: ухіляем недахопы цэнтралізаванай PKI пры дапамозе блокчейна

Як паказана на малюнку, дайджэст агульнадаступнага ключа кашалька фармуецца шляхам паслядоўнага ўжывання хэш-функцый SHA256 і RIPEMD160. Тут RIPEMD160 адказвае за кампактнае паданне дадзеных, разраднасць якіх не перавышае 160 біт. Гэта важна - бо рэестр не танная база дадзеных. Сам агульнадаступны ключ заносіцца ў пятае поле. У першым полі змяшчаюцца даныя, якія ўстанаўліваюць сувязь з папярэдняй транзакцыяй. У нулявой транзакцыі гэтае поле нічога не ўтрымоўвае, што адрознівае яе ад наступных транзакцый. Другое поле - гэта дадзеныя для праверкі складнасці транзакцый. Для сцісласці будзем зваць дадзеныя першага і другога палёў "звязкам" і "праверкай" адпаведна. Змест гэтых палёў фарміруецца метадам ітэратыўнага хэшавання так, як гэта прадэманстравана на прыкладзе звязвання другой і трэцяй транзакцый на малюнку ніжэй.

DPKI: ухіляем недахопы цэнтралізаванай PKI пры дапамозе блокчейна

Дадзеныя з першых пяці палёў завяраюцца ЭЛП, якая фармуецца пры дапамозе сакрэтнага ключа кашалька.

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

DPKI: ухіляем недахопы цэнтралізаванай PKI пры дапамозе блокчейна

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

Ардынарны агульнадаступны ключ – гэта тое, дзеля чаго ўсё, уласна, і ладзілася. Гэты ключ задзейнічаны ў розных працэдурах і працэсах, якія разгортваюцца ў навакольным свеце (банкаўскія і іншыя транзакцыі, дакументазварот, і інш.). Напрыклад, сакрэтны ключ з ардынарнай пары можа выкарыстоўвацца для фарміравання ЭЛП розных дакументаў - плацежных даручэнняў і г.д., а агульнадаступны - для праверкі гэтай ЭЛП з наступным выкананнем гэтых даручэнні пры ўмове яе валіднасці.

Службовая пара выдаецца зарэгістраванаму суб'екту DPKI. Назва гэтай пары адпавядае яе прызначэнню. Заўважым, што пры фармаванні/праверцы нулявой транзакцыі службовыя ключы не ўжываюцца.

Яшчэ раз удакладнім прызначэнне ключоў:

  1. Ключы кашалька ўжываюцца для фармавання/праверкі як нулявы, так і любы іншы, выдатнай ад нулявой, транзакцыі. Сакрэтны ключ кашалька вядомы толькі ўладальніку кашалька, які адначасова з'яўляецца ўладальнікам мноства ардынарных агульнадаступных ключоў.
  2. Ардынарны агульнадаступны ключ па сваім прызначэнні аналагічны агульнадаступным ключы, для якога выпускаецца сертыфікат у цэнтралізаванай PKI.
  3. Службовая пара ключоў належыць DPKI. Сакрэтны ключ выдаецца зарэгістраваным суб'ектам і выкарыстоўваецца пры фарміраванні ЭЛП транзакцый (за выключэннем нулявой). Агульнадаступны прымяняецца для праверкі ЭЛП транзакцыі перад яе размяшчэннем у рэестры.

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

Заўвага: Службовая ключавая пара можа быць вядома розным суб'ектам DPKI. Напрыклад, можа быць адзінай для ўсіх. Менавіта па гэтай прычыне пры фарміраванні подпісу кожнай ненулявой транзакцыі прымяняецца два сакрэтныя ключы, адзін з якіх ключ кашалька - ён вядомы толькі ўладальніку кашалька, які адначасова з'яўляецца уладальнікам мноства ардынарных агульнадаступных ключоў. Усе ключы маюць свой сэнс. Напрыклад, заўсёды можна даказаць, што транзакцыя была занесена ў рэестр зарэгістраваным суб'ектам DPKI, бо подпіс быў сфарміраваны ў тым ліку і на сакрэтным службовым ключы. І тут не можа быць злоўжыванняў, напрыклад DOS-напады, бо ўладальнік аплачвае кожную транзакцыю.

Усе транзакцыі, якія ідуць следам за нулявой, фармуюцца падобнай выявай: агульнадаступны ключ (але не кашалька, як у выпадку з нулявой транзакцыяй, а з ардынарнай ключавой пары) праганяецца праз дзве хэш-функцыі SHA256 і RIPEMD160. Так фармуюцца дадзеныя трэцяга поля. У чацвёртае поле заносіцца суправаджальная інфармацыя (напрыклад, інфармацыя аб бягучым статусе, тэрмінах дзеяння, часовая адзнака, ідэнтыфікатары выкарыстоўваных крыптаалгарытмаў і інш.). У пятым полі - агульнадаступны ключ са службовай ключавой пары. З яго дапамогай потым будзе правярацца ЭЛП, таму ён тыражуецца. Абгрунтуем неабходнасць такога падыходу.

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

Няхай зламыснік выконвае падробку дадзеных транзакцыі. З пункту гледжання ключоў і ЭЛП магчымыя наступныя варыянты:

1. Зламыснік размяшчае ў транзакцыі свой агульнадаступны ключ пры нязменнай ЭЛП уладальніка.
2. Зламыснік фармуе ЭЛП на сваім сакрэтным ключы, але пакідае агульнадаступны ключ уладальніка без змен.
3. Зламыснік фармуе ЭЛП на сваім сакрэтным ключы і размяшчае ў транзакцыі парны агульнадаступны ключ.

Відавочна, што варыянты 1 і 2 бессэнсоўныя, бо заўсёды будуць выяўлены падчас праверкі ЭЛП. Сэнс мае толькі варыянт 3, і калі зламыснік фармуе ЭЛП на сваім уласным сакрэтным ключы, то ён змушаны захоўваць у транзакцыі парны агульнадаступны ключ, адрозны ад агульнадаступнага ключа ўладальніка. Для зламысніка гэта адзіны спосаб навязаць сфальсіфікаваныя дадзеныя.

Выкажам здагадку, што ўладальнік размяшчае фіксаванай парай ключоў – сакрэтным і агульнадаступным. Няхай дадзеныя завяраюцца ЭЛП пры дапамозе сакрэтнага ключа з гэтай пары, а агульнадаступны ключ паказваецца ў транзакцыі. Выкажам здагадку таксама, што гэты агульнадаступны ключ ужо быў раней занесены ў рэестр і яго сапраўднасць дакладна пацверджана. Тады на падлог будзе ўказваць тая акалічнасць, што агульнадаступны ключ з транзакцыі не адпавядае агульнадаступнаму ключу з рэестра.

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

Транзакцыя завяраецца ЭЛП - тут вось і спатрэбяцца сакрэтныя ключы, і не адзін, а адразу два - службовы і кашалька. Дзякуючы выкарыстанню двух сакрэтных ключоў забяспечваецца неабходны ўзровень бяспекі - бо службовы сакрэтны ключ можа быць вядомы іншым карыстачам, тады як сакрэтны ключ кашалька вядомы толькі ўладальніку ардынарнай ключавой пары. Мы назвалі такі двух ключавы подпіс “кансалідаваным” ЭЛП.

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

DPKI: ухіляем недахопы цэнтралізаванай PKI пры дапамозе блокчейна

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

Уявім, што нам трэба праверыць, ці сапраўды транзакцыя №3 ідзе пасля транзакцыі №2. Для гэтага метадам камбінаванага хэшавання вылічаецца значэнне хэш-функцыя для дадзеных з трэцяга, чацвёртага і пятага палёў транзакцыі №2. Потым выконваецца канкатэнацыя звестак з першага поля транзакцыі №3 і раней атрыманае значэнне камбінаванай хэш-функцыі для звестак з трэцяга, чацвёртага і пятага палёў транзакцыі №2. Усё гэта таксама праганяецца праз дзве хэш-функцыі SHA256 і RIPEMD160. Калі атрыманае значэнне супадае з дадзеным другога поля транзакцыі №2, то праверка пройдзена і складнасць пацверджана. Больш наглядна гэта паказана на малюнках ніжэй.

DPKI: ухіляем недахопы цэнтралізаванай PKI пры дапамозе блокчейна
DPKI: ухіляем недахопы цэнтралізаванай PKI пры дапамозе блокчейна

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

DPKI: ухіляем недахопы цэнтралізаванай PKI пры дапамозе блокчейна

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

Такім чынам, паколькі заяўнік сам адпраўляе заяўку на рэгістрацыю натыфікатаў, якія захоўваюцца не ў базе даных УЦ, а ў рэестры, то асноўнымі архітэктурнымі кампанентамі DPKI трэба лічыць:

1. Рэестр дзейных натыфікатаў (РДН).
2. Рэестр адкліканых натыфікатаў (РОН).
3. Рэестр прыпыненых натыфікатаў (РПН).

Інфармацыя аб агульнадаступных ключах захоўваецца ў РДН/РОН/РПН у выглядзе значэнняў хэш-функцыі. Варта таксама заўважыць, што гэта могуць быць як розныя рэестры, так і розныя ланцужкі ці нават адзін ланцужок у складзе адзінага рэестра, калі інфармацыя аб статусе ардынарнага агульнадаступнага ключа (водгук, прыпыненне дзеяння і інш.) заносіцца ў чацвёртае поле структуры дадзеных у выглядзе адпаведнага кодавага значэння. Існуе мноства розных варыянтаў архітэктурнай рэалізацыі DPKI і выбар таго, ці іншага, залежыць ад шэрагу фактараў, напрыклад такога крытэра аптымізацыі як выдаткі доўгачасовай памяці для захоўвання агульнадаступных ключоў і інш.

Такім чынам, DPKI можа апынуцца калі не прасцей, то сама меней параўнальнай з цэнтралізаваным рашэннем па складанасці архітэктуры.

Застаецца галоўнае пытанне - які рэестр падыдзе для рэалізацыі тэхналогіі?

Галоўнае патрабаванне да рэестра - магчымасць фарміравання транзакцый адвольнага тыпу. Самы вядомы прыклад прымянення рэестра - гэта сетка Біткойн. Але ў ёй пры рэалізацыі апісанай вышэй тэхналогіі ўзнікаюць вызначаныя цяжкасці: адбіваецца абмежаванасць існай мовы сцэнараў, адсутнасць неабходных механізмаў для апрацоўкі адвольных набораў дадзеных, спосабаў фармавання транзакцый адвольнага тыпу, а таксама шматлікае іншае.

Мы ў кампаніі ENCRY паспрабавалі вырашыць сфармуляваныя вышэй праблемы і распрацавалі рэестр, які, на наш погляд, мае шэраг пераваг, а менавіта:

  • падтрымлівае некалькі тыпаў транзакцый: у ім можна як абменьвацца актывамі (гэта значыць выконваць фінансавыя транзакцыі), так і фармаваць транзакцыі з адвольнай структурай,
  • распрацоўнікам даступны прапрыетарны мове праграмаванні PrismLang, які забяспечвае неабходную гнуткасць пры рашэнні розных тэхналагічных задач,
  • прадугледжаны механізм апрацоўкі адвольных набораў даных.

Калі падыходзіць спрошчана, тое мае месца наступная паслядоўнасць дзеянняў:

  1. Заяўнік рэгіструецца ў DPKI і атрымлівае лічбавы кашалёк. Адрас кашалька - значэнне хэш-функцыі ад агульнадаступнага ключа кашалька. Сакрэтны ключ кашалька вядомы толькі заяўніку.
  2. Зарэгістраванаму суб'екту даецца доступ да службовага сакрэтнага ключа.
  3. Суб'ект фармуе нулявую транзакцыю і запэўнівае яе ЭЛП з выкарыстаннем сакрэтнага ключа кашалька.
  4. Калі фармуецца выдатная ад нулявой транзакцыя, тое запэўнівае яе ЭЛП з выкарыстаннем двух сакрэтных ключоў: кашалька і службовага.
  5. Суб'ект адпраўляе транзакцыю ў пул.
  6. Вузел сеткі ENCRY счытвае транзакцыю з пула і правярае ЭЛП, а таксама складнасць транзакцыі.
  7. Калі ЭЛП валідная і складнасць пацверджана, то падрыхтоўвае транзакцыю для занясення ў рэестр.

Тут рэестр выступае ў ролі размеркаванай базы даных, у якой захоўваецца інфармацыя аб дзеючых, ануляваных і прыпыненых натыфікатах.

Канешне, дэцэнтралізацыя не панацэя. Фундаментальная праблема першаснай аўтэнтыфікацыі карыстальнікаў нікуды не знікае: калі ў цяперашні час праверкай заяўніка займаюцца ЦР, то ў DPKI праверку прапануецца дэлегаваць удзельнікам суполкі, і выкарыстоўваць фінансавую матывацыю для стымуляцыі актыўнасці. Тэхналогія праверкі па адкрытых крыніцах добра вядомая. Эфектыўнасць такой праверкі пацверджана на практыцы. Ізноў жа ўспомнім шэраг рэзанансных расследаванняў інтэрнэт-выданні Bellingcat.

Але ўвогуле складаецца наступная карціна: DPKI - гэта магчымасць выправіць, калі не ўсё, то шматлікія недахопы цэнтралізаванай PKI.

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

Крыніца: habr.com

Дадаць каментар