- By Pekka Riikonen -
Have you been looking for a secure place to talk? A place where you can
be sure that the message you send to a person really goes to that person,
no one else is able to see the message, and no one is able to alter the
message? More and more people answer yes to the question, but where to
find such a place? The answer comes in the form of new generation chat
protocol called Secure Internet Live Conferencing, or just SILC (casually
pronounced as silk).
Security is the key
Security has been the primary design goal in the development of the
SILC protocol. It is a known fact that chat protocols have been insecure
and vulnerable to many security problems. In the contemporary
network environment, which is both demanding and full of potential
security risks, developing a secure chat protocol is important. In the SILC
protocol, all messages are always encrypted and authenticated, either using
session keys, channel keys, or other private message keys. In fact,
sending unencrypted messages and packets is impossible in the SILC network.
This is the problem of many other chat protocols that provide message
encryption. These protocols are not secure by default, but attempt to
provide the security by applying external security protocols, such as PGP
or SSL on top of the insecure chat protocol. While PGP and SSL have proved
to be secure, the result is often something other than the authors expected.
These protocols often encrypt only the data of the message, and leave
out message authentication, packet authentication, key management and
other security issues. They also often secure only part of the network,
namely the part where the security protocol, such as SSL, is used, leaving
rest of the network open.
Something old, something new, something borrowed, something blue
SILC chat protocol provides all the features that are so familiar to all
of us who have been chatting for quite some time. It provides nicknames,
channels, private messages, user retrieval, and all the tools that every
chatter needs to reach the ultimate chatting experience. For those who
have been using IRC, chances are they feel at home with SILC, because most
of the commands that are found in IRC are also found in SILC, and the
general appearance resembles IRC. The protocol, however, is not based on
IRC and does not support it.
But there are new features, too. In addition to providing all the old
features now as secure ones, there are many new commands that control
various security features of a SILC client. Channel messages are always
encrypted, and so are private messages. It is possible to encrypt any
message end to end, so that only the sender and the receiver is able to
encrypt and decrypt messages. All channels have their own channel key
and only the users on the channel are able to encrypt and decrypt messages
for that channel. Many times, servers create default keys, so that the
network always remains encrypted even if other secret keys are not used or
negotiated by an end user. Users can negotiate secret keys with other
users, and use the negotiated key material to secure, for example, private
messages, or perhaps a file transfer stream.
Yes, a chat protocol is not a chat protocol nowadays without a file
transfer support. SILC use the SFTP protocol by default to do its
file transfers. The file transfer stream is always sent peer to peer
between users, and it is encrypted using negotiated secret keys. The
support for file transfer is actually developed so that any file transfer
protocol can be used with SILC. The SFTP is the default protocol but
others could be used, too.
Keys, keys and keys
It might seem that managing all these keys that do
this and that is hard. Managing the keys is extremely important, but the
user interface plays an important role in the ease of use. Negotiating the
keys for file transfer, for example, can be transparent and can be done
automatically when the file transfer request is sent. During the
negotiation, the user may be prompted to accept the remote user's public
key before continuing. Verifying the public keys before accepting them is,
of course, important, the same with the server public key when the user connects
for the very first time to the server. The SILC Protocol has its own
SILC public key, but it also supports SSH2 public keys, OpenPGP
certificates and X.509 certificates.
"Give me my nickname back!"
This is something we have all heard of once or twice on IRC. The fact
that there can be only one nickname of a kind in IRC makes it hard to
find the nickname you really like without stepping into someone's territory.
And, this usually leads into nickname wars. The DALnet IRC network and some others
solve the problem by providing nickname registering services, so that
you can register the nickname you want and no one else can have it.
SILC takes an entirely different approach to the problem. And it is simple;
nicknames are not unique. Just like there are many people in the world
with same name, there can be many people with same nickname in the SILC
network. Why would you want to enforce that there cannot be same
nicknames in the chat network when there are bound to be people with same
name chatting in the same network? In the SILC network, it is possible to have
multiple copies of the same nickname, and it is always guaranteed that you will get the
nickname you want. This renders nickname wars obsolete, and nickname
registering services as well.
New users in the SILC network will face this issue when they give WHOIS
command to a nickname and the WHOIS returns multiple same nicknames.
A user can be identified as different from other users by his real name,
username, hostname, and in the end by the fingerprint of his public key.
Because there can be same nicknames, identifying the person you really
want to talk to is important. Giving the WHOIS command before sending a private
message to "joe" might be a good idea.
Deploying the SILC
SILC is meant for Internet-wide use, and the protocol attempts to scale
better than IRC. The network design of SILC allows
for a more scalable network because it does not require for all servers to
keep global data in sync. Normal SILC servers are connected to SILC
routers, and the routers are the only entities in the network that know
global data, and are responsible of keeping it in sync. This
dramatically reduces the number of entities in the network that need to
be in sync.
SILC also fits perfectly as a company's internal chat server. Many
companies have already reported that they have replaced their IRC servers
with SILC servers. Even though the software is still in beta phase, and
more client implementations are needed, SILC is usable and can be
deployed in any environment. SILC is also distributed as a toolkit to make
SILC application development easy and fast for programmers.
The SILC project's home is at http://silcnet.org, and interested readers are asked to take a look at the SILC Whitepaper, SILC FAQ and other
documentation. The ultimate resource for those who would like to know
how the protocol ticks is the protocol specification drafts. The protocol specifications are also available from the IETF. The
SILC Network is naturally a nice place to find help as well as talk about
SILC. Joining #silc channel is a good start.