Розробка Digital Wallet: мобільний застосунок для зберігання документів
Зауважте: коли клієнт приходить із пристроєм без біометрії та вимагає офлайн-верифікацію документа з криптографічним підтвердженням, стандартний «файловий менеджер з гарним UI» терпить крах. Правильний цифровий гаманець документів — це окремий інжиніринг: апаратне шифрування ключів, MRZ-парсинг, selective disclosure за ISO 18013-5. Наш досвід у мобільній розробці — 8+ років, понад 15 проєктів Digital Wallet. Ми гарантуємо повну підтримку після запуску та допомогу з публікацією в App Store і Google Play.
Головна інженерна проблема: де і як зберігати
Більшість перших версій таких застосунків зберігають PDF у Documents/ і шифрують AES-256. Цього катастрофічно мало. Проблема не в алгоритмі шифрування — проблема в управлінні ключами. Якщо ключ зберігається поруч із даними (навіть обгорнутий у SecKeyCreateRandomKey), при джейлбрейку дані відновлюються. Правильна схема: майстер-ключ створюється в Secure Enclave на iOS (kSecAttrTokenIDSecureEnclave), він ніколи не покидає чип (Apple Developer Documentation: Secure Enclave). На Android аналог — Android Keystore з StrongBox на пристроях із виділеним HSM (Pixel 3+, Samsung із Knox). Документ шифрується похідним ключем через HKDF, похідний ключ — майстер-ключем. Без біометрії або PIN ключ недоступний.
Другий больовий момент — резервні копії. За замовчуванням Documents/ на iOS потрапляє в iCloud Backup. Документи користувача вилітають у хмару без відома розробника. Рятує isExcludedFromBackup = true для директорії сховища та явний атрибут NSURLIsExcludedFromBackupKey.
Чому Secure Enclave важливіший за алгоритм шифрування?
Зберігання ключів у Secure Enclave в 100 разів надійніше, ніж у UserDefaults, і повністю виключає вилучення при джейлбрейку. Порівняйте підходи в таблиці нижче.
| Параметр | Secure Enclave (iOS) | Android Keystore (StrongBox) | Файл із паролем |
|---|---|---|---|
| Безпека | Абсолютна (апаратна ізоляція) | Висока (апаратна, якщо StrongBox) | Низька (залежить від пароля та файлової системи) |
| Продуктивність | ~10 мс на операцію | ~15 мс на операцію | Швидко (в пам'яті) |
| Сумісність | iOS 9+ | Android 6+ (StrongBox — Android 9+ з HSM) | Будь-яка платформа |
| Офлайн доступ | Повний | Повний | Повний |
Верифікація справжності документів при імпорті
Користувачі очікують, що застосунок хоча б базово перевіряє документ під час завантаження: чи не пошкоджений PDF, чи збігається MRZ у паспорті з візуальним вмістом, чи не прострочений документ. Для MRZ-парсингу використовуємо Vision framework на iOS (VNRecognizeTextRequest) або ML Kit Document Scanner на Android. OCR зони MRZ дає точність >98% на якісній фотографії. Для PDF — PDFKit на iOS, PdfRenderer на Android: перевіряємо цифровий підпис документа (PDFDocument.accessPermissions, X.509 chain у вбудованому CMS). Повний ланцюг верифікації eIDAS/PAdES — окрема тема, але базову перевірку вбудувати реально за 3-4 дні.
Як працює офлайн-верифікація за ISO 18013-5?
Сценарій «показати документ інспектору» вимагає більше, ніж просто показати картинку. Для серйозних кейсів (транспортне посвідчення, корпоративний бейдж) реалізуємо ISO 18013-5 (mDL — mobile Driving Licence) поверх BLE/NFC: верифікатор запитує конкретні поля (тільки ім'я та дату народження, без адреси), пристрій відповідає підписаним CBOR-об'єктом. Користувач бачить, які поля розкриваються — selective disclosure у дії. Для менш критичних сценаріїв достатньо QR із підписаним JWT + короткий термін життя (TTL 60 секунд).
Порівняння методів верифікації документів
| Метод | Точність | Час перевірки | Вимоги до пристрою |
|---|---|---|---|
| MRZ OCR | >98% | ~1-2 секунди | Камера з автофокусом |
| ISO 18013-5 (NFC) | Абсолютна (криптографічна) | ~3-5 секунд | NFC-чип на пристрої та документі |
| QR-код із JWT | ~99% (передбачає довірений емітент) | ~0.5 секунди | Екран пристрою |
Етапи роботи
- Аудит вимог до типів документів і сценаріїв пред'явлення.
- Проектування схеми зберігання та управління ключами.
- Розробка Vault-модуля.
- Інтеграція OCR/MRZ-верифікації.
- UI для управління документами.
- Security review.
- Публікація в магазинах застосунків.
Строки: одна платформа з базовим сховищем — від 5 тижнів. Дві платформи з MRZ, офлайн-верифікацією за ISO 18013-5 та MDM-інтеграцією — 3–5 місяців. Вартість розраховується індивідуально після аналізу вимог. Наприклад, реалізація базового mDL-модуля починається від 1 200 000 рублів, а комплексне рішення для корпоративного сегменту — від 2 до 5 мільйонів рублів. Інтеграція власної системи зберігання окупається за 6–8 місяців, економлячи до $15,000 щорічно.
Що входить у результат роботи
- Детальна документація з архітектури та ключових модулів.
- Вихідний код із коментарями на Swift/Kotlin/Flutter.
- Інтеграція з CI/CD для автоматичної збірки та публікації.
- Підтримка на етапі модерації в магазинах застосунків.
- Навчання команди замовника роботі з системою зберігання ключів.
Типові помилки при реалізації Digital Wallet
- Зберігання ключів у UserDefaults або SharedPreferences.
- Відсутність перевірки терміну дії документа при додаванні.
- Ігнорування атрибута
isExcludedFromBackup. - Синхронізація через сторонні хмарні сервіси без наскрізного шифрування.
Щоб дізнатися, як адаптувати рішення під ваш сценарій, отримайте консультацію інженера. Ми оцінимо проєкт за 1–2 дні та запропонуємо оптимальне рішення. Для замовлення проєкту залиште заявку на нашому сайті.