Secure communication via the internet

RELATED APPLICATION

[0001] The current application claims priority from European Patent Application Number 02076498.1, which was filed on Apr. 16, 2002, the contents of which are incorporated herein by reference.

FIELD OF THE INVENTION

[0002] The invention relates to secure electronic communication via a communication system, in particular the Internet, using public key encryption.

BACKGROUND OF THE INVENTION

[0003] Electronic communication has spread widely with the success of Internet and is spreading even further with the arrival of all kinds of wireless communication, for instance using PDAs (Personal Digital Assistants) and mobile phones. Electronic communication can take many forms, such as email, file transport, accessing web sites, etc. Normally, electronic communication is unprotected in the sense that the electronic content can be accessed by many people that have access to the computers involved in the distribution of the electronic content. As an example, sending an email usually involves the sending and receiving computer, access computers that provide both station access to the network, and several routing computers involved in routing the email through the Internet. Even one route may involve a dozen routers, where for each communication different routers may be chosen. Consequently, tens of thousands of operators of all those computers can access electronically exchanged content. Although the operators may be bound by contract or law not to disclose such content, it can never be ruled out that somebody may not be able to resist the temptation. A serious threat to security is also that malicious people may break into (“hack”) one or more of these computers and in that way get access to the electronic content.

[0004] It is therefore desired to secure electronic communication. This may involve encrypting the digital content and in that way making it unreadable for a person that does not have access to the decryption key/algorithm. Alternatively, or additionally it may involve authenticating the communication by digitally signing the content. In itself, suitable encryption algorithms and modes of using such algorithms are known. Particularly, public key cryptography has proven very successful as the basis for exchanging keys between the sending and receiving parties. In the Internet community, PGP (Pretty Good Privacy) has been a reasonably successful implementation of public key cryptography.

[0005] PGP is a hybrid cryptosystem combining features of both conventional and public key cryptography. When a user encrypts plaintext with PGP, PGP first compresses the plaintext. PGP then creates a random number session key, which is a one-time-only secret key. The session key works with a conventional encryption algorithm to encrypt the plaintext; the result is ciphertext. Once the data is encrypted, the session key is then encrypted to the recipient's public key. This public key-encrypted session key is transmitted along with the ciphertext to the recipient. Decryption works in the reverse. The recipient's copy of PGP uses his or her private key to recover the session key, which PGP then uses to decrypt the conventionally encrypted ciphertext.

[0006] PGP also uses public key cryptography as a method for employing digital signatures. Digital signatures let the recipient of information verify the authenticity of the information's origin, and also verify that the information was not altered while in transit. A digital signature also provides non-repudiation, which means that it prevents the sender from claiming that he or she did not actually send the information. Instead of encrypting information using someone else's public key, it is encrypted it with the sender's private key. If the information can be decrypted with the corresponding public key, then it must have originated with the owner of the keys. To improve the speed, PGP uses a one-way hash function in the process. The one-way hash function takes the variable-length message as input and produces a fixed-length, relatively short output, known as a message digest. The hash function ensures that, if the information is changed in any way—even by just one bit—an entirely different output value is produced. Then PGP uses the digest and the private key to create the “signature”. PGP transmits the signature and the plaintext together. Upon receipt of the message, the recipient uses PGP to re-compute the digest, thus verifying the signature.

[0007] Keys are managed in a distributed way in PGP based on a “web of trust”. Every user generates and distributes his own public key. Users sign each other's public keys, creating an interconnected community of PGP users. If a user wants to, he can store his public key in one or more key servers. Digital certificates simplify the task of establishing whether a public key truly belongs to the purported owner. A digital certificate consists of a public key, certificate information (“Identity” information about the user, such as name, user ID, and so on.), and one or more digital signatures. The purpose of the digital signature on a certificate is to state that the certificate information has been attested to by some other person or entity. Certificates are used when it is necessary to exchange public keys with someone else. For small groups of people who wish to communicate securely, it is easy to manually exchange diskettes or emails containing each owner's public key. In addition to manual public key distribution use can be made of storage-only repositories called Certificate Servers, or more structured systems that provide additional key management features and are called Public Key Infrastructures (PKIs). A key server, also called a certificate server or a directory server, is a database that allows users to submit and retrieve digital certificates. A PKI includes the certificate storage facilities of a certificate server, but also provides services and protocols for managing public keys. These include the ability to issue, revoke, and trust certificates. The main feature of a PKI is the introduction of what are known as Certification Authority (CA) and Registration Authority (RA) components. A CA creates certificates and digitally signs them using the CA's private key. Because of its role in creating certificates, the CA is the central component of a PKI. Using the CA's public key, anyone wanting to verify a certificate's authenticity verifies the issuing CA's digital signature, and hence, the integrity of the contents of the certificate (most importantly, the public key and the identity of the certificate holder). A CA is often software that is used to issue the actual certificates to its computer users. Typically, an RA refers to the people, processes, and tools used to support the registration of users with the PKI (enrollment) and ongoing administration of users. The RA may perform vetting—the process of verifying that a public key belongs to its purported owner. An RA is a human entity—a person, group, department, company, or other association.

[0008] A user can download from a website or via ftp via the Internet a PGP software program (plug-in) that may be used freely for personal use. The program enables a user to create a private/public key pair. The software makes it also possible for the user to store the public key in a key server in the Internet. The user has to select a key server. If a user wants to send an encrypted communication he first has to retrieve the public key that belongs to the receiver. The sending user may contact the receiver, and the receiver may send its public key to the sender. The sender may also try and search for a key from the several different key servers in the Internet. After having obtaining the public key of the receiver, the user of the sending station can instruct the PGP program to encrypt a communication (email or file) with this public key. The secured communication can then be sent or transferred using standard communication protocols, such as email or ftp. The receiver can use its own private key to decrypt the secured communication. The described PGP software includes several cryptographic protocols based on public key encryption for performing the different types of secure communication.

[0009] Despite the availability of (free) cryptographic solutions like PGP, almost all electronic communication for personal use is not secured. Nevertheless, even businesses, such as law firms, accountants and bankers, frequently use ordinary, unsecured email for their business email over the public Internet.

SUMMARY OF THE INVENTION

[0010] It is an object of the invention to provide an improved method and system for secure communication between a sending and receiving station.

[0011] To meet the object of the invention, the method of enabling secure communication between at least one sending station and at least one receiving station via a communication system, in particular Internet, using public key cryptography includes:

[0012] in the sending station, in response to a desire to send a secure electronic communication to the receiving station, indicating such intention to a key server in the communication system;

[0013] in the key server verifying whether a public key is available for the receiving station or a user of the receiving station (hereinafter “receiver”); and on a negative outcome of the verification, indicating to the receiver an intention to send a secured communication to the receiver, and enabling the receiving station to obtain software that enables the receiver to create a private/public key pair for the receiver and to make the public key of the receiver available to the key server; and

[0014] if the public key was already available to the key server or in response to the public key having been made available by the receiver, using the public key for the receiver to secure the electronic communication; and making the secured communication available to the receiver through the communication system.

[0015] The inventor has realized that the low uptake of public key cryptographic solutions is at least partially caused by a user having to fully understand the concept of public key encryption and having to perform many steps in handling the keys. Low uptake is also caused by the impossibility of sending an encrypted message to a person who does not have PGP or another means of decrypting messages. The invention enables the sending of an encrypted message, or a pointer to it, to a person who doesn't have encryption tools. The message, or links in the message, enable automatic or partially automatic (download and) installation of encryption tools on recipients computer, who thereafter can (received and) decrypt and read the message. According to the invention, the key server is not just a passive storage of public keys but is the center piece in all communications involving keys. The client software in the sending station informs the key server that it intends to send an email (or other electronic content) to a receiver. The key server checks whether a public key is available for the receiver. If not, the key server fully automatically undertakes actions to stimulate creation of such a public key. To this end, the key server sends a communication to the receiver informing the receiver that the sender wants to send a secure message. The key server also makes software available to the receiver (e.g. by sending a links to a download server, or by attaching the software). This software is capable of creating a private/public key pair in the receiver and to fully automatically store the public key in the server (e.g. send it via Internet). Preferably, the software is also able to decrypt a received secured communication. In this way, users need not to check the many key servers for a public key of a recipient, need not to distribute their own public keys (and so do also not need to store public keys of others with the risk of using out-of-date keys), need not to inform other users where to download software from and how to use the software to create and store keys.

[0016] As defined in the dependent claim 2, the communication of the secure message takes place via a server. In this way, the sending client only needs to have access to the public key of the secure server. This simplifies checking whether the key is still valid. Moreover, the sending client is relieved from having to manage the email in the situation that the receiving client has not yet obtained a key pair. Preferably, the sending client always uses the services of the secure server for delivery of secured content. Alternatively, the sending client may send the email directly to the receiving client encrypted with the public key of the receiving client if this key is available in the key server. If the client sends directly, the secure server is used if no public key of the receiver is available yet. The secure server may be combined with the key server, but may also be separate from it.

[0017] As defined in the dependent claim 3, the secure server temporarily stores the secured email until the receiving client has made a public key available to the key server. If desired, the secure server can inform the sending client that no successful secure delivery was possible within a predetermined period (of, for example, one week) if within that period no public key was made available by the receiving client or no delivery of the email was possible.

[0018] As defined in the dependent claim 4, when the receiving client makes its public key available to the key server, the secure server can deliver the secured content to the receiver. To this end, the content must be encrypted in such a way that the receiver can decrypt it using its private key. The secure server can encrypt the message using the public key of the receiver. Since the message is stored in a form encrypted using the server's public key, the message must also be decrypted first using the server's private key.

[0019] As defined in the dependent claim 5, the key server plays also an important role for authentication/signing of digital content, such as emails. Software, like a plug-in, is automatically made available to the receiver to enable the receiver to obtain a public key necessary for verifying the authenticated/signed communication.

[0020] As defined in the dependent claim 6, the private key of the sender is used for authenticating the communication. The authenticated communication may be sent directly to the receiver. Advantageously, as defined in the dependent claim 7, the sender sends the authenticated message to a secure server (preferably the same one as used for sending encrypted emails). In this way, the sender is relieved from delivery of the message, in particular if the receiver has not yet obtained its public key. The secure server re-authenticates the communication by signing it with its own private key. The newly authenticated communication is made available to the receiver, e.g. by emailing it from the server to the receiver. In this way it is possible that the receiver only has to deal with the public key of the secure server and, as such, is relieved from having to check for other keys and verifying the validity of those keys. For higher security, the signature of the secure server may be added to the signature of the sender, enabling the receiver to verify both signatures.

[0021] As defined in the dependent claim 8, the chance of misuse of the system is reduced by verifying that a communication identity of a station that wishes to participate (i.e. store its public key in the key server) is valid. In this way all stations (or users of the stations) that send secured (e.g. encrypted or signed) communications can be traced back. By accepting in a receiver only secured communications (and automatically disregarding all communications that have not been secured) an effective filter against Spam (unsolicited emails) is created. The number of unsolicited communications will be reduced and any unsolicited communications that are received can be traced back to a valid sender. The communication identity that is verified of a sender or receiver can be any suitable verifiable identity, such as a communication address, (e.g. IP address), or personal name/address as long as a verifiable proof of identity is supplied.

[0022] As defined in the dependent claim 9, the key server also performs the role of checking that the same cryptographic protocols and, in particular, the same release of those protocols are used. The server automatically takes the initiative to inform the station with the oldest software to upgrade to a newer release. In this way, users do not need to understand which (releases of) cryptographic protocols are used.

[0023] As defined in the dependent claim 10, preferably the key server triggers stations to use a latest approved release of the client software, including the cryptographic protocol. In this way, any protocol of which the security has been questioned can be replaced quickly. The users are relieved from having to keep up-to-date with which protocols and which software to use.

[0024] As defined in the dependent claim 11, the user can configure/control which communications are secured. The client software can, based on these settings, perform the securing fully automatic for those receivers as once specified by the user (or later on updated by the user).

[0025] As defined in the dependent claim 12, the key server or secure server registers when a user (or station of a user) has performed a billable operation. This may, for example, be: retrieving a public key or sending a secured communication. Billing can then be fully automatic, on a subscription basis (postpaid) or on a prepaid basis where the billable amount is subtracted from a prepaid balance.

[0026] As defined in the dependent claim 13, a distinction is made between servers. A special server (company server) is designated for dealing with keys (and optionally secure temporary storage of secured communications) for specific stations. Preferably, the company server has access to the Internet through a firewall that shields all the communication for a company. The company server may service one or more of the following:

[0027] all public keys for senders/receivers within the company;

[0028] all public keys for authorized external senders/receivers (e.g. customers) of the company.

[0029] These and other aspects of the invention are apparent from and will be elucidated with reference to the embodiments described hereinafter.

BRIEF DESCRIPTION OF THE DRAWINGS

[0030] In the drawings:

[0031]FIG. 1 shows an architecture of the system according to the invention;

[0032]FIG. 2 shows a flow diagram of operations in the sending client;

[0033]FIG. 3 shows a flow diagram of operations in the key server according to the invention; and

[0034]FIG. 4 shows a hierarchy of servers according to the invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

[0035]FIG. 1 shows an architecture of the system according to the invention. The system includes at least one sending station and one receiving station that can communicate via a communication system. The communication system is preferably, but is not limited to a wide area network. The figure shows a typical architecture where the communication infrastructure is based on Internet. The backbone of Internet is indicated by number <b>100</b> and is usually formed by routers and wide area links connecting the routers. Two stations <b>110</b> and <b>120</b> are shown. In the example, the stations can act both as a sending station and as a receiving station as is usually the case for Internet. The stations <b>110</b> and <b>120</b> gain access to the Internet <b>100</b> via respective access providers <b>130</b> and <b>140</b>. Station <b>120</b> is a mobile terminal (e.g. mobile phone or PDA) that communicates with its access provider <b>140</b> at least partly via a wireless telecommunications network <b>150</b>. Station <b>110</b> is a conventional stationary terminal, such as a personal computer, that communicates to its access provider <b>130</b> via a conventional access network <b>160</b>, such as a telephone line and telecommunication switches or a cable network (and fixed telecommunication lines). According to the invention, a centralized server <b>170</b> plays a role in secure communication between the stations <b>110</b> and <b>120</b>. In short, the server <b>170</b> plays the role of:

[0036] key intermediary controlling availability of public keys for the involved devices and acting as a key intermediary between the sender and receiver, particularly when one of the parties has not yet obtained the necessary keys;

[0037] communication intermediary, where the communication between the sender and receiver takes place via the server. The communication between the sender and server is secured using the keys of the sender/server, where appropriate. The communication between the server and receiver is managed by the keys of the server/receiver where appropriate.

[0038] Spam filter: the server only accepts keys from genuine stations, so that all secure communications can be traced back to a genuine station.

[0039] The server is preferably implemented on a computer platform, equipped with one or more processors that, suitably programmed, perform the functions according to the invention. The platform is preferably chosen from generally available platforms optimised for Internet functions. The platform includes a background storage, typically implemented on hard disks, such as a RAID system, a main memory, a user interface for enabling operator control and feedback, and any ordinary hardware used in such computer systems, such as I/O interfaces and control logic.

[0040] The cryptographic operations that need to be performed in the stations and the server are typically implemented in software. As will be described in more detail below, the stations and the server are equipped with suitable programs to perform the cryptographic operations. Preferably, the software is a plug-in or a set of plug-ins. For example, a plug-in for an email program, such as Outlook, and a plug-in for a file management program, like Explorer. If desired, part or the entire operation may be performed in hardware. The cryptographic algorithms itself are not part of the invention. Any suitable algorithm may be used. Preferably, the protocol suite of PGP is used, also enabling compatible co-operation with stations using the conventional PGP plug-ins. Particular care should be given to the private keys. Preferably, these keys are stored securely. To this end the stations may have access to a secure storage, e.g. in the form of a smart card that can be inserted into the stations or communicate with the stations (e.g. via a wired link like USB or wirelessly). In itself, suitable ways of storing keys are known.

[0041] The operation of the system will now be described for encryption of emails and signing of emails, where the signature is an attachment to the email. Persons skilled in the art will be able to apply the principles of the described two cryptographic applications also to other applications, such as signing with message recovery where the original message is not required by the receiver to verify the signature. The principles can also be used for other communications than emails. For instance, files can be protected and transferred via ftp using the same principles.

[0042] Encryption

[0043] It is assumed that the sending station is already equipped with all necessary software (and/or hardware) for performing the steps described below. If not, the sending station may download the software from, preferably, the server <b>170</b>. It is preferred that the software is a plug-in in the email program of the sending station. In this way, the user only needs to perform the normal operations for sending an email with minimal additional steps to be taken for securing the email. The software in the sending station enables the user to send an encrypted email to a receiving station. Preferably the software is configurable by the user. The software may enable the user to indicate that:

[0044] all electronic communication should be encrypted;

[0045] all electronic communication to receivers businesses should be encrypted;

[0046] all electronic communication to selected receivers should be encrypted;

[0047] an individual electronic communication should be encrypted.

[0048] The software may decide on whether or not an email is intended for a business receiver based on predetermined rules, such as all email addresses ending with .com. Alternatively, the user may be able to specify specific addresses, or address ranges, for example all addresses within the domain ibm.com. For the emails to selected receivers, the software enables the user to specify individual email addresses. Preferably, whenever the sending station receives an encrypted email, the software allows the user to add the sending email address to the list of selected receivers to which emails should be sent in an encrypted form. Advantageously, the software is able to automatically store such an address in the list, where the user can configure that such an automatic addition should or should not happen.

[0049]FIG. 2 shows a flow diagram of the steps performed by the sending client. In step <b>200</b>, it is established whether the email should be encrypted. If not, in step <b>210</b> the email is sent to the receiver in the conventional way. If encryption is desired, in step <b>230</b> the client checks whether a public key is available for the receiver. The sending station may store public keys for some or all receiving stations it has communicated to in the past. If such a key exists, this key may be used. If no such key is available (or the sending station does not store any public key of other stations), the sending station contacts the server <b>170</b> via the Internet. It provides an identification of the receiver to the server <b>170</b>. This identification may be the name of the receiving user. Alternatively, it may be the email address of the receiving user or internet identification (such as IP address) of the receiving station. It is preferred that the sending client does not store or use stored keys of other clients but that it always contacts the key server. In this way, it can be guaranteed that up-to-date keys (and encryption protocols) are used. If the key is already available in the server, the sending client receives the key from the server and uses it to encrypt the message in step <b>240</b>. In step <b>210</b> the message is then send directly to the receiver. If no such key is (yet) available, the server provides the public key of a secure server. In FIG. 1, the secure server is indicated with number <b>180</b>. The secure server may the same as the key server. In step <b>250</b> the sending client uses this key to encrypt the message and sends the message to the secure server in step <b>260</b> for further processing.

[0050] As described above, the message is encrypted in the sending client before sending it to the recipient or server. Preferably, the encryption occurs just before sending it. In that way, the user can still edit the message until the message is actually sent (or handed over to the email program for transmission). Advantageously, a plaintext form of the message is kept at the sender's computer, where optionally modification of this message is prohibited.

[0051]FIG. 3 shows a flow diagram of the steps performed by the key server. In step <b>300</b> the key server verifies whether a pubic key of a recipient is already available. The server does this in response to a request from the sender for a public key of a recipient (or an indication that the sender wants to send a secured communication to the recipient). The identification of the recipient is supplied by the sender. If the outcome is positive, the server supplies the public key in step <b>310</b>. If the outcome is negative, in step <b>320</b> the key server supplies a public key of a secure server (that may be the same as the key server). As has been described for FIG. 2, the sender sends the message encrypted with this key to the secure server. In response to receiving such a message, the secure server stores it in encrypted form in a storage. This storing operation is not shown in FIG. 3. The key server also sends to the intended receiver a notification that it is the intention to send an encrypted message to the receiver. The notification may take the form of “you have received an encrypted message from . . . ” or “ . . . wants to send an encrypted message to you” followed by a prescription on how to read that message. Preferably, the server sends a message to the recipient similar to: “name@sender.com has sent you an encrypted email message. You need to download a plug in from www.izemail.com in order to read this email message. Please come to www.izemail.com/yourcode to receive the plug-in and read the message. The subject of the message is [subject line]”. The prescription involves downloading the crypto software and installing it on the client. The download function may be implemented by a server using Internet's web functionality. The prescription may point the recipient to a webpage on the server for downloading secure email software. After downloading of a plug-in (the initial plug-in may be small, additional modules can be downloaded later), the software is installed. During the installation automatically a private/public key pair is created and the public key is sent to the key server, thus making it crypto-enabled. The receiving client may, after installation, also send an initialization message to the server. In step <b>340</b> the key server checks whether already a public key has been supplied by the receiver. If so, in step <b>350</b> it provides this public key (or makes it available) to the secure server. In response, the secure server then decrypts the stored original message, encrypts it with the brand new public key of the new user. Since the stored message was encrypted with the public key of the secure server, the message is also decrypted by the secure server with its private key. Using the PGP or other suitable public key based protocols, the secure server will first decrypt the message and then re-encrypt it. In this case, the plain form of the message is preferably not stored in a background storage accessible by human operators. For example, the decryption and re-encryption may be performed in as secure unit, such as a crypto-processor on a smart card or other physically secured unit. Of course, the re-encryption may take place in the key server. In that case, the key server in step <b>350</b> performs the re-encryption. The re-encrypted message is sent to the receiver. In response to the public key of the receiver becoming available, the key server may optionally inform the original sending client of the new user, and (securely) transmits the public key to the sender for future use. In the preferred embodiment, the sending client does not store public keys. In that case, the public key does not need to be supplied. Instead, an indication may be supplied to the sender that the receiver has responded and that the message has or will be delivered. If the outcome of step <b>340</b> is that no public key has been supplied yet, then the key server may optionally check whether too much time has expired already. This test is shown in step <b>360</b>. If, for example, a one month response period has not yet expired, the key server remains prepared to ensure that the message is supplied. In the figure this is indicated by returning to step <b>340</b>. The loop shown represents a waiting loop. It will be appreciated that in an actual implementation this may be done differently, e.g. the server may operate on an ‘interrupt’ basis, where one of the possible triggers is the receipt of a message from the sender with the public key. As part of the waiting loop, the server may send occasional reminders to the intended receiver, for example, a reminder may be sent every three days. For example, the message to the recipient could be: “name@sender.com has sent you a secure email message on dd mmm yyyy. Please go to www.izemail.com/yourcode to download a plug-in for your email program for reading the message securely”. Also regular feedback may be provided to the sender, for example in the form of: name@recipient.com hasn't read your message of dd mmm yyyy yet. We'll keep you informed. If the maximum waiting period has expired, in step <b>370</b> the necessary clean-up operations may be performed or triggered by the key server, like informing the sender that the message could not be delivered and removing the stored message from the secure server.

[0052] Preferably, some or all messages (other than the encrypted message) are signed to increase confidence of the users of the system according to the invention. Advantageously, to help people understand the process, the server can send the original encrypted message to the recipient that is not yet part of the system, suggesting that “this is an encrypted message which I'll help you decipher, if you download my software”. After installation of the software as described above, the message is replaced by the re-encrypted message generated by the server. Technically, the original message can never be decrypted by the user because the user will never get hold of the secret key of the server, needed to decrypt the message. Nevertheless, supplying the message immediately and replacing it at a later stage will help the user in understanding the system and put more pressure on the user to follow the procedure.

[0053] In a preferred embodiment, the sending client is not involved in the management of public keys at all. If the sender wants to send an encrypted message to a recipient it simply encrypts it with the public key of a server, sends the encrypted message to the server together with an indication of the intended receiver. So in effect, the sending client performs steps <b>250</b> and <b>260</b> of FIG. 2. To obtain the public key of the server, the sending client may each time it wishes to submit an encrypted message to the secure server contact the key server to obtain the key. Alternatively, the client may store this single public key and automatically at certain intervals (e.g. every two weeks) perform a test to see if this key is still up-to-date and retrieve an update if this is available. Preferably, the server uses more than one public key, so that each time a new one is selected, the old one may still be used for a limited period. If necessary, the key server can revoke a public key, in particular the key of the secure server. Such an operation may be necessary if the private key of the secure server has been disclosed or is under threat, e.g. by a malevolent employee and for other causes of the server secret key ceasing to be fully secret or usable. In such a case, the server immediately contacts all registered users, for example by sending an email. Alternatively, in response to the sending client contacting the server, the server provides the updated key to the sending client. The sending client then uses this key for encryption. The latter method has the advantage that the user need not be aware of a change of the key and remains confident in using the system.

[0054] In a receiving client that does not yet participate in the system at a certain moment a message that secure email is available will be received as described above. If the user chooses to participate the software is installed, preferably as a plug-in of the email program. In the embodiment where the client station keeps public keys of other stations, after the installation or as part of the installation a so-called key ring is built. To this end, the user's address book may be scanned automatically and keys downloaded for users on the contact list. Preferably, such an operation is done in the background, very gradually, not disturbing the normal operation of the computer. If at a later stage a user stores a new email address, the software automatically contacts the key server to retrieve a corresponding key.

[0055] Once the software has been installed, received email messages are automatically decrypted using its private key and displayed in plain text. Preferably, a small graphic indicates that the message has been encrypted.

[0056] In a preferred embodiment, the storage in the key server and/or secure server is based on a database. This simplifies storing the relevant data in a structured way and makes it easier to allow several ways of specifying a user.

[0057] Digital Certificate

[0058] Preferably, information on a key for a station or user of a station is stored and exchanged in the form of a digital certificate. The digital certificate is a collection of identifying information bound together with a public key and preferably signed by the key server to prove its authenticity. The digital certificate may include (but is not limited to) the following information:

[0059] The version number—this identifies which version of the software and//or protocols was used to create the key associated with the certificate.

[0060] The certificate holder's public key—the public portion of the holder's key pair, together with the algorithm of the key, such as RSA, RSA Legacy, DH (Diffie-Hellman), or DSA (Digital Signature Algorithm).

[0061] The certificate holder's information—this consists of “identity” information about the station or user of the station, such as his or her name, user ID, email address, ICQ number, photograph, and so on.

[0062] The digital signature of the certificate owner—also called a self-signature, this is the signature using the corresponding private key of the public key associated with the certificate.

[0063] The certificate's validity period—the certificate's start date/time and expiration date/time; indicates when the certificate will expire. If the key pair contains subkeys, then this includes the expiration of each of the encryption subkeys as well.

[0064] The preferred symmetric encryption algorithm for the key—indicates the encryption algorithm to which the certificate owner prefers to have information encrypted. Preferred algorithms are CAST, IDEA, Triple-DES, Twofish and Rijndael.

[0065] Digital Signatures

[0066] A sending station that wishes to authenticate (sign) a communication can use its private key, preferably using the PGP protocols. The signature may be an attachment to the message, where the message is unencrypted. If so desired, the message may also be encrypted. The sending stations may send the signed message directly to the recipient providing the recipient with information on how to obtain the software and keys for verifying the signature through the server. Preferably, the sending station sends the signed message to the secure server together with an indication of the intended recipient. The server then verifies the signature using the public key of the sender. If not correct or the server does not have the public key, the server automatically contacts the sender and enables the sender to obtain a correct key pair or make its public key available to the server. The server may also make updates of the cryptographic protocols available to the sending client. If correct, the server signs the message with its own private key and provides the message to the recipient (e.g. emails the message). In a way similar to as described for the encryption, the server stimulates the receiving client to obtain the public key of the server and to become part of the system by creating a key pair and making its public key available to the server. The server preferably also informs the sender of the progress.

[0067] Spam Filter

[0068] In the embodiment where secured message are sent directly to a recipient, preferably secured messages (encrypted and/or signed) are automatically stored in mailboxes other then the one(s) used for receiving unsecured communications. The user can choose to ignore unsecured communications. Preferably, the client's software enables the user to configure that unsecured emails are automatically deleted. Optionally, an automatic reply is given to the sender informing the sender that the message has been automatically been deleted and instructing the sender how secured communications can be sent that will be accepted. The instructions can be similar as has been described above. Preferably, the receiver of an unsecured communication informs the key server so that the key server can inform the original sender and manage the process of getting the sender to obtain a key pair and send secure communications.

[0069] Hierarchy of Servers

[0070] In a simple system it is sufficient to use only one server, that can perform the role of the key server as well as the secure server. The server may be replicated to provide fast access from different areas. FIG. 4 shows a preferred embodiment with a hierarchy of servers. In principle, the hierarchy of servers follows the hierarchy in the Internet with a division between the public part of the Internet <b>400</b>, and restricted parts, shown are <b>410</b> and <b>420</b>. The restricted parts are typically company specific parts of the Internet, also used for communication within the domain of the company. The restricted parts are preferably connected to the public part via respective firewalls. Shown are the firewalls <b>430</b> and <b>440</b>. Communication in the restricted parts may be established in any suitable way, for example using a mix of locale area and wide area technologies. Server <b>405</b> is the public server as described above, in principle designated to service any user/station not serviced by any of the other servers. Preferably, each of the restricted parts of the Internet is serviced by a dedicated server, shown are the servers <b>450</b> and <b>460</b>. This enables companies to enforce an encryption policy from their employees (i.e. for those stations within the company restricted part). This policy can be forced by their own server acting as a key server, policy server, and optionally download server. In this way, companies can ensure that employees send each other encrypted email. Preferably, it is ensured that also any outgoing email (i.e. emails passing through the firewall into or through the public part of the Internet) is encrypted. In a preferred embodiment, the system is configured that clients within a restricted part for any service of a server always contact the server dedicated for the restricted part. If this server can not provide the service (e.g. a public key of a user in the public part of Internet is requested), preferably the server takes care of obtaining such information from the public server <b>410</b>. Alternatively, the software in the client already decides which server to use. Such a decision could be based on whether the recipient is an employee of the company (for instance judged by the extension of the communication identification or not. The company server <b>450</b>, <b>460</b> preferably services any secure communication for all authorized users in the respective restricted part <b>410</b>, <b>420</b>. Additionally, the company server services any secure communication with authorized users outside the restricted part, e.g. users in the public part or another restricted part. As an example, keys of customers or suppliers of a company may be added to the company server. In this way the company has much more control of the secure communication with its customers and suppliers. Particularly in a situation where companies have a close relationship, it is preferred that the company servers of the companies cooperate, for example by regularly synchronizing the databases. In this way, communication between the companies can be kept more secure. In particular, changes in employees that are updated in the database of the company internal server can be made available to key outside companies in a quick and reliable way.

[0071] Advantageously, all communication between a station and the server is secured. This may be done by creating a secure connection through the Internet, for example using SSL (secure socket layer). Preferably, all messages to a user of a station are signed by the sending party. This will increase confidence in the system and get a user more acquainted with the concept of digital signatures.

[0072] In a preferred embodiment, the server also takes care of secure communication with stations outside the system. As an example, the protocols used within the system may be based on the PGP set and implementation of cryptography. The server can establish an interface to PGP clients that do not use the client's software according to the invention, but use other implementations of PGP. The server may also take care of conversion between different sets of protocols. For example, the sending client may communicate with the key server and/or secure server using a first set of protocols, whereas the receiving client may communicate with the server(s) using a different second set of protocols. The server can perform the conversion by decrypting a secured message received from the sender using the protocols for the sender and the private key of server for those protocols, and re-encrypting it using the protocols of the receiver and the public key of the receiver for the receiver's protocols.

[0073] It should be noted that the above-mentioned embodiments illustrate rather than limit the invention, and that those skilled in the art will be able to design many alternative embodiments without departing from the scope of the appended claims. In the claims, any reference signs placed between parentheses shall not be construed as limiting the claim. The words “comprising” and “including” do not exclude the presence of other elements or steps than those listed in a claim. The invention can be implemented by means of hardware comprising several distinct elements, and by means of a suitably programmed computer. Where the system/device/apparatus claims enumerate several means, several of these means can be embodied by one and the same item of hardware. The computer program product may be stored/distributed on a suitable medium, such as optical storage, but may also be distributed in other forms, such as being distributed via the Internet or wireless telecommunication systems.