SDES

Не путать с упрощенным DES (SDES) .

SDES ( описания безопасности протокола описания сеанса ) для медиапотоков — это способ согласования ключа для безопасного транспортного протокола реального времени . Стандартизация была предложена IETF в июле 2006 г. (см. RFC   4568. )

Как это работает

Ключи передаются во вложении SDP к SIP- сообщению. Это означает, что транспортный уровень SIP должен гарантировать, что никто другой не сможет увидеть вложение. Это можно сделать с помощью транспортного уровня TLS или других методов, таких как S/MIME. Использование TLS предполагает, что следующему прыжку в цепочке прокси-серверов SIP можно доверять, и он позаботится о требованиях безопасности запроса.

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

Чтобы проиллюстрировать этот принцип на примере, телефон отправляет вызов прокси. Использование схемы sip указывает на то, что вызов должен быть безопасным. Ключ имеет кодировку Base64 во вложении SDP.

INVITE sips:*[email protected];user=phone SIP/2.0
Via: SIP/2.0/TLS 172.20.25.100:2049;branch=z9hG4bK-s5kcqq8jqjv3;rport
From: "123" <sips:[email protected]>;tag=mogkxsrhm4
To: <sips:*[email protected];user=phone>
Call-ID: 3c269247a122-f0ee6wcrvkcq@snom360-000413230A07
CSeq: 1 INVITE
Max-Forwards: 70
Contact: <sip:[email protected]:2049;transport=tls;line=gyhiepdm>;reg-id=1
User-Agent: snom360/6.2.2
Accept: application/sdp
Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE, PRACK, MESSAGE, INFO
Allow-Events: talk, hold, refer
Supported: timer, 100rel, replaces, callerid
Session-Expires: 3600;refresher=uas
Min-SE: 90
Content-Type: application/sdp
Content-Length: 477

v=0
o=root 2071608643 2071608643 IN IP4 172.20.25.100
s=call
c=IN IP4 172.20.25.100
t=0 0
m=audio 57676 RTP/SAVP 0 8 9 2 3 18 4 101
a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:WbTBosdVUZqEb6Htqhn+m3z7wUh4RJVR8nE15GbN
a=rtpmap:0 pcmu/8000
a=rtpmap:8 pcma/8000
a=rtpmap:9 g722/8000
a=rtpmap:2 g726-32/8000
a=rtpmap:3 gsm/8000
a=rtpmap:18 g729/8000
a=rtpmap:4 g723/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=encryption:optional
a=sendrecv

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

SIP/2.0 200 Ok
Via: SIP/2.0/TLS 172.20.25.100:2049;branch=z9hG4bK-s5kcqq8jqjv3;rport=62401;received=66.31.106.96
From: "123" <sips:[email protected]>;tag=mogkxsrhm4
To: <sips:*[email protected];user=phone>;tag=237592673
Call-ID: 3c269247a122-f0ee6wcrvkcq@snom360-000413230A07
CSeq: 1 INVITE
Contact: <sip:*[email protected]:5061;transport=tls>
Supported: 100rel, replaces
Allow-Events: refer
Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, PRACK, INFO
Accept: application/sdp
User-Agent: pbxnsip-PBX/1.5.1
Content-Type: application/sdp
Content-Length: 298

v=0
o=- 1996782469 1996782469 IN IP4 203.43.12.32
s=-
c=IN IP4 203.43.12.32
t=0 0
m=audio 57076 RTP/SAVP 0 101
a=rtpmap:0 pcmu/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-11
a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:bmt4MzIzMmYxdnFyaWM3d282dGR5Z3g0c2k5M3Yx
a=ptime:20
a=sendrecv

Обсуждение: Инициация вызова и отсутствие сквозного шифрования.

Распространенная проблема с защищенными носителями заключается в том, что обмен ключами может не завершиться при поступлении первого медиа-пакета. Чтобы избежать первоначальных щелчков, эти пакеты необходимо отбросить. Обычно это короткий период времени (менее 100 мс), так что это не является серьезной проблемой.

Метод SDES не обеспечивает сквозное шифрование мультимедиа. Например, если пользователь A разговаривает с пользователем B через прокси-сервер P, SDES позволяет согласовывать ключи между A и P или между B и P, но не между A и B. Для сквозной безопасности мультимедиа вы должны сначала установить доверительные отношения с другой стороной. Если вы используете для этого доверенное промежуточное звено, задержка установления вызова значительно увеличится, что затрудняет работу таких приложений, как «нажми и говори». Если вы делаете это в одноранговой сети, вам может быть сложно идентифицировать другую сторону. Например, ваш оператор может реализовать архитектуру B2BUA и играть роль другой стороны, так что у вас по-прежнему не будет сквозной безопасности. Новые современные протоколы, такие как ZRTP , предлагают сквозное шифрование для вызовов SIP/RTP.

См. также

• MIKEY Метод обмена ключами
• ZRTP Предложение по сквозному обмену ключами
• DTLS-SRTP Стандарт IETF Сквозной обмен ключами

Внешние ссылки

• Презентация о различных методах обмена ключами ( формат Microsoft PowerPoint .)