eZing - Secure messaging on your own infrastracture
eZing - Secure messaging on your own infrastracture
Send messages end-to-end encrypted with a well known technology to everyone using your own infrastructure. No need to trust others.
Send messages end-to-end encrypted with a well known technology to everyone using your own infrastructure. No need to trust others. Read more
eZing is a messaging app that closes follows concepts of well-known messengers to achieve the same comfortable reading and writing of messages. The transport to be used is E-Mails, using standard IMAP-servers. Messages are locally encrypted and forwarded. Decryption takes place at the recipients device. Necessary keys are generated within the app so the private key never leaves the device while the public key is transmitted to the chat partners.
eZing - secure messaging based on well known technology
There are obviously a lot of messengers around. But each and every messenger has the same weak spot. Data are held and forwarded on central servers on premises of the providers. Over time, encryption slowly made its way into the apps. But what kind of encryption is used? Is it safe? Proven to work?
Another problem are proprietary protocols. Usually there's an API for third party developers, but every messenger introduces its own, new API that evolves with the enhancements of the primary app.
What happens if my partner doesn't have the necessary app? Maybe he doesn't want it or, as it happened to me recently, his phone fell into a river. Not only all stored messages are lost, at least temporarily, I am disconnected from that way of communication.
Is there a thing everyone has, that is available everywhere?
Sure, E-Mail is an aged protocol and writing emails is formalized enough to be tedious with salutation and complimentary close, especiall if you only want to send a quick "I'm here". But E-Mail simply works. Everywhere. Cross platform and fast.
Even if the mailserver is down, you receive your mail as soon as the server is available again. Mails will not be lost. Most importantly: Mails are decentral. Everyone can use their own mailserver. If necessary, I can set up a mail server on my notebook and communicate globally. I can run a mailserver in the company and all internal mails stay internal. Still I can communicate with external recipients. No extension necessary, because well, that's the heart of E-Mail.
Security? E-Mail has an answer, de facto standard PGP. With the public-key process, safe E-Mail are no problem these days. Sure, it is difficult to set this up and it requires a few additional steps when sending a mail. eZing takes care of this, it addresses all the keys and encryption/decryption, so you can concentrate on your conversation and the app sees to your privacy.
Advantages of eZing
- Proven transport mechanism E-Mail
- Safe communication using PGP
- Decentral message storage on arbitrary mail servers
- Encryption using PGP
- Transmition using SMTP
- Message storage using IMAP-Servers
- Notification via Push-Services
To demonstrate the technical feasibility and identify eventual problems, we have developed a prototype for android. With succeeding Kickstarter-financing, we will develop the app for all major phone operating systems, Android, iOS and WindowsPhone. The concept requires the app communicating with a server-component. This transmits new messages to the app. If a message is sent from the app, it is encrypted on the device. The message is then transmitted to the server component and will be stored in the outbox of an IMAP-Server. It is then forwarded by SMTP to the recipients account. There, the server component monitoring the inbox, notifies the recipient about the message, only naming the sender, since the content of the message is encrypted. Once the user launches the app, the message is downloaded from the server and decrypted. Your private key does not need to ever leave your device. The public keys are sent during the communication. This way, the partner always has they key to encrypt departing messages.
There are two components required to be completed. One is the app itself that provides the user interface. The other one is the server component that talks to the IMAP/SMTP-servers. This has to be run on a server that has network connectivity and is available to the app. This can be anything from a company machine to a NAS with a mailserver at home. Or a friends server. Since the communication is encrypted end to end, this is no problem: Your messages are safe. Still it may be important to keep e.g. company communications on own premises, even if the messages are encrypted.
Criteria for secure communication
The following seven criteria are evaluated to determine the the security of a messaging app:
1. Encrypted in transit?
We achieve this by encrypting the message before it is sent. Still, the communication between app and server component should be using transport layer security like https.
2. Encrypted so the provider can’t read it?
This is achieved through PGP-encryption
3. Can you verify contacts’ identities?
Initially, contacts are marked as "not trusted". They can be set to "trustworthy" once you are sure about who you communicate with. The verification can take place by scanning a QR-code from the partners phone during a face-to-face meeting.
4. Are past comms secure if your keys are stolen?
This is called "perfect forward secrecy". This cannot be done with PGP. We are looking for a solution, but will probably not be able to offer a solution in the frist increment.
5. Is the code open to independent review?
Real trust is built such means. We will disclose the code at the end of the beta phase. It will not be open-source but available in full for a review.
6. Is security design properly documented?
This is part of the implementation and will be evaluated during the review at the end of the beta phase.
7. Has there been any recent code audit?
The audit is supposed to be repeated every 12 months. In this campaign, we want to push the system to the market, properly reviewed. If there is ongoing support, we will continue to keep the highest level of integrity and security in the code, which also means, but is not limited to, code audits.
We already started creating a prototype to test nearly all aspects of the app we want to build. See what's already realized:
After you installed the app you have to configure your account. If you just want to test the app or do not have an own server, but like the idea of sending encrypted messages, choose "easy". If you already know how this works and want to use your own servers, choose "advanced"
If you choose "easy" we create an emailaddress for you, but we need a nickname you like. Your nickname will be part of your mailaddress, e.g. firstname.lastname@example.org
If your nickname is free and registered, your public and private-keys will be created. This might take some time. From seconds to minutes - depends on how fast your phone can crunch numbers.
At next your contacts-list will appear. After your initial start you have no contacts in your list. Start adding some.
Enter an email-address you know or choose a contact from your local addressbook. Your contacts will not be transfered to any server. You just choose a contacts email-address from your addressbook.
That's it. You switch to your chatlist and start a conversation. As soon as you receive the public key from your chat-partner, your chat will be encrypted.
Risks and challenges
Most pitfalls are already solved, because we have a running prototype.
Worst case might happen if app will be rejected from app-store.
- (30 days)