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

Розробка нативного криптогаманця для 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.

Як захистити гаманець від 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: додати логотип мережі та назву в список вибору.

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

Наш метод 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 місяців.

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