Разработка программных модулей ведения технической документации в дистанциях сигнализации и связи

Размещено на http://www.allbest.ru/

1. АКТУАЛЬНОСТЬ РАЗРАБОТКИ И ВНЕДРЕНИЯ АВТОМАТИЗИРОВАННЫХ РАБОЧИХ МЕСТ ВЕДЕНИЯ ТЕХНИЧЕСКОЙ ДОКУМЕНТАЦИИ В ДИСТАНЦИЯХ СИГНАЛИЗАЦИИ И СВЯЗИ

сигнализация связь автоматизированный

1.1 Требования, предъявляемые к автоматизированным системам ведения документации

Программно-аппаратные комплексы автоматизированных рабочих мест ведения технической документации должны отвечать определенным требованиям, указанным в техническом задании на их разработку. Условно эти требования можно разделить на требования к системе в целом и на требования к задачам и функциям, выполняемым модулями АРМ.

К требованиям к системе в целом относят:

1) Требования к структуре и функционированию.

а) Комплекс задач АРМ_ВТД должен обеспечивать преемственность первичных баз технической документации АРМ ВТД предыдущих версий. На каждом предприятии (ШЧ и Ш) ПЭВМ должна быть установлена непосредственно на рабочем месте инженера группы технической документации, начальника участка и (или) старших электромехаников бригад СЦБ, старшего электромеханика дорожной лаборатории, а также в местах согласования и утверждения изменений в схемах.

б) Комплекс задач АРМ_ВТД должен разрабатываться с учетом особенностей систем с распределенным хранением данных.

в) Программное обеспечение (ПО) АРМ-ВТД должно состоять из двух взаимодействующих программ АРМ-сервер и АРМ-клиент и иметь модульную структуру. Схема взаимодействия АРМ-сервера и АРМ-клиентов приведена на рис. 1.1. Список программных модулей АРМ-ВТД должен охватывает весь комплекс задач, возникающих при выполнении типовых технологических процедур с технической документацией, задач, возникающих при компьютерной реализации и группы задач, решение которых становится возможным при переходе на новые технологии. Программно-аппаратный комплекс АРМ-ВТД будет иметь структуру, представленную на рис. 1.2 и 1.3 (альтернативные варианты).

Рис. 1.1. Схема взаимодействия АРМ-сервера и АРМ-клиента

Рис. 1.2. Архитектура рабочих мест программного комплекса АРМ-ВТД с использованием сервера службы Ш.

Рис. 1.3. Архитектура рабочих мест программного комплекса АРМ-ВТД с использованием серверов ШЧ.

Основными группами задач являются следующие:

- базовые задачи;

- задачи ведения;

- задачи синтеза схем размещения;

- задачи автоматизации перевода ТД в электронный вид;

- задачи ведения технической оснащенности.

2) Требования к численности и квалификации персонала системы и режиму его работы.

3) Требования к показателям назначения.

4) Требования к надежности функционирования.

5) Требования к безопасности.

6) Требования к эргономике и технической эстетике.

7) Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы.

8) Требования к защите информации от несанкционированного доступа.

9) Требования к сохранности информации при авариях.

10) Требования к средствам защиты от внешних воздействий.

11) Требования к стандартизации и унификации.

Задачами и функциями АРМов ведения технической документации

являются следующие:

1. работа графического редактора;

2. первичный ввод принципиальных схем;

3. создание и ведение базы технической документации (БДТД);

4. работа с указаниями;

5. работа с инструкциями;

6. работа с телеграммами;

7. формирование спецификаций по базе ТД;

8. сверка технической документации;

9. первичный ввод схем напольного оборудования, аппаратов управления, блочных планов на машинные носители с использованием графического редактора;

10. обеспечение режимов локальной вычислительной сети (ЛВС) и системы передачи данных (СПД);

- согласование и утверждение ТД с использованием дорожной компьютерной сети;

- использование электронной подписи для согласования и утверждения ТД;

11. сервисное обеспечение комплекса;

12. использование сканированных отображений.

1.2 Структура программных комплексов ведения технической документации

Изложенные выше требования определяют структуру интегрированной системы автоматизации проектирования и ведения технической документации, в состав которой входит программный комплекс АРМ-ВТД. Программное обеспечение АРМов имеет модульную структуру, и его состав зависит от функциональных задач АРМа.

В структуре АРМа можно выделить следующие подсистемы (модули):

M1 - программа интерактивного меню для доступа ко всем режимам АРМа. Меню программы настраивается на конкретную конфигурацию модулей. Стандартными вариантами конфигурации являются АРМ по ведению указаний (АРМ-У), АРМ по ведению ТД в дистанциях сигнализации и связи (АРМ-ШЧТД), АРМ по ведению ТД в службе Ш (АРМ-ШТД), АРМ для проектирования ТД на устройства железнодорожной автоматики и телемеханики (АРМ-П).

М2 - модуль ведения баз технической документации, объектов, спецификаций и т.д. Данный модуль формирует структуру баз и обеспечивает режимы хранения, архивирования, доступа и защиты информации. В базу данных вводится эксплуатационная и проектная документация, включая описи по объектам автоматизации, по системам автоматики и чертежам, а также Журнал учета изменений действующих устройств СЦБ, куда вводятся данные обо всех изменениях в документации. Ввод новых принципиальных и монтажных схем на машинных носителях должен осуществлять по следующей технологии, регламентированной инструкцией ЦШ-617 [3]: созданные с помощью АРМа схемы выводятся на бумажные носители (создаются контрольные экземпляры). Контрольные экземпляры согласовываются и утверждаются в порядке, установленном вышеупомянутой инструкцией; производится сверка утвержденной схемы контрольного экземпляра на бумажном носителе со схемой-оригиналом, находящейся в базе данных АРМа; указываются фамилии исполнителей, согласовавших и утвердивших лиц, инвентарный номер, наименование чертежа и другие данные. Делается отметка о соответствии схемы-оригинала в файле графического изображения со схемой контрольного экземпляра на бумажном носителе с указанием фамилии исполнителя и даты; файл графического изображения схемы-оригинала помещается в базу данных и архив на машинных носителях. Работники, имеющие допуск к работе на АРМ-ВТД, должны пройти соответствующее обучение и выполнять правила работы, методы защиты и хранения компьютерной информационной базы. Список лиц, имеющих допуск к базе данных, утверждается руководством службы сигнализации и связи железной дороги.

M5 - модуль обеспечения режимов работы создаваемых АРМов в локальной сети и дорожной сети передачи данных. Служит для передачи схем, указаний, инструкций, данных по объектам и оборудованию и другой информации, передаваемой АРМами. Данный модуль основан на использовании TCP/IP протокола.

M6 - модуль “Источник указаний” - обеспечивает формирование и ведение базы данных коллективного пользования (БДКП) “Указания”. Служит для работы с базой данных, содержащей указания, включающие текстовую и графическую части, информацию о дате их поступления, источнике, области их применения и др. Модуль поддерживает функции поиска по указаниям (по номеру указания, дате выхода, текстовой строке, системе (устройству), на которое распространяется указание). Обладает системой фильтров списка.

M7 - модуль “Источник инструкций и телеграмм” обеспечивает формирование и ведение базы данных “Инструкций” и “Телеграмм”. Служит для разработки и хранения поступивших или созданных инструкций и телеграмм. Поддерживает режимы поиска, а для инструкций также ввод графической информации.

M8 - модуль формирования технической оснащенности дистанции на основе автоматической обработки первичной базы технической документации, включая схему технической оснащенности дистанции (СТОД). Естественно необходимым для автоматического формирования СТОД являются созданные списки по объектам дистанции (списки станций, перегонов, переездов) и введенные схематические планы станций.

M9 - модуль формирования заказных спецификаций на любой объект, систему или устройство по имеющейся технической документации. Заказные спецификации выбираются из библиотеки, созданной на основе ГОСТ. Использование данных БДКП по производителям оборудования, возможности поиска в базе данных, формирований списков по заданным фильтрам, автоматическое заполнение информации с возможностью редактирования.

M10 - модуль планирования и учета работы с “Указаниями”, обеспечивающий все режимы внесения изменений в существующую документацию, определенные инструкцией ЦШ-617. Внесение изменений в действующие принципиальные и монтажные схемы экземпляра дистанции сигнализации и связи, выполненные на машинных носителях, должно осуществляться в следующем порядке: со схемы оригинала выполняется копия, помещаемая в специальный файл; средствами графического редактора на копии схемы-оригинала осуществляется внесение изменений и создается новый файл схемы с изменениями, который выводится на бумажные носители (контрольный экземпляр); оба файла хранятся в базе данных АРМа до момента утверждения схемы с изменениями на бумажном носителе (контрольного экземпляра) и включений в действующие устройства, после чего первоначальный файл помещается в архив, а на его место в базе данных остается файл системы с изменениями, которая становится схемой-оригиналом. [3]

M11 - модуль сканирования технической документации и формирования “подложки” с возможностью ее редактирования графическими редакторами.

Работа с указаниями и другой технической документацией, связанных с безопасностью движения поездов, предъявляет повышенные требования к сохранности и подлинности информации, содержащейся в документах. Криптографические методы защиты данных и применение электронной цифровой подписи (ЭЦП) для аутентификации ТД позволяют повысить надежность систем электронного документооборота.

1.3 Электронная цифровая подпись как средство аутентификации электронных документов

Юридический статус ЭЦП в России был закреплен 10 января 2002 года, когда президент РФ федеральный закон "Об электронной цифровой подписи". Основная идея данного закона состоит в том, что электронная подпись юридически приравнивается к графической. Таким образом, на информацию, подписанную электронной цифровой подписью, распространяются все традиционные процессуальные функции подписи.

Закон об электронной цифровой подписи ставит целью "обеспечение правовых условий для использования электронных цифровых подписей в процессах обмена электронными сообщениями, при соблюдении которых электронная цифровая подпись признается равнозначной собственноручной подписи" в документе на бумажном носителе.[22] Требуется также обеспечение правовых условий предоставления услуг по удостоверению электронных цифровых подписей.

Менее формально электронную подпись можно определить как алгоритм, с помощью которого автор сообщения (официально он именуется владельцем ЭЦП) "подписывает" сообщение. По подписи получатель сообщения может удостовериться, что сообщение подписал именно автор, а не кто-то другой. ЭЦП гарантирует, что подписанный электронный документ нельзя ни подделать, ни изменить.

Первый государственный стандарт на электронную подпись начал действовать на территории РФ с 1 января 1995 года (ГОСТ Р 34.10-94) вместе со вспомогательными стандартами в данной области (в том числе со стандартом вычисления так называемой хеш-функции).[4] Криптостойкость ЭЦП по ГОСТ Р 34.10-94 была основана на сложности решения задачи дискретного логарифмирования. Однако в связи с дальнейшим развитием математического аппарата теории чисел были найдены алгоритмы, позволяющие значительно ускорить процесс вычисления секретного ключа, участвующего в формировании ЭЦП, что снизило надежность электронной подписи. Таким образом, потребовалась новые процедуры синтеза и проверки ЭЦП, значительно более защищенные с точки зрения возможности взлома.

Новый госстандарт на ЭЦП ГОСТ Р 34.10-2001 начал действовать с 2002 года. В его основу положена задача нахождения кратности точек эллиптической кривой d по известным точкам C и P, где C=kP. Данная проблема еще мало изучена, однако на сегодняшний день не существует сведений об эффективных методах определения кратности k. Иными словами, надежность новой ЭЦП полностью зависит от технической сложности решения упомянутой задачи.

Поскольку широкое распространение технологии ЭЦП стало возможным только благодаря закреплению ее юридического статуса, необходимо рассмотреть правовые вопросы применения электронной подписи в корпоративных структурах более подробно.

2. РАЗРАБОТКА СХЕМЫ ДОКУМЕНТООБОРОТА В ХОЗЯЙСТВЕ СИГНАЛИЗАЦИИ И СВЯЗИ

2.1 Правовые аспекты применения электронной подписи для заверения технических документов

Федеральный закон "Об электронно-цифровой подписи" ставит своей целью обеспечение правовых условий для использования электронной цифровой подписи в процессах обмена электронными данными, при соблюдении которых электронная цифровая подпись признается юридически равнозначной подписи физического лица, в том числе полномочного представителя юридического лица.[22] Использование ЭЦП для заверения электронных документов регулируется соглашением сторон в рамках данного федерального закона.

Закон оперирует с такими специфическими понятиями, как открытый и закрытый ключи, сертификат ключа подписи, сертификат на средство ЭЦП и др.

Так, электронная цифровая подпись представляет собой, согласно терминологии закона, аналог собственноручной подписи физического лица или полномочного представителя юридического лица, представленный как последовательность символов, полученная в результате криптографического преобразования электронных данных с использованием закрытого ключа ЭЦП, которая позволяет пользователю открытого ключа ЭЦП установить целостность и достоверность этой информации, а также владельца закрытого ключа ЭЦП;

средства ЭЦП есть программные и (или) технические средства, реализующие функции изготовления ключей, выработки и (или) проверки ЭЦП;

закрытый ключ ЭЦП - это последовательность символов, предназначенная для выработки ЭЦП и известная только его владельцу;

открытый ключ ЭЦП - предназначенная для проверки ЭЦП общедоступная последовательность символов, однозначно связанная с соответствующим закрытым ключом ЭЦП;

пользователь открытого ключа ЭЦП - лицо, использующее открытый ключ ЭЦП;

сертификат открытого ключа ЭЦП (сертификат ключа подписи) - документ, подтверждающий принадлежность открытого ключа ЭЦП владельцу сертификата ключа подписи, выданный и заверенный удостоверяющим центром;

владелец сертификата ключа подписи (владелец сертификата) - лицо, на имя которого выдан сертификат ключа подписи, и которое владеет закрытым ключом ЭЦП, соответствующим открытому ключу, указанному в сертификате;

удостоверяющий центр открытых ключей электронной цифровой подписи (удостоверяющий центр) - юридическое лицо, выдающее сертификат ключа подписи, удостоверяющий принадлежность открытого ключа ЭЦП;

сертификат на средство ЭЦП - документ, выданный по правилам соответствующей системы сертификации, удостоверяющий соответствие этого средства специальным требованиям и позволяющий в течение определенного срока действия использовать данное средство в качестве инструмента изготовления ключей, выработки и (или) проверки ЭЦП;

подтверждение подлинности ЭЦП - положительный результат проверки правильности ЭЦП, осуществляемой пользователем открытого ключа ЭЦП или удостоверяющим центром путем использования сертифицированного открытого ключа подписи;

корпоративная информационная система (КИС) - информационная система, в которой условия документооборота, выработки и применения ЭЦП, выдачи сертификатов ключей подписи устанавливаются соглашениями участников системы. Хозяйство сигнализации и связи железных дорог России в современных условиях представляет собой типичную КИС, в которой огромные объемы ТД (в объеме до 50 млн. листов формата А4) требуют эффективных методов работы с ними.

Глава III закона посвящена регулированию деятельности удостоверяющих центров - организаций, занимающихся созданием, распространением и архивным хранением закрытых и открытых ключей пользователей ЭЦП, а также вспомогательных средств ЭЦП (параметров эллиптической кривой, простых чисел и др.).

Удостоверяющий центр подтверждает принадлежность открытого ключа ЭЦП конкретному лицу посредством выдачи сертификата ключа подписи. Он также обязан подтверждать подлинность ЭЦП по запросу пользователя открытого ключа ЭЦП.

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

При выпуске сертификата ключа подписи удостоверяющий центр обязан подтвердить, во-первых, достоверность сведений, содержащихся в сертификате, во-вторых, соответствие сертификата требованиям данного Федерального закона и иных нормативных правовых актов Российской Федерации, в-третьих, соответствие закрытого ключа ЭЦП открытому ключу и наличие в удостоверяющем центре всех сведений о владельце сертификата.

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

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

В корпоративных информационных системах удостоверяющий центр обеспечивает доступ к реестру сертификатов ключей подписи только участникам этой системы.

Удостоверяющий центр вправе самостоятельно осуществлять ведение реестра сертификатов ключей подписи или обратиться к услугам иного лица для осуществления этой деятельности. Он обязан выдавать и заверять бумажные копии сертификатов ключей подписи по требованиям уполномоченных государственных органов и судов. При этом указывается место и дата заверения. Бумажная копия заверяется собственноручной подписью должностного лица удостоверяющего центра и его печатью.

2.2 Организационно-технические вопросы создания системы удостоверяющего центра

Системы управления электронной технической документацией (СУ ЭТДО) должны обеспечивать защиту электронной технической информации и документации от подделки при помощи электронной цифровой подписи (ЭЦП). СУ ЭТДО является частью корпоративной информационной системы (КИС), поэтому на нее распространяются все требования законодательства и нормативной базы, регламентирующие применение ЭЦП в КИС. КИС должна включать в себя:

* полномочное подразделение на предприятии или совместный орган (в случае ведения совместных проектов несколькими предприятиями), обеспечивающий комплекс мероприятий и все необходимые виды работ по обеспечению безопасности и защиты ЭТД в КИС. Таким органом должен являться удостоверяющий центр

* программный или программно-технический комплекс, реализующий функции ЭЦП и обеспечивающий реализацию прикладных протоколов применения ЭЦП

* нормативную, методическую и эксплуатационную документацию, обеспечивающую применение ЭЦП в КИС.

Подпись и передача ЭТД, представляющих государственную, военную или

коммерческую тайну должна проводиться в соответствии с требованиями настоящего стандарта, существующей нормативной базы и законодательства в области защиты 7 ГОСТ Р 5.103-2002 информации.

3. ПРОГРАММНАЯ РЕАЛИЗАЦИЯ СРЕДСТВ СИНТЕЗА И ПРОВЕРКИ ЭЛЕКТРОННОЙ ПОДПИСИ

3.1 Описание механизмов синтеза и проверки электронной подписи по ГОСТ Р 34.10-2001

3.1.1 Термины и определения

Действующий в настоящее время в области криптографической защиты информации государственный стандарт ГОСТ Р 34.10-2001 был принят и введен в действие постановлением Госстандарта России от 12.09.2001 г. Данный ГОСТ пришел на смену ГОСТ Р 34.10-94, действовавшему с 1 января 1995 года. Необходимость разработки нового стандарта была вызвана потребностью повысить стойкость электронной цифровой подписи (ЭЦП) к несанкционированным изменениям.

В данном стандарте используются следующие термины:

1) дополнение - строка бит, формируемая из цифровой подписи и произвольного текстового поля;

2) ключ подписи - элемент секретных данных, специфичный для субъекта и используемый только данным субъектом в процессе формирования ЭЦП;

3) ключ проверки - элемент данных, математически связанный с ключом подписи и используемый проверяющей стороной в процессе проверки цифровой подписи;

4) параметр схемы ЭЦП - элемент данных, общий для всех субъектов схемы цифровой подписи, известный или доступный всем этим субъектам;

5) подписанное сообщение - набор элементов данных, состоящий из сообщения и дополнения, являющегося частью сообщения;

6) последовательность псевдослучайных чисел - последовательность чисел, полученная в результате выполнения некоторого арифметического (вычислительного) процесса, используемая в конкретном случае вместо последовательности случайных чисел;

7) последовательность случайных чисел - последовательность чисел, каждое из которых не может быть предсказано (вычислено) только на основе знания предшествующих ему чисел данной последовательности;

8) процесс проверки подписи - процесс, в качестве исходных данных которого используются подписанное сообщение, ключ проверки и параметры схемы ЭЦП и результатом которого является заключение о правильности или ошибочности цифровой подписи;

9) процесс формирования подписи - процесс, в качестве исходных данных которого используются сообщение, ключ подписи и параметры схемы ЭЦП, а в результате формируется ЭЦП;

10) свидетельство - элемент данных, представляющий соответствующее доказательство достоверности (недостоверности) подписи проверяющей стороне;

11) случайное число - число, выбранное из определенного набора чисел таким образом, что каждое число из данного набора может быть выбрано с одинаковой вероятностью;

12) сообщение - строка бит ограниченной длины;

13) хэш-код - строка бит, являющаяся выходным результатом хэш-функции;

14) хэш-функция - функция, отображающая строки бит в строки бит фиксированной длины и удовлетворяющая следующим свойствам:

а) по данному значению функции сложно вычислить исходные данные, отображенные в это значение;

б) для заданных исходных данных трудно найти другие исходные данные, отображаемые с тем же результатом;

в) трудно найти какую-либо пару исходных данных с одинаковым значением хэш-функции.

15) электронная цифровая подпись - строка бит, полученная в результате процесса формирования подписи. Данная строка имеет внутреннюю структуру, зависящую от конкретного механизма формирования подписи.

Общепризнанная схема (модель) электронной цифровой подписи (см. б ИСО/МЭК 14888-1) охватывает три процесса:

-- генерация ключей (подписи и проверки);

-- формирование подписи;

-- проверка подписи.

Рассмотрим последовательно механизмы формирования и проверки ЭЦП в соответствии с ГОСТ Р 34.10-2001.

3.1.2 Реализация механизма синтеза ЭЦП по ГОСТ Р 34.10-2001

Для получения электронной цифровой подписи под сообщением необходимо выполнить следующие действия:

1) вычислить хэш-код сообщения М:

(3.1)

2) вычислить целое число б, двоичным представлением которого является вектор , и определить

(3.2)

Если е = 0, то определить е = 1.

3) сгенерировать случайное (псевдослучайное) целое число k, удовлетворяющее неравенству

0<k<q (3.3)

4) вычислить точку эллиптической кривой С = kР и определить

(3.4)

где х -- x-координата точки С. Если r = О, то вернуться к п. 3).

5) вычислить значение

(3.5)

Если s = 0, то вернуться к п. 3).

6) вычислить двоичные векторы и , соответствующие r и s, и определить цифровую подпись как конкатенацию двух двоичных векторов. Исходными данными этого процесса являются ключ подписи d и подписываемое сообщение М, а выходным результатом -- электронная цифровая подпись ж. Схематическое представление процесса формирования ЭЦП приведено на рис. 3.1.

Рис. 3.1. Схема процесса формирования ЭЦП.

3.1.3 Выработка простых чисел и вычисление хэш-функции

Необходимость при вычислении и проверке ЭЦП использовать случайные (а когда это не представляется возможным, псевдослучайные) простые числа k, p, q, являющиеся наиболее слабым звеном в системе криптозащиты ЭЦП от подделки, делает задачу генерации этих чисел отдельной достаточно сложной проблемой. Рассмотрим рекомендуемую ГОСТ Р 34.10-2001 схему вычисления простых случайных чисел.

Получение таких чисел осуществляется с использованием линейного конгруэнтного датчика по модулю 2¹⁶ (или по модулю 2³²) x_n = bx_n-1 + с. При этом изначально задаются начальное состояние х₀ и параметр датчика с.

Эти величины необходимо зафиксировать (запомнить) для возможности проведения проверки того, что простые числа получены по установленной процедуре.

Процедура позволяет получать простые числа p длины t 17 битов с простым делителем q длины t/2 битов числа р-1 (операция означает округление операнда до ближайшего целого в меньшую сторону, - то же, но с округлением в большую сторону).

Получение чисел осуществляется с использованием линейного конгруэнтного датчика х_n = (19381 x_n-1 + с) (mod 2¹⁶). Задаются число х₀ с условием 0 x₀ 2¹⁶ и нечетное число с условием 0 с 2¹⁶.

Процедура вычисления включает в себя следующие шаги:

1) ₀ = X₀;

2) Вычисление последовательности чисел (t₀ , t₁ , ..., t₅ ) по правилу t₀ = t.

Если t_i 17, то t_i+1 = t_i /2

Если t_i 17, то s = 1.

3) Нахождение наименьшего простого числа р длиной t битов.

4) Вычисление m = s - 1.

5) Вычисление r_m = t_m /16

6) Вычисление последовательности (y₁ ,......,y_rm ) по рекурсивному правилу y_i+1 = (19381y_i + c) (mod 2¹⁶).

7) Определение y_m = y_i*2¹⁶ⁱ.

8) Вычисление y₀ = y_rm.

9) Вычисление N = 2^t-1/p_m+1 ^t-1 y_m) / (p_m+1 2¹⁶). Если N нечетно, то N=N+1;

10) Присваивание k = 0;

11) Вычисление р_m = p_m+1*(N+k) + 1;

12) Если р_m2^t , то переход к шагу 6;

13) Проверка условий 2^p*(N+k) *(mod p_m) = 1 и 2^(N+k)*(mod p_m ) 1.

Если хотя бы одно из условий не выполнено, то k =k + 2 и переход к шагу 11.

Если оба условия выполнены, то m = m - 1.

14) Если m0 , то переход к шагу 5.

Если m < 0, то p₀ - искомое простое число р и р₁- искомое простое число q.

Таким образом за 14 шагов вычисления формализуется процедура выработки простых чисел, необходимых для надежной работы алгоритмов ЭЦП.

Еще одной важной задачей, решение которой необходимо для синтеза и проверки электронной подписи, является вычисление хэш-функции подписываемого документа, представляемого сообщением М. Существует несколько различных алгоритмов, позволяющих выполнить данную задачу. ГОСТ Р 34.11 - 94 предлагает один из наиболее защищенных с точки зрения криптостойкости методов определения хэш-функции. Рассмотрим его отдельно.

Функция h, называемая хэш-функцией, отображает двоичные строки произвольной конечной длины в выходы небольшой (например, 64, 128, 160,192, 224, 256, 384, 512) фиксированной длины, называемые хэш величинами. Хэш-величины служат как компактный репрезентативный образ входной двоичной строки, и их можно использовать, как если бы они однозначно отождествлялись с этой строкой (сообщением).

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

В ГОСТ Р 34.11 - 94 используется метод последовательного хеширования, использующий хэш-функцию с фиксированным размером входа (см. рис.3.2), то есть функцию сжатия с коэффициентом 2.

Рис. 3.2. Метод последовательного хеширования.

Если необходимо хешировать сообщение m = (m₁, m₂, … m_i), то хеширование выполняется следующим образом:

Если последний блок меньше чем n бит, то он набивается одним из существующих методов до достижения длины кратной n . В отличие от стандартных предпосылок, что сообщение разбито на блоки и произведена набивка последнего блока (форматирование входа априори), если необходимо, до начала хеширования, в ГОСТ Р 34.11 - 94 процедура хеширования ожидает конца сообщения (форматирование входного сообщения апостериори). Набивка производится следующим образом: последний блок сдвигается вправо, а затем набивается нулями до достижения длины в 256 бит.

Параллельно рассчитываются контрольная сумма, представляющая собой сумму всех блоков сообщения (последний суммируется уже набитым), по правилу А + В mod 2^k, где k = |A| = |B|, а |A| и |B| - битовые длины слов A и B (далее на рисунках эту операцию будем обозначать значком ), и битовая длина хешируемого сообщения, приводимая по 256 mod 2 (так называемое MD - усиление), которые в финальной функции сжатия используются для вычисления итогового хеша (см. рис. 3.3).

Рис. 3.3. Общая схема функции хеширования по ГОСТ Р 34.11 - 94.

Функция сжатия внутренних итераций ч отображает два слова длиной 256 бит в одно слово длиной 256 бит:

ч: {01}²⁵⁶Ч{01}²⁵⁶>{01}²⁵⁶

и состоит из трех процедур (см. рис. 3.4):

- перемешивающего преобразования;

- шифрующего преобразования;

- генерирования ключей.



Рис. 3.4. Структура функции сжатия в ГОСТ Р 34.11 - 94.

Рассмотрим данные процедуры более детально.

а) Перемешивающее преобразование.

Здесь использована модифицированная для хеширования перестановка Фейстеля, где n-битный вход разделяется на k блоков по r бит, так чтобы kl=n:

где p - входное сообщение. Пусть вход A = (A₁, A₂, … A_l)Ѓё{01}ⁿ, а выход B=(B₁, B₂, … B_l)Ѓё{01}ⁿ, тогда F_p(A) описывается следующим образом:

Схематически модифицированная функция Фейстеля представлена на рис. 3.5.



Рис. 3.5. Модифицированная схема Фейстеля для хеширования.

Перемешивающее преобразование имеет вид

где шⁱ - j-я степень преобразования ш. Схематически данное преобразование представлено на рис. 5.6.

Перемешивающее преобразование ГОСТ Р 34.11 - 94

Заметим (см. рис. 3.6), что s_i выводится из h_i-1. (см. рис. 3.4). Функция ш:{01}²⁵⁶>{01}²⁵⁶ преобразует слово з₁₆ || … || з₁, з_i Ѓё {01}¹⁶, i=1,…,16 в слово (см. рис. 3.7).

Рис. 3.7 Функция ш перемешивающего преобразования.

б) Шифрующее преобразование

Основным функциональным предназначением шифрующего преобразования является получение s_i из h_i-1. Пусть , где , а , где . Тогда

где - шифрование по ГОСТ 28147 - 89 в режиме простой замены. Схематически это изображено на рис. 3.8.

Рис. 3.8. Шифрующее преобразование.

Функция сжатия финальной итерации производит итоговую хеш-величину, зависящую от результата хеширования последовательным методом, контрольной суммы по модулю два и длины сообщения в битах, приведенной по mod 2²⁵⁶:

- последний набитый нулями блок (см. рис. 3.3). Сначала вычисляется битовая длина последнего (ненабитого) блока сообщения |m_l|?256 бит. Если |m_l|<256, то производится его набивка справа нулями до достижения длины 256 бит и получается новый блок . Вычисляются итоговая контрольная сумма и длина всего сообщения . Параллельно выполняется последняя итерация . Затем вычисляются перемешивающие преобразования и , давая в результате итоговую хеш-величину h_итог.

Подведем итог всему вышесказанному, составив алгоритм вычисления хеш-функции. Изначально известными величинами являются двоичное сообщение M , блоки замен для шифрования в режиме простой замены по ГОСТ 28147-89 и начальный вектор . На выходе необходимо получить хеш-величину h_итог для сообщения M.

На первом этапе вычислений происходит инициализация алгоритма:

Затем, пока текущая длина сообщения М не менее 256 бит, циклически производятся следующие действия:

1) итерация метода последовательного хеширования: ;

2) итерация вычисления длины сообщения: ;

3) итерация вычисления контрольной суммы: .

Как только длина сообщения уменьшается до 256 бит, наступает завершающая стадия вычислений (функция сжатия финальных итераций):

1) вычисляется полная длина сообщения: ;

2) набивается последний блок (до 256 бит): ;

3) вычисляется контрольная сумма сообщения: ;

4) выполняется последняя итерация: ;

5) полученная хеш-функция усиливается (для повышения ее криптостойкости): ;

6) вычисляется итоговая хеш-величина за счет преобразования усиленной: .

3.1.4 Реализация механизма проверки ЭЦП по ГОСТ Р 34.10-2001

Для проверки цифровой подписи ж под полученным сообщением М необходимо выполнить следующие действия:

1) по полученной подписи вычислить целые числа r и s. Если выполнены неравенства 0< r <q и 0<s <q, то перейти к следующему шагу. В противном случае подпись неверна.

2) вычислить хэш-код полученного сообщения М (см. (3.1));

3) вычислить целое число б, двоичным представлением которого является вектор , и определить e (см. (3.2));

Если е = 0, то определить е = 1.

4) вычислить значение ; (3.6)

5) вычислить значения и ; (3.7)

6) вычислить точку эллиптической кривой C = z₁P + z₂Q и определить

(3.8)

где x_с -- x-координата точки С.

7) если выполнено равенство R = r, то подпись принимается, в противном случае подпись неверна.

Исходными данными этого процесса являются подписанное сообщение М, ЭЦП ж и ключ проверки Q, а выходным результатом -- свидетельство о достоверности или ошибочности данной подписи.

Схематическое представление процесса проверки электронной цифровой подписи приведено на рис. 3.9.

ГОСТ Р 34.10-2001 подробно описывает алгоритмы работы с электронной подписью, что позволяет дать их программную или аппаратную интерпретацию. Аппаратная реализация методов синтеза и проверки ЭЦП является более предпочтительной с точки зрения высокой скорости ее действия по сравнению с программной, однако имеет значительно более высокую стоимость в разработке. Наиболее широкое распространение получило все же программное воплощение методов ЭЦП в связи с бурным развитием вычислительной техники, когда высокие скорости вычислений позволяют снизить время синтеза и проверки ЭЦП, вычисление хеш-функций до долей секунды.

Рис. 3.9. Схема процесса проверки ЭЦП.

Реализацию механизмов ЭЦП, встроенных в АРМ-ВТД (модуль электронной подписи), предпочтительно выполнить в программном виде в соответствии с действующими государственными стандартами в этой области. Рассмотрим более детально построение модуля ЭЦП в следующей главе.

3.2 Разработка процедур подписи и аутентификации сообщения (документа)

3.2.1 Метод синтеза ЭЦП

Для разработки программных модулей ЭЦП используем объектно-ориентированный язык программирования высокого уровня C++ на платформе Borland C++ Builder 5/6.

Пусть создаваемый базовый класс электронной подписи будет иметь следующий вид (шаблон):

class sign {

public:

sign() { }; // конструктор

~sign() { }; // деструктор класса

void SignUp(void); // метод подписи сообщения mes

bool TestSign(void); // метод проверки подписи {s,r1}

cBigNumber unsigned hyper hash(long double l, unsigned long* h);

// метод вычисления хеш-функции

cBigNumber p, q, k, x, r, r1, y, v, s1, s2, s, u, a, len; // данные (переменные)

cBigNumber GetRandDig(cBigNumber p); // генерация случайного числа

/* изначально заданы p, q, x, a, len, используются при работе методов остальные, все данные имеют открытый доступ для всех объектов*/

unsigned hyper* mes, h; // mes - подписываемое сообщение, h -

// итоговая хеш-функция

};

Структура метода void SignUp(void) определена ГОСТ Р 34.10-2001 и представляет из себя следующий код (в упрощенном виде):

void sign::SignUp(void)

{

h = hash(len, mes); // вызов метода хеш-функции

k = GetSimpleNum(p); // вычисление случайного числа k

AddPoint(xp, yp, a, p); // Вычисление координат точки эллипт. кривой С=kP

ee = ee.setmod(hh, qq); // e = h mod q

r = r.setmod(xcc, qq); // r = xcc mod q

s = s.setmod((r*dd + kk*ee), qq); // s = (r*d + k*e) mod q

}

Метод SignUp сохраняет вычисленную ЭЦП в паре {s, r1}.

3.2.2 Метод вычисления хеш-функции

Метод SignUp использует вызов метода хеш-функции void hash(void), который должен быть определен следующим образом (см. п. 3.1.3.):

unsigned hyper sign::hash(long double l, unsigned hyper* h)

{ unsigned hyper *h1, *h2; unsigned hyper ret = NULL;

if(((h1 = new unsigned hyper[l]) == NULL) || // выделение памяти под

((h2 = new unsigned hyper[HASHSTEP+1]) == NULL)) // сообщение

ShowMessage("Хэширование файла невозможно! Недостаточно памяти.");

for(unsigned hyper a=0; a<=HASHSTEP; a++)

{ // цикл побитового сдвига слов сообщения - реализация

h1[0] = h[0]>>1; // функции сжатия (см. п. 3.1.3)

for(unsigned hyper i=1; i<=l-1; i++)

{ h1[i] = h[i]>>1;

if((h[i-1])&1) h1[i] = h1[i]|DIGIT2_63;

}

for(unsigned hyper v=0; v<=l-1; v++) h[v] = h1[v];

h2[a] = h[0];

for(unsigned hyper f=1; f<=l-1 ; f++)

h2[a] = addmod2(h2[a], h[f]);

} // окончание работы функции сжатия

ret = h2[0];

for(unsigned int f1=1; f1<=HASHSTEP; f1++)

ret = addmod2(ret, h2[f1]); // функция финальной итерации

delete h1; // освобождение памяти

return ret; }

3.2.3 Метод проверки ЭЦП

При работе метод проверки подписи bool TestSign(void) использует те же поля p, q, k, a, p, h, что и метод SignUp. Данный метод имеет следующий вид (упрощенно):

bool sign::TestSign(void)

{

h = hash(len, mes); // вызов метода хеш-функции

ee = ee.setmod(hh, qq);

vv = ObrPoMod(ee, qq); // вычисление

z1 = z1.setmod(s*vv, qq); // вспомогательных

z2 = qq - (r*vv).setmod(r*vv, qq); // величин

u = mod(mod(powl(a, s1)*powl(y, s2), p), q); // u=( (a^s1*y^s2) mod p) mod q

C = AddPoint(xp, yp, z1, aa, pp) + AddPoint(xq, yq, z2, aa, pp);

// Вычисление точки C = z₁P + z₂Q

R = R.setmod(tmpX, qq);

if(R == r) return true; // при совпадении R и r подпись считается

return false; // действительной

}

Работа описанных методов происходит при условии, что в массив mes записано исходное сообщение (документ), в переменной len записана его длина, известен открытый ключ пользователя Q = {x_q, y_q}, простые числа p, q, коэффициент эллиптической кривой a, выдаваемые удостоверяющим центром. Таким образом, необходимо произвести ряд подготовительных операций перед вычислением и проверкой ЭЦП, что выполняют вспомогательные методы, описанные в следующей главе.

3.3 Увязка модуля ЭЦП с внешней системой

3.3.1 Операции над большими числами

Высокая криптостойкость ЭЦП достигается использованием в алгоритме кроме всего прочего больших чисел (длиной 256 и 512 бит), не поддерживаемых имеющимися встроенными в язык программирования средствами. Таким образом, возникает задача создания новых типов данных, позволяющих хранить большие числа и производить над ними следующие операции: сложение, вычитание, умножение, деление, деление по модулю (mod), сложение по модулю два, возведение в степень. Основным требованием к выполнению операций является минимизация временных затрат на их производство.

Максимальное число, получаемое при возведении в степень с 256-битным основанием {01}²⁵⁶ 256-битного же числа {01}²⁵⁶ (данное действие выполняется при синтезе и проверке ЭЦП), имеет длину 256*2²⁵⁶ бит, т.е. 2²⁶⁴ бит или ~3*10⁷⁹ байт, что недостижимо на современном уровне развития вычислительной техники. Следовательно, произвести вычисление значения выражения вида a^x mod q напрямую технически невозможно. Воспользуемся поэтому следующим свойством операции mod:

 (3.9)

для возведения в степень по модулю. Данное рекуррентное выражение программно реализуется следующим образом:

inline TBigInt powmod(TBigInt a, TBigInt x, TBigInt q)

{ if(x > 1)

return mod((powmod(a, x - 1, q))*(mod(a,q)), q);

else

return mod(a, q);

},

где mod(a, q) - функция деления по модулю, описываемая следующим образом:

inline TBigInt mod(TBigInt a, TBigInt b) { return (a - (a / b)*b); }

Аргументы и возвращаемое значение методов mod, powmod являются большими целыми числами типа (класса) cBigNumber, для которого определены операции сложения, умножения, деления нацело, деления по модулю, возведения в степень по модулю, побитового сдвига и других. Число хранится в объекте типа cBigNumber в виде массива типа long.

Методы, реализующие указанные операции, имеют следующие наименования:

“+”, “-”, “*”, “/” - арифметические действия;

setmod(a, b) - деление a по модулю b;

s.setpowmod(a, b) - возведение s в степень a по модулю b;

ObrPoMod(a, b) - функция деления числа, обратного a, по модулю b;

3.3.2 Алгоритм умножения точки эллиптической кривой на скаляр

Необходимость производить вычисления со сложением точек эллиптической кривой потребовала расширить круг операций с большими числами и ввести следующие функции:

SumEllip(xa, ya, xb, yb, a, p) - функция сложения точек A{x_a, y_b} и B{x_b, y_b} кривой коэффициентом a и модулем p;

AddPoint(xa, ya, k, a, p) - функция умножения точки A{x_a, y_b} на число k.

Сложение двух точек A{x₁, y₁} и B{x₂, y₂}, результатом которого является точка С{x₃, y₃}, производится следующим образом:

а) если x₁ ? x₂, то

(3.9)

б) если x₁=x₂ и y₁=y₂?0, то

(3.10)

В соответствии с данным определением реализуем сложение точек программным спрособом:

inline void SumEllip(cBigNumber x1, cBigNumber y1, cBigNumber x2, cBigNumber y2, cBigNumber a, cBigNumber p)

{ cBigNumber up, dwn, lam;

if(x1 != x2)

{ if(y2 >= y1) up = up.setmod(y2 - y1, p);

else up = p - up.setmod(y1 - y2, p);

if(x2 >= x1) dwn = ObrPoMod(x2 - x1, p);

else dwn = p - ObrPoMod(x1 - x2, p);

lam = lam.setmod(up*dwn, p);

tmpX = tmpX.setmod(lam*lam - x1 - x2, p);

if(lam*(x1 - tmpX) - y1 >= 0)

tmpY = tmpY.setmod(lam*(x1 - tmpX) - y1, p);

else

tmpY = p - tmpY.setmod(lam*(-x1 + tmpX) + y1, p); }

if((x1 == x2) && (y1 == y2) && (y1 != 0))

{ up = up.setmod(x1*x1*3 + a, p); // числитель

dwn = ObrPoMod(2*y1, p); // знаменатель

lam = lam.setmod(up*dwn, p);

tmpX = tmpX.setmod(lam*lam - x1*2, p);

if(lam*(x1 - tmpX) - y1 >= 0) tmpY = tmpY.setmod(lam*(x1 - tmpX) - y1, p);

else tmpY = p - tmpY.setmod(lam*(-x1 + tmpX) + y1, p);

} return; }

Данная функция сохраняет результат в паре tmpX, tmpY.

Произведение точки P на число k есть сложение точки P само с собой k раз:

(3.11)

Поскольку на практике k - достаточно большое число, произвести вычисление Q напрямую за приемлемое время невозможно. Представленная ниже программная реализация алгоритма вычисления кратной точки эллиптической кривой позволяет за число операций порядка 2*L, где L - длина используемых чисел (в данном случае 256 бит), произвести данный расчет. Алгоритм использует метод последовательного сдвига и сложения, использующего двоичное представление координат точек.

inline void AddPoint(cBigNumber x, cBigNumber y, cBigNumber k, cBigNumber a, cBigNumber p)

{ cBigNumber xp = x, yp = y; bool isFirstZero = false;

if(((k.item(1))&1) == 0)

{ isFirstZero = true;}

else { tmpAddX = xp;

tmpAddY = yp; }

for(long i = 1; i<=8; i++) // 8 - число слов типа long в координате

for(long j = 1; j<=32; j++) // 32 - число бит в элементе типа long

{ if((i == 1) && (j == 1)); // пропускаем первый бит

else { SumEllip(xp, yp, xp, yp, a, p); // сложение P = 2*P

xp = tmpX; yp = tmpY;

if(((k.item(i))&(power2[j-1]))) // текущий бит установлен?

{ { if(isFirstZero) { SumEllip(xp, yp, xp, yp, a, p);

tmpAddX = tmpX; tmpAddY = tmpY;

isFirstZero = false; }

else { SumEllip(tmpAddX, tmpAddY, xp, yp, a, p); // накопление рез-та

tmpAddX = tmpX;

tmpAddY = tmpY; } } } } } return;}

3.3.3 Передача секретных параметров ЭЦП в модуль ЭЦП

Как было сказано в п. 1.3, модуль обеспечения режимов работы создаваемых АРМов в локальной сети и дорожной сети передачи данных ответственен за передачу схем, указаний, инструкций, различных данных по объектам и оборудованию и другой информации. Работа с данным модулем основана на передаче потоков информации. Последовательность необходимых для работы модуля ЭЦП входных данных передается в него посредством потока класса TStream или производных от него.

Метод void ExtractFromStream(void) служит для организации взаимодействия методов SignUp и TestSign с внешней программной средой и имеет следующее описание:

void sign::ExtractFromStream(void)

{ long double buf[5]; // sizeof(long double) - размер типа long double

p = buf[0]; // ES - указатель на передаваемый поток класса TMemoryStream

...