Skip to main content

Flaw in email security means signed mails cannot be encrypted

I was at a company the other day that uses a well-known email encryption solution as they have some very sensitive information that they need to send both internally and externally. As is common for these solutions, it is possible to automatically sign the email by putting a keyword in the subject line, such as 'signemail'. Similarly, the mail will be encrypted automatically if the confidential flag is set or a keyword, such as 'encryptemail' is added to the subject.

So far, so good. There are no messy button presses or extra steps for the user. However, there is a flaw with the solution. (I should point out that at this moment it is unclear if it is a product problem or a configuration problem, hence my not mentioning the product.)

The issue is that signing the message appears to take precedence over encryption. So, if you add both keywords to the subject then the message will only be signed and not encrypted. Now the encryption solution does also sign the message, so if you want it encrypted then you don't need to specifically sign it as well.

So is this really a problem or am I just making a fuss? Well, I can envisage several situations when it would be a problem. The most likely is probably replying to a signed message with confidential data. Let's say that Alice puts in a request for sensitive information from Bob via a signed email - only certain people can have access to the information so it is reasonable to expect Alice to digitally sign the request, but the request is not sensitive in itself.

Now, if Bob replies to that request with the sensitive information attached he will follow policy and mark it as confidential and add the encryption keyword, 'encryptemail', to the subject line. He will now assume that the information will automatically be encrypted. However, if he doesn't remove Alice's 'signemail' keyword it will just be signed and not encrypted. This then violates the policy and sends confidential information in plaintext while the user believes that it has been encrypted.

It also highlights that you shouldn't use a keyword that might be used as part of everyday language. For example, don't use the keyword 'sign' as someone could send a sensitive document with a subject something like 'Contract for you to sign'.

I suggest that everyone using this type of solution should test it to see if this happens on their system. If it does, you will, at the least, need to publish an advisory warning to your users.
Labels:

Comments

  1. public key infrastructure21 November 2011 at 02:18

    I really enjoyed the article. It proved to be Very helpful to me and I am sure to all the commentters here!Keep writing.Thanks.

    pki certificate.

    ReplyDelete

Post a Comment

Popular Posts

Coventry Building Society Grid Card

Coventry Building Society have recently introduced the Grid Card as a simple form of 2-factor authentication. It replaces memorable words in the login process. Now the idea is that you require something you know (i.e. your password) and something you have (i.e. the Grid Card) to log in - 2 things = 2 factors. For more about authentication see this post . How does it work? Very simply is the answer. During the log in process, you will be asked to enter the digits at 3 co-ordinates. For example: c3, d2 and j5 would mean that you enter 5, 6 and 3 (this is the example Coventry give). Is this better than a secret word? Yes, is the short answer. How many people will choose a memorable word that someone close to them could guess? Remember, that this isn't a password as such, it is expected to be a word and a word that means something to the user. The problem is that users cannot remember lots of passwords, so remembering two would be difficult. Also, having two passwords isn't real...
Post a Comment
Read more

Trusteer or no trust 'ere...

...that is the question. Well, I've had more of a look into Trusteer's Rapport, and it seems that my fears were justified. There are many security professionals out there who are claiming that this is 'snake oil' - marketing hype for something that isn't possible. Trusteer's Rapport gives security 'guaranteed' even if your machine is infected with malware according to their marketing department. Now any security professional worth his salt will tell you that this is rubbish and you should run a mile from claims like this. Anyway, I will try to address a few questions I raised in my last post about this. Firstly, I was correct in my assumption that Rapport requires a list of the servers that you wish to communicate with; it contacts a secure DNS server, which has a list already in it. This is how it switches from a phishing site to the legitimate site silently in the background. I have yet to fully investigate the security of this DNS, however, as most...
13 comments
Read more

Web Hosting Security Policy & Guidelines

I have seen so many websites hosted and developed insecurely that I have often thought I should write a guide of sorts for those wanting to commission a new website. Now I have have actually been asked to develop a web hosting security policy and a set of guidelines to give to project managers for dissemination to developers and hosting providers. So, I thought I would share some of my advice here. Before I do, though, I have to answer why we need this policy in the first place? There are many types of attack on websites, but these can be broadly categorised as follows: Denial of Service (DoS), Defacement and Data Breaches/Information Stealing. Data breaches and defacements hurt businesses' reputations and customer confidence as well as having direct financial impacts. But surely any hosting provider or solution developer will have these standards in place, yes? Well, in my experience the answer is no. It is true that they are mostly common sense and most providers will conform...
10 comments
Read more