3 <title>SILC Protocol White Paper</title>
4 <link rev=made href="mailto:priikone@silcnet.org">
5 <meta name="Author" content="Pekka Riikonen - SILC Project">
6 <meta name="Description"
7 content="SILC - Secure Internet Live Conferencing Protocol">
8 <meta name="Created" content="Version 1.0 / 05 Aug 2001">
10 <body bgcolor="#ffffff">
12 <font face="Helvetica">
17 Chat protocols are very popular on the Internet. They have actually
18 been very popular since the very first chat protocols appeared on the net.
19 The Internet Relay Chat (IRC) was one of the first chat protocols, and quickly
20 gained the status of being the most popular chat on the net. Today, IRC
21 has several competitors from various other so called Instant Messaging (IM)
22 protocols, such as ICQ. However, all of these different chat protocols
23 have something in common; they are all insecure.
26 The security is important feature in applications and protocols in
27 contemporary network environment. The older chat protocols, however have
28 failed to deal with the growing security requirements on the Internet.
29 It is not anymore enough to just provide services, like for example
30 chat services. Now, they need to be secure services.
33 The Secure Internet Live Conferencing (SILC) protocol is a new generation
34 chat protocol which provides full featured conferencing services, just
35 like any other contemporary chat protocol provides. In addition, it
36 provides security by encrypting and authenticating the messages in
37 the network. The security has been the primary goal of the SILC protocol
38 and the protocol has been designed from the day one security in mind.
39 All packets and messages travelling in the SILC Network are always
40 encrypted and authenticated. The network topology is also different
41 from for example IRC network. The SILC network topology attempts to be
42 more powerful and scalable than the IRC network. The basic purpose
43 of the SILC protocol is to provide secure conferencing services.
46 The SILC Protocol have been developed as Open Source project. The
47 protocol specifications are freely available and they have been submitted to
48 the IETF. The very first implementations of the protocol are also already
52 <h1>About This White Paper</h1>
54 The purpose of this white paper is to give short but deep enough introduction
55 to the SILC Protocol. The document describes the purpose of the protocol
56 and how the protocol works in practice. This document is intended for all
57 audience. This document should be easy to understand for non-technical
58 person and still be detailed enough for technically oriented person. See
59 the section <a href="#terms">Terms and Abbreviations</a> for terms used
64 (c) Copyright 2001 Pekka Riikonen
65 (<a href="mailto:priikone at silcnet.org">priikone at silcnet.org</a>)
67 This document is free document; you can redistribute it and/or modify
68 it under the terms of the GNU General Public License as published by
69 the Free Software Foundation; either version 2 of the License, or
70 (at your option) any later version. This document is distributed in
71 the hope that it will be useful, but WITHOUT ANY WARRANTY; without even
72 the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
73 See the GNU General Public License for more details.
77 <h1>SILC Protocol</h1>
80 <img src="silc_network.JPG" alt="SILC Network" align="center" border"0">
86 A client is a piece of software connecting to SILC server. The software
87 is usually run by the end user, a real person that is. The purpose of the
88 clients is to provide the end user an interface to the SILC services.
89 They are used to actually engage the conversations on the SILC Network,
90 and they can be used to execute various SILC commands.
93 The clients are distinquished from other clients by unique Client ID.
94 There cannot be multiple same Client IDs in the SILC Network at the same time.
95 The end user, however does not use Client IDs. The end users usually selects
96 a perferred nickname they want to use, and identifies themself with that
97 nickname to other users on the network. The nicknames are not unique in
98 the SILC Network. There can be multiple same nicknames at the same time
99 on the network. The maximum length for the nickname is 128 characters.
102 Most of the other chat protocols have unique nicknames. This is where SILC
103 differs from most of the other chat protocols. The purpose of this
104 feature is to make IRC style nickname wars obsolete, as no one owns their
105 nickname; there can always be somene else with the same nickname.
108 When client connects to the server the SILC Key Exchange (SKE) protocol and
109 SILC Connection Authentication protocol are executed. The result of the
110 SKE protocol is the session key that the client and server use to secure
111 their communication. All commands, for example, that the client sends
112 to the server are secured with the session key. The session key expires
113 periodically and the rekey process can be executed with or without the
114 Perfect Forward Secrecy (PFS). The connection authentication protocol is
115 used to authenticate the client to the server. The server may allow the
116 client to connect without authentication, or it may require a passphrase or
117 public key encryption based authentication.
124 Servers forms the basis for the SILC Network, by providing a point to which
125 clients may connect. There are two kinds of servers in SILC; normal servers
126 and router servers. The next section describes the function of router
130 Normal servers connect to router server. Normal servers cannot directly
131 connect to other normal servers. Messages that are destined outside the
132 local server are always sent to the router for further routing.
133 The clients usually connect to the normal server, however, clients may
134 connect to router servers as well. The SILC Network diagram above
135 illustrates how normal servers connects to the router server.
138 The servers are distinquished by other servers in the network by unique
139 Server ID. There cannot be multiple same Server IDs in the SILC Network
140 at the same time. The servers keep track of local information. It knows
141 all locally connected clients and it knows all channels that its clients
142 have joined. However, it does not know any global information. It
143 usually does not keep track of global clients, however, it may cache
144 that information if it was queried. The reason for this is that the
145 server does not need to keep global information up to date and thus
146 makes the server faster. They can always query the information from
150 When server connects to its router the SILC Key Exchange (SKE) protocol
151 and the SILC Connection Authentication protocol are executed, just like
152 when client connects to server. The SKE results in to the session key
153 that is used to secure the communication between the server and the
154 router. The connection authentication protocol is used to authenticate
155 the server to the router. The authentication is always based in either
156 passphrase or public key encryption.
163 The router servers are servers that actually handles the message routing
164 in the network. They are, however also normal servers and they do accept
165 client connections. Each of the router in the network is called a cell.
166 The cell can have only one active router and it may have several servers
167 and several clients. The cell, however may have backup routers that can
168 take over the tasks of the primary router if it becomes unreachable.
169 The switch to the backup router should be transparent and only local
170 connections to the primary router are lost. Other connections in the
171 cell are intact, and clients and servers merely experience some lag in
172 the network connection during the switch to the backup router.
175 The normal server knows only local information. Router server on the
176 other hand knows local information and global information. It considers
177 the cell as local and outside cells as global. It knows all the clients
178 connected to the network, all created channels, and all routers and servers
179 in the network. The server may query the global information if it is needed.
180 For example, when client sends WHOIS command, the server may query the
181 information from the router. If the router does not know all the details
182 that the WHOIS command requires it can query the information from a router
183 or a server which knows all the details. It may then cache that information.
186 The primary purpose of the router server is to route the messages to
187 local servers and local clients, and messages that are destined to outside
188 the cell are routed to the primary route or some other secondary
189 route if it is a faster route. The routers in the network forms a ring.
190 Each router has a primary route to other router in the network. Finally
191 the ring is closed by the last router using the first router in the
192 network as its primary route.
195 <img src="silc_routers.JPG" alt="SILC Routers" align="center" border"0">
198 The diagram above illustrates how the routers forms a ring in the network.
199 A router may have several secondary routes which it may use when it
203 When routers connect to its primary router the SKE and the SILC Connection
204 Authentication protocols are executed just like when normal server connects
205 to its router. The session key is used to secure the communication between
206 the routers. All the secondary routes also have their own session keys.
210 <h1>SILC Packet Protocol</h1>
213 <img src="silc_packet.JPG" alt="Typical SILC Packet" align="center" border"0">
218 <h1>SILC Key Exchange Protocol</h1>
223 <h1>SILC Connection Authentcation Protocol</h1>
233 <h2>Channel Message Delivery</h2>
236 <img src="silc_channel.JPG" alt="Channel Message Delivery" align="center" border"0">
239 <h2>Channel Message Delivery With Channel Private Key</h2>
244 <h1>Private Messages</h1>
246 Private messages are messages that are sent from one client to another
247 through the SILC Network. They are private because they are not sent to
248 anyone else except to the true receiver of the message. Private messages
249 can be used to engage private conversation with another client if channels
253 As all messages in SILC the private message are also encrypted and
254 authenticated. There are several ways to secure private messages. By
255 default private messages are encrypted using the session keys established
256 in the SKE protocol. It is also possible to negotiate a private message
257 key between the two clients and encrypt the messages with that key. It
258 is even possible to encrypt the messages with public key cryptosystem,
259 if desired. The next sections will describe all these private message
263 The SILC protocol provides these three methods of delivering private messages
264 because none of the methods alone can satisfy the security requirements
265 of all people. The end user should decide the acceptable level of risk,
266 the required level of security and other security and usability aspects when
267 deciding what way of sending private message suites for them.
271 <h2>Private Message Delivery With Session Keys</h2>
273 Sending private messages are by default secured with session keys established
274 in the SKE protocol. This means that the private message is always encrypted
275 with the session key of the next receiver of the message enroute to the
276 receiving client. This also means that the message is decrypted and
277 re-encrypted everytime it is sent further to the receiving client.
280 <img src="silc_priv1.JPG" alt="Basic Private Message Delivery" align="center" border"0">
283 As the above diagram shows the private messages sent by Client A to the
284 Client B travels through the SILC Network and is always decrypted and
285 re-encrypted with the session key of the next receiver. The Client B then
286 finally decrypts the private messages that is encrypted with the session
287 key shared between the Client B and the Server Y.
290 This way of securing private messages is not perfect and cannot be used
291 in all circumstances. If the clients having the conversation cannot trust
292 the servers and routers in the SILC Network they should not send private
293 messages that are secured in this manner. Messages secured in this manner
294 can be decrypted by the servers and routers that the clients may consider
298 If the clients on the other hand trust the servers and routers in their
299 SILC Network, or they do not care that servers can decrypt their messages,
300 sending private messages in this way is very simple from client's point
301 of view. For servers and routers this of course means that they need
302 to decrypt and re-encrypt each private message. Since this way of securing
303 private message cannot be used at all times the SILC protocol provides
304 other ways of securing private messages.
308 <h2>Private Message Delivery With Private Message Key</h2>
310 Private messages can be secured with private message key as well. This
311 key is known only by the sender of the message and the receiver of the
312 message. This way no one else except the sender and the receiver can encrypt
313 and decrypt the private messages. The message is encrypted by the sender
314 with the private message key and all the servers and routers pass the message
315 through enroute to the receiver. They cannot decrypt the message since
316 they do not have the key. When sending private messages in this way it
317 does not matter whether the clients trust or do not trust the servers and
318 routers in the SILC network.
321 <img src="silc_priv2.JPG" alt="Private Messages with Private Message Key" align="center" border"0">
324 As the above diagram shows the Client A encrypts the message with private
325 message key and sends the message to the SILC Network. All servers and
326 routers merely pass the message through since they cannot decrypt it.
327 The Client B then receives the message and decrypts it with the private
331 Sending private messages in this manner is always secure since the key is
332 shared only by the sender and the receiver. The problem of this method
333 is that the sender and the receiver must somehow agree about the key
334 they are going to use. The private message key can generally be anything.
335 It can be a passphrase that only the sender and the receiver knows. They
336 could have been agreed to use some word or phrase as the key sometime
337 earlier before they started the conversation. Or the key maybe from some
338 random string from a code book that only the sender and the receiver poses.
339 Or it can be a key that is negotiated using some key negotiation protocol.
342 The problem however is fundamental. How to agree to use some key when
343 you cannot reach the other person over secure channel? The SILC protocol
344 solves this problem by providing a possiblity to negotiate the key
345 between two clients using the SKE protocol. One or both of the clients
346 can set up the SKE server running in their host and ask the other client
347 to connect to it. As a result of the SKE protocol the clients have
348 now shared secret that they can use as private message key. The key
349 is known only by the two clients that exexcuted the SKE protocol. They
350 can then use that key to secure all subsequent private messages.
353 Using this method of private messages delivery is recommended if the
354 clients cannot trust the servers and routers in the SILC Network. The
355 drawback is the extra phase of setting the private message key before
356 starting the conversation. However, using the SKE protocol is the
357 recommended way to negotiate the private message key since it can be
358 automized and does not cause any extra tasks for end user.
362 <h2>Private Message Delivery With Public Key Encryption</h2>
364 If the clients cannot trust the servers and routers in the SILC Network
365 they can use the private message key. As described in the previous section
366 it is easy to set up with the SKE protocol. However, sometimes the two
367 clients do not want to use any passphrases as private message key or
368 negotiate the key with SKE, or perhaps they are unable to negotiate the
369 key because of some other external problem. The SILC protocol provides
370 yet another way of securing the private messages. This way does not
371 require setting or negotiating private message key. And, in this method
372 also it does not matter whether the clients trust or do not trust the
373 servers and routers in the SILC Network. The method is public key
374 encryption. The clients can encrypt the private messages with the
375 receiver's public key and send the message to the network. The servers
376 and routers cannot decrypt the messages since they do not have the
377 receiver's private key. The receiver on the other hand has the private
378 key which it uses to decrypt the message.
381 <img src="silc_priv3.JPG" alt="Private Messges with Public Key Cryptosystem" align="center" border"0">
384 As the above diagram shows the Client A has the Client B's public key.
385 It will encrypt the message with that key and sends the message to the
386 SILC Network. All servers and routers pass the message through since
387 they cannot decrypt it. The Client B then uses its private key to
388 decrypt the message. The Client B has also the Client A's public key
389 that it can use to encrypt messages that it will send to Client A.
392 Even this method of private message delivery is not perfect. The drawbacks
393 of this method is that the public key encryption process, as being
394 assymmetric cryptosystem, is much slower than encryption process with
395 symmetric cryptosystems. This is not probably problem with short messages
396 but may be inconvenient with long messages. The other drawback is that the
397 sender must first assure that the public key it is using in the encryption
398 is actually the receiver's public key. This is a absolute requirement
399 in this method. If the sender cannot authenticate the receiver's public
400 key this method of private message delivery should not be used. In SILC
401 protocol clients can fetch other clients public keys from servers.
402 However, the servers may not have authenticated the fetched public key so
403 that should not be fully trusted. Use of certificates can solve the
404 problem. The receiver's certificate could be authenticated by a third
405 party Certificate Authority (CA).
408 Usually verifying the public key is not a problem since the receiver
409 can provide the public key on some website, or verify the fingerprint of
410 the key over email, or phone call. The clients can also fetch the
411 public keys from SILC servers if they trust that the keys are authentic.
412 If both of the clients trust that the public keys are authentic using this
413 method of private message delivery is very simple and recommended.
421 <h1>Further Information</h1>
423 More detailed information about the SILC Protocol is available in the
424 SILC Protocol specification documents. There exists currently four
425 Internet Drafts that defines the protocol in great detail. The Internet
426 Drafts are available from the following sources but also from the
427 <a href="http://www.ietf.org">IETF website</a>.
430 - <a href="http://silcnet.org/docs/draft-riikonen-silc-spec-03.txt">
431 Secure Internet Live Conferencing (SILC), Protocol Specification</a>
434 - <a href="http://silcnet.org/docs/draft-riikonen-silc-pp-03.txt">
435 SILC Packet Protocol</a>
438 - <a href="http://silcnet.org/docs/draft-riikonen-silc-ke-auth-03.txt">
439 SILC Key Exchange and Authentication Protocols</a>
442 - <a href="http://silcnet.org/docs/draft-riikonen-silc-commands-01.txt">
449 <h1>Terms and Abbreviations</h1>
projects / runtime.git / blob