Session Keys для мобільного крипто застосунку: автопідпис з обмеженнями

Session Keys в мобільному криптозастосунку: автопідпис без компромісів

Ви запустили гру на блокчейні або DeFi-застосунок. Користувачі скаржаться: кожна дія вимагає біометрії. Конверсія падає. Частина аудиторії йде. Рішення — Session Keys за стандартом ERC-4337. Ми впроваджували їх у 10+ проєктах з Account Abstraction. Середній час підпису скоротився з 5 до 1 секунди, а витрати на газ — до 70%.

Згідно з Account Abstraction (ERC-4337), session keys — тимчасові криптографічні ключі з обмеженими правами. Вони автопідписують транзакції без повторного підтвердження основним ключем. Політика дозволів задає ліміти: цільовий контракт, функція, максимальна сума. Навіть при витоку сесійного ключа зловмисник не виведе всі кошти — тільки те, що дозволено політикою. Ми пропонуємо впровадження Session Keys у ваш мобільний застосунок з нуля або поверх існуючого смарт-акаунта. Оцінимо проєкт за один робочий день, типовий термін реалізації — від 3 до 5 днів.

Як Session Keys скорочують витрати на газ?

Порівняйте стандартний підпис та Session Keys:

Session Keys у 3–5 разів швидші. З Paymaster користувач не платить газ взагалі, витрати знижуються до 70%.

Політика дозволів: ключ до безпеки

Політика дозволів — контракт, що перевіряє кожну UserOperation. Він фіксує цільовий контракт, функцію та ліміт суми. Без неї сесійний ключ став би повним аналогом основного. З нею навіть при компрометації сесійного ключа зловмисник не виведе кошти за межі політики.

Архітектура: ERC-4337 + EIP-7715

Session Keys реалізуються на рівні смарт-акаунта (Account Abstraction). Мобільний застосунок надсилає userop замість прямих транзакцій. Стек:

• permissionless.js або @zerodev/sdk для створення смарт-акаунта
• @zerodev/session-key для керування сесіями
• Bundler (Pimlico, Stackup) для відправлення UserOperation

Сесійний ключ — ephemeral keypair (secp256k1), згенерований на пристрої. Приватна частина зберігається в Keychain/KeyStore. Публічний ключ та політика дозволів реєструються через enableSessionKey, підписаний основним ключем (один раз, з біометрією).

Що відбудеться при компрометації сесійного ключа?

Зловмисник, отримавши приватний ключ сесії, зможе підписувати лише дозволені операції: наприклад, playRound з лімітом 0.01 ETH. Вивести основні кошти не вдасться. Користувач у будь-який момент може відкликати сесійний ключ через revokeSessionKey.

Зберігання та життєвий цикл на мобільному

Сесійний приватний ключ живе в Keychain з kSecAttrAccessibleWhenUnlockedThisDeviceOnly — біометрія не потрібна, оскільки ключ обмежений політикою. TTL сесії відображається користувачеві: «Сесія активна 45 хв з 60». Ручне відкликання — через revokeSessionKey UserOperation, підписаний основним ключем. При закритті застосунку ключ у пам'яті обнуляється, але в Keychain залишається до закінчення TTL або відкликання.

Порівняння з іншими підходами до автопідпису

Session Keys виграють за всіма параметрами для застосунків з частими мікротранзакціями.

Як впровадити Session Keys: покрокова інструкція

1. Створення смарт-акаунта на ERC-4337 (якщо відсутній)
2. Генерація ephemeral keypair на пристрої (secp256k1, зберігається в Keychain/KeyStore)
3. Формування UserOperation enableSessionKey з підписом основного ключа та біометрією
4. Визначення політики дозволів: target, function, valueLimit, validUntil
5. Інтеграція з Bundler (Pimlico/Stackup) та Paymaster (Pimlico Verifying Paymaster)
6. Реалізація UI для відображення активних сесій, TTL та ручного відкликання
7. Тестування та деплой

Що входить у роботу

• Розробка смарт-акаунта на ERC-4337 (якщо відсутній)
• Створення session keypair (secp256k1) на пристрої
• Політика дозволів з target, valueLimit, validUntil
• Інтеграція з Bundler (Pimlico/Stackup)
• Підключення Paymaster (Pimlico Verifying Paymaster / Biconomy)
• UI керування сесіями (відображення TTL, ручне відкликання)
• Документація API та приклади коду
• Навчання команди замовника

Що потрібно врахувати

Bundler fees: UserOperation через Bundler коштує газ. Для сесій з частими транзакціями використовуємо Paymaster — смарт-контракт, що оплачує газ за користувача. Інтеграція з Pimlico Verifying Paymaster або Biconomy — стандартне завдання.

Не можна створити сесійний ключ без інтернету — потрібно надіслати enableSessionKey у мережу. Кешуємо sessionKeyData локально та дозволяємо використовувати до закінчення TTL без повторного запиту.

Терміни — від 3 до 5 робочих днів: ERC-4337 смарт-акаунт (якщо немає), сесійний keypair, політика дозволів, інтеграція з Bundler/Paymaster, UI керування сесією. Якщо смарт-акаунт вже є — від 2 до 3 днів.

Зв'яжіться з нами для консультації — ми гарантуємо безпеку та надійність рішення. Замовте технічний аудит вашого проєкту, щоб зрозуміти, як Session Keys можуть прискорити застосунок.

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