 |
|
|
|
Метод регистрации нового пользователя в распределенной социальной сети
Метод регистрации нового пользователя Целью данной работы является разработка метода регистрации нового пользователя в распределенной социальной сети, обеспечивающей повышенный уровень безопасности. Встатье также описываются ограничения, связанные с работой метода, и пользователи, которые участвуют в ходе выполнения процесса регистрации нового пользователя. Далее описываются следующие процедуры: безопасный обмен переменными, регистрация, включающая в себя выработку пары ключей нового пользователя, выработка дополнительных пар ключей, реализующих многослойное шифрование и периодическую смену этих ключей Введение Социальные сети (СС) стали в наше время одними из самых популярных и быстро развивающихся сетевых сервисов. На данный момент, существует три основных типа архитектур построения СС – клиент-серверная, распределенная и децентрализованная распределенная. Клиент-серверная архитектура СС является наиболее популярной вследствие легкости реализации, но в то же время обладает определенными недостатками. Распределенная иполностью децентрализованная архитектуры построения СС сложнее в реализации, но обладают большим количеством возможностей с точки зрения безопасности [1]. Одной из главных проблем защиты СС, построенных на базе распределенной и полностью децентрализованной архитектур, является относительная невозможность применения способов защиты, которые используются для СС, основанных на клиент-серверной архитектуре. В данной работе предлагается метод регистрации нового пользователя, который может быть использован практически в любой СС, основанной на распределенной или полностью децентрализованной архитектуре, которые используют протокол DHT или DHT-подобные протоколы [2]. Метод включает в себя следующие процедуры:
Пользователи, участвующие в процессе регистрации нового пользователя В ходе выполнения алгоритма в нем принимают участие следующие пользователи:
Процедура регистрации нового пользователя Процедура регистрации проходит в четыре этапа. В ходе первого и второго этапов пользователи A и B обмениваются переменными, которые необходимы для начала процесса регистрации нового пользователя. В ходе третьего этапа происходит регистрация нового пользователя B. В ходе четвертого этапа пользователь B с помощью пользователя Aгенерирует свою основную пару ключей шифрования, которая необходима ему для работы в РСС. Этап 1. Шифрование и безопасный обмен переменными В ходе выполнения данного этапа происходит первоначальная выработка и согласование переменных, необходимых для процедуры приглашения, и личный контакт между пользователями A и B, что позволяет предотвратить перехват переменных в случае передачи через сети открытого доступа. Пользователи A и B связываются друг с другом с помощью любого типа связи, позволяющего общаться в режиме реального времени, например телефонной связи. Пользователь Bуведомляет пользователя A о том, что он хочет зарегистрироваться в РСС, пользователем которой является A. Пользователь A соглашается зарегистрировать пользователя B ипредлагает B выработать логин, который будет использоваться B для входа в РСС, и временный пароль, который будет использоваться для создания одного из уровней шифрования при передаче данных через РСС в ходе выполнения третьего и четвертого этапов. Пользователь B вырабатывает логин и временный пароль, которые он сообщает A. Пользователь Aпроверяет уникальность логина, выбранного пользователем B, и в случае необходимости вместе с пользователем B корректирует логин B для достижения уникальности. Пользователь A, в свою очередь, вырабатывает свой временный пароль, который будет аналогично использоваться для создания еще одного уровня шифрования при передаче данных через РСС в ходе выполнения третьего и четвертого этапов. Пользователь A вырабатывает файл приглашения, который является хеш-суммой, выработанной от хеш-сумм компонентов, сложенных с помощью операции сложения по модулю два: логин пользователя B, временные пароли пользователей A и B, текущий адрес пользователя A в сети, выработанный в соответствии с логикой протокола DHT, текущие Дата иВремя и «Соль», которая является криптостойким набором цифр. Следует отметить, что в ходе выработки файла приглашения пользователь A может использовать любые совместимые между собой протоколы выработки хеш-сумм, что позволит повысить криптостойкость файла приглашения в случае, если пользователь C перехватит этот файл и попытается его взломать. После выработки файла приглашения пользователь A вырабатывает от него хеш-сумму. Данная хеш-сумма будет использоваться пользователями A и B для создания еще одного уровня шифрования при передаче данных через РСС в ходе выполнения третьего и четвертого этапов. Далее пользователь A создает криптоконтейнер, который шифрует с помощью временных паролей, выработанных A и B. В криптоконтейнер он помещает файл приглашения, хеш-сумму, выработанную от файла дистрибутива клиента РСС, и логин пользователя A, который связан с адресом клиента пользователя A в РСС согласно логике протокола DHT. После создания криптоконтейнера пользователь A помещает его на физический носитель вместе с файлом дистрибутива клиента РСС. Создание криптоконтейнера необходимо, так как пользователь C может попытаться перехватить передаваемые файлы. В результате перехвата, в случае если файл приглашения, хеш-сумма от файла дистрибутива клиента РСС, выработанная A, и логин пользователя A не будут зашифрованы, пользователь C может попытаться зарегистрироваться в РСС под своим именем либо подменить файл дистрибутива клиента РСС на модифицированный, содержащий вредоносные функции, либо указать свой логин вместо логина пользователя A. Данный физический носитель пользователь A передает пользователю B в ходе личной встречи. Также пользователь A сообщает пользователю B свой временный пароль, который онвыработал. Стоит отметить, что личная встреча пользователей A и B является наиболее предпочтительной, так как это позволяет максимально обезопасить процесс передачи файлов. Но вслучае необходимости пользователь A может передать эти файлы пользователю B с помощью любых других видов связи, в том числе и открытых. В частности, для таких случаев предусмотрено вышеописанное двойное шифрование с помощью временных паролей, придуманных пользователями A и B. В то же время стоит отметить, что в случае передачи файлов, необходимых для процесса регистрации, вне личной встречи пользователю необходимо учитывать, что эти файлы могут быть перехвачены и слои шифрования, основанные на временных паролях пользователей A и B, могут быть взломаны.
Рисунок 1. Схематичное отображение этапа 1. Передача файла дистрибутива клиента РСС и зашифрованных в криптоконтейнере файла приглашения, хеш-суммы от файла дистрибутива клиента пользователю B в ходе личной встречи с пользователем A Этап 2. Расшифровывание переменных На данном этапе пользователь B расшифрует полученные криптоконтейнеры, определит полученные переменные и установит на свой компьютер дистрибутив клиента РСС. Пользователь B расшифровывает полученный на физическом носителе криптоконтейнер с помощью временных паролей, которые были выработаны в ходе личной встречи пользователей A и B. Таким образом, пользователь B получает файл дистрибутива клиента РСС и расшифрованные файл приглашения и хеш-сумму от файла дистрибутива клиента РСС, которую высчитал пользователь A. Пользователь B вырабатывает хеш-сумму от файла приглашения, которая будет использоваться для создания еще одного уровня шифрования при передаче данных через сети открытого доступа в ходе выполнения третьего и четвертого этапов. Пользователь B также вырабатывает свою хеш-сумму от файла дистрибутива клиента РСС, который находился на физическом носителе, и сравнивает его с хеш-суммой, которую выработал пользователь A. В случае если хеш-суммы идентичны, пользователь B может считать, что файл дистрибутива клиента РСС является тем файлом, от которого пользователь A высчитывал хеш-сумму, из чего следует, что это тот файл, который передал пользователь A. Дополнительно пользователь B может сравнить полученную и выработанную хеш-суммы с хеш-суммой клиента РСС, выложенной на официальном сайте РСС в сети общего доступа Интернет, в случае если существует такая возможность. В случае если пользователь A не смог передать дистрибутив, пользователь B может скачать последнюю версию дистрибутива с официального сайта РСС в сети общего доступа Интернет, вычислить хеш-сумму от скачанного дистрибутива и сравнить ее с той, которую прислал пользователь A. Пользователь B устанавливает на свой компьютер клиент РСС, получает адрес узла в сети, выработанный в соответствии с логикой протокола DHT. Далее пользователь B вводит в клиент файл приглашения, который для него выработал пользователь A, и логин пользователя A. Клиент РСС пользователя B находит в РСС клиент пользователя A и уведомляет о том, что планируется процедура регистрации нового пользователя. В случае успешного ответа клиента пользователя A клиент пользователя Bпредлагает B ввести свой логин, который он выработал в ходе первого этапа. После этого пользователь B может ввести пароль, который будет использоваться для аутентификации Bв РСС. Этап 3. Регистрация пользователя B На данном этапе пользователи A и B произведут аутентификацию и верификацию друг друга для подтверждения своих личностей. Пользователь B создает криптоконтейнер, имеющий три уровня шифрования, которые обеспечиваются с помощью временных паролей и хеш-суммы от файла приглашения. Вкриптоконтейнер B вкладывает сообщение для A, в котором представляется как B и просит начать процесс генерации ключей для него. Полученный криптоконтейнер B отправляет A через РСС. Пользователь А получает криптоконтейнер с сообщением от пользователя B, но он не может быть уверен в том, что это сообщение от настоящего B, и таким образом A связывается сB через любой другой тип связи, позволяющий общаться в режиме реального времени, например телефонная связь. Связавшись с B, пользователь A подтверждает, что с ним связался настоящий B, и начинает процесс генерации основной пары ключей для пользователя B.
Рисунок 2. Схематичное отображение этапов 2 и 3. Пользователь B вкладывает сообщение для пользователя A в криптоконтейнер, имеющий три уровня шифрования, которые обеспечиваются с помощью временных ключей A и B и хеш-суммы от файла приглашения. Данный криптоконтейнер B отправляет A через РСС. Пользователь A расшифровывает криптоконтейнер и получает сообщение. Для подтверждения отправителя сообщения A связывается с B не через РСС, например с помощью телефонной связи Этап 4. Генерация основной пары ключей пользователя B На данном этапе производится генерация основной пары ключей, секретного и открытого, пользователя B, что позволит B стать полноценным пользователем РСС. Пользователь A вырабатывает «секрет», который является хеш-суммой, выработанной от хеш-сумм компонентов, сложенных с помощью операции сложения по модулю два: временные пароли пользователей A и B, текущий адрес пользователя A в сети, выработанный в соответствии с логикой протокола DHT, открытый ключ основной пары шифрования, текущие Дата и Время и «Соль». После вычисления «секрета» пользователь A вырабатывает сертификат для пользователя B, который аналогично является хеш-суммой, выработанной от хеш-сумм компонентов, сложенных с помощью операции сложения по модулю два: логин пользователя B, открытый ключ основной пары шифрования, файл приглашения, «секрет», текущие Дата и Время и«Соль». Пользователь A помещает открытый ключ своей основной пары и сертификат для пользователя B в криптоконтейнер, зашифрованный с помощью временных паролей, выработанных на первом этапе, и хеш-суммы от файла приглашения, который он отправляет через РСС пользователю B. Пользователь B расшифровывает полученный криптоконтейнер и получает открытый ключ основной пары пользователя A и сертификат, который ему необходим для выработки своей основной пары ключей шифрования. Таким образом, пользователь B вырабатывает инициализирующую переменную для выработки своей основной пары ключей шифрования, которая является хеш-суммой отвыработанной от хеш-сумм компонентов, сложенных с помощью операции сложения по модулю два: текущий адрес пользователя B в сети, выработанный в соответствии с логикой протокола DHT, файл приглашения, сертификат, открытый ключ основной пары пользователя A, текущие Дата и Время и «Соль». После выработки своей основной пары ключей шифрования пользователь B создает криптоконтейнер, в который он помещает открытый ключ своей основной пары шифрования, зашифрованный с помощью временных паролей, и открытого ключа основной пары шифрования пользователя A. Таким образом, расшифровать один из слоев шифрования этого криптоконтейнера может только пользователь A, который владеет секретным ключом своей основной пары шифрования. Пользователь B отправляет этот криптоконтейнер через сеть РСС пользователю A. После получения этого криптоконтейнера пользователь A расшифровывает его и в результате получает открытый ключ основной пары шифрования пользователя B.
Рисунок 3. Выработка основной пары ключей шифрования. Пользователь A отправляет пользователю B сертификат и открытый ключ своей основной пары шифрования через РСС вкриптоконтейнере с тремя уровнями шифрования, которые обеспечиваются временным паролями и хеш-суммой от файла приглашения. Пользователь B расшифровывает полученный криптоконтейнер, вырабатывает свою основную пару ключей шифрования и отправляет открытый ключ этой пары пользователю A через РСС в криптоконтейнере, который зашифрован с помощью временных паролей и открытого ключа пользователя A С этого момента процедура регистрации считается завершенной и пользователи A и B могут считаться «Друзьями» друг друга. В частности, с этого момента пользователи A и Bмогут использовать для шифрования открытые ключи основных пар друг друга и использовать личные секретные ключи для расшифрования отправленных друг другу данных. Особенности работы с ключами Как уже было описано выше, после процедуры приглашения пользователь B обладает парой ключей шифрования. В то же время стоит отметить, что, учитывая мощности современной компьютерной техники, а также уязвимости отдельных криптографических протоколов к определенным типам атак, единичный слой шифрования сообщений, передаваемых между пользователями A и B, является недостаточным. Таким образом, в целях повышения уровня безопасности передаваемых сообщений и общего сохранения уровня производительности РСС было предпринято решение использовать два обязательных – основной и т.н. сесионный – и один опциональный – т.н. временный – слоя шифрования. Основная пара ключей шифрования была выработана в ходе этапа 4 и является обязательной парой, которая обеспечивает первый слой шифрования. Данная пара меняется только позапросу пользователя-владельца. Сессионная пара ключей шифрования будет также являться обязательной при передаче сообщений между пользователями. Она будет обеспечивать второй слой шифрования передаваемых сообщений. Предполагается, что данная пара будет актуальна в течение 24 часов и может быть перегенерирована по запросу пользователя-владельца. Временная пара ключей шифрования будет являться опциональной при передаче сообщений между пользователями. Она будет обес-печивать третий слой шифрования передаваемых сообщений. Предполагается, что данная пара будет актуальна в течение одного часа и может быть перегенерирована по запросу пользователя-владельца. В зависимости от своей политики безопасности пользователь может настроить смену сессионной и временной пар ключей менее чем через 24 и 1 час соответственно. Процедура выработки дополнительных пар ключей Подразумевается, что пользователь B после успешного выполнения процедуры регистрации захочет начать сеанс общения с пользователем A. B вырабатывает сессионную пару ключей, входными данными для которой является хеш-сумма, выработанная от хеш-сумм компонентов, сложенных с помощью операции сложения по модулю два: логин пользователя A, пароль пользователя B, открытые ключи пользователей A и B, текущие Дата и Время и «Соль», которая является криптостойким набором цифр. После выработки сессионной пары ключей шифрования B создает криптоконтейнер, в который он помещает открытый ключ своей сессионной пары шифрования, зашифрованный спомощью временных паролей и открытого ключа основной пары шифрования A. B отправляет этот криптоконтейнер A через сеть РСС. После получения этого криптоконтейнера A расшифровывает его и в результате получает открытый ключ сессионной пары шифрования B. В свою очередь, A вырабатывает свою сессионную пару ключей, входными данными для которой является хеш-сумма, выработанная от хеш-сумм компонентов, сложенных спомощью операции сложения по модулю два: логин пользователя B, пароль пользователя A, открытые ключи пользователей A и B, текущие Дата и Время и «Соль». A создает криптоконтейнер, в который он помещает открытый ключ своей сессионной пары шифрования, зашифрованный с помощью временных паролей и открытого ключа основной пары шифрования B. Пользователь A отправляет этот криптоконтейнер B через сеть РСС. B расшифровывает криптоконтейнер и получает открытый сессионный ключ A. С этого момента пользователи A и B могут использовать двойной слой шифрования, основанный на основной и сессионной парах ключей шифрования, при передаче сообщений друг другу. Процедура выработки опциональной – временной – пары ключей шифрования является абсолютно аналогичной процедуре выработки сессионной пары ключей, за исключением того, что в качестве входных данных для этой пары используется хеш-сумма, выработанная от хеш-сумм компонентов, сложенных с помощью операции сложения по модулю два, вслучае пользователя B: логин пользователя A, открытый ключ основной пары пользователя A, открытые ключи сессионных пар пользователя A и B, текущие Дата и Время и «Соль». В случае пользователя A набор компонентов аналогичен, за исключением того, что вместо хеш-сумм логина и открытого ключа основной пары пользователя A используются хеш-суммы логина и открытого ключа основной пары пользователя B. Стоит отметить, что в случае если пользователь B по каким-либо причинам не смог начать общение с пользователем A после регистрации, то временные пароли пользователей хранятся в зашифрованном виде в клиентах РСС пользователей до того момента, пока не будет выработана вторая пара ключей шифрования – сессионная. В случае если политика безопасности пользователей подразумевает тройной слой шифрования, один из временных паролей будет также использоваться до того момента, пока небудет выработана третья пара ключей шифрования – временная. Стоит также отметить, что для повышения уровня безопасности при многослойном шифровании можно использовать разные типы шифрования для каждого слоя. Это снизит производительность, но также позволит уменьшить риск взлома передаваемого между пользователями трафика в случае, если один из используемых криптографических протоколов будет уязвим к какогму-либо типу атак.
Рисунок 4. Выработка сессионной пары ключей шифрования. Пользователь B вырабатывает сессионную пару ключей, секретный и открытый. Секретный ключ B хранит у себя, открытый отправляет пользователю A в криптоконтейнере, состоящем из трех уровней шифрования: временные пароли A и B и открытый ключ основной пары ключей шифрования A. A расшифровывает криптоконтейнер, получает ключ и вырабатывает свою сессионную пару ключей шифрования. A сохраняет у себя секретный ключ, а открытый отправляет вкриптоконтейнере, зашифрованном с помощью временных паролей A и B и открытого ключа основной пары ключей шифрования B Процедура смены пар ключей после истечения срока их действия В процессе общения пользователей A и B периодически будет происходить генерация новой пары сессионных ключей. Для A такая пара будет иметь вид: секретный ключ СК_A_НОМЕР и открытый ключ ОК_A_НОМЕР. Соответственно, для B ключи будут иметь вид: секретный ключ СК_B_НОМЕР и открытый ключ ОК_B_НОМЕР. Значение компоненты НОМЕР будет выбираться случайно и станет представлять собой набор из пяти случайных цифр. Пар ключей такого вида может быть создано от пяти добесконечности. Пользователи могут настраивать эту опцию в зависимости от своей политики безопасности. Секретные ключи этих пар будут храниться во временной памяти клиента РСС. Открытые ключи после генерации будут пересылаться пользователю, для которого они сгенерированы. К примеру, A в процессе общения с B сгенерировал некоторое количество пар таких ключей. Секретные ключи он хранит во временной памяти своего клиента РСС, открытые ключи он пересылает B. B получает данные ключи и сохраняет их во временной памяти своего клиента РСС. В свою очередь, B сгенерировал некоторое количество пар и, соответственно, сохранил в своем клиенте секретные ключи и отправил A открытые ключи этих пар. Таким образом, у пользователей A и B накопилось некоторое количество пар секретных и открытых ключей. В случайный момент времени, независимо от времени истечения жизни актуальных ключей и количества полученных открытых ключей, клиенты пользователей A и B проводят полную ревизию хранилищ открытых ключей, выбирают случайный открытый ключ и пересылают его номер пользователю – владельцу секретного ключа. После отсылки клиенты ожидают получение подтверждения от клиента пользователя, которому был отправлен номер выбранного ключа. Клиент пользователя – владельца секретного ключа получает номер открытого ключа, проводит ревизию хранилища ключей, находит необходимый секретный ключ, помечает егодля использования, очищает хранилище от других сгенерированных секретных ключей и отправляет номер секретного ключа и временную метку, обозначающую то, с какого момента данный ключ начнет применяться, клиенту пользователя, который прислал ему номер открытого ключа. Клиент получает номер и временную метку, помечает открытый ключ, имеющий этот номер, для использования и очищает хранилище от других открытых ключей. Таким образом, клиенты пользователей A и B подготавливаются к процедуре «устаревания» актуальной пары ключей, которая используется для шифрования. В момент наступления времени, указанного во временной метке, устаревшая пара ключей заменяется на новую. Старая пара ключей уничтожается. Все пары и номера пользователи A и B отправляют в криптоконтейнерах, которые зашифрованы с помощью двух или трех уровней шифрования (в зависимости от настроек ихполитик безопасности) – основной, сессионной и временной пар ключей шифрования соответственно. В случае если клиент будет выгружен из памяти, действующие секретные и открытые ключи должны будут храниться в служебных данных клиентов пользователей взашифрованном виде в служебных данных пользователей. Ключи, которые были выработаны для «обновления» и не были задействованы до момента выгрузки клиента из памяти, будут удалены. Данную процедуру предполагается использовать для смены сессионной и временной пар ключей пользователей.
Рисунок 5. Периодическая смена ключей. Пользователи A и B вырабатывают секретные и открытые ключи, имеющие вид: СК_A_НОМЕР, ОК_A_НОМЕР и СК_B_НОМЕР, ОК_B_НОМЕР. Секретные ключи хранятся у них в хранилищах секретных ключей их клиентов РСС, а открытые ключи они пересылают друг другу и хранят в хранилищах открытых ключей Ограничения и особенности работы метода Стоит отметить, что процедура описывает способ защищенной аутентификации между пользователем и приглашаемым, но он не предусматривает защиты от угроз отзлоумышленного обеспечения, имеющего возможность перехвата данных на уровне пользователя, такого как контроль за тем, что пользователь вводит с клавиатуры, взаимодействие с операционной системой и другое. Также следует отметить, что логин любого пользователя является уникальной переменной, которая не может быть изменена в течение жизненного цикла пользователя и не должна дублироваться. Инвайт, который вырабатывает пользователь A для пользователя B, имеет максимальный срок действия, равный одному месяцу. Предполагается, что пользователь A может привыработке настраивать срок действия инвайта в указанных пределах. Это необходимо для того, чтобы пользователь C не смог воспользоваться инвайтом для регистрации в РСС через пользователя A. По истечении срока жизни инвайта клиент пользователя A перестанет принимать сообщения, зашифрованные с помощью хеш-суммы, выработанной отинвайта. Также стоит отметить, что после процесса регистрации B клиент пользователя A перестает принимать сообщения, зашифрованные с помощью хеш-суммы, выработанной отинвайта. Все данные, отправляемые клиентами РСС, передаются с помощью протокола Distributed Hash-Table (DHT) через сети общего доступа, такие как сеть глобального обмена информацией Интернет. Стоит отметить, что метод может работать и с DHT-подобными протоколами, при условии соответствующей модификации под конкретный протокол. В данном конкретном случае описана процедура, которая подразумевает, что хеш-таблица DHT будет состоять из записей вида: DHT-адрес – Логин пользователя. В то же время Логин пользователя в случае необходимости модификации под конкретную РСС может быть заменен на любую компоненту, которая должна быть уникальной и может быть найдена по DHT-адресу в РСС. Следует отметить, что на момент начала процедуры регистрации пользователь A, который является приглашающим, должен быть доступен в РСС. Следует также отметить, что перед выполнением процедуры приглашения пользователю A рекомендуется обновить свой дистрибутив клиента РСС до последней официальной стабильной версии. Заключение В результате разработки процедуры был получен метод, состоящий из процедур, позволяющих пользователям проводить регистрацию нового пользователя, который обеспечивает повышенный уровень безопасности и в то же время может быть применим практически к любым РСС, работающим на основе протокола DHT или DHT-подобных протоколов. Стоит отметить, что при описании метода не учитывается, что пользователь A, приглашающий пользователя B, может стать злонамеренным. Эти и другие вопросы планируется описать в дальнейших работах. Следует также отметить, что хотя метод обладает определенными недостатками, такими как необходимость личной встречи пользователей, использование нескольких уровней шифрования, это позволяет повысить общий уровень безопасности метода по сравнению с «классическим» методом регистрации, основанным на регистрации нового пользователя через свою электронную почту.
Ключевые слова: распределенные социальные сети, РСС, регистрация, социальные сети, периодическая смена пар ключей, многослойное шифрование. New user registration method for Distrubuted Social Network Bogoraz A.G., Department of Information Technologies Security, Institute of Computer Technologies and Information Security, Southern Federal University, Rostov Region, Taganrog, bogoraz.a.g@gmail.com Abstract: The purpose of this work is to develop a method for registering a new user in the Distributed Social Network, providing an increased level of security. The article also describes the limitations associated with the work of the method, as well as users who participate in the process of registering a new user. The following procedures are described: secure exchange of variables, registration, including generation of a new user's key pair, generation of additional key pairs that implement multi-layer encryption and periodicall change of these keys. Keywords: Distributed Social Network, DSN, invitation, registration, social network, periodical pair regeneration, multi-layer encryption. |
БОГОРАЗ А.Г., кафедра безопасности информационных технологий, Институт компьютерных технологий и информационной безопасности, Южный федеральный университет, Ростовская область, г. Таганрог, 
Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
