Анализ существующих методов информационной безопасности облачных сервисов на базе мобильных облачных вычислений с использованием метода PP-CP-ABE

Размещено на http://www.allbest.ru/

Техническое задание

Анализ существующих методов информационной безопасности.

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

1) Обеспечение надёжного шифрования данных при передаче их от пользователя, к провайдеру услуг по хранению данных

2) Минимизация нагрузки на облачные сервисы

3) Возможность применения метода для лёгких мобильных устройств.

Содержание

Введение

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

1.1 Характеристики

1.2 Модели развёртывания

1.3 Облачные модели

1.4 Основные правила по обеспечению безопасности

1.4.1 Правило №1

1.4.2 Правило №2

1.4.3 Правило №3

1.4.4 Правило №4

1.4.5 Правило №5

2. Эффективные и безопасные операции по хранению данных для мобильного облачного вычисления

2.1 Системы и модели

2.1.1 Обозначения

2.1.2 Системная модель

2.1.3 Атакующая модель

2.1.4 Древо политики доступа

2.2 Сохранение конфиденциальности в CP-ABE

2.2.1 Краткий обзор

2.2.2 Исходящая информация

2.2.3 Настройка системы и ключа

2.2.4 PP-CP-ABE шифрование

2.2.5 Аутсорсинг расшифровки

2.3 Параметры для хранения данных

2.3.1 Обзор управления данными

2.3.2 Установка (схема)

2.3.3 Загрузка новых файлов

2.3.4 Обновление данных

2.4 Оценка качества

2.4.1 Оценка безопасности

2.4.2 Оценка эффективности

Заключение

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

Введение

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

Конфиденциальность данных является главным параметром, когда пользователи предоставляют свои данные для хранения поставщикам общественных облачных сервисов. Чтобы защитить данные пользователей, используется шифрование данных в облаке в данной работе была рассмотрена схема Ciphtertext Policy Attribute-Based Encryption (CP-ABE) особенность данной схемы, это облегчение управление ключами и управление криптографическим доступом.

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

Начнем с определения облачных вычислений. Явление это новое, поэтому существует не так много авторитетных источников, где определяется это понятие. Наиболее комплексно и фундаментально подошли к данному вопросу американские специалисты Питер Мелл и Тим Гранс из Лаборатории Информационных Технологий Национального Института Стандартов и Технологий (NIST). В своей работе The NIST Definition of Cloud Computing (Определение облачных вычислений: версия NIST) они пишут следующее.

Облачные вычисления - это модель предоставления удобного сетевого доступа в режиме «по требованию» к коллективно используемому набору настраиваемых вычислительных ресурсов (например, сетей, серверов, хранилищ данных, приложений и/или сервисов), которые пользователь может оперативно задействовать под свои задачи и свести к минимуму число взаимодействий с поставщиком услуги или собственных управленческих усилий. Эта модель направлена на повышение доступности вычислительных ресурсов и сочетает в себе пять главных характеристик, три модели обслуживания и четыре модели развертывания.

1.1 Характеристики

Национальным институтом стандартов и технологий США зафиксированы следующие обязательные характеристики облачных вычислений:

· Самообслуживание по требованию (англ. self service on demand), потребитель самостоятельно определяет и изменяет вычислительные потребности, такие как серверное время, скорости доступа и обработки данных, объём хранимых данных без взаимодействия с представителем поставщика услуг;

· Универсальный доступ по сети, услуги доступны потребителям по сети передачи данных вне зависимости от используемого терминального устройства;

· Объединение ресурсов (англ. resource pooling), поставщик услуг объединяет ресурсы для обслуживания большого числа потребителей в единый пул для динамического перераспределения мощностей между потребителями в условиях постоянного изменения спроса на мощности; при этом потребители контролируют только основные параметры услуги (например, объём данных, скорость доступа), но фактическое распределение ресурсов, предоставляемых потребителю, осуществляет поставщик (в некоторых случаях потребители всё-таки могут управлять некоторыми физическими параметрами перераспределения, например, указывать желаемый центр обработки данных из соображений географической близости);

· Эластичность, услуги могут быть предоставлены, расширены, сужены в любой момент времени, без дополнительных издержек на взаимодействие с поставщиком, как правило, в автоматическом режиме;

· Учёт потребления, поставщик услуг автоматически исчисляет потреблённые ресурсы на определённом уровне абстракции (например, объём хранимых данных, пропускная способность, количество пользователей, количество транзакций), и на основе этих данных оценивает объём предоставленных потребителям услуг.

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

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

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

1.2 Модели развёртывания

Частное облако (англ. private cloud) -- инфраструктура, предназначенная для использования одной организацией, включающей несколько потребителей (например, подразделений одной организации), возможно также клиентами и подрядчиками данной организации. Частное облако может находиться в собственности, управлении и эксплуатации как самой организации, так и третьей стороны (или какой-либо их комбинации), и оно может физически существовать как внутри, так и вне юрисдикции владельца.

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

Гибридное облако (англ. hybrid cloud) -- это комбинация из двух или более различных облачных инфраструктур (частных, публичных или общественных), остающихся уникальными объектами, но связанных между собой стандартизованными или частными технологиями передачи данных и приложений (например, кратковременное использование ресурсов публичных облаков для балансировки нагрузки между облаками).

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

1.3 Облачные модели

Термин «облачные вычисления» используется весьма широко, однако разные облачные модели имеют принципиальные отличия друг от друга с точки зрения безопасности. Поэтому критически важно, чтобы организации не пользовались универсальным подходом для всех моделей. Облачные модели можно разделить на программное обеспечение, предоставляемое в виде сервиса (Software as a Service, SaaS); платформы, предоставляемые в виде сервиса (Platform as a Service, PaaS), и сервисы интеграции (Integration as a Service, IaaS). При обеспечении безопасности облака необходимо учитывать как различия между этими тремя видами облачных моделей, так и их общие черты.

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

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

IaaS. Эта модель ориентирована на управление виртуальными машинами. Основная задача директора по безопасности -- внедрить систему руководства (governance), которая позволит организации регулировать создание и удаление виртуальных машин и тем самым избегать неконтролируемого доступа к ним и потенциальных денежных растрат.

1.4 Основные правила по обеспечению безопасности

1.4.1 Правило №1 (PaaS)

Защищайте конфиденциальную информацию до ее отправки в облако.

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

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

1.4.2 Правило №2 (SaaS)

Не «клонируйте» свою организацию в облаке.

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

Пользователи, имеющие по нескольку паролей, являются потенциальной угрозой безопасности и создают лишнюю нагрузку на сотрудников отдела ИТ-поддержки. Риски и издержки, связанные со множественными паролями, особенно велики в крупных организациях, только начинающих пользоваться облачными вычислениями и применяющих SaaS. Например, если в организации 10 тыс. служащих, ей очень дорого обойдется выдача новых паролей каждому из них для доступа к облачным сервисам. В частности, ИТ-специалистам придется удалять старый и заводить новый пароль всякий раз, когда пользователь забудет свои реквизиты доступа к SaaS-сервису.

Единая точка входа даст возможность пользователю получать доступ и к своему рабочему столу, и к любым облачным сервисам с помощью одного и того же пароля. Этот подход не только предотвратит проблемы с безопасностью, но и обеспечит значительную экономию денег. Пользователи систем с единой точкой входа реже забывают свои пароли, а значит, снижается объем работы у службы ИТ-поддержки. Единая точка входа также упрощает выдачу новых паролей и уничтожение отслуживших. Когда в организации появляется новый пользователь, потребуется активировать всего один новый пароль, а не несколько. Вкратце: вред отсутствия единой точки входа в облако состоит в повышенных рисках безопасности и возрастании нагрузки на службу ИТ-поддержки, а также в риске, что после ухода служащего из организации сохранятся «забытые» учетные записи, которыми могут воспользоваться злоумышленники.

1.4.3 Правило №3 (PaaS)

Ведите протокол аудита

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

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

1.4.4 Правило №4 (IaaS)

Защитите себя от нелегитимного использования облака

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

Хотя провайдеры облачных сервисов предлагают различные уровни их мониторинга, организации следует рассмотреть возможность внедрения собственной инфраструктуры руководства облачным сервисом. Такая независимая система контроля особенно полезна, когда организация пользуется услугами нескольких SaaS-провайдеров, например предоставляющих приложение для кадрового учета, систему ERP и CRM. Однако в этой ситуации директору по безопасности и директору по технологиям необходимо учитывать, что различные облачные провайдеры пользуются разными методами доступа к информации и применяют различные модели безопасности.

Например, для доступа к данным кто-то пользуется REST, кто-то -- SOAP и т. д. В целях обеспечения безопасности кто-то применяет сертификаты, кто-то -- API-ключи, которые мы рассмотрим в следующем разделе. Кое-кто пользуется простой HTTP-аутентификацией. Все эти технологии имеют принципиальные различия, что необходимо учитывать тем, кто намерен пользоваться услугами нескольких провайдеров.

На помощь вновь придет решение, предоставленное облачным брокером, который служит посредником при установлении соединений различных типов и, по сути, «сглаживает» различия между ними. Брокер упростит для организации одновременное использование сервисов разных типов. В ситуациях, когда ресурс достаточно стандартен (например, хранение в качестве сервиса), его легко можно будет заменить на другой того же типа. Тем самым решается проблема смены провайдера в случае, если он становится ненадежным или прекращает работу. В сущности, пользовательская организация не обязана вникать в технические подробности различных интерфейсов. Ей необходима возможность работать на более высоком уровне и использовать облако только ради обеспечиваемого им преимущества -- экономии денег.

1.4.5 Правило №5 (SaaS, PaaS и IaaS)

Защищайте API-ключи

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

Рассмотрим для примера сервис Google Apps. Если организация хочет получить единую точку входа во все приложения Google Apps, это делается с помощью API-ключей. Если эти ключи украдут, атакующий получит доступ к электронной почте всех пользователей в организации.

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

2. Эффективные и безопасные операции по хранению данных для мобильного облачного вычисления

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

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

1) Сохранение конфиденциальности шифра, политика основанная на параметрах шифрования (Privacy Preserving Cipher Policy Attribute-Based Encryption (PP-CP-ABE))

Используя PP-CP-ABE, легкие устройства могут надежно произвести на стороне (аутсорсинг) тяжелое шифрование и операции по декодированию при передаче данных к провайдеру облачных сервисов, не раскрывая содержания данных и используемых ключей безопасности.

2) Attribute Based Data Storage (ABDS) система в качестве криптографического механизма контроля доступа.

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

Структура CP-ABE позволяет привязать к каждому пользователю несколько параметров доступа и шифрования. Несколько пользователей могут иметь общие параметры, которые позволяют шифрующему устройству определять политику доступа к данным, путем составления нескольких параметров с помощью логических операторов, таких как “AND”, “OR”, и т.д. Чтобы расшифровать сообщение, параметры дескриптора пользователя должны удовлетворять политике доступа. Эта уникальная особенности CP-ABE делает привлекательным хранение данных в облачных сервисах, которые требуют эффективного доступа к данным и управление ими для большого количества пользователей.

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

С CP-ABE новая проблема состоит в том, как включить беспроводные мобильные устройства, особенно легкие устройства, такие как сотовые телефоны и датчики, в систему облака.

Эта новая проблема возникла из-за того, что схемы CP-ABE всегда требуют, интенсивных вычислительных ресурсов и алгоритмов декодирования и шифрования.

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

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

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

Используя PP-CP-ABE, пользователи могут надежно произвести вычисление на стороне (аутсорсинг), интенсивное шифрование CP-ABE и операции по декодированию к облаку без разглашения содержания данных и секретных ключей. Таким образом, легкие устройства с ограниченным ресурсом вычисления, могут получить доступ и управлять данными, хранящимися в хранилище данных облака. Кроме того ABDS подходит для мобильных вычислений, чтобы уравновесить коммуникацию и хранение, и таким образом уменьшает стоимость операций по управлению данными (таких как закачка, обновления, и т.д.) и для мобильных узлов облака и для поставщиков услуг хранения.

2.1. СИСТЕМЫ И МОДЕЛИ

2.1.1 Обозначения

Acronym	Descriptions	Описание
DO	Data Owner	Владелец данных
ESP	Encryption Service Provider	Поставщик услуг шифрования
DSP	Decryption Service Provider	Поставщик услуг дешифрования
SSP	Storage Service Provide	Поставщик услуг хранения (данных)
TA	Trust Authority	Доверенный источник
T	Access Policy Tree	Древо политики доступа

2.1.2 Системная модель

1) Данные должны быть зашифрованы перед отправкой Поставщику услуг по хранению (данных)(SSP);

2) Поставщик службы шифрования (ESP) обеспечивает шифрование, владельцу данных, не зная фактического ключа шифрования данных (DEK);

3) Поставщик расшифровки службы (DSP) обеспечивает расшифровку данных пользователей, не зная содержания данных;

4) Даже сговор ESP, DSP и SSP, не открыл бы доступ к содержанию данных пользователя.

Рис.1

Как показано на рисунке 1, SSP, ESP, DSP и образуют основные компоненты предлагаемой системы. ESP и DSP обеспечивают PP-CP-ABE услуги и SSP, например, Amazon S3, предоставляет услуги по хранению данных. В частности, более мощные ПК и мобильные телефоны могут работать как прокси-сервер для связи датчиков, которые собирают информацию.

2.1.3 Атакующая модель

Будем считать, что алгоритм симметричного шифрования и односторонняя хэш-функция, используемая в данной работе является безопасной и задача дискретного логарифмирования (DL) на обеих групп и сложна. Кроме того, TA отвечает за распределение криптографических ключей хорошо защищён и надежен. Рассмотрим провайдеров облачного сервиса, который являются честными, но любопытными. Другими словами, поставщики услуг будут работать в соответствии с предлагаемыми протоколами и возвращают правильные результаты вычислений. Однако, поставщики услуг попытаются узнать как можно больше важной информации (например, анкетные данные, ключи, и т.д.) и возможно могут вступить в сговор с злоумышленниками. Целью злоумышленников "является выявление данных в облаке без разрешения DOs. Несколько злоумышленников могут объединить свои силы для выполнения атаки, они могут попытаться расшифровать зашифрованный текст и поставить под угрозу ключи декодирования, к которым у них нет права доступа. Таким примером нападения может служить сговор - то, что несколько пользователей отзывают доступ к файлам, и они пытаются тайно сговориться, чтобы получить обновленные файлы от общественного облака.

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

2.1.4 Древо политики доступа

В этом разделе кратко описана модель Access Policy Tree, используемое в PP-CP-ABE. Данное древо состоит из конечных узлов и внутренних узлов. Каждый лист узел представляет собой атрибут, а каждый внутренний узел представляет собой логический элемент, например, “AND”, “OR” и т.д.



Рис. 2

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

ь parent(x): возвращает родительский узел узла X;

ь att(x) обозначает параметр, связанный с конечным узлом х в древе доступа к данным;

ь T состоит из множества конечных узлов (т.е. параметров) и внутренних узлов (логические элементы) и определяет политику доступа к данным, то есть, если пользователь владеет набором параметров, которые удовлетворяют логическим операциям дерева до корневого, он может получить доступ к данным обеспеченные T. Пользователь имеет закрытые ключи, соответствующие набору признаков (параметров). AND и OR являются наиболее часто используемыми логическими элементами.

ь numx это количество дочерних узлов . Дочерний узел у узла X идентифицируются по индексу integer index(y) от 1 до numx

ь Пороговое значение kx=numx-1 где x это AND и kx = 0 где x это OR узел. kx используется в качестве многочлен степени узла х с помощью пороговой схемы разделения.

2.2 Сохранение конфиденциальности в CP-ABE

В этом разделе рассмотрим строение PP-CP-ABE алгоритма. В PP-CP-ABE, децентрализованный аутсорсинг интенсивных вычислений СР-ABE шифрование и дешифрование для мощных облачных поставщиков услуг (ESP и DSP), не раскрывая свои данные и секретные ключи.

2.2.1 Краткий обзор

По существу, основная идея PP-CP-ABE произвести интенсивную, но некритическую часть на стороне шифрования и алгоритм дешифрования поставщикам услуг, в то время как поставщики услуг сохраняют важные данные. Как будет доказано позднее, аутсорсинг вычисления не уменьшает уровень безопасности по сравнению с исходными схемами CP-ABE, где все вычисления выполняются локально.

Сложность шифрования CP-ABE линейно возрастает от параметров политики доступа. Тем не менее, уровень безопасности не зависит от the access policy tree. Таким образом мы можем безопасно произвести большую часть сложного шифрования на стороне (аутсорсинг) ESP, просто сохраняя небольшое количество секретной информации, которая обработана локально.

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

2.2.2 Исходная информация

Предлагаемая PP-CP-ABE построена с использованием билинейного соединения, а также тайной схемы разделения, которые кратко представлены ниже.

1) Билинейное соединение: Соединение - билинейной функции e: G0 * G0 > G1 где G0 и G1 две мультипликативных циклических группы с большим главным порядком р. Задача дискретного логарифмирования на G0 и на G1 трудна.

Соединение обладает следующими свойствами:

Билинейность:

e(Pa,Qb)=e(P,Q)ab ,

Невырожденность:

где g является генератором G0

Вычислимость:

существует эффективный алгоритм вычисления соединения.

2) Секретный Обмен: (t,n) секретный обмен, используется для разделения данных на части n и любые части t могут восстановить данные, данные не будут раскрыты если их соединение не превысит t. В - 1-й степени многочлена, любые t точки на полиноминале могут быть использованы для восстановления данных, т. е. многочлена. Определим коэффициенты Лагранжа Дi,S для и набор, S, элементов Zp:

2.2.3 Настройка системы и ключа

TA первой установки PP-CP-ABE системы выбрать билинейной оператор: e: G0 * G0 > G1 простого порядка дp генератора g. TA выбирает два случайных параметра б, в Zp. Открытые параметры публикуются в виде:

(1)

Главный ключ MK = (в,gб), который известен только ТA.

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

Алгоритм генерации ключа:

1) Выбираем случайно r Zp

2) Выбираем случайно rj Zp для каждого параметра j S

3) Вычисляем (генерируем) закрытый ключ:

4) Посылаем SK к DO через защищенный канал.

2.2.4 PP-CP-ABE Шифрование

Для стороннего (аутсорсинг) расчета шифрования и сохранения конфиденциальности данных, DO необходимо указать specify a policy tree Ф = ТESP TDO, где является логическим элементом, соединяющий два поддерева (subtrees) ТESP и TDO. . ТESP политика доступа к данным, которая будет выполняться ESP, и TDO - (controlled data access policy) управляемой политики доступа к данным. TDO как правило, имеет небольшое количество атрибутов для уменьшения вычислительных мощностей в DO, в котором он может быть под-дереве с одним параметром (рис. 3).

модель облачный информационный безопасность

Рис. 3 Ф = ТESP TDO

На практике, TDO имеет один параметр, может в произвольном порядке определить многочлен 1-й степени qR(х) и наборы s=qR(0), s1=qR(1) и s2=qR(2). Затем DO посылает данные ESP которые отмечаются как:

При этом следует заметить, что отправление S1 и TESP не представят секреты вашего решения.

ESP запускает алгоритм шифрования, который описан ниже:

1. случайным образом выбранный многочлен qx со степенью dx=kx-1, где kx секретное пороговое значение совместного использования:

1. 1. Для корневого узла то есть , выбирает - cтепень многочлена с

1. 2. наборы dx - степень многочлена с

2. Формирует временный зашифрованный текст

Где YESP есть множество конечных узлов в TESP.

В то же время, DO выполняет следующие операции:

1. Выполняет Шифрование (s2,TDO) и получает:

2. Вычисляет C = Me()бs и С = hs , где М это сообщение.

3. Посылает C , С в ESP

4. При получении сообщения от DO, ESP генерирует следующий зашифрованный текст:

Наконец, ESP посылает СТ в SSP

2.2.5 Аутсорсинг расшифровки

Алгоритм дешифрования CP-ABE в вычислительном отношении дорог, так как билинейное соединение - дорогая работа. PP-CP-ABE решает эту проблему вычисления, производя дорогие операции Соединения на стороне (аутсорсинг) к DSP. Опять же, аутсорсинг не будет подвергать содержание данных зашифрованного текста на DSP.

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

(2)

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

. (3)

После того, как DSP получит и затем происходит расшифровка следующим образом:

1) DSP выполняет рекурсивную функцию расшифровки узла (Decrypt Node) , где R является корнем T. Рекурсия функции та же, что и определена в [3] и расшифровка узла и алгоритм расшифровки следующий:

Рекурсия обрабатывается следующим образом: дочерний элемент x, он вызывает Decrypt Node и сохраняет в файл как Fy. Пусть Sx произвольный параметр kx - размер дочерних узлов у, DSP проводит вычисление:

(4)

где i = index(z) и

В конце, рекурсивный алгоритм возвращает

2) Затем вычисляется

3) Посылается в DO

При получении {A,B}, DO вычисляет , а затем он восстанавливает сообщение:

2.3 Параметры для хранения данных

2.3.1 Обзор управления данными

Частое обновление данных вызовет дополнительные расход по управлению файлами. Например, для обновления существующих файлов, например, изменение некоторых полей данных из зашифрованной базы данных, в которой зашифрованные данные должны быть загружены от SSP до DSP для дешифрования. По окончании обновления, ESP должен снова повторно зашифровать данные и загрузить данные в SSP. Таким образом повторное шифрование данных требует скачивание и загрузку данных, все это приводит к увеличению издержек для DO.

Чтобы решить описанную проблему стоимости издержек, разумно разделить файл на независимые блоки, которые зашифрованы независимо. Чтобы обновить файлы, может просто загрузить определенные блоки, которые будут обновлены. Таким образом, можно избежать повторного шифрования всех данных. Кроме того управление доступом к данным может быть осуществлено на отдельные блоки данных, используя "ленивую" (lazy) стратегию перешифрования. Например, когда был изменён доступ к данным в определенном файле (т.е., дерево доступа изменено), это событие может быть зарегистрировано, не вызывая при этом ни какие изменения файлов. Пока содержание данных не должно быть обновлено, перешифрование выполняется, используя предложенную схему PP-CP-ABE.

Рис. 4

Разделение данных на несколько небольших блоков также приводит к дополнительным расходам. Это вызвано тем, что дополнительная управляющая информация должна быть присоединена для каждого блока данных для управления ими. Например, управляющее сообщение должно включать в себя ID блока и указатель на соответствующий Т доступа к данным древа (data access tree). На рисунке 4 изображен образец файла, сохраненного в SSP. Как показано на рисунке 4, каждый файл разбивается на блоки. Блок представляет собой кортеж {BID, Ptr, Encrypted Data}, где BID является уникальным идентификатором блока; Ptr является указателем на блок управления CT; и данные хранятся в зашифрованы с помощью ДЭК. Блок управления {CID, Encrypted DEK} имеет ID блока управления, т.е., CID и ДЭК шифруется с помощью PP-CP-ABE схеме.

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

1) Каждое обновление данных должна влиять только на небольшое количество данных, например, обновление некоторых полей данных в базе данных;

2) В каждый период единицы времени известно число блоков, которые будут обновлены;

3) Каждый блок данных имеет одинаковую вероятность быть обновленым;

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

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

(5)

где n - число обновленных блоков в период единицы времени и 2n, означает, что обновления включает одно шифрование и одно дешифрование, которые требуются для двух передач; Sb является размером блока; Сс является стоимостью скорости передачи данных, которая взымается с обоих провайдеров облачных систем хранения и поставщика услуг по беспроводной передачи данных; F - это размер файла; Sc - это размер управляющей информации для каждого блока данных и СS - это уровень хранения данных. DO может минимизировать (5) и получают оптимальный размер блока:



2.3.2 Установка (схема)

PP-CP-ABE enables expressive policy with descriptive attributes to enforce data access control to the stored data. For example, if Alice wants to share a file to all CS students, she can specify the descriptive policy “CS AND Student”. Все пользователи, параметры которого удовлетворяют данной политике могут расшифровать данные.

Помимо набора дескриптивных параметров, включенных в систему, каждому пользователю присваивается уникальный двоичный ID: . Мы можем определить термин "бит назначения атрибутов" (“bit-assignment attribute”), который представлен ??в виде для обозначения двоичного значения в положении i в ID. указывает на i-й бит из ID=1, указывает на i-й бит из ID=0. Если длина ID равна n, тогда общее количество битов назначения атрибутов равно 2n. Это означает, что два двоичных значения отображены на одной позиции двоичного разряда (один для значения 0 и один для значения 1). Таким образом, DO с ID u однозначно определяется набором бит задания Su. Кроме того, несколько DOs могут иметь общее подмножество битов назначения. Так, например, DO u1's ID is 000 and a DO u2's ID is 001, Su1 = {B0;B1;B2} and Su2 = {B0;B1;B2} and Su1 ? Su2 = {B0;B1}. Атрибуты разрядного присвоения могут использоваться, когда DO хочет совместно использовать данные c любым произвольным набором DOs. В этом случае трудно описать набор DOs, эффективно использующие дескриптивные атрибуты.

2.3.3 Загрузка новых файлов

Перед загрузкой новых файлов в SSP, ESP и DO необходимо определить параметры шифрования, такие как размер блока. TT then invokes ESP with an access policy TESP , which is the access policy to be enforced on the uploaded files.

Сначала мы определим некоторые термины, используемые далее:

· Константа: Переменная или её дополнение, например: b1, , etc.

· Product Term: Константы соединённые с помощью AND, например

· Sum-of-Product Expression (SOPE): Константы соединённые с помощью OR, например

Учитывая набор совместно используемых получаемых данных S, fs() функция принадлежности, которая находится в форме SOPE, определяет список получателей:

Например, если подгруппа S = {000; 001; 011; 111}, затем fS = b0b1b2 + b0b1b2 + b0b1b2 + b0b1b2.

Затем DO работает согласно алгоритму Куайна -- Мак-Класки для уменьшения fs к минимальному SOPE . Сокращение можно рассмотреть, не заботятся значения ? тех IDs, которые в настоящее время не присвоены никакому DO, далее сократить количество множителей в функции принадлежности. Например, если S = {000; 001; 011; 111}, fminS = b0b1 + b1b2.

в виде SOPE, TESP может быть сформулирована в дизъюнктивной нормальной форме (ДНФ). То есть, для каждого продукта термин E в , DO определяет множитель W c использование следующих правил:

1) Для положительных констант

2) Для отрицательных констант

Как следствие, TESP определяет политику доступа в следующем формате: например . Мы можем обнаружить, что содержит 2 множителя, и TESP содержит 2 логических элемента AND, соединенные полностью логическим элементом OR. Наконец, TT загружает блоки данных и блок управления к SSP, где каждый блок данных зашифрован DEK, и DEK защищен политикой доступа в блоке управления.

2.3.4 Обновление данных

Теперь исследуем то, как эффективно обрабатывать данные обновления, то есть, как изменить зашифрованные данных с или без изменения данных политики управления доступом.

1) Обновления данных с изменением политики доступа: В разделе 2.3.1 была описана "ленивая" (“lazy”) стратегию перешифрования, принятую в DOs. Используя "ленивую" схему перешифрования, DO постоянно записывает, отменяемые получателем данные. Когда будет потребность изменить данные, DO выберет новое древо доступа к данным, которое может отменить все ранее зарегистрированные получателем данные.

Когда DO обновляет блок данных с изменением политики доступа, мы должны рассмотреть следующие случаи:

· Если нет никакого блока управления, связанного с последней политикой доступа, т.е., никакие обновления данных не произошли после последнего события изменения политикой доступа DO шифрует новый случайный DEK, связанный с последней политикой доступа с PP-CPABE, и присоединяют новый блок управления до конца файла, см. рисунок 4.

· Если существует блок управления, связанный с последней политикой доступа, т.е., по крайней мере один блок данных был зашифрован с новейшей политикой доступа, DO может просто перенаправить указатель блока управления, cм. рисунок 4, к блоку управления, связанному с последней политикой доступа.

· Если на блок управления не указывает никакой блок данных, этот блок управления должен быть удален.

2) Обновления без изменения политики доступа: Если никакие изменения в политике доступа не требуются, DO может просто выполнить схему PP-CP-ABE и загрузить обновленный блок данных в SSP. ID блока и указатель на блок управления не изменяются.

2.4 Оценка качества

В этом разделе дадим оценки безопасности представленного решения. Затем представим вычисление, передачу и оценку результатов деятельности хранения.

2.4.1 Оценка безопасности

Структура данных шифрованного текста и закрытого ключа в PP-CPABE совпадает с исходным BSW CP-ABE [3], таким образом, PP-CP-ABE можно рассматривать как вариант CP-ABE. Однако, в PP-CP-ABE, дерево политики доступа создано двумя поддеревьями . В целом содержит единственный атрибут, дабы уменьшить коммуникационные издержки и вычисление. Таким образом, DO случайно определяет многочлен 1-й степени q(x) и параметры . Кортеж посылается в ESP. Легко доказать что, на основе порогового секрета совместное использование схемы [26], при данном многочлене 1-й степени q(x), зная, S1, секреты S и S2 информации теоретически безопасна.

На основе предположений безопасности, представленные в разделе 2-А, ESP, DSP и SSP являются ненадежными, но честными поставщиками услуг, которые будут выполнять всё в соответствии с протоколом и возвращать правильные результаты. Чтобы поставить под угрозу секретную информацию пользователей, ESP, DSP и SSP могут выполнить совместную атаку. В этом случае, авторизованный пользователь который удовлетворяет древу доступа T обеспечивает его закрытый ключ на DSP для расшифровки. Затем, ESP и DSP может попытаться использовать секретный ключ для получения M от . ESP имеет , и таким образом он может легко получить . Это происходит потому доступно от общедоступных параметров, представленных в (1). Как пользователь удовлетворяет политики доступа можно получить следующие значения , , и через функцию Fx (см. (4)), не зная б и . В следующей таблице перечислены все рациональных термины, которые доступны для ESP и DSP.

ESP
DSP

Как мы видим, ESP имеет значения и , но он не знает о значениях и s. DSP обладает большим количеством условий, а также закрытым ключом от (см. (2)). Следует отметить, что не допустимый закрытый ключ CP-ABE, начиная с встроен с и и остальная часть всех компонентов с закрытым ключом встроен с . По существу этот закрытый ключ может быть допустимым закрытым ключом CP-ABE когда (i) главный ключ ; (ii) способствует сговору пользователей который является действительным компонентом встроенный в ; и (iii) способствует сговору пользователей которые ограничены случайным , который отличается от в D. Так как t - экспонента генератора , получение этого эквивалентно решению проблемы DLP, которая считается трудной. Таким образом, учитывая безопасность тайного обмена и надежность DLP на , ESP и DSP не могут получить или даже если они вступят в сговор.

2.4.2 Оценка эффективности

1) Выполнение вычислений PP-CP-ABE: Чтобы оценить производительность представленной схемы PP-CP-ABE, мы оцениваем издержки вычисления поставщиков услуг и пользователей на основе теоретического анализа и на основе результатов эксперимента.

Во-первых, проанализируем количество дорогостоящих криптографических операций над G0 и G1, т. е. соединение, возведение в степень, умножение, выполняемое поставщиками услуг и устройствами пользователей. В данном анализе предполагаем, что в политике доступа есть один параметр соединённый логическим элементом и имеет только один параметр. Кроме того, корневой узел - логический элемент AND.

В следующей таблице сравнивается число возведений в степень, умножения и хеша к операциям G0, понесенным на стороне ESP и на стороне пользователя в аутсорсинге шифрования, где a1 - число атрибутов в TESP:

ESP		0
Userw		1	1

Также сравним параметры возведений в степень, умножения, инверсии и соединяющихся операций, проведённые аутсорсингом дешифрования на стороне DSP и на стороне пользователя как показано в следующей таблице, где a1 - число атрибутов в TESP:

				Pairing
DSP
User	1	2	1	0

Из вышеупомянутого анализа мы видим, что издержки вычисления линейные для поставщиков услуг (ESP и DSP) и постоянные для пользователя. Среди всех операций, операция соединение будет наиболее интенсивным из всех вычислений.

Также проводим экспериментальную оценку криптографического соединения и операций ECC на беспроводном датчике Моте (8 бит-7,37 МГц ATMega128L, 4 КБ ОЗУ). Тестовые среды и результаты перечислены в следующей таблице:

	Pairing
Sensor	31250 мс	10720 мс	196 мс

Кроме теоретического анализа, также выполни экспериментальные измерения. На основе проекта [3] с открытым исходным кодом CP-ABE реализуем и оценим PP-CP-ABE на ПК с процессором Intel Atom 1,6 ГГц Linux ядро 2.6.32. Время вычислений измеряется с помощью тактов системных часов, возвращенные часами clock_t clock(void) функционируют в стандартной библиотеке для C. Чтобы проиллюстрировать, что большинство издержек вычисления произведено на стороне поставщиками услуг, вычисление проводится как у пользователя так и на сервер на той же платформе и записывается зарегистрированное число тактов системных часов. На рисунке 5 видны издержки вычисления, понесенные поставщиками услуг и пользователями при аутсорсинг дешифровании и шифровании. Издержки вычисления рассчитаны с точки зрения логарифма по основанию 10, т.е., из тысяч (K) тактов. Как мы видим на рисунке, более чем 90% шифрования и больше чем 99% вычислений дешифрования выполняются поставщиками услуг.

Рис. 5

2) Характеристика накопления ABDS: Проанализируем производительность хранения ABDS и сравнив его с несколькими связанными криптографическими решениями для управления доступом: широковещательные схемы шифрования (Subset-Diff) [14], BGW широковещательная передача шифрования [6], схема полиномиала управления доступом (ACP) [29]. Производительность оценена с точки зрения издержек хранения шифрованного текста, ключевые издержки хранения (системные параметры и публичные / закрытые ключи, сохраненные у пользователя и TA). Мы обозначаем общее количество пользователей в системе N, и также учтём, что пользователь хочет совместно использовать файл к любому данному набору получателей в системе. Сравнительные результаты представлены в Таблице:

Scheme	Ciphertext Storage	Key Storage
	Single data receiver	multiple data receivers	TA	User
ABDS
Subset-Diff
BGW1
BGW2
ACP

Издержки хранения шифрованного текста (Ciphertext Storage Overhead) В схеме Subset-Diff размер шифрованного текста составляет , где t есть максимальное количество пользователей, которые хотят поставить под угрозу шифрованный текст. Для схемы BGW размер шифрованного текста или о чем сообщается в [6]. В схеме ACP размер сообщения зависит от степени полиномиала управления доступом, который равняется числу текущих получателей. Таким образом размер сообщения . Чтобы управлять рядом получателей S использующих ABDS, размер шифрованного текста зависит от числа множителей в (см. 2.3.3). В [25], авторы вывели верхней границы и нижней границы среднего Количество ключевых слов в свернутом SOPE. Экспериментально, среднее число требуемого сообщения составляет [9].

Рассмотрим некоторые случаи, когда затраты на хранение зашифрованный текст является максимальным.

Лемма 1 (многократные получатели данных худший случай): Худший случай совместного использования файла с многократными получателями данных происходит, когда выполняются следующие условия: 1) Число отличных получателей ; 2) Расстояние Хемминга между IDs любых двух получателей, по крайней мере 2. В худшем случае число ключевых сообщений обновления .

Доказательство1: Пожалуйста, обратитесь к [8] для полного доказательства. В этом случае число множителей использование ABDS. Однако, мы видим, что худшие случаи происходят c чрезвычайно низкой долей вероятности.

Лемма 2 (худшая возможность случая): При совместном использовании файла всеми получателями данных худший вариант развития событий происходит с вероятностью

Рис.6

Доказательство2: В худшем случае расстояние Хемминга IDs получателей N/2 должно быть по крайней мере 2. Как показано в таблице Карно на рисунке 6, каждая ячейка представляет ID. Для любой ячейки отмеченной 0 и любой ячейки обозначенной 1, расстояние Хемминга, по крайней мере 2. Таким образом худший случай происходит в двух случаях: (i) шифратор хочет достичь N \ 2 получателей обозначенные цифрами 1 на рисунке 6; шифратор хочет достигнуть, получателя N\2 отмеченный 0 на рисунке 6.



Рис. 7 а

Рис. 7 б

Чтобы исследовать средний значение, моделируем ABDS систему с 512 пользователями и 1024 пользователями, и число требуемых сообщений показано на рисунке 7 (a) и рисунке 7 (b) соответственно. При моделировании, рассмотрим случаи 0%, 5%, 25%, 50% IDs не указаны. Для каждого случая различные проценты получателей в произвольном порядке выбраны из группы. Повторяем 100 раз усреднения результата. Экспериментально, размер сообщения в CP-ABE начинается примерно с 630 байт, и каждый дополнительный параметр добавляет около 300 байт. Так как число атрибутов в политике доступа ограничено logN, мы можем прийти к заключению, что издержки хранения шифрованного текста ABDS находятся в порядке O (log2 N).