Коротко — вариантов реализовать подпись в мобильном приложении несколько. Какой выбрать, зависит от требований (юридическая значимость подписи, где хранится приватный ключ, поддержка токенов/смарт‑карт, офлайн/онлайн, UX) и от того, какие продукты вы готовы использовать (например, официальные мобильные SDK от КриптоПро или сторонние УЦ). Ниже — подробный обзор подходов, преимущества/ограничения и практические рекомендации.
1) Вариант «официальный мобильный SDK / приложение поставщика (CryptoPro)»
- Многие поставщики ЭЦП (включая CryptoPro) имеют мобильные продукты/SDK, которые позволяют:
- хранить/использовать ключ в защищённом контейнере на устройстве (или работать с внешним токеном),
- выполнять подпись CMS/PAdES/PKCS#7/PKCS#1,
- запрашивать и верифицировать сертификаты, работать с timestamp (TSP).
- Как это может работать:
- ваше приложение вызывает SDK (или внешний нативный клиент) и отправляет ему документ/хеш для подписи,
- SDK запрашивает PIN/биометрию у пользователя,
- SDK возвращает подпись (CMS/PAdES),
- ваше приложение прикрепляет подпись к документу/отправляет на сервер.
- Плюсы: легальная совместимость (если SDK сертифицирован), UX: подпись прямо в приложении, безопасное хранение ключа.
- Минусы: лицензионные расходы, необходимость интеграции нативно (Android/iOS).
Рекомендация: если важна юридическая значимость в РФ и вы уже используете CryptoPro в вебе — уточните у поставщика мобильный SDK/решение и используйте его. Это максимально близко к нынешнему сценарию.
2) Вариант «внешнее приложение (deep link / Intent)»
- Идея: оставить подпись в отдельном нативном приложении (например, CryptoPro Mobile), а ваше приложение / PWA передаёт туда документ через Intent/URI, пользователь подписывает в отдельном приложении, результат возвращается через deep link или файл.
- Реализация:
- Android: Intent + FileProvider, возвращаем результат через activity result / custom URI.
- iOS: custom URL scheme / Universal Link / UIDocumentInteraction / share extension.
- Для PWA в обёртке (Cordova/Capacitor) этот вариант прост: вызвать нативный плагин/Intent.
- Плюсы: не нужно встраивать сложную крипто‑логику, можно переиспользовать готовое приложение.
- Минусы: переключение в другое приложение хуже UX, требуется наличие установленного приложения у пользователя.
3) Вариант «нативная реализация с хранением ключа в Keystore/TEEs»
- Храните приватный ключ в Android Keystore (hardware‑backed) или iOS Secure Enclave и подписывайте прямо из приложения (через API платформы).
- Для формирования типов подписей (CMS/PAdES) используйте библиотеки (BouncyCastle/SpongyCastle на Android, OpenSSL/third‑party на iOS), либо готовые SDK.
- Плюсы: лучший UX (все в одном приложении), можно использовать биометрическую аутентификацию.
- Минусы: как завести юридически значимый ключ на устройство (получение сертификата/выпуск) — сложнее; требования к уровню защиты для квалифицированной подписи могут не выполняться.
4) Вариант «удалённая подпись (cloud signing, HSM)»
- Приватный ключ хранится в HSM/на сервере УЦ. Клиент инициирует подпись, пользователь подтверждает действие (OTP, push‑уведомление, банковская авторизация).
- Подход часто используется для «удалённых квалифицированных подписей» (RSP/Remote Signing) при наличии соответствующих процедур УЦ.
- Плюсы: нет необходимости хранить ключи на устройстве, централизованное управление, масштабируемость.
- Минусы: требуется доверенный УЦ/HSM, нужно обеспечить надёжную аутентификацию и юридические требования.
5) Вариант «смарт‑карты / токены через OTG / NFC / Bluetooth»
- Если подписи на токенах/смарт‑картах у ваших пользователей — мобильное приложение может работать с токеном через USB‑OTG, NFC или Bluetooth (посредством нативных драйверов/SDK).
- Нужны драйверы/библиотеки от производителя токена/УЦ.
6) Для PWA (в браузере)
- WebCrypto API не даёт доступа к национальным сертификатам/токенам напрямую и не подходит для типичного сценария ЭЦП на мобильном браузере.
- Возможные пути:
- PWA вызывает внешний нативный компонент (через URL схемы, open with, или через обёртку Cordova/Capacitor).
- Использовать серверную подпись с подтверждением пользователем (push/OTP).
- В некоторых браузерах/платформах возможна интеграция через client certificates, но это редко покрывает ЭЦП в стиле КриптоПро.
Практические технические шаги (общий алгоритм подписи электронного документа)
1. Определите формат подписи: CMS/PKCS#7, XMLDSig, PAdES (для PDF) и т. д.
2. Получите/подготовьте сертификат пользователя (X.509) и цепочку.
3. Вычислите дайджест (hash) документа по соответствующим правилам (для PDF — специфические правила).
4. Передайте дайджест на подпись в крипто‑модуль (SDK/Keystore/внешнее приложение/HSM).
5. Получите подпись и упакуйте её в нужный формат (например, CMS Detached или PAdES).
6. Примерно всегда полезно добавить timestamptoken (RFC 3161) — для усиления юридической силы.
7. Проверяйте подпись на сервере/клиенте после получения.
Библиотеки и инструменты (общие)
- Java/Android: BouncyCastle для CMS, iText / PDFBox / Apache PDFBox + iText для PAdES.
- iOS: OpenSSL / Security.framework + сторонние библиотеки (для CMS).
- Универсально: использовать сертификатный сервер/УЦ и стандартные форматы CMS/PAdES.
- Для интеграции с CryptoPro — использовать их мобильный SDK/приложение (если есть), документацию у CryptoPro.
Вопросы, которые нужно прояснить перед выбором подхода
- Нужна ли вам квалифицированная подпись (КЭП) или простая ЭЦП достаточно?
- Где должен храниться приватный ключ (у пользователя на устройстве, на токене, в HSM на сервере)?
- Требуется ли поддержка имеющихся смарт‑карт/токенов пользователей?
- Должен ли пользователь подписывать прямо в приложении (без перехода в сторонние приложения)?
- Бюджет/лицензирование: готовы ли покупать мобильные SDK от поставщика?
Рекомендация для вашего случая (вы уже используете CryptoPro Browser Plugin)
- Спросите у CryptoPro про их мобильный эквивалент (CryptoPro Mobile/SDK). Это самый быстрый путь получить «аналогичный» опыт: подпись из приложения без выхода из системы и с сохранением юридической совместимости.
- Для PWA: делать «обёртку» (Cordova/Capacitor) и подключать нативный плагин, который вызывает CryptoPro Mobile или ваш серверный механизм подписи.
- Если не хотите зависеть от одного поставщика — рассмотрите модель «серверный HSM + подтверждение через мобильное приложение», но это дороже в плане сертификации и доверия.
Если хотите — могу:
- помочь подобрать конкретный архитектурный вариант с учётом ваших требований,
- составить список API/эндпойнтов и потоков (диаграмма) для выбранного варианта,
- подготовить примерную заготовку кода (Android Intent/плагин Cordova или пример подписи через BouncyCastle) — укажите, что предпочитаете (Android/iOS/PWA) и какие требования по юридической значимости.