Сип как расшифровать: расшифровка, конструкция, виды, технические характеристики

Содержание

Расшифровка марок СИП

Сравнительные характеристики проводов СИП

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

Провод СИП-4 – самонесущий изолированный провод из светостабилизированного полиэтилена.

Провод СИП-5 – самонесущий изолированный провод из светостабилизированного сшитого полиэтилена.

Провод СИП-5нг (AsXSn) — самонесущий изолированный провод из светостабилизированного сшитого полиэтилена с изоляцией, не поддерживающей горение.

Сравнительные характеристики проводов СИП

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

СИП-4

СИП-5

СИП-5нг

Токопроводящая жила

алюминиевая, круглой формы, многопроволочная уплотненная

алюминиевая, круглой формы, многопроволочная уплотненная

алюминиевая, круглой формы, многопроволочная уплотненная

Изоляция

светостабилизи-рованный полиэтилен

светостабилизи-рованный сшитый полиэтилен

светостабилизи-рованный сшитый полиэтилен, не поддерживающий горение

Стойкость к изгибу

при t° -40°С

при t° -40°С

при t° -40°

Температура эксплуатации

от -60 °С до +50 °С

от -60 °С до +50 °С

от -60 °С до +50 °С

min температура прокладки провода

-20°С

-20°С

-20°С

Длительно допустимая температура нагрева жил

+70 °С

+90 °С

+90 °С

min радиус изгиба при прокладке

10 Ø провода

10 Ø провода

10 Ø провода

min срок службы

25 лет

25 лет

25 лет

расшифровка аббревиатуры самонесущего кабеля, характеристики и монтаж

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

Устройство кабеля

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

Разделяют разные маркировки изделия:

  • ​СИП-1 и 1А;
  • провод 2 и 2А;
  • СИП-3 и 3А;
  • марки 4 и 5.

Первые модели используют в трехфазных сетях. Провод состоит из четырёх алюминиевых жил, покрытых устойчивым к свету полиэтиленом. У четвёртой составляющей стальной сердечник, она не заизолирована. Жила выполняет роль нейтральной и несущей. У СИП-2 такие же свойства, но все составляющие покрыты изоляцией.

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

Самым качественным считается провод СИП-4. Он состоит из четырёх компонентов, каждый из них изолирован термопластичным материалом. Но у него отсутствует несущая жила. Третья модель рассчитана на максимальное напряжение до 35 кВ, остальные до 1 кВ.

У разных видов кабеля СИП характеристики общие:

  • срок гарантии не превышает пяти лет;
  • эксплуатационное время достигает 45 лет;
  • кабель подходит для использования в холодном климате;
  • температура при монтаже может опускаться до -10 градусов;
  • интервал эксплуатации — от -60 до +50 по Цельсию.

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

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

Условия монтажа

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

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

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

Сфера применения

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

У СИП есть импортные аналоги. Финны выпускают качественный проводник АМКА, а французы предлагают приобрести свой кабель марки Торсада. СИП-3 легко заменить польскими кабелями SAX или PAS-W. Модели 4 и 5 характеристиками похожи на изделия шведских производителей Ex Four Core, AsXsn или ALUS.

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

  • «Рыбинсккабель»;
  • «Завод Москабель»;
  • «Камский кабель»;
  • «Севкабель».

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

СИП — это… Что такое СИП?

СИП

самонесущий изолированный провод

Источник: http://www.mzva.ru/

СИП

специальная инженерная подготовка

СИП

Столичный институт переводчиков

Москва, образование и наука

СИП

станкоинструментальное производство

Словарь: С. Фадеев. Словарь сокращений современного русского языка. — С.-Пб.: Политехника, 1997. — 527 с.

СИП

Семипалатинский испытательный полигон

Казахстан

Источник: http://www.tmet.freenet.kz/conten.htm

СИП

русская аббревиатура индекса Standart & Poor 500

англ.: Standart & Poor 500

англ.

СИП

стабилизированный источник питания

  1. СиП
  2. СП

социология и политология

кафедра СиП ТулГУ; кафедра СП СПбГЭТУ

г. Тула, образование и наука, полит., Санкт-Петербург

  1. СиП

Источник: http://tsu.tula.ru/index.php?id=26

  1. СИП
  2. СиП

слияния и поглощения
слияния и приобретения

англ.: mergers and acquisitions

http://geopub.narod.ru/​student/​fokin/​3/​end.htm

англ.

  1. СИП

Пример использования

На долю американских корпораций приходится 40% количества сделок по слиянию и приобретению компаний (СИП) стоимостью более 1 млрд долл. (Фокин С. Влияние транснациональных компаний на конкурентоспособность стран)
Трансграничные СиП сократились в большей степени, чем ПИИ, вкладываемые в новые проекты.

«Логос-Пресс-Консультант», №33 (529). 12 сентября 2003

  1. СИП
  2. СиП

слияния и поглощения
слияния и приобретения

англ.: mergers and acquisitions

http://geopub.narod.ru/​student/​fokin/​3/​end.htm

англ.

  1. СИП

Пример использования

На долю американских корпораций приходится 40% количества сделок по слиянию и приобретению компаний (СИП) стоимостью более 1 млрд долл. (Фокин С. Влияние транснациональных компаний на конкурентоспособность стран)
Трансграничные СиП сократились в большей степени, чем ПИИ, вкладываемые в новые проекты.

«Логос-Пресс-Консультант», №33 (529). 12 сентября 2003

СиП

Спутник и погром

ультранационалистический проект

http://sputnikipogrom.com/​

Источник: http://identarist.ru/index.php/2013/10/sip/

СИП

служба информационной поддержки

СИП

социальная информационная продукция;
социальный информационный продукт

СИП

стойка индивидуального преобразования

в маркировке, связь

СИП

стоимость инвестиционного проекта

фин.

Источник: http://www.cfin.ru/finanalysis/invest/cip.shtml

СИП

самолётный измерительный пункт

авиа

Источник: http://www.airwar.ru/enc/spy/il18rt.html

СИП

среднесрочная инвестиционная программа

Источник: http://www.oilcapital.ru/news/2008/03/111127_120992.shtml

СИП

струнный измерительный преобразователь

Источник: http://www.energo-press.info/nre/arc/NRE/2003/09-nre.pdf

СИП

«СургутИнтерНовости»

ТРК

Казахстан

СиП

социология и психология

кафедра

мед., образование и наука

Источник: http://www.npi-tu.ru/?lang=rus&id=2&pid=103&ppid=165

Словарь сокращений и аббревиатур. Академик. 2015.

Что такое SIP-панели? — Ultrasip.ru


Аббревиатура «SIP» расшифровывается как «Structural Insulated Panel», на русский язык этот термин обычно переводят как «несущая утепленная панель» либо «конструкционная теплоизоляционная панель». Но поскольку в строительный лексикон уже прочно вошло слово SIP, встречается перевод «структурно-изоляционная панель», не вполне правильный, но соответствующий аббревиатуре СИП по первым буквам.

Устройство SIP-панели несложно. Это «бутерброд» из листа пенополистирола (ППС) и двух листов OSB, склеенных специальным клеем на промышленном оборудовании. Образуется монолитная конструкция с высокими нагрузочными и теплоизоляционными характеристиками.

Немного про составные части SIP-панели.

OSB (Orient Strand Board), по русски «ориентированно-стружечная плита» (ОСП), производится из трех слоев древесной щепы.

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

В наружных слоях щепа, как правило, ориентирована продольно, а во внутренних – поперечно. Благодаря послойно-перекрестному ориентированию щепы OSB плиты по своим физико-механическим свойствам намного превосходят традиционные ДСП и МДФ.

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

В настоящий момент в России для изготовления качественных СИП-панелей применяется плита ОСБ типа «3», специально предназначенная для изготовления несущих конструкций, в том числе, и в условиях повышенной влажности.

Пенополистирол (EPS, ППС) – вспененный полистирольный пластик с закрытыми порами. Это отличный утеплитель, уже многие годы применяющийся в строительстве. Он не токсичен, не выделяет вредных веществ.

За счет низкой теплопроводности пенополистирола СИП панели имеют хорошие показатели теплоизоляции. Для сравнения, типовая СИП-панель толщиной в 174 мм по теплоизоляции аналогична кирпичной кладке толщиной 2,5 метра, или 4,2 метра железобетона.

Клей — как правило это влагоотверждаемый однокомпонентный реактивный клей на основе полиуретана.

Типовые размеры СИП-панелей: стеновые СИП-панели обычно устанавливаются вертикально, и их длина соответствует типичной высоте этажа. Длина их в России составляет 2500 либо 2800 мм и обусловлена размерами плит OSB. Ширина — 625 либо 1250 мм. При производстве домокомплекта панели нарезаются согласно проектным размерам.

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

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

технические характеристики, расшифровка, ГОСТ, ТУ, применение 🚩35 сечений по цене от 57.99 ₽ до 336.34 ₽

ГОСТ СИП-2: 31946-2012

Нормативная документация: ТУ 16-705.500-2006
Код ОКПО: 35 5332 0900


Расшифровка СИП-2

  • С — Самонесущий
  • И — Изолированный
  • П — Провод
  • 2 — Изолированная нулевая несущая жила

Конструкция провода СИП-2

  1. Основные жилы — алюминевые жилы, круглой формы, многопроволочные, уплотненные.
  2. Изоляция — светостабилизированный сшитый полиэтилен (ПЭ).
  3. Несущая жила — сталеалюминиевая нулевая, круглой формы, скручена из круглых проволок, уплотненная, изолированная из светостабилизированного сшитого полиэтилена.
  4. Вспомогательная жила — алюминиевая второстепенная токопроводящая жила, изолированная из светостабилизированного сшитого полиэтилена
  5. Провод — изолированные основные жилы, скрученные вокруг неизолированной несущей жилы.
  6. Скрутка изолированных жил имеет правое направление.

Технические характеристики СИП-2

Номинальное переменное напряжение 0,6/1 кВ частотой 50 Гц
Испытательное импульсное напряжение 20 кВ
Коэфициент линейного расширения алюминиевого сплава не более 23х10-6 1/°С
Удельное объемное сопротивление изоляции и защитной изоляции, при длительно-допустимой температуре нагрева токопроводящих жил не менее 1х1012 Ом*см
Строительная длина, не менее 200-450 метров
Минимальный радиус изгиба 10 наружных диаметров
Модуль упругости токопроводящей жилы не менее 62 500 Н/мм2
Прочность при растяжении проволок из алюминиевого сплава не менее 295 Н/мм2
Допустимые усилия при протяжке кабеля по трассе прокладки 50 Н/мм2
Относительное удлинение при разрыве не менее 4%
Диапазон температур эксплуатации от -60°С до +50°С
Вид климатического исполнения B, категорий размещения 1, 2 и 3 по ГОСТ 15150
Минимальная температура прокладки кабеля без предварительного подогрева -20°С
Стойкость к воздействию повышенной относительной влажности
при температуре окружающей среды до +35°C
98%
Допустимая температура нагрева жил длительно-допустимая +90°С
в режиме перегрузки +130°С
предельная при коротком замыкании +250°С
Гарантийный срок эксплуатации 3 года
Срок службы не менее 40 лет

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

Характеристики изоляции из светостабилизированного сшитого полиэтилена

Наименование характеристики Значение
До старения
Прочность при растяжении, МПа, не менее 12,5
Относительное удлинение при разрыве, %, не менее 200
После старения в термостате при температуре (135±3)°С в течение 168 часов
Изменение* значения прочности при растяжении, %, не более ±25
Изменение* значения относительного удлинения при разрыве, %, не более ±25
Тепловая деформация
Относительное удлинение после выдержки при температуре (200±3)°С и растягивающей нагрузке 0,2 МПа, %, не более 175
Остаточное относительное удлинение после снятия нагрузки и охлаждения, %, не более 15
Водопоглощение после выдержки в течение 336 часов в воде при температуре (85±2)°С: изменение массы, мг/см2, не более 1
Усадка после выдержки в термостате при температуре (130±3)°С в течение 1 часа, %, не более 4
Стойкость к продавливанию при воздействии температуры (90±2) °С в течение 4 часов: глубина продавливания, %, не более 50
Содержание сажи, %, не менее 2,5

* Изменение — разность между средним значением, полученным после старения, и средним значением, полученным до старения, выраженная в процентах от последнего.


Таблица сечений и маркоразмеры СИП-2

Число жил и номинальное сечение жилы, мм2 Максимальный наружный диаметр, мм Расчетная масса, кг/км
3х16+1х25 24 308
3х16+1х54,6 28 427
3х25+1х35 27 424
3х25+1х54,6 30 512
3х35+1х50 31 571
3х35+1х54,6 32 606
3х50+1х50 34 727
3х50+1х54,6 35 762
3х50+1х70 36 798
3х70+1х54,6 39 973
3х70+1х70 40 1010
3х70+1х95 41 1087
3х95+1х70 43 1240
3х95+1х95 45 1319
3х120+1х95 48 1553
3х25+1х54,6+1х16 27 552
3х35+1х50+1х16 25 607
3х35+1х50+1х25 27 636
3х35+1х54,6+1х16 27 641
3х35+1х54,6+1х25 28 670
3х50+1х50+1х16 25 735
3х50+1х50+1х25 27 764
3х50+1х54,6+1х16 27 768
3х50+1х54,6+1х25 28 798
3х50+1х70+1х16 28 814
3х70+1х54,6+1х16 27 976
3х70+1х54,6+1х25 28 1005
3х70+1х70+1х25 29 1050
3х70+1х70+1х35 31 1080
3х70+1х95+1х16 31 1100
3х70+1х95+1х25 31 1115
3х70+1х95+1х35 36 1252
3х95+1х95+1х16 39 1381
3х95+1х95+1х25 39 1422
3х120+1х95+1х25 34 1595

Аналоги СИП-2

СИП-1 — Отличие: неизолированная нулевая несущая жила.


Где применяется

Провод предназначен:

  • для магистралей воздушных линий электропередачи (ВЛ) и линейных ответвлений от ВЛ на номинальное напряжение до 0,6/1 кВ включительно номинальной частотой 50 Гц в атмосфере воздуха типов 2 и 3 по ГОСТ 15150, в том числе на побережьях морей, соленых озер, в промышленных районах и районах засоленных песков.

Цвета

Кабель выпускается в черном цвете.

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

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

🔺 Количество товара в каталоге 35 по цене от 57.99 ₽
🔺 Технические характеристики, фото, выбор по параметрам, оптовая и розничная продажа
🔺 Доставка по Москве и всей России

Что такое SIP-телефония, как работает и для чего применяется

Большинство пользователей глобальной сети знают и даже активно используют способ передачи мультимедийных данных через Интернет – межсетевой протокол IP (Internet Protocol). Если говорить просто, то для обмена информацией, включая аудиосообщения, требуется установить IP-соединение между устройствами.


Но что такое SIP-телефония? Это один из протоколов передачи голосовой информации, который базируется на принципах IP-телефонии. Расшифровывается SIP как Session Initiation Protocol – «Протокол Установления Сеанса». Используется для множества целей – аудио и видеоконференции, телефония, онлайн-игры и другое. Протокол SIP работает по схеме «клиент-сервер-клиент», чередуя запросы и ответы.

Далее подробно остановимся на алгоритме работы, отличиях от IP и VoIP и преимуществах SIP-телефонии.

Как работает

Что такое звонок через SIP? Обмен голосовыми сообщениями выполняется по следующему алгоритму:


  1. Первый абонент передает голосовое сообщение, которое записывается и сжимается с помощью специальных кодеков, встроенных в программные модули. Пользователь не замечает работу этих скриптов, однако, благодаря сжатию аудиоданных снижается нагрузка на Интернет-соединение. Качество при этом остается высоким за счет преобразования аналогового сигнала в цифровой.
  2. Цифровой сигнал поступает на принимающего устройство второго абонента – СИП-телефон, компьютер, смартфон.
  3. Между устройствами устанавливается связь, то есть сначала они находят друг друга по IP-адресу, а затем подключаются по SIP-протоколу и начинают сеанс.
  4. После соединения со вторым устройством цифровой сигнал преобразуется в аналоговый, и абонент слышит в трубке или гарнитуре голос собеседника.

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

Что нужно для отправки и приема звонка через Интернет?


Пользователям предлагается несколько вариантов применения SIP-протокола:

  1. С помощью ноутбука или стационарного ПК. На устройство следует установить программный клиент и оснастить его гарнитурой – обычно это наушники и микрофон.
  2. Используя смартфон, планшет или другой гаджет с наличием операционной системы и возможностью подключения к сети Интернет. На гаджет устанавливается специальный модуль, выполняется подключение и регистрация по инструкции к программному обеспечению. Звонок по SIP-каналу можно выполнить через мобильные сети 3G и 4G, а также через Wi-Fi.
  3. Посредством стационарного SIP-телефона, который подключается к роутеру.
  4. Применяя VoIP-шлюз с подключенным проводным телефоном. Шлюз подключается к роутеру.

Разберем на примере, что такое SIP.

Владислав планирует перелет самолетом из Пхукета в Москву на определенное время. На смартфоне у него SIP-клиент. Российская авиакомпания также имеет виртуальную АТС с поддержкой этого протокола. Владислав набирает номер компании, через сервер смартфона выполняется поиск IP-адреса авиаперевозчика. При отклике абоненты соединяются для обмена информацией.

Голосовые сообщения Владислава сжимаются и оцифровываются, после чего передаются на сервер собеседника. СИП-модуль виртуальной АТС дешифрует сигнал и передает его на устройство уже в аналоговом качестве – абонент слышит голос.

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

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

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

Также клиентам выдаются стандартные телефонные номера:

  • Виртуальные. Обычно – это комбинации с какой-то добавочной информацией, которая позволяет идентифицировать номер. Пользователи соединяются сначала с сервером поставщика услуги, а после по «цифровому хвосту» номера связываются непосредственно с абонентом.
  • Прямые. Это привычные комбинации цифр, которые используются для городских и междугородних номеров. Звонки на такие линии выполняются без отличия от вызовов через обычные АТС. Главное преимущество – качество сигнала выше, за счет цифровой обработки на стороне SIP-оператора.
  • Бесплатные. Номера вида 8-800 используются сервисами, службами поддержки и работы с клиентами по России. На них также можно звонить, используя SIP-протокол.

Ввод комбинаций номера в SIP-телефонии аналогичен с сотовой связью, то есть используется код страны. Например, для России – (+7).

Чем отличается SIP-телефония от VoIP и IP


Если СИП-протокол – это стандарт для звонков через Интернет, тогда возникает вопрос: для каких целей применяют IP-телефонию и VoIP? Например, подключаясь к виртуальной АТС, эти технологии используются совместно, что несколько запутывает неопытных пользователей. Давайте разберемся в понятиях.

Начнем с фундамента – это Internet Protocol или IP, что означает межсетевой протокол. По нему все сетевые устройства в мире связываются в глобальную сеть. Соответственно у каждого компьютера, гаджета, сервера или прибора подключенного к интернету есть уникальный IP-адрес. С его помощью пользователи обмениваются любыми данными и информацией.

Чтобы передавать аудиоданные по сети была придумана собственная технология, ответвление Internet Protocol – VoIP, то есть Voice over IP. Переводится как «голос по IP» или проще «голос по Интернету». С помощью этой технологии пользователи могут обмениваться данными, где в каком-либо виде присутствует голос. Например, вебинары и трансляции через Интернет, звонки в сети, онлайн-игры, видеонаблюдение с оповещением и другое.

SIP-телефония представляет собой более узкое понятие, то есть разновидность IP-телефонии, выделенный протокол связи. Основное отличие в том, что соединение между абонентами осуществляется только по этому каналу, не используя другие технологии. Это позволяет привязать номер к конкретному пользователю, а не к общей локации. Например, SIP-протокол применяется в Skype, а также в сервисах отслеживания звонков call tracking.

Преимущества технологии

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

  1. Экономия бюджета. Подключить этот протокол гораздо дешевле, чем обеспечить офис аналоговой АТС. К тому же в вашем распоряжении многоканальный номер, отличная скорость и качество соединения. Вы можете легко увеличить число операторов в вашей сети при минимальных затратах времени и средств. Попробуйте сделать такое в аналоговой АТС.
  2. Телефонизация компании на «раз-два». SIP-телефонию можно описать одной фразой: «подключись и работай». Например, вы только въехали в новый офис, ещё не успели обустроиться, но связь с клиентами хотите поддерживать. Как это сделать быстро и без забот, если у вас есть ноутбук с гарнитурой, компьютер или гаджет? Только с помощью технологии SIP. Для стабильного соединения подойдет даже мобильный интернет 3G или 4G.


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


  1. Технология позволяет создать удаленный колл-центр, не тратя деньги на закупку стационарного оборудования и аренду офиса.
  2. Множество опций – голосовая почта, переадресация между сотрудниками и отделами, автоответчик, голосовое меню. Также СИП-технология позволяет проставлять очередность звонков, ориентируясь на загрузку менеджеров, записывать разговоры.
  3. Протокол отлично работает с модулями обратного звонка, пропущенных вызовов на сайте. В связке они увеличивают показатели конверсии звонков в заявку в среднем на 60%.
  4. Наличие программного обеспечения для любых операционных систем, мобильных устройств, смартфонов.

Мы ответили на вопрос, SIP-телефония: что это и как работает. Рассмотрим, где эта технология активнее всего применяется.  

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

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

Резюме

Мы изучили, что такое SIP. Узнали отличия этого вида интернет-телефонии от IP-связи и VoIP. Рассмотрели принцип работы, преимущества, программное обеспечение и сферу применения технологии.

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

Провод СИП-4


Провод СИП-4

Расшифровка провода СИП-4:
С — Самонесущий
И — Изолированный
П — Провод

Использование провода СИП-4

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

Конструкция провода СИП-4:

  1. Алюминиевая жила, может быть многопроволочной, круглой или уплотненной. Конструкция не предусматривает отдельной несущей жилы.
  2. Изоляция выполнена из светостабилизированного сшитого ПЭ. Изолированные жилы имеют разную расцветку или нумерацию.
  3. Скрутка вправо.

Технические характеристики провода СИП-4:

Температура эксплуатации от: -50 до +50 °С;
Температура при монтаже не менее: -20 °С;
Максимально допустимая температура нагрева токопроводящих жил:
— в обычном режиме эксплуатации: — 70;
— в режиме перегрузки (но не более 8 часов в сутки): — 80;
Короткое замыкание с протеканием тока КЗ (до 5 секунд): — 135;
Разрывная прочность фазного провода:
— при сечении троса 25 мм2 — 4,1 кН;
— при сечении троса 50 мм2 — 7,3 кН;
— при сечении троса 95 мм2 — 13,7 кН;

Номинальное рабочее напряжение — 0,66 кВ или 1 кВ;

Частота переменного тока — 50 Гц;

Расчетная таблица

Марка провода

Сечение

Внешний диаметр, мм

Масса провода кг/км

СИП-4

2х10

12,2

91,4

СИП-4

2х35

18,8

257,5

СИП-4

2х50

21,8

349,0

СИП-4

2х70

25,6

493,5

СИП-4

2х95

29,4

653,5

СИП-4

2х120

39,0

1617,0

СИП-4

4х10

14,7

182,8

СИП-4

4х35

22,7

515,0

СИП-4

4х50

26,3

698,0

СИП-4

4х70

30,9

987,0

СИП-4

4х95

35,4

1307,0

СИП-4

4х120

47,0

3234,0


Как декодировать SIP через TLS с помощью Wireshark — База знаний 4PSA

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

Пошаговое руководство

Сделайте захват

Первый шаг — захват вызова. Вызов может проходить через TLS, UDP или TCP.Также порты могут быть 5060 или 5061 для Kamailio или 5050 для Asterisk.

  1. Чтобы захватить их все, выполните следующую команду:

     tcpdump -nni any -s 0 порт 5050 или порт 5060 или порт 5061 -w /usr/local/voipnow/admin/htdocs/tls.pcap 
  2. Когда вы откроете захват, вы увидите, что часть вызова TLS даже не распознается Wireshark как SIP.
    На снимке ниже мы получили звонок с телефонного терминала (A) 192.168.1.225 через сервер VoipNow (B) по адресу 10.150.20.27 и к другому телефонному терминалу (C) по UDP по адресу 192.168.3.152. Как видите, часть между A и B отсутствует, потому что она использует TLS, тогда как связь между B и C происходит по UDP и видна. В захвате закодированные пакеты будут отображаться как TLS.

  3. Помимо фильтров, когда вы захватываете TLS, вам необходимо убедиться, что вы захватили рукопожатие SSL между телефонным терминалом и сервером VoipNow. В противном случае вы не сможете расшифровать захват.

Декодировать TLS

  1. Сначала вам понадобится закрытый ключ, используемый Kamailio. В VoipNow 3.5 вы можете найти его в /etc/voipnow/certs/kamailio.pem.
  2. Возьмите закрытый ключ и сохраните его на своем ПК в файле filename.key. Должно получиться так:

     ----- НАЧАТЬ ЧАСТНЫЙ КЛЮЧ -----
    MIIEvgIBADANBgkahkiG9w0BAQEFAASCBKgwggSkAgEAAoIBAQDLsm335w5i + BiY
    gg05NsBTR1ZTSbsMjkoprJoQ8KPxFvLGegwyWY + Fk25GmFCur7GfZYuYACXcU0H /
    ...
    l7DtP + PYdC2Yz6lld8FO6LB6RgsZHnXlDj8yxhzeALDBRvZSt + of4iedEK1J + 0pA
    zuqB / sOrM + e1J8z3vsF9kikZ
    ----- КОНЕЦ ЧАСТНОГО КЛЮЧА ---- 
  3. Откройте Wireshark и перейдите в Edit >> Preferences >> Protocols >> SSL >> Edit и выполните точную настройку, как показано ниже.Используйте файл, созданный ранее с закрытым ключом.

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

    Это квитирование SSL происходит во время каждой перезагрузки телефона и после каждого квитирования TCP.

    На этом этапе должен быть виден весь поток вызовов.

Статьи по теме

#trackbackRdf ($ trackbackUtils.getContentIdentifier ($ page) $ page.title $ trackbackUtils.getPingUrl ($ page))

Зашифрованные и незашифрованные пакеты SIP в Wireshark

VoIP и шифрование — это результат инкапсуляции передачи пакетов протокола VoIP и сопровождающих аудиопакетов в некоторый метод шифрования, например TLS (безопасность транспортного уровня). В нашем случае мы используем самый распространенный протокол VoIP — SIP (Session Initiation Protocol) и медиа-метод — RTP (Real-time Transfer Protocol).

(Чтобы просмотреть видеоверсию этого пошагового руководства, посетите https://youtu.be/XMjXixv7h38)

Честно говоря, один может быть зашифрован без другого, но по существу делает другой бесполезным или уязвимым за пределами того, что вы могли бы счесть «хорошей идеей». Например;

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

Хотя они не могли бы просматривать детали телефонных звонков из самих пакетов, в чем вообще смысл?

В обратном порядке — Наш администратор шифрует аудиопакеты, но не SIP-пакеты. Вы можете спросить: «Ну, разговор важнее, не так ли?». Хотя я склонен согласиться, что злоумышленник может получить информацию для проведения других типов атак.

Сюда входят;

Обнаружение IP-адреса УАТС: Теперь УАТС может быть целью проникновения или DDoS

Обнаружение IP-адреса устройства пользователя: Телефон может быть атакован для DDoS-атак.
Если IP-телефон использует POE, он может быть подключен последовательно через ПК пользователя, что также будет уязвимо. IP также может использоваться для будущей идентификации пользователя.

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

Как упоминалось выше, обычным шифрованием, используемым для SIP, является протокол TLS (SIP / TLS). Таким образом, шифрование имеет преимущества и ограничения TLS и любые уязвимости безопасности, которые могут возникнуть с ним.Вот почему так важно быть в курсе проблем TLS, таких как ошибка Heartbleed (https://xkcd.com/1354/) и изменение шифрования с v1.0 / 1.1 на 1.2.

Для инкапсуляции аудиопакетов мы используем так называемый DTLS-SRTP (https://en.wikipedia.org/wiki/Datagram_Transport_Layer_Security) — безопасный транспортный протокол в реальном времени (как вы уже догадались), который также основан на протоколе TLS. .

Существует также еще один проект под названием ZRTP (https://en.wikipedia.org/wiki/ZRTP), где Z происходит от «Циммермана», который также создал проект PGP.Хотя этот метод был создан в 2006 году, он не получил такого широкого распространения, как SRTP, вероятно, из-за отсутствия поддерживающих его конечных точек.

Давайте посмотрим на некоторые сравнения пакетов из Wireshark
Незашифрованный пакет вызовов SIP
Небезопасный пакет SIP. Обратите внимание на полную информацию о вызове.
Незашифрованный поток вызовов SIP
Зашифрованный вызов с использованием SIP / TLS
Защищенный вызов завершен. Обратите внимание на отсутствие подробностей звонка.
Безопасный поток вызовов SIP.Невозможно записать сведения о звонке.
А что насчет аудио (RTP)?
Захват незашифрованного аудио
Незашифрованное аудио RTP. Полностью захвачено и воспроизводится повторно.
Зашифрованное аудио с SRTP
Безопасный пакет SRTP. Не могу расшифровать аудио.

Поскольку SIP / TLS и SRTP изначально встроены в большинство всех SIP-устройств, которые я видел за последние 10 лет, и даже готовы к использованию в таких проектах, как asterisk, нет никаких оправданий не использовать их.Для дополнительной безопасности вы также можете выбрать поставщика SIP, например nurango, который также предлагает зашифрованные магистрали SIP.

Secure SIP защищает трафик VoIP

Протокол инициирования сеанса

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

Secure SIP — это механизм безопасности, определенный в SIP RFC 3261, для отправки сообщений SIP по каналу с шифрованием Transport Layer Security.Первоначально используемый для защиты сеансов HTTP, TLS можно использовать для защиты сеансов связи SIP от перехвата или взлома. Развертывая устройства на основе SIP, поддерживающие Secure SIP, сетевые администраторы получают выгоду от повышенного уровня безопасности своих сетей VoIP.

Противодействие угрозам

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

RFC 3261 определяет механизмы для обеспечения повышенной безопасности сеанса SIP.

Самым базовым уровнем безопасности, который должен быть реализован всеми пользовательскими агентами SIP и прокси-серверами SIP, является проверка подлинности Message Digest (MD5). Это обеспечивает базовый уровень аутентификации между прокси-сервером SIP и пользовательским агентом SIP. На другом конце спектра могут быть реализованы безопасные многоцелевые расширения электронной почты (S / MIME) для шифрования данных непосредственно в сообщениях SIP.

Поддержка SIP для S / MIME не получила такого широкого распространения, как HTTP, из-за необходимой поддержки инфраструктуры открытого ключа и дополнительной сложности управления сертификатами безопасности. Безопасный SIP, выполняющий SIP через TLS на поэтапной основе, обеспечивает более полный уровень безопасности, чем базовая аутентификация MD5, без дополнительных накладных расходов, налагаемых S / MIME.

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

Для безопасной связи SIP RFC 3261 определяет унифицированный идентификатор ресурса SIPS (URI), поскольку HTTPS используется для безопасных соединений HTTP. SIPS URI гарантирует, что SIP через TLS используется между каждой парой переходов для проверки и защиты соединения, а также для обеспечения безопасного соединения между конечными точками.

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

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

Secure SIP — это необязательный элемент для пользовательских агентов SIP, но большее количество оконечных точек VoIP на основе SIP предоставляют его. Сетевым администраторам VoIP следует подумать о внедрении этой технологии в своих сетях на основе SIP, чтобы получить дополнительный уровень безопасности, который может обеспечить Secure SIP.

Уорд — директор по управлению линейкой продуктов в Trinity Convergence. С ним можно связаться по адресу [email protected]

Подробнее по этой теме

Aruba усиливает безопасность беспроводной голосовой связи

04.02.04

Сетевая безопасность — ключ к обеспечению безопасности сетей VoIP

20.02.06

Обзор: Тестирование пограничного контроллера сеанса включает продукты от Ditech, Ingate, Mera и…

17.04.06 Присоединяйтесь к сообществам Network World на Facebook и LinkedIn, чтобы комментировать самые важные темы.

Авторские права © 2006 IDG Communications, Inc.

Положения и условия | SIP2SIP

SIP2SIP — бесплатная услуга, предоставляемая AG Projects B.V. зарегистрированная компания в Нидерландах, что подчиняется законам Нидерландов и ЕС.

Услуга предназначена для тестирования производимого программного обеспечения и проданы AG Projects своим клиентам.

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

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

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

Как правило, данные конечных пользователей не передаются третьим лицам.

Общие

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

Счета

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

Удаление аккаунта

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

Чтобы удалить свою учетную запись, войдите на http://x.sip2sip.info. На вкладке «Удостоверение» нажмите кнопку удаления учетной записи.

Контакты

Контакты из вашей адресной книги никому не передаются и оставаться локальным для вашего SIP-клиента.

Сигнализация

Сигнализация может осуществляться в виде открытого текста с использованием протоколов UDP и TCP.Вы можете использовать TLS для шифрования данных между конечными точками и платформой SIP. и веб-серверы. Нет гарантии, что шифрование будет работать сквозная сигнальная часть платформы SIP обеспечивает только поэтапный переход. безопасность сигнализации, любой промежуточный узел может решить переключиться с TLS на незашифрованный транспорт, такой как UDP.

Сессии

Вся сигнализация SIP для установления сеанса (Методы INVITE / BYE / CANCEL / PRACK / ACK SIP и их ответы), передаваемые SIP-серверами платформы, хранятся в открытом виде для несколько дней в базах платформы.И конечные пользователи, и платформа Оператор имеет доступ к этой информации для устранения неполадок.

Регистрация

Никакая регистрационная информация (метод SIP REGISTER) не хранится в Платформа.

Подписок

Нет диалоговых окон присутствия (методы SUBSCRIBE / NOTIFY) и связанных XML полезные данные хранятся в базах данных сервера. Короткие логи о том, какое устройство или абонент меняет свое состояние присутствия, сохраняются для устранения неполадок целей.

Журнал регистрации звонков

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

Офлайн-обмен сообщениями

Текстовые сообщения

Сообщения, отправленные с использованием метода SIP MESSAGE, не могут быть доставлены на локальный пользователей платформы хранятся для последующей доставки в формате открытого текста в база данных платформы.

Голосовая почта

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

Медиа RTP

потоков RTP передаются медиа-реле, работающими на платформе. Настоящий данные нигде не хранятся. Вы можете зашифровать свои данные с помощью SRTP, но при использовании метода SDES, поддерживаемого большинством устройств, ключи шифрования доступны в виде открытого текста в сигнализации SIP. Кто имеет доступ к плоскость сигнализации (и все SIP-серверы на пути всегда имеют к ней доступ) сможет расшифровать любой зашифрованный SRTP поток с помощью ключа SDES обмен.Альтернативой является использование zRTP, где известны только ключи до конечных точек.

MSRP Медиа

Сообщения чата

сеансов чата MSRP выполняются через TLS-соединения через платформу MSRP relay серверы. Содержание сообщений нигде не регистрируется и не сохраняется.

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

Передача файлов

сеансов передачи файлов MSRP выполняются через TLS-соединения через платформу MSRP серверы ретрансляции. Содержимое файлов не регистрируется и не сохраняется, но MSRP Компонент relay видит их содержимое во время передачи.

Шлюз XMPP

Все сообщения чата и информация о присутствии передаются через SIP / XMPP. шлюз.Содержание сообщения нигде не хранится.

Защита данных и конфиденциальности

Чтобы свести к минимуму вероятность того, что ваши сеансы SIP и медиафайлы будут открыты, выполните следующие действия: следующее:

  • Использовать SIP-адреса, не раскрывающие ваше настоящее имя
  • Используйте обход ICE NAT в обеих конечных точках, таким образом потоки RTP могут протекать большую часть времени одноранговым узлом, не проходя через серверные медиа-реле, которые могут быть перехвачены
  • Используйте шифрование zRTP, таким образом вы будете знать о атаках посредников, пытающихся перехватить и расшифровать ваши данные
  • Не используйте метод SIP MESSAGE для сообщений чата, поскольку все сообщения проходят через сигнализацию, которая всегда скомпрометирована, когда сервер находится посередине.
  • Использовать механизмы сквозного шифрования, такие как OTR, при использовании чата MSRP
  • Используйте службы анонимизации для защиты / подделки реального IP-источника клиента.Это просто добавляет еще один уровень обфускации, где-то в сети анонимизации можно отследить реальный IP-адрес
Незаконный перехват

Чтобы защитить ваши данные от раскрытия через Интернет (например, прослушивания IP-адресов), выполните следующие действия:

  • Использовать TLS для сигнализации SIP (это зашифрует сигнализацию между клиентом и сервером)
  • Использовать zRTP для аудио и видео (клиенты Blink и Jitsi поддерживают zRTP)
  • Использовать TLS для носителей MSRP
  • Использовать OTR для чата (клиент Blink поддерживает OTR)

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

Законный перехват

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

RFC 8591: обмен сообщениями на основе SIP с S / MIME

RFC 8591: обмен сообщениями на основе SIP с S / MIME [RFC Home] [ТЕКСТ | PDF | HTML] [Tracker] [IPR] [Информационная страница]

ПРЕДЛАГАЕМЫЙ СТАНДАРТ
 Инженерная группа Интернета (IETF) B.Кэмпбелл
Запрос комментариев: 8591 стандартная скорость
Обновления: 3261, 3428, 4975 Р. Хаусли
Категория: Стандарты Track Vigil Security
ISSN: 2070-1721 апреля 2019 г.


                    Обмен сообщениями на основе SIP с S / MIME

Абстрактный

   Мобильные приложения для обмена сообщениями, используемые с инициированием сеанса
   Протокол (SIP) обычно использует некоторую комбинацию SIP MESSAGE
   метод и протокол ретрансляции сеанса сообщений (MSRP).Пока эти
   обеспечивают механизмы для пошаговой безопасности, ни один из них изначально не обеспечивает
   сквозная защита. Этот документ предлагает руководство о том, как
   обеспечивать сквозную аутентификацию, защиту целостности и
   конфиденциальность при использовании защищенной / многоцелевой интернет-почты
   Расширения (S / MIME). Он обновляет и предоставляет пояснения для RFC.
   3261, 3428 и 4975.

Статус этой памятки

   Это документ Internet Standards Track.

   Этот документ является продуктом Инженерной группы Интернета.
   (IETF).Он представляет собой консенсус сообщества IETF. Она имеет
   получил публичное рецензирование и был одобрен к публикации
   Инженерная группа управления Интернетом (IESG). Дополнительная информация о
   Интернет-стандарты доступны в разделе 2 RFC 7841.

   Информация о текущем статусе этого документа, исправлениях,
   а о том, как оставить отзыв о нем, можно узнать по адресу
   https://www.rfc-editor.org/info/rfc8591.

















Campbell & Housley Standards Track [Страница 1] 

RFC 8591 S / MIME для обмена сообщениями SIP, апрель 2019 г.


Уведомление об авторских правах

   Авторские права (c) 2019 IETF Trust и лица, указанные в качестве
   авторы документа.Все права защищены.

   Этот документ подпадает под действие BCP 78 и Правового регулирования IETF Trust.
   Положения, касающиеся документов IETF
   (https://trustee.ietf.org/license-info) действует на дату
   публикация этого документа. Пожалуйста, просмотрите эти документы
   внимательно, поскольку они уважительно описывают ваши права и ограничения
   к этому документу. Компоненты кода, извлеченные из этого документа, должны
   включить упрощенный текст лицензии BSD, как описано в Разделе 4.e
   Правовые положения Trust и предоставляются без гарантии, как
   описано в упрощенной лицензии BSD.Campbell & Housley Standards Track [Страница 2] 

RFC 8591 S / MIME для обмена сообщениями SIP, апрель 2019 г.


Оглавление

   1. Введение  . . . . . . . . . . . . . . . . . . . . . . . . 4
   2. Терминология. . . . . . . . . . . . . . . . . . . . . . . . . 4
   3. Постановка проблемы и масштаб. . . . . . . . . . . . . . . . . 5
   4. Применимость S / MIME. . . . . . . . . . .. . . . . . . . 6
     4.1. Подписанные сообщения. . . . . . . . . . . . . . . . . . . . . 6
     4.2. Зашифрованные сообщения. . . . . . . . . . . . . . . . . . . 7
     4.3. Подписанные и зашифрованные сообщения. . . . . . . . . . . . . . 9
     4.4. Обработка сертификатов. . . . . . . . . . . . . . . . . . 9
       4.4.1. Альтернативное имя субъекта. . . . . . . . . . . . . . 9
       4.4.2. Подтверждение сертификата. . . . . . . . . . . . . . . 9
   5. Кодирование передачи. . . . . . . . .. . . . . . . . . . . . . 9
   6. Возможности пользовательского агента. . . . . . . . . . . . . . . . . . . 10
   7. Использование S / MIME с методом SIP MESSAGE. . . . . . . . . . 11
     7.1. Ограничение размера. . . . . . . . . . . . . . . . . . . . . . . 11
     7.2. Возможности SIP User Agent. . . . . . . . . . . . . . . 11
     7.3. Случаи отказа. . . . . . . . . . . . . . . . . . . . . . 12
   8. Использование S / MIME с MSRP. . . . . . . . . . . . . . . . . . . 12
     8.1. Нарезка. . . . . .. . . . . . . . . . . . . . . . . . 12
     8.2. Потоковые данные. . . . . . . . . . . . . . . . . . . . . . 13
     8.3. Указывая на поддержку S / MIME. . . . . . . . . . . . . . 14
     8.4. URI MSRP. . . . . . . . . . . . . . . . . . . . . . . . 14
     8.5. Случаи отказа. . . . . . . . . . . . . . . . . . . . . . 15
   9. Взаимодействие S / MIME с другими функциями обмена сообщениями SIP. . . . 15
     9.1. Общий профиль для обмена мгновенными сообщениями. . . . . . . . . . 15
     9.2. Уведомления об отправке мгновенных сообщений.. . . . . . . 16
   10. Примеры. . . . . . . . . . . . . . . . . . . . . . . . . . 17
     10.1. Подписанное сообщение в SIP, включая сертификат отправителя 17
     10.2. Подписанное сообщение в SIP без сертификата. . . . . . . 19
     10.3. Подписанное и зашифрованное сообщение MSRP в одном фрагменте. . 20
     10.4. Подписанное и зашифрованное сообщение MSRP, отправленное в нескольких
            Куски. . . . . . . . . . . . . . . . . . . . . . . . . 21 год
   11. Вопросы IANA. . . . . . . . . . . . . .. . . . . . . 23
   12. Соображения безопасности. . . . . . . . . . . . . . . . . . . 23
   13. Список литературы. . . . . . . . . . . . . . . . . . . . . . . . . 25
     13.1. Нормативные ссылки . . . . . . . . . . . . . . . . . . 25
     13.2. Информативные ссылки. . . . . . . . . . . . . . . . . 28 год
   Приложение A. Детали сообщения. . . . . . . . . . . . . . . . . . 30
     А.1. Подписанное сообщение. . . . . . . . . . . . . . . . . . . . . 30
     А.2. Короткое подписанное сообщение. . . . . .. . . . . . . . . . . . 32
     А.3. Подписанное и зашифрованное сообщение. . . . . . . . . . . . . . 33
       А.3.1. Подписанное сообщение до шифрования. . . . . . . . . 33
       А.3.2. Зашифрованное сообщение. . . . . . . . . . . . . . . . . . 35 год
   Адреса авторов. . . . . . . . . . . . . . . . . . . . . . . 39






Campbell & Housley Standards Track [Страница 3] 

RFC 8591 S / MIME для обмена сообщениями SIP, апрель 2019 г.


1.Введение

   Несколько мобильных систем обмена сообщениями используют протокол инициации сеанса.
   (SIP) [RFC3261], обычно как некоторая комбинация SIP MESSAGE
   метод [RFC3428] и протокол ретрансляции сеанса сообщений (MSRP)
   [RFC4975]. Например, Voice over LTE (VoLTE) использует SIP MESSAGE.
   способ отправки сообщений службы коротких сообщений (SMS). Открытый мобильный
   Система конвергентных IP-сообщений (CPM) Альянса (OMA) [CPM] использует протокол SIP.
   MESSAGE для коротких сообщений в режиме пейджера и использует MSRP для
   большие сообщения и для сеансов сообщений.Глобальная система для
   Ассоциация мобильной связи (GSMA) Rich Communication Services
   (RCS) использует CPM для обмена сообщениями [RCS].

   В то же время организации все больше полагаются на мобильные
   системы обмена сообщениями для отправки уведомлений своим клиентам. Многие из
   эти уведомления важны для безопасности. Например, такие
   уведомления обычно используются для уведомления о финансовых транзакциях,
   уведомление о попытках смены логина или пароля и отправка
   коды двухфакторной аутентификации.И SIP, и MSRP можно использовать для передачи любого контента с помощью
   Форматы многоцелевых расширений электронной почты (MIME). SIP
   СООБЩЕНИЕ обычно ограничивается короткими сообщениями (под
   1300 октетов для запроса MESSAGE). MSRP может переносить произвольно
   большие сообщения и могут разбивать большие сообщения на куски.

   Хотя и SIP, и MSRP предоставляют механизмы для пошаговой защиты,
   ни один из них не обеспечивает сквозную защиту. Вместо этого они зависят
   в S / MIME [RFC8550] [RFC8551].Однако на момент написания этой статьи
   S / MIME редко используется для обмена сообщениями на основе SIP и MSRP.
   Сервисы. Этот документ обновляет и разъясняет RFC 3261, 3428 и
   4975 в попытке упростить S / MIME для SIP и MSRP
   реализовать и развернуть с возможностью взаимодействия.

   Этот документ обновляет RFC 3261, 3428 и 4975, чтобы обновить
   рекомендации по криптографическим алгоритмам и обработка S / MIME
   объекты данных. Он обновляет RFC 3261, чтобы разрешить сообщения, подписанные S / MIME, для
   в некоторых ситуациях отправляться без встроенных сертификатов.Ну наконец то,
   он обновляет RFC 3261, 3428 и 4975, чтобы прояснить сообщения об ошибках.
   требования для определенных ситуаций.

2. Терминология

   Ключевые слова «ДОЛЖНЫ», «НЕ ДОЛЖНЫ», «ОБЯЗАТЕЛЬНО», «ДОЛЖНЫ», «НЕ ДОЛЖНЫ»,
   «ДОЛЖЕН», «НЕ ДОЛЖЕН», «РЕКОМЕНДУЕТСЯ», «НЕ РЕКОМЕНДУЕТСЯ», «МОЖЕТ» и
   «ДОПОЛНИТЕЛЬНО» в этом документе следует толковать, как описано в
   BCP 14 [RFC2119] [RFC8174] когда и только когда они появляются во всех
   столицы, как показано здесь.



Campbell & Housley Standards Track [Страница 4] 

RFC 8591 S / MIME для обмена сообщениями SIP, апрель 2019 г.


3.Постановка проблемы и масштаб

   В этом документе обсуждается использование S / MIME с обменом сообщениями на основе SIP.
   Существуют и другие стандартизированные протоколы обмена сообщениями, например Extensible
   Протокол обмена сообщениями и присутствия (XMPP) [RFC6121]. Точно так же и другие
   существуют форматы сквозной защиты, такие как веб-подписи JSON
   [RFC7515] и веб-шифрование JSON [RFC7516].

   В этом документе основное внимание уделяется обмену сообщениями на основе SIP, поскольку его использование
   становится все более распространенным в мобильной среде. Он ориентирован на S / MIME,
   поскольку в нескольких мобильных операционных системах уже есть библиотеки S / MIME
   установлен.Хотя также может иметь значение указание сквозного
   безопасность для других механизмов обмена сообщениями и безопасности, это вне
   объем этого документа.

   Сеансы MSRP согласовываются с использованием протокола описания сеанса.
   (SDP) [RFC4566] механизм предложения / ответа [RFC3264] или аналогичный
   механизмы. В этом документе предполагается, что SIP используется для
   обмен предложения / ответа. Однако методы должны быть адаптируемыми.
   к другим протоколам сигнализации.

   [RFC3261], [RFC3428] и [RFC4975] уже описывают использование
   S / MIME.[RFC3853] обновляет SIP для поддержки расширенного шифрования.
   Стандартный (AES). В целом это руководство является неполным, содержит
   несоответствия, и все еще устарел с точки зрения поддерживаемых и
   рекомендуемые алгоритмы.

   Рекомендации RFC 3261 основаны на неявном предположении, что
   S / MIME используется для защиты приложений сигнализации. Этот совет
   не совсем подходит для приложений обмена сообщениями. Например,
   предполагается, что расшифровка сообщения всегда происходит до SIP
   транзакция завершена.Этот документ предлагает нормативные обновления и разъяснения по использованию
   S / MIME с помощью метода SIP MESSAGE и MSRP. Он не пытается
   для определения полной системы безопасного обмена сообщениями. Такая система могла бы
   требуется значительная работа по регистрации пользователей, сертификату и ключу
   генерация и управление, многосторонние чаты, управление устройствами и т. д.
   Хотя ничто в данном документе не должно препятствовать этим усилиям, они не работают.
   объем этого документа.

   Этот документ в первую очередь касается отправки одиночных сообщений - для
   например, "сообщения в режиме пейджера", отправленные с использованием метода SIP MESSAGE и
   «большие сообщения», отправленные в MSRP.Методы использования общей подписи или
   ключ шифрования в сеансе сообщений выходит за рамки этого
   документ.





Campbell & Housley Standards Track [Страница 5] 

RFC 8591 S / MIME для обмена сообщениями SIP, апрель 2019 г.


   Требования к криптографическим алгоритмам в этом документе предназначены для
   дополняют уже указанные для SIP и MSRP.

4. Применимость S / MIME

   Синтаксис криптографических сообщений (CMS) [RFC5652] представляет собой инкапсуляцию
   синтаксис, который используется для цифровой подписи, дайджеста, аутентификации или
   зашифровать произвольное содержимое сообщения.CMS поддерживает множество
   архитектуры для управления ключами на основе сертификатов, особенно
   один, определенный IETF PKIX (Инфраструктура открытых ключей с использованием X.509)
   Рабочая группа [RFC5280]. Значения CMS генерируются с использованием ASN.1.
   [X680], с использованием основных правил кодирования (BER) и Distinguished
   Правила кодирования (DER) [X690].

   Спецификация сообщений S / MIME [RFC8551] определяет части тела MIME.
   на базе CMS. В этом документе приложение / pkcs7-mime media
   используется для цифровой подписи инкапсулированной части тела, и это
   также используется для шифрования инкапсулированной части тела.4.1. Подписанные сообщения

   Хотя и SIP, и MSRP требуют поддержки multipart / signed
   формата, использование application / pkcs7-mime РЕКОМЕНДУЕТСЯ для большинства
   подписанные сообщения. Опыт использования S / MIME в электронном
   почта показала, что составные / подписанные тела подвергаются большему риску
   "полезное" вмешательство посредников, частая причина подписи
   ошибка проверки. Этот риск также присутствует при обмене сообщениями.
   Приложения; например, посредники могут вставить Instant
   Уведомление об отправке сообщений (IMDN) запрашивает [RFC5438] в
   Сообщения.(См. Раздел 9.2.) Формат application / pkcs7-mime следующий:
   также более компактный, что может быть важно для приложений обмена сообщениями,
   особенно при использовании метода SIP MESSAGE. (См. Раздел 7.1.)
   Использование multipart / signed может иметь смысл, если сообщение требует
   для чтения принимающими агентами, не поддерживающими S / MIME.

   При создании подписанного сообщения отправка пользовательских агентов (UA) ДОЛЖНА
   соблюдайте соглашения, указанные в [RFC8551] для
   Тип носителя application / pkcs7-mime с smime-type = signed-data.Когда
   проверяя подписанное сообщение, принимающие UA ДОЛЖНЫ следовать
   соглашения, указанные в [RFC8551] для приложения / pkcs7-mime
   Тип носителя с smime-type = signed-data.










Campbell & Housley Standards Track [Страница 6] 

RFC 8591 S / MIME для обмена сообщениями SIP, апрель 2019 г.


   Отправляющие и принимающие UA ДОЛЖНЫ поддерживать дайджест сообщения SHA-256.
   алгоритм [RFC5754]. Для удобства алгоритм SHA-256
   идентификатор повторяется здесь:

      id-sha256 ИДЕНТИФИКАТОР ОБЪЕКТА :: = {
        Joint-iso-itu-t (2) страна (16) сша (840) организация (1) правительство (101)
        csor (3) nistalgorithm (4) hashalgs (2) 1}

   Отправляющие и получающие UA МОГУТ поддерживать другой дайджест сообщения
   алгоритмы.Отправляющие и принимающие UA ДОЛЖНЫ поддерживать цифровую эллиптическую кривую.
   Алгоритм подписи (ECDSA) с использованием эллиптической кривой NIST P-256 и
   алгоритм дайджеста сообщения SHA-256 [RFC5480] [RFC5753]. Отправка
   и получающие UA ДОЛЖНЫ поддерживать цифровую подпись по кривой Эдвардса.
   Алгоритм (EdDSA) с curve25519 (Ed25519) [RFC8032] [RFC8419]. За
   удобство, ECDSA с идентификатором алгоритма SHA-256, объект
   идентификатор известной эллиптической кривой NIST P-256 и
   Идентификатор алгоритма Ed25519 повторяется здесь:

      ecdsa-with-SHA256 ИДЕНТИФИКАТОР ОБЪЕКТА :: = {
        iso (1) член-тело (2) us (840) ansi-X9-62 (10045) подписи (4)
        ecdsa-with-SHA2 (3) 2}

      - Примечание. Эллиптическая кривая NIST P-256 также известна как secp256r1.secp256r1 ИДЕНТИФИКАТОР ОБЪЕКТА :: = {
        iso (1) стержень-тело (2) us (840) ansi-X9-62 (10045) кривые (3)
        простое число (1) 7}

      id-Ed25519 ИДЕНТИФИКАТОР ОБЪЕКТА :: = {
        iso (1) идентифицированная организация (3) thawte (101) 112}

4.2. Зашифрованные сообщения

   При создании зашифрованного сообщения отправляющие UA ДОЛЖНЫ следовать
   соглашения, указанные в [RFC8551] для приложения / pkcs7-mime
   Тип носителя с smime-type = auth-enveloped-data. При расшифровке
   полученное сообщение, принимающие UA ДОЛЖНЫ следовать указанным соглашениям
   в [RFC8551] для типа носителя application / pkcs7-mime с
   smime-type = auth-enveloped-data.Campbell & Housley Standards Track [Страница 7] 

RFC 8591 S / MIME для обмена сообщениями SIP, апрель 2019 г.


   Отправляющие и принимающие UA ДОЛЖНЫ поддерживать алгоритм AES-128-GCM для
   шифрование содержимого [RFC5084]. Для удобства AES-128-GCM
   идентификатор алгоритма здесь повторяется:

      id-aes128-GCM ИДЕНТИФИКАТОР ОБЪЕКТА :: = {
        Joint-iso-itu-t (2) страна (16) сша (840) организация (1) правительство (101)
        csor (3) nistAlgorithm (4) aes (1) 6}

   Отправляющие и получающие UA МОГУТ поддерживать другой контент с аутентификацией.
   алгоритмы шифрования.Отправляющие и принимающие UA ДОЛЖНЫ поддерживать алгоритм AES-128-WRAP для
   шифрование одного ключа AES другим ключом AES [RFC3565]. За
   для удобства здесь повторяется идентификатор алгоритма AES-128-WRAP:

      id-aes128-wrap ИДЕНТИФИКАТОР ОБЪЕКТА :: = {
        Joint-iso-itu-t (2) страна (16) сша (840) организация (1) правительство (101)
        csor (3) nistAlgorithm (4) aes (1) 5}

   Отправляющие и получающие UA МОГУТ поддерживать другое шифрование ключей.
   алгоритмы.

   Ключи шифрования с симметричным ключом могут быть распределены до того, как сообщения будут отправлены.
   послал.Если отправка и получение UA поддерживаются ранее
   ключи шифрования, тогда они ДОЛЖНЫ назначить KEKIdentifier [RFC5652]
   к ранее распределенному симметричному ключу.

   В качестве альтернативы можно использовать алгоритм согласования ключей для установления
   одноразовый ключ-ключ шифрования. При отправке и получении поддержки UA
   ключевое соглашение, то они ДОЛЖНЫ поддерживать эллиптическую кривую
   Алгоритм Диффи-Хеллмана (ECDH) с использованием эллиптической кривой NIST P-256
   и функция получения ключа ANSI-X9.63-KDF с SHA-256
   алгоритм дайджеста сообщения [RFC5753].При отправке и получении UA
   поддерживают соглашение о ключах, тогда они ДОЛЖНЫ поддерживать алгоритм ECDH
   с использованием curve25519 (X25519) [RFC7748] [RFC8418]. Для удобства,
   (1) идентификатор для алгоритма ECDH с использованием ANSI-X9.63-KDF
   с алгоритмом SHA-256 и (2) идентификатор для X25519
   алгоритм повторяется здесь:

      dhSinglePass-stdDH-sha256kdf-scheme ИДЕНТИФИКАТОР ОБЪЕКТА :: = {
        iso (1) идентифицированная организация (3) certicom (132)
        схемы (1) 11 1}

      id-X25519 ИДЕНТИФИКАТОР ОБЪЕКТА :: = {
        iso (1) идентифицированная организация (3) thawte (101) 110}






Campbell & Housley Standards Track [Страница 8] 

RFC 8591 S / MIME для обмена сообщениями SIP, апрель 2019 г.


4.3. Подписанные и зашифрованные сообщения

   RFC 3261, раздел 23.2 говорит, что когда клиент пользовательского агента (UAC) отправляет
   подписанные и зашифрованные данные, "СЛЕДУЕТ" отправить объект EnvelopedData
   инкапсулировано в сообщении SignedData. По сути, это говорит о том, что
   нужно сначала зашифровать, а затем подписать. Этот документ обновляет RFC 3261.
   сказать, что при отправке подписанного и зашифрованного пользовательского контента в SIP
   MESSAGE, отправляющие UA ДОЛЖНЫ сначала подписать сообщение, и
   затем зашифруйте его. То есть он должен отправить объект SignedData внутри
   объект AuthEnvelopedData.По причинам совместимости
   получатели ДОЛЖНЫ принимать сообщения, подписанные и зашифрованные в любом
   приказ.

4.4. Обработка сертификатов

   Отправка и получение UA ДОЛЖНЫ следовать за обработкой сертификата S / MIME.
   процедуры [RFC8550], за некоторыми исключениями, подробно описанными ниже.

4.4.1. Альтернативное имя субъекта

   И в SIP, и в MSRP личность отправителя сообщения
   обычно выражается как SIP URI.

   Расширение альтернативного имени субъекта используется в качестве предпочтительного средства
   для передачи SIP URI субъекта сертификата.Любой SIP URI
   настоящее ДОЛЖНО быть закодировано с использованием ВЫБОРА uniformResourceIdentifier из
   тип GeneralName, как описано в [RFC5280], раздел 4.2.1.6.
   Поскольку тип SubjectAltName является ПОСЛЕДОВАТЕЛЬНОСТЬЮ GeneralName, несколько
   МОГУТ присутствовать URI.

   МОГУТ использоваться другие методы идентификации субъекта сертификата.

4.4.2. Подтверждение сертификата

   При проверке сертификата принимающие UA ДОЛЖНЫ поддерживать ECDSA.
   с использованием эллиптической кривой NIST P-256 и дайджеста сообщения SHA-256
   алгоритм [RFC5480].Отправляющие и получающие UA МОГУТ поддерживать другую цифровую подпись
   алгоритмы проверки сертификатов.

5. Кодирование передачи

   UA SIP и MSRP всегда могут принимать двоичные данные. Внутренний
   Сущности S / MIME не требуют кодирования base64 [RFC4648].

   И SIP, и MSRP предоставляют 8-битные безопасные транспортные каналы; base64
   кодирование обычно не требуется для внешних объектов S / MIME.



Campbell & Housley Standards Track [Страница 9] 

RFC 8591 S / MIME для обмена сообщениями SIP, апрель 2019 г.


   Однако, если есть вероятность, что сообщение может пересечь 7-битный транспорт
   (например, шлюзы, которые преобразуются в 7-битный транспорт для
   промежуточная передача), кодировка base64 может потребоваться для внешней
   организация.6. Возможности пользовательского агента

   UA для обмена сообщениями может реализовывать подмножество возможностей S / MIME. Четное
   при реализации некоторые функции могут быть недоступны из-за
   конфигурация. Например, UA, у которых нет пользовательских сертификатов.
   не может подписывать сообщения от имени пользователя или расшифровывать зашифрованные
   сообщения, отправленные пользователю. Как минимум, UA, поддерживающий S / MIME
   ДОЛЖЕН иметь возможность проверить подписанное сообщение.

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

   UA SIP и MSRP объявляют о своем уровне поддержки S / MIME посредством
   с указанием их возможности получить "application / pkcs7-mime"
   тип носителя.

   Тот факт, что UA указывает на поддержку "составных / подписанных" носителей.
   type не обязательно подразумевает поддержку S / MIME.UA может
   просто иметь возможность отображать контент с четкой подписью без проверки
   подпись. UA, которые хотят указать возможность проверки
   подписи для сообщений с четкой подписью ДОЛЖНЫ также указывать на поддержку
   "приложение / pkcs7-подпись".

   UA может указать, что он может получать все типы smime с помощью рекламы
   "application / pkcs7-mime" без параметров. Если UA не принимает
   все smime-типы, он рекламирует медиа-тип с соответствующими
   параметры. Если поддерживается более одного типа smime, UA
   включает отдельный экземпляр строки медиа-типа, соответственно
   параметризованный, для каждого.Например, UA, который может получать только подписанные данные, будет рекламировать
   "приложение / pkcs7-mime; smime-type = подписанные данные".

   Сигнализация SIP может разветвляться на несколько пунктов назначения для данного адреса.
   записи (AoR). У пользователя может быть несколько UA с разными
   возможности; способности запомнились из взаимодействия с
   один такой UA может не применяться к другому. (См. Раздел 7.2.)





Campbell & Housley Standards Track [Страница 10] 

RFC 8591 S / MIME для обмена сообщениями SIP, апрель 2019 г.


   UA также могут рекламировать или обнаруживать S / MIME, используя внеполосный
   механизмы.Такие механизмы выходят за рамки этого документа.

7. Использование S / MIME с методом SIP MESSAGE

   Использование S / MIME с методом SIP MESSAGE описано в
   Раздел 11.3 [RFC3428], а также для SIP в целом в Разделе 23
   [RFC3261]. Этот раздел и его дочерние разделы предлагают пояснения.
   для использования S / MIME с методом SIP MESSAGE, а также связанных
   обновления RFC 3261 и 3428.

7.1. Ограничение размера

   Запросы SIP MESSAGE обычно ограничены 1300 октетами. Тот
   ограничение применяется ко всему сообщению, включая оба поля заголовка SIP
   и содержание сообщения.Это связано с возможностью
   фрагментация больших запросов, отправленных по UDP. В общем, это
   трудно быть уверенным, что ни один прокси или другой посредник не перешлет
   Запрос SIP через UDP где-то на пути. Следовательно, S / MIME
   сообщения, отправленные с использованием метода SIP MESSAGE, должны быть минимальными по размеру
   возможный. Сообщения, которые не укладываются в лимит, могут быть отправлены
   используя MSRP.

   Раздел 23.2 [RFC3261] требует, чтобы сообщение SignedData содержало
   сертификат, который будет использоваться для проверки подписи.Чтобы
   уменьшить размер сообщения, этот документ обновляет этот текст, чтобы сказать, что
   сообщение SignedData, отправленное в запросе SIP MESSAGE, ДОЛЖНО содержать
   сертификат, но МОЖЕТ опустить его, если у отправителя есть основания полагать, что
   получатель (1) уже имеет сертификат в своей связке ключей или
   (2) имеет другой метод доступа к сертификату.

7.2. Возможности SIP User Agent

   SIP UA теоретически могут указать поддержку S / MIME, включив
   соответствующий тип или типы носителя в поле заголовка SIP Accept в
   ответ на запрос OPTIONS или в 415 (Unsupported Media
   Type) ответ на SIP-запрос, содержащий неподдерживаемый носитель.
   типа в теле.К сожалению, этот подход может быть ненадежным.
   в общем случае. В случае, если нисходящий прокси-сервер SIP разветвляется
   ОПЦИИ или другой запрос, не связанный с ПРИГЛАШЕНИЕМ, к нескольким серверам пользовательских агентов
   (UAS), этот прокси будет пересылать только «лучший» ответ. Если
   у получателя несколько устройств, отправитель может узнать только
   возможности устройства, отправившего переадресованный ответ. Слепо
   доверие к этой информации может привести к отправке сообщений S / MIME
   для UA, которые его не поддерживают, что в лучшем случае сбивает с толку и
   в худшем случае вводит получателя в заблуждение.Campbell & Housley Standards Track [Страница 11] 

RFC 8591 S / MIME для обмена сообщениями SIP, апрель 2019 г.


   UA могут использовать структуру возможностей UA [RFC3840] для
   указать поддержку. Однако для этого потребуется регистрация
   одного или нескольких тегов мультимедийных функций с IANA.

   UA МОГУТ использовать другие внеполосные методы, чтобы указать свой уровень
   поддержка S / MIME.

7.3. Случаи отказа

   Раздел 23.2 [RFC3261] требует, чтобы получатель SIP
   запрос, который включает в себя часть тела неподдерживаемого типа мультимедиа и
   Поле заголовка Content-Disposition "обрабатывает" параметр "обязательный"
   вернуть ответ 415 (неподдерживаемый тип носителя).Учитывая, что SIP
   СООБЩЕНИЕ существует только для доставки содержимого в
   тело, то к верхней части тела разумно относиться как всегда
   обязательный. Однако [RFC3428] не делает такого утверждения. Этот документ
   обновляет раздел 11.3 [RFC3428], добавляя утверждение, что UAC
   который получает запрос SIP MESSAGE с неподдерживаемым типом носителя
   ДОЛЖЕН вернуть ответ 415.

   В разделе 23.2 [RFC3261] говорится, что если получатель получает S / MIME
   тело зашифровано с использованием неправильного сертификата, оно ДОЛЖНО возвращать SIP 493
   (Неразборчиво) ответ и ДОЛЖЕН отправить действительный сертификат в этом
   отклик.На практике это не всегда возможно для SIP MESSAGE.
   Запросы. БПЛА может не расшифровывать сообщение, пока пользователь
   готов ее прочитать. Сообщения могут быть доставлены в хранилище сообщений или
   отправлено через службу промежуточной пересылки. Этот документ обновляет RFC 3261.
   чтобы сказать, что БПЛА ДОЛЖЕН вернуть ответ SIP 493, если он
   немедленно пытается расшифровать сообщение и определяет, что
   сообщение было зашифровано неверным сертификатом. Однако это МОЖЕТ
   вернуть 200-классный ответ, если расшифровка отложена.8. Использование S / MIME с MSRP

   MSRP имеет функции, которые взаимодействуют с использованием S / MIME. В
   в частности, возможность отправлять сообщения кусками, возможность
   отправлять сообщения неизвестного размера и использовать SDP для указания
   Поддержка медиа-типов создает соображения по использованию S / MIME.

8.1. Разбивка

   MSRP позволяет разбивать сообщение на «куски» для передачи.
   В этом контексте термин «сообщение» относится ко всему сообщению, которое
   один пользователь может отправить другому. Кусок - это фрагмент этого
   сообщение, отправленное в одном запросе MSRP SEND.Все куски, которые
   составлять конкретное сообщение, разделять одно и то же значение идентификатора сообщения.





Campbell & Housley Standards Track [Страница 12] 

RFC 8591 S / MIME для обмена сообщениями SIP, апрель 2019 г.


   Отправляющий UA может разбить сообщение на куски, которые получающий
   UA соберется заново, чтобы сформировать полное сообщение. Посредники, такие
   поскольку реле MSRP [RFC4976] могут разбивать куски на более мелкие или
   может снова собрать куски в более крупные; поэтому сообщение
   полученный получателем может быть разбит на другое количество
   фрагментов, чем было отправлено получателем.Посредники также могут
   привести к тому, что блоки будут получены в порядке, отличном от отправленного.

   Отправитель ДОЛЖЕН применять любые операции S / MIME ко всему сообщению.
   прежде чем разбить его на куски. Точно так же получатель должен
   повторно собрать сообщение из его фрагментов перед дешифровкой,
   проверка подписи и т. д.

   Фрагменты MSRP выделяются конечной строкой. Конечная линия включает
   семь дефисов, 64-битное случайное значение, взятое из начальной строки, и
   флаг продолжения. MSRP требует, чтобы UA-отправитель сканировал данные, чтобы
   отправлено в определенном фрагменте, чтобы гарантировать, что конечная строка не
   случайно возникают как часть данных.Это сканирование происходит на
   кусок, а не все сообщение; следовательно, это должно произойти после
   отправитель применяет любые операции S / MIME.

8.2. Потоковые данные

   MSRP позволяет режим работы, при котором UA отправляет некоторые фрагменты
   сообщение до того, как узнать полную длину сообщения. За
   Например, отправитель может отправлять потоковые данные через MSRP как один
   сообщение, даже если он не знает полной длины этих данных в
   продвигать. Этот режим несовместим с S / MIME, поскольку отправляющий UA
   должен применять операции S / MIME ко всему сообщению до
   разбивая его на куски.Поэтому при отправке сообщения в формате S / MIME отправитель
   ДОЛЖЕН включать поле заголовка Byte-Range для каждого фрагмента, включая
   первый кусок. Поле заголовка Byte-Range ДОЛЖНО включать общее
   длина сообщения.

   Более высокий уровень может выбрать разбиение таких потоковых данных на серию
   сообщений до применения операций S / MIME, чтобы каждое
   Фрагмент отображается как отдельное (отдельное) сообщение S / MIME в MSRP.
   Такие механизмы выходят за рамки этого документа.Campbell & Housley Standards Track [Страница 13] 

RFC 8591 S / MIME для обмена сообщениями SIP, апрель 2019 г.


8.3. Указывая на поддержку S / MIME

   UA, который поддерживает эту спецификацию, ДОЛЖЕН явно включать
   соответствующий тип или типы носителя в атрибуте "accept-types" в
   любое предложение SDP или ответ, в котором предлагается MSRP. Это МОЖЕТ указывать на то, что это
   требует оболочки S / MIME для всех сообщений, помещая соответствующие
   Типы носителей S / MIME в атрибуте accept-types и размещение всех
   другие поддерживаемые типы носителей в атрибуте «accept-wrapped-types».Для обратной совместимости отправитель МОЖЕТ обращаться с партнером, который включает
   звездочку ("*") в атрибуте "accept-types" как потенциально
   поддержка S / MIME. Если одноранговый узел возвращает MSRP 415 (тип MIME не
   понял) ответ на попытку отправить сообщение S / MIME,
   отправитель должен относиться к одноранговому узлу как к не поддерживающему S / MIME для
   продолжительность сеанса, как указано в разделе 7.3.1 [RFC4975].

   Хотя эти атрибуты SDP позволяют конечной точке выражать поддержку
   определенные типы носителей только в том случае, если они завернуты в конверт указанного типа,
   он не позволяет выражать более сложные структуры.За
   Например, конечная точка может сказать, что она поддерживает text / plain и
   text / html, но только когда внутри application / pkcs7 или message / cpim
   контейнер, но он не может выражать требование, чтобы типы листьев
   всегда содержаться в контейнере application / pkcs7, вложенном в
   контейнер сообщения / cpim. Это имеет значение для использования S / MIME.
   в формате message / cpim. (См. Раздел 9.1.)

   MSRP позволяет использовать несколько режимов отчетности, которые обеспечивают разные уровни
   Обратная связь. Если отправитель включает поле заголовка Failure-Report с
   значение «нет», он не будет получать отчеты об ошибках.Этот режим
   не следует использовать небрежно, так как такой отправитель никогда не увидит
   415, как описано выше, и у него не будет возможности узнать, что
   получатель не смог обработать тело S / MIME.

8.4. URI MSRP

   URI MSRP недолговечны. Конечные точки НЕ ДОЛЖНЫ использовать URI MSRP для
   идентифицировать сертификаты или вставлять URI MSRP в тему сертификата
   Поля альтернативного имени. Когда сеансы MSRP согласовываются с использованием SIP
   [RFC3261] вместо этого используются SIP AoR одноранговых узлов.

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







Campbell & Housley Standards Track [Страница 14] 

RFC 8591 S / MIME для обмена сообщениями SIP, апрель 2019 г.


8.5. Случаи отказа

   Успешная доставка сообщения S / MIME не означает, что
   получатель успешно расшифровал содержимое или подтвердил
   подпись.Расшифровка и / или проверка может произойти не сразу на
   квитанция, так как получатель не может сразу просмотреть сообщение,
   и UA может решить не пытаться расшифровать или проверить до тех пор, пока
   пользователь запрашивает это.

   Точно так же успешная доставка данных в оболочке S / MIME не
   собственный, указывает, что получатель поддерживает прилагаемый носитель
   тип. Если одноранговый узел только неявно указал на поддержку вложенного
   тип мультимедиа с помощью подстановочного знака в "accept-types" или
   атрибуты SDP "accept-wrapped types", он не может расшифровать сообщение
   вовремя, чтобы отправить ответ 415.9. Взаимодействие S / MIME с другими функциями обмена сообщениями SIP.

9.1. Общий профиль для обмена мгновенными сообщениями

   Общий профиль для обмена мгновенными сообщениями (CPIM) [RFC3860] определяет
   абстрактная служба обмена сообщениями с целью создания шлюзов
   между различными протоколами обмена сообщениями, которые могут мгновенно передавать
   сообщения без изменений. Метод SIP MESSAGE и MSRP были
   изначально разработан для сопоставления с абстракциями CPIM. Однако на
   на момент написания этой статьи шлюзы, совместимые с CPIM, не были развернуты.Насколько известно авторам, никакие другие протоколы обмена мгновенными сообщениями явно не использовались.
   сопоставлен с CPIM.

   CPIM также определяет схему URI абстрактного обмена сообщениями «im:». По состоянию на
   На момент написания этой статьи схема «im:» не использовалась широко.

   Формат сообщения CPIM [RFC3862] позволяет UA прикреплять
   метаданные, не зависящие от транспорта, для произвольного содержимого MIME. Формат был
   разработан как формат канонизации, позволяющий подписанным данным пересекать
   конвертирующие протокол шлюзы без потери метаданных, необходимых для
   проверить подпись.Хотя обычно он для этого не используется
   цель, он использовался для других приложений метаданных - для
   например, IMDN [RFC5438] и многосторонний чат MSRP [RFC7701].

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



Campbell & Housley Standards Track [Страница 15] 

RFC 8591 S / MIME для обмена сообщениями SIP, апрель 2019 г.


   подписи, которые покрывают метаданные CPIM, в то время как последнее невозможно
   если метаданные зашифрованы. Клиенты, предназначенные для использования в таких
   сети МОГУТ применять сквозные подписи и шифрование
   операции только с полезной нагрузкой CPIM, оставляя метаданные CPIM
   незащищен от осмотра и модификации.UA, которые поддерживают
   S / MIME и CPIM ДОЛЖНЫ иметь возможность проверять подписи и расшифровывать
   охватывают данные оба (1), когда эти операции применяются к
   все тело CPIM и (2) когда они применяются только к CPIM
   полезная нагрузка. Это означает, что приемник должен быть гибким в
   Синтаксический анализ документа MIME и что он не может делать предположений, что
   Части тела, защищенные S / MIME, всегда будут в одном и том же положении или
   уровень в полезной нагрузке сообщения.

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

9.2. Уведомления об отправке мгновенных сообщений

   Механизм IMDN [RFC5438] позволяет как конечным точкам, так и посредникам
   серверы приложений для запроса и создания доставки
   уведомления. Использование S / MIME не влияет строго на сквозное
   использование IMDN. Механизм IMDN рекомендует, чтобы устройства
   подписывать уведомления о доставке.Далее требуется
   что уведомления о доставке, которые являются результатом зашифрованных сообщений, также
   быть зашифрованным.

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

   Такие посредники не смогут читать зашифрованные данные из конца в конец.
   сообщения, чтобы интерпретировать запросы уведомления о доставке.Посредники, вставляющие информацию в сквозные подписанные
   сообщения приведут к сбою проверки подписи. (Видеть
   Раздел 9.1.)










Campbell & Housley Standards Track [Страница 16] 

RFC 8591 S / MIME для обмена сообщениями SIP, апрель 2019 г.


10. Примеры

   В следующих разделах показаны примеры сообщений S / MIME в SIP и
   Рекомендуемая производителем розничная цена. Примеры включают теги «[start-hex]» и «[end-hex]», чтобы
   обозначают двоичное содержимое, показанное в шестнадцатеричном формате.Теги не являются частью
   фактическое сообщение и не учитываются в заголовке Content-Length
   значения поля.

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

   В состав персонажей входит Алиса с SIP AoR
   «[email protected]» и Боб с AoR SIP «[email protected]».

   В Приложении A показано подробное содержание каждого тела S / MIME.

10.1. Подписанное сообщение в SIP, включая сертификат отправителя

   На рисунке 1 показано сообщение, подписанное Алисой.Этот орган использует
   Тип носителя "application / pkcs7-mime" с параметром smime-type
   значение "подписанных данных".

   Тело S / MIME включает сертификат подписи Алисы. Несмотря на то
   исходное содержание сообщения довольно короткое и содержит только минимальный SIP
   поля заголовка включены, общий размер сообщения приближается к
   максимально допустимый для метода SIP MESSAGE, если UAC не заранее
   знание того, что все SIP-переходы будут использовать транспорт с контролируемой перегрузкой
   протоколы. Сообщение, включающее все поля заголовка SIP, которые
   обычно используются в некоторых развертываниях SIP, вероятно, превышают
   предел.Campbell & Housley Standards Track [Страница 17] 

RFC 8591 S / MIME для обмена сообщениями SIP, апрель 2019 г.


   СООБЩЕНИЕ sip: [email protected] SIP / 2.0
   Через: SIP / 2.0 / TCP alice-pc.example.com; branch = z9hG4bK776sgdkfie
   Максимальное количество нападающих: 70
   От: sip: [email protected]; tag = 49597
   Кому: sip: [email protected]
   Call-ID: [email protected]
   CSeq: 1 СООБЩЕНИЕ
   Content-Transfer-Encoding: двоичный
   Тип содержимого: приложение / pkcs7-mime; smime-type = подписанные данные;
                 name = "smime.p7m "
   Content-Disposition: вложение; filename = "smime.p7m"
   Длина содержимого: 762

   [начало-шестнадцатеричный]
   308202f606092a864886f70d010702a08202e7308202e3020101310d300b0609
   608648016503040201305306092a864886f70d010701a0460444436f6e74656e
   742d547970653a20746578742f706c61696e0d0a0d0a576174736f6e2c20636f
   6d652068657265202d20492077616e7420746f2073656520796f752e0d0aa082
   016b308201673082010da003020102020900b8793ec0e4c21530300a06082a86
   48ce3d040302302631143012060355040a0c0b6578616d706c652e636f6d310e
   300c06035504030c05416c696365301e170d3137313231393233313230355a17
   0d3138313231393233313230355a302631143012060355040a0c0b6578616d70
   6c652e636f6d310e300c06035504030c05416c6963653059301306072a8648ce
   3d020106082a8648ce3d03010703420004d87b54729f2c22feebd9ddba0efa40
   642297a6093887a4dae7990b23f87fa7ed99db8cf5a314f2ee64106ef1ed61db
   fc0a4b91c953cbd022a751b914807bb794a324302230200603551d1104193017
   86157369703a616c696365406578616d706c652e636f6d300a06082a8648ce3d
   040302034800304502207879be1c27f846276fdf15e333e53c6f17a757388a02
   cb7b8ae481c1641ae7a00ff99cd9c94076c82b02fea3b1350179a4b7752
   e16fa30a3f9ab29650b0e2818931820109308201050201013033302631143012
   060355040a0c0b6578616d706c652e636f6d310e300c06035504030c05416c69
   6365020900b8793ec0e4c21530300b0609608648016503040201a06930180609
   2a864886f70d010
0b06092a864886f70d010701301c06092a864886f70d 010905310f170d3139303132363036313335345a302f06092a864886f70d0109 0431220420ef778fc940d5e6dc2576f47a599b3126195a9f1a227adaf35fa22c 050d8d195a300a06082a8648ce3d04030204473045022005fdc2b55b0f444a46 be468dfc7ef3b7de30019ef0952a223e8521890b35bb4e02210090e43a9d9846 cf2af8159c5c0ef48848fa2f39f998b1bb99b52a6fc6c776f2c8 [конец шестнадцатеричного] Рисунок 1: Подписанное сообщение в SIP Campbell & Housley Standards Track [Страница 18]

RFC 8591 S / MIME для обмена сообщениями SIP, апрель 2019 г.


10.2. Подписанное сообщение в SIP без сертификата

   На рисунке 2 показано то же сообщение от Алисы без встроенного
   сертификат. Более короткая общая длина сообщения может быть больше
   управляемый.

   СООБЩЕНИЕ sip: [email protected] SIP / 2.0
   Через: SIP / 2.0 / TCP alice-pc.example.com; branch = z9hG4bK776sgdkfie
   Максимальное количество нападающих: 70
   От: sip: [email protected]; tag = 49597
   Кому: sip: [email protected]
   Call-ID: [email protected]
   CSeq: 1 СООБЩЕНИЕ
   Content-Transfer-Encoding: двоичный
   Тип содержимого: приложение / pkcs7-mime; smime-type = подписанные данные;
                 name = "smime.p7m "
   Content-Disposition: вложение; filename = "smime.p7m"
   Длина содержимого: 395

   [начало-шестнадцатеричный]
   3082018706092a864886f70d010702a082017830820174020101310d300b0609
   608648016503040201305306092a864886f70d010701a0460444436f6e74656e
   742d547970653a20746578742f706c61696e0d0a0d0a576174736f6e2c20636f
   6d652068657265202d20492077616e7420746f2073656520796f752e0d0a3182
   0109308201050201013033302631143012060355040a0c0b6578616d706c652e
   636f6d310e300c06035504030c05416c696365020900b8793ec0e4c21530300b
   0609608648016503040201a069301806092a864886f70d010
0b06092a86 4886f70d010701301c06092a864886f70d010905310f170d3139303132363036 313335345a302f06092a864886f70d010220420ef778fc940d5e6dc2576 f47a599b3126195a9f1a227adaf35fa22c050d8d195a300a06082a8648ce3d04 03020447304502203607275592d30c8c5a931041a01804d60c638ac9a8080918 87172a0887c8d4aa022100cd9e14bd21817336e9052fe590af2e2bcde16dd3e9 48d0f5f78a969e26382682 [конец шестнадцатеричного] Рисунок 2: Подписанное сообщение в SIP без сертификата Campbell & Housley Standards Track [Страница 19]

RFC 8591 S / MIME для обмена сообщениями SIP, апрель 2019 г.


10.3. Подписанное и зашифрованное сообщение MSRP в одном блоке

   На рисунке 3 показано подписанное и зашифрованное сообщение от Боба Алисе, отправленное.
   через MSRP.

   MSRP dsdfoe38sd ОТПРАВИТЬ
   Путь к пути: msrp: //alicepc.example.com: 7777 / iau39soe2843z; tcp
   Исходный путь: msrp: //bobpc.example.org: 8888 / 9di4eae923wzd; tcp
   Идентификатор сообщения: 456so39s
   Байт-диапазон: 1-1940 / 1940
   Content-Disposition: вложение; filename = "smime.p7m"
   Тип содержимого: приложение / pkcs7-mime; smime-type = auth-enveloped-data;
                 name = "smime.p7m "

   [начало-шестнадцатеричный]
   308207

b2a864886f70d0109100117a082077f3082077b0201003182024f 3082024b0201003033302631143012060355040a0c0b6578616d706c652e636f 6d310e300c06035504030c05416c696365020
f50bb70bd5c40e300d0609 2a864886f70d010101050004820200759a61b4ddf1f1af24668005635e476110 fa2723c1b9e45484b6d33e8387de967dc5e0cafb35571a56a1975cb550e7be31 c131da80fb731024845babb8d64cac26040424d9330561c843999415dd644b3c ad95072f71451393c99f282c4883bd0ccc5dd54b931464e00a6e55e592c51a68 de1062516ec7d3ca8e764bb8ac789a88377765ef8dc36c0a6ed3ecae5285cac6 a29d5059445719a1bdcf906e0ff37e2c2ef0f4ec6225100cc062e1c748963bbc 88b8e3dfcf714073729dd5c7583e758acf3d186f2fa417be22c37c9a76c6b427 29aad27f73ae44ac98474d1eeb48948c12a403d0b3ce08a218d6af456924897c c5c9664f6dfeb3f18141158dfc3b84090aa60380aa865137e1699c5c81974167 9d7a3c90ba79e6d7d5c8d89bb54a667423e43b0b7d6f78c0b4ab67bc343662a6 35fe595f1149c53950cac2e0ba318c227e6f76a8d940400fd3d3ea1c8ecea003 dcce2f1fb00f5cea335de1303fcbf93d8e1cbfd682f19beb624bacd1d7b8f580 f114a13b890894fb4044a5daa764b7f8c5ff92949452b35aeb9639b8ad63c051 5c95ccc6f823c2201067ea2262413fef397d48f7b6143f842ae8e1a48cad3ae0 1abaa3cf9ee7e36620e05cca0611bfac00eef1a498f2d259b9f0f7da83ef6f1b 061f387c2dc48c8b5dbaca862308f32f47925165c9e5ebb467799884918dd697 b447f4c407989b889b0c2e9580af783082050f06092a864886f70d010701301e 06096086480165030401063011040c4d8757222eac5294117f0c120201108082 04e0fe2fb3de0bf06998c39bf4a952fabf8b0fee3d7e2e85181aecf1a89e1a2e decd9404885612dfc6984334d8602b7749b2504e45f57c3b066626b0fc746236 1eec267c560139be5cd286a2af9696cf51852278e52c3818cab0a68c598de4fc e14a333884e4de5ddf57edd78867027a31e4a7c0c0299144c5de6bae39699e70 0e057eb0f0dad73b8b369f42eb321b41538781d982a11a0b3943ac10c97b54ee b73b38ec131afc5610e373487274d69cafa9541

6c64f6962d42eb33f904 1a4ae11b88dc6958d53df50b8bb52aa35e2299885d0aae416b86f0a88d0eb7a9 81dbb283e8b94e9d50bf6265c2348a18a169aacb5a37a529bda2f9cb10efddcf 14231095d87964637bd33fb13c68b4cff9a1906960c1ea2301d325b7a15c5829 f3ea038f24df6b23180377d37131f75db18f41f9d85b653dfa46bf2617126326 ccf1cb833457752352c8417a094484d7b64bcf51b26a9beb3a0ed4b9caf1bd23 c690c654f7eb9ce9852e2f6d068eef8ba33bc6c4dddca7aef4d3574737d7c4dc Campbell & Housley Standards Track [Страница 20]


RFC 8591 S / MIME для обмена сообщениями SIP, апрель 2019 г.


   1e93770d8f4f22dea61d73083c32c4038c1eb3dd3383a89a8795e241c2ed7cb6
   80758c041069489860fc9f490e85236072548b3249698f99953acf1ec658b7aa
   85e554c449701a6d4b039ed103dc458df4b29cb04b8cedd540c84348da79c186
   56d5188f9f3a9e4b9b840c70664b
c60b7ac984e918d48a09dbddfb281fc
   862510db59d9fa9dc93f10f9c6d7bef72931d184cad7ac13c1a5295fc89fe3bb
   7eb8e02085a828c5a138786e607ade4f5e8d4115909209ba878a79305a5316c2
   2229e42b886d06481c8473f9d51269e2af6341bce20f768e860d7784ed46150e
   04ff50cd209c5b127511369fe06bc4aa9a72d8f1fe4fcf0866d664b365ffa86e
   8c1b43e7a9212aecc16ca350a28efae25fac054dd934bfe7e5fa4f753aa41596
   8c7ebec439e0ac0270b4874a068d22484c09d9e8abe17f1372b4b2f65f1148e8
   933eda92e5d1774564963b391c3bbd9f1c27ffe36f832e05155fc39ee6652fa7
   b4188975ec5c67b32c9f213c8ac6b8e132a5a7c3bf74f016405cd8c201d10521
   93e186d44358de388d73211ba2f1792f3cfeb9bbde7211d26f56ab06e11ccc9c
   cde2b88cd8373773eafc37fd85b7a7a2bcaec752e617d6e01c02b86e9d9a40f3
   20462c5d66f8351716dcd6014bdf30a60f75fc0631c920845ed8c0bad35ddf19
   84f2241cd3b529dc1028845f8089543df4f1441ede36b1bf31af5afc8c2b708d
   50b645d4e7db88648c3eefe14765158fb0e8d3bb53ddcbe26d7124c6e1d992f8
   3230aa953376ee8c68109568e8571f0c9bbda48f4df306fe747f371175148f31
   832767cd766cf07b450cbf62cad2a7bd71f1f88233f116a1a7f3caf12f34bcf4
   0d21e79ffc9827221b68b080ff03ad782d6d6d07871676f798943e54f13fd75c
   89c0b4263bf10f56243f9e72ef3b3899a539d9a3ac5be2b69400a3cf8d196c5c
   ed697b2ed803b987a5ee85c5095b48da7a5b03b47e2b9fe4cd4bc3098e864e0c
   e7d467da99cd7f3a9e947b5eea77f7a6be16c8c7e9e0decc1ff132559c234321
   7b9c2950386e85d2942121086cdfa19658195be6d7f86bca9881b695082964f1
   2e7cf801025d6792c6882409414d703321ec83abd698d68956118713a0ff1272
   acbc9a6d148900c74c16921df9b38f29ec46d4f10060fffe5e36bbbacaf2d1ba
   d7dd057ed3e30ebcd69083f9d3a2a26ef90b751d6a1adfa0590db19da107cf3e
   a8db0410f6ffc6e1aef19cd23d985a921976352d
   [конец шестнадцатеричного]
   ------- dsdfoe38sd $

              Рисунок 3: Подписанное и зашифрованное сообщение в MSRP

10.4. Зашифрованное и подписанное MSRP сообщение, отправляемое несколькими блоками.

   На рисунке 4 показано то же сообщение, что и на рисунке 3, за исключением того, что
   сообщение разбито на два блока. Операции S / MIME были
   выполняется до разбиения сообщения на части.

   MSRP d93kswow ОТПРАВИТЬ
   Путь к пути: msrp: //alicepc.example.com: 7777 / iau39soe2843z; tcp
   Исходный путь: msrp: //bobpc.example.org: 8888 / 9di4eae923wzd; tcp
   Идентификатор сообщения: 12339sdqwer
   Байт-диапазон: 1-960 / 1940
   Content-Disposition: вложение; filename = "smime.p7m "
   Тип содержимого: приложение / pkcs7-mime; smime-type = enveloped-data;
                 name = "smime.p7m"




Campbell & Housley Standards Track [Страница 21] 

RFC 8591 S / MIME для обмена сообщениями SIP, апрель 2019 г.


   [начало-шестнадцатеричный]
   308207

b2a864886f70d0109100117a082077f3082077b0201003182024f 3082024b0201003033302631143012060355040a0c0b6578616d706c652e636f 6d310e300c06035504030c05416c696365020
f50bb70bd5c40e300d0609 2a864886f70d010101050004820200759a61b4ddf1f1af24668005635e476110 fa2723c1b9e45484b6d33e8387de967dc5e0cafb35571a56a1975cb550e7be31 c131da80fb731024845babb8d64cac26040424d9330561c843999415dd644b3c ad95072f71451393c99f282c4883bd0ccc5dd54b931464e00a6e55e592c51a68 de1062516ec7d3ca8e764bb8ac789a88377765ef8dc36c0a6ed3ecae5285cac6 a29d5059445719a1bdcf906e0ff37e2c2ef0f4ec6225100cc062e1c748963bbc 88b8e3dfcf714073729dd5c7583e758acf3d186f2fa417be22c37c9a76c6b427 29aad27f73ae44ac98474d1eeb48948c12a403d0b3ce08a218d6af456924897c c5c9664f6dfeb3f18141158dfc3b84090aa60380aa865137e1699c5c81974167 9d7a3c90ba79e6d7d5c8d89bb54a667423e43b0b7d6f78c0b4ab67bc343662a6 35fe595f1149c53950cac2e0ba318c227e6f76a8d940400fd3d3ea1c8ecea003 dcce2f1fb00f5cea335de1303fcbf93d8e1cbfd682f19beb624bacd1d7b8f580 f114a13b890894fb4044a5daa764b7f8c5ff92949452b35aeb9639b8ad63c051 5c95ccc6f823c2201067ea2262413fef397d48f7b6143f842ae8e1a48cad3ae0 1abaa3cf9ee7e36620e05cca0611bfac00eef1a498f2d259b9f0f7da83ef6f1b 061f387c2dc48c8b5dbaca862308f32f47925165c9e5ebb467799884918dd697 b447f4c407989b889b0c2e9580af783082050f06092a864886f70d010701301e 06096086480165030401063011040c4d8757222eac5294117f0c120201108082 04e0fe2fb3de0bf06998c39bf4a952fabf8b0fee3d7e2e85181aecf1a89e1a2e decd9404885612dfc6984334d8602b7749b2504e45f57c3b066626b0fc746236 1eec267c560139be5cd286a2af9696cf51852278e52c3818cab0a68c598de4fc e14a333884e4de5ddf57edd78867027a31e4a7c0c0299144c5de6bae39699e70 0e057eb0f0dad73b8b369f42eb321b41538781d982a11a0b3943ac10c97b54ee b73b38ec131afc5610e373487274d69cafa9541

6c64f6962d42eb33f904 1a4ae11b88dc6958d53df50b8bb52aa35e2299885d0aae416b86f0a88d0eb7a9 81dbb283e8b94e9d50bf6265c2348a18a169aacb5a37a529bda2f9cb10efddcf 14231095d87964637bd33fb13c68b4cff9a1906960c1ea2301d325b7a15c5829 [конец шестнадцатеричного] ------- d93kswow + MSRP op2nc9a ОТПРАВИТЬ Путь к пути: msrp: // alicepc.example.com:8888/9di4eae923wzd;tcp Исходный путь: msrp: //bobpc.example.org: 7654 / iau39soe2843z; tcp Идентификатор сообщения: 12339sdqwer Байт-диапазон: 961-1940 / 1940 Content-Disposition: вложение; filename = "smime.p7m" Тип содержимого: приложение / pkcs7-mime; smime-type = enveloped-data; name = "smime.p7m" Campbell & Housley Standards Track [Страница 22]


RFC 8591 S / MIME для обмена сообщениями SIP, апрель 2019 г.


   [начало-шестнадцатеричный]
   f3ea038f24df6b23180377d37131f75db18f41f9d85b653dfa46bf2617126326
   ccf1cb833457752352c8417a094484d7b64bcf51b26a9beb3a0ed4b9caf1bd23
   c690c654f7eb9ce9852e2f6d068eef8ba33bc6c4dddca7aef4d3574737d7c4dc
   1e93770d8f4f22dea61d73083c32c4038c1eb3dd3383a89a8795e241c2ed7cb6
   80758c041069489860fc9f490e85236072548b3249698f99953acf1ec658b7aa
   85e554c449701a6d4b039ed103dc458df4b29cb04b8cedd540c84348da79c186
   56d5188f9f3a9e4b9b840c70664b
c60b7ac984e918d48a09dbddfb281fc
   862510db59d9fa9dc93f10f9c6d7bef72931d184cad7ac13c1a5295fc89fe3bb
   7eb8e02085a828c5a138786e607ade4f5e8d4115909209ba878a79305a5316c2
   2229e42b886d06481c8473f9d51269e2af6341bce20f768e860d7784ed46150e
   04ff50cd209c5b127511369fe06bc4aa9a72d8f1fe4fcf0866d664b365ffa86e
   8c1b43e7a9212aecc16ca350a28efae25fac054dd934bfe7e5fa4f753aa41596
   8c7ebec439e0ac0270b4874a068d22484c09d9e8abe17f1372b4b2f65f1148e8
   933eda92e5d1774564963b391c3bbd9f1c27ffe36f832e05155fc39ee6652fa7
   b4188975ec5c67b32c9f213c8ac6b8e132a5a7c3bf74f016405cd8c201d10521
   93e186d44358de388d73211ba2f1792f3cfeb9bbde7211d26f56ab06e11ccc9c
   cde2b88cd8373773eafc37fd85b7a7a2bcaec752e617d6e01c02b86e9d9a40f3
   20462c5d66f8351716dcd6014bdf30a60f75fc0631c920845ed8c0bad35ddf19
   84f2241cd3b529dc1028845f8089543df4f1441ede36b1bf31af5afc8c2b708d
   50b645d4e7db88648c3eefe14765158fb0e8d3bb53ddcbe26d7124c6e1d992f8
   3230aa953376ee8c68109568e8571f0c9bbda48f4df306fe747f371175148f31
   832767cd766cf07b450cbf62cad2a7bd71f1f88233f116a1a7f3caf12f34bcf4
   0d21e79ffc9827221b68b080ff03ad782d6d6d07871676f798943e54f13fd75c
   89c0b4263bf10f56243f9e72ef3b3899a539d9a3ac5be2b69400a3cf8d196c5c
   ed697b2ed803b987a5ee85c5095b48da7a5b03b47e2b9fe4cd4bc3098e864e0c
   e7d467da99cd7f3a9e947b5eea77f7a6be16c8c7e9e0decc1ff132559c234321
   7b9c2950386e85d2942121086cdfa19658195be6d7f86bca9881b695082964f1
   2e7cf801025d6792c6882409414d703321ec83abd698d68956118713a0ff1272
   acbc9a6d148900c74c16921df9b38f29ec46d4f10060fffe5e36bbbacaf2d1ba
   d7dd057ed3e30ebcd69083f9d3a2a26ef90b751d6a1adfa0590db19da107cf3e
   a8db0410f6ffc6e1aef19cd23d985a921976352d
   [конец шестнадцатеричного]
   ------- op2nc9a $

           Рисунок 4: Подписанное, зашифрованное и разбитое на части сообщение MSRP

11.Соображения IANA

   В этом документе нет действий IANA.

12. Соображения безопасности

   Вопросы безопасности для S / MIME [RFC8550] [RFC8551] и
   Применяются эллиптические кривые в CMS [RFC5753]. Безопасность, связанная с S / MIME
   соображения для SIP [RFC3261], SIP MESSAGE [RFC3428] и MSRP
   Применяются [RFC4975].




Campbell & Housley Standards Track [Страница 23] 

RFC 8591 S / MIME для обмена сообщениями SIP, апрель 2019 г.


   Соображения безопасности для алгоритмов, рекомендуемых в этом
   документ также применяется; см. [RFC3565], [RFC5480], [RFC5753], [RFC5754],
   [RFC7748], [RFC8032], [RFC8418] и [RFC8419].В этом документе предполагается, что проверка сертификата конечного объекта
   предоставляется цепочкой доверия к центру сертификации (ЦС), используя
   инфраструктура открытого ключа. Соображения безопасности от
   Применяются [RFC5280]. Однако возможны и другие методы проверки.
   - например, отправка подписанного отпечатка пальца для конечного объекта в
   SDP. Связь между этой работой и обсуждаемыми методами
   в [RFC8224] и [RTP-Sec] выходят за рамки этого документа.

   При сопоставлении сертификата конечного объекта с отправителем или получателем
   identity, используются соответствующие SIP AoR.Обычно это
   соответствуют полям заголовка SIP From и To. Некоторые UA могут извлекать
   идентификатор отправителя из SIP AoR в других полях заголовка - например,
   P-Asserted-Identity [RFC3325]. В общем, БАС надо сравнивать
   сертификат удостоверения личности, на который он полагается - например,
   для отображения конечному пользователю или сравнения с фильтрацией сообщений
   правила.

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

   Мобильный обмен сообщениями обычно представляет собой онлайн-приложение; онлайн
   Проверка отзыва сертификатов обычно возможна.

   S / MIME обычно не защищает заголовки SIP или MSRP. Пока это
   обычно защищает заголовок CPIM, некоторые поля заголовка CPIM могут
   не подлежат защите, если отправитель исключает их из зашифрованных или
   подписанная часть сообщения.(См. Раздел 9.1.) Определенные сообщения
   услуги - например, основанные на RCS - могут включать
   посредники, которые прикрепляют метаданные к пользовательским сообщениям в
   форма полей заголовка SIP, MSRP или CPIM. Эти метаданные могут
   возможно раскрыть информацию третьим лицам, которую отправитель может





Campbell & Housley Standards Track [Страница 24] 

RFC 8591 S / MIME для обмена сообщениями SIP, апрель 2019 г.


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

   Сообщения MSRP, разбитые на блоки, должны быть повторно собраны получателем.
   перед расшифровкой или проверкой подписей. (См. Раздел 8.1.)
   Раздел 14.5 [RFC4975] описывает потенциальный отказ в обслуживании.
   атака, при которой злоумышленник помещает большие значения в заголовок Byte-Range
   поле. Реализации должны проверить эти значения перед
   выделение памяти для повторной сборки.Изменение зашифрованного текста в EnvelopedData может остаться незамеченным, если
   аутентификация также не используется, что имеет место при отправке
   EnvelopedData без упаковки в SignedData или включения
   SignedData внутри него. Это одна из причин перехода от
   EnvelopedData в AuthEnvelopedData в качестве аутентифицированного шифрования
   алгоритмы обеспечивают аутентификацию без необходимости в SignedData
   слой.

   Атака на S / MIME-реализации HTML и multipart / mixed
   сообщения выделяются в [Efail].Чтобы избежать этой атаки, клиенты
   ДОЛЖЕН гарантировать, что тип содержимого text / html является полным HTML.
   документ. Клиенты ДОЛЖНЫ относиться к каждой из частей
   multipart / mixed конструкция как происходящая из разного происхождения. Клиенты
   ДОЛЖЕН обрабатывать каждую зашифрованную или подписанную часть сообщения MIME как
   из разных источников как из незащищенного контента, так и из каждого
   разное.

13. Ссылки

13.1. Нормативные ссылки

   [RFC2119] Брэднер, С., «Ключевые слова для использования в RFC для обозначения
              Уровни требований », BCP 14, RFC 2119,
              DOI 10.17487 / RFC2119, март 1997 г.,
              .

   [RFC3261] Розенберг, Дж., Шульцринн, Х., Камарилло, Г., Джонстон,
              А., Петерсон, Дж., Спаркс, Р., Хэндли, М. и Э.
              Школьник, "SIP: протокол инициации сеанса", RFC 3261,
              DOI 10.17487 / RFC3261, июнь 2002 г.,
              .

   [RFC3264] Розенберг, Дж. И Х. Шульцринн, "Модель предложения / ответа
              с протоколом описания сеанса (SDP) », RFC 3264,
              DOI 10.17487 / RFC3264, июнь 2002 г.,
              .




Campbell & Housley Standards Track [Страница 25] 

RFC 8591 S / MIME для обмена сообщениями SIP, апрель 2019 г.


   [RFC3428] Кэмпбелл, Б., Эд., Розенберг, Дж., Шульцринн, Х.,
              Хайтема, К. и Д. Гурл, "Протокол инициации сеанса".
              (SIP) Extension for Instant Messaging », RFC 3428,
              DOI 10.17487 / RFC3428, декабрь 2002 г.,
              .

   [RFC3565] Шаад Дж. "Использование расширенного стандарта шифрования (AES)
              Алгоритм шифрования в синтаксисе криптографических сообщений
              (CMS) ", RFC 3565, DOI 10.17487 / RFC3565, июль 2003 г.,
              .

   [RFC3853] Петерсон, Дж., "Расширенный стандарт шифрования S / MIME (AES)
              Требования к протоколу инициации сеанса (SIP) »,
              RFC 3853, DOI 10.17487 / RFC3853, июль 2004 г.,
              .

   [RFC4566] Хэндли, М., Якобсон, В., и К. Перкинс, "SDP: сеанс
              Описание протокола », RFC 4566, DOI 10.17487 / RFC4566,
              Июль 2006 г., .

   [RFC4975] Кэмпбелл, Б., ред., Мэхи, Р., ред., И К. Дженнингс, ред.,
              «Протокол ретрансляции сеанса сообщений (MSRP)», RFC 4975,
              DOI 10.17487 / RFC4975, сентябрь 2007 г.,
              .[RFC5084] Housley, R., "Использование AES-CCM и AES-GCM с аутентификацией.
              Шифрование в синтаксисе криптографических сообщений (CMS) »,
              RFC 5084, DOI 10.17487 / RFC5084, ноябрь 2007 г.,
              .

   [RFC5280] Купер, Д., Сантессон, С., Фаррелл, С., Бойен, С.,
              Хаусли, Р. и У. Полк, "Открытый ключ Internet X.509"
              Сертификат инфраструктуры и список отозванных сертификатов
              (CRL) Профиль ", RFC 5280, DOI 10.17487 / RFC5280, май 2008 г.,
              .

   [RFC5480] Тернер, С., Браун, Д., Ю, К., Хаусли, Р., и Т. Полк,
              "Открытый ключ объекта криптографии с эллиптической кривой
              Информация », RFC 5480, DOI 10.17487 / RFC5480, март 2009 г.,
              .

   [RFC5652] Housley, R., «Синтаксис криптографических сообщений (CMS)», STD 70,
              RFC 5652, DOI 10.17487 / RFC5652, сентябрь 2009 г.,
              .







Campbell & Housley Standards Track [Страница 26] 

RFC 8591 S / MIME для обмена сообщениями SIP, апрель 2019 г.


   [RFC5753] Тернер С. и Д. Браун, "Использование эллиптической кривой
              Алгоритмы криптографии (ECC) в криптографическом сообщении
              Syntax (CMS) », RFC 5753, DOI 10.17487 / RFC5753, январь
              2010 г., .

   [RFC5754] Тернер, С., "Использование алгоритмов SHA2 с криптографическими
              Синтаксис сообщения ", RFC 5754, DOI 10.17487 / RFC5754, январь
              2010 г., .

   [RFC8174] Лейба Б., «Неоднозначность прописных и строчных букв в RFC.
              2119 Ключевые слова », BCP 14, RFC 8174, DOI 10.17487 / RFC8174,
              Май 2017 г., .

   [RFC8418] Housley, R., "Использование ключа Диффи-Хеллмана для эллиптической кривой
              Алгоритм согласования с X25519 и X448 в
              Синтаксис криптографических сообщений (CMS) », RFC 8418,
              DOI 10.17487 / RFC8418, август 2018 г.,
              .

   [RFC8419] Housley, R., "Использование цифровой подписи Edwards-Curve"
              Подписи алгоритма (EdDSA) в криптографическом сообщении
              Синтаксис (CMS) », RFC 8419, DOI 10.17487 / RFC8419, август
              2018 г., .

   [RFC8550] Шаад, Дж., Рамсделл, Б., и С. Тернер, "Secure /
              Многоцелевые расширения почты Интернета (S / MIME) версии 4.0
              Обработка сертификатов », RFC 8550, DOI 10.17487 / RFC8550,
              Апрель 2019 г., .

   [RFC8551] Шаад, Дж., Рамсделл, Б., и С. Тернер, "Secure /
              Многоцелевые расширения почты Интернета (S / MIME) версии 4.0
              Спецификация сообщений », RFC 8551, DOI 10.17487 / RFC8551,
              Апрель 2019 г., .

   [X680] ITU-T, «Информационные технологии - абстрактная синтаксическая нотация.
              Один (ASN.1): Уточнение основных обозначений »,
              Рекомендация МСЭ-Т X.680, ИСО / МЭК 8824-1, август 2015 г.,
              .

   [X690] ITU-T, "Информационные технологии - правила кодирования ASN.1:
              Спецификация базовых правил кодирования (BER), канонических
              Правила кодирования (CER) и особые правила кодирования
              (DER) ", Рекомендация ITU-T X.690, ISO / IEC 8825-1, август
              2015 г., .







Campbell & Housley Standards Track [Страница 27] 

RFC 8591 S / MIME для обмена сообщениями SIP, апрель 2019 г.


13.2. Информативные ссылки

   [CPM] Open Mobile Alliance, "Конвергентная система обмена IP-сообщениями OMA.
              Описание, кандидат версии 2.2 », сентябрь 2017 г.

   [Efail] Поддебняк, Д., Дрезен, К., Мюллер, Дж., Изинг, Ф.,
              Шинцель, С., Фридбергер, С., Соморовский, Дж., И Дж.
              Швенк, "Efail: нарушение S / MIME и электронной почты OpenPGP
              Шифрование с использованием каналов эксфильтрации ", август 2018 г.,
              .

   [RCS] GSMA, "Документ с описанием услуги универсального профиля RCS,
              Версия 2.2 ", май 2018 г.,
              .

   [RFC3325] Дженнингс, К., Петерсон, Дж., И М. Уотсон, "Частный
              Расширения протокола инициации сеанса (SIP) для
              Подтвержденная идентификация в надежных сетях », RFC 3325,
              DOI 10.17487 / RFC3325, ноябрь 2002 г.,
              .

   [RFC3840] Розенберг, Дж., Шульцринн, Х., и П. Кизиват,
              "Указание возможностей пользовательского агента в сеансе
              Протокол инициации (SIP) », RFC 3840,
              DOI 10.17487 / RFC3840, август 2004 г.,
              .

   [RFC3860] Петерсон, Дж., «Общий профиль для обмена мгновенными сообщениями.
              (CPIM) ", RFC 3860, DOI 10.17487 / RFC3860, август 2004 г.,
              .

   [RFC3862] Клайн, Г. и Д. Аткинс, «Общее присутствие и мгновенное
              Обмен сообщениями (CPIM): формат сообщения », RFC 3862,
              DOI 10.17487 / RFC3862, август 2004 г.,
              .

   [RFC4648] Йозефссон, С., «Данные Base16, Base32 и Base64.
              Кодировки », RFC 4648, DOI 10.17487 / RFC4648, октябрь 2006 г.,
              .

   [RFC4976] Дженнингс, К., Махи, Р. и А. Роуч, "Relay Extensions
              для протокола ретрансляции сеансов сообщений (MSRP) », RFC 4976,
              DOI 10.17487 / RFC4976, сентябрь 2007 г.,
              .




Campbell & Housley Standards Track [Страница 28] 

RFC 8591 S / MIME для обмена сообщениями SIP, апрель 2019 г.


   [RFC5438] Бургер, Э. и Х. Хартабиль, "Утилизация мгновенных сообщений"
              Уведомление (IMDN) », RFC 5438, DOI 10.17487 / RFC5438,
              Февраль 2009 г., .

   [RFC6121] Сен-Андре, П., «Расширяемый обмен сообщениями и присутствие
              Протокол (XMPP): мгновенный обмен сообщениями и присутствие »,
              RFC 6121, DOI 10.17487 / RFC6121, март 2011 г.,
              .

   [RFC7515] Джонс, М., Брэдли, Дж. И Н. Сакимура, "JSON Web
              Подпись (JWS) », RFC 7515, DOI 10.17487 / RFC7515, май
              2015, .

   [RFC7516] Джонс, М. и Дж. Хильдебранд, "Веб-шифрование JSON (JWE)",
              RFC 7516, DOI 10.17487 / RFC7516, май 2015 г.,
              .

   [RFC7701] Ниеми, А., Гарсиа-Мартин, М., и Г. Сандбаккен, «Мульти-
              party Chat с использованием протокола ретрансляции сеанса сообщений
              (MSRP) ", RFC 7701, DOI 10.17487 / RFC7701, декабрь 2015 г.,
              .

   [RFC7748] Лэнгли, А., Гамбург, М., и С. Тернер, "Эллиптические кривые.
              for Security », RFC 7748, DOI 10.17487 / RFC7748, январь
              2016 г., .

   [RFC8032] Йозефссон, С. и И. Лиусваара, "Edwards-Curve Digital
              Алгоритм подписи (EdDSA) », RFC 8032,
              DOI 10.17487 / RFC8032, январь 2017 г.,
              .

   [RFC8224] Петерсон, Дж., Дженнингс, К., Рескорла, Э. и К. Вендт,
              «Аутентифицированное управление идентификацией во время сеанса.
              Протокол инициации (SIP) », RFC 8224,
              DOI 10.17487 / RFC8224, февраль 2018 г.,
              .

   [RTP-Sec] Петерсон Дж., Барнс Р. и Р. Хаусли, "Лучшие практики
              для защиты среды передачи данных RTP, сигнализируемой с помощью SIP ", Работа в
              Прогресс, draft-ietf-sipbrandy-rtpsec-08, апрель 2019 г.











Campbell & Housley Standards Track [Страница 29] 

RFC 8591 S / MIME для обмена сообщениями SIP, апрель 2019 г.


Приложение A. Детали сообщения

   В следующем разделе показано подробное содержание тел S / MIME.
   используется в разделе 10.А.1. Подписанное сообщение

   На рисунке 5 показаны детали сообщения, подписанного Алисой, используемого в
   пример в Разделе 10.1.

 CMS_ContentInfo:
   contentType: pkcs7-signedData (1.2.840.113549.1.7.2)
   d.signedData:
     версия: 1
     дайджестАлгоритмы:
         алгоритм: sha256 (2.16.840.1.101.3.4.2.1)
         параметр: 
     encapContentInfo:
       eContentType: pkcs7-data (1.2.840.113549.1.7.1)
       Электронное содержание:
   0000-43 6f 6e 74 65 6e 74 2d-54 79 70 65 3a 20 74 Content-Type: t
   000f - 65 78 74 2f 70 6c 61 69-6e 0d 0a 0d 0a 57 61 внешн. / Обычн.... Ва
   001e - 74 73 6f 6e 2c 20 63 6f-6d 65 20 68 65 72 65 tson, иди сюда
   002d - 20 2d 20 49 20 77 61 6e-74 20 74 6f 20 73 65 - Я хочу купить
   003c - 65 20 79 6f 75 2e 0d 0a- e вы ...
     сертификаты:
       г. сертификат:
         cert_info:
           версия: 2
           серийный номер: 13292724773353297200
           подпись:
             алгоритм: ecdsa-with-SHA256 (1.2.840.10045.4.3.2)
             параметр: 
           эмитент: O = пример.com, CN = Алиса
           срок действия:
             notBefore: 19 декабря, 23:12:05 2017 г. по Гринвичу
             notAfter: 19 декабря 23:12:05 2018 по Гринвичу
           тема: O = example.com, CN = Алиса
           ключ:
             алгоритм:
               алгоритм: id-ecPublicKey (1.2.840.10045.2.1)
               параметр: OBJECT: prime256v1 (1.2.840.10045.3.1.7)
             public_key: (0 неиспользованных битов)
   0000-04 d8 7b 54 72 9f 2c 22-fe eb d9 dd ba 0e .. {Тр., "......
   000e - fa 40 64 22 97 a6 09 38-87 a4 da e7 99 [email protected] "... 8 ......
   001c - 23 f8 7f a7 ed 99 db 8c-f5 a3 14 f2 ee 64 # ............ d
   002a - 10 6e f1 ed 61 db fc 0a-4b 91 c9 53 cb d0 .n..a ... K..S ..
   0038 - 22 a7 51 b9 14 80 7b b7-94 ".Q ... {..



Campbell & Housley Standards Track [Страница 30] 

RFC 8591 S / MIME для обмена сообщениями SIP, апрель 2019 г.


           IssueUID: 
           subjectUID: <ОТСУТСТВИЕ>
           расширения:
               объект: X509v3 Альтернативное имя субъекта (2.5.29.17)
               критический: BOOL ABSENT
               ценность:
   0000-30 17 86 15 73 69 70 3a-61 6c 69 63 65 0 ... sip: alice
   000d - 40 65 78 61 6d 70 6c 65-2e 63 6f 6d @ example.com
         sig_alg:
           алгоритм: ecdsa-with-SHA256 (1.2.840.10045.4.3.2)
           параметр: 
         подпись: (0 неиспользованных битов)
   0000-30 45 02 20 78 79 be 1c-27 f8 46 27 6f df 15 0E. ху .. '. Ф'о ..
   000f - e3 33 e5 3c 6f 17 a7 57-38 8a 02 cb 7b 8a e4 .3. 
     подписывающий
         версия: 1
         d.issuerAndSerialNumber:
           эмитент: O = example.com, CN = Alice
           серийный номер: 13292724773353297200
         дайджестАлгоритм:
           алгоритм: sha256 (2.16.840.1.101.3.4.2.1)
           параметр: 
         signedAttrs:
             объект: contentType (1.2.840.113549.1.9.3)
             набор:
               ОБЪЕКТ: pkcs7-data (1.2.840.113549.1.7.1)

             объект: signatureTime (1.2.840.113549.1.9.5)
             набор:
               UTCTIME: 24 января, 23:52:56 2019 GMT

             объект: messageDigest (1.2.840.113549.1.9.4)
             набор:
               СТРОКА ОКТЕТОВ:
   0000 - ef 77 8f c9 40 d5 e6 dc-25 76 f4 7a 59 .w .. @ ...% v.zY
   000d - 9b 31 26 19 5a 9f 1a 22-7a da f3 5f a2 .1 & .Z .. "z .._.
   001a - 2c 05 0d 8d 19 5a,.... Я
         signatureAlgorithm:
           алгоритм: ecdsa-with-SHA256 (1.2.840.10045.4.3.2)
           параметр: 






Campbell & Housley Standards Track [Страница 31] 

RFC 8591 S / MIME для обмена сообщениями SIP, апрель 2019 г.


         подпись:
   0000-30 45 02 20 58 79 куб.см 62-85 e0 86 06 19 d3 bf 0E. Xy.b .......
   000f - 53 d4 67 9f 03 73 d7 45-20 cf 56 10 c2 55 5b S.g..s.E .V..U [
   001e - 7b ec 61 d4 72 dc 02 21-00 83 aa 53 44 28 4d {.а.р ..! ... SD (M
   002d - 4c ef de 31 07 9c f9 71-bd 69 5d 6e c8 71 e9 L..1 ... q.i] n.q.
   003c - a4 60 ec 2e 12 65 2b 77-a4 62 4d .` ... e + w.bM
         unsignedAttrs:
           <ОТСУТСТВИЕ>

                         Рисунок 5: Подписанное сообщение

А.2. Короткое подписанное сообщение

   На рисунке 6 показано сообщение, подписанное Алисой, без встроенного
   сертификат, используемый в примере в Разделе 10.2.

 CMS_ContentInfo:
   contentType: pkcs7-signedData (1.2.840.113549.1.7.2)
   d.signedData:
     версия: 1
     дайджестАлгоритмы:
         алгоритм: sha256 (2.16.840.1.101.3.4.2.1)
         параметр: 
     encapContentInfo:
       eContentType: pkcs7-data (1.2.840.113549.1.7.1)
       Электронное содержание:
   0000-43 6f 6e 74 65 6e 74 2d-54 79 70 65 3a 20 74 Content-Type: t
   000f - 65 78 74 2f 70 6c 61 69-6e 0d 0a 0d 0a 57 61 внешн. / Однотонный .... Wa
   001e - 74 73 6f 6e 2c 20 63 6f-6d 65 20 68 65 72 65 tson, иди сюда
   002d - 20 2d 20 49 20 77 61 6e-74 20 74 6f 20 73 65 - Я хочу купить
   003c - 65 20 79 6f 75 2e 0d 0a- e you...
     сертификаты:
       <ОТСУТСТВИЕ>
     crls:
       <ОТСУТСТВИЕ>
     подписывающий
         версия: 1
         d.issuerAndSerialNumber:
           эмитент: O = example.com, CN = Alice
           серийный номер: 13292724773353297200
         дайджестАлгоритм:
           алгоритм: sha256 (2.16.840.1.101.3.4.2.1)
           параметр: 
         signedAttrs:
             объект: contentType (1.2.840.113549.1.9.3)
             набор:
               ОБЪЕКТ: pkcs7-data (1.2.840.113549.1.7.1)




Campbell & Housley Standards Track [Страница 32] 

RFC 8591 S / MIME для обмена сообщениями SIP, апрель 2019 г.


             объект: signatureTime (1.2.840.113549.1.9.5)
             набор:
               UTCTIME: 24 января, 23:52:56 2019 GMT

             объект: messageDigest (1.2.840.113549.1.9.4)
             набор:
               СТРОКА ОКТЕТОВ:
   0000 - ef 77 8f c9 40 d5 e6 dc-25 76 f4 7a 59 .w .. @ ...% v.zY
   000d - 9b 31 26 19 5a 9f 1a 22-7a da f3 5f a2.К ...
   002d - cf 3c af 07 c8 1c 11 64-f0 21 e7 70 e0 f6 a0. <..... d.!. P ...
   003c - 96 2e 0a 7b 19 b7 42 ad-cb 34 ... {.. B..4
         unsignedAttrs:
           <ОТСУТСТВИЕ>

           Рисунок 6: Подписанное сообщение без встроенного сертификата

А.3. Подписанное и зашифрованное сообщение

   В следующих разделах показаны подробности сообщения, подписанного Бобом и
   зашифровано для Алисы, как используется в примерах в Разделах 10.3
   и 10.4.

А.3.1. Подписанное сообщение до шифрования

 CMS_ContentInfo:
   contentType: pkcs7-signedData (1.2.840.113549.1.7.2)
   d.signedData:
     версия: 1
     дайджестАлгоритмы:
         алгоритм: sha256 (2.16.840.1.101.3.4.2.1)
         параметр: 
     encapContentInfo:
       eContentType: pkcs7-data (1.2.840.113549.1.7.1)
       Электронное содержание:
   0000-43 6f 6e 74 65 6e 74 2d-54 79 70 65 3a 20 74 Content-Type: t
   000f - 65 78 74 2f 70 6c 61 69-6e 0d 0a 0d 0a 57 61 внешн. / Однотонный .... Wa
   001e - 74 73 6f 6e 2c 20 63 6f-6d 65 20 68 65 72 65 tson, иди сюда
   002d - 20 2d 20 49 20 77 61 6e-74 20 74 6f 20 73 65 - Я хочу купить
   003c - 65 20 79 6f 75 2e 0d 0a- e you...




Campbell & Housley Standards Track [Страница 33] 

RFC 8591 S / MIME для обмена сообщениями SIP, апрель 2019 г.


     сертификаты:
       г. сертификат:
         cert_info:
           версия: 2
           серийный номер: 11914627415941064473
           подпись:
             алгоритм: ecdsa-with-SHA256 (1.2.840.10045.4.3.2)
             параметр: 
           эмитент: O = example.org, CN = Bob
           срок действия:
             notBefore: 20 декабря, 23:07:49 2017 г. по Гринвичу
             notAfter: 20 декабря 23:07:49 2018 по Гринвичу
           тема: O = пример.org, CN = Боб
           ключ:
             алгоритм:
               алгоритм: id-ecPublicKey (1.2.840.10045.2.1)
               параметр: OBJECT: prime256v1 (1.2.840.10045.3.1.7)
             public_key: (0 неиспользованных битов)
   0000-04 86 4f ff fc 53 f1 a8-76 ca 69 b1 7e 27 ..O..S..v.i. ~ '
   000e - 48 7a 07 9c 71 52 ae 1b-13 7e 39 3b af 1a Hz..qR ... ~ 9; ..
   001c - ae bd 12 74 3c 7d 41 43-a2 fd 8a 37 0f 02 ... t <} AC ... 7 ..
   002a - ba 9d 03 b7 30 1f 1d a6-4e 30 55 94 bb 6f .... 0 ... N0U..o
   0038-95 cb 71 fa 48 b6 d0 a3-83..q.H ....
           IssueUID: 
           subjectUID: <ОТСУТСТВИЕ>
           расширения:
               объект: X509v3 Альтернативное имя субъекта (2.5.29.17)
               критический: ИСТИНА
               ценность:
   0000-30 15 86 13 73 69 70 3a-62 6f 62 40 65 0 ... sip: bob @ e
   000d - 78 61 6d 70 6c 65 2e 6f-72 67 xample.org
         sig_alg:
           алгоритм: ecdsa-with-SHA256 (1.2.840.10045.4.3.2)
           параметр: 
         подпись: (0 неиспользованных битов)
   0000-30 45 02 21 00 b2 24 8c-92 40 28 22 38 9e c9 0E.! .. $ .. @ ("8 ..
   000f - 25 7f 64 куб.см fd 10 6f ba-0b 96 c1 19 07 30 34% .d ... o ...... 04
   001e - d5 1b 10 2f 73 39 6c 02-20 15 8e b1 51 f0 85 ... / s9l. ... Q ..
   002d - b9 bd 2e 04 cf 27 8f 0d-52 2e 6b b6 fe 4f 36 ..... '.. R.k..O6
   003c - f7 4c 77 10 b1 5a 4f 47-9d e4 0d .Lw..ZOG ...
     crls:
       <ОТСУТСТВИЕ>
     подписывающий
         версия: 1
         d.issuerAndSerialNumber:
           эмитент: O = example.org, CN = Bob
           серийный номер: 11914627415941064473




Campbell & Housley Standards Track [Страница 34] 

RFC 8591 S / MIME для обмена сообщениями SIP, апрель 2019 г.


         дайджестАлгоритм:
           алгоритм: sha256 (2.16.840.1.101.3.4.2.1)
           параметр: 
         signedAttrs:
             объект: contentType (1.2.840.113549.1.9.3)
             набор:
               ОБЪЕКТ: pkcs7-data (1.2.840.113549.1.7.1)

             объект: signatureTime (1.2.840.113549.1.9.5)
             набор:
               UTCTIME: 24 января, 23:52:56 2019 GMT

             объект: messageDigest (1.2.840.113549.1.9.4)
             набор:
               СТРОКА ОКТЕТОВ:
   0000 - ef 77 8f c9 40 d5 e6 dc-25 76 f4 7a 59 .w .. @ ...% v.zY
   000d - 9b 31 26 19 5a 9f 1a 22-7a da f3 5f a2 .1 & .Z .. "z .._.
   001a - 2c 05 0d 8d 19 5a, .... Z
         signatureAlgorithm:
           алгоритм: ecdsa-with-SHA256 (1.2.840.10045.4.3.2)
           параметр: 
         подпись:
   0000-30 45 02 21 00 f7 88 ed-44 6a b7 0f ff 2c 1f 0E.! .... Dj ...,.
   000f - fa 4c 03 74 fd 08 77 fd-61 ee 91 7c 31 45 b3 .L.t..w.a .. | 1E.
   001e - 89 a6 76 15 c7 46 fa 02-20 77 94 ad c5 7f 00 ..v..F .. w .....
   002d - 61 c7 84 b9 61 23 cc 6e-54 bb 82 82 65 b6 d4 a...a # .nT ... e ..
   003c - cc 12 99 76 a6 b1 fc 6d-bc 28 d6 ... v ... m. (.
         unsignedAttrs:
           <ОТСУТСТВИЕ>

            Рисунок 7: Сообщение, подписанное Бобом перед шифрованием

А.3.2. Зашифрованное сообщение

 CMS_ContentInfo:
   contentType: pkcs7-authEnvelopedData (1.2.840.113549.1.9.16.1.23)
   d.authEnvelopedData:
     версия: 0
     originatorInfo: 
     recipientInfos:
       d.ktri:
         версия: 
         d.issuerAndSerialNumber:
           эмитент: O = пример.г
   000f - 61 10 fa 27 23 c1 b9 e4-54 84 b6 d3 3e 83 87 a .. '# ... T ...> ..
   001e - de 96 7d c5 e0 ca fb 35-57 1a 56 a1 97 5c b5 ..} .... 5W.V .. \.
   002d - 50 e7 be 31 c1 31 da 80-fb 73 10 24 84 5b ab P..1.1 ... s. $. [.
   003c - b8 d6 4c ac 26 04 04 24-d9 33 05 61 c8 43 99 ..L. & .. $. 3.a.C.
   004b - 94 15 dd 64 4b 3c ad 95-07 2f 71 45 13 93 c9 ... dK <... / qE ...
   005a - 9f 28 2c 48 83 bd 0c cc-5d d5 4b 93 14 64 e0. (, H ....]. K..d.
   0069 - 0a 6e 55 e5 92 c5 1a 68-de 10 62 51 6e c7 d3.nU .... h..bQn ..
   0078 - ca 8e 76 4b b8 ac 78 9a-88 37 77 65 ef 8d c3 ..vK..x..7we ...
   0087 - 6c 0a 6e d3 ec ae 52 85-ca c6 a2 9d 50 59 44 l.n ... R ..... PYD
   0096 - 57 19 a1 bd cf 90 6e 0f-f3 7e 2c 2e f0 f4 ec W ..... n .. ~, ....
   00a5 - 62 25 10 0c c0 62 e1 c7-48 96 3b bc 88 b8 e3 b% ... b..H.; ....
   00b4 - df cf 71 40 73 72 9d d5-c7 58 3e 75 8a cf 3d ..q @ sr ... X> u .. =
   00c3 - 18 6f 2f a4 17 be 22 c3-7c 9a 76 c6 b4 27 29 .o / ... ". | .V .. ')
   00d2 - aa d2 7f 73 ae 44 ac 98-47 4d 1e eb 48 94 8c...s.D..GM..H ..
   00e1 - 12 a4 03 d0 b3 ce 08 a2-18 d6 af 45 69 24 89 ........... Ei $.
   00f0 - 7c c5 c9 66 4f 6d fe b3-f1 81 41 15 8d fc 3b | ..fOm .... A ...;
   00ff - 84 09 0a a6 03 80 aa 86-51 37 e1 69 9c 5c 81 ........ Q7.i. \.
   010e - 97 41 67 9d 7a 3c 90 ba-79 e6 d7 d5 c8 d8 9b .Ag.z <.. y ......
   011d - b5 4a 66 74 23 e4 3b 0b-7d 6f 78 c0 b4 ab 67 .Jft #.;.} Ox ... g
   012c - до н.э. 34 36 62 a6 35 fe 59-5f 11 49 c5 39 50 ок. 46b.5.Y_.I.9P.
   013b - c2 e0 ba 31 8c 22 7e 6f-76 a8 d9 40 40 0f d3...1. "~ Ов .. @@ ..
   014a - d3 ea 1c 8e ce a0 03 dc-ce 2f 1f b0 0f 5c ea ......... / ... \.
   0159 - 33 5d e1 30 3f cb f9 3d-8e 1c bf d6 82 f1 9b 3] .0? .. = .......
   0168 - eb 62 4b ac d1 d7 b8 f5-80 f1 14 a1 3b 89 08 .bK .........; ..
   0177 - 94 fb 40 44 a5 da a7 64-b7 f8 c5 ff 92 94 94 .. @ D ... d .......
   0186 - 52 b3 5a eb 96 39 b8 ad-63 c0 51 5c 95 cc c6 R.Z..9..c.Q \ ...
   0195 - f8 23 c2 20 10 67 ea 22-62 41 3f ef 39 7d 48. #. .g. "bA? .9} H
   01a4 - f7 b6 14 3f 84 2a e8 e1-a4 8c ad 3a e0 1a ba...?. * .....: ...
   01b3 - a3 cf 9e e7 e3 66 20 e0-5c ca 06 11 bf ac 00 ..... f. \ ......
   01c2 - ее f1 a4 98 f2 d2 59 b9-f0 f7 da 83 ef 6f 1b ...... Y ...... o.
   01d1 - 06 1f 38 7c 2d c4 8c 8b-5d ba ca 86 23 08 f3 ..8 | -...] ... # ..
   01e0 - 2f 47 92 51 65 c9 e5 eb-b4 67 79 98 84 91 8d /G.Qe .... gy ....
   01ef - d6 97 b4 47 f4 c4 07 98-9b 88 9b 0c 2e 95 80 ... G ...........
   01fe - af 78 .x
     authEncryptedContentInfo:
       contentType: pkcs7-data (1.2.840.113549.1.7.1)
       contentEncryptionAlgorithm:
         алгоритм: aes-128-gcm (2.16.840.1.101.3.4.1.6)
         параметр:
           aes-nonce:
   0000 - 4d 87 57 22 2e ac ​​52 94-11 7f 0c 12 МВт ".. R .....
           aes-ICVlen: 16
       encryptedContent:
   0000 - fe 2f b3 de 0b f0 69 98-c3 9b f4 a9 52 fa bf ./....i.....R ..
   000f - 8b 0f ee 3d 7e 2e 85 18-1a ec f1 a8 9e 1a 2e ... = ~ ..........
   001e - de cd 94 04 88 56 12 df-c6 98 43 34 d8 60 2b ..... V .... C4 .. +



Campbell & Housley Standards Track [Страница 36] 

RFC 8591 S / MIME для обмена сообщениями SIP, апрель 2019 г.


   002d - 77 49 b2 50 4e 45 f5 7c-3b 06 66 26 b0 fc 74 wI.PNE. | ..F & .. t
   003c - 62 36 1e ec 26 7c 56 01-39 be 5c d2 86 a2 af b6 .. & | V.9. \ ....
   004b - 96 96 cf 51 85 22 78 e5-2c 38 18 ca b0 a6 8c ... Q. "x., 8 .....
   005a - 59 8d e4 fc e1 4a 33 38-84 e4 de 5d df 57 ed Y .... J38 ...]. W.
   0069 - d7 88 67 02 7a 31 e4 a7-c0 c0 29 91 44 c5 de ..g.z1 ....). D ..
   0078 - 6b ae 39 69 9e 70 0e 05-7e b0 f0 da d7 3b 8b k.9i.p .. ~ ......
   0087 - 36 9f 42 eb 32 1b 41 53-87 81 d9 82 a1 1a 0b 6.B.2.AS .......
   0096-39 43 ac 10 c9 7b 54 ee-b7 3b 38 ec 13 1a fc 9C."..
   00d2 - 5d 0a ae 41 6b 86 f0 a8-8d 0e b7 a9 81 db b2] .. Ak ..........
   00e1 - 83 e8 b9 4e 9d 50 bf 62-65 c2 34 8a 18 a1 69 ... N.P.be.4 ... i
   00f0 - aa cb 5a 37 a5 29 bd a2-f9 cb 10 ef dd cf 14 ..Z7.) .........
   00ff - 23 10 95 d8 79 64 63 7b-d3 3f b1 3c 68 b4 cf # ... ydc {.?. .
   02c1 - 92 e5 d1 77 45 64 96 3b-39 1c 3b bd 9f 1c 27 ... wEd..9 ......
   02d0 - ff e3 6f 83 2e 05 15 5f-c3 9e e6 65 2f a7 b4 ..o ...._... e / ..
   02df - 18 89 75 ec 5c 67 b3 2c-9f 21 3c 8a c6 b8 e1 ..u. \ G.,.! <....
   02ee - 32 a5 a7 c3 bf 74 f0 16-40 5c d8 c2 01 d1 05 2 .... t .. @ \ .....



Campbell & Housley Standards Track [Страница 37] 

RFC 8591 S / MIME для обмена сообщениями SIP, апрель 2019 г.


   02fd - 21 93 e1 86 d4 43 58 de-38 8d 73 21 1b a2 f1!.0357 - d8 c0 ba d3 5d df 19 84-f2 24 1c d3 b5 29 dc ....] .... $ ...).
   0366-10 28 84 5f 80 89 54 3d-f4 f1 44 1e de 36 b1. (._ .. T = .. D..6.
   0375 - bf 31 af 5a fc 8c 2b 70-8d 50 b6 45 d4 e7 db .1.Z .. + p.P.E ...
   0384 - 88 64 8c 3e ef e1 47 65-15 8f b0 e8 d3 bb 53 .d.> .. Ge ...... S
   0393 - dd cb e2 6d 71 24 c6 e1-d9 92 f8 32 30 aa 95 ... mq $ ..... 20 ..
   03a2 - 33 76 ee 8c 68 10 95 68-e8 57 1f 0c 9b bd a4 3v..h..h.W .....
   03b1 - 8f 4d f3 06 fe 74 7f 37-11 75 14 8f 31 83 27 .M...t.7.u..1 ..
   03c0 - 67 кд 76 6c f0 7b 45 0c-bf 62 ca d2 a7 bd 71 g.vl. {E..b .... q
   03cf - f1 f8 82 33 f1 16 a1 a7-f3 ca f1 2f 34 bc f4 ... 3 ....... / 4 ..
   03de - 0d 21 e7 9f fc 98 27 22-1b 68 b0 80 ff 03 ад.! ..... ". H .....
   03ed - 78 2d 6d 6d 07 87 16 76-f7 98 94 3e 54 f1 3f x-мм ... v ...> T.?
   03fc - d7 5c 89 c0 b4 26 3b f1-0f 56 24 3f 9e 72 ef. \ ... & ... V $ ?. r.
   040b - 3b 38 99 a5 39 d9 a3 ac-5b e2 b6 94 00 a3 cf .8..9 ... [......
   041a - 8d 19 6c 5c ed 69 7b 2e-d8 03 b9 87 a5 ee 85..w ..........
   0456 - 1f f1 32 55 9c 23 43 21-7b 9c 29 50 38 6e 85 ..2U. # C! {.) P8n.
   0465 - d2 94 21 21 08 6c df a1-96 58 19 5b e6 d7 f8 .. !!. L ... X. [...
   0474 - 6b ca 98 81 b6 95 08 29-64 f1 2e 7c f8 01 02 k ......) d .. | ...
   0483 - 5d 67 92 c6 88 24 09 41-4d 70 33 21 ec 83 ab] g ... $. AMp3! ...
   0492 - d6 98 d6 89 56 11 87 13-a0 ff 12 72 ac bc 9a .... V ...... r ...
   04a1 - 6d 14 89 00 c7 4c 16 92-1d f9 b3 8f 29 ec 46 m .... L ......). F
   04b0 - d4 f1 00 60 ff fe 5e 36-bb ba ca f2 d1 ba d7.6 .......
   04bf - dd 05 7e d3 e3 0e bc d6-90 83 f9 d3 a2 a2 6e .. ~ ........... n
   04ce - f9 0b 75 1d 6a 1a df a0-59 0d b1 9d a1 07 cf ..u.j ... Y ......
   04dd - 3e a8 db> ..
     authAttrs:
       
     mac:
   0000 - f6 ff c6 e1 ae f1 9c d2-3d 98 5a 92 19 76 35 ........ =. Z..v5
   000f - 2d -
     unauthAttrs:
       

               Рисунок 8: Сообщение, зашифрованное Бобом для Алисы









Campbell & Housley Standards Track [Страница 38] 

RFC 8591 S / MIME для обмена сообщениями SIP, апрель 2019 г.


Адреса авторов

   Бен Кэмпбелл
   Стандарт Велосити, ООО

   Электронная почта: ben @ nostrum.ком


   Расс Хаусли
   Vigil Security, ООО

   Электронная почта: housley@vigilsec.com







































Campbell & Housley Standards Track [Стр. 39]
 

Что такое SIPS и SRTP? Ознакомьтесь с нашими часто задаваемыми вопросами об Askozia

В телефонии по протоколу передачи голоса по IP используются два стандартных протокола. SIP (протокол инициации сеанса) создает соединение от однорангового узла (например, от телефона к телефону или от телефона к телефонной системе). Допустим, он устанавливает переключатели для аудиопотока.После установления соединения RTP (транспортный протокол реального времени) используется для передачи аудио- или видеоданных. Большой проблемой безопасности стандартных подключений SIP / RTP является то, что сообщения SIP и потоки RTP могут быть перехвачены и прочитаны / прослушаны каждым, кто обладает базовыми знаниями сетевых технологий. В связи с этим рекомендуется использовать простой SIP / RTP только в локальных сетях (LAN), а не через общедоступный Интернет.

Чтобы преодолеть недостатки безопасности SIP и RTP и безопасно совершать защищенные вызовы через Интернет, были разработаны зашифрованные версии обоих протоколов.SIPS, что означает SIP Secure, является SIP, дополненным TLS (Transport Layer Security). С помощью этого TLS можно установить безопасное соединение между IP-АТС и телефоном VoIP с использованием метода рукопожатия. SRTP кодирует голос в зашифрованные IP-пакеты и передает их через Интернет от передатчика (IP-телефонная система) к получателю (IP-телефон или программный телефон), как только SIPS инициирует безопасное соединение. Чтобы получатель мог расшифровать пакеты, ключ отправляется через SIPS, в то время как соединение инициируется на предыдущем шаге.

Используя SIPS / SRTP, безопасное одноранговое соединение используется не только для звука, но и во время установления соединения. Это означает, что зашифрован не только звук, но и детали подключения (кто кому звонит и т. Д.). Чтобы использовать эти безопасные протоколы, все задействованные устройства должны поддерживать SIPS и SRTP. Если один из партнеров не поддерживает эти протоколы, установить безопасное соединение невозможно. Рекомендуется использовать SIPS и SRTP в сценариях, где ожидаются атаки из внешнего мира (т.е. в облаке или при отсутствии VPN).

Начиная с версии 4.0 AskoziaPBX полностью поддерживает SIPS и SRTP.

Расшифровать зашифрованные двоичные файлы приложения в macOS при включенном SIP

Расшифровывать зашифрованные двоичные файлы приложения в macOS при включенном SIP.

Это хорошо работает и прекрасно компилируется для iOS. Если вы хотите использовать его на устройствах iOS, вы можете использовать build-ios.sh (Спасибо @ dlevi309).

Как использовать

На Mac с процессором M1

 > git clone https: // github.com / paradiseduo / appdecrypt.git
> cd appdecrypt
> chmod + x build-macOS_arm.sh
> ./build-macOS_arm.sh
> cd .build / release
> ./appdecrypt
Версия 2.0

appdecrypt - это инструмент для расшифровки зашифрованных двоичных файлов приложения в macOS при включенном SIP.

Примеры:
    mac:
        appdecrypt /Applicaiton/Test.app /Users/admin/Desktop/Test.app
    iPhone:
        приложение / вар / контейнеры / пакет / приложение / XXXXXX / tmp

ИСПОЛЬЗОВАНИЕ: appdecrypt encryptMachO_Path decryptMachO_Path

АРГУМЕНТЫ:
   Путь к файлу приложения для шифрования. Путь к выходному файлу.

ОПЦИИ:
  -h, --help Показать справочную информацию.
  
Например,
 > ./appdecrypt /Applicaiton/Test.app /Users/admin/Desktop/Test.app
Успешное копирование файла.
Дамп /Applications/Test.app/Wrapper/Test.app/Test Success
Дамп /Applications/Test.app/Wrapper/Test.app/PlugIns/TestNotificationService.appex/TestNotificationService Успех
Дамп /Applications/Test.app/Wrapper/Test.app/Frameworks/trackerSDK.framework/trackerSDK Успех
Дамп / Приложения / Тест.app / Wrapper / Test.app / Frameworks / AgoraRtcKit.framework / AgoraRtcKit Success
> cd /Users/admin/Desktop/Test.app
> ls
WrappedBundle Обертка
> cd Wrapper
> ls
BundleMetadata.plist Test.app iTunesMetadata.plist
  

На iPhone с побегом из тюрьмы с процессором arm64

Сначала необходимо подключить iPhone для взлома через USB.

 > git clone https://github.com/paradiseduo/appdecrypt.git
> cd appdecrypt
> chmod + x build-iOS.sh
> ./build-iOS.sh
> scp -P 2222 global.xml [адрес электронной почты защищен]: / tmp
> cd .build / release
> scp -P 2222 appdecrypt [защита электронной почты]: / tmp

// В оболочке iPhone
> cd / tmp
> ldid -Sglobal.xml appdecrypt
> ./appdecrypt
Версия 2.0

appdecrypt - это инструмент для расшифровки зашифрованных двоичных файлов приложения в macOS при включенном SIP.

Примеры:
    mac:
        appdecrypt /Applicaiton/Test.app /Users/admin/Desktop/Test.app
    iPhone:
        приложение / вар / контейнеры / пакет / приложение / XXXXXX / tmp

ИСПОЛЬЗОВАНИЕ: appdecrypt encryptMachO_Path decryptMachO_Path

АРГУМЕНТЫ:
   Путь к файлу приложения для шифрования. Путь к выходному файлу.

ОПЦИИ:
  -h, --help Показать справочную информацию.
  
Например,
 > ./appdecrypt / var / container / Bundle / Application / 23E4B0B4-7275-46CE-8EEA-18CADE61FDB8 / tmp
Успешное копирование файла.
Дамп /var/containers/Bundle/Application/23E4B0B4-7275-46CE-8EEA-18CADE61FDB8/Aweme.app/Aweme Success
Дамп /var/containers/Bundle/Application/23E4B0B4-7275-46CE-8EEA-18CADE61FDB8/Aweme.app/PlugIns/AwemeDYShareExtension.appex / AwemeDYShareExtension Success
Дамп /var/containers/Bundle/Application/23E4B0B4-7275-46CE-8EEA-18CADE61FDB8/Aweme.app/PlugIns/AwemeNotificationService.appex/AwemeNotificationService Успешно
Дамп /var/containers/Bundle/Application/23E4B0B4-7275-46CE-8EEA-18CADE61FDB8/Aweme.app/PlugIns/AwemeWidgetExtension.appex/AwemeWidgetExtension Success
Дамп /var/containers/Bundle/Application/23E4B0B4-7275-46CE-8EEA-18CADE61FDB8/Aweme.app/PlugIns/AWEVideoWidget.appex/AWEVideoWidget Success
Дамп / вар / контейнеры / Пакет / Приложение / 23E4B0B4-7275-46CE-8EEA-18CADE61FDB8 / Aweme.app / PlugIns / AwemeBroadcastExtension.appex / AwemeBroadcastExtension Успешно
Дамп /var/containers/Bundle/Application/23E4B0B4-7275-46CE-8EEA-18CADE61FDB8/Aweme.app/PlugIns/AWEFriendsWidgets.appex/AWEFriendsWidgets Success
Дамп /var/containers/Bundle/Application/23E4B0B4-7275-46CE-8EEA-18CADE61FDB8/Aweme.app/PlugIns/AwemeVideoNotification.appex/AwemeVideoNotification Success
Дамп /var/containers/Bundle/Application/23E4B0B4-7275-46CE-8EEA-18CADE61FDB8/Aweme.app/Frameworks/ByteRtcEngineKit.framework/ByteRtcEngineKit Успех
Дамп / вар / контейнеры / Пакет / Приложение / 23E4B0B4-7275-46CE-8EEA-18CADE61FDB8 / Aweme.приложение / Frameworks / byteaudio.framework / byteaudio Успех
> ls
Полезная нагрузка /
> cd Payload
> ls
Aweme.	

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *