Розробка мобільного додатка для зберігання документів (Digital Wallet)
Паспорт у телефоні — звучить просто, поки ти не зустрішся з користувачем на iOS 15 без Face ID, якому потрібно продемонструвати документ офлайн з криптографічним підтвердженням автентичності. Тут звичайний «файловий менеджер з гарним UI» перетворюється на невдалий продукт, а правильний Digital Wallet стає окремим інженерним проектом.
Основна інженерна проблема: де та як зберігати
Більшість перших версій таких додатків роблять те ж саме: зберігають PDF у Documents/ та шифрують AES-256. Це катастрофічно недостатньо. Проблема не в алгоритмі шифрування—це управління ключами.
Якщо ключ зберігається поряд з даними (навіть обгорнутий у SecKeyCreateRandomKey), дані можна відновити при джейлбрейку чи фізичному доступі до пристрою. Правильна схема: мастер-ключ створюється в Secure Enclave на iOS (kSecAttrTokenIDSecureEnclave) і ніколи не покидає чип. На Android аналог — Android Keystore з StrongBox на пристроях із виділеним HSM (Pixel 3+, Samsung з Knox). Документ шифрується похідним ключем через HKDF, похідний ключ шифрується мастер-ключем. Без біометрії або PIN ключ недоступний.
Другий болючий момент — резервні копії. За замовчуванням Documents/ на iOS потрапляє в iCloud Backup. Документи користувача відправляються в хмару без відома розробника. Рятує isExcludedFromBackup = true для каталогу сховища та явний атрибут NSURLIsExcludedFromBackupKey.
Верифікація автентичності документів при імпорті
Зберігання — половина справи. Користувачі очікують, що додаток усе ж таки зможе базово перевірити документ при завантаженні: чи не пошкоджений PDF, чи MRZ у паспорті збігається з візуальним вмістом, чи не закінчився термін дії документа.
Для розпізнавання MRZ використовуємо Vision framework на iOS (VNRecognizeTextRequest) або ML Kit Document Scanner на Android. OCR зони MRZ дає точність >98% на якісній фотографії. Для PDF — PDFKit на iOS, PdfRenderer на Android: перевіряємо цифровий підпис документа (PDFDocument.accessPermissions, ланцюг X.509 у вбудованому CMS).
Повна верифікація eIDAS/PAdES — окрема тема, але базова перевірка реалізується за 3-4 дні.
Структура сховища
WalletVault/
├── index.encrypted # CBOR-маніфест усіх документів (ID, тип, дата, хеш мініатюри)
├── docs/
│ ├── {uuid}.enc # Зашифрований документ (AES-GCM, 256-bit)
│ └── {uuid}.meta.enc # Метадані (ім'я, теги, термін дії)
└── keys/
└── vault.key.ref # Посилання на ключ у Keychain/Keystore (не сам ключ)
Маніфест-індекс дозволяє відображати список документів без розшифрування самих файлів—мініатюри зберігаються окремо, зменшені до 64×64 px.
Офлайн-демонстрація та верифікація третьою стороною
Сценарій «показати документ інспектору» потребує більше, ніж просто показати картинку. Для критичних випадків (посвідчення водія, корпоративний бейдж) реалізуємо ISO 18013-5 (mDL — mobile Driving Licence) поверх BLE/NFC: верифікатор запитує конкретні поля (лише ім'я та дату народження, без адреси), пристрій відповідає підписаним CBOR-об'єктом. Користувач бачить, які поля розкриваються—selective disclosure у дії.
Для менш критичних сценаріїв достатньо QR з підписаним JWT + короткий час життя (60 секунд).
Етапи роботи
Аудит вимог до типів документів та сценаріїв демонстрації → проектування схеми зберігання та управління ключами → розробка Vault-модуля → інтеграція OCR/MRZ-верифікації → UI для управління документами → security review → публікація.
Одна платформа з базовим сховищем: від 5 тижнів. Дві платформи з MRZ, офлайн-верифікацією за ISO 18013-5 та MDM-інтеграцією: 3–5 місяців. Вартість розраховується індивідуально після аналізу вимог.