Archive for June, 2011

TVRA == Threat Vulnerability and Risk Analysis

A study on IMS, I am just posting here the picture. The full article belongs to the nice people below  🙂

Dong Wang, Chen Liu, Model-based Vulnerability Analysis of IMS Network, Journal of Networks, Vol. 4, No. 4, June 2009

Advertisements

Carte pentru Copii

Posted: June 3, 2011 in promote
Tags:

Pentru ca a fost Ziua Copilului si pentru ca avem o familie de kinderi saracutzi, azi am strans bani si am cumparat carti pentru copiii nostri 🙂

http://miaschildren.org/

Si pentru ca echipa mea a fost mai mereu super ocupata si nu ne-am mobilizat la timp, azi cativa colegi au plecat frumusel cu banii spre librariile si anticariatele din centru si s-au intors cu o cutie plina de carti frumoase. Singura obiectie a noastra a fost ca dintre toti dezvoltatorii nostri super tari pe Security si 4G si VoIP, nu a reusit niciunul sa cumpere o carte de programare 😛

Lately I had the opportunity to work again with the VoIP team. Besides the fact that I remember the good old days when I was the stupidest member of the team and I super super enjoyed learning in a fast manner from my VoIP guru colleagues, I really enjoyed getting in touch again with this wonderful technology.

I am moving towards a managerial/sales position, but moments like this re-confirm to me that I am truly happy when I do 1000% super technical stuff. I love mathematics and cryptography and working with super technical people. I am just happy to do this

Secure Real-time Transport Protocol – RFC 3711 is a pretty classic transport protocol for VoIP packets. It can be used as a stand-alone protocol, which case it should have some out of band ways of defining the encryption and authentication keys. Also, these keys can be dynamically negotiated via SDP – Security Description for Media Streams – RFC 4568.

Basically there are 3 crypto suites that can be used to encrypt the RTP payload:

AES_CM_128_HMAC_SHA1_80

AES_CM_128_HMAC_SHA1_32

AES_F8_128_HMAC_SHA1_80

These are classic crypto suites, but each implementation may use variations of these ones. I wouldn’t say that you can define your own 3DES crypto suite for securing RTP packets, but at least you can use your own key length for authenticating the packets.

Encryption either uses AES in Counter Mode or in F8. I never used F8, so I won’t talk about it right now 🙂

Authentication uses a hash based message authentication code, having SHA1 as a hash function.

And, as we all know, the SHA1 produces an output of 160 bits.

The nice people from IETF show us how the SRTP packet is supposed to look like:

        0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+
     |V=2|P|X|  CC   |M|     PT      |       sequence number         | |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
     |                           timestamp                           | |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
     |           synchronization source (SSRC) identifier            | |
     +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ |
     |            contributing source (CSRC) identifiers             | |
     |                               ....                            | |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
     |                   RTP extension (OPTIONAL)                    | |
   +>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
   | |                          payload  ...                         | |
   | |                               +-------------------------------+ |
   | |                               | RTP padding   | RTP pad count | |
   +>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+
   | ~                     SRTP MKI (OPTIONAL)                       ~ |
   | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
   | :                 authentication tag (RECOMMENDED)              : |
   | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
   |                                                                   |
   +- Encrypted Portion*                      Authenticated Portion ---+

In SDP (or otherwise via out of band methods), the sender and receiver exchange master keys in order to have a cryptographic base for VoIP packets encryption. The keys are series of bits and are not directly used for encryption. They are master keys out of which each party derives symmetrical sessions keys used for the actual RTP encryption. Usually the master “key” that is exchanged between parties also contains a salt value, used for randomization at the session keys generation and also in re-keying. Although this value is not mandatory, it is strongly recommended, as it provides enough randomization to protect against off-line dictionary attacks on the session keys.

The optional MKI (Message Key Identified) header has a configurable length (it usually is 4B) and it is used by sender and received to properly identify the master key used for the current stream – this is also used in re-keying.

The authentication tag, or n_tag – the way it’s called, contains the authentication data. This is a recommended field, as is used when the packet is also authenticated (not only encrypted). The RTP packet can be only encrypted – null authentication, null-encrypted and authenticated and both encrypted and authenticated (when the encryption is done before authentication). This n_tag contains the authentication data, providing protection against replay attacks.

Intrinsic to the SRTP there is no way of specifying the keys lifetime. This is either pre-configured on the RTP endpoints, or it is negotiated in the SDP header. This lifetime is specified (at least to my understanding) in terms of packets: how many packets the endpoint is supposed to encrypt using a particular session key, before that key is no longer considered safe to use.

If we are to consider a call-control scenario, my SDP would look something like this:

 a=crypto:1 AES_CM_128_HMAC_SHA1_80
      inline:PS1uQCVeeCFCanVmcjkpPywjNWhcYD0mXXtxaVBR|2^20|1:32

where:

– the algorithm used is AES in Counter Mode, using a 128b key and HMAC-SHA1 authentication key, out of which it uses only 80b of the master key that follows

– the master key is what follows after the “inline” keyword:

PS1uQCVeeCFCanVmcjkpPywjNWhcYD0mXXtxaVBR

meaning that fancy string

– also, that fancy string may or may not contain the salt also within it

– the 2^20 is the lifetime in terms of packets to be encrypted before a new session key must be generated

– the 1:32 is the MKI: value is “1” and the number of  bits used for representing it is “32”; this can also be expressed as “1:4” meaning: value 1 for MKI and 4B

The RTP packets would have a “trailer” containing the MKI and the n_tag.

Let’s take a simple example of a G711 U-Law, 20ms p-time (meaning 160B per frame) codec, which is encrypted as above.

The total number of Bytes in the UDP packet would be 224, out of which, for RTP we have 180 B:

– 12 B RTP header

– 160 B payload

– 4 B MKI

– 4 B AuthTag

The SIP SDP would look like this:

SDP

The RTP would look like this:

srtp

Happy securing stuff to everybody!