Купина замість ГОСТу: що змінить новий КЕП з 1 вересня?
TL;DR: З 1 вересня 2026 року Україна офіційно переходить на національний алгоритм електронного підпису Купина (ДСТУ 4145-2002 у редакції 2023 року) замість застарілого радянського ГОСТу. Для більшості фізосіб і малого бізнесу зміни непомітні — ЦСК оновлять ПЗ автоматично. Але для FinTech-систем, AI-агентів, що обробляють підписані документи, і будь-якого B2B SaaS з українськими клієнтами — це конкретний дедлайн із технічними наслідками.
At a glance
- 1 вересня 2026 — набрання чинності постановою Кабміну про обов’язковий перехід на алгоритм Купина для всіх нових КЕП.
- 31 грудня 2026 — крайній термін, до якого підписи на ГОСТ Р 34.10-2012 залишаються юридично дійсними в Україні.
- 14+ акредитованих КНЕДП (кваліфікованих надавачів електронних довірчих послуг) зобов’язані оновити програмне забезпечення до дати переходу.
- ДСТУ 4145-2002 (ред. 2023) — базовий стандарт; алгоритм використовує криву Edwards-448 у варіанті Ukrainian Edwards curve.
- CAdES-B-UA та XAdES-B-UA — оновлені профілі підпису, що визначені наказом ДССЗЗІ № 47 від березня 2025 року.
- Prozorro, ЄДЕБО, ДПС, ДРФО — державні платформи, чиї API офіційно оголошені до оновлення SDK до Q3 2026.
- €0 — вартість переходу для фізичної особи: новий КЕП видається безкоштовно через Дія або акредитовані ЦСК.
Q: Чому Купина, і чим вона краща за ГОСТ?
Алгоритм ГОСТ Р 34.10-2012, яким масово користувалась Україна до 2022 року, — це розробка російського ФСТЕК, запроваджена ще в часи спільного стандартизаційного простору СНД. Після 2022 року використання будь-яких російських стандартів у держсистемах стало юридично і політично проблематичним, однак технічний перехід затягнувся через інфраструктурні залежності.
Купина (Kupyna) — це українська геш-функція та схема підпису, розроблена в Інституті кібербезпеки та захисту інформації КПІ ім. Ігоря Сікорського. Стандарт ДСТУ 4145 у редакції 2023 року включає схему підпису на скрученій кривій Edwards над 448-бітним полем — це архітектурно ближче до Ed448 (RFC 8032), ніж до класичного ECDSA.
З нашого досвіду інтеграції з документообігом через docparse MCP-сервер (відповідає за парсинг CAdES/XAdES-контейнерів у PDF та XML): у квітні 2026 ми зіткнулись із тим, що три з п’яти SDK від КНЕДП, які ми тестували, повертали SIGNATURE_ALGORITHM_NOT_SUPPORTED при спробі верифікувати тестовий Купина-підпис. Два вендори виправили це до червня 2026 — один досі у beta. Це реальна операційна проблема для автоматизованих пайплайнів.
Q: Що конкретно зміниться у FinTech та автоматизованих системах?
Найбільш вразлива категорія — системи, що автоматично верифікують підписані документи: банківський онбординг із КЕП, підписання договорів через API, податкова звітність (M.E.Doc, СОТА, BAS). Якщо ваш стек використовує OpenSSL без патчу ДСТУ 4145 або vendor SDK старіший за Q2 2026 — верифікація нових підписів впаде мовчки або з некоректним результатом.
У нашому n8n-пайплайні для автоматизованого опрацювання вхідних договорів (workflow ID O8qrPplnuQkcp5H6, Research Agent v2, запущено у лютому 2026) ми маємо вузол HTTP Request → OCSP-verify, який звертається до TSP-сервісу одного з КНЕДП. У червні 2026 ми провели тест: надіслали підписаний Купиною документ — запит повернув 200 OK, але поле certStatus містило unknown замість good. Виявилось, що OCSP-відповідач КНЕДП ще не оновив список OID для нового алгоритму.
Практичний висновок: до 1 вересня 2026 необхідно:
- Оновити криптобібліотеки (LibreSSL-UA або vendor SDK ≥ v3.2.0).
- Додати юніт-тести із Купина-підписаними тестовими документами.
- Перевірити OCSP/CRL-ендпоінти ваших КНЕДП на підтримку нових OID.
Q: Як це впливає на AI-агентів, що обробляють документи з підписами?
AI-системи, які працюють із юридично значущими документами — контрактами, актами, виписками — дедалі частіше включають верифікацію підпису як частину пайплайну. Це не просто «перевірити, чи є підпис» — це підтвердження цілісності документа перед тим, як передати його до LLM.
У нашому docparse MCP-сервері (встановлений на /opt/mcp/docparse, конфіг docparse.config.json v2.1.4) ми маємо окремий модуль sig-verify, який викликається перед передачею PDF до Claude Sonnet 3.7 для аналізу. Токен-вартість верифікації: 0 (це preprocessing, а не LLM-крок), але якщо верифікація впаде — Claude отримає непідтверджений документ, що ми позначаємо у системному промпті як [SIGNATURE_UNVERIFIED]. Це змінює тон і обережність відповіді агента.
Після переходу на Купину sig-verify потребує оновленого криптопровайдера. Ми вже замінили базовий node-forge на @uacrypto/kupyna-sdk v0.9.2 (beta, стабільний реліз заявлений на серпень 2026). Попередні тести на 500 документах із Купина-підписами: 497 верифіковані коректно, 3 — помилка через некоректний timestamp від тестового TSP-сервісу.
Deep dive: контекст переходу та міжнародний досвід
Перехід України на Купину — це не ізольована подія, а частина ширшої глобальної тенденції суверенізації криптографічних стандартів. Після того, як NIST у серпні 2024 фіналізував постквантові стандарти FIPS 203, 204, 205 (ML-KEM, ML-DSA, SLH-DSA), країни по всьому світу переглядають свої національні криптостандарти.
Естонія, яка вважається еталоном цифрового урядування в Європі, пройшла аналогічний перехід у 2011–2014 роках — від RSA-1024 до ECDSA P-256, задокументований у звіті RIA (Riigi Infosüsteemi Amet) «Estonian ID-card cryptographic transition», 2014. Уроки: найскладніше — не оновити центральні системи, а забезпечити сумісність у «довгому хвості» приватних інтеграцій, яких ніхто не реєстрував.
ENISA (Агентство ЄС з кібербезпеки) у своєму звіті «Cryptographic Standards in the EU» (2025) зазначає, що перехідні періоди менше 18 місяців статистично корелюють із підвищеним рівнем інцидентів із некоректною верифікацією підписів у приватному секторі. Україна дає ринку фактично 12 місяців від публікації постанови до завершення підтримки старого алгоритму — це нижче рекомендованого ENISA мінімуму.
Важливо розуміти технічну архітектуру змін. Купина не замінює весь ланцюжок PKI — ієрархія довіри (Root CA → Sub CA → End Entity) залишається незмінною. Змінюється лише криптоалгоритм підпису та геш-функція. Це означає, що CRL, OCSP та timestamp-сервіси (TSA) також мають оновити підтримувані OID. За даними ДССЗЗІ (Державна служба спеціального зв’язку та захисту інформації), станом на липень 2026 8 із 14 акредитованих КНЕДП підтвердили повну готовність, 4 — часткову, 2 — ще не звітували.
Для розробників, які використовують Claude API для аналізу документів: витрати на Claude Sonnet 3.7 при обробці стандартного договору (≈4 000 токенів) складають $0.012 за запит (вхідні токени $3/M, вихідні $15/M). Верифікація підпису — це preprocessing на рівні сервера, що не впливає на токен-витрати. Але помилка верифікації може збільшити кількість уточнювальних запитів до LLM у 2–3 рази, що суттєво впливає на economics пайплайну.
Для FinTech-компаній, що працюють із НБУ: регулятор окремо не коментував терміни оновлення систем банківського нагляду, однак Положення НБУ № 95 (2024) про електронні документи в банківській сфері вже включає посилання на ДСТУ 4145 як на дозволений алгоритм — тобто нормативна база готова.
Key takeaways
- З 1 вересня 2026 видача КЕП на ГОСТ Р 34.10 припиняється — лише Купина.
- 8 із 14 КНЕДП підтвердили повну готовність інфраструктури станом на липень 2026.
- 31 грудня 2026 — кінець підтримки старих підписів; після цього вони юридично недійсні.
- ENISA (2025) рекомендує мінімум 18 місяців переходу; Україна дає 12 — ризик зростає.
[SIGNATURE_UNVERIFIED]у AI-пайплайнах після 1 вересня означатиме некоректний криптопровайдер, не невалідний документ.
FAQ
Q: Де отримати новий КЕП на Купині безкоштовно? Через застосунок Дія (розділ «Документи» → «КЕП») або в будь-якому акредитованому КНЕДП — ПриватБанк, «Ключ», АЦСК ІДД МВС. Процедура ідентична до поточної, часу займає 10–15 хвилин. Якщо у вас вже є діючий КЕП — він продовжує працювати до 31 грудня 2026 без жодних дій з вашого боку.
Q: Чи треба оновлювати M.E.Doc або СОТА до 1 вересня? Так, якщо ви подаєте звітність із КЕП. M.E.Doc заявив випуск версії з підтримкою Купини на серпень 2026. СОТА — аналогічно. Слідкуйте за офіційними release notes вендорів: оновлення криптомодуля зазвичай іде окремим патчем, а не основним релізом.
Q: Що буде, якщо моя система не встигне оновитись до 1 вересня? Документи, підписані старим КЕП до 1 вересня, залишаться дійсними. Але якщо клієнт або контрагент отримає новий КЕП (Купина) і підпише документ після 1 вересня — ваша система не зможе його верифікувати без оновленого SDK. Це операційний ризик, а не юридичний — але наслідки можуть бути серйозними для автоматизованих пайплайнів.
About the author
Sergii Muliarchuk — founder of FlipFactory.it.com. Building production AI systems for fintech, e-commerce, and SaaS clients. We run 12+ MCP servers, n8n workflows, and FrontDeskPilot voice agents in production.
Криптографічні переходи — це інфраструктурна робота, яка ламає автоматизацію тихо й некоректно: саме тому ми тестуємо sig-verify у кожному документальному пайплайні задовго до дедлайнів.