Heml.is – This Just Isn’t Security

heml.is_

In light of all the recent panic over surveillance and Internet monitoring, there are a plethora of “secure” communication programs being announced and launched. These tend to make bold promises of being secure, protecting users from surveillance, and being better than equivalent services.

Yesterday, 3 notable personalities in the web-o-sphere lost much credibility in my (and anyone interested in security’s) view. Why? For using pseudo-security, and trying to market it as security. They clearly do not have a strong background in cryptography or security theory, and appear out to make money, rather than to create a well-designed and well-architected, resilient and decentralised service. And I’m not against someone making a commercial service, but hey, at least design it well, and make it open source.

Open source doesn’t prevent being a commercial success. Take a look at, say, Android, or RedHat Linux, or SUSE, or indeed any open source project with a company behind it that doesn’t turn a loss (and hey, a company that runs at a loss won’t last long).

Without further ado, let’s just take a look at what they say about their service.

From their own FAQ:

Will it be Open Source?
We have all intentions of opening up the source as much as possible for scrutiny and help! What we really want people to understand however, is that Open Source in itself does not guarantee any privacy or safety. It sure helps with transparency, but technology by itself is not enough. The fundamental benefits of Heml.is will be the app together with our infrastructure, which is what really makes the system interesting and secure.

While it is true that being open source alone is not a guarantee of security, they want to open the source, “as much as possible”. Yet they are intent on offering a closed platform. From history, lessons have been learned about poor security, such as Cryptocat, which is open-source, and has had many security holes. Would these holes (which are critical to the security of the service) have been found if it was not open source? Arguably not, as they arose in review of the source code.

Is it really secure?
Yes and no. Nothing is ever 100% secure. There will not be any way for someone without access to your phone to read anything, but with access to your phone they can of course read the messages. Just as they can use any other app you have installed.

This suggests the decryption keys are stored unprotected on the device, meaning a rooted device permits trivial key retrieval. This can easily be avoided by encrypting the key with a strong, password-derived key. Every rooted user should be aware of this. But likely won’t, as the makers appear unwilling to suggest downsides of the system.

Your server only?
Yes! The way to make the system secure is that we can control the infrastructure. Distributing to other servers makes it impossible to give any guarantees about the security. We’ll have audits from trusted third parties on our platforms regularly, in cooperation with our community.

How is this ANY better than iMessage, or any other large-corporation, closed-source rival? If they control the infrastructure, and one cannot freely review the source code running on it, this is just as bad as iMessage, which is simply not secure. They mention third party audits in cooperation with the community, but what community will there be, when the software is closed source, and entirely centralized?

Will you provide an API and/or allow third party clients?
At this point we don’t see how that would be possible without compromising the security, so for now the answer is no.

In security, the mantra is “trust nothing”. In particular, it is NEVER safe to trust the end user’s device, or client software. The answer above says that they, the experts, cannot see a way to permit an API or third party clients, without compromising security. As everyone familiar with XDA knows, it is trivially easy to modify apps and their underlying code, as is seen with tools like smali and apktool, as well as the Xposed Framework. 

It is clear that this Heml.is system is placing far too much trust in the clients in this system. While alternative systems are trusting nobody but themselves (for example, Bitcoin), this is a step backwards, towards the dependent situation where users are forced to trust a closed network, over which they have no input. This closed network can only run on the servers of the service provider.

Does Heml.is save every message on a server?
Messages will only be stored on our end until they have been delivered to the recipient. We might add support for optional expiry times to messages, in which case messages would be stored until they had been delivered or they expire. Whichever comes first.

Frankly, this answer actually made me laugh out loud, and get many a strange look. This is the kind of answer that public relations (PR) people dream of. The answer here is “yes”, and the people behind Heml.is even admit it. But they fail to recognize that with an untrusted central server, you are forced to go simply on THEIR WORD that they actually do remove these messages. What makes you certain they do remove them? And that they always will? Do you trust the NSA to remove what they store about you? Do you trust iMessage to? Why should you trust Heml.is to?

I honestly cannot understand why they have brought this kind of product to the public at this stage; they have proposed nothing in any way better than ANY other service on the market. There is as much guaranteed security in this system as there is in standing on a pedestal in a crowded city with a megaphone and shouting your correspondence to the world. This is a real shame, as I really hoped that Heml.is would be different. I thought more from its developers, who have reputations for being sensible and privacy/security conscious.

What is on offer here is a closed-box security system. Statistically speaking, any project of this magnitude will have at least 1 major flaw in its cryptographic implementation. And I can already predict that flaw, having no access to the software, or indeed any information beyond that available to us all from their website. So I will make that prediction now, and in public. This system will, in my professional opinion, rely on trusting their centralized server for the identification and authentication of users to each other. Meaning, if the central server is compromised, or the operators are forced through duress, they would be able to modify the server so a request for Bob’s public key would return a public key under the control of the attacker. The only way to alleviate this is to have an entirely open and distributed, decentralized back-end, which never trusts a client not to lie, and a client that never trusts the server.

It is not currently possible to achieve perfect security in this sense (of being assured the key you receive is from the person it claims to be), short of in-person verification of key fingerprints. But it is possible to at least not rely on a centralized server to be trustworthy, when that server is not able to be inspected by yourself, and independently run. This was a major opportunity for a totally distributed network facilitating free and secure private communications, which has been spoiled through a lack of experience by those designing it, with regard to security.

I see no way that even the proposal can withstand any kind of scrutiny from those in the security field such as myself. I would love for the guys behind it to get in touch, and see if they are willing to address some of these issues. Perhaps it’s all a big set of misunderstandings, but from the wording here, this system is wholly insecure, and relies entirely upon their “service in the middle” to honestly relay keys to users. And if they’re going for “all out convenience”, that will be the easiest way to go. But there are plenty of changes they can make to improve this system, and if they are willing to discuss this, I am more than happy to make a few suggestions that would eliminate the issues with their central server, and “no third party clients” (which effectively means they wouldn’t properly open-source the resulting application).

Peter, Leif or Linus, drop me an email (pulser _at_ xda-developers.com) and we can have a constructive chat about this, and if you want to make a response here, add one. As it stands though, this whole project comes across as an exercise to produce money from the “masses” for the promise of secure communications. And there’s nothing wrong with that. But at least make it use proper, well-designed, and robust security principles, which will stand up to users making use of third party clients, or being able to ensure they are not placing any trust in your server for key distribution. If you rely on trusting the user’s client to behave, or on your server to never be compromised (and your staff never placed under legal or physical threats), then one day, the walls will crumble down. And it’s all achievable, while being fully open-source, open-standard, and open-platform.


_________
Want something on the XDA Portal? Send us a tip!

Tags: