administration
|
About |
Photo theory |
Альбомы |
Разное |
Freeware |
administration |
|
В последнее время, в бизнесе все чаще стали применяться механизмы криптозащиты информации.
Термин информационная безопасность(ИБ) стал все чаще появляться на страницах газет, вакансиях, размещаемых на сайтах работодаталей, резюме. ИБ все больше и больше входит в моду, во многом на эту мельницу льют воду вирусописатели, потому что наиболее частые, яркие и громкие моменты связаны, именно с этим направлением. Но к счастью или к сожалению, ущерб от них не настолько критичен для бизнеса и(или) государства, как неправильно организованная работа с системами защиты информации. Утечки данных связанные с потерями, непредумышленными публикациями в открытых и доступных источниках и хранилищах, кражами, передачами несут в себе значительно более серьезные угрозы, во многом потому, что ставят под удар аутентичность подписей конкретных людей, сделок, документов, финансовых, сырьевых и других транзакций. И если дефейс (изменение главной или другой страницы сайта) сайта больше бьет по имиджу, то утечка конфиденциальных или секретных данных создает угрозу не только существованию бизнеса, но может поставить под угрозу и жизни людей.
Информационная безопасность - это широкий, юридически и технически сложный пласт знаний. Концептуально он сформулирован в "Доктрине информационной безопасности" от 09 сентября 2000 № Пр-1895. На тот момент времени ситуация в законодальстве была аховая, не четкие формулировки, недостаточная терминологическая формализованность, отсутствие судебной практики применения расследования инцидентов, многое делалось по наитию. Сейчас, в 2009 году, на момент написания статьи, ситуация с нормативными документами прояснилась, наработалась судебная и исполнительная практика по делам, реорганизованы службы занимающиеся сертификацией и лицензированием деятельности, закрыты дыры в законодательстве, которые оставляли неосвещенными методологию применения закона, фактически оставляя его за правовым полем, но хотя изменения за последние 10 лет произошли огромные, тем не менее законодательство попрежнему идет на шаг позади от практики, а в договорах банки, иногда допускают ошибки, которые либо нарушают законодательство, либо вовсе, делают договор с клиентом не действительным.
В данной статье, я хочу осветить нормы применения электронной цифровой подписи, не зарываясь в тенические детали, больше необходимого, также я не буду акцентировать внимание на упомянутых "дырах" и смысловых юридических нестыковках, хотя стоило бы, но тогда статья станет не о цифровой подписи, а о нюансах, связанных с практикой эксплуатации СЗИ и СКЗИ.
Основное регулирование осуществляется группой законов:
Основные терминологические определения можно почерпнуть из 3х источников:
В основе цифровой подписи лежит алгоритм шифрования данных. При использовании цифровой подписи используется 3 государственных стандарта: ГОСТ Р 34.10-2001 - является алгоритмом управляющим ключами и использущим процедуру выработки электронной подписи в соответствии со стандартом ГОСТ Р 34.11-94, который применяя алгоритм, описанный в стандарте ГОСТ 28147-89, вырабатывает некоторое большое число (хеш (от англ. hash)), однозначно обусловленное закрытым ключем владельца и текстом документа. Я не буду рассматривать протоколы шифрования и цифровой подписи, принятые в других государства, остановлюсь лишь, на протоколах и алгоритмах, официально принятых и разрешенных у нас в Российской Федерации, при обмене данными с государственными службами.
Стандарт цифровой подписи ГОСТ Р 34.10-2001, описывается в постановлении Госстандарта от 12 сентября 2001 года, за номером 380-ст и приходит на смену стандарту ГОСТ Р 34.10-94. Принципиальная разница между ними состоит в вычислителной сложности, если стандарт от 94 года требовал разложения на простые сомножители большого числа, то стандарт от 2001 года требует дискретного логарифмирования, последний значительно более "вычислительно сложнее" в силу того, что методик по объективно быстрой оптимизации процесса поиска, на данный момент времени, не существует. Этот переход позволил снизить длину ключа с 512 до 256 бит, при общем увеличении криптостойкости. На данный момент времени, рекомендовано примение двух длин ключей 256 бит для коммерческого применения и 512 для федерального.
Логика цифровой электронной подписи состоит в том, чтобы весь текст документа, со всеми контролируемыми ей полями, а также длина этого документа, была сведена в некоторое большое число, которое стояло бы в абсолютной зависимости от учтенных полей документа, его длины и закрытого ключа владельца. В этом простом утверждении заложена сложная математика, которая размывает возможности по криптоанализу закономерностей между текстом и хешом, к примеру, два докумена отличающиеся друг от друга лишь одним знаком, будут иметь абсолютно разные, не имеющие ничего общего, электронные подписи.
Однако, вполне очевидно, когда бОльшее преобразуется в меньшее, существует возможность получать одинаковые результаты при разных входных текстах. Это называется коллизия. Следующая идея, которая, обычно возникает, вслед за этим - это изменение исходного документа так, чтобы подпись осталась, как у оригинального. Теоретически такая возмозможность есть. Это серьезная проблема, которая с той или иной степенью эффективности решается любым алгоритмом хеширования - функции преобразующей текст документа на основе закрытого ключа в сообщение фиксированного размера, обычно кратного 256 битам (32 байтам).
Однако, это все практически не реально. Практически означает, что подобрать дополнительные символы в тексте так, чтобы документ не потерял свою смысловую ценность не реально, вероятность такого события оценивается в области 10 в -77 степени. Чуть-чуть легче обстоят дела с документом, который может не иметь смыслового ограничения, то есть может иметь, какое угодно безумное сообщение, вплоть до абсурдного набора нечитаемых двоичных данных, это примерно 10 в -39 степени. Иными словами, если перебирать по одному документу в секунду, то уйдет примерно 10 в 32 степени лет.
2008м году Florian Mendel, Norbert Pramstaller, Christian Rechberger из института прикладной обработки информации и коммуникаций, Австрия, вместе с Marchin Kontak и Janusz Szmidt факультета Кибенетики из института Математики и Криптологии военного университета Технологий, смогли сформулировать условия успешной атаки на алгоритм хеширования ГОСТ Р 34.11, повышающие вероятность до 10 в -30 степени, то есть улучшить до примерно 10 в 23 степени лет. Если учесть, что жизненный цикл коммерческого документа редко превышает несколько десятков лет, а точка невозврата в диапазоне от нескольких часов до нескольких лет, то можно себе представить осмысленность подобных атак в реальной жизни.
Однако, у электронной подписи есть одно уязвимое место. Оно определяется архитектурой, принципом, заложенным в логику работы. Проблема заключается в получении открытого ключа абонента, присылающего подписанный документ. Где и как можно удостериться, что проверочный ключ и документ принадлежат тому, с кем планируется вести дела, выяснить не представляется возможным. Злоумышленник может подсунуть свой открытый ключ, а затем от имени абонента, еще и подложить свой подписанный документ. Естественно, все сойдется, документ будет принят, будет ответоно подписан и... как говорится, ищи потом ветра в поле. Естественно, подобная ситуация умозрительна, по причине того, что такое построение взаимоотношений обычно не применяется, ну, пожалуй только, если вы не пользователь конференций и не активный эксплуататор PGP при обмене сообщениями в телеконференциях. Там применяется статистический метод подтверждения аутентичности абонента, когда есть возможность посмотреть на открытый ключ человека год назад, два года назад или за любой произвольный период времени и таким образом, практически исключить еденичные акты мошенничества со стороны злоумышленника.
Когда нет возможности убедиться в том, что аутентичность абонента корректна, в схему вводится третий участник: удостверяющий центр (УЦ). УЦ занимается аккумуляцией и отслеживанием статуса открытых ключей всех своих пользователей-клиентов.
На момент установления взаимоотношений между УЦ и его будущим пользователем, пользователь юридически, документально подтверждает свою аутентичность перед УЦ, в свою очередь УЦ предоставляет своему пользователю свой открытый ключ, которым он подписывает все исходящие из него по запросу пользователя открытые ключи, упакованные в сертификаты.
Сертификат - это оболочка или как его еще называют, контейнер в котором хранится достаточно большой объем информации относящегося к хранящемуся в нем ключу другого абонента, это могут быть имя, фамилия, отчество, фактический или юридический адрес, и так далее, обязательным полем для заполнения, в частности, входит дата истечения действия сертификата. Дата, после которого сертификат считается не действительным, а ключ содержащийся в нем устаревшим.
Каждый ключ должен действовать в течении ограниченного времени. Связанно это с тем, что по мере его эксплуатации, увеличивается, хоть и гипотетически, вероятность того, что на основе анализа подписанных документов, будет вычислен ключ. Значительно большая вероятность состоит в том, что ключ будет утерян или скопирован злоумышленником, а УЦ об этом не будет поставлен в известность. Таким образом, лимитируя время жизни ключа, УЦ обезопасивает себя и всех пользователей своего сервиса.
Идея работы УЦ во взаимоотношениях двух абонентов проста. Абонент1 доверяет УЦ, Абонент2 доверяет УЦ, и хотя оба они не доверяют друг другу, они оба могут быть уверены в том, что запрошенные ими открытые ключи друг друга принадлежат тем, друг другу.
Также, при осуществлении проверок, каждый из абонентов-пользователей УЦ, должен проверять сертификат на отзыв. Довольно редкий, но тем не менее, исключительно важный момент, когда ключ был утерян или скомпрометирован, каким либо образом, для предотвращения нарушения аутентичности, пользователь извещает УЦ о событии, после чего УЦ отзывает сертификат и перевыпускает новый. В результате чего, для всех остальных участников смена происходит прозрачно. При проверке, сообщения абонента, которому перевыпустили сертификат, каждый из участников сверяет, не был ли он отозван и если был, запрашивают и получают новый, также подписанный УЦ.
Все системы работающие в рамках УЦ, представляют собой систему на основе открытых ключей. Сокращенно она называется PKI (Public Key Infrastructure), термин устоявшийся и применяющийся наиболее часто на неофициальном уровне. В официальных документах вместо аббревиатуры PKI применяется аббревиатура от Инфраструктура Открытых Ключей - ИОК. Смысл обоих одинаков. В данном статье, буду применять официальное сокращение ИОК.
Группа абонентов в рамках одного УЦ не может пользоваться услугами другого УЦ. Это неудобство разрешается 3 базовыми способами, которые могут быть друг с другом перемешаны. Важно знать, что сертификаты доверия между УЦ могут быть внесены ограничивающие применение условия, например, невозможность проведения финансовых сделок или максимальный путь доверия. Количество УЦ, которые пользователь может проследить в стремлении проверить сужой сертификат. Это отмечается в специальных полях сертификата и проверяется прикладным ПО конечного пользователя.
Способы:
В России на данный момент, по информации ассоциации Электронных Торговых Площадок, насчитывается до 300 УЦ.
Помимо этой ассоциации в РФ действует мостовой УЦ, создан и поддерживается компанией ЗАО "АНК".
УЦ выходя на федеральный уровень, должен быть внесен в государственный реестр открытых ключей подписей, реестр которого можно посмотреть на сайте уполномоченного федерального органа Реестр УФО (уполномоченный федеральный орган), который является подразделением Минкомсвязи Российской Федерации.
(c) 2006-2009
by Foto-Workshop.
Перепечатка или цитирование свободно при
условии, указания ссылки на данный источник.
