1. Description
I Am Safe is a communication system that facilitates the exchange of tiny, standardized messages (Micromessages) between two participants about the safety and livelihood of the sender. Micromessages can be relayed between devices even where no Internet is available.
The objective of the system is to create a communication channel that allows people in areas without Internet connection to inform friends and families about their well-being.
2. Need
Many crises, such as wars, natural disasters or state oppression, lead to portions of the population being disconnected from the Internet. As a result, people inside and outside the affected region don't have any information about the situation of their relatives and friends, which leads to a permanent stress that can seriously impact their lives.
It is not unusual that some individuals manage to leave these disconnected areas or that some have satellite connections. That creates the opportunity that these individuals convey messages to and from disconnected people.
3. Technical Implementation
The proposed system allows to send a basic status message that can travel between devices until it finds the recipient or an Internet connection. Each device does not only work as a sender and recipient, but also as a relay and a filter that enforces common pruning rules. These rules are essential to keep the message pool in a manageable size.
These rules are:
1.
Later messages are prioritized over older messages for transfer and storage.
2.
Messages that belong to one of the synchronizing devices are prioritized over other messages.
3.
Messages with invalid cryptographic signatures are discarded.
4.
If multiple messages have the same sender and the same recipient, only the latest message is kept.
5.
A message is discarded if another message is a reply to it.
6.
Each user can only have a limited number of contacts.
7.
The storage space that is available for the message pool is limited on each device.
Each message is cryptographically signed by its sender. The public key of the sender has been signed by a server (Hub). Each relay can therefore use the Hub's public key to validate the sender's public key and it can then use the sender's public key to validate the integrity of the message.
Each conversation uses symmetric encryption to protect the message content.
4. Limitations
Users have to sign up while they still have Internet. Allowing offline signups would make it impossible to verify the public keys of users.
Users cannot send messages on behalf of others and only in a very limited form about others.
A message that is stuck for a long time might be discarded even if it's important for someone.
The meaning of the standardized information is open to interpretation and a message cannot answer all questions.
Even if a user in a crisis situation has access to Internet, the connection might be slow and expensive.
5. Guiding principles

Solidarity

Users help each other by relaying messages as much as they benefit.

Safety

Users are anonymous and message content is encrypted.
Micromessages don't pose any threat to authoritarian rulers.

Security

Sabotage and cybersecurity threats are mitigated.
The authenticity of messages can be verified.

Availability

The app is distributed for free and runs on standard Android devices.
Translations to other languages are possible, in the limits of Android's locale options.
The app has a simple and intuitive user interface.

Sustainability

Robustness is prioritised over feature-richness.
Since receiving news about relatives and friends during life-threatening crises is an emotional topic, it is expected that donations can create some income from users and their families who are living in wealthier parts of the world.

No Messaging App

The app does not try to replace messaging apps or systems for fast response.
6. Elements

Conversation

Each conversation has two members. Conversations are in pending state until both participants provided their public keys.
A conversation highlights the respective latest message from the sender and the recipient and also show previous messages that were invalidated by later ones.
A conversation shows the read status of each message, if an own message was sent and if an own message is known to have been received.

Message

Each message contains the following public information:
The public key of the sender
The public key of the recipient
The region
The creation date
The creation date of the last message from the recipient that the sender had knowledge of when sending the message
The signature of the encrypted content, the public keys, the region, the creation date and the creation date of the last received message
The public key of the sender
The date when the Hub signed the public key of the sender
The Hub's signature of the public key of the sender and of the date when it signed it
The following information is encrypted with a symmetric key that is known to the participants of a conversation:
The sender's situation. The following points can be answered or left open:
health
safety at home
safety on the street
food and water
income
Partner is living at the usual place
Partner's health
Children are living at their usual places
Children's health
Optional location information (latitude and longitude)
7. Typical User Flow

Installation

The application contains the hard-coded public key of the Hub, including previous keys.

Registration

Each user must register at the Hub. For this step an Internet connection is unavoidable.
The user must have an email address where they receive an OTP to confirm the address.
During registration an asymmetric key pair is generated. The Hub signs the user's public key with its own secret key. The signature confirms also the creation date so that it will be possible to enforce expiry.
Users choose a limited number of geographical regions. The selection can later be changed, but regions that are in use by conversations cannot be deselected.
The maximal used disk space and the maximal age of messages in the pool can be customized in the settings.

Pairing

Two users who want to exchange messages have to pair their devices. This can happen via the Hub, in physical proximity or by transmitting information over another secure channel.
Pairing does the following:
a conversation is created on both devices, containing
the public keys of both participants
a unique symmetric encryption key
the region
The Hub does not need to know the encryption key, but it may store it for pairing.

Message Exchange

When a user adds a message to a conversation, all earlier messages with the same sender and the same recipient are invalidated.
A message contains the content about the situation of people and meta data. The meta data makes it possible by any device to
let the recipient identify own messages
verify the authenticity of a message
decide the priority of a message for relaying
decide if this message should be discarded
see which was the last message that the sender has received from the recipient.

Synchronisation with the Hub

If a device has Internet connection, the message pool can be synchronised with the Hub in the following order:
1.
The device receives all messages that belong to one of its conversations.
2.
The device sends messages of its conversations, if they are unknown to the Hub.
3.
The device receives messages of other people and sends their messages, if they are unknown to the Hub.

Peer-to-Peer Synchronisation

Users can decide to exchange messages directly from device to device to increase the chance of delivery.
Messages are transferred via a local Wi-Fi network in three batches:
1.
Messages that belong to either of the two users who pair their devices, regardless of their age.
2.
Updates to the messages that were sent in the first step, if the recipient has a newer version.
3.
The rest of the messages, sorted by age (newest first), as many as the the other side is able to accept.
All messages must be in the group of accepted regions.
The connection is facilitated by a QR code that is scanned by the other side.

Pruning

The local database of messages is pruned regularly and after each transfer, removing
messages with invalid signatures
messages that were superseded by updates
messages that have received a reply
messages that belong to an irrelevant geographical region, as defined in the settings
The message pool can be reduced if
a chosen threshold of total messages or storage is exceeded or
a chosen maximum age of messages is exceeded.

Message Delivery

Incoming messages are identified at the destination by their own and the sender's public keys.
8. Challenges

Slow Propagation of Messages

The propagation of messages will depend largely on the density of a network of applications, on the frequency of data exchange and on the mobility of at least some users between disconnected and connected areas.
It can be assumed that disconnected users are very motivated to find ways how to contact their relatives and friends. This could help spread the application and arrange P2P syncing.
It is evident that messages will be much slower than those of traditional messaging apps. But even if a message arrives with a delay of several weeks and if the conveyed information is outdated, receiving a sign of life with a specified date and place may be of high value for the recipient.

Propagation of Obsolete Messages

Due to the decentralised nature of the network, applications cannot synchronise with an authoritative server. Therefore, many obsolete messages will still propagate through the network and consume resources.
Each application must contribute to the pruning of messages so that the amount of obsolete messages gradually decays by replacing them with updates or removing those who reached their end of life.
It will be important to strike a good balance between keeping the message pool slim and promoting old messages that still might have a value.

Propagation of Irrelevant Messages

In order to increase efficiency, users in disconnected areas should mostly store and convey messages whose participants live in the same affected area.
Each application therefore restricts the storage and relaying of messages to selected regions. Regions can be countries or other entities, but they should be unambiguous and shouldn't consistent.
Theoretically users could also create custom or virtual regions.

Hub Key Rotation

Because of the unavailability of network connections, it is not possible to assume that each device knows about new or revoked keys. If we deploy new keys with new application versions, messages that use the latest key will be discarded on older applications.
As a mitigation, new hub keys will be released with a future validity date. Therefore, the key will have a head start to propagate before the messages that rely on it.

Asymmetric Key Rotation

Public Keys that are used in conversations can be updated and signed by the Hub.
Each device can have multiple key pairs, using only the latest for new messages. An older key can be discarded from a conversation as soon as the conversation partner starts using the new key.

Symmetric Key Rotation

Symmetric Keys that are used in conversations can be updated in a similar procedure like pairing.

Devices Cannot Handle Quantity

The quantity of messages is limited by the following rules:
Only messages of selected regions are accepted.
Older messages are discarded. The lifetime can be chosen according to the available system resources.
Each relay contributes to filtering, letting only the latest message for each direction in a conversation survive.
Message bodies are standardised and the replies about the status are packed into bit patterns. Therefore they are very small, even compared to textual chat messages.
The message transfer can take some time, but we can assume that users are motivated to help each other and don't mind waiting.
9. Cybersecurity Threat Analysis

Assets

Where stored
Why needed
How to reduce attack surface
email addresses
devices, database of the Hub
Required to mitigate the risk of mass signups. Required to identify users for pairing requests. Useful to send notifications.
It is possible to save them on the server in encrypted form.
symmetric encryption keys of conversations
participating devices, temporarily on the Hub if pairing is sent via the Hub
Required during ongoing pairing requests.
Encryption keys should be deleted on the server some time after a request was delivered to the invited users.
IP addresses
database of the Hub
Required for rate limiting.
Required for logging (monitoring, debugging and intrusion detection).
Rate limiters automatically discard old data.
Logs could be anonymized after some time.
private keys
devices
Required for signing messages (content and meta information)
Private keys never leave their devices.
locations (GPS)
devices
Users need to see the locations.
Adding locations to messages is opt-in.
Users can choose the coarse location of Android.
Users can change the location before sending the message.

Threats and Mitigations

The following analysis is based on STRIDE threat modeling.

Spoofing

Attack
Mitigation
An attacker signs up, pretending to be another user.
At signup, users are identified by their email addresses. Email addresses are verified by a confirmation link. Only after confirmation, the account can be used.
An attacker communicates with the Hub, pretending to be another user.
All communication after the signup is authenticated by a secret token.
An attacker injects a fake message, pretending to be an existing sender.
The message fails verification of the signature with the included public key and stops propagating.
An attacker signs a false or altered message with a key that doesn't belong to the recipient.
The sender ID is the public key of the sender. If the attacker uses his own key, it will become a different conversation and the recipient will not accept it.
An attacker alters the message content or meta data (creation data, region, delivery information).
The message fails verification of the signature with the included public key and stops propagating.
An attacker alters the Hub's signature or the verification procedure on the device.
Messages that pass now verification cannot continue propagating.
An unauthorized user has access to the admin interface.
The interface is protected by login with a password policy and multii factor authentication.

Tampering

Attack
Mitigation
An attacker changes the content or meta data of another user's message.
The signature fails and the message is discarded at the next device or the Hub.
An attacker changes the confirmed email address to an invalid address.
Every new address needs to be confirmed.

Repudiation

Attack
Mitigation
An attacker deletes a message.
The decentralized nature of the network makes it difficult to trace back this form of attack. This even more, because each device has the right to discard messages in order to reduce the storage.
The same decentralized nature, however, increases the chance that the message will find another route, which renders this attack less effective.
An attack on the Hub does not leave any trace that would allow analysis or automatic responses.
The server creates logs that can be consumed by IDS and IPS and used for post mortem analyses
An attacker anonymously disturbs the network or other users through the Hub.
All activity that involves sending or retrieval of messages or contacting another user requires a confirmed and active account.

Information Disclosure

Attack
Mitigation
An attacker views encryption keys in transit.
Encryption keys are only sent during pairing. Pairing happens either through TLS-encrypted connections (HTTPS) or in physical proximity by scanning a QR code.
An attacker views encryption keys at rest.
Databases are protected in their environment (server, Android).
An attacker views messages in transit.
Message content is protected by symmetric encryption.
An attacker views unencrypted messages at rest.
Databases are protected in their environment (server, Android).
An attacker links a public key to a device.
Keys that are used for the identity are randomly generated.
An attacker analyses traffic and tries to link public keys to devices.
An attacker who monitors the network might see a higher frequency of certain keys at certain places, but does not know, which device sends or picks up which message, unless he is doing a P2P synchronization with a device.
It is also possible to generate new key pairs and keep deprecated keys only for late incoming messages.
An attacker links message content to a real person.
Message content that might give away information, such as the location, is encrypted.
An attacker links a public key to an email address.
Only the Hub has knowledge about the link between public keys to email addresses and allowed conclusions about any information only to authenticated users who have this information anyway.
An attacker collects registered email addresses.
The response does not allow conclusions about the existence of an address if it is not the own address of an authenticated user.

DoS

Attack
Mitigation
An attacker floods the network with correctly signed messages by his own key to existing or fake recipients.
A maximum number of conversations per sender reduces the number of messages that a sender can have at a relay. Excess messages stop propagating at the next device or the Hub.
An attacker floods the network with correctly signed messages from fake senders to existing or fake recipients.
Each signature is only valid if the sender's public key was signed by the Hub. It is therefore possible to limit the number of valid public keys. Unsigned messages stop propagating at the next device or the Hub.
An attacker overwhelms the Hub with a high number of requests.
The Hub is protected by a rate limiter that has different limits depending on the type of request.
Synchronization is split into batches of manageable sizes. Each batch counts towards the rate quota.

Elevation of Privileges

Attack
Mitigation
An attacker gains admin rights on the Hub.
Users have only access via the web API and administrators only via a web interface. Both are separated and need only shared access to the same database.
10. Links and Resources