АссистентНовый вопросИсторияОбласти знаний
Партнёрские проектыСпецпроектыСтать автором
Сменить язык
О РУВИКИ
ТехнологииИнфраструктура и безопасностьДоступ, приватность и защита данныхВзаимная аутентификация

Взаимная аутентификация

Экспертиза РАН

Logo-ran-black.png
Проведена экспертиза
Российской академией наук
Подробнее
Aprove.svg

Экспертиза РАН

Arrow-Right.png
Logo-ran.png
Проведена экспертиза
Российской академией наук
Подробнее

Взаимная аутентификация — процесс, при котором две стороны аутентифицируют друг друга одновременно в рамках протокола аутентификации. В некоторых протоколах (например, IKE, SSH) взаимная аутентификация является режимом по умолчанию, в других (например, TLS) — опциональным.

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

Взаимная аутентификация часто используется в интернете вещей (IoT). Разработка эффективных схем безопасности для IoT-систем — сложная задача, особенно если требуется лёгкость и низкие вычислительные затраты. Взаимная аутентификация — важный этап обеспечения безопасности, способный защитить систему от множества атак[3], последствия которых могут быть критическими для IoT-систем (например, серверов электронного здравоохранения) в случае их взлома. Анализы ряда схем передачи данных показали, что отсутствие взаимной аутентификации рассматривается как слабое место[4].

Этапы процесса и верификация

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

  1. Алиса отправляет Бобу сообщение, зашифрованное открытым ключом Боба, чтобы доказать, что она является действительным пользователем.
  2. Боб проверяет сообщение:
    1. Боб сверяет формат и метку времени. Если что-либо неправильно, сессия прерывается.
    2. Сообщение расшифровывается с помощью секретного ключа Боба, что позволяет получить идентификатор Алисы.
      1. Боб проверяет, соответствует ли сообщение действительному пользователю. При несовпадении сессия прерывается.
  3. Боб отправляет Алисе ответ, зашифрованный её публичным ключом, чтобы подтвердить свою подлинность.
  4. Алиса сверяет полученное сообщение:
    1. Алиса анализирует формат и метку времени. В случае несоответствия сессия завершается.
    2. Сообщение расшифровывается секретным ключом Алисы, в результате получается идентификатор Боба.
      1. Алиса проверяет, соответствует ли отправитель допустимому пользователю. При ошибке сессия прерывается.
  5. После этих этапов обе стороны идентифицированы и могут безопасно продолжать общение. Далее Алиса и Боб создают общий секретный ключ для дальнейшей защищённой коммуникации.

Для подтверждения успешного прохождения взаимной аутентификации часто применяют логику Бэрроуза—Абади—Нидема (BAN-логика), которая доказывает, что сообщение получено от надёжного источника. BAN-логика исходит из предположения о недоверии к субъекту, и затем проверяет его легитимность[1].[2][5][6]

Защита от атак

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

Атака «человек посередине»
Такая атака происходит, когда третье лицо стремится перехватить или подслушивать сообщения, иногда изменяя их для адресата. Если стороны обмениваются сообщениями без проверки отправителя, злоумышленник может внедриться в коммуникацию незаметно. Взаимная аутентификация предотвращает этот тип атак, так как стороны верифицируют друг друга перед обменом ключами или сообщениями: при несовпадении идентичности сессия завершается[7].
Атака повтором
Атака повтором похожа на MITM-атаку, но основана на воспроизведении старых сообщений вне контекста для обмана сервера. В противостоянии подобным схемам важную роль играют временные метки в протоколе.[8][9][10] При превышении максимально допустимой задержки по времени сессия прерывается[10]. Для отслеживания времени отправки сообщений также могут использоваться случайно сгенерированные числа[9].
Спуфинг-атака
Спуфинг опирается на подделку данных для получения доступа к серверу или к выдаче себя за другое лицо. Сервер проверяет пользователя и выдаёт сессионный ключ только при успешной взаимной аутентификации[10].
Имитационная атака
В данном случае злоумышленник выдаёт себя за другого пользователя с целью несанкционированного доступа к системе[11]. Взаимная аутентификация предполагает обмен сертификатами, которые позволяют верифицировать источник, и атакующий не сможет подменить пользователя из-за отсутствия нужного ключа[5].

Взаимная аутентификация также обеспечивает целостность информации: если отправители проверены, полученные данные считаются надёжными[5].

mTLS

По умолчанию протокол TLS удостоверяет сервер для клиента с помощью X.509-сертификатов, а аутентификация клиента возлагается на уровень приложения. TLS допускает аутентификацию клиента с помощью X.509-сертификата с клиентской стороны[12], однако такой подход требует предварительного распространения сертификатов среди клиентов и менее удобен для конечных пользователей.

Взаимная аутентификация TLS (mTLS) чаще применяется во взаимодействии B2B (business-to-business), где ограниченное число однородных программных клиентов подключается к определённым веб-службам; здесь операция сертификации проще, а требования к безопасности обычно выше, чем в пользовательских сценариях.

mTLS также используют в приложениях на основе микросервисов и сред исполнения, например, Dapr и путем применения таких систем, как SPIFFE[13].

Лёгковесные схемы и защищённые схемы

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

Поэтому во многих схемах взаимной аутентификации требуется обеспечение низкого памятного следа, чтобы соответствовать возможностям устройств с большими объёмами данных[3]. Сейчас широкое распространение получило облачные вычисления, но даже они иногда не позволяют избежать задержек из-за работы с большими объёмами информации. Применение edge-вычислений позволяет обрабатывать данные ближе к пользователю, сохраняя скорость. Лёгковесность может достигаться за счёт ограничения числа битов при коммуникации[3].

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

В ряде случаев приходится жертвовать временем выполнения или затратами памяти для приоритета защиты конфиденциальности информации[2][10].

Схемы на основе паролей

Во взаимной аутентификации с использованием паролей, выбранных пользователем, увеличивается уязвимость к взлому (так как пароль создаёт человек, а не компьютер). Использование только сгенерированных системой паролей повышает безопасность, но усложняет использование. Возможность выбора и смены пароля делают приложение более удобным для пользователя[15]. поэтому современные решения стараются это учитывать. Исследователи отмечают, что протокол, использующий пароли совместно с взаимной аутентификацией, также защищает идентичность пользователя: сообщения доступны только участвующим сторонам[16].

К недостаткам следует отнести то, что таблицы паролей могут занимать значительный объём памяти[15]. Одним из решений является использование одноразовых паролей (OTP), которые отправляются пользователю по SMS или email. OTP действуют ограниченное время и не требуют долговременного хранения.

Многофакторная аутентификация

В последние годы для повышения уровня безопасности стали использовать схемы с двумя и более факторами. Парольная аутентификация — «однофакторная», в то время как смарт-карта (двухфакторная)[15] и биометрическая (трёхфакторная) схемы становятся всё популярнее. Смарт-карты проще реализовать, но подвержены риску компрометации[15]. Биометрия востребована из-за сложности атаки на ключ сессии[6]. однако шумные данные сложно шифровать. Несмотря на дополнительные факторы, взаимная аутентификация необходима на всех этапах[6].

Схемы на основе сертификатов и практические приложения

Взаимная аутентификация широко применяется в схемах для интернета вещей, где физические объекты получают доступ к IP-сетям[9]. Схемы аутентификации могут применяться к самым разным системам передачи данных[14]. По мере роста числа пользователей и устройств в интернете эффективная организация защищённых протоколов становится всё сложнее. Вместо паролей устройства используют сертификаты для идентификации.

Радиосети

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

RFID-метки широко используются для отслеживания объектов, в том числе на складах[18]. Такой подход ускоряет инвентаризацию, но при передаче данных с RFID-меток на облачный сервер возникает дополнительный риск безопасности[18]. Для защиты данных применяются трёхсторонние схемы, где участвуют RFID-метка, считыватель и облако[18].

Также предложен вариант схемы на RFID с привязкой определённых считывателей к конкретным меткам для повышения безопасности и снижения памяти[19]. В такой архитектуре при взломе отдельного считывателя скомпрометирована будет только часть системы, а обмен происходит по приватному ключу.

Системы удалённого мониторинга состояния пациентов (например, по беспроводной персональной сети — WBAN) также строят аутентификацию между пациентом, медицинским провайдером и доверенной третьей стороной[10]. Это снижает нагрузку на персонал и сохраняет неприкосновенность данных, хотя основная сложность — защищённая передача по открытым каналам.[7].

Облачные вычисления

Облако в здравоохранении применяется для хранения удалённых данных пациентов[2] Такие облачные сервисы, включая телемедицинские информационные системы (TMIS), основаны на схемах с взаимной аутентификацией.[14] Для анонимизации, повышения безопасности используют подходы на основе блокчейна, позволяющие аутентифицировать пользователя через главную ноду и сохранять анонимность.[20].

Fog/cloud-компьютинг позволяет обрабатывать большие потоки информации, хотя имеет ограничения по памяти и производительности[21]. Вычисления на мобильных границах (MEC) считаются облегчённой версией fog-вычислений[21], особенно востребованной для сервисов с большим радиусом действия, например, с использованием 5G. Пример — смарт-часы, которые способны автоматически связываться с медицинской организацией при ухудшении показателей пациента[5]

Применение fog-вычислений встречается и в автомобилях: верификация технических узлов гарантирует безопасность передачи информации и защищает системы от взлома.[8].

Машинная аутентификация

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

Примечания

  1. ↑ 1 2 Chen, Yulei; Chen, Jianhua (2020). “A secure three-factor-based authentication with key agreement protocol for e-Health clouds”. The Journal of Supercomputing [англ.]. 77 (4): 3359—3380. DOI:10.1007/s11227-020-03395-8. ISSN 0920-8542. S2CID 221146362. Дата обращения 2024-06-26. |access-date= требует |url= (справка)
  2. ↑ 1 2 3 4 5 6 7 8 Chen, Liquan; Qian, Sijie; Lim, Ming; Wang, Shihui (2018). “An enhanced direct anonymous attestation scheme with mutual authentication for network-connected UAV communication systems”. China Communications [англ.]. 15 (5): 61—76. DOI:10.1109/CC.2018.8387987. S2CID 49333360. Дата обращения 2024-06-26. |access-date= требует |url= (справка)
  3. ↑ 1 2 3 Jan, Mian Ahmad; Khan, Fazlullah; Alam, Muhammad; Usman, Muhammad (2019). “A payload-based mutual authentication scheme for Internet of Things”. Future Generation Computer Systems [англ.]. 92: 1028—1039. DOI:10.1016/j.future.2017.08.035. HDL:10453/117906. S2CID 57380203. Дата обращения 2024-06-26. |access-date= требует |url= (справка)
  4. ↑ Amin, Ruhul; Islam, SK Hafizul; Vijayakumar, Pandi; Khan, Muhammad Khurram; Chang, Victor (2018). “A robust and efficient bilinear pairing based mutual authentication and session key verification over insecure communication”. Multimedia Tools and Applications [англ.]. 77 (9): 11041—11066. DOI:10.1007/s11042-017-4996-z. S2CID 13674284. Дата обращения 2024-06-26. |access-date= требует |url= (справка)
  5. ↑ 1 2 3 4 Chen, Chin-Ling; Chiang, Mao-Lun; Hsieh, Hui-Ching; Liu, Ching-Cheng; Deng, Yong-Yuan (2020). “A Lightweight Mutual Authentication with Wearable Device in Location-Based Mobile Edge Computing”. Wireless Personal Communications [англ.]. 113: 575—598. DOI:10.1007/s11277-020-07240-2. S2CID 218934756. Дата обращения 2024-06-26. |access-date= требует |url= (справка)
  6. ↑ 1 2 3 Sahoo, Shreeya Swagatika; Mohanty, Sujata; Majhi, Banshidhar (2020). “Improved Biometric-Based Mutual Authentication and Key Agreement Scheme Using ECC”. Wireless Personal Communications [англ.]. 111 (2): 991—1017. DOI:10.1007/s11277-019-06897-8. S2CID 208125038. Дата обращения 2024-06-26. |access-date= требует |url= (справка)
  7. ↑ 1 2 Sasikaladevi, N.; Malathi, D. (2019). “Energy Efficient Lightweight Mutual Authentication Protocol (REAP) for MBAN Based on Genus-2 Hyper-Elliptic Curve”. Wireless Personal Communications [англ.]. 109 (4): 2471—2488. DOI:10.1007/s11277-019-06693-4. S2CID 204084523. Дата обращения 2024-06-26. |access-date= требует |url= (справка)
  8. ↑ 1 2 3 Dewanta, Favian; Mambo, Masahiro (2019). “A Mutual Authentication Scheme for Secure Fog Computing Service Handover in Vehicular Network Environment”. IEEE Access [англ.]. 7: 103095—103114. Bibcode:2019IEEEA...7j3095D. DOI:10.1109/ACCESS.2019.2931217. S2CID 199509951. Дата обращения 2024-06-26. |access-date= требует |url= (справка)
  9. ↑ 1 2 3 Melki, Reem; Noura, Hassan N.; Chehab, Ali (2020). “Lightweight multi-factor mutual authentication protocol for IoT devices”. International Journal of Information Security [англ.]. 19 (6): 679—694. DOI:10.1007/s10207-019-00484-5. S2CID 209340123. Дата обращения 2024-06-26. |access-date= требует |url= (справка)
  10. ↑ 1 2 3 4 5 6 Narwal, Bhawna; Mohapatra, Amar Kumar (2020). “SEEMAKA: Secured Energy-Efficient Mutual Authentication and Key Agreement Scheme for Wireless Body Area Networks”. Wireless Personal Communications [англ.]. 113 (4): 1985—2008. DOI:10.1007/s11277-020-07304-3. S2CID 216529906. Дата обращения 2024-06-26. |access-date= требует |url= (справка)
  11. ↑ HCI for Cybersecurity, Privacy and Trust : [англ.]. — 2021. — Vol. 12788. — ISBN 978-3-030-77391-5. — doi:10.1007/978-3-030-77392-2.
  12. ↑ Dierks, Tim (Август 2008). “The Transport Layer Security (TLS) Protocol Version 1.2”. tools.ietf.org [англ.]. Архивировано из оригинала 2017-12-24. Дата обращения 2024-06-26. Используется устаревший параметр |url-status= (справка)
  13. ↑ Mutual TLS: Securing Microservices in Service Mesh (англ.). The New Stack (1 февраля 2021). Дата обращения: 26 июня 2024. Архивировано 13 марта 2021 года.
  14. ↑ 1 2 3 4 g. Lopes, Ana Paula; Gondim, Paulo R. L. (2020). “Mutual Authentication Protocol for D2D Communications in a Cloud-Based E-Health System”. Sensors [англ.]. 20 (7): 2072. Bibcode:2020Senso..20.2072G. DOI:10.3390/s20072072. PMC 7181216. PMID 32272675. |access-date= требует |url= (справка)
  15. ↑ 1 2 3 4 Karuppiah, Marimuthu; Saravanan, R. (2015). “Cryptanalysis and an Improvement of New Remote Mutual Authentication Scheme using Smart Cards”. Journal of Discrete Mathematical Sciences and Cryptography [англ.]. 18 (5): 623—649. DOI:10.1080/09720529.2015.1013693. S2CID 62591965. Дата обращения 2024-06-26. |access-date= требует |url= (справка)
  16. ↑ Karuppiah, Marimuthu; Das, Ashok Kumar; Li, Xiong; Kumari, Saru; Wu, Fan; Chaudhry, Shehzad Ashraf; Niranchana, R. (2019). “Secure Remote User Mutual Authentication Scheme with Key Agreement for Cloud Environment”. Mobile Networks and Applications [англ.]. 24 (3): 1046—1062. DOI:10.1007/s11036-018-1061-8. S2CID 64720667. Дата обращения 2024-06-26. |access-date= требует |url= (справка)
  17. ↑ Choudhary, Karanjeet; Gaba, Gurjot Singh; Butun, Ismail; Kumar, Pardeep (2020). “MAKE-IT—A Lightweight Mutual Authentication and Key Exchange Protocol for Industrial Internet of Things”. Sensors [англ.]. 20 (18): 5166. Bibcode:2020Senso..20.5166C. DOI:10.3390/s20185166. PMC 7570918. PMID 32927788. |access-date= требует |url= (справка)
  18. ↑ 1 2 3 Anandhi, S.; Anitha, R.; Sureshkumar, Venkatasamy (2020). “An Authentication Protocol to Track an Object with Multiple RFID Tags Using Cloud Computing Environment”. Wireless Personal Communications [англ.]. 113 (4): 2339—2361. DOI:10.1007/s11277-020-07330-1. S2CID 219070999. Дата обращения 2024-06-26. |access-date= требует |url= (справка)
  19. ↑ Guo, Fuchun; Mu, Yi; Susilo, Willy; Varadharajan, Vijay (2017). “Privacy-Preserving Mutual Authentication in RFID with Designated Readers”. Wireless Personal Communications [англ.]. 96 (3): 4819—4845. DOI:10.1007/s11277-017-4430-x. S2CID 207264759. Архивировано из оригинала 2021-08-14. Дата обращения 2024-06-26. Используется устаревший параметр |url-status= (справка)
  20. ↑ Liu, Xiaoxue; Ma, Wenping; Cao, Hao (2019). “MBPA: A Medibchain-Based Privacy-Preserving Mutual Authentication in TMIS for Mobile Medical Cloud Architecture”. IEEE Access [англ.]. 7: 149282—149298. Bibcode:2019IEEEA...7n9282L. DOI:10.1109/ACCESS.2019.2947313. S2CID 204863294. Дата обращения 2024-06-26. |access-date= требует |url= (справка)
  21. ↑ 1 2 Liu, Xiaoxue; Ma, Wenping; Cao, Hao (2019). “NPMA: A Novel Privacy-Preserving Mutual Authentication in TMIS for Mobile Edge-Cloud Architecture”. Journal of Medical Systems [англ.]. 43 (10): 318. DOI:10.1007/s10916-019-1444-9. PMID 31522286. S2CID 202570185. Дата обращения 2024-06-26. |access-date= требует |url= (справка)

Ссылки

Категории