Asterisk Encrypted Authentication For Clients

Home » Asterisk Users » Asterisk Encrypted Authentication For Clients
Asterisk Users 9 Comments

Hello, I am searching for a solution to encrypt authentication from Asterisk server to clients. Searching srtp seem to encrypt traffic, I just want client authentication with encryption. Can someone point to the right direction? has anybody used ZRTP? experience with ZRTP?


9 thoughts on - Asterisk Encrypted Authentication For Clients

  • Hi Motty,

    Isn’t the whole point of the nonce in a SIP registration to ensure the secret doesn’t go on the wire in plain-text? Is this not enough, or are you looking to hide the username too?

    (if so, fair ‘nuf, just wondering why 🙂


    Ps, if so then I think TLS is the missing part of your equation.

  • You want SIP over TLS. That encrypts the signalling. SRTP and ZRTP
    encrypt the actual voice traffic.



  • Thanks Jeff, I don’t want SIP over TLS. I would like to encrypt password only, I
    suppose over TLS.


  • The password isn’t sent – SIP auth involves a challenge/response with hashing (digest authentication). If that’s all you are interested in, you are already there.



  • Thanks Jeff, just to confirm, password are not sent in plain text? I
    want to safeguard against man in the middle attacks, sniffing traffic of clients.


  • That’s correct.

    The way it works is:

    – Both the client, and Asterisk, know what the password is.

    – The client sends a SIP message which would require authorization
    (a register or invite, for example). It provides the username
    in the message.

    – The server generates a random “nonce” (basically a big random
    number) and sends it back to the client… basically saying
    “Use this nonce, and your password, to prove who you are.”

    – The client combines the nonce, and the password, and uses the
    combined data as input into a hashing function (I can’t recall
    whether MD-5, SHA-1, or something more modern is used). I
    *think* some of the other details of the original message are
    also included in the hash but don’t recall for certain.

    – The client re-sends the original message, and includes its
    username, the nonce, and the hash. It does not send the
    password at all.

    – The server makes sure that the nonce is is the most recent
    one it sent, and that this is the first time the client has
    sent back that particular nonce. Once that’s certain, the
    server uses the nonce and its copy of the password to
    compute the hash, and compares this with the hash the client

    – If the hashes match, the server “knows” that the client knows
    the correct password (to a very high degree of certainty) and
    it allows the command to proceed. If they don’t match, the
    client doesn’t know the password, and the command is rejected.

    The hash functions that are used, are ones which would make it extremely difficult (months or years of computing time) to figure out what the password is, by breaking the hash algorithm.

    Of course, if a “weak” (short, guessable) password is used, it can be broken by a dictionary attack or brute force – the hash technique can’t defend against this.