Розробка мобільного додатку для електронного підпису документів

Розробка мобільного додатка для електронного підпису документів

На перший погляд завдання прозоре: користувач відкриває PDF, малює підпис пальцем, натискає «Підписати». На практиці між «намалював» та «юридично значимо підписав» — прірва завширшки PKI-інфраструктури, ланцюги сертифікатів, часові мітки TSA та вимоги регулятора. Це не той випадок, коли достатньо зберегти растрове зображення поверх документа.

Кваліфікована vs звичайна електронна підпис

Регуляторні вимоги диктують вибір архітектури набагато сильніше, ніж технічні переваги. Якщо продукт працює в РФ—потрібен GOST Р 34.10-2012 з акредитованим УЦ. Якщо в ЄС — eIDAS, PAdES/XAdES, кваліфікований сертифікат QTSP. Якщо внутрішній документообіг без юридичної значимості—достатньо RSA-2048 або ECDSA P-256 на self-signed сертифікаті.

Більшість проектів починають із «внутрішнього узгодження» і через півроку виявляють, що потрібна кваліфікована ЕП. Краще проектувати з запасом: абстракція SigningProvider із підключаємими реалізаціями—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, приватний ключ ніколи не покидає карту.

Хмарний HSM + mobile SDK. Провайдери вроде Entrust nShield або AWS CloudHSM пропонують мобільні SDK. Ключ в HSM, телефон відправляє хеш через TLS mutual auth, отримує підпис. Потребує інтернету—невідповідно для офлайн-сценаріїв.

Для більшості корпоративних додатків оптимально: Secure Enclave / Keystore для внутрішнього документообігу + опціональний NFC-токен для юридично значимих операцій.

Формат підпису: PAdES, XAdES, CAdES

PDF-документи підписуються у форматі PAdES (PDF Advanced Electronic Signatures, ETSI EN 319 132). Реалізація на мобільному клієнті:

1. Обчислити SHA-256 від діапазону байт PDF, виключаючи зарезервоване місце для підпису (ByteRange).
2. Сформувати CMS SignedData структуру з атрибутами signingCertificate, signingTime, ESSCertIDv2.
3. Опціонально—отримати часову мітку від TSA (RFC 3161): відправити хеш підпису, отримати TSTInfo, вбудувати у unauthenticatedAttributes.
4. Записати 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 недоступний, рішення на рівні політики—або відклонити, або дозволити з позначкою «не перевірено».

Типові помилки при реалізації

Трійка найбільш болючих граблей:

• Clock skew на пристрої. Підпис створюється з signingTime, зміщеним на кілька годин (пристрій не синхронізований). TSA-мітка виправляє ситуацію—ще один аргумент на користь її застосування.
• Неправильний ByteRange. PDF дописується метаданими після обчислення хеша—підпис невалідний. Потрібно резервувати місце для всього CMS-контейнера заздалегідь і не чіпати байти за межами ByteRange.
• Сертифікат без nonRepudiation у keyUsage. Верифікатори вроде Adobe Reader або Acrobat повідомляють про недовірену підпис. Переконаємося при виданні сертифіката.

Етапи проекту

Вибір схеми (тип ЕП, PKI чи self-signed) → розробка абстракції SigningProvider → інтеграція з Keychain/Keystore → PAdES-реалізація → UI (програвач документів + рукописна підпис) → інтеграція з корпоративним УЦ → security audit → публікація.

Терміни: внутрішній документообіг з Keystore, одна платформа—від 6 тижнів. Кваліфікована ЕП з TSA, NFC-токеном, двома платформами—3–5 місяців. Вартість розраховується індивідуально після аналізу вимог до типу підпису та регуляторного середовища.