Chromium Code Reviews
chromiumcodereview-hr@appspot.gserviceaccount.com (chromiumcodereview-hr) | Please choose your nickname with Settings | Help | Chromium Project | Gerrit Changes | Sign out
(187)

Side by Side Diff: srtp/doc/intro.txt

Issue 2344973002: Update libsrtp to version 2.0 (Closed)
Patch Set: Add '.' back to include_dirs Created 4 years, 2 months ago
Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.
Jump to:
View unified diff | Download patch
« no previous file with comments | « srtp/doc/header.template ('k') | srtp/doc/references.txt » ('j') | no next file with comments »
Toggle Intra-line Diffs ('i') | Expand Comments ('e') | Collapse Comments ('c') | Show Comments Hide Comments ('s')
OLDNEW
(Empty)
1 /**
2
3 @mainpage Introduction to libSRTP
4
5 This document describes libSRTP, the Open Source Secure RTP library
6 from Cisco Systems, Inc. RTP is the Real-time Transport Protocol, an
7 IETF standard for the transport of real-time data such as telephony,
8 audio, and video, defined by RFC 3550. Secure RTP (SRTP) is an RTP
9 profile for providing confidentiality to RTP data and authentication
10 to the RTP header and payload. SRTP is an IETF Proposed Standard,
11 defined in RFC 3711, and was developed in the IETF Audio/Video
12 Transport (AVT) Working Group. This library supports all of the
13 mandatory features of SRTP, but not all of the optional features. See
14 the @ref Features section for more detailed information.
15
16 This document is organized as follows. The first chapter provides
17 background material on SRTP and overview of libSRTP. The following
18 chapters provide a detailed reference to the libSRTP API and related
19 functions. The reference material is created automatically (using the
20 doxygen utility) from comments embedded in some of the C header
21 files. The documentation is organized into modules in order to improve
22 its clarity. These modules do not directly correspond to files. An
23 underlying cryptographic kernel provides much of the basic
24 functionality of libSRTP, but is mostly undocumented because it does
25 its work behind the scenes.
26
27 @section LICENSE License and Disclaimer
28
29 libSRTP is distributed under the following license, which is included
30 in the source code distribution. It is reproduced in the manual in
31 case you got the library from another source.
32
33 @latexonly
34 \begin{quote}
35 Copyright (c) 2001-2005 Cisco Systems, Inc. All rights reserved.
36
37 Redistribution and use in source and binary forms, with or without
38 modification, are permitted provided that the following conditions
39 are met:
40 \begin{itemize}
41 \item Redistributions of source code must retain the above copyright
42 notice, this list of conditions and the following disclaimer.
43 \item Redistributions in binary form must reproduce the above
44 copyright notice, this list of conditions and the following
45 disclaimer in the documentation and/or other materials provided
46 with the distribution.
47 \item Neither the name of the Cisco Systems, Inc. nor the names of its
48 contributors may be used to endorse or promote products derived
49 from this software without specific prior written permission.
50 \end{itemize}
51 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
52 "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
53 LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
54 FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
55 COPYRIGHT HOLDERS OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT,
56 INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
57 (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
58 SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
59 HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
60 STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
61 ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
62 OF THE POSSIBILITY OF SUCH DAMAGE.
63 \end{quote}
64 @endlatexonly
65
66 @section Features Supported Features
67
68 This library supports all of the mandatory-to-implement features of
69 SRTP (as defined by the most recent Internet Draft). Some of these
70 features can be selected (or de-selected) at run time by setting an
71 appropriate policy; this is done using the structure srtp_policy_t.
72 Some other behaviors of the protocol can be adapted by defining an
73 approriate event handler for the exceptional events; see the @ref
74 SRTPevents section.
75
76 Some options that are not included in the specification are supported.
77 Most notably, the TMMH authentication function is included, though it
78 was removed from the SRTP Internet Draft during the summer of 2002.
79
80
81 @latexonly
82 Some options that are described in the SRTP specification are not
83 supported. This includes
84 \begin{itemize}
85 \item the Master Key Index (MKI),
86 \item key derivation rates other than zero,
87 \item the cipher F8,
88 \item anti-replay lists with sizes other than 128,
89 \item the use of the packet index to select between master keys.
90 \end{itemize}
91 @endlatexonly
92
93 The user should be aware that it is possible to misuse this libary,
94 and that the result may be that the security level it provides is
95 inadequate. If you are implementing a feature using this library, you
96 will want to read the Security Considerations section of the Internet
97 Draft. In addition, it is important that you read and understand the
98 terms outlined in the @ref LICENSE section.
99
100
101 @section Installing Installing and Building libSRTP
102
103 @latexonly
104
105 To install libSRTP, download the latest release of the distribution
106 from \texttt{srtp.sourceforge.net}. The format of the names of the
107 distributions are \texttt{srtp-A.B.C.tgz}, where \texttt{A} is the
108 version number, \texttt{B} is the major release number, \texttt{C} is
109 the minor release number, and \texttt{tgz} is the file
110 extension\footnote{The extension \texttt{.tgz} is identical to
111 \texttt{tar.gz}, and indicates a compressed tar file.} You probably
112 want to get the most recent release. Unpack the distribution and
113 extract the source files; the directory into which the source files
114 will go is named \texttt{srtp}.
115
116 libSRTP uses the GNU \texttt{autoconf} and \texttt{make}
117 utilities\footnote{BSD make will not work; if both versions of make
118 are on your platform, you can invoke GNU make as \texttt{gmake}.}. In
119 the \texttt{srtp} directory, run the configure script and then make:
120 \begin{verbatim}
121 ./configure [ options ]
122 make
123 \end{verbatim}
124 The configure script accepts the following options:
125 \begin{quote}
126 \begin{description}
127 \item[--help] provides a usage summary.
128 \item[--disable-debug] compiles libSRTP without the runtime
129 dynamic debugging system.
130 \item[--enable-generic-aesicm] compile in changes for ismacryp
131 \item[--enable-syslog] use syslog for error reporting.
132 \item[--disable-stdout] diables stdout for error reporting.
133 \item[--enable-console] use \texttt{/dev/console} for error reporting
134 \item[--gdoi] use GDOI key management (disabled at present).
135 \end{description}
136 \end{quote}
137
138 By default, dynamic debugging is enabled and stdout is used for
139 debugging. You can use the configure options to have the debugging
140 output sent to syslog or the system console. Alternatively, you can
141 define ERR\_REPORTING\_FILE in \texttt{include/conf.h} to be any other
142 file that can be opened by libSRTP, and debug messages will be sent to
143 it.
144
145 This package has been tested on the following platforms: Mac OS X
146 (powerpc-apple-darwin1.4), Cygwin (i686-pc-cygwin), Solaris
147 (sparc-sun-solaris2.6), RedHat Linux 7.1 and 9 (i686-pc-linux), and
148 OpenBSD (sparc-unknown-openbsd2.7).
149
150
151 @endlatexonly
152
153 @section Applications Applications
154
155 @latexonly
156
157 Several test drivers and a simple and portable srtp application are
158 included in the \texttt{test/} subdirectory.
159
160 \begin{center}
161 \begin{tabular}{ll}
162 \hline
163 Test driver & Function tested \\
164 \hline
165 kernel\_driver & crypto kernel (ciphers, auth funcs, rng) \\
166 srtp\_driver & srtp in-memory tests (does not use the network) \\
167 rdbx\_driver & rdbx (extended replay database) \\
168 roc\_driver & extended sequence number functions \\
169 replay\_driver & replay database \\
170 cipher\_driver & ciphers \\
171 auth\_driver & hash functions \\
172 \hline
173 \end{tabular}
174 \end{center}
175
176 The app rtpw is a simple rtp application which reads words from
177 /usr/dict/words and then sends them out one at a time using [s]rtp.
178 Manual srtp keying uses the -k option; automated key management
179 using gdoi will be added later.
180
181 The usage for rtpw is
182
183 \texttt{rtpw [[-d $<$debug$>$]* [-k $<$key$>$ [-a][-e]] [-s | -r] dest\_ip
184 dest\_port] | [-l]}
185
186 Either the -s (sender) or -r (receiver) option must be chosen. The
187 values dest\_ip, dest\_port are the IP address and UDP port to which
188 the dictionary will be sent, respectively. The options are:
189 \begin{center}
190 \begin{tabular}{ll}
191 -s & (S)RTP sender - causes app to send words \\
192 -r & (S)RTP receive - causes app to receive words \\
193 -k $<$key$>$ & use SRTP master key $<$key$>$, where the
194 key is a hexadecimal value (without the
195 leading "0x") \\
196 -e & encrypt/decrypt (for data confidentiality)
197 (requires use of -k option as well)\\
198 -a & message authentication
199 (requires use of -k option as well) \\
200 -l & list the available debug modules \\
201 -d $<$debug$>$ & turn on debugging for module $<$debug$>$ \\
202 \end{tabular}
203 \end{center}
204
205 In order to get a random 30-byte value for use as a key/salt pair, you
206 can use the \texttt{rand\_gen} utility in the \texttt{test/}
207 subdirectory.
208
209 An example of an SRTP session using two rtpw programs follows:
210
211 \begin{verbatim}
212 [sh1] set k=`test/rand_gen -n 30`
213 [sh1] echo $k
214 c1eec3717da76195bb878578790af71c4ee9f859e197a414a78d5abc7451
215 [sh1]$ test/rtpw -s -k $k -ea 0.0.0.0 9999
216 Security services: confidentiality message authentication
217 set master key/salt to C1EEC3717DA76195BB878578790AF71C/4EE9F859E197A414A78D5ABC 7451
218 setting SSRC to 2078917053
219 sending word: A
220 sending word: a
221 sending word: aa
222 sending word: aal
223 sending word: aalii
224 sending word: aam
225 sending word: Aani
226 sending word: aardvark
227 ...
228
229 [sh2] set k=c1eec3717da76195bb878578790af71c4ee9f859e197a414a78d5abc7451
230 [sh2]$ test/rtpw -r -k $k -ea 0.0.0.0 9999
231 security services: confidentiality message authentication
232 set master key/salt to C1EEC3717DA76195BB878578790AF71C/4EE9F859E197A414A78D5ABC 7451
233 19 octets received from SSRC 2078917053 word: A
234 19 octets received from SSRC 2078917053 word: a
235 20 octets received from SSRC 2078917053 word: aa
236 21 octets received from SSRC 2078917053 word: aal
237 ...
238 \end{verbatim}
239
240
241 @endlatexonly
242
243
244 @section Review Secure RTP Background
245
246 In this section we review SRTP and introduce some terms that are used
247 in libSRTP. An RTP session is defined by a pair of destination
248 transport addresses, that is, a network address plus a pair of UDP
249 ports for RTP and RTCP. RTCP, the RTP control protocol, is used to
250 coordinate between the participants in an RTP session, e.g. to provide
251 feedback from receivers to senders. An @e SRTP @e session is
252 similarly defined; it is just an RTP session for which the SRTP
253 profile is being used. An SRTP session consists of the traffic sent
254 to the SRTP or SRTCP destination transport addresses. Each
255 participant in a session is identified by a synchronization source
256 (SSRC) identifier. Some participants may not send any SRTP traffic;
257 they are called receivers, even though they send out SRTCP traffic,
258 such as receiver reports.
259
260 RTP allows multiple sources to send RTP and RTCP traffic during the
261 same session. The synchronization source identifier (SSRC) is used to
262 distinguish these sources. In libSRTP, we call the SRTP and SRTCP
263 traffic from a particular source a @e stream. Each stream has its own
264 SSRC, sequence number, rollover counter, and other data. A particular
265 choice of options, cryptographic mechanisms, and keys is called a @e
266 policy. Each stream within a session can have a distinct policy
267 applied to it. A session policy is a collection of stream policies.
268
269 A single policy can be used for all of the streams in a given session,
270 though the case in which a single @e key is shared across multiple
271 streams requires care. When key sharing is used, the SSRC values that
272 identify the streams @b must be distinct. This requirement can be
273 enforced by using the convention that each SRTP and SRTCP key is used
274 for encryption by only a single sender. In other words, the key is
275 shared only across streams that originate from a particular device (of
276 course, other SRTP participants will need to use the key for
277 decryption). libSRTP supports this enforcement by detecting the case
278 in which a key is used for both inbound and outbound data.
279
280
281 @section Overview libSRTP Overview
282
283 libSRTP provides functions for protecting RTP and RTCP. RTP packets
284 can be encrypted and authenticated (using the srtp_protect()
285 function), turning them into SRTP packets. Similarly, SRTP packets
286 can be decrypted and have their authentication verified (using the
287 srtp_unprotect() function), turning them into RTP packets. Similar
288 functions apply security to RTCP packets.
289
290 The typedef srtp_stream_t points to a structure holding all of the
291 state associated with an SRTP stream, including the keys and
292 parameters for cipher and message authentication functions and the
293 anti-replay data. A particular srtp_stream_t holds the information
294 needed to protect a particular RTP and RTCP stream. This datatype
295 is intentionally opaque in order to better seperate the libSRTP
296 API from its implementation.
297
298 Within an SRTP session, there can be multiple streams, each
299 originating from a particular sender. Each source uses a distinct
300 stream context to protect the RTP and RTCP stream that it is
301 originating. The typedef srtp_t points to a structure holding all of
302 the state associated with an SRTP session. There can be multiple
303 stream contexts associated with a single srtp_t. A stream context
304 cannot exist indepent from an srtp_t, though of course an srtp_t can
305 be created that contains only a single stream context. A device
306 participating in an SRTP session must have a stream context for each
307 source in that session, so that it can process the data that it
308 receives from each sender.
309
310
311 In libSRTP, a session is created using the function srtp_create().
312 The policy to be implemented in the session is passed into this
313 function as an srtp_policy_t structure. A single one of these
314 structures describes the policy of a single stream. These structures
315 can also be linked together to form an entire session policy. A linked
316 list of srtp_policy_t structures is equivalent to a session policy.
317 In such a policy, we refer to a single srtp_policy_t as an @e element.
318
319 An srtp_policy_t strucutre contains two crypto_policy_t structures
320 that describe the cryptograhic policies for RTP and RTCP, as well as
321 the SRTP master key and the SSRC value. The SSRC describes what to
322 protect (e.g. which stream), and the crypto_policy_t structures
323 describe how to protect it. The key is contained in a policy element
324 because it simplifies the interface to the library. In many cases, it
325 is desirable to use the same cryptographic policies across all of the
326 streams in a session, but to use a distinct key for each stream. A
327 crypto_policy_t structure can be initialized by using either the
328 crypto_policy_set_rtp_default() or crypto_policy_set_rtcp_default()
329 functions, which set a crypto policy structure to the default policies
330 for RTP and RTCP protection, respectively.
331
332 @section Example Example Code
333
334 This section provides a simple example of how to use libSRTP. The
335 example code lacks error checking, but is functional. Here we assume
336 that the value ssrc is already set to describe the SSRC of the stream
337 that we are sending, and that the functions get_rtp_packet() and
338 send_srtp_packet() are available to us. The former puts an RTP packet
339 into the buffer and returns the number of octets written to that
340 buffer. The latter sends the RTP packet in the buffer, given the
341 length as its second argument.
342
343 @verbatim
344 srtp_t session;
345 srtp_policy_t policy;
346 uint8_t key[30];
347
348 // initialize libSRTP
349 srtp_init();
350
351 // set policy to describe a policy for an SRTP stream
352 crypto_policy_set_rtp_default(&policy.rtp);
353 crypto_policy_set_rtcp_default(&policy.rtcp);
354 policy.ssrc = ssrc;
355 policy.key = key;
356 policy.next = NULL;
357
358 // set key to random value
359 crypto_get_random(key, 30);
360
361 // allocate and initialize the SRTP session
362 srtp_create(&session, &policy);
363
364 // main loop: get rtp packets, send srtp packets
365 while (1) {
366 char rtp_buffer[2048];
367 unsigned len;
368
369 len = get_rtp_packet(rtp_buffer);
370 srtp_protect(session, rtp_buffer, &len);
371 send_srtp_packet(rtp_buffer, len);
372 }
373 @endverbatim
374
375 @section ISMAcryp ISMA Encryption Support
376
377 The Internet Streaming Media Alliance (ISMA) specifies a way
378 to pre-encrypt a media file prior to streaming. This method
379 is an alternative to SRTP encryption, which is potentially
380 useful when a particular media file will be streamed
381 multiple times. The specification is available online
382 at http://www.isma.tv/specreq.nsf/SpecRequest.
383
384 libSRTP provides the encryption and decryption functions needed for ISMAcryp
385 in the library @t libaesicm.a, which is included in the default
386 Makefile target. This library is used by the MPEG4IP project; see
387 http://mpeg4ip.sourceforge.net/.
388
389 Note that ISMAcryp does not provide authentication for
390 RTP nor RTCP, nor confidentiality for RTCP.
391 ISMAcryp RECOMMENDS the use of SRTP message authentication for ISMAcryp
392 streams while using ISMAcryp encryption to protect the media itself.
393
394
395 */
OLDNEW
« no previous file with comments | « srtp/doc/header.template ('k') | srtp/doc/references.txt » ('j') | no next file with comments »

Powered by Google App Engine
This is Rietveld 408576698