Шифр-Arch

На сьогодні все більше документів існує виключно у електронному виглядіє, тому виникає актуальна задача архівного зберігання таких документів, особливо якщо документи призначені не лише для внутрішнього використання, але й для передачі в інші установи. Як правило, такі документи повинні мати кваліфікований електронний підпис (КЕП), але не обов'язково. Строки зберігання таких документів вимірюється десятиліттями, наявна необхідність перевірки КЕП всіма підписантами для встановлення:
  • Цілісність.
  • Конфіденційність.
  • Достовірність.
Актуально на сьогодні для державного, банківського та страхового секторів.

Стандартний підхід

Використання КЕП у форматі ASiC/CAdES X-Long, яка дозволяє забезпечити довготривалу перевірку КЕП. 
  • Рішення про достовірність КЕП приймається, якщо вона успішно перевіряється, при створенні. 
  • Після певного періоду часу неможливо перевірити КЕП згідно чинних нормативних документів.
Функції
  • Перевірка КЕП, перед занесенням документу в архів*.
    • Перевірка КЕП:
      • Відправка запитів до ЦЗО (OCSP).
      • ВІдправка запитів до ЦСК (OCSP).
    • Розширення підпису до CAdES X-Long (у випадку необхідності).
  • Перевірка КЕП у форматі CAdES X-Long та документу з архіву*.
    • Перевірка КЕП:
      • Відправка запитів до ЦУО (OCSP).
      • Відправка запитів до ЦСК (OCSP).
*- КЕП зберігається разом з документами в архіві.

Розширений (Blockchain) підхід

У доповнення до Стандартного підходу, пропонується використовувати модифіковані механізми блокчейн, на основі імітовставки.
  • Рішення про коректність КЕП приймається, коли вона успішно перевіряється при створенні.
  • Сам КЕП та результати її перевірки, а також всі використовувані для перевірки дані заносяться до БД та зчеплюються з попередніми записами за допомогою імітовставки.
  • При перевірці КЕП, безпосередньо сам підпис не перевіряється, а лише перевіряється цілісність всіх зчеплених записів у БД.
Функції
  • Отримання КЕП, перед занесенням документу в архів*.
    • Перевірка КЕП
      • Відправка запитів до ЦЗО (OCSP)
      • Відправка запитів до ЦСК (OCSP)
    • Розширення підпису до CAdES X-Long (у випадку необхідності)
    • Формування QR-code для КЕП CAdES X-Long
    • Додавання відкріпленого КЕП, хеш-образ у БД зі зчепленими записами
  • Перевірка цілісності документу з архіву
    • Порівняння хеш-образу документу та записи з БД зі зчепленими записами
  • Перевірка цілісності БД зі зчепленими записами
    • Перевірка цілісності БД зі зчепленими записами, завдяки її відтворення
*- КЕП зберігається у БД архіву КЕП зі зчепленими записами, без документів

Недоліки та переваги обох підходів

 
Недоліки
Переваги
Стандартний підхід
  1. Обмежений строк гарантованої перевірки КЕП:
    • Строк дії сертифікату ЦЗО (ЦЗО).
    • Строк дії сертифікату ЦСК (ЦЗО).
    • Строк дії сертифікату OCSP (ЦСК).
    • Строк дії сертифікату TSP (ЦЗО).
  2. Можливість компрометації використовуваних ключів.
  3. Можливість відмови від існуючих стандартів КЕП, з причини їх морального старіння.
  4. Необхідність розширення КЕП до формату CAdES X-Long.
  5. Перевірка КЕП з архіву онлайн з ЦСК та ЦЗО.
  1. Простота використання.
  2. Відсутність БД.
  3. Відсутність необхідності у забезпеченні додаткових механізмів захисту.
  4. Документи зберігаються в окремій системі.
Розширений підхід (Blockchain)
  1. Складність рішення.
  2. Необхідність ведення БД з відкріпленою КЕП зчепленими записами.
  3. Необхідність періодично здійснювати перевірку цілісності всієї БД зі зчепленими записами.
  4. Необхідність розширення підпису до формату CAdES X-Long.
  5. Необхідність при забезпеченні захисту ключа імітовставки для блокчейну.
  1. Необмежений строк гарантованої перевірки КЕП, так як сам КЕП не перевіряється, а перевіряється лише цілісність зчеплених записів у БД з відкріпленним КЕП.
  2. Компрометація використовуваних ключів не впливає на вже перевірені КЕП.
  3. Відмова від існуючи стандартів КЕП не вливає, на вже перевірені КЕП.
  4. Документи зберігаються в окремій системі.
  5. Перевірка КЕП з архіву в офлайн (без ЦСК та ЦЗО).

Корпоративний архів з використанням Шифр-Arch

Система архівування документів, яка дозволяє забезпечити структуроване та довготривале зберігання електронних документів у томі місці, де гарантована перевірка цілісності зчеплених записів у БД (blockchain), навіть після неможливості перевірки КЕП.
Характерристики
Шифр-Arch, як система ведення довготривалого архіву дозволяє:
  • Працювати одразу у кількох ЦОД, у вигляді єдиного кластеру.
  • Працювати автономно у кожному ЦОД, якщо єдиний кластер “розвалився”.
  • Відновлення єдиного кластеру, після його “розвалу”, на основі кластерів одного з ЦОД.
  • Горизонтальне масштабування, до 32-х серверів у кластері БД з документами.
  • Зберігання документів: не обмежено за об'ємом (здійснювалася перевірка на192 ТБ).
  • Розмір документу: до 5 ТБ.
  • Клонування вузлів з пов'язаними ланцюжками для підвищення довіри/захисту від підробки.
  • Автентифікація за допомогою JWT (JSON Web Token).
  • Захист каналів зв'язку:
    • Робота в середині системи через HTTPS/TLS.
    • Робота з API через HTTPS/TSL.
    • Web-інтерфейс через HTTPS/TLS.
Функції
  • Перевірка КЕП, перед занесення документу в архів*.
    • Перервірка КЕП:
      • Відправка запитів до ЦЗО (OCSP).
      • ВІдправка запитів до ЦСК (OCSP).
    • Розширення підпису до CAdES X-Long (у випадку необхідності).
    • Додатково можна додати до КЕП документу:
      • КЕП відповідального співробітника (архіваріуса).
      • Печатка організації.
    • Додавання відкріпленого КЕП, хеш-образу документу та результатів перевірки КЕП у БД зі зчепленими записами.
  • Пошук документу за реквізитами та підписантами (текст документу не індексується).
  • Перевірка КЕП, перед занесенням документу в архів*.
  • Перевірка цілісності документу з архіву:
    • Співставлення хеш-образу документу та запису з БД зі зчепленими записами.
    • Прийняття рішення за результатами консолідованої перевірки з кількома вузлами.​
  • Перевірка цілісності БД зі зчепленими записами (кілька таких БД):
    • Перевірка цілісності БД зі зчепленими записами, за допомогою відтворення.
    • Прийняття рішення за результатами консолідованої перевірки з кількома вузлами.
    • За розкладом.
Рольова модель:
  • Адміністратор архіву.
  • Оператор архіву.
*- КЕП зберігається у БД архіву КЕП зі зчепленими записами, без документів.

Криптографія

Використовувані криптографічні алгоритми:
  • ЕП/КЕП:
    • ДСТУ 4145+ГОСТ 34.311-95 (за замовчуванням).
    • ДСТУ 4145+ДСТУ 7624:2014*.
    • ECDSA+SHA-256.
    • RSA+SHA-256.
  • Hash:
    • ГОСТ 34.311-95.
    • ДСТУ 7564:2014.
    • SHA-2 семейство.
  • MAC (використовується для блокчейну):
    • ДСТУ ГОСТ 28147:2009.
    • ДСТУ 7624:2014 (за замовчуванням).
    • AES (AES-NI).
*- на даний момент не затребуване, можливе підключення за необхідністю.
Використовувані сховища ключів:
  • ЕП/КЕП:
    • PFX/PKCS#12 (за замовчуванням).
    • PKCS#11-активний режим (Network HSM).
  • MAC:
    • PKCS#12 (за замовчуванням).
    • PKCS#11-активний режим (Network HSM).

Архітектура системи довготривалого зберігання документів (архіву)

Користувацький веб-клієнт

На рисунках продемонстровано головну сторінку та сторінку додавання документу.
Рисунок 1. Головна сторінка вкладки "Документи в архіві"
Рисунок 2. Процес додавання документу в архів