Certification Authority по Мрежова Сигурност 1



Дата18.09.2016
Размер263.57 Kb.
#10210
Софийски университет „Св. Климент Охридски”
Факултет по Математика и Информатика


Курсова работа

на тема:

Certification Authority




по

Мрежова Сигурност – 1


Разработил:

Симона Венциславова Милкова



Проверил: ......................

ФN: 43297





София, 2005 година
Съдържание


Увод 2

Същностни понятия 3

Ситуацията в България 9

Нужди 11


Осигуряване на сигурност и надеждност 11

Финансова база 12

Генериране и съхранение на частните ключове 12

Изисквания за цифровите сертификати 13

Алгоритми за криптиране. 13

Примерно изграждане на частна CA за нуждите на университет. 14

Избор на йерархия: 14

Изграждане на CA 15

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

Приложение 18







Увод

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


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

Същностни понятия

Протоколи като HTTP, SMTP, FTP, NNTP и Telnet не предлагат адекватна защита срещу подслушване, кражба и фалшификация на пренасяната информация, защото при създаването им сигурността не е представлявала голям проблем. SSL е голям плюс за мрежовите протоколи, тъй като внася известна сигурност в иначе несигурните TCP базирани протоколи.


Secure Sockets Layer (SSL) :универсален протокол за автентикация и комуникация между потребители и Web- сървъри.Той е най-използвания протокол в интернет и имплементира X.509.Тъй като е вграден в повечето известни browser-и , при инсталирането на цифров сертификат се активират SSL възможностите.

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

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

  • Криптирана SSL връзка.Интонацията, която се предава между клиент и сървър се криптира от изпращащия и се декриптира от получателя, предоставяйки висока степен на конфиденциалност. Той се състои от два под протокола: SSL record протокол и SSL handshake протокол.Първият се грижи за формата на предаваната информация, а вторият, използвайки първия, разменя съобщения между клиента и сървъра.Чрез тези съобщения могат да се извършат следните действия:

    • Автентикация на сървъра на клиента

    • Възможност да изберат криптиращ алгоритъм

    • Автентикация на клиента на сървъра

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

    • Установяване на криптирана SSL връзка.

    • SSL ръкостискане

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


Алгоритми за криптиране.
Въпреки че, SSL покрива повечето изисквания за сигурност, в много случаи не е достатъчно.Има много видове алгоритми за криптиране: симетрични, базирани на публичен ключ, криптографски hash функции и др.


  • Симетричните алгоритми използват един ключ за криптиране и декриптиране на информацията.Основния недостатък е че ключа трябва да остане скрит, а това е проблем при предаването му през мрежова среда.Симетрични алгоритми са: DES, 3DES, Blowfish, IDEA, Cast, RC2, RC4, RC5, FEAL, SAFER.




  • Проблемът с разменянето на ключове е решен при алгоритъма , базиран на публичен ключ.Той се основава на сложна математическа задача.Най-популярният алгоритъм е RSA. Други са the Digital Signature Algorithm (DSA) и Elliptic Curve Digital Signature Algorithm (ECDSA)..Алгоритъмът използва двойка ключове– един за криптиране и един за декриптиране на данните. Единият от тези ключове е проектиран да бъде споделян (разменян) между участниците в комуникацията и се нарича публичен ключ, а другият се съхранява във всяка една от страните и не се поделя и разкрива пред никого. Той се нарича частен ключ. Двата ключа са допълващи се (комплементарни). Когато единият се използва за криптиране, само другият може да декриптира информацията и обратно.
    Системата за криптиране с двоен ключ се основава на математическата релация между публичния и частния ключ. Частният ключ се генерира едва след като е известен публичният ключ. Съществуват две основни операции, асоциирани с криптографията чрез двоен ключ – криптиране и цифров подпис.

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

    • Цифров подпис също използва криптиране, но неговата цел е да докаже източника на информация, а не да подписва самите данни.Първо интонацията се hash-ра , използвайки някой от алгоритмите- MD2, MD5, or SHA-1, после се криптира, използвайки частния ключ, добавя се цифровия подпис, съдържащ публичния ключ и се изпраща.Проверката дали сертификата е валиден се състои в hash-ране на оригиналната информация , декриптиране, използвайки публичния ключ и сравнение на стойностите на hash функциите.Примерно, ако Б желае целият свят да бъде сигурен, че именно той е автор на дадено съобщение, той го криптира, използвайки частния си ключ, след което го изпраща. Данните не са защитени, защото всеки, който притежава публичния ключ на Б, ще може да ги разчете, но всеки, който стори това, ще бъде убеден, че съобщението е издадено от Б и не е променяно след това, т.е., че той е автор на съобщението. Това всъщност е и смисълът на цифров подпис.В криптографията, цифров подпис е метод на удостоверяване на цифрова информация, аналогично на реалния подпис, който човек използва в документи.Понякога, понятието цифров подпис се бърка с електронен подпис.Въпреки че, често се използват за едно и също нещо, има известна разлика: електронния подпис не е необходимо да се криптира , аналог е на адреса или телефона в даден документ.




  • Криптографски hash функции:информацията се редуцира до поле с фиксирана дължина. Hash еднозначно определя оригиналните данни.Вероятността да се получи същия hash от различни блокове данни е под 0.01%.Такива алгоритми са: MD2, MD5, or SHA-1.



Public key infrastructure е подредба, която проучва и гарантира, на трета страна (third-party), индетичността на даден потребител. Също така, свързва даден потребител с публичен ключ. като удостоверява, че ние комуникираме с този, с който си мислим.
Като използваме Public Key Cyptography, можем да сме сигурни, че само криптираната информация може да се декриптира с отговарящия частен ключ.

В реалния свят, често се случва да не знаем със сигурност, чий е публичния ключ, което е голям проблем.Единственото, което можем да направим е да се доверим на трета страна (third-party), която да удостовери, че този публичен ключ принадлежи на страната, която твърди, че е нейна собственост.


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

• Управление на ключовете – PKI улеснява издаването на нови публични ключове, изважда от употреба ключове, компрометирали своята надеждност, и управлява нивото на доверие, аташирано към ключовете на различните потребители.


• Публикуване на ключовете – PKI предлага добре дефиниран способ за всеки желаещ да намери и използва даден публичен ключ, както и информация за валидността на даден ключ.
• Използване на ключовете – PKI включва и набор от приложения, използващи ключове за криптиране и подписване на данните за обмен.
Основните елементи, които изграждат една PKI са Certification Authority, Registration Authority (RA) и публично достъпни хранилища за списъка с анулирани сертификати (Certificate Revocation List).

Цифровият сертификат е сертификат, който използва цифров подпис, за да свърже публичния ключ с набор от атрибути, между които е и името на собственика на сертификата, адрес и др., както и срок за валидност на този ключ.И тъй като сертификатът е един вид паспорт за своя собственик, много е важно всеки, който има достъп до този сертификат, да бъде убеден в неговата достоверност. Ето защо всеки сертификат съдържа информация за това кой го е издал. По този начин, когато даден сертификат се чете за извличане на публичния ключ или името на собственика, се проверява и коя организация го е издала. Ако организацията е в списъка от организации, на които потребителят се доверява, сертификатът „се признава“ за валиден. В противен случай сертификатът е безполезен за четящия. С други думи, ползването на цифрови сертификати е много подобно на използването на идентификационните документи в реалния живот, които също трябва да бъдат издадени от оторизирани организации.

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


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



Lightweight Directory Access Protocol (LDAP)- първоначално е бил олекотена версия на X.500 Directory Access Protocol, но сега вече е предпочитан от много организации.Важна негова характеристика, е че улеснява комуникацията между хората, съхранявайки информация за хора, организации, групи и др.Може да съхранява информация от всякакъв вид: email, адрес, fax, телефон,снимки,конфиденциална информация и др.

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




S/MIME(Secure/Multi-purpose Internet Mail Extension) базиран на технологии от RSA Data Security.Той предлага следните възможности: подписва и криптира съобщения и обвива информацията (enveloped data).


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

Има два вида CA.




  • Частната CA е отговорна за издаването на сертификати само на членове на собствената си организация, както и обратно: единствените потребители които й имат доверие са нейните членовете. Идеална е за корпоративни мрежи. Например, една компания може да изгради собствена CA за email, използвайки S/MIME като стандарт за криптиране и автентификация на съобщенията. Компанията ще издава сертификати на всеки работник, както и всеки работник ще конфигурира S/MIME съвместимия си email клиент, да разпознава фирмените сертификати. За частната CA верификацията на идентичността е прост и ясен процес, защото в дадена корпоративна среда, работниците са известни и могат да се идентифицират лесно чрез информацията предоставена от отдел човешки ресурси. В такъв случай, отдел човешки ресурси играе ролята на Registration Authority (RA).




  • Публичната CA издава сертификати на външни за компанията потребители. Степента на сигурност зависи от вида на CA, която е издала сертификата, и от типа на сертификата.Такива CAs са например Entrust, Verisign, Geotrust и др.

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


Обикновено публичната CA издава сертификати за общодостъпни web sites, изискващи криптиране и/или автентификация, често за електронна търговия, в която клиентска информация трябва да бъде изпратена безопасно. За такива операции е от съществена важност, клиента да изпрати информацията си до сайта, без да се тревожи че някои друг може да има достъп до нея.
За публичната CA, верификацията е значително по-труден процес, отколкото за частната CA. Информацията изисквана от субекта за доказване на неговата самоличност варира в зависимост от това дали той е частно или юридическо лице. За частно лице информацията може да е просто фотокопие на личната карта, докато за юридическо лице е необходим документ доказващ правото му да използва това име.
Независимо че повечето публични CA предлагат техните услуги срещу заплащане, те носят реална отговорност. Разбира се, не могат да предложат абсолютни гаранции, но за да бъде една CA наистина добра е необходимо да се ползва с доверието на потребителите. В противен случай няма да се задържи за дълго в подобен бизнес.


Registration Authority (RA) осъществява регистрацията на потребител и изпраща на CA заявка за издаване или отхвърляне на сертификат.Тя не се занимава с издаване на сертификати. RA разглежда подадените молби за издаване на сертификати като проверява предоставената информация.

Ситуацията в България

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

- дали изразеното волеизявление има правна стойност;

- дали положеният електронен подпис удовлетворява изискванията на правото;

- дали подписаният с електронни подписи документ представлява доказателствено средство пред съда.
Бяха изработвани няколко законопроекта докато се стигне до решението на МС от 13 октомври за внасянето на настоящия законопроект в НС. В него е отчетен опитът на всички държави в областта на високите технологии.
Законопроектът е изцяло съобразен с основните положения на Директива 1999/93/ЕС на Европейския парламент и Съвета на Европа от 13 декември 1999 г. относно рамката на Общността върху електронните подписи (в сила от 20 януари 2000 г.), както и с редица от успешно прилаганите вече законодателни решения в други страни.
Предметът на закона обхваща уредбата на електронния подпис, електронния документ и условията и редът за предоставяне на удостоверителни услуги.
Преди приемането на закона за Електронният подпис, доставчик на удостоверителни услуги е била Българската Стопанска Камара, която е предоставяла услугата чрез Белгиската GlobalSign. БСК не разполага със собствен център за издаване на сертификати за електронен подпис.
Комисията за регулиране на съобщенията (КРС) е регистрирала до момента два доставчика на удостоверителни услуги (ДУУ) за универсален електронен подпис.


№ по 
ред


ДУУ

Решение 


Дата

Удостоверение

Уеб сайт

1.

„Информационно обслужване“ АД

260

27.03.2003 г.

Удостоверение

www.StampIT.org

2.

„БАНКСЕРВИЗ“ АД

1113

25.09.2003 г.

Удостоверение

www.B-trust.org

На 27.03.2003 г. с решение No 260/27.03.2003 г. Комисията за регулиране на съобщенията регистрира „Информационно обслужване“ АД като доставчик на удостоверителни услуги. Дружеството е първият регистриран доставчик на удостоверителни услуги в страната и издава удостоверения за универсален електронен подпис.


У нас дейността на доставчика на удостоверителни услуги и съдържанието на издаваните от него удостоверения са регламентирани в закона за „Електронния документ и електронен подпис“ и наредбите по неговото прилагане. Регулирането на тази дейност от държавата се налага, за да може електронният подпис да се приравни на саморъчния.
Процедурата на „Информационно обслужване“ АД за издаване на удостоверение за електронен подпис е разработена така, че удостоверението се издава след представяне на всички необходими документи за идентифициране на лицето и след физическото му явяване.

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

На 25.09.2003 г. с решение No 1113/25.09.2003 г. Комисията за регулиране на съобщенията сертфицира Банксервиз за доставчик на удостоверителни услуги. С това Банксервиз стана втората фирма у нас, която има право да издава е-подпис от най-високо ниво.

Фирмата ще предложи на потребителите услугата B-Trust PKI, която осигурява идентификация на издателите на електронни документи. "За разлика от предлаганите от ИО услуги, ние ще издаваме удостоверения и за обикновен, и за универсален електронен подпис", коментира Любомир Цеков от Банксервиз. Услугите ще бъдат разделени в два класа, като второто ниво ще представлява универсалният електронен подпис. И в двата класа ще има персонални и професионални удостоверения. Наред с това, компанията ще издава и сървърни сертификати, гарантиращи идентичността на компютърна система или ресурс и връзката му с неговия публичен ключ. Всички сертификати са застраховани за сумата от 600 000 лева.



Нужди

Една CA трябва да е надеждна.За да отговори на това изискване, тя трябва да осигури надеждност в морално, материално, финансово и информационно отношение.


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

Осигуряване на сигурност и надеждност


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

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

  3. Солидна система за сертифициране.Това включва следните мерки за безопасност

    1. Системно правене на backup копия на информацията.

    2. Защита срещу природни бедствия-земетресения, пожари и наводнения.

    3. Защита срещу човешка грешка.

  4. Цялостност и яснота на предлаганите услуги. В частност, CA трябва да публикува пълен списък с анулираните сертификати(Certification Revocation List), така че хората да не се заблудят от отменен сертификат.

Финансова база


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

Това включва: мерки за предотвратяване на вътрешни нередности. предизвикани от собствените на CA, да имат високо квалифициран персонал и др.


Идентификация на кандидата.

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



  • За частно лице: шофьорска книжка, лична карта и др.

  • За организация: сертификат, че фирмата е регистрирана, сертификат за фирмения печат и др.

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



Съдържание на сертификата.

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



Публикуване на дигиталните сертификати.

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



Изтичане на валидността на сертификат.

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


Генериране и съхранение на частните ключове





  1. Частния ключ на CA трябва да се пази в отделен специално направен за целта модул, и да не може да се изтрие не оторизирано.




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



  1. Когато CA дава на клиента неговия чатен ключ, тя следва специални процедури , за да потвърди идентичността му.

За да предпази частните ключове от незаконен достъп, CA се нуждае от физическа защита на данните, например, като съхранява контролния модул в желязна кутия.

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

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

Както вече споменахме, основната функция на PKI е да свързва публичния ключ със определена идентификационна информация. Това свързване се прави с помощта на CA, която играе ролята на доверена трета страна (trusted third party). CA дигитално подписва определена информационна структура, съдържаща име и съответния публичен ключ.Тази информационна структура заедно с подписа на CA се нарича сертификат.От основна важност за сигурността и надеждността на една CA е тя да има сигурна система за сертифициране.


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

Алгоритми за криптиране.


Всеки алгоритъм , базиран на публичен ключ, се основава на сложна математическа задача.Най-популярният алгоритъм е RSA. Други са the Digital Signature Algorithm (DSA) и Elliptic Curve Digital Signature Algorithm (ECDSA).
Хардуер за генериране и съхранение на цифрови подписи.
Генерирането на дигитални подписи налага използването на специален хардуер.Той трябва да отговаря на опредени изисквания и зависи от самия алгоритъм. В момента, smart cards са най-разпространени.Те представляват микропроцесор с памет и могат да генерират и съхраняват ключове и сертификати.Самите функции за криптиране са вградени в самата карта.За да се достъпи информацията от картата са нужни специални четци и драйвери.
Модели за валидиране на дигитален подпис.
Потвърждаването на валидността на цифров подпис е математическа операция(резултата е истина или лъжа).Използва се публичния ключ на подписалия.

Приемането на подписа за валиден зависи от валидността на съответния публичен ключ. Основно има три модела: обвивачен(shell), хибриден и верижен.

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

Хибридния модел изисква всички сертификати в веригата от сертификати да е валиден, в момента на генериране на подписа.

Това е добър избор, но за предпочитане е третия модел: верижния.

В него, подписа е валиден ако подписващия притежава валиден сертификат, в момента на генериране на подписа.

Една гъвкава PKI трябва да може да преминава от един модел в друг.


Примерно изграждане на частна CA за нуждите на университет.

Избор на йерархия:





  1. Коренна йерархия.

      • Високо ниво на сигурност.

      • Позволява премахването на Root CA.

      • На върха седи Root CA , например това може да е кабинета на Ректора.Тя сама подписва издадените сертификати.

      • На второ ниво са подчинените CAs –това могат да са различните факултети. В сертификатите, издадени от Root

      • CA на подчинената CA, пише нейното име. В йерархията на СА, root сертификата може да подписва сертификати на други СА. Това означава, че всеки който го знае публичния ключ на root СА може да ги проверява всички сертификати издадени от СА в йерархията.




  1. Кръстосана йерархия

      • CA играе роля и на Root CA и на подчинена CA.

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

      • Много е удобно в случаите, когато двете организации имат вече изградени CAs

      • Кръстосана йерархия крие известни рискове.Това, че има още една Root CA води до излишно доверие между организациите.

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



Изграждане на CA





  1. Идентичност на CA: записва се във всеки издаден сертификат.




  1. Примерно:


Име: Софийски университет „Св. Климент Охридски”

Адрес: 1504 София, бул. "Цар Освободител"15

Телефон: (+359 2) 9460 255


  1. Инфраструктура:




  • Нашата CA ще играе роля на доверена трета страна (trusted third party), за да улесни процеса на утвърждаване на самоличността в университета.Това утвърждаване нарочно е представено със сертификат, така всяко съобщение ще е дигитално подписано и издадено от CA. Операциите, свързани със сертификационния процес, ще включват именуване, подходяща автентикация на кандидата, застраховка, анулиране и др. Ще предлагаме три нива на сертификационни услуги: клиентски сертификати, сървърни сертификати и Certificate Authority сертификати. Молби могат да се отправят по електронен път само ако става въпрос за подновяване на съществуващ сертификат.

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

  • Студенти и преподаватели могат да подадат молба за клиентски сертификат, който им дава гаранция за идентичността на собственика.Те трябва да представят документ за самоличност на длъжностното лице от Registration Authority(RA). Клиентските сертификати са много удобни за email услуги , online пазаруване, и други web-базирани услуги.

  • Certificate Authority сертификатите се издават от Root CA на подчинените CA.Така се изгражда самата йерархия и верижните сертификати.




  • Registration Authority(RA).

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

  • Назначава се специално длъжностното лице, което обработва молбите и валидира самоличността и предоставената информация на кандидата.Този човек трябва да е различен от човека, който одобрява молбите.Информацията на одобрените потребители се записва в отделен компютър- RA терминал, различен от CA машината за този факултет.

  • Хранилище.

  • За по лесно следене на все още висящите, одобрените и отхвърлените молби се прави базата данни, до която достъп има само RA и CA.За клиентите се прави потребителски интерфейс, чрез който могат да проверяват техния статус.Търсенето в базата може да се ускори като се използват индекси на атрибути като сериен номер на сертификата, дата на изтичане, име, и др.Високо производителен сървър, базиран на LDAP стандарта може да се използва за общодостъпно хранилище за листа с отказаните сертификати (Certificate Revocation List).


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

След като молбата е одобрена, на кандидата му се издава сертификат.

Този сертификат и съответния му публичен ключ се записват в хранилището и се публикуват на LDAP Directory server , където са достъпни за всеки.

Сертификат се смята за валиден ако:




  1. Е издаден от нашата CA

  2. Е публикуван на LDAP Directory server

  3. Не е включен в Certificate Revocation List

  4. Не е изтекъл

  5. Валидността му може да се удостовери от валиден Certificate Authority сертификат.

Обикновено, периода на валидност на клиентски и сървърни сертификати е 6 месеца, а на CA сертификати е 12 месеца.
Анулиране на сертификат.
Сертификат се анулира ако:


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

  2. В резултат на природно бедствие се е разкрила конфиденциална интонация,

  3. Ако има промяна в данните на клиента, записани ж сертификата.

. Сертификата може да се анулира и по желание на клиента.


.

Обобщение.
CA, която построихме се състои от следните компоненти:


  1. Registration Authority(RA)

  2. RA терминали-компютри разположени в факултетите, и имащи достъп до молбите за регистриране.

  3. Молба за регистриране- web приложение, което RA о студентите използват, за да взаимодействат с CA .

  4. Root CA- през по-голяма част от времето не е вързана в мрежа, за по-голяма сигурност.Включва се в мрежата на университета, за да изпрати на LDAP подновен лист с анулираните сертификати. Root CA се грижи за издаването на сертификати на подчинените си CA. Root CA ще обработи публичния ключ и копие от хеша, генериран от Декана и ще определи дали има съвпадение.Ако има, ще го одобри и ще запише информацията в LDAP.

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

  6. LDAP Directory Server-това е централа на всички процеси свързани с оторизацията и автентикацията на потребители.

        1. Той трябва да пази паролите, сертификатите и листа с отказаните сертификати за всеки оторизиран потребител.

        2. Сървърът трябва да е постоянно включен в мрежата.

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

  8. Сървъри-това са машини с данни, който могат да се до стъпват от студенти и преподаватели.Те трябва да притежават сървърен сертификат , издаден от CA на факултета.Те могат да бъдат достъпни през SSL протокол.

Картинката долу показва структурата на CA, която изградихме.







Приложение





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

  2. Университетски приложения- например това са регистрационни форми, молби за стипендии, библиотеки.Тази информация е нужно да се достъпва по сигурен начин, през SSL протокол.

Хардуерно решение:


  1. За обработването на 10,000 -- 250,000 заявки ни трябва Directory Server: с минимум 2GB HDD и 256MB RAM.

  2. За обработването на 250,000 -- 1,000,000 заявки ни трябва Directory Server: с минимум 4GB HDD и 512MB RAM .

  3. За обработването над 1,000,000 заявки ни трябва Directory Server: с минимум 8GB HDD и 1GB RAM



Софтуерно решение:
Netscape Certificate Server може да се използва за създаване и работа със стандартни цифрови сертификати, базирани на публичен ключ. За LDAP Directory Server може да се използва Netscape Directory Server.Разбира се, има голям брой безплатни CA софтуерни пакети. OpenSSL command-line tool позволява изграждането CA за малки организации, покривайки само най-основните изкисвания.Други безплатни софтуерни пакети са: OpenCA и pyCA.
В долната таблица за изброени някои комерсиални продукти


Продукт

Производител

Платформа

LDAP


Iplanet (Netscape)


Solaris 9 or 8 Operating Systems (SPARC Platform Edition)
Solaris 9 Operating System (x86 Platform Edition)
Red Hat Enterprise Linux AS 2.1
Microsoft Windows 2000/2003 Server and Advanced Server
HP-UX 11.11
IBM AIX 5.1


LDAP


NDS – Novell


Microsoft Windows Server 2003( in addition to previous versions of Windows)
Linux
NetWare
variety of UNIX operating systems

LDAP

Netscape Directory Server™



HP HP-UX 11.0 11i
Red Hat Linux

Advanced Server 2.1


Sun Solaris 8 and 9
Windows NT 4.0 Server and 2000 Advanced Server.

LDAP


Microsoft – Active

Directory




Windows Server 2003
Windows NT 4.0

CA

Entrust Authority Security Manager 7.1



Microsoft Windows Server 2003 Standard

Microsoft Windows Server 2003 Enterprise

Microsoft Windows 2000 Server

Microsoft Windows 2000 Advanced Server


Sun Solaris 9 и 8

HP®-UX 11i

IBM AIX 5.1



CA


Netscape Certificate

Server



Red Hat Linux Advanced Server 2.1
Sun Solaris 8 operating environments.


Използвана литература:


  1. Network Security with OpenSSL на O'Reilly

  2. матиралите предоставени на http://netsec.iseca.org/materials.

  3. en.wikipedia.org.

  4. Електронен подпис”, сп. Computer, 12/2003

  5. 2. в-к “Пари", стр. 19, 20/04/2001г.

  6. 3. “Електронният подпис - какво да очакваме от новия закон”, http://wt.noxis.net/feature.php?id=81

  7. http://www.informatik.tu-darmstadt.de/ftp/pub/TI/TR/TI-04-06.data_security.pdf

  8. http://bass.gmu.edu/courses/ECE543/reportsF01/vishnumala.pdf

  9. http://www.octech.org/icourses/ist/ulmer/IST221Site/ist221Ch10.htm

  10. други web sites.






Каталог: downloads -> 2004 2005-1 -> papers
downloads -> Конкурс за певци и инструменталисти „ Медени звънчета
downloads -> Задача Да се напише програма която извежда на екрана думите „Hello Peter. #include void main { cout }
downloads -> Окс“бакалавър” Редовно обучение I до III курс
downloads -> Конспект по дисциплината „Екскурзоводство и анимация в туризма" Специалност: "Мениджмънт в туризма"
downloads -> Alexander Malinov
downloads -> Тема 8: Линейни алгоритми. Отделяне на цифрите на число, преобразуване на числа. Алгоритмично направление: Алгоритми от теория на числата
downloads -> Отчет за научноизследователската, учебната и финансовата дейност на националния природонаучен музей при бан през 2013 г
downloads -> Закон за националния архивен фонд в сила от 13. 07. 2007 г
papers -> Спам и системи за защита от спам


Сподели с приятели:




©obuch.info 2024
отнасят до администрацията

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