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 session key of the next receiver of the message enroute to the
 132 receiving client.  This also means that the message is decrypted and
 133 re-encrypted everytime 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 may consider
 151 to be 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
 163 <p><br>
 164 <h2>Private Message Delivery With Private Message Key</h2>
 165 <p>
 166 Private messages can be secured with private message key as well.  This
 167 key is known only by the sender of the message and the receiver of the
 168 message.  This way no one else except the sender and the receiver can encrypt
 169 and decrypt the private messages.  The message is encrypted by the sender
 170 with the private message key and all the servers and routers pass the message
 171 through enroute to the receiver.  They cannot decrypt the message since
 172 they do not have the key.  When sending private messages in this way it
 173 does not matter whether the clients trust or do not trust the servers and
 174 routers in the SILC network.
 175 <p>
 176
 177 <img src="silc_priv2.JPG" alt="Private Messages with Private Message Key" align="center" border"0">
 178 <p><br>
 179
 180 As the above diagram shows the Client A encrypts the message with private
 181 message key and sends the message to the SILC Network.  All servers and
 182 routers merely pass the message through since they cannot decrypt it.
 183 The Client B then receives the message and decrypts it with the private
 184 message key.
 185 <p>
 186
 187 Sending private messages in this manner is always secure since the key is
 188 shared only by the sender and the receiver.  The problem of this method
 189 is that the sender and the receiver must somehow agree about the key
 190 they are going to use.  The private message key can generally be anything.
 191 It can be a passphrase that only the sender and the receiver knows.  They
 192 could have been agreed to use some word or phrase as the key sometime
 193 earlier before they started the conversation.  Or the key maybe from some
 194 random string from a code book that only the sender and the receiver poses.
 195 Or it can be a key that is negotiated using some key negotiation protocol.
 196 <p>
 197
 198 The problem however is fundamental.  How to agree to use some key when
 199 you cannot reach the other person over secure channel?  The SILC protocol
 200 solves this problem by providing a possiblity to negotiate the key
 201 between two clients using the SKE protocol.  One or both of the clients
 202 can set up the SKE server running in their host and ask the other client
 203 to connect to it.  As a result of the SKE protocol the clients have
 204 now shared secret that they can use as private message key.  The key
 205 is known only by the two clients that exexcuted the SKE protocol.  They
 206 can then use that key to secure all subsequent private messages.
 207 <p>
 208
 209 Using this method of private messages delivery is recommended if the
 210 clients cannot trust the servers and routers in the SILC Network.  The
 211 drawback is the extra phase of setting the private message key before
 212 starting the conversation.  However, using the SKE protocol is the
 213 recommended way to negotiate the private message key since it can be
 214 automized and does not cause any extra tasks for end user.
 215
 216
 217 <p><br>
 218 <h2>Private Message Delivery With Public Key Encryption</h2>
 219 <p>
 220 If the clients cannot trust the servers and routers in the SILC Network
 221 they can use the private message key.  As described in the previous section
 222 it is easy to set up with the SKE protocol.  However, sometimes the two
 223 clients do not want to use any passphrases as private message key or
 224 negotiate the key with SKE, or perhaps they are unable to negotiate the
 225 key because of some other external problem.  The SILC protocol provides
 226 yet another way of securing the private messages.  This way does not
 227 require setting or negotiating private message key.  And, in this method
 228 also it does not matter whether the clients trust or do not trust the
 229 servers and routers in the SILC Network.  The method is public key
 230 encryption.  The clients can encrypt the private messages with the
 231 receiver's public key and send the message to the network.  The servers
 232 and routers cannot decrypt the messages since they do not have the
 233 receiver's private key.  The receiver on the other hand has the private
 234 key which it uses to decrypt the message.
 235 <p>
 236
 237 <img src="silc_priv3.JPG" alt="Private Messges with Public Key Cryptosystem" align="center" border"0">
 238 <p><br>
 239
 240 As the above diagram shows the Client A has the Client B's public key.
 241 It will encrypt the message with that key and sends the message to the
 242 SILC Network.  All servers and routers pass the message through since
 243 they cannot decrypt it.  The Client B then uses its private key to
 244 decrypt the message.  The Client B has also the Client A's public key
 245 that it can use to encrypt messages that it will send to Client A.
 246 <p>
 247
 248 Even this method of private message delivery is not perfect.  The drawbacks
 249 of this method is that the public key encryption process, as being
 250 assymmetric cryptosystem, is much slower than encryption process with
 251 symmetric cryptosystems.  This is not probably problem with short messages
 252 but may be inconvenient with long messages.  The other drawback is that the
 253 sender must first assure that the public key it is using in the encryption
 254 is actually the receiver's public key.  This is a absolute requirement
 255 in this method.  If the sender cannot authenticate the receiver's public
 256 key this method of private message delivery should not be used.  In SILC
 257 protocol clients can fetch other clients public keys from servers.
 258 However, the servers may not have authenticated the fetched public key so
 259 that should not be fully trusted.  Use of certificates can solve the
 260 problem.  The receiver's certificate could be authenticated by a third
 261 party Certificate Authority (CA).
 262
 263 <p>
 264 Usually verifying the public key is not a problem since the receiver
 265 can provide the public key on some website, or verify the fingerprint of
 266 the key over email, or phone call.  The clients can also fetch the
 267 public keys from SILC servers if they trust that the keys are authentic.
 268 If both of the clients trust that the public keys are authentic using this
 269 method of private message delivery is very simple and recommended.
 270
 271
 272 <p><br>
 273 <h1>Conclusions</h1>
 274
 275
 276 <a name="terms"></a>
 277 <h1>Terms and Abbreviations</h1>
 278
 279 </font>
 280
 281 </body>
 282 </html>