2. Вступ

За останні тридцять років вся людська цивілізація зазнала значних змін. Цей феномен переходу суспільства від постіндустріального до інформаційного розглядають багато різних галузей науки, кожна із своєї точки зору. Останні десятиріччя визначаються інформаційною революцією, що захопила усі галузі науки, техніки, відпочинку та майже всіх інших сфер людської діяльності. Таких вражаючих змін цивілізація досягла за допомогою створення машин для обробки інформації.

Перші обчислювальні машини були створені наприкінці сорокових років двадцятого сторіччя. Вже в п'ятдесяті роки обчислювальні машини перемістилися з лабораторій вчених до дослідних інститутів: з об'єкта досліджень вони перетворились на робочий інструмент. В шістдесяті роки обчислювальні машини використовуються для планування, обліку та інших розрахунків в державних і комерційних установах. Подальший розвиток комп'ютерів призвів до зростання обчислювальних потужностей, мініатюризації техніки, здешевлення її та, як наслідок, глобального розповсюдження.

Справжню революцію в розвитку технологій обробки інформації зробили комп'ютерні мережі. Ідея об'єднання обчислювальних машин створила умови для реалізації цілої низки сучасних інформаційних технологій: розподілене зберігання інформації, розподілена обробка даних, створення надпотужних розподілених мереж з тисяч комп'ютерів. На сьогодні телекомунікації стрімко розвиваються, в першу чергу також в напрямку зменшення розмірів пристроїв, їх здешевлення та їх розповсюдження (так, в останні десть років революційний стрибок створили мобільні комунікації: це дозволяє людині залишатись на зв'язку з телекомунікаційними мережами навіть за межами домівки або офісу).

Усі ці досягнення створюють можливості до більш ефективного використання часу: якщо минулого сторіччя нормою вважалася доставка листів за кілька днів або навіть тижнів, то сьогоденні потреби у комунікаціях вимагають передачу інформації за хвилини або, навіть, секунди. Змінився темп життя кожної людини, а, отже, і цивілізації в цілому. Як написав наприкінці минулого сторіччя Біл Гейтс, лідер провідної компанії в області виробництва програмного забезпечення Microsoft, у своїй книзі «Бізнес із швидкістю думки» [1] - «Якщо ви не знайдете спосіб використовувати Інтернет в своїй справі, то через десть років ви позбудетесь свого бізнесу».

Зрозуміло, що такий стан речей не може не вплинути і на найдавнішу з комерційних галузей - торгівлю. По-перше високі вимоги до часу вимагають укладати угоди за дуже короткий термін. Комунікаційні засоби розширюють ринки збуту для продавців, збільшують пропозицію для покупців та прискорюють обіг коштів. По-друге в інформаційному суспільстві виник новий вид товару - інформація. Сучасні технології дозволяють перетворити в нематеріальну, суто інформаційну, форму: книжку, музикальний твір, тощо. Оскільки така інформація не може існувати без комп'ютера, продаж її можна здійснити також лише за допомогою комп'ютерів.

Наявність дієздатної моделі системи дозволить простіше відпрацьовувати на ній ідейні, технічні та технологічні рішення. Цю роботу орієнтовано на тих, хто вимагає дослідження сучасних технологій в галузі «електронної торгівлі». В роботі розглянуто різні типи систем електронної комерції, методи їх проектування та побудови. Запропоновано проект захищеної системи електронної комерції, яка є достатньо легкою для масштабування, навіть до рівня державної системи. Детально розглянуто побудову найважливіших з точки зору безпеки модулів системи. Збудовано діючу модель системи, яка дозволяє відпрацювати технологію побудови системи електронної комерції.

2.2 Передісторія

електронна комерція криптографія мережа інтернет

Із розвитком та глобальним розповсюдженням комп'ютерних мереж виникло так зване «електронне середовище» для спілкування людей. За часів, коли комп'ютерами користувались лише вчені, існувала потреба лише в обміні спеціальною інформацією. Пізніше комп'ютери з'явились у галузях освіти, бізнесу, інших. Сьогодні вживання комп'ютерів набули такого ж широкого масштабу, як, наприклад, телебачення або телефонний зв'язок. Комп'ютерні мережі стали одним із повсякденно використовуваних середовищ для спілкування мільйонів людей.

Людина завжди намагається створити собі комфортні умови у будь-якому середовищі. Так виник феномен електронної комерції: по-перше це дозволяє швидше укладати угоди, по-друге відкриває нові ринки для покупців та продавців, по-третє дозволяє продавати та покупати інформацію без власне матеріальних носіїв, зо містять цю інформацію. Вже на початку дев'яностих років, коли у Сполучених Штатах - країні батьківщині глобальної комп'ютерної мережі Інтернет - почали з'являтись перші електронні магазини.

Треба підкреслити, що електронні засоби не змінюють ані сутності комерційної угоди, ані її основних атрибутів; вони лише додають нових можливостей. Ці можливості можна використовувати як за сталими правилами, так і всупереч їм: тобто електронне середовище відкриває як нові можливості для торгівлі, так і нові можливості для різних зловживань. Історія розвитку засобів електронної комерції фактично є історією пізнання цієї простої істини: із зростанням потужності обчислювальних засобів зростали можливості зловмисників, що в свою чергу вимагало побудови систем захисту від зловживань. Виходом з цієї ситуації є побудова системи електронної комерції із інтегрованою підсистемою захисту - тобто політика безпеки має бути однією з основних складових частин системи починаючи ще з етапу проектування.

2.3 Актуальність теми

На сьогодні на Заході існує кілька систем підтримки електронної комерції (див. наприклад [2]) що частіше всього є транснаціональними корпораціями. Деякі з західних країн мають державні системи з підтримки електронної комерції. В Україні сьогодні відсутня аналогічна державна система. Кілька крупних комерційних організацій створюють власні системи - але таке «задоволення» далеко не кожному по кишені.

Також гостро стоїть проблема аутентифікації суб'єктів комерційних відносин. На сьогодні не існує єдиного стандарту на спосіб побудови системи електронної комерції, часто про проектуванні таких систем авторами закладається заслаба система безпеки, часто через недостатньо надійну аутентифікацію сторін. Відсутність систем сертифікації ключів - а це є загальновизнаним надійним методом аутентифікації - відкриває простір для численних зловживань (наприклад, відкриття фіктивних електронних магазинів, що «продають повітря»). У цивілізованому світі існує кілька систем розповсюдження сертифікатів відкритих ключів засобами електронних криптосистем, наприклад VeriSign [3] - але використання таких систем є не дешевим і практично не доступно для організацій України. Очевидно, що виникла потреба створити в Україні аналогічну систему.

Умови, що склалися в даний момент в країні, а також державні інтереси в підтримці розвитку малого та середнього бізнесу, вимагають створення саме державної програми по підтримці та регулюванні електронної комерції - системи, де гарантом довіри виступатиме держава в особі якоїсь установи.

2.4 Мета роботи

В ході роботи виконано дієздатну демонстраційну модель системи електронної комерції. Для спрощення в моделі було реалізовано лише один модуль для клієнта системи «покупця» та один модуль для клієнта системи «продавця». Також необхідним є модуль генерації ключів, який буде реалізовано для роботи під керуванням ОС MS-DOS, що дозволяє оминути проблему безпеки таємних ключів в багатозадачних ОС в пам'яті комп'ютера під час генерації ключів (докладніше див. розділ 4.5.2, Модуль із створення сертифікату відкритого підпису).

Метою роботи є підбір алгоритмів для побудови систем електронної комерції масштабу держави, перевірка можливості суміщення обраних технологій та відпрацювання технологічних рішень. Зрозуміло, що необхідною частиною системи має бути набір організаційних вимог до експлуатації системи, які мають забезпечити виконання обраної політики безпеки.

3. Постановка завдання

3.1 Аналіз проблеми

Основне призначення електронної комерції - надати можливість покупцям вибирати, оформляти замовлення та здійснювати покупки товарів та отримання послуг в будь-який час за допомогою мереж загального користування, в тому числі мережі Інтернет. В попередньому розділі було показано, що вже існує нагальна потреба в створенні системи підтримки електронної комерції. Потрібно створити велику розгалужену систему, яка дозволила б створити електронний магазин навіть небагатій організації та дозволить стати покупцем будь-кому, хто має доступ до мережі Інтернет.

На шляху реалізації такої системи постає багато проблем.

Перша проблема - це мільйони користувачів. Отже, систему потрібно реалізувати за допомогою ієрархічної архітектури: це дозволить реалізувати кілька центрів по підтримці системи з кількістю клієнтів в десятки-сотні тисяч - це реальні показники для сучасних обчислювальних систем середнього рівня. Також це дозволить легко масштабувати систему - адже можна буде не лише додавати кінцевих користувачів, а й нові вузли будь-якого рівня для підтримки системи. Також це дозволить використовувати деревоподібну модель розповсюдження сертифікатів - що є найнадійнішою (докладніше про механізми розповсюдження сертифікатів див. 4.4.3, Робота з сертифікатами відкритих ключів).

Друга проблема - проста інтеграція нової системи в існуючу мережу Інтернет та пов'язаних з цим сервісів. Так, нова система має доповнювати систему WWW, за допомогою якої зараз створено мільйони сайтів. Таким чином продавці мають можливість використовувати усі створені дотепер засоби візуального представленні інформації в мережі Інтернет (в рамках протоколу WWW), а власне механізми електронної комерції будуть лише доповненням. В свою чергу це дозволить легко інтегрувати нову систему підтримки електронної комерції у вже існуючі web- проекти, в тому числі в інші системи електронної комерції.

Третя проблема - це джерело довіри в системі. Деревоподібна структура системи дозволить використовувати ієрархічну модель розповсюдження довіри, але потрібно обрати корінь такої ієрархії. Оскільки система буде розбудовуватися в масштабі держави, то логічно функції джерела довіри покласти на якусь державну установу.

3.1.1 Огляд існуючих засобів

На сьогодні існує та функціонує багато систем електронної комерції в усьому світі. Нажаль в нашій країні немає системи державного рівня, яка дозволила б надавати засоби впровадження електронної комерції всім зацікавленим особам та організаціям. В Україні існує кілька систем електронної комерції, але багато з них не задовольняють суворим вимогам до великої та безпечної у використанні системи (див. також розділ 3.1.2, Класифікація існуючих засобів).

Переважна більшість систем електронної комерції, а тим більше найбільш цікаві для нас великі західні системи, що забезпечують достатній рівень захищеності користувачів, є закритими системами. Це по-перше наражає користувачів на ризик атаки з боку власника або оператора такої системи (з використанням «люків» або інших засобів зменшення стійкості захисту користувача в системі, які відомі тільки власникам або розробникам системи). По-друге це фактично унеможливлює створення аналогічної системи з використанням чужого досвіду побудови. Ми можемо лише здогадуватись про технологію побудови такої системи з зовнішніх ознак: наприклад система Amazon [2] використовує транспортний протокол https для передачі закритої інформації та використовує платіжні системи Visa [4] та MasterCard [5].

Аби створити систему, в якій напевно не буде різних «задніх дверей» та будь-яких інших способів обходу засобів безпеки, треба самому повністю спроектувати та відтворити цю систему. Також треба увесь час, починаючи від етапу проектування, враховувати інтеграцію підсистеми захисту [6].

Крім технічних аспектів існують також правові, докладний розгляд яких виходить за межі цієї роботи. Однак треба наголосити, що відсутність законів України, які регулювали б проблеми, що пов'язані з електронними документами, відповідальністю за шахрайства в цій області діяльності, значно ускладнюють ситуацію з розвитком новітніх технологій, в тому числі електронної комерції. Ситуація також погіршується незадовільним станом телекомунікаційного зв'язку та відсутністю грошей у населення для оплати комп'ютерів та послуг зв'язку.

Також на початкові кроки у розвитку електронної комерції впливає відсутність правового поля в Україні в цій галузі. До речі, в Росії вже прийнято закон про Електронну торгівлю [7]. В першу чергу, відсутність законодавства про електронний цифровий підпис не дає можливості розвитку структур, які надавали б послуги сертифікації ключів для виконання суворої аутентифікації торговця та покупців.

Для запобігання порушення грошового обігу усі операції купівлі-продажу в електронній комерції повинні виконуватись через банківські рахунки торговця-покупця.

Такій підхід до організації електронної комерції дасть змогу підвищити рівень захисту інформації і зменшити ризики, які пов'язані саме з електронною комерцією навіть на період до введення в дію нових Законів України, що будуть регламентувати цю діяльність.

3.1.2 Класифікація існуючих засобів

Серед існуючих систем електронної комерції можна виділити такі основні групи:

- замовлення товару через мережу Інтернет з оплатою «класичними» засобами,

- купівля товару через мережу Інтернет з оплатою за допомогою існуючих платіжних системи (платіжні картки, home banking, тощо),

- купівля товару через мережу Інтернет з оплатою за допомогою власних платіжних систем.

Перший метод фактично не реалізує систему електронної комерції в повному обсязі - адже така система має надавати можливість укласти та виконати угоду лише своїми засобами (тут вважаємо, що платіжна система входить як складова частина до системи електронної комерції).

Останній з перерахованих методів на дає такої гнучкості, яку надає система з використанням різних існуючих платіжних засобів. Але саме такі системи на сьогодні є найбільш розповсюдженими в світі, а також в Україні. Треба наголосити, що велику кількість таких систем було створено без задоволення суворих вимог до захищеності та безпеки - наприклад, багато систем використовують аутентифікацю з використанням пароля, що є цілком не припустимим у системі з ризиками фінансових втрат. Таким чином ці системи є потенційно небезпечними для участі в них, як з боку продавця, так і з боку покупця. Лише система, яку було спроектовано з урахуванням вимог на забезпечення безпеки та захищеності (див. розділ 4.4.4, Підсистема захисту) може забезпечити захист користувачів від втрат.

3.2 Огляд літератури

На сьогодні опубліковано дуже мало інформації з розглядуваного питання. Написано та видано багато книг з електронної комерції, що висвітлюють ідеоголгічні питання, заходи по веденню справ з використанням систем електронної комерції, побудову бізнес-планів, побудову інтерфейсів для продавця та покупця, питання дизайну Інтернет - магазинів і таке інше. Але, на противагу до цього розмаїття, немає практично жодної роботи, яка б розкривала технічний бік побудови систем електронної комерції. Існує кілька стандартів, в тому числі міжнародних стандартів (ISO, інші) та проектів таких стандартів, в тому числі [8]. Але, зрозуміло, неможливо використовувати лише стандарт під час розробки реальної системи: стандарт накладає деякі обмеження на процес розробки та функціональність системи. Для фактичної розробки системи потрібен проект. Спроби знайти подібну інформацію в мережі Інтернет майже нічого не дали, хоча в мережі зустрічаються аналогічні проекти на етапі розробки (наприклад [9]).

Фактично основним джерелом інформації під час підготовки проекту став проект постанови НБУ «Вимоги до організації електронної комерції в Україні» [10]. Так, в Проекті аналізуються ризики кожного з учасників системи. Ризики в електронній комерції складаються з двох частин: ризики при оформленні замовлення на товари та послуги і ризики при оплаті цих замовлень. Ризики при оформленні замовлень на товари та послуги можуть бути як з боку покупця (оформлення замовлення з попередньою оплатою в електронній крамниці, яка фактично не існує; шахрайське використання номера рахунку при оплаті за допомогою магнітної картки), так і з боку торговця (надання неправильної адреси або номера рахунку для доставки товару тощо). Розгляд ризиків, які виникають при оплаті товарів і відносяться до системних ризиків платіжних систем, виходить за межі цього документу.

Також не можна не назвати роботу [6], яка в основному висвітлює питання захищеності системи електронної комерції, але торкається також і питань побудови архітектури такої системи. Матеріал, що наведений в цій статті частково висвітлено в подальших розділах.

Існує також цілий ряд робіт, що присвячені окремим технічним аспектам проблеми побудови системи електронної комерції, наприклад робота [11], яка досліджує довірчі відносини між покупцем та продавцем.

Отже, на сьогодні фактично не існує опублікованих робіт, які б описували побудову архітектури та технологію розробки системи електронної комерції. Існують лише стандарти, яких замало для побудови системи, оскільки вони не висвітлюють технологію побудови. Також немає досліджень щодо вибору оптимальної архітектури.

3.3 Вимоги до системи

Система має надавати три основних інтерфейси:

· для користувача системи «покупця»,

· для користувача системи «продавця»,

· для оператора системи,

· для організації, що уповноважена видавати сертифікати відкритих ключів.

Зрозуміло, що кожен з цих інтерфейсів має реалізовувати свій набір функцій; кожен з учасників системи має свої привілеї та дозволи, які не суперечать обраній політиці безпеки.

Покупець та продавець є найбільш численними в системі - саме вони є кінцевими споживачами, саме для них проектується та будується ця весь програмно-апаратний комплекс. Система електронної комерції накладає певні обмеження на дії її користувачів, які диктує політика безпеки системи (наприклад заборонено розголошувати свій таємний ключ). Ці умови користування системою повинні бути оформлені у вигляді договору, який укладають користувач та оператор системи.

Оператором системи може бути будь-яка організація, вона займатиметься підтримкою діяльності системи. Ця організація повинна стежити за цілісністю ієрархії розповсюдження сертифікатів відкритих ключів, повинна підтримувати всі сервіси по роботі із сертифікатами (докладніше див. розділ 4.4.3, Робота з сертифікатами відкритих ключів). Також необхідно постійно дотримуватись вимог забезпечення безпеки системи та провадити заходи з дотримування політики безпеки всіма учасниками системи (див. розділ 4.4.4, Підсистема захисту).

Організація, що має право створювати сертифікати відкритих підписів користувачів в загальному випадку може не співпадати із організацією, що підтримую працездатність системи. Однак, безперечно, інформація про нові сертифікати має якнайшвидше (бажано - в реальному часі) поступати до системи підтримки ієрархії розповсюдження сертифікатів.

Система має забезпечувати захищеність кожного учасника:

- покупець має бути впевненим, що продавець є дійсно продавцем і в змозі виконати свою частину угоди - доставити товари, надати послуги абощо;

- продавець має бути впевненим в тому, що покупець є здатним на оплату наданих товарів або послуг.

Таку впевненість може надати сувора аутентифікація сторін - тоді продавець буде впевненим, що покупець платить із свого гаманці, я не з вкраденої кредитної картки, яку от-от заблокують. А покупець може бути впевненим в тому, що він має справу з магазином, що пройшов реєстрацію та отримав відповідні дозволи у держави або вповноважених органів.

Розширений перелік вимог до системи можна знайти в [10].

Система має реалізувати функціональність, що дозволить її використовувати за стандартним сценарієм процесу купівлі/продажу через Інтернет.

3.3.1 Стандартний сценарій купівлі з використанням мережі Інтернет

Покупець входить на сайт продавця. Покупець робить свій вибір та передає продавцю інформацію про нього. Покупець має бути впевненим, що продавець є тим, кого він з себе вдає та, відповідно, здатний виконати дії, про які він повідомляє на сайті (надати товари/послуги и т. ін.). Продавець має бути певним в тому, що покупець цей є тим, кого він з себе вдає, та, відповідно, згодний оплатити надані послуги. Після підтвердження продавцем можливості покупки, покупець виконує оплату угоди, використовуючи будь-який доступний для нього платіжний засіб - власне процес оплати виходить за рамки цієї роботи.

Система має реалізовувати політику безпеки, що базується на моделі взаємної недовіри. Це водночас і забезпечую безпеку кожного з учасників системи, і чітко розмежовує відповідальність за можливі втрати внаслідок порушення політики безпеки.

Клієнтську частину для покупця має бути реалізовано як модуль браузера (plug-in), в моделі реалізований лише модуль для Microsoft Internet Explorer. Клієнтську частину для продавця має бути реалізовано як модуль web- сервера, в моделі реалізований лише модуль для Microsoft Internet Information Server. Модулі покупця та продавця мають використовувати з'єднання, що вже було встановлене браузером під час перегляду web-сайту покупцем.

3.4 Постановка задачі

Розробити модель системи електронної комерції, що буде реалізовувати кожен з основних модулів хоча б під одну ОС / браузер / сервер і т. ін. Модель має задовольняти усім вимогам до системи, що наведені у попередньому розділі, в тому числі вимогам до захищеності всіх учасників системи. Ця система має базуватись на сучасних технологіях передачі інформації, телекомунікацій, та криптографічного захисту.

4. Реалізація системи

4.1 Функції системи

З огляду на наведене в попередніх розділах ми можемо сформулювати функції, які має реалізовувати система електронної комерції:

- підтримка деревоподібної системи розповсюдження сертифікатів відкритих ключів;

- генерація пар ключів для кожного користувача та оператора системи;

- засвідчення справжності відкритого ключа вповноваженою організацією за допомогою сертифікатів;

- сувора аутентифікація покупця та продавця під час укладання угоди;

- шифрування усього трафіка, яким обмінюються сторони під час укладання угоди з метою зберегти комерційну та банківську таємницю;

- під час укладання угоди кожне повідомлення з кожної сторони має підписуватись з метою забезпечення цілістності інформації, а отже чіткого розподілу відповідальності за зміст кожного повідомлення;

- використання зручного для кожної з сторін механізму оплати - наприклад платіжної картки, системи клієнт-банк, системи home banking, НСМЕП, навіть традиційного способу роботи з банком (за платіжними дорученнями, тощо).

Наведена вище функціональність гарантуватиме неможливість зловживань:

- фальшивий магазин

- провадження будь-яких дій від чужого імені

- підстановка магазином, покупцем або третіми особами іншої угоди, замість реально укладеної.

Реалізація власне платіжної системи виходить за рамки побудови системи електронної комерції - це є окрема велика задача. Система електронної комерції лише має надавати зручний для користувача інтерфейс для використання будь-якої платіжної системи (навіть традиційної «паперової» - автоматичне заповнення та друкування документів можна доручити програмі).

4.2 Алгоритми роботи системи

Для функціонування системи, кожен з її учасників має згенерувати пару ключів. На цю пару ключів уповноважений орган з сертифікації має видати сертифікат.

4.2.1 Алгоритм процесу купівлі

1. Клієнт: перегляд списку товарів на web- сайті продавця

2. Клієнт: вибір товарів / послуг за допомогою сервісів, що надає web-сайт продавця.

3. Клієнт: натискання кнопки «Придбати».

4. Web-сайт продавця генерує список товарів у вигляді таблиці у внутрішньому форматі нашої системи. Формат таблиці див. нижче.

5. Клієнт: клієнтський модуль, складова нашої системи, приймає форматну заявку на купівлю; відправляє сертифікат покупця.

6. Продавець: виконує аутентифікацію покупця. Відправляє йому свій сертифікат.

7. Клієнт: виконує аутентифікацію продавця. На базі взаємної суворої аутентифікації генерується сеансовий ключ, яким шифрується увесь трафік на подальших кроках.

8. Клієнт: відправляє продавцеві отриману на кроці 5 заявку на купівлю. Пакет даних підписується.

9. Продавець: перевірка вмісту заявки (перевірка коректності оформлення заявки). Перевірка наявності товарів по БД товарів, и т. ін. Перевірка підпису покупця.

10. Продавець: на цьому етапі можна виконати деякі сервісні операції, що пов'язані з процесом торгівлі, наприклад зарезервувати товар на складі.

11. Продавець: відсилає підтвердження: заявку прийнято, товар є в наявності (або відмова від угоди, якщо товару немає), заявку може бути виконано. Пакет даних підписується.

12. Клієнт: перевірка підпису продавця та свого підпису. Відмова від покупки у випадку невдачі.

13. Клієнт: відображення заявки, підтвердження покупки. Опціонально: вибір варіанту угоди (якщо продавець пропонує такі). Відправка торговцю підтвердження. Пакет даних підписується.

14. Начало торгової операції: запуск механізму по переказу грошей.

Підписування на кроках 8 - 12 гарантує, що ані покупець, ані продавець не змінили вміст угоди, на яку погодився покупець на кроці 13.

Також системою можна передбачити надавання покупцеві варіантів угоди: наприклад вибір більш зручного для нього платіжного засобу, вибір строків та способу доставки товару, тощо. Таку функціональність мають надавати модулі системи, що встановлюються у продавця та покупця. Власне вибір варіанту покупець здійснює на кроці 13, тобто інформація про вибір користувача передається по закритому каналу зв'язку (див. розділ 4.4.2, Підсистема симетричної криптографії).

4.2.2 Структурна схема системи

Основними блоками системи є:

1. генератор пари ключів для асиметричної криптопідсистеми

2. створення сертифікатів відкритих ключів

3. модуль системи захисту для продавця

4. модуль системи захисту для покупця

Ці блоки вимагають реалізації такої функціональності: багаторозрядна арифметика (1, 2, 3, 4), генерація великих простих чисел (1, 2), створення сертифікатів відкритого ключа (2), перевірка сертифікату відкритого ключа (що в свою чергу вимагає перевірки ЕЦП та контролю логічного ланцюга уповноважених установ, кроки 3, 4), симетрична криптосистема (3, 4), накладання та перевірка підпису (3, 4).

Розглянемо докладніше взаємодію компонентів системи.

4.2.3 Архітектура системи

Під час побудови архітектури системи електронної комерції ми повинні дотримуватись таких вимог:

n використання мережі Інтернет для діалогу покупця та продавця на етапі вибору товарів та формування замовлення;

n забезпечення суворої аутентифікації та закритого каналу зв'язку між покупцем та продавцем на етапі укладання угоди, при цьому повинні бути використані ті самі канали зв'язку, що і на першому етапі;

n після досягнення угоди проведення власне платежів засобами платіжних систем (які використовують свої захищені канали зв'язку).

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

Таким чином архітектура системи електронної комерції виглядає наступним чином:

Мал. 4.1. Архітектура системи електронної комерції.

• На Мал. 4.1 представлено модель системи. Тут суцільними лініями показані зв'язки, що використовуються безпосередньо під час укладання угоди (див. 4.2.1, Алгоритм процесу купівлі). Пунктирна лінія позначає зв'язок між сервером продавця, що обслуговую систему електронної комерції та web- сайтом продавця - такий зв'язок не є обов'язковим. Штрих-пунктирною лінією позначено шляхи розповсюдження сертифікатів в системі - коренем дерева є ЦСК 0.
• Хоча власне платіжні засоби не є компонентом системи електронної комерції, на діаграмі також відображені банки, за допомогою яких здійснюється переведення коштів. Подвійною лінією позначено зв'язок покупця та продавця із своїм банком, за допомогою якого ініціюється переказ грошей. Потрійною лінією показаний зв'язок банків - СЕП абощо. З даної діаграми легко бачити, що ані кошті, ані інформація про реквізити платежів не передається через Інтернет.
• 4.2.4 Архітектура механізму розповсюдження сертифікатів відкритих ключів
• Система електронної комерції вимагає суворої аутентифікації сторін, що укладають угоду. Сувора аутентифікація є одним із сервісів, що їх надають сучасні цифрові криптографічні засоби. Сутність аутентифікації полягає в доведенні того, що сторона є саме тим, кого вона з себе вдає. Сувора аутентифікація - це аутентифікація з використанням криптографічних засобів [12, 13].
• За допомогою механізму суворої аутентифікації можна пересвідчитись, що кожна з сторін є тим, за кого вона себе вдає. Система електронної комерції вимагає більшого: наявності довіри однієї сторони до іншої. Сторона А може довіряти безпосередньо стороні Б. Однак за умови створення великої системи такий механізм не є гнучким: адже кількість учасників може вимірюватися мільйонами.
• Для передачі довіри від однієї сторони системи до іншої використовується механізм сертифікатів відкритих ключів. Організація О, що вповноважена видавати сертифікати відкритих ключів (центр сертифікації ключів), проводить встановлену процедуру та видає сертифікат на відкритий ключ організації В. Сертифікат містить відкритий ключ В захищений від модифікації підписом О. Таким чином кожен учасник системи може впевнитись в тому, що підпис В не є модифіковано, що затверджує організація О. За умови, коли А довіряє О, він може сміливо довіряти і В: адже О довіряє В, що засвідчено сертифікатом.

Такий ланцюг сертифікатів відкритих ключів може бути як завгодно довгим: О видає сертифікат В, В видає сертифікат Д і так далі. Такий механізм дозволяє А довіряти безпосередньо лише О, а довіру, наприклад, до Д можна встановити за допомогою сертифіката відкритого ключа Д. Інколи такий механізм розповсюдження сертифікатів відкритих ключів називають розповсюдженням довіри.

• Велика система може мати ієрархічну, або деревоподібну структуру: існує одна єдина організація, якій кожен учасник системи довіряє безпосередньо. Центральна організація - ЦСК 0 - видає сертифікати ЦСК нижчого рівня, які в свою чергу видають сертифікати іншим ЦСК або безпосередньо клієнтам системи. Також можливий варіант, коли схема розповсюдження сертифікатів має мережену, або павутинну структуру - кілька основних ЦСК видають сертифікати на відкриті ключі один одного, фактично структура складається з кількох сплутаних дерев. Таку схему використовує, наприклад, система криптографічного захисту PGP [14].

Оскільки задачею передбачено побудова системи електронної комерції державного рівня, то ефективніше використовувати деревоподібну модель розповсюдження сертифікатів: державні установи мають саме ієрархічну структуру, що значно спростить впровадження системи електронної комерції.

• Мал. 4.2. Архітектура механізму розповсюдження сертифікатів в системі електронної комерції.

Потенціальну можливість використовувати більше двох рівнів ієрархії в механізмі розповсюдження довіри не доцільно використовувати в системі державного рівня в Україні. На сьогодні багато інстанцій та державних інституцій України використовують саме таку ієрархію: центральне управління та обласні відділення. Це дозволяє кожному з відділень працювати з відносно невеликою кількістю авторизованих на відповідну діяльність організацій, наприклад банків.

Технічно немає перешкод тому, щоб ввести ще один рівень ієрархії у дерево розповсюдження довіри, але це навряд доцільно в рамках системи підтримки електронної комерції в Україні.

• Підсистема розповсюдження сертифікатів має реалізовувати багато інших сервісних функцій. Наприклад, отримав розголосу таємний ключ користувача К - відповідний відкритий ключ вже не може забезпечувати криптографічного захисту. Сертифікат ключа К має бути оголошено скасованим. Таким чином ЦСК мають підтримувати списки скасованих сертифікатів. Також задля забезпечення захищеності системи кожна пара ключів повинна мати термін дії. Докладніше про механізми сертифікації див. роботу Онищенка Івана [15].
• 4.3 Технології, за допомогою яких збудовано систему

Система електронної комерції складається з багатьох модулів, серед яких можна виділити кілька підсистем. Розглянемо найбільші з них.

• Усі засоби захисту в системі, починаючи з шифрування трафіку та закінчуючи цифровими підписами та сертифікаційними механізмами розповсюдження довіри, базуються на криптографічних засобах та будуть повністю зкомпроментовані у випадку недостатньо надійних криптографічних механізмів. Саме тому значну увагу було приділено проектуванню та реалізації криптографічної підсистеми.
• 4.3.1 Підсистема асиметричної криптографії

Система асиметричної криптографії дозволяє реалізувати такі сервіси:

• - сувора аутентифікація сторін,
• - накладання та перевірка електронного цифрового підпису (ЕЦП),
• - видача та перевірка сертифікатів відкритих ключів.
• В системі електронної комерції будуть використовуватись стандартні алгоритми RSA [16] з довжиною ключа 1024 біт.
• Ключі в схемі RSA генеруються наступним чином: знаходяться два великі прості числа p і q, для їх добутку N = pq значення функції Ейлера:

(N)=(p-1)(q-1).	(4.1)

• Вибирається випадкове число e, що не перевищує (N) і взаємно просте з ним. Обчислюється обернений до e елемент за модулем (N). Таким чином публічний ключ - (N, e), таємний ключ - (N, d). Зрозуміло, що вибір між d і e в якості таємного ключа досить умовний, тому в подальшому будемо вважати, що випадковим з певними властивостями обирається таємний ключ - число d, а відкритий ключ обчислюється. Параметри p і q використовуються лише для обчислення оберненого елемента в Z*_(N) і після генерації ключа знищуються.
• Процедура накладання цифрового підпису на повідомлення m полягає в обчисленні виразу

S = md mod N.	(4.2)

• Перевірка підпису полягає в порівнянні отриманого повідомлення m з виразом

Se mod N,	(4.3)

• що має дорівнювати

mde mod N = m.	(4.4)

• Дуже важливо реалізувати свою бібліотеку для асиметричної криптосистеми, оскільки потенційно будь-яка загальнодоступна бібліотека з криптографії може містити так звані «закладки», «задні двері», «люки» або інші механізми, що послаблюють захист. Однією з важливих задач при генерації пари ключів є генерація великих простих чисел. Також бібліотека по реалізації криптосистеми має включати в себе бібліотеку по роботі з довгими числами. Докладніше див. роботу [17] та [18].
• 4.3.2 Підсистема симетричної криптографії
• Оскільки сучасні системи симетричної криптографії значно швидші за системи асиметричної криптографії, то задля шифрування трафіка, яким обмінюються сторони під час укладання угоди, має сенс використовувати саме систему симетричної криптографії. Сеансовий ключ для симетричної криптосистеми створюється під час суворої аутентифікації сторін за стандартним протоколом ISO 11166 [19]. Докладніше про роботу симетричної криптосистеми див. роботу [18].
• 4.3.3 Робота з сертифікатами відкритих ключів

Вище розглянуто ефективність вибору ієрархічної системи розповсюдження сертифікатів, вказали на наявність трьох рівнів в ієрархії ЦСК: головний ЦСК 0, обласні ЦСК, уповноважені ЦСК на місцях - наприклад банки. Центри сертифікації нижчого рівня видають сертифікати на відкриті ключі клієнтів системи.

Обговоримо процедуру видачі сертифікату відкритого ключа. Політикою безпеки системи має бути обумовлене, що вповноважений орган повинен видавати сертифікат відкритого ключа лише за умови, що ключ надано організацією або особою, що буде цей ключ використовувати (або вповноваженою особою). Для цього мають бути розроблені певні організаційні вимоги.

Система може допускати кілька методів передачі відкритого ключа на процедуру видачі сертифіката. Наприклад:

• - передача в електронному вигляді за допомогою телекомунікаційних мереж в режимі on-line,
• - передача в електронному вигляді за допомогою телекомунікаційних мереж в режимі off-line,
• - передача в електронному вигляді на магнітному, оптичному або іншому носії - без передачі через мережі телекомунікацій,
• - навіть в паперовому вигляді - як роздрукований на папері дамп (див. Уживані терміни) відкритого ключа.

Кожен з цих методів передачі вимагає особливих процедур для того, щоб уникнути можливості підміни або перехоплення ключа в момент передачі, використання чужого імені для видачі сертифікату. Так, передача через телекомунікаційні мережі має бути зашифрованою та вестись після суворої аутентифікації сторін (наприклад з використанням старого відкритого ключа), видача сертифікату відкритого ключа особі має здійснюватись після перед'ялення документу, що засвідчує особу.

ЦСК має надавати кілька інтерфейсів: загальнодоступний для усіх користувачів, з використанням аутентифікації - для ЦСК нижчих рівнів, та внутрішній, для використання в межах одного центра та центрів більш високого рівня.

ЦСК має реалізовувати багато функцій, деякі з них повинні бути доступними лише для авторизованого персоналу:

• додавання / зміна інформації про клієнтів системи - тільки внутрішній запит,
• запит на анулювання сертифіката - вимагає аутентифікації та відповідних прав (звичайний користувач має змогу анулювати лише свій сертифікат, ЦСК може анулювати будь-який сертифікат, що їм виданий),
• запит на видачу сертифікату - вимагає аутентифікації,
• запит на інформацію про сертифікат, відкритий ключ ЦСК, тощо - загальнодоступно,
• отримати інформацію про сертифікацію - загальнодоступно.

Технічна реалізація інтерфейсів ЦСК повинна бути реалізована наступним чином. Треба стандартизувати та відокремити інтерфейсні модулі від основної системи роботи з сертифікатами - ведення бази даних і т. ін. Це дозволить під час розробки технології побудови ЦСК відволіктись від фізичного середовища передачі відкритого ключа та готового сертифіката (передавати інформацію можна як телекомунікаційними мережами або магнітними носіями, так і на аркуш паперу). Таким чином підтримка ще одного способу передачі інформації до ЦСК вимагатиме побудови лише додаткового інтерфейсного модуля. Власне система центру сертифікації приймає інформацію в її внутрішньому стандартизованому форматі - таким чином задачею інтерфейсного модуля є «переклад» у внутрішній формат системи підтримки ієрархії розповсюдження сертифікатів. Такий метод дозволить спростити та розбити на модулі систему захищеності центру сертифікації.

• Підтримка системи розповсюдження сертифікатів має бути реалізована за триступеневою архітектурою: «товстий клієнт», сервер застосувань (приложений) та сервер баз даних - див. [6].
• Докладніше про механізми сертифікації див. роботу [15].
• 4.3.4 Підсистема захисту
• Система електронної комерції складається з багатьох компонентів, кожен з яких вимагає певних заходів для захисту інформації. Так, збереження в таємниці таємних ключів усіх учасників системи є окремою нетривіальною задачею, що не маю універсального розв'язку. Також треба вжити певних заходів для захисту серверів підтримки дієздатності системи - бо, наприклад, несанкціонована модифікація списку анульованих сертифікатів становить загрозу для нормального функціонування системи.
• Як показано в [6], протягом всього періоду розробки системи необхідно враховувати заходи із захисту та безпеки інформації. В системи електронній комерції треба використовувати модель загроз «взаємної недовіри» та потрібно заборонити функціонування системи в обхід підсистем захисту та розмежування доступу.
• Оскільки технічні задачі з захисту інформації , які виникають в системі, є досить типовими, ми в роботі не будемо розглядати типові заходи - як то створення окремих мережевих сегментів для серверів, створення захищеної зони з обмеженим фізичним доступом до неї, і т. ін. Лише наголосимо на їх необхідності та на залежності надійності та безпеки всієї системи від цих заходів по забезпеченню захисту інформації.
• 4.4 Опис моделі системи

Модель системи електронної комерції має реалізовувати хоча б по одній реалізації кожного модуля системи - інакше модель не буде дієздатною. Таким чином потрібно реалізувати:

• - генератор пари ключів для асиметричної криптосистеми - окрема програма,
• - програма по створенню сертифіката відкритого ключа,
• - модуль системи захисту для покупця - plug-in (див. Уживані терміни) для браузера Microsoft Internet Explorer,
• - модуль системи захисту для продавця - plug-in для web- сервера Microsoft Internet Information Server.
• Ці основні модулі будуть включати в себе менші блоки, які мають реалізувати всі функції, що наведено у розділі 4.3, Структурна схема системи - це і перевірка ЕЦП, і перевірка ланцюга сертифікатів та інші.
• 4.4.1 Генератор пари ключів для асиметричної криптосистеми
• Генератор пари ключів для асиметричної криптосистеми має забезпечити захищеність закритого ключа на етапі генерації - тому обраний варіант з реалізацією його під однозадачну операційну систему MS-DOS - в однозадачній системі значно легше захистити дані, з якими працює програма. Вже згенерований ключ також треба захищати, але це вже окрема задача (див. також розділ 4.4.4, Підсистема захисту).
• Докладніше про генератор ключів див. роботу [17].
• 4.4.2 Модуль із створення сертифікату відкритого підпису
• Модуль із створення сертифікату відкритого підпису має бути частиною розгалуженої системи з підтримки ієрархії розповсюдження сертифікатів (див. розділ 4.4.3, Робота з сертифікатами відкритих ключів).
• Докладніше про програму з створення сертифікатів див. роботу [15].
• 4.4.3 Модулі підтримки клієнтів системи
• Останні два модулі - модулі системи захисту для клієнтів системи (продавців та покупців) було спроектовано та реалізовано автором роботи, їх докладний опис наведено в наступному розділі.
• 5. Модулі системи електронної комерції для використання клієнтами системи
• Модулі для використання клієнтами системи реалізуватимуться як компоненти за стандартом COM [20, 21], який дозволяє легко конструювати модулі, що можна підключати до інших програм, в тому числі браузера Internet Explorer або web- сервера Internet Information Server.
• 5.1 Архітектура підсистеми взаємодії з користувачами
• Як було сказано вище та наведено на схемі системи електронної комерції, модулі взаємодії з користувачами повинні працювати як доповнення до існуючих програмних засобів. Так, модуль підтримки покупця повинен бути інтегрований у web- браузер користувача, а модуль продавця має бути інтегрований у web- сервер. Така схема побудови системи електронної комерції надає широкі можливості по побудові електронних магазинів.
• Весь механізм по формуванню замовлення покупцем реалізується програмістами web- сайту та ніяк не залежить від власне системи електронної комерції. Це дозволяє реалізувати як простий Інтернет - магазин, так і складний програмний комплекс (наприклад із кошиком покупця, який можна наповнювати). Власне системі електронній комерції передається лише остаточно сформоване замовлення покупця. Формування такого замовлення цілком залежить від продавця, що надає змогу реалізувати будь-яку логіку формування замовлення, в тому числі «безкоштовні» подарунки, знижки, тощо.
• Також важливо те, що модуль СЕК продавця відокремлено від його web- сайту та механізму формування замовлення. Таким чином можливо організувати послугу по побудові типових web- сайтів для магазинів, що за будь-якими причинами не бажають створювати власний сайт та механізм формування замовлень. Це створює ще одну можливість заробляти гроші на електронній комерції: надавати в оренду типові web- сайти та створювати типові механізми формування замовлень.
• Відокремлення СЕК від платіжної системи дозволяє зберігати таємницю угоди між покупцем та продавцем - документи, які надходять до платіжної системи не містять деталей угод, а лише кінцеві суми платежів та номери рахунків (карток, тощо). Деталі угоди відомі лише покупцю та продавцю і під час укладання угоди захищені від розголошення криптографічними засобами.

Размещено на http://www.allbest.ru/

Мал. 5.1. Архітектура взаємодії клієнтських модулів в СЕК

Процес купівлі з точки зору взаємодії клієнтських модулів буде виглядати так:

1. Покупець відвідує сайт продавця, обирає деякі товари. Програмне забезпечення сайту відповідає за формування заявки.

2. Сайт передає модулю СЕК покупця спеціальним чином сформовану заявку.

3. Модулі СЕК покупця та продавця встановлюють зв'язок - взаємна аутентифікація, встановлення закритого каналу зв'язку.

4. Модуль покупця передає заявку модулю продавця.

5. Модуль продавця перевіряє коректність заявки. При цьому можлива взаємодія з КС продавця - наприклад перевірка наявності товару на складі або наявності покупця в БД «постійних клієнтів». В разі необхідності заявка доповнюється пропозиціями продавця та передається клієнту. Заявку може бути розширено за рахунок вибору платіжного засобу, вибору строків або способу доставки товару - при чому різним варіантам може відповідати різна результуюча сума до сплати.