<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Информационная безопасность &#187; Атака злоумышленник-посредник</title>
	<atom:link href="http://www.microfinance.uz/category/ataki-na-potok-dannyx/aktivnye-ataki/ataka-zloumyshlennik-posrednik/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.microfinance.uz</link>
	<description>Бухгалтерский и налоговый учёт</description>
	<lastBuildDate>Thu, 26 Jan 2012 14:59:26 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.1.2</generator>
		<item>
		<title>Атака злоумышленник-посредник</title>
		<link>http://www.microfinance.uz/ataka-zloumyshlennik-posrednik/</link>
		<comments>http://www.microfinance.uz/ataka-zloumyshlennik-posrednik/#comments</comments>
		<pubDate>Mon, 06 Oct 2008 07:23:22 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[Атака злоумышленник-посредник]]></category>

		<guid isPermaLink="false">http://www.microfinance.uz/ataka-zloumyshlennik-posrednik/</guid>
		<description><![CDATA[Данный вид атак — &#8220;Злоумышленник-посредник&#8221; (англ. man-in-the-middle) породил целое новое направление в электронном бизнесе, а именно, создание центров сертификации (СА — certification authority). Для понимания сущности атаки необходимо представление о функционировании криптографической системы с открытыми ключами. Подробные системы с открытыми ключами (или как они еще называются, асимметричные системы) описаны в части V, посвященной криптографии, в [...]]]></description>
			<content:encoded><![CDATA[<p>Данный вид атак — &#8220;Злоумышленник-посредник&#8221; (англ. man-in-the-middle) породил целое новое направление в электронном бизнесе, а именно, создание центров сертификации (СА — certification authority). Для понимания сущности атаки необходимо представление о функционировании криптографической системы с открытыми ключами. Подробные системы с открытыми ключами (или как они еще называются, асимметричные системы) описаны в части V, посвященной криптографии, в данной главе рассказ о них пойдет в общих чертах.<span id="more-91"></span><br />
Для успешного защищенного взаимодействия пары пользователей А и Б каждый из них должен сгенерировать пару криптографических ключей — открытый и закрытый, одним из которых можно только шифровать, другим — только дешифровать. Открытый ключ, в отличие от закрытого, не требует сохранения в конфиденциальности и отсылается удаленному адресату, т. е. А посылает свой открытый ключ (OA) Б, а Б посылает свой открытый ключ (ОБ) А. Теперь, если А хочет отправить Б зашифрованное сообщение, то он шифрует его открытым ключом ОБ. Зашифровать такое сообщение может кто угодно, поскольку открытый ключ известен всем желающим. Но дешифровать сообщение сможет только обладатель закрытого ключа Б (ЗБ), т. е. сам Б. Идентификацию отправителя, зашифровавшего сообщение, можно производить по второй паре ключей, т. е. А может вставить в сообщение для Б некий элемент, зашифрованный закрытым ключом А (ЗА), а так как у Б есть открытый ключ А, то он сможет дешифровать этот элемент и проверить, что он был действительно зашифрован обладателем секретного ключа А, т. е. самим А (на этом принципе работает механизм электронной цифровой подписи — ЭЦП).<br />
Данный защищенный механизм работает на основе убеждения, что открытый и закрытый ключи (OA и ЗА) принадлежит именно А, а открытый и закрытый ключи (ОБ и ЗБ) принадлежит именно Б. Однако иногда абоненты защищенной связи могут быть введены в заблуждение. Было уже отмечено, что открытые ключи не требуют сохранения их в конфиденциальности, и это действительно так. Однако отправление открытых ключей адресатам без доверенного контроля пути следования как раз и приводит к возможности реализации описываемой атаки.<br />
Предположим, что между А и Б имеется шлюз, управляемый злоумышленником — 3. Тогда при подготовке к общению в защищенном режиме (или при очередной смене ключей), когда А направляет Б свой открытый ключ, 3 перехватывает его и сохраняет у себя. Вместо этого он отправляет Б открытый ключ из пары, сгенерированной им самим, т. е. открытый ключ OA&#8217;. Когда Б направляет А свой открытый ключ, 3 также перехватывает его и сохраняет у себя. Вместо этого он отправляет А открытый ключ из другой пары сгенерированной им самим, т. е. открытый ключ ОБ&#8217;. В общем случае пары и ключи OA&#8217; и ОБ&#8217; могут совпадать — это не принципиально. Важно то, что теперь злоумышленник выступает прозрачным посредником в защищенном обмене информацией между А и Б, которые общаются друг с другом, не подозревая, что на самом деле их обмен данными контролируется. Для предотвращения атак подобного класса необходимо обеспечение доверенной доставки открытых ключей абонентам. Если А и Б находятся в личном контакте или имеют альтернативный доверенный канал обмена информацией, то задача решается достаточно просто: Но если они находятся в разных концах света и общаются только с помощью Интернета, задача доверенной доставки становится нетривиальной.<br />
Организации, занимающиеся сертификацией открытых ключей — СА, обеспечивают установку своей цифровой подписи на набор параметров пользователя сети, включающих его идентификационные данные и открытый ключ — т. н. цифровой сертификат. После этого сертификат с открытым ключом может быть свободно распространен без опасности подмены. Вопрос об удостоверении полномочий данного абонента в получении сертификата решаются, например, таким образом: пользователь устанавливает защищенную сессию связи с Веб-сервером СА, на сервере генерируется пара ключей, причем на сервере сохраняется только копия открытого ключа, а секретный ключ сохраняется только клиентом. После этого СА дополнительно альтернативными методами (факсом, обычной почтой и т. д.) получает подтверждение авторизованное™ пользователя, сгенерировавшего ключи, формирует для него сертификат, отсылает пользователю и сохраняет копию сертификата у себя для дальнейшего использования. Иногда СА сохраняет у себя и секретный ключ пользователя на случай его утери, но это уже предмет договорных отношений между самим пользователем и СА.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.microfinance.uz/ataka-zloumyshlennik-posrednik/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
	</channel>
</rss>

