Java за цифрово подписване на документи в уеб



страница4/14
Дата14.08.2018
Размер1.94 Mb.
1   2   3   4   5   6   7   8   9   ...   14

0.2.Цифрови сертификати и PKI


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

0.2.1.Модели на доверие между непознати страни


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

За съжаление математическо решение на този проблем няма. Съществуват алгоритми за обмяна на ключове, например алгоритъмът на Diffe-Helman, но те не издържат на атаки от тип „човек по средата” (main-in-the-middle).

За да започнат две страни сигурна комуникация по несигурна преносна среда, е необходимо по някакъв начин те да обменят публичните си ключове. Един от подходите за това е двете страни да се доверят на трета, независима страна, на която вярват, и с нейна помощ да обменят ключовете си. Тази трета страна е в основата на инфраструктурата на публичния ключ, но има различни подходи, по които се избира такава трета страна и различни принципи, на които се изгражда доверието. Тези подходи и принципи се дефинират от т. нар. „модели на доверие[PGP, 1999, стр. 29-33], [NZSSC, 2005].

Разпространени са различни модели на доверие между непознати страни –модел с единствена доверена страна, Web of trust, йерархичен модел, модел на кръстосаната сертификация (cross certification) и др.


Модел с единствена доверена страна


Моделът с единствена доверена страна (директно доверие) е най-простият. При него има единствена точка, централен сървър, на който всички вярват. Сървърът може да съхранява публичните ключове на всички участ­ници в комуника­цията или просто да ги подписва със своя личен ключ, с което да гарантира истинността им.

На фигура 1-3 е показан схематично моделът на директно доверие:





Фигура 0 3. Директно доверие

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

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

Модел „Web of trust”


Моделът “Web of trust” е приложим при малки групи участници, между някои от които има предварително установено доверие. При този модел всеки участник знае истинските публични ключове на част от останалите (има доверие на своите приятели). За установяване на доверие между непознати участ­ници не е необходим централен сървър, който да съхра­нява ключовете на всички, а доверието се трансферира транзитивно от приятел на приятел. Възможно даден участник да подписва цифрово пуб­личните ключове на всички участници, на които има директно доверие.

На фигура 1-4 е показан моделът „Web of trust” в действие:





Фигура 0 4. Модел на доверие “Web of trust”

Ако даден участник A има директно доверие на друг участник B, а участник B има директно доверие на участник C, то може да се счита, че участник A има индиректно доверие на участник C. По този начин всеки участник може транзитивно да изгради своя мрежа на доверие.

По модела на Web of Trust работи една от най-големите световни системи за подписване на електронна поща и други документи – PGP (Pretty Good Privacy).

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


Йерархичен модел на доверие


При йерархичния модел на доверие всички участници вярват в няколко доверени трети страни, наречени сертификационни органи (certification authorities – CA). Сертификаци­онните органи от своя страна трансферират доверието на свои подчинени сертификационни органи, а те също могат да го трансферират или да потвърдят доверието към някой конкретен участ­ник в комуникацията.

Нa сертификационните органи от първо ниво (root CA) се вярва безус­ловно. Техните публични ключове са известни предварително на всички участници. На сертификационните органи от междинно ниво се вярва индиректно (транзитивно). Техните публични ключове са подписани от сертификацион­ните органи на предходното ниво. На конкретните учас­тници в комуника­цията се вярва също транзитивно. Техните публични клю­чове са подписани от междинните сертификационни органи (фигура 1-5):





Фигура 0 5. Йерархичен модел на доверие

Йерархичният модел на доверие е силно разпространен в Интернет, при финансови, e-commerce и e-goverment приложения. Той е мощен и работи добре при голям брой участници.

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

Хибриден модел „кръстосана сертификация”


Хибридният модел на кръстосана сертификация се базира на йерархии от сертификационни органи и участници в комуникацията (както при йерар­хичния модел), но позволява транзитивно прехвърляне на доверие между отделните йерархии (както в „Web of trust” модела). Използва се при нужда от обединяване на няколко йерархични инфраструктури на доверие.

На фигура 1-6 моделът е показан схематично:





Фигура 0 6. Хибриден модел на кръстосана сертификация

Кой модел да използваме?


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

0.2.2.Цифрови сертификати и инфраструктура на публичния ключ


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

Цифрови сертификати


Цифровите сертификати свързват определен публичен ключ с определено лице. Можем да ги въз­приемаме като електронни документи, удостоверя­ващи, че даден публичен ключ е собственост на дадено лице [PGP, 1999, стр 21-27].

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

Съществуват различни стандарти за цифрови сертификати, например PGP (Pretty Good Privacy), SPKI/SDSI (Simple Public Key Infrastructure / Simple Distributed Security Infrastructure) и X.509. В практиката за целите на циф­ровия подпис най-масово се използват X.509 сертификатите. Те са ориен­тирани към йерархичния модел на доверие.

Стандартът X.509


X.509 е широко-възприет стандарт за цифрови сертификати. Един X.509 цифров сертификат съдържа публичен ключ на дадено лице, информация за това лице (име, организация и т. н.), информация за сертификационния орган, който е издал сертификата, информация за срока му на валидност, информация за използваните криптографски алгоритми и различни други детайли.

Инфраструктура на публичния ключ


Инфраструктурата на публичния ключ (public key infrastructure – PKI) предоставя архитектурата, организацията, техниките, практиките и проце­дурите, които подпомагат чрез цифрови сертификати приложението на криптографията, базирана на публични ключове (public key cryptography) за целите на сигурната обмяна на информация по несигурни мрежи и преносни среди [GlobalSign, 1999].

PKI използва т. нар. сертификационни органи (certification authorities), които управляват и подпомагат процесите по издаване, анулиране, съхра­няване и верификация на цифрови сертификати.

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

Има различни типове PKI инфраструктура, но ние ще разгледаме само най-разпространения тип – този с йерархичен модел на доверие, който широко се използва в Интернет (например при HTTPS протокола за сигурна връзка между уеб браузър и уеб сървър).


Услуги на PKI инфраструктурата


PKI инфраструктурата има за цел да осигури следните услуги на своите потребители:

  • Конфиденциалност при пренос на информация. Осъществява се чрез шифриране на информацията с публичен ключ и дешифриране със съответния му личен ключ.

  • Интегритет (неизменимост) на пренасяната информация. Осъщест­вява се чрез техно­логията на цифровия подпис.

  • Идентификация и автентикация. Цифровите сертификати осигуря­ват идентификация на даден участник в комуникацията и позволяват той да бъде автентикиран по сигурен начин. Сертификационните органи гарантират с цифров подпис, че даден публичен ключ е на даден участник.

  • Невъзможност за отказ (non-repudiation) от извършено действие. Осъществява се чрез цифрови подписи, които идентифицират участника, извършил дадено действие, за което се е подписал.

Сертификационни органи


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

Сертификационен орган (certification authority – CA) е институция, която е упълномощена да издава цифрови сертификати и да ги подписва със своя личен ключ [Raina, 2003, стр 30-31]. Целта на сертификатите е да пот­върдят, че даден публичен ключ е притежание на дадено лице, а целта на сертифика­ционните органи е да потвърдят, че даден сертификат е истин­ски и може да му се вярва. В този смисъл сертификационните органи се явяват безпристрастна доверена трета страна, която осигурява висока степен на сигурност при компю­търно-базирания обмен на информация.

Сертификационните органи се наричат още удостоверяващи органи или доставчици на удостоверителни услуги.

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

Регистрационен орган


Регистрационният орган (registration authoruty – RA) е орган, който е упъл­номощен от даден сертификационния орган да проверява самоличността и автентичността на заявителя при заявка за издаване на цифров сертифи­кат. Сертификационните органи издават цифрови сертификати на дадено лице след като получат потвърждение от регистрационния орган за него­вата самоличност [Raina, 2003, стр. 33-35].

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


Ниво на доверие в сертификатите


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

Ниво на доверие в сертификационните органи


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

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

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

Световно утвърдени сертификационни органи


Сред най-известните утвърдени глобални световни сертификационни органи са компаниите: GlobalSign NV/SA (www.globalsign.net), Thawte Consulting (www.thawte.com), VeriSign Inc. (www.verisign.com), TC TrustCenter AG (www.trustcenter.de), Entrust Inc. (www.entrust.com) и др.

Български сертификационни органи


В България има няколко сертификационни органа, утвърдени от закона за универсалния електронен подпис и комисията за регулиране на съобще­нията (www.crc.bg). Сред тях са фирмите: “Информационно обслуж­ване” АД (www.stampit.org) и “Банксервиз” АД (www.b-trust.org).

Йерархична структура на сертификационните органи


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

Един сертификационен орган може да бъде от първо ниво (top-level certification authority; Root CA) или да бъде от някое следващо ниво (вж. фигура 1-7):





Фигура 0 7. Йерархия на сертификационните органи

Сертификационните органи от първо ниво при започването на своята дейност издават сами на себе си сертификат, който подписват с него самия. Тези сертификати са саморъчно-подписани и се наричат Root-сертифи­кати.

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

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


Подписване на сертификати


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

Сертификационните органи издават на своите клиенти (крайните потребители) сертификати, които не могат да бъдат използвани за подписване на други сертификати. Ако един потребител си купи сертификат от някой сертификационен орган и подпише с него друг сертификат, новоподписаният сертификат няма да е валиден.

Един сертификационен орган издава сертификати, с които могат да бъдат подписвани други сертификати, само на други сертификационни органи, като по този начин ги прави непосредствено подчинени на себе.

Саморъчно подписани сертификати


Един сертификат може да бъде подписан от друг сертификат (най-често собственост на някой сертификационен орган) или да е подписан от самия себе си.

Сертификатите, които не са подписани от друг сертификат, а са подписани от самите себе си, се наричат саморъчно-подписани сертификати (self-signed certificates). В частност Root-сертификатите на сертификационните органи на първо ниво се явяват саморъчно-подписани сертификати [Wikipedia, SSC, 2005].

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

Саморъчно подписани сертификати и модел на директно доверие


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

Локален сертификационен орган


Описаната схема за сигурност, базирана на self-signed сертификати може да се подобри, като фирмата изгради свой собствен локален сертифика­ционен орган за служителите си. За целта фирмата трябва първоначално да си издаде саморъчно-подписан сертификат, а на всички свои служители да издава сертификати, подписани с него. Така първоначалният сертифи­кат на фирмата се явява доверен Root-сертификат, а самата фирма се явява локален сертификационен орган от първо ниво.

Изграждането на локален сертификационен орган се поддържа стандартно от някои операционни системи, например от Windows 2000 Server и Windows 2003 Server, които предоставят т. нар. certificate services.


Рисковете на директното доверие и локалната сертификация


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

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


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

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


Сертификационни вериги


Когато един сертификационен орган от първо ниво издава сертификат на свой клиент, той го подписва със своя Root-сертификат. По този начин се създава верига от сертификати, състояща се от два сертификата – този на сертификационния орган, предхождан от този на неговия клиент.

Вериги от сертификати (сертификационни вериги, certificate chains, certification paths) се наричат последователности от серти­фикати, за които всеки сертификат е подписан от следващия след него. В началото на веригата обикновено стои някакъв сертификат, издаден на краен клиент, а в края на веригата стои Root-сертификатът на някой сертификационен орган. В средата на веригата стоят сертификатите на някакви междинни сертификационни органи [RFC 3280, раздел 3.2].

На фигура 1-8 е даден пример за сертификационна верига:



Фигура 0 8. Сертификационна верига

Тя започва от сертификата на крайния клиент (Thawte Freemail Member), който е подписан от сертификата на междинен сертификационен орган (Thawte Personal Freemail Issuing CA) и завършва с root-сертификата на сертификационен орган от първо ниво (Thawte Personal Freemail CA).

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

Верификация на цифрови сертификати


Има няколко подхода за проверка на валидността на цифрови сертифи­кати. В зависимост от модела на доверие (модел с единствена доверена страна, йерархичен модел, модел Web of trust и т. н.) сертификатите могат да се проверяват по различни начини.

Ние ще разгледаме два начина за проверка на цифрови сертификати – директна верификация и верификация на сертификационна верига.


Директна верификация на сертификати


При директната верификация се проверява срокът на валидност на серти­фиката и се проверява дали той е издаден директно от сертификационен орган, на който имаме доверие. Обикновено директната верификация се използва при модел на доверие с единствена доверена страна (локален сертификационен орган).

Реализацията е много лесна – просто се прове­рява дали даденият сертифи­кат е директно подписан от сертификат, на който имаме доверие. За целта системата, която извършва такава проверка, трябва да поддържа мно­жество от доверени сертификати за директна проверка.


Верификация на сертификационна верига


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

На един сертификат, който се намира в началото на дадена сертифика­ционна верига може да се вярва само ако тази сертификационна верига бъде успешно верифицирана. В такъв случай се казва, че този сертификат е проверен сертификат (verified certificate).

Верификацията на една сертификационна верига включва проверка дали всеки от сертификатите, които я съставят, е подписан от следващия серти­фикат във веригата, като за последния сертификат се проверява дали е в списъка на Root-сертификатите, на които безусловно се вярва. За всеки от сертификатите се проверява допълнително срокът му на валидност и дали има право да подписва други сертификати [RFC 3280, раздел 6].

Доверени Root-сертификати


Всеки софтуер за проверка на сертификационни вериги поддържа списък от доверени Root-сертификати (trusted root CA certificates), на които вярва безусловно. Това са най-често Root-сертификатите на утвърдените глобални (све­товни) сертификационни органи.

Например уеб браузърът Microsoft Internet Explorer идва стандартно със списък от около 150 доверени Root-сертификата, а браузърът Mozilla при първоначална инсталация съдържа около 70 доверени сертификата.


Процесът на верификация на сертификационна верига


Проверката на една сертификационна верига включва не само проверка на това дали всеки сертификат е подписан от следващия и дали сертификатът в края на тази верига е в списъка на доверените Root-сертификати.

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

При проверката на дадена сертификационна верига се проверява и дали някой от сертификатите, които я съставят, не е анулиран (revoked). На процеса по анулиране на сертификати ще се спрем малко по-късно.

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

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

0.2.3.Хранилища за сертификати


В системите за електронно подписване на документи се използват защи­тени хранилища за ключове и сертификати (protected keystores). Едно такова хранилище може да съдържа три типа елементи – сертифи­кати, сертификационни вериги и лични ключове.

Хранилищата са защитени с пароли


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

Стандарти за защитени хранилища


Има няколко разработени стандарта за защитени хранилищата за ключове и сертификати, например JKS (Java Key Store), PKCS#12 и смарт-карти (PKCS#11).

Стандартът PKCS#12


Най-разпространен е стандартът PKCS#12, при който хранилището се съхранява във вид на файл със стандартното разширение .PFX (или по-рядко използваното разширение .P12). Едно PKCS#12 хранилище обик­новено съдържа един сертификат, съответен на него личен ключ и сертификационна верига, удостоверяваща автентичността на сертификата [PKCS#12]. Наличието на сертификационна верига не е задължително и понякога в PFX файловете има само сертификат и личен ключ.

В повечето случаи за улеснение на потребителя паролата за достъп до един PFX файл съвпада с паролата за достъп до личния ключ, записан в него. Поради тази причина при използване на PFX файлове най-често се изисква само една парола за достъп.


Смарт карти


Смарт картите (smart card) представляват магнитни или чип-карти, които съхраняват чувстви­телна информация (лични ключове, сертификати и др.) и защитават много по-сигурно информацията, отколкото файловете с PFX хранилища.

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

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

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


Стандарти за достъп до смарт карти


Смарт картите имат собствен криптопроцесор, собствена операционна система, защитена памет и собствена файлова система. Достъпът до тях става на различни нива с различни протоколи. Стандартът ISO 7816 (http://www.maxking.com/iso78161.htm) описва основните компоненти на смарт картите и работата с тях на ниско ниво.

На по-високо ниво за достъп до смарт карти се използва стандартът PKCS#11, който дефинира програмен интерфейс за взаимодействие с криптографски устройства (cryptographic tokens) – като смарт карти, хар­дуерни крипто­графски ускорители и други [PKCS#11].

Софтуерът, който се доставя заедно със смарт картите, обикновено съдържа имплементация на PKCS#11 за съответната карта и за съответния карточетец.

PKCS#11 стандартът не позволява физически да се извличат личните ключове от смарт карта, но дава възможност за използване на тези ключове с цел шифриране, дешифриране или подписване на данни. Разбира се, за да се извърши подобна операция, е необходимо преди това потреби­телят да въведе своя PIN код, който защитава достъпа до картата.

PKCS#11 стандартът предоставя интерфейс за достъп до защитени храни­лища за ключове и сертификати, съхранявани върху смарт карта. По тази причина със смарт картите може да се работи по начин, много подобен на работата с PKCS#12 хранилища. Една PKCS#11 съвместима смарт карта, обаче, има много повече възможности от едно PKCS#12 хранилище.

0.2.4.Издаване и управление на цифрови сертификати


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

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


Издаване на сертификат през Интернет


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

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

За някои видове сертификати личните данни могат се състоят единствено от един проверен e-mail адрес, докато за други те могат да включват пълна информация за лицето – имена, адрес, номер на документ за самоличност и т.н. Проверката на личните данни става по процедура, определена от съответния сертификационен орган.

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

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

Сертификати за тестови цели


За тестови цели могат да бъдат използвани демонстрационни цифрови сертификати, които някои известни сертификационни орган като Thawte, VeriSign и GlobalSign издават на потен­циални клиенти от своите сайтове.

Срещу валиден e-mail адрес Thawte издават напълно безплатно сертифи­кати за подписване на електронна поща. Те могат да бъдат получени само за няколко минути от адрес http://www.thawte.com/email/.

VeriSign издават на потенциални клиенти демонстрационни сертификати със срок на валидност 60 дни също срещу валиден e-mail адрес от http://www.verisign.com/client/enrollment/index.html.

GlobalSign също предлагат демонстрационни серти­фикати срещу валиден e-mail адрес от сайта си http://secure.globalsign.net/, но техните са с валидност 30 дни.


Сертификатите в уеб браузърите


Повечето уеб браузъри могат да използват съхранените в тях сертификати и лични ключове за автентикация пред защитени SSL сървъри и за някои други цели. Много E-Mail клиенти също могат да използват сертификатите, съхранявани в уеб браузърите, при подписване, шифриране и дешиф­риране на електронна поща.

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


Експортиране на сертификат от уеб браузър в PFX хранилище


След като имаме сертификат с личен ключ, инсталиран в нашия уеб браузър и искаме да го ползваме от външно приложение, трябва да го експортираме във формат PKCS#12 (в .PFX файл).

В Internet Explorer експортирането на сертификат и личен ключ става от главното меню чрез командите Tools | Internet Options | Contents | Certificates | Export (фигура 1-9):





Фигура 0 9. Експортиране на сертификат от Internet Explorer

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

В Netscape и Mozilla можем да експортираме сертификати от хранилището на уеб браузъра чрез командите Edit | Preferences | Privacy & Security | Certificates | Manage Certificates | Backup (фигура 1-10):



Фигура 0 10. Експортиране на сертификат от Mozilla

Файлови формати за съхранение на сертификати


Форматът PKCS#12 (файлове от тип .PFX/.P12) се използва най-често за съхранение на цифров сертификат, придружен от сертификационната си верига и личен ключ, съответстващ на публичния ключ на сертификата.

При съхраняване на X.509 сертификати, за които нямаме съответен личен ключ, по-често се използват други файлови формати. Най-често се изпол­зва кодирането ASN.1 DER, при което сертификатите се записват във файлове с разширение .CER (или по-рядко разширения .CRT или .CA).

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

Сертифи­кационните органи разпространяват Root-сертификатите си във вид на CER файлове, обикновено от своя уеб сайт.


Смарт картите в уеб браузърите


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

Internet Explorer използва вграденото в Windows хранилище за сертифи­кати (т. нар. Windows Certificate Store), в което могат да се импортират сертификати от смарт карти.

Mozilla използва свое собствено хранилище за сертификати и позволява в него да се импортират сертификати от смарт карта.

Импортирането става като се използва PKCS#11 имплементацията за съответната смарт карта. Това е библиотека (.dll файл под Windows и .so файл под UNIX/Linux), който осигурява достъп до информацията и функциите от смарт картата по стандарта PKCS#11. Тази библиотека обикновено се разпространява заедно с драйверите за карточетеца и съответната смарт карта.


0.2.5.Анулирани сертификати


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

Списъци на анулираните сертификати (CRL)


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

Тези списъци се подписват цифрово от сертификационния орган, който ги издава, и се наричат списъци на анулираните сертификати (certificate revocation lists – CRL). В един такъв списък се посочват името на сертификационния орган, който го е издал, датата на издаване, датата на следващото издаване на такъв списък, серийните номера на анулираните сертификати и специфичните времена и причини за това анулиране.

Списъците с анулирани сертификати обикновено се записват във файлове с разширение .CRL и се разпространяват от уеб сайтовете на съответните сертификационни органи. Пример за списък с анулираните сертификати е този на StampIT: http://www.stampit.org/crl/stampit.crl (фигура 1-11):



Фигура 0 11. Списък с анулирани сертификати

Повече информация за CRL списъците може да се намери в тяхната официална спецификация – [RFC 3280, раздел 5].


Проверка на сертификати по OSCP


OCSP (Online Certificate Status Protocol) е протокол за проверка на валид­ността на сертификат в реално време. Чрез него може да се отправи заявка към сертификационния орган, издал даден сертификат, и да се провери дали в настоящия момент този сертификат е валиден.

Проверката на статуса се осъществява чрез използване на OCSP клиент (OCSP Requestor) и OCSP сървър (OCSP Responder). OCSP клиентът се обръща към OCSP сървъра на сертификационния орган, който дава отговор за статуса на сертификата. Този отговор е електронно подписан със сертификата на OCSP сървъра и съдържа както информация за проверявания сертификат, така и времето на обработка, което служи като доказателство за валидност. OCSP протоколът е описан в [RFC 2560].


1   2   3   4   5   6   7   8   9   ...   14


База данных защищена авторским правом ©obuch.info 2016
отнасят до администрацията

    Начална страница