doc/whitepaper/silc_protocol.html

   1 <html>
   2 <header>
   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">
   9 </head>
  10 <body bgcolor="#ffffff">
  11
  12 <font face="Helvetica">
  13
  14 <h1>About the White Paper</h1>
  15 <p>
  16 The purpose of this white paper is to give short but deep enough introduction
  17 to the SILC Protocol.  The document describes the purpose of the protocol
  18 and how the protocol works in practice.  This document is intended for all
  19 audience.  This document should be easy to understand for non-technical
  20 person and still be detailed enough for technically oriented person.  See
  21 the section <a href="#terms">Terms and Abbreviations</a> for terms used
  22 in this documents.
  23 <p>
  24
  25 <p>
  26 (c) Copyright 2001 Pekka Riikonen
  27 (<a href="mailto:priikone at silcnet.org">priikone at silcnet.org</a>)
  28 <p>
  29 This document is free document; you can redistribute it and/or modify
  30 it under the terms of the GNU General Public License as published by
  31 the Free Software Foundation; either version 2 of the License, or
  32 (at your option) any later version.  This document is distributed in
  33 the hope that it will be useful, but WITHOUT ANY WARRANTY; without even
  34 the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
  35 See the GNU General Public License for more details.
  36
  37 <p><br>
  38 <h1>Summary</h1>
  39
  40 xxx
  41
  42 <p>
  43
  44 <p><br>
  45 <h1>SILC Protocol</h1>
  46 <p>
  47
  48 <img src="silc_network.JPG" alt="SILC Network" align="center" border"0">
  49
  50 <p><br>
  51 <h2>Clients</h2>
  52 <p>
  53
  54 <p><br>
  55 <h2>Servers</h2>
  56 <p>
  57
  58 <p><br>
  59 <h2>Routers</h2>
  60 <p>
  61
  62 <img src="silc_routers.JPG" alt="SILC Routers" align="center" border"0">
  63
  64
  65 <p><br>
  66 <h1>SILC Packet Protocol</h1>
  67 <p>
  68
  69 <img src="silc_packet.JPG" alt="Typical SILC Packet" align="center" border"0">
  70
  71
  72
  73 <p><br>
  74 <h1>SILC Key Exchange Protocol</h1>
  75 <p>
  76
  77
  78 <p><br>
  79 <h1>SILC Connection Authentcation Protocol</h1>
  80 <p>
  81
  82
  83
  84 <p><br>
  85 <h1>Channels</h1>
  86 <p>
  87
  88 <p><br>
  89 <h2>Channel Message Delivery</h2>
  90 <p>
  91
  92 <img src="silc_channel.JPG" alt="Channel Message Delivery" align="center" border"0">
  93
  94 <p><br>
  95 <h2>Channel Message Delivery With Channel Private Key</h2>
  96 <p>
  97
  98
  99 <p><br>
 100 <h1>Private Messages</h1>
 101 <p>
 102 Private messages are messages that are sent from one client to another
 103 through the SILC Network.  They are private because they are not sent to
 104 anyone else except to the true receiver of the message.  Private messages
 105 can be used to engage private conversation with another client if channels
 106 are not desired.
 107 <p>
 108
 109 As all messages in SILC the private message are also encrypted and
 110 authenticated.  There are several ways to secure private messages.  By
 111 default private messages are encrypted using the session keys established
 112 in the SKE protocol.  It is also possible to negotiate a private message
 113 key between the two clients and encrypt the messages with that key.  It
 114 is even possible to encrypt the messages with public key cryptosystem,
 115 if desired.  The next sections will describe all these private message
 116 delivery methods.
 117
 118 <p>
 119 The SILC protocol provides these three methods of delivering private messages
 120 because none of the methods alone can satisfy the security requirements
 121 of all people.  The end user should decide the acceptable level of risk,
 122 the required level of security and other security and usability aspects when
 123 deciding what way of sending private message suites for them.
 124
 125
 126 <p><br>
 127 <h2>Private Message Delivery With Session Keys</h2>
 128 <p>
 129 Sending private messages are by default secured with session keys established
 130 in the SKE protocol.  This means that the private message is always encrypted
 131 with the next receiver of the message enroute to the receiving client.
 132 This also means that the message is decrypted and re-encrypted everytime
 133 it is sent further to the receiving client.
 134 <p>
 135
 136 <img src="silc_priv1.JPG" alt="Basic Private Message Delivery" align="center" border"0">
 137 <p><br>
 138
 139 As the above diagram shows the private messages sent by Client A to the
 140 Client B travels through the SILC Network and is always decrypted and
 141 re-encrypted with the session key of the next receiver.  The Client B then
 142 finally decrypts the private messages that is encrypted with the session
 143 key shared between the Client B and the Server Y.
 144 <p>
 145
 146 This way of securing private messages is not perfect and cannot be used
 147 in all circumstances.  If the clients having the conversation cannot trust
 148 the servers and routers in the SILC Network they should not send private
 149 messages that are secured in this manner.  Messages secured in this manner
 150 can be decrypted by the servers and routers that the clients consider to be
 151 untrusted.
 152 <p>
 153
 154 If the clients on the other hand trust the servers and routers in their
 155 SILC Network, or they do not care that servers can decrypt their messages,
 156 sending private messages in this way is very simple from client's point
 157 of view.  For servers and routers this of course means that they need
 158 to decrypt and re-encrypt each private message.  Since this way of securing
 159 private message cannot be used at all times the SILC protocol provides
 160 other ways of securing private messages.
 161
 162 <p><br>
 163 <h2>Private Message Delivery With Private Message Key</h2>
 164 <p>
 165 Private messages can be secured with private message key as well.  This
 166 key is known only by the sender of the message and the receiver of the
 167 message. This way no one else except the sender and the receiver can encrypt
 168 and decrypt the private messages.  The message is encrypted by the sender
 169 with the private message key and all the servers and routers pass the message
 170 through enroute to the receiver.  They cannot decrypt the message since
 171 they do not have the key.  When sending private messages in this way it
 172 does not matter whether the clients trust or do not trust the servers and
 173 routers in the SILC network.
 174 <p>
 175
 176 <img src="silc_priv2.JPG" alt="Private Messages with Private Message Key" align="center" border"0">
 177 <p><br>
 178
 179 As the above diagram shows the Client A encrypts the message with private
 180 message key and sends the message to the SILC Network.  All servers and
 181 routers merely pass the message through since they cannot decrypt it.
 182 The Client B then receives the message and decrypts it with the private
 183 message key.
 184 <p>
 185
 186 Sending private messages in this manner is always secure since the key is
 187 shared only by the sender and the receiver.  The problem of this method
 188 is that the sender and the receiver must somehow agree about the key
 189 they are going to use.  The private message key can generally be anything.
 190 It can be a passphrase that only the sender and the receiver knows.  They
 191 could have been agreed to use some word or phrase as the key sometime
 192 earlier before they started the conversation.  Or the key maybe from some
 193 random string from a code book that only the sender and the receiver poses.
 194 Or it can be a key that is negotiated using some key negotiation protocol.
 195 <p>
 196
 197 The problem however is fundamental.  How to agree to use some key when
 198 you cannot reach the other person over secure channel?  The SILC protocol
 199 solves this problem by providing a possiblity to negotiate the key
 200 between two clients using the SKE protocol.  One or both of the clients
 201 may set up the SKE server running in their host and ask the other client
 202 to connect to it.  As a result of the SKE protocol the clients have
 203 now shared secret that they can use as private message key.  The key
 204 is known only by the two clients that exexcuted the SKE protocol.  They
 205 can then use that key to secure all subsequent private messages.
 206 <p>
 207
 208 Using this method of private messages delivery is recommended if the
 209 clients cannot trust the servers and routers in the SILC Network.  The
 210 drawback is the extra phase of setting the private message key before
 211 starting the conversation.  However, using the SKE protocol is the
 212 recommended way to negotiate the private message key since it can be
 213 automized and does not cause any extra tasks for end user.
 214
 215 <p><br>
 216 <h2>Private Message Delivery With Public Key Encryption</h2>
 217 <p>
 218 If the clients cannot trust the servers and routers in the SILC Network
 219 they can use the private message key.  As described in the previous section
 220 it is easy to set up with the SKE protocol.  However, sometimes the two
 221 clients do not want to use any passphrases as private message key or
 222 negotiate the key with SKE, or perhaps they are unable to negotiate the
 223 key because of some other external problem.  The SILC protocol provides
 224 yet another way of securing the private messages.  This way does not
 225 require setting or negotiating private message key.  And, in this method
 226 also it does not matter whether the clients trust or do not trust the
 227 servers and routers in the SILC Network.  The method is public key
 228 encryption.  The clients can encrypt the private messages with the
 229 receiver's public key and send the message to the network.  The servers
 230 and routers cannot decrypt the messages since they do not have the
 231 receiver's private key.  The receiver on the other hand has the private
 232 key which it uses to decrypt the message.
 233 <p>
 234
 235 <img src="silc_priv3.JPG" alt="Private Messges with Public Key Cryptosystem" align="center" border"0">
 236 <p><br>
 237
 238 As the above diagram shows the Client A has the Client B's public key.
 239 It will encrypt the message with that key and sends the message to the
 240 SILC Network.  All servers and routers pass the message through since
 241 they cannot decrypt it.  The Client B then uses its private key to
 242 decrypt the message.  The Client B has also the Client A's public key
 243 that it can use to encrypt messages that it will send to Client A.
 244 <p>
 245
 246 Even this method of private message delivery is not perfect.  The drawbacks
 247 of this method is that the public key encryption process, as being
 248 assymmetric cryptosystem, is much slower than encryption process with
 249 symmetric cryptosystems.  This is not probably problem with short messages
 250 but may be inconvenient with long messages.  The other drawback is that the
 251 sender must first assure that the public key it is using in the encryption
 252 is actually the receiver's public key.  This is a absolute requirement
 253 in this method.  If the sender cannot authenticate the receiver's public
 254 key this method of private message delivery should not be used.  In SILC
 255 protocol clients can fetch other clients public keys from servers.
 256 However, the servers may not have authenticated the fetched public key so
 257 that should not be fully trusted.  Use of certificates can solve the
 258 problem.  The receiver's certificate could be authenticated by a third
 259 party Certificate Authority (CA).
 260
 261 <p>
 262 Usually verifying the public key is not a problem since the receiver
 263 can provide the public key on some website, or verify the fingerprint of
 264 the key over email, or phone call.  The clients can also fetch the
 265 public keys from SILC servers if they trust that the keys are authentic.
 266 If both of the clients trust that the public keys are authentic using this
 267 method of private message delivery is very simple and recommended.
 268
 269
 270 <p><br>
 271 <h1>Conclusions</h1>
 272
 273
 274 <a name="terms"></a>
 275 <h1>Terms and Abbreviations</h1>
 276
 277 </font>
 278
 279 </body>
 280 </html>