Протоколы обеспечения безопасности доступа к облачным хранилищам данных

From CryptoWiki
Jump to: navigation, search

Contents

Введение

Облачные технологии являются одной из информационных технологий, рассматриваемых в настоящий момент как альтернатива к традиционным моделям обработки информации.
По версии стандарта NIST SP-800-145 [1] под облачными вычислениями принято понимать модель предоставления доступа к разделяемому множеству вычислительных ресурсов (сетей, серверов, систем хранения данных, приложений, услуг и т. д), которые без вмешательства со стороны поставщика услуг выделяются “подписчику” облака по требованию в соответствии с его запросами.
Согласно различным исследованиям количество пользователей в сфере облачных технологий увеличилось на 20% за последние годы [2]. По разным оценкам на Западе облачные технологии экономят до 60% расходов на ИТ-инфраструктуру. Рост использования облачных технологий различными информационными структурами в России составил не менее 40% к 2013 году [3].
Основной идеей облачных технологий является предоставление ресурсов по требованию. Таким образом, субъекту, арендующему ресурсы, нет необходимости содержать их.
Использование облачных технологий дает ряд преимуществ перед традиционными информационными технологиями:

  • Организация может более эффективно управлять использованием вычислительных ресурсов.
  • Повышается управляемость ИТ-инфраструктурой (в том числе географическая).
  • Упрощается управление бесперебойностью работы организации благодаря заложенным в концепцию системам резервного копирования и миграции виртуальных машин.
  • Сокращение расходов на ИТ-инфраструктуру, таких как содержание парка вычислительных ресурсов, электроэнергию, а также персонала, обслуживающего эту инфраструктуру.

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

Постановка задачи защиты информации

Целью данной статьи является изучение современных протоколов обеспечения безопасности доступа к облачным хранилищам данных.
Для достижения поставленной задачи были определены следующие подзадачи:

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

Архитектура облачного хранилища

Рисунок 1 - Архитектура облачного хранилища

Сетевая архитектура облачного хранилища данных представлена на рисунке 1 [4]. Три сетевые сущности могут быть идентифицированы следующим образом:

  • Пользователи: пользователи, которые хранят данные в облаке и обрабатывают их. Пользователем может выступать организация, отдельный пользователь или ИТ-система, которые потребляют облачные сервисы.
  • Облачный провайдер (Cloud Server Provider-CSP): лицо, имеющее значительные ресурсы и опыт в построении и управлении распределёнными серверами облачных хранилищ. Облачный провайдер является собственником информационных систем, построенных на технологии облачных вычислений, и, соответственно, управляет их жизненным циклом.
  • Проверяющая третья сторона (Third Party Auditor -TPA): участник взаимодействия с опытом и возможностями, которых нет у пользователя. Он является доверенной стороной, которая оценивает риски облачных сервисов по запросу пользователя.

Пользователь хранит данные посредством CSP на серверах облачного хранилища, которые работают одновременно, совместно и распределённо. Резервирование данных может быть реализовано методом стирания и корректировки кода для дальнейшего избавления от ошибок или падения серверов с увеличением важности и объёма данных пользователя. Далее пользователь взаимодействует с облачными серверами через облачного провайдера, чтобы получить доступ к данным или восстановить их.
В некоторых случаях пользователю может потребоваться выполнить операции над данными на уровне блоков. Наиболее общими формами этих операций являются блок обновления, удаления, вставки и добавления. Так как пользователи больше не обладают данными локально,крайне важно заверить пользователей, что данные корректно хранятся и обрабатываются. Таким образом, пользователи должны быть оснащены средствами безопасности, посредством которых они будут уверены, что данные в порядке без наличия их на локальной машине. В случае, если пользователям необязательно иметь время, технические возможности или ресурсы, чтобы отслеживать данные, они могут делегировать задачи доверенной третьей стороне.

Дерево Меркеля

Рисунок 2 - Дерево Меркеля

Модель безопасности

Проверяющая схема является безопасной, если для (i-файловый индекс) не существует алгоритма, выполняющегося за полиномиальное время, и который может обмануть проверяющего с не пренебрежимо малой вероятностью; если для (ii) существует алгоритм, выполняющийся за полиномиальное время, который может восстановить исходные файлы данных путём проведения многочисленных запросов и ответов [5]. В данной системе пользователь может периодически вызывать сервер хранилища для обеспечения корректности облачных данных и исходных файлов, которые могут быть восстановлены при взаимодействии с сервером.

Основные определения

Билинейное отображение.. Билинейное отображение - отображение e : G × G → GT , где G-группа Gap Diffie-Hellman (GDH) и GT-другая мультипликативная циклическая группа порядка простого числа p со следующими свойствами:
(i)-вычисляемая: существует эффективно вычисляемый алгоритм вычисления e;
(ii)-билинейная: для всех h1, h2 ∈ G и a, b ∈ Zp, Формула 1.png
(iii)-невырожденная: e(g, g)!= 1, где g является генератором группы G.
Хэш-Дерево Меркеля. Хэш-Дерево Меркеля является хорошо изученной структурой аутентификации, которая предназначена эффективно и безопасно доказывать, что набор элементов не подвергался изменениям. Он построен в виде двоичного дерева, где листья -это хэши аутентичных значений данных [5].

Описание алгоритма

Пример данной аутентификации изображён на рисунке 2. Проверяющий с аутентичным hr делает запрос для {x2, x7} и требует проверки аутентичности полученных блоков [5]. Доказывающий осуществляет проверку с дополнительной информацией аутентификации (auxiliary authentication information - AAI) Формула 3.png.
Проверяющий может убедиться в валидности x2 и x7, сначала вычислив

Формула 4.png

затем осуществив проверку вычисленной hr с аутентичным значением. Хэш-Дерево Меркеля в основном используется для аутентификации значений блоков данных.

Формула 5.png

Этот вероятностный алгоритм выполняется пользователем. Он принимает в качестве входных параметров безопасности 1^k, и возвращает открытый ключ pk и закрытый ключ sk.

Формула 6.png

Следующий алгоритм также выполняется пользователем. Он принимает в качестве входных данных секретный ключ sk и файл F, который представляет собой упорядоченный набор блоков {mi}, и на выходе получаем набор сигнатур Φ, который представляет собой упорядоченную серию подписей {σi} на {mi}. Выходными данными также вявляются метаданные-подпись sigsk(H(R)) корня R хэш-дерева Меркеля. В данном случае конечными узлами хэш-дерева Меркеля являются хэши H(mi).

Формула 7.png

Этот алгоритм выполняется сервером. На вход принимает файл F, его подпись Φ, и запрос chal. На выходе получаем доказательство целостности данных P для блоков, указанных chal.

Формула 8.png

Этот алгоритм может быть запущен пользователем или проверяющей третьей стороной при получении доказательства Р. Он принимает в качестве входных данных открытый ключ pk, вызов chal, и доказательство P, полученное от сервера, и выводит TRUE, если целостность файла является корректной, в противном случае-FALSE.

Формула 9.png

Данный алгоритм выполняется сервером. Он принимает в качестве входных данных файл F, его подпись Φ, и запрос на проведение операции “обновление” от пользователя. Алгоритм выводит обновленный файл F', обновленные подписи Φ' и доказательство проведения операции Pupdate.

Формула 10.png

Алгоритм запускается пользователем. Он принимает в качестве входных данных открытый ключ pk, подпись sigsk(H(R)), запрос на операцию “обновление”, и в качестве доказательства Pupdate от сервера. Если проверка прошла успешно, на выходе получаем подпись sigsk(H(R')) для нового корня дерева R', или FALSE в противном случае.

Протокол проверки целостности данных

Рисунок 3 - Схема обмена сообщениями между третьей стороной (TPA) и сервером (CSS)
  • Предварительный этап: Генерируется открытый и закрытый ключи пользователя путем вызова функции Кейген.jpg. Вызовом функции Сигнген.jpg подписывается файл F = (m1, . . . ,mn), который состоит из упорядоченных блоков данных Ми.jpg в дереве Меркеля. Учитывая, что F = (m1, . . . ,mn), пользователь выбирает случайный элемент u ← G. Пусть Сск.jpg файл тегов для Ф. Тогда пользователь вычисляет подпись σi для каждого блока mi (i = 1, . . . , n). Обозначим множество подписей Φ = {σi}, 1 ≤ i ≤ n. Затем пользователь создает корневой R, основанный на построении хеш-дерева Меркеля (MHT), где узлы дерева представляют собой упорядоченный набор BLS хешей “file tags” H(mi) (i = 1, . . . , n). Далее пользователь подписывает корень R отдельным ключом α: Сиг.jpg. Пользователь отправляет Сигск.jpg на сервер и удаляет СигскА.jpg из локального хранилища [5].
  • Проверка целостности: клиентом или третьей стороной, например, TPA, можно проверить целостность распределенных данных через вызов сервера. TPA может использовать spk, чтобы проверить подпись на t. Если проверка не прошла, возвращается FALSE; в противном случае, восстанавливается u. Чтобы создать сообщение “chal”, TPA (верификатор) выбирает случайный c-элемент подмножества I = {s1, . . . , sc} из [1, n], где мы предполагаем, s1 ≤ · · · ≤ sc. Для каждого i ∈ I TPA выбирает случайный элемент νi ← Zp. Сообщение “chal” определяет позиции блоков для проверки фазы вызовов. Верификатор отправляет сообщение {(i, νi)} s1≤i≤sc на сервер (CSS).
  • Проверка на сервере: получив сообщение chal из TRA, сервер вычисляет Генпроф.jpg, где Миq.jpg проверяет Esig.jpg , если проверка подлинности завершается неудачей, выдается FALSE. В противном случае, верификатор проверяет Eeeig.jpg, если так, то выход TRUE; в противном случае-FALSE. Работа протокола изображена на рис 3.

Протокол аутентификации для облачных вычислений

Идентификация на основе шифрования и подписи для облачных вычислений с иерархической архитектурой (IBE AND IBS FOR HACC)

В облачных вычислениях связь между пользователями постоянна [6]. Для достижения безопасной связи предлагаются схемы шифрования и подписи. Поэтому, мы предлагаем шифрование на основе идентификационной информации Identity-Based Encryption (IBE) и на основе идентификационной подписи Identity-Based Signature (IBS) для схемы HACC.

A. На основе идентификационной информации (IBE)
IBE состоит из шифрования и расшифрования.
Шифрование: Предположим, E1 и E2 - два пользователя в облачных вычислениях. Идентичность Е2

    IDe2.jpg 

Чтобы зашифровать сообщение m с IDE1, E1 действует следующим образом:
1. Вычисляет

    P1P2.jpg

2. Выбирает случайное R.jpg
3. Выводит зашифрованный текст

   C.jpg, 
где
G.jpg

могут быть предварительно вычислены.

Расшифрование: После получения шифрованного текста C=.jpg E2 может расшифровать C, используя свой секретный ключ, действуя следующим образом:

    Se2.jpg

Где P1.jpg является секретом точки узла DN0.jpg:
1.Вычисляет

    D.jpg, 

где

  Qid.jpg

2. Выводит сообщение

  M.jpg


В. На основе идентификационной подписи (IBS)
IBS включает в себя два алгоритма: подписи и проверки.
Подпись: Предположим, E1 и E2 - два пользователя в облачных вычислениях. Идентичность Е2

   IDe2.jpg

Чтобы подписать сообщение m, Е2 действует следующим образом:
1. Вычисляет

    P1P2Pm1.jpg

2. Вычисляет

   B.jpg, 

Где P2.jpg является секретом точка Е2;
3. Результаты подписи

   BPmQ.jpg

Проверка подписи: Другие пользователи могут проверить подпись, действуя следующим образом: Подтверждение

  EP.jpg     (*) 

Где

   Rez.jpg 

Если уравнение (*) справедливо, подпись верна.

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

Рисунок 4 - Схема установления соединения между пользователем и сервером

В этом разделе в качестве протокола аутентификации для облачных вычислений (Authentication Protocol for Cloud Computing) используем инфраструктуру открытых ключей (PKI) с использованием алгоритмов IBE и IBS для согласования ключей. Аналогично протоколу TLS, который использует алгоритм RSA для обмена ключами [6].
C : Клиент
S : Сервер
Ncns.jpg: Случайные числа
SID: Идентификатор сеанса
Spec.jpg : Шифр спецификации C
Specs.jpg : Шифр спецификации S
Scs.jpg: Предварительный главный секрет
Eps.jpg: Шифрование Scs.jpg на открытом ключе сервера при использовании алгоритма шифрования IBE
М : Сообщение ClientHello
SigM.jpg: Подпись сообщения M закрытым ключом пользователя с использованием алгоритма подписи IBS
Veri.jpg : Проверка подписи пользователя SigM.jpg с помощью IDc.jpg, используя алгоритм проверки IBS
DssEps.jpg : Расшифрование Eps.jpg секретным ключом сервера, используя алгоритм IBE

Как показано на рис.4, на стадии (1) пользователь С посылает сообщение ClientHello серверу S. Сообщение содержит случайное число Nc.jpg, идентификатор сессии SID и спецификацию С Spec.jpg. Spec.jpg при использовании протокола TLS для обработки схемы IBE и IBS. Например, C спецификация может иметь такую форму TLS_IBE_IBS_WITH_SHA_AES. IBE и IBS используются в качестве безопасной транспортировки и аутентификации. SHA является хэш-функцией. AES является симметричным алгоритмом шифрования. Сообщение ClientHelloDone заканчивает шаг (1).

На стадии (2) сервер S реагирует на cообщение ServerHello, которое содержит случайное число Ns.jpg, идентификатор сессии SID и шифр спецификации S Specs.jpg. Сообщение ServerHelloDone завершает шаг (2).

На шаге (3) пользователь C выбирает предварительный главный секрет Scs.jpg и шифрует его с помощью открытого ключа сервера S Ps.jpg с использованием алгоритма шифрования IBE. Зашифрованный текст передается как сообщение ClientKeyExchange. Затем C генерирует подпись SigM.jpg как сообщение IdentityVerify и направляет его серверу S. Наконец, сообщение ClientFinished означает, что шаг (3) заканчивается.

На шаге (4) сервер S, во-первых, проверяет подпись SigM.jpg с помощью IDc.jpg. C может пройти проверку, только если он является действительным владельцем IDc.jpg. Это завершает проверку подлинности пользователя C. Тогда S расшифровывает Eps.jpg с помощью своего закрытого ключа Ss.jpg. Правильная расшифровка Scs.jpg будет указывать, что S является действительным владельцем IDs.jpg. Этот шаг проверяет подлинность действий сервера S. Сообщение ServerFinished означает конец шага (4).

В конце концов, общий секретный ключ между C и S рассчитывается по формуле Kcs.jpg , где PRF - псевдослучайная функция.

Глоссарий

Библиографический указатель

Перейти к списку литературы

Вернуться к оглавлению

Практическое задание

    Доступно для скачивания приложение, демонстрирующее атаки на режимы шифрования ECB и CBC:
  • File:BDZ Application.zip

  • Также доступен для скачивания исходный код этого приложения:

  • File:Bdz attack CBC and ECB.zip




  • Рахматуллина А.Р.,
    Шабыков А.И.
    2014

    Назад