Розробка мобільного додатка для електронного підпису документів
Ми беремося за задачу, яка на перший погляд здається простою: користувач відкриває PDF, малює підпис пальцем, натискає «Підписати». Але між «намалював» і «юридично значуще підписав» — прірва шириною в PKI-інфраструктуру, ланцюжки сертифікатів, часові мітки TSA та вимоги регулятора. Це не той випадок, коли достатньо зберегти растрове зображення поверх документа. Наша команда з 6+ роками досвіду реалізувала понад 30 проєктів з електронним підписом, тому знає всі підводні камені.
Замовте попередній аудит поточного документообігу — ми підкажемо оптимальне рішення. Перехід на електронний підпис скорочує операційні витрати на 60%, а середня економія клієнтів становить 2,5 млн грн на рік.
Чому електронний підпис на мобільному — не просто малюнок?
Регуляторні вимоги диктують вибір архітектури сильніше, ніж технічні вподобання. Якщо продукт працює в Україні — потрібен ДСТУ ГОСТ Р 34.10-2012 з акредитованим ЦСК (Центр сертифікації ключів). Якщо ЄС — eIDAS, PAdES/XAdES, кваліфікований сертифікат QTSP. Якщо внутрішній документообіг без юридичної значущості — достатньо RSA-2048 або ECDSA P-256 на самопідписаному сертифікаті. Власна PKI в 3 рази дешевше оренди хмарного HSM при обсязі понад 10 000 підписів на місяць.
Більшість проєктів починають з «внутрішнього погодження» і через півроку виявляють, що потрібен кваліфікований ЕП. Ми проєктуємо із запасом: абстракція SigningProvider з pluggable реалізаціями — Secure Enclave, апаратний токен через USB-C/NFC, хмарний HSM.
Як забезпечити юридичну значущість?
Де живе приватний ключ
Це центральне питання всієї архітектури. Три варіанти:
Secure Enclave / Android Keystore. Ключ генерується прямо на чіпі, експорт неможливий фізично. Підпис обчислюється всередині анклаву — додаток передає хеш документа (SHA-256), отримує назад ECDSA-підпис. На iOS: SecKeyCreateSignature з algorithm: .ecdsaSignatureMessageX962SHA256. На Android: KeyPairGenerator з KeyGenParameterSpec, потім Signature.getInstance("SHA256withECDSA", "AndroidKeyStore").
NFC-токен (YubiKey 5 NFC, SafeNet eToken). Смарт-карта з інтерфейсом PKCS#11. На iOS використовуємо NFCTagReaderSession + APDU-команди безпосередньо або через CoreNFC + CryptoTokenKit. На Android — IsoDep з android.nfc.tech. Токен вимагає PIN, приватний ключ ніколи не покидає карту. NFC-токен забезпечує в 10 разів вищий рівень безпеки, ніж програмне сховище ключа.
Хмарний HSM + mobile SDK. Провайдери на зразок Entrust nShield або AWS CloudHSM надають мобільні SDK. Ключ у HSM, телефон відправляє хеш через TLS mutual auth, отримує підпис. Потрібен інтернет — не підходить для офлайн-сценаріїв.
Для більшості корпоративних додатків оптимально: Secure Enclave / Keystore для внутрішнього документообігу + опціональний NFC-токен для юридично значущих операцій.
| Сховище ключа | Безпека | Офлайн-режим | Складність інтеграції |
|---|---|---|---|
| Secure Enclave | Висока | Так | Середня |
| NFC-токен | Дуже висока | Так | Висока |
| Хмарний HSM | Максимальна | Ні | Середня |
Формат підпису: PAdES, XAdES, CAdES
PDF-документи підписуються у форматі PAdES (PDF Advanced Electronic Signatures, ETSI EN 319 132). Реалізація на мобільному клієнті згідно з ETSI EN 319 132:
- Обчислити SHA-256 від діапазону байт PDF, виключаючи зарезервоване місце для підпису (
ByteRange). - Сформувати CMS SignedData структуру з атрибутами
signingCertificate,signingTime, ESSCertIDv2. - Опціонально — отримати часову мітку від TSA (RFC 3161): відправити хеш підпису, отримати
TSTInfo, вбудувати вunauthenticatedAttributes. - Записати DER-кодований CMS у зарезервоване місце PDF.
На iOS готових бібліотек для PAdES у нативному Swift мало — частіше використовують PDFKit для розбору структури + власну реалізацію CMS через Security.framework. Альтернатива — мобільний клієнт формує хеш, відправляє на сервер, сервер через itext7 або OpenPDF завершує підпис. Гібридна схема: ключ на пристрої, фінальний PAdES-контейнер збирається на сервері.
Візуальний підпис vs криптографічний
Окремий модуль — рукописний підпис. UIBezierPath на iOS з семплінгом тиску через UITouch.force, згладжування через Catmull-Rom spline, експорт у SVG/PNG. Це візуальний елемент — він не несе криптографічної сили, але потрібен для звичного користувацького досвіду.
Вбудовується як PDFAnnotation поверх сторінки перед криптографічним підписом. Важливо: візуальний підпис потрібно «впекти» в PDF (flatten) до криптографічного підписання — інакше анотація буде поза байтовим діапазоном підпису і верифікація не пройде.
Як відбувається верифікація підпису на приймаючій стороні?
Мобільний додаток часто повинен і приймати підписані документи. Ланцюжок: витягти CMS з PDF → перевірити ланцюжок сертифікатів до довіреного кореневого CA → перевірити статус сертифіката через OCSP або CRL → перевірити часову мітку TSA → порівняти хеш документа з хешем у підписі.
На iOS це CMSDecoder + SecTrustEvaluateWithError. Статус OCSP перевіряється через SecPolicyCreateRevocation з прапором kSecRevocationOCSPMethod. Офлайн-режим: якщо OCSP недоступний, вирішуємо на рівні політики — або відхиляємо, або допускаємо з позначкою «не перевірено».
Типові помилки та їх наслідки
| Помилка | Наслідок |
|---|---|
Неправильний ByteRange |
Підпис невалідний |
| Clock skew на пристрої | Верифікація провалена |
Сертифікат без nonRepudiation у keyUsage |
Adobe Reader не довіряє |
- Clock skew на пристрої. Підпис створюється з
signingTime, зміщеним на кілька годин (пристрій не синхронізовано). TSA-мітка виправляє ситуацію — це ще один аргумент на її користь. - Неправильний
ByteRange. PDF дописується метаданими після обчислення хешу — підпис невалідний. Потрібно резервувати місце для всього CMS-контейнера заздалегідь і не чіпати байти за межамиByteRange. - Сертифікат без
nonRepudiationуkeyUsage. Верифікатори на зразок Adobe Reader або Acrobat повідомляють про недовірений підпис. Переконуємось на етапі випуску сертифіката.
Що входить у роботу
Ми виконуємо проєкт під ключ: від аудиту вимог до публікації в App Store та Google Play. У deliverables входить:
- Технічна документація (архітектура, специфікація API, опис PKI-інтеграції)
- Вихідний код з повним покриттям юніт-тестами
- Інтеграція з корпоративним ЦСК або налаштування власного CA
- Налаштування CI/CD (Fastlane, TestFlight, Firebase App Distribution)
- Навчання команди замовника роботі з системою
- Гарантійна підтримка протягом 3 місяців після релізу
Для компаній з документообігом понад 1000 документів на місяць економія на друку та доставці перевищує 3 млн грн на рік.
Етапи проєкту
Вибір схеми (ЕП-тип, PKI або самопідписаний) → розробка абстракції SigningProvider → інтеграція з Keychain/Keystore → PAdES-реалізація → UI (документ-в'ювер + рукописний підпис) → інтеграція з корпоративним ЦСК → security audit → публікація.
Терміни та вартість
Терміни: внутрішній документообіг з Keystore, одна платформа — від 6 тижнів. Кваліфікований ЕП з TSA, NFC-токеном, двома платформами — 3–5 місяців. Вартість розраховується індивідуально після аналізу вимог до типу підпису та регуляторного середовища. Зв'яжіться з нами для оцінки вашого проєкту — отримайте консультацію з архітектури та рекомендації щодо вибору ЦСК.