Въведение и приложение на PKI базирани информационни технологии 1. Преглед на PKI инфраструктурата. Какво налага използването и ? 1.1 През Интернет минава свободно информацията, която е не кодирана и не доверена. 1.2 Преминава и важна/поверителна информация за много приложения. - Е-Комерс приложения - Софтуерни продукти - Финансов софтуер - Корпоративна информация и т.н 1.3 Множество проблеми свързани със сигурността на информацията. 1.3.1 Частна информация - Подслушване - Interception 1.3.2 Автентикация - spoofing - подмяна на самоличността 1.3.3 Цялостност на информацията - модификация - промяна на информацията преди да достигне целта си 1.3.4 Не отричане (нотификация) - Non-repudation - доказателство, че участващите страни са получили информацията 1.4 Сигурни алгоритми - съвсем бегло повторение на казаното на лекцията за Криптографията 1.4.1 Симетрични алгоритми - Triple-DES, DES, CAST, RC2, IDEA 1.4.2 Асиметрични алгоритми - Public Key Algorithms - RSA, DSA, Diffie-Hellman, Elliptic Curve 1.4.3 Хеширащи алгоритми и приложения 1.4.3.1 Приложения в програмирането - кратко допълнение към лекцията за Криптография - хеш функции, при обекти, хеш таблици и т.н. - дефиниция на хеш - Процес при който математически се преобразува наредена последователност от данни до поле с фиксирана големина. - уникално репрезентира първоначалната информация - вероятността да получим една и съща хеш стойснот при различни първоначални данни е < 0.001% (зависи от конкретния алгоритъм) - SHA-1, MD5, RIPEMD - приложения и евентуално разлики ;) 1.5 Симетрично кодиране - кратко обяснение - кодиране с един ключ - къде може да се използва - локална мрежа, ограничен кръг от хора - къде не се препоръчва да се използва - не се препоръчва във Интернет или други големи и глобални мрежи. - ако на един потребител му е слаба защитата и бъде разбита, то с неговия ключ може да се подслуват всички останали * ключът е един и същ за всички участници 1.6 Асиметрични алгоритми - кратко обяснение - кодиране с двойка ключове 2. Цифров или електроен подпис. 2.1 Какво е електронен подпис? - резултат от кодирането на хеш кода, извлечен от съответната информация 2.2 Подписването - е процес обратен на Верификацията - с частнния ключ се подписват данните - с публичния ключ се верифицира подписа 2.3 Технология на подписването с електрония подпис 2.3.1 Генериране на хеш код на данните - използване на някой наличен алгоритъм за хеширане 2.3.2 Кодиране на хеш кода с частния ключ на изпращача - кодиране на хеша посредством RSA или съответния алгоритъм използван за генериране на ключовете 2.3.3 Добавяне на получената сигнатура и копие на публичния ключ на изпращача. - полученият подписан хеш код със копие от публичния ключ се добавят към края на данните, които са били подписани 2.4 Технология на верификация на електрония подпис 2.4.1 Генериране на хеш код на оригиналните данните - пресмята се хеш кода на първоначалните данни, като се използва същия хеширащ алгоритъм както при подписване 2.4.2 Декодиране на електрония подпис - всеки електронен подпис съдържа копие на публичния ключ - декодират се електрония подпис (сигнатура) посредством публичния ключ на изпращача - получава се хеш 2.4.3 Сравняват се резултатите(хешовете) от хеширането и декодирането. - ако хешовете съвпадат електрония подпис е верифициран - ако хешовете се различават тогава данните най-вероятно са променени по време на преноса им 2.5 Критични въпроси - Как получателя може да провери и идентифицира произхода на публичния ключ на изпращача? - Как изпращача може да провери и идентифицира произхода на публичния ключ на получателя? 3. Цифрови сертификати. 3.1 Предназначение - Преди двете страни да започнат да обменят информация използвайки PKI криптография, всяка една от тях иска да е сигурна, че другата е автентикирана (проверена). Нека А и Б са участниците в комуникацията. - Преди Б да приеме съобсщение подписано от А, Б иска да бъде сигурен, че публичния ключ принадлежи на А не на някой, който се представя за А. - Един от възмозните начини да бъдем сигурни е като използваме услугите на трета доверена страна - CA (Certification Authority) - Веднъж след като А предостави доказателства за самоличността си пред Certification Authority, CA създава съобщение съдържащо името и друга лична информация на А, както и публичния и ключ. Това съобщение се нарича Цифров сертификат. 3.2 Какво всъщност представлява Цифровия сертификат. 3.2.1 Цифровия сертификат е X.509 базирана структура със цифров подпис. Данните в нея описват кой е собственик на сертитификата, кой е подписал този сертификат и друга свързана информация. X.509 Certificate __________________________________ Version # Serial # Signature Algorithm Issuer Name Validity Period Subject Name Subject Public Key Issuer Unique ID Subject Unique ID Extensions __________________________________ CA Authorized - Digital Signature 3.2.2 Когато сигнатурата е подписана от CA, то на сигнатурата може да се вярва. - след като данните биват подписани, те вече няма да могат да бъдат променени "незабелязано". - допълнителните данни(Extensions) могат да бъдат и биват използвани за нуждите на крайните приложения 3.3 Етапите през които преминава един Цифров сертификат Key pair generated | |-----------------------> Certificate issued | | | | New key pair Key pair in use ---------------> Private key compromised | generated | | | Certificate expires Certificate revoked | | Re-certify <------------ Key pair lifetime exceeded? 3.4 Списък със анулирани сертификати - Certificate Revocation Lists - CA периодично публикуват структура от данни наречена CRL, която е описана в X.509 стандарта. - Всеки анулиран сертификат се идентифицира в CRL със собствения си сериен номер. т.е. CRL е списък от серийни номера на цифрови сертификати. - CRL-ите най-често се разпространяват на известни Web URL адреси или от собственna X.500 базирана директорийна структура. 4. Участници в PKI инфраструктурата. 4.1 Регистриращ орган - RA (Registration Authority ) - идентифицира и доказва самоличността на потребителите. 4.2. Сертификационен орган или CA (Certification Authorities) - издава съотвентие цифрови сертификати и CRL списъци 4.3 Хранилища или Repositories. - публично достъпни бази данни, които съхраняват цифровите сертификати и CRL списъци 5. Регистриращ орган - RA 5.1 Какви функции изпълнява ? - продава и препродава сертификати на крайните клиенти - проверя идентичноста на клиентие и съответно ги одобрява или отхвърля - *валидира със сертификат приложения - одобрява заявките за двойки ключове както и за сертификати - одборява заявките за възстановяване на съхранени ключове - почти не се практикува, но по някога е полезно - (S-MIME процеса) - приема и анализира заявките за анулиране на сертификати - физически предоставя *token на хората или на съответните упълномощени лица 6. Сертификационен орган - CA. Сертификационния орган - основата на вярата. 6.1 Какви функции изпълнява ? - Трета независима страна на доверие - Издава и поддържа цифровите сертификати - Поддърза списъци със анулираните и подновените сертификати - Указва и поставя правила за използването на съответните цифрови сертификати 6.2 Какво е важно за сертифициращия орган ? - опит, високо надеждна и с игурна архитектур и др. Има световни организации, които са въвели стандарт за CA. Всеки CA трябва да го покрие. В него се включени и описани до най-малката подробност всички процедури и правила при организиране на структурата. 7. Правила или Сертификационна полица - CP (Certificate Policy) 7.1 Каква и на кого е тази полица? За какво служи ? - специфицира основните(минимални) изсиквания за издаване на цифров цертификат (като минимален набор от документи и т.н.) - представлява неформален договор между клиентие и нея - набор от правила, които едновременно указват и котролират PKI имплементацията - (дадени полета от сертификата за какво да се използват) - документ описващ какво точно е сертификата - набор от правила важащи за съхранението на сертификатите - начин за съвет и помощ на тясно свързани организации 8. Сигурност и приложения на публичния ключ. 8.1 Автентикация и контрол на достъпа. 8.2 SSL - протокол от network слоя, използван да защити преноса на данни в TCP/IP базирани мрежи. Какво е SessionKey? Кой и кога го генерира? Как се използва? - SSL 2.0 - предоставя кодиране на връзката между сървера и клиента. - SSL 3.0 - предоставя кодиране на връзката между сървера и клиента, като предоставя допълнително и автентикация на клиента. 9. Смарт карти. 9.1 Въведение. Какво е това смарт карта и има ли почва у нас ? - Микрокомпютър (микропроцесор) с памет, който генерира и съхранява кодиращи ключове и сертификати. - Различен механизъм и интерфейс на работа - SmartReader - различни видове, с - KeyPad, FingerPrint и т.н. - Криптографксите функции използваши частния ключ се изпълняват на самата смарт карта 10. Приложение на смарт картите в PKI. 10.1 Какво ни предоставят ? - смарт картите са *джоб* за сертификати - надежден носител на данни - като частен ключ и др. - смарт картите са като джобен компютър, можем да подписваме с тях *самостоятелно*, лесно и бързо - смарт картите ни предоставят - мобилност - сигурност - прозрачност - като с лекота извършваме подписването, без да се замисляме къде се намира частния ключ и т.н. 11. Смарт картата - цифрова самоличност. 11.1 Какжо е цифрова самоличност ? - цифровата самоличност вклюва - асиметрична двойка ключове - X.509 базиран сертификат Подписване на емайл. MIME и S-MIME Интегриране на PKI със Outlook и други продукти. Web security 12. Детайлен преглед на SSL (Secure Sockets Layer) протокола. 12.1 Какво ни предоставя SSL ? - кодиране на сесии - автентикация на сървери - възможност за автентикация на клиенти - автетикация на съобщенията -- SSL е проткола е проектиран и имплементиран от Netscape Communications. Той е предназначен да работи на ниво сокет и да защитава протоколите от по високите нива като телнет, фтп и хттп. -- Голяма част от функционалността и възможностите заложени в ССЛ са част от сравнително скоро дефинирания и въведен протокол IPv6. -- SSL-Record Layer протоколът работи върху TCP или други надеждни транспортни протоколи. -- Осъществяването на сесия онтнема между 5 и 8 съобщения. SSL разчита на съществуващ кодиращ механизъм за автентикацията на сървера. -- SSL не поддържа подмяна на ключовете след като веднъз вече е установена сесия. 12. 2 SSL протколи. SSL protocol message - съобщение базирано на SSL протокол спецификацията 12.2.1 SSL Record Protocol - Всички SSL protocol messages вариват във до 32,767 байта в брой записи. Всяко съобщение има хедър част 2 или 3 байта. Хедъра включва сигурна 'escape function', флаг, който указва наличието на padding (подравнявания), и дължината на съобщението (и вероятно на padding). Когато хеадъра е 2 байта няма padding, а при 3 съществува. 1 2 3 4 5 6 7 8 +----------------+-----------------+----------------+ |# S Length | Length | Padding length | +----------------+-----------------+----------------+ # е броят на байтовете в хедъра 0 индикира 3 byte header, max length 32,767 bytes. 1 индикира a 2 byte header, max length 16,383 bytes S индикира наличието на security escape функция, въпреки, че до момента в2.0 няма имплеменирани такива. 12.2.2 SSL record header - SSL record header не съдържа информация за версията, въпреки че версията може да се вземе по време на handshak-а. - record header е разделен на 3 компонента : -- MAC-DATA -- Actual-data -- Padding-data - MAC е Message Authentication Code - Actual-data, актуалните данни които се изпращат - Padding-data е подравняващите данни 12.2.2.1 Какво е MAC-DATA ? - MAC-DATA представлява hash от ключа, данните, paddin и sequence number. - Хеш се избира на базата на съществуващ cipher. - Използваният ключ е този на изпращача или още наречен пишещ ключ ((sender)-write-key), който дефакто съвпада със ключа за четене на получателя ((receiver)-read-key) - Ако не е специфициран cipher , не съществуват mac данни или padding данни. 12.2.2.2 Какво е Padding ? За какво се използва ? - Padding се използва за да осигури/подравни данните на множество блокове с еднаква големина, когато се използва блок chiper. - Padding данните винаги се игнорира след като MAC-ът бъде пресметнат. 12.2.2.3 Какво предствляват Sequence numbers ? За какво се използват при SSL ? - Sequence числото е 32 битово цяло число или integer и се увеличава със всяко изпратено съобщение. - Sequence числата след като се "превъртят" (overflow) се нулират, т.е. следващото число след 0xFFFFFFFF е 0x00000000. - Всяка от страните си има собственно sequence число - Всякакви грешки от сорта на отказана автентикация, кодиране и т.н генерират входно/изходна грешка и се затваря socket връзката. 12.2.3 SSL Handshake Protocol - Handshake въсниква когато машината се опитва да осъществи SSL връзка. - Съществуват 3 базови типа на хандшейкинг : -- Първият е когато не съществува сесия или "recently" . Recently не е точно специфициран, но се предполага, че трае под 100 секунди (SSL, C.8). -- Вторият тип е когато все още съществуват сесийните идентификатори -- Третия тип е когато се изисква автентикация на клиента 12.2.3.1 Как се започва и установява SSL конекция? * Всички съобщения и ключове са описани в следващата точка. - При първоначалната инициализация на връзката, когато клиента иска да установи сигурна конекция, той първи изпраща CLIENT-HELLO съобщение, включващо challenge, заедно със информация за криптографксите алгоритми, които поддържа или които ще използва. Сърверът отговаря с SERVER-HELLO съобщение, което представлява идентификатор на конекцията, неговия сертификат и информация относно какви криптографски алгоритми поддържа. Клиента е отговорен за окончателния избор на криптиращи алгоритми, които ще се използват със сървера. 12.2.3.1.1 При първи тип инициализация - Recently - Клиена верифицира публичния ключ на сървера и отговаря със CLIENT-MASTER-KEY съобщение, което е случайно генериран master key, кодиран или чатично кодиран със публичния ключ на сървера. - Клиента изпраща CLIENT-FINISHED съобщение, което включва идентификатор на конекцията, кодиран със client-write-key - Сървърът отговаря с SERVER-VERIFY съобщение, което служи да си провери самоличността при клиента. Самото съобщение представлява кодиран challenge (текст) със сървърският ключ за писане(server write key). Забележка :От друга страна сървърът получава своя ключ за писане от клиента, като клиента му го кодира с неговия публичен ключ (което е изпратен още в самото начало, чрез CLIENT-MASTER-KEY съобщение). Реално сървърът получава подходящия частен ключ със които може да декодира CLIENT- MASTER-KEY съобщение, от където вече се взема реално server-write-key. 12.2.3.1.2 При втори тип инициализация - Когато идентификатор на сесия бъде получен от клиента, протича инициализация със сравнително малки изменения спрямо Recently. Разликите има в CLIENT-HELLO съобщението, което при този тип включва и session-id. - Друга разлика е при SERVER-HELLO съобщението, което вече включва и поле session_id_hit, който се установява ако съществува session-id. - Клиента от своя страна изпраща в кодиран вид идентификатора на конекцията с CLIENT-FINISH съобщението. - Сървърът отговаря с SERVER-VERIFY and a SERVER-FINISH съобщения, които са идентични със "No session identifier case.". Единствената разлика е че SERVER-FINISH съобщението съдържа session-id вместо new-session-id. 12.2.3.1.3 Трети тип инициализация - автентикация на клиента - Ако се използва автентикация на клиента, тогава на някой етап от инициализацията сърверът трябва да изпрати съобщение от типа на REQUEST-CERTIFICATE, което да съдържа chalлenge и каква автентикация се изисква. - Клиента отговаря с CLIENT-CERTIFICATE съобщение, което вклчва тип на сертификата, самият сертификат и друга допълнителна информация. - Сърверът изпраща SERVER-FINISH съобщение и инитициализацията приключва. Обобщено използваните съобщения при инициализация са следните: 1 В случай, че не съществува идентификатор на сесията client-hello C -> S: challenge, cipher_specs server-hello S -> C: connection-id,server_certificate,cipher_specs client-master-key C -> S: {master_key} server_public_key client-finish C -> S: {connection-id} client_write_key server-verify S -> C: {challenge} server_write_key server-finish S -> C: {new_session_id} server_write_key 2 В случай, че съществува идентификатор на сесията при клиента и при сървера client-hello C -> S: challenge, session_id, cipher_specs server-hello S -> C: connection-id, session_id_hit client-finish C -> S: {connection-id}client_write_key server-verify S -> C: {challenge}server_write_key server-finish S -> C: {session_id}server_write_key 3 В случай, че е използван сесииен идентификатор и се изисква автентикация на клиента client-hello C -> S: challenge, session_id, cipher_specs server-hello S -> C: connection-id, session_id_hit client-finish C -> S: {connection-id}client_write_key server-verify S -> C: {challenge}server_write_key request-certificate S -> C: {auth_type,challenge'}server_write_key client-certificate C -> S: {cert_type,client_cert, response_data}client_write_key server-finish S -> C: {session_id}server_write_key Забележка: При последния тип 3, в последната размяна на съобщения response_data е функция от тип auth_type. (тези типове и структури са взети от SSL спецификацията) При handshake процеса има дефинирани и няколко вида грешки: - NO-CIPHER-ERROR - настъпва, когато клиента и сървъра не могат да се разберат за cipher - NO-CERTIFICATE-ERROR - BAD-CERTIFICATE-ERROR - UNSUPPORTED_CERTIFICATE_TYPE. NO-CIPHER Всикчи грешки без първата могат да бъдат преудоляни, ако клиента е със невалиден сертификат (като пример). 12.3 Ключове, които се използват SSL с протокола. Съществуват няколко вида ключове, които се използват при инитициализацията. Това са : - server's public key - master key - client-read-key - client-write-key. По стандарт се използва термина server-write-key, като друго наименование на client-read-key и server-read-key е друго наименование на client-write-key. - Client-write-key и client-read-key се получават непосредствени от сигурен hash от master key, един симврол, challenge, и идентификация на връзката (connection-id). - При тези входни данни само master key се изпраща кодиран със публичния ключ на сървера. - Master key се преизползва по и през сесиите, докато read- & write- keys се генерират наново при всяка сесия. - За момента е прието да се използва MD5 хеш, макар и да не е задължителен по спецификация. - Съществуват две или повече множества, които се използват за генерирането на SSL ключовете, в заивсимост от това колко битов ключ ние е нужен. - формулата е следната: key-material-N = hash (master key, "N", challenge, connection-id) Ключовете се вземат като резултат от хешовете, защото по дезайн сигурните хеш алгоритми, при промяна дори само на 'N' в резулта ще се получат коренно различни хешове. 12.4. SSL Application Protocol Веднъж след като handshaking е завършен, се намесава SSL Application Protocol. От друга страна в SSL спецификацията не съществува ясно дефинирана стъпка, след която се приема, че осъществена SSL връзката. Кога е завършила инициализацията се разбира, когато се прекъсне TCP конекцията и ключовете трябва да бъдат пазени приблизително 100 секунди след това, но това никъде не е дефинирано експлицитно. 12.5 Други детайли SSL използва https за достъп до документи достъпни през HTTP по SSL. Https има одобрен и резервиран специален порт 443 от IANA. SSL поддържа RC2 & RC4 със 128 bits или 40 bits частен ключ, както и DES, 3 key 3DES и IDEA.