Розробка мобільного HD-гаманця (BIP-39/BIP-44)

Ми часто бачимо, як команди намагаються реалізувати HD-гаманець, просто згенерувавши seed-фразу з бібліотеки й отримавши адресу, але при перенесенні фрази в MetaMask або Trust Wallet адреси не збігаються. Причина — ігнорування стандартів деривації (BIP-44) і відмінностей у кривих (secp256k1 vs Ed25519). У цій статті розберемо, як уникнути таких помилок і побудувати сумісний гаманець.

Як забезпечити сумісність HD-гаманця з MetaMask і Ledger?

Сумісність досягається точним дотриманням BIP-44 шляхів і використанням перевірених криптобібліотек. Наприклад, WalletCore (від Trust Wallet) підтримує 60+ монет і коректно обробляє hardened derivation для Ed25519. Починаємо з аудиту вимог: які монети, чи потрібна сумісність з конкретним гаманцем. Потім обираємо бібліотеку: WalletCore для iOS/Android або noble-curves + поліфіли для React Native. Ентропія генерується апаратно: SecRandomCopyBytes (iOS) або SecureRandom (Android).

Чому готові бібліотеки не вирішують усіх проблем?

Проблема 1: BigInt і нативні модулі

У React Native старі версії Hermes не підтримують BigInt. Бібліотека @scure/bip32 (noble-curves) вимагає його, і додаток падає з ReferenceError: BigInt is not defined. Рішення — явний поліфіл або перехід на react-native-quick-crypto з нативним модулем.

Проблема 2: Різниця кривих

BIP-32/44 спочатку писалися для secp256k1 (Bitcoin, Ethereum). Solana використовує Ed25519 і SLIP-0010 деривацію, де всі шляхи hardened. Якщо змішувати криві без урахування цього, адреси будуть невірними. WalletCore обробляє це коректно.

Проблема 3: Тестування сумісності

Вектори з BIP-39 та BIP-32 специфікацій — обов'язкова частина тест-сьюту. Якщо ваш mnemonicToSeed("abandon abandon ... about") видає не c55257... — у PBKDF2 баг. BIP-39 визначає тестові вектори для всіх kdf параметрів.

Як реалізувати HD-гаманець за 5 кроків?

1. Аудит вимог: визначити монети, цільову платформу (iOS/Android/Flutter/RN) та необхідну сумісність з іншими гаманцями.
2. Вибір бібліотеки: WalletCore (нативний або через Flutter/RN мости) або noble-curves з поліфілом BigInt.
3. Генерація seed: апаратна ентропія з Secure Enclave/StrongBox, мнемоніка створюється за BIP-39.
4. Деривація ключів: за BIP-44 для secp256k1 або SLIP-0010 для Ed25519, усі hardened шляхи.
5. Тестування: юніт-тести на офіційні вектори та інтеграційні тести відновлення адрес.

Як ми будуємо реалізацію, що гарантує сумісність?

Структура гаманця в пам'яті:

HDWallet
├── mnemonic: String (тільки в пам'яті, ніколи в UserDefaults)
├── seed: Data (512 біт, ephemeral)
└── accounts: [CoinType: [HDAccount]]
    ├── ETH: account 0 → m/44'/60'/0'
    ├── BTC: account 0 → m/44'/0'/0'
    └── SOL: account 0 → m/44'/501'/0'/0'

Приватні ключі — у Secure Enclave (iOS) або StrongBox (Android). Seed та мнемоніка знищуються через Data.resetBytes / Arrays.fill(). Для мультиакаунту фіксуємо вибір account' або address_index у ТЗ.

Таблиця порівняння підходів:

WalletCore забезпечує сумісність з 60+ монетами, тоді як noble-curves вимагає ручної реалізації для кожної, що у 5 разів збільшує час розробки.

Порівняння термінів по платформах:

Типові помилки при реалізації

• Зберігання seed-фрази в SharedPreferences/UserDefaults — грубе порушення безпеки. Використовуйте Secure Enclave/StrongBox.
• Ігнорування hardened derivation — при normal derivation витік child private key призводить до відновлення parent ключа.
• Змішування BIP-44 та SLIP-0010 — для Ed25519 всі шляхи hardened, для secp256k1 — mixed.

Що входить у нашу роботу

• Аудит вимог та вибір криптобібліотеки.
• Реалізація генерації та відновлення seed-фрази (BIP-39).
• Деривація ключів за BIP-44 та SLIP-0010.
• Інтеграція з Secure Enclave/StrongBox.
• Написання unit-тестів на офіційні вектори.
• Тестування сумісності з гаманцями (MetaMask, Trust Wallet, Ledger).
• Деплой в App Store/Google Play та документація.

Готові оцінити ваш проєкт? Зв'яжіться з нами — ми допоможемо реалізувати HD-гаманець під ключ з гарантією сумісності та безпеки.

Докладніше про стандарти: BIP-39 та BIP-44.

Чому шифрування мобільних додатків — це не просто 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.