Телефон: 8-800-350-22-65
WhatsApp: 8-800-350-22-65
Telegram: sibac
Прием заявок круглосуточно
График работы офиса: с 9.00 до 18.00 Нск (5.00 - 14.00 Мск)

Статья опубликована в рамках: XXXII Международной научно-практической конференции «Научное сообщество студентов XXI столетия. ТЕХНИЧЕСКИЕ НАУКИ» (Россия, г. Новосибирск, 26 мая 2015 г.)

Наука: Информационные технологии

Скачать книгу(-и): Сборник статей конференции

Библиографическое описание:
Дубман С.Э. РАЗРАБОТКА АЛГОРИТМА ПРОТОКОЛА АУТЕНТИФИКАЦИИ В КЛИЕНТ-СЕРВЕРНОЙ МОДЕЛИ // Научное сообщество студентов XXI столетия. ТЕХНИЧЕСКИЕ НАУКИ: сб. ст. по мат. XXXII междунар. студ. науч.-практ. конф. № 5(31). URL: http://sibac.info/archive/technic/5(31).pdf (дата обращения: 29.03.2024)
Проголосовать за статью
Конференция завершена
Эта статья набрала 0 голосов
Дипломы участников
У данной статьи нет
дипломов

РАЗРАБОТКА  АЛГОРИТМА  ПРОТОКОЛА  АУТЕНТИФИКАЦИИ  В  КЛИЕНТ-СЕРВЕРНОЙ  МОДЕЛИ

Дубман  Станислав  Эдуардович

магистрант  2  курса,  кафедра  «ИБ»,  НИУ  «МИЭТ»,  РФ,  г.  Зелеленоград

Е-mail:  feyde 87@gmail.com

Смык  Сергей  Владимирович

научный  руководитель,  канд.  техн.  наук,  доцент,  Научно-исследовательский  университет  «МИЭТ»,  РФ,  г.  Зелеленоград

 

Целью  работы  является  разработка  алгоритма  протокола  аутентификации  на  базе  криптоалгоритмов  RSA  и  Диффи-Хэллмана,  позволяющего  без  установки  дополнительного  программного  обеспечения  на  клиентской  рабочей  станции  безопасно  передавать  информацию,  требующую  защиты.

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

Для  решения  проблемы  обмена  данными  были  разработаны  различные  протоколы,  например  протокол  взаимоблокировки  (рисунок  1)  Основная  идея  которого  заключается  в  том,  что  при  передаче  данных  по  незащищенной  сети  сообщения  делятся  на  две  части,  каждая  из  которых  в  отдельности  бесполезна.  Сам  протокол  можно  записать  в  следующем  виде  [1]:

1.  первый  участник  протокола  (далее  Алиса)  отправляет  второму  участнику  (далее  Боб)  свой  открытый  ключ;

2.  Боб  отправляет  Алисе  свой  открытый  ключ;  Алиса  шифрует  свое  сообщение  с  помощью  открытого  ключа  Боба.

3.  Половину  зашифрованного  сообщения  она  отсылает  Бобу;

4.  Боб  шифрует  свое  сообщение  с  помощью  открытого  ключа  Алисы.  Половину  зашифрованного  сообщения  он  отсылает  Алисе;

5.  Алиса  отправляет  оставшуюся  половину  зашифрованного  сообщения;

6.  Боб  складывает  обе  половины  сообщений  Алисы  и  расшифровывает  его  своим  закрытым  ключом.  Затем  Боб  посылает  Алисе  оставшуюся  половину  своего  шифрованного  сообщения;

7.  Алиса  складывает  обе  половины  сообщений  Боба  и  расшифровывает  его  своим  закрытым  ключом.

 

Рисунок  1.  Протокол  взаимоблокировки

 

Данный  протокол  помогает  предотвратить  атаку  «человека  посередине»  при  передаче  сообщений,  но  не  удобен  при  практической  реализации,  так  как  приходится  передавать  сообщения  не  целиком,  а  по  частям,  в  связи  с  чем  возникают  дополнительные  «расходы»  на  передаваемый  трафик.

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

1)  сервер  генерирует  случайное  число  R_B,  вычисляет  хэш-функцию: 

 

P   =  H(H  (логин,  пароль),  R_B)                     (1)

 

и  отправляет  половину  значения  P;

2)  клиент  генерирует  случайное  число  R_A,  вычисляет  хэш-функцию: 

 

N   =  H(H  (логин,  пароль),  R_A)                     (2)

 

и  так  же  отправляет  половину  значения  N

3)  сервер  получив  «первую  половину  значения»  N  отправляет  «вторую  часть»  P  и  R_B  клиенту;

4)  клиент  вычисляет: 

 

P ’  =  H(H(логин,  пароль),  R_B)                      (3)

 

сравнивает  P  и  P,  если  равенство  P  =  P  выполняется,  то  посылается  серверу  «вторая  часть»  N  и  R_A;

5)  сервер  вычисляет  значение: 

 

N ’  =  H(H  (логин,  пароль),  R_A)                    (4)

 

а  так  же  сравнивает  получившееся  значение  и  N.  В  случае  верного  равенства,  считаем  аутентификацию  пройденной.

Данная  схема  (рисунок  2)  позволяет,  подтвердить  взаимную  подлинность  участников  протокола.  Для  возможности  установки  защищенного  канала  связи  необходимо  передать  сеансовые  ключи.  Для  этого  необходимо  включить  в  вычисление  хэш-функции,  происходящее  на  первом  и  втором  шаге,  открытые  ключи  сервера  и  клиента  соответственно  [2].  После  чего  устанавливаем  сеансовый  ключ,  который  будет  использован  для  шифрования  передаваемых  данных.  Для  увеличения  надежности  протокола,  можно  предоставить  пользователю  выбор  криптоалгоритма,  поддерживаемого  сервером. 

Таким  образом,  одновременно  проходит  аутентификация  клиента  и  сервера,  а  так  же  устанавливаются  сеансовые  ключи. 

 

Рисунок  2.  Алгоритм  аутентификации  пользователя

 

В  таком  виде  протокол  не  будет  подвержен  пассивным  атакам  в  виду  того,  что  информация  не  передается  в  открытом  виде  по  каналу  связи.  Однако,  учитывая  возможность  того,  что  злоумышленник  может  использовать  данные  предыдущих  сеансов,  нельзя  быть  полностью  уверенным  в  невозможности  реализации  атаки  «человек  посередине».  Для  устранения  данной  уязвимости  предлагается  проведение  между  клиентом  и  сервером  синхронизации  по  времени,  а  так  же  установка  «метки  времени».  Протокол  предполагает,  что  пользователь  уже  зарегистрирован  на  сервере.

Для  предоставления  регистрационных  данных  серверу,  возможно,  использовать  следующий  алгоритм  (рисунок  3):

1)  сервер  (далее  В)  генерирует  случайное  число  R_B,  вычисляет: 

 

P  =  H (OKB,  Ser,  R_B),                                     (5)

 

делит  Р  на  две  части  и  отправляет  «первую  половину»  Р  клиенту,  где  H  это  функция  хеширования,  ОКВ  открытый  ключ  ВSet  сертификат  сервера;

2)         клиент  генерирует  R_A,  вычисляет: 

 

N  =  H (login,  password,  R_A,  1/2P),                         (6)

 

так  же  делит  полученное  N  на  две  половины  и  отправляет  «первую  половину»  N  серверу;

3)  B  отправляет  клиенту  «вторую  часть»  PR_BSerOKB; 

4)  А  проверяет  равенство  Р  =  Р‘,  где 

 

P’  =  H (OKBSerR_B),                                    (7)

 

шифрует  с  помощью  ОКВ  и  ассиметричного  алгоритм  следующие  данные  EB(loginpasswordR_AP),  далее  вычисленное  значение  отправляет  серверу,  где  EB  —  функция  шифрования  с  помощью  открытого  ключа  В;

5)  сервер,  используя  свой  закрытый  ключ,  расшифровывает  сообщение  клиента.  Если  значения  P  и  P  совпадают,  то  записываем  регистрационные  данные  в  базу  данных,  если  нет,  то  пробуем  еще  n  раз. 

 

Рисунок  3.  Алгоритм  передачи  регистрационных  данных

 

Достоверность  в  данном  протоколе,  подтверждает  только  сервер.  Для  клиент-серверных  систем  эта  особенность  считается  оправданной,  однако  может  негативно  повлиять  на  защищенность  используемых  схем. 

При  организации  передачи  данных,  можно  использовать  протокол  Диффи-Хэллмана  для  генерации  сеансового  ключа  и  передачи  информации.  В  результате  получим  следующий  алгоритм:

1)  сервер  генерирует  случайное  число  R_B,  вычисляет 

 

P  =  H (DH_BSer,  R_B),                                  (8)

 

где  H  это  функция  хеширования,  ОКВ  открытый  ключ  ВSet  сертификат  сервера. 

Сервер  делит  Р  на  две  части  и  отправляет  «первую  половину»  Р  клиенту;

2)  клиент  генерирует  R_A,  вычисляет 

 

N  =  H (H(login),  DH_A,  R_A,  1/2P),                         (9)

 

так  же  делит  полученное  N  на  две  половины  и  отправляет  «первую  половину»N  серверу;

3)  B  отправляет  клиенту  «вторую  часть»  PR_BSerDH_B; 

4)  А  проверяет  равенство  Р  =  Р‘,  где 

 

P’  =  H (DH_BSerR_B),                                 (10)

 

если  равенство  верное,  то  отправляется  «вторая  половина»  NH(login),  R_A,  DH_A;

5)  сервер  вычисляет 

 

N'  =  H (H(login),  R_A,  DH_A,  1/2P);                        (11)

 

6)  на  основе  сеансового  ключа,  полученного  с  помощью  алгоритма  Диффи-Хэлмана,  устанавливаем  защищенный  канал  связи  и  передаем  регистрационную  информацию;

7)  сервер  проверяет  верность  равенства  H(login)=H(login').  Если  оно  верно,  то  считаем  регистрационные  данные  верными  и  при  необходимости  продолжаем  передачу  данных.

К  недостаткам,  данного  алгоритма  можно  отнести  следующие  моменты:

1.  в  протоколе  узкой  частью  является  знание  таких  данных  как  логин  и  пароль  пользователя.  Если  злоумышленнику  станут  известны  эти  значения,  он  сможет  выдавать  себя  за  регистрированного  пользователя;

2.  пользователю  необходимо  каждый  раз  при  аутентификации,  генерировать  пару  ключи  шифрования.

Приведенная  схема  аутентификации  была  разработана  специально  для  клиент-серверной  модели,  где  предполагалось  взаимное  доверие  между  его  участниками. 

Данная  схема  позволяет  без  установки  дополнительного  программного  обеспечения  на  клиентской  рабочей  станции  безопасно  передавать  информацию,  требующую  защиты,  в  тот  момент,  когда  это  требуется,  при  этом  проводится  проверку  аутентичности. 

 

Список  литературы:

1.Смит  Р.Э.,  Аутентификация:  от  паролей  до  открытых  ключей:  пер.  с  англ.  М.:  Издательский  дом  «Вильямс»,  2002.  —  432  с.

2.Шнайер  Б.,  Прикладная  криптография.  Протоколы,  алгоритмы,  исходные  тексты  на  языке  Си:  Пер.  с  англ.  М.:  Триумф,  2003.  —  816  с.

Проголосовать за статью
Конференция завершена
Эта статья набрала 0 голосов
Дипломы участников
У данной статьи нет
дипломов

Оставить комментарий

Форма обратной связи о взаимодействии с сайтом
CAPTCHA
Этот вопрос задается для того, чтобы выяснить, являетесь ли Вы человеком или представляете из себя автоматическую спам-рассылку.