Публикувано на: 20 декември, 2023*Текстът е предоставен от DataArt
Автор: Максим Завгородний, Solution Архитект в DataArt
Казвам се Максим Завгородний и от десет години работя в DataArt, като през последните три съм Solution Architect. Професионалните ми интереси са свързани с машинно обучение, изкуствен интелект, както и с разработването на блокчейн базирани системи.
В тази статия ще се опитам да обясня основните принципи, които трябва да се спазват при проектирането на блокчейн решения и да насоча вниманието на читателите към определени дейности като създаване на портфейли и генериране, съхранение и използване на ключове. Текстът няма да анализира техническите нюанси за всеки от тях. По-скоро маркираните точки могат да се използват като контролен списък, за да проверите проекта си и това дали съответства на стандартите за безопасност.
Решенията, базирани на блокчейн, се използват доста успешно във финансовата сфера, например – при проектирането на платежни системи и борсови платформи за търговия с криптовалути. Но блокчейн технологиите могат също толкова добре да се използват в застраховането, здравеопазването, туризма и други сфери на бизнеса. В същото време клиентите, които се интересуват от използването на относително нова и популярна технология, често не са достатъчно наясно с проблемите със сигурността, които могат да възникнат при блокчейн проектите. Именно затова техните приложения толкова често се хакват. Например само през 2019 г. бяха хакнати над 30 основни платформи за търговия.
Нека започнем с факта, че значението на киберсигурността в проектите за криптовалута е очевидно. Но какво ще кажете за други области? Нека разгледаме основните аспекти на блокчейн технологията, които изискват внедряване в съответствие с високи стандарти за сигурност, независимо от естеството на бизнеса на клиента. Трансакции, сертификати, създаване и съхранение на частни ключове – всеки аспект или процес на изпълнение може да бъде еднакво уязвим. Тези аспекти остават абсолютно същите във всяка блокчейн инфраструктура. Добрата новина е, че най-добрите финансови практики могат безопасно да се следват и в други сфери – например в проекти в областта на медицината.
Най-лесният и бърз начин за осигуряване на блокчейн проект, е да се използват съществуващи библиотеки с отворен код (като bitcoinJ) или RPC интеграция с продукти като Electrum или Geth. Това ще ни позволи да работим с ключове, трансакции, сийдове (seeds) и т.н. чрез съществуващата RPC. Този подход наистина може да бъде оправдан на етапа на доказване на концепцията, когато сроковете и бюджетът са ограничени. Но тази опция не трябва да е водеща при производствен режим.
Ето списък на въпросите, свързани със сигурността, които трябва да бъдат обхванати при проектирането на система:
● Генериране на ключ / сийдове (seeds)
● Създаване на портфейл
● Съхранение на ключове
● Използване на ключове
Следва да разгледаме грубо какво точно изискват високите стандарти за сигурност при всяка от тези точки:
1. Генериране на ключ и / или сийдове (seeds)
Всички криптографски сийдове и ключове за трансакции трябва да бъдат генерирани вътрешно. Такава информация е абсолютно поверителна и не трябва да се предава на трети страни. Алгоритмите за генериране на ключове и сийдове трябва да следват поверителни и непредвидими правила.
1.1 Генериран от оператора ключ / сийдове
Чувствителната криптографска информация като ключове или сийдове трябва да бъде генерирана от оператора, който е отговорен за подписа, потвърждаващ трансакцията. Ако говорим за децентрализирано приложение като криптопортфейл, ключът и сийдът трябва да бъдат генерирани от потребителя на приложението, без да се прехвърлят тези чувствителни данни на някой друг.
В случай на централизирано приложение (онлайн портфейли или класически борси за криптовалута), процесът на създаване ще се извърши на тези централизирани платформи.
Методологиите за генериране трябва да бъдат проверени, за да се изключи детерминизмът. Сигурността на алгоритмите за генериране на поверителна криптографска информация трябва да бъде потвърдена от независими одитори.
Генерирането на ключове и сийдове трябва да се извършва в подходяща демилитаризирана зона (DMZ) или автономна система. Архивите на криптографски данни трябва да бъдат криптирани и прехвърлени в тайно хранилище на доверено лице за архивиране и възстановяване.
1.2 Random Bit Generators (RBG)
Става дума за ключове, които трябва да се използват с одобрени криптографски алгоритми.
Например True Random Number Generation (TRNG), подобно на детерминираните генератори на случайни битове (DRBG), се счита за приет стандарт в индустрията. Ключовете се генерират с помощта на математическа обработка на изхода, използвайки генератори на случайни битове и допълнителни параметри. За повече информация вижте Насоките за генериране на криптографски ключове (NIST Специална публикация 800-133).
2. Създаване на портфейл
Логиката на внедряването на портфейл или трезор на частен ключ за работа с блокчейн трансакции трябва да обхваща набор от въпроси: управление на адреси, използване на частни ключове за потвърждаване на операция и прилагане на мултиподпис.
Също така портфейлът може да бъде внедрен за всеки отделен акаунт. Детерминираният метод ви позволява да създадете набор от адреси / двойки ключове, под формата на общ пул от адреси от един главен сийд. Когато прилагате портфейл, трябва да обърнете внимание на различни рискове, като загуба, кражба и компрометиране на ключовете. Създаването на портфейл с акаунт на конкретен потребител трябва да бъде придружено от въвеждането на допълнителни нива на автентикация.
2.1 Внедряване на йерархичен детерминиран портфейл ( (HD Wallet)
Чрез главния сийд (наричан още “master seed”) може да се извърши създаване на достатъчен брой уникални адреси, свързани само с помощта на алгоритъма за генериране, т.е. независими един от друг за външен наблюдател. На всеки вторичен адрес е дадено място в раздвоената структура и е свързан с определен път през HD дървото. Важно е изпълнението на HD портфейла да отговаря на стандарта, т.е. BIP44.
2.2 Уникален адрес за всяка трансакция
За всяка анонимна трансакция трябва да се генерира уникален адрес.
2.3 Мултиподпис. Множество ключове за подписване
Всеки адрес, който е генериран от HD портфейла, изисква поне два подписа, които да се използват като вход за трансакция. Освен това, за да се предпазят средствата на потребителя от кражба, е необходимо ключовете да се поставят в DMZ, изолирани един от друг.
2.4 Ключ за възстановяване на резервно копие
Често срещан метод е да се създадат 2 от 3 възможни подписа, които да се използват като вход за извършване на трансакция.
2.5 Използване на йерархично детерминирани (HD) портфейли
Всички адреси се определят детерминирано въз основа на сийдове, които трябва да са частни.
Loading …
София
2.6 Архивиране на портфейла
Задължително е редовно да се създават резервни копия за всички новогенерирани ключове, както и на мастър сийда.
2.7 Криптиране на портфейла
Всички данни на портфейла трябва да бъдат криптирани с помощта на защитени алгоритми. Данните за дешифриране трябва да бъдат разположени на отделни възли със стриктни правила за сигурност, например Identity service, Vault HashiCorp и др.
3. Съхранение на ключове
Когато ключовете не се използват, те трябва да бъдат надеждно криптирани. В допълнение към самото криптиране е необходимо да се обърне внимание на самото съхранение на ключовете (те трябва да бъдат поставени в напълно независима инфраструктура) и физическата сигурност на носителите на информация.
3.1 Първичните ключове се съхраняват в криптиран вид
За съхранение на ключове и / или сийдове трябва да се използва високо ниво на криптиране. Например AES-256-CBC.
3.2 Място за съхранение на ключове
Криптирани ключове и / или сийдове и криптирани пароли трябва да се съхраняват на различни платформи. Освен това тази информация трябва да бъде физически разпределена между различни местоположения и доставчици.
3.3 Резервен ключ
Ключовете / сийдовете трябва да бъдат архивирани (цифрови, хардуерни, хартиени и др.).
3.4 Основна политика за архивиране
Ключовете трябва да бъдат защитени от физическо унищожаване, включително природни бедствия и щети (наводнения, пожари и др). Съхранявайте резервните копия на места, географски отдалечени от мястото на използване. Всички архивни копия трябва да бъдат защитени чрез контрол на достъпа.
4. Използване на клавиши
Всички операции за взаимодействие със сийдове трябва да се извършват безопасно. Необходимо е да се предотврати възможността за копиране или промяна на ключовете чрез зловреден софтуер.
Ключовете трябва да бъдат защитени от недобросъвестни потребители, които използват оторизиран достъп за неоторизирани трансакции. Прилагането на механизма за дешифриране и подписване трябва да бъде многопластово и надеждно.
4.1 За генериране на ключове се препоръчва използването на принципа „потребител / пропуск / n-ти фактор“
Достъпът до използване на ключ трябва да бъде защитен с помощта на многофакторен модел за автентикация. Например може да са необходими идентификатор (това може да бъде потребителско име, имейл и т.н.), маркери на Google Authenticator, цифрови подписи от частен ключ и проверка на личен идентификатор.
4.2 Ключовете трябва да се използват само в надеждна среда
Използването на ключове в надеждна DMZ среда намалява риска от неоторизирано копиране на зловреден софтуер, поставяне на копия и съхранение на ключове. Този подход също ще предпази от опити за възстановяване на злонамерени ключове и кражба на поверителни данни.
4.3 Проверка на оператора и на операционния дневник
Необходимо е да се извършат проверки на всички, които имат достъп до системата. Всички действия на оператора трябва да бъдат регистрирани и записани в дневници.
4.4 Едно устройство – един ключ
Два ключа от портфейла не могат да се съхраняват на едно и също устройство, достъпът до който изисква множество подписи.
4.5 Многофакторна автентикация
Трансакциите за подписване трябва да бъдат защитени чрез многофакторна автентикация.
4.6 Одитор на операциите
За важни трансакции трябва да добавите допълнителен етап за удостоверяване със задължително одобрение на мениджъра.
Това са основните компоненти, необходими за сигурна защита на система, базирана на блокчейн. Техническото изпълнение обаче не е достатъчно, за да се гарантира безопасността.
Необходимо е още:
Запис и документиране на всички операции с дневници, системни одити, одити на сигурността, процедури и политики за ключови потребители. Всички операции и промени в системата трябва да бъдат записани в дневниците.
Проследяване на регистрацията на трансакциите и архивиране на регистрационните файлове.
Използвани източници:
Withdrawn NIST Technical Series Publication
Most Significant Hacks of 2019 — New Record of Twelve in One Year
