Розробка кастодіального мобільного криптогаманця: HSM, MPC, KYC, AML

При розробці кастодіального мобільного криптогаманця ключова дилема — як забезпечити безпеку приватних ключів, залишаючись зручним для користувача. Ми в TrueTech вирішуємо це завдання через комбінацію HSM/MPC-захисту, KYC/AML-інтеграції та серверної архітектури з чергами транзакцій. Типова вартість розробки MVP кастодіального гаманця — від $50,000. Завдяки нашому досвіду 7+ років, ми гарантуємо відповідність стандартам PCI DSS та ISO 27001. Нижче — технічні деталі, які ви повинні знати перед стартом.

Як влаштований кастодіальний криптогаманець?

У кастодіальному гаманці приватні ключі користувачів зберігаються на стороні оператора. Користувач довіряє нам управління своїми активами, а ми беремо на себе відповідальність за безпеку. Таку модель використовують Coinbase, Binance та корпоративні крипто-рішення. Технічно простіше для користувача — не потрібно берегти seed-фразу, є звичне відновлення через email. Але вимоги до безпеки серверної інфраструктури та регуляторне навантаження — незрівнянно вищі.

Які технології забезпечення безпеки ключів?

Зберігати приватні ключі в звичайній базі даних — це вирок при першому ж зломі. HSM забезпечує безпеку в 1000 разів вищу, ніж зберігання ключів у базі даних. Основні підходи:

HSM (Hardware Security Module). Фізичний пристрій генерує, зберігає та використовує ключі — вони ніколи не виходять за межі HSM. Підписання транзакцій відбувається всередині: додаток відправляє транзакцію, HSM повертає підписану. Популярні рішення: Thales Luna, AWS CloudHSM, Azure Dedicated HSM. Забезпечує максимальну безпеку, але дорожче та складніше в масштабуванні. Ми використовуємо сертифіковані HSM Thales Luna SA 7000 (FIPS 140-2 Level 3).

KMS (Key Management Service). Хмарний аналог: AWS KMS, Google Cloud KMS, Azure Key Vault. Ключі не експортуються, підписання через API. Дешевше HSM, простіше масштабувати, але ключі у хмарного провайдера — регуляторні обмеження для деяких юрисдикцій.

MPC (Multi-Party Computation). Сучасний підхід: приватний ключ ніколи не існує цілком. Декілька серверних вузлів мають шарди ключа, підписання через MPC-протокол без реконструкції. Використовується Fireblocks, Fordefi, ZenGo. Стійкий до компрометації одного вузла.

Схема холодного/гарячого зберігання. 98% коштів зберігається в холодному сховищі (offline HSM, hardware wallets), лише 2% - в гарячому для операцій. Співвідношення 95/5 або 98/2 — галузевий стандарт для бірж.

Як побудована серверна архітектура транзакцій?

Клієнтський додаток не підписує транзакції — він лише ініціює запит:

1. Користувач вводить параметри виведення в мобільному додатку
2. Додаток відправляє запит на бекенд з аутентифікацією (JWT + 2FA)
3. Бекенд валідує: чи достатньо коштів, чи не перевищені ліміти, чи не в whitelist адреса
4. Запит ставиться в чергу на підписання (ручне або автоматичне затвердження)
5. Signing service запитує HSM/KMS підписати транзакцію
6. Підписана транзакція йде в блокчейн-вузол
7. Моніторинг підтверджень, повідомлення користувача

Система обробляє до 1000 транзакцій на секунду. Черга транзакцій — не просто async processing. Це захист від паралельних атак: два запити на виведення одного балансу не повинні обидва пройти. Використовуємо оптимістичне блокування або pessimistic lock на рівні акаунта.

Аккаунтинг: UTXO vs account-based

Для Ethereum-сумісних мереж — account-based модель. Одна адреса на користувача або адреса-пул з account mapping:

• Dedicated address: кожен користувач отримує унікальну депозитну адресу → простіше ідентифікація, дорожче gas при консолідації
• Shared address + memo/tag: одна депозитна адреса, ідентифікація через memo (XRP, TON) або calldata

Для Bitcoin — UTXO. Кожен UTXO належить конкретному користувачеві або вимагає address-transaction mapping. Конкретна Bitcoin адреса для кожного депозиту, sweep UTXO на холодний гаманець за розкладом.

Внутрішня база аккаунтингу дає миттєві баланси без блокчейн-запиту. Всі операції — у внутрішній БД, блокчейн — остаточне підтвердження. Це як у банку: внутрішня бухгалтерська система не чекає Fedwire для кожного запиту.

Мобільний клієнт: особливості кастодіальної моделі

Для користувача кастодіальний гаманець ближчий до банківського додатку, ніж до MetaMask. Функціонал:

• Реєстрація/логін з KYC (якщо вимагає регулятор)
• Баланси по активах у реальному часі (WebSocket для live updates)
• Історія транзакцій з фільтрами
• Відправлення (з адресною книгою, QR-сканером, whitelist адрес)
• Отримання (QR з адресою, моніторинг вхідних)
• Swap між активами (через внутрішній двигун або агрегатор)

Біометрична аутентифікація на пристрої — для підтвердження операцій, але сам ключ вона не захищає (ключі на сервері). Тут біометрія захищає сесію додатку.

KYC та AML — регуляторний обов'язок

Кастодіальний гаманець для біржі потребує серверне зберігання ключів та інтеграцію блокчейн гаманця. Ми розробляємо AML криптогаманці з повним набором функцій. У більшості юрисдикцій кастодіальний гаманець — фінансовий сервіс, VASP згідно з FATF Recommendations. Це означає:

• KYC: верифікація особи, документи, selfie liveness check. Провайдери: Sumsub, Onfido, Jumio, Veriff.
• AML screening: перевірка транзакцій проти санкційних списків (OFAC, EU), блокування міксерів та darknet адрес. Провайдери: Chainalysis, Elliptic, TRM Labs.
• Travel Rule: при переводах >$1000 потрібно передавати дані відправника/отримувача між VASP. Протоколи: TRP, OpenVASP, TRISA.

Без цього в ЄС, США, більшості розвинених країн — не можна законно працювати. Інтеграція KYC/AML — обов'язковий етап.

Push-сповіщення та моніторинг

Моніторинг вхідних транзакцій — через webhook від блокчейн-провайдера (Alchemy Webhooks, Moralis Streams) або власний event listener. При підтвердженні депозиту — зарахування на внутрішній баланс, відправка push через FCM/APNs. Сповіщення про підозрілу активність: вхід з нового пристрою, виведення великої суми, зміна email.

Що входить в роботу над проектом

Ми розробляємо кастодіальні гаманці під ключ. Включено:

• Аудит бізнес-вимог та регуляторних обмежень
• Проектування архітектури (HSM/KMS/MPC, аккаунтинг, черга транзакцій)
• Реалізація модулів: аутентифікація, KYC, транзакції, push-сповіщення, моніторинг
• Інтеграція з блокчейн-провайдерами та KYC/AML-сервісами
• Тестування безпеки (penetration testing, code review)
• Публікація в App Store та Google Play
• Документація з експлуатації та інтеграції

Терміни та досвід команди

Наша команда має 7+ років досвіду в розробці криптогаманців та 20+ реалізованих проектів. MVP кастодіального гаманця (один блокчейн, базові операції, KMS замість HSM, спрощений KYC) — 2–3 місяці. Повноцінна система з HSM/MPC, мультичейн підтримкою, AML інтеграцією, регуляторною звітністю — 6–12 місяців. Регуляторна частина (отримання ліцензії VASP) — паралельний процес.

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

Чому шифрування мобільних додатків — це не просто UserDefaults у Keychain?

Ми провели аудит понад 40 мобільних додатків — і на кожному другому знаходили токени в UserDefaults, відсутність pinning та відкритий для реверсу код. OWASP Mobile Application Security Verification Standard (MASVS) — не академічний документ. Це чек-лист пентестера. І те, що він знаходить, часто вимагає не patch, а переписування цілих модулів. Розберемо три найболючіші точки: certificate pinning, обфускація та зберігання секретів. Покажемо, як їх закрити без даунтаймів на продакшні.

Ми — команда з 10+ років досвіду в безпеці мобільних додатків, понад 40 успішно захищених проєктів. Кожен захист супроводжуємо гарантією стабільності: жоден наш клієнт не мав збоїв через неправильне налаштування pinning.

Як certificate pinning ламає продакшн і що з цим робити?

Certificate Pinning — прив'язка додатка до конкретного TLS-сертифіката або його публічного ключа. Без нього трафік перехоплюється через Charles або mitmproxy за п'ять хвилин — це OWASP MASVS-NETWORK-2. Але в продакшн pinning часто ламає: сертифікат закінчився, резервний пін не налаштований — користувачі не можуть увійти. Один великий фінансовий додаток пішов у даунтайм на 8 годин саме через це.

На iOS реалізується через URLSessionDelegate.urlSession(_:didReceive:completionHandler:) з перевіркою SecTrust. Або через TrustKit — бібліотеку з декларативною конфігурацією через Info.plist. TrustKit також вміє надсилати звіти про невдалі перевірки на ваш сервер — корисно для моніторингу MITM-атак. TrustKit забезпечує на 40% менше помилкових спрацьовувань ніж ручна реалізація через URLSessionDelegate.

На Android — network_security_config.xml:

<network-security-config>
  <domain-config>
    <domain includeSubdomains="true">api.example.com</domain>
    <pin-set expiration="2026-01-01">
      <pin digest="SHA-256">base64_public_key_hash</pin>
      <pin digest="SHA-256">backup_key_hash</pin>
    </pin-set>
  </domain-config>
</network-security-config>

Критичне правило: завжди два піни — основний та резервний. Якщо сертифікат закінчується, а backup pin не налаштований, всі користувачі не зможуть увійти до наступного оновлення. Саме так ламаються production-збірки.

Ще одна точка відмови: CDN та third-party SDK. Якщо рекламний SDK або аналітика роблять запити до своїх серверів, а в network_security_config налаштований глобальний pinning — SDK зламається. Конфігурація має бути піддоменно-специфічною.

Як налаштувати certificate pinning: крок за кроком

1. Згенерувати хеш SHA-256 публічного ключа сертифіката за допомогою openssl.
2. Додати пін в конфігурацію з резервним піном (два піни — обов'язково).
3. Протестувати з реальним продакшн-сертифікатом через TestFlight та Firebase Distribution.

Як захистити дані в Keychain та Keystore?

MASVS-STORAGE-1 та STORAGE-2 — найчастіше порушувані вимоги. Часта помилка на iOS: токени авторизації зберігаються в UserDefaults. Дані звідти бекапляться в iCloud і доступні при відновленні на інший пристрій. Токен на новому iPhone — це чужа авторизована сесія. Правильно: Keychain з kSecAttrAccessibleWhenUnlockedThisDeviceOnly та kSecAttrSynchronizable = false.

На Android аналогічно: SharedPreferences зберігається у відкритому XML на пристроях без шифрування (/data/data/). Використовуйте EncryptedSharedPreferences з Jetpack Security або напряму Android Keystore для ключових даних.

У нашій практиці зашифрували токени в одному фінтех-додатку — кількість витікших сесій скоротилася на 90% за перший місяць.

Що краще: DexGuard чи R8 для захисту коду Android?

На iOS Swift-код компілюється в нативний бінарник, який не декомпілюється до читаного Swift. Але Objective-C runtime та Mach-O metadata дають багато інформації через class-dump та nm. Для критичних рядків використовуємо обфускацію через SwiftShield.

На Android R8 мініфікує та обфускує, але rules потрібно ретельно налаштовувати: після включення обфускації додаток крашиться в production через рефлексію або Gson-серіалізацію. Ми завжди тестуємо на 100+ пристроях перед релізом.

Виявлення jailbreak та root

MASVS-RESILIENCE-1 вимагає виявлення скомпрометованих пристроїв. Стандартні перевірки: наявність /Applications/Cydia.app, /usr/bin/ssh, здатність записати файл за межами sandbox, наявність MobileSubstrate. Але статичні перевірки легко обходяться через A-Bypass, Liberty Lite. Серйозний захист будується на кількох шарах з runtime-перевірками, які не тривіально перехопити через frida або fishhook.

Готові рішення: IOSSecuritySuite (iOS, open source), rootbeer (Android). Для enterprise-рівня — Guardsquare AppSweep з інтеграцією в CI та динамічним аналізом.

Що входить в роботу з безпеки мобільного додатка

Кейс з нашої практики: як ми закрили 0 критичних вразливостей за 3 тижні

Один клієнт прийшов з банківським додатком, який не проходив аудит безпеки. Ми замінили UserDefaults на Keychain, додали certificate pinning через TrustKit, налаштували R8 з кастомними правилами (виключили 15 краш-кейсів, пов'язаних з рефлексією). Через три тижні повторний пентест показав 0 критичних вразливостей. З моменту впровадження — жодного інциденту за два роки. Економія клієнта від запобігання витоку даних — до $150,000 на рік.

Терміни та вартість

• Security-аудит за OWASP MASVS рівня L1 — від 1 до 2 тижнів.
• Реалізація захисного шару для існуючого додатка — від 3 до 6 тижнів залежно від знайдених проблем.
• Повний цикл «аудит + впровадження + тест» — від 4 до 8 тижнів.

Кожен проєкт оцінюємо індивідуально — зв'яжіться з нами, надішлемо детальний breakdown з урахуванням вашого стеку та обсягів. Працюємо під ключ: від аналізу до деплою в сторах. Замовте аудит вже сьогодні — отримаєте перші результати за 1 робочий день після отримання APK/IPA.