3. Процедура формирования подписи по схеме Эль Гамаля не позволяет вычислять цифровые подписи под новыми сообщениями без знания секретного ключа (как в RSА).

Однако алгоритм цифровой подписи Эль Гамаля имеет и некоторые недостатки по сравнению со схемой подписи RSА. В частности, длина цифровой подписи получается в 1,5 раза больше, что, в свою очередь, увеличивает время ее вычисления.

Алгоритм цифровой подписи DSА

Алгоритм цифровой подписи DSА (Digital Signature Algorithm) предложен в 1991 г. в НИСТ США для использования в стандарте цифровой подписи DSS (Digital Signature Standard). Алгоритм DSА является развитием алгоритмов цифровой подписи Эль Гамаля и К.Шнорра.

Отправитель и получатель электронного документа используют при вычислении большие целые числа: G и Р простые числа, L бит каждое (512 < L < 1024); q - простое число длиной 160 бит (делитель числа (Р-1)). Числа G, Р, q являются открытыми и могут быть общими для всех пользователей сети.

Отправитель выбирает случайное целое число X, 1 < Х < q. Число Х является секретным ключом отправителя для формирования электронной цифровой подписи.

Затем отправитель вычисляет значение Y = GX mod P.

Число Y является открытым ключом для проверки подписи отправителя и передается всем получателям документов.

Этот алгоритм также предусматривает использование односторонней функции хэширования h(·). В стандарте DSS определен алгоритм безопасного хэширования SНА (Secure Hash Algorithm).

Для того чтобы подписать документ М, отправитель хэширует его в целое хэш-значение m: m = h(М), 1<m<q,

затем генерирует случайное целое число К, 1< К< q, и вычисляет число r:

r = (GK mod Р) mod q.

Затем отправитель вычисляет с помощью секретного ключа Х целое число s:

s = ((m + r * X)/K) mod q.

Пара чисел (r,s) образует цифровую подпись S = (r,s) под документом М.

Таким образом, подписанное сообщение представляет собой тройку чисел (М,r,s).

Получатель подписанного сообщения (М,r,s) проверяет выполнение условий 0 < r < q, 0 < s < q и отвергает подпись, если хотя бы одно из этих условий не выполнено. Затем получатель вычисляет значение

w = (1/s) mod q, хэш-значение m = h(М) и числа

u1 = (m * w) mod q; u2 = (r * w) mod q.

Далее получатель с помощью открытого ключа Y вычисляет значение

v = ((Gu1 * Yu2 ) mod Р) mod q и проверяет выполнение условия v =r.

Если условие v=r выполняется, тогда подпись S=(r,s) под документом М признается получателем подлинной.

Можно строго математически доказать, что последнее равенство будет выполняться тогда, и только тогда, когда подпись S=(r,s) под документом М получена с помощью именно того секретного ключа X, из которого был получен открытый ключ Y. Таким образом, можно надежно удостовериться, что отправитель сообщения владеет именно данным секретным ключом Х (не раскрывая при этом значения ключа X) и что отправитель подписал именно данный документ М.

По сравнению с алгоритмом цифровой подписи Эль Гамаля алгоритм DSА имеет следующие основные преимущества:

1. При любом допустимом уровне стойкости, т.е. при любой паре чисел G и Р (от 512 до 1024 бит), числа q, X, r, sимеют длину по 160 бит, сокращая длину подписи до 320 бит.

2. Большинство операций с числами К, r, s, Х при вычислении подписи производится по модулю числа q длиной 160 бит, что сокращает время вычисления подписи.

3. При проверке подписи большинство операций с числами u1, u2, v, w также производится по модулю числа qдлиной 160 бит, что сокращает объем памяти и время вычисления.

Недостатком алгоритма DSА является то, что при подписывании и при проверке подписи приходится выполнять сложные операции деления по модулю q: s = ((m + rX)/K) (mod q), w = (1/s) (mod q), что не позволяет получать максимальное быстродействие.

Следует отметить, что реальное исполнение алгоритма DSА может быть ускорено с помощью выполнения предварительных вычислений. Заметим, что значение r не зависит от сообщения М и его хэш-значения m. Можно заранее создать строку случайных значений К и затем для каждого из этих значений вычислить значения r. Можно также заранее вычислить обратные значения К-1 для каждого из значений К. Затем, при поступлении сообщения М, можно вычислить значение s для данных значений r и К-1. Эти предварительные вычисления значительно ускоряют работу алгоритма DSА.

Отечественный стандарт цифровой подписи ГОСТ Р 34.10-94

Отечественный стандарт цифровой подписи обозначается как ГОСТ Р 34.10-94. Алгоритм цифровой подписи, определяемый этим стандартом, концептуально близок к алгоритму DSА. В нем используются следующие параметры:

р - большое простое число длиной от 509 до 512 бит либо от 1020 до 1024 бит;

q - простой сомножитель числа (р-1), имеющий длину 254...256 бит;

а - любое число, меньшее (р-1), причем такое, что аq mod p = 1;

х - некоторое число, меньшее q;

у = аx mod р.

Кроме того, этот алгоритм использует однонаправленную хэш-функцию Н(х). Стандарт ГОСТ Р 34.11-94 определяет хэш-функцию, основанную на использовании стандартного симметричного алгоритма ГОСТ 28147-89.

Первые три параметра р, q, а являются открытыми и могут быть общими для всех пользователей сети. Число х является секретным ключом. Число у является открытым ключом. Чтобы подписать некоторое сообщение m, а затем проверить подпись, выполняются следующие шаги.

1. Пользователь А генерирует случайное число k, причем k<q.

2. Пользователь А вычисляет значения 

r = (аk mod p) mod p;

s = (х * r + k (Н(m))) mod p.

Если Н(m) mod q = 0, то значение Н(m) mod q принимают равным единице. Если r = 0, то выбирают другое значение k и начинают снова. Цифровая подпись представляет собой два числа: r mod 2256 и

s mod 2256.

Пользователь А отправляет эти числа пользователю В.

3. Пользователь В проверяет полученную подпись, вычисляя

v = Н(m)q-2 mod q;

z1 = (s * v) mod q;

z2 = ((q-r) * v) mod q;

u = ((аz1 * уz2 ) mod р) mod p.

Если u = r, то подпись считается верной.

Различие между этим алгоритмом и алгоритмом DSА заключается в том, что в DSА s = (k-1 (х * r + (Н(m)))) mod q, что приводит к другому уравнению верификации.

Следует также отметить, что в отечественном стандарте ЭЦП параметр q имеет длину 256 бит. Западных криптографов вполне устраивает q длиной примерно 160 бит. Различие в значениях параметра q является отражением стремления разработчиков отечественного стандарта к получению более безопасной подписи.

Этот отечественный стандарт вступил в действие c начала 1995 г.

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



7. Безопасность электронной коммерции

Одним из видов электронного бизнеса считается электронная коммерция. В соответствии с документами ООН, бизнес признается электронным, если хотя бы две его составляющие из четырех (производство товара или услуги, маркетинг, доставка и расчеты) осуществляются с помощью Интернета. Поэтому в такой интерпретации обычно полагают, что покупка относится к электронной коммерции, если, как минимум, маркетинг (организация спроса) и расчеты производятся средствами Интернета. Более узкая трактовка понятия «электронная коммерция» характеризует системы безналичных расчетов на основе пластиковых карт.

Ключевым вопросом для внедрения электронной коммерции является безопасность.

Высокий уровень мошенничества в Интернете является сдерживающим фактором развития электронной коммерции. Покупатели, торговля и банки боятся пользоваться этой технологией из-за опасности понести финансовые потери. Люди главным образом используют Интернет в качестве информационного канала для получения интересующей их информации. Лишь немногим более 2% всех поисков по каталогам и БД в Интернете заканчиваются покупками.

Приведем классификацию возможных типов мошенничества в электронной коммерции:

· транзакции (операции безналичных расчетов), выполненные мошенниками с использованием правильных реквизитов карточки (номер карточки, срок ее действия и т.п.);

· получение данных о клиенте через взлом БД торговых предприятий или путем перехвата сообщений покупателя, содержащих его персональные данные;

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

· увеличение стоимости товара по отношению к предлагавшейся покупателю цене или повтор списаний со счета клиента;

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

Протокол SSL

Протокол SSL (Secure Socket Layer) был разработан американской компанией Netscape Communications. SSL обеспечивает защиту данных между сервисными протоколами (такими как HTTP, NNTP, FTP и т.д.) и транспортными протоколами (TCP/IP) с помощью современной криптографии в соединениях «точка-точка». Ранее можно было без особых технических ухищрений просматривать данные, которыми обмениваются между собой клиенты и серверы. Был даже придуман специальный термин для этого - «sniffer».

Протокол SSL предназначен для решения традиционных задач обеспечения защиты информационного взаимодействия:

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

· после установления соединения между сервером и клиентом весь информационный поток между ними должен быть защищен от несанкционированного доступа;

· и наконец, при обмене информацией стороны должны быть уверены в отсутствии случайных или умышленных искажений при ее передаче.

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

Конфиденциальность информации, передаваемой по установленному защищенному соединению, обеспечивается путем шифрования потока данных на сформированном общем ключе с использованием симметричных криптографических алгоритмов (например, RC4_128, RC4_40, RC2_128, RC2_40, DES40 и др.). Контроль целостности передаваемых блоков данных производится за счет использования так называемых кодов аутентификации сообщений (Message Autentification Code, или MAC), вычисляемых с помощью хэш-функций (например, MD5).

Протокол SSL включает два этапа взаимодействия сторон защищаемого соединения:

· установление SSL-сессии;

· защита потока данных.

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

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

Наиболее распространенным пакетом программ для поддержки SSL является SSLeay. Он содержит исходный код на C, который может быть встроен в такие приложения, как Telnet и FTP.

В SSL используется криптография с открытым (публичным) ключом, также известная как асимметричная криптография. Она использует два ключа: один для шифрования, другой для расшифровывания сообщения. Два ключа математически связаны таким образом, что данные, зашифрованные с использованием одного ключа, могут быть расшифрованы только с использованием другого, парного первому. Каждый пользователь имеет два ключа открытый и секретный (приватный). Пользователь делает доступным открытый ключ любому корреспонденту сети. Пользователь и любой корреспондент, имеющий открытый ключ, могут быть уверены, что данные, зашифрованные с помощью открытого ключа, могут быть расшифрованы только с использованием секретного ключа.

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

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

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

· имя человека/организации, выпускающей сертификат;

· субъект сертификата (для кого был выпущен данный сертификат);

· публичный ключ субъекта;

· некоторые временные параметры (срок действия сертификата и т.п.).

Сертификат «подписывается» приватным ключом человека (или организации), который выпускает сертификаты. Организации, которые производят подобные операции, называются Certificate authority (CA). Если в стандартном Web-браузере, который поддерживает SSL, зайти в раздел security, то там можно увидеть список известных организаций, которые «подписывают» сертификаты. Технически создать свою собственную CA достаточно просто, но также необходимо уладить юридическую сторону дела, и с этим могут возникнуть серьезные проблемы.

SSL на сегодня является наиболее распространенным протоколом, используемым при построении систем электронной коммерции. С его помощью осуществляется 99% всех транзакций. Широкое распространение SSL объясняется в первую очередь тем, что он является составной частью всех браузеров и Web-серверов. Другое достоинство SSL - простота протокола и высокая скорость реализации транзакции.

В то же время, SSL обладает рядом существенных недостатков:

· покупатель не аутентифицируется;

· продавец аутентифицируется только по URL;

· цифровая подпись используется только при аутентификации в начале установления SSL-сессии. Для доказательства проведения транзакции при возникновении конфликтных ситуаций требуется либо хранить весь диалог покупателя и продавца, что дорого с точки зрения ресурсов памяти и на практике не используется, либо хранить бумажные копии, подтверждающие получение товара покупателем;

· не обеспечивается конфиденциальность данных о реквизитах карты для продавца.

Протокол SET

Другой протокол безопасных транзакций в Интернете SET (Security Electronics Transaction). SET основан на использовании цифровых сертификатов по стандарту Х.509.

Протокол выполнения защищенных транзакций SET является стандартом, разработанным компаниями MasterCard и VISA при значительном участии IBM, GlobeSet и других партнеров. Он позволяет покупателям приобретать товары через Интернет, используя самый защищенный на настоящее время механизм выполнения платежей. SET является открытым стандартным многосторонним протоколом для проведения безопасных платежей с использованием пластиковых карточек в Интернет. SET обеспечивает кросс-аутентификацию счета держателя карточки, продавца и банка продавца для проверки готовности оплаты товара, целостность и секретность сообщения, шифрование ценных и уязвимых данных. Поэтому SET можно назвать стандартной технологией или системой протоколов выполнения безопасных платежей с использованием пластиковых карточек через Интернет.

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

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

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

В связи с перечисленными выше проблемами компании VISA и MasterCard вместе с другими компаниями, занимающимися техническими вопросами (например IBM, которая является ключевым разработчиком в развитии протокола SET), определили спецификацию и набор протоколов стандарта SET. Эта открытая спецификация очень быстро стала де-факто стандартом для электронной коммерции. В этой спецификации шифрование информации обеспечивает ее конфиденциальность. Цифровая подпись и сертификаты обеспечивают идентификацию и аутентификацию (проверку подлинности) участников транзакций. Цифровая подпись также используется для обеспечения целостности данных. Открытый набор протоколов используется для обеспечения взаимодействия между реализациями разных производителей.

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

· секретность данных оплаты и конфиденциальность информации заказа, переданной вместе с данными об оплате;

· сохранение целостности данных платежей; целостность обеспечивается при помощи цифровой подписи;

· специальную криптографию с открытым ключом для проведения аутентификации;

· аутентификацию держателя по кредитной карточке, которая обеспечивается применением цифровой подписи и сертификатов держателя карточек;

· аутентификацию продавца и его возможности принимать платежи по пластиковым карточкам с применением цифровой подписи и сертификатов продавца;

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

· готовность оплаты транзакций в результате аутентификации сертификата с открытым ключом для всех сторон;

· безопасность передачи данных посредством преимущественного использования криптографии.

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

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

· открытый, полностью документированный стандарт для финансовой индустрии;

· основан на международных стандартах платежных систем;

· опирается на существующие в финансовой отрасли технологии и правовые механизмы.

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

Рисунок 21 - Процесс взаимодействия участников платежной операции

В этом процессе участвуют следующие объекты:

· Держатель карточки - покупатель, делающий заказ.

· Банк покупателя финансовая структура, которая выпустила кредитную карточку для покупателя.

· Продавец электронный магазин, предлагающий товары и услуги.

· Банк продавца финансовая структура, занимающаяся обслуживанием операций продавца.

· Платежный шлюз система, контролируемая обычно банком продавца, которая обрабатывает запросы от продавца и взаимодействует с банком покупателя.

· Сертифицирующая организация доверительная структура, выдающая и проверяющая сертификаты.

Взаимоотношения участников операции показаны на рисунке непрерывными линиями (взаимодействия описанные стандартом или протоколом SET) и пунктирными линиями (некоторые возможные операции).

Динамика взаимоотношений и информационных потоков в соответствии со спецификацией стандарта SET включает следующие действия:

1. Участники запрашивают и получают сертификаты от сертифицирующей организации.

2. Владелец пластиковой карточки просматривает электронный каталог, выбирает товары и посылает заказ продавцу.

3. Продавец предъявляет свой сертификат владельцу карточки в качестве удостоверения.

4. Владелец карточки предъявляет свой сертификат продавцу.

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

6. После проверки платежный шлюз возвращает результаты продавцу.

7. Некоторое время спустя, продавец требует у платежного шлюза выполнить одну или более финансовых операций. Шлюз посылает запрос на перевод определенной суммы из банка покупателя в банк продавца.

Представленная схема взаимодействия подкрепляется в части информационной безопасности спецификацией Chip Electronic Commerce, созданной для использования смарт-карточек стандарта EMV в Интернете.



Список литературы

1. Аутентификация. Теория и практика обеспечения безопасного доступа к информационным ресурсам. - Москва: Наука, 2015. - 552 c.

2. Бабаш, А. В. Информационная безопасность (+ CD-ROM) / А.В. Бабаш, Е.К. Баранова, Ю.Н. Мельников. - М.: КноРус, 2013. - 136 c.

3. Безопасность России. Правовые, социально-экономические и научно-технические аспекты. Основы информационно-психологической безопасности: моногр. . - М.: Международный гуманитарный фонд "Знание", 2014. - 416 c.

4. Безопасность ребенка. Информационный стенд. - М.: Сфера, Ранок, 2013. - 787 c.

5. Васильков, А. В. Безопасность и управление доступом в информационных системах / А.В. Васильков, И.А. Васильков. - М.: Форум, 2015. - 368 c.

6. Гафнер, В. В. Информационная безопасность / В.В. Гафнер. - М.: Феникс, 2014. - 336 c.

7. Гришина, Н. В. Информационная безопасность предприятия. Учебное пособие / Н.В. Гришина. - М.: Форум, 2015. - 240 c.

8. Девянин, П.Н. Анализ безопасности управления доступом и информационными потоками в компьютерных системах / П.Н. Девянин. - М.: Радио и связь, 2013. - 176 c.

9. Ефимова, Л. Л. Информационная безопасность детей. Российский и зарубежный опыт / Л.Л. Ефимова, А С. А, Кочерга. - М.: Юнити-Дана, 2013. - 240 c.

10. Информационная безопасность открытых систем. В 2 томах. Том 1. Угрозы, уязвимости, атаки и подходы к защите / С.В. Запечников и др. - Москва: Машиностроение, 2016. - 536 c.

11. Информационная безопасность открытых систем. В 2 томах. Том 2. Средства защиты в сетях / С.В. Запечников и др. - Москва: СПб. [и др.] : Питер, 2014. - 560 c.

12. Мельников, В. П. Информационная безопасность / В.П. Мельников, С.А. Клейменов, А.М. Петраков. - М.: Academia, 2017. - 336 c.

13. Мельников, В. П. Информационная безопасность / В.П. Мельников, С.А. Клейменов, А.М. Петраков. - М.: Академия, 2013. - 336 c.

14. Мельников, В. П. Информационная безопасность и защита информации / В.П. Мельников, С.А. Клейменов, А.М. Петраков. - Москва: Мир, 2013. - 336 c.

15. Мельников, В.П. Информационная безопасность и защита информации / В.П. Мельников. - М.: Академия (Academia), 2016. - 282 c.

16. Партыка, Т. Л. Информационная безопасность / Т.Л. Партыка, И.И. Попов. - М.: Форум, Инфра-М, 2016. - 368 c.

17. Партыка, Т.Л. Информационная безопасность / Т.Л. Партыка, И.И. Попов. - М.: ИНФРА-М, 2015. - 368 c.

18. Петров, Сергей Викторович; Кисляков Павел Александрович Информационная Безопасность / Александрович Петров Сергей Викторович; Кисляков Павел. - Москва: СПб. [и др.] : Питер, 2013. - 329 c.

Размещено на Allbest.ru