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 |
|---|---|---|
| Підтвердження на клієнті | Кожна транзакція | Тільки перша (enableSessionKey) |
| Час очікування | 5–10 сек | 1–2 сек (автопідпис) |
| Газ на транзакцію | Повний gas | UserOperation + Bundler (з Paymaster — 0) |
| Безпека | Максимальна | Висока (обмежені права) |
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, підписаний основним ключем (один раз, з біометрією).
Технічні деталі: генерація ключа на iOS/Android
На iOS використовуємо SecKeyCreateRandomKey з атрибутом kSecAttrKeyType: kSecAttrKeyTypeECSECPrimeRandom. На Android — KeyPairGenerator.getInstance("EC", "AndroidKeyStore") з параметром secp256r1. Приватний ключ не покидає Keychain/KeyStore.
Що відбудеться при компрометації сесійного ключа?
Зловмисник, отримавши приватний ключ сесії, зможе підписувати лише дозволені операції: наприклад, playRound з лімітом 0.01 ETH. Вивести основні кошти не вдасться. Користувач у будь-який момент може відкликати сесійний ключ через revokeSessionKey.
Зберігання та життєвий цикл на мобільному
Сесійний приватний ключ живе в Keychain з kSecAttrAccessibleWhenUnlockedThisDeviceOnly — біометрія не потрібна, оскільки ключ обмежений політикою. TTL сесії відображається користувачеві: «Сесія активна 45 хв з 60». Ручне відкликання — через revokeSessionKey UserOperation, підписаний основним ключем. При закритті застосунку ключ у пам'яті обнуляється, але в Keychain залишається до закінчення TTL або відкликання.
Порівняння з іншими підходами до автопідпису
| Підхід | Безпека | Гнучкість | Gas cost |
|---|---|---|---|
| Approve + permit | Середня (схвалення всіх транзакцій) | Низька | Високий (кожне схвалення) |
| Meta-transactions | Висока | Середня | Середній (релеєр) |
| Session Keys (ERC-7715) | Висока (обмежені права) | Висока | Низький (Paymaster) |
Session Keys виграють за всіма параметрами для застосунків з частими мікротранзакціями.
Як впровадити Session Keys: покрокова інструкція
- Створення смарт-акаунта на ERC-4337 (якщо відсутній)
- Генерація ephemeral keypair на пристрої (secp256k1, зберігається в Keychain/KeyStore)
- Формування UserOperation enableSessionKey з підписом основного ключа та біометрією
- Визначення політики дозволів: target, function, valueLimit, validUntil
- Інтеграція з Bundler (Pimlico/Stackup) та Paymaster (Pimlico Verifying Paymaster)
- Реалізація UI для відображення активних сесій, TTL та ручного відкликання
- Тестування та деплой
Що входить у роботу
- Розробка смарт-акаунта на 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 можуть прискорити застосунок.