Крипто та не крипто
written on Friday, January 23, 2015
Використовувані поняття:
- алгоритм — покрокове рішення математичної задачі, яке може бути втілене у програмному модулі чи апаратному засобі; приклади: RSA, AES, SHA-1, DH, ДСТУ-4145, ГОСТ-28147-89;
- секретний ключ — набір даних, відомий лише власнику, що використовується у роботі алгоритму;
- публічний ключ — набір даних, утворений від секретного ключа, що поширюється публічно (на візитках, публічних сайтах, довідниках). Отримати приватний ключ за публічним неможливо. Одному приватному ключу відповідає один публічний;
- підпис — набір даних, що виникає в результаті роботи алгоритму та доводить, що модулю, який реалізує алгоритм, був відомий приватний ключ і документ;
- перевірка підпису — робота алгоритму, що використовує публічний ключ, документ і підпис, відповідаючи на питання «чи справді алгоритму, що створював підпис, були відомі саме цей документ і приватний ключ, що відповідає даному публічному ключу». Перевірка підпису здійснюється для документа, сертифіката та часової мітки;
- центр сертифікації — організація, чий публічний ключ широко відомий, і є довіра, що секретний ключ добре захищений, а підписані ним сертифікати підтверджують дані реальних суб'єктів. Центр сертифікації надає послуги з підписання сертифікатів;
- сертифікат — підписаний центром сертифікації документ, що містить публічний ключ і підтверджує його зв'язок із певним суб'єктом (юрособа, фізособа) чи об'єктом (штамп, сервер, гаманець);
- ЕЦП — набір із підпису, документа та сертифіката суб'єкта, що має юридичні наслідки; також використовується для позначення набору із секретного ключа та сертифіката, що пов'язує публічний ключ із суб'єктом права;
- спільний ключ — однаковий набір даних, відомий двом сторонам певного процесу. Може бути створений однією стороною та переданий іншій, або розрахований двома сторонами автономно;
- смарткарта — апаратний модуль, що містить секретний чи спільний ключ і виконує алгоритм, який використовує цей ключ. Видає назовні лише результат операції, але не ключ. Доступ до запуску алгоритму, що використовує ключ, може бути захищений пін-кодом;
- сим-карта — окремий випадок смарт-карти, що використовує спільний з оператором ключ для підтвердження володіння телефонним номером;
- е-паспорт — окремий випадок смарт-карти, що використовує секретний ключ і пов'язаний із ним сертифікат, щоб підтвердити відповідність особи власника, як суб'єкта, вказаного в сертифікаті, або для створення підпису, або для створення спільного з будь-яким іншим суб'єктом ключа;
- формат — чітко описане представлення даних (ключа, сертифіката, документа), необхідне програмі чи апаратному модулю для роботи алгоритму та подання результату.
ЕЦП (ключ-сертифікат-софт)
Застосовується в деяких процессах в Україні (інтернет-банкінг, реєстрація ФОП, здача податкової звітності).
- За допомогою ЕЦП можна в автоматичному режимі довести необмеженому колу осіб, що джерелом документа в незміненому вигляді був власник секретного ключа або хтось, хто має до нього доступ. При правильній поведінці співробітників АЦСК та отримувача ключа — це той самий суб'єкт, що записаний у сертифікаті;
- За допомогою ЕЦП отримувач (не підписант) документа може довести третім особам (наприклад суду), що джерелом документа в незміненому вигляді був власник ключа або хтось хто має до нього доступ;
- За допомогою ЕЦП та часової мітки (треба довірений сервер) можна довести те саме і факт існування документа у певний момент часу (створений не пізніше);
- За допомогою ЕЦП можна зашифрувати файл таким чином, що розшифрувати його зможе лише власник певного приватного ключа (певний суб'єкт);
- За допомогою ЕЦП можна довести свою особу будь-якому окремому суб'єкту з широкого кола;
Ці задачі вирішуються у випадку якщо всі суб'єкти взаємодії мають доступ до програмних чи апаратних засобів що підтримують алгоритми та формати один одного і цей процес визнається державою як учасником цього процесу.
Наразі в Україні склалася ситуація коли:
- широке коло осіб не має доступу до таких програмних засобів;
- широкодоступні засоби що реалізують популярні алгоритми не визнаються;
- відсутній якийсь формат документів;
- самі документи існують лише всередині якоїсь системи;
- виробниками таких систем є сертифікаційні центри;
- не існує загальнодоступної системи для обміну реєстрації чи легалізації документів ні побудованої на національних ні на світових стандартах;
RSA vs ДСТУ4145
Питання протиставлення RSA та ДСТУ 4145 (і супутніх ГОСТів) у контексті аутентифікації та ідентифікації зачіпає одну ланку описаної вище проблеми — широку доступність криптографічних засобів і можливість виходу більшої кількості виробників на ринок. Інші аспекти цієї проблеми мають бути вирішені незалежно від використовуваного стандарту. Зокрема сумісність форматів може перевірятися стендом а створення (чи ліцензування) загальнодоступної системи (чи стандарту обміну для систем) буде потрібне в будь-якому випадку.
Проблеми широкої доступності криптографічних засобів (а точніше кінцевих продуктів) можуть бути вирішені без зміни стандарту (але з можливістю перейти на RSA чи інший перспективний алгоритм згодом). Наприклад можливо:
- викупити чи створити криптобібліотеку стандарту ДСТУ 4145 провести її сертифікацію та опублікувати для вільного використання;
- ліцензувати бібліотеку і створити загальнодоступні сервіси аутентифікації (далі портал) і сервіс обміну документами як об'єкти цифрової інфраструктури для внутрішнього використання в держорганах і як сервіс для бізнесу;
Однією з дійсних переваг RSA чи ECDSA є його підтримка браузерами у вигляді сертифікатів та Web Crypto API (http://www.w3.org/2012/webcrypto/webcrypto-next-workshop/papers/Using_the_W3C_WebCrypto_API_for_Document_Signing.html). При використанні RSA-сертифікатів аутентифікацію (але не підписання документів) можна виносити на канальний рівень (SSL він же TLS він же HTTPS) де вона тривіально налаштовується в конфігурації веб-сервера а підписання реалізовувати засобами Web Crypto API браузера.
Обмеження та припущення
При використанні ЕЦП всі суб'єкти покладаються на те (довіряють) що кожен АЦСК сертифікує ключі лише тим суб'єктам особу яких записує в сертифікат а власник ключа не розголошує його або розголошує лише особам яких уповноважує виступати від свого імені (наприклад бухгалтеру).
Видача текстового пароля
Видача текстового пароля через ЦНАПи чи інші органи влади може вирішити проблему ідентифікації суб'єкта онлайн без застосування ЕЦП і необхідності використовувати сертифіковані засоби криптографічного захисту.
Текстові паролі використовуються для доступу до більшості ресурсів в інтернеті включаючи інтернет-банкінг для фізосіб в Україні. У деяких ситуаціях використовується два паролі (двофакторна авторизація наприклад пароль + код із смс).
- пароль дозволяє довести сервісу що видав пароль що суб'єкт який звертається до сервісу у певний момент часу мав доступ до пін-конверта або знає текст пароля. При правильній поведінці оператора та отримувача конверта — це той самий суб'єкт що й отримувач пін-конверта;
- при онлайн-доступі таке підтвердження може бути перевірене порталом авторизації з видачею токена підтвердження для широкого кола сервісів що довіряють порталу в процедурі аутентифікації;
- портал що перевіряє пароль не може довести особу користувача третім особам інакше ніж адміністративно;
- пароль не може використовуватися для прямого підтвердження своєї особи широкому колу суб'єктів;
- пароль не може використовуватися для підтвердження незмінності документа чи часу його створення;
Процедура видачі пароля може бути заснована на пін-конвертах що використовуються в банківській сфері. Оператор перевіряє особу людини яка хоче отримати конверт записує перевірену ідентичність в систему акаунтів разом з номером пін-конверта який портал може пов'язати з самим паролем.
При використанні пароля всі суб'єкти покладаються на те що портал аутентифікації коректно перевіряє пароль а оператори коректно перевіряють особу при видачі пін-конверта;
Аутентифікація за смс (one time password) є різновидом аутентифікації за паролем має ті самі властивості та може її доповнювати. Додаткова гарантія — смс можуть приходити лише на один телефон і їх не можна заздалегідь скопіювати як пароль. Для використання аутентифікації за смс-паролем оператор повинен замість (або разом з) видачею пін-конверта перевірити і записати номер телефону ідентифікованої особи.
Портал може комбінувати різні способи аутентифікації (пароль otp ЕЦП) не вимагаючи впровадження ЕЦП на кожному сервісі що його використовує. Це допоможе плавно перейти від простого (видача конвертів) до складного (ЕЦП) і одночасно заощадити на ліцензіях не ліцензуючи криптобібліотеку для кожного окремого ресурсу. При цьому портал буде використовувати ЕЦП тільки для підтвердження особи але не для підпису документів шифрування і всього іншого. Для такої схеми достатньо шифрування зі спільним ключем і видачі нумерованих смарт-карт як більш безпечного аналога пін-конвертів.
Смарт-карта
Смарт-карта що містить приватний ключ і сертифікат може видаватися як окремий пристрій може бути поєднана з сим-картою телефону або вбудована в паспорт.
Використання смарт-карти що реалізує ЕЦП дозволяє вирішити всі ті ж задачі що ЕЦП як таке але при цьому додатково захищає власника ключа від несанкціонованого доступу до нього.
Вбудовування смарт-карти в паспорт дозволяє державі обмежити передачу ключа третім особам з санкції чи без санкції власника. Щоб ця гарантія працювала треба також заборонити використання ключів не вбудованих в паспорт тобто організувати державну монополію на ЕЦП.
This entry was tagged