Concept of security social network architecture protecting confidentiality Текст научной статьи по специальности «Компьютерные и информационные науки»

TECHNICAL SCIENCES

КОНЦЕПЦ1Я БЕЗПЕЧНО1 АРХ1ТЕКТУРИ СОЦ1АЛЬНО1 МЕРЕЖ1, ЩО ЗАХИЩАС

КОНФ1ДЕНЦ1ЙН1СТЬ

Ахрамович В.М.

к.т.н., доцент, Державний утверситет телекомуткацт

CONCEPT OF SECURITY SOCIAL NETWORK ARCHITECTURE PROTECTING

CONFIDENTIALITY

Akhramovych V.

Ph.D., associate Professor, State University of Telecommunications

АНОТАЦ1Я

Розглянуто структуру сощально! мереж!, яка забезпечуе конфщенцшшсть даних користувачiв, в тому числ^ ввд адмiнiстраторiв та власнишв мереж. Для забезпечення вказаних цшей в мереж1 маються домени: мента, обмшника, сховища даних, розглянута взаeмодiя мереж1 з користувачем. Мережа надсилае та зберiгаe всi поввдомлення та особисту шформацш в зашифрованому виглядг Iдентичнiсть користувача пов'язана з ушкальними ключами. Для зв'язку м1ж двома користувачами використовуеться Локаграма. Об-мш повiдомленнями ввдбуваеться за допомогою обмшнишв. Щоб друзi мали доступ до власного профiлю та iншого особистого вмюту, кожен користувач керуе шдексом . 1ндексний файл складаеться з запиав i ресурсiв. Передбачено розподшене зберiгання данних в рiзних сховищах, основною вимогою для друга користувача по каналу ППД е знання загально! секретно! секцп, передбачено використання криптографiч-но! хеш-функци, використання дешлькох пристро1в одним користувачем.

ABSTRACT

The structure of the social network is considered, which ensures the confidentiality of user data, including from administrators and network owners. To provide these goals, the network has domains: client, exchanger, data warehouse, considered the interaction of the network with the user. The network sends and stores all messages and personal information in encrypted form.

User identity is associated with unique keys. For communication between two users the Locogram is used. Messaging is done through exchangers. For each user to access their own profile and other personal content, each user manages the index. The index file consists of records and resources.

Provided distributed storage of data in different repositories, the main requirement for the second user through the PPD channel is knowledge of the general secret section, the use of cryptographic hash function, the use of multiple devices by one user.

Ключовi слова: сощальна мережа; децентралiзацiя; моделювання; домен; користувач; архиектура; вщносини; взаемодiя; граф; друзц запити; аношмшсть; данц шформащя; шифрування; ключц логограма; вдентифшащя;, канал; генеращя; довiра; протокол; синхрошзащя; профшь.

Keywords: social network; decentralization; modeling; domain; user; architecture; relationships; interaction; graph; friends; queries; anonymity; data; information; encryption; keys; locogram; identification; channel; generation; trust;protocol; synchronization; profile.

Вступ.

З децентралiзованою оргашзащею кожна з сощальних мереж, вирiшуe проблему адмшстра-тивного домену, однак вона не забезпечуе достат-нього захисту приватного життя для сво!х користу-вачiв. Friendsbook, надае концепцш децентралiзо-вано! ОСМ, яка заповнюе цю порожнечу своею архiтектурою безпеки.

Основна частина.

Огляд.

Щоб забезпечити мщш довiрчi вiдносини з вiртуальними контактами, Friendsbook обмежуе дружбу вщносинам, якi реально iснують. Крiм того,

перспектива користувача у Friendsbook об-межуеться його власною СМ. Користувачi Friendsbook не знають, чи е !хш сусiди друзями. Рисунок 1 iлюструе ситуацiю користувача и в кон-текстi соцiального графа Friendsbook. и знае лише тих члешв, якi знаходяться у його особистому колi друзiв и (и) = {VI, v2, v3}. Перегляд неведомого члена wi6 V \ (Г (и) и и) неможливий. Навiть прямi запити друзiв мiж и та wi виключенi. Розглядаючи дружбу мiж и

та другом vi6 Г (и) в iзоляцii, и знае лише особисту шформацш, для яко! vi явно надав доступ (на рис. 1, символiзуеться блокуванням). ) або один з його друзiв vi та неввдомий користувач Wi СМ.

Рис.1: Погляд користувача на сощальний граф Friendsbook.

Для моделювання ще! ситуаци Friendsbook ро-зрiзняе так1 домени:

Домен клiента. Домен ктента включае всiх ко-ристувачiв системи. Технiчно, клiент представлений термшалом користувача, налаштований вiдповiдним програмним забезпеченням Friendsbook.

Домен обмiнника. У Friendsbook домен обмш-ника використовуеться для зв'язку мiж двома ктентами. Обмiнник - абстрактне поняття каналу зв'язку. Обмшник забезпечуе безпечний та аношм-ний обмiн повiдомленнями та шшою особистою ш-формацiею м1ж двома клiентами. Для забезпечення постшно! доступностi та пвдтримки мобiльних абонента кожен розширювач повинен забезпечувати можливiсть кешування та асинхронно! доставки по-вiдомлення.

Домен сховища даних - сховище даних (СД) -абстрактне поняття сховища даних. Сторшка даних використовуеться користувачем для постшного

збер^ання його особисто! шформацп та вмюту. Забезпечення права на шформацшне самовизначення вимагае повного контролю доступу ктента до сховища даних. Для того, щоб друзi користувачiв от-римували цю шформацш в будь-який час, домен сховища даних повинен гарантувати постiйну до-ступнiсть даних, що зберiгаються там.

Рисунок 2 iлюструе залежностi i взаемодп двох входжень трьох домешв. Клiент и розмiщуе свiй особистий контент вмагазиш даних СД. Клiент V може отримати цi даш в будь-який час через СД. Для зв'язку и i V забезпечують один одного обмш-ником. и посилае сво! поввдомлення V через обмшник ОБv i отримуе поввдомлення вiд V через влас-ний обмiнник ОБи. Кшьшсть i використання клiентiв, обмiнникiв i сховищ даних для кожного користувача не обмежеш. Щоб отримувати по-вiдомлення через свого клiента, користувач може мати тiльки одного друга, а також будь-якого кори-стувача

Рис. 2 Залежност11 взаемод1я двох кл1ент1в, обмгнника I доменгв сховищ даних (т - шифрованI пов1дом-

лення).

забезпечити через обмшники. З точки зору за-безпечення власно! аношмносп, рекомендуеться використовувати декшька обмiнникiв. У кращому випадку користувач надасть кожному зi св!х друзiв iнтегрований пошук. Для того, щоб звести до мшмуму ймовiрнiсть успiшного використання атаки, можна також використовувати кiлька обмш-ник1в на одного друга. З тих же причин рекомендуеться використовувати декшька сховищ даних.

Концепщя безпеки

Для дотримання вимог конфщенцшносп та безпеки, Friendsbook надсилае та збертае всi по-вiдомлення та особисту шформацш в зашифрова-ному виглядi. На основi концепци хорошо! конфщенцшносл (ХК) [1], яка, крт усього iншого, забезпечуе безпечну електронну пошту, Friendsbook використовуе комбшацш асиметрич-ного та симетричного шифрування. Iнформацiя, яку необхiдно обмiняти, спочатку шифруеться на ос-новi симетрично! процедури. Симетричний ключ потiм зашифровуеться вiдкритим ключем одер-жувача. Зашифрований контент складаеться з зашифровано! шформаци, асиметрично зашифрова-ного симетричного ключа i пщпису на основi закри-того ключа вщправника. Спочатку ХК базувалася на концепци 1нтернет довiри (1Д). Iдентичнiсть ко-ристувача пов'язана з унiкальним вiдкритим клю-чем, а для того, щоб той самий одержувач зашиф-рував повщомлення, всi вщправники використову-ють один i той же вщкритий ключ. Очевидно, що за допомогою одше! пари ключiв юнуе ризик де-анонiмiзацi! передавача i приймача. Для того, щоб забезпечити максимальний захист конфщенцшносл у РпепскЬоок, кожей користувач и генеруе для

кожного з сво!х дру ив V ^ ГШ) пару ключових

к~ к- ' к~

сл1в V , де ^И^ивццюситься до

ключа публiчно! посилання (КПП). I навпаки, ко-жен друг генеруе пару ключiв для стлкування

(КГД) Кй^Р. для и. КГДв е виключними

для зашифрованого зв'язку i забезпечення осо-бистих даних. Використовуеться обмiн мiж и i V. З точки зору и, дружба з V визначаеться трьома Ь8Кв

^ЫчЬ- . дс . Формування дружби з

трьома ключами пов'язано з шдвищеною склад-нiстю в управлшш ключами. Оск1льки кожна дружба визначаеться трьома ключами, користувач и повинен керувати 3п ключами замiсть звичайних п + 2 ключiв для сво!х n=|Г(u)|друзiв. Ця обставина свщомо приймаеться. Кожна пара КГД використовуеться для стлкування в межах одше! дружби. Таким чином, деанонiмiзацiя сошального графа наба-гато складнiша. З iншого боку, видалення ключiв зменшуе видалення скомпрометованого КГД. Зав-дяки тому, що загальнодоступний КПП використо-вуеться другом, скомпрометований протокол управлшня потоком (ПК) не повинен управлятися в списках скасування.

З'язок

Незалежно вiд реалiзацi! обмшника, КГД доз-воляють анонiмну та безпечну доставку повщом-лень. Дал1 пояснюеться використання КГД в спшкуванш двох користувачiв.

Формат пов1домлення

Для зв'язку м1ж двома користувачами використовуеться FriendsbookЛокаграма[2]. Локаграма складаеться з щентифшатора, вмiсту та пщпису. Виходячи з структури локаграми, на малюнку 3 показана структура повщомлення у Friendsbook, який хоче вiдправити повiдомлення своему другов^ пiсля чого три компоненти складаються наступним чином. 1дентиф1катор - це хеш-значення КПП

к** 11-11?,. Хеш-значення генеруеться за допомогою

вiдповiдно! хеш-функцi! Н i використовуеться для

призначення повщомлення одержувачу и. Оскшьки

и генеруе КПП л 11-г V для V, для кожного з сво!х друзiв, аношмшсть одержувача и забезпечуеться,

навиъ якщо повщомлення передаеться через неза-хищений канал зв'язку.

Змют. У випадку контакту це засноване на

к.

КПП 11зашифроване повадомлення т. Шиф-рування гарантуе ексклюзивний i авторизований доступ за допомогоюкористувача и. Великi обсяги даних спочатку шифруютъся за допомогою симет-рично! процедури. Використовуваний ключ шиф-

руеться за допомогою VI додаеться до за-шифрованого повiдомлення. Метод ввдповвдае процедур! ХК. Для невеликих обсяпв даних т також

К -

може бути зашифровано безпосередньо .

Незалежно ввд використовуваного варiанту, нижче використовуетъся термiн "шифрування на основi КПП". Пiдпис. Щдпис використовуетъся для забез-печення цiлiсностi та автентичносл повiдомленъ

користувачу v. Це хеш-значення ш, закодованого на

К;

ocHOBi КПП

функц1я H

^U-iV. Знову запускаеться хеш-

AUv + (m) Kv-,u '(H(m)) 'И

Рис. 3 Створення повадомлення у Friendsbook.

КV-tU аношмшсть

Оскшьки пльки и КПП ввдправника V також забезпечуеться, коли повiдом-лення передаетъся через захищений канал зв'язку. Обмш пов1домленнями

Рисунок 4 ¡люстру€ зв'язок \пж двома друзями

и та V. Використовуються два КГД 1'

та -,Р ^ и-¡V . 3 точки зору и дружба з V визна-

часться трьома

КПП Ky,-,V i ^V->U.

Рис. 4: Зв'язок мiж двома користувачами у Friendsbook.

Обмш пoвiдoмленнями ввдбуваеться за допомогою обмшника ОБv або ОБи. Функцioнальнicть oбмiнника нагадуе функцioнальнicть поштово! скриньки. Пoвiдoмлення зберiгаетьcя oбмiнникoм, поки воно не може бути доставлене одержувачу. Кожен oбмiнник iдентифiкуетьcя за ушкальною ад-ресою. Щоб тдвищити рiвень анoнiмнocтi, кори-стувач може надати кожному 3i сво1х друзiв iншу адресу oбмiнника. Другу також можуть бути наданi декiлька рiзних адрес, як1, наприклад, змiнюютьcя випадковим чином почергово. Оcкiльки кожне по-

ввдомлення кодуе приймач як щентифшатор, по-ввдомлення можуть передаватися за будь-яким каналом зв'язку, а також мoжливi cинхрoннi i асин-хрoннi, реалiзацiï. Крiм прoтoкoлiв, таких як XMPP [6], IRC [4] i SMTP [5] у поеднант з POP3 [3] або IMAP [7], обмшники можуть також використо-вувати послуги SMS або мжроблогшгу, таш як Twitter. Можлива передача через WLAN або Bluetooth на ocнoвi власного спещального протоколу або фотографування QR-коду.

Збер^ання даних

Для того, щоб зробити особистий контент до-ступним для власного кола друзiв, в Friendsbook ви-користовуються сховища даних. Авторизований доступ користувача u до особистого змiсту друга v забезпечуеться шифруванням контенту на ochobI

к-

публ¡много КПП1 v V-i'U. Рсалпащя сховища даних повинна вщповщати лише вимозi про передачу осо-бистого контенту

Дшсний унiфiкований локатор ресурав (УЛР) можна посилатися i отримувати. Для забезпечення постiйного доступу до даних, реалiзацiя сховища даних повинна гарантувати високу доступнiсть. Можливими е FTP-сервер [5], сервер WebDAV [2] або сайти, так1 як Amazon S3 [9] або Dropbox [8].

Схема адресацп.

Для того, щоб друзi мали доступ до власного профшю та шшого особистого в\псту. кожен користувач керуе ¡ндсксом для кожного друга v.

Це шифруеться на ochobI КПП ^-V-tU i зберiгаеться в сховищi даних СД. Якщо двое людей знаходяться в дружбi в Friendsbook, вони роздшя-ють УЛР-адреси з 1хшми iндексними файлами. 1н-дексний файл складаеться з запиав i ресурсiв. Записи введення е простою iнформацiею про користувача, яка включае в себе iм'я, вiк або стать, вводяться у виглядi пар ключ / значення, напри-клад, ключовi слова. вш = 25 зберiгаеться в iндекс-ному файлi. 1ндексний файл може мютити будь-яку к1льк1сть таких запиав. Для бiльш складного вмюту доступний список ресурсiв. Ресурси можуть бути рекурсивно побудованi, прикладом цього може бути дошка, реалiзована у виглядi списку ресурсiв. Кожна окрема дошка оголошень знову представляе ресурс, через рiзнi властивостi, так1 як наприклад обсяг даних мультимедiйного контенту у Friendsbook пропонуються рiзнi можливосл для ш-теграцп. Ресурси можуть бути:

a) безпосередньо в вдексному файл^ наприклад. кодуеться як рядок База64 [3];

b) пов'язаний з незашифрованим файлом;

c) пов'язаний з файлом, зашифрованим на ос-новi загального КПП друга;

d) пов'язаний з симетрично зашифрованим файлом.

Щоб зберегти файл тонкого iндексу е варiанти:

а) слщ використовувати лише для малих об'ектiв даних;

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

Цей варiант мае сенс, зокрема, якщо користувач на публщ не хоче бути пов'язаним з посилан-ням на вмiст. Для того, щоб забезпечити ресурси для обмеженого кола друзiв, такий варiант мае бути доступним, для обмеженого кола друзiв. Приклад, це могла б бути особиста дошка. Використовуваний симетричний ключ може бути штегрований як ресурс через варiант:

с) для доступу користувача и до файлу друга v,

спочатку завантажуеться ¡ндсксний файл .

Хочете, щоб у один клш вщкрився ресурс за допомогою посилань, u вщкрив вщповщний УЛР i де-шифрував згаданий вмют. Якщо bmîct знову е поси-ланням, цей крок повторюеться. За допомогою цього мехашзму користувач може плавно перегля-дати особистий вмют сво1х друзiв.

Розподiлене зберiгання.

Так само, як дешлька рiзних обмшнишв можуть бути використанi для одного або декшькох друзiв, користувачi мають можливiсть поширювати та вибiрково розповсюджувати свою особисту ш-формацю за допомогою одного або бшьше сховищ даних. З одного боку, користувач, таким чином, зберiгае свое право на шформацшне самовизна-чення, з шшого боку, це дозволяе роздшити чутли-вий та iнший особистий змют, наприклад, якщо правовi положения або правовi норми змушують користувача робити це. Концепця магазину даних також дозволяе штегрувати iншi соцiальнi плат-форми. Наприклад, ОСМ, так1 як Flickr або Last.fm, можуть бути шгегроваш в Friendsbook для надання загальнодоступних фотографiй або музичних файлiв як сховищ даних. Для публшацп особистого контенту можна використовувати iншу послугу, наприклад, - приватний сервер FTP. Щоб обмежити доступ до вибраного кола друзiв, вмiст збертаеться зашифрованим на основi пов'язаних КПП. Домен обмшу дозволяе користувачевi в будь-який час по-вщомляти сво1х друзiв про змiни в домеш магазину даних. Якщо, наприклад, користувач и, змшив записи ¡ндс кс но го файлу ^u-tv або виршшв пе-

ремютити, Ï\t-rV до ¡ншого сховища даних, вш може повщомити друга v в обмшнику ОБv.

Навчання дружбь

У зв'язку з вимогою мщних вiдносин довiри мiж друзями, немае пщтримки для пошуку шших користувачiв. Перегляд соцiального графа не пщтримуеться. Таким чином, можливостi надюлати запит на дружбу iншим користувачам дуже обме-жений. Нижче представлен рiзнi варiанти фор-мування дружби. До цього будуть пояснюватися деяш термiни, як1 стосуються обмiну повщомлен-нями.

06mïh пов1домленнями.

У Friendsbook безпечний канал зв'язку м1ж двома друзями визначае право власносп та використання ПК. На додаток до цшсносп повщомлень та автентичносл партнера по комунiкацiï, використання КГД забезпечуе авторизований доступ до обмшу змютом. У Friendsbook безпечний канал зв'язку юнуе тшьки тод^ коли двое користувачiв е друзями. Якщо два користувачi хочуть завести но-вих друзiв, певною шформащею потрiбно об-мiнюватися через небезпечний канал. У контексл Friendsbook е канал, який не забезпечений викори-станням КГД двох користувачiв. На додаток до ди-ференцiацiï мiж захищеними i небезпечними каналами зв'язку, проводиться вщмшнють м1ж повщом-леннями у дiапазонi (ПД) i поза дiапазоном гурту (ППД). Повiдомлення ППД не передаються через обмiнник. Вони вщправляються тiльки при побу-довi дружби. Цше повiдомлення не зашифровано на

0CH0Bi публiчних КПП. Проте OKpeMi частини вмюту можуть бути зашифрован на 0CH0Bi пyблiч-ного КПП. ПД-поввдомлення ПД-повiдомлення пе-редаються через обмiнник. Вони повнiстю зашифроваш на основi пyблiчного КПП. Поввдомлення МП пiдтверджyються пiдтвердженням (ACK).

Протокол дружби.

Основою для укладення дружби е дрyжнiй протокол, першi кроки якого базуються на каналi ППД. Надалi обмiн iнформацiею завжди стосуеться обмiнy повiдомленнями. Проте протокол не визна-чае спосiб обмшу iнформацiею мiж двома користу-вачами. Якщо обмiн iнформацiею е просто тексто-вим файлом, його можна отримати будь-якими за-собами, наприклад,

Рис. 5: Формування дружби через протокол Дружби.

основною вимогою для друга користувача по Використовуючи криптографiчнy хеш-

каналу ППД е знания загально! секретно! секцп функцио [2] Н i загальний секрет, sec и генеруе код

нроцес дружби показано на рисунку 5 ! включае аутснтиф|кацГ| (КА) hLU = H(FLQ ц5ес) який

наступш кроки. передае и разом з запитом про дружбу через канал

а) и спочатку генеруе КГД V ППД до v.

ключ публ!чного посилання КПП генеруе запит про Ь) Якщо перев!ряеться цшсшсть i автентич-

дружбу ЗД;

шсть запиту на дружбу, v генеруе ^U-t V ^U-fV .

Використовуючи ^ lil rV, v кодуе публ1чний

K~

КПП i?l LL разом з будь-яким числом адрес об-

мшника ■■■ ■ 0БП j генеруе вщюввдь друга

ВД (ВД, English: дружба вщюввдь). Разом з КА

h^G, = fi(F||Sec), v передае вщюввдь друга через канал ПДД.

кс) За допомогою 111 V удешифруе вмют

ВД. Через прикршлеш КА hFa, u може забезпечити

цшсшсть запиту дружби ВД i автентичносп v.

К '

Осшльки ключ Ul . V передаеться в незашифро-ваному виглядi на етат а), u повинен замшити його на ключове ввдновлення (КП) до оголошення його адреси в обмшнику. Зловмисник, який мае доступ до каналу ППД, в шшому випадку зможе де-анонiмiзyвати наступш поввдомлення вiд v до u через використовуваний вдентифпсатор. и створюе но-

К

+

U2—>V

К

вий It2-»V. За допомогою "Vl И, и кодуе публ1чний КПП, генеруе КП i передае КП до каналу

Об, .. .ОБ'

Kvi

ПД V. Використову еться обмшник ^131 ,1,,иип . с1). и кодуе будь-яке число адрес користувача

-■Зппна осюш КПП . генеруе

оновлення обмшника ЗП I передае ЗП до V через

Нарештi, и та V повинн передавати УЛР-адресу до iндексного файлу 1и ^ V або IV ^ и у своему доменi магазину даних. Для цъого ввдповвдна зашифрована адреса СД на основ1 КПП

К;

41-, V, генеруе пропонований П I передае П через . Шсля того, як V отримав поновлення ключа и (див. крок с), V також виконуе профiлъ для и. Цей етап е незалежним вiд стадiй d) i е). Щоб протидiяти атакам ввдтворення, протокол дружби використовуе випадково згенерований поввдомлення для кожного поввдомлення, крiм того, запити друзiв можутъ бути тимчасовими, що визначае максималъний термiн ди запиту про дружбу. Щ елементи не вiзуалiзуються на малюнку 5. Пiдтвердження по-вiдомленъ ПД, iдентифiкаторiв вiдправникiв i необ-х1дних КА не показано.

Протокол взаемодп.

Концепцiя Friendsbook виключае перегляд ш-ших користувачiв. Щоб зб№шити можливостi для процесу дружби, Friendsbook надае протокол

зв'язку. У СМ новi дружнi знайомства часто вини-каютъ в резулътатi спшьного знайомства, а протокол «зчеплення» - спроба моделювати цю ситуацш для ОСМ Friendsbook. Використання протоколу зв'язку е корисним, коли користувач мае двох друзiв, якi ще не мають взаемних ввдносин один з одним. Пвдхвд грунтуеться на припущеннi, що два друзi V та w користувача и, ймовiрно, погодяться один з одним у взаемнш дружносп, коли и надае взаемну рекомендацш w та V. Iмовiрнiстъ прий-няття рекомендаци залежить вiд ступеня впевне-ностi мiж и та V або и та w. На рисунку 6 прошюст-ровано протокол взаемодп на приклад 1 трьох кори-стувач1в и, v та \у {у,\у}£ Г(и)1 ¡\.\\ | € Е. Упротоколi зв'язку ва повiдомлення обмiнюютъся за захищеними каналами ПД.

а) и посилае запит зв'язку (ЗЗ) на V i w. Змiст Пw або Пу не уточнюеться бiлъш детально. Це, наприклад, повноваження w, ввдповвдно, як загаль-ноприйнятий атрибут профшю у зв'язку з персо-нальним повiдомленням ЗЗ поввдомлення шифру-ються на основi публiчних КПП з V i w, вiдповiдно;

б) Якщо V зацiкавлений у дружбi з w, V ввдповвдае на запит зв'язку з приймаючим зв'язком

(СА), у свою чергу V генеруе новий КГД XV

I надсилае публ1чний КПП ^VI IV . \\' шифруе

К~

назад до и на основ1 публ1чного КПП VI'1 и . Якщо w також зацiкавлений вiн аналопчно робить необхiднi кроки.

c) и дешифруе СА з V 1 перенаправляе його \у

на основ1 публ1чного КПП IV . Аналопчно и

поступае з СА w.

d) У бiлъш шзньому ходi зв'язку м1ж V i w, щоб запобiгти деанонiмiзацil за допомогою и, w виконуе поновлення ключа шсля отримання поввдомлення

С А. Для цього новий КГД 2 V пе-

редае публ1чний КПП зашифрований як поввдом-

лення КП на основ1 КПП 1 IV . V пропкае ана-логiчно;

e) Для запобпання анонiмним атакам, V i w мо-жуть додатково також оновити адреси розши-рювачiв, пiсля чого w посилае новий розширювач СД\уяк ЗП-зашифроване поввдомлення на основ1

КПП

W v. v робить аналопчно.

Рис. 6: Процес комуткацИ' при встановлент дружби за допомогою протоколу зв'язку.

f) Останнш обмш v i w через повщомлення (П), виконують шлях до 1х iндексних фамв у виглядi адрес ШIФv i ШIФw, вiдповiдно. Генера^ та вiдправка повiдомлень вщбуваеться аналопчно протоколу дружби.

Однак, через сильний взаемозв'язок довiри мiж u та w, u та v, потенцiйна атака MITM не вважаеться вразливiстю безпеки. Проблему можна усунути, ви-магаючи, щоб v та w на крощ d) забезпечили цшсшсть повщомлення та достовiрнiсть партнерiв по комушкацп. Аналогiчно протоколу дружби, для цього можна використовувати КА. Необхщний за-гальний секрет v i w повинен обмшюватися по каналу ППД.

Лтратура

1. M. Crispin, "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1." RFC 3501 (Proposed Standard), Mar. 2003. UpdatedbyRFCs 4466, 4469, 4551, 5032, 5182, 5738, 6186.

2. L. Dusseault, "HTTP Extensions for Web Distributed Authoringand Versioning (WebDAV)." RFC 4918 (Proposed Standard), June 2007. Updatedby RFC 5689.

3. J. Myersand M. Rose, "Post Office Protocol -Version 3." RFC 1939 (INTERNET STANDARD), May 1996. Updatedby RFCs 1957, 2449, 6186.

4. OikarinenandD.Reed,"Internet Relay Chat Protocol. "RFC1459 (Experimental), May 1993. UpdatedbyRFCs 2810, 2811, 2812, 2813.

5. J. Postel, "Simple Mail Transfer Protocol." RFC 821 (INTERNET STANDARD), Aug. 1982. Ob-soletedby RFC 2821. [176] J. Posteland J. Reynolds, "File Transfer Protocol." RFC 959 (INTERNET STANDARD), Oct. 1985. Updatedby RFCs 2228, 2640, 2773, 3659, 5797.

6. P. Saint-Andre, "Extensible Messaging and Presence Protocol (XMPP): Core." RFC 6120 (Proposed Standard), Mar. 2011.

7. W.Stallings,Cryptography and Network Security: Principles and Practice. PrenticeHall, 5 ed., January 2010.

8. Dropbox, "Dropbox," 2013. https://www.dropbox.com/, letzterAbruf: 03.04.2013.

9. S3, "Amazon simples torageservice (amazon s3)," 2013. http://aws.amazon .com/s3/, letzterAbruf: 03.04.2013.