Мобільний додаток для електронного пропуску (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%.
Зв'яжіться з нами для оцінки обсягу робіт та термінів. Замовте демонстрацію роботи перепустки на вашому обладнанні. Ми пропонуємо рішення під ключ і готові оцінити ваш проєкт безкоштовно.