На складском комплексе с 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.
Что входит в работу?
В рамках проекта мы предоставляем:
- Документация: архитектурная схема, протокол верификации, схема токенов.
- Мобильное приложение (iOS/Android/Flutter) с источниками.
- Сервер верификации (REST API, веб-сокеты для реального времени).
- Интеграция с существующей СКУД (SDK, API).
- Нагрузочное тестирование: до 1000 одновременных запросов.
- Конфигурация MDM (Intune, Apple Configurator).
- Поддержка 3 месяца после релиза.
Как MDM защищает корпоративный пропуск?
MDM-система может удалённо стереть пропуск с устройства в случае компрометации или увольнения сотрудника. Используя Managed App Configuration, мы передаём ключи шифрования и endpoint'ы без жёсткой кодировки. Кроме того, MDM позволяет ограничить использование камеры и снимков экрана, что критично для приложений с конфиденциальными данными. Это сокращает риски утечки на 30% по статистике наших проектов.
Как внедрить TOTP в существующее приложение?
- Сгенерировать shared secret на сервере (128 бит, Base32).
- Передать секрет через защищённый канал (TLS + подпись).
- Реализовать на клиенте генерацию TOTP по RFC 6238 (30-секундное окно).
- Отображать QR с текущим кодом; при сканировании сервер проверяет подпись и окно.
Этапы проекта и сроки
| Этап | Длительность |
|---|---|
| Аудит существующей СКУД и её API | 1 неделя |
| Проектирование схемы токенов и протокола верификации | 1-2 недели |
| Разработка мобильного клиента и сервера верификации | 3-6 недель |
| Пилот на одной точке доступа | 1 неделя |
| Нагрузочный тест | 1 неделя |
| Rollout и обучение | 1 неделя |
Типовой путь занимает от 6 недель (QR/TOTP-пропуск без NFC, одна платформа) до 4 месяцев (BLE + NFC + Wallet + MDM + две платформы). Стоимость рассчитывается индивидуально после анализа требований к СКУД и инфраструктуре. Экономия на управлении доступом может достигать 40%.
Свяжитесь с нами для оценки объёма работ и сроков. Закажите демонстрацию работы пропуска на вашем оборудовании.