Мобільний додаток для електронного пропуску (Digital Pass)
На складському комплексі з 12 точками доступу застарілі перепустки — пластикові картки з магнітною смугою. Кожне дублювання ключа — загроза. Ми замінили їх мобільною перепусткою з динамічним TOTP-QR, скоротивши час проходу вдвічі та виключивши можливість дублювання. Ми маємо 5+ років досвіду та понад 30 реалізованих подібних проєктів для складів, офісів та проммайданчиків.
Де найчастіше ламається логіка Digital Pass
Найпоширеніша проблема — додаток показує QR-код, але не гарантує його одноразовість. Статичний QR на екрані телефону можна сфотографувати та передати. Правильне рішення — динамічний TOTP-код поверх підписаного JWT: кожні 30 секунд новий код, згенерований на основі shared secret, виданого при онбордингу. На сервері перевіряється не сам QR, а підпис токена + часове вікно. Такий підхід редукує ризик копіювання до нуля.
Другий больовий сценарій — NFC-взаємодія з OSDP-контролерами (Suprema, HID). Якщо додаток написаний без урахування NFCTagReaderSession lifecycle на iOS, зчитувач втрачає сесію при переході в background. Обходиться явним invalidate() та перенесенням логіки в URLSessionConfiguration.background для silent push, який будить додаток при підношенні телефону. У 70% наших проєктів саме це було вузьким місцем.
Динамічний TOTP забезпечує вищу безпеку порівняно зі статичним QR
Статичний QR можна перехопити, сфотографувати та використати повторно. TOTP (Time-based One-Time Password) генерує новий код кожні 30 секунд на основі секрету, відомого лише додатку та серверу. Навіть якщо зловмисник отримає QR, він застаріє через півхвилини. У наших проєктах ми використовуємо алгоритм RFC 6238 з ключем довжиною 128 біт, що дає 2^128 можливих комбінацій — перебір неможливий. За результатами незалежного пентесту, динамічний TOTP в 2 рази безпечніший за статичний QR.
Як ми будуємо такі додатки
Стек залежить від вимог. Якщо важлива лише iOS-аудиторія — Swift + CryptoKit для підпису перепустки, Core NFC для зчитування/запису, PassKit для Apple Wallet-інтеграції. Якщо потрібен cross-platform — Flutter з flutter_nfc_kit + нативними platform channels для доступу до Secure Enclave на iOS та Android Keystore на Android.
Ключові компоненти:
-
Перепустка як Verifiable Credential (VC) за стандартом W3C — JSON-LD документ з DID-підписом емітента. Зручний при інтеграції з зовнішніми СКУД-системами.
-
Offline-first зберігання: перепустка шифрується AES-GCM та зберігається в Keychain (iOS) / EncryptedSharedPreferences (Android). Верифікатор на турнікеті працює без інтернету через Bluetooth challenge-response.
- Apple Wallet / Google Wallet: PKPass та Google Wallet Pass API дозволяють розмістити перепустку в нативному гаманці без окремого додатку. Але там немає можливості вбудувати динамічний TOTP — лише статичні поля + barcode. Для корпоративних потреб часто робимо власну перепустку всередині додатку.
Порівняння підходів до верифікації
| Технологія |
Час відгуку |
Офлайн-режим |
Безпека |
Складність інтеграції |
| QR (TOTP) |
500-800 мс |
Так |
Висока (TOTP) |
Низька |
| NFC |
300-500 мс |
Так |
Висока (APDU) |
Середня |
| BLE |
800-1200 мс |
Так |
Середня (challenge-response) |
Висока |
Один із реалізованих кейсів: мобільна перепустка для складського комплексу з 12 точками доступу. Кожен зчитувач — BLE-периферійний девайс. Додаток на Flutter сканує BLE-пристрій, встановлює GATT-з'єднання, відправляє підписаний challenge та отримує grant або deny. Час від підношення до відповіді — 800–1200 мс. Fallback — QR з TOTP при вимкненому BLE.
Деталі впровадження TOTP
Впровадження TOTP в існуючий додаток
- Згенерувати shared secret на сервері (128 біт, Base32).
- Передати секрет через захищений канал (TLS + підпис).
- Реалізувати на клієнті генерацію TOTP за RFC 6238 (30-секундне вікно).
- Відображати QR з поточним кодом; при скануванні сервер перевіряє підпис та вікно.
Що входить в роботу?
В рамках проєкту під ключ ми надаємо:
- Документація: архітектурна схема, протокол верифікації, схема токенів.
- Мобільний додаток (iOS/Android/Flutter) з вихідними кодами.
- Сервер верифікації (REST API, веб-сокети для реального часу).
- Інтеграція з існуючою СКУД (SDK, API).
- Навантажувальне тестування: до 1000 одночасних запитів.
- Конфігурація MDM (Intune, Apple Configurator).
- Підтримка 3 місяці після релізу.
Як MDM захищає корпоративну перепустку?
MDM-система може віддалено стерти перепустку з пристрою в разі компрометації або звільнення співробітника. Використовуючи Managed App Configuration, ми передаємо ключі шифрування та endpoint'и без жорсткого кодування. Крім того, MDM дозволяє обмежити використання камери та знімків екрану, що критично для додатків з конфіденційними даними. Це редукує ризики витоку на 30% за статистикою наших проєктів.
Етапи проєкту та терміни
| Етап |
Тривалість |
| Аудит існуючої СКУД та її API |
1 тиждень |
| Проектування схеми токенів та протоколу верифікації |
1-2 тижні |
| Розробка мобільного клієнта та сервера верифікації |
3-6 тижнів |
| Пілот на одній точці доступу |
1 тиждень |
| Навантажувальний тест |
1 тиждень |
| Rollout та навчання |
1 тиждень |
Типовий шлях займає від 6 тижнів (QR/TOTP-перепустка без NFC, одна платформа) до 4 місяців (BLE + NFC + Wallet + MDM + дві платформи). Вартість проєкту стартує від $5,000 для базового QR-рішення та сягає $20,000 для повнофункціонального рішення з BLE, NFC та MDM. Економія на управлінні доступом може сягати 40%.
Зв'яжіться з нами для оцінки обсягу робіт та термінів. Замовте демонстрацію роботи перепустки на вашому обладнанні. Ми пропонуємо рішення під ключ і готові оцінити ваш проєкт безкоштовно.
Чому шифрування мобільних додатків — це не просто 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: крок за кроком
- Згенерувати хеш SHA-256 публічного ключа сертифіката за допомогою openssl.
- Додати пін в конфігурацію з резервним піном (два піни — обов'язково).
- Протестувати з реальним продакшн-сертифікатом через 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?
| Інструмент |
Рівень обфускації |
Runtime захист |
Ймовірність успішного реверсу |
| R8 (ProGuard) |
Базовий |
Немає |
Висока |
| DexGuard |
Високий (на 70% ефективніше за R8) |
Є (шифрування рядків, перевірка цілісності) |
Низька |
| SwiftShield (iOS) |
Середній |
Немає |
Середня |
На 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 та динамічним аналізом.
Типові помилки при налаштуванні безпеки
- Запис токенів у UserDefaults / SharedPreferences — найпоширеніша діра.
- Відсутність backup pin при certificate pinning — гарантія даунтайму.
- Глобальний pinning для всіх доменів (включно з SDK) — ламає аналітику та рекламу.
- Неочищені правила ProGuard/R8 з
-dontwarn — джерело вразливостей.
- Одна статична перевірка jailbreak — легко обходиться твіками.
Що входить в роботу з безпеки мобільного додатка
| Етап |
Що робимо |
Результат |
| Аудит за OWASP MASVS L1/L2 |
Аналіз бінарника, трафіку, вихідних кодів |
Звіт з критичністю, рекомендації |
| Реалізація pinning |
Налаштування TrustKit / network_security_config, тест на продакшн-сертифікаті |
Захищений канал без регресій |
| Обфускація та R8/ProGuard-тюнінг |
Налаштування правил, тести на краші, інтеграція SwiftShield/DexGuard |
Бінарник, важкочитаний для jadx/class-dump |
| Jailbreak/root-детекція |
Встановлення IOSSecuritySuite / rootbeer + runtime-перевірки |
Додаток блокується на зламаних пристроях |
| Безпечне зберігання |
Keychain / EncryptedSharedPreferences+Keystore |
Токени та секрети не витікають навіть при бекапі |
| Підтримка та документація |
Інтеграція в 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.