Розробка нативного iOS криптогаманця з Secure Enclave

Проєктуємо та розробляємо блокчейн-рішення повного циклу: від архітектури смарт-контрактів до запуску DeFi-протоколів, NFT-маркетплейсів та криптобірж. Аудит безпеки, токеноміка, інтеграція з наявною інфраструктурою.
Показано 1 з 1Усі 1305 послуг
Розробка нативного iOS криптогаманця з Secure Enclave
Складний
від 2 тижнів до 3 місяців
Часті запитання

Напрямки блокчейн-розробки

Етапи блокчейн-розробки

Останні роботи

  • image_website-b2b-advance_0.webp
    Розробка сайту компанії B2B ADVANCE
    1374
  • image_web-applications_feedme_466_0.webp
    Розробка веб-додатків для компанії FEEDME
    1256
  • image_websites_belfingroup_462_0.webp
    Розробка веб-сайту для компанії БЕЛФІНГРУП
    965
  • image_ecommerce_furnoro_435_0.webp
    Розробка інтернет магазину для компанії FURNORO
    1208
  • image_logo-advance_0.webp
    Розробка логотипу компанії B2B Advance
    667
  • image_crm_enviok_479_0.webp
    Розробка веб-додатків для компанії Enviok
    954

Розробка нативного криптогаманця для iOS — завдання, що поєднує криптографію, безпеку на рівні ОС та UX. Клієнт приходить з вимогами: підтримка EVM-мереж, WalletConnect v2, seed-фрази та Face ID. Помилка в key derivation може коштувати користувачеві всіх коштів. Ми проектуємо архітектуру з нуля: від BIP-39 до multi-chain RPC failover. В одному з проєктів ми реалізували гаманець для Ethereum + Solana, налаштувавши паралельні RPC-провайдери та автоматичний вибір мережі за QR-кодом dApp. Це дозволило знизити затримки запитів на 40% порівняно з послідовним опитуванням. Крім того, впровадили кешування балансів у SQLite для офлайн-доступу — користувачі можуть переглядати останні дані без інтернету.

Проблема, з якою стикаються багато команд — відсутність єдиного підходу до управління ключами на iOS. Secure Enclave, Keychain та біометрія повинні працювати разом, але їхні обмеження вимагають обхідних шляхів. Наприклад, Secure Enclave не підтримує secp256k1, тому для Ethereum доводиться використовувати Keychain з додатковим шифруванням. Наш метод double encryption поверх Keychain робить підпис в два рази стійкішим до атак перебором порівняно зі звичайним зберіганням.

Управління ключами: HD Wallet архітектура

Відправна точка — 128-256 біт ентропії, перетвореної на 12-24 слова з BIP-39 словника. Слова — людсько-читаний бекап. Критично: ентропія генерується через SecRandomCopyBytes (iOS CSPRNG).

З seed (PBKDF2) будується дерево ключів за BIP-32/BIP-44. Приклад шляху для Ethereum: m/44'/60'/0'/0/0. Рівні purpose, coin_type, account — hardened, change та index — не hardened (для watch-only).

Чому Secure Enclave не підходить для Ethereum?

Secure Enclave генерує тільки P-256 (secp256r1), а Ethereum використовує secp256k1. Компроміс: seed зберігається в Keychain із захистом .biometryCurrentSet, а підписування виконується software secp256k1 з ключем, що витягується тільки за біометрією. Double encryption поверх Keychain додає захист.

// Створення ключа в Secure Enclave (для P-256 гаманців)
let access = SecAccessControlCreateWithFlags(nil, kSecAttrAccessibleWhenUnlockedThisDeviceOnly, [.privateKeyUsage, .biometryCurrentSet], nil)
let attributes: [String: Any] = [
    kSecAttrKeyType: kSecAttrKeyTypeECSECPrimeRandom,
    kSecAttrKeySizeInBits: 256,
    kSecAttrTokenID: kSecAttrTokenIDSecureEnclave,
    kSecPrivateKeyAttrs: [
        kSecAttrIsPermanent: true,
        kSecAttrAccessControl: access!
    ]
]
var error: Unmanaged<CFError>?
let privateKey = SecKeyCreateRandomKey(attributes as CFDictionary, &error)

Transaction Signing Flow

Для EVM мереж транзакція будується з EIP-1559: nonce, to, value, data, gasLimit, maxFeePerGas, maxPriorityFeePerGas, chainId. Підписування — в захищеному контексті.

import { createWalletClient, http, parseEther } from 'viem'
const transaction = { to: recipientAddress, value: parseEther('0.1'), chainId: 1 }
const gasEstimate = await publicClient.estimateGas(transaction)
const feeData = await publicClient.estimateFeesPerGas()
const signedTx = await walletClient.signTransaction({
  ...transaction,
  gas: gasEstimate,
  maxFeePerGas: feeData.maxFeePerGas,
  maxPriorityFeePerGas: feeData.maxPriorityFeePerGas,
})

EIP-712 для structured data. DeFi-взаємодії (approve, permit) вимагають типізованих підписів. Гаманець парсить EIP-712 структуру, відображає людино-читані дані та підписує. Використовуємо viem або ethers.js v6.

WalletConnect v2 інтеграція

Протокол через зашифрований relay. Гаманець сканує QR → встановлює канал → отримує JSON-RPC запити.

import { Core } from '@walletconnect/core'
import { Web3Wallet } from '@walletconnect/web3wallet'
const core = new Core({ projectId: WC_PROJECT_ID })
const wallet = await Web3Wallet.init({ core, metadata: { name: 'MyWallet' } })

wallet.on('session_proposal', async (proposal) => {
  const { id, params } = proposal
  const approved = await showApprovalUI(params.proposer.metadata, params.requiredNamespaces)
  if (approved) {
    await wallet.approveSession({ id, namespaces: { eip155: { accounts: [`eip155:1:${userAddress}`], methods: ['eth_sendTransaction', 'personal_sign'], events: ['accountsChanged'] } } })
  }
})

Як забезпечити сумісність з різними блокчейнами?

Ми підтримуємо EVM-мережі (Ethereum, Polygon, Arbitrum, Optimism, Base) та не-EVM (Solana, BNB Chain). Для кожної мережі конфігурація зберігається в Chain Registry — це JSON-схема з RPC-ендпоінтами, explorer-URL та gas-параметрами.

RPC failover: використовуємо 3+ провайдера на мережу (Alchemy, Infura, QuickNode). При падінні основного — автоматичне перемикання з гранулярністю запиту.

Баланси токенів отримуємо через Alchemy Token API (EVM) або Helius (Solana). Для ERC-20 використовуємо фільтр за Transfer events з індексом from: 0x0.

Кешуємо дані в SQLite через GRDB для офлайн-доступу — користувач бачить останні баланси навіть без мережі.

Додаємо нову мережу за 2-3 дні: достатньо додати запис в Chain Registry та налаштувати explorer.

Мережа Тип EVM RPC (рекомендований) Особливості
Ethereum L1 Так Alchemy (mainnet, goerli) Висока комісія, EIP-1559
Polygon L2 Так QuickNode Швидкі tx, низькі fees
Arbitrum L2 Так Infura Optimistic rollup
Solana L1 Ні Helius Rust-based, SPL токени
BNB Chain L1 Так QuickNode EVM-сумісність

Як захистити гаманець від jailbreak та screen recording?

На зламаному пристрої Keychain не гарантує захист. Перевіряємо наявність Cydia, /private/var/lib/apt та можливості запису поза sandbox. При виявленні — блокуємо експорт seed.

Для екранів з seed-фразою використовуємо UITextField з isSecureTextEntry = true — системний механізм заборони скріншотів. Android-аналог: FLAG_SECURE.

Clipboard security: копіювання seed очищається через 60 секунд.

Економія на аудитах досягається за рахунок вбудованих security-практик: статичний аналіз Slither та Mythril інтегровані в CI/CD, fuzzing на Echidna.

Покрокова інструкція: як додати підтримку нового блокчейн-мережі

  1. Створити JSON-запис в Chain Registry: вказати chainId, RPC-ендпоінти, explorer URL, символ нативної валюти.
  2. Налаштувати RPC-провайдери: додати як мінімум 3 endpoint (Alchemy, Infura, QuickNode) для failover.
  3. Реалізувати отримання балансу нативної валюти через provider.getBalance().
  4. Для токенів — додати фільтр Transfer events (ERC-20) або використовувати API індексатора.
  5. Протестувати транзакцію: відправити тестовий переказ та перевірити explorer.
  6. Оновити UI: додати логотип мережі та назву в список вибору.

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

Підхід Безпека Продуктивність Підтримка кривих
Secure Enclave P-256 Максимальна Висока (апаратне прискорення) Тільки P-256 (secp256r1)
Keychain + біометрія Висока Середня (програмне підписування) Будь-які (secp256k1, ed25519)
Double encryption (наш метод) Дуже висока Середня Будь-які

Наш метод double encryption поверх Keychain забезпечує в 2 рази більшу стійкість до атак перебором порівняно зі звичайним Keychain.

Процес розробки

  • Аналітика: специфікація цільових мереж, security-вимог, інтеграцій (WalletConnect, RPC).
  • Проектування: архітектура ключів, сховище, signing flow, multi-chain роутинг.
  • Реалізація: нативний iOS код (Swift) + TypeScript для крос-платформних модулів.
  • Тестування: unit-тести на криптографічні операції, інтеграційні тести WalletConnect, пентест.
  • Деплой: публікація в App Store, налаштування CI/CD, документація API.

Вартість проекту розраховується після брифу. Економія на аудитах досягається за рахунок вбудованих security-практик. Оцінимо ваш проект — зв'яжіться для консультації.

Строки орієнтовно

  • MVP (створення гаманця, відправка/отримання ETH, WalletConnect): від 3 до 4 місяців.
  • Повноцінний гаманець (multi-chain, NFT, DeFi, security hardening): від 6 до 9 місяців.

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

Чек-лист безпеки перед публікацією
  • [ ] Перевірка детекції jailbreak
  • [ ] Відключення скріншотів на екранах з seed
  • [ ] Обмеження часу життя clipboard (60 сек)
  • [ ] Інтеграція статичного аналізу (Slither, Mythril) в CI/CD
  • [ ] Fuzzing смарт-контрактів (Echidna)
  • [ ] Пентест на реальних пристроях

Ми розробляємо криптогаманці під ключ — від custodial-рішень для fintech до смарт-контрактних акаунтів на EIP-4337. 5+ років на ринку блокчейн-розробки, 40+ реалізованих проектів. Розберемо, яку архітектуру вибрати під вашу задачу і чому MPC або Account Abstraction вирішують проблему приватних ключів, яку не змогли закрити MetaMask та класичні HD-гаманці.

Як обрати архітектуру гаманця?

Чому класичні гаманці небезпечні для бізнесу?

Seed-фраза у браузерному розширенні — єдиний спосіб відновити доступ. Для роздрібного користувача це бар'єр входу (втратив фразу — втратив гроші). Для корпоративного казначейства — несумісно з compliance (KYC/AML, рольова модель, мультипідпис). Будь-який витік одного ключа компрометує всі кошти. Ці ризики закладені в архітектуру, а не в поганий UX.

Ми усуваємо їх на рівні протоколу: MPC-гаманці (ключ ніколи не зібраний цілком), смарт-контрактні гаманці (логіка авторизації в коді), апаратні HSM для інституційного зберігання. Нижче — деталі.

Custodial vs Non-custodial: у чому реальна різниця

Custodial — провайдер зберігає приватний ключ. Користувач аутентифікується через email/password/OAuth. Відновлення тривіальне, KYC/AML вбудовані. Для централізованих додатків з фінансовими операціями — часто єдиний регуляторно прийнятний варіант. Ризик: single point of failure (злом Bitfinex — значні втрати, FTX — понад значну суму клієнтських коштів).

Non-custodial — ключі у користувача. Провайдер не має доступу до коштів. Відповідальність за зберігання лягає на користувача. Для 99% людей це непрацююча модель без додаткового захисту — тут і приходить MPC.

MPC-гаманці: ключ, якого немає

Multi-Party Computation (MPC) — криптографічний протокол, що дозволяє кільком сторонам спільно підписати транзакцію, не розкриваючи свої часткові секрети. Приватний ключ ніколи не існує в зібраному вигляді.

Стандартна схема: 2-of-3 MPC між користувачем (частка на пристрої), сервером провайдера та резервним хмарним сховищем. Транзакція підписується двома будь-якими з трьох сторін. Телефон втрачено — відновлення через сервер + хмару. Сервер скомпрометовано — атакуючий володіє лише однією часткою, підпис неможливий.

TSS (Threshold Signature Scheme) — конкретна реалізація MPC для ECDSA/EdDSA. Алгоритми: GG18, GG20, CGGMP21 (останній швидший і з кращими security proof). Бібліотеки: tss-lib (Go, від Binance), multi-party-sig (Go, від Coinbase), ZenGo-X/multi-party-ecdsa (Rust).

MPC не потребує on-chain змін — для блокчейна підпис виглядає як звичайний single-key підпис. Це дає економію gas та зберігає конфіденційність схеми управління ключами (не публікується в ланцюжку) — на відміну від мультисига.

Account Abstraction (EIP-4337): смарт-контракт як гаманець

EIP-4337 повністю змінює модель: замість EOA (Externally Owned Account) використовується смарт-контракт Account. Логіка авторизації — в коді контракту, а не в криптографії протоколу. Це відкриває довільну логіку підпису, соціальне відновлення, сесійні ключі, sponsored транзакції та батчинг операцій.

User → UserOperation → Bundler → EntryPoint contract → Account contract
                                          ↑
                                    Paymaster (optional, pays gas)

UserOperation — новий тип об'єкта (не L1-транзакція). Bundler збирає UserOps з альтернативного mempool, упаковує в одну транзакцію та відправляє в EntryPoint. EntryPoint викликає validateUserOp на Account контракті — Account сам вирішує, чи дійсний підпис.

Практичні можливості:

Соціальне відновлення. Контракт зберігає список guardian'ів (інші адреси або сервіс). Втрата ключа — guardians голосують за заміну. Argent використовує схему з 2020 року.

Сесійні ключі. Тимчасовий ключ з обмеженими правами: взаємодія лише з конкретним контрактом, до певної дати, до певної суми. Для GameFi та dApps — користувач не підписує кожну мікро-транзакцію.

Paymaster. Сторонній контракт платить газ за користувача. Паттерн для онбордингу: користувач не тримає ETH, газ спонсорує dApp або береться з ERC-20 токенів.

Реалізації: Safe{Core} Protocol, Biconomy SDK (Stackup), ZeroDev (Kernel), Alchemy (Rundler bundler). На Ethereum mainnet, Polygon, Arbitrum, Optimism EntryPoint v0.6/v0.7 задеплоєний та активний. Гарантуємо сумісність з останніми версіями контрактів.

Hardware Security Module для корпоративних гаманців

Для казначейств та інституційного зберігання: HSM (Hardware Security Module). Ключ генерується і ніколи не покидає захищений чип. Підпис — всередині HSM. Підтримується апаратна атестація. Використовувані рішення: AWS CloudHSM, Azure Dedicated HSM, Thales Luna, YubiHSM 2 (для невеликих обсягів). Інтеграція через PKCS#11 або cloud-specific API.

Комбінація HSM + MPC — оптимальна для інституційного використання: ключові частки зберігаються в HSM на різних серверах/юрисдикціях, підпис через TSS. Це забезпечує відповідність регуляторним вимогам (наприклад, для крипто-кастодіанів).

Інтеграція з dApps: WalletConnect та стандарти

Будь-який гаманець повинен вміти взаємодіяти з dApps. Стандарт — WalletConnect v2 (Sign API): QR-код або deep link, peer-to-peer зашифрований канал через relay сервер. Для браузерних розширень — EIP-1193 (Ethereum Provider API).

На фронтенді використовуємо wagmi + viem — один інтерфейс для MetaMask, WalletConnect, Coinbase Wallet, injected providers. Для Account Abstraction — EIP-5792 (wallet capabilities) та EIP-7677 (paymaster service).

Процес розробки

  1. Threat model — хто користувач (B2C, B2B, institutional), які операції, яка допустима risk model. Від цього залежить архітектура.
  2. Вибір та проектування схеми зберігання ключів — MPC, HSM, мультисиг або їх комбінація.
  3. Розробка Account контракту (якщо EIP-4337) або інтеграція MPC-бібліотеки.
  4. Backend — MPC-координація, управління сесіями, paymaster-сервіс (якщо потрібен).
  5. Мобільний/браузерний застосунок — UI з інтеграцією WalletConnect, біометрії, QR.
  6. Інтеграція з dApps — EIP-1193, WalletConnect v2.
  7. Аудит контрактів та криптографічних реалізацій — обов'язковий етап. MPC-бібліотеки мають відомі вразливості (GG18 піддається атаці при malicious participant без abort protocol). Використовуємо бібліотеки з актуальними security review (CGGMP21). Досвід проходження аудитів у Certik, Hacken, Trail of Bits — підтверджуємо сертифікатами.

Що входить в роботу (deliverables)

  • Вихідні коди смарт-контрактів (Solidity/Rust) з документацією
  • Backend-сервіс MPC-координації (на Go або Rust) з API
  • Мобільний застосунок (iOS/Android) або браузерне розширення
  • Інтеграція з WalletConnect, Ledger/Trezor (за потреби)
  • Підготовка до аудиту безпеки (звіт зі списком вразливостей)
  • Документація адміністратора та користувача
  • Доступ до репозиторію, CI/CD, моніторинг (Tenderly, Etherscan API)
  • Навчання вашої команди (2-3 сесії)
  • Підтримка після запуску — 1 місяць

Строки та вартість

Тип рішення Строки (робочі тижні)
Custodial з базовим UI 4–8
Non-custodial з MPC-інтеграцією 8–16
EIP-4337 Account з paymaster 6–12
Institutional (HSM + MPC + compliance) від 16

Вартість розраховується індивідуально під ваш проект. Оцінимо за 1 день — зв'яжіться з нами. Надаємо гарантію на код та timeline.

Типові помилки при розробці криптогаманців (і як їх уникнути)

  • Використання застарілих MPC-бібліотек — GG18 без abort protocol. Обираємо CGGMP21 або tss-lib з актуальними audit report.
  • Жорстка прив'язка до одного блокчейну — не закладають абстракцію під L2/сайдчейни. Використовуємо viem/wagmi для кросс-чейн.
  • Ігнорування MEV-атак — при використанні мультисига без таймлоків. Додаємо tx simulation (Tenderly) та sandwitching protection.
  • Відсутність fallback-механізму відновлення — для Account Abstraction не налаштовують social recovery. Закладаємо з першого релізу.

Усуваємо ці граблі на етапі проектування — під кожен проект складаємо threat model та security checklist.

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