Исследователи из Массачусетского технологического института представили (http://www.forbes.com/sites/andygreenberg/2011/12/19/an-mit-.../) проект CryptDB (http://css.csail.mit.edu/cryptdb/), в рамках которого предпринята попытка решения проблемы безопасностого хранения данных в БД, обслуживаемых в облачных сервисах и других неподконтрольных системах. Основная проблема при хранении важной информации в неподконтрольных СУБД связана с возможностью утечки данных в процессе взлома сервиса или в результате неправомерных действий администраторов. Для решения этой проблемы в CryptDB обеспечена поддержка шифрования, при которой данные на стороне СУБД никогда не фигурируют в открытом виде.
При использовании CryptDB, в процессе выполнения SQL-запросов все действия производятся только с зашифрованными данными, т.е. пользователь может отправить SQL-запрос к СУБД и получить результат без расшифровки информации на стороне серве...URL: http://www.forbes.com/sites/andygreenberg/2011/12/19/an-mit-.../
Новость: http://www.opennet.me/opennews/art.shtml?num=32610
Идея интересная, но я что-то не понял:1. нельзя использовать "salary > age*2+10", но можно "salary > age" или "salary > 10"
Это как так? Если "salary>age" и "salary>10" катит, значит значения обоих полей нам известны. Что мешает произвести над известными значениями мат.операцию?
2. если значение salary и age нам известны, то где "все действия производятся только с зашифрованными данными, т.е. пользователь может отправить SQL-запрос к СУБД и получить результат без расшифровки информации на стороне сервера"?
> 1. нельзя использовать "salary > age*2+10", но можно "salary > age" или "salary > 10"
> Это как так? Если "salary>age" и "salary>10" катит, значит значения обоих полей нам
> известны. Что мешает произвести над известными значениями мат.операцию?For example, it does not support both computation
and comparison on the same column, such as WHERE salary >
age*2+10. CryptDB can process a part of this query, but it would
also require some processing on the proxy. In CryptDB, such a
query should be (1) rewritten into a sub-query that selects a whole
column, SELECT age*2+10 FROM . . ., which CryptDB computes
using HOM, and (2) re-encrypted in the proxy, creating a new col-
umn (call it aux) on the DBMS server consisting of the newly en-
crypted values. Finally, the original query with the predicate WHERE
salary > aux should be run. We have not been affected by this
limitation in our test applications (TPC-C, phpBB, HotCRP, and
grad-apply).
А по-русски можно? Я этот набор букв прочесть не могу. Если бы мог - читал бы форумы где постят первоисточник как есть, а не в переводе как здесь.
> А по-русски можно? Я этот набор букв прочесть не могу. Если бы
> мог - читал бы форумы где постят первоисточник как есть, а
> не в переводе как здесь.Ваня, ты точно уверен, что ты айтишнег? Айтишнеги обычно на уровне "Читаю без словаря" аглицким владеют. Бо все ИТ - стопроцентно амеровское изобретение... Хочишь ты этого, или нет.
Аналогично: а вы точно "Аноним" или у вас всё-таки есть имя?Я занимаюсь ИТ, но на уровне fluent английский не знаю. А документация на "техническом английском" (ну нет такого языка, и есть одновременно) отличается от написанного стройностью изложения и количеством использованных слов также как english отличается от basic english (см. вики там есть целые статьи на basic english).
Анонимность - это вещь весьма относительная. В одном месте я аноним, в другом - нет.
Как, впрочем, и уровень знания английского языка. Вы утверждаете, что "техническим английским"(хотя это далеко не basic english, а совсем другое подмножество языка) вы владеете, но в то же время затрудняетесь прочитать цитату из публикации о новом способе шифрования данных в СУБД. Парадокс.
Это не цитата из документации, а запись из блога. Как следствие она сделана не на "техническом английском", а на fluent с использованием терминов, что не одно и то же.Пример на русском:
официальный: "этот нехороший человек предаст нас при первой опасности"
разговорный: "эта редиска кинет нас на первом шухере"
> Это не цитата из документации, а запись из блога. Как следствие она
> сделана не на "техническом английском", а на fluent с использованием терминов,
> что не одно и то же.То была как раз цитата из официальной документации: http://people.csail.mit.edu/nickolai/papers/raluca-cryptdb.pdf
не стоит спорить об ощущениях - это бессмысленно
> Если "salary>age" и "salary>10" катит, значит значения обоих полей нам известны.это высказыние неверно (rtfm про гомоморфное шифрование). дальнейшая логика, как и последующеие, постренные на его основе
"Гомоморфное шифрование — криптографическая система, которая позволяет проводить определенные математические действия с открытым текстом путем произведения (в общем случае других) операций с зашифрованным текстом.
Существует несколько частично гомоморфных систем шифрования. Например, RSA гомоморфна для операции умножения.
В 2009 году впервые была предложена полностью гомоморфная система, то есть гомоморфная для операций умножения и сложения одновременно, что дает возможность выразить любую математическую функцию."И?? В статье явно указано что математические операции выполнять он не умеет, только прямые сравнения.
Если уж посылаете на*** - так посылайте грамотно.
Если "salary>age" и "salary>10" катит, значит значения обоих полей нам известныЗначения нам не известны, но сравнить можем.
существуют крипто шифры которые не нарушают отношения больше-меньше.
Но нарушаю. операции умножения\сложения.
Спасибо за ответ. По поводу сравнения двух зашифрованных чисел понятно.Но если salary - число и мы можем сравнить её с любым другим незашифрованным числом и узнать результат сравнения ("salary > 10"). Ээээ... Где здесь шифр? По сути мы точно знаем значение salary, иначе не можем сравнить. Или можем любое число зашифровать по тому же алгоритму и сравнить, но тогда мы с тем же успехом могли бы расшифровать и salary и не городить огород.
> Но если salary - число и мы можем сравнить её с любым
> другим незашифрованным числомПочему незашифрованным? К числу можно применить точно такое же необратимое преобразование, как и к данным поля.
Если мы можем сравнивать, значит мы можем и вычислять. Это житейская логика. Нельзя сравнить два неизвестных числа, значит что-то нам о них известно. И если о целом числе известно что оно больше 3 и меньше 5, значит это 4 и ни черта это не шифрование.Могу жёстко ошибаться, но пока так :).
> И если о целом числе известно что оно больше 3 и меньше 5, значит это 4 и ни черта это не шифрование.Только клиент знает, что это тройка и пятерка, как и то, что целое число - 4. Но пока все эти числа дойдут до базы в SQL-запросах, они будут зашифрованы на прокси (к которому злоумышленник или админ облака не имеет доступа и ключа шифрования не знает), и будут числа, к примеру, 3 => 6468461, 5 => 6468463 и 4 => 6468462 (третье физически лежит в базе). Очевидно, первое меньше, чем третье, а второе больше, но злоумышленнику это ничего не даст, поскольку он не знает расшифрованных значений этих чисел. Если он захочет написать запрос вроде "...where x > 3 and x < 5", то без известного ключа шифрования этот запрос зашифруется не так, как у авторизованного пользователя (или вообще уйдет нешифрованным), и СУБД получит совсем другие числа (к примеру, 3 => 8888881 и 5 => 8888883, или в открытом виде 3 и 5), и поле x=6468462 не пройдет проверку
Хотя я всё это и так понимал, но спасибо за объяснение. Я смотрю на это глазами клиента SaaS, которому нужны ГАРАНТИИ. Если используется шифр Цезаря (ваш пример) - то это не шифр, и гарантий криптостойкости он не несёт. Если RSA - то вряд ли мы получим красивые цифры.Идея понятна, реализация нет. На вики (даже не вики) пишут что уже есть возможность осуществлять умножение и сложение над зашифрованными числами, почему бы не использовать её? Ну да ладно, это вопрос к разработчикам.
Ещё раз спасибо.
Это что за таинственные секретные стойкие никому не известные шифры, которые сохраняют операцию сравнения больше-меньше?
Да и замедление на 10-25% это не "всего на", а очень много.
Позволю себе усомниться в цифири.Была такая СУБД - Trusted Oracle. Так вот, там замедление в сравнении с одноверсионной обычной СУБД было _в разы_.
Э, а крипто к FGAC каким боком?
Получше владеть предметом стоит. FGAC во времена Trusted Oracle как класс отсутствовало. Это называется ныне Oracle Label Security и к VPD отношения не имеет.Трастед Оракл отличался тем, что хранил данные на диске в зашифрованном виде и расшифровывал их в момент прогрузки в память. Частями. И криптовал все и вся, в том числе содержимое областей памяти. Даже физическая кража сервера не давала доступа к данным. Ни в каком виде.
здрасти. криптовать данные оракл начал с восьмерки (а как бы даже и не с девятки? в девятке как минимум обфускейшн пак уже был, щас не скажу точно). и трастед оракл занимался не криптованием, а именно что аксесс контролем. во всяком случае, если верить докам. руками я его не щупал.
> Получше владеть предметом стоит. FGAC во времена Trusted Oracle как класс отсутствовало.
> Это называется ныне Oracle Label Security и к VPD отношения не
> имет.Это точно, знание - сила. RTFM, который называется oracle label security guide, чтобы вдруг узнать, что OLS - это VPD.
Это как цена - цена может быть большая, но приемлемая. Тут нужно смотреть - что мы приобретаем такой ценой.
Какой-то берд. Убили весь функционал СУБД, нахрена нужно такое решение. Если уж хочется секьюрности, её нужно делать на уровне самого приложения (т.е. отсылать уже шифрованные блобы только нужных кусков), либо использовать k/v хранилище с подобным решением.
По-моему фишка в том, что такая схема позволяет производить дедупликацию данных и прочие профиты.
смысл ихней системы как раз в том, что ничего переделывать не нужно в существующем коде и с большой вероятностью всё будет работать. если судить из новости, они вроде запустили phpbb таким образом.
это всё так если субд mysql и её юзают как kей-value хранилище
так а смысл тогда от облачной базы данных? если в облаке хранить только шифрованные блобы, как искать по базе без предварительного скачивания всей базы? ребята сделали очень интересную и нужную штуку
так и с этой херней искать не сможешь, кроме совсем тривиальных неинтересных случаев.смысла от облачной базы всегда мало, независимо от топика.
> так и с этой херней искать не сможешь, кроме совсем тривиальных неинтересных
> случаев.
> смысла от облачной базы всегда мало, независимо от топика.Смысл в том, чтобы успокоить хомячье, что даже имеющий физический доступ к облачному оборудованию, якобы ничего не сможет расшифровать. Мамой клянусь ;))))))
>> так и с этой херней искать не сможешь, кроме совсем тривиальных неинтересных
>> случаев.
>> смысла от облачной базы всегда мало, независимо от топика.
> Смысл в том, чтобы успокоить хомячье, что даже имеющий физический доступ к
> облачному оборудованию, якобы ничего не сможет расшифровать. Мамой клянусь ;))))))Даже в случае изъятия винтов АНБ/ЦРУ/КНБ/ФСБ и прочими трехбуквенными конторами. Ж))))))
Ну, не "успокоить хомячьё", а дать ГАРАНТИЮ серьёзным конторам что тот же SaaS или хостящийся интернет-магазин никто кроме владельца не увидит.
> Ну, не "успокоить хомячьё", а дать ГАРАНТИЮ серьёзным конторам что тот же
> SaaS или хостящийся интернет-магазин никто кроме владельца не увидит.Гарантию может дать только покойник. Что не встанет.
Цена вопроса может быть такой, что гарантии тупо идут лесом.
Есть такое соображение, как "обеспечение национальной безопасности". Советую посмотреть "Враг государства". Весьма близко к существующим реалиям в подобных случаях.
PS. Фил Циммерман не зря в тюрячке сидел, знаешь?
Принятые в качестве ГОСТА криптографические алгоритмы дают математическую гарантию что на существующем уровне развития алгоритмов и техники их нельзя взломать быстрее чем за N месяцев.Закон о защите персональных данных чётко определил критерии секретности данных и способов их защиты. Так что не нужно изобретать велосипед, достаточно лишь адаптировать предложенные меры к вашей ситуации. Для самых важных данных там предлагается компьютер не подключённый к сетям и стоящий в запертой комнате. Но закон о персональных данных, а не о напр. коммерческой тайне, так что предложенные меры защиты можно усилить.
Для целей гос.безопасности используются более серьёзные ограничения, так напр. в армии США используется топливо не пригодное для использования в гражданских автомобилях, хотя армейские машины могут использовать гражданское топливо (сейчас ограничено отменяют в связи с сокращением военного бюджета); интерфейсы (и протоколы) компьютерной техники, не совместимые с выпускаемыми (т.е. украденный компьютер никуда не подключишь); изолированные и защищённые сети данных. Ещё раз: для гос.безопасности, а не для штабных крыс.
ванюша, какой же ты, всё-таки, сказочный дурачок…
> Ну, не "успокоить хомячьё", а дать ГАРАНТИЮ серьёзным конторамГарантию что необращаемый алгоритм вдруг не окажется обращаемым ? Особенно когда под рукой вся база, известны действия, результаты, и куча времени для анализа ?
Многим подойдет, особенно если цена за сервис относительно небольшая, а данные не сверхсекретны
В основе криптографии как раз и лежит утверждение что злоумышленик заполучил зашифрованные данные, имеет все возможные данные об алгоритме шифрования и кучу времени для анализа. Единственное что ему не известно - секретный пароль. И существующие алгоритмы имеют математическую гарантию криптостойкости.
> так и с этой херней искать не сможешь, кроме совсем тривиальных неинтересных
> случаев.ну у авторов "херни" в тривиальный и неинтересный случай вписался как минимум phpBB
> смысла от облачной базы всегда мало, независимо от топика.
аргументы? гипножаба нашептала?
Тривиальных - да. Неинтересных - нет. Можно подумать, что кто-то на больших объёмах ищет по чему-то кроме тривиальных сравнений полей. А сравнивать (и, следовательно, строить индексы) здесь можно.
Строить индексы по чему? По зашифрованным данным? И по какому признаку определять, что в зашифрованной странице находятся данные, отвечающие, к примеру, признаку не полностью?
> И по какому признаку определять,
> что в зашифрованной странице находятся данные, отвечающие, к примеру, признаку не
> полностью?сам то понял что сказал? кроме шуток, я серьёзно не понял твой вопрос
К примеру, когда в страницу попадает не вся строка.
> так а смысл тогда от облачной базы данных? если в облаке хранить
> только шифрованные блобы, как искать по базе без предварительного скачивания всей
> базы? ребята сделали очень интересную и нужную штукуТы б погуглил по запросу TDE. Много интересного узнаешь. За умного, глядишь, сойдешь.
> Ты б погуглил по запросу TDE. Много интересного узнаешь. За умного, глядишь,
> сойдешь.Encryption of the database file is performed at the page level. The pages in an encrypted database are encrypted before they are written to disk and decrypted when read into memory
ты б сам сначала погуглил. а то за умного пока не сходишь
>> Ты б погуглил по запросу TDE. Много интересного узнаешь. За умного, глядишь,
>> сойдешь.
> Encryption of the database file is performed at the page level. The
> pages in an encrypted database are encrypted before they are written
> to disk and decrypted when read into memory
> ты б сам сначала погуглил. а то за умного пока не сходишьЯ, если чо, в Оракле работаю. Технарем. А ты только из гугола узнаешь обрывки сведений.
> Я, если чо, в Оракле работаю. Технарем. А ты только из гугола
> узнаешь обрывки сведений.мне должно стать стыдно? ты назвал технологию, я прочитал о ней, увидел что она предоставляет совсем не то, о чём новость. ещё вопросы? прозрачное шифрование базы на физическом уровне это очевидное и давно изобретённое решение. а шифрование на уровне данных - я в первый раз увидел такую реализацию
Не понятно как это поможет в облаке?
Как в облаке реализовать безопасное хранение и работу с ключом?
Ключ - на твоем сервере, в твоём приложении. База - в облаке. База не может расшифровать твои данные, но может сделать над ними некоторые операции (в частности - сортировку).
Т.е. база будет вести операции, не расшифровывая данные? Но тогда набор операций будет очень небольшим и сами операции будут требовать существенно больших затрат.
Сейчас только сравнение (хотя теоретически могли бы сделать сложение и умножение).Замедление 10-25%.
> Т.е. база будет вести операции, не расшифровывая данные? Но тогда набор операций
> будет очень небольшим и сами операции будут требовать существенно больших затрат.Я не понимаю, вы что, совсем рехнулись? Как база может вести операции, не расшифровывая данные? Даже Оракл не смог этого сделать и придумал TDE.
> Я не понимаю, вы что, совсем рехнулись? Как база может вести операции,
> не расшифровывая данные? Даже Оракл не смог этого сделать и придумал
> TDE.а терь читаем текст новости. да, пора бы, уже покомментил, поязвил. можно и прочитать
А приложение то где будет? Если само приложение не в облаке, пусть даже и на другом, тогда вообщее не вижу смысла держать базу в облаке.
А если приложение тоже в облаке, то как там безопасно хранить ключ?
Приложение в облаке, данные в облаке, пароль у вас. Остальное - вопросы реализации.
> А приложение то где будет? Если само приложение не в облаке, пусть
> даже и на другом, тогда вообщее не вижу смысла держать базу
> в облаке.
> А если приложение тоже в облаке, то как там безопасно хранить ключ?зачем приложение в облако совать? Облако для базы хорошо надежностью храения и доступностью данных, а приложение может быть хоть на планшете у клиента.