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

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 е показан схематично моделът на директно доверие:

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

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

Модел „Web of trust”

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 
  Конфиденциалност при пренос на информация. Осъществява се чрез шифриране на информацията с публичен ключ и дешифриране със съответния му личен ключ.
  
• 
  Интегритет (неизменимост) на пренасяната информация. Осъщест­вява се чрез техно­логията на цифровия подпис.
  
• 
  Идентификация и автентикация. Цифровите сертификати осигуря­ват идентификация на даден участник в комуникацията и позволяват той да бъде автентикиран по сигурен начин. Сертификационните органи гарантират с цифров подпис, че даден публичен ключ е на даден участник.
  
• 
  Невъзможност за отказ (non-repudiation) от извършено действие. Осъществява се чрез цифрови подписи, които идентифицират участника, извършил дадено действие, за което се е подписал.
  

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вериги от сертификати (сертификационни вериги, 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).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Смарт карти

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

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

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

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

На по-високо ниво за достъп до смарт карти се използва стандартът 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 адрес, докато за други те могат да включват пълна информация за лицето – имена, адрес, номер на документ за самоличност и т.н. Проверката на личните данни става по процедура, определена от съответния сертификационен орган.

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

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

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

Срещу валиден 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 дни.

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

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

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

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

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

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



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

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

При съхраняване на 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.Анулирани сертификати

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

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

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



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

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

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

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