Розробка некастодіального мобільного криптогаманця під iOS та Android

Користувач втратив seed-фразу — 12 слів, записаних на клаптику паперу. Рахунок на $200k заморожено назавжди. Некастодіальний гаманець повинен виключати такі сценарії архітектурно: приватний ключ шифрується і зберігається лише на пристрої, відновлення можливе тільки за мнемонікою. Ми в True Tech розробляємо некастодіальні криптогаманці протягом багатьох років, реалізували 15+ проєктів для iOS та Android. Наш досвід показує: головне — коректна реалізація BIP-стандартів та безпечне зберігання seed.

Чому некастодіальний гаманець — єдиний безпечний вибір?

Найпоширеніша проблема — втрата seed-фрази. Користувачі не роблять бекап, втрачають листок або зберігають у хмарі без шифрування. Друга проблема — несумісність: нестандартна деривація позбавляє можливості відновити адреси в інших гаманцях. Третя — витік приватного ключа при зберіганні у відкритому вигляді. Крім того, неправильний розрахунок gas (EIP-1559) збільшує комісії в 2–5 разів, а відсутність WalletConnect ізолює гаманець від DeFi-екосистеми. Всі ці проблеми вирішуються архітектурно.

Чому BIP39/32/44 — обов'язковий фундамент?

Починаємо з мнемонічної фрази. BIP39 визначає список з 2048 слів та алгоритм генерації 512-бітного seed з 12 або 24 слів + опціональної passphrase через PBKDF2-HMAC-SHA512 (2048 ітерацій). Seed → master key через BIP32 HMAC-SHA512. Ієрархічна деривація ключів за шляхом BIP44: m/44'/60'/0'/0/0 — перша Ethereum адреса, m/44'/0'/0'/0/0 — перша Bitcoin адреса. Чому це критично: користувач повинен мати можливість відновити всі свої адреси в будь-якому іншому сумісному гаманці (MetaMask, Trust Wallet, Ledger) за однією мнемонікою. Відступ від стандарту позбавляє користувача цієї можливості.

Генерація мнемоніки на Android:

// BitcoinJ або Web3j для BIP39
val entropy = ByteArray(16) // 128 біт → 12 слів
SecureRandom().nextBytes(entropy)
val mnemonic = MnemonicCode.INSTANCE.toMnemonic(entropy)
// ["word1", "word2", ..., "word12"]

// seed з мнемоніки
val seed = MnemonicCode.toSeed(mnemonic, "") // без passphrase
val masterKey = HDKeyDerivation.createMasterPrivateKey(seed)

Контрольна сума мнемоніки (останнє слово або його частина) — обов'язкова валідація при імпорті. Користувачі регулярно вводять помилки.

iOS, Swift:

// WalletCore від Trust Wallet — чудова бібліотека для iOS/Android
let wallet = HDWallet(strength: 128, passphrase: "")
let mnemonic = wallet.mnemonic  // 12 слів
let ethAddress = wallet.getAddressForCoin(coin: .ethereum)

Trust Wallet Core (WalletCore) — open source, підтримує 60+ блокчейнів, реалізує всі BIP стандарти. Використовується в Trust Wallet, Argent, і десятках інших гаманців. Для нового некастодіального гаманця — стандартний вибір основи. WalletCore в 2 рази прискорює розробку порівняно з самостійною реалізацією.

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

Ключ не можна зберігати у відкритому вигляді ніде: ні у файлі, ні в SharedPreferences, ні в базі даних. Схема:

1. Користувач створює PIN або налаштовує біометрію
2. Генерується випадковий ключ шифрування (AES-256), захищений Android Keystore / iOS Secure Enclave з прив'язкою до біометрії
3. Seed шифрується цим ключем
4. Зашифрований blob зберігається в зашифрованій БД (SQLCipher) або EncryptedSharedPreferences

При біометричній аутентифікації:

val cryptoObject = BiometricPrompt.CryptoObject(cipher) // cipher прив'язаний до ключа в Keystore
biometricPrompt.authenticate(promptInfo, cryptoObject)
// в onAuthenticationSucceeded:
val decryptedSeed = result.cryptoObject?.cipher?.doFinal(encryptedSeed)

Приватний ключ у розшифрованому вигляді живе в пам'яті лише на час підписання транзакції. Після — обнуляємо масив байт, GC не гарантує звільнення, тому явний Arrays.fill(keyBytes, 0.toByte()).

Як інтегруватися з блокчейнами та DeFi?

Для Ethereum-сумісних мереж (ETH, BSC, Polygon, Arbitrum, Optimism) — Web3j (Android) або web3.swift (iOS). Для Bitcoin — BitcoinJ. Для Solana — Solana Mobile Stack SDK. Для TON — ton-kotlin або TonConnect. Підключення до мережі через RPC провайдер: Infura, Alchemy, QuickNode. Для приватності — власна нода (але дорого в підтримці) або використання декількох провайдерів з fallback.

Відправка ETH транзакції:

val credentials = Credentials.create(privateKeyHex)
val nonce = web3j.ethGetTransactionCount(
    credentials.address,
    DefaultBlockParameterName.PENDING
).send().transactionCount

val rawTransaction = RawTransaction.createEtherTransaction(
    nonce,
    gasPrice,
    gasLimit,
    toAddress,
    amountInWei
)
val signedTransaction = TransactionEncoder.signMessage(rawTransaction, chainId, credentials)
val txHash = web3j.ethSendRawTransaction(
    Numeric.toHexString(signedTransaction)
).send().transactionHash

Приватний ключ використовується тільки для TransactionEncoder.signMessage — підпис відбувається локально, в мережу йде лише підписана транзакція без ключа.

EIP-1559 та розрахунок газу

З London hardfork (EIP-1559) транзакції мають maxFeePerGas і maxPriorityFeePerGas замість простого gasPrice. Правильний розрахунок: eth_feeHistory RPC метод для аналізу останніх блоків, алгоритм підбору maxPriorityFeePerGas (tip) на основі перцентилів. MetaMask використовує 50-й перцентиль пріоритетних комісій з останніх 5 блоків як базову пораду. Показувати користувачеві три варіанти (slow/normal/fast) з оцінкою часу підтвердження — стандартний UX. Неправильний розрахунок збільшує вартість транзакції до 30%.

WalletConnect для dApps

Без WalletConnect гаманець ізольований від екосистеми DeFi. WalletConnect v2 (Sign API) — протокол для зв'язку між гаманцем і dApp через relay сервер. Реалізація: WalletConnect Swift SDK (iOS), WalletConnect Kotlin SDK (Android). Сесія встановлюється через QR-код або deep link:

1. dApp генерує URI: wc:...@2?relay-protocol=irn&symKey=...
2. Користувач сканує QR в гаманці
3. Встановлюється E2E-зашифрована сесія через relay
4. dApp запитує eth_sendTransaction → користувач бачить деталі → підписує

Seed phrase backup flow

UX seed backup — критична частина. Користувачі втрачають гроші через втрату seed. Правильний флоу:

1. Показати мнемоніку — запитати підтвердження, що записав
2. Верифікація: показати 3 випадкових слова з фрази, попросити ввести порядкові номери
3. Нагадувати про бекап в онбордингу та періодично Забороняємо скріншоти на екрані з seed через FLAG_SECURE / iOS UIScreen.capturedDidChangeNotification.

Мультичейн та токени

ERC-20 токени не потребують окремих ключів — та ж Ethereum адреса. Баланс через balanceOf(address) виклик контракту. Список токенів — через CoinGecko API або Trust Wallet Assets репозиторій (відкритий список з іконками для 10000+ токенів). NFT (ERC-721, ERC-1155) — ownerOf(tokenId) / balanceOf(address, id). Метадані через tokenURI → IPFS або HTTP.

Порівняння методів зберігання ключів

Процес розробки та терміни

Аналітика та проектування — узгодження функціональних вимог, вибір блокчейнів, архітектури. Реалізація — написання коду генерації ключів, зберігання, підписання. Інтеграція — підключення RPC, WalletConnect, фіатних шлюзів (опціонально). Тестування — пентести, симуляції втрати seed, перевірка на сумісність. Деплой — публікація в App Store та Google Play, налаштування CI/CD.

В результаті ви отримуєте вихідний код гаманця під iOS та/або Android, повну документацію з архітектури та безпеки, доступ до репозиторію та CI-пайплайнів, інтеграцію з обраними блокчейнами, налаштування WalletConnect v2, допомогу з публікацією в сторах, навчання команди замовника (2 дні) та гарантійну підтримку 3 місяці.

Базовий некастодіальний гаманець (Ethereum + ERC-20 + WalletConnect + seed backup) — 2–4 місяці. Додавання кожного нового блокчейну з повною інтеграцією — 2–4 тижні. Вартість розраховується індивідуально.

Некастодіальний гаманець у більшості юрисдикцій не вимагає ліцензії — користувач сам керує своїми ключами. Але якщо додається обмін валют (swap), fiat on-ramp — ситуація змінюється. Консультація з юристом щодо регулювання обов'язкова перед запуском з такими функціями. Ми гарантуємо, що ваш продукт відповідатиме найкращим практикам безпеки та вимогам App Store Review Guidelines.

Отримайте консультацію щодо вашого проєкту — зв'яжіться з нами. Замовте розробку гаманця з гарантованою безпекою.

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