Если Ваша система основана на криптографических преобразованиях, квалифицирующим признаком чего является наличие сертификата ФАПСИ на используемые средства, или позиционирование разработчиком своих разработок, как шифровальных средств или СКЗИ,
В этом случае согласно закону, система является корпоративной системой ЭЦП и регулируется по Статье 17 закона "Об ЭЦП":
Статья 17.
2. Порядок использования электронных цифровых подписей в корпоративной информационной системе устанавливается решением владельца корпоративной информационной системы или соглашением участников этой системы.
Дополнительно в этом случае, согласно закону о лицензировании отдельных видов деятельности Вам необходимо получить:
1. Лицензию на право ведения деятельности, связанной с оказанием услуг, связанных с использованием ЭЦП.
2. Лицензию на деятельность УЦ.
Публичная система с использованием СКЗИ
По сравнению с предыдущим вариантом, накладывается дополнительное ограничение, связанное с необходимостью использовать только, сертифицированное программное обеспечение.
В случае использования внешнего УЦ, требование на получение лицензии на деятельность УЦ, снимается.
VI. Выводы
1. Единственной основой для регулирования порядка применения АСП остается Гражданский Кодекс РФ, содержащий отсылочные нормы, либо к действующему закону, регулирующему порядок применения АСП, либо к договору сторон.
2. Регулирование порядка применения одного из видов АСП - ЭЦП осуществляется законом "Об электронной цифровой подписи".
3. Регулирование порядка применения иных АСП, в том числе цифровой подписи - ЦП остается предметом договорного права, что непосредственно следует из текста ГК и закона об ЭЦП.
4. Большинство технологии цифровой подписи (ЦП) не являются технологией, регулирование которой предусмотрено законом об ЭЦП.
5. Регулирование порядка использования основных типов ЦП выглядит следующим образом.
Система без использования сертификатов
Система без использования шифровальных средств
Система с использованием шифровальных средств
Корпоративная
Публичная
Корпоративная
Публичная
I
I
I
I
Нет
Нет
№1
№1
Система с использованием сертификатов
Система без использования шифровальных средств
Система с использованием шифровальных средств
Корпоративная
Публичная
Корпоративная
Публичная
I
I
II
II
Нет
Нет
№1, №2
№1.
I - регулирование на основе договорных отношений
II - регулирование на основе закона об ЭЦП
Лицензия №1 - лицензия на деятельность по оказанию услуг, связанных с использованием ЭЦП.
Лицензия №2 - лицензия на деятельность УЦ.
Пример практического применения механизма электронно-цифровой подписи
Для чего это нужно
Столкнувшись с проблемой обеспечения контроля подлинности документов хранимых в БД, я довольно долго искал способ ее решения. Та информация, что встречается, слабо полезна новичкам, ибо имеет уклон либо в теорию/математику асимметричных алгоритмов шифрования, либо в юриспруденцию (да да, те самые законы об электронно-цифровой подписи). Попытаюсь в меру своих сил исправить положение.
Пример реализован в среде Delphi 6, СУБД Interbase/Firebird, компоненты доступа InterBase Express (IBX), шифрование - LockBox . Для получения хеша используется алгоритм MD5, шифрование RSA.
В БД заведена таблица документов DOCUMENTS, подлинность которых нам и нужно контролировать, таблица DOCUMENT_SIGNS - подписи документов определенными пользователями из таблицы USERS.
Логика работы
Пользователю генерируются/назначаются два ключа - открытый (публичный) и закрытый (приватный). Первый доступен всем (будет использоваться для проверки подлинности подписи и документа), а второй только пользователю. Для подписания документа вычисляется его хеш (шифрование всего полумегабайтного документа довольно ресурсоемко), этот хеш шифруется закрытым ключом
(сделать это - т.е. сформировать собственно подпись может только владелец ключа и никто кроме него) и вносится в таблицу DOCUMENT_SIGNS, привязываясь конкретному пользователю и документу. Если кто-либо хочет проверить подписан ли документ пользователем, или пользователь хочет проконтролировать неизменность документа - он расшифровывает подпись открытым ключом и сравнивает с хешем документа - если они совпали - документ аутентичен
Хеш документа вычисляется на сервере (что б не гонять зря данные) с помощью UDF. Для этого реализованы две функции - хеширование блоба (md5_blob) и хеширование строки (md5_string). Если документ хранится как блоб то все просто, а если как набор полей, то можно считать хеш от строки, состоящей из конкатенированных полей ( select md5_string(d.doc_f2||d.doc_f1) from documents d). В последнем случае помним: поля, на основании которых вычисляется хеш не должны быть nullable - null+value=null, сумма длин всех полей не более максимальной длинны строки СУБД.
Расшифровка подписи выполняется в клиентском приложении, но никто не мешает вынести их в udf.
Хеширование - в идеале необратимое преобразование позволяющее для данных переменной длинны вернуть однозначно соответствующее им данные фиксированного размера(дайджест, хеш), обычно 128 бит.
Пример
Пример состоит из двух приложений - клиентского и административного. Для его работы нужно иметь установленный сервер СУБД.
Администраторский интерфейс.
Генерация пар ключей, назначение публичного ключа пользователю, сохранение приватного ключа в файл. Важен размер ключа, для клиентского приложения он "зашит" в код (1024).
Клиентский интерфейс.
Подписание выбранного документа определенным пользователем, проверить подпись, снять подпись с документа.
Практическое применение может быть довольно разнообразным: подписание ключевых элементов БД для последующего "разбора полетов" в случае конфликтных ситуаций, организация внутреннего безбумажного документооборота организации, авторизация в приложениях с помощью "ключевой" дискеты...
Список использованной литературы:
1. Copyright, 2003, Мариуполь, Николай Пономаренко Статья для Delphi Plus
2. ФЗ «Об Электронной цифровой подписи» № 1-ФЗ от 10.01.2002 г.
3. Гражданский Кодекс РФ
4. Internet
Дата: 2019-07-30, просмотров: 150.
