Interview with Erik Kangas, President of Lux Scientiae
by Berislav Kucan - Wednesday, 15 January 2003.
Beyond these confidentiality issues, unencrypted email traversing the general Internet can be untraceably modified or deleted by people in the "right" place or with the "right" access. Emails can also be captured and resent later, possibly with modifications. This could have a devastating effect on a business!

The only way to prevent this is to use a combination of encryption and digital signatures in your business email to prevent eavesdropping, provide modification detection, and provide non-repudiation for messages traveling through the general Internet and through the corporate Intranets.

Even messages confined to a corporate Intranet are subject to all of the same kinds of attacks that messages traveling over the general Internet are vulnerable to, should a hacker break into the Intranet or should an employee or other insider wish to compromise the system. Especially if a company has a large Intranet, it should consider using secure email even for internal email messages as this threat is much greater than is usually perceived.

Are there problems with secure messaging interoperability?

First, let me point out that there are no interoperability problems involved in using IMAP, POP, and SMTP over SSL or TLS. All modern email clients support these types of secure connections and are generally very easy to configure.

The interoperability problems come in when try sending or receiving encrypted or digitally signed messages. The first problem is that there is not a single standard for encrypting and signing messages; the two most prominent methods are PGP and S/MIME. These are completely incompatible; if you are using PGP and your friend is using S/MIME, you will not be able to send each other secure messages.

That said, PGP has been an Internet standard (OpenPGP - RFC 2440) since 1997 and PGP-encrypted email accounts for well over 90% of the current encrypted email traffic on the Internet. So, using PGP will make you compatible with the majority. However, what really counts is the minority that you actually need to communicate with and their needs. Therefore you may find a need for the use of S/MIME if your correspondents like using its 3rd party issued certificates for email communications rather than PGP's trust model. It is useful to know that some email clients, such as Microsoft Outlook, can be configured to use BOTH PGP and S/MIME so that you can correspond securely using whatever method is necessary at the moment.

The other interoperability issue involves "key exchange". Both PGP and S/MIME are public key cryptography systems in which each user has a public and a private key. If you want to send your friend an encrypted message, you first need his/her public key; if your friend wants to prove that you signed a message or that the message that you sent him/her was unaltered, s/he first needs your public key. So there is the necessity of trading public keys before secure communication can ensue. There are various ways of doing this and PGP offers "key servers" from which your correspondents' keys can be downloaded to make the process easier. However, not everyone has their PGP keys listed on a key server, let alone the same key server, and not everyone uses PGP, so the key exchange issue is still an impediment to sending secure messages -- especially if you have to send them quickly.

From your experience, is secure messaging being a part of security policies deployed within companies?

Spotlight

Operation Pawn Storm: Varied targets and attack vectors, next-level spear-phishing tactics

Posted on 23 October 2014.  |  Targets of the spear phishing emails included staff at the Ministry of Defense in France, in the Vatican Embassy in Iraq, military officials from a number of countries, and more.


Weekly newsletter

Reading our newsletter every Monday will keep you up-to-date with security news.
  



Daily digest

Receive a daily digest of the latest security news.
  

DON'T
MISS

Fri, Oct 24th
    COPYRIGHT 1998-2014 BY HELP NET SECURITY.   // READ OUR PRIVACY POLICY // ABOUT US // ADVERTISE //