Hindi lihim na ang isa sa mga karaniwang ginagamit na pantulong na tool, kung wala ang proteksyon ng data sa mga bukas na network ay imposible, ay ang teknolohiya ng digital na sertipiko. Gayunpaman, hindi lihim na ang pangunahing disbentaha ng teknolohiya ay walang pasubaling pagtitiwala sa mga sentro na naglalabas ng mga digital na sertipiko. Ang Direktor ng Teknolohiya at Innovation sa ENCRY Andrey Chmora ay nagmungkahi ng isang bagong diskarte sa pag-oorganisa pampublikong pangunahing imprastraktura (Public Key Infrastructure, PKI), na makakatulong na maalis ang mga kasalukuyang pagkukulang at gumagamit ng distributed ledger (blockchain) na teknolohiya. Ngunit una sa lahat.
Kung pamilyar ka sa kung paano gumagana ang iyong kasalukuyang pampublikong pangunahing imprastraktura at alam ang mga pangunahing pagkukulang nito, maaari kang lumaktaw sa kung ano ang iminumungkahi naming baguhin sa ibaba.
Ano ang mga digital na lagda at sertipiko?Ang pakikipag-ugnayan sa Internet ay palaging nagsasangkot ng paglilipat ng data. Lahat tayo ay may interes sa pagtiyak na ang data ay naipadala nang ligtas. Ngunit ano ang seguridad? Ang pinaka-hinahangad na serbisyo sa seguridad ay pagiging kumpidensyal, integridad at pagiging tunay. Para sa layuning ito, kasalukuyang ginagamit ang mga pamamaraan ng asymmetric cryptography, o cryptography na may pampublikong key.
Magsimula tayo sa katotohanan na upang magamit ang mga pamamaraang ito, ang mga paksa ng pakikipag-ugnayan ay dapat magkaroon ng dalawang indibidwal na magkapares na susi - pampubliko at lihim. Sa tulong nila, ibinibigay ang mga serbisyong panseguridad na binanggit namin sa itaas.
Paano nakakamit ang pagiging kumpidensyal ng paglilipat ng impormasyon? Bago magpadala ng data, ang nagpapadalang subscriber ay nag-e-encrypt (cryptographically transforms) ang bukas na data gamit ang pampublikong susi ng tatanggap, at ang tatanggap ay nagde-decrypt ng natanggap na ciphertext gamit ang ipinares na sikretong key.
Paano nakakamit ang integridad at pagiging tunay ng ipinadalang impormasyon? Upang malutas ang problemang ito, nilikha ang isa pang mekanismo. Ang bukas na data ay hindi naka-encrypt, ngunit ang resulta ng paglalapat ng cryptographic hash function - isang "compressed" na imahe ng input data sequence - ay ipinadala sa naka-encrypt na form. Ang resulta ng naturang hashing ay tinatawag na "digest", at ito ay naka-encrypt gamit ang lihim na susi ng nagpapadalang subscriber ("ang saksi"). Bilang resulta ng pag-encrypt ng digest, isang digital signature ang nakuha. Ito, kasama ang malinaw na teksto, ay ipinapadala sa tatanggap na subscriber ("verifier"). Ide-decrypt niya ang digital signature sa public key ng testigo at ikinukumpara ito sa resulta ng paglalapat ng cryptographic hash function, na hiwalay na kinakalkula ng verifier batay sa natanggap na bukas na data. Kung magkatugma ang mga ito, ipinapahiwatig nito na ang data ay ipinadala sa isang tunay at kumpletong anyo ng nagpapadalang subscriber, at hindi binago ng isang umaatake.
Karamihan sa mga mapagkukunan na gumagana sa personal na data at impormasyon sa pagbabayad (mga bangko, kompanya ng insurance, airline, sistema ng pagbabayad, pati na rin ang mga portal ng gobyerno tulad ng serbisyo sa buwis) ay aktibong gumagamit ng mga pamamaraan ng asymmetric na cryptography.
Ano ang kinalaman ng digital certificate dito? Simple lang. Parehong ang una at pangalawang proseso ay kinabibilangan ng mga pampublikong susi, at dahil gumaganap ang mga ito ng isang pangunahing papel, napakahalagang tiyakin na ang mga susi ay talagang pagmamay-ari ng nagpadala (ang saksi, sa kaso ng pag-verify ng lagda) o ang tatanggap, at hindi pinalitan ng mga susi ng mga umaatake. Ito ang dahilan kung bakit umiiral ang mga digital na sertipiko upang matiyak ang pagiging tunay at integridad ng pampublikong susi.
Tandaan: ang pagiging tunay at integridad ng pampublikong susi ay nakumpirma sa eksaktong parehong paraan tulad ng pagiging tunay at integridad ng pampublikong data, iyon ay, gamit ang isang electronic digital signature (EDS).
Saan nagmula ang mga digital na sertipiko?Ang mga pinagkakatiwalaang awtoridad sa sertipikasyon, o Mga Awtoridad ng Sertipikasyon (CA), ay may pananagutan sa pag-isyu at pagpapanatili ng mga digital na sertipiko. Ang aplikante ay humiling ng pagpapalabas ng isang sertipiko mula sa CA, sumasailalim sa pagkakakilanlan sa Registration Center (CR) at tumatanggap ng isang sertipiko mula sa CA. Ginagarantiyahan ng CA na ang pampublikong susi mula sa sertipiko ay eksaktong pagmamay-ari ng entity kung saan ito ibinigay.
Kung hindi mo kinukumpirma ang pagiging tunay ng pampublikong susi, ang isang umaatake sa panahon ng paglilipat/pag-imbak ng susi na ito ay maaaring palitan ito ng kanyang sarili. Kung naganap ang pagpapalit, magagawa ng attacker na i-decrypt ang lahat ng ipinadala ng nagpapadalang subscriber sa tumatanggap na subscriber, o baguhin ang bukas na data sa kanyang sariling paghuhusga.
Ginagamit ang mga digital na sertipiko saanman available ang asymmetric cryptography. Ang isa sa mga pinakakaraniwang digital na sertipiko ay ang mga SSL certificate para sa secure na komunikasyon sa HTTPS protocol. Daan-daang kumpanyang nakarehistro sa iba't ibang hurisdiksyon ang kasangkot sa pag-isyu ng mga SSL certificate. Ang pangunahing bahagi ay nasa lima hanggang sampung malalaking pinagkakatiwalaang sentro: IdenTrust, Comodo, GoDaddy, GlobalSign, DigiCert, CERTUM, Actalis, Secom, Trustwave.
Ang CA at CR ay mga bahagi ng PKI, na kinabibilangan din ng:
- Buksan ang direktoryo β isang pampublikong database na nagbibigay ng ligtas na imbakan ng mga digital na sertipiko.
- Listahan ng pagbawi ng sertipiko β isang pampublikong database na nagbibigay ng secure na imbakan ng mga digital na sertipiko ng mga binawi na pampublikong key (halimbawa, dahil sa kompromiso ng isang ipinares na pribadong key). Ang mga paksa ng imprastraktura ay maaaring independiyenteng ma-access ang database na ito, o maaari nilang gamitin ang espesyal na Online Certification Status Protocol (OCSP), na nagpapasimple sa proseso ng pag-verify.
- Mga gumagamit ng sertipiko β mga naserbisyuhan na paksa ng PKI na pumasok sa isang kasunduan ng user sa CA at i-verify ang digital signature at/o encrypt na data batay sa pampublikong key mula sa certificate.
- Mga tagasunod β nagsilbi sa mga paksa ng PKI na nagmamay-ari ng isang lihim na susi na ipinares sa pampublikong susi mula sa sertipiko, at na pumasok sa isang kasunduan ng subscriber sa CA. Ang subscriber ay maaaring sabay na maging user ng certificate.
Kaya, ang mga pinagkakatiwalaang entity ng pampublikong pangunahing imprastraktura, na kinabibilangan ng mga CA, CR at bukas na direktoryo, ay may pananagutan para sa:
1. Pagpapatunay ng pagiging tunay ng pagkakakilanlan ng aplikante.
2. Pag-profile sa public key certificate.
3. Pag-isyu ng isang pampublikong susi na sertipiko para sa isang aplikante na ang pagkakakilanlan ay maaasahang nakumpirma.
4. Baguhin ang status ng public key certificate.
5. Pagbibigay ng impormasyon tungkol sa kasalukuyang katayuan ng public key certificate.
Disadvantages ng PKI, ano sila?Ang pangunahing depekto ng PKI ay ang pagkakaroon ng mga pinagkakatiwalaang entity.
Ang mga user ay dapat na walang kondisyong magtiwala sa CA at CR. Ngunit, tulad ng ipinapakita ng kasanayan, ang walang kondisyong pagtitiwala ay puno ng malubhang kahihinatnan.
Sa nakalipas na sampung taon, nagkaroon ng ilang malalaking iskandalo sa lugar na ito na may kaugnayan sa kahinaan sa imprastraktura.
β noong 2010, nagsimulang kumalat ang Stuxnet malware online, nilagdaan gamit ang mga ninakaw na digital certificate mula sa RealTek at JMicron.
- Noong 2017, inakusahan ng Google ang Symantec na nag-isyu ng malaking bilang ng mga pekeng certificate. Noong panahong iyon, isa ang Symantec sa pinakamalaking CA sa mga tuntunin ng dami ng produksyon. Sa browser ng Google Chrome 70, ang suporta para sa mga certificate na ibinigay ng kumpanyang ito at ng mga kaakibat nitong sentro na GeoTrust at Thawte ay itinigil bago ang Disyembre 1, 2017.
Ang mga CA ay nakompromiso, at bilang resulta lahat ay nagdusaβang mga CA mismo, pati na rin ang mga user at subscriber. Nasira ang tiwala sa imprastraktura. Bilang karagdagan, ang mga digital na sertipiko ay maaaring mai-block sa konteksto ng mga salungatan sa pulitika, na makakaapekto rin sa pagpapatakbo ng maraming mapagkukunan. Ito mismo ang kinatatakutan ilang taon na ang nakalilipas sa administrasyong pampanguluhan ng Russia, kung saan noong 2016 tinalakay nila ang posibilidad na lumikha ng isang sentro ng sertipikasyon ng estado na maglalabas ng mga sertipiko ng SSL sa mga site sa RuNet. Ang kasalukuyang estado ng mga gawain ay tulad na kahit na ang mga portal ng estado sa Russia mga digital na sertipiko na inisyu ng mga kumpanyang Amerikano na Comodo o Thawte (isang subsidiary ng Symantec).
May isa pang problema - ang tanong pangunahing pagpapatunay (authentication) ng mga gumagamit. Paano matukoy ang isang user na nakipag-ugnayan sa CA na may kahilingang mag-isyu ng digital certificate nang walang direktang personal na pakikipag-ugnayan? Ngayon ito ay nalutas sa sitwasyon depende sa mga kakayahan ng imprastraktura. May kinuha mula sa mga bukas na rehistro (halimbawa, impormasyon tungkol sa mga legal na entity na humihiling ng mga sertipiko); sa mga kaso kung saan ang mga aplikante ay mga indibidwal, mga opisina ng bangko o mga post office ay maaaring gamitin, kung saan ang kanilang pagkakakilanlan ay nakumpirma gamit ang mga dokumento ng pagkakakilanlan, halimbawa, isang pasaporte.
Ang problema sa pamemeke ng mga kredensyal para sa layunin ng pagpapanggap ay isang pangunahing problema. Tandaan natin na walang kumpletong solusyon sa problemang ito dahil sa impormasyon-teoretikong mga kadahilanan: nang walang pagkakaroon ng maaasahang impormasyon bilang priori, imposibleng kumpirmahin o tanggihan ang pagiging tunay ng isang partikular na paksa. Bilang isang patakaran, para sa pagpapatunay ay kinakailangan na magpakita ng isang hanay ng mga dokumento na nagpapatunay sa pagkakakilanlan ng aplikante. Mayroong maraming iba't ibang mga paraan ng pag-verify, ngunit wala sa mga ito ang nagbibigay ng buong garantiya ng pagiging tunay ng mga dokumento. Alinsunod dito, hindi rin matitiyak ang pagiging tunay ng pagkakakilanlan ng aplikante.
Paano maaalis ang mga pagkukulang na ito?Kung ang mga problema ng PKI sa kasalukuyang estado nito ay maipaliwanag sa pamamagitan ng sentralisasyon, lohikal na ipagpalagay na ang desentralisasyon ay makakatulong sa bahagyang pagtanggal ng mga natukoy na pagkukulang.
Ang desentralisasyon ay hindi nagpapahiwatig ng pagkakaroon ng mga pinagkakatiwalaang entity - kung gagawa ka desentralisadong pampublikong pangunahing imprastraktura (Desentralisadong Pampublikong Key Infrastructure, DPKI), pagkatapos ay hindi kailangan ng CA o CR. Iwanan natin ang konsepto ng digital certificate at gumamit ng distributed registry para mag-imbak ng impormasyon tungkol sa mga pampublikong key. Sa aming kaso, tinatawag namin ang isang rehistro na isang linear database na binubuo ng mga indibidwal na talaan (mga bloke) na naka-link gamit ang teknolohiyang blockchain. Sa halip na isang digital na sertipiko, ipakikilala namin ang konsepto ng "notification".
Kung ano ang magiging hitsura ng proseso ng pagtanggap, pag-verify at pagkansela ng mga notification sa iminungkahing DPKI:
1. Ang bawat aplikante ay nagsusumite ng aplikasyon para sa isang abiso nang nakapag-iisa sa pamamagitan ng pagsagot sa isang form sa panahon ng pagpaparehistro, pagkatapos nito ay lumikha siya ng isang transaksyon na naka-imbak sa isang espesyal na pool.
2. Ang impormasyon tungkol sa pampublikong susi, kasama ang mga detalye ng may-ari at iba pang metadata, ay iniimbak sa isang ipinamahagi na pagpapatala, at hindi sa isang digital na sertipiko, para sa pagpapalabas nito sa isang sentralisadong PKI ang CA ang may pananagutan.
3. Ang pagpapatunay ng pagiging tunay ng pagkakakilanlan ng aplikante ay isinasagawa pagkatapos ng katotohanan sa pamamagitan ng magkasanib na pagsisikap ng komunidad ng gumagamit ng DPKI, at hindi ng CR.
4. Tanging ang may-ari ng naturang notification ang maaaring magbago ng status ng isang pampublikong key.
5. Maaaring ma-access ng sinuman ang ipinamahagi na ledger at suriin ang kasalukuyang katayuan ng pampublikong susi.
Tandaan: Ang pag-verify ng komunidad ng pagkakakilanlan ng isang aplikante ay maaaring mukhang hindi maaasahan sa unang tingin. Ngunit dapat nating tandaan na sa panahong ito ang lahat ng mga gumagamit ng mga digital na serbisyo ay hindi maiiwasang mag-iiwan ng isang digital footprint, at ang prosesong ito ay magpapatuloy lamang sa pagkakaroon ng momentum. Buksan ang mga elektronikong rehistro ng mga legal na entity, mapa, pag-digitize ng mga imahe ng lupain, mga social network - lahat ng ito ay magagamit sa publiko na mga tool. Matagumpay na nagamit ang mga ito sa panahon ng mga pagsisiyasat ng parehong mga mamamahayag at mga ahensyang nagpapatupad ng batas. Halimbawa, sapat na upang alalahanin ang mga pagsisiyasat ng Bellingcat o ng joint investigative team na JIT, na pinag-aaralan ang mga pangyayari ng pagbagsak ng Malaysian Boeing.
Kaya paano gagana ang isang desentralisadong pampublikong pangunahing imprastraktura sa pagsasanay? Pag-isipan natin ang paglalarawan ng teknolohiya mismo, na tayo patented noong 2018 at nararapat nating isaalang-alang ito bilang ating kaalaman.
Isipin na mayroong ilang may-ari na nagmamay-ari ng maraming pampublikong susi, kung saan ang bawat susi ay isang tiyak na transaksyon na nakaimbak sa pagpapatala. Sa kawalan ng CA, paano mo mauunawaan na ang lahat ng mga susi ay pagmamay-ari ng partikular na may-ari na ito? Upang malutas ang problemang ito, ang isang zero na transaksyon ay nilikha, na naglalaman ng impormasyon tungkol sa may-ari at ang kanyang pitaka (kung saan ang komisyon para sa paglalagay ng transaksyon sa pagpapatala ay na-debit). Ang null na transaksyon ay isang uri ng "anchor" kung saan ang mga sumusunod na transaksyon na may data tungkol sa mga pampublikong key ay ikakabit. Ang bawat naturang transaksyon ay naglalaman ng isang espesyal na istraktura ng data, o sa madaling salita, isang abiso.
Ang notification ay isang nakabalangkas na hanay ng data na binubuo ng mga functional na field at kabilang ang impormasyon tungkol sa pampublikong susi ng may-ari, ang pagtitiyaga nito ay ginagarantiyahan ng paglalagay sa isa sa mga nauugnay na talaan ng ipinamahagi na pagpapatala.
Ang susunod na lohikal na tanong ay kung paano nabuo ang isang zero na transaksyon? Ang null na transaksyonβtulad ng mga kasunod na transaksyonβay isang pagsasama-sama ng anim na field ng data. Sa panahon ng pagbuo ng isang zero na transaksyon, ang key pair ng wallet ay kasangkot (pampubliko at ipinares na mga lihim na susi). Ang pares ng mga key na ito ay lilitaw sa sandaling irehistro ng gumagamit ang kanyang pitaka, kung saan ang komisyon para sa paglalagay ng zero na transaksyon sa pagpapatala at, pagkatapos, ang mga pagpapatakbo na may mga abiso ay ide-debit.
Gaya ng ipinapakita sa figure, nabubuo ang wallet public key digest sa pamamagitan ng sunud-sunod na paglalapat ng SHA256 at RIPEMD160 hash functions. Narito ang RIPEMD160 ay responsable para sa compact na representasyon ng data, ang lapad nito ay hindi lalampas sa 160 bits. Ito ay mahalaga dahil ang pagpapatala ay hindi isang murang database. Ang pampublikong susi mismo ay ipinasok sa ikalimang field. Ang unang field ay naglalaman ng data na nagtatatag ng koneksyon sa nakaraang transaksyon. Para sa isang zero na transaksyon, walang laman ang field na ito, na nagpapaiba nito sa mga susunod na transaksyon. Ang pangalawang field ay data para sa pagsuri sa pagkakakonekta ng mga transaksyon. Para sa kaiklian, tatawagin namin ang data sa una at pangalawang field na "link" at "check", ayon sa pagkakabanggit. Ang mga nilalaman ng mga patlang na ito ay nabuo sa pamamagitan ng umuulit na pag-hash, tulad ng ipinakita sa pamamagitan ng pag-link sa pangalawa at pangatlong transaksyon sa figure sa ibaba.
Ang data mula sa unang limang field ay na-certify sa pamamagitan ng electronic signature, na nabuo gamit ang secret key ng wallet.
Iyon lang, ang null na transaksyon ay ipinadala sa pool at pagkatapos ng matagumpay na pag-verify ay naipasok sa pagpapatala. Ngayon ay maaari mong "i-link" ang mga sumusunod na transaksyon dito. Isaalang-alang natin kung paano nabuo ang mga transaksyon maliban sa zero.
Ang unang bagay na malamang na nakakuha ng iyong mata ay ang kasaganaan ng mga key pairs. Bilang karagdagan sa pamilyar na pares ng susi ng wallet, ginagamit ang karaniwan at mga pares ng susi ng serbisyo.
Isang ordinaryong pampublikong susi ang nasimulan ng lahat. Ang susi na ito ay kasangkot sa iba't ibang mga pamamaraan at proseso na nalalahad sa labas ng mundo (pagbabangko at iba pang mga transaksyon, daloy ng dokumento, atbp.). Halimbawa, ang isang lihim na susi mula sa isang ordinaryong pares ay maaaring gamitin upang makabuo ng mga digital na lagda para sa iba't ibang mga dokumento - mga order sa pagbabayad, atbp., at isang pampublikong susi ay maaaring gamitin upang i-verify ang digital na lagda na ito sa kasunod na pagpapatupad ng mga tagubiling ito, sa kondisyon na ito ay pwede.
Ang pares ng serbisyo ay ibinibigay sa nakarehistrong paksa ng DPKI. Ang pangalan ng pares na ito ay tumutugma sa layunin nito. Tandaan na kapag bumubuo/nagsusuri ng zero na transaksyon, hindi ginagamit ang mga service key.
Muli nating linawin ang layunin ng mga susi:
- Ginagamit ang mga wallet key upang bumuo/mag-verify ng parehong null na transaksyon at anumang iba pang hindi null na transaksyon. Ang pribadong susi ng pitaka ay kilala lamang ng may-ari ng pitaka, na siya ring may-ari ng maraming ordinaryong pampublikong susi.
- Ang isang ordinaryong pampublikong susi ay katulad ng layunin sa isang pampublikong susi kung saan ang isang sertipiko ay inilabas sa isang sentralisadong PKI.
- Ang pares ng service key ay kabilang sa DPKI. Ang sikretong key ay ibinibigay sa mga rehistradong entity at ginagamit kapag bumubuo ng mga digital na lagda para sa mga transaksyon (maliban sa mga zero na transaksyon). Ginagamit ang Pampubliko upang i-verify ang electronic digital signature ng isang transaksyon bago ito i-post sa registry.
Kaya, mayroong dalawang grupo ng mga susi. Kasama sa una ang mga service key at wallet key - may katuturan lang ang mga ito sa konteksto ng DPKI. Kasama sa pangalawang pangkat ang mga ordinaryong key - maaaring mag-iba ang saklaw ng mga ito at tinutukoy ng mga gawain sa aplikasyon kung saan ginagamit ang mga ito. Kasabay nito, tinitiyak ng DPKI ang integridad at pagiging tunay ng mga ordinaryong pampublikong key.
Tandaan: Ang pares ng key ng serbisyo ay maaaring kilala sa iba't ibang entity ng DPKI. Halimbawa, maaaring pareho ito para sa lahat. Ito ay para sa kadahilanang ito na kapag bumubuo ng pirma ng bawat non-zero na transaksyon, dalawang lihim na susi ang ginagamit, ang isa ay ang wallet key - ito ay kilala lamang ng may-ari ng pitaka, na siya ring may-ari ng maraming ordinaryong mga pampublikong susi. Ang lahat ng mga susi ay may sariling kahulugan. Halimbawa, laging posible na patunayan na ang transaksyon ay ipinasok sa rehistro ng isang nakarehistrong paksa ng DPKI, dahil ang lagda ay nabuo din sa isang lihim na susi ng serbisyo. At hindi maaaring magkaroon ng pang-aabuso, tulad ng mga pag-atake ng DOS, dahil binabayaran ng may-ari ang bawat transaksyon.
Ang lahat ng mga transaksyon na sumusunod sa zero one ay nabuo sa katulad na paraan: ang pampublikong susi (hindi ang pitaka, tulad ng kaso ng zero na transaksyon, ngunit mula sa isang ordinaryong key pair) ay pinapatakbo sa pamamagitan ng dalawang hash function na SHA256 at RIPEMD160. Ito ay kung paano nabuo ang data ng ikatlong field. Ang ikaapat na field ay naglalaman ng kasamang impormasyon (halimbawa, impormasyon tungkol sa kasalukuyang status, mga petsa ng pag-expire, timestamp, mga identifier ng crypto-algorithms na ginamit, atbp.). Ang ikalimang field ay naglalaman ng pampublikong susi mula sa pares ng service key. Sa tulong nito, susuriin ang digital signature, kaya gagayahin ito. Bigyan natin ng katwiran ang pangangailangan para sa ganitong paraan.
Alalahanin na ang isang transaksyon ay ipinasok sa isang pool at nakaimbak doon hanggang sa ito ay maproseso. Ang pag-iimbak sa isang pool ay nauugnay sa isang tiyak na panganib - ang data ng transaksyon ay maaaring mapeke. Pinapatunayan ng may-ari ang data ng transaksyon gamit ang electronic digital signature. Ang pampublikong key para sa pag-verify ng digital signature na ito ay tahasang ipinahiwatig sa isa sa mga field ng transaksyon at pagkatapos ay ipinasok sa registry. Ang mga kakaibang katangian ng pagpoproseso ng transaksyon ay nagagawang baguhin ng isang attacker ang data sa kanyang sariling paghuhusga at pagkatapos ay i-verify ito gamit ang kanyang sikretong key, at ipahiwatig ang isang ipinares na pampublikong key para sa pag-verify ng digital na lagda sa transaksyon. Kung ang pagiging tunay at integridad ay tiyak na eksklusibo sa pamamagitan ng digital na lagda, kung gayon ang gayong pamemeke ay hindi mapapansin. Gayunpaman, kung, bilang karagdagan sa digital na lagda, mayroong isang karagdagang mekanismo na nagsisiguro sa parehong pag-archive at pagtitiyaga ng nakaimbak na impormasyon, kung gayon ang pamemeke ay maaaring makita. Upang gawin ito, sapat na upang ipasok ang tunay na pampublikong susi ng may-ari sa pagpapatala. Ipaliwanag natin kung paano ito gumagana.
Hayaan ang umaatake na pekein ang data ng transaksyon. Mula sa punto ng view ng mga susi at digital na lagda, posible ang mga sumusunod na opsyon:
1. Inilalagay ng attacker ang kanyang pampublikong key sa transaksyon habang ang digital signature ng may-ari ay nananatiling hindi nagbabago.
2. Gumagawa ng digital signature ang attacker sa kanyang pribadong key, ngunit hindi nababago ang pampublikong key ng may-ari.
3. Gumagawa ang attacker ng digital signature sa kanyang pribadong key at naglalagay ng ipinares na pampublikong key sa transaksyon.
Malinaw, ang mga opsyon 1 at 2 ay walang kabuluhan, dahil palaging makikita ang mga ito sa panahon ng digital signature verification. Ang opsyon 3 lang ang may katuturan, at kung ang isang attacker ay bubuo ng digital signature sa sarili niyang secret key, mapipilitan siyang mag-save ng ipinares na pampublikong key sa transaksyon, na iba sa public key ng may-ari. Ito ang tanging paraan para sa isang umaatake na magpataw ng pekeng data.
Ipagpalagay natin na ang may-ari ay may nakapirming pares ng mga susi - pribado at pampubliko. Hayaang ma-certify ang data sa pamamagitan ng digital signature gamit ang secret key mula sa pares na ito, at ang pampublikong key ay ipinahiwatig sa transaksyon. Ipagpalagay din natin na ang pampublikong key na ito ay naipasok na dati sa registry at ang pagiging tunay nito ay mapagkakatiwalaang na-verify. Pagkatapos ang isang pamemeke ay ipahiwatig ng katotohanan na ang pampublikong susi mula sa transaksyon ay hindi tumutugma sa pampublikong susi mula sa pagpapatala.
Sumama tayo. Kapag pinoproseso ang pinakaunang data ng transaksyon ng may-ari, kinakailangang i-verify ang pagiging tunay ng pampublikong key na ipinasok sa registry. Upang gawin ito, basahin ang susi mula sa pagpapatala at ihambing ito sa totoong pampublikong susi ng may-ari sa loob ng perimeter ng seguridad (lugar ng kamag-anak na kawalan ng kapansanan). Kung ang pagiging tunay ng susi ay nakumpirma at ang pagtitiyaga nito ay ginagarantiyahan sa pagkakalagay, kung gayon ang pagiging tunay ng susi mula sa kasunod na transaksyon ay madaling makumpirma/matanggihan sa pamamagitan ng paghahambing nito sa susi mula sa pagpapatala. Sa madaling salita, ang susi mula sa pagpapatala ay ginagamit bilang isang sample ng sanggunian. Ang lahat ng iba pang transaksyon ng may-ari ay pinoproseso nang katulad.
Ang transaksyon ay pinatunayan ng isang elektronikong digital na lagda - dito kailangan ang mga lihim na susi, at hindi isa, ngunit dalawa nang sabay-sabay - isang susi ng serbisyo at isang susi ng pitaka. Salamat sa paggamit ng dalawang lihim na susi, natitiyak ang kinakailangang antas ng seguridad - pagkatapos ng lahat, ang lihim na susi ng serbisyo ay maaaring malaman ng ibang mga gumagamit, habang ang lihim na susi ng pitaka ay kilala lamang ng may-ari ng ordinaryong pares ng susi. Tinawag namin ang naturang two-key signature bilang isang "consolidated" digital signature.
Ang pag-verify ng mga hindi null na transaksyon ay isinasagawa gamit ang dalawang pampublikong key: ang wallet at ang service key. Ang proseso ng pag-verify ay maaaring nahahati sa dalawang pangunahing yugto: ang una ay ang pagsuri sa digest ng pampublikong susi ng pitaka, at ang pangalawa ay ang pagsuri sa electronic digital na lagda ng transaksyon, ang parehong pinagsama-samang isa na nabuo gamit ang dalawang lihim na susi ( wallet at serbisyo). Kung ang bisa ng digital signature ay nakumpirma, pagkatapos pagkatapos ng karagdagang pag-verify ang transaksyon ay ipinasok sa rehistro.
Maaaring lumitaw ang isang lohikal na tanong: kung paano suriin kung ang isang transaksyon ay kabilang sa isang tiyak na kadena na may "ugat" sa anyo ng isang zero na transaksyon? Para sa layuning ito, ang proseso ng pag-verify ay pupunan ng isa pang yugto - pagsuri sa koneksyon. Dito natin kakailanganin ang data mula sa unang dalawang field, na hanggang ngayon ay hindi natin pinansin.
Isipin natin na kailangan nating suriin kung ang transaksyon No. 3 ay talagang darating pagkatapos ng transaksyon No. 2. Upang gawin ito, gamit ang pinagsamang paraan ng hashing, ang halaga ng hash function ay kinakalkula para sa data mula sa ikatlo, ikaapat at ikalimang field ng transaksyon No. 2. Pagkatapos ay ang pagsasama-sama ng data mula sa unang field ng transaksyon No. 3 at ang dating nakuha na pinagsamang hash function na halaga para sa data mula sa ikatlo, ikaapat at ikalimang field ng transaksyon No. 2 ay ginanap. Ang lahat ng ito ay pinapatakbo din sa pamamagitan ng dalawang hash function na SHA256 at RIPEMD160. Kung ang natanggap na halaga ay tumutugma sa data sa pangalawang larangan ng transaksyon No. 2, pagkatapos ay ang tseke ay naipasa at ang koneksyon ay nakumpirma. Ito ay ipinapakita nang mas malinaw sa mga figure sa ibaba.
Sa pangkalahatang mga termino, ang teknolohiya para sa pagbuo at pagpasok ng isang abiso sa rehistro ay eksaktong katulad nito. Ang isang visual na paglalarawan ng proseso ng pagbuo ng isang chain ng mga notification ay ipinakita sa sumusunod na figure:
Sa tekstong ito, hindi tayo magtatagal sa mga detalye, na walang alinlangan na umiiral, at babalik sa pagtalakay sa mismong ideya ng isang desentralisadong pampublikong pangunahing imprastraktura.
Kaya, dahil ang aplikante mismo ay nagsumite ng isang aplikasyon para sa pagpaparehistro ng mga abiso, na hindi nakaimbak sa database ng CA, ngunit sa pagpapatala, ang mga pangunahing bahagi ng arkitektura ng DPKI ay dapat isaalang-alang:
1. Magrehistro ng mga wastong notification (RDN).
2. Magrehistro ng mga binawi na abiso (RON).
3. Magrehistro ng mga nasuspinde na notification (RPN).
Ang impormasyon tungkol sa mga pampublikong key ay nakaimbak sa RDN/RON/RPN sa anyo ng mga halaga ng hash function. Kapansin-pansin din na ang mga ito ay maaaring magkaibang mga rehistro, o magkakaibang mga kadena, o kahit isang kadena bilang bahagi ng iisang rehistro, kapag ang impormasyon tungkol sa katayuan ng isang ordinaryong pampublikong susi (pagbawi, pagsususpinde, atbp.) ay ipinasok sa ikaapat na field ng istraktura ng data sa anyo ng katumbas na halaga ng code. Mayroong maraming iba't ibang mga pagpipilian para sa pagpapatupad ng arkitektura ng DPKI, at ang pagpili ng isa o ang isa ay nakasalalay sa isang bilang ng mga kadahilanan, halimbawa, tulad ng mga pamantayan sa pag-optimize tulad ng gastos ng pangmatagalang memorya para sa pag-iimbak ng mga pampublikong susi, atbp.
Kaya, ang DPKI ay maaaring maging, kung hindi mas simple, at hindi bababa sa maihahambing sa isang sentralisadong solusyon sa mga tuntunin ng pagiging kumplikado ng arkitektura.
Ang pangunahing tanong ay nananatili - Aling registry ang angkop para sa pagpapatupad ng teknolohiya?
Ang pangunahing kinakailangan para sa pagpapatala ay ang kakayahang makabuo ng mga transaksyon ng anumang uri. Ang pinakatanyag na halimbawa ng isang ledger ay ang Bitcoin network. Ngunit kapag ipinatupad ang teknolohiyang inilarawan sa itaas, ang ilang mga paghihirap ay lumitaw: ang mga limitasyon ng umiiral na wika ng script, ang kakulangan ng mga kinakailangang mekanismo para sa pagproseso ng mga di-makatwirang hanay ng data, mga pamamaraan para sa pagbuo ng mga transaksyon ng isang di-makatwirang uri, at marami pa.
Sinubukan namin sa ENCRY na lutasin ang mga problemang nabuo sa itaas at bumuo ng isang pagpapatala, na, sa aming opinyon, ay may ilang mga pakinabang, katulad:
- sumusuporta sa ilang uri ng mga transaksyon: maaari itong parehong makipagpalitan ng mga asset (iyon ay, magsagawa ng mga transaksyon sa pananalapi) at lumikha ng mga transaksyon na may di-makatwirang istraktura,
- may access ang mga developer sa proprietary programming language na PrismLang, na nagbibigay ng kinakailangang flexibility kapag nilulutas ang iba't ibang mga teknolohikal na problema,
- isang mekanismo para sa pagproseso ng mga arbitrary na set ng data ay ibinigay.
Kung gagawa kami ng isang pinasimple na diskarte, ang sumusunod na pagkakasunud-sunod ng mga aksyon ay magaganap:
- Nagrerehistro ang aplikante sa DPKI at tumatanggap ng digital wallet. Ang address ng wallet ay ang hash value ng pampublikong key ng wallet. Ang pribadong susi ng wallet ay alam lamang ng aplikante.
- Ang nakarehistrong paksa ay binibigyan ng access sa lihim na key ng serbisyo.
- Ang paksa ay bumubuo ng isang zero na transaksyon at bini-verify ito gamit ang isang digital na lagda gamit ang sikretong key ng wallet.
- Kung ang isang transaksyon maliban sa zero ay nabuo, ito ay pinatunayan ng isang elektronikong digital na lagda gamit ang dalawang sikretong key: isang pitaka at isang serbisyo.
- Ang paksa ay nagsusumite ng isang transaksyon sa pool.
- Binabasa ng ENCRY network node ang transaksyon mula sa pool at sinusuri ang digital signature, pati na rin ang pagkakakonekta ng transaksyon.
- Kung ang digital signature ay wasto at ang koneksyon ay nakumpirma, pagkatapos ay inihahanda nito ang transaksyon para sa pagpasok sa rehistro.
Dito gumaganap ang registry bilang isang distributed database na nag-iimbak ng impormasyon tungkol sa wasto, nakansela at nasuspinde na mga notification.
Siyempre, ang desentralisasyon ay hindi isang panlunas sa lahat. Ang pangunahing problema ng pangunahing user authentication ay hindi nawawala kahit saan: kung kasalukuyang ang pag-verify ng aplikante ay isinasagawa ng CR, pagkatapos ay sa DPKI ito ay iminungkahi na italaga ang pag-verify sa mga miyembro ng komunidad, at gumamit ng pinansyal na pagganyak upang pasiglahin ang aktibidad. Ang teknolohiya sa pag-verify ng open source ay kilala. Ang pagiging epektibo ng naturang pagpapatunay ay nakumpirma sa pagsasanay. Muli nating alalahanin ang ilang high-profile na pagsisiyasat ng online na publikasyong Bellingcat.
Ngunit sa pangkalahatan, lumalabas ang sumusunod na larawan: Ang DPKI ay isang pagkakataon upang itama, kung hindi man lahat, kung gayon ang marami sa mga pagkukulang ng sentralisadong PKI.
Mag-subscribe sa aming Habrablog, plano naming patuloy na aktibong saklawin ang aming pananaliksik at pag-unlad, at sundin , kung ayaw mong makaligtaan ang iba pang balita tungkol sa mga proyekto ng ENCRY.
Pinagmulan: www.habr.com