Transcript завантажити презентацію

Мартиненко С.В., к.ф.-м.н, Директор технічний
Бєлов С.В., Начальник відділу інформаційної безпеки
ТОВ «Інтер-Метл»
Проблематика положень законодавства
в галузі ЕЦП
Проблематика застосування положень законодавства
в галузі ЕЦП стосується:
 Закону України «Про електронний цифровий
підпис».
 Постанови Кабінету Міністрів України № 680 від 26
травня 2004 р.
 Наказів, виданих різними органами центральної
влади, в тому числі - які стосуються технічних
питань застосування ЕЦП.
2
Проблемні питання Закону України «Про
електронний цифровий підпис»
 Першочерговим завданням є внесення необхідних правок до
Закону України «Про електронний цифровий підпис» (далі –
Закон України) для приведення його у відповідність в першу чергу
з Європейським законодавством (Директива 1999/93/ЄС), світовою
практикою в цій сфері узгодження з положеннями Закону України
«Про електронні документи та електронний документообіг»
Діючий Закон України має ряд недоліків, основними з них є такі:
 Не визначений термін «користувач» (ст.2 Закону);
 Серед обов’язкових реквізитів сертифікату ключа (ст.6), який
розповсюджується та використовується в електронному вигляді, немає
електронного цифрового підпису центру сертифікації ключів
 Відсутнє правове врегулювання визнання іноземних сертифікатів
відповідно до ст.17
3
Закон України про ЕЦП та Директива ЄС
1999/93/ЄС
 Невідповідність юридичної сили/ правового
статусу електронного підпису в Законі України та
Директиві ЄС еквівалентним власноручному :
Закон України
1. електронний цифровий підпис підтверджено з
використанням
2. посиленого сертифіката ключа
3. за допомогою надійних засобів цифрового
підпису;
Директива ЄС
1. удосконалені електронні підписи,
2. засновані на кваліфікованих сертифікатах і
3. створені за допомогою
безпечних механізмів створення підпису
4
Розходження Закону України про ЕЦП з
Директивою ЄС 1999/93/ЄС
Аналіз показує що:
 1) «посилений сертифікат» Закону України не відповідає «кваліфікованому
сертифікату» Директиви ЄС;
 2) «надійний засіб ЕЦП» Закону України не відповідає «безпечному механізму
створення підпису» Директиви ЄС;
 3) За Законом України для набуття юридичної сили відбувається лише на етапі
перевірки підпису, а Директива вимагає контроль на етапі створення підпису;
 4) Визначення «електронний підпис» Закону України звужує визначення,
прийняте в Директиві ЄС і вони різні за суттю, а „електронний цифровий підпис” за
Законом України – це обмежений термін „електронний підпис” за Директивою ЄС;
 6) Термін „удосконалений електронний підпис” за Директивою ЄС, який
визнається еквівалентом власноручного підпису в ЄС, в Законі України відсутній;
 7) Термін «безпечний механізм створення підпису» Директиви ЄС не відповідає
терміну «надійний засіб електронного цифрового підпису» Закону України.
Базові визначення Закону України не відповідають визначенням Директиви ЄС, немає
відповідності щодо юридичної сили/ правового статусу електронного (цифрового)
підпису.
5
Інші питання, які потрібно вирішити та
пропозиції розв'язання
 Нерозумінням різниці між термінами та їх сутності призвело до підміни одного
терміну іншим: в ДСТУ ETSI TS 102 045:2009 та ДСТУ ETSI TS 101 862:2009 термін
«кваліфікований» (qualified) замінений на «посилений», що є помилковим.
 Зважаючи на прийняту Україною програму наближення до ЄС, Закон України
повинен відповідати законодавству ЄС, зокрема законодавчі акти, які приймаються
на виконання Директиви повинні мати пряме посилання на цю Директиву (ст.13
Директиви).
 В Росії для забезпечення відповідності національного законодавства європейському
був прийнятий новий Закон РФ «Про електронний підпис» (2010 р.), де визначено
три види електронного підпису - простий, посилений та кваліфікований.
Пропозиція:
 Внести необхідні правки в Закон України «Про електронний цифровий підпис» та
розробити новий Закон, в якому забезпечити дотримання вимог законодавства ЄС
в галузі електронних підписів.
 Тексти прийнятих стандартів в галузі цифрового підпису та вимог до ЦСК привести
у відповідність оригіналам стандартів ETSI та CWA
6
Зміни до Постанови №680 від 26 травня
2004 щодо позначок часу -1
В п.3 Постанови КМУ № 680 «Про затвердження Порядку засвідчення наявності електронного
документа (електронних даних) на певний момент часу» вказано що надання послуг
фіксування часу включає:
 реєстрацію звернень, на підставі яких формується позначка часу; формування позначки
часу за допомогою особистого ключа центру сертифікації; реєстрацію та збереження
позначки часу, переданої користувачеві послуги фіксування часу.”
Реєстрація звернень та збереження сформованих позначок часу не мають практичного
сенсу:
 запит на позначку часу є фактично анонімним, що випливає з вимог, затверджених
спільним Наказом Мінюсту та Держспецзв’язку № 1236/5/453 від 20.08.2012;
 реєстрація відповіді не має сенсу з юридичної точки зору, оскільки у спірних
питаннях розглядається отримана заявником позначка часу, додана до
електронного документу.
 реєстрація запиту не має сенсу з точки зору прив’язки до особи, яка звернулась по
позначку часу, оскільки не визначений порядок реєстрації.
При цьому значно уповільнюється робота ЦСК з обслуговування підписувачів; база
даних та архіви ЦСК містять інформацію, яка не має відповідного юридичного
статусу. У разі надання платних послуг фіксування часу з подальшим виставленням
рахунків слід використовувати інші механізми (автентифікаційні).
7
Зміни до Постанови №680 від 26 травня
2004 щодо позначок часу -2
 Міжнародною практикою та стандартами прийнято, що формування позначки часу
може виконувати фізична або юридична особа, яка виконує вимоги щодо якості
надання такої послуги. Це може бути і центр сертифікації ключів. Формування
відбувається програмними засобами (служба), яки базуються на джерелах точного
часу. Сертифікат для служби позначок часу формується Центральним
засвідчувальним органом окремо від сертифікатів ЦСК та може використовуватись
окремо від ЦСК.
 Формулювання в Постанові порядку «формування позначки часу за допомогою
особистого ключа центру сертифікації» обмежує таку послугу виключно центрами
сертифікації ключів, що суперечить міжнародному досвіду та практиці.
Пропозиції:
 Виключити з тексту реєстрацію звернень, переглянути вимоги до реєстрації та
збереження позначки часу – реєстрація тільки в електронному журналі подій.
 Формулювання щодо формування позначки часу замінити на «формування
позначки часу за допомогою особистого ключа особи, яка отримала в ЦЗО
сертифікат для формування позначок часу».
8
Зміни до Наказів в галузі ЕЦП
 Наказ СБУ 10.05.2006 № 50 «Про внесення змін до правил посиленої
сертифікації» (п.1.5) Одним з правових питань, які потребують врегулювання є
питання використання в якості відокремлених пунктів реєстрації центрів
сертифікації ключів (ЦСК), як представництв, не тільки власних підрозділів, філій,
а й організацій, які виконують такі функцій за договорами з ЦСК та відповідають
вимогам, які застосовуються до відокремлених пунктів реєстрації. Внесення
відповідних правок в Наказ дозволить більш ефективно створювати ринок ЕЦП та
значно зменшити витрати на його розбудову, що задовольнить вимоги більшості
користувачів ЦСК та є необхідним для ринку ЕЦП країни.
Пропозиція: В тексті Наказу виключити слова «(підрозділів, філій)».
 Зміни до Наказу Мінюсту та Держспецзв’язку № 1236/5/453 від 20.08.2012
Необхідно внести ряд правок до прийнятих технічних вимог застосування ЕЦП
(спільний Наказ Мінюсту та Адміністрації Держспецзв’язку № 1236/5/453 від
20.08.2012 «Про затвердження вимог до форматів, структури та протоколів, що
реалізуються у надійних засобах електронного цифрового підпису»):
9
Зміни до Наказу Мінюсту та Держспецзв’язку №
1236/5/453 від 20.08.2012
 1) до тексту Наказу не включені алгоритми хешування SHA-1, SHA-256, SHA384, SHA-512, які визначені діючими стандартами: ДСТУ ISO/IEC 10118-3:2005
(Спеціалізовані геш-функції»), ДСТУ ETSI TS 102 176-1 (Геш-функції й асиметричні
алгоритми), що унеможливлює в ряді випадків використання стандартних
програмних застосувань, та ускладнює використання електронних документів
 2) У Наказі «Про затвердження вимог до протоколу визначення статусу
сертифіката» п.3.3.2 вказано, що слід обчислити геш-значення для структури
ResponderID, але не вказаний алгоритм. За стандартом RFC 2560, на якому
базується ця специфікація, цим алгоритмом повинен бути SHA-1. Тут може бути
несуміснсть рішень розробників, як використовували ГОСТ 34-311 або інший
стандарт.
Пропозиції:
 1. Включити до нової редакції вказаного Наказу алгоритми SHA-1, SHA-256, SHA384, SHA-512 та їх об’єктні ідентифікатори;
 2.Чітко визначити алгоритм хешування за замовченням та алгоритм хешування
поля byKey структури ResponderID.
10