Не е тайна, че един от често използваните спомагателни инструменти, без които е невъзможна защитата на данните в отворени мрежи, е технологията за цифрови сертификати. Не е тайна обаче, че основният недостатък на технологията е безусловното доверие в центровете, които издават цифрови сертификати. Директорът по технологии и иновации в ENCRY Андрей Чмора предложи нов подход към организирането инфраструктура с публичен ключ (Инфраструктура с публичен ключ, PKI), който ще помогне за премахване на настоящите недостатъци и който използва технологията на разпределения регистър (блокчейн). Но на първо място.
Ако сте запознати с това как работи текущата ви инфраструктура с публичен ключ и знаете основните й недостатъци, можете да преминете към това, което предлагаме да промените по-долу.
Какво представляват цифровите подписи и сертификати?Взаимодействието в Интернет винаги включва прехвърляне на данни. Всички имаме интерес да гарантираме, че данните се предават сигурно. Но какво е сигурност? Най-търсените услуги за сигурност са конфиденциалност, интегритет и автентичност. За тази цел в момента се използват методи на асиметрична криптография или криптография с публичен ключ.
Нека започнем с факта, че за да използват тези методи, субектите на взаимодействие трябва да имат два индивидуални сдвоени ключа - публичен и таен. С тяхна помощ се предоставят охранителните услуги, които споменахме по-горе.
Как се постига поверителността на трансфера на информация? Преди да изпрати данни, изпращащият абонат криптира (криптографски трансформира) отворените данни, използвайки публичния ключ на получателя, а получателят дешифрира получения шифрован текст, използвайки сдвоения таен ключ.
Как се постига целостта и автентичността на предаваната информация? За да се реши този проблем, беше създаден друг механизъм. Отворените данни не са криптирани, но резултатът от прилагането на криптографската хеш функция - „компресирано“ изображение на последователността от входни данни - се предава в криптирана форма. Резултатът от такова хеширане се нарича „дайджест“ и се криптира с помощта на секретния ключ на изпращащия абонат („свидетелят“). В резултат на криптиране на дайджеста се получава цифров подпис. Той, заедно с чистия текст, се предава на абоната получател („верификатор“). Той дешифрира цифровия подпис на публичния ключ на свидетеля и го сравнява с резултата от прилагането на криптографска хеш функция, която верификаторът изчислява независимо въз основа на получените отворени данни. Ако те съвпадат, това означава, че данните са предадени в автентичен и пълен вид от изпращащия абонат, а не модифицирани от нападател.
Повечето ресурси, които работят с лични данни и информация за плащане (банки, застрахователни компании, авиокомпании, платежни системи, както и правителствени портали като данъчната служба), активно използват методи за асиметрична криптография.
Какво общо има цифровият сертификат с това? Просто е. И първият, и вторият процес включват публични ключове и тъй като те играят централна роля, е много важно да се гарантира, че ключовете действително принадлежат на подателя (свидетелят, в случай на проверка на подписа) или на получателя, а не са заменени с ключовете на нападателите. Ето защо съществуват цифрови сертификати, за да гарантират автентичността и целостта на публичния ключ.
Забележка: автентичността и целостта на публичния ключ се потвърждава по абсолютно същия начин, както автентичността и целостта на публичните данни, тоест с помощта на електронен цифров подпис (EDS).
Откъде идват цифровите сертификати?Доверените сертифициращи органи или сертифициращи органи (CA) са отговорни за издаването и поддържането на цифрови сертификати. Кандидатът заявява издаване на удостоверение от КО, преминава идентификация в Регистрационен център (ЦР) и получава удостоверение от КО. СО гарантира, че публичният ключ от сертификата принадлежи точно на субекта, за който е издаден.
Ако не потвърдите автентичността на публичния ключ, тогава нападателят по време на прехвърлянето/съхранението на този ключ може да го замени със свой собствен. Ако заместването е извършено, нападателят ще може да дешифрира всичко, което изпращащият абонат предава на приемащия абонат, или да промени отворените данни по свое усмотрение.
Цифровите сертификати се използват навсякъде, където е налична асиметрична криптография. Едни от най-разпространените цифрови сертификати са SSL сертификатите за защитена комуникация по HTTPS протокола. Стотици компании, регистрирани в различни юрисдикции, участват в издаването на SSL сертификати. Основният дял се пада на пет до десет големи доверени центъра: IdenTrust, Comodo, GoDaddy, GlobalSign, DigiCert, CERTUM, Actalis, Secom, Trustwave.
CA и CR са компоненти на PKI, който включва също:
- Отворете директорията – публична база данни, която осигурява сигурно съхранение на цифрови сертификати.
- Списък на анулираните сертификати – публична база данни, която осигурява сигурно съхранение на цифрови сертификати на отменени публични ключове (например поради компрометиране на сдвоен частен ключ). Субектите на инфраструктурата могат независимо да имат достъп до тази база данни или могат да използват специализирания протокол за състояние на онлайн сертифициране (OCSP), който опростява процеса на проверка.
- Потребители на сертификати – обслужвани PKI субекти, които са сключили потребителско споразумение с УО и проверяват цифровия подпис и/или криптират данните на базата на публичния ключ от сертификата.
- последователи – обслужвани PKI субекти, които притежават таен ключ, съчетан с публичния ключ от сертификата, и които са сключили абонатно споразумение с CA. Абонатът може едновременно да бъде и потребител на сертификата.
По този начин доверените субекти на инфраструктурата на публичния ключ, които включват CA, CR и отворени директории, са отговорни за:
1. Проверка на автентичността на самоличността на заявителя.
2. Профилиране на сертификата за публичен ключ.
3. Издаване на удостоверение за публичен ключ за заявител, чиято самоличност е надеждно потвърдена.
4. Променете статуса на сертификата за публичен ключ.
5. Предоставяне на информация за актуалното състояние на сертификата за публичен ключ.
Недостатъци на PKI, какви са те?Основният недостатък на PKI е наличието на доверени субекти.
Потребителите трябва безусловно да се доверяват на CA и CR. Но, както показва практиката, безусловното доверие е изпълнено със сериозни последствия.
През последните десет години имаше няколко големи скандала в тази област, свързани с уязвимостта на инфраструктурата.
— през 2010 г. зловредният софтуер Stuxnet започна да се разпространява онлайн, подписан с помощта на откраднати цифрови сертификати от RealTek и JMicron.
- През 2017 г. Google обвини Symantec в издаване на голям брой фалшифицирани сертификати. По това време Symantec беше един от най-големите CA по отношение на производствените обеми. В браузъра Google Chrome 70 поддръжката на сертификати, издадени от тази компания и нейните свързани центрове GeoTrust и Thawte, беше спряна преди 1 декември 2017 г.
УО бяха компрометирани и в резултат на това пострадаха всички – самите УО, както и потребителите и абонатите. Доверието в инфраструктурата е подкопано. Освен това цифровите сертификати могат да бъдат блокирани в контекста на политически конфликти, което също ще засегне работата на много ресурси. Точно от това се страхуваха преди няколко години в администрацията на руския президент, където през 2016 г. обсъдиха възможността за създаване на държавен сертификационен център, който да издава SSL сертификати на сайтове в Рунет. Сегашното състояние на нещата е такова, че дори държавните портали в Русия цифрови сертификати, издадени от американски компании Comodo или Thawte (дъщерно дружество на Symantec).
Има и друг проблем - въпросът първично удостоверяване (автентификация) на потребителите. Как да идентифицираме потребител, който се е свързал с СО с искане за издаване на цифров сертификат без пряк личен контакт? Сега това се решава ситуационно в зависимост от възможностите на инфраструктурата. Взема се нещо от отворени регистри (например информация за юридически лица, които искат сертификати); в случаите, когато кандидатите са физически лица, могат да се използват банкови офиси или пощенски служби, където тяхната самоличност се потвърждава с документи за самоличност, например паспорт.
Проблемът с фалшифицирането на идентификационни данни с цел представяне е основен. Нека отбележим, че няма пълно решение на този проблем поради информационно-теоретични причини: без да разполагаме с надеждна информация a priori, е невъзможно да се потвърди или отрече автентичността на конкретен обект. По правило за проверка е необходимо да се представи набор от документи, доказващи самоличността на заявителя. Има много различни методи за проверка, но нито един от тях не дава пълна гаранция за автентичността на документите. Съответно, автентичността на самоличността на жалбоподателя също не може да бъде гарантирана.
Как могат да бъдат отстранени тези недостатъци?Ако проблемите на PKI в сегашното му състояние могат да се обяснят с централизацията, тогава е логично да се предположи, че децентрализацията би помогнала за частично отстраняване на установените недостатъци.
Децентрализацията не предполага наличието на доверени субекти - ако създадете децентрализирана инфраструктура с публичен ключ (Децентрализирана инфраструктура с публичен ключ, ДПКИ), тогава не са необходими нито CA, нито CR. Нека изоставим концепцията за цифров сертификат и използваме разпределен регистър за съхраняване на информация за публичните ключове. В нашия случай ние наричаме регистър линейна база данни, състояща се от отделни записи (блокове), свързани с помощта на блокчейн технология. Вместо цифров сертификат ще въведем понятието „уведомление“.
Как ще изглежда процесът на получаване, проверка и анулиране на уведомления в предложения DPKI:
1. Всеки заявител подава самостоятелно заявление за уведомление, като попълва формуляр при регистрацията, след което създава транзакция, която се съхранява в специализиран пул.
2. Информацията за публичния ключ, заедно с данните за собственика и други метаданни, се съхранява в разпределен регистър, а не в цифров сертификат, за издаването на който в централизирана PKI отговаря CA.
3. Проверката на автентичността на самоличността на заявителя се извършва постфактум от съвместните усилия на потребителската общност на DPKI, а не от CR.
4. Само собственикът на такова уведомление може да промени статуса на публичен ключ.
5. Всеки може да получи достъп до разпределената книга и да провери текущото състояние на публичния ключ.
Забележка: Проверката на общността на самоличността на кандидата може да изглежда ненадеждна на пръв поглед. Но трябва да помним, че в днешно време всички потребители на цифрови услуги неизбежно оставят дигитален отпечатък и този процес ще продължи да набира скорост. Отворени електронни регистри на юридически лица, карти, дигитализиране на теренни изображения, социални мрежи - всичко това са публично достъпни инструменти. Те вече се използват успешно по време на разследвания както от журналисти, така и от правоохранителните органи. Например, достатъчно е да си припомним разследванията на Bellingcat или съвместния разследващ екип JIT, който проучва обстоятелствата около катастрофата на малайзийския Боинг.
И така, как би работила на практика една децентрализирана инфраструктура с публичен ключ? Нека се спрем на описанието на самата технология, която ние патентован през 2018 г и с право го считаме за наше ноу-хау.
Представете си, че има собственик, който притежава много публични ключове, където всеки ключ е определена транзакция, която се съхранява в регистъра. При липса на CA, как можете да разберете, че всички ключове принадлежат на този конкретен собственик? За да се реши този проблем, се създава нулева транзакция, която съдържа информация за собственика и неговия портфейл (от който се дебитира комисионната за поставяне на транзакцията в регистъра). Нулевата транзакция е вид „котва“, към която ще бъдат прикрепени следните транзакции с данни за публични ключове. Всяка такава транзакция съдържа специализирана структура от данни или с други думи известие.
Известието е структуриран набор от данни, състоящ се от функционални полета и включващ информация за публичния ключ на собственика, чиято устойчивост е гарантирана чрез поставяне в един от свързаните записи на разпределения регистър.
Следващият логичен въпрос е как се формира нулева сделка? Нулевата транзакция - подобно на следващите - е съвкупност от шест полета с данни. По време на формирането на нулева транзакция се включва двойката ключове на портфейла (публични и сдвоени секретни ключове). Тази двойка ключове се появява в момента, в който потребителят регистрира своя портфейл, от който ще бъде дебитирана комисионната за поставяне на нулева транзакция в регистъра и впоследствие операциите с известия.
Както е показано на фигурата, дайджестът на публичния ключ на портфейла се генерира чрез последователно прилагане на хеш функциите SHA256 и RIPEMD160. Тук RIPEMD160 отговаря за компактното представяне на данни, чиято ширина не надвишава 160 бита. Това е важно, защото регистърът не е евтина база данни. В петото поле се въвежда самият публичен ключ. Първото поле съдържа данни, които установяват връзка с предишната транзакция. За нулева транзакция това поле не съдържа нищо, което го отличава от следващите транзакции. Второто поле е данни за проверка на свързаността на транзакциите. За краткост ще наричаме данните в първото и второто поле съответно „връзка” и „проверка”. Съдържанието на тези полета се генерира чрез итеративно хеширане, както е показано чрез свързване на втората и третата транзакции на фигурата по-долу.
Данните от първите пет полета се удостоверяват с електронен подпис, който се генерира чрез секретния ключ на портфейла.
Това е всичко, нулевата транзакция се изпраща в пула и след успешна проверка се въвежда в регистъра. Сега можете да „свържете“ следните транзакции с него. Нека разгледаме как се формират транзакции, различни от нула.
Първото нещо, което вероятно хваща окото ви, е изобилието от двойки ключове. В допълнение към вече познатата двойка ключове за портфейла се използват двойки обикновени и сервизни ключове.
С обикновен публичен ключ е започнато всичко. Този ключ участва в различни процедури и процеси, протичащи във външния свят (банкови и други транзакции, документооборот и др.). Например, секретен ключ от обикновена двойка може да се използва за генериране на цифрови подписи за различни документи - платежни нареждания и др., а публичен ключ може да се използва за проверка на този цифров подпис с последващо изпълнение на тези инструкции, при условие че е валиден.
Сервизната двойка се издава на регистрирания субект на DPKI. Името на този чифт отговаря на предназначението му. Имайте предвид, че при формиране/проверка на нулева транзакция не се използват служебни ключове.
Нека отново да изясним предназначението на ключовете:
- Ключовете на Wallet се използват за генериране/проверка както на нулева транзакция, така и на всяка друга ненулева транзакция. Частният ключ на портфейла е известен само на собственика на портфейла, който също е собственик на много обикновени публични ключове.
- Обикновеният публичен ключ е подобен по предназначение на публичен ключ, за който се издава сертификат в централизиран PKI.
- Двойката сервизен ключ принадлежи на DPKI. Тайният ключ се издава на регистрирани лица и се използва при генериране на цифрови подписи за транзакции (с изключение на нулеви транзакции). Public се използва за проверка на електронния цифров подпис на транзакция, преди тя да бъде поставена в регистъра.
По този начин има две групи ключове. Първият включва сервизни ключове и ключове за портфейл - те имат смисъл само в контекста на DPKI. Втората група включва обикновени ключове - техният обхват може да варира и се определя от задачите на приложението, в които се използват. В същото време DPKI гарантира целостта и автентичността на обикновените публични ключове.
Забележка: Двойката сервизен ключ може да е известна на различни DPKI обекти. Например, може да е еднакво за всички. Именно поради тази причина при генериране на подписа на всяка ненулева транзакция се използват два секретни ключа, единият от които е ключът на портфейла - той е известен само на собственика на портфейла, който е и собственик на много обикновени публични ключове. Всички клавиши имат собствено значение. Например, винаги е възможно да се докаже, че транзакцията е била въведена в регистъра от регистриран субект на DPKI, тъй като подписът също е генериран върху ключ за секретна услуга. И не може да има злоупотреби, като DOS атаки, защото собственикът плаща за всяка транзакция.
Всички транзакции, които следват нулевата единица, се формират по подобен начин: публичният ключ (не портфейлът, както в случая на нулевата транзакция, а от обикновена двойка ключове) се изпълнява през две хеш функции SHA256 и RIPEMD160. Така се формират данните от третото поле. Четвъртото поле съдържа съпътстваща информация (например информация за текущото състояние, дати на изтичане, клеймо за време, идентификатори на използваните криптоалгоритми и др.). Петото поле съдържа публичния ключ от двойката служебни ключове. С негова помощ след това ще бъде проверен цифровият подпис, така че той ще бъде репликиран. Нека обосновем необходимостта от такъв подход.
Спомнете си, че транзакция се въвежда в пул и се съхранява там, докато не бъде обработена. Съхраняването в пул е свързано с известен риск - данните за транзакциите могат да бъдат фалшифицирани. Собственикът удостоверява данните за сделката с електронен цифров подпис. Публичният ключ за проверка на този електронен подпис се посочва изрично в едно от полетата за транзакция и впоследствие се въвежда в регистъра. Особеностите на обработката на транзакцията са такива, че атакуващият може да промени данните по свое усмотрение и след това да ги провери с помощта на секретния си ключ и да посочи сдвоен публичен ключ за проверка на цифровия подпис в транзакцията. Ако автентичността и целостта се гарантират изключително чрез цифров подпис, тогава такава фалшификация ще остане незабелязана. Но ако в допълнение към цифровия подпис има допълнителен механизъм, който гарантира както архивирането, така и устойчивостта на съхраняваната информация, тогава фалшификатът може да бъде открит. За да направите това, достатъчно е да въведете истинския публичен ключ на собственика в регистъра. Нека обясним как работи това.
Нека нападателят фалшифицира данни за транзакции. От гледна точка на ключовете и цифровите подписи са възможни следните опции:
1. Нападателят поставя своя публичен ключ в транзакцията, докато цифровият подпис на собственика остава непроменен.
2. Нападателят създава цифров подпис върху частния си ключ, но оставя публичния ключ на собственика непроменен.
3. Нападателят създава цифров подпис върху своя частен ключ и поставя сдвоен публичен ключ в транзакцията.
Очевидно опции 1 и 2 са безсмислени, тъй като винаги ще бъдат открити по време на проверката на цифровия подпис. Само опция 3 има смисъл и ако атакуващият формира цифров подпис върху собствения си таен ключ, тогава той е принуден да запази сдвоен публичен ключ в транзакцията, различен от публичния ключ на собственика. Това е единственият начин нападателят да наложи фалшифицирани данни.
Да приемем, че собственикът има фиксирана двойка ключове - частни и публични. Нека данните са удостоверени с цифров подпис с помощта на секретния ключ от тази двойка, а публичният ключ е посочен в транзакцията. Да приемем също, че този публичен ключ е бил въведен преди това в регистъра и неговата автентичност е надеждно проверена. Тогава за фалшификат ще говори фактът, че публичният ключ от транзакцията не съответства на публичния ключ от регистъра.
Нека да обобщим. При обработката на данните за първата транзакция на собственика е необходимо да се провери автентичността на публичния ключ, въведен в регистъра. За да направите това, прочетете ключа от регистъра и го сравнете с истинския публичен ключ на собственика в периметъра на сигурността (зона на относителна неуязвимост). Ако автентичността на ключа е потвърдена и неговата устойчивост е гарантирана при поставяне, то автентичността на ключа от последваща транзакция може лесно да бъде потвърдена/опровергана чрез сравняването му с ключа от регистъра. С други думи, ключът от системния регистър се използва като референтна проба. Всички други транзакции на собственика се обработват по подобен начин.
Транзакцията се удостоверява с електронен цифров подпис - тук са необходими секретни ключове, и то не един, а два наведнъж - сервизен ключ и ключ за портфейл. Благодарение на използването на два секретни ключа се осигурява необходимото ниво на сигурност - в крайна сметка секретният ключ на услугата може да бъде известен на други потребители, докато секретният ключ на портфейла е известен само на собственика на обикновената двойка ключове. Нарекохме такъв подпис с два ключа „консолидиран“ цифров подпис.
Проверката на ненулевите транзакции се извършва с помощта на два публични ключа: портфейла и сервизния ключ. Процесът на проверка може да бъде разделен на два основни етапа: първият е проверка на дайджеста на публичния ключ на портфейла, а вторият е проверка на електронния цифров подпис на транзакцията, същият консолидиран, който е формиран с помощта на два секретни ключа ( портфейл и услуга). Ако валидността на цифровия подпис е потвърдена, след допълнителна проверка транзакцията се вписва в регистъра.
Може да възникне логичен въпрос: как да проверите дали транзакцията принадлежи към определена верига с „корен“ под формата на нулева транзакция? За тази цел процесът на проверка е допълнен с още един етап - проверка на свързаността. Тук ще ни трябват данните от първите две полета, които досега сме игнорирали.
Нека си представим, че трябва да проверим дали транзакция № 3 действително идва след транзакция № 2. За целта чрез комбинирания метод на хеширане се изчислява стойността на хеш функцията за данните от третото, четвъртото и петото поле на транзакция №2. След това се извършва конкатенацията на данни от първото поле на транзакция № 3 и получената преди това комбинирана стойност на хеш функцията за данни от третото, четвъртото и петото поле на транзакция № 2. Всичко това също се изпълнява чрез две хеш функции SHA256 и RIPEMD160. Ако получената стойност съвпада с данните във второто поле на транзакция № 2, тогава проверката е преминала и връзката е потвърдена. Това е показано по-ясно на фигурите по-долу.
Най-общо технологията за генериране и въвеждане на уведомление в регистъра изглежда точно така. Визуална илюстрация на процеса на формиране на верига от уведомления е представена на следната фигура:
В този текст няма да се спираме на подробностите, които несъмнено съществуват, а да се върнем към обсъждането на самата идея за децентрализирана инфраструктура с публичен ключ.
Така че, тъй като самият заявител подава заявление за регистрация на уведомления, които се съхраняват не в базата данни на CA, а в регистъра, трябва да се вземат предвид основните архитектурни компоненти на DPKI:
1. Регистър на валидните уведомления (РДН).
2. Регистър на оттеглените нотификации (RON).
3. Регистър на спрените уведомления (РПН).
Информацията за публичните ключове се съхранява в RDN/RON/RPN под формата на стойности на хеш функция. Също така си струва да се отбележи, че това могат да бъдат или различни регистри, или различни вериги, или дори една верига като част от един регистър, когато информация за състоянието на обикновен публичен ключ (отмяна, спиране и т.н.) се въвежда в четвърто поле от структурата на данните под формата на съответната кодова стойност. Има много различни варианти за архитектурно изпълнение на DPKI и изборът на един или друг зависи от редица фактори, например такива критерии за оптимизация като цената на дългосрочната памет за съхраняване на публични ключове и др.
Така DPKI може да се окаже, ако не по-опростен, то поне сравним с централизирано решение по отношение на архитектурна сложност.
Основният въпрос остава - Кой регистър е подходящ за внедряване на технологията?
Основното изискване за регистъра е възможността за генериране на транзакции от всякакъв тип. Най-известният пример за счетоводна книга е биткойн мрежата. Но при прилагането на описаната по-горе технология възникват определени трудности: ограниченията на съществуващия скриптов език, липсата на необходимите механизми за обработка на произволни набори от данни, методи за генериране на транзакции от произволен тип и много други.
Ние от ENCRY се опитахме да разрешим проблемите, формулирани по-горе, и разработихме регистър, който според нас има редица предимства, а именно:
- поддържа няколко вида транзакции: може както да обменя активи (т.е. да извършва финансови транзакции), така и да създава транзакции с произволна структура,
- разработчиците имат достъп до собствения език за програмиране PrismLang, който осигурява необходимата гъвкавост при решаване на различни технологични проблеми,
- осигурен е механизъм за обработка на произволни набори от данни.
Ако възприемем опростен подход, тогава се извършва следната последователност от действия:
- Кандидатът се регистрира в DPKI и получава дигитален портфейл. Адресът на портфейла е хеш стойността на публичния ключ на портфейла. Частният ключ на портфейла е известен само на заявителя.
- Регистрираният субект получава достъп до секретния ключ на услугата.
- Субектът генерира нулева транзакция и я удостоверява с цифров подпис, използвайки секретния ключ на портфейла.
- Ако се формира транзакция, различна от нула, тя се удостоверява с електронен цифров подпис с помощта на два секретни ключа: портфейл и сервизен.
- Субектът изпраща транзакция към пула.
- Мрежовият възел ENCRY чете транзакцията от пула и проверява цифровия подпис, както и свързаността на транзакцията.
- Ако цифровият подпис е валиден и връзката е потвърдена, тогава той подготвя транзакцията за въвеждане в регистъра.
Тук регистърът действа като разпределена база данни, която съхранява информация за валидни, отменени и спрени известия.
Разбира се, децентрализацията не е панацея. Основният проблем с първичното удостоверяване на потребителя не изчезва никъде: ако в момента проверката на кандидата се извършва от CR, тогава в DPKI се предлага проверката да се делегира на членове на общността и да се използва финансова мотивация за стимулиране на дейността. Технологията за проверка с отворен код е добре известна. Ефективността на такава проверка е потвърдена на практика. Нека отново припомним редица нашумели разследвания на онлайн изданието Bellingcat.
Но като цяло се очертава следната картина: DPKI е възможност да се коригират, ако не всички, то много от недостатъците на централизирания PKI.
Абонирайте се за нашия Habrablog, ние планираме да продължим активно да отразяваме нашите изследвания и разработки и да следим , ако не искате да пропуснете други новини за проекти на ENCRY.
Източник: www.habr.com