КРАЯТ НА 20-ти век беше белязан от лавинообразно разпространение на интернет: скоростите на достъп нарастваха експоненциално, покриваха се все повече и повече нови територии и беше възможно да се установи между почти всеки две точки в света бърза връзкачрез мрежата. Но прехвърлянето на информация не беше сигурно; нападателите можеха да я прихванат, откраднат или променят. По това време започва да набира популярност идеята за организиране на надежден канал, който да използва публично достъпни комуникации за комуникация, но да защитава предаваните данни чрез използването на криптографски методи. Цената за организиране на такъв канал беше многократно по-малка от цената за полагане и поддръжка на специален физически канал. Така организирането на защитен комуникационен канал стана достъпно за средни и малки предприятия и дори физически лица.

ViPNet система

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

Ключовата структура е комбинирана и има симетрична схема на разпределение на ключовете, което дава възможност да се осигури твърда централизирана системасистема за управление и разпространение на публичен ключ и се използва като надеждна среда за работа на PKI. Приложните програми на системата ViPNet допълнително предоставят сигурни услуги в реално време за излъчване на съобщения, конференции и преговори; за услуги по гарантирана доставка на пощенска кореспонденция с процедури за електронен подпис и контрол на достъпа до документи; за услуги за автообработка за автоматично доставяне на файлове. Освен това, отделно проектирани криптографски функцииядра (подписване и криптиране) и внедрена поддръжка за MS Crypto API, ако е необходимо, могат да бъдат вградени директно в различни приложни системи (например системи за управление на електронни документи).

Системният софтуер ViPNet работи в Windows и Linux операционни среди.

ViPNet ПО ПЕРСОНАЛ

Всеки ViPNet CUSTOM компонент съдържа вградена защитна стена и система за наблюдение на мрежовата активност на приложенията, което ви позволява да получите надеждна разпределена система от защитни стени и персонални защитни стени.

За разрешаване на възможни конфликти на IP адреси в локални мрежи, включени в една защитена мрежа, ViPNet CUSTOM предлага разработена система от виртуални адреси. В много случаи това прави възможно опростяването на конфигурацията на приложния софтуер на потребителя, тъй като насложената виртуална мрежа с нейните виртуални адреси ще скрие реалната сложна структура на мрежата. ViPNet CUSTOM поддържа възможности за междумрежови връзки, което ви позволява да установите необходимите сигурни канали за комуникация между произволен брой защитени мрежи, изградени с помощта на ViPNet CUSTOM. Освен това системата осигурява защита на информацията в съвременни мултисервизни комуникационни мрежи, предоставящи услуги за IP телефония и аудио и видеоконференции. Поддържат се приоритизиране на трафика и H.323, Skinny протоколи.

Протокол Kerberos

Протоколи за удостоверяване:

3. Удостоверяване с публичен ключ

Описание на DSA

p = просто число с дължина L бита, където L е кратно на 64, в диапазона от 512 до 1024.

q= 160-битов прост - умножител p-1

g = , където h е всяко число, по-малко от p-1, за което повече от 1

x = число, по-малко от q

Използва се еднопосочна хеш функция: H(m).

Първите три параметъра, p, q, g, са отворени и могат да се споделят между потребителите на мрежата. Частният ключ е x, а публичният ключ е y. За да подпишете съобщение, m:

1. A генерира произволно число k, по-малко от q

2. А генерира

Неговият подпис са параметрите r и s, той ги изпраща на B

3. B проверява подписа чрез изчисляване

Ако v=r, тогава подписът е правилен.

Резюме

Системата за стандарти IPSec включва прогресивни техники и постижения в областта мрежова сигурност. Системата IPSec твърдо заема водеща позиция в набора от стандарти за създаване на VPN. Това се улеснява от неговата отворена конструкция, способна да включва всички нови постижения в областта на криптографията. IPsec ви позволява да защитите мрежата си от повечето мрежови атаки чрез „изпускане“ на чужди пакети, преди да достигнат IP слоя на получаващия компютър. Само пакети от регистрирани комуникационни партньори могат да влизат в защитения компютър или мрежа.

IPsec осигурява:

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

Работата в рамките на стандартите IPSec гарантира пълна защита на информационния поток от данни от подател до получател, затваряйки трафика за наблюдатели на междинни възлимрежи. VPN решения, базирани на IPSec протоколен стек, осигуряват изграждането на виртуални защитени мрежи, тяхната сигурна работа и интеграция с отворени комуникационни системи.

Защита на ниво приложение

SSL протокол

SSL протокол ( Сигурен гнездо Layer - слой със защитени гнезда), разработен от Netscape Communications с участието на RSA Data Security, е предназначен да реализира защитен обмен на информация в приложения клиент/сървър. На практика SSL се прилага широко само във връзка с ниво на приложение HHTP.

Функции за сигурност, предоставени от SSL протокола:

• криптиране на данни за предотвратяване на разкриването на чувствителни данни по време на предаване;
• подписване на данни за предотвратяване на разкриване на чувствителни данни по време на предаване;
• удостоверяване на клиента и сървъра.

SSL протоколът използва криптографски методизащита на информацията, за да се гарантира сигурността на обмена на информация. Този протокол извършва взаимно удостоверяване и гарантира поверителността и автентичността на предаваните данни. Ядрото на SSL протокола е технология за интегрирано използване на симетрични и асиметрични криптосистеми. Взаимното удостоверяване на страните се извършва чрез борсата цифрови сертификатипублични ключове на клиента и сървъра, удостоверени с цифров подпис на специални удостоверителни центрове. Поверителността се осигурява чрез криптиране на предаваните данни с помощта на симетрични сесийни ключове, които страните обменят при установяване на връзка. Автентичността и целостта на информацията се осигурява чрез формиране и проверка на електронен подпис. Алгоритъмът RSA и алгоритъмът на Дифи-Хелман се използват като алгоритми за асиметрично криптиране.

Фигура 9 Крипто-защитени тунели, формирани въз основа на SSL протокола

Според SSL протокола се създават крипто-защитени тунели между крайните точки виртуална мрежа. Клиентът и сървърът работят на компютри в крайните точки на тунела (фиг. 9)

Протоколът за SSL разговор има два основни етапа при формирането и поддържането на защитена връзка:

• установяване на SSL сесия;
• сигурно взаимодействие.

Първият етап се разработва преди директната защита на обмена на информация и се извършва съгласно протокола първоначален поздрав(Handshake Protocol), част от SSL протокола. Когато се установи повторно свързване, е възможно да се генерират нови сесийни ключове въз основа на старата споделена тайна.

В процеса на установяване на SSL сесия се решават следните задачи:

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

Фигура 10 Процес на удостоверяване на клиент от сървър

SSL протоколът предоставя два вида удостоверяване:

• удостоверяване на сървъра от клиента;
• удостоверяване на клиент от сървър.

Софтуерът клиент/сървър с активиран SSL може да използва стандартни криптографски техники с публичен ключ, за да провери дали сертификатът на сървъра/клиента и публичният ключ са валидни и са издадени от доверен сертифициращ орган. Пример за процеса на удостоверяване на клиента от сървъра е представен на фигура 10.

Диаграма на приложението на протокола

Преди да предаде съобщение по връзка за данни, съобщението преминава през следните стъпки на обработка:

1. Съобщението е фрагментирано на блокове, подходящи за обработка;

2. Данните са компресирани (по избор);

3. Генерира се MAC ключ;

4. Данните са криптирани с помощта на ключ;

1. С помощта на ключа данните се дешифрират;

2. MAC ключът е проверен;

3. Възниква декомпресия на данни (ако е използвана компресия);

4. Съобщението се сглобява от блокове и получателят го прочита.

Автентично раздаване на ключове

А, Клиент	C.A.Център за проверка	б, сървър
Генериране на двойка ключове за цифров подпис: . Трансфер до CA	- симетрична схема на криптиране; - отворена схема за криптиране; - CPU верига; - всякакви функции (за предпочитане ONF)	Генериране на двойка ключове за отворена схема за криптиране: . Трансфер до CA
К- произволен сесиен ключ.
		Ако , Че Ксе приема като автентичен споделен таен ключ

Работен етап

А		б
	Симетрична схемакриптиране
. . .	и т.н.	. . .

Атаки срещу SSL протокола

Подобно на други протоколи, SSL е податлив на атаки, свързани с ненадеждна софтуерна среда, въвеждане на програми за отметки и т.н.:

• Отговорна атака.Състои се от нападателя, който записва успешна комуникационна сесия между клиента и сървъра. По-късно той установява връзка със сървъра, използвайки записаните съобщения на клиента. Но чрез използване на уникален идентификатор на връзката, "nonce", SSL побеждава тази атака. Кодовете на тези идентификатори са дълги 128 бита, така че атакуващият трябва да запише 2^64 идентификатора, за да има 50% шанс да познае. Количество необходими записии ниската вероятност за отгатване правят тази атака безсмислена.
• Атака на протокола за ръкостискане.Нападателят може да се опита да повлияе на процеса на ръкостискане, така че страните да изберат различни алгоритми за криптиране. Тъй като много реализации поддържат експортирано криптиране, а някои дори поддържат 0-криптиране или MAC алгоритми, тези атаки са от голям интерес. За да извърши такава атака, нападателят трябва да подмени едно или повече съобщения за ръкостискане. Ако това се случи, клиентът и сървърът ще изчислят различни хеш стойности за съобщението за ръкостискане. В резултат на това страните няма да приемат „завършени“ съобщения една от друга. Без да знае тайната, нападателят няма да може да коригира съобщението „завършено“, така че атаката може да бъде открита.
• Разкриване на шифри. SSL зависи от няколко криптографски технологии. Криптирането с публичен ключ RSA се използва за препращане на сесийни ключове и удостоверяване клиент/сървър. Като шифър на сесията се използват различни криптографски алгоритми. Ако тези алгоритми бъдат успешно атакувани, SSL вече не може да се счита за защитен. Атаките срещу определени комуникационни сесии могат да бъдат извършени чрез запис на сесията и след това опит за отгатване на ключа на сесията или RSA ключа. При успех се отваря възможност за четене на предадената информация.
• Нападателят е в средата.Атаката Man-in-the-Middle включва три страни: клиент, сървър и нападател. Нападател, разположен между тях, може да прихване обмена на съобщения между клиента и сървъра. Атаката е ефективна само ако се използва алгоритъмът на Diffie-Halman за обмен на ключове, тъй като целостта на получената информация и нейният източник не могат да бъдат проверени. В случай на SSL такава атака е невъзможна поради използването на сертификати от сървъра, сертифицирани от сертифициращ орган.

TLS протокол

Цел на създаване и предимства

Целта на създаването на TLS е да подобри сигурността на SSL и да го направи по-точен и пълна дефиницияпротокол:

• По-надежден MAC алгоритъм
• По-подробни предупреждения
• По-ясни дефиниции на спецификациите на сивата зона

TLS предоставя следните подобрения на сигурността:

• Хеширащи ключове за удостоверяване на съобщения - TLS използва хеширане в кода за удостоверяване на съобщения (HMAC), за да предотврати промяната на записа, когато се предава през незащитена мрежа, като например Интернет. SSL версия 3.0 също поддържа удостоверяване на съобщения чрез ключове, но HMAC се счита за по-сигурен от MAC функцията, използвана в SSL версия 3.0.
• Подобрена псевдослучайна функция (PRF) PRF се използва за генериране на ключови данни. В TLS PRF се дефинира с помощта на HMAC. PRF използва два алгоритъма за хеширане, за да гарантира своята сигурност. Ако един от алгоритмите бъде хакнат, данните ще бъдат защитени от втория алгоритъм.
• Подобрена проверка на съобщението „Готовност“ – TLS версия 1.0 и SSL версия 3.0 изпращат съобщение „Готовност“ до двете крайни системи, което показва, че доставеното съобщение не е било променено. В TLS обаче тази проверка се основава на PRF и HMAC стойности, което осигурява по-високо ниво на сигурност от SSL версия 3.0.
• Последователна обработка на сертификати – За разлика от SSL версия 3.0, TLS се опитва да посочи тип сертификат, който може да се използва от различни реализации на TLS.
• Специфични предупредителни съобщения - TLS предоставя по-точни и пълни предупреждения за проблеми, открити от една от крайните системи. TLS също така съдържа информация кога кои предупредителни съобщения трябва да бъдат изпратени.

SSH протокол

SSH протокол ( Сигурна обвивкаЗащитната обвивка е набор от протоколи за удостоверяване с публичен ключ, който позволява на потребител от страна на клиента да влезе сигурно в отдалечен сървър.

Основната идея на протокола е, че потребителят от страна на клиента трябва да изтегли от отдалечен сървърпубличен ключ и го използвайте за установяване на защитен канал с помощта на криптографски мандат. Криптографските идентификационни данни на потребителя са неговата парола: тя може да бъде криптирана с помощта на получения публичен ключ и предадена на сървъра.

Всички съобщения са криптирани с помощта на IDEA.

Архитектура на SSH протокол

SSH се осъществява между два ненадеждни компютъра, работещи в незащитена мрежа (клиент - сървър).

Пакетът от SSH протоколи се състои от три компонента:

• Протоколът на транспортния слой SSH осигурява удостоверяване на сървъра. За това се използва публичен ключ. Първоначалната информация за този протокол, както от страна на сървъра, така и от страна на клиента, е чифт публични ключове - „ключове на главния компютър“. Резултатът от протокола е взаимно удостоверен защитен канал, който гарантира тайната и целостта на данните.

• SSH протокол за удостоверяване на потребителя. Извършва се през еднопосочен канал за удостоверяване, установен от протокола на SSH транспортния слой. За извършване на удостоверяване от клиент към сървър се поддържат различни еднопосочни протоколи за удостоверяване. Тези протоколи могат да използват или публичен ключ, или парола. Например, те могат да бъдат създадени на базата на протокол за удостоверяване с помощта на проста парола. Резултатът от протокола е взаимно удостоверен защитен канал между сървъра и потребителя. Използват се следните методи:

публичен ключ- на клиента се изпраща електронен подпис, сървърът проверява доверието в публичния ключ на клиента, като използва копието на ключа, наличен на сървъра, след което проверява автентичността на клиента с помощта на Sc.

парола- клиентът потвърждава своята автентичност с парола.

базиран на хост- подобно на publickey, за който се използва само двойка ключове клиентски хост; След като потвърди автентичността на хоста, сървърът се доверява на потребителското име.

• Протоколът за свързване на SSH работи по защитен канал с взаимно удостоверяване, установен от предишни протоколи. Протоколът осигурява работата на защитен канал, като го разделя на няколко защитени логически канала.

Протокол за разпределение на ключовете

Протоколът включва 3 етапа. Първата фаза е фазата "Hello", където първият идентификатор е низът I, изпратен за стартиране на протокола, последван от списък с поддържани алгоритми X.

На етап 2 страните се договарят за таен ключ, s. За това се използва алгоритъмът на Дифи-Хелман. Сървърът потвърждава своята самоличност, като изпраща на клиентите своя публичен ключ, потвърден с цифров подпис, , и дайджест подпис, h. Идентификаторът sid е зададен на h.

В етап 3 секретният ключ, идентификаторът на сесията и дайджестът се използват за създаване на 6 „ключа за приложение“, изчислени чрез .

Резюме

Предимствата на протокола включват:

• способността да се действа от край до край с внедряване на TCP/IP стекове и съществуващи интерфейси за програмиране на приложения;
• повишена ефективност в сравнение с бавните канали;
• липса на проблеми с фрагментацията, определяне на максималния обем на блоковете, предавани по даден маршрут;
• комбинация от компресия и криптиране.

14.09.2006 Марк Джоузеф Едуардс

Кой метод е оптимален за вашите условия? Прехвърлянето на файлове по интернет е много често срещана операция и защитата на прехвърлените файлове е от изключително значение за много фирми. Има няколко начина за прехвърляне на файлове и много методи за защита на тези файлове по време на процеса на прехвърляне.

Кой метод е оптимален за вашите условия?

Прехвърлянето на файлове по интернет е много често срещана операция и защитата на прехвърлените файлове е от изключително значение за много фирми. Има няколко начина за прехвърляне на файлове и много методи за защита на тези файлове по време на процеса на прехвърляне. Изборът на методи за предаване и криптиране зависи от общите нужди на подателя. В някои случаи е достатъчно просто да се гарантира сигурността на файловете по време на процеса на прехвърляне. В други е по-важно файловете да се шифроват по такъв начин, че да останат защитени дори след доставяне до получателя. Нека разгледаме по-отблизо начините за сигурно прехвърляне на файлове.

По пътя и при пристигането

Ако вашите намерения са ограничени до защита на файлове, докато се прехвърлят Интернет канали, имате нужда от безопасна транспортна технология. Една от възможностите е да използвате уеб сайт, който може да приема изпратени до него файлове и ви позволява да го направите сигурно зарежданетакива файлове. За сигурно транспортиране на файлове към уеб сайт можете да създадете уеб страница, която е оборудвана със слой със защитени сокети (SSL) и хоства ActiveX контрола или Javascript скрипт. Например, можете да използвате контролата AspUpload от Persitis Software; разработчиците твърдят, че това е „най-модерното управление на файловия транспорт до централните възли, достъпно на пазара“. Друга възможност е да използвате скрипта Free ASP Upload, който не изисква двоичен компонент. За да осигурите допълнителна сигурност, можете дори да защитите с парола както уеб страницата, така и свързаната директория за публикуване на материали, получени на сайта. Що се отнася до изтеглянето на файлове от уеб сайт, достатъчно е да се гарантира, че съответният уеб сървър осигурява връзка чрез SSL, според понеза URL адреса, който се използва за изтегляне на файлове.

Алтернативен вариант е да използвате FTP сървър, който осигурява пренос на данни чрез FTP Secure протокол. По същество FTPS е FTP протокол, работещ през защитена SSL връзка. Възможност за ползване FTPS протоколсе предоставя в много популярни FTP клиенти, но, за съжаление, не е внедрен в FTP услугата на Microsoft. Следователно ще трябва да използвате приложение за FTP сървър, което предоставя тази възможност (например популярния продукт WFTPD). Не бъркайте FTPS с SSH протокола за прехвърляне на файлове. SFTP е протокол за прехвърляне на файлове, който работи върху Secure Shell (SSH); освен това може да се използва за прехвърляне на файлове. Имайте предвид обаче, че SFTP не е съвместим с традиционния FTP, така че в допълнение към защитен шел сървър (да речем такъв, предоставен от SSH Communications Security), ще ви е необходим специален SFTP клиент (това може да е клиентът, включен в PuTTY Telnet/Secure Shell или WinSCP с GUI).

В допълнение, сигурното прехвърляне на файлове може да бъде организирано въз основа на виртуално лично VPN мрежи. Windows платформиСървърът осигурява съвместимост с VPN технология чрез RRAS. Това обаче не гарантира съвместимост с VPN решенията на вашите партньори. Ако няма такава съвместимост, можете да използвате едно от широко използваните решения, като например инструмента Open-VPN с отворен програмен код. Той е безплатен и работи на редица платформи, включително Windows, Linux, BSD и Macintosh OS X. За повече информация относно интегрирането на OpenVPN вижте Работа с OpenVPN ( ).

Чрез установяване на VPN връзка можете да разпределяте директории и да прехвърляте файлове в двете посоки. Всеки път, когато използвате VPN, трафикът е криптиран, така че няма нужда от допълнително криптиране на файлове - освен ако не искате файловете да останат защитени в системата, към която се прехвърлят. Този принцип важи за всички методи за предаване, които споменах досега.

Ако се чувствате комфортно с фазата на прехвърляне и основната ви грижа е да предотвратите достъпа на неоторизирани потребители до съдържанието на вашите файлове, може да е препоръчително просто да шифровате вашите файлове, преди да ги транспортирате. В този случай имейлът вероятно ще бъде ефективен каналпрехвърляне на файл. Приложенията за имейл са инсталирани на почти всяка настолна система, така че ако изпращате файлове по имейл, не е необходимо да използвате никаква допълнителна технология освен криптирането на данни. Методът за прехвърляне на файлове по имейл е ефективен, тъй като съобщенията и прикачените файлове обикновено пристигат директно в пощенската кутия на получателя, въпреки че съобщението може да премине през множество сървъри по време на процеса на прехвърляне.

Ако все пак изисквате допълнителни средстваза да защитите данните, докато пътуват по имейл, обмислете използването на протоколи SMTP Secure (SMTPS) и POP3 Secure (POP3S). По същество SMTPS и POP3S са обикновени SMTP и POP3 протоколи, работещи през защитена SSL връзка. Microsoft Exchange Server, подобно на повечето имейл клиенти, включително Microsoft Outlook, предоставя възможност за използване на протоколите SMTPS и POP3S. Имайте предвид, че дори когато протоколът SMTPS се използва за обмен на файлове между пощенския клиент и пощенския сървър, пак е възможно пощенският сървър да достави поща до крайния получател чрез обикновена, незащитена SMTP връзка.

Тъй като инструментите за обработка на имейли станаха толкова широко разпространени, останалата част от тази статия ще обсъди предимно проблемите със защитения трансфер на файлове по имейл канали. При това ще приемем, че изпращачът трябва да криптира данните, за да ги защити както по време на предаването, така и след доставката. И така, нека разгледаме най-популярните технологии за криптиране на имейл днес.

Инструменти за компресиране на файлове

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

Един от най-популярните методи за създаване на архиви компресирани файлове- метод на компресия с цип; Почти всички архиватори го поддържат. И един от най-разпространените инструменти за компресиране на zip днес е приложението WinZip. Може да се използва като самостоятелна програма, да бъде вграден в Windows Explorer за лесен достъп и да интегрира продукта с клиента на Outlook с помощта на модула WinZip Companion за Outlook. WinZip, подобно на много други архиватори, оборудвани с zip, предоставя възможност за криптиране с помощта на метода за криптиране Zip 2.0. Но трябва да се каже, че защитата на файлове с този метод не е достатъчно надеждна. По-приемлива опция за криптиране е реализирана в WinZip 9.0. Както показва Фигура 1, WinZip вече поддържа спецификацията Advanced Encryption Standard (AES), която използва 128-битови или 256-битови ключове за криптиране. AES е сравнително нова технология, но вече се счита за индустриален стандарт.

Фигура 1: WinZip поддържа AES спецификацията

Не мога да кажа точно колко архиватори използват силни алгоритми за криптиране, използващи AES, и ще се огранича да спомена едно такова приложение; Това е продукт bxAutoZip, разработен от BAxBEx Software. Той може да взаимодейства с програмата за криптиране CryptoMite от BAxBEx и може да бъде вграден в Outlook. Докато WinZip ви позволява да криптирате данни само с помощта на Zip 2.0 и AES, CryptoMite предоставя възможността да използвате редица други инструменти за криптиране, включително популярните алгоритми Twofish и Blowfish, Cast 256, Gost, Mars и SCOP.

Почти всеки вече е оборудван с инструменти за разопаковане на zip файлове. компютърни системи, обаче, не всички zip приложения осигуряват съвместимост с различни алгоритми за криптиране. Следователно, преди да изпратите криптирани файлове, трябва да се уверите, че zip приложението на получателя „разбира“ избрания алгоритъм.

Когато шифровате файлове с помощта на zip приложения, се използват пароли за сигурност. За да дешифрира архивен файл, получателят трябва да използва и подходящата парола. Трябва да се внимава при избора на метод за доставка на парола. Вероятно най-сигурните методи за доставяне на парола са по телефон, факс или куриер. Можете да изберете всеки от тях, но при никакви обстоятелства не трябва да изпращате паролата по имейл в обикновен текст; в този случай опасността неоторизиран потребител да получи достъп до криптирания файл рязко се увеличава.

Не забравяйте, че архиваторите, оборудвани с инструменти за криптиране, осигуряват прехвърляне на файлове не само чрез имейл канали. Те могат да се използват ефективно за транспортиране на данни, като се използват другите методи, споменати по-горе.

Доста добра поверителност

Друг изключително популярен метод за криптиране може да се приложи с помощта на Pretty Good Privacy. PGP направи фурор, когато Фил Цимерман го публикува за първи път безплатно в Интернет през 1991 г. PGP стана търговски продукт през 1996 г., а след това правата върху него бяха закупени от Network Associates (NAI) през 1997 г. През 2002 г. тази технология е придобита от NAI от млада компания, наречена PGP Corporation.

Оттогава PGP Corporation продаде комерсиална версия на PGP, която работи в среда на Windows и Mac OS X. Сегашна версия PGP 9.0, който осигурява криптиране на отделни файлове и криптиране на целия диск, може да бъде вграден в AOL Instant Messenger (AIM). В допълнение, PGP 9.0 се интегрира с продукти като Outlook, Microsoft Entourage, Lotus Notes, Qualcomm Eudora, Mozilla Thunderbird и Apple Mail.

PGP използва система за криптиране с публичен ключ, която генерира двойка ключове за криптиране - публичен ключ и частен ключ. Тези два ключа са математически свързани по такъв начин, че данните, криптирани с публичния ключ, могат да бъдат декриптирани само с частния ключ. Потребителят на PGP генерира двойка публичен ключ-личен ключ и след това публикува публичния ключ в директория с публични ключове или уеб сайт. Секретният ключ, разбира се, не се публикува никъде и се пази в тайна; ползва се само от собственика си. Дешифрирането на данни с помощта на частен ключ изисква парола, но криптирането на данни с помощта на публичен ключ не изисква парола публични ключовеВсеки може да го използва.

За да направят системата PGP по-лесна за използване, нейните разработчици са внедрили функция за автоматично анкетиране на директории с публични ключове. Тази функция ви позволява да въведете имейл адреса на потребителя в лентата за търсене и да намерите публичния му ключ. PGP предоставя възможност за автоматично четене на публични ключове, които могат да се съхраняват локално във вашата система в специален базиран на файл „ключодържател“ за лесен достъп. Чрез запитване до директория с публични ключове, PGP ви позволява винаги да съхранявате в „пакет“ най-много най-новите версии. Ако потребител промени своя публичен ключ, можете да получите достъп до актуализирания ключ по всяко време, когато имате нужда от него.

За да се осигурят по-силни гаранции за автентичността на публичните ключове, могат да се използват цифрови подписи, като се използват ключовете на други потребители. Подписването на ключа от друг потребител служи допълнително потвърждениече ключът всъщност принадлежи на човека, който се нарича негов собственик. За да потвърди ключ с помощта на цифров подпис, PGP извършва математическа операция и добавя своя уникален резултат към ключа. След това подписът може да бъде проверен чрез сравняването му с ключа за подписване, който е бил използван за създаване на подписа. Този процес наподобява процеса на едно лице, потвърждаващо самоличността на друго.

PGP се ползва с доверие от мнозина, защото отдавна си е изградил репутация в индустрията като надеждна технология за защита на информация. Въпреки това, ако решите да използвате PGP или друг метод за криптиране с публичен ключ, не забравяйте, че получателите на вашите файлове също трябва съвместима системакриптиране. Едно от предимствата на PGP при използване на имейл като канал за предаване на данни е, че поддържа собствен модел на криптиране, както и X.509 и S/MIME технологии, които ще обсъдя по-късно.

Освен това трябва да се отбележи още един момент. Независимо дали планирате да използвате PGP, WinZip или друга система за шифроване, ако искате да шифровате съдържанието на самото съобщение в допълнение към шифроването на прикачените файлове, ще трябва да напишете съобщението на отделен файли също го шифровайте. Ако желаете, този файл със съобщения може да бъде поставен в архива заедно с други файлове или да бъде прикачен като прикачен файл.

PKI

Инфраструктурата на публичния ключ (PKI) е уникална, но принципът на нейната работа донякъде напомня на принципа на PGP. PKI включва използването на чифт ключове – публичен и секретен. За да криптират данните, изпратени до получателя, подателите използват публичния ключ на получателя; След като данните бъдат доставени на получателя, той ги дешифрира с помощта на личния си ключ.

Екран 2: Преглед на съдържанието на сертификата

Една основна разлика е, че в PKI публичният ключ обикновено се съхранява във формат на данни, известен като сертификат. Сертификатите могат да съдържат много повече информация от обикновените ключове. Например сертификатите обикновено съдържат дата на изтичане, така че знаем кога сертификатът и свързаният с него ключ вече няма да бъдат валидни. Освен това сертификатът може да включва името, адреса, телефонния номер и друга информация на собственика на ключа. Фигура 2 показва съдържанието на сертификата, както се показва в прозореца Програми на Microsoft Internet Explorer(IE) или Outlook. До известна степен съдържанието на сертификата зависи от това какви данни собственикът желае да постави в него.

Подобно на PGP, PKI позволява формирането на "вериги на доверие", в които сертификатите могат да бъдат подписвани с помощта на сертификатите на други потребители. Освен това се появиха сертифициращи органи (CA). Това са доверени независими организации, които не само издават собствени сертификати, но и подписват други сертификати, като по този начин гарантират тяхната автентичност. Както при PGP и свързаните с него ключови сървъри, сертификатите могат да бъдат публикувани на публични или частни сървъри за сертификати или LDAP сървъри, изпратени по имейл и дори хоствани на уеб сайт или файлов сървър.

За да осигурят автоматично удостоверяване на сертификат, разработчиците на имейл клиенти и уеб браузъри обикновено оборудват своите програми с инструменти за взаимодействие със сървърите на сертифициращия орган. По време на този процес вие също ще можете да получите информация за анулирането на сертификат по една или друга причина и съответно да направите заключение, че на този сертификат вече не може да се вярва. Разбира се, понякога трябва да плащате за услугите на сертифициращите органи за предоставяне и сертифициране на сертификати; цените може да варират в зависимост от избрания сертифициращ орган. Някои организации предоставят на клиентите безплатни лични сертификати по имейл, докато други начисляват значителна такса за това.

PKI се основава на спецификацията X.509 (извлечена от спецификацията LDAP X). Следователно сертификати, издадени от един орган (включително сертификати, които генерирате за себе си), обикновено могат да се използват в редица платформи. Необходимо е само тези платформи да са съвместими със стандарта X.509. Можете сами да генерирате сертификати, като използвате някой от наличните инструменти, като OpenSSL.

Ако вашата организация използва Microsoft услугаУслуги за сертификати, можете да поискате сертификат чрез тази услуга. В среди Windows сървър 2003 и Windows 2000 Server този процестрябва да продължи приблизително по същия начин. Трябва да отворите уеб страницата на сървъра за сертификати (обикновено се намира на http://име на сървър/CertSrv), след което изберете Заявка за сертификат. На Следваща страницатрябва да изберете елемента Искане на потребителски сертификат и да следвате инструкциите на уеб администратора, докато процесът приключи. Ако услугата за сертификат е конфигурирана по такъв начин, че е необходимо одобрение от администратор за издаване на сертификат, системата ще ви уведоми за това със специално съобщение и ще трябва да изчакате решението на администратора. В други случаи в крайна сметка ще видите хипервръзка, която ще ви позволи да инсталирате сертификата.

Някои независими сертифициращи органи, като Thwate и InstantSSL на Comodo Group, предлагат безплатни лични имейл сертификати на потребителите; това е лесен начин за получаване на сертификати. Освен това такива удостоверения вече ще бъдат подписани от органа, който ги е издал, което ще улесни проверката на тяхната автентичност.

Когато става въпрос за използване на PKI за изпращане на криптирани данни с помощта на имейл програма, спецификацията Secure MIME (S/MIME) влиза в действие. Outlook, Mozilla Thunderbird и Apple Mail са само няколко примера имейл приложения, което ви позволява да използвате този протокол. За да изпратите шифровано имейл съобщение (със или без прикачени файлове) до получател, трябва да имате достъп до публичния ключ на получателя.

За да получите публичен ключ на друг потребител, можете да видите информацията за ключа на LDAP сървъра (освен ако ключът не е публикуван с помощта на LDAP протокола). Друг вариант: можете да помолите този човек да ви изпрати съобщение с цифров подпис; Като правило, когато доставят подписано съобщение на получателя, имейл клиентите, оборудвани с S/MIME възможности, прикачват копие на публичния ключ. Или можете просто да помолите лицето, което ви интересува, да ви изпрати съобщение с прикачен към него публичен ключ. По-късно можете да съхраните този публичен ключ в интерфейса за управление на ключове, който идва с вашия имейл клиент. Outlook се интегрира с вграден Windows съхранениеСертификати за съхранение на сертификати. Ако трябва да използвате публичния ключ, той винаги ще бъде под ръка.

Базирано на подателя криптиране

Voltage Security разработи нова технология - identity-based encryption (IBE). Като цяло тя е подобна на PKI технологията, но има интересна функция. IBE използва частен ключ за дешифриране на съобщения, но не използва обикновен публичен ключ по време на процеса на криптиране. IBE предвижда използването на имейл адреса на подателя като такъв ключ. Така при изпращане на криптирано съобщение до получателя не възниква проблемът с получаването на публичния му ключ. Всичко, от което се нуждаете, е имейл адресът на лицето.

Технологията IBE включва съхраняване на секретния ключ на получателя на сървър за ключове. Получателят потвърждава правата си за достъп до ключовия сървър и получава секретен ключ, с който дешифрира съдържанието на съобщението. Технологията IBE може да се използва от потребители на Outlook Outlook Express, Lotus Notes, Pocket PC и Research in Motion (RIM) BlackBerry. Според представители на Voltage Security, IBE също работи на всякакви имейл системи, базирани на браузър, работещи с почти всяка операционна система. Вероятно такива универсални решения за сигурност на напрежението са точно това, от което се нуждаете.

Трябва да се отбележи, че технологията IBE се използва в продуктите на FrontBridge Technologies като средство за улесняване на сигурния обмен на криптирани имейл съобщения. Вероятно вече знаете, че през юли 2005 г. FrontBridge беше придобит от Microsoft, който планира да интегрира решенията на FrontBridge с Exchange; Може да не мине много преди комбинация от тези технологии да бъде предложена на потребителите като управлявана услуга. Ако вашата организация и имейл системите на вашите партньори са базирани на Exchange, следете развитието в тази област.

Всичко взето предвид

Има много начини за сигурно прехвърляне на файлове през интернет и несъмнено най-простият и най-ефективен от тях се предоставя по имейл. Разбира се, тези, които трябва да обменят голям брой файлове, които съставляват големи количества данни, може да обмислят използването на други методи.

Трябва внимателно да обмислите колко файла ще прехвърлите, колко големи са те, колко често ще трябва да прехвърляте файловете, кой трябва да има достъп до тях и как ще се съхраняват там, където са получени. Като вземете предвид тези фактори, можете да изберете по най-добрия начинпрехвърляне на файл.

Ако решите, че имейлът е най-добрият ви вариант, имайте предвид, че след като пристигне пощата, много пощенски сървъриИ пощенски клиентиможете да стартирате скриптове или да извършвате конкретни действия въз основа на правила. Използвайки тези функции, можете да автоматизирате движението на файлове както по маршрута на пощенските сървъри, така и когато файловете пристигнат във вашата пощенска кутия.

Марк Джоузеф Едуардс - старши Windows редакторИТ специалист и автор на седмичния имейл бюлетин за актуализация на сигурността ( http://www.windowsitpro.com/email). [имейл защитен]

Създаване на защитен канал за предаване на данни между разпределени корпоративни информационни ресурси

А. А. Теренин, д-р,

Специалист по осигуряване на качеството на ИТ и софтуер

Дойче Банк Москва

В момента голямо предприятие с мрежа от клонове в страната или света трябва да създаде един единствен информационно пространствои осигуряване на ясна координация на дейностите между своите клонове.

За да се координират бизнес процесите, протичащи в различни отрасли, е необходим обмен на информация между тях. Данните, идващи от различни офиси, се натрупват за по-нататъшна обработка, анализ и съхранение в някой централен офис. След това натрупаната информация се използва за решаване на бизнес проблеми от всички клонове на предприятието.

Данните, обменяни между клоновете, подлежат на строги изисквания за тяхната надеждност и цялост. Освен това данните, представляващи търговска тайна, трябва да бъдат поверителни. За пълна паралелна работа на всички офиси, обменът на информация трябва да се извършва онлайн (в реално време). С други думи, трябва да се създаде постоянен канал за предаване на данни между клоновете на предприятието и централата. Да предоставя непрекъсната работаТакъв канал налага изискване за поддържане на достъп до всеки източник на информация.

Ние обобщаваме изискванията, на които трябва да отговарят каналите за предаване на данни между клоновете на предприятието, за да изпълняват задачата за осигуряване на постоянна комуникация с високо качество:

каналът за предаване на данни трябва да е постоянен,

данните, предавани по такъв канал, трябва да поддържат цялостност, надеждност и поверителност.

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

В допълнение към разпределените корпоративни системи, които работят в реално време, има системи, които работят офлайн. Обменът на данни в такива системи не се извършва постоянно, а на определени периоди от време: веднъж на ден, веднъж на час и т.н. подобни системисе натрупват в отделни клонови бази данни (БД), както и в централни бази данни, като само данните от тези БД се считат за надеждни.

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

Изискването за надеждност означава осигуряване на оторизиран достъп, удостоверяване на страните по взаимодействие и гарантиране на недопустимостта на отказ от авторство и факта на предаване на данни.

Към системите за осигуряване сигурността на информационните транзакции в разпределена информационна среда се налагат по-строги изисквания, но това е тема за отделна статия.

Как да осигурим такава защита на канала за предаване на данни?

Може да се свърже физически каналпрехвърляне на данни от всеки клон към всеки (или само всички клонове от центъра) и осигуряване на невъзможност за достъп до физическата среда за предаване на информационни сигнали. Да, такова решение може да е приемливо за изпълнение в рамките на един защитен обект, но говорим за разпределени корпоративни системи, където разстоянието между обектите на взаимодействие може да се измерва в хиляди километри. Цената за прилагане на такъв план е толкова висока, че никога няма да бъде рентабилен.

Друг вариант: наемете съществуващи, вече инсталирани комуникационни канали или сателитни канали от телеком оператори. Подобно решениесъщо е включен в категорията на скъпите; освен това защитата на тези канали ще изисква внедряване или инсталиране на специален софтуер (софтуер) за всяка от взаимодействащите страни.

Много често, евтино и ефективно решениее организирането на сигурни комуникационни канали по целия свят компютърна мрежаИнтернет.

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

Нека да разгледаме по-подробно как можете да създадете сигурни канали за предаване на данни през Интернет.

Проблемите на защитеното предаване на данни през отворени мрежи са широко дискутирани в популярната и масова литература:

World Wide WebИнтернет непрекъснато се разширява, средствата за предаване и обработка на данни се развиват, оборудването за прихващане на предадени данни и достъп до поверителна информация става все по-модерно. В момента проблемът за осигуряване на защита на информацията от нейното неразрешено копиране, унищожаване или модифициране по време на съхранение, обработка и предаване по комуникационни канали става все по-актуален.

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

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

За защита на информацията, предавана по публични комуникационни канали, се използват много мерки за сигурност: данните се криптират, пакетите се предоставят с допълнителна контролна информация и се използва протокол за обмен на данни с висока степен на сигурност.

Преди да решите как да защитите предаваните данни, е необходимо ясно да очертаете обхвата на възможните уязвимости, да изброите методите за прихващане, изкривяване или унищожаване на данни и методите за свързване към комуникационни канали. Отговорете на въпроси какви цели преследват нападателите и как могат да използват съществуващите уязвимости, за да реализират плановете си.

от допълнителни изискваниядо осъществими защитен каналпредаването на данни може да се разграничи:

идентифициране и удостоверяване на взаимодействащи страни;

процедура за защита срещу подмяна на една от страните (използване на криптографски алгоритми с публичен ключ);

контрол върху целостта на предаваните данни, пътя на предаване на информацията и нивото на защита на комуникационния канал;

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

компресиране на предаваната информация;

откриване и коригиране на грешки при предаване на данни по комуникационни канали;

одит и регистрация на събития;

автоматично възстановяванепроизводителност.

Да изградим модел на нарушителя и модел на охранявания обект (фиг. 1).

Алгоритъм за установяване на връзка

За реализиране на защитен канал за предаване на данни се използва модел на взаимодействие клиент-сървър.

Разглеждат се две страни: сървър и клиент – работна станция, който иска да установи връзка със сървъра за по-нататъшна работа с него.

Първоначално има само два ключа: публичен и частен ключ на сървъра ( ОКИ ЗКС), а публичният ключ на сървъра е известен на всички и се предава на клиента, когато той има достъп до сървъра. Частният ключ на сървъра се съхранява при най-строга секретност на сървъра.

Инициализаторът на връзката е клиентът, той получава достъп до сървъра през всяка глобална мрежа, с която работи този сървър, най-често чрез Интернет.

Основната задача при инициализиране на връзка е да се установи канал за обмен на данни между две взаимодействащи страни, да се предотврати възможността за фалшифициране и да се предотврати ситуацията на заместване на потребителя, когато се установи връзка с един потребител, а след това друг участник в системата се свързва с една от страните на канала и започва да присвоява съобщения, предназначени за легитимен потребител или да предава съобщения от чуждо име.

Необходимо е да се предвиди възможност за свързване на атакуващ по всяко време и повтаряне на процедурата „ръкостискане“ на определени интервали от време, чиято продължителност трябва да бъде зададена на минимално допустимия.

Въз основа на предположението, че ЗКСИ ОКвече са създадени и ОКвсеки знае и ЗКС– само към сървъра, получаваме следния алгоритъм:

1. Клиентът изпраща заявка за връзка към сървъра.

2. Сървърът стартира приложението, предавайки на искащата станция някакво специално съобщение за предварително инсталираното клиентско приложение, в което публичният ключ на сървъра е твърдо кодиран.

3. Клиентът генерира своите ключове (публични и частни), за да работи със сървъра ( OKCИ ЗКК).

4. Клиентът генерира сесиен ключ ( KS) (ключ за симетрично шифроване на съобщение).

5. Клиентът изпраща следните компоненти към сървъра:

клиентски публичен ключ ( OKC);

сесиен ключ;

произволно съобщение (да го наречем х), криптиран с публичния ключ на сървъра с помощта на алгоритъма RSA.

6. Сървърът обработва полученото съобщение и изпраща съобщение в отговор х, шифрован със сесийния ключ ( симетрично криптиране) + криптиран с публичния ключ на клиента (асиметрично криптиране, като алгоритъма RSA) + подписан от частния ключ на сървъра ( RSA, DSA, GOST) (тоест, ако от страна на клиента след дешифриране отново получим X, това означава, че:

съобщението идва от сървъра (подпис – ЗКС);

сървърът прие нашите OKC(и криптиран с нашия ключ);

сървърът е приет KS(шифрова съобщението с този ключ).

7. Клиентът получава това съобщение, проверява подписа и дешифрира получения текст. Ако в резултат на извършване на всички обратни действия получим съобщение, напълно идентично с изпратеното до сървъра х, то се счита, че защитеният канал за обмен на данни е инсталиран правилно и е напълно готов за работа и изпълнение на своите функции.

8. Впоследствие двете страни започват да обменят съобщения, които се подписват с личните ключове на подателя и се криптират със сесийния ключ.

Диаграмата на алгоритъма за установяване на връзка е показана на фиг. 2.

Алгоритъм за подготовка на съобщение за изпращане към защитен канал

Формулировката на проблема е следната: входът на алгоритъма е оригиналният (отворен) текст, а на изхода чрез криптографски трансформации получаваме затворен и подписан файл. Основната задача, възложена на този алгоритъм, е да осигури сигурно предаване на текст и да осигури защита в незащитен канал.

Необходимо е също така да се въведе възможност за предотвратяване на разкриване на информация, когато съобщение е прихванато от нападател. Мрежата е отворена; всеки потребител в тази мрежа може да прихване всяко съобщение, изпратено по връзка за данни. Но благодарение на защитата, присъща на този алгоритъм, данните, получени от нападателя, ще бъдат напълно безполезни за него.

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

Има и възможност в другия край на канала (от приемащата страна) да е имало нападател, който е заместил законния представител. Благодарение на този алгоритъм, съобщение, което лесно попада в ръцете на такъв нападател, също ще бъде „нечетливо“, тъй като спуферът не знае публичния и частния ключ на страната, която е спуфнирал, както и ключа на сесията.

Алгоритъмът може да се реализира по следния начин (фиг. 3):

изходният текст е компресиран с помощта на ZIP алгоритъм;

успоредно с този процес изходният текст се подписва с публичния ключ на получателя;

компресираният текст е криптиран симетричен ключсесия, този ключ също е от приемащата страна;

се добавя към шифрования и компресиран текст цифров подпис, който уникално идентифицира подателя;

съобщението е готово за изпращане и може да бъде предадено по комуникационния канал.

Алгоритъм за обработка на съобщение при получаване от защитен канал

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

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

Ако искате да осигурите максимална защита за преминаване на съобщение по защитен канал, трябва да прибегнете до доста времеемки и ресурсоемки операции. Докато печелим в сигурността, губим в скоростта на обработка на препратените съобщения.

Освен това е необходимо да се вземат предвид времето и машинните разходи за поддържане на надеждността на комуникацията (проверка от страните една на друга) и за обмен на информация за контрол и управление.

Алгоритъм за обработка на съобщение при получаване от защитен канал (фиг. 4):

от полученото криптирано, компресирано и подписано съобщение се извлича цифров подпис;

текст без цифров подпис се дешифрира със сесийния ключ;

декодираният текст се подлага на процедура за разархивиране, използвайки например ZIP алгоритъма;

текстът, получен в резултат на двете предишни операции, се използва за проверка на цифровия подпис на съобщението;

на изхода на алгоритъма имаме началната отворено съобщениеи резултата от проверката на подписа.

Алгоритъм за подпис на съобщение

Нека разгледаме по-отблизо алгоритъма за подписване на съобщения. Ще изхождаме от предположението, че всички публични и частни ключове на двете страни, които обменят данни, вече са генерирани и частните ключове се съхраняват при техните непосредствени собственици, а публичните ключове се изпращат един на друг.

Тъй като изходният текст може да има неограничен и всеки път непостоянен размер, а алгоритъмът за цифров подпис изисква блок от данни с определена постоянна дължина за своята работа, стойността на хеш функцията от този текст ще се използва за преобразуване на целия текст в неговия дисплей с предварително определена дължина. В резултат на това получаваме текстов дисплей поради основното свойство на хеш функцията: тя е еднопосочна и няма да е възможно да възстановите оригиналния текст от получения дисплей. Алгоритмично е невъзможно да се избере текст, чиято стойност на хеш функцията да съвпада с предварително намерената. Това не позволява на атакуващия лесно да замени съобщението, тъй като стойността на неговата хеш функция веднага ще се промени и провереният подпис няма да съответства на стандарта.

За да намерите стойността на хеш функцията, можете да използвате добре известни алгоритми за хеширане ( SHA, MD4, MD5, GOSTи т.н.), които ви позволяват да получите блок данни с фиксирана дължина на изхода. Именно с този блок ще работи алгоритъмът за цифров подпис. Алгоритмите могат да се използват като алгоритъм за електронен цифров подпис DSA, RSA, Ел Гамали т.н.

Нека опишем алгоритъма за подпис на съобщение точка по точка (фиг. 5):

на входа общ алгоритъмполучава се изходен текст с произволна дължина;

изчислява се стойността на хеш функцията за дадения текст;

EDS;

с помощта на получените данни се изчислява стойността EDSцелият текст;

На изхода на алгоритъма имаме цифров подпис на съобщението, който след това се изпраща, за да бъде прикрепен към пакета информация, изпратен към канала за обмен на данни.

Алгоритъм за проверка на подписа

Алгоритъмът получава като вход два компонента: оригиналния текст на съобщението и неговия цифров подпис. Освен това изходният текст може да има неограничен и всеки път променлив размер, но цифровият подпис винаги има фиксирана дължина. Този алгоритъм намира хеш функцията на текста, изчислява цифровия подпис и го сравнява с информацията, получена като вход.

На изхода на алгоритъма имаме резултат от проверката на цифровия подпис, който може да има само две стойности: „подписът съответства на оригинала, текстът е автентичен“ или „подписът на текста е неправилен, целостта, автентичността или авторството на съобщението е подозрително“.Изходната стойност на този алгоритъм може след това да се използва допълнително в системата за поддръжка на защитен канал.

Нека опишем алгоритъма за проверка на подпис на съобщение точка по точка (фиг. 6):

входът на общия алгоритъм е изходен текст с произволна дължина и цифров подпис на този текст с фиксирана дължина;

изчислява се стойността на хеш функцията от дадения текст;

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

цифровият подпис, който е въведен като вход на общия алгоритъм, се изпраща към същия блок;

също входът на този блок (изчисляване на цифровия подпис) получава таен (личен) ключ, който се използва за намиране EDS;

с помощта на получените данни се изчислява стойността на електронния цифров подпис на целия текст;

получихме цифров подпис на съобщението, сравнявайки го с EDS, получени като вход на общия алгоритъм, можем да направим изводи за надеждността на текста;

На изхода на алгоритъма имаме резултат от проверката на цифровия подпис.

Възможни атаки срещу предложената схема за реализиране на защитен комуникационен канал

Нека да разгледаме най-често срещаните примери за възможни атаки срещу защитен канал за предаване на данни.

Първо, трябва да решите на какво и на кого можете да се доверите, защото ако не вярвате на никого и нищо, тогава няма смисъл да пишете такива програми, които да поддържат обмен на данни в глобалната мрежа.

Вярваме както на себе си, така и на софтуера, инсталиран на работната станция.

Когато използваме браузър (Internet Explorer или Netscape Navigator), за да комуникираме със сървър, ние се доверяваме на този браузър и му вярваме да проверява сертификатите на сайтовете, които посещаваме.

След като проверите подписа на аплета, на който можете да се доверите ОК, който е вграден в данни или програми (аплети), изтеглени от сървъра.

Притежание ОК, на които имаме доверие, можем да започнем по-нататъшна работа със сървъра.

Ако системата е изградена с помощта на клиентски приложения, тогава трябва да имате доверие на инсталирания клиентски софтуер. След това, използвайки верига, подобна на тази по-горе, можем да се доверим на сървъра, с който е установена връзката.

Възможни атаки.

1. При прехвърляне ОК. По принцип е достъпен за всеки, така че няма да е трудно за нападателя да го прихване. Притежание ОК, теоретично е възможно да се изчисли ЗКС. Необходимо е да се използват криптографски ключове с достатъчна дължина, за да се запази поверителността за определено време.

2. След прехвърляне от сървъра ОКи преди клиентът да изпрати своя OKCИ KS. Ако по време на тяхното генериране ( OKC, ЗККИ KS) се използва слаб генератор на произволни числа, можете да опитате да предвидите всичките три посочени параметъра или всеки един от тях.

За да се отблъсне тази атака, е необходимо да се генерират произволни числа, които отговарят на редица изисквания. Невъзможно е, например, да се използва таймер за генериране на произволни числа, тъй като нападателят, след като е прихванал първото съобщение ( ОКот сървъра), може да зададе времето за изпращане на пакет с точност до секунди. Ако таймерът се задейства на всяка милисекунда, тогава е необходимо пълно търсене само на 60 000 стойности (60 s _ 1000 ms), за да го отворите.

За генериране на произволни числа е необходимо да се използват параметри, които са недостъпни за нападателя (компютъра му), например номер на процеса или други системни параметри (като напр. идентификационен номердескриптор).

3. При предаване на пакет, съдържащ OKC, KS, х, криптиран ОК. За да разкриете прихваната информация, трябва да имате ЗКС. Тази атакасе свежда до атаката, обсъдена по-горе (селекция ЗКС). От нейната собствена затворена информация, предадено на сървъра, е безполезно за нападателя.

4. При прехвърляне от сървъра към клиента някои тестово съобщение х, криптиран KSИ OKCи подписан ЗКС. За да дешифрирате прихванато съобщение, трябва да знаете и OKC, И KS, което ще бъде известно, ако една от горните атаки бъде приложена, след като врагът е разбрал ЗКС.

Но дешифрирането на тестово съобщение не е толкова страшно; много по-голяма опасност е възможността за фалшифициране на предаденото съобщение, когато нападателят може да се представя за сървъра. За това той трябва да знае ЗКСда подпишете правилно пакета и всички ключове KSИ OKC, като самото съобщение хза да съставите правилно фалшивия пакет.

Ако някоя от тези точки бъде нарушена, системата се счита за компрометирана и не може да осигури по-нататък сигурната работа на клиента.

И така, разгледахме атаките, които са възможни на етапа на прилагане на процедурата за „ръкостискане“ (HandShake). Нека опишем атаки, които могат да бъдат извършени по време на предаване на данни през нашия канал.

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

Също така е невъзможно да се използва атака "вероятно изтегляне на дума", тъй като всяка дума ще изглежда различно във всяко съобщение. Тъй като архивирането включва разбъркване на информация, подобно на това, което се случва при изчисляване на хеш стойност, предишната информация влияе върху това как ще изглежда следващият блок от данни.

От описаното следва, че във всеки случай атакуващият може да използва атака само въз основа на изчерпателно търсене на всички възможни ключови стойности. За да се увеличи устойчивостта на този тип атака, е необходимо да се разшири диапазонът от стойности KS. Когато използвате 1024-битов ключ, диапазонът от възможни стойности се увеличава до 2 1024.

За да напише или замени съобщения, предавани по комуникационен канал, нападателят трябва да знае личните ключове на двете страни, участващи в обмена, или да знае един от двата частни ключа ( З К). Но в този случай той ще може да фалшифицира съобщения само в една посока, в зависимост от това в чия З Ктой знае. Той може да действа като подател.

Когато се опитва да излъже някоя от страните, т.е. когато се опитва да се представи за легален участник в обмена след установяване на комуникационна сесия, той трябва да знае KSИ З К(вижте случаите, обсъдени по-рано). Ако не KS, нито едно З Клицето, на чието място иска да се свърже с комуникационния канал, е неизвестно на нападателя, тогава системата веднага ще разбере за това и по-нататъшната работа с компрометирания източник ще спре.

В самото начало на работа, когато се свързвате към сървър, е възможна тривиална атака: подправяне на DNS сървъра. Не е възможно да се предпазите от него. Решението на този проблем е отговорност на администраторите на DNS сървъри, управлявани от интернет доставчици. Единственото, което може да ви спести, е вече описаната по-горе процедура за проверка на сертификата на сайта с браузър, потвърждавайки, че връзката е направена към желания сървър.

Заключение

Статията обсъжда методите за изграждане на защитен канал за предаване на данни, за да се осигури взаимодействие между разпределени корпоративни изчислителни системи.

Разработен е протокол за установяване и поддържане на защитена връзка. Предложени са алгоритми за осигуряване на защита при предаване на данни. Анализират се възможните уязвимости на разработената схема за взаимодействие.

Подобна технология за организиране на защитени връзки е организирана от протокола за мрежова комуникация SSL. В допълнение, виртуалните частни мрежи (VPN) са изградени въз основа на предложените принципи.

ЛИТЕРАТУРА

1. Медведовски И. Д., Семянов П. В., Платонов В. В. Атака в интернет. - Санкт Петербург: Издателство "DMK" 1999. - 336 с.

2. Karve A. Инфраструктура с публичен ключ. LAN/Списание мрежови решения(Руско издание), 8, 1997 г.

3. Мелников Ю. Н. Електронен цифров подпис. Защитни възможности. Поверително № 4 (6), 1995 г., стр. 35–47.

4. Теренин А. А., Мелников Ю. Н. Създаване на защитен канал в мрежата. Материали от семинара „Информационна сигурност - юг на Русия“, Таганрог, 28–30 юни 2000 г.

5. Теренин А. А. Разработване на алгоритми за създаване на защитен канал в отворена мрежа. Автоматизация и модерни технологии. – Издателство “Машиностроене”, бр.6, 2001, с. 5–12.

6. Теренин А. А. Анализ на възможни атаки срещу защитен канал в отворена мрежа, създадена от софтуер. Материали от XXII конференция на младите учени на Механико-математическия факултет на Московския държавен университет, Москва,17–22 април 2000 г.