Безпека застосунків, створених на основі блокчейн-інфраструктури: загальні проблеми та конкретні рішення

18 травня
Максим Завгородний, Solution-архітектор
Безпека застосунків, створених на основі блокчейн-інфраструктури: загальні проблеми та конкретні рішення
Я сім років працюю в DataArt, останні три роки як Solution-архітектор. Сфера професійних інтересів: ML/AI. До цього був залучений у проектування та розробку децентралізованих систем на базі блокчейну, де займався питаннями безпеки.

У цій статті я спробую пояснити основні принципи, яких варто дотримуватися, проектуючи блокчейн-рішення, та звернути увагу на окремі моменти: створення гаманців, генерацію, зберігання та використання ключів. У тексті не буде розбору технічних нюансів по кожному з них, виділені пункти можна використовувати як чекліст для перевірки плану вашого проекту на відповідність стандартам безпеки.

Рішення на основі технології блокчейн активно використовують у проектах фінансової сфери, наприклад, при проектуванні платіжних систем, бірж, криптовалютних торгових платформ. Але блокчейн з таким самим успіхом можна застосовувати у страхуванні, охороні здоров'я та інших сферах бізнесу. При цьому клієнти, зацікавлені у використанні порівняно нової та популярної технології, часто є недостатньо інформованими про проблеми безпеки, що виникають у блокчейн-проектах. Саме тому їхні застосунки так часто стають об'єктами зламу. Наприклад, у 2019 році було зламано понад 30 великих торгових платформ.

Почнемо з того, що значення кібербезпеки у криптовалютних проектах виглядає очевидним. А як щодо інших галузей? Давайте розглянемо основні аспекти технології блокчейн, що вимагають реалізації відповідно до високих стандартів безпеки —незалежно від характеру бізнесу замовника застосунку. Транзакції, сертифікати, створення та зберігання приватних ключів — кожен аспект або процес реалізації може рівною мірою виявитися недостатньо захищеним. Самі ці аспекти залишаються абсолютно однаковими в будь-який блокчейн-інфраструктурі. Хороша новина: кращим практикам, напрацьованим у фінансовій сфері, можна успішно слідувати, наприклад, у медичних проектах.

Найпростіший та найшвидший спосіб забезпечення безпеки блокчейн-проекту пов'язаний з використанням існуючих бібліотек з відкритим вихідним кодом (як-от bitcoinJ) або RPC-інтеграцією з продуктами на кшталт Electrum чи Geth. Це дозволить нам маніпулювати ключами, транзакціями, сідами тощо за допомогою існуючого RPC. Цей підхід дійсно може бути виправданий на етапі Proof of Concept, коли терміни та бюджет зазвичай є обмеженими. Але в режимі продакшну розглядати такий варіант не варто.

Бібліотеки та будь-яке ПЗ для генерації конфіденційної криптографічної інформації мають бути вільними від будь-яких додаткових функцій. Усі використовувані для цього програми мають успішно пройти юридичну перевірку й аудит безпеки, а будь-яка передача згенерованих ключів і сідів всередині системи має бути заборонена. До того ж заборонити варто і довіру до будь-яких відкритих бібліотек і сторонніх сервісів.

Ось список аспектів безпеки, які мають бути охоплені при проектуванні системи:

  • Генерація ключів/сідів.
  • Створення гаманця.
  • Зберігання ключів.
  • Використання ключів.

Давайте розглянемо, чого саме вимагають високі стандарти безпеки щодо кожного з цих пунктів.

1. ГЕНЕРАЦІЯ КЛЮЧА ТА/АБО СІДА

Всі криптографічні сіди і ключі для операцій з транзакціями мають створюватися всередині системи. Така інформація є абсолютно конфіденційною і не повинна передаватися третім особам. Алгоритми створення ключів і сідів мають при цьому дотримуватися конфіденційних і непрогнозованих правил.

1.1 Створений оператором ключ/сід

Така чутлива криптографічна інформація, як ключі або сіди, має створюватись оператором, відповідальним за підпис, що підтверджує транзакцію. Якщо ми говоримо про децентралізований застосунок, як-от криптогаманець, ключ і сід мають бути згенеровані користувачем застосунку без передачі цих конфіденційних даних ще комусь.

У випадку з централізованим застосунком (онлайн-гаманці або класичні криптовалютні біржі) процес створення виконуватиметься на цих централізованих платформах.

Методології генерації мають бути перевірені, щоб виключити детермінізм. Безпека алгоритмів генерації конфіденційної криптографічної інформації має бути підтверджена незалежними аудиторами.

Генерація ключового сіда має виконуватись у відповідній демілітаризованій зоні (DMZ) чи автономній системі. Резервні копії криптографічних секретів мають бути зашифровані та передані у таємне сховище довіреній особі для організації бекапів і відновлення.

1.2 Генератор псевдовипадкових чисел (DRBG)

Ми розглядаємо генерацію ключів, які слід використовувати з затвердженими криптографічними алгоритмами.

Наприклад, генерація випадкових чисел (TRNG), як і детерміновані генератори випадкових бітів (DRBG), в індустрії вважаються визнаним стандартом. Ключі генеруються з використанням математичної обробки на виході за допомогою генераторів випадкових бітів і додаткових параметрів. Більш детальну інформацію ви можете знайти в рекомендаціях щодо генерації криптографічних ключів (спеціальна публікація НІСТ 800-133).

2. СТВОРЕННЯ ГАМАНЦЯ

Логіка реалізації гаманця або сховища приватних ключів для роботи з блокчейн-транзакціями має охоплювати набір питань: керування адресами, використання приватних ключів для підтвердження операції, впровадження мультипідпису.

Також гаманець може бути впроваджений для кожного окремого облікового запису. Детерміністичний спосіб дозволяє створювати набір адрес / пари ключів у вигляді загального пулу адрес з одного майстер-сіда. Також при впровадженні гаманця необхідно звернути увагу на різні ризики, як-от втрата, крадіжка, компрометація ключів. Об'єднання гаманця з рахунком конкретного користувача має супроводжуватися впровадженням додаткових рівнів ідентифікації.

2.1 Реалізація ієрархічного детермінованого (HD) гаманця

Значення кореневого сіда (master seed) можна використовувати для створення достатньої кількості унікальних адрес, пов'язаних тільки за допомогою алгоритму генерації, тобто незалежних одна від одної для стороннього спостерігача. Кожна дочірня адреса отримує місце в розгалуженій структурі та асоціюється з певним шляхом через HD-дерево. Важливо, що реалізація HD-гаманця має відповідати стандарту, наприклад, BIP44.

2.2 Унікальна адреса для кожної транзакції

Для анонімної операції з транзакціями має бути згенерована унікальна адреса.

2.3 Мультипідпис. Декілька ключів для підпису

Для будь-якої адреси, яку генерує HD-гаманець, обов'язкові мінімум два підписи, щоб використовувати вхідні дані для транзакції. До того ж, щоб убезпечити кошти користувача від спроб розкрадання, необхідно розмістити ключі в ізольованих одна від одної демілітаризованих зонах.

2.4 Резервний ключ для відновлення

Загальний метод — створення двох із трьох можливих підписів для використання вхідних даних транзакції.

2.5 Використання ієрархічно детермінованих (HD) гаманців

Всі адреси призначаються детерміновано на основі сідів, які мають бути приватними.

2.6 Резервне копіювання гаманців

Обов'язковим є регулярне створення резервних копій для кожного нового покоління ключів і майстер-сіда.

2.7 Шифрування гаманця

Усі дані гаманця мають бути зашифровані за допомогою надійних алгоритмів. Дані для розшифровки повинні розташовуватися на окремих нодах з надійними політиками безпеки, наприклад, Identity service, Vault HashiCorp тощо.

Висока архітектура гаманця з мультипідписом

Висока архітектура гаманця з мультипідписом

3. ЗБЕРІГАННЯ КЛЮЧІВ

Коли ключі не використовуються, вони мають зберігатись у надійно зашифрованому вигляді. Крім власне шифрування, необхідно приділити увагу роздільному зберіганню ключів — їх варто помістити в абсолютно незалежні інфраструктури — і фізичній безпеці носіїв інформації, де це можливо.

3.1 Первинні ключі зберігаються в зашифрованому вигляді

Для зберігання ключів та/або сідів необхідно використовувати надійний рівень шифрування. Наприклад, AES-256-CBC.

3.2 Місце зберігання ключів

Зашифровані ключі та/або сіди та зашифровані паролі мають зберігатися на різних платформах. До того ж ця інформація має бути фізично рознесена між різними локаціями і провайдерами.

3.3 Резервний ключ

Необхідно створити резервні копії ключів/сідів (цифрові, апаратні, паперові тощо).

3.4 Політика резервного копіювання ключів

Ключі необхідно убезпечити від ризику фізичного знищення, зокрема від стихійних лих і техногенних катастроф: повеней, пожеж тощо. Зберігайте резервні копії у місцях, географічно віддалених від місця використання. Усі резервні копії мають бути захищені засобами контролю доступу.

4. ВИКОРИСТАННЯ КЛЮЧІВ

Усі операції взаємодії з сідами мають бути безпечними. Необхідно виключити можливість копіювання та зміни ключів шкідливими програмами.

Ключі повинні бути захищені від недобросовісних користувачів, які використовують авторизований доступ для несанкціонованих транзакцій. Реалізація механізму дешифрування і підпису має бути багаторівневою та надійною.

4.1 Для формування ключів рекомендується використовувати шлях: user/pass/nth factor

Доступ до використання ключа має бути захищений за допомогою багатофакторної моделі аутентифікації. Наприклад, може знадобитися ідентифікатор (ним може бути ім'я користувача, електронна адреса тощо), токени Google Authenticator, цифрові підписи з приватного ключа, особиста перевірка ID.

4.2 Ключі мають використовуватися тільки в довіреному середовищі

Використання ключів виключно в довіреному середовищі DMZ знижує  ризик несанкціонованого копіювання та зберігання ключів шкідливими програмами. Цей підхід також захищає від спроб відновлення ключів зловмисниками та крадіжки конфіденційних даних.

4.3 Перевірки рекомендацій оператора / security officer і журналу операцій

Необхідно перевірити минуле всіх співробітників, які отримують доступ до системи. Усі дії операторів мають бути зареєстровані та збережені в логах.

4.4 Один пристрій — один ключ

На одному й тому самому пристрої не можуть зберігатися два ключі від гаманця, доступ до якого вимагає декількох підписів.

4.5 Багатофакторна аутентифікація

Підписання транзакцій має бути захищене багатофакторною аутентифікацією.

4.6 Аудитор операцій

Для важливих транзакцій необхідно додати додатковий рівень аутентифікації з обов'язковим схваленням менеджера.

Послідовність використання ключів

Послідовність використання ключів

Ми розглянули основні рівні, необхідні для надійного захисту системи, заснованої на рішенні з використанням блокчейну. Проте однієї технічної реалізації для забезпечення безпеки недостатньо.

Також слід:

  • Охопити та задокументувати всі операції з логами, системні аудити, аудити безпеки, процедури і політики для ключових користувачів. Усі операції та зміни в системі мають реєструватись у логах.
  • Забезпечити трасування логування транзакцій і резервне копіювання логів.

Для написання статті були використані джерела:

  • Україна, Remote.UA; Україна, Дніпро; Україна, Київ; Україна, Львів; Україна, Одеса; Україна, Харків; Україна, Херсон
    18 листопада
  • Україна, Remote.UA; Україна, Дніпро; Україна, Київ; Україна, Львів; Україна, Одеса; Україна, Харків; Україна, Херсон
    1 липня
  • Україна, Дніпро; Україна, Київ; Україна, Львів; Україна, Одеса; Україна, Харків; Україна, Херсон
    25 червня
  • Україна, Одеса
    25 червня