CC BY
53
УДK 681.323
К.А. ПОГРЕБНЯК, П. О. КРАВЧЕНКО
МОДЕЛЬ KОMБIНОВAНОÏ 1НФРАСТРУКТУРИ В1ДКРИТИХ КЛЮЧ1В
Пpoпoнyeтьcя мoдель кoмбiнoвaнoï iнфpacтpyктypи biARpmBx ключ1в (IBK), щo no-еднуе у co6í пеpевaги IBK на баз1 Х.509 та IBK на баз1 iденгифiкaтopiв. Ocoбливicтю poзpoб-ленoï кoмбiнoвaнoï IBK e нaявнicть вiдoкpемленoгo cеpвеpy пiдпиcy, який забезпечуе цiлicнicть, aвтентичнicть, дocтyпнicть та cвoeчacне шювлення бази дaниx iдентифiкaтopiв кopиcтyвaчiв дoменy та зaгaльнocиcтемниx пapaметpiв.
Вступ
Як гоказують дocлiдження, пoдaльший poзвитoк електpoннoгo дoкyментooбiгy мoжли-вий лише за yмoви cyггeвoгo cкopoчення витpaт на IBK [1]. На даний мoмент в Укpaïнi IBK фyнкцioнyють на нaцioнaльнoмy aбo pегioнaльнoмy piвнi та бaзyютьcя на викopиcтaннi cеpтифiкaтiв вiдпoвiднo дo cтaндapтy Х.509 [2]. Bикopиcтaння IBK на бaзi Х.509 у межax opгaнiзaцiй, мiнicтеpcтв та вiдoмcтв не дoзвoлить cкopoтити витpaти кopиcтyвaчiв, ocr^rr пoбyдoвa та poзгopтaння тaкoï iнфpacтpyктypи вимагае знaчниx фiнaнcoвиx зaтpaт. З iншoгo бoкy, викopиcтaння aльтеpнaтивнoï IBK на бaзi iдентифiкaтopiв дoзвoляe œoporara витpaти на cтвopення, впpoвaдження та кopиcтyвaння пocлyгaми, щo надае зазначена iнфpacтpyктy-pa [3]. Однак apxiтектypa IBK на бaзi iдентифiкaтopiв пoтpебye дoвipи дo yпoвнoвaженoгo на re^pa^i' ключiв (УГK), ocкiльки безпocеpедньo УГK генеpye та видае ocoбиcтий ключ кopиcтyвaчy. Bимoгa poзпoвcюдження та мoжливicть збеpiгaння ocoбиcтиx ключiв rnp^-тyвaчiв не дoзвoляe викopиcтoвyвaти IBK на бaзi iдентифiкaтopiв на pегioнaльнoмy та нацюнальшму piвняx.
У нayкoвoмy cпiвтoвapиcтвi з'явилacя iдея викopиcтaння кoмбiнoвaнoï IBK, тобто IBK на бaзi Х.509 впpoвaджyeтьcя на нaцioнaльнoмy та pегioнaльнoмy piвняx, a IBK на бaзi iдентифiкaтopiв - на piвнi opгaнiзaцiй, мiнicтеpcтв та вiдoмcтв [4].
На даний час запропоновано декшька моделей комбшованих 1ВК, що мають за мету спростити процес електронного документооб^у за рахунок скорочення кшькосп сертифь катiв користувачiв. Розглянемо основнi недолши запропонованих моделей комбiнованих 1ВК.
Girault [5] будуе схему, у якш вiдкритий ключ дiлиться на двi частки, одну з яких виробляе сервер, а iншу - користувач. У такому разi УГК не в змозi пiдмiнити вiдкритий ключ користувача. Але для того щоб довести справжнють вiдкритого ключа, вщправнику необхiдно виконати iнтерактивний протокол з нульовими знаннями з одержувачем. Зазна-чена схема передбачае, що вщправник та одержувач володдать однаковими загальносис-темними параметрами.
У схемi Gentry [6] таемний ключ роздшяеться на двi частини, одшею з них володiе сервер, шшою - користувач. Для розшифрування повiдомлення користувач повинен отри-мати другу компоненту таемного ключа вщ сервера по захищеному каналу зв'язку. Сервер сертифшуе iдентифiкатор та вщкритий ключ користувача. Таким чином, уш користувачi повиннi мати сертифiкати.
Al-Riyami та Paterson [7] запропонували схему, дуже схожу на схему Gentry, але у нш немае необхщносп сертифшувати вiдкритий ключ користувача. Користувач публшуе двi частки вiдкритого ключа, яю пов'язанi мiж собою. Але сервер генерацп ключiв може легко скомпрометувати користувача, замшюючи його вщкритий ключ, та при цьому ця замша не може бути шяким чином виявлена.
Chen у робот [8] пропонуе мехашзм перевiрки вщкритих ключiв засвiдчувальних центрiв, що видають особисп ключi. Вiн показуе, яким чином можна побудувати iерархiчну систему, у якш можна перевiрити увесь ланцюг сертифшаив. Але поза увагою залишаються питання отримання справжшх iдентифiкаторiв та загальносистемних параметрiв.
Callas [9] запропонував схему, у якш сервер генеруе вщкрий i таемний ключ кожного користувача. Щоб отримати вщкритий ключ користувача, необхщно здшснити неавтентиф-шований запит до сервера. Для отримання таемного ключа користувача необхщно здшснити автентифшований запит до сервера. Мехашзми доведення цшсносп та справжносп видкритого та таемного ключiв не уточнюються.
У схемi Voltage [3] користувачi володiють сертифшатом традицшно1 1ВК та ключем 1ВК на iдентифiкаторах. Сертифiкати використовуються для автентифшацп користувача та для накладання цифрового пщпису, ключi 1ВК на щентифшаторах — для направленого шифру-вання. Головною перевагою системи, на думку розробниюв, е вiдсутнiсть перевiрки сертиф-iкату одержувача перед вщправкою повiдомлення. Механiзми взаемодп користувачiв з рiзних доменiв та дп у разi компрометацп ключiв 1ВК на щентифшаторах не уточнюються.
Зазначимо, що у вшх цих системах не виршуеться проблема призначення та розповсюд-ження вiдкритих iдентифiкаторiв. Очевидно, що у шформацшнш системi, яка натчуе мшьйо-ни користувачiв, практично неможливо розробити политику призначення загальновщомих та вщкритих щентифшатс^в.
Цыь - розробка моделi комбшовано1 1ВК, що мае переваги 1ВК як на базi Х.509, так i на базi iдентифiкаторiв; розробка методу направленого шифрування, що дозволяе вирiшити проблемнi питання взаемодп користувачiв та узгодження загальносистемних параметрiв у такiй 1ВК.
Задач1: 1) розробка моделi комбшовано1 шфраструктури вiдкритих ключiв; 2) розробка протоколу узгодження загальносистемних параметрiв та взаемодп користувачiв.
Об'ект досл1дження - процеси криптографiчних перетворень у 1ВК при реатазаци узгодження загальносистемних параметрiв та направленого шифрування.
Предмет до^дження - модель комбшовано! 1ВК, метод направленого шифрування, що дозволяють налагодити взаемодда користувачiв з доменiв, якi застосовують рiзнi загальносистемнi параметри.
Попереднi дослщження показують, що створювати 1ВК на щентифшаторах мае сенс тiльки у рамках деяко! оргашзацп. Таким чином, будуть юнувати багато доменiв з рiзними системними параметрами та политиками безпеки. Серед проблемних питань, яю необхiдно вирiшити для побудови тако! системи, е питання взаемодп користувачiв рiзних доменiв та узгодження загальносистемних параметрiв цих доменiв.
1. Архггектура комбшованот 1ВК
Сутнiсть розроблено! комбшовано! iнфраструктури вiдкритих ключiв полягае у тому, що уся множина користувачiв подiляеться на групи (домени). На практищ групою можна вважати деякий вiдцiл, органiзацiю, мiнiстерство тощо. Усi користувачi певно! групи використовують 1ВК на базi iдентифiкаторiв. Таким чином, структура групи щонайменше складаеться з УГК та користувачiв. Зазначимо, що УГК кожно! групи визначае загальносистемш параметри, полiтику безпеки та щентифшатори користувачiв, якi мають бути цшсними, автентичними та доступними у межах групи. 1дентифГкатори користувачiв можуть бути представленi у виглядi бази даних.
Можливють перевiрки користувачем будь-яко! групи цшсносп та автентичностi бази даних iдентифiкаторiв, загальносистемних параметрiв та полiтики безпеки довшьно фшсовано! групи досягаеться шляхом використання 1ВК на базi X.509. Зазначимо, що у роботi архггектура 1ВК на базГ X.509 не визначаеться у повному обсязг Вважаеться, що використовуються усГ необхщш сервюи, якг надае традицшна 1ВК (OCSP, TSP, реестрацгя користувачГв тощо).
Особливютю розроблено! комбшовано! 1ВК е наявнють серверу пгдпису, який е елементом групи та забезпечуе цшснють, автентичнють, доступнють та своечасне поновлення бази даних щентифшаторГв користувачГв групи шляхом накладання електронного цифрового пгдпи-су (ЕЦП). Сервер пгдпису використовуе пару ключГв, що визначена 1ВК на базГ X.509, тобто сервер шдпису мае сертифГкат вщкритого ключа. Цшснють та автентичнють загальносистемних параметрГв домену Г полпики безпеки досягаеться за рахунок додання !х до розши-рень сертифшату вщкритого ключа серверу пщпису. Таким чином, будь-який користувач може перевГрити цшснють та справжнють загальносистемних параметрГв та полпики безпеки шляхом перевГрки ланцюжка сертифшаив. Зауважимо, що користувачГ групи не е суб'ектами 1ВК на базГ X.509, але програмне забезпечення, яке вони використовують, пщтримуе необхщш алгоритми перевГрки ЕЦП.
Схематично модель комбшовано! 1ВК зображена на рис. 1. На схемГ у якосп УГК виступае сервер клктав.
Рис. 1. Архггектура комбшовано! шфраструктури вщкритих ключГв Розглянемо мехашзм направленого шифрування (НШ) У випадку належносп користу-вачГв одному домену схема направленого шифрування вщбуваеться тшьки у межах 1ВК на базГ щентифшаторГв, наприклад з використанням схеми Boneh-Franklin [10]. Пюля форму-вання зашифрованого повщомлення користувач вщправляе його шшому користувачу через поштовий сервер. Одержувач повщомлення отримуе особистий ключ з серверу ключГв або, у разГ наявносп ключа, одразу розшифровуе повщомлення. У такому випадку поштовий сервер визначае вщправника повщомлення для одержувача.
Якщо користувачi належать рiзним доменам, то вщправник направлено зашифровуе повiдомлення та пщписуе його, використовуючи алгоритми НШ, що визначенi у зовнiшнiй 1ВК на iдентифiкаторах, та ЕЦП, що визначеш у внутрiшнiй 1ВК на щентифшаторах вiдповiдно. Далi сервер пщпису отримуе пiдписане та зашифроване повщомлення, перевiряe ЕЦП, тобто переконуеться, що зашифроване повщомлення цшсне та дшсно належить користувачу групи. У разi усшшно! перевiрки сервер пiдпису видаляе ЕЦП користувача, пщписуе тшьки зашифроване повщомлення та вщправляе його одержувачу. Зазначимо, що сервер пщпису не спроможний розшифрувати повiдомлення вiдправника. Наступним кро-ком поштовий сервер у груш одержувача самостшно або за допомогою серверу пiдпису перевiряе ЕЦП та у разi успiху вщправляе одержувачу. Одержувач повщомлення отримуе особистий ключ з серверу ключiв, або у разi наявносп ключа одразу розшифровуе повiдом-лення.
Слiд вiдзначити, що схема НШ е досить повшьною для великих обсяпв даних, тому доцшьно використовувати алгоритм симетричного шифрування. Наприклад, вiдправник гене-руе ключ та зашифровуе повщомлення вщповщно до ГОСТ 28147[11], а наступним кроком направлено зашифровуе згенерований ключ з використанням схеми БопеЬ-РгапкНп [10].
2. Протоколи взаемодн користувачiв комбшованоТ 1ВК
Розглянемо формалiзовану модель комбшовано! iнфраструктури 1ВК. Нехай задана множина домешв О = (О1 |1 = 1..т}, де т> 0 - кшьюсть доменiв. Вважатимемо, що домен О I складаеться з серверу генерацп ключiв БКО , серверу пщпиав 8'Г)8 та множини користувачiв И1 = (иу 1= 1..п;}, тобто О1 = (БКО, ,И;}.
Позначимо центр сертифшацп ключiв (ЦСК) у 1ВК на базi Х.509 як БРК1.
Визначимо протокол Е = (I, Я, и, V} взаемодп користувачiв у комбiнованiй шфраструк-турi ключiв, як протокол, що складаеться з чотирьох етатв:
- Етап шщашзаци I.
- Етап генерацп ключiв користувачiв Я .
- Етап направленого шифрування И .
- Етап розшифрування V .
Розглянемо етап iнiцiалiзацil, що складаеться з встановлення системних параметрiв Брк1 та з встановлення системних параметрiв доменiв О;.
Етап встановлення системних параметрiв . Обираеться просте число Ч, група О та генератор групи Р порядку Ч. Центр сертифшацп ключiв генеруе майстер-ключ d е [1,ч -1] та обчислюе вiдкритий ключ 0 = dP . Позначимо множину загальносистемних параметрiв як Б = (ч, О, Р} . Зазначимо, що вiдритий ключ 0 та множина загальносистемних пара-метрiв Б визначенi в сертифшат вiдкритого ключа .
Етап встановлення системних параметрiв О;. генеруе особистий ключ dDS е [1,Ч -1] та обчислюе вщкритий ключ = d1DSP . Далi вибираеться просте число Ч;, двi групи О11,О21 порядку та бiлiнiйне вiдображення Вейля або Тейта е{ : О/ х О/ ^ 02' та генератор групи р; е О11. БКО генеруе майстер-ключ d1KG е та обчислюе вщкритий ключ 0КО = dKGPl. Далi обираються криптографiчнi геш-функцп Н1 :(0,1}* ^ О1 та Н2 : О'2 ^ (0,1}' для деякого 1. Таким чином, dDS,QDS - Це пара ключiв традицшно! 1ВК, а dKG, 0КО - пара ключiв 1ВК на базi iдентифiкаторiв. Системни-ми параметрами домену О; будуть Б1 = (д1,О1,О12,е1,Р1,Н1,Н12}. Вiдритий ключ та множина загальносистемних параметрiв Б1 визначеш в сертифшат вiдкритого ключа . Позначимо базу iдентифiкаторiв користувачiв домену 01 як ББ1 = (ID1j | j = 1..п1} .
База даних ББ1 пiдписуеться на ключi dDS .
Етап генерацп ключiв користувачiв визначаеться так:
Кожному користувачу Иу домену О1 вщповщае iдентифiкатор е {0,1} . Будь-якому
щентифшатору е {0,1} однозначно вщповщае вiдкритий ключ Qij = H11(IDij) е 011 та
таемний ключ dlj = d1KGQij, що формуеться по запиту користувача до . Процес встановлення ключових даних мае такий вигляд (рис. 2).
Рис. 2. Схема розподшення ключових даних
Наступним кроком визначимо протоколи направленого шифрування та розшифрування у межах рiзних доменiв (рис. 3) або одного i того ж домену (рис. 4). Зафшсуемо домени О; та Ог. Оберемо двох користувачiв Ulj е О; та иГ8 е Ог i розглянемо два випадки 1 = г (один домен) та 1 Ф г ^зш домени).
Визначимо етап направленого шифрування.
У випадку 1 ф г протокол направленого шифрування користувача Иу на користувача иг8 описуеться так:
1. Користувач Иу звертаеться до веб-серверу домену Ог та отримуе сертифiкат вщкритого ключа серверу пiдпису SDs та базу DBг . Наступним кроком користувач Иу перевiряе справжнiсть сертифшату, перевiряючи пiдпис SpкI за допомогою вщкритого ключа Q, та отримуе з нього загальносистемнi параметри Dг. Далi користувач Иу перевiряе цiлiснiсть бази даних шляхом перевiрки цифрового пiдпису на вщкритому ключi QDS та отримуе вщкритий iдентифiкатор IDгs користувача иг8 .
2. Користувач Иу направлено зашифровуе повщомлення М, використовуючи вiдкритий ключ Qгs та загальносистемнi параметри Dг, а по^м пiдписуе його на своему особистому ключi dlj. У результат отримуеться зашифроване та пiдписане повщомлення Sdlj (EQгs (М)), яке вш надсилае на сервер цифрового пщпису S1DS .
3. Сервер SDS перевiряе пiдпис користувача Ulj та у разi успiху пщписуе зашифроване повiдомлення EQгs (М) на особистому ключi dl. Отримане повщомлення Sdl (EQгs (М)) надсилаеться на поштовий сервер домену О г.
Аналогiчним чином визначимо етап розшифрування для випадку 1 ф г.
1. Поштовий сервер домену О г звертасться до веб-серверу домену О та отримуе сертифiкат серверу . Наступним кроком поштовий сервер домену О г перевiряe справжнiсть сертифiкату. Поштовий сервер домену О г перевiряe цiлiснiсть повщомлення шляхом перевiрки цифрового пiдпису на вщкритому ключi Q1DS . У разi успiху поштовий сервер домену О г надсилае повiдомлення користувачу иГ8.
2. Користувач иГ8, у разi вiдсутностi у нього особистого ключа, звертаеться до сервера ключiв 8Гко з запитом на отримання ключа.
3. Сервер ключiв генеруе та надсилае його користувачу иГ8 .
4. Користувач иГ8 розшифровуе повiдомлення М за допомогою ключа drs.
Рис. 3. Протокол взаемодп користувашв
У випадку i = г етап направленого шифрування користувача Иу на користувача и^ мае вигляд.
1. Користувач uij звертаеться до веб-серверу домену та отримуе сертифшат вiдкритого ключа серверу тдпису 818 та базу DBi . Наступним кроком користувач Иу перевiряе справжнiсть сертифiкату, перевiряючи пiдпис 8рЫ за допомогою вiдкритого ключа Q, та отримуе з нього загальносистемнi параметри Di. Далi користувач Uij перевiряе цiлiснiсть бази даних шляхом перевiрки цифрового тдпису на вщкритому ключi QDS та отримуе вщкритий iдентифiкатор IDis користувача и^ .
2. Користувач Иу направлено зашифровуе повiдомлення М, використовуючи вiдкритий ключ Qis та загальносистемш параметри Di, i надсилае користувачу и^ через поштовий сервер домену Оi.
Етап розшифрування для випадку i = г .
1. Користувач и^ , у разi вiдсутностi у нього особистого ключа, звертаеться до сервера ключiв 8Ко з запитом на отримання ключа.
2. Сервер ключiв генеруе для користувача и^ особистий ключ та надсилае його користувачу и^ .
3. Користувач и^ розшифровуе повщомлення М за допомогою ключа dis .
Рис. 4. Протокол взаемодп користувачiв
3. Виршення проблемних питань при розгортаннi та використаннi
комбшованоТ 1ВК
Щоб практично побудувати комбшовану 1ВК, яка дозволить знизити вартють послуг безпеки, необхщно виршити таю питання:
1. Розповсюдження загальносистемних параметр1в.
2. Розроблення полггики безпеки.
Розглянемо бшьш детально проблему розповсюдження загальносистемних параметр1в. По-перше, зауважимо, що криптограф1чш примггиви у 1ВК на баз1 Х.509 та на баз1 щентифша-тор1в не можуть використовувати однаков1 загальносистемш параметри. Криптограф1чш примггиви у 1ВК на баз1 щентиф1катор1в на поточний момент базуються на використанш елштичних кривих, що не задовшьняють МОУ-умов1, у той час як криптограф1чш примггиви у 1ВК на баз1 Х.509 використовують елштичш крив1, що задовшьняють зазначенш умовг Що стосуеться множини домешв, у яких функцюнуе 1ВК на баз1 щентиф1катор1в, то у загальному випадку слщ вважати, що для кожного домену задаш сво! загальносистемш параметри.
Таким чином, постае задача розповсюдження автентичних загальносистемних пара-метр1в з метою унеможливлення атак, що базуються на шдмш вщкритих параметр1в системи. Загальносистемш параметри 1ВК на баз1 Х.509 мютять в сертиф1кат1, тобто !х цшсшсть та справжнють гарантуеться ЦСК, що випустив сертифшат. Щодо загальносистемних параметр1в 1ВК на баз1 щентифшатор1в, то дослщниками було запропоновано де-кшька шдход1в [4]. Параметри можуть бути включеш до сертифшату вщкритого ключа як додатков1 поля, але у раз1 компрометацп особистого ключа, що вщповщае вщкритому ключу сертифшата, доведеться перевипускати сертифшат. Альтернативою цьому шдходу е використання сертифшату атрибупв для загальносистемних параметр1в. Але зважаючи на те, що в Украш не шдтримуються сертифшати атрибупв, у запропонованш комбшованш 1ВК використовуеться перший шдхщ.
Сервер генерацп ключ1в визначае загальносистемш параметри домену та передае !х серверу шдпису, який додае !х до свого запиту на сертифшат. Фактично, якщо сервер генерацп передав загальносистемш параметри серверу шдпису, то вш повинен звернутися ¡з запитом до ЦСК на перевипуск сертифшату. Але загальносистемш параметри не змшю-ються часто, тому це суттево не вплине на частоту перевипуску сертифшату. У випадку блокування або скасування сертифшату серверу шдпису загальносистемш параметри немае потреби змшювати, а необхщно лише додати до нового сертифшату вщкритого ключа серверу пщпису.
При розробщ полггики безпеки домену слщ виршити питання формування та розповсюдження щентифшатор1в користувач1в домену, а також порядок генерацп та видач1 особистих ключ1в користувач1в домену.
Вщкрит щентифшатори користувач1в повинш бути загальнодоступними та зручними для запам'ятовування строками. Пропонусться використовувати внутршш поштов1 адреси. Одна Í3 проблем, яку необхщно виршити, була описана у робот Callas [5]. I! сутнють поля-гае у тому, що у раз1 вщкритого доступу до ус1х щентиф1катор1в групи зловмисник може дослщити ii структуру або розсилати спам. Щоб запоб1гти цьому, пропонуеться використовувати вщкриту базу щентиф1катор1в (яка мютить щентифшатори публ1чних сшвробгтниюв оргашзацп) та закриту, до яко! мають доступ тшьки сшвробгтники.
Проблема захищеного отримання ключа вщ центру сертифшацп е одшею з найважливь ших для шфраструктури вщкритих ключ1в. Традицшна 1ВК виршуе це питання за допомо-гою отримання таемного ключа безпосередньо у примщеш центру сертифшацп. Такий пщхщ може бути прийнятним у раз1 довгострокових ключ1в, якщо ж ключ1 е короткостроко-вими, то отримання особистого ключа у примщеш сторонньо! оргашзацп призводить до значних накладних витрат. У схем1 компанп Voltage це питання виршуеться шляхом суворо! автентифшацп користувача на ключовому сервер! з використанням сертиф1кат1в. Таким чином, користувач повинен володгги довгостроковим ключем для отримання корот-кострокового, що суперечить ще! 1ВК на баз! щентиф!катор!в, згщно з якою користувач! не мають сертиф1кат1в. У запропонованш модел1 ключовий сервер розташовуеться у межах т1е! ж групи, що i користувач, тобто витрати часу на отримання особистого ключа будуть значно меншт Також пропонуеться використовувати нештерактивний метод. Необхщно зазначити, що на вщмшу вщ традицшно! 1ВК, користувач не повинен отримувати особистий ключ на кожний перюд, а тшьки тод1, коли у цьому е потреба.
Вщкрит1 ключ! змшюються автоматично за рахунок конкатенацп вщкритого щентифша-тора користувача та мггки часу (перюд змши яко! встановлюеться у полггищ безпеки вщповщно! групи).
До переваг розроблено! системи можна вщнести:
1. Масштабованють системи.
2. Використання щентиф1катор1в як вщкритих ключ1в для кшцевих користувач1в.
3. Можливють взаемодп користувач1в з р1зних домешв з р1зними загальносистемними параметрами.
4. Забезпечення конфщенцшносп, цшсносп та справжносп.
5. Можливють пщключення додаткових сервю1в (антив1рус, антиспам тощо).
6. Можливють контролю кореспонденцп з боку кер1вництва (якщо е потреба).
Основними недолшами розроблено! системи е:
1. Навантаження на сервер пщпису домену (слщ виконувати формування та перев1рку пщпису для кожного електронного листа).
2. Необхщнють перепщписувати базу щентиф1катор1в при реестрацп або видаленш нового користувача.
3. Розробка апаратних модул1в, що пщтримували б криптограф!чш примгтиви у 1ВК на баз! щентифкатс^в.
4. Висновки
Наукова новизна представлена новою моделлю комбшовано! 1ВК, яка поеднуе 1ВК на баз! X.509 та 1ВК на баз! щентиф!катор!в. Особливютю розроблено! модел1 комбшовано! 1ВК е наявнють вщокремленого серверу пщпису, який забезпечуе цшснють, автентичнють, доступнють та своечасне поновлення бази даних щентиф!катор!в користувач1в домену та загальносистемних параметр1в.
Також був розроблений метод направленого шифрування у комбшованш 1ВК для взаемодп користувач1в з р1зних домешв, що мають р1зш загальносистемш параметри та политики безпеки.
Практична значущгсть полягае у зменшеш вартосп ус1е! системи, що обумовлено скороченням кшькосп сертиф1кат1в завдяки застосуванню 1ВК на баз! щентиф!катор!в на р1вш кшцевих користувач1в. Практична значимють методу направленого шифрування полягае у можливосп взаемодп користувач1в домешв з р1зними загальносистемними параметрами. Сутнють методу полягае у формуванш пщписаних загальносистемних параметр1в, отриманш та перев1рщ параметр1в користувачем шшого домену, направленому шифруванш
повщомлення на отриманих параметрах та nepeBip^ цшсносп отриманого зашифрованого повiдомлення сервером тдпису.
Зазначимо, що основними недолшами системи е навантаження на сервер тдпису та необхщнють перепiдписування бази iдентифiкаторiв при реестрацп або видаленш нового користувача. Проте домен комбшовано! 1ВК налiчуе в середньому не бшьш нiж 500 користувачiв, тому загальне навантаження на сервер тдпису не е великим.
У подальшому плануеться визначити структури розширень сертифшалв, що вiдносяться до 1ВК на базi iдентифiкаторiв, а також формати тдписаних та зашифрованих даних.
Список лггератури: 1. Горбенко 1.Д., OmnpieHKoВ.В. Стан та проблемт питання створення та розвитку Нацюнально! 1ВК //Прикладна радюелектрошка. 2006. Том.5. №1. С. 41-51 2. ITU-T (International Telecommunications Union) Recommendation X.509: Information Technology - Open Systems Interconnection The Directory: Authentication Framework. 2000 3. Voltage Security. Identity-Based Encryption and PKI Making Security Work. 2005. 4. Geraint Price, Chris J. Mitchell: Interoperation Between a Conventional PKI and an ID-Based Infrastructure. EuroPKI 2005: 73-85. 5. GiraultM. Self-certified public keys. In D. W. Davies, editor, Advances in Cryptology—EUROCRYPT'91, volume 547 ofLecture Notes in Computer Science. 1992. Р. 490-497. Springer-Verlag. 6. Gentry C. Certificate-based encryption and the certificate revocation problem. In E. Biham, editor, Advances in Cryptology - EUROCRYPT 2003, volume 2656 of Lecture Notes in Computer Science, pages 272-293. Springer-Verlag, 2003. 7. Al-Riyami S., Paterson K. G. Certificateless Public Key Cryptography, extended abstract in Proceedings of ASIACRYPT '03, LNCS 2894, Springer-Verlag, 2003. 8. Chen L., Harrison K., Moss A., Soldera D., and Smart N.P. Certification of public keys within an identity based system. In A. H. Chan and V. D. Gligor, editors, Information Security, 5 th International Conference, ISC, volume 2433 ofLNCS, pages 322-333. Springer-Verlag, 2002. 9. Callas J. Identity-Based Encryption with Conventional Public-Key Infrastructure. In 4th Annual PKI R&D Workshop, number 7224 in Interagency Reports, pages 102-115. NIST, 2005. 10. Boneh D. and Franklin M. Identity-based encryption from the Weil pairing. Advances in Cryptology - CRYPTO 2001, volume 2139 of Lecture Notes in Computer Science. Springer-Verlag. 2001.Р. 213-229. 11. ГОСТ 28147-89 "Государственный стандарт Союза ССР. Система обработки информации. Защита криптографическая. Алгоритм криптографического преобразования".
Поступила в редколлегию 01.06.2011 Погребняк Костянтин Анатолшович, канд. техн. наук, доцент каф. Б1Т ХНУРЕ. Адреса: Украша, 61166, Харюв, пр. Летна, 14, е-mail: iitkostya@gmail.com
Кравченко Павло Олександрович, астранг каф. Б1Т ХНУРЕ. Адреса: Укршна, 61166, Харюв, пр. Ленша, 14, е-mail: kravchenkopo@gmail.com
