Ecosyste.ms: Awesome

An open API service indexing awesome lists of open source software.

Awesome Lists | Featured Topics | Projects

https://github.com/deku-messaging/DekuSMS-Android

Android SMS app ~ Featuring E2EE, Cloud Forwarding, RMQ integrations
https://github.com/deku-messaging/DekuSMS-Android

android-sms double-ratchet e2ee encrypted-messages encrypted-sms-messages rabbit-mq sms sms-forwarding

Last synced: 26 days ago
JSON representation

Android SMS app ~ Featuring E2EE, Cloud Forwarding, RMQ integrations

Awesome Lists containing this project

README 

        
# Deku SMS

--------

[Get it on F-Droid](https://f-droid.org/packages/com.afkanerd.deku/)

[Get it on Google Play](https://play.google.com/store/apps/details?id=com.afkanerd.deku)



     

Contents



[About](#about)



[Build](#build)



[Reproducible builds](#reproducible_builds)



#  About

Deku SMS is an Android SMS app. 



Deku SMS is being developed as a proof-of-concept for secure SMS messaging, SMS image transmission and SMS-Cloud communications. 



The technical functionalities of the app are currently not user friendly, which would be updated with the help of PRs and issues. The reason for the lack of user friendliness is solely based on the app aiming to be as customizable as possible. Users should be able to configure the app to their custom cloud servers without being tied into using specific providers.



Join us on [Telegram](https://t.me/deku_sms) for feature release announcements or general SMS and security discussions.



Credits to the new logo goes to: [Erenye4g3r](https://github.com/Erenye4g3r)



Features



[End-to-End encryption](#e2e_encryption)



[Ability to forward incoming messages to cloud server](#cloud_forward)



[Ability to use mobile phone as an SMS Gateway to send messages from the cloud](#sms_gateway)



##  End to End Encryption

Deku SMS supports end to end encryption (with Perfect Forward Secrecry - PFS) for users. For the feature to work, both users need to be using Deku SMS as their default SMS app. This is because there are protocols in Deku SMS that won't be available in other SMS apps; custom message headers and channels for sending messages. 



Don't worry if you send an request to someone who does not use the App, there's a great chance they won't see it; Deku SMS uses data channels (does not require an internet connection) for sending secure requests and most SMS apps would dump messages coming in from that channel (especially on iPhones). If the user does not have Deku SMS and an SMS app made by someone weird enough to encode byte data from data channels they won't see the request.



The users are guided through a [ECDH](https://cryptobook.nakov.com/asymmetric-key-ciphers/ecdh-key-exchange) handshake, after which a secure key is generated and associated with the peers phone number; 256 bits agreement keys are generated for this - ~91 Bytes to be transmitted by SMS and let's call this the SK. The SK becomes the RK for the first messages being sent - and thus begins the era of the KeyChains. You have got to read this, to see what we are working with here [https://signal.org/docs/specifications/doubleratchet/](https://signal.org/docs/specifications/doubleratchet/).



Every message being sent has a Public Key attached to it and some other details (call this the Headers). This means the size of each message is atleast 100 Bytes for the Header followed by the contents. The headers are not encrypted (yet). 



To count in SMS, for every SMS being sent you have 1 additional SMS added as the header; if you compose an SMS of body size 1 (140 bytes) you send 1 + 1(header) = 2 messages. If you compose an SMS of body size 2 (140 * 2 bytes) you get 3 messages being sent (2 + 1(header)). SMS text (UTF-7/8) encoded messages can segment themselves, which means multiple messages can be sent and then joint on the receiving end to make one message; that's why extremely long SMS messages can be received - infact you can encode an entire image to Base64 and transmit via SMS thanks to this (has some issues though so be careful with sending that large a message).



Also good to remember, the size of your composed messages is not the same size as the encrypted message (but with better UI/UX persons helping on this project one should be able to know how large a message they might be sending already). 



The users cannot know when their peer has deleted their secured keys; This means messages will still be received by peer in encrypted form. Good to know however, because if you and I are chatting in encrypted messages and I tell you stuff, you better have encryption turned on because no way I will tell more stuff in plain text. The eventual goal (eventual because have not programmed that yet) is, when you reply back to me or send me any message that is in plain text, I then know you have lost your encryption keys and continue communicating that way.



However not yet sure what happens when you continue communicating encrypted without starting a new session - because encryption are device based to store the keys; perhaps we continue communicating encrypted from where we left off because otherwise it won't work if new keys have not initiated... sounds like the actions taken here depends on how paranoid one is about their comms (I like this :D ).



All messages are currently being stored in the default SMS inbox (including encrypted messages). Users switching between SMS apps would still maintain their inbox as it is. Upcoming features would remove encrypted messages to custom database if users intends.



Note to developers: There is a race condition right after the first keys have been exchanged. Anyone can be Alice, but they'd be an issue of both are Alice because Service providers decide to not deliver the message from the true Alice on time; because SMS :(



##  Forward incoming messages to cloud

Forward incoming SMS messages to custom url. The messages remain in queue till the device has an active connection. The messages remain queue if server status codes is in range `5xx`. The device also provides visibility into the messages being forwarded into the cloud.



The content being forwarded to your cloud look like:



```json

 {

"id": "long()",

"message_id":"str",

"thread_id":"str",

"date":"str",

"date_sent":"str",

"type":"int()",

"num_segments":"int()",

"subscription_id":"int()",

"status":"int()",

"error_code":"int()",

"read":"int()",

"is_encrypted":"int()",

"formatted_date":"str",

"address":"str",

"text":"str",

"data":"str"

}

```



Supported Protocols

- HTTP(s)

- (S)FTP

- SMTP



##  Android phone as SMS Gateway

You can transmit data from your to your cloud to Android devices, using your Android phones as your SMS Gateway.



The app has direct built configurations for [RabbitMQ](#https://www.rabbitmq.com/) allowing technical users

to configure their own messaging queue directly from their own server.



The structure of the incoming RabbitMQ messages is a json like:

```json

{"sid":"", "id":"", "to":"", "text":""}

```

> sid: special id you can include in the message going to your messaging queue server

> 

> id: uniquely generated by messaging queue server - should not be used in determining the status of messages. Primarily used to inform messaging queue server to `ack` the message.

> 

> to: phone number of the receipient. Should be in [E.164 Format](https://support.twilio.com/hc/en-us/articles/223183008-Formatting-International-Phone-Numbers).

> 

> text: the message to be sent to the receipient.



The app sends a callback to your SMS Gateways once the requested message [status changes]()*.

```json

{"type":"SMS_TYPE_STATUS", "status":"[status_changes]()", "sid":""}

```



* Status changes - `sent`, `delivered`, `failed`



#  Build

```bash

git clone https://github.com/deku-messaging/Deku-SMS-Android.git

git submodule update --init --recursive

```

Getting the project into Android-studio would allow for an easy build.



##  Reproducible builds notes

Check a build against any previous commits. Requires docker

- `commit` = hash of commit being compared

- `commit_url` = url of the repo from git (should have been called repo_url)

- `release_url` = url of the github release to build against (or any place where the apk can be downloaded)

- `jks` = path to signing key file

- `jks_pass` = password for jks



```bash

make check-commits \

commit= \

commit_url= \

release_url= \

jks= \

jks_pass=

```



- https://f-droid.org/docs/Reproducible_Builds/