In addition to the many user-facing improvements in the latest incarnation of Android announced yesterday, there are a number of interesting security improvements, which seem to indicate that Google have not totally neglected platform security in this new release. This article will run through what’s new, and what it means for you.
SELinux in Enforce Mode
In Android 4.4, SELinux has moved from running in permissive mode (which simply logs failures), into enforcing mode. SELinux, which was introduced in Android 4.3, is a mandatory access control system built into the Linux kernel, in order to help enforce the existing access control rights (i.e. permissions), and to attempt to prevent privilege escalation attacks (i.e. an app trying to gain root access on your device).
Support for Elliptic Curve Cryptography (ECDSA) Signing keys in AndroidKeyStore
The integrated Android keystore provider now includes support for Eliptic Curve signing keys. While Eliptic Curve Cryptography may have received some (unwarranted) bad publicity lately, ECC is a viable form of public key cryptography that can provide a good alternative to RSA and other such algorithms. While asymmetric cryptography will not withstand quantum computing developments, it is good to see that Android 4.4 is introducing more options for developers. For long-term data storage, symmetric encryption remains the best method.
SSL CA Certificate Warnings
Many corporate IT environments include SSL monitoring software, which adds a Certificate Authority (CA) to your computer and/or browser, to permit the corporate web filtering software to carry out a “man in the middle” attack on your HTTPS sessions for security and monitoring purposes. This has been possible with Android by adding an additional CA key to the device (which permits your company’s gateway server to “pretend” to be any website it chooses). Android 4.4 will warn users if their device has had such a CA certificate added, such that they are aware of the possibility of this happening.
Automated Buffer Overflow Detection
Android 4.4 now compiles with FORTIFY_SOURCE running at level 2, and ensures all C code is compiled with this protection. Code compiled with clang is also covered by this. FORTIFY_SOURCE is a security feature of the compiler, which attempts to identify some buffer overflow opportunities (which can be exploited by malicious software or users to gain arbitrary code execution on a device). While FORTIFY_SOURCE doesn’t eliminate all possibilities of buffer overflows, it certainly is better used than unused, to avoid any obvious oversights when allocating buffers.
Google Certificate Pinning
Expanding on the support for certificate pinning in earlier versions of Jellybean, Android 4.4 adds protection against certificate substitution for Google certificates. Certificate Pinning is the act of permitting only certain whitelisted SSL certificates to be used against a certain domain. This protects you from your provider substituting (for example) a certificate provided to it under an order by the government of your country. Without certificate pinning, your device would accept this valid SSL certificate (as SSL allows any trusted CA to issue any certificate). With certificate pinning, only the hard-coded valid certificate will be accepted by your phone, protecting you from a man-in-the-middle attack.
It certainly appears that Google have not been resting on their laurels with Android security. This is in addition to the inclusion of dm-verity, which could possibly have serious consequences for people who like to root and modify their devices with locked bootloaders (i.e. which enforce kernel signatures).
November 1, 2013 By: Pulser_G2
Android 4.4 introduces a number of changes intended to reduce the risks of rootkits on the platform. In addition to SELinux, the dm-verity kernel feature is also used on boot. The dm-verity feature is used to verify the filesystem storage, and detect modifications to the device at block level (rather than file level). In essence, dm-verity aims to prevent root software from modifying the device file system. This is done by detecting the modifications made to the filesystem, which will no longer match the expected configuration.
In dm-verity, each block of the storage device has a SHA-256 hash associated with it. (For reference, a block is simply a unit of address for storage, typically around 4 KB on flash devices.) A tree of hashes is formed across pages, such that only the “top” hash in the tree (known as the root hash) needs to be trusted, in order for the entire filesystem to be trusted. If any block is modified, this will change the hash, breaking the chain.
The boot partition of the device will contain a public key, which the OEM is expected to externally verify (perhaps via the bootloader or low-level CPU features). This public key is used to ensure the signature of the hash on the file system is valid and unmodified.
In order to reduce the time taken to verify the filesystem, blocks are only verified when they are accessed, and are verified in parallel with the regular read operation (to essentially eliminate any latency with accessing the storage). If the verification changes (i.e. files have changed on the system partition), then a read error is generated. Depending on the application accessing the data, it may proceed if it’s not a critical action, but it is also possible for applications to decline to operate under these conditions.
While nobody can predict the future with 100% accuracy, I think it’s fair to say that “rooting” and modifying devices running Android 4.4 with locked bootloaders (i.e. where root exploits are required, as the OEM will not permit custom kernels) may well be considerably more difficult than in previous Android versions. It seems that Android 4.4 is taking a few leaves out of the Chrome OS book, as these changes essentially implement “verified boot,” as found on Chrome OS.
To re-iterate, if you are able to change the kernel your device uses, this feature will not be a concern. It’s possible to either disable dm-verity in the kernel, or to set it up to use your own keys to authenticate the system hash. For users who choose to buy carrier-branded devices and accept a locked bootloader, but find a way to root the device, take heed of this warning. It’s not at all unlikely (in my technical opinion) for this to happen on future devices. If you want the ability to modify the software on your phone, I’d avoid anything with a locked bootloader, and ensure you can modify the kernel (to disable or modify the dm-verity signatures).
Right now, little is known about what this will actually mean, but aside from greater security for users on stock ROMs, I suspect there will be some noticeable impact on casual users wishing to make small changes to Android. Until we see devices from other OEMs shipping with 4.4, it’s difficult to really assess how (or if) this will change things. But take note, and bear it in mind.
October 31, 2013 By: Jimmy McGee
If you’ve ever handed someone your phone to someone, whether to show them a funny picture or if they ask to check it out, you know the terror that runs through your mind thinking of what they could stumble upon: your usernames and passwords for different sites, your special ‘recipe,’ your mistress’s phone number, anything.
Well, XDA Forum Member msappz offers a new way to keep your secret life private. In this video, XDA Developer TV Producer Walter White TK reviews Safe N Secure Notepad. TK shows off the application and gives his thoughts, so check out this app review.
October 13, 2013 By: Will Verduzco
The answer to the question above, as security researcher Philip Marquardt demonstrated, is “yes.” However, it’s not all that likely in practice, and there are several simple ways to protect yourself.
Data security is a rapidly growing concern in our increasingly digital world. In order to help bring these concerns to light, we recently launched a Security forum specifically for discussion of various security-related topics. Not too long ago, we also talked about malware on Android and how this is largely an overstated problem for those running relatively recent builds of the OS. However, when most people think of mobile security, they think of protecting their own device from intrusions. What many people haven’t considered is the possibility of using a mobile device’s various built-in sensor array to spy on unsuspecting victims.
This is exactly what Philip did while at Georgia Tech, as part of a proof-of-concept keystroke logger. This keylogger works in a rather unconventional way. Rather than using a physical connection to intercept data between a target computer and its keyboard or malicious software stored on the target computer, Philip demonstrated that an iPhone 4’s accelerometer could be used to determine the keystrokes pressed on a nearby physical keyboard. Using two neural networks (one for horizontal distance, and one for vertical distance), the software was able to correlate vibrations picked up by the phone’s accelerometer with their associated keystrokes.
Naturally, there are some major limitations preventing this from becoming the next big security scare. First, a rather precise and sensitive accelerometer must be used. For example in Philip’s testing, the iPhone 3GS was not sensitive enough to work properly, but the iPhone 4 was. Second, the mobile device doing the data acquisition must be relatively close to the physical keyboard being used because as we all know, unfocused vibrational energy through most transmission media dissipates according to the square of its distance. Furthermore, even with extended learning time, individual keypress recognition was impossible and whole word recognition was only 46% accurate—with shorter words being correspondingly less accurate.
Despite the initial limitations in individual key press and low individual word accuracy, however, reliability increased dramatically to 73% if second-choice words were also counted. Thus, semantic analysis clearly has a powerful effect in tuning word detection in context. That said, this would render detection of passwords and other non-semantically relevant data impossible.
So while this is extremely unlikely to be used in the wild in its current form, and the current detection accuracy limits its use to dictionary words, I know that I’ll be a bit more careful if I notice some unknown mystery object on my desk. After all, the sensors in our mobile devices are only become more and more accurate. Furthermore, more purpose-built sensors can conceivably be used to achieve a higher detection accuracy.
Ultimately, there are many more likely ways in which your data will be stolen, so this is nothing to lose sleep over. And if you really wish to protect yourself from the possibility of accelerometer-based spying, just make sure there are no hidden devices on your desk next to your keyboard. Now, acoustic emanation word detection (PDF)… That’s something far more worrying and far more difficult to thwart. I guess it’s time to listen to loud, bass-heavy music whenever I type sensitive information. It may go well with my tinfoil hat.
You can learn more about Philip’s research by viewing his security research paper (warning: PDF).
Via I Programmer.
[Thanks to security researcher John Doyle for the heads up.]
A little over a year ago, we took at Anti Spy Mobile, an application by XDA Senior Member pandata000 that was aimed at helping users make sure that their applications’ permissions were in check. The previously mentioned app worked by figuring out which applications are installed, searching for well known spyware, analyzing permissions and Android intents, and giving an easily understandable output to the user listing potential trouble spots. Anti Spy Mobile unfortunately is not able to track the actual connections made by spyware.
In response to user request, pandataooo has now created a new application aimed at showing all of your current connections. Aptly titled Network Connections, pandataooo’s new app monitors and logs all connections from every network-connected app so that you know where exactly your data is going. Similar to the netstat command, this app works for both inbound and outbound traffic, and it displays the output on a per-app basis. Network Connections is even compatible with non-rooted phones. In other words, you have no excuse for not at least checking periodically.
Head over to the application thread to get started.
Please note: Network Connections normally comes in two forms: lite and premium. There are a few minor restrictions in the light version such as an unobtrusive nag screen and a limit on how long you can leave continuous capture enabled. The application can be relaunched indefinitely, allowing users to still capture connection information after the limit has been reached. However, as a special offering to the XDA community, the developer has made an unlocker available from now until next Saturday (10/19/2013) that will give you a permanently free copy of the premium app.
We’ve all heard about the Android malware problem. After all, proponents of other mobile operating systems love to spread FUD stating that Android’s malware situation is out of control. Further, there are various entities such as antivirus firms with vested interests in demonstrating that there is indeed an issue.
Who’s to blame the companies using these unscrupulous tactics? After all, it’s simply good business to undermine your mobile OS competitors or create demand for your product in the case of security solution providers. And up until very recently, Google unfortunately lacked a reliable way of determining and tracking the scope of the problem. That changed recently, however, when Google introduced its current multiple layers of defense, which is seen in the infographic to your right.
According to a presentation by Android Security Chief Adrian Ludwig, it is estimated that less than 0.001% of application installs are able to evade the platform’s multi-layered defense system—a system which includes sandboxed permissions, application verification, trusted sources, and runtime defenses. This figure includes both applications installed through Google Play, as well as the 1.5 billion applications installed through other means (side-loaded or alternate app stores).
So what does the data show? When installing from non-Google sources, under 0.5% of applications are flagged by the application verification system. Of these, under 0.13% of these applications end up being installed by the user, and under 0.001% of these attempt to evade Android’s runtime defenses. The actual number that is able to cause harm and evade these defense mechanisms is unclear, but if the data is to be believed, it would reason that this number is smaller than 0.001% of applications that users attempt to install.
The next major question becomes which apps are most frequently flagged by the application verification system. Research presented by Ludwig demonstrated that nearly 40% of these applications are “fraudware” apps that make premium phone calls and text messages. Another 40% are rooting apps, which are “potentially harmful,” but not malicious per se. Then, 15% of the apps are commercial spyware, which track things such as Internet behavior or collect other personal information. The remainder is a diverse group of truly malicious apps.
In the grand scheme of things, 0.001% is a very small number. That’s 1 in 100,000, which anyone would be hard pressed to label as significant. It’s not 0, but it’s unrealistic to expect it to be 0. That said, it’s close enough so that the vast majority of users should be relatively safe by employing good security practices and installing only applications from trusted sources and reading permissions.
It is important to keep in mind, however, that just like the security providers and proponents of other mobile operating systems that can profit from Android security FUD, Google also has a dog in the fight. No group is truly impartial here. And unfortunately, it is up to the user to decide with his or her own personal data who is to be believed. That said, I know my mobile operating system of choice, despite the FUD. But since I care about my data (and that of my friends and family), I won’t be turning off Verify Apps or installing from untrusted sources any time soon.
Have you or any of your friends ever fallen victim to malware on Android? Let us know your thoughts on the Android malware situation in the comment box below. You can learn more by viewing the full presentation.
September 24, 2013 By: Jimmy McGee
We have talked about app development, Ubuntu Touch development, NFC and Firefox OS presentations from XDA:DevCon 2013. All of these presentations are of great value for developers and enthusiasts. However, there is a dark secret in your pocket: exploits. These exploits can be used for good, gaining root or unlocking. However, they can also be used for bad, such as stealing your chickens or texting curse words to your mother, or worse.
This presentation has a simple title, but the content is not simple. “Android Security Vulnerabilities and Exploits” presented by XDA Elite Recognized Developer jcase. Jcase is a mobile security researcher and the developer of many Android exploits. There is great reason he is an XDA Elite Recognized Developer. Members of the forum sing his praises and OEMs curse his names.
In his presentation, Jcase talks about how the very exploits we often use to root our phones expose us and others to malicious software such as spyware, bots, keyloggers and other forms of malware. He shows past vulnerabilities in applications and firmware and how they are mitigated today. He shows off some of the tools and methods he uses in identifying vulnerabilities. Finally, he walks the audience through finding a security vulnerability and exploiting it.
If you want to see more or get a copy of the presentations slides, visit the XDA:DevCon Presentations page.
August 12, 2013 By: TheRomMistress
Despite previous claims by Bitcoin developers that its open-source wallet application provides “a strong level of protection against many types of fraud,” developers announced Sunday that weaknesses within the Android operating system are responsible for rendering all Android wallets generated to date vulnerable to theft.
The issue lies within the area of the OS that should be generating secure and random key codes, which is why the problem only affects wallets generated by Android applications.
Some applications affected include Bitcoin Wallet, blockchain.info wallet, BitcoinSpinner, and Mycelium Wallet. Front-end applications such as Coinbase or MtGox are not vulnerable since private keys are not generated on the Android device.
Updates are still being prepared for clockchain.info and BitcoinSpinner. The update for Bitcoin Wallet is currently under beta testing, and Mycelium Wallet has already received an update. It is strongly recommended to update as soon as a new version is available. In the meantime, key rotation is necessary, according to the Bitcoin developers in their Aug. 11 blog post. “This involves generating a new address with a repaired random number generator and then sending all the money in your wallet back to yourself…Once your wallet is rotated, you will need to contact anyone who has stored addresses generated by your phone and give them a new one.”
The discovery just so happened to coincide with a ruling made by Magistrate Judge Amos Maazant of the Eastern District of Texas federal court that the online payment form be thought of as a true currency. The ruling sets a precedence that anyone committing fraud with the “online crypto-currency” could be looking at more severe penalties. Jon Matonis, executive director of the Bitcoin Foundation, predicted that the International Standards Organization may eventually classify the currency as a “non-national” commodity, which does not need to be issued or backed by any government. Matonis said the ruling “highlights the fact that Bitcoin is becoming recognized as commodity money in the same way that gold and silver are recognized as money.”
July 25, 2013 By: Jimmy McGee
Whether you want to admit it or not, Android is not always as secure as it could be. But thankfully, good people find the security flaws and report them. Google then patches the vulnerabilities. Then, we hit a roadblock. If you are on a stock ROM, you usually have to wait for your carrier to roll out an update for your device to get the patch. Since rolling out updates doesn’t lead to new phone sales, some carriers don’t offer updates in any reasonable amount of time, or sometimes not at all.
Well don’t leave yourself vulnerable. XDA Recognized Contributor Tungstwenty has a solution, as Portal Administrator Will Verduzco reported earlier. In this video, XDA Developer TV Producer TK reviews Master Key Dual Fix patch. TK shows off how to install the patch and the required Xposed framework, so check out this video.
July 19, 2013 By: Jimmy McGee
Android 4.3 leaked for the Google Nexus 4 That and more are covered by Jordan, as he reviews all the important stories from this week. Included in this week’s news is an article using your Android device as a Virtual driving game wheel and news about an Xposed Patch for the two recent Master Key-style Android vulnerabilities
Jordan talks about the other videos released this week on XDA Developer TV. XDA Developer TV Producer Kevin released a video talking about Xprivacy to protect your privacy, Elite Recognized Developer AdamOutler should how to do an Unbrickable Mod on the Samsung Captivate, and TK showed us how to root our T-Moble variant of our Samsung Galaxy S 4. Pull up a chair and check out this video.
July 18, 2013 By: Will Verduzco
By now, you’ve undoubtedly heard of the Android Master Key vulnerability, which allows a malicious payload to be inserted in an application that is installed, due to a discrepancy between signature verification and app installation. The vulnerability has been known for some time, having been responsibly disclosed by Bluebox back in February, and patched a couple of weeks ago.
Another vulnerability, also known officially as Bug 9695860, works in a similar fashion and results in the installation of an unwanted malicious payload from a seemingly innocuous file. It, just like its predecessor, has also been patched a little over two weeks ago by Google.
Unfortunately, while these vulnerabilities have since been patched by Google and incorporated into a handful of OEM firmware updates, not every manufacturer has been so expedient. And given the usual delays ranging from laziness and lack of profitability to technical complexity, there’s really no telling as to when they will make their way into the majority of end-user devices. The aftermarket community’s quite a bit better, though. Case in point, CyanogenMod 10.1 has had the fix merged ever since July 7th.
However, while quite a good number of people run CM10.1 and derivative kanged ROMs, obviously not everyone is running CM10.1 on his or her device. After all, a good number of people enjoy running modified stock ROMs in order to preserve the original look and feel or OEM-specific features. And there are other source-built ROMs that just haven’t been updated to include the upstream fixes.
So what are stock firmware + root users to do in order to be safe? Well first off, said users should refrain from installing APKs that don’t come from trusted sources such as Google Play. However, we realize that this isn’t a true solution. To deliver that, XDA Recognized Contributor Tungstwenty came up with an Xposed module that patches both vulnerabilities in one go.
Previously, we’ve seen Recognized Developer rovo89‘s Xposed Framework used for quite a few modifications ranging from alleviating issues in recent Android revisions to managing permissions to loading the borderline malware (I kid, I kid) Facebook Home. However, we’ve not yet seen the framework used to deliver a fix for a vulnerability in such a manner. (Those wishing for a primer on the fantastic Xposed Framework should visit our write-up from a few months back.)
As expected from any Xposed-based modification, installation of Tungstwenty’s Xposed Module is incredibly simple. In his words:
1. Make sure the Xposed Framework is installed.
Follow the instructions on the thread. Root is required only during installation, it is no longer required afterwards. Only ICS or above is supported.
2. Install the Master Key dual fix module.
3. Follow the Xposed notification about a new module being available, and on the list of modules activate Master Key dual fix
4. Reboot the device (a Soft reboot is sufficient)
You should now see an image similar to the attached one. The green text shows that the module is active and the 2 vulnerabilities have been patched.
Those who would like to learn more about the vulnerability should visit this thread by Recognized Developer Adam77Root, which explains it in a little bit greater detail. It also outlines which ROMs would and would not be affected. Until you’re patched by either installing this Xposed patch or updating to the latest CM10.1 nightly, we advise that you only install APKs from trusted sources such as the Google Play store.
Head over to Tungstwenty’s modification thread to get your fix… literally.
July 13, 2013 By: Samantha
Looks like even we Australians haven’t been able to stay clear from the unprecedented, mass surveillance that Americans have been subjected to, as The Sydney Morning Herald (SMH) has revealed today. It may or may not come as a shock that Australia’s largest telecommunications company Telstra has had a secret pact with the US intelligence agencies for at least a decade, obliging Telstra to store mass volumes of communication data of Australians for potential investigations by the US in the future.
An agreement penned when 50.1 percent of Telstra was still owned by the Australian Federal Government, it obliged Telstra to meet the demands of the FBI and Justice Department to “provide technical or other assistance to facilitate…electronic surveillance,” while allowing for all communications involving a US point of contact to be stored in a secure storage facility located on US soil and managed and sifted through by Americans with top-level security clearance. This data includes phone calls, emails, and online messages.
This means if you’re an Australian who’s contacted anyone in the US in the last decade at least, those related phone calls, emails, and online messages are stored in some dark, dank dungeon of borderline criminality with big, shameful ‘Made in Australia’ and ‘Owned by the US’ stickers all over it. That’s not a very desirable place for your private information to be stored.
SMH has also confirmed that the agreement was still in operation “as recently as March 2011,” while Telstra has disappeared in their White House replica doghouse with the tail between the legs, refusing to comment or answer detailed questions about it.
This is a major concern for Aussies, as although the contract does not “authorise Telstra or law enforcement agencies to undertake surveillance” (SMH), the legality of the contract is very questionable, if not an “invasion of privacy and erosion of Australia’s sovereignty,” as spoken by the Greens on Friday. This is so, as there a a number of legislation such as the Telecommunications (Interception and Access) Act 1979 (Cth) and Telecommunications Act 1997 (Cth) that govern the ‘privacy of communications,’ with the former “[prohibiting] the interception of communications passing over a telecommunications system and prohibits access to stored communications (i.e. email, SMS and voice mail messages) except where authorised in specific circumstances” (Electronic Frontiers Australia).
And for Optus customers, don’t feel so safe, as our second largest telecommunications company has also declined to comment whether they have stored data for “potential surveillance by US, or Australian, authorities” (SMH). This also certainly doesn’t mean that all you folks with unmentioned companies such as Vodafone are exempt from such probings.
Let’s see how this unfolds, shall we?
“It’s How We [Dis]Connect” Telstra Advertisement
[Source: Sydney Morning Herald]
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.