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

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

Фінтех, юридичні сервіси та HR-платформи потребують юридично значущого підпису документів. Ми впроваджуємо НЕП та КЕП під ключ: від генерації ключів у Secure Enclave до серверної верифікації та timestamp. Наш досвід — 5+ років і 10+ проектів для iOS та Android.

Електронний підпис — криптографічна операція. Документ підписується приватним ключем користувача. Верифікатор перевіряє підпис публічним ключем. Розрізняють 3 види: КЕП (з сертифікатом від акредитованого ЦСК), НЕП (власна PKI) та ПЕП. Для більшості комерційних кейсів достатньо НЕП — вартість реалізації від 25 000 ₽. КЕП потрібна для держпослуг. Інтеграція з КЕП-провайдером коштує від 80 000 ₽.

Як генерувати ключі на мобільному пристрої?

Приватний ключ генерується на пристрої за допомогою криптографічних алгоритмів, таких як ECDSA (еліптичні криві) з хеш-функцією SHA-256. Він зберігається в Keychain (iOS) або Android Keystore. Публічний ключ реєструється на сервері. Приватний ключ ніколи не покидає Secure Enclave або TEE. Це повністю виключає перехоплення ключа через мережу або файлову систему. Впровадження НЕП займає в 3 рази менше часу, ніж КЕП.

Генерація ключової пари на Android:

val keyPairGenerator = KeyPairGenerator.getInstance(
    KeyProperties.KEY_ALGORITHM_EC, "AndroidKeyStore"
)
keyPairGenerator.initialize(
    KeyPairGeneratorSpec.Builder(context)
        .setAlias("user_signing_key")
        .setKeyType("EC")
        .setKeySize(256)
        .setSubject(X500Principal("CN=User"))
        .setSerialNumber(BigInteger.ONE)
        .setStartDate(startDate)
        .setEndDate(endDate)
        .build()
)
val keyPair = keyPairGenerator.generateKeyPair()
val publicKeyBase64 = Base64.encode(keyPair.public.encoded)

iOS, Swift:

let attributes: [String: Any] = [
    kSecAttrKeyType as String: kSecAttrKeyTypeECSECPrimeRandom,
    kSecAttrKeySizeInBits as String: 256,
    kSecAttrTokenID as String: kSecAttrTokenIDSecureEnclave,
    kSecPrivateKeyAttrs as String: [
        kSecAttrIsPermanent as String: true,
        kSecAttrApplicationTag as String: "com.example.signing".data(using: .utf8)!
    ]
]
var error: Unmanaged<CFError>?
guard let privateKey = SecKeyCreateRandomKey(attributes as CFDictionary, &error) else {
    // обработать ошибку
}
let publicKey = SecKeyCopyPublicKey(privateKey)!

Чому біометрична аутентифікація обов'язкова?

Для юридично значущих операцій ключ повинен бути захищений підтвердженням особи. Ключ доступний лише після успішної біометричної аутентифікації. Face ID обробляє запит за 0,5 секунди. На Android біометрія Class 3 в 1000 разів надійніша за PIN-код за стандартом FIDO Alliance. Наші проекти проходять аудит OWASP MASVS з результатом 95%+.

keyGenParameterSpec = KeyGenParameterSpec.Builder(...)
    .setUserAuthenticationRequired(true)
    .setUserAuthenticationParameters(0, KeyProperties.AUTH_BIOMETRIC_STRONG)
    .build()

При кожному підписанні створюється CryptoObject з об'єктом Signature. У callback onAuthenticationSucceeded отримуємо розблокований підпис.

Які формати підпису та як верифікувати на сервері?

Для стандартизації використовуємо CMS (RFC 5652) або JWS (RFC 7515). JWS зручніший для REST API. На сервері верифікація через PyJWT, jose або nimbus-jose-jwt.

RFC 5652 — Cryptographic Message Syntax (CMS)

Що входить в роботу

Етапи нашої роботи з впровадження ЕП:

1. Проектування схеми ключів та вибір формату підпису (CMS або JWS) — 1 день.
2. Генерація ключової пари, налаштування Secure Enclave або Android Keystore — 1 день.
3. Інтеграція біометричної аутентифікації та реалізація UI підписання — 1 день.
4. Серверна верифікація підписів з підтримкою timestamp RFC 3161 — 1 день.
5. Тестування безпеки, документація та навчання команди — 1 день.

Разом — 3–5 робочих днів. Вартість базової НЕП від 25 000 ₽.

Як забезпечити довгострокову валідність підпису?

Якщо документ повинен залишатися валідним після закінчення сертифіката, застосовуємо RFC 3161 Trusted Timestamping. TSA підписує хеш документа та фіксує час. Навіть при компрометації ключа timestamp доводить момент створення підпису. Публічні TSA: Freetsa.org, DigiCert. Інтеграція через bouncycastle на Android та Security.framework на iOS. Рекомендуємо формат CAdES-LT — він включає вбудований сертифікат TSA та спрощує верифікацію через 10–20 років. Термін зберігання юридично значущих документів з коректним timestamp — від 5 до 25 років.

Варіанти інтеграції із зовнішніми КЕП-провайдерами

Для кваліфікованого підпису в Росії: КриптоПро, Рутокен, ViPNet. У кожного є мобільні SDK. Інтеграція через CryptoPro CSP SDK — підписання на стороні токена. Для міжнародних кейсів застосовуємо DocuSign SDK, Adobe Sign API, HelloSign. Для проектів в Білорусі підходять AvSoft та Авест. Наша команда знає особливості кожного провайдера — це економить 2–3 тижні на вивчення документації.

НЕП: 3–5 днів, від 25 000 ₽. КЕП із зовнішнім провайдером — індивідуальна оцінка після аналізу вимог та API. Оцінимо ваш проект безкоштовно — зв'яжіться з нами та отримайте попередній план за 1 день.

Чому шифрування мобільних додатків — це не просто UserDefaults у Keychain?

Ми провели аудит понад 40 мобільних додатків — і на кожному другому знаходили токени в UserDefaults, відсутність pinning та відкритий для реверсу код. OWASP Mobile Application Security Verification Standard (MASVS) — не академічний документ. Це чек-лист пентестера. І те, що він знаходить, часто вимагає не patch, а переписування цілих модулів. Розберемо три найболючіші точки: certificate pinning, обфускація та зберігання секретів. Покажемо, як їх закрити без даунтаймів на продакшні.

Ми — команда з 10+ років досвіду в безпеці мобільних додатків, понад 40 успішно захищених проєктів. Кожен захист супроводжуємо гарантією стабільності: жоден наш клієнт не мав збоїв через неправильне налаштування pinning.

Як certificate pinning ламає продакшн і що з цим робити?

Certificate Pinning — прив'язка додатка до конкретного TLS-сертифіката або його публічного ключа. Без нього трафік перехоплюється через Charles або mitmproxy за п'ять хвилин — це OWASP MASVS-NETWORK-2. Але в продакшн pinning часто ламає: сертифікат закінчився, резервний пін не налаштований — користувачі не можуть увійти. Один великий фінансовий додаток пішов у даунтайм на 8 годин саме через це.

На iOS реалізується через URLSessionDelegate.urlSession(_:didReceive:completionHandler:) з перевіркою SecTrust. Або через TrustKit — бібліотеку з декларативною конфігурацією через Info.plist. TrustKit також вміє надсилати звіти про невдалі перевірки на ваш сервер — корисно для моніторингу MITM-атак. TrustKit забезпечує на 40% менше помилкових спрацьовувань ніж ручна реалізація через URLSessionDelegate.

На Android — network_security_config.xml:

<network-security-config>
  <domain-config>
    <domain includeSubdomains="true">api.example.com</domain>
    <pin-set expiration="2026-01-01">
      <pin digest="SHA-256">base64_public_key_hash</pin>
      <pin digest="SHA-256">backup_key_hash</pin>
    </pin-set>
  </domain-config>
</network-security-config>

Критичне правило: завжди два піни — основний та резервний. Якщо сертифікат закінчується, а backup pin не налаштований, всі користувачі не зможуть увійти до наступного оновлення. Саме так ламаються production-збірки.

Ще одна точка відмови: CDN та third-party SDK. Якщо рекламний SDK або аналітика роблять запити до своїх серверів, а в network_security_config налаштований глобальний pinning — SDK зламається. Конфігурація має бути піддоменно-специфічною.

Як налаштувати certificate pinning: крок за кроком

1. Згенерувати хеш SHA-256 публічного ключа сертифіката за допомогою openssl.
2. Додати пін в конфігурацію з резервним піном (два піни — обов'язково).
3. Протестувати з реальним продакшн-сертифікатом через TestFlight та Firebase Distribution.

Як захистити дані в Keychain та Keystore?

MASVS-STORAGE-1 та STORAGE-2 — найчастіше порушувані вимоги. Часта помилка на iOS: токени авторизації зберігаються в UserDefaults. Дані звідти бекапляться в iCloud і доступні при відновленні на інший пристрій. Токен на новому iPhone — це чужа авторизована сесія. Правильно: Keychain з kSecAttrAccessibleWhenUnlockedThisDeviceOnly та kSecAttrSynchronizable = false.

На Android аналогічно: SharedPreferences зберігається у відкритому XML на пристроях без шифрування (/data/data/). Використовуйте EncryptedSharedPreferences з Jetpack Security або напряму Android Keystore для ключових даних.

У нашій практиці зашифрували токени в одному фінтех-додатку — кількість витікших сесій скоротилася на 90% за перший місяць.

Що краще: DexGuard чи R8 для захисту коду Android?

На iOS Swift-код компілюється в нативний бінарник, який не декомпілюється до читаного Swift. Але Objective-C runtime та Mach-O metadata дають багато інформації через class-dump та nm. Для критичних рядків використовуємо обфускацію через SwiftShield.

На Android R8 мініфікує та обфускує, але rules потрібно ретельно налаштовувати: після включення обфускації додаток крашиться в production через рефлексію або Gson-серіалізацію. Ми завжди тестуємо на 100+ пристроях перед релізом.

Виявлення jailbreak та root

MASVS-RESILIENCE-1 вимагає виявлення скомпрометованих пристроїв. Стандартні перевірки: наявність /Applications/Cydia.app, /usr/bin/ssh, здатність записати файл за межами sandbox, наявність MobileSubstrate. Але статичні перевірки легко обходяться через A-Bypass, Liberty Lite. Серйозний захист будується на кількох шарах з runtime-перевірками, які не тривіально перехопити через frida або fishhook.

Готові рішення: IOSSecuritySuite (iOS, open source), rootbeer (Android). Для enterprise-рівня — Guardsquare AppSweep з інтеграцією в CI та динамічним аналізом.

Що входить в роботу з безпеки мобільного додатка

Кейс з нашої практики: як ми закрили 0 критичних вразливостей за 3 тижні

Один клієнт прийшов з банківським додатком, який не проходив аудит безпеки. Ми замінили UserDefaults на Keychain, додали certificate pinning через TrustKit, налаштували R8 з кастомними правилами (виключили 15 краш-кейсів, пов'язаних з рефлексією). Через три тижні повторний пентест показав 0 критичних вразливостей. З моменту впровадження — жодного інциденту за два роки. Економія клієнта від запобігання витоку даних — до $150,000 на рік.

Терміни та вартість

• Security-аудит за OWASP MASVS рівня L1 — від 1 до 2 тижнів.
• Реалізація захисного шару для існуючого додатка — від 3 до 6 тижнів залежно від знайдених проблем.
• Повний цикл «аудит + впровадження + тест» — від 4 до 8 тижнів.

Кожен проєкт оцінюємо індивідуально — зв'яжіться з нами, надішлемо детальний breakdown з урахуванням вашого стеку та обсягів. Працюємо під ключ: від аналізу до деплою в сторах. Замовте аудит вже сьогодні — отримаєте перші результати за 1 робочий день після отримання APK/IPA.