This article first introduces some general informations about authentication, encryption and cryptography concepts. Then TLS and GnuTLS are introduced. Furthermore, how to integrate TLS to SIP stack is introduced. Almost all the contents are from specification
or internet., and the relevant copyright belongs to original author. I put them together for recording and studying.

Acronym and Abbreviation

S/MIME -- Secure Multipurpose Internet Mail Extensions (S/MIME)
PKCS -- Public Key Cryptography Standards
AES -- Advanced Encryption Standard
DES -- Data Encryption Standard
SHA -- Secure Hash Algorithm
MD5 -- Message Digest Algorithm
RSA -- Rivest, Shamir and Adleman (who first publicly described the algorithm)
DSA -- Digital Signature Algorithm
MAC -- Message Authentication Code
CA -- Certificate Authority

Authentication and Encryption

Authentication -- Authentication means identifying the object, for example person, and knowing that the identity of the object is in reality the same as the object claims it to be.

Encryption -- encryption is the process of transforming information (referred to as plaintext) using an algorithm (called cipher) to make it unreadable to anyone except those possessing special knowledge, usually referred to as a key.

IPSec -- Network Layer
It is a protocol suite for securing Internet Protocol (IP) communications by authenticating and encrypting each IP packet of a communication session. Applications do not need to be specifically designed to use IPsec.

TLS/SSL -- Transport Layer
It is used to establish a secure connection between two parties.It must be designed into an application to protect the application protocols.

HTTP Authentication [Basic Authentication(RFC2543), Digest Authentication(RFC3261) ], S/MIME -- Application Layer
HTTP Authentication is used to authenticate user using username and password.
S/MIME is a way for SIP to encrypt SIP message body. SIP headers can also be encapsulated in S/MIME body, so that integrity of headers can be checked with outer SIP headers. Certifications are also involved in S/MIME scheme.

Cryptography

Symmetric Encryption: DES, Triple DES, AES(Advanced Encryption Standard)

Asymmetric Encryption: RSA, DSA

Hash Functions: MD5, SHA1

Digital Signature: Consists of 3 algorithms: Key generation, signing algorithm, signature verifying algorithm.

Blind Digital Signature: Allow a participant to sign a message without knowing what the message is. This is called a blind signature. Used in Voting and Digital Cash. E.g. consider 3 roles in anonymous voting. Authority -- determine a Voter is the person having
voting right, but he cannot look into a Voter’s ticket. Voter -- has the right to vote. Counter -- checking tickets and getting the final result. Suppose the ticket is t. Voter sends blind(t) to Authority. Authority verifies Voter’s correctness and sign it
using his private key, and the result is sign(blind(t)). Authority send back the signed message to the Voter. Voter unblind the signed message, and the result is unblind(sign(blind(t)))==sign(t). The Voter sends sign(t) anonymously to the Counter. Counter
receives the sign(t) and he knows this ticket is from right person.

Group Digital Signature: is a method for allowing a member of a group to anonymously sign a message on behalf of the group. E.g. several companies form a group to apply a project from the government. They respectively sign their documents and sent them to the
government. The government knows the documents are from the group with the group’s public key, but it does not know which company a document belongs to. After the government chooses a document, group members can know which company the chosen document belongs
to. A Trusted Authoriy can be involved in the process.

Digital Certificate: Use digital signature to bind a public key with an identity. The certificate can be used to verify that a public key belongs to an individual.

TLS Concepts

TLS: “Transport Layer Security” and is the successor of SSL, the Secure Sockets Layer protocol. TLS is used to establish a secure connection between two parties.

Functions: Confidentiality and Authentication

TLS Layers:

Record Protocol: symmetric encryption, data authenticity, and optionally compression. (gnutls_record_recv, gnutls_record_send, gnutls_record_get_direction)

Alert protocol:  offers some signaling to the other protocols. It can help informing the peer for the cause of failures and other error conditions. (gnutls_alert_send, gnutls_alert_get)

Handshake protocol: is responsible for the security parameters’ negotiation, the initial key exchange and authentication. (gnutls_handshake).

Application Protocol: TLS Record Protocol user.

Handshake

When a TLS client and server first start communicating, they agree on a protocol version, select cryptographic algorithms, optionally authenticate each other, and use public-key encryption techniques to generate shared secrets.

1. Establish a TCP connection
2. Set Handshake Parameters
3. Handshake(gnutls_handshake).

The ClientHello and ServerHello establish the following attributes: Protocol Version, Session ID, Cipher Suite, and Compression Method. Additionally, two random values are generated and exchanged: ClientHello.random and ServerHello.random.

The actual key exchange uses up to four messages: the server Certificate, the ServerKeyExchange, the client Certificate, and the ClientKeyExchange.

Authentication Scenarios

No Authentication: In this case, TLS provides encryption functions, and does not provide authentication functions.

Target-only Authentication: In the target-only authentication scenario, the target presents its own certificate to the client during the SSL/TLS handshake, so that the client can verify the target's identity. In this scenario, therefore, the target is authentic
to the client, but the client is not authentic to the target.

Mutual Authentation: The target presents its own certificate to the client and the client presents its own certificate to the target during the SSL/TLS handshake, so that both the client and the target can verify each other's identity. In this scenario, therefore,
the target is authentic to the client and the client is authentic to the target.

TLS Authentication Method

Certificate Authentication

X.509 Trust model:

X.509 certificates contain the public parameters, of a public key algorithm, and an authority’s signature, which proves the authenticity of the parameters.
The X.509 protocols rely on a hierarchical trust model.

Open PGP Trust model:

OpenPGP keys also contain public parameters of a public key algorithm, and signatures from several other parties.
The OpenPGP key authentication relies on a distributed trust model, called the “web of trust”. The “web of trust” uses a decentralized system of trusted introducers, which are the same as a CA. OpenPGP allows anyone to sign anyone’s else public key.

Anonymous Authentication

The anonymous key exchange performs encryption but there is no indication of the identity of the peer. This kind of authentication is vulnerable to a man in the middle attack, but this protocol can be used even if there is no prior communication and trusted
parties with the peer, or when full anonymity is required.

The key exchange methods for anonymous authentication require Diffie-Hellman parameters to be generated by the server and associated with an anonymous credentials structure.

Diffie–Hellman key exchange (D–H) is a specific method of exchanging keys. It is one of the earliest practical examples of key exchange implemented within the field of cryptography. The Diffie–Hellman key exchange method allows two parties that have no prior
knowledge of each other to jointly establish a shared secret key over an insecure communications channel. This key can then be used to encrypt subsequent communications using a symmetric key cipher. A part of IPSec standard.

The protocol has two system parameters p and g. They are both public and may be used by all the users in a system. Parameter p is a prime number and parameter g (usually called a generator) is an integer less than p, with the following property: for every number
n between 1 and p-1 inclusive, there is a power k of g such that n = g^k mod p.
 
Suppose Alice and Bob want to agree on a shared secret key using the Diffie-Hellman key agreement protocol. They proceed as follows: First, Alice generates a random private value a and Bob generates a random private value b. Both a and b are drawn from the
set of integers . Then they derive their public values using parameters p and g and their private values. Alice's public value is g^a mod p and Bob's public value is g^b mod p. They then exchange their public values. Finally, Alice computes g^(ab) = (g^b)^a
mod p, and Bob computes g^(ba) = (g^a)^b mod p. Since g^(ab) = g^(ba) = k, Alice and Bob now have a shared secret key k.

The protocol depends on the discrete logarithm problem for its security. It assumes that it is computationally infeasible to calculate the shared secret key k = g^(ab) mod p given the two public values g^a mod p and g^b mod p when the prime p is sufficiently
large.

GnuTLS

GnuTLS is a implementation of TLS protocol.

API

Following is not an exhaustive list of APIs.

Record Protocol:
gnutls_record_recv, gnutls_record_send, gnutls_record_get_direction,

Alert Protocol:
gnutls_alert_send, gnutls_alert_get,

Handshake Protocol:
gnutls_handshake

Parameter Setting:
gnutls_anon_allocate_server_credentials
gnutls_anon_allocate_client_credentials
gnutls_certificate_allocate_credentials
gnutls_anon_set_server_dh_params
gnutls_certificate_set_dh_params
gnutls_certificate_set_x509_keyfile//certificateFile and privateKeyFile
gnutls_certificate_set_x509_trust_file//ca certificate file
gnutls_certificate_set_x509_crl_file//crlFile
gnutls_dh_set_prime_bits

Certificate Files

ca-private-key-file -- Private key of a CA. CA uses its private key to issue certificate of a host.

ca-certificate-file -- CA itself has a certificate-file, and is signed by itself(Root CA) or signed by upper level CA. The ca-certificate-file is used by a host to verify another host’s certificate issued by the CA.

host-certificate-file -- A certificate issued by a CA, used to show that the host owns the public-key in the certificate and the relevant private-key which keeps secret.

host-private-key-file -- Private key of a host. During TLS handshake, private key is used to encrypt/decrypt parameters if X.509 certificate is used.

crl-file -- Certificate-Revocation-List-File. A CA generate the file to withdraw a former issued certificate.

Content in a X.509 Certificate

Following are not an exhausted list.
Serial Number
Algorithm ID
Issuer
Validity
Not Before
Not After
Subject
Subject Public Key Info
Public Key Algorithm
Subject Public Key
Certificate Signature Algorithm
Certificate Signature

certtool

certtool is a tool provided by GNU to facilitate using GnuTLS. Step3 and Step8 both generate a certificate. In reality, CA does not need to know private-key of a host, so the Step8 way to generate a certificate is normal.

1) Create a private key:
certtool --generate-privkey --outfile key.pem

2) Create a self-signed certificate
certtool --generate-self-signed --load-privkey ca-private-key.pem --outfile ca-cert.pem

3) Generate a certificate using the private key
certtool --generate-certificate --load-privkey host-private-key.pem --outfile host-cert.pem --load-ca-certificate ca-cert.pem --load-ca-privkey ca-private-key.pem

4) Create CRL
certtool --generate-crl --load-ca-privkey ca-private-key.pem --load-ca-certificate ca-cert.pem --load-certificate cert-to-be-revocated.pem --outfile crl.pem

5) Verify a CRL
certtool --verify-crl --load-ca-certificate ca-cert.pem <crl.pem

6) View the certificate information
certtool --certificate-info --infile cert.pem

7) Create a certificate request
certtool --generate-request --load-privkey host-private-key.pem --outfile request.pem

8) Generate a certificate using request
certtool --generate-certificate --load-request request.pem --outfile cert.pem --load-ca-certificate ca-cert.pem --load-ca-privkey ca-key.pem

SIP Authentication and Confidentiality using TLS

Attacks

Registration Hijacking -- ‘From’ header of a SIP REGISTER request can be modified arbitrarily by the owner of a UA. An attacker may de-register all all existing contacts for a URI, and then register their own device as the appropriate contact address.

Impersoning a Server -- Prevention of this threat requires a means by which UAs can authenticate the servers to whom they send requests.

Tampering with Message Bodies -- SDP may be changed by PROXY servers.

Tearing down sessions -- Once a dialog is established, A third party attacker captures some initial messages to learn parameters of the session, such as From, To, CallID and so forth. The attacker can forge a BYE to tear down the dialog.

Denial of Service -- If REGISTER requests are not properly authenticated and authorized by registras, a number of denial-of-service attacks are apt open up.

Open/Close/Send/Recv TLS session

SIP is a layered protocol. The transport layer includes TCP, UDP, SCTP and TLS. SIP stack should include functionalities of create/close a TLS session, accept a TLS session, send/receive over TLS session.

Determine when TLS session is used

When SIP stack behaves as client side, if UAC specifies SIPS URI in a request, TLS transport should be used to send the request. When SIP stack behaves as service side, if UAS receives messages from peer sides through TLS session, it indicates that TLS transport
is used.

Message Headers Changes

URI Scheme: Some headers which includes a URI, URI scheme changes from SIP to SIPS. E.g. the Request Uri, Route, VIA, Record-Route. E.g. sips:1212@gateway.com.

transport parameter in URI: in the SIPS URI scheme, transport is independent of TLS, and thus sips:alice@atlanta.com;transport=tcp and sips:alice@atlanta.com;transport=sctp are both valid (although note that UDP is not a valid transport for SIPS). The use of
transport=tls has consequently been deprecated.

VIA: VIA is composed of Scheme/Version/TransportProtocol. When a request is sent to a SIPS URI, the Scheme still indicates “SIP”, and the transport protocol is TLS. E.g. Via: SIP/2.0/TLS erlang.bell-telephone.com:5060;branch=z9hG4bK87asdks7

Managing Keys and Certificates

This is a issue that should be considered.
Further Relevant Topics
Using SIP with TLS only secures the call signalling, and doesn't do anything for the audio (media). There are really three components to securing a voice connection:

1. Use SIP and TLS. This makes sure that the parameters (numbers, calling name etc) that you negociate with the remote end cannot be captured, and it means that people that don't have the key can't hijack your facilities.

2. Use Secure RTP (SRTP). This encrypts the media, so that even if someone captures all of your audio packets (for example with wireshark), they still cannot hear it as speech. The keys used by SRTP are exchanged during the signalling phase, so normally if
you use SRTP then you also secure the signalling with TLS.

3. The keys themselves. Security keys (like passwords) control access to the facilities and allow decoding only for those that are permitted. Key exchange or key distribution is still a problem that is being discussed today, i.e. how can you securely distribute
new keys to every phone in your network, so that they can successfully 'log on'? You don't want to have to send an email to everyone with their 'password' which somehow needs to be configured into the phone. In a completely open VoIP community, you need a
keying system such that anyone can call any other and enjoy a secure connection without previously exchanging keys in any way.

Reference

[1]http://en.wikipedia.org/wiki/Transport_Layer_Security
[2]gnutls.pdf
[3]rfc5246 TLS
[4]http://www.ietf.org/proceedings/65/slides/sip-5.pdf
[6]rfc3261 SIP
[7]http://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange
[8]http://docs.google.com/viewer?a=v&pid=sites&srcid=bmV0aXAuY29tfGhvbWV8Z3g6NTA2NTM0YmNhZjRhZDYzZQ Diffie–Hellman key exchange: A Non-Mathematician’s Explanation
[9] http://www.rsa.com/rsalabs/node.asp?id=2248
[10]http://en.wikipedia.org/wiki/Ipsec

http://fusesource.com/docs/esb/4.3/amq_security/SSL-UseCerts.html

[11]http://www.site.uottawa.ca/~bob/gradstudents/DigestAuthenticationReport.pdf
[12]http://www.voipuser.org/forum_topic_8326.html
[13]http://www.techrepublic.com/article/make-a-sip-based-voip-network-more-secure/6145231
[14]http://en.wikipedia.org/wiki/IP_Multimedia_Subsystem