Sibprompost.ru

Стройка и ремонт
0 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Режим шифрования со счетчиком

5.5. Вопросы защиты информации в сетях G-PON

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

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

Основной алгоритм шифрования, использующийся в технологии G-PON — это расширенный стандарт криптозащиты (AES — Advanced Encryption Standard). Этот алгоритм шифрования относится к виду так называемых блочных кодов, который обрабатывает блоки данных длинной 16 байт. Данный алгоритм поддерживает длину шифр-ключа в 128, 192 и 256 битов.

Стандарт AES поддерживает несколько режимов шифрования данных, однако в технологии G-PON используется только один из них. Он получил название «шифрование со счётчиком» Counter Mode (CTR). Шифратор создает поток, состоящий из 16 байтных псевдослучайных шифроблоков. По заданному алгоритму шифроблоки взаимодействуют с входной нешифрованной информацией в результате чего на выходе получается зашифрованная информационная последовательность. Па приемной стороне происходит обратная операция, в которой участвуют те же самые шифроблоки и зашифрованная информационная последовательность. В результате получается исходная нешифрованная информационная последовательность. В технологии G-PON
стандартным ключом является ключ длиной 128 битов, хотя могут поддерживаться и ключи большей длины.

В технологии «шифрование со счётчиком» Counter mode (CTR) используется синхронный крипто-счетчик, который является общим как для оптического линейного окончания (OLT), так и для оптического сетевого блока (ONU). Крипто-счетчик имеет длину 46 битов и состоит из 2х частей. Старшие 30 бит представляют собой межкадровый счетчик (inter-frame counter), а младшие 16 бит внутрикадровый счетчик (intra-frame counter).

Внутрикадровый счетчик обнуляется в начале нисходящего кадра и увеличивается после каждых четырех байт. Например, при скорости 1.244 Гбит/с счетчик будет принимать значения от 0 до 4859.

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

Начала блоков, содержащих псевдослучайную шифропоследовательньсть, выравниваются по положению с началом блока полезной нагрузки. В случае, если в блоке полезной нагрузки располагается ATM трафик, в результате выполнения операции «исключающее или» (XOR) зашифрованными оказывается 48 байт исходной полезной информации. Как известно, ATM ячейка имеет длину 53 байта, а 48 байт, о которых речь шла выше, соответствуют 3-м целым блокам шифропоследовательности. В результате операции «исключающего или» мы и получаем, что 48 байт информации становятся зашифрованной.

Читайте так же:
Не работает счетчик производительности windows 7

В случае, если полезная нагрузка представлена в виде GEM фрагментов, шифруется вся информация блока полезной нагрузки за исключением заголовка Port-ID. Так как количество СЕМ фрагментов не соответствует целому числу блоков с шифропоследовательностью, то оставшаяся часть кодируется с помощью старших битов последнего блока с шифропоследовательностью, оставшаяся часть шифроблока отбрасывается.

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

Когда датаграмма отправляется OLT или принимается ONU, то в ней содержится информация о первом байте заголовка. В первом байте заголовка находится значение криптосчетчика. Для конкретной датаграммы это значение используется в качестве начального значения счетчика шифроблоков. Для последующих шифроблоков в той же датаграмме счетчик увеличивается на 1 для каждого последующего. Такая организация счетчиков приводит к тому, что значение счетчика
никогда не повторяется два раза. 46-ти битное значение блока криптосчетчика управляет 128 битами AES последовательности по следующему алгоритму. 46 бит повторяются 3 раза, в итоге получается 138 битная последовательность, 10 первых бит которой отбрасываются. Полученные 128 бит информации подвергаются обработке AES алгоритма, в результате чего получается случайная шифропоследо-вательность, которая потом взаимодействует с блоками данных.

Рисунок 5.16 Взаимосвязь между последовательностью криптосчетчика
и шифроблока

Рассмотрим вопрос обмена ключами в сети G-PON. Будем считать, что у нас имеется OLT и ONU, которые при взаимодействии используют либо Port-TD, либо VPI и готовы для обмена ключами. Как ONU, так и OLT используют специальные регистры, в которых содержится информация о ключах.

Процесс обмена ключами инициируется OLT. Со стороны OLT отправляется сообщение внутри канала PLOAM. Действие ONU на этот запрос заключается в создании, сохранении и отправки ключа OLT. GNU сохраняет у себя ключ в так называемом . Поскольку длина PLOAM сообщения ограничена по длине, то ключ отправляется в 2х PLOAM сообщениях. Для увеличения надежности обе части шифроключа отправляются 3 раза. Все ключи или части этих ключей имеют параметр Key Index, таким образом на приемной стороне OLT имеет однозначную информацию какой ключ или какая часть ключа к нему пришла. Данный параметр — Keyjndex увеличивается для каждого следующего ключа, создаваемого ONU в ответ на запрос со стороны OLT.

Читайте так же:
Оформление оплаты по счетчику

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

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

Ctr (Counter). Режим счетчика

Этот режим имеет n-битовый счетчик, единственная цель которого – максимизировать период выходной последовательности и нелинейную функцию зашифрования, которая в качестве входа принимает генерируемые счетчиком n-битовые значения, а выдает последовательность γi.

C1 = P1 Ek (IV) при i = 1 Ci = Pi Ek (nonce||i) при i > 1

P1 = C1 Ek (IV) при i = 1 Pi = Ci Ek (nonce||i) при i > 1

Рисунок 2.5 Режим Counter

Алгоритм расшифрования полностью идентичен алгоритму зашифрования.

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

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

Криптостойкость режима полностью определяется криптостойкостью блочного алгоритма шифрования.

Как и в режиме OFB, необходимо потребовать, чтобы одинаковые Ek и IV не использовались повторно.

Выработка вектора инициализации (IV)

Варианты выбора вектора инициализации:

Фиксированный IV. Вообще говоря, этот вариант применять не следует, так как он чреват определенными последствиями:

CBC – Два первых совпадающих блока шифруются одинаково.

OFB – При использовании одинаковых Ek и IV вырабатываемая ключевая последовательность (гамма-последовательность) будет идентичной.

CTR – аналогично OFB.

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

Случайный IV. Хороший способ, однако он сопряжен с некоторыми трудностями:

Получатель должен знать значение IV.

Трудно реализовать качественный генератор случайных чисел.

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

Оказия. Этот способ наиболее рентабелен, по моему мнению. Он состоит из следующих действий:

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

Читайте так же:
Подключение счетчика галлус 2000

Зашифровать оказию, получив тем самым вектор инициализации.

Зашифровать сообщение с помощью IV.

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

Генераторы псевдослучайных последовательностей

Рисунок 2.5 Классификация генераторов

Криптографические

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

Некриптографические

Линейными конгруэнтными генераторами являются генераторы

X (aX b) m n n mod 1 = + − ,

в которых n X –n-й член последовательности, а n−1 X – предыдущий член

последовательности. Переменные a, b и m – постоянные: а – множитель, b –

инкремент и m – модуль. Ключом или затравкой служит значение 0 X .

Период такого генератора не больше, чем m. Если a, b и m подобраны

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

период будет равен m. (Например, для линейного конгруэнтного генератора b

Режим шифрования со счетчиком

  • Наука
  • Инвестиции
  • Музей
  • О нас
  • Научный блог
  • Новости
  • Карьера
  • СМИ о нас

Новый режим шифрования CTR-ACPKM (Counter mode with Advanced Cryptographic Prolongation of Key Material, режим счётчика с улучшенной криптографической пролонгацией ключевого материала) опубликован как дополнение ISO/IEC 10116:2017/AMD 1:2021 к международному стандарту ISO/IEC 10116:2017.

Документ подготовлен под руководством трёх российских экспертов: начальника лаборатории криптографии «Криптонит» Василия Шишкина, зам. генерального директора «КриптоПро» Станислава Смышляева и начальника отдела криптографических исследований «КриптоПро» Евгения Алексеева.

Режим CTR-ACPKM предназначен для использования в блочных шифрах (включая AES, «Кузнечик» и «Магма»). Он устраняет слабые места, связанные с обработкой больших объемов данных на одном ключе.

Длительное использование одного ключа — распространённая угроза безопасности, при которой противнику становится доступен ряд способов скомпрометировать ключ и данные (например, выполнив атаку по побочным каналам). Самый очевидный способ защититься от них — ограничить срок жизни ключа (key lifetime), то есть обновлять ключ каждый раз, когда объем обработанных на нём данных достигает определенного предела L.

Эту проблему как раз и решает новый режим CTR-ACPKM. Его главной особенностью является встроенный механизм внутреннего преобразования ключа (internal re-keying), позволяющий существенно увеличить объем информации, который может быть безопасно на нем обработан. Он позволяет избегать ресурсоёмкой операции по выработке нового симметричного ключа для каждого последующего набора данных, заменив её более быстрым механизмом принудительного преобразования исходного ключа. Снижение вычислительных затрат при шифровании особенно актуально для мобильных устройств и IoT-сегмента.

Режим CTR-ACPKM, разработанный российскими экспертами, стал шестым стандартизированным на международном уровне. Он вошёл в стандарт ISO/IEC наряду с пятью классическими режимами: ECB (Electronic Codebook, режим электронной кодовой книги или простой замены); CBC (Cipher Block Chaining, режим сцепления блоков шифртекста); CFB (Cipher Feedback, режим обратной связи по шифртексту); OFB (Output Feedback, режим обратной связи вывода) и CTR (Counter Mode, режим счётчика).

Читайте так же:
По платежке больше чем по счетчику

В отличие от них CTR-ACPKM позволяет разрабатывать эффективные протокольные решения на базе блочных шифров, защищаясь от гораздо более сильных противников (в частности, способных выполнить атаку по побочным каналам).

Ранее данный режим шифрования был введен Рекомендациями по стандартизации Р 1323565.1.017-2018 «Информационная технология. Криптографическая защита информации. Криптографические алгоритмы, сопутствующие применению алгоритмов блочного шифрования», а также опубликован в RFC 8645. Активное участие в данных работах принимали специалисты компаний «КриптоПро», «Криптонит» и эксперты технического комитета TK 26.

Использование режима CTR начального вектора (IV)

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

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

Так вот в чем моя проблема. У меня есть следующий код в Java(используя библиотеку bouncycastle):

Каждый другой вызов приведенного выше кода с одним и тем же ключом дает разный результат! Но когда это делается:

Я получаю один и тот же результат при каждом вызове вышеприведенного кода. Но почему это? Я имею в виду, что CTR не нуждается в IV, так почему же, когда я не даю IV в каждом вызове, я получаю другой результат, а когда я даю IV, он возвращает тот же результат? Если бы я всегда использовал вышеупомянутый IV (все нули) при использовании CTR, было бы это безопасно?

Любые идеи были бы очень полезны. Спасибо

3 ответа

  • Нужно ли мне, чтобы выходной буфер был кратен размеру блока AES для режима CTR?

В моем коде C я использую OpenSSL AES в режиме CTR для шифрования через интерфейс EVP, то есть у меня есть что-то вроде этого: ret = EVP_EncryptInit_ex(ctx, EVP_aes_256_ctr(), NULL, key, iv)) . ret = EVP_EncryptUpdate(ctx, out, &outlen, in, inlen); Длина входных данных не кратна размеру.

Я пытаюсь сделать CTR вручную поверх режима ECB (но все же) с помощью Crypto++. Идея такова: Для одного блока: просто используйте ECB для нескольких блоков, используйте алгоритм CTR (AFAIK): //We have n block of plain data -> M PlainData M[n]; key; iv; char *CTR; cipher =; for(i = 0; i

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

Читайте так же:
Импульс сервис поверка счетчиков

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

Это позволяет запускать часть «counter» с нуля для нескольких сообщений, при условии, что вы никогда не будете повторно использовать часть «IV».

Однако обратите внимание, что это всего лишь соглашение о маркировке. Математически это то же самое, что назвать все это «counter» и запустить счетчик со случайным кратным некоторому целому числу для каждого сообщения.

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

CTR работает путем шифрования последовательных значений счетчика. Первое значение для этой последовательности IV (IV означает «initial value». ). Таким образом, CTR действительно использует IV.

Если вы используете режим CTR с тем же ключом и случайно повторно используете значение счетчика, которое вы уже использовали для какого-то другого шифрования (с тем же ключом), то вы получаете печально известный two-times-pad, и безопасность пошла насмарку. В частности, использование фиксированного IV для всех сообщений-верный рецепт катастрофы.

«easy» способ избежать повторения счетчика-всегда выбирать IV с помощью криптографически защищенного генератора случайных чисел (подумайте » java.security.SecureRandom «) среди множества возможных IV, т. Е. Всех 16-байтовых последовательностей. Это пространство достаточно велико, чтобы в какой-то момент можно было пренебречь риском повторного использования значения счетчика.

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

Режим CTR использует что-то, что по существу эквивалентно IV, и это начальное значение счетчика.

голоса
Рейтинг статьи
Ссылка на основную публикацию
Adblock
detector