Что это РСЯ в Яндекс Директ и как работает?
Здравствуйте, уважаемые гости и друзья. Данную статью решила сделать обзорной: что это РСЯ? Ведь довольно часто у рекламодателей, которые столкнулись с понятием контекстной рекламы совсем недавно, возникает данный вопрос.
Что это РСЯ?
РСЯ или Рекламная Сеть Яндекса это совокупность сайтов, на которых показываются рекламные объявления Яндекс Директ. Это могут быть новостные порталы, почтовые сервисы, форумы и прочее, прочее, прочее. Это огромное количество площадок.
Стать участником Рекламной Сети может любой сайт, который соответствует определенным критериям, предъявляемым Яндексом. Данные критерии отбора довольно жёсткие. Ведь сайт должен иметь определенную посещаемость в сутки: от 100 уникальных посетителей. Причем этот показатель должен сохраняться в течение двух месяцев подряд. А также сайты проходят модерацию на предмет запрещенных тематик, несоответствующего контента, несоответствия законодательству, наличие вирусов и т.
д.
Так что попадают в РСЯ отобранные – прошедшие модерацию сайты. Например, для того чтобы разместить на своем сайте рекламные блоки Контекстной Медийной Сети от Гугл вам придется пройти более лояльную проверку. Критерии отбора сильно отличаются. Присоединиться к КМС значительно проще.
На сентябрь 2017 года по заялвению Яндекса аудитория охвата РСЯ составляет около 70 миллионов человек. Для сравнения – в 2014 году охват составлял 56 миллионов. И данная цифра будет только расти!
Чем отличается РСЯ от Поиска?
Показ рекламы в поиске можно обозначить как некий ответ на запрос пользователя, который он задает в строке своего браузера. Своим рекламным посланием мы как бы предугадываем желание человека, показывая ему, в соответствии с запросом, релевантное объявление.
Нужно понимать, что когда человек вводит поисковый запрос, то он непосредственно заинтересован в товаре или услуге которую вы предлагаете. Клиент готов к тому, чтобы воспользоваться вашей услугой или купить ваш товар.
Именно поэтому рекламодатели ведут острую борьбу за эти запросы: они дают целевой трафик и высокую конверсию. Следствие — высокая цена клика, результат конкурентной борьбы за «место под солнцем».
Показы объявлений в Рекламной Сети Яндекса – это показы, которые совершаются на площадках, куда пользователь приходит не в поисках решения своего вопроса, а для того, чтобы провести время. Например, если это новостной портал — почитать новости. Или написать письмо, если это почтовый сервис. Или просто пообщаться на форуме. И на всех этих площадках мы можем пользователя как бы «догонять» своим рекламным объявлением.
В отличие от рекламы на Поиске, РСЯ дает возможность рекламировать свои товары и услуги, даже если у вас небольшой рекламный бюджет. Да, часто конверсия здесь ниже, но зато здесь неограниченное количество пользователей, которые могут превратиться в ваших клиентов. Вы только подумайте – 70 миллионов человек ежедневно посещаю рекламные площадки Яндекса. Возможности РСЯ поистине неограниченны!
Как работает РСЯ — виды таргетинга
Принцип, по которому производится показ рекламных объявлений можно разделить на 3 вида или, как говорят, на три вида таргетинга в РСЯ:
Поведенческий таргетинг РСЯ
Допустим, вы хотите купить пылесос.
Вы ввели соответствующий запрос «купить пылесос» в поисковую строку Яндекса, или Рамблера, или mail.ru. Ваш браузер сохранил так называемый Cookie (куки) файл, в котором сохранилась служебная информация. Данная информация состоит из статистики, предпочтений пользователя, настроек и прочего. Считав информацию кики-файлов, Яндекс определил вас как уникального пользователя. Он как бы учел ваши индивидуальные особенности и на основании этих особенностей — ведь вам нужен именно пылесос — покажет вам рекламные объявления с соответствующим содержанием.
Тематический таргетинг РСЯ
В соответствии с тематическим таргетингом реклама будет показана на тех площадках, которые по теме наиболее близки запросу пользователя. Если вернуться к пылесосам, то в соответствии с тематическим таргетингом объявления будут показаны на форумах, где обсуждают различные модели пылесосов или на площадках, тематика которых связана с ремонтом пылесосов.
Ретаргетинг
Третий вид таргетинга в РСЯ – ретаргетинг.
О нем я подробно говорила в статье «Яндекс Директ настройка ретаргетинга для чайников».
В заключение, хочу обратить ваше внимание, что весной 2016 года к Яндекс Директу присоединились внешние SSP (Sell Side platforms). Это технологические платформы, которые умеют продавать мобильный трафик в RTB-аукционе. То есть показы могут быть осуществлены не только на площадках Яндекса, но и во внешних сетях.
Поэтому, если мы говорим о рекламе на площадках, то правильно говорить не РСЯ, а показы в Сетях. Но это уже кому как больше нравится.
И как всегда попрошу вас поделиться данной статьей, если она показалась вам полезной.
С вами была Юлия Хайретдинова
что это такое – рекламная сеть Яндекса
Обучение в IMBA
Мы собрали для тебя подробный список терминов, методик и
инструментов,
которые встречаются в учебных программах.
РСЯ – это рекламная сеть «Яндекса», один из
вариантов размещения контекстной рекламы. В отличие от рекламных
объявлений в поиске, РСЯ демонстрирует рекламу на сайтах-партнерах
поисковика. В результате ее видят те, кто сидит на тематических ресурсах
или недавно искал в поисковой системе похожие товары и услуги. «Яндекс»
сотрудничает с огромным количеством сайтов, вдобавок имеет собственные
информационные сервисы: понять, что такое РСЯ, можно, ненадолго зайдя на
любой такой ресурс. Объявления, которые будут показываться на странице,
относятся к рекламной сети.
Как работает РСЯ
- Рекламодатель, продающий
велосипеды, настраивает рекламную кампанию с показом объявлений в РСЯ.
Это можно сделать в «Яндекс.Директе». Специалист может сам выбрать
сайты, на которых будет показываться реклама, или положиться на
алгоритмы поисковой системы. - Пользователь, который хочет купить велосипед, вводит в «Яндекс» соответствующий запрос, но пока ничего не приобретает.
- Когда
этот человек зайдет на сайт, подключенный к рекламной сети, он увидит
объявление рекламодателя-продавца. Поисковая система запомнит, что
именно он искал, и будет показывать ему такие товары. Возможно, человек
даже не будет знать, что такое РСЯ, хотя о принципе работы контекстной
рекламы догадываются многие. - Срок, в течение которого «Яндекс»
помнит, что искал пользователь, составляет от 30 до 90 дней, но
объявления обычно перестают показываться раньше, потому что человек
начинает искать новые вещи – реклама обновляется.
Особенности рекламных сетей «Яндекса»
Для
тех, кто умеет пользоваться рекламными сетями и знает, что это такое,
РСЯ может оказаться выгоднее, чем поиск. У нее есть несколько
особенностей, делающих сервис привлекательным:
- более широкий охват при одинаковых с поисковой рекламой бюджетах;
- не такая высокая, как в поиске, цена за клик;
- есть
возможность настроить ретаргетинг, когда побывавшего на сайте, но
ничего не купившего человека начинает догонять соответствующая реклама; - объявления выглядят как картинки (иногда анимированные) и бросаются в глаза, что позволяет обойти «баннерную слепоту»;
- реклама
показывается не только по истории запросов, но и по интересам. «Яндекс»
собирает сведения о пользователях, анализирует их, так что рукодельнице
будут чаще показываться поделочные камни или пряжа, а художнику –
товары для рисования.
«Яндекс»Существенный минус РСЯ – относительно
низкая кликабельность. Многие не видят объявлений из-за включенных
блокировщиков рекламы, другие предпочитают игнорировать баннеры.
Виды таргетинга
РСЯ работает по нескольким видам таргетинга. Среди них:
- поведенческий. Человеку показывают объявления на основе того, чем он интересовался или что искал в поисковой строке;
- тематический.
Реклама размещается на сайтах по теме объявления. К примеру, курсы
французского будут рекламироваться в блоге, посвященном жизни во Франции
или путешествиям; - ретаргетинг. Такие объявления догоняют
тех, кто уже посетил сайт рекламодателя, и работают как напоминание.
Например, человек просмотрел интернет-магазин, пробыл там солидное
количество времени, но ничего не купил (хотя, возможно, положил товар в
корзину). Реклама будет напоминать ему об этом магазине, чтобы он
вернулся и сделал покупку.
Реклама будет напоминать ему об этом магазине, чтобы онУзнать больше о контекстной
рекламе помогут тематические курсы IMBA. Выберите подходящую программу,
чтобы начать обучение у одних из лучших специалистов.
Синонимы:
Что такое операторы в Яндекс.Директе и почему их важно использовать
Операторы — это специальные символы, которые помогают более точно задать ключевые фразы в рекламной системе, позволяют точнее управлять показами. С их помощью вы можете зафиксировать падеж, склонение, количество слов во фразе. В результате повышается эффективность запросов и исключаются нецелевые показы.
Рассмотрим на примере: по умолчанию рекламное объявление в Директе показывается по всем запросам, содержащим ключевую фразу. Это позволяет показать рекламу максимально большому количеству пользователей сети.
| Ключевое слово | Запросы по нему |
| Купить шторы | Купить шторы бу |
| Шторы своими руками | |
| Купить шторы на кухню | |
| Купить шторы Москва | |
| Купить шторы Иркутск | |
| Купить шторы оптом |
Однако если вы продаете исключительно новые шторы или работаете только в Красноярске, либо не продаете шторы оптом, ваше объявление получит много нецелевых кликов. Чтобы таргетироваться точнее, используйте операторы соответствия.
Какие операторы предлагает Яндекс:
- Оператор минус
- Оператор кавычки
- Оператор восклицательный знак
- Оператор плюс
- Оператор квадратные скобки
- Оператор круглые скобки и вертикальная черта
Оператор минус
Наиболее часто в своей ежедневной работе мы используем оператор «-» (минус-слова).
Он позволяет блокировать показы объявления, если в запросе пользователя есть ненужные нам слова.
Разберем работу минус-слов на примерах.
Допустим, мы владеем интернет-магазином женских свитеров в Москве. Тогда из запроса «купить свитер» обязательно убираем включенные слова: бу, мужские, хоккейный, картинки, чтобы наше объявление не показывалось по запросам «купить б/у свитер», «купить свитер мужской». Показывать объявления по данным запросам не имеет никакого смысла. Ведь человек, искавший мужской свитер, вряд ли кликнет по нашему объявлению с женскими свитерами, а если и кликнет, то не найдет нужного и уйдет с сайта, а мы потеряем деньги.
Разберем еще один пример. В рекламной кампании для нашего сайта из запроса «seo-аудит сайта» обязательно исключаются такие слова, как: -диплом, -книга, -видео, -договор, -изображения, -Википедия.
Очень важно исключать нецелевые запросы, так как, во-первых, CTR объявлений будет выше, а во-вторых, исключается возможность неэффективных кликов.
Следовательно, бюджет рекламной кампании не тратится впустую.
Важное замечание: оператор «минус-слова» не может быть использован вместе с оператором «кавычки», так как кавычки запрещают показы по вложенным запросам.
Я не рекомендую использовать больше 10 минус-слов на один запрос. Если минус-слов очень много, лучше использовать оператор «кавычки», а вложенные запросы, которые подходят, следует выбрать и выделить как отдельные ключевые слова.
Еще одно важное правило: на момент создания рекламной кампании в ключевых словах «минус-слова» могут отсутствовать. Они появляются не только при создании, но и в процессе работы рекламной кампании. Поэтому необходимо постоянно отслеживать качество ключевых слов, уточняя их в интерфейсе.
Исключить минус-слова при подборе можно с помощью кнопки «уточнить» в «Прогнозе бюджета». Выделяя галочками ненужные слова, добавляем их в список минус-слов для определенного ключевого слова.
Если в каждой фразе присутствует слово, которое надо исключить, можно сформировать единый список минус-слов для всей кампании.
Сформированный список добавляется либо при создании кампании в Excel или Коммандере, либо в интерфейсе Яндекс.Директ.
Списки минус-слов желательно периодически просматривать и добавлять в них новые слова, чтобы исключить все нецелевые показы объявлений.
Важно знать
Если ключевое слово пересекается с минус-словом, то минус-слово не учитывается.
Минус-слова в Яндекс.Директ учитываются во всех словоформах. Например, если есть минус-слово бесплатно, то по фразам с элементами бесплатно, бесплатные, бесплатный, бесплатная, бесплатных и т.д. также идет учет минус-слов. Достаточно написать одну словоформу, чтобы исключить все.
Минус-слова позволяют повышать CTR объявления, снизить расходы на рекламу и исключить нецелевые клики.
Показывайте рекламу только тем, кто действительно ищет вас!
Оператор кавычки
Фиксирует количество слов в запросе. Показы будут выдаваться только по заданному слову или фразе и всем словоформам.
К примеру:
| Ключевое слово с оператором | Показывается | Не показывается |
| «купить кастрюлю» | купить кастрюлю | купить кастрюлю дешево |
| купить кастрюли | кастрюлю для кухни купить | |
| кастрюлю купить | купить кастрюлю цена | |
| кастрюли купить |
В чем же разница?
Первая фраза инициирует показ по абсолютно любым запросам, где есть слово «кастрюля» и слово «купить» в любой последовательности.
Второй вариант, в кавычках, жёстко ограничивает количество слов, но слова внутри фразы могут меняться местами. Их будет именно столько, сколько в вашей ключевой фразе.
Таким образом, по ключевой фразе в кавычках «купить кастрюлю» показы могут быть только по четырем запросам, которые представлены в таблице выше.
По всем остальным запросам показов не будет. Имейте в виду, что оператор кавычки не влияет на словоформу или на очередность слов.
Cоветую быть аккуратнее с использованием этого оператора, практика показывает, что не всегда брать высокочастотник в кавычки выгодно, я бы рекомендовала не бояться экспериментировать, рекламироваться по вложенным запросам и создавать рекламные кампании по среднечастотным и низкочастотным запросам.
Оператор восклицательный знак
Оператор восклицательный знак закрепляет словоформу у слова, перед которым он ставится, если быть точнее фиксирует падеж, число, время.
Рассмотрим пример:
| Ключевое слово с оператором | Показывается | Не показывается |
| Купить !банан | Где можно купить банан | Купить бананы |
| Купить дешево банан | Купить банановый сок | |
| Купить банан оптом | Купить футболку с бананом | |
| Джинсы банан купить | Джинсы бананы купить |
Данный оператор хорошо применим, когда необходимо использовать именно ЭТИ словоформы, а от остальных необходимо отказаться.
Допустим, у нас есть ключевой запрос «школа маникюра», который подразумевает обучающие курсы по маникюру. Думаю, вы уже догадались, что если ввести запрос именно так, будет большой процент ненужных нам запросов.
Кавычки здесь не помогут. Если я сделаю ключ «школа маникюра» в кавычках, то потеряю много запросов, таких как:
- школа маникюра +на ногтях
- школа маникюра +и педикюра
- школа маникюра спб
В данной ситуации оператор восклицательный знак подойдет идеально.
Конечно, над минус-словами придется поработать, но, согласитесь, нецелевых запросов фактически нет.
Оператор плюс
Дело в том, что Яндекс.Директ по умолчанию «не видит» союзы и предлоги. Данный оператор фиксирует стоп-слова (предлоги, местоимения и служебные части речи, которые автоматически исключаются из запроса при отборе объявлений для показа). Проще говоря, делает слово обязательным в запросе.
| Ключевое слово с оператором | Показывается | Не показывается |
| Чай +с сахаром | чай +с сахаром калорийность | чай без сахара |
| чай +с сахаром калории | сколько сахара +в чае | |
| можно ли кормящей маме чай +с сахаром | песня чай сахар | |
| калории +в чае без сахара |
К примеру, весьма распространенный запрос «работа на дому», если не зафиксировать предлог «на» оператором плюс, вы будете показываться также по запросам: «работа дома», «работа по дому», а у этих фраз, согласитесь, совсем другой смысл.
В Яндекс.Директе на этот оператор стоит обратить особое внимание, т.к по ряду тематик крайне важна сама форма, по которой пользователи вбивают запрос.
Оператор квадратные скобки
Помогает фиксировать порядок слов. Используется чаще всего с единственной целью — указание направления поездок/перелётов.
| Ключевое слово с оператором | Показывается | Не показывается |
| Купить Жд билет [Москва-Казань] | Жд билет из Москвы в Казань купить | Жд билет Казань Москва купить |
Оператор круглые скобки и вертикальная черта
Как видно из таблицы, при добавлении ключевого слова без оператора квадратные скобки оно будет показываться по запросам, для которых наш заголовок будет нерелевантен.
Данный оператор помогает группировать два слова в одной фразе с помощью знака «|». Честно сказать, на практике круглые скобки применяются крайне редко, но обойти его стороной было бы неправильно, поэтому рассмотрим пример.
Допустим, мы решили объединить запросы «продажа газона» по городам миллионникам. С применением оператора ключевой запрос будет выглядеть следующим образом:
— Продажа газона в (Москве|Санкт-Петербурге|Красноярске|Новосибирске|Казане)
С данным запросом мы будем показывать рекламу всем, кто введет в поисковую строку запрос «продажа газона» с уточнением города.
Огромным минусом является нерелевантность заголовка, именно из-за этого я крайне редко практикую использование данного оператора. К примеру, если бы мы делали рекламную кампанию из 5 ключевых слов, у нас бы было 5 релевантных заголовков. В данном случае у нас одно длинное ключевое слово с использованием оператора, поэтому и заголовок один. Такой оператор хорошо применим в Wordstat, когда надо посмотреть статистику запросов, можно сгруппировать ключевые слова подобным образом и сэкономить время.
При необходимости вы можете использовать несколько операторов одновременно:
-билеты [Новосибирск (Казань|Ростов]
Показы будут по запросам: билеты из Новосибирска в Казань, билеты из Новосибирска в Ростов, купить билеты на самолет Новосибирск Казань, купить билет на самолет Новосибирск Ростов.
Еще один из ярких примеров, когда можно и нужно использовать сразу несколько операторов. Допустим, в город приезжает певица Марфуша, и мы решили искать покупателей по запросу ее популярной песни. Нам нужно, чтобы показы были именно по фразе «идет бычок качается» в суперточном и узком соответствии.
Наши действия следующие:
- закрепляем порядок слов оператором квадратные скобки;
- закрепляем словоформу «идет бычок качается» оператором восклицательный знак;
- закрепляем фразу оператором кавычки.
В итоге получаем вот такой запрос «[!идет !бычок !качается]» и показы только по фразе без каких-либо возможных вариантов.
Стоит ли применять операторы в РСЯ?
Операторы в РСЯ в большинстве случаев лучше не использовать.
Если на поиске в 97% случаев следует добавлять минус-слова, то в РСЯ это делать нужно в 15-20% случаев, если не меньше. РСЯ сильно отличается от поиска. Добавляя слова с оператором минус, мы исключаем страницы, на которых данное минус-слово встречается.
То есть если мы будем рекламировать посудомоечную машину Philips определенной модели и добавим минус-слова «отзывы, характеристики, форум, инструкция», то мы автоматически отключим страницы, где присутствуют данные слова, отключим форумы и т.д.
Оператор плюс также сильно сокращает охват потенциальных клиентов. К примеру, запрос «купить ванну +для дачи» не будет показываться на страницах с запросом «ванна на дачу купить». Для РСЯ я рекомендую тестировать минус-слова. Выписываем все нецелевые слова, например, бесплатно, своими, руками, free, шпоры, контрольная и др. Добавляем список минус слов к вашей рекламной кампании и тестируем хотя бы неделю. После этого можно будет сделать выводы об эффективности.
В заключение
Не пренебрегайте операторами ключевых слов в Директе, ведь грамотный подход позволит существенно сэкономить бюджет, сократив нерелевантные клики и запросы.
Источник
Критические уязвимости в библиотеках JSON Web Token
TL; DR: Если вы используете node-jsonwebtoken, pyjwt, namshi / jose, php-jwt или jsjwt с асимметричными ключами (RS256, RS384, RS512, ES256, ES384, ES512), обновите его до последней версии.
См. Jwt.io для получения дополнительной информации об уязвимых библиотеках. (обновлено 20.04.2015)
Это гостевой пост от Тима Маклина, который является членом Зала славы исследователей безопасности Auth0.Тим обычно ведет блог на www.timmclean.net.
Недавно, изучая безопасность различных реализаций веб-токенов JSON, я обнаружил множество библиотек с критическими уязвимостями, позволяющими злоумышленникам обойти этап проверки. Те же два недостатка были обнаружены во многих реализациях и языках, поэтому я подумал, что было бы полезно указать, где именно возникают проблемы. Я считаю, что изменение стандарта может помочь предотвратить будущие уязвимости.
«Я обнаружил множество библиотек с критическими уязвимостями, позволяющими злоумышленникам обойти этап проверки.«
Твитнуть
Для тех, кто не знаком, JSON Web Token (JWT) — это стандарт для создания токенов, которые утверждают некоторое количество утверждений.
Например, сервер может сгенерировать токен с утверждением «зарегистрирован как администратор» и предоставить его клиенту. Затем клиент может использовать этот токен, чтобы доказать, что он вошел в систему как администратор. Токены подписаны ключом сервера, поэтому сервер может проверить, является ли токен законным.
JWT обычно состоят из трех частей: заголовка, полезной нагрузки и подписи.
Заголовок определяет, какой алгоритм используется для генерации подписи, и выглядит примерно так:
header = '{"alg": "HS256", "typ": "JWT"}' HS256 указывает, что этот токен подписан с использованием HMAC-SHA256.
Полезная нагрузка содержит утверждения, которые мы хотим сделать:
payload = '{"loggedInAs": "admin", "iat": 1422779638}' Как предлагается в спецификации JWT, мы включаем метку времени под названием iat , сокращенно от «выпущено в».
Подпись вычисляется с помощью base64url, кодирующего заголовок и полезную нагрузку и объединяющего их с точкой в качестве разделителя:
ключ = 'секретный ключ'
unsignedToken = encodeBase64 (заголовок) + '.' + encodeBase64 (полезная нагрузка)
подпись = HMAC-SHA256 (ключ, беззнаковый токен) Чтобы собрать все вместе, мы base64url кодируем подпись и объединяем три части, используя точки:
токен = encodeBase64 (заголовок) + '.' + encodeBase64 (полезная нагрузка) + '.'+ encodeBase64 (подпись)
# токен сейчас:
# eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJsb2dnZWRJbkFzIjoiYWRtaW4iLCJpYXQiOjE0MjI3Nzk2Mzh9.gzSraSYS8EXBxLMuj 900CXBxLyMgj 900CMXCMJSMJ0CM8EXBXLXXXXXXXXXMXXXXXXXXXXXXXXXXXXLX
Чтобы узнать больше о веб-токенах JSON, ознакомьтесь с нашей бесплатной электронной книгой ниже.
Отлично. Итак, что в этом плохого?
Что ж, попробуем проверить токен.
Во-первых, нам нужно определить, какой алгоритм использовался для генерации подписи. Нет проблем, в заголовке есть поле alg , которое сообщает нам об этом.
Но подождите, мы еще не проверили этот токен, а это значит, что мы не проверили заголовок. Это ставит нас в неудобное положение: чтобы проверить токен, мы должны позволить злоумышленникам выбрать, какой метод мы используем для проверки подписи.
Это имеет катастрофические последствия для некоторых реализаций.
Встречайте алгоритм "None"
Алгоритм none - любопытное дополнение к JWT. Он предназначен для использования в ситуациях, когда целостность токена уже проверена.Интересно, что это один из двух алгоритмов, которые необходимо реализовать (второй - HS256 ).
К сожалению, некоторые библиотеки рассматривали токены, подписанные алгоритмом none , как действительные токены с проверенной подписью. Результат? Любой может создавать свои собственные «подписанные» токены с любой полезной нагрузкой, которую он хочет, позволяя произвольный доступ к учетной записи в некоторых системах.
Собрать такой жетон просто. Измените заголовок приведенного выше примера, чтобы он содержал «alg»: «none» вместо HS256 .Внесите любые желаемые изменения в полезную нагрузку. Используйте пустую подпись (например, signature = "" ).
Большинство (надеюсь, все?) Реализаций теперь имеют базовую проверку для предотвращения этой атаки: если был предоставлен секретный ключ, то проверка токена для токенов с использованием алгоритма none не удастся. Это хорошая идея, но она не решает основной проблемы: злоумышленники контролируют выбор алгоритма. Продолжаем копать.
RSA или HMAC?
Спецификация JWT также определяет ряд асимметричных алгоритмов подписи (на основе RSA и ECDSA).С помощью этих алгоритмов токены создаются и подписываются с использованием закрытого ключа, но проверяются с помощью соответствующего открытого ключа. Это довольно удобно: если вы публикуете открытый ключ, но держите закрытый ключ при себе, только вы можете подписывать токены, но любой может проверить, правильно ли подписан данный токен.
Большинство библиотек JWT, на которые я смотрел, имеют такой API:
# иногда называют "декодировать"
verify (строковый токен, строковый ключ проверки)
# возвращает полезную нагрузку, если токен действительный, иначе выдает ошибку
В системах, использующих подписи HMAC, verifyKey будет секретным ключом подписи сервера (поскольку HMAC использует тот же ключ для подписи и проверки):
проверить (clientToken, serverHMACSecretKey)
В системах, использующих асимметричный алгоритм, verifyKey будет открытым ключом, по которому должен быть проверен токен:
проверить (clientToken, serverRSAPublicKey)
К сожалению, злоумышленник может этим злоупотребить.Если сервер ожидает токен, подписанный с помощью RSA, но на самом деле получает токен, подписанный с помощью HMAC, , он будет думать, что открытый ключ на самом деле является секретным ключом HMAC .
Как это катастрофа? Предполагается, что секретные ключи HMAC должны быть закрытыми, а открытые ключи - общедоступными. Это означает, что ваш типичный злоумышленник в лыжной маске имеет доступ к открытому ключу и может использовать его для подделки токена, который сервер примет.
Сделать это довольно просто.Сначала возьмите свою любимую библиотеку JWT и выберите полезную нагрузку для своего токена. Затем получите открытый ключ, используемый на сервере в качестве ключа проверки (скорее всего, в текстовом формате PEM). Наконец, подпишите свой токен, используя открытый ключ в формате PEM в качестве ключа HMAC. Фактически:
forgedToken = знак (tokenPayload, 'HS256', serverRSAPublicKey)
Самая сложная часть - убедиться, что serverRSAPublicKey совпадает с ключом проверки, используемым на сервере.Чтобы атака сработала, строки должны точно совпадать - точно такой же формат, без лишних или отсутствующих разрывов строк.
Конечный результат? Любой, кто знает открытый ключ, может подделать токены, которые пройдут проверку.
Рекомендации для разработчиков библиотек
Я предлагаю библиотекам JWT добавить параметр алгоритма к своей функции проверки:
verify (токен строки, алгоритм строки, ключ проверки строки)
Сервер уже должен знать, какой алгоритм он использует для подписи токенов, и позволять злоумышленникам предоставлять это значение небезопасно.
Кто-то может возразить, что некоторые серверы должны поддерживать более одного алгоритма по соображениям совместимости. В этом случае для каждого поддерживаемого алгоритма можно (и нужно) использовать отдельный ключ. JWT предоставляет поле «идентификатор ключа» ( kid ) именно для этой цели. Поскольку серверы могут использовать идентификатор ключа для поиска ключа и соответствующего алгоритма, злоумышленники больше не могут
контролировать способ использования ключа для проверки. В любом случае я не думаю, что библиотеки JWT должны даже смотреть на поле alg в заголовке, за исключением, возможно, проверки, соответствует ли оно ожидаемому алгоритму.
Любой, кто использует реализацию JWT, должен гарантировать, что токены с другим типом подписи будут отклонены. В некоторых библиотеках есть дополнительный механизм для занесения в белый или черный список алгоритмов; воспользуйтесь этим, иначе вы можете оказаться в опасности. Еще лучше: имейте политику проведения аудитов безопасности любых библиотек с открытым исходным кодом, которые вы используете для обеспечения критически важных функций.
Улучшение стандарта JWT / JWS
Я хотел бы предложить отказаться от поля заголовка alg .Как мы видели здесь, его неправильное использование может иметь разрушительное влияние на безопасность реализации JWT / JWS. Насколько я могу судить, идентификаторы ключей представляют собой адекватную альтернативу. Это гарантирует изменение спецификации: библиотеки JWT продолжают писать с недостатками безопасности из-за их зависимости от alg .
JWT (и JOSE) предоставляют возможность иметь кроссплатформенный набор реализаций безопасной криптографии. Надеюсь, с этими исправлениями мы немного приблизились к тому, чтобы воплотить это в жизнь.
В сторону: делегирование реализации JWT экспертам
JWT являются неотъемлемой частью стандарта OpenID Connect, уровня идентификации, который находится поверх инфраструктуры OAuth3. Auth0 - это платформа идентификации, сертифицированная OpenID Connect. Это означает, что если вы выберете Auth0, вы можете быть уверены, что он на 100% совместим с любой сторонней системой, которая также соответствует спецификации.
Спецификация OpenID Connect требует использования формата JWT для токенов ID, которые содержат информацию профиля пользователя (например, имя и адрес электронной почты пользователя), представленную в форме утверждений.Эти утверждения представляют собой утверждения о пользователе, которым можно доверять, если потребитель токена может проверить его подпись.
Хотя спецификация OAuth3 не требует формата для токенов доступа, используемых для предоставления приложениям доступа к API-интерфейсам от имени пользователей, в отрасли широко распространено использование JWT и для них.
Как разработчик, вам не нужно беспокоиться о непосредственной проверке, проверке или декодировании связанных с аутентификацией JWT в ваших сервисах. Вы можете использовать современные SDK от Auth0 для правильной реализации и использования JWT, зная, что они соответствуют последним передовым отраслевым практикам и регулярно обновляются для устранения известных рисков безопасности.
Например, Auth0 SDK для одностраничных приложений предоставляет метод извлечения информации о пользователе из идентификатора идентификатора auth0.getUser .
Если вы хотите опробовать платформу Auth0, зарегистрируйте бесплатную учетную запись и приступайте к работе! С вашей бесплатной учетной записью у вас будет доступ к следующим функциям:
Чтобы узнать больше о JWT, их внутренней структуре, различных типах алгоритмов, которые могут использоваться с ними, и других типичных применениях, ознакомьтесь с руководством JWT.
RFC 7518 - веб-алгоритмы JSON (JWA)
[Docs] [txt | pdf] [draft-ietf-jose ...] [Tracker] [Diff1] [Diff2] [IPR]
ПРЕДЛАГАЕМЫЙ СТАНДАРТ
Инженерная группа Интернета (IETF) М. Джонс
Запрос комментариев: 7518 Microsoft
Категория: Standards Track Май 2015
ISSN: 2070-1721 гг.
Веб-алгоритмы JSON (JWA)
Аннотация
Эта спецификация регистрирует криптографические алгоритмы и идентификаторы.
для использования с веб-подписью JSON (JWS), веб-шифрованием JSON
(JWE) и спецификации веб-ключа JSON (JWK).Он определяет несколько
Реестры IANA для этих идентификаторов.
Статус этой памятки
Это документ Internet Standards Track.
Этот документ является продуктом Инженерной группы Интернета.
(IETF). Он представляет собой консенсус сообщества IETF. Оно имеет
получил публичное рецензирование и был одобрен к публикации
Инженерная группа управления Интернетом (IESG). Дополнительная информация о
Интернет-стандарты доступны в разделе 2 RFC 5741.
Информация о текущем статусе этого документа, исправлениях,
а как оставить отзыв о нем можно узнать на
http: // www.rfc-editor.org/info/rfc7518.
Уведомление об авторских правах
Авторские права (c) 2015 IETF Trust и лица, указанные как
авторы документа. Все права защищены.
Этот документ регулируется BCP 78 и Правовой нормой IETF Trust.
Положения, касающиеся документов IETF
(http://trustee.ietf.org/license-info) действует на дату
публикация этого документа. Просмотрите эти документы
внимательно, поскольку они уважительно описывают ваши права и ограничения
к этому документу. Компоненты кода, извлеченные из этого документа, должны
включить упрощенный текст лицензии BSD, как описано в разделе 4.е из
Правовые положения Trust и предоставляются без гарантии, как
описана в упрощенной лицензии BSD.
Jones Standards Track [Страница 1]
RFC 7518 JSON Web Algorithms (JWA) Май 2015 г.
Содержание
1. Введение . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Условные обозначения. . . . . . . . . . . . . . . . . 4
2. Терминология. . . . . . . . . . . .. . . . . . . . . . . . . 5
3. Криптографические алгоритмы цифровых подписей и MAC. . 6
3.1. Значения параметра заголовка "alg" (алгоритм) для JWS. . . . 6
3.2. HMAC с функциями SHA-2. . . . . . . . . . . . . . . . 7
3.3. Цифровая подпись с RSASSA-PKCS1-v1_5. . . . . . . . 8
3.4. Цифровая подпись с ECDSA. . . . . . . . . . . . . . 9
3.5. Цифровая подпись с RSASSA-PSS. . . . . . . . . . . . 10
3.6. Использование алгоритма «нет».. . . . . . . . . . . . . . 11
4. Криптографические алгоритмы управления ключами. . . . . . . . . 11
4.1. Значения параметра заголовка "alg" (алгоритм) для JWE. . . . 12
4.2. Ключевое шифрование с помощью RSAES-PKCS1-v1_5. . . . . . . . . . 13
4.3. Ключевое шифрование с RSAES OAEP. . . . . . . . . . . . . 14
4.4. Перенос ключей с помощью AES Key Wrap. . . . . . . . . . . . . 14
4.5. Прямое шифрование с общим симметричным ключом. . . . . . 15
4.6. Ключевое соглашение с эллиптической кривой Диффи-Хеллмана
Эфемерная статика (ECDH-ES).. . . . . . . . . . . . . . 15
4.6.1. Параметры заголовка, используемые для согласования ключа ECDH. . . . 16
4.6.1.1. Параметр заголовка «epk» (эфемерный открытый ключ). . 16
4.6.1.2. Параметр заголовка "apu" (соглашение PartyUInfo). . 17
4.6.1.3. Параметр заголовка "apv" (соглашение PartyVInfo). . 17
4.6.2. Вывод ключа для ключевого соглашения ECDH. . . . . . . . 17
4.7. Ключевое шифрование с помощью AES GCM. . . . . . . . . . . . . . . 18
4.7.1. Параметры заголовка, используемые для шифрования ключа AES GCM.. 19
4.7.1.1. Параметр заголовка "iv" (вектор инициализации). . 19
4.7.1.2. "tag" (тег аутентификации) Параметр заголовка. . . 19
4.8. Ключевое шифрование с помощью PBES2. . . . . . . . . . . . . . . . 20
4. 8.1. Параметры заголовка, используемые для шифрования ключа PBES2. . . 20
4.8.1.1. Параметр заголовка "p2s" (ввод соли PBES2). . . . 21 год
4.8.1.2. Параметр заголовка "p2c" (счетчик PBES2). . . . . . 21 год
5. Криптографические алгоритмы шифрования контента.. . . . . . 21 год
5.1. "enc" (алгоритм шифрования) Значения параметра заголовка для
JWE. . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.2. AES_CBC_HMAC_SHA2 Алгоритмы. . . . . . . . . . . . . . 22
5.2.1. Соглашения, используемые при определении AES_CBC_HMAC_SHA2. . . 23
5.2.2. Общий алгоритм AES_CBC_HMAC_SHA2. . . . . . . . . 23
5.2.2.1. AES_CBC_HMAC_SHA2 Шифрование. . . . . . . . . . 23
5.2.2.2. AES_CBC_HMAC_SHA2 Расшифровка. .. . . . . . . . 25
5.2.3. AES_128_CBC_HMAC_SHA_256. . . . . . . . . . . . . . 25
5.2.4. AES_192_CBC_HMAC_SHA_384. . . . . . . . . . . . . . 26
5.2.5. AES_256_CBC_HMAC_SHA_512. . . . . . . . . . . . . . 26
5. 2.6. Шифрование содержимого с помощью AES_CBC_HMAC_SHA2. . . . . . 26
5.3. Шифрование контента с помощью AES GCM. . . . . . . . . . . . . 27
6. Криптографические алгоритмы ключей. . . . . . . . . . . . . . 27
6.1. Значения параметра «kty» (тип ключа).. . . . . . . . . . . 28
Jones Standards Track [Страница 2]
RFC 7518 JSON Web Algorithms (JWA) Май 2015 г.
6.2. Параметры ключей эллиптических кривых. . . . . . . . . . . 28
6.2.1. Параметры для открытых ключей эллиптических кривых. . . . . . 28
6.2.1.1. Параметр "crv" (Кривая). . . . . . . . . . . . . 28
6.2.1.2. Параметр "x" (координата X). . . . . . . . . . 29
6.2.1.3. Параметр "y" (координата Y). . . . . . . . . . 29
6.2.2. Параметры закрытых ключей эллиптических кривых. . . . . 29
6.2.2.1. Параметр "d" (закрытый ключ ECC). . . . . . . . . 29
6.3. Параметры для ключей RSA. . . . . . . . . . . . . . . . . 30
6.3.1. Параметры для открытых ключей RSA. . . . . . . . . . . 30
6.3.1.1. Параметр "n" (Модуль). . . . . . . . . . . . . 30
6.3.1.2. Параметр "е" (экспонента). . . . . . . . . . . . 30
6.3.2. Параметры для закрытых ключей RSA. . . . . . . . . . . 30
6.3.2.1. Параметр "d" (частный показатель степени). . . . . . . . 30
6.3.2.2. Параметр "p" (первый основной коэффициент). . . . . . . 31 год
6.3.2.3. Параметр «q» (второй основной коэффициент). . . . . . . 31 год
6.3.2.4. Параметр "dp" (показатель степени ЭЛТ первого фактора). . . 31 год
6.3.2.5. Параметр "dq" (второй фактор CRT Exponent). . . 31 год
6.3.2.6. Параметр "qi" (первый коэффициент ЭЛТ). . . . . 31 год
6.3.2.7. Параметр "oth" (информация о других простых числах). . . . . . . 31 год
6.4. Параметры для симметричных ключей. . . . . . . . . . . . . . 32
6.4.1. Параметр "k" (ключевое значение). . . . . . . . . . . . . . 32
7. Соображения IANA. . . . . . . . . . . . . . . . . . . . . 32
7.1. Реестр веб-подписей и алгоритмов шифрования JSON. . 33
7.1.1. Шаблон регистрации. . . . . . . . . . . . . . . . 34
7.1.2. Первоначальное содержимое реестра. . . . . . . . . . . . . . 35 год
7.2. Регистрация имен параметров заголовка. . . . . . . . . . . 42
7.2.1. Содержимое реестра. . . . . . . . . . . . . . . . . . 42
7.3. Реестр алгоритмов сжатия веб-шифрования JSON. . . 43
7.3.1. Шаблон регистрации. . . . . . . . . . . . . . . . 43
7.3.2. Первоначальное содержимое реестра. . . . . . . . . . . . . . 44
7.4. Реестр типов веб-ключей JSON. . . . . . . . . . . . . . . 44
7.4.1. Шаблон регистрации. . . . . . . . . . . . . . . . 44
7.4.2. Первоначальное содержимое реестра. . . . . . . . . . . . . . 45
7.5. Регистрация параметров веб-ключа JSON. . . . . . . . . . 45
7.5.1. Содержимое реестра. . . . . . . . . . . . . . . . . . 46
7.6. Реестр эллиптических кривых веб-ключей JSON. . . . . . . . . . 48
7.6.1. Шаблон регистрации. . . . . . . . . . . . . . . . 48
7.6.2. Первоначальное содержимое реестра. . . . . . . . . . . . . . 49
8. Соображения безопасности. . . . . . . . . . . . . . . . . . . 49
8.1. Криптографическая гибкость. . . . . . . . . . . . . . . . . . 50
8.2. Ключевые времена жизни. . . . . . . . . . . . . . . . . . . . . . 50
8.3. RSAES-PKCS1-v1_5 Вопросы безопасности. . . . . . . . 50
8.4. Вопросы безопасности AES GCM. . . . . . . . . . . . . 50
8.5. Вопросы безопасности незащищенного JWS. . . . . . . . . . 51
8.6. Атаки отказа в обслуживании. . . . . . . . . . . . . . . . 51
8.7. Повторное использование материала ключа при шифровании ключей. . . . . . . . 51
8.8. Вопросы пароля. . . . . . . . . . . . . . . . . 52
8.9. Ключевая энтропия и случайные значения. . . . . . . . . . . . . . 52
Jones Standards Track [Страница 3]
RFC 7518 JSON Web Algorithms (JWA) Май 2015 г.
8.10. Различия между цифровыми подписями и MAC. . . . . 52
8.11. Использование сильных сторон алгоритма сопоставления. . . . . . . . . . . 53
8.12. Адаптивные атаки по выбранному зашифрованному тексту.. . . . . . . . . . 53
8.13. Время атаки. . . . . . . . . . . . . . . . . . . . . 53
8.14. Представления закрытого ключа RSA и ослепление. . . . . . 53
9. Соображения интернационализации. . . . . . . . . . . . . 53
10. Список литературы. . . . . . . . . . . . . . . . . . . . . . . . . 53
10.1. Нормативные ссылки . . . . . . . . . . . . . . . . . . 53
10.2. Информативные ссылки. . . . . . . . . . . . . . . . . 56
Приложение A. Перекрестная ссылка идентификатора алгоритма.. . . . . . . 59
А.1. Цифровая подпись / идентификатор алгоритма MAC Cross-
Справка . . . . . . . . . . . . . . . . . . . . . . . . 60
А.2. Перекрестная ссылка на идентификатор алгоритма управления ключами. . . 61
А.3. Перекрестная ссылка на идентификатор алгоритма шифрования содержимого. 62
Приложение Б. Тестовые примеры для алгоритмов AES_CBC_HMAC_SHA2. . . . 62
В.1. Тестовые примеры для AES_128_CBC_HMAC_SHA_256. . . . . . . . . 63
БИ 2. Тестовые примеры для AES_192_CBC_HMAC_SHA_384. . .. . . . . . 64
В.3. Тестовые примеры для AES_256_CBC_HMAC_SHA_512. . . . . . . . . 65
Приложение C. Пример расчета ключевого соглашения ECDH-ES. . . . . 66
Благодарности. . . . . . . . . . . . . . . . . . . . . . . . 69
Адрес автора. . . . . . . . . . . . . . . . . . . . . . . . 69
1. Введение
Эта спецификация регистрирует криптографические алгоритмы и идентификаторы.
для использования с веб-подписью JSON (JWS) [JWS], JSON Web
Спецификации шифрования (JWE) [JWE] и веб-ключа JSON (JWK) [JWK].Он определяет несколько реестров IANA для этих идентификаторов. Все эти
спецификации используют структуры данных на основе JSON [RFC7159]. Этот
спецификация также описывает семантику и операции, которые
специфические для этих алгоритмов и типов ключей.
Регистрация алгоритмов и идентификаторов здесь, а не в
Спецификации JWS, JWE и JWK предназначены для того, чтобы они оставались
без изменений с учетом изменений в наборе Обязательных, Рекомендуемых,
Необязательные и устаревшие алгоритмы с течением времени. Это также позволяет
вносит изменения в спецификации JWS, JWE и JWK без изменения этого
документ.
Имена, определенные в этой спецификации, короткие, потому что основная цель
для компактности полученных представлений.
1.1. Условные обозначения
Ключевые слова «ДОЛЖНЫ», «НЕ ДОЛЖНЫ», «ОБЯЗАТЕЛЬНО», «ДОЛЖНЫ», «НЕ ДОЛЖНЫ»,
«ДОЛЖЕН», «НЕ ДОЛЖЕН», «РЕКОМЕНДУЕТСЯ», «НЕ РЕКОМЕНДУЕТСЯ», «МОЖЕТ» и
«ДОПОЛНИТЕЛЬНО» в этом документе следует толковать, как описано в
«Ключевые слова для использования в RFC для обозначения уровней требований» [RFC2119].Jones Standards Track [Страница 4]
RFC 7518 JSON Web Algorithms (JWA) Май 2015 г.
Интерпретация должна применяться только тогда, когда термины появляются в
все заглавные буквы.
BASE64URL (OCTETS) обозначает кодировку base64url для OCTETS, согласно
Раздел 2 [JWS].
UTF8 (STRING) обозначает октеты представления UTF-8 [RFC3629].
из STRING, где STRING - это последовательность из нуля или более Unicode
[UNICODE] символы. ASCII (STRING) обозначает октеты представления ASCII [RFC20].
of STRING, где STRING - это последовательность из нуля или более ASCII
символы.
Объединение двух значений A и B обозначается как A || Б.
2. Терминология
Термины «Веб-подпись JSON (JWS)», «Кодировка Base64url», «Заголовок
Параметр »,« Заголовок JOSE »,« Полезная нагрузка JWS »,« Защищенный заголовок JWS »,
"Подпись JWS", "Вход для подписи JWS" и "Незащищенный JWS" определены
согласно спецификации JWS [JWS].
Термины «JSON Web Encryption (JWE)», «Дополнительные проверенные данные
(AAD) "," Тег аутентификации "," Ключ шифрования содержимого (CEK) "," Прямой
Шифрование "," Соглашение о прямом ключе "," Тег аутентификации JWE "," JWE
Шифрованный текст "," Зашифрованный ключ JWE "," Вектор инициализации JWE "," JWE
Защищенный заголовок "," Соглашение о ключах с переносом ключей "," Ключ
Шифрование "," Режим управления ключами "и" Перенос ключей "определяются
спецификация JWE [JWE].Термины «Веб-ключ JSON (JWK)» и «Набор JWK» определены JWK.
спецификация [JWK].
Термины «Шифрованный текст», «Цифровая подпись», «Вектор инициализации»,
«Код аутентификации сообщения (MAC)» и «Открытый текст» определяются
"Глоссарий по безопасности в Интернете, версия 2" [RFC4949].
Этот термин определяется данной спецификацией:
Base64urlUInt
Представление положительного или нулевого целочисленного значения как
base64url кодирование беззнакового обратного порядка байтов значения
представление в виде последовательности октетов.Последовательность октетов ДОЛЖНА
использовать минимальное количество октетов, необходимых для представления
значение. Ноль представлен как BASE64URL (одиночный нулевой
октет), то есть "AA".
Jones Standards Track [Страница 5]
RFC 7518 JSON Web Algorithms (JWA) Май 2015 г.
3. Криптографические алгоритмы для цифровых подписей и MAC
JWS использует криптографические алгоритмы для цифровой подписи или создания MAC
содержимого защищенного заголовка JWS и полезной нагрузки JWS.3.1. Значения параметра заголовка "alg" (алгоритм) для JWS
В таблице ниже представлен набор параметров заголовка "alg" (алгоритм).
значения, определенные в этой спецификации для использования с JWS, каждое из которых
более подробно объясняется в следующих разделах:
+ -------------- + ------------------------------- + - ------------------ +
| "alg" Param | Цифровая подпись или MAC | Реализация |
| Значение | Алгоритм | Требования |
+ -------------- + ------------------------------- + - ------------------ +
| HS256 | HMAC с использованием SHA-256 | Обязательно |
| HS384 | HMAC с использованием SHA-384 | Необязательно |
| HS512 | HMAC с использованием SHA-512 | Необязательно |
| RS256 | RSASSA-PKCS1-v1_5 с использованием | Рекомендуется |
| | SHA-256 | |
| RS384 | RSASSA-PKCS1-v1_5 с использованием | Необязательно |
| | SHA-384 | |
| RS512 | RSASSA-PKCS1-v1_5 с использованием | Необязательно |
| | SHA-512 | |
| ES256 | ECDSA с использованием P-256 и SHA-256 | Рекомендуется + |
| ES384 | ECDSA с использованием P-384 и SHA-384 | Необязательно |
| ES512 | ECDSA с использованием P-521 и SHA-512 | Необязательно |
| PS256 | RSASSA-PSS с использованием SHA-256 и | Необязательно |
| | MGF1 с SHA-256 | |
| PS384 | RSASSA-PSS с использованием SHA-384 и | Необязательно |
| | MGF1 с SHA-384 | |
| PS512 | RSASSA-PSS с использованием SHA-512 и | Необязательно |
| | MGF1 с SHA-512 | |
| нет | Нет цифровой подписи или MAC | Необязательно |
| | выполнено | |
+ -------------- + ------------------------------- + - ------------------ +
Использование знака «+» в столбце «Требования к реализации» означает
что сила требований, вероятно, будет увеличена в будущем
версия спецификации.См. Приложение A.1 с таблицей перекрестных ссылок на JWS digital.
сигнатуры и значения MAC "alg" (алгоритм), определенные в этом
спецификация с эквивалентными идентификаторами, используемыми другими стандартами
и программные пакеты.
Jones Standards Track [Страница 6]
RFC 7518 JSON Web Algorithms (JWA) Май 2015 г.
3.2. HMAC с функциями SHA-2
Коды аутентификации сообщений на основе хэша (HMAC) позволяют использовать
секрет плюс криптографическая хеш-функция для генерации MAC.Этот
может использоваться, чтобы продемонстрировать, что тот, кто сгенерировал MAC, был в
владение ключом MAC. Алгоритм реализации и
проверка HMAC представлена в RFC 2104 [RFC2104].
Ключ того же размера, что и выходной хэш (например, 256 бит для
"HS256") или больше ДОЛЖНЫ использоваться с этим алгоритмом. (Этот
требование основано на Разделе 5.3.4 (Эффект безопасности HMAC
Key) стандарта NIST SP 800-117 [NIST.800-107], в котором говорится, что
эффективная сила безопасности - это минимум силы безопасности
ключа и в два раза больше внутреннего хеш-значения.)
MAC-адрес HMAC SHA-256 создается согласно RFC 2104 с использованием SHA-256 в качестве
алгоритм хеширования "H", использующий вход для подписи JWS в качестве "текстового" значения,
и используя общий ключ. Выходное значение HMAC - это JWS.
Подпись.
Следующие значения параметра заголовка "alg" (алгоритм) используются для
указывают, что подпись JWS - это значение HMAC, вычисленное с использованием
соответствующий алгоритм:
+ ------------------- + -------------------- +
| Значение параметра "alg" | MAC-алгоритм |
+ ------------------- + -------------------- +
| HS256 | HMAC с использованием SHA-256 |
| HS384 | HMAC с использованием SHA-384 |
| HS512 | HMAC с использованием SHA-512 |
+ ------------------- + -------------------- +
MAC-адрес HMAC SHA-256 для JWS проверяется путем вычисления HMAC.
значение согласно RFC 2104, используя SHA-256 в качестве хэш-алгоритма "H", используя
полученный ввод подписи JWS в качестве "текстового" значения и с использованием
Общий ключ.Это вычисленное значение HMAC затем сравнивается с результатом.
base64url декодирует полученное закодированное значение подписи JWS. В
сравнение вычисленного значения HMAC со значением подписи JWS ДОЛЖНО
быть сделано в режиме постоянного времени, чтобы предотвратить атаки по времени.
В качестве альтернативы, вычисленное значение HMAC может быть закодировано base64url и
по сравнению с полученным закодированным значением подписи JWS (также в
постоянным временем), так как это сравнение дает тот же результат, что и
сравнение незакодированных значений.В любом случае, если значения совпадают,
HMAC прошел валидацию.
Jones Standards Track [Страница 7]
RFC 7518 JSON Web Algorithms (JWA) Май 2015 г.
Защита контента и проверка с помощью HMAC SHA-384 и HMAC
Алгоритмы SHA-512 выполняются идентично процедуре для HMAC.
SHA-256 - просто используя соответствующие алгоритмы хеширования с
соответственно большие минимальные размеры ключей и значения результатов: 384 бита
каждый для HMAC SHA-384 и 512 бит для HMAC SHA-512.Пример использования этого алгоритма показан в Приложении A.1 [JWS].
3.3. Цифровая подпись с RSASSA-PKCS1-v1_5
В этом разделе определяется использование цифрового RSASSA-PKCS1-v1_5.
алгоритм подписи, как определено в разделе 8.2 RFC 3447 [RFC3447]
(широко известный как PKCS # 1) с использованием хэш-функций SHA-2 [SHS].
С этими алгоритмами ДОЛЖЕН использоваться ключ размером 2048 бит или больше.
Цифровая подпись RSASSA-PKCS1-v1_5 SHA-256 создается как
следует: сгенерировать цифровую подпись входных данных для подписи JWS, используя
RSASSA-PKCS1-v1_5-SIGN и хеш-функцию SHA-256 с желаемым
закрытый ключ.Это значение подписи JWS.
Следующие значения параметра заголовка "alg" (алгоритм) используются для
указывают, что подпись JWS - это вычисленное значение цифровой подписи
используя соответствующий алгоритм:
+ ------------------- + ----------------------------- ---- +
| Значение параметра "alg" | Алгоритм цифровой подписи |
+ ------------------- + ----------------------------- ---- +
| RS256 | RSASSA-PKCS1-v1_5 с использованием SHA-256 |
| RS384 | RSASSA-PKCS1-v1_5 с использованием SHA-384 |
| RS512 | RSASSA-PKCS1-v1_5 с использованием SHA-512 |
+ ------------------- + ----------------------------- ---- +
Цифровая подпись RSASSA-PKCS1-v1_5 SHA-256 для JWS:
проверяется следующим образом: отправьте вход для подписи JWS, JWS
Подпись и открытый ключ, соответствующий используемому закрытому ключу
подписывающей стороной к алгоритму RSASSA-PKCS1-v1_5-VERIFY с использованием SHA-256
как хеш-функция.Подпись и проверка с помощью RSASSA-PKCS1-v1_5 SHA-384 и RSASSA-
PKCS1-v1_5 алгоритмы SHA-512 выполняются идентично алгоритму
процедура для RSASSA-PKCS1-v1_5 SHA-256 - просто используя
соответствующие алгоритмы хеширования вместо SHA-256.
Пример использования этого алгоритма показан в Приложении A.2 [JWS].
Jones Standards Track [Страница 8]
RFC 7518 JSON Web Algorithms (JWA) Май 2015 г.
3.4. Цифровая подпись с ECDSA
Алгоритм цифровой подписи с эллиптической кривой (ECDSA) [DSS] обеспечивает
для использования криптографии с эллиптическими кривыми, которая может обеспечить
эквивалентная безопасность криптографии RSA, но с использованием более коротких размеров ключей
и с большей скоростью обработки для многих операций. Это означает
что цифровые подписи ECDSA будут существенно меньше
длины, чем эквивалентно сильные цифровые подписи RSA.
Эта спецификация определяет использование ECDSA с кривой P-256 и
криптографическая хеш-функция SHA-256, ECDSA с кривой P-384
и хеш-функцию SHA-384, и ECDSA с кривой P-521 и
Хеш-функция SHA-512.Кривые P-256, P-384 и P-521
определено в [DSS].
Цифровая подпись ECDSA P-256 SHA-256 генерируется следующим образом:
1. Создайте цифровую подпись входных данных для подписи JWS с помощью ECDSA.
P-256 SHA-256 с желаемым закрытым ключом. На выходе будет
пара (R, S), где R и S - 256-битные целые числа без знака.
2. Превратите R и S в последовательности октетов в обратном порядке, при этом каждая
длина массива составляет 32 октета. Последовательность октетов
представления НЕ ДОЛЖНЫ быть сокращены, чтобы опустить любой ведущий ноль
октеты, содержащиеся в значениях.3. Соедините две последовательности октетов в порядке R, а затем S.
(Обратите внимание, что многие реализации ECDSA напрямую создают это
конкатенация в качестве их вывода.)
4. Результирующая 64-октетная последовательность является значением подписи JWS.
Следующие значения параметра заголовка "alg" (алгоритм) используются для
указывают, что подпись JWS - это вычисленное значение цифровой подписи
используя соответствующий алгоритм:
+ ------------------- + ----------------------------- - +
| Значение параметра "alg" | Алгоритм цифровой подписи |
+ ------------------- + ----------------------------- - +
| ES256 | ECDSA с использованием P-256 и SHA-256 |
| ES384 | ECDSA с использованием P-384 и SHA-384 |
| ES512 | ECDSA с использованием P-521 и SHA-512 |
+ ------------------- + ----------------------------- - +
Jones Standards Track [Страница 9]
RFC 7518 JSON Web Algorithms (JWA) Май 2015 г.
Цифровая подпись ECDSA P-256 SHA-256 для JWS проверяется как
следует:
1.Значение подписи JWS ДОЛЖНО быть последовательностью из 64 октетов. Если это
не 64-октетная последовательность, проверка не удалась.
2. Разделите последовательность из 64 октетов на две последовательности по 32 октета. В
первая последовательность октетов представляет R, а вторая S. Значения R
и S представлены как последовательности октетов с использованием функции Integer-to-
Преобразование OctetString определено в разделе 2.3.7 SEC1 [SEC1]
(в порядке байтов с прямым порядком байтов).
3. Отправьте входные данные для подписи JWS, R, S и открытый ключ (x, y) в
валидатор ECDSA P-256 SHA-256.Подписание и проверка с помощью ECDSA P-384 SHA-384 и ECDSA P-521
Алгоритмы SHA-512 выполняются идентично процедуре для
ECDSA P-256 SHA-256 - просто используя соответствующие алгоритмы хеширования
с соответственно большими значениями результата. Для ECDSA P-384 SHA-384,
R и S будут иметь 384 бита каждый, что даст последовательность из 96 октетов. За
ECDSA P-521 SHA-512, R и S будут 521 бит каждый, в результате
132-октетная последовательность. (Обратите внимание, что преобразование целой строки в октетную строку
определено в разделе 2.3.7 из SEC1 [SEC1] используется для представления R и S как
последовательности октетов при необходимости добавляют старшие биты заполнения с нулевым значением
округлить размер до кратного 8 битам; таким образом, каждый 521-битный
целое число представлено 528 битами в 66 октетах.)
Примеры использования этих алгоритмов приведены в Приложениях A.3 и A.4.
из [JWS].
3.5. Цифровая подпись с RSASSA-PSS
В этом разделе определяется использование цифровой подписи RSASSA-PSS.
алгоритм, как определено в разделе 8.1 RFC 3447 [RFC3447] с
Функция генерации маски MGF1 и хэш-функции SHA-2, всегда использующие
одна и та же хэш-функция для хэш-функции RSASSA-PSS и
Хэш-функция MGF1.Размер значения соли такой же, как и
вывод хэш-функции. Все остальные параметры алгоритма используют
значения по умолчанию, указанные в Приложении A.2.3 RFC 3447.
В этом алгоритме ДОЛЖЕН использоваться ключ размером 2048 бит или больше.
Цифровая подпись RSASSA-PSS SHA-256 генерируется следующим образом:
генерировать цифровую подпись входных данных для подписи JWS с помощью RSASSA-
PSS-SIGN, хэш-функция SHA-256 и генерация маски MGF1
функция с SHA-256 с желаемым закрытым ключом.Это JWS
Значение подписи.
Jones Standards Track [Страница 10]
RFC 7518 JSON Web Algorithms (JWA) Май 2015 г.
Следующие значения параметра заголовка "alg" (алгоритм) используются для
указывают, что подпись JWS - это вычисленное значение цифровой подписи
используя соответствующий алгоритм:
+ ------------------- + ----------------------------- ------------------ +
| Значение параметра "alg" | Алгоритм цифровой подписи |
+ ------------------- + ----------------------------- ------------------ +
| PS256 | RSASSA-PSS с использованием SHA-256 и MGF1 с |
| | SHA-256 |
| PS384 | RSASSA-PSS с использованием SHA-384 и MGF1 с |
| | SHA-384 |
| PS512 | RSASSA-PSS с использованием SHA-512 и MGF1 с |
| | SHA-512 |
+ ------------------- + ----------------------------- ------------------ +
Цифровая подпись RSASSA-PSS SHA-256 для JWS проверяется как
следующим образом: отправьте вход для подписи JWS, подпись JWS и
открытый ключ, соответствующий закрытому ключу, используемому подписывающей стороной для
Алгоритм RSASSA-PSS-VERIFY с использованием SHA-256 в качестве хэш-функции и
использование MGF1 в качестве функции генерации маски с SHA-256.Подпись и проверка с помощью RSASSA-PSS SHA-384 и RSASSA-PSS
Алгоритмы SHA-512 выполняются идентично процедуре для
RSASSA-PSS SHA-256 - просто используя альтернативный алгоритм хеширования в
обе роли.
3.6. Использование алгоритма «нет»
Также МОГУТ быть созданы JWS, которые не обеспечивают защиту целостности.
Такой JWS называется незащищенным JWS. Незащищенный JWS использует
"alg" значение "none" и форматируется идентично другим JWS, но
ДОЛЖЕН использовать пустую последовательность октетов в качестве значения подписи JWS.Получатели ДОЛЖНЫ проверить, что значение подписи JWS пустое.
последовательность октетов.
Реализации, поддерживающие незащищенные JWS, НЕ ДОЛЖНЫ принимать такие
объекты как действительные, если приложение не указывает, что это
допустимо для конкретного объекта, не имеющего защиты целостности.
Реализации НЕ ДОЛЖНЫ принимать незащищенные JWS по умолчанию. Для того, чтобы
для предотвращения атак на более раннюю версию приложения НЕ ДОЛЖНЫ сигнализировать
принятие незащищенных JWS на глобальном уровне и ДОЛЖЕН сигнализировать
приемка по объектам.См. Раздел 8.5 по безопасности
соображения, связанные с использованием этого алгоритма.
4. Криптографические алгоритмы управления ключами
JWE использует криптографические алгоритмы для шифрования или определения Контента.
Ключ шифрования (CEK).
Jones Standards Track [Страница 11]
RFC 7518 JSON Web Algorithms (JWA) Май 2015 г.
4.1. Значения параметра заголовка "alg" (алгоритм) для JWE
В таблице ниже представлен набор параметров заголовка "alg" (алгоритм).
значения, определенные в этой спецификации для использования с JWE.Эти алгоритмы используются для шифрования CEK, создавая JWE
Зашифрованный ключ или использовать соглашение о ключах для согласования CEK.
+ -------------------- + -------------------- + ------- - + ---------------- +
| Значение параметра "alg" | Управление ключами | Подробнее | Реализация |
| | Алгоритм | Заголовок | Требования |
| | | Params | |
+ -------------------- + -------------------- + ------- - + ---------------- +
| RSA1_5 | RSAES-PKCS1-v1_5 | (нет) | Рекомендуем- |
| ЮАР-ОАЭП | РГАЭС ОАЭП с использованием | (нет) | Рекомендуется + |
| | параметры по умолчанию | | |
| RSA-OAEP-256 | РГАЭС ОАЭП с использованием | (нет) | Необязательно |
| | SHA-256 и MGF1 | | |
| | с SHA-256 | | |
| A128KW | Браслет для ключей AES с | (нет) | Рекомендуется |
| | начальный по умолчанию | | |
| | значение с использованием | | |
| | 128-битный ключ | | |
| A192KW | Браслет для ключей AES с | (нет) | Необязательно |
| | начальный по умолчанию | | |
| | значение с использованием | | |
| | 192-битный ключ | | |
| A256KW | Браслет для ключей AES с | (нет) | Рекомендуется |
| | начальный по умолчанию | | |
| | значение с использованием | | |
| | 256-битный ключ | | |
| dir | Прямое использование | (нет) | Рекомендуется |
| | общие симметричные | | |
| | ключ как CEK | | |
| ECDH-ES | Эллиптическая кривая | "эпк", | Рекомендуется + |
| | Диффи-Хеллман | "апу", | |
| | Эфемерная статика | "apv" | |
| | ключевое соглашение | | |
| | с использованием Concat KDF | | |
| ECDH-ES + A128KW | ECDH-ES с использованием | "эпк", | Рекомендуется |
| | Concat KDF и CEK | "апу", | |
| | завернутый | "apv" | |
| | «A128KW» | | |
| ECDH-ES + A192KW | ECDH-ES с использованием | "эпк", | Необязательно |
| | Concat KDF и CEK | "апу", | |
| | завернутый | "apv" | |
| | «A192KW» | | |
Jones Standards Track [Страница 12]
RFC 7518 JSON Web Algorithms (JWA) Май 2015 г.
| ECDH-ES + A256KW | ECDH-ES с использованием | "эпк", | Рекомендуется |
| | Concat KDF и CEK | "апу", | |
| | завернутый | "apv" | |
| | «A256KW» | | |
| A128GCMKW | Упаковка ключей с | "iv", | Необязательно |
| | AES GCM с использованием | "тег" | |
| | 128-битный ключ | | |
| A192GCMKW | Упаковка ключей с | "iv", | Необязательно |
| | AES GCM с использованием | "тег" | |
| | 192-битный ключ | | |
| A256GCMKW | Упаковка ключей с | "iv", | Необязательно |
| | AES GCM с использованием | "тег" | |
| | 256-битный ключ | | |
| PBES2-HS256 + A128KW | PBES2 с HMAC | "p2s", | Необязательно |
| | SHA-256 и | "p2c" | |
| | Упаковка "A128KW" | | |
| PBES2-HS384 + A192KW | PBES2 с HMAC | "p2s", | Необязательно |
| | SHA-384 и | "p2c" | |
| | Упаковка "A192KW" | | |
| PBES2-HS512 + A256KW | PBES2 с HMAC | "p2s", | Необязательно |
| | SHA-512 и | "p2c" | |
| | Упаковка "A256KW" | | |
+ -------------------- + -------------------- + ------- - + ---------------- +
В столбце «Дополнительные параметры заголовка» указано, какой дополнительный заголовок
Параметры используются алгоритмом, за исключением «alg», который все используют.Все, кроме dir и ECDH-ES, также создают значение зашифрованного ключа JWE.
Использование знака «+» в столбце «Требования к реализации» означает
что сила требований, вероятно, будет увеличена в будущем
версия спецификации. Использование знака «-» означает, что
сила требований, вероятно, будет уменьшена в будущей версии
спецификация.
См. Приложение A.2 для таблицы с перекрестными ссылками на JWE "alg"
(алгоритм) значения, определенные в этой спецификации, с эквивалентными
идентификаторы, используемые другими стандартами и программными пакетами.4.2. Шифрование ключей с помощью RSAES-PKCS1-v1_5
Этот раздел определяет особенности шифрования JWE CEK с помощью
RSAES-PKCS1-v1_5 [RFC3447]. Параметр заголовка "alg" (алгоритм)
значение "RSA1_5" используется для этого алгоритма.
В этом алгоритме ДОЛЖЕН использоваться ключ размером 2048 бит или больше.
Пример использования этого алгоритма показан в Приложении A.2 [JWE].
Jones Standards Track [Страница 13]
RFC 7518 JSON Web Algorithms (JWA) Май 2015 г.
4.3. Шифрование ключей с помощью RSAES OAEP
В этом разделе определены особенности шифрования JWE CEK с помощью RSAES.
с использованием оптимального заполнения асимметричным шифрованием (OAEP) [RFC3447]. Два
определены наборы параметров для использования OAEP, которые используют разные
хэш-функции. В первом случае параметры по умолчанию указаны
в Приложении A.2.1 RFC 3447. (Эти параметры по умолчанию
хэш-функция SHA-1 и MGF1 с генерацией маски SHA-1
функция.) Во втором случае хэш-функция SHA-256 и
Используются MGF1 с функцией генерации маски SHA-256.Следующие значения параметра заголовка "alg" (алгоритм) используются для
указывают, что зашифрованный ключ JWE является результатом шифрования
CEK с использованием соответствующего алгоритма:
+ ------------------- + ----------------------------- ------------------ +
| Значение параметра "alg" | Алгоритм управления ключами |
+ ------------------- + ----------------------------- ------------------ +
| ЮАР-ОАЭП | RSAES OAEP с параметрами по умолчанию |
| RSA-OAEP-256 | RSAES OAEP с использованием SHA-256 и MGF1 с |
| | SHA-256 |
+ ------------------- + ----------------------------- ------------------ +
С этими алгоритмами ДОЛЖЕН использоваться ключ размером 2048 бит или больше.(Это требование основано на Таблице 4 (Временные рамки безопасности)
NIST SP 800-57 [NIST.800-57], который требует 112 бит безопасности
для новых применений и Таблицу 2 (Сопоставимые сильные стороны) того же, что
утверждает, что 2048-битные ключи RSA обеспечивают 112 бит безопасности.)
Пример использования RSAES OAEP с параметрами по умолчанию показан на
Приложение A.1 [JWE].
4.4. Перенос ключей с помощью AES Key Wrap
В этом разделе определяются особенности шифрования JWE CEK с помощью
Алгоритм переноса ключа Advanced Encryption Standard (AES) [RFC3394] с использованием
начальное значение по умолчанию, указанное в разделе 2.2.3.1 из этого
документ.
Jones Standards Track [Страница 14]
RFC 7518 JSON Web Algorithms (JWA) Май 2015 г.
Следующие значения параметра заголовка "alg" (алгоритм) используются для
указывают, что зашифрованный ключ JWE является результатом шифрования
CEK с использованием соответствующего алгоритма и размера ключа:
+ ----------------- + ------------------------------- ------------------ +
| "alg" Param | Алгоритм управления ключами |
| Значение | |
+ ----------------- + ------------------------------- ------------------ +
| A128KW | AES Key Wrap с начальным значением по умолчанию с использованием |
| | 128-битный ключ |
| A192KW | AES Key Wrap с начальным значением по умолчанию с использованием |
| | 192-битный ключ |
| A256KW | AES Key Wrap с начальным значением по умолчанию с использованием |
| | 256-битный ключ |
+ ----------------- + ------------------------------- ------------------ +
Пример использования этого алгоритма приведен в Приложении A.3 из [JWE].
4.5. Прямое шифрование с общим симметричным ключом
В этом разделе описаны особенности прямого выполнения симметричных
шифрование ключей без выполнения этапа переноса ключей. В этом случае,
общий симметричный ключ используется непосредственно как шифрование содержимого
Значение ключа (CEK) для алгоритма "enc". Пустая последовательность октетов
используется в качестве значения зашифрованного ключа JWE. Заголовок "alg" (алгоритм)
В этом случае используется значение параметра "dir".
Обратитесь к соображениям безопасности по срокам жизни ключей в Разделе 8.2
и AES GCM в разделе 8.4 при рассмотрении использования прямого
шифрование.
4.6. Ключевое соглашение с эфемерной статикой Диффи-Хеллмана для эллиптических кривых
(ECDH-ES)
В этом разделе определены особенности согласования ключей с Elliptic.
Curve Diffie-Hellman Ephemeral Static [RFC6090], в сочетании с
Concat KDF, как определено в разделе 5.8.1 [NIST.800-56A]. В
Ключевой результат соглашения может быть использован одним из двух способов:
1. непосредственно в качестве ключа шифрования содержимого (CEK) для "enc"
алгоритма в режиме прямого согласования ключей, или
2.как симметричный ключ, используемый для обертывания CEK с «A128KW»,
Алгоритмы «A192KW» или «A256KW» в ключевом соглашении с Key
Режим упаковки.
Новое значение эфемерного открытого ключа ДОЛЖНО быть сгенерировано для каждого ключа.
договорная операция.
Jones Standards Track [Страница 15]
RFC 7518 JSON Web Algorithms (JWA) Май 2015 г.
В режиме прямого согласования ключей выходные данные Concat KDF ДОЛЖНЫ быть
ключ той же длины, что и используемый в алгоритме "enc".В этом
В этом случае пустая последовательность октетов используется в качестве зашифрованного ключа JWE.
значение. Значение параметра заголовка «alg» (алгоритм) «ECDH-ES» равно
используется в режиме прямого согласования ключей.
В режиме согласования ключей с переносом ключей вывод Concat KDF
ДОЛЖЕН быть ключом длины, необходимой для указанного переноса ключей.
алгоритм. В этом случае зашифрованный ключ JWE представляет собой оболочку CEK.
с согласованным ключом.
Следующие значения параметра заголовка "alg" (алгоритм) используются для
указывают, что зашифрованный ключ JWE является результатом шифрования
CEK, использующий результат алгоритма согласования ключей в качестве ключа
ключ шифрования для соответствующего алгоритма упаковки ключей:
+ ----------------- + ------------------------------- ------------------ +
| "alg" Param | Алгоритм управления ключами |
| Значение | |
+ ----------------- + ------------------------------- ------------------ +
| ECDH-ES + A128KW | ECDH-ES с использованием Concat KDF и CEK в оболочке |
| | «A128KW» |
| ECDH-ES + A192KW | ECDH-ES с использованием Concat KDF и CEK в оболочке |
| | «A192KW» |
| ECDH-ES + A256KW | ECDH-ES с использованием Concat KDF и CEK в оболочке |
| | «A256KW» |
+ ----------------- + ------------------------------- ------------------ +
4.6.1. Параметры заголовка, используемые для согласования ключей ECDH
Следующие имена параметров заголовка используются для ключевого соглашения как
определено ниже.
4.6.1.1. Параметр заголовка "epk" (эфемерный открытый ключ)
Значение "epk" (эфемерный открытый ключ), созданное отправителем для
использование в алгоритмах согласования ключей. Этот ключ представлен как
Значение открытого ключа веб-ключа JSON [JWK]. Он ДОЛЖЕН содержать только открытый ключ
параметры и ДОЛЖЕН содержать только минимальные параметры JWK
необходимо представлять ключ; другие включенные параметры JWK могут быть
проверены на последовательность и соблюдаются, либо их можно игнорировать.Этот
Параметр заголовка ДОЛЖЕН присутствовать и ДОЛЖЕН быть понят и обработан
реализациями, когда используются эти алгоритмы.
Jones Standards Track [Страница 16]
RFC 7518 JSON Web Algorithms (JWA) Май 2015 г.
4.6.1.2. Параметр заголовка "apu" (соглашение PartyUInfo)
Значение apu (соглашение PartyUInfo) для алгоритмов согласования ключей
используя его (например, "ECDH-ES"), представленный как закодированный base64url
строка.При использовании значение PartyUInfo содержит информацию о
производитель. Использование этого параметра заголовка НЕОБЯЗАТЕЛЬНО. Этот заголовок
Параметр ДОЛЖЕН пониматься и обрабатываться реализациями, когда
эти алгоритмы используются.
4.6.1.3. Параметр заголовка "apv" (соглашение PartyVInfo)
Значение apv (соглашение PartyVInfo) для алгоритмов согласования ключей
используя его (например, "ECDH-ES"), представленный как закодированный base64url
строка. При использовании значение PartyVInfo содержит информацию о
получатель.Использование этого параметра заголовка НЕОБЯЗАТЕЛЬНО. Этот
Параметр заголовка ДОЛЖЕН пониматься и обрабатываться реализациями.
когда используются эти алгоритмы.
4.6.2. Вывод ключа для ключевого соглашения ECDH
В процессе получения ключа согласованный ключ получается из
общий секрет Z, установленный с помощью алгоритма ECDH, на
Раздел 6.2.2.2 [NIST.800-56A].
Вывод ключей выполняется с помощью Concat KDF, как определено в
Раздел 5.8.1 [NIST.800-56A], где дайджест-метод - SHA-256.Параметры Concat KDF устанавливаются следующим образом:
Z
Это установлено для представления общего секрета Z в виде
последовательность октетов.
Keydatalen
Задается количество бит в желаемом ключе вывода. За
«ECDH-ES», это длина ключа, используемого алгоритмом «enc».
Для «ECDH-ES + A128KW», «ECDH-ES + A192KW» и «ECDH-ES + A256KW» это
составляет 128, 192 и 256 соответственно.
AlgorithmID
Значение AlgorithmID имеет вид Datalen || Данные, где Данные
представляет собой строку переменной длины из нуля или более октетов, а Datalen - это
32-битный счетчик с прямым порядком байтов фиксированной длины, который указывает
длина (в октетах) данных.В случае прямого ключевого соглашения,
Данные устанавливаются в октеты представления ASCII "enc"
Заголовок Значение параметра. В ключевом соглашении с переносом ключей
случае, Данные устанавливаются в октеты представления ASCII
"alg" (алгоритм) Заголовок Значение параметра.
Jones Standards Track [Страница 17]
RFC 7518 JSON Web Algorithms (JWA) Май 2015 г.
PartyUInfo
Значение PartyUInfo имеет вид Datalen || Данные, где Данные
строка переменной длины из нуля или более октетов, а Datalen - это
32-битный счетчик с прямым порядком байтов фиксированной длины, который указывает длину
(в октетах) данных.Если заголовок "apu" (соглашение PartyUInfo)
Параметр присутствует, данные устанавливаются на результат base64url
декодирование значения "apu" и Datalen устанавливается на количество
октеты в Data. В противном случае для Datalen установлено значение 0, а для Data установлено значение
пустая последовательность октетов.
PartyVInfo
Значение PartyVInfo имеет вид Datalen || Данные, где Данные
строка переменной длины из нуля или более октетов, а Datalen - это
32-битный счетчик с прямым порядком байтов фиксированной длины, который указывает длину
(в октетах) данных.Если заголовок "apv" (соглашение PartyVInfo)
Параметр присутствует, данные устанавливаются на результат base64url
декодирование значения "apv" и Datalen устанавливается на количество
октеты в Data. В противном случае для Datalen установлено значение 0, а для Data установлено значение
пустая последовательность октетов.
SuppPubInfo
Это установлено в keydatalen, представленном как 32-битный прямой порядок байтов.
целое число.
SuppPrivInfo
Задается пустая последовательность октетов.
Приложения должны указывать, как заголовки "apu" и "apv"
Параметры используются для этого приложения.Значения apu и apv
ДОЛЖЕН быть отличным при использовании. Приложения, желающие соответствовать
[NIST.800-56A] должен предоставлять значения, которые соответствуют требованиям
этот документ, например, используя значения, которые идентифицируют производителя и
потребитель. В качестве альтернативы приложения МОГУТ проводить вывод ключей в
аналогично «методу согласования ключей Диффи-Хеллмана» [RFC2631]:
в этом случае параметр "apu" МОЖЕТ быть опущен или представлять
случайное 512-битное значение (аналог PartyAInfo в Ephemeral-Static
mode в RFC 2631) и параметр "apv" НЕ ДОЛЖЕН присутствовать.См. Приложение C для примера расчета ключевого соглашения с использованием этого
метод.
4.7. Шифрование ключей с помощью AES GCM
В этом разделе описаны особенности шифрования содержимого JWE.
Ключ шифрования (CEK) с расширенным стандартом шифрования (AES) в
Режим Галуа / счетчика (GCM) ([AES] и [NIST.800-38D]).
Jones Standards Track [Страница 18]
RFC 7518 JSON Web Algorithms (JWA) Май 2015 г.
ТРЕБУЕТСЯ использование вектора инициализации (IV) размером 96 бит с
этот алгоритм.IV представлен в кодировке base64url как
значение параметра заголовка "iv" (вектор инициализации).
Используемое значение дополнительных проверенных данных - пустой октет.
строка.
Запрошенный размер вывода тега аутентификации ДОЛЖЕН быть 128 бит,
независимо от размера ключа.
Значение JWE Encrypted Key - это выходной зашифрованный текст.
Вывод тега аутентификации представлен в кодировке base64url
форма как «тег» (тег аутентификации) Значение параметра заголовка.
Следующие значения параметра заголовка "alg" (алгоритм) используются для
указывают, что зашифрованный ключ JWE является результатом шифрования
CEK с использованием соответствующего алгоритма и размера ключа:
+ ------------------- + ----------------------------- ---------------- +
| Значение параметра "alg" | Алгоритм управления ключами |
+ ------------------- + ----------------------------- ---------------- +
| A128GCMKW | Перенос ключей с помощью AES GCM с использованием 128-битного ключа |
| A192GCMKW | Перенос ключей с помощью AES GCM с использованием 192-битного ключа |
| A256GCMKW | Перенос ключей с помощью AES GCM с использованием 256-битного ключа |
+ ------------------- + ----------------------------- ---------------- +
4.7.1. Параметры заголовка, используемые для шифрования ключа AES GCM
Следующие параметры заголовка используются для шифрования ключа AES GCM.
4.7.1.1. Параметр заголовка "iv" (вектор инициализации)
Значение параметра заголовка "iv" (вектор инициализации) - это
представление в кодировке base64url 96-битного значения IV, используемого для
операция шифрования ключа. Этот параметр заголовка ДОЛЖЕН присутствовать и
ДОЛЖНЫ быть поняты и обработаны реализациями, когда эти
используются алгоритмы.
4.7.1.2. "tag" (Тег аутентификации) Параметр заголовка
Заголовок "tag" (тег аутентификации) Значение параметра - это
представление 128-битного тега аутентификации в кодировке base64url
значение, полученное в результате операции шифрования ключа.Этот заголовок
Параметр ДОЛЖЕН присутствовать, ДОЛЖЕН быть понят и обработан
реализации, когда используются эти алгоритмы.
Jones Standards Track [Страница 19]
RFC 7518 JSON Web Algorithms (JWA) Май 2015 г.
4.8. Ключевое шифрование с помощью PBES2
В этом разделе описаны особенности выполнения на основе пароля
шифрование JWE CEK, сначала получая ключ шифрования из
вводимый пользователем пароль с использованием схем PBES2, как указано в
Раздел 6.2 [RFC2898], затем зашифровав JWE CEK с помощью
производный ключ.
Эти алгоритмы используют алгоритмы HMAC SHA-2 в качестве псевдослучайных
Функция (PRF) для получения ключа PBKDF2 и переноса ключей AES
[RFC3394] для схемы шифрования. Ввод пароля PBES2 является
последовательность октетов; если используемый пароль представлен в виде текста
строка, а не последовательность октетов, кодировка текста UTF-8
строка ДОЛЖНА использоваться как последовательность октетов. Параметр соли ДОЛЖЕН
вычисляться из "p2s" (ввод соли PBES2) Значение параметра заголовка
и значение параметра заголовка "alg" (алгоритм), как указано в
Определение "p2s" ниже.Параметр счетчика итераций ДОЛЖЕН быть
предоставляется как значение параметра заголовка "p2c" (счетчик PBES2). В
алгоритмы соответственно используют HMAC SHA-256, HMAC SHA-384 и HMAC
SHA-512 в качестве PRF и использует 128-, 192- и 256-битные ключи AES Key Wrap.
Длина их производных ключей составляет соответственно 16, 24 и 32 октета.
Следующие значения параметра заголовка "alg" (алгоритм) используются для
указывают, что зашифрованный ключ JWE является результатом шифрования
CEK, использующий результат соответствующего шифрования на основе пароля
алгоритм в качестве ключа шифрования для соответствующего ключа
алгоритм упаковки:
+ -------------------- + ---------------------------- ------------------ +
| Значение параметра "alg" | Алгоритм управления ключами |
+ -------------------- + ---------------------------- ------------------ +
| PBES2-HS256 + A128KW | PBES2 с HMAC SHA-256 и «A128KW» |
| | упаковка |
| PBES2-HS384 + A192KW | PBES2 с HMAC SHA-384 и «A192KW» |
| | упаковка |
| PBES2-HS512 + A256KW | PBES2 с HMAC SHA-512 и «A256KW» |
| | упаковка |
+ -------------------- + ---------------------------- ------------------ +
См. Приложение C спецификации JWK [JWK] для примера ключа
вычисление шифрования с использованием «PBES2-HS256 + A128KW».4.8.1. Параметры заголовка, используемые для шифрования ключа PBES2
Следующие параметры заголовка используются для шифрования ключа с
PBES2.
Jones Standards Track [Страница 20]
RFC 7518 JSON Web Algorithms (JWA) Май 2015 г.
4.8.1.1. Параметр заголовка "p2s" (ввод соли PBES2)
Параметр заголовка "p2s" (ввод соли PBES2) кодирует ввод соли
значение, которое используется как часть значения соли PBKDF2. "P2s"
значение - BASE64URL (ввод соли).Этот параметр заголовка ДОЛЖЕН быть
присутствуют и ДОЛЖНЫ быть поняты и обработаны реализациями, когда
эти алгоритмы используются.
Соль расширяет возможные ключи, которые могут быть получены из заданного
пароль. Значение Salt Input, содержащее 8 или более октетов, ДОЛЖНО быть
используемый. Новое значение соли ДОЛЖНО генерироваться случайным образом для каждого
операция шифрования; см. RFC 4086 [RFC4086] для обсуждения
генерация случайных значений. Используемое значение соли: (UTF8 (Alg) || 0x00
|| Salt Input), где Alg - параметр заголовка "alg" (алгоритм).
значение.4.8.1.2. Параметр заголовка "p2c" (счетчик PBES2)
Параметр заголовка "p2c" (счетчик PBES2) содержит PBKDF2
количество итераций, представленное как положительное целое число JSON. Этот заголовок
Параметр ДОЛЖЕН присутствовать, ДОЛЖЕН быть понят и обработан
реализации, когда используются эти алгоритмы.
Счетчик итераций увеличивает вычислительные затраты, в идеале дополняемые
возможный диапазон ключей, вводимых солью. Минимум
РЕКОМЕНДУЕТСЯ количество итераций 1000.
5. Криптографические алгоритмы шифрования контента.
JWE использует криптографические алгоритмы для шифрования и защиты целостности
открытый текст и для защиты целостности Дополнительной аутентификации
Данные.Jones Standards Track [Страница 21]
RFC 7518 JSON Web Algorithms (JWA) Май 2015 г.
5.1. "enc" (алгоритм шифрования) Значения параметров заголовка для JWE
В таблице ниже представлен набор заголовков "enc" (алгоритм шифрования).
Значения параметров, определенные в данной спецификации для использования с
JWE.
+ --------------- + --------------------------------- - + ---------------- +
| "enc" Param | Алгоритм шифрования контента | Реализация |
| Значение | | Требования |
+ --------------- + --------------------------------- - + ---------------- +
| A128CBC-HS256 | AES_128_CBC_HMAC_SHA_256 | Обязательно |
| | аутентифицированное шифрование | |
| | алгоритм, как определено в Разделе | |
| | 5.2.3 | |
| A192CBC-HS384 | AES_192_CBC_HMAC_SHA_384 | Необязательно |
| | аутентифицированное шифрование | |
| | алгоритм, как определено в Разделе | |
| | 5.2.4 | |
| A256CBC-HS512 | AES_256_CBC_HMAC_SHA_512 | Обязательно |
| | аутентифицированное шифрование | |
| | алгоритм, как определено в Разделе | |
| | 5.2,5 | |
| A128GCM | AES GCM с использованием 128-битного ключа | Рекомендуется |
| A192GCM | AES GCM с использованием 192-битного ключа | Необязательно |
| A256GCM | AES GCM с использованием 256-битного ключа | Рекомендуется |
+ --------------- + --------------------------------- - + ---------------- +
Все также используют значение вектора инициализации JWE и создают JWE
Значения зашифрованного текста и тега аутентификации JWE.
См. Приложение A.3 с таблицей перекрестных ссылок на JWE "enc"
(алгоритм шифрования) значения, определенные в этой спецификации с
эквивалентные идентификаторы, используемые другими стандартами и программными пакетами.5.2. Алгоритмы AES_CBC_HMAC_SHA2
В этом разделе определяется семейство алгоритмов аутентифицированного шифрования.
построено с использованием композиции AES [AES] в цепочке блоков шифрования (CBC)
режим [NIST.800-38A] с операциями заполнения PKCS # 7 согласно разделу 6.3
операций [RFC5652] и HMAC ([RFC2104] и [SHS]). Этот
Семейство алгоритмов называется AES_CBC_HMAC_SHA2. Он также определяет три
экземпляры этого семейства: первые с использованием 128-битных ключей CBC и HMAC
SHA-256, второй с использованием 192-битных ключей CBC и HMAC SHA-384, а
третий - с использованием 256-битных ключей CBC и HMAC SHA-512.Тестовые примеры для этих
алгоритмы можно найти в Приложении B.
Jones Standards Track [Страница 22]
RFC 7518 JSON Web Algorithms (JWA) Май 2015 г.
Эти алгоритмы основаны на «аутентифицированном шифровании с AES-
CBC и HMAC-SHA "[AEAD-CBC-SHA], выполняя одинаковые криптографические
вычислений, но с вектором инициализации (IV) и
Значения тегов аутентификации остаются отдельными, а не
соединены со значением зашифрованного текста в выходном представлении.Этот вариант обсуждается в Приложении B данной спецификации. Этот
Семейство алгоритмов является обобщением семейства алгоритмов в
[AEAD-CBC-SHA] и может использоваться для реализации этих алгоритмов.
5.2.1. Соглашения, используемые при определении AES_CBC_HMAC_SHA2
Мы используем следующие условные обозначения.
CBC-PKCS7-ENC (X, P) обозначает шифрование AES-CBC P с использованием PKCS
# 7 заполнение с использованием шифра с ключом X.
MAC (Y, M) обозначает применение MAC к сообщению M
используя клавишу Y.5.2.2. Общий алгоритм AES_CBC_HMAC_SHA2
В этом разделе определяется AES_CBC_HMAC_SHA2 таким образом, чтобы
независимо от размера ключа AES-CBC или используемой хеш-функции.
Разделы 5.2.2.1 и 5.2.2.2 определяют общее шифрование и
алгоритмы дешифрования. Разделы с 5.2.3 по 5.2.5 определяют экземпляры
из AES_CBC_HMAC_SHA2, которые определяют эти детали.
5.2.2.1. AES_CBC_HMAC_SHA2 Шифрование
Алгоритм аутентифицированного шифрования принимает на вход четыре октета.
строки: секретный ключ K, открытый текст P, дополнительные проверенные данные
A и вектор инициализации IV.Подтвержденный зашифрованный текст
значение E и значение тега аутентификации T предоставляются как выходы.
Данные в открытом тексте зашифрованы и аутентифицированы, а
Дополнительные проверенные данные проверяются, но не зашифровываются.
Процесс шифрования выглядит следующим образом или использует эквивалентный набор
шаги:
1. Вторичные ключи MAC_KEY и ENC_KEY генерируются из
введите ключ K следующим образом. Каждый из этих двух ключей - октет
строка.
MAC_KEY состоит из начальных октетов MAC_KEY_LEN из K, в
заказ.ENC_KEY состоит из последних октетов ENC_KEY_LEN из K в
заказ.
Jones Standards Track [Страница 23]
RFC 7518 JSON Web Algorithms (JWA) Май 2015 г.
Количество октетов в клавише ввода K ДОЛЖНО быть суммой
MAC_KEY_LEN и ENC_KEY_LEN. Значения этих параметров равны
указанные алгоритмами аутентифицированного шифрования в разделах
5.2.3–5.2.5. Обратите внимание, что ключ MAC стоит перед
ключ шифрования во входном ключе K; это в обратном порядке
имен алгоритмов в идентификаторе «AES_CBC_HMAC_SHA2».2. Используемый IV представляет собой 128-битное значение, генерируемое случайным образом или
псевдослучайно для использования в шифре.
3. Открытый текст зашифрован CBC с использованием заполнения PKCS # 7 с использованием
ENC_KEY как ключ и IV. Обозначим вывод зашифрованного текста
с этого шага как Э.
4. Строка октетов AL равна количеству битов в
Дополнительные проверенные данные A, выраженные как 64-битное беззнаковое
целое число с прямым порядком байтов.
5. Тег аутентификации сообщения T вычисляется путем применения HMAC.
[RFC2104] к следующим данным в следующем порядке:
Дополнительные проверенные данные A,
вектор инициализации IV,
зашифрованный текст E, вычисленный на предыдущем шаге, и
строка октетов AL, определенная выше.Строка MAC_KEY используется в качестве ключа MAC. Обозначим выход
MAC, вычисленного на этом этапе как M. Первые октеты T_LEN
M используются как T.
6. Зашифрованный текст E и тег аутентификации T возвращаются как
выходы аутентифицированного шифрования.
Процесс шифрования можно проиллюстрировать следующим образом. Здесь K, P, A,
IV и E обозначают ключ, открытый текст, дополнительные проверенные данные,
Вектор инициализации и зашифрованный текст соответственно.
MAC_KEY = начальные октеты MAC_KEY_LEN из K,
ENC_KEY = окончательные октеты ENC_KEY_LEN из K,
E = CBC-PKCS7-ENC (ENC_KEY, P),
M = MAC (MAC_KEY, A || IV || E || AL),
T = начальные октеты T_LEN M.Jones Standards Track [Страница 24]
RFC 7518 JSON Web Algorithms (JWA) Май 2015 г.
5.2.2.2. AES_CBC_HMAC_SHA2 Расшифровка
У аутентифицированной операции дешифрования есть пять входов: K, A, IV, E,
и T, как определено выше. У него только один выход: либо
значение открытого текста P или специальный символ FAIL, который указывает, что
входы не являются подлинными. Аутентифицированный алгоритм дешифрования
следующим образом, или использует эквивалентный набор шагов:
1.Вторичные ключи MAC_KEY и ENC_KEY генерируются из
введите клавишу K, как в шаге 1 раздела 5.2.2.1.
2. Целостность и подлинность А и Е проверяются
вычисление HMAC с входными данными, как на шаге 5 из
Раздел 5.2.2.1. Значение T из предыдущего шага равно
по сравнению с первыми битами длины MAC_KEY вывода HMAC. Если
эти значения идентичны, тогда A и E считаются действительными,
и обработка продолжается. В противном случае все данные, используемые в
подтверждение MAC отбрасывается, а аутентифицированный
операция дешифрования возвращает указание на то, что она не удалась, и
операция останавливается.(Но см. Раздел 11.5 [JWE] для безопасности
соображения по предотвращению атак по времени.)
3. Значение E расшифровывается, проверяется заполнение PKCS # 7 и
удалено. Значение IV используется как вектор инициализации. В
значение ENC_KEY используется в качестве ключа дешифрования.
4. Возвращается значение открытого текста.
5.2.3. AES_128_CBC_HMAC_SHA_256
Этот алгоритм является конкретным экземпляром универсального
Алгоритм AES_CBC_HMAC_SHA2 выше. Он использует сообщение HMAC
код аутентификации [RFC2104] с хэш-функцией SHA-256 [SHS] для
обеспечивать аутентификацию сообщений, при этом вывод HMAC усечен до 128
битов, соответствующих алгоритму HMAC-SHA-256-128, определенному в
[RFC4868].Для шифрования использует AES в режиме работы CBC.
как определено в разделе 6.2 [NIST.800-38A], с заполнением PKCS # 7 и
128-битное значение IV.
Параметры AES_CBC_HMAC_SHA2, специфичные для AES_128_CBC_HMAC_SHA_256
находятся:
Длина ключа ввода K составляет 32 октета.
ENC_KEY_LEN - 16 октетов.
MAC_KEY_LEN - 16 октетов.
Для HMAC используется алгоритм хеширования SHA-256.
Вывод HMAC-SHA-256 усекается до T_LEN = 16 октетов на
удаление последних 16 октетов.Jones Standards Track [Страница 25]
RFC 7518 JSON Web Algorithms (JWA) Май 2015 г.
5.2.4. AES_192_CBC_HMAC_SHA_384
AES_192_CBC_HMAC_SHA_384 основан на AES_128_CBC_HMAC_SHA_256, но
со следующими отличиями:
Ключ ввода K имеет длину 48 октетов вместо 32.
ENC_KEY_LEN - 24 октета вместо 16.
MAC_KEY_LEN - 24 октета вместо 16.
SHA-384 используется для HMAC вместо SHA-256.Значение HMAC SHA-384 усекается до T_LEN = 24 октета вместо
16.
5.2.5. AES_256_CBC_HMAC_SHA_512
AES_256_CBC_HMAC_SHA_512 основан на AES_128_CBC_HMAC_SHA_256, но
со следующими отличиями:
Ключ ввода K имеет длину 64 октета вместо 32.
ENC_KEY_LEN - 32 октета вместо 16.
MAC_KEY_LEN - 32 октета вместо 16.
SHA-512 используется для HMAC вместо SHA-256.
Значение HMAC SHA-512 усекается до T_LEN = 32 октета вместо
16.5.2.6. Шифрование содержимого с помощью AES_CBC_HMAC_SHA2
Этот раздел определяет особенности выполнения аутентифицированных
шифрование с алгоритмами AES_CBC_HMAC_SHA2.
CEK используется как секретный ключ K.
Следующие значения параметра заголовка "enc" (алгоритм шифрования)
используются, чтобы указать, что зашифрованный текст JWE и аутентификация JWE
Значения тегов были вычислены с использованием соответствующего алгоритма:
+ --------------- + --------------------------------- ------------------ +
| "enc" Param | Алгоритм шифрования контента |
| Значение | |
+ --------------- + --------------------------------- ------------------ +
| A128CBC-HS256 | AES_128_CBC_HMAC_SHA_256 аутентифицированное шифрование |
| | алгоритм, как определено в разделе 5.2.3 |
| A192CBC-HS384 | AES_192_CBC_HMAC_SHA_384 аутентифицированное шифрование |
| | алгоритм, как определено в Разделе 5.2.4 |
| A256CBC-HS512 | AES_256_CBC_HMAC_SHA_512 аутентифицированное шифрование |
| | алгоритм, как определено в Разделе 5.2.5 |
+ --------------- + --------------------------------- ------------------ +
Jones Standards Track [Страница 26]
RFC 7518 JSON Web Algorithms (JWA) Май 2015 г.
5.3. Шифрование контента с помощью AES GCM
Этот раздел определяет особенности выполнения аутентифицированных
шифрование с помощью AES в режиме Галуа / счетчика (GCM) ([AES] и
[NIST.800-38D]).
CEK используется в качестве ключа шифрования.
Для этого алгоритма ТРЕБУЕТСЯ использование IV размером 96 бит.
Запрошенный размер вывода тега аутентификации ДОЛЖЕН быть 128 бит,
независимо от размера ключа.
Следующие значения параметра заголовка "enc" (алгоритм шифрования)
используются, чтобы указать, что зашифрованный текст JWE и аутентификация JWE
Значения тегов были вычислены с использованием соответствующего алгоритма и
размер ключа:
+ ------------------- + ----------------------------- - +
| "enc" Значение параметра | Алгоритм шифрования контента |
+ ------------------- + ----------------------------- - +
| A128GCM | AES GCM с использованием 128-битного ключа |
| A192GCM | AES GCM с использованием 192-битного ключа |
| A256GCM | AES GCM с использованием 256-битного ключа |
+ ------------------- + ----------------------------- - +
Пример использования этого алгоритма приведен в Приложении A.1 из [JWE].
6. Криптографические алгоритмы ключей
Веб-ключ JSON (JWK) [JWK] - это структура данных JSON, представляющая
криптографический ключ. Эти ключи могут быть асимметричными или симметричными.
Они могут содержать как общедоступную, так и личную информацию о ключе.
В этом разделе определяются параметры ключей с использованием алгоритмов
указанные в этом документе.
Jones Standards Track [Страница 27]
RFC 7518 JSON Web Algorithms (JWA) Май 2015 г.
6.1. Значения параметра "kty" (тип ключа)
В таблице ниже представлен набор значений параметра "kty" (тип ключа), которые
определены этой спецификацией для использования в JWK.
+ ------------- + -------------------------------- + - ------------------ +
| "кты" Парам | Тип ключа | Реализация |
| Значение | | Требования |
+ ------------- + -------------------------------- + - ------------------ +
| EC | Эллиптическая кривая [DSS] | Рекомендуется + |
| RSA | RSA [RFC3447] | Обязательно |
| окт | Последовательность октетов (используется для | Обязательного |
| | представляют собой симметричные ключи) | |
+ ------------- + -------------------------------- + - ------------------ +
Использование знака «+» в столбце «Требования к реализации» означает
что сила требований, вероятно, будет увеличена в будущем
версия спецификации.6.2. Параметры ключей эллиптических кривых
JWK могут представлять ключи Elliptic Curve [DSS]. В этом случае
Значение элемента "kty" равно "EC".
6.2.1. Параметры для открытых ключей эллиптической кривой
Открытый ключ Elliptic Curve представлен парой координат
взятые из конечного поля, которые вместе определяют точку на
Эллиптическая кривая. Следующие члены ДОЛЖНЫ присутствовать для всех
Открытые ключи эллиптической кривой:
o "crv"
o "x"
Следующий участник ДОЛЖЕН также присутствовать в общедоступной программе Elliptic Curve.
ключи для трех кривых, определенных в следующем разделе:
о "у"
6.2.1.1. Параметр crv (Кривая)
Параметр crv (кривая) определяет используемую криптографическую кривую.
с ключом. Значения кривых из [DSS], используемые в этой спецификации
находятся:
o «П-256»
o "П-384"
o "П-521"
Jones Standards Track [Страница 28]
RFC 7518 JSON Web Algorithms (JWA) Май 2015 г.
Эти значения зарегистрированы в IANA "Эллиптическая кривая веб-ключа JSON".
реестр, определенный в разделе 7.6. Дополнительные значения crv могут быть
прописаны по другим спецификациям. Регистрация спецификаций
дополнительные кривые должны определять, какие параметры используются для представления
ключи для кривых прописаны. Значение "crv" чувствительно к регистру.
строка.
Сжатие точки SEC1 [SEC1] не поддерживается ни для одного из этих трех
кривые.
6.2.1.2. Параметр "x" (координата X)
Параметр "x" (координата x) содержит координату x для
Точка эллиптической кривой. Он представлен как кодировка base64url для
представление координаты в виде строки октетов, как определено в
Раздел 2.3.5 из SEC1 [SEC1]. Длина этой строки октета ДОЛЖНА
быть полным размером координаты кривой, указанной в "crv"
параметр. Например, если значение «crv» равно «P-521», октет
строка должна быть длиной 66 октетов.
6.2.1.3. Параметр "y" (координата Y)
Параметр "y" (координата y) содержит координату y для
Точка эллиптической кривой. Он представлен как кодировка base64url для
представление координаты в виде строки октетов, как определено в
Раздел 2.3.5 из SEC1 [SEC1]. Длина этой строки октета ДОЛЖНА
быть полным размером координаты кривой, указанной в "crv"
параметр. Например, если значение «crv» равно «P-521», октет
строка должна быть длиной 66 октетов.
6.2.2. Параметры закрытых ключей эллиптической кривой
В дополнение к элементам, используемым для представления общедоступной эллиптической кривой
ключи, следующий член ДОЛЖЕН присутствовать для представления Elliptic
Кривые приватные ключи.
6.2.2.1. Параметр "d" (закрытый ключ ECC)
Параметр "d" (закрытый ключ ECC) содержит эллиптическую кривую.
значение закрытого ключа.Он представлен как кодировка base64url для
представление строки октетов значения закрытого ключа, как определено
в Разделе 2.3.7 SEC1 [SEC1]. Длина этой строки октета
ДОЛЖЕН быть потолок (log-base-2 (n) / 8) октетов (где n - порядок
кривая).
Jones Standards Track [Страница 29]
RFC 7518 JSON Web Algorithms (JWA) Май 2015 г.
6.3. Параметры для ключей RSA
JWK могут представлять ключи RSA [RFC3447].В этом случае «кты»
значение члена - «RSA». Семантика параметров, определенных ниже
те же, что определены в разделах 3.1 и 3.2 RFC 3447.
6.3.1. Параметры для открытых ключей RSA
Следующие члены ДОЛЖНЫ присутствовать для открытых ключей RSA.
6.3.1.1. Параметр "n" (модуль)
Параметр "n" (модуль) содержит значение модуля для RSA.
открытый ключ. Он представлен как значение в кодировке Base64urlUInt.
Обратите внимание, что разработчики обнаружили, что некоторые криптографические библиотеки
префикс дополнительного нулевого октета к представлениям модуля, которые они
return, например, возвращение 257 октетов для 2048-битного ключа, а
чем 256.Реализации, использующие такие библиотеки, должны будут
позаботьтесь об исключении лишнего октета в кодировке base64url
представление.
6.3.1.2. Параметр "е" (экспонента)
Параметр «e» (показатель степени) содержит значение показателя степени для RSA.
открытый ключ. Он представлен как значение в кодировке Base64urlUInt.
Например, при представлении значения 65537 последовательность октетов
кодирование base64url ДОЛЖНО состоять из трех октетов [1, 0, 1];
результирующее представление для этого значения - «AQAB».6.3.2. Параметры для закрытых ключей RSA
В дополнение к членам, используемым для представления открытых ключей RSA,
следующие члены используются для представления закрытых ключей RSA. В
параметр "d" ТРЕБУЕТСЯ для закрытых ключей RSA. Остальные позволяют
оптимизации и ДОЛЖНЫ быть включены производителями JWK
представляющие закрытые ключи RSA. Если производитель включает любой из
другие параметры закрытого ключа, тогда все остальные ДОЛЖНЫ присутствовать,
за исключением «oth», который ДОЛЖЕН присутствовать только когда больше
использовались два простых множителя.6.3.2.1. Параметр "d" (частный показатель)
Параметр "d" (частный показатель) содержит частный показатель
значение для закрытого ключа RSA. Он представлен как Base64urlUInt-
закодированное значение.
Jones Standards Track [Страница 30]
RFC 7518 JSON Web Algorithms (JWA) Май 2015 г.
6.3.2.2. Параметр "p" (первый основной коэффициент)
Параметр «p» (первый простой множитель) содержит первое простое число
фактор.Он представлен как значение в кодировке Base64urlUInt.
6.3.2.3. Параметр "q" (второй основной коэффициент)
Параметр q (второй простой множитель) содержит второе простое число
фактор. Он представлен как значение в кодировке Base64urlUInt.
6.3.2.4. Параметр "dp" (показатель степени ЭЛТ первого фактора)
Параметр "dp" (показатель степени ЭЛТ первого фактора) содержит китайский
Показатель теоремы об остатке (CRT) первого множителя. это
представлен как значение в кодировке Base64urlUInt.
6.3.2.5. Параметр "dq" (показатель второго фактора ЭЛТ)
Параметр "dq" (показатель степени ЭЛТ второго фактора) содержит ЭЛТ
показатель степени второго множителя.Он представлен как Base64urlUInt-
закодированное значение.
6.3.2.6. Параметр "qi" (первый коэффициент ЭЛТ)
Параметр "qi" (первый коэффициент ЭЛТ) содержит ЭЛТ
коэффициент второго фактора. Он представлен как
Значение в кодировке Base64urlUInt.
6.3.2.7. Параметр "oth" (информация о других простых числах)
Параметр "oth" (информация о других простых числах) содержит массив
информация о любых третьих и последующих простых числах, если они существуют.
Когда использовались только два простых числа (нормальный случай), этот параметр
НЕОБХОДИМО опустить.Когда использовались три или более простых числа,
количество элементов массива ДОЛЖНО быть количеством используемых простых чисел минус два.
Дополнительные сведения об этом случае см. В описании
OtherPrimeInfo параметры в Приложении A.1.2 RFC 3447 [RFC3447],
на основе которого моделируются следующие параметры. Если потребитель
JWK не поддерживает закрытые ключи с более чем двумя простыми числами и
обнаруживает закрытый ключ, который включает параметр "oth", затем
НЕ ДОЛЖНЫ использовать ключ. Каждый элемент массива ДОЛЖЕН быть объектом с
следующих членов.6.3.2.7.1. "r" (основной фактор)
Параметр "r" (простой коэффициент) в элементе массива "oth"
представляет собой значение последующего основного фактора. Он представлен
как значение в кодировке Base64urlUInt.
Jones Standards Track [Страница 31]
RFC 7518 JSON Web Algorithms (JWA) Май 2015 г.
6.3.2.7.2. "d" (коэффициент экспоненты CRT)
Параметр "d" (коэффициент экспоненты CRT) в элементе массива "oth"
представляет показатель CRT соответствующего простого множителя.это
представлен как значение в кодировке Base64urlUInt.
6.3.2.7.3. "t" (факторный коэффициент CRT)
Параметр "t" (коэффициент коэффициента CRT) в массиве "oth"
член представляет собой коэффициент CRT соответствующего простого числа
фактор. Он представлен как значение в кодировке Base64urlUInt.
6.4. Параметры для симметричных ключей
Когда значение элемента JWK "kty" равно "oct" (последовательность октетов), член
"k" (см. раздел 6.4.1) используется для представления симметричного ключа (или
другой ключ, значение которого представляет собой последовательность из одного октета).Член "alg"
СЛЕДУЕТ также присутствовать для определения алгоритма, который предполагается использовать.
с ключом, если приложение не использует другие средства или соглашения
для определения используемого алгоритма.
6.4.1. Параметр "k" (ключевое значение)
Параметр "k" (ключевое значение) содержит значение симметричного (или
другой однозначный) ключ. Он представлен как base64url
кодирование последовательности октетов, содержащей значение ключа.
7. Соображения IANA
Для всех реестров используется следующая процедура регистрации.
установленным данной спецификацией.Процедура регистрации значений обязательна.
[RFC5226] после трехнедельного обзора
Список рассылки [email protected] по совету одного или нескольких
Назначенные эксперты. Однако, чтобы учесть распределение ценностей
до публикации Назначенные эксперты могут одобрить регистрацию
как только они убедятся, что такая спецификация будет опубликована.
Запросы на регистрацию, отправленные в список рассылки для просмотра, должны использовать
соответствующий предмет (e.г., «Запрос на регистрацию алгоритма:
пример").
В течение отчетного периода назначенные эксперты либо утвердят
или отклонить
ключевых слов и поисковые запросы: в чем разница?
В обычном разговоре термины «ключевое слово» и «поисковый запрос» часто используются как синонимы, но на самом деле между ними есть разница. Так в чем же разница между ключевым словом и поисковым запросом?
Ключевое слово похоже на платоновский идеал поискового запроса - это абстракция, которую мы экстраполируем из нескольких поисковых запросов.
Поисковый запрос или условие поиска - это фактическое слово или строка слов, которые пользователь поисковой системы вводит в поле поиска. Вы можете думать о поисковом запросе как о реальном применении ключевого слова - оно может быть написано с ошибками, не по порядку или к нему прикреплены другие слова, или, наоборот, оно может быть идентично ключевому слову.
Как специалисты по поисковому маркетингу, мы нацелены на ключевых слов .
- В SEO мы нацелены на эти абстракции, оптимизируя контент на странице (используя ключевые слова в URL-адресах, теги заголовков, основной текст, имена файлов изображений, метаописания и т. Д.), Создавая входящие ссылки с ключевыми словами в якорный текст и т. д.
- В PPC мы нацелены на ключевые слова, делая ставки на них и используя их в наших объявлениях и целевых страницах.
Поисковые запросы , с другой стороны, представляют собой реальные термины, которые люди используют для поиска этих страниц с помощью платного и обычного поиска.
Так, например, вы можете сделать ставку по ключевому слову "джинсы скинни". Просматривая отчет по поисковым запросам в AdWords, вы можете увидеть все запросы, которые посетители вводили для показа вашего объявления. Предполагая, что вы используете широкое соответствие, эти запросы могут включать точное ключевое слово, а также бесконечные варианты, такие как «джинсы скинни, «женские джинсы скинни», «темные джинсы скинни», «джинсы скинни 0 размера» и так далее.
Если некоторые из этих поисковых запросов соответствуют четкому повторяющемуся шаблону (например, "женские узкие джинсы"), вы можете создать группу объявлений и соответствующие объявления для этого поискового запроса, после чего поисковый запрос станет одно из ваших ключевых слов.
Поисковые запросы - это больше, чем ключевые слова, и, просматривая поисковые запросы, мы можем найти новые ключевые слова для таргетинга в наших поисковых маркетинговых кампаниях. (Анализ поисковых запросов также является хорошим способом поиска минус-слов).
Есть вопросы?
Платформа RSA NetWitness ... | RSA Link
Оглавление
Программы-вымогатели преследуют предприятия уже более десяти лет, и теперь организации должны уделять первоочередное внимание обнаружению этих атак. Хотя в отчетах отмечается небольшое снижение количества атак с использованием программ-вымогателей (Sophos 2020), теперь они стали узконаправленными, более сложными и смертоносными из-за ценности зашифрованных активов.
Чтобы программа-вымогатель была максимально эффективной, она должна заразить как можно больше конечных точек. Это означает, что вымогатель обычно развертывается с использованием методов, позволяющих быстро и легко распространять. Методы развертывания могут включать следующие:
- Microsoft SysInternals PsExec Utility
- Объекты групповой политики (GPO)
- System Center Configuration Manager (SCCM)
Если злоумышленник достиг стадии, когда они готовы к распространять программу-вымогатель, вы, скорее всего, обнаружите ее, когда она начнет шифрование ваших файлов, а это уже слишком поздно.Перед развертыванием программы-вымогателя злоумышленник должен проникнуть в сеть, настроить бэкдоры, собрать учетные данные, перемещаться в боковом направлении и эксфильтровать данные - злоумышленник должен создать много шума, чтобы достичь своей конечной цели, и именно в этих ключевых точках где защитники должны обнаружить эту атаку. Время ожидания от первых признаков вредоносной активности до развертывания программы-вымогателя может составлять всего несколько часов, поэтому быстрое обнаружение для предотвращения успешной атаки является обязательным. На следующем рисунке показан пример последовательности действий атаки программ-вымогателей:
Давайте рассмотрим это и посмотрим, как мы можем обнаружить это с помощью NetWitness.
Сбор учетных данных
Для того, чтобы злоумышленник мог двигаться в боковом направлении, ему понадобятся некоторые учетные данные, которые обычно получаются путем сброса памяти LSASS и использования Mimikatz для извлечения учетных данных в открытом виде из дампа. Существует несколько методов, которые злоумышленник может использовать для дампа памяти LSASS:
- Microsoft Sysinternals ProcDump
- Использование функции MiniDump из comsvcs.dll
- Пользовательские приложения (например, Dumpert)
Описание этих методов и то, как они проявляются в NetWitness, важно для защитников, чтобы они могли быстро определить, происходят ли эти действия в их сети.
ProcDump
ProcDump - это служебная программа командной строки, которая обычно запускается через cmd.exe. Соответствующие события для этого будут выглядеть примерно так, как показано ниже, где cmd.exe запускает двоичный файл ProcDump с аргументами командной строки для дампа памяти LSASS и сохранения его как минидампа:
Затем мы видим открытый lsass двоичного файла ProcDump. exe для сброса памяти:
Этот минидамп обычно удаляется из сети, чтобы злоумышленник мог запустить Mimikatz для извлечения учетных данных.Они делают это в автономном режиме, поскольку введение Mimikatz в сеть, скорее всего, вызовет антивирус и другие обнаружения. Вы обязательно должны следить за своими журналами AV на предмет предупреждений этого типа.
Вышеупомянутая активность может быть обнаружена путем добавления следующего правила приложения в ваш оконечный декодер (-ы):
Имя Логика procdump lsass dump param.src contains ma lsass '|| парам.dst содержит '-ma lsass' использование инструмента sysinternals param.src содержит '-accepteula' || param.dst содержит '-accepteula'
Инструменты Microsoft Sysinternal также могут быть обнаружены с помощью следующего запроса, file.vendor = 'sysinternals - www.sysinternals.com':
As a defender, тогда можно будет идентифицировать злонамеренный умысел, проанализировав расположение и имена двоичных файлов.Например, на снимке экрана ниже показано, что инструмент Sysinternal с именем pd.exe существует в каталоге C: \ PerfLogs \, он должен выделяться как аномальный и быть упорядоченным:
comsvcs.dll
Этот метод существует уже довольно давно, но редко используется злоумышленниками, однако это метод сброса памяти LSASS, который все же следует контролировать. Пример того, как это может выглядеть, показан ниже, где мы видим команду PowerShell, использующую rundll32.exe, чтобы использовать функцию MiniDump для создания минидампа LSASS:
Затем мы видим, что rundll32.exe открывает lsass.exe для сброса памяти:
Вышеуказанное действие можно обнаружить, добавив следующее правило приложения для вашего оконечного декодера (ов):
Имя Логика comsvcs.dll lsass dump param.src содержит 'comsvcs.dll MiniDump' || парам.dst содержит 'comsvcs.dll MiniDump'
Пользовательские приложения
Пользовательские приложения могут быть настроены для сброса памяти LSASS с помощью прямых системных вызовов и отключения API. Примером инструмента, который делает именно это, является Dumpert. Подобные инструменты обычно запускаются с помощью cmd.exe. Из приведенного ниже мы видим, что cmd.exe использовался для запуска Outflank-Dumpert.exe, а впоследствии Outflank-Dumpert.exe открывает lsass.exe для дампа памяти:
Активность из неподписанных исполняемых файлов, открывающая LSASS, будет помечено мета-значением, показанным на следующем рисунке.В качестве защитника все двоичные файлы, помеченные этим мета-значением, должны быть исследованы, чтобы подтвердить, являются ли они законными или вредоносными:
Если минидамп LSASS передается по сети через протокол открытого текста, и вы нажали fingerprint_minidump Lua синтаксический анализатор вашего пакетного декодера (-ов), будет создано следующее мета-значение; что было бы еще одной отличной отправной точкой для расследования:
Боковое движение
После того, как злоумышленник получит учетные данные, он может начать горизонтальное перемещение к конечным точкам в сети.У злоумышленника есть ряд вариантов, которые, как правило, используются:
- Протокол удаленного рабочего стола (RDP)
- Инструментарий управления Windows (WMI)
- Блок сообщений сервера (SMB)
Хотя все вышеперечисленное используется в среде на законных основаниях, защитникам важно понимать, как и где они используются для выявления аномального использования.
RDP
RDP - отличный способ для злоумышленников перемещаться в боковом направлении, он обеспечивает интерактивное графическое представление конечной точки, к которой они подключаются, и может легко вписаться в обычные повседневные операции, позволяя защитникам оставаться незамеченными .Обычно журналы RDP используются при обнаружении свидетельств взлома. Злоумышленник будет использовать одного или нескольких пользователей, и эту информацию затем можно использовать в качестве точки поворота для определения боковой активности:
Чтобы журналы событий RDP анализировались, как показано выше, я добавил два правила парсера динамических журналов. : Log Parser Настройка: Log Parser Rules Tab
Лучший журнал для мониторинга активности RDP - это журнал событий Microsoft-Windows-TerminalServices-LocalSessionManager / Operational ; идентификатор события 21 будет успешным RDP-соединением.Отличное чтение, чтобы лучше понять идентификаторы событий, связанных с RDP, можно найти здесь: Журналы событий, связанных с RDP Windows: идентификация, отслеживание и расследование | Поразмыслите над битами.
WMI
Переход к конечным точкам вбок с помощью WMI - распространенный метод, принятый злоумышленниками. Как правило, предпочтение отдается использованию инструмента под названием WMIExec. На следующем снимке экрана показан пример того, как использование этого инструмента выглядит в NetWitness Endpoint. Снизу мы видим сервис поставщика WMI, WmiPrvSE.exe, запускает cmd.exe и передает вместе с ним параметры:
Добавление следующих правил приложений в ваш оконечный декодер (-ы) может помочь в обнаружении потенциально вредоносного использования WMI:
Имя Логика wmiexec param.dst содержит '127.0.0.1 \\ admin $ \\ __ 1'
NetWitness Endpoint Decoder также поставляется с готовым содержимым для обнаружения потенциально вредоносного использования WMI :
Вращение по этим мета-значениям было бы отличным способом обнаружения возможного бокового движения атакующего, как защитник вы хотели бы идентифицировать любые нетипичные команды, связанные с активностью WMIC, пример этого показан ниже, где злоумышленник может использовать WMI для удаленного выполнения команд на конечной точке, используя «процесс создания вызова»:
Remote WMI act iveity также помечается в пакетах NetWitness с мета-значением, удаленная активность wmi.Когда используется вызов процесса create (CAR-2016-03-002: Create Remote Process via WMIC | MITER Cyber Analytics Repository), мета-значение execmethod будет заполнено под мета-ключом действия. Выявление конечных точек, где это происходит, а обычно не происходит, - еще одна отличная отправная точка для выявления потенциально вредоносного использования WMI:
SMB
Боковое перемещение через SMB обычно выполняется с помощью команды net use. Он позволяет злоумышленникам получить доступ к общему ресурсу на удаленном компьютере.Их предпочтительными ресурсами обычно являются административные общие ресурсы, обычно это C $, ADMIN $, D $. Чтобы определить, происходит ли этот тип активности в вашей среде, обратите внимание на следующие мета-значения:
Ниже показан пример команды net use для подключения административного общего ресурса:
Как защитник, вы хотели бы сосредоточиться на этих событиях и посмотреть, на каких конечных точках происходит это действие, оттуда вы можете выполнить анализ временной шкалы на конечной точке, чтобы увидеть, какие еще действия имели место в это время.
Бэкдоры
После того, как злоумышленник проник в сеть, ему необходимо поддерживать постоянство. Злоумышленник может это сделать двумя основными способами:
- Развернуть веб-оболочку на общедоступном сервере
- Развернуть троян, чтобы отправить маяк обратно на сервер C2
Распространенным методом обнаружения C2 является с помощью упреждающего поиска, который мы много раз подробно обсуждали в рамках серии «Профилирование атакующих».Мы настоятельно рекомендуем прочитать эти сообщения, чтобы понять C2 и обнаружение веб-оболочки, поскольку они были подробно рассмотрены в ряде сообщений.
Еще одним отличным средством для выявления конечных точек, которые потенциально могут быть заражены веб-оболочками или троянами, является журнал событий Microsoft-Windows-Windows Defender / Operational . События антивируса часто упускаются из виду, но могут быть отличным индикатором потенциального взлома, как показано ниже, где Защитник обнаружил две веб-оболочки в каталоге C: \ PerfLogs \:
Создание учетной записи
Злоумышленники могут выбрать создание учетной записи чтобы протолкнуть их программы-вымогатели или сдвинуться в сторону.Обычно злоумышленник может создать учетную запись с помощью команды net. Если появляется следующее мета-значение, его следует исследовать, чтобы подтвердить, было ли создание учетной записи пользователя законным или нет:
Поворот на этом мета-значении даст нам некоторый контекст относительно того, какой пользователь был создан и как. Из приведенного ниже мы видим, что lsass.exe запустил net.exe для создания учетной записи с именем helpdesk - это примерное поведение эксплойта EternalBlue:
Если пользователь добавлял через командную строку, это выглядело бы так продолжение.Это не означает, что это законное поведение, но демонстрирует различия в том, как будет выглядеть нормальное выполнение net.exe:
Для обоих этих событий защитник должен выполнить анализ на конечной точке (s ) и выполните анализ временной шкалы для поиска дальнейшего аномального поведения.
Некоторые дополнительные полезные правила приложений, которые могут быть развернуты для обнаружения аномального поведения с помощью LSASS:
Имя Логика lsass записывает exe имя файла.src = 'lsass.exe' && action = 'Writetoexecutable' lsass создает процесс filename.src = 'lsass.exe' && action = 'createprocess'
С точки зрения создания учетной записи, журнал событий Security будет записывать идентификатор события 4720 вместе с информацией о созданном пользователе:
Как защитник, вы можете обратиться к reference.id = '4720', чтобы проанализировать, какие учетные записи пользователей были создал и где.
Развертывание программ-вымогателей
Программы-вымогатели могут быть развернуты несколькими способами. Здесь мы рассмотрим развертывание через PsExec. Это распространенный выбор злоумышленников, поскольку это законный инструмент Microsoft, который можно легко создать с помощью сценария для копирования и выполнения файлов. Основываясь на том, как работает PsExec, мы можем легко определить его активность по следующему мета-значению:
Просматривая эти события, мы видим, что PsExec.exe использовался для подключения к удаленной конечной точке.передать двоичный файл и выполнить его:
Полезным правилом приложения для дальнейшего обнаружения использования PsExec может быть:
Имя Логика Использование psexec psexec имя_файла
psex = ' .exe '
Существует множество клонов OS PsExec, которые работают очень похоже, следующие правила приложений должны быть добавлены, чтобы помочь идентифицировать их использование в вашей среде:
Имя Логика использование remcom имя файла.dst = 'remcomsvc.exe' Использование csexec filename.dst = 'csexecsvc.exe' Использование paexec .dst начинается с 'paexec'
пакета , Выполнение PsExec будет отмечено мета-ключом «Индикаторы взлома». В качестве защитника вам нужно будет определить, является ли действие PsExec законным или нет:
Для перспективы журнала в журнале событий System записывается идентификатор события 7045 (создание службы) при использовании PsExec, как показано ниже:
Это потому, что PsExec и аналогичные инструменты используют диспетчер управления службами (SCM) для своей работы.Для лучшего понимания PsExec и того, как он работает, перейдите по следующему URL-адресу: https://www.contextis.com/de/blog/lateral-movement-a-deep-look-into-psexec.
То, что было описано выше, является просто примером того, как может разворачиваться атака программы-вымогателя. Конечно, существует множество тактик, приемов и процедур (ДТС), которые злоумышленник будет иметь в своем арсенале, которые не были описаны в этом сообщении в блоге, но мы надеемся, что это даст вам хорошую отправную точку для того, как использовать NetWitness для выявления аномальных поведения и предотвращения успешных атак.
Нет проблем, в заголовке есть поле 
. . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Условные обозначения. . . . . . . . . . . . . . . . . 4
2. Терминология. . . . . . . . . . . .. . . . . . . . . . . . . 5
3. Криптографические алгоритмы цифровых подписей и MAC. . 6
3.1. Значения параметра заголовка "alg" (алгоритм) для JWS. . . . 6
3.2. HMAC с функциями SHA-2. . . . . . . . . . . . . . . . 7
3.3. Цифровая подпись с RSASSA-PKCS1-v1_5. . . . . . . . 8
3.4. Цифровая подпись с ECDSA. . . . . . . . . . . . . . 9
3.5. Цифровая подпись с RSASSA-PSS. . . . . . . . . . . . 10
3.6. Использование алгоритма «нет».. . . . . . . . . . . . . . 11
4. Криптографические алгоритмы управления ключами. . . . . . . . . 11
4.1. Значения параметра заголовка "alg" (алгоритм) для JWE. . . . 12
4.2. Ключевое шифрование с помощью RSAES-PKCS1-v1_5. . . . . . . . . . 13
4.3. Ключевое шифрование с RSAES OAEP. . . . . . . . . . . . . 14
4.4. Перенос ключей с помощью AES Key Wrap. . . .
8.1. Параметры заголовка, используемые для шифрования ключа PBES2. . . 20
4.8.1.1. Параметр заголовка "p2s" (ввод соли PBES2). . . . 21 год
4.8.1.2. Параметр заголовка "p2c" (счетчик PBES2). . . . . . 21 год
5. Криптографические алгоритмы шифрования контента.. . . . . . 21 год
5.1. "enc" (алгоритм шифрования) Значения параметра заголовка для
JWE. . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.2. AES_CBC_HMAC_SHA2 Алгоритмы. . . . . . . . . . . . . . 22
5.2.1. Соглашения, используемые при определении AES_CBC_HMAC_SHA2. . . 23
5.2.2. Общий алгоритм AES_CBC_HMAC_SHA2. . . . . . . . . 23
5.2.2.1. AES_CBC_HMAC_SHA2 Шифрование. . . . . . . . . . 23
5.2.2.2. AES_CBC_HMAC_SHA2 Расшифровка. .. . . . . . . . 25
5.2.3. AES_128_CBC_HMAC_SHA_256. . . . . . . . . . . . . . 25
5.2.4. AES_192_CBC_HMAC_SHA_384. . . . . . . . . . . . . . 26
5.2.5. AES_256_CBC_HMAC_SHA_512. . . . . . . . . . . . . . 26
5.
2.6. Шифрование содержимого с помощью AES_CBC_HMAC_SHA2. . . . . . 26
5.3. Шифрование контента с помощью AES GCM. . . . . . . . . . . . . 27
6. Криптографические алгоритмы ключей. . . . . . . . . . . . . . 27
6.1. Значения параметра «kty» (тип ключа).. . . . . . . . . . . 28
Jones Standards Track [Страница 2] 
. . . . . . . . . . 30
6.3.1.1. Параметр "n" (Модуль). . . . . . . . . . . . . 30
6.3.1.2. Параметр "е" (экспонента). . . . . . . . . . . . 30
6.3.2. Параметры для закрытых ключей RSA. . . . . . . . . . . 30
6.3.2.1. Параметр "d" (частный показатель степени). . . . . . . . 30
6.3.2.2. Параметр "p" (первый основной коэффициент). . . . . . . 31 год
6.3.2.3. Параметр «q» (второй основной коэффициент). . . . . . . 31 год
6.3.2.4. Параметр "dp" (показатель степени ЭЛТ первого фактора). . . 31 год
6.3.2.5. Параметр "dq" (второй фактор CRT Exponent). . . 31 год
6.3.2.6. Параметр "qi" (первый коэффициент ЭЛТ). . . . . 31 год
6.3.2.7. Параметр "oth" (информация о других простых числах). . . . . . . 31 год
6.4. Параметры для симметричных ключей. . . . . . . . . . . . . . 32
6.4.1. Параметр "k" (ключевое значение). . . . . . . . . . . . . . 32
7. Соображения IANA. . . . . . . . . . . . . . . . .
. . . . 32
7.1. Реестр веб-подписей и алгоритмов шифрования JSON. . 33
7.1.1. Шаблон регистрации. . . . . . . . . . . . . . . . 34
7.1.2. Первоначальное содержимое реестра. . . . . . . . . . . . . . 35 год
7.2. Регистрация имен параметров заголовка. . . . . . . . . . . 42
7.2.1. Содержимое реестра. . . . . . . . . . . . . . . . . . 42
7.3. Реестр алгоритмов сжатия веб-шифрования JSON. . . 43
7.3.1. Шаблон регистрации. . . . . . . . . . . . . . . . 43
7.3.2. Первоначальное содержимое реестра. . . . . . . . . . . . . . 44
7.4. Реестр типов веб-ключей JSON. . . . . . . . . . . . . . . 44
7.4.1. Шаблон регистрации. . . . . . . . . . . . . . . . 44
7.4.2. Первоначальное содержимое реестра. . . . . . . . . . . . . . 45
7.5. Регистрация параметров веб-ключа JSON. . . . . . . . . . 45
7.5.1. Содержимое реестра. . . . . . . . . . . . . . . . . . 46
7.6. Реестр эллиптических кривых веб-ключей JSON. . . . . . . .
. . 48
7.6.1. Шаблон регистрации. . . . . . . . . . . . . . . . 48
7.6.2. Первоначальное содержимое реестра. . . . . . . . . . . . . . 49
8. Соображения безопасности. . . . . . . . . . . . . . . . . . . 49
8.1. Криптографическая гибкость. . . . . . . . . . . . . . . . . . 50
8.2. Ключевые времена жизни. . . . . . . . . . . . . . . . . . . . . . 50
8.3. RSAES-PKCS1-v1_5 Вопросы безопасности. . . . . . . . 50
8.4. Вопросы безопасности AES GCM. . . . . . . . . . . . . 50
8.5. Вопросы безопасности незащищенного JWS. . . . . . . . . . 51
8.6. Атаки отказа в обслуживании. . . . . . . . . . . . . . . . 51
8.7. Повторное использование материала ключа при шифровании ключей. . . . . . . . 51
8.8. Вопросы пароля. . . . . . . . . . . . . . . . . 52
8.9. Ключевая энтропия и случайные значения. . . . . . . . . . . . . . 52
Jones Standards Track [Страница 3] 
8.10. Различия между цифровыми подписями и MAC. . . . . 52
8.11. Использование сильных сторон алгоритма сопоставления. . . . . . . . . . . 53
8.12. Адаптивные атаки по выбранному зашифрованному тексту.. . . . . . . . . . 53
8.13. Время атаки. . . . . . . . . . . . . . . . . . . . . 53
8.14. Представления закрытого ключа RSA и ослепление. . . . . . 53
9. Соображения интернационализации. . . . . . . . . . . . . 53
10. Список литературы. . . . . . . . . . . . . . . . . . . . . . . . . 53
10.1. Нормативные ссылки . . . . . . . . . . . . . . . . . . 53
10.2. Информативные ссылки. . . . . . . . . . . . . . . . . 56
Приложение A. Перекрестная ссылка идентификатора алгоритма.. . . . . . . 59
А.1. Цифровая подпись / идентификатор алгоритма MAC Cross-
Справка . . . . . . . . . . . . . . . . . . . . . . . . 60
А.2. Перекрестная ссылка на идентификатор алгоритма управления ключами. . . 61
А.3. Перекрестная ссылка на идентификатор алгоритма шифрования содержимого.
62
Приложение Б. Тестовые примеры для алгоритмов AES_CBC_HMAC_SHA2. . . . 62
В.1. Тестовые примеры для AES_128_CBC_HMAC_SHA_256. . . . . . . . . 63
БИ 2. Тестовые примеры для AES_192_CBC_HMAC_SHA_384. . .. . . . . . 64
В.3. Тестовые примеры для AES_256_CBC_HMAC_SHA_512. . . . . . . . . 65
Приложение C. Пример расчета ключевого соглашения ECDH-ES. . . . . 66
Благодарности. . . . . . . . . . . . . . . . . . . . . . . . 69
Адрес автора. . . . . . . . . . . . . . . . . . . . . . . . 69
1. Введение
Эта спецификация регистрирует криптографические алгоритмы и идентификаторы.
для использования с веб-подписью JSON (JWS) [JWS], JSON Web
Спецификации шифрования (JWE) [JWE] и веб-ключа JSON (JWK) [JWK].Он определяет несколько реестров IANA для этих идентификаторов. Все эти
спецификации используют структуры данных на основе JSON [RFC7159]. Этот
спецификация также описывает семантику и операции, которые
специфические для этих алгоритмов и типов ключей.
Регистрация алгоритмов и идентификаторов здесь, а не в
Спецификации JWS, JWE и JWK предназначены для того, чтобы они оставались
без изменений с учетом изменений в наборе Обязательных, Рекомендуемых,
Необязательные и устаревшие алгоритмы с течением времени.
Это также позволяет
вносит изменения в спецификации JWS, JWE и JWK без изменения этого
документ.
Имена, определенные в этой спецификации, короткие, потому что основная цель
для компактности полученных представлений.
1.1. Условные обозначения
Ключевые слова «ДОЛЖНЫ», «НЕ ДОЛЖНЫ», «ОБЯЗАТЕЛЬНО», «ДОЛЖНЫ», «НЕ ДОЛЖНЫ»,
«ДОЛЖЕН», «НЕ ДОЛЖЕН», «РЕКОМЕНДУЕТСЯ», «НЕ РЕКОМЕНДУЕТСЯ», «МОЖЕТ» и
«ДОПОЛНИТЕЛЬНО» в этом документе следует толковать, как описано в
«Ключевые слова для использования в RFC для обозначения уровней требований» [RFC2119].Jones Standards Track [Страница 4] 
ASCII (STRING) обозначает октеты представления ASCII [RFC20].
of STRING, где STRING - это последовательность из нуля или более ASCII
символы.
Объединение двух значений A и B обозначается как A || Б.
2. Терминология
Термины «Веб-подпись JSON (JWS)», «Кодировка Base64url», «Заголовок
Параметр »,« Заголовок JOSE »,« Полезная нагрузка JWS »,« Защищенный заголовок JWS »,
"Подпись JWS", "Вход для подписи JWS" и "Незащищенный JWS" определены
согласно спецификации JWS [JWS].
Термины «JSON Web Encryption (JWE)», «Дополнительные проверенные данные
(AAD) "," Тег аутентификации "," Ключ шифрования содержимого (CEK) "," Прямой
Шифрование "," Соглашение о прямом ключе "," Тег аутентификации JWE "," JWE
Шифрованный текст "," Зашифрованный ключ JWE "," Вектор инициализации JWE "," JWE
Защищенный заголовок "," Соглашение о ключах с переносом ключей "," Ключ
Шифрование "," Режим управления ключами "и" Перенос ключей "определяются
спецификация JWE [JWE].Термины «Веб-ключ JSON (JWK)» и «Набор JWK» определены JWK.
спецификация [JWK].
Термины «Шифрованный текст», «Цифровая подпись», «Вектор инициализации»,
«Код аутентификации сообщения (MAC)» и «Открытый текст» определяются
"Глоссарий по безопасности в Интернете, версия 2" [RFC4949].
Этот термин определяется данной спецификацией:
Base64urlUInt
Представление положительного или нулевого целочисленного значения как
base64url кодирование беззнакового обратного порядка байтов значения
представление в виде последовательности октетов.Последовательность октетов ДОЛЖНА
использовать минимальное количество октетов, необходимых для представления
значение. Ноль представлен как BASE64URL (одиночный нулевой
октет), то есть "AA".
Jones Standards Track [Страница 5]
Добавить комментарий