Функции шифровки mcrypt


Содержание

Функции шифрования на основе mcrypt

Я узнал здесь, что небезопасно разрабатывать алгоритмы шифрования с нуля. Учитывая этот совет, я сделал пару функций шифрования на основе mcrypt:

  1. Безопасны ли они?
  2. Как насчет IV? Можно ли просто добавить его в конец зашифрованной строки?
  3. Было бы лучше /быстрее сделать все это с помощью модуля, то есть с помощью mcrypt_module_open ?

3 ответа

Нет, это не безопасно. Для простоты предположим, что ваши данные D ровно на один блок. Затем зашифрованный текст содержит 3 16-байтовых блока следующим образом.

= D xor AES (IV) || MD5 (D) xor AES (IV + 1) || IV

(Обычно для сообщения обычно добавляется сообщение IV, но здесь это не имеет значения).

Если злоумышленник может угадать D, то злоумышленник может получить AES (IV) и AES (IV + 1), а затем генерировать другой действительный шифротекст, вычисляя

D ‘xor AES (IV) || MD5 (D ‘) xor AES (IV + 1) || IV

для любого сообщения, которое ему нравится.

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

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

Вещи, которые могут быть или не быть проблемой:

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

Вы не используете укрепление ключа. Это делает его таким, что грубый ввод пароля будет проще, чем грубо заставлять сам ключ, а это значит, что большая часть вашего алгоритма шифрования де-факто слабее, чем заявлено. Я рекомендую для этого bcrypt ; Я считаю, что он включен в php 5.3 +.

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

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

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

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

mcrypt_encrypt

(PHP 4 >= 4.0.2, PHP 5, PHP 7 = 1.0.0)

mcrypt_encrypt — Шифрует текст с заданными параметрами

Эта функция объявлена УСТАРЕВШЕЙ начиная с PHP 7.1.0. Использовать эту функции крайне не рекомендуется.

Описание

Список параметров

Одна из констант MCRYPT_ciphername или название алгоритма в виде строки.

Ключ, с которым будут шифроваться данные. Если длина ключа не соответствует требованием шифра, то будет возвращено FALSE и выдано предупреждение.

Данные, которые будут зашифрованы с помощью шифра cipher и режима mode . Если размер данных не кратен размеру блока, то они будут дополнены симвами ‘\0‘.

Размер возвращаемого текста может быть больше размера исходных данных data .

Одна из констант MCRYPT_MODE_modename , либо одна из следующих строк: «ecb», «cbc», «cfb», «ofb», «nofb» и «stream».

Используется для инициализации в режимах CBC, CFB, OFB, а также в некоторых алгоритмах в режиме STREAM. Если переданный IV размер не поддерживается режимом сцепления или IV не был передан, а режим сцепления его требует, функция сгенерирует предупреждение об ошибке и вернет FALSE .

Возвращаемые значения

Возвращает строку с зашифрованными данными или FALSE в случае возникновения ошибки.

Список изменений

Версия Описание
5.6.0 Некорректные размеры ключа key и инициализирующего вектора iv более не принимаются. Теперь в случае некорректных входных параметров Функция mcrypt_encrypt() будет возвращать FALSE и вызывать предупреждение. Ранее в подобном случае ключ и инициализирующий вектор дополнялись до необходимого размера с помощью символов ‘\0‘.

Примеры

Пример #1 Пример использования mcrypt_encrypt()

# ключ должен представлять собой случайную бинарную строку.
# Для преобразовангия строки в ключ используйте scrypt, bcrypt или PBKDF2
# Ключ задается в виде строки шестнадцатеричных чисел
$key = pack ( ‘H*’ , «bcb04b7e103a0cd8b54763051cef08bc55abe029fdebae5e1d417e2ffb2a00a3» );

# Показываем длину ключа.
# Длина ключа должна быть 16, 24 или 32 байт для AES-128, 192 и 256 соответственно
$key_size = strlen ( $key );
echo «Длина ключа: » . $key_size . «\n» ;

$plaintext = «This string was AES-256 / CBC / ZeroBytePadding encrypted.» ;

# Создаем случайный инициализирующий вектор используя режим CBC
$iv_size = mcrypt_get_iv_size ( MCRYPT_RIJNDAEL_128 , MCRYPT_MODE_CBC );
$iv = mcrypt_create_iv ( $iv_size , MCRYPT_RAND );

# Создаем шифрованный текст совместимыс с AES (размер блока = 128)
# Подходит только для строк не заканчивающихся на 00h
# (потому как это символ дополнения по умолчанию)
$ciphertext = mcrypt_encrypt ( MCRYPT_RIJNDAEL_128 , $key ,
$plaintext , MCRYPT_MODE_CBC , $iv );

# Добавляем инициализирующий вектор в начало, чтобы он был доступен для расшифровки
$ciphertext = $iv . $ciphertext ;

# перекодируем зашифрованный текст в base64
$ciphertext_base64 = base64_encode ( $ciphertext );

echo $ciphertext_base64 . «\n» ;

# Результирующий шифрованный текст не имеет целостности или аутентичности и не
# защищен от атак padding oracle.

$ciphertext_dec = base64_decode ( $ciphertext_base64 );

# Извлекаем инициализирующий вектор. Длина вектора ($iv_size) должна совпадать
# с тем, что возвращает функция mcrypt_get_iv_size()
$iv_dec = substr ( $ciphertext_dec , 0 , $iv_size );

# Извлекаем зашифрованный текст
$ciphertext_dec = substr ( $ciphertext_dec , $iv_size );

# Отбрасываем завершающие символы 00h
$plaintext_dec = mcrypt_decrypt ( MCRYPT_RIJNDAEL_128 , $key ,
$ciphertext_dec , MCRYPT_MODE_CBC , $iv_dec );

шифрование — Как удалить функции mcrypt в Stack Overflow

Модуль mcrypt устарел в PHP 7.1, поэтому я должен реорганизовать мои старые функции шифрования / дешифрования с помощью функций openssl. На самом деле я не нашел способа сделать это.

Моя главная проблема заключается в следующем: сценарий все еще должен иметь возможность дешифровать существующие зашифрованные данные. У меня нет шансов расшифровать мою функцию и снова зашифровать данные новой функцией!

Вот мой существующий код:

ОБНОВИТЬ:
Вот как я пытался это решить — чтобы получить тот же $ iv, я взял тот же код, что и в старой функции, и попытался реализовать его так, как описано здесь: php: mcrypt_encrypt to openssl_encrypt и проблемы OPENSSL_ZERO_PADDING


Я надеюсь, что вы можете дать мне хорошие советы.

Решение

Наконец-то я нашел решение — спасибо всем за помощь и поддержку, которые подтолкнули меня в правильном направлении и задали правильные вопросы. Главное, что я пропустил, это ECB-Mode (я взял CBC …). Так что все вещи с $ iv на самом деле не были нужны.

Для завершения ответа здесь мои новые функции:

Статья Краткое знакомство с алгоритмами. Серверный шифровальщик на PHP. Mcrypt и SHA256.

DefWolf

Mod. Cryptography

Advanced Encryption Standard — это симметричный алгоритм блочного шифрования.
Блочное шифрование — это когда информация разбивается на блоки и шифруется кратными блоками например, 8-ми или 16 байтам.
Данный алгоритм был принят правительством США в качестве стандарта в результате конкурса, проведенного между технологическими институтами. Надежным ключом считается ключ в 128 бит и больше, напоминаю, что 1 байт = 8 битов ). 128 байт делятся на группы из 8- ми рядом стоящих бит так, чтобы в результате получился массив. Байт — это основной элемент, которым оперирует алгоритм AES. Значение байта задается в шестнадцатеричной системе. Например: 10101100 = 1010 1100 = АС. Старший бит — это единичный бит числа, отвечающий за самую большую степень двойки. Байт делится на 2 группы: старшие биты в данном случае — это 1010 идут первыми, а младшие 1100 — вторыми. Алгоритм основан на подстановках, перестановках и линейных преобразованиях, каждый из которых выполняется на блоках данных по 16 байтов. Все операции выполняются по несколько раз и называются раундами. Во время каждого раунда уникальный ключ рассчитывается из ключа шифрования и включается в вычисления. Основываясь на блочной структуре AES, изменение отдельного бита либо в ключе, либо в блоке открытого текста приводит к совершенно другому блоку зашифрованного текста.

SHA-256 — это хеш функция, созданная Агентством национальной безопасности США весной 2002 года. SHA 256 раздробляет информацию на части по 512 бит и производит ее криптографическое «смешивание», а затем выдаёт 256-битный хеш-код. Всю это процедуру он повторяет 64 раза.
SHA256 имеет длину 64 символа. Каждый символ — это цифра от 0 до 9 и/или буква от A до F, которые формируют 4 бита информации. Таким образом, весь хеш равняется 64 x 4 = 256 битов информации. Именно поэтому в названии функции SHA256 присутствует 256.

PHP-Mcrypt — это интерфейс библиотеки mcrypt, которая поддерживает широкий набор алгоритмов.

Что же теперь перейдем к самому шифровальщику:

Параметры функции encrypt_decrypt:

  • $action — шифровать/дешифровать
  • $string — текст файла
  • $secret_key — ключ
  • $encrypt_method — метод шифрования, о нем чуть позже
  • $iv — ненулевой инициализирующий вектор.

Ко всем зашифрованным файлам добавляет расширение .FS .Функция encfile принимает в качестве аргумента файл и проверяет не является ли он каким либо важным файлом, который может навредить системе или этот файл создан нашей программой, например Readme.html, в котором мы оставим сообщение администратору, а также проверяет был ли файл зашифрован. Также она делает дефейс главной страницы сайта, код которой берет с pastebin.

Далее функция encdir переходит из директорию в директорию и вписывает в файл зашифрованный код, а функция shell вставляет бэкдор во все файлы с расширением .php

Зашифровать, расшифровать данные по ключу в PHP

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

Рассмотрим основные методы шифровки

base64 — позволяет шифровать и расшифровывать данные алгоритмом MIME base64. Он не использует ключей и его часто используют для скрытия ссылок в php.

Примеры:

Как видно мы использовали сначала операцию base64_encode и получили шифр: PGEgaHJlZj0iIyI+0KHRgdGL0LvQutCwPC9hPg== , а затем подставили его в base64_decode и получили ссылку обратно.

md5 — позволяет хэшировать данные в одностороннем порядке. То есть в отличие от base64, вы уже не сможете их расшифровать обратно. Часто md5 используют для хранения паролей в БД, но в последнее время зашифрованную комбинацию md5 стало легко найти в таблицах по расшифровке, любезно предоставленную многими сайтами и алгоритмами. Поэтому для хранения паролей md5 лучше заменять на Blowfish алгоритмы.

Пример:

Шифрование по ключу

И последний пример шифровки/дешифровки, о котором я хотел рассказать использует ключ (как пароль). То есть в функцию шифрования вы передаете уникальный ключ, код шифруется вместе с ним. Для расшифровки вы должны предоставить функции зашифрованный код и ключ, который знаете только вы. Пример использования функций в самом низу кода.

$str = «Булочки, которые надо зашифровать!
По ключу «;
$code = strToHex(__encode($str, ‘My#key-do-36-simvolov’));
echo ‘Зашифрованный код: ‘.$code.»
«;

$str = __decode(hexToStr($code), ‘My#key-do-36-simvolov’);
echo ‘Расшифрованный код: ‘.$str.»
«;
?>

Шифровать можно с html содержимым. Длина ключа должна быть не более 36 символов.

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

Конечно, любой код можно расшифровать/взломать и этот не исключение, поэтому используйте надежные методы шифрования.

Прячем JavaScript-код на фронтенде от посторонних

Рассказывает веб-разработчик Денис Лисогорский

Давайте представим ситуацию, когда вы и ваша команда пишете интересный и сложный код на JavaScript. Причём этот код в кратчайшие сроки нужно использовать в проекте. Если его функциональность действительно уникальна, то в процессе разработки и у вас, и у членов команды вполне резонно возникнет вопрос: «Как защитить код от копирования?».

Как защитить код: веб-сокеты, крипторы и обфускация

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

Итак, есть несколько вариантов защиты кода:

  1. Использовать веб-сокеты.
  2. Использовать крипторы.
  3. Сделать обфускацию кода.

Крипторы приводят код в нечитаемый вид, используя, как правило, base64 (что неизбежно приводит к увеличению объёма кода примерно на 30%). Затем к полученному результату прибавляется так называемая «соль» — набор символов, который при разборе кода функцией-дешифровщиком используется в качестве ключа. Ну а потом вся строка кода обычно выполняется через eval(). Проблема крипторов в том, что если понять принцип их работы, отсечь «соль» и декодировать, то сразу становится доступен весь код в его исходном виде.

Обфускаторы же изменяют сам код, вставляя между операторами нечитаемые символы, меняя имена переменных и функций на набор визуально непонятных символов. При этом объём кода также сильно увеличивается из-за вставки дополнительного псевдокода, а также замены символов на hex, когда любые символы переводятся в их hex-значения (например, латинская буква ‘e’ может быть записана как ‘\x65’, причём это прекрасно интерпретируется любым браузером). Можете посмотреть, как работает перевод в hex через любой сервис Text To Hex, например на Crypt Online.

Применение обфускаторов сильно усложняет дальнейшую отладку кода, поскольку это необратимый процесс. К тому же в некоторых случаях они могут повлиять на функциональность кода. Попробовать обфускаторы можно на любом сервисе обфускации, к примеру этом или этом. Также в Сети можно найти платные крипторы-обфускаторы, в настройках которых вы сможете указывать степень защиты, время жизни скрипта и прочее, при этом скрипт будет намертво привязан к вашему домену, т.е. для дешифровки будет использоваться уникальное для вашего хоста значение. Стоимость таких крипторов начинается от 45 $. Кроме этого, перед обфускацией вы можете предварительно минимизировать код, заменив все имена переменных и функций на их односимвольные синонимы. Отличный и очень популярный инструмент на Node.js — UglifyJS, который работает как в автоматическом режиме (скажем, через Gulp), так и в режиме командной строки.

ZIP Service, Москва, можно удалённо, от 100 000 ₽

Также есть всем известный Closure Compiler от Google, который кроме минимизации анализирует JavaScript-код, удаляет мёртвый код, переписывает и сводит к минимуму то, что осталось. Он также проверяет синтаксис, ссылки на переменные и типы и предупреждает об общих ошибках JavaScript. Имеет хорошо документированный API.

Кроме предложенных методов можно сделать следующее:

  • использовать WebStorage и скрывать там JavaScript код;
  • прятать часть кода в отдельном файле на сервере и вызывать его через XMLHttpRequest ;
  • использовать побитовые операторы для замены чисел на наборы скобок и знака

;

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

    Зашифровка кода на примере JavaScript-калькулятора

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

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

    По итогам работ в браузере вы увидите нечто такое:

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

    При этом никто ведь не знает, что здесь зашифрован именно скрипт. Это может оказаться какой-то параметр, текст или изображение. Через base64 можно зашифровать всё что угодно.

    Поищем в коде функцию glob() , которой передаётся шифрованная строка. Вот она: glob=function(s)


    Видим ещё несколько функций sfd() и rty() . Ищем эти функции. Вот они:

    На этом месте многие закончат попытки расшифровки и оставят ваш сайт в покое.

    Рассмотрим алгоритм подробнее.

    Как защитить JavaScript от копирования на своём сайте

    Первым делом указываем в футере сайта путь на скрипт и тут же кодируем его:

    В строке выше мы говорим интерпретатору PHP взять файл script.js, далее закодировать его через base64, прибавить строку ‘K’ и всё это записать в переменную $filebase64 .

    Добавление строки ‘K’ (это может быть любая латинская буква или комбинация букв или цифр) защищает нас от того, что желающий скопировать ваш скрипт расшифрует его с помощью alert() или онлайн-дешифратора. Ведь с дополнительными символами скрипт не будет работоспособен.

    Затем где-то дальше в коде вызываем скрипт:

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

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

    Разбираем подробно что здесь происходит.

    Наша основная функция glob() принимает один параметр s . Он сразу передаётся функции substring() с параметром —

    [] (это равно 1 в зашифрованном виде), которая извлекает из s строку начиная с первого символа и до конца. Следовательно, если мы в PHP-коде в качестве строки прибавляли более одного символа, скажем три, то нам нужно будет в функции substring() указать 2+(-

    []) . Либо путём шифрования цифр через побитовые операторы мы можем создать запутанную формулу, часть переменных которой мы можем прятать в cookies или sessionStorage, что сделает крайне затруднительным понимание того, какое количество символов необходимо отбросить для дешифровки кода.

    Пример замены цифр через побитовый оператор

      -1 можно заменить на

    []
    1 можно заменить на —

    []
    0 можно заменить на

    Далее полученный результат принимает функция rty() . Эта функция представляет собой набор символов, в частности: this[«\x61\x74\x6F\x62»] ;

    Попробуйте ввести это в консоли браузера и вы увидите, что на самом деле делает эта функция. Например, вы увидите:

    Т.е. набор символов — это зашифрованная функция atob() , которая, согласно описанию на MDN, декодирует строку, закодированную с использованием base64.

    Результат декодирования получает функция sfd() . Она также представляет собой набор символов: this[«\x65\x76\x61\x6C»]; .

    Вы уже догадались, что нужно сделать? �� Выполните в консоли браузера и вы увидите:

    Здесь, думаю, уже объяснять ничего не надо. Все мы знаем, что функция eval() выполняет скрипт, полученный из строки. «Плохая практика», как сказали бы многие, для обычного кода, но в нашем случае это безопасная и нужная функция для реализации нашей идеи. К тому же напрямую к этой функции пользователь не сможет получить доступ.

    Наверное, вы задались вопросом, а каким же образом функции зашифрованы в наборе символов? Очень просто: набор символов — это текст, преобразованный в шестнадцатеричную систему счисления. Т.е. это текст в формате hex (hexadecimal), в котором можно зашифровать любые символы.

    Таким образом, наша расшифрованная функция выглядит так (специально разбил по строчкам, чтобы было наглядно):

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

    Вы можете пойти и дальше. Если каким-то образом кто-то всё же расшифрует ваш скрипт, немного усложните его, чтобы людям было сложнее модифицировать его. Например, можно поговорить о побитовом операторе ^ , c помощью которого можно творить чудеса. Например, a^b^b будет равно a . В качестве b может быть использован ключ, который мы зашифруем где-то выше…

    Всё будет работать как и раньше, но собьёт с толку нехороших копипастеров.

    За материал благодарим нашего подписчика Дениса Лисогорского

    Базу данных не стащить: правильные способы защитить данные в таблицах БД

    Содержание статьи

    Как же ошибаются те люди, которые доверяют защиту данных исключительно самой
    СУБД. Мол, если пароль на подключение хороший и версия демона – самая последняя,
    то все будет нормально. Ничего подобного. Базы как сливали, так и будут сливать.
    А наша задача – сделать их нечитаемыми для тех, кому они не предназначены.

    Актуальная проблема из мира информационной безопасности – обеспечить
    сохранность данных. Есть ситуации, в которых даже при наличии серьезной защиты
    системы, сохранность данных оказывается под большим вопросом. Как так? Могу
    привести пример из личного опыта, когда в разглашении информации был виновен
    засланный сотрудник конкурирующей компании. Находясь на рабочем местом и будучи
    технически подкованным, он взламывал сервера баз данных банальным брутфорсом
    через терминальное соединение. Базы с клиентами «засланец» перепродавал другим
    компаниям, а «интересная» информация о ведении бизнеса отправлялась сотрудникам
    силовых структур. Что из этого вышло, объяснять излишне.

    Вообще, имея физический доступ к локальной сети, инсайдер мог поступить
    гораздо проще: атаковать программу, которая работает с базой данных. Нередко
    сценарий взлома сводится к тому, что из программы разными способами извлекаются
    конфиги для подключения к базе. Захватив ту же 1С, которая хранит в себе конфиги
    подключения к базе (в том числе, шифрованный обычным XOR’ом пароль),
    злоумышленник получает доступ к самой базе. Особо не стесняясь, он может ее
    выкачать, модифицировать или просто удалить. Такая брешь в защите способна
    сыграть злую шутку, особенно в корпоративной среде.

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

    Шифрованию – быть!

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

    Компания Spelabs (www.spellabs.ru/spellabsCrypto1C.htm)
    как-то анонсировала продукт, организующий дополнительную безопасность
    бухгалтерских 1С на уровне шифрования данных, причем на полностью прозрачном
    уровне. Пользовательские приложения, не подозревая о надстройке, работали в
    обычном режиме. Увы, компания прекратила разработку этого направления. Но
    реально обойтись и без подобных инструментов, ведь для шифрования сгодятся даже
    штатные средства СУБД!

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

    • AES_ENCRYPT() — шифрование AES
    • AES_DECRYPT() — расшифровка AES
    • COMPRESS() — возвращение результата в бинарном виде
    • DES_ENCRYPT() — шифрование DES
    • DES_DECRYPT() — дешифрование DES
    • ENCODE() — шифрование строки поверхностным паролем (на выходе
      получается шифрованное слово первоначальной «plaintext» длины
    • DECODE() — расшифровка текста, обработанного функцией ENCODE()
    • ENCRYPT() — шифрование с помощью Unix’ового системного вызова crypt
    • MD5() — подсчет MD-5 суммы
    • SHA1(), SHA() — подсчет SHA-1 (160-бит)

    Для их применения надо лишь чуть изменить свои SQL-запросы, добавив в нужном
    месте функции AES_ENCRYPT() или DES_ENCRYPT(), которые считаются наиболее
    надежными в MySQL на текущий момент. Например, так:

    INSERT INTO t VALUES (1,AES_ENCRYPT(‘text’,’password’));

    Приятно признать, что хорошие программисты эти функции используют. Часто во
    время проведения SQL-инжекции мне приходилось ломать голову и определять
    функцию, которую использовал кодер для крипточки данных. В результате, требуется
    производить те же AES_DECRYPT(AES_ENCRYPT()) наряду с unhex(hex()).

    Помимо симметричного шифрования, когда упаковка и распаковка текста
    производятся одним и тем же ключом (общим для двух участников обмена
    сообщениями), поддерживается и ассиметричное криптование. Идея ассиметричных
    алгоритмов подразумевает наличие двух ключей – открытого и закрытого
    (секретного). Один из них используется для шифрования информации, а другой — для
    дешифрования. Если кодирование осуществляется с помощью открытого ключа, то
    расшифровать такие данные можно только с помощью парного ему закрытого.
    Предлагаю разобраться с этим на примере Microsoft SQL Server, который часто
    используется в корпоративных порталах и сложных приложениях.

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

    Одна из таких функций — EncryptByCert(), используемая для ассиметричного
    шифрования данных с помощью сертификатов. Открытым ключом тут выступает
    сертификат. Только откуда этот сертификат взять? Ответ прост – сгенерировать с
    помощью другой специальной функции. Покажу на примере, как можно сгенерировать
    сертификат с именем для andrej базы «Bank» с помощью хранимой процедуры:

    USE Bank;
    CREATE CERTIFICATE andrej
    ENCRYPTION BY PASSWORD = ‘pGFD4bb925DGvbd2439587y’
    # Для генерации с использованием подгрузки из файла
    # FROM FILE = ‘c:\Shipping\Certs\Shipping11.cer’
    # WITH PRIVATE KEY (FILE = ‘c:\Shipping\Certs\Shipping11.pvk’,
    WITH SUBJECT = ‘Employers Access’,
    EXPIRY_DATE = ’10/31/2009′;
    GO

    У нас создался сертификат! Теперь его можно без проблем использовать для
    размещения в таблице зашифрованных записей, выполняя привычные SQL-запросы:

    INSERT INTO [БАЗА].[ТАБЛИЦА]
    values( N’ДАННЫЕ ДЛЯ ЗАШИФРОВКИ’,
    EncryptByCert(Cert_ID(‘andrej’), @cleartext) );
    GO

    В этом примере неформатированный текст из переменной @cleartext шифруется
    сертификатом с именем «andrej». Зашифрованные данные помещаются в таблицу
    «ТАБЛИЦА». Уточню, что данные могут быть расшифрованы только с помощью
    соответствующего закрытого ключа (как уже было сказано, «приватного»).

    Имя функции для обратного преобразования угадать несложно: DecryptByCert(). А
    вот синтаксис более хитер, и с ним все чуть сложнее. Дело в том, что на
    приватный ключ, как правило, закладывается дополнительный пароль (passphrase).
    Его необходимо ввести, и по этой причине он обязательно будет присутствовать в
    коде запроса или процедуры. Это не очень хорошо, потому что в этом случае его
    можно быстро увести. Но с этим мы разберемся позже, когда поговорим о
    безопасности хранимых процедур. А пока – код для извлечения данных из
    шифрованной базы данных:


    SELECT convert(nvarchar(max), DecryptByCert(Cert_Id(‘andrej’),
    ProtectedData, N’pGFD4bb925DGvbd2439587y’))
    FROM [БАЗА].[ТАБЛИЦА]
    WHERE Description
    = N’Employers Access’;
    GO

    В этом примере производится выборка строк из таблицы [БАЗА].[ТАБЛИЦА],
    помеченных как «Employers Access». Пример дешифрует зашифрованный текст с
    помощью закрытого ключа сертификата «Andrej» и дополнительного пароля
    pGFD4bb925DGvbd2439587y. Расшифрованные данные преобразуются из типа varbinary в
    тип nvarchar.

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

    Прячем хранимые процедуры!

    Если ты не заметил, многое упирается в то, что вся конфиденциальность и
    целостность завязана на использование хранимых процедур или функций. Получается,
    что, получив к ним доступ и грамотно проанализировав их код, любой опытный хакер
    сможет преобразовать шифрованную белиберду в исходный текст. Конечно, добраться
    до кода процедур далеко не всегда реально, потому здесь всплывает вопрос об
    утечке программной начинки производства, а именно – логике ПО. Но именно по этой
    причине необходимо прибегать к шифрованию процедур и функций в базе. Одно из
    самых популярных и удачных средств для таких действий – это программа SQL Shield
    (www.sql-shield.com).
    После несложной установки приложения не забудь указывать дополнительный флаг
    /*sqlshield*/ с выражением «WITH ENCRYPTION» всякий раз, когда будешь создавать
    защищенную процедуру. Вот пример функции, которая исполняет простейший запрос к
    базе:

    CREATE PROCEDURE MyTest
    WITH /*sqlshield*/ ENCRYPTION
    AS
    SELECT 2+2

    Исполняем процедуру и получаем:

    Проверим, в каком виде хранится процедура, с помощью специального средства
    для ковыряния в файлах базы. Подойдет SQL Server Syscomments Decryptor (www.geocities.com/d0mn4r/dSQLSRVD.html),
    который при отображении текста процедуры показывает одни лишь знаки вопроса.
    Все работает!

    Как облегчить себе жизнь?

    В заключение – не менее интересный продукт XP_CRYPT (www.xpcrypt.com).
    Это средство осуществляет весь тот геморрой, который мы только что проделали
    вручную. Все, что от тебя требуется, – скачать дистрибутив проги, установить ее
    на сервер (к сожалению, есть версия только для Винды), обозначить свою базу
    данных и начать химию с таблицами с помощью удобного GUI-интерфейса.

    Организуем знакомство на примере из практики. Предположим, у нас есть
    интернет-магазин, где каким-то образом хранятся данные о кредитных картах
    клиентов (распространенная ситуация, хотя это категорически запрещено!). Наша
    задача — зашифровать конкретные данные о клиентах, т.е. поля с паролем, номером
    кредитной карточки и т.п. Пока мы ничего не делали, при запросе SELECT * FROM
    tbl_CCards, СУБД возвращает все в открытом виде:

    Username Password CredCardNum
    james god 1234567890123456
    lucas sex 2894787650102827
    anna love 3234563638716434

    Напишем внешнюю функцию UDF (расшифровывается, как «User-Defined-Function»,
    подробности) для преобразования строки в SHA-хеш:

    CREATE FUNCTION ud_MakeSHA1 (@clearpass VARCHAR (8000) )
    RETURNS VARCHAR (40)
    AS
    BEGIN
    DECLARE @ret as VARCHAR(40)
    EXEC master..xp_sha1 @clearpass,@ret OUTPUT
    RETURN @ret
    END

    Отдаем команду: UPDATE tbl_CCards SET password = dbo.ud_MakeSHA1(Password).
    После чего еще раз проверяем содержимое базы той же командой. Что видим? Все
    зашифровано, все пароли захешировались!

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

    CREATE FUNCTION ud_CheckUser (@username VARCHAR(16),@clear_pass VARCHAR
    (16))
    RETURNS INTEGER
    AS BEGIN
    DECLARE @res INTEGER
    SELECT @res = count(*) FROM tbl_CCards where username=@username AND
    password=dbo.ud_MakeSHA1(@clear_pass)
    IF @res > 1 SELECT @res= 0
    RETURN @res
    END

    Проверяем исполнением команды:

    SELECT dbo.ud_CheckUser (‘anna’,’kolbaska’)
    >1 (неправильно)
    SELECT dbo.ud_CheckUser (‘anna’,’love’)
    >0 (окейно!)

    К шифрованию номера кредитной карты надо подойти более серьезно. Впрочем, мы
    не будем вникать в различного рода стандарты по информационной безопасности в
    платежно-карточной сфере (вроде PCI; хотя организации, работающие с кредитными
    картами, безусловно обязаны это делать). В бесплатной версии XP_CRYPT существует
    возможность генерации только 256-битного ключа RSA. Вот этим и можно
    воспользоваться (пусть упомянутый стандарт и требует, как минимум, 768-битного
    ключа). Я бы мог сейчас привести код по генерации публичного и приватного ключа,
    но… поступим проще. Все действия можно выполнить из понятного графического
    интерфейса, и во многих случаях оставить все на совести программы, не написав ни
    строчки кода. И поверь, будет работать!

    Пример из личного опыта

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

    ID LastName FirstName Emp
    Sum
    354 Somov Oleg
    IT-Manager M0x8900f56543
    643 Antipova Alexandra Director
    4343Lax#dsdsss
    411 Timurov Valeriy Technical Dep.
    0x2322322222

    Выборку из базы я привел абсолютно произвольную, а теперь суть идеи.
    «Безопасниками» компании было предпринято вполне благородное решение – шифровать
    данные о зарплатах, которые очень часто бывают «серыми». Инсайдер получил доступ
    к базе и сильно обломался, заимев информацию в таком виде. Однако, он не
    отчаялся и проделал следующий фокус. Резонно предположив, что человек с
    должностью директора должен получать больше, чем простой менеджер, он поменял
    соответствующие поля со значениями зарплат одно на другое, тем самым – подложив
    бухгалтерскому отделу абсолютно левую информацию. В благополучный день такая
    вещь прокатила, и все безопасники были уволены. Для справки: этим сотрудником
    был не я, как впрочем, и не безопасником.

    Так делать не стоит

    В SQL Server можно создавать четыре типа объектов (хранимые процедуры,
    представления, пользовательские функции и триггеры) с параметром WITH
    ENCRYPTION. Этот параметр позволяет зашифровать определение объекта таким
    образом, что тот можно будет использовать, но получить его определение
    стандартными способами станет невозможно. Это средство рекомендуется и
    Microsoft. К сожалению, на практике никакой защиты применение стандартных
    средств шифрования не обеспечивает! Алгоритм, используемый при шифровании
    определений объектов, выглядит так:

    1. SQL Server берет GUID той базы данных, в которой создается объект, и
      значение столбца colid таблицы syscomments для создаваемого объекта (чаще
      всего, его значение – 1 или 2) и производит их конкатенацию;
    2. Из полученного значения генерируется ключ при помощи алгоритма SHA;
    3. Этот хеш используется в качестве входящего значения при применении еще
      одного алгоритма хеширования – RSA. С его помощью генерируется набор символов,
      равный по длине шифруемому определению объекта;
    4. С этим набором символов и с реальным определением объекта производится
      операция XOR. В результате получаются данные, которые помещаются в столбец
      ctext таблицы syscomments.

    У этой схемы есть два слабых места:

    • Нам ничего не мешает заиметь исходные значения (GUID и colid) для
      выполнения тех же самых операций и получить ключ на расшифровку. Это можно
      сделать, например, использовав утилиту dSQLSRVD. Правда, для получения GUID
      базы данных (и для запуска этой утилиты) нам нужны права системного
      администратора;
    • Если у нас есть права на создание объектов в базе данных, можно
      сгенерировать точно такой же ключ для объекта, определение которого нам уже
      известно (путем сравнения шифрованного определения с незашифрованным). Ну и –
      использовать его для расшифровки значения другого объекта.

    Как можно расшифровать зашифрованные объекты на SQL Server? Есть два
    варианта:

    • Использовать утилиту dSQLSRVD. Она позволяет выбрать любой зашифрованный
      объект на сервере и записать его определение в текстовый файл;
    • Использовать хранимую процедуру DECRYPT2K. Код на создание данных хранимых
      процедур (в разных вариантах и с разными объяснениями), которые расшифровывают
      определение зашифрованных объектов, легко найти через Google.

    Зачем нужно шифрование?

    За века своего существования человечество придумало множество способов хранения тайны. В Древнем Риме, например, чтобы тайно передать письмо, брили голову рабу, писали на коже сообщение, а потом, дождавшись, когда волосы отрастут, отправляли его к адресату. Конечно, XXI век не позволяет делать дела столь неспешно, да и защита в этом примере обеспечивается только тем, что о письме никто не знает. К счастью, компьютеры, изначально созданные для взлома военных шифров, дают каждому из нас прекрасный способ хранения личных тайн – информацию можно зашифровать. То, что долгое время было доступно только государственным службам, сегодня может применить любой пользователь. И, что более существенно, даже если вы не задумываетесь над этим, у вас всегда есть тайны, достойные шифрования.

    Есть что скрывать

    «У меня нет никаких тайн, мне нечего скрывать», – часто можно услышать от пользователей, когда речь заходит о шифровании и других средствах защиты конфиденциальности. Обычно за этой фразой стоит нечто другое – «я считаю, что никто не потрудится лезть в мой телефон или компьютер, чтобы там найти что-то ценное». Но практика показывает, что это не так. Файл, сохраненный на рабочий стол компьютера или телефон, оставленный в гостиной, довольно быстро будет изучен кем-то из домочадцев. Все ли письма, фотографии и документы вы готовы показывать жене, брату, теще, детям? Возможно, там нет ничего криминального. Но готовы ли вы сообщить номер своей кредитной карты и ее PIN-код детям-подросткам? Отдать брату пароли от почты и социальных сетей?Демонстрировать все семейные фото друзьям, которые пришли в гости и на пятнадцать минут сели за компьютер? Есть ли желание объяснять жене, что Элеонора – это начальник отдела смежников на работе, а встреча с ней завтра – это совещание с участием еще десяти человек?

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

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

    Семь бед – один ответ

    Угроз, как мы видим, существует много, и от каждой из них можно придумать свой способ защиты: изолировать компьютер в запертой спальне, поставить PIN-код на включение смартфона и так далее. Но если защитить информацию не путем физической изоляции, а так, чтобы ее мог прочитать только владелец, результат будет более надежным и всеобъемлющим. Абсолютно все перечисленные неурядицы – большие и малые – могли бы не случиться, если бы важная информация, предназначенная не для всех глаз, хранилась бы в зашифрованном виде.
    Иногда вы сталкиваетесь с шифрованием, даже если не задумываетесь об этом, – например, заходя в Gmail или на сайт онлайн-банкинга по протоколу HTTPS, вы связываетесь с банком по зашифрованному каналу. Встроено шифрование и в самый популярный сегодня стандарт сотовой связи GSM. Но сегодня мы сосредоточимся на другом – шифровании данных, хранящихся на компьютере или смартфоне.

    Что такое шифрование

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

    Ваш цифровой сейф

    Самое удобное на сегодня решение по шифрованию файлов на компьютере – это создание «контейнера», который виден в системе как отдельный диск. На этот диск можно сохранять или копировать любую информацию, с ним можно работать из любой программы, он ничем, по сути, не отличается от флешки или раздела винчестера, чем и удобен. Важное «но» – на самом деле контейнер является отдельным большим файлом на вашем винчестере, доступ к которому организован через специальную программу, например Kaspersky CRYSTAL. Любой файл, сохраняемый на этот особый диск, будет «на лету» зашифрован и записан в общий файл-контейнер.

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

      • ключ (пароль) шифрования является единственной защитой информации от посторонних. Он должен быть очень длинным, трудным для подбора, – в общем, стойким. Советы по выбору стойкого пароля можно прочитать в этом посте;
      • на диске-хранилище нужно хранить всю конфиденциальную информацию;
      • вся информация на диске доступна знающему пароль. Если у вас есть разные группы информации для разных пользователей, заведите несколько хранилищ с разными паролями;
      • не держите диск-хранилище постоянно подключенным, иначе с него можно украсть файлы так же, как с обычного диска. Подключайте диск на время работы с важными данными и отключайте сразу после ее завершения;
      • информация на зашифрованном диске будет потеряна целиком, если файл-контейнер окажется хоть немного поврежден. Регулярно проводите резервное копирование файла-контейнера;
      • обязательно используйте всестороннюю защиту компьютера, такую как Kaspersky CRYSTAL, чтобы обезопасить свой пароль от троянских приложений и «клавиатурных шпионов». Действующий шпион сводит парольную защиту на нет.

    Сейф на смартфоне

    Ответом на вышеописанную проблему с кражей смартфонов стало включение в современные мобильные ОС функций шифрования. Ключевая информация в смартфоне постоянно хранится в зашифрованном виде и всякий раз расшифровывается, когда владелец вводит пароль или PIN-код разблокировки. Apple не дает пользователю глубоко управлять этой функцией, но значительное количество информации подвергается шифровке при активации защитного PIN-кода на включение смартфона/планшета. В Android в настройках безопасности имеется опция полной шифровки содержимого телефона, которая делает все данные на устройстве недоступными без ввода пароля. Для максимальной надежности в обоих случаях рекомендованы свежие версии мобильных ОС – iOS с 6.1 и Android с 4.1.

    «Облачная» защита

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

    Функции шифровки mcrypt


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

    Джейн на совещании с ИТ-менеджерами банка Acme объяснила, что безопасность компании можно рассматривать как ряд уровней (слоев) защиты. Для иллюстрации этого Джейн использует «матрешку» — комплект кукол, вкладывающихся одна в другую. Последняя из четырех или пяти этих кукол содержит в себе что-то вроде приза. Чтобы получить приз нужно один за другим удалять «слои» кукол, и если по каким-то причинам слои не могут быть удалены, добраться до приза будет труднее. Джейн объясняет, что злоумышленник, чтобы добраться до корпоративных информационных ресурсов, должен также «победить» много уровней защиты.

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

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

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

    Шифрование базы данных

    Он изложил свою точку зрения на стратегию шифрования, начав с краткого обзора процесса шифрования. Он представляет своей группе простой пример, в котором величина остатка на счете изменена дополнением секретного числа с одной цифрой. Если секретное число будет равно, например, 2, а величина остатка на с счете — 3467, то зашифрованная величина будет равна 3469. Реальная величина может быть расшифрована вычитанием числа 2 из зашифрованной величины, Джон пояснил, что этот процесс называется дешифрованием (decryption). Такую логику добавления определенного числа к реальным данным называют алгоритмом шифрования (encryption algorithm). Число 2, которое добавляется алгоритмом, называется ключом шифрования (encryption key). Исходные данные (original data) и ключ шифрования обрабатываются алгоритмом шифрования для создания зашифрованных данных (encrypted data), как показано рис.1.

    Рис 1. Механизм шифрования

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

    Алгоритмы шифрования чаще всего общедоступны; следовательно, безопасность обеспечивается выбором трудно угадываемого ключа. Если бы хакеры в этом примере должны были угадать 1-цифровой ключ, они должны были бы перебрать только 10 чисел — цифры от 0 до 9. Однако, если бы ключ состоял из двух цифр, то они должны были бы перебрать 100 чисел — от 0 до 99. Джон поясняет, чем длиннее ключ, тем более трудно угадать его.

    Пакеты, поставляемые с СУБД Oracle

    Генерация ключей . Поскольку безопасность зашифрованных данных зависит от трудности угадывания ключа, выбор надлежащего ключа — самый главный шаг в процессе шифрования. Ключ может быть любым значением данных типа RAW, но если оно выбрано не достаточно случайно, злоумышленник будет в состоянии угадать ключ. Джон предупреждает, ключ не может быть, например, именем вашего домашнего животного или вашей датой рождения; это должно быть действительно случайное число. Один младший администратор базы данных спрашивает: «Как вы сгенерируете такой случайный ключ»? Джон отвечает, что случайные числа могут генерироваться с помощью встроенного пакета DBMS_RANDOM , но криптографически стойкая генерация случайных чисел достигается использованием функции RANDOMBYTES в пакете DBMS_CRYPTO . Функция имеет один входной параметр (типа данных BINARY_INTEGER , на выходе выдается число типа данных RAW, длина которого определена входным параметром. Это число может использоваться как ключ. Джон демонстрирует это на примере простого PL/SQL-кода, показанного на листинге 1.

    Листинг 1. Шифрование данных

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

    Таблица 1. Константы для алгоритмов пакета DBMS_CRYPTO

    Первый столбец в табл. 1 — Constant Name (имя константы) — показывает константы, определенные в пакете для указания различных алгоритмов и длин ключей (Effective Key Length). Например, для указания 128-битового ключа, соответствующего стандарту Advanced Encryption Standard (AES, усовершенствованный стандарт шифрования), поясняет Джон, вы используете константу DBMS_CRYPTO.ENCRYPT_AES128 (см. строку 5 листинга 1). Чем длиннее ключ, тем меньше шансов у злоумышленника для его угадывания, но больше работы у сервера для шифрования и дешифрования. Для установления соотношения между безопасностью и нагрузкой на сервер Джон выбирает средний вариант — 128-битовый ключ и алгоритм AES.

    Затем определяется тип сцепления, которое при блочном шифровании позволяет разбивать данные на участки для шифрования, как это показано в строке 6 листинга 1. Самый распространенный формат — Cipher Block Chaining (CBC, сцепление блоков шифротекста), указывается в пакете DBMS_CRYPTO константой CHAIN_CBC . Другие варианты сцепления: Electronic Code Book ( CHAIN_ECB , электронная книга кодов), Cipher Feedback ( CHAIN_CFB , шифрование с обратной связью от шифротекста) и Output Feedback ( CHAIN_OFB , шифрование с обратной связью по выходу).

    Наконец, поясняет Джон, при блочном шифровании данные обычно шифруются в блоках по восемь символов. Если длина входных данных не кратна восьми, добавляется недостающий символ или символы; этот процесс называется дополнением (padding). Простейший вариант — дополнение нулями. Джон указывает, что этот вариант включается константой PAD_ZERO , определенной в пакете DBMS_CRYPTO , но он не считается достаточно безопасным, поскольку потенциальный злоумышленник может угадать его. Более безопасное дополнение основано на стандарте Public-Key Cryptography Standard # 5 (PKCS#5, криптографический стандарт с общим ключом), задаваемый в пакете DBMS_CRYPTO константой PKCS5, как это показано в строке 7 листинга 1. Если вы уверены, комментирует Джон, что длина данных уже кратна размеру блоков, то дополнения не потребуется, и вы можете указать это с помощью константы PAD_NONE.

    Все эти три параметра — алгоритм с длиной ключа, методы сцепления и дополнения — объединяются в один параметр, передаваемый во встроенную функцию шифрования ENCRYPT пакета DBMS_CRYPTO . Функции ENCRYPT требуется, чтобы незашифрованные данные имели тип RAW. Это преобразование делается в строке 12 листинга 1.

    В целях стандартизации, продолжает Джон, банк Acme принял решение во всех приложениях использовать алгоритм AES с 128-битовыми ключами, сцепление CBC и дополнение PCKS #5. Используя эти значения, Джон создает простейшую функцию GET_ENC_VAL , показанную на листинге 2, которая принимает только два параметра — исходные незашифрованные данные и ключ — и возвращает зашифрованные данные.

    Листинг 2. Простая функция шифрования

    Дешифрование

    Джон объясняет, что в пакете DBMS_CRYPTO есть функция дешифрования DECRYPT . Она принимает для дешифрования исходные зашифрованные данные; ключ, использованный во время шифрования; а также объединенный параметр: алгоритм, длина ключа и схемы сцепления и дополнения. Вместе с данными, которые нужно дешифровать, необходимо передавать те же самые ключ и модификаторы, использованные во время шифрования. Банк Acme использует стандартные (одинаковые) алгоритм, длину ключа и схемы сцепления и дополнения, поэтому Джон создал простую функцию для дешифрования зашифрованных данных, показанную на листинге 3. Эта функция принимает только два параметра — зашифрованные данные и ключ — и возвращает расшифрованные данные типа VARCHAR2 (преобразование данных типа RAW делается в строке 20 листинга 3).

    Листинг 3. Простая функция дешифрования

    Управление ключами

    В варианте 1, продолжает Джон, для шифрования данных во всех строках используется один ключ. В этом случае для хранения ключа существует несколько вариантов:

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

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

    Самый большой недостаток этого подхода — уязвимость ключа к воровству. Если ключ украден, все данные в базе данных поставлены под угрозу. Поэтому Джон предложил другой подход для защиты конфиденциальных данных в базах данных OLTP-систем. Такая база данных имеет таблицу ACCOUNT_MASTER , в которой хранится конфиденциальный элемент данных — имя владельца банковского счета (account holder). Столбец, содержащий это имя, ACC_NAME , должен быть зашифрован. Первичный ключ этой таблицы — ACCOUNT_NO . Таблица ACCOUNT_MASTER выглядит примерно так:

    Джон предлагает использовать разные ключи для различных строк таблицы ACCOUNT_MASTER , что устраняет риск незащищенности данных на уровне всей базы данных, если ключ крадется. Он создает таблицу ACCOUNT_MASTER_ENC для хранения зашифрованных данных (имена владельцев счетов) и другую таблицу для хранения ключей, использованных для шифрования. Эти таблицы — ACCOUNT_MASTER_ENC и ACCOUNT_MASTER_KEYS — выглядят примерно так:

    Затем Джон создает представление VW_ACCOUNT_MASTER , показанное на листинге 4, чтобы соединить эти три таблицы для получения расшифрованных данных. Он указывает на строку 8 листинга 4, в которой данные расшифровываются с помощью функции GET_DEC_VAL , рассмотренной выше. Эта функция возвращает данные типа VARCHAR2, поэтому они показываются как столбец VARCHAR2(2000); функция CAST в строке 7 преобразует их в данные типа VARCHAR2(20).

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

    Листинг 4. Представление VW_ACCOUNT_MASTER

    Публичный синоним ACCOUNT_MASTER указывает на это представление, поэтому пользователи могут извлекать из него данные. Но, спрашивает разработчик Джилл, как же пользователи смогут манипулировать данными в таблице ACCOUNT_MASTER ? Используя триггер INSTEAD OF (см. листинг 5), поясняет Джон. Этот триггер модифицирует реальные таблицы, когда пользователи вставляют строки в представление или обновляют его.

    Листинг 5. Триггер INSTEAD OF для представления

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

    Дополнительные меры

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

    Арап Нанда (Arup Nanda) (arup@proligence.com) — основатель компании Proligence (Нью-Йорк), предоставляющей высокоспециализированную расширенную поддержку решений Oracle и обучение методам обеспечения информационной безопасности. В 2003 г. он был удостоен награды » Oracle’s DBA of the Year «( администратор года баз данных Oracle). Арап — соавтор книги Oracle Privacy Security Auditing (издательство Rampant TechPress, 2003) — «Средства аудита в СУБД Oracle, обеспечивающие информационную безопасность».

    Хостинг в Европе для новичков (от 25 руб/мес) и VIP-хостинг для профессионалов (от 1000 руб/мес)

    Скидка 25% на все тарифы хостинга по промокоду STDCITF

    Шифрование и защита данных через хеш-функцию SHA-3 Keccak

    Шифрование и защита данных через хеш-функцию SHA-3 Keccak.

    Я хотел написать статью, я написал статью, всё просто)

    Рекомендуется тем, кому интересна практическая криптография.

    . Тихой ночью, сижу пишу, на радость себе, на пользу остальным) .

    SHA-3 Keccak — это современная хеш-функция третьего поколения, победившая в мировом конкурсе и выбранная NIST в качестве мирового стандарта.

    SHA-3 Keccak является криптопримитивом, она построена на конструкции Sponge, что отличает её от всех прошлых хеш-функций.
    SHA-3 Keccak сильно близка к Случайному Оракулу — идеализированной хеш-функции.
    Наличие конструкции Sponge позволяет как бы впитать исходные данные, а затем выжать из них хеш-сумму.
    Это делает её неуязвимой ко многим векторам атаки, что и позволяет её использовать в качестве криптопримитива.

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

    Криптопримитив SHA-3 Keccak устойчив к атаке на постоянный префикс и переменный суффикс.
    Криптопримитив SHA-3 Keccak устойчив к атаке на удлинение данных.

    Анализ кода SHA-3 Keccak показал, что количество алгоритмических операций не зависит от самих данных, а зависит только от их длины, что исключает атаку на время выполнения.

    Подробнее о SHA-3 Keccak как о универсальном криптопримитиве в статье по ссылке:
    (https://www.pgpru.com/biblioteka/statji/keccaksponge)

    Отличная C++ реализация SHA-3 Keccak на сайте (которую я переписал для себя всего на 200 строк кода суммарно с файлом .h и .cpp):
    (http://create.stephan-brumme.com/hash-library/)

    Примечание: SHA-3 Keccak незначительно отличается от оригинального Keccak, отличие лишь в коде заполнителя Padding, однако из-за этого выходные хеш-суммы отличаются до неузнаваемости.

    Если Вы желаете распараллелить вычисление хеш-суммы для проверки данных на подделку, то уже есть соответствующая тема:
    (Расчёт хеш-суммы большого файла в параллельном режиме для проверки целостности)


    Если Вы желаете сами своими руками создать ключ, по уже есть соответствующая тема:
    (Ручное получение энтропии для создания безопасного ключа)

    SHA-3 Keccak можно использовать для:
    1. Получения производных ключей на основе базового ключа.
    2. Для получения кода проверки на подделку (Message Auth Code — Code Verificate).
    3. Для получения потока гаммы со счётчиком — случайных чисел, которые проксориваются с данными для получения зашифрованных данных и наоборот.

    Всё это позволяет создать сетевой защищённый канал данных.
    Достаточно просто можно использовать её для шифрования файла и добавления кода защиты (Message Auth Code — Code Verificate).

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

    Итак, сначала нам нужен ключ.
    Ключ (Key) — это уникальная секретная последовательность величин определённой фиксированной длины.
    Ключи бывают 128, 256, 512 битные.
    512 битные ключи — это для особых случаев). Предел Бремерманна показывает, что ключ такой длины в нашей вселенной перебрать просто нереально.

    Далее, для защиты данных используется Код Верификации и Гамма.
    Код Верификации (Code Verificate) (его ещё называют Message Auth Code) нужен для обеспечения подлинности данных (защиты данных от подделки или ошибки (частный случай подделки)). Код Верификации добавляется к данным.
    Код Верификации напрямую зависит от ключа и данных.

    В общем виде Код Верификации вычисляется как результат хеш-функции — Hash(Key + Data).

    Гамма (Gamma) нужна для обеспечения конфиденциальности данных. Гамма накладывается на данные.
    Гамма вырабатывается поблочно, напрямую зависит от ключа и номера блока.
    Количество блоков должно быть минимально достаточным, чтобы покрыть все данные.

    Вот формула для получения минимального количества блоков гаммы:

    Len = размер данных в байтах
    Size = размер блока в байтах (равен размеру выходной хеш-суммы нашей хеш-функции)
    Count = минимальное количество блоков

    Mod(a, b) = остаток от деления a на b

    Count = Len / Size + (Mod(Len, Size) > 0)

    В общем виде Гамма вычисляется как результат хеш-функции — Hash(Key + NumberBlock)

    Далее, гамма должна быть одноразовой и она является секретной.
    Чтобы зашифровать данные, нужно данные наложить на полученную гамму, выполнив операцию Xor между гаммой и данными.
    Проксорив гамму с данными, мы получим зашифрованные данные (Encrypted Data).
    Проксорив зашифрованные данные с гаммой, мо получим исходные данные (Data).

    EncryptedData = Gamma XOR Data

    Data = EncryptedData XOR Gamma

    Далее, SHA-3 Keccak позволяет использовать один и тот же ключ как для получения Кода Верификации, так и для выработки Гаммы.
    Единственное, что нужно сделать для избежания коллизии входных параметров, это добавить байт, обозначающий режим работы, так сказать.
    Пусть 1 — это работа в режиме расчёта Кода Верификации.
    Пусть 2 — это работа в режиме расчёта Гаммы.

    Тогда перепишем наши общие формулы:
    Код Верификации рассчитывается как Hash(Key + 1 + Data)
    Гамма рассчитывается поблочно как Hash(Key + 2 + NumberBlock)

    Уверен Вы скажите, что это всё очень просто. Так вот за это я и люблю эту хеш-функцию.

    Итак, у нас есть ключ, есть исходные данные, так что же нужно получить на выходе?
    На выходе в конечном счёте мы должны получить всего две вещи: Код Верификации и Зашифрованные Данные.

    Для удобства сначала первым записывается в файл Код Верификации, затем уже Зашифрованные Данные.

    Код Верификации имеет фиксированную длину, равную длине выходной хеш-суммы нашей хеш-функции.
    Зашифрованные Данные имеют переменную длину, равную длине исходных данных.

    Итак, сам алгоритм в общем виде:

    CodeVerificate = Hash(Key + 1 + Data)

    Цикл для NumberBlock с 1 по Count
    <
    Gamma[NumberBlock] = Hash(Key + 2 + NumberBlock)
    >

    EncryptedData = Xor(Gamma, Data)

    Дешифровка по аналогии.

    Важно:
    1. Только в данном примере один и тот же ключ можно использовать только для однократного шифрования/дешифрования (однако это несложно исправить, но не будем усложнять). Повторное использование этого же ключа недопустимо, поскольку гамма должна быть одноразовой.
    2. Использование других (прошлых) хеш-функций для этих целей недопустимо, они не предназначены для этого.

    Был изложен наиболее простой вариант использования SHA-3 Keccak.
    На самом деле для создания защищённого сетевого канала этой схемы недостаточно, нужно ещё реализовать механизм согласования ключей сеанса и идентификаторы пользователей, однако для этого по-прежнему достаточно SHA-3 Keccak, никаких других криптографических средств не требуется.

    Посмотрите на схему во вложении, она поможет лучше понять алгоритм.

    28.02.2020, 03:16

    Защита программы средствами SHA-1
    Собственно не совсем понятно что это и как им пользоваться. Кто ни будь пожалуйста объясните.

    SHA хэш — шифрование, расшифровка
    SHA хэш — шифрование, расшифровка C#. Ребят, пожалуйста помогите. не могу разобраться, дали.

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

    Для формирования хеш-адреса использовать хеш-функцию универсального хеширования
    Для формирования хеш-адреса использовать хеш-функцию универсального хеширования . Подскажите.

    28.02.2020, 05:25 2

    Степень криптостойкости в этом случае должна определяться не менее чем 2^(значение бит на выходе/2)

    Как мне представляется sha-3 предназначена ровно для тех же самых целей, что и предназначались прежние функции md-5, sha-1, sh-2. Просто md5 взломана, в sha-1 выявлены серьезные проблемы, а sha-2 это развитие sha-1 с более длинный выходной последовательностью бит, что все равно автоматически ставит ее в ряд функций с подмоченной репутацией. Чем sha-3 принципиально отличается (по назначению) от своих предшественниц?
    Что касается схемы защиты информации, одна операция XOR это все шифрование? Просто применение современной хеш-функции наряду с одной операций XOR для шифрования выглядит откровенно слабо. С верификацией то же не совсем понятно. ЭЦП то здесь здесь нет. Какова ее цель в данной схеме, показать целостность расшифрованных данных? Тогда для чего там добавлять ключ?

    28.02.2020, 10:26 3
    28.02.2020, 13:44 [ТС] 4

    Да, это называется лавинный эффект, так и должно быть.

    Да, на этом основана атака Дней Рождений, увеличение длины выходной хеш-суммы в 2 раза решит проблему.

    Да, она серьёзно отличается именно тем, что NIST учёл предыдущий опыт и указал, что новая хеш-функция должна базироваться на совсем другом принципе. SHA-3 базируется на конструкции криптографической губки Sponge, что и даёт ей свойства криптопримитива.

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

    CodeVerificate поможет определить была ли подделка или нет. Если расшифрованные данные оказались повреждены или подменены, CodeVerificate измениться и не совпадёт. Подделать сам CodeVerificate нельзя, чтобы его подделать, нужны сами поддельные данные и ключ, а ключа у взломщика нет, что не даёт ему возможность создавать верные CodeVerificate.

    Добавлено через 6 минут
    . Схема настолько хороша и красива, вытекающая напрямую из свойств моей любимой SHA-3, что я рисовал её 40 минут и периодически на неё посматриваю и сейчас.
    Дело в том, что в предыдущих хеш-функциях нужна была громозкая конструкция HMAC для создания Message Auth Code (CodeVerificate), была проблема с удлинением сообщения из-за конструкции Меркла-Дамгарда, схемы становились некрасивыми и плохо анализируемыми и всё равно многое нельзя было делать.

    Добавлено через 3 минуты

    AES многих специалистов в своё время удивил своей алгоритмической простотой)

    — Niels Ferguson, Bruce Schneier Practical Cryptography — 2003 — pp. 56-57

    Добавлено через 26 минут

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

    Однако, я попробую более подробно расписать алгоритм этих действий:
    Итак, пусть само слово хранится в байтовом массиве Data.
    Ключ мы запишем в байтовый массив Key.
    Тогда просто вычисляем хеш-сумму от объединения массива Key + байт «1» + Data.
    «1» — мы обозначили условно режим работы в режиме вычисления Кода Верификации (CodeVerificate (CV)).
    Итак, в массиве CodeVerificate у нас записано например 64 байта выходного хеша (если использовать SHA-3-512 бит).
    Эти числа случайные и по ним Вы не сможете сказать, какие были данные на входе и какой был ключ.
    Не просто так на вход подаётся ключ и данные, они вместе оказываются математически связаны, результирующий хеш математически связан с входными данными и ключом и составляет неразрывное целое.
    Проще говоря, посторонний не подделает.

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

    Когда мы подаём на вход хеш-функции ключ и номер блока, мы получаем первую порцию случайных чисел.
    Итак, пусть у нас есть байтовый массив Gamma.
    Запишем в него результат вычисления хеш-функции от Key + байт «2» + «0001».
    «2» — условно обозначили режим работы в режиме выработки Гаммы (Gamma (G)).
    «0001» — номер первого блока гаммы, да, мы сначала создадим первый блок.
    Размер одного блока равер размеру хеша, пусть будет 64 байта.
    Гамма — случайная, одноразовая и секретная.

    Итак, допустим у нас в массиве Data записано всего 10 байт, значит одного блока гаммы достаточно.
    Выполняем операцию Xor над каждым байтом гаммы и данных, строго над соответствующей позиции, один в один.
    Запишем этот результат в массив EncryptedData (ED).
    Цикл
    <
    EncryptedData[i] = Gamma[i] ^ Data[i];
    >

    Всё, в CV у нас на вид сплошной рандом, в ED тоже сплошной рандом.
    CV и G математически связаны через ключ.
    Случайное + Данные = Случайное, поэтому данные скрыты в гамме, зашифрованы.
    Сам CV не раскрывает ничего о входных данных, потому что хеш-функция однонаправленная.

    Илон Маск рекомендует:  Что такое код pcntl_fork
    Понравилась статья? Поделиться с друзьями:
    Кодинг, CSS и SQL