Безопасное сетевое взаимодействие (часть 1)

Аутентификационный протокол версии 4

Хотя рассмотренный сценарий усиливает безопасность по сравнению с первым сценарием, остаются еще две проблемы. Первая проблема состоит в том, что время жизни связано с билетом, гарантирующем билет. Если это время жизни очень короткое (т.е. минуты), то пароль у пользователя будет запрашиваться повторно. Если время жизни большое (т.е. часы), то оппонент имеет больше возможностей для совершения различных replay-атак. Злоумышленник должен просматривать сеть и перехватить билет, гарантирующий билет, и затем ждать, когда законный пользователь выйдет. Затем оппонент может подделать сетевой адрес законного пользователя и послать сообщение шага (3) к TGS . Это откроет ему неограниченный доступ к ресурсам и файлам законного пользователя.

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

Таким образом, можно сформулировать следующее дополнительное требование. Сетевой сервис (т.е. TGS или прикладной сервис) должны иметь возможность убедиться в том, что билет использует тот, кто получил его.

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

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

Рассмотрим технологию распределения ключа сессии.

       Обмен с аутентификационным сервисом для получения билета, гарантирующего билет

1. C -> AS: ID_C, ID_tgs, TS₁ - клиентский модуль запрашивает билет, гарантирующий билет

   ID_C: идентификатор пользователя.

   ID_tgs: идентификатор TGS .

   TS₁: отметка времени, позволяет AS проверить, синхронизированы ли часы клиента с часами AS .

2. AS -> C: E_Kc [K_{C, tgs}, ID_tgs, TS₂, LТ₂, Ticket_tgs ] - AS возвращает билет, гарантирующий билет

   Ticket_tgs = E_Kas,tgs [K_C,tgs, ID_C, AD_C, ID_tgs, TS₂, LТ₂ ]

   Ticket_tgs: билет, используемый клиентом для доступа к TGS .

   K_c: ключ шифрования, основанный на пользовательском пароле, применение которого позволяет AS и клиентскому модулю аутентифицировать пользователя и защитить содержимое сообщения (2).

   К_{C, tgs}: ключ сессии, созданный AS для обеспечения безопасного обмена между клиентским модулем и TGS .

   K_as,tgs: ключ, которым зашифрован билет и который известен только AS и TGS .

   ID_tgs: подтверждение того, что данный билет предназначен для TGS .

   AD_C: адрес пользователя, предотвращает использование билета с любой рабочей станции, кроме той, с которой он был первоначально получен.

   TS₂: время создания билета.

   LТ₂: время жизни билета.

   Обмен с сервисом, гарантирующим билет, для получения билета, гарантирующего сервис

3. C -> TGS: ID_S, Ticket_tgs, Authenticator_C - клиентский модуль запрашивает билет, гарантирующий сервис

   ID_S: идентификатор сервера S.

   Ticket_tgs: гарантирует TGS , что данный пользователь аутентифицирован AS .

   Authenticator_c: создается клиентом для подтверждения законности ключа.

   Authenticator_C = E_Kc,tgs [ID_C, AD_C, TS₃ ]

   TS₃: время создания аутентификатора.

4. TGS -> C: E_Kс,tgs [K_{C, S}, ID_S, TS₄, LT₄, Ticket_S ] - TGS возвращает билет, гарантирующий сервис

   Ticket_S = E_Ktgs,s [K_C,S, ID_C, AD_C, ID_S, TS₄, LТ₄]

   Ticket_S: билет, используемый клиентом для доступа к серверу S.

   К_tgs,s: ключ, разделяемый S и TGS .

   К_C,S: ключ сессии, который создается TGS для обеспечения безопасного обмена между клиентским модулем и сервером без необходимости разделения ими постоянного ключа.

   ID_S: доказательство того, что этот ключ предназначен для сервера S.

   TS₄: время создания билета.

   LТ₄: время жизни билета.

   Клиент/серверный аутентификационный обмен для получения сервиса

5. C -> S: Ticket_S, Authenticator_C - клиент запрашивает сервис

   Ticket_S = E_Ktgs,s [K_{C, S}, ID_C, AD_C, ID_S, TS₄, LТ₄ ]

   Authenticator_C = E_Kc [ID_C, AD_C, TS₅ ]

   Ticket_S: гарантирует серверу, что данный клиент аутентифицирован AS .

   Authenticator_c: создается клиентом для подтверждения законности ключа.

   TS₅: время создания аутентификатора.

6. S -> C: E_Kc [TS₅ + 1] - дополнительная аутентификация сервера для клиента

   TS₅ + 1: гарантирует С, что не было replay-атак.

Прежде всего, клиентский модуль посылает сообщение к AS с требованием доступа к TGS . AS отвечает сообщением, зашифрованным ключом, полученным из пароля пользователя, который содержит билет. Зашифрованное сообщение также содержит ключ сессии К_C,tgs, где индексы определяют, что это ключ сессии между С и TGS . Таким образом, ключ сессии безопасно передан как С, так и TGS .

К первой фазе сценария добавлено несколько дополнительных элементов информации. Сообщение (1) включает отметку времени, так что AS знает, что сообщение своевременно. Сообщение (2) включает несколько элементов билета в форме, доступной С. Это необходимо С для подтверждения того, что данный билет предназначен для TGS и для определения момента истечения срока его действия.

Теперь, имея билет и ключ сессии, С может обратиться к TGS . Как и раньше, С посылает TGS сообщение, которое включает билет и идентификатор требуемого сервиса (сообщение (3)). Дополнительно С передает аутентификатор, который включает идентификатор и адрес пользователя С, а также отметку времени. В отличие от билета, который является переиспользуемым, аутентификатор применяется только один раз и не имеет времени жизни ( LT ). Теперь TGS расшифровывает билет с помощью ключа, который он разделяет с AS . Этот билет содержит ключ сессии К_С,tgs. В действительности билет устанавливает, что любой, кто использует К_С,tgs, должен быть С. TGS задействует ключ сессии для дешифрования аутентификатора. TGS может затем сравнить имя и адрес из аутентификатора с тем, которое содержится в билете, и с сетевым адресом входящего сообщения. Если все совпадает, то TGS может быть уверен, что отправитель билета является настоящим его собственником. В действительности аутентификатор устанавливает, что до времени TS₃ возможно использование K_С,tgs. Заметим, что билет не доказывает чью-либо идентичность, а является способом безопасного распределения ключей. Аутентификатор является доказательством идентификации клиента. Так как аутентификатор может быть использован только один раз, опасности, что оппонент украдет аутентификатор для пересылки его позднее, не существует.

Сообщение (4) от TGS имеет вид сообщения (2). Сообщение зашифровано ключом сообщения, разделяемым TGS и С, и включает ключ сессии, который разделяется С и сервером S, идентификатор S и отметку времени билета. Билет включает тот же самый ключ сессии.

С теперь имеет переиспользуемый билет, гарантирующий сервис S. Когда С представляет этот билет, как и в сообщении (5), он также посылает аутентификатор. Сервер может расшифровать билет, получить ключ сессии и расшифровать аутентификатор.

Если требуется взаимная аутентификация, сервер посылает сообщение (6), в котором возвращает значение отметки времени из аутентификатора, увеличенное на единицу и зашифрованное ключом сессии. С может расшифровать это сообщение для получения увеличенной отметки времени. Так как сообщение может быть расшифровано ключом сессии, С уверен, что оно может быть создано только S. Это гарантирует С, что replay-атаки не было.

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