Comments on Masabists: Problems with Mobile Security #1

Hello again slakin duff,I can see that you mean we...

2008-08-07T10:08:00.000+01:00

Hello again slakin duff,

I can see that you mean well, and you are exactly correct in your assertion that encryption alone does not equal security.

In the article body we state "And good choice of algorithms isn't enough! You must use them in a wise way with user education, good seeding, padding, key management, and protection against replays, insertions, concatenations, man in the middle, phishing and all manner of other attacks that cryptography alone will not solve"

Just saying that you use AES is not enough, as you say. You say that you cannot identify anyone today doing as I have suggested, so email me direct, and I'll give you some systems to have a look at to find issues as I have described, and also issues mentioned in our subsequent posting about random number generators

We never mentioned a one-time pad, but we are using a variety of the approach, in the keystream generated from AES CFB (as are almost everyone on the internet right now). The whole point of securing the keystream seed/key and not the full message is that it's much smaller and easier to pass around inside the more costly (slow) RSA encryption block used for key exchange than the whole message. You can then use the generated keystream to protect a long, or in fact, streamed message with a much more efficient encryption. Some people do use RSA for everything, but it's not practical in all situations.

We are not saying that cryptography generated in "ivory towers" is secure, or that there is no way of carrying out secure business without it.

But I will say this:
1: If you are passing confidential information via the internet, or any other public telecommunications network, you should do something to prevent that data being mis-used by other parties.
2: If you create your own cryptography to form a part of your security, and don't build it and test it to a public standard, then history tells us that it is more likely that there will be a weakness in your approach.
3: The publicly approved algorithms have not been created, tested and approved by a mysterious "ivory tower", but are publicly recommended because they have been published, subjected to attack and investigation by many well funded departments in government and university security groups, and also by educated volunteers. It is only once plenty of people have had a chance to attack and investigate a system which is fully exposed would a cryptographic approach become mature enough to be included in standards like FIPS.

I'm not entirely sure how to answer your final question. Keeping your security system secret means that you don't benefit from other people with fiendish and different minds helping to find your mistakes, unless they are doing it in secret to damage your system. Publishing is the sensible way to test a security system, unless you are running it off-line, in a physically secure location (or concrete bunker).

Another interpretation of your final question: people in huge and "solid companies" can throw money and cryptography at their systems, and still not provide security, regardless of the crypto-standards and buzz-words, and we've seen that happen.

It is quite tricky to build something very secure, and almost impossible to build something completely secure.

Unfortunately it's quite easy to build something that looks secure (i.e. uses AES in a naive/unsafe manner) but would fall to the simplest of attacks, once someone has figured out what you are doing (which is easy when you reverse engineer java).

The companies involved probably think that they have got something secure, and that provides the appearance of security, which to the consumer, business insurer, or investor is an important thing. It will only become a problem when they become interesting to an attacker, and until that happens, simply obscuring their data with a caesar-cipher would have been just as effective!

Sorry, I was detained. Let's start at the top with...

2008-08-07T03:48:00.000+01:00

Sorry, I was detained. Let's start at the top with your references to the "Snake Oil" article.

The first assumption is that all security can be reduced to the application of encryption. Wrong.

The second assumption being made invariably, is that JUST BECAUSE you use encryption the security is good. Wrong again. Many breakins have taken place and the data was encrypted (TJ Maxx). Encryption doesn't do much to protect you from insiders. And look what a stinking mess DNS is in, SSL or not. Certificates are being duped and all. It's a disaster.

The third assumption being made is that just because an individual can read the "Snake Oil" article, they can then discern for themselves whether a particular security product (SW or HW) or service is good. Wrong. For some, it's like reading instructions to operate an electron microscope, then being told "There...you read the instructions, now go use it!"

"Snake Oil" is simply predicated on past cases where some have passed off bad products at the expense of others. I won't make any comments about the author. The fact is, "Snake Oil" as it is, is useless.

In fact, I cannot identify anyone today, attempting to do as the author describes. Perhaps there are such people. BUT MY POINT IS there are thousands of products (SW and HW) and services being offered by what appear to be solid companies that I have no way of evaluating.

During the past year everyone and their brother has released a security product. Am I supposed to believe they are all good, JUST BECAUSE they tell me they use AES256??? How do you or anyone else know that they're applying the algorithm properly? Where are the keys stored, where do they originate? Do you know? Does the sales person even know or care? No, just so long as they say "we use AES256", I'm supposed to think it's OK. And even if it's FIPS certified, should I trust them not to keep a copy of MY keys? I have no way to know that in the future a company will not come under an order from some authority to disclose all my data... for whatever reason. And the mere possession of encrypted data can get me in trouble.

Don't even get me started about the idiotic statement that only encryption algorithms from ivory tower people can provide security. I can give you several ways to protect data that do not use encryption, do not XOR the data with a one-way pad (not really encryption), yet it is physically impossible to determine the original contents of the data.

BTW, the application of a one-time pad is academic. Why does this keep coming up? All you are doing is exchanging the burden of protecting one document with that of another. This does not have a practical use in communications. And forget about steganography.

Encryption has several problems. Why would anyone conduct development of superior means to protect data at rest, or during communications, if it was completely useless? Why not keep it to themselves? They'd actually be better off the more people think it is snake oil and can't work.

Thank you for allowing me to comment.

Hi Slakinduff,yes, the blog is alive (look at the ...

2008-06-12T15:42:00.000+01:00

Hi Slakinduff,

yes, the blog is alive (look at the latest posts on blog.masabi.com)

We posted here to encourage people to contribute and let us know what they think, or what we made a mistake on, so that we can answer criticism or improve things that are oversights, and so that all readers of the blog can be informed about security issues and approaches on mobile from both posts and comments.

Do elaborate on your comments, but please try to be constructive and informative in your criticism.

Hello, At this moment I am doing my thesis on mobi...

2008-06-12T10:16:00.000+01:00

Hello,

At this moment I am doing my thesis on mobile commerce possibilities.

I thought this article was really interesting for me but I just read the latest comment...

Yes, slakinduff I am reading and I am very interested in what you have to add to this article.

Maarten van Dijk

Several mistakes here, dim comments, and linked si...

2008-06-11T15:36:00.000+01:00

Several mistakes here, dim comments, and linked sites are full of errors, too.
I want to elaborate, but first let me know someone is out there. Everything is so old, not sure it's worth my time if no one is even looking here. Hello???

An excellent article - concise and precise. Having...

2007-09-28T17:27:00.000+01:00

An excellent article - concise and precise. Having worked on quite a few mobile solutions, I'd thought that HTTPS was as best as it could get, especially considering a slight performance cost with Bouncy. I'm impressed that you could fit an encryption system into a footprint that small!

I've sent you an email too at your (email us) link, hope it reaches the right desks ;), if there is any other address, please let me know.
Thanks.

Hello anonymous,Re-reading the advisory, you are a...

2007-07-19T18:37:00.000+01:00

Hello anonymous,

Re-reading the advisory, you are absolutely right that the first link to RC4 advisory is specific to SSH not SSL, and as such is not appropriate in this context - it wasn't deliberate, but that's no excuse in security.

However that does not change the fact that RC4 is not considered very good by security professionals and academics, in fact
"most security professionals recommend using alternative symmetric algorithms". There are a number of known mathematical weaknesses in the algorithm - the flaws are not just in RC4 implementations such as the SSH advisory I incorrectly linked to.

Also the quote from William Burr of NIST about RC4 never becoming a FIPS standard is accurate, and you will find that it still isn't approved to this day.

You say it's "good enough for most practical purposes" but why use something in new products which has doubts raised about it when there are better alternatives? RC4 should be in graceful retirement, only supported for legacy systems. It's putting your head in the sand to continue adding it to new products, and is building problems for the future completely unnecessarily.

About connection speeds, I don't completely understand your point about latency, but can't email you to confirm what you meant. We perform one connection only, and our encryption is faster than HTTPS, hence the speed improvement.

Apples and oranges? I am comparing one version of secure comms over HTTP (HTTPS) with another method of securing comms over HTTP (EncryptME), and ours is significantly faster no matter how many times you run the tests, and on whatever device, thanks to it having to do fewer things. And before you ask, yes, it is protected against replay attack.

Of course this is a company blog and we have a vested interest in marketing our products, but this article was not intended just as a vehicle for FUD and promotion - we would happily use SSL for MIDP if it actually worked consistently and securely across all devices. Sadly the mobile world is never that simple and I have outlined the reasons here.

while I realise this is a marketing piece, that's ...

2007-07-19T17:23:00.000+01:00

while I realise this is a marketing piece, that's not excuse for peddling FUD about other alternatives.

Point number two about out of date symmetric ciphers is pretty badly wrong. In actuality, RC4 only has one significant cryptoanalytic result against its name beyond brute force, and that can be worked around. In any case, the result doesn't affect the use of RC4 in TLS. The only concern about RC4 is the keysize, but it's good enough for most practical purposes.

The cert advisory you link to in support of your case isn't anything to do with the security of RC4 itself, but in fact a vulnerability in the SSH protocol. If you took it as an example of why null terminated strings and not validating input are a bad idea, then you'd be right. Giving it as an example of RC4 being a bad thing is disingenuous.

I'm also rather interested in the statistics you have in point 5 about encryptMe. In the fastest machine tested, the N80, the connection setup time would seem to be faster than the latency will allow. OK, you can trim down the TLS startup time by using a pre-agreed cipher suite, but security dictates there be a minimum of three messages. One in one direction, and two in the other. If you could elaborate on that point, it'd be interesting. I suspect it compares apples with oranges....

post in haste, repent at leisure.... a couple of o...

2007-07-14T09:19:00.000+01:00

post in haste, repent at leisure.... a couple of omissions that have nagged me:

plain text SMS will hang around in most users' sent-items folder on their phone so that phone thieves or anyone who gets hold of your phone can retrieve pins, passwords and Card details, and potentially use your phone to abuse them.

What have I got against Opera?
Absolutely nothing, I think it's a great product, and well written, and as such can cope with my mentioning it as an example of not quite reaching perfection. They couldn't avoid decrypting confidential info at their transcoder as they are a browser, not a single purpose application. (but they could add encryption to OperaMini basic if they really wanted to)

There are plenty of companies and products in the press right now that I could name and shame as examples of real security failings, but that would be a bit too aggressive, and I'll leave the educated reader to join the dots.