В продължение на хиляди години хората са използвали различни методи, за да се скрие информация трябва да бъде предадена, както и проверка на подателя и на съобщението. С развитието на цивилизацията е създаден и сега получава широко разпространена единствен метод за изпълнение на тези три задачи. протокол
S / MIME - е система от защитени изпращане на електронна поща с използване на криптиране и цифрови подписи.
Сегашните технологии за криптиране (затваряне) са разделени на два основни вида: алгоритми със симетричен (тайно) ключ, като DES или AES криптиране и асиметрични алгоритми (отворен / затворен) ключове, като RSA или ECC. Съвременните средства за проверка на изпращача - математическа еднопосочни функции, наречени хешове, които правят уникални подписи. Две често използван метод хеширане - е MD5 и SHA алгоритми. Компютрите могат да ги използват, за да се създаде уникална хашиш или номер съответства на изходния текст индивид (текстове идентични източници са с една стойност хеш код). Тези прости инструменти се използват и комбинират, за да се създаде инфраструктура с публичен ключ (PKI).
Сертификатът за изпитване
Идентичност в рамките на системата на PKI се управляват с помощта на цифрови сертификати, които не са много различни от държавните издава карти за самоличност, които по-голямата част от хората се транспортират през международните граници - паспорти. паспорти стандарт в света на цифрови сертификати - е формат X.509, който се използва широко за подписване и криптиране технологии като S / MIME, IPsec, SSH, както и сигурността на безжичната мрежа, виртуални частни мрежи (VPN) и дори съобщение за сигурност сървър (като например уеб сайтове SSL).
Сертификатите са базирани на асиметрични криптографски и хеш кодове. За да създадете сертификат заявител (този, който се нуждае от основен, подписано от по-висока Калифорния) създава таен ключ. Ключът се държи заключена, така че неговата автентичност не е под въпрос. съответния публичен ключ е създаден, заедно с таен ключ. Както подсказва името му, откритата част на двойката не е тайна и се разпространява безплатно, макар и все още по начин, който да гарантира неговата автентичност.
Тази двойка ключове прави възможни две основни операции. Първо, всеки може да използва публичния ключ за криптиране на нещо, което може да декриптира само на частния ключ; На второ място, можете да използвате публичния ключ за дешифриране на криптиран частния ключ. Това е важно, за проверка на подписа, което може да създаде само таен ключ.
Заявка за сертифициращия орган включва подробности като това, което всеки човек или компютър ключът е предназначен, вида и надеждността на алгоритъма, както и публичната част на двойката ключове. Сертифициращ орган (CA) получава и проверява информацията в искането, и след това, с помощта на хеширане алгоритъм, който създава уникален идентификатор, съответстващи на информацията.
Използването на неговия личен ключ, СО криптира информацията за хашиш и го сглобява в стандартен формат (като X.509), създаване на сертификат, съответстващ на първоначалното искане. X.509 сертификата ще съдържа списък с приложения, включително самоличността на сертификат (темата), срок на валидност, публичен ключ и операциите, за които могат да бъдат използвани в сертификата. След това, сертификатът се връща на молещата; Този маркер, който по същество се казва: "Аз, сертифициращ орган (CA), гарантирам за този публичен ключ и тайна част, която отговаря за него, за всички от описаните тук методи се използват."
На органа по сертифициране корен (като най-високо ниво на веригата на доверие) самоподписани сертификати. Най-приемливи основните сертифициращи идват вградени в операционната система база или приложението, но могат да бъдат актуализирани или променени чрез опаковки или корпоративна среда. Между корен ТЗ и крайната точка на дървото (което обикновено се описва отделно лице или система) може да бъде едно или повече корен КО.
Веригата се състои от всички възли и всички предходни сертификати, вградени в тях подписан сертификат на това ниво. Трета страна човек се опитва да се валидира сертификат може да се провери на място изчислява хеш с разшифрован от самия сертификат, с помощта на придружаващия публичния ключ за тази конкретна CA или лице. По този начин се създава и напълно тествани верига от корена на крайния възел на дървото - предположи, разбира се, че основата на доверие.
статус сертификат Обновяване
Всеки добър сертифициращ орган са начини за разпространение на списък на сертификатите, че вече не трябва да се има доверие. Този списък анулирани сертификати (CRL) описва, издала предмети Калифорния е пряко направени невалиден. Удобно, местоположението на CRL е типично сертификат имот сертифициращ орган а.
Много приложения прекарват много повече време за зареждане на сертификат, ако той не може да провери веригата или РЛО при всеки възел във веригата. В зависимост от това, което защитава сертификата, потребителят може да искате или да не желае да му се доверите. Редовно актуализиран, широко достъпни разпределение точка CRL е от съществено значение за всеки сертифициращ орган, и най-вече за обществените корени.
Корените на земята верига сертификати, както и верига, свързваща всички те са базирани йерархия сертификат. Повечето клиенти системи и приложения предполагат, че крайната точка на сертификата за дърво е валиден само ако е на верига за надежден главен. Това може да бъде и юридическо сертифициращ орган, разположен в притежаването и под контрола на тази конкретна фирма или обществен корен CA (като VeriSign).
На последно място, във всяко добро криптографска система включва концепция за управление на жизнения цикъл. Компютрите по-бързо, много по-малко стойка алгоритми. Всеки добър криптосистема нуждае от способността да се поднови и да се премине към нови алгоритми и ключове с течение на времето. КО следва да бъдат актуализирани по подходящ начин, когато криптографски решен нестабилност и някои функции се въвеждат в експлоатация или извадени от него.
Изпълнение на S / MIME
Предполагаме, че вече има необходимата инфраструктура, което позволява операции, които ще опишем. В нашия случай, ние използваме Active Directory интегрирани сертификат Enterprise Server.
получаване на сертификати
Първата задача - е да се получи на съответни сертификати. За да направите това, отворете конзолата за мениджър Сертификат MMC Мениджмънт (certmgr.msc), щракнете с десния бутон на лична папка ( "Private"), изберете Всички задачи ( «всички задачи") изскачащ и изберете Заявка Нов ( «Заявка за нова") от списъка.
Това започва съветника за инсталиране на сертификат, както е показано на фиг. 1. По подразбиране ще се показва няколко опции, предназначени за фирми-важните от тях потребителски сертификат ( «потребителския сертификат"). По-късно той ще бъде използван, за да е възможно процесите на подписване и криптиране. Сертификатът трябва да бъде подходяща за следващия.
Фиг. 1 Заявка за сертификата
- Цифровите подписи (създаване на съобщение с печат за автентичност от създателя му)
- ключ криптографската сигурност (един ключ за защита за други технологии, като криптиране на файловата система)
- Сигурен обмен на електронна поща (шифровани съобщения, които могат да бъдат прочетени само от предназначението им получател в притежание на съответния частен ключ)
За изпращане на подписани S / MIME имейл свойства на криптографски ключ защита не се изисква. Въпреки това, за да изпращат или получават криптирана поща, този имот е необходимо, докато свойствата на подпис - не. По подразбиране, услуги сертификат Windows® шаблони включват тези три качества. Ако потребителят не е разрешено да поиска нови сертификати, те няма да се появи, когато стартирате съветника. Ако корпоративен орган за сертифициране не е на разположение, потребителят ще бъде представен "инсталация грешка" се посочва, че не може да се осъществи връзка с домейн или на сертифициращ орган. приемем, че един сертификат дава възможност за целите на това ръководство и подписът и криптографска защита.
сертификати Exchange
Най-лесният начин да започнат да обменят шифровани съобщения по електронна поща между двама потребители е да си изпращат съобщения подписани. След ново съобщение, потребителят кликне върху бутона "Вход". (Понякога бутона е скрит по подразбиране, за да Outlook, докато тя е била използвана най-малко веднъж. Тя може да се намери, като изберете "Опции за нови съобщения", а след това кликнете върху "Настройки за сигурност" и да изберете "Добавяне на цифров подпис на това съобщение" в диалоговия прозорец на свойствата безопасност.) бутон подпис (малко жълт плик с червена панделка на това, което казва "Вход") добавя цифров подпис към съобщението, за да се определи автентичността на нейния източник.
Фиг. 2, когато обменят сертификати не изнасят частния ключ
Всеки приемник след това ръчно създава запис за контакт в Outlook и добавя удостоверението за вписване на подателя. След като двама потребители са разменили сертификати, те ще имат възможност да обменят помежду си послания криптирана електронна поща.
отстраняване на неизправности
Понякога получателя затруднения при откриването на криптирана съобщението. Най-вероятният източник на проблеми тук са ненадеждни корен КО, междинни КО, които не могат да бъдат проверени, и не са на разположение РЛО.
Ненадеждно корен CA обикновено се появява в Outlook като съобщение за грешка, свързана с подписването: "Има трудности, свързани с подписването. кликнете върху бутона подпис "за повече информация. За решаване на проблема в рамките на Outlook, отвори определен сертификат, а след това върху "За CA. "От изскачащ диалог. Вижте посланието на раздела "Общи", или в диалоговия прозорец за сертификат. Ако това означава, че основен сертификат CA не е надежден, и искате да инсталирате, щракнете върху раздела Details. Щракнете върху "Copy във файла. "И следвайте инструкциите в съветника, приемайки всяко неизпълнение на задълженията и предоставяне на името на файла и папка по избор.
Вторият проблем е отбелязано по-горе, неуспех да се провери междинни сертифициращи органи, обикновено се появява в два случая: когато клиентът се опитва да проверява удостоверението, не могат да получат достъп до информация за местоположението на сертифициращия орган (AIA), посочено в удостоверението, или клиентът има вариант на удостоверението на междинния центъра сертифициране, която не съвпада с това, което произвежда CA (клиентът често изостава от версията или две). Тези условия се появяват, за да бъде много подобен на потребителския интерфейс на Outlook. Видяхме това само в много специални случаи, когато валидността на сертификата на междинния сертифициращ орган във веригата е изтекъл и удостоверението се издава отново преди Изтичащи издава сертификати на подчинените.
В действителност, този проблем се появява, когато има пропуски във веригата. Някои сертификати майки може да не са твърде подробни или не, вградени в терминален възел на дървото правилно, което допълнително усложнява ситуацията.
Фиг. 3 пълнене пропуски в верига сертификат
След получаване на веригата на сертификат изнася в получателят ще трябва да отворите и да импортирате веригата по същия начин, както сме внесени корена. Единствената разлика е, че избраната папка за съхранение трябва да бъде "Междинното сертифициращите органи". Ако съобщението се отваря и на удостоверението е показана като валиден за Outlook, а след това всичко работи правилно.
Що се отнася до третия проблем, липсата на CRL, поправката е сравнително лесно. Първоначалната реакция от Outlook ще изглежда много подобен на предишния проблем. Въпреки това, се показва грешката, дори ако основен или междинен подписване КО на се има доверие. За всяко ниво на веригата на сертификати отворен край, по-горе раздел със свойства сертификат информация и след това погледнете в полето тема "Разпространение точки списъците с невалидните (CRL)».
Разпределение на сертификати
Разпределение - това е най-лесната част. В действителност, подписано съобщението се прехвърля на вашия имейл сървър, който след това го изпраща от едно място на друго доказан начин - чрез SMTP. Единственият проблем, които сме виждали в предаването подписан или криптирана поща е, че някои системи поща отхвърлят или да се счупи, подписани или шифровани съобщения, които минават през тях. Коригиращи действия е да се работи с ръководителя на ИТ системата за производство на валидни видове съобщения. Разбира се, може да се наложи да приемат факта, че някои видове съобщения са блокирани. Получателят може да е добра причина да не се позволи на криптирани съобщения в определен работна среда.
отговори криптиране.
За да създадете шифрован отговор (ако приемем по-горе процес на възбуждане е вече приключила), изпращачът е необходимо да се създаде само съобщение и натиснете "Шифроване" (малко жълт плик със синята ключалката на това, че се казва "Encrypt") в прозореца създавате нови съобщения. Ако този бутон не е наличен, следвайте стъпките за изпращане на подписано съобщение, с изключение на последния, вместо което проверка на "съдържанието и приложенията Шифроване на съобщението".
S / MIME подпис не се изисква да изпратят на получателя на шифровано съобщение, но и двамата работят добре заедно, защото подписването позволява на читателя да се провери сървър (функцията за шифроване не удостоверява подателя). Процесът на кодиране ще се опита да криптиране на съобщение с помощта на известни публични ключове на всички получатели. Ако системата не може да намери сертификати за някои получатели, те ще бъдат маркирани в поп-нагоре диалоговия прозорец, който предлага да изпрати съобщението некриптиран, както е показано на фиг. 4.
Фиг. 4 Можете да решите да изпратите некриптиран съобщение, ако има проблем със сертификата
По подразбиране, подписване и криптиране трябва да работи с други сравними конфигурирани клиентски системи, но понякога обменят подписали или криптирани съобщения между няколко версии могат да доведат до проблеми, ако хеширане или криптиране алгоритъм не се поддържа предишното ниво. Ние сме изправени пред подобен проблем при изпращане на подписан електронна поща (като се използва SHA-512, тъй като хеш алгоритъм) потребител с помощта на Windows XP Service Pack 2. Защото получаващата система не подкрепят хеша, потребителят не е в състояние да провери подписа или прочетете съобщението. Въпреки това, ако Outlook настройки не са се променили по подразбиране, потребителите е малко вероятно да се срещнат много проблеми на този етап.
При получаване на съобщение, предназначено получател трябва да бъде в състояние да го отворите, ако наличната публичния ключ, свързан с публичния сертификат. В допълнение, потребителят може да се изисква да осигури допълнителен маркер, което потвърждава собствеността на таен ключ, в зависимост от това как е внедрен. Други потребители, които са завършили подобна процедура инициализация може да участва в подобни подписани и криптирани комуникации с получателя. Ако потребителят се е променило таен ключ (например, поради загуба на компютъра), е необходимо сертификати за повторно искане и да преразпределят подписаното съобщение или удостоверение файл сред тези, с които той желае да обменят шифровани съобщения.
Заключение.
Осъществяване подписан и криптиран S / MIME работа между двама потребители в две различни директории или организации, обикновено не е много по-сложно, отколкото изпълнява, както е описано по-горе. Подписът е много полезно, когато се използва правилно, тъй като удостоверява автентичността на съобщението. Криптирани съобщения осигуряват допълнително ниво на секретност за предаване на данни за поверителни комуникации. Заедно те предоставят потвърждение на изпращача и автентичността и поверителността на данните. Процес, описан тук позволява повечето потребителите лесно да се възползват от тези възможности.
Свързани статии