SIP Security

1
SIP Security

• BY,
• Vivek Nemarugommula

2
vulnerabilities
Registration Hijacking
3
Proxy Impersonation
4
Message Tampering
5
Session Tear Down
6
Denial of Service (DoS)
7
SIP Security Architecture
8
Digest Authentication

• Sip Provides A challenge-based mechanism for
  authentication that is based on authentication in
  HTTP.
• This scheme is known as Digest authentication due
  to the use of MD5 hashing function on the
  username/password combination
• When a client tries to establish a connection
  with UAS, registrar, or redirect server, the
  server sends the 401 Unauthorized response to
  challenge the identity of a UAC.
• When the client initializes a connection with a
  proxy server, the proxy responds with the 407
  Proxy Authentication Required to challenge the
  UAC.

9
Challenge Based Authentication
10
Digest Authentication Headers

• SIP uses headers for Authentication
• The WWW-Authentication header is used in 401
  response message sent by the server.
• In response to the 401 challenge, the UA should
  include a Authorization header containing the
  credentials in the next request.
• Similarly, the Proxy-Authenticate header is used
  in 407 response message sent by the proxy.

11
Description Of Parameters
12

• After the client receives the 401 or 407
  challenge from the server, it re-submits a
  request with the credentials by including an
  Authorization (in response to 401) or
  Proxy-Authorization (in response to 407) header
  field with request.

13
Parameters in Authorization Header
14
Digest Calculation

• The Method of calculating the Request-Digest is
  as follows
• Default algorithm MD5 is used.

15
Digest Calculation
16
Problems with Digest

• Hash is weak
• Authenticating a request to more than
• one element is problematic
• Leaks hash to elements in the path
• Not well implemented
• In practice, DIGEST is only good for
• authenticating to the first hop

17
Secure MIME (S/MIME)

• SIP messages carry MIME bodies and the MIME
  standard includes mechanisms for securing MIME
  contents to ensure both integrity and
  confidentiality by means of the multipart/signed
  and application/pkcs7-mime MIME types
• Provides end-to-end integrity protection and
  encryption of the body and parts of the message
  header
• X.509 certificates are used to identify the end
  users on the basis of their email addresses which
  are part of the SIP URI
• The signing of MIME bodies is the lesser problem
  since each user is in possession of her private
  key and the user certificate may be forwarded to
  the recipient embedded into the pkcs7-mime or
  pkcs7-signature attachments

18
S/MIME

• On the other hand the encryption of MIME bodies,
  e.g. the Session Description Protocol (SDP)
  payload HJ98 requires the foreknowledge of the
  recipients public key. This key, usually
  certified by X.509 certificate must either be
  pre-fetched from a public directory or may be
  requested from the peer via a special SIP
  message.
• Any mechanisms depending on the existence of
  end-user certificates are seriously limited in
  that there is virtually no consolidated authority
  today that provides certificates for end-user
  applications on a global scale.

19
Protecting the Signaling TLS

• Hop-by-hop transport security
• Typically, endpoints enter into a serverauth
  relationship with a server and authenticate using
  DIGEST

20
Problems With TLS

• Key distribution makes mutual authentication
  impractical (so far)
• Only protects one hop - no assurances of what
  happens beyond that hop

21
SIPS

• Secure sip, like https is to http
• Proxies receiving a sips request are required to
  forward only on secure transports (weakened in
  private domains)
• Not as strong as https - no way to tell if a
  proxy doesnt conform to the requirement

22
Protecting the Media SRTP

• Encrypts individual media packets using a
  symmetric session key.
• Session key must be securely exchanged - current
  recommendation is to use S/MIME in the signaling.

23
The Secure Real-Time Transport Protocol (SRTP)

• Both RTP and RTCP packets can be
  cryptographically secured by the Secure Real-time
  Transport Protocol (SRTP) and the companion
  Secure Real-time Transport Control Protocol
  (SRTCP)
• The Secure RTP Packet Format
• only the RTP payload body (including any RTP
  padding if present) is encrypted.
• The Master Key Identifier (MKI) field is optional
  and identifies the master key from which the
  session keys were derived.
• The 16 bit sequence number already present in the
  RTP packet is used together with a 32 bit
  rollover counter (ROC) which is part of the
  cryptographic context for the SRTP session to
  prevent replay attacks.
• The authentication tag is a cryptographic
  checksum computed over both the header and body
  of the RTP packet.

24
Secure RTP Packet Format
25
The Secure RTCP Packet Format
26
RTCP (continued)

• The RTP control packets are secured in a similar
  way as the RTP packets themselves, one difference
  being that the use of the authentication tag is
  mandatory.
• Otherwise it would be possible for a malevolent
  attacker e.g. to terminate an RTP media stream by
  sending a BYE packet.
• An additional field is the SRTCP index which used
  as a sequence counter preventing replay-attacks.
• The MSB of the index field is used as an
  Encryption flag (E) which is set if the RTCP body
  is encrypted.

27
Default Encryption Algorithms
28
Encryption using AES in counter mode.

• In principle any encryption scheme can be used
  with SRTP.
• As default algorithms the NULL cipher (no
  confidentiality) and the Advanced Encryption
  Standard in Counter Mode (AES-CTR) are defined.
• AES in counter mode acts as a keystream generator
  producing a pseudo-random keystream of arbitrary
  length that is applied in a bit-wise fashion to
  the RTP/RTCP payload by means of a logical XOR
  function, thus working as a classical stream
  cipher.
• In order to work as a pseudo-random generator AES
  is loaded at the start of each RTP/RTCP packet
  with a distinct initialization vector (IV) that
  is derived by hashing a 112 bit salt_key, the
  synchronisation source identifier (SSRC) of the
  media stream, and the packet index.

29
Encryption (continued)

• Encrypting this IV results in an output of 128
  pseudo-random bits.
• By counting the IV up by increments of one as
  many keystream blocks can be generated as are
  required to encrypt the whole RTP/RTPC payload.
• AES used in counter mode instead of the more
  common cipher block chaining mode (CBC) has the
  big advantage that the keystream can be
  precomputed before the payload becomes available
  thus minimizing the delay introduced by
  encryption

30
Default Authentication Algorithm
31
Authentication using HMAC-SHA-1

• The default SRTP message authentication algorithm
  is HMAC-SHA-1 , based on the popular 160 bit
  SHA-1 hash function.
• Cryptographical security is achieved by hashing a
  160 bit secret auth_key into the checksum which
  is then truncated to 80 bits in order to reduce
  the packet overhead and which has the further
  advantage that it hides the complete internal
  state of the hash function.
• In applications where transmission bandwidth is a
  problem the authentication tag might be weakened
  to 32 bits.

32
Session Key Derivation

• The encryption and authentication algorithms
  described earlier both require secret symmetric
  session keys that must be known to all user
  agents participating in a SIP session.
• The SRTP standard offers a partial solution by
  deriving all needed session keys from a common
  master key but leaves open the distribution of
  the master key itself.
• Again the AES block cipher is used in counter
  mode to generate the necessary keying material.
• The pseudo-random generator is loaded with an IV
  that is itself a function of a 112 bit
  master_salt value, a one byte label and a session
  key number .

33
Continued

• By applying the labels 0x00 up to 0x05,
  encryption, authentication and salting keys for
  both SRTP and SRTCP are derived from the same
  master key.
• If a key derivation rate has been defined then
  every time a number of packets equivalent to the
  key derivation rate have been sent, a new set of
  either SRTP or SRTCP session keys are computed.

34
Session Key Derivation (cont)
35
Conclusions

• DIGEST is only good for authenticating to the
  first hop.
• Authenticating a request to more than one element
  is problematic
• S/MIME Suffers from same key distribution issue
  hindering mutual-auth TLS.
• Needs research on improving protection through
  SIP Identity.
• Improving Protection through certificates and
  credentials.

36
References

• SIP Security
• Andreas Steffen, Daniel Kaufmann, Andreas
  Stricker
• http//www.site.uottawa.ca/bob/gradstudents/Diges
  tAuthenticationReport.pdf