Обязательно указать статус системы, как корпоративный

1.         Обязательно указать статус системы, как корпоративный.

2.         Указать, что доступ к систем возможен только при получении специального абонентского комплекта (программно-аппаратного обеспечения), отсутствие которого не позволяет подключаться к системе.

3.         Указать, что получить указанный абонентский комплект (скачать с сайта или получить иным, нежели при непосредственном контакте путем) пользователь может, только согласившись с правилами корпоративной системы, в т.ч. в электронном виде (путем акцепта предложения на сайте, направления письма или напрямую подписав договор).

В этом случае система определяется как корпоративная в независимости от каналов доступа (Интернет, телефон и т.д.), поскольку в этом случае сети публичных провайдеров используются исключительно как транспортная среда и не служат для оказания публичной услуги. Квалифицирующим признаком "корпоративная система", служит отсутствие возможности подключения к системе пользователя публичных систем без предварительного заключения договора.

Публичная система без использования СКЗИ.

Поскольку, как и в предыдущем случае Ваша система цифровой подписи не является СКЗИ или шифровальным средством, квалифицирующим признаком чего является наличие сертификата ФАПСИ на используемые средства, или позиционирование разработчиком своих разработок, как шифровальных средств или СКЗИ. Постольку регулирование ее использования находится вне сферы рассматриваемого закона, и регулируется аналогично случаю Системы без использования сертификатов или УЦ.

Корпоративная система с использованием СКЗИ

Если Ваша система основана на криптографических преобразованиях, квалифицирующим признаком чего является наличие сертификата ФАПСИ на используемые средства, или позиционирование разработчиком своих разработок, как шифровальных средств или СКЗИ,

В этом случае согласно закону, система является корпоративной системой ЭЦП и регулируется по Статье 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 - лицензия на деятельность УЦ.

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