Software Requirements Specification

for

Secure Communications
Platform
Version 0.2

Prepared by Zakaria Swapan

<organization>

18 August 2019
Table of Contents

Table of Contents.......................................................................................................................... ii
Revision History............................................................................................................................. ii
1. Introduction............................................................................................................................ 1
1.1 Purpose................................................................................................................................. 1
1.2 Document Conventions......................................................................................................... 1
1.3 Intended Audience and Reading Suggestions........................................................................ 1
1.4 Product Scope....................................................................................................................... 1
1.5 References............................................................................................................................ 1
2. Overall Description.................................................................................................................. 2
2.1 Product Perspective............................................................................................................... 2
2.2 Product Functions................................................................................................................. 2
2.3 User Classes and Characteristics............................................................................................. 2
2.4 Operating Environment........................................................................................................ 2
2.5 Design and Implementation Constraints................................................................................ 2
2.6 User Documentation............................................................................................................. 2
2.7 Assumptions and Dependencies............................................................................................ 3
3. External Interface Requirements........................................................................................... 3
3.1 User Interfaces...................................................................................................................... 3
3.2 Hardware Interfaces.............................................................................................................. 3
3.3 Software Interfaces............................................................................................................... 3
3.4 Communications Interfaces................................................................................................... 3
4. System Features....................................................................................................................... 4
4.1 System Feature 1................................................................................................................... 4
4.2 System Feature 2 (and so on)................................................................................................ 4
5. Other Nonfunctional Requirements...................................................................................... 4
5.1 Performance Requirements................................................................................................... 4
5.2 Safety Requirements............................................................................................................. 5
5.3 Security Requirements.......................................................................................................... 5
5.4 Software Quality Attributes................................................................................................... 5
5.5 Business Rules....................................................................................................................... 5
6. Other Requirements................................................................................................................ 5
Appendix A: Glossary................................................................................................................... 5
Appendix B: Analysis Models...................................................................................................... 5
Appendix C: To Be Determined List........................................................................................... 6

Revision History
Name Date Reason For Changes Version

Zakaria Swapan 18 August 2019 Started the Document 0.1

Zakaria Swapan 19 August 2019 Updated the Feature Lists 0.2

Zakaria Swapan, 20 August, 2019 Grouped the features, updated the features, 0.3
Rafsan Mazumder, updated the Section 2, 3, and 4
Istiak Ahmed

Dr. Anindya Iqbal 21 August, 2019 Updated Non-Functional Requirements 0.4

Rafsan Mazumder, 21 August, 2019 Updated External Interfaces Requirements 0.5

Istiak Ahmed

Zakaria Swapan 21 August, 2019 Overall Editing done. 0.6

1. Introduction
1.1 Purpose
The purpose of this document is to present a detailed description of our secure communications
software/platform RiverWalk, which will support mobile phones/tablets, desktops, and web browsers. The
document will explain the purpose and features of the software, its interfaces, what it will be able to do, and
the constraints under which it must operate. This document is intended for users of the software and the
developers.

Secured Communication is a key component for any enterprise. You should not depend on any third party
or publicly available apps such as whatsapp, viber, and messenger for your internal or non-disclosure
communications due to the omnipresence security and privacy threats. You must have full control over
your own communication networks and channels. To ensure the top-most security, you need a trusted
communications platform where you have full control on what data and meta-data are being stored and
where these data are reposited. You also need to ensure that the networks and data repositories are within
the jurisdiction you operate in and the system is operated by your own people.

The system will be built based on industry standard software protocols and platforms, and compiled for the
enterprise with source-code, so that you can see what you get. This will give you complete assurance that
there is no trap door or spyware component inside the system.
As the nature of the platform is very sensitive, we are considering robust end-to-end security in all areas.
All data will be end-to-end encrypted, meaning no one else can eavesdrop the conversations, not even
server admins. The platform will also provide mechanisms to enforce enterprise policies e.g., the
participants of a conversation may be restricted from performing certain operations e.g., recording the
conversation or taking snapshots.

1.2 Document Conventions

This Document is created based on the IEEE template for System Requirement Specification Documents.

1.3 Intended Audience and Reading Suggestions

<Describe the different types of reader that the document is intended for, such as developers, project
managers, marketing staff, users, testers, and documentation writers. Describe what the rest of this SRS
contains and how it is organized. Suggest a sequence for reading the document, beginning with the
overview sections and proceeding through the sections that are most pertinent to each reader type.>

1.4 Product Scope

Business communication solutions must combine the strongest security with great features and ease of
use. RiverWalk will be built ground up as a secure collaboration platform - all functionality sits on the same
role and security model - so with this platform you are always sure that your communication is secure and
your privacy is protected (Fig. 1.4.1).

On top of the Open Source code-base sits the Prometheus Encryption framework which ensures all
communication channels from voice to files and code snippets to messages are all encrypted and stay
secure mitigating any possibility of no man-in-the-middle attack or eavesdropping.
 Figure 1.4.1: Functionality scope of RiverWalk platform.

#Rafsan

Finally, the rich set of functionalities that it delivers sits on top of this unique encrypted, anywhere and
multi-account framework. The platform basically delivers all the functionality a modern enterprise needs
with a Secure Messenger, One-Click Conference Calls, HD Video Calls, File and Code Snippets
Sharing, Enterprise Directory, and Search.

All chats, calls, and files are protected with end-to-end encryption, and the system does not have the
decryption keys. These are kept temporarily only on the devices of the users.

1.5 References
From Wire Whitepaper:
[1] https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security
[2] https://firebase.google.com/docs/cloud-messaging/
[3] https://developer.apple.com/library/content/documentation/
NetworkingInternet/Conceptual/RemoteNotificationsPG/APNSOverview. html
[4] http://www.tarsnap.com/scrypt.html
[5] https://en.wikipedia.org/wiki/Self-service_password_reset
[6] https://whispersystems.org/blog/asynchronous-security/
[7] https://github.com/wireapp/proteus
[8] https://github.com/trevp/axolotl/wiki
[9] https://whispersystems.org/blog/advanced-ratcheting/
[10] https://whispersystems.org/blog/simplifying-otr-deniability/
[11] https://whispersystems.org/blog/private-groups/
[12] https://github.com/WhisperSystems/Signal-Android
[13] https://eprint.iacr.org/2014/904.pdf
[14] https://github.com/jedisct1/libsodium
[15] https://en.wikipedia.org/wiki/Salsa20#ChaCha_variant
[16] https://en.wikipedia.org/wiki/Hash-based_message_authentication_code
[17] https://en.wikipedia.org/wiki/Curve25519
[18] https://tools.ietf.org/html/rfc5869
[19] https://en.wikipedia.org/wiki/Advanced_Encryption_Standard
[20] https://medium.com/@wireapp/call-security-constant-bit-rate-
encoding-and-improving-webrtc-a85be6caa43a
[21] http://tools.ietf.org/html/rfc768
[22] http://tools.ietf.org/html/rfc3550
[23] https://tools.ietf.org/html/rfc5245
[24] https://tools.ietf.org/html/rfc5389
[25] https://tools.ietf.org/html/rfc5766
[26] https://tools.ietf.org/html/rfc4566
[27] https://tools.ietf.org/html/rfc3711
[28] https://tools.ietf.org/html/rfc4347
[29] http://tools.ietf.org/html/rfc5764
[30] https://tools.ietf.org/html/rfc6716

IEEE Template for System Requirement Specification Documents:

https://goo.gl/nsUFwy

GNU General Public License version 3:

http://www.gnu.org/licenses/gpl.html

CDDL Common Development and Distribution License:

https://opensource.org/licenses/CDDL-1.0

Wire App GITHUB:

https://github.com/wireapp/wire

Wire Security Whitepaper:

https://wire-docs.wire.com/download/Wire+Security+Whitepaper.pdf

Sample Gephi SRS:

https://gephi.org/users/gephi_srs_document.pdf

WhatsApp Demo SRS:

https://www.studocu.com/en/document/lovely-professional-university/software-engineering/other/whatsapp-
software-requirement-specification-srs/3071361/view

WhatsApp WIki:
https://en.wikipedia.org/wiki/WhatsApp

2. Overall Description
2.1 Product Perspective
Based on our current understanding of your requirements for secure multi-platform collaboration system,
we prepared the following solution proposal. The solution is primarily based on an open source and end-to-
end encrypted communications/conferencing/collaboration solution, which offers secure chats, calls, and
file sharing across all major platforms.

All chats, calls, and files are protected with the highest security norm, end-to-end encryption, because
security and client privacy are our top priority. In regular operations, system does not store the decryption
keys centrally. Decryption keys are only kept on the devices of the users. This way any sensitive
information that businesses, non-profit organizations, or academic institutions share during their day-to-day
communication stay secure.

Our solution is based on open source software which brings additional credibility and it opens new
opportunities for your employees to build additional API integrations on top of the platform.

Many members in our base software team worked at Skype in the early days, helping to change the
telecom landscape, and contributing to real-time communication technologies that later became WebRTC
— which now powers tools used daily by hundreds of millions of people.

Building on that foundation, we are ready to revolutionize the way people collaborate and communicate,
and we are looking forward to welcoming you as our valued customer.

2.2 Product Functions

We are very excited about the product we are building and we are confident that it provides market-unique
features that you will enjoy. We highlight some of the core functionalities (Fig. 2.2.1) of our platform below:

● Secure messenger
● One-click conference calls
● Crystal clear HD video calls
● Simple file sharing with Search
● Multiple platforms (mobile, web, and desktop)
● Guest Rooms - E2EE external
● Highly secured end-to-end encrypted communications.
● This application can be used for group discussion .
● It allows users to find other logged in users.
● Cross platform availability: Access messages from several devices at once, including tablets,
computers, smartphones etc.
● Team meeting for business and academic purposes.
● Options for editing, deleting and customizing communication between users.
● Instant search: Finding the message, even among millions. Filtered by sender to make searching
easier.
● Options to mute the group to get notifications only when people mention user or reply to user’s
message.
● Users can pin messages to be displayed at the top of the chat screen. All members of the group will
receive a notification.
● Send and receive file of any type upto a particular size depending on the type of users.
 Figure 2.2.1: Core functionalities and administrative controls in RiverWalk.

2.3 User Classes and Characteristics

A large organization with employees of different backgrounds, skill levels, and responsibilities needs to
differentiate its communications platform users accordingly. The major types of users we have identified
are discussed below.

- Power users: Power users have high definition desktops/mobiles, high bandwidths, great internet
coverage, and necessary software installed.

- Executives: Executives are technology-shy, have assistants who need access to all apps, their
requests need to be prioritized.

- IT Department: Need access to database and access to admin menus in order to change product
functionality.

- Exclusive class: Exclusive users get functionality according to their customized needs.

- Technologically challenged: Technologically challenged persons with little or no educational

expertise have to find the product easier to understand and use.

- Premium users: Premium users will get a broad range of functionality (e.g., video meeting with a
large group) other than regular users.

- Low network coverage area users: Product has to be specifically optimized to match the low
network coverage area users.

- Business users: Customization and relevant features may be needed for particular business users.

2.4 Operating Environment

The hardware, software, and technology used should have the following specifications:

● Ability to connect to the wifi or mobile network

● Ability to exchange data over the network
● Touch screen for convenience or Keypad (in absence of touch screen)
● Processor with minimum speed of 500 MHz
● Continuous power supply
● Ability to use camera, gallery, microphone, and other services of mobile
● Ability to take input from users
● Device must have 512 MB RAM or above

The product will support the following operating systems:

Server Side
 ● Linux

Client Side

● Android
● Web Browsers in WIndows and Linux

2.5 Design and Implementation Constraints

● Create the account by entering and verifying mobile number
● In case of network not available
● If not able to exchange data over network, prompt error message "Connection not available"
● In case of not being able to access the services of mobile hardware
● If a hardware component e.g., camera is not working, prompt error message, "Can’t access
camera"
● Lock an account
● If a user failed to follow the policies of RiverWalk and those enforced by the enterprise
● In case of spamming by 10 users
○ Maintain consecutive marked spam counter
○ Increment spam counter
○ For every consecutive spam, increment logic counter by 1
○ Deactivate the account as the spam number reaches 10

2.6 User Documentation

The following types of documentation will be provided:

● ‘Help’ option in desktop, mobile, and all other platforms that designed in an exclusive way
● User Manual available online and option to download
● Video Tutorials in Youtube or other sharing platform
● ‘Contact Us’ option for direct support

Take help from wiki -- how to write user documentation

2.7 Assumptions and Dependencies

2.7.1 Dependencies

The RiverWalk platform is dependent on some external resources:

● Licensed Software from third parties (i.e., Signal, Wire, Skype etc.)
 ● Open Source Software (Signal, Wire, FreeSwitch, Asterisk, Opus etc.)
● Network and data availability
● Power Supply
● Better connection for exchanging data over network
● Availability of mobile services

Required internal dependencies:

● cassandra (with the correct schema)
● elasticsearch (with the correct schema)
● redis

Required external dependencies are the following configured AWS services (or "fake"
replacements providing the same API):
● SES
● SQS
● SNS
● S3
● DynamoDB

Required additional software:

● netcat (in order to allow the services being tested to talk to the dependencies above)

2.7.2 Audio, Video, and Signaling (AVS)

The audio, video, and signaling (AVS) library will be developed in ANSI C/C++. The code is cross
compiled for Android and iOS. Wrappers for interaction with upstream modules are written in Java
for Android and Objective-C for iOS.

2.7.3 Proteus/Cryptobox

The Axolotl protocol implementation and other cryptographic and utility libraries are developed in
Rust, then cross-compiled for iOS and Android. The web version has its own port of these libraries
in JavaScript.

2.7.4 MinIO

MinIO is an object storage server released under Apache License v2.0. It is compatible with
Amazon S3 cloud storage service. It is best suited for storing unstructured data such as photos,
videos, log files, backups and container / VM images. Size of an object can range from a few KBs
to a maximum of 5TB.
MinIO server is light enough to be bundled with the application stack, similar to NodeJS, Redis
and MySQL.

2.7.5 Restund

Restund is a modular and flexible STUN and TURN Server, with IPv4 and IPv6 support.

Features:

● Authentication module
● Binding module
● MySQL module
● Statistics module
● Status module
● Syslog module
● TURN module

3. External Interface Requirements

3.1 User Interfaces
Once the application is installed, it goes through the user’s phone book and, upon consenting, sends a
push invitation to connect and chat on the platform. A user enters his/her phone number and can then
change the phone name.

Web access: An intuitive web portal (Fig. 3.1.1) for accessing the communications system by any user.
 Figure 3.1.1: A sample prototype of web portal.

Messages in mobile: Ability to send text and multimedia messages with or without message timer (Fig.
3.1.2). Timed messages will self-destroy as soon as the timer expires.

Figure 3.1.2: Sending/receiving messages with timer.

File sharing and search: Ability to share files and links with page reviews, and search with text and visual
cues (Fig. 3.1.3).
 Figure 3.1.3: Files and links sharing with page reviews.

Secure external collaboration: Provision Guest Room for secure communications with partners (Fig. 3.1.4).
No download or account needed, just a web browser required.

Figure 3.1.4: Guest room for secure communications with partners.

Ubiquitous framework: Seamlessly works anywhere on any device e.g., mobile, desktop, and tablets using
the same account with additional support for multiple accounts within the same app (Fig. 3.1.5).

Figure 3.1.5: Ubiquitous framework, which is available anywhere on any device.

Multimodal content delivery: Seamlessly integrate voice calls, video calls, one-clink conference calls, and
screen sharing (Fig. 3.1.5).

Figure 3.1.5: Integrate multimodal (voice, video, and text) content delivery.

Multimodal messaging/chats and notification: One-to-one as well as group messaging/chats, timed

messages, reactions, reminders, and attention messages using any modality e.g., text, voice, and video
with low bandwidth requirements (Fig. 3.1.6). The Chats button allows the user to open a new chat or join
an existing chat group. To do so the user accesses the compose feature in order to write a new note. Here
the user can see all chats that he or she has sent. Users can reconfigure display settings such as color,
font size, etc.

Figure 3.1.6: Instant messages and notifications.

 Figure 3.1.7: Multimodal one-to-one and group chats with personalized display settings.

Contacts with availability status: Ability to access contacts from an organized list of personal and enterprise
acquaintances with Availability Status monitoring (Fig. 3.1.8). Status settings enable the user to let others
know whether he/she is available, in a meeting, or busy. The user may also clear the status.
 Figure 3.1.8: Contacts feature to list acquaintances (left) and Status settings (right).

3.2 Hardware Interfaces

3.2.1 End-user requirements
The most of the end-users will be using smartphones. The hardware of the smartphones should meet the
following capability requirements:

● Ability to read gallery

● Ability to read contacts
● Ability to exchange data over network
● Touch screen for convenience or Keypad (in absence of touch screen)
● Continuous power supply
● Ability to connect to network
● Ability to take input from user
● Ability to validate user

3.2.2 Servers/Hosts
- Total users (10K)

- Kubernetes nodes (3x)

● Ubuntu 16.04 (optional but recommended)
 ● 4 core, 8 GB, RAM, ~100GB disk
● Public IP and port 443 open to the world (if all behind a firewall, further discussion needed)

- Cassandra (3x)
● Ubuntu 16.04
● 2-4 core, 8 GB, RAM, ~100GB disk
● Accessible from the kubernetes cluster

- Minio.io (4x)
● Ubuntu 16.04
● 2 core, 2-4 GB, RAM, ~500GB disk
● Accessible from the kubernetes cluster

- TURN Server
● Ubuntu 16.04
● 2 core, 4 GB, RAM, ~16GB disk
● Public IP, open UDP ports 1024-65000, TCP 3478 and TLS 5349

3.2.3 Storage
Depends on the usage, etc. but roughly this is how much data we will store:
● For user/conversation metadata (3 years worth of data): 5 TB
● For notifications (the last 28 days worth of data): 2 TB

User Data Storage:

Depends on how long assets can/should live on the server side
3 years worth of data, ~30 TB + 10TB Extra = ~40TB

Per User Data:

- 1 GB of data/user

3.3 Software Interfaces

AVS:
- The audio, video, and signaling (AVS) library of Wire is developed in ANSI C/C++. The code is
cross compiled for Android and iOS. Wrappers for interaction with upstream modules are written in
Java for Android and Objective-C for iOS.
- Audio-video library for calling (mostly C), then cross compiled for iOS and Android

Proteus / Cryptobox:
- The Axolotl protocol implementation and other cryptographic and utility libraries are developed in
Rust, then cross-compiled for iOS and Android. The web version has its own port of these libraries
in JavaScript.
 ● Proteus: Axolotl Protocol Implementation in Rust, then cross compiled for iOS and Android
● Cryptobox: High-level API with persistent storage for proteus
● Cryptobox-haskell: Haskell bindings to cryptobox
● Cryptobox-C: C-FFI to cryptobox
● Hkdf: HKDF implementation (RFC 5869) in Rust, then cross compiled to iOS and Android

Android: Audio-Video Signaling:

Different platforms implementation languages:

● Android: Scala
● Webapp: Javascript
● Desktop: Typescript
● Server: Haskell

Software requirements for different platforms:

● Android: JDK 8 and Android SDK

● Desktop: Node.js
3.3.1 Communications Protocol
XMPP:
- XMPP (eXtensible Messaging and Presence Protocol) - for one-on-one instant messages and
group chats. Need to customize data field for fewer payload.

HTTP:
- For update profile/contact

VoIP:
- Voice over IP methodology makes voice and voice and Video calls. We can use PJSIP library to
implement VoIP functionality and also Opus for voice codec.

Server Software Core:

- Nearly everything is Haskell, Nginx (for reverse proxying and authentication, written in C) with a
plugin written in Rust

JSON/protocol buffers over:

- HTTPS: for client requests
- WSS: for delivering real-time notifications

Token based authentication:

- Nginx plugin written in Rust

Stateless:
- All our stateless services are written in Haskell, except for nginz (which is vanilla nginx with an extra
module for authentication)

CDN:
- Email, notifications, CDN (better latency for assets)

Restund (TURN) Servers:

- Restund servers allow two users on different private networks (for example Alice who is in an office
connected to an office router and Bob who is at home connected to a home router) to have a Wire
audio or video call. More precisely, Restund is a modular and flexible STUN and TURN Server, with
IPv4 and IPv6 support.

UDP:

- Restund servers provide the best audio/video connections if end-user devices can connect to them
via UDP. In this case, a firewall (if any) needs to allow and/or forward the complete UDP port range
1024-65535 for incoming UDP traffic. Port 3478 is the default control port, however one UDP port
per active connection is required, so a whole port range must be available and reachable from the
outside.
 - In case e.g. office firewall rules disallow UDP traffic, there is a possibility to use TCP instead, at the
expense of call quality.

TCP:

- Two (configurable) ports are used by restund for TCP, one for plain TCP and one for TLS. By
default restund uses ports 3478 for plain TCP and port 5349 for TLS. You can instead use (if that’s
easier with firewall rules) for example ports 80 and 443 (requires to run restund as root) or do a
redirect from a load balancer (if using one) to redirect 443 -> 5349 and 80 -> 3478.

3.3.2 Notifications
User needs to be notified of a new message using push notification. User should get benefits from
notifications for following features:

● Sent
● Delivered
● Read Receipt
● Is typing
● Last seen
● Online/offline status
● Busy

3.3.3 Databases
System and server architectures: Please elaborate Figs. 3.3.3.1 and 3.3.3.2.
Figure 3.3.3.1: System architecture.
 Figure 3.3.3.2: Server architecture.

Database clusters:

● Cassandra: Main database, multiple clusters used for user profiles, conversation meta and user
notifications.

● Elasticsearch: Search by name/user.

● Redis: User presences / websockets.

● MySQL: The RiverWalk Business API client requires MySQL to store data.
Two separate databases (dbs) for messages and accounts. We can use Mnesia or Postgres for read/write
messages and Postgres for profiles/accounts. We want to archive all messages in a separate db i.e,. Riak.
For notification queue we can use Radis.

3.3.4 Operations
Following technologies will be used to run the daily operations and monitor the system 24x7.

Monitoring: Kubernetes comes with a basic dashboard (Fig. 3.3.4.1).

Figure 3.3.4.1: Kubernetes dashboard.

Metrics collection: Prometheus and grafana.

Logging: Elasticsearch, Fluentd, Kibana.

Relevant sources: https://scalablesystem.design/ds101/kubernetes-install-using-kubespray

3.4 Communications Interfaces

Fig. 3.4.1 presents a high-level outline of the (deployment) architecture of the components that
make up our Communications Servers as well as the main internal and external dependencies
among components.
 Figure 3.4.1: Dependencies among components of communications servers.

3.4.1 Services

● nginz: Public API Reverse Proxy (Nginx with custom libzauth module)
● galley: Conversations and Teams
● brig: Accounts
● gundeck: Push Notification Hub
● cannon: WebSocket Push Notifications
● cargohold: Asset (image, file, ...) Storage
● proxy: 3rd Party API Integration
● restund: STUN/TURN server for use in Audio/Video calls
● spar: Single-Sign-On (SSO)

3.4.2 Communication Channels

Users will be able to communicate via following modes:

● Internet (including 2G/3G/4G mobile network, Ethernet etc.)

● WiFi & Hotspots
● Intranet
● Bluetooth (peer-to-peer)

3.4.3 Data Transfer

Assets (images, voice/video messages stored independently so this will really vary)

● ~200 GB/day transferred (~2 MB/sec)

Calling

● 100K calls/day
● Around 20 MB/sec (5 up, 5 down)

4. Systems Features
This section demonstrates most prominent features and explains how these can be used with potential
benefits.

4.1 User Registration

4.1.1 Sign-up
User must be able to register for the application using a valid mobile phone number. This phone number
will be the unique identifier of that user (Fig. 4.1.1.1).
 Figure 4.1.1.1: User registration data flow.

On installing the application, user must be prompted to register using their phone number. This phone
number needs to be verified using OTP (One Time Password) system. System will send an SMS of this
phone number that contains 6 digits OTP along with 3 character prefix (e.g abc-123456). User put only 6
digits in application and prefix will auto populated in application. This prefix will help user to put correct
OTP when multiple OTP is received that may be introduced using the resend option. Functional sequence
of events for User Registration is sketched in Fig. 4.1.1.2.
 Figure 4.1.1.2: User registration sequence.

There must be a resend option in OTP page. This resend option button/link must be disabled for the first
minute. Functional sequence of events for Resend OTP is drawn in Fig. 4.1.1.3.

Figure 4.1.1.3: Resend OTP sequence.

After verifying the phone number, the account will be created and redirected to basic setting page where
other information will be set by the user.

Validating email address: A user may provide an email address to use as alias in web based clients. The
email address will be verified using [fill in] (Fig. 4.1.1.4).

Figure 4.1.1.4: Email address verification.

4.1.2 Account Management

Users should be able to manage his/her own profile/account from the apps (Fig. 4.1.2.1).

Figure 4.1.2.1: Managing account profile.

4.2 Client/Device Registration
Client/device registration (Fig. 4.2.1) is required in order to participate in the exchange of end-to-end
encrypted content. The concept of user accounts is less relevant, as encrypted content is exchanged
among clients.

Figure. 4.2.1: Client/device registration.

A user may register up to two (2) client applications (usually on different devices) - primary and secondary.
Attempts to register more than one primary client will result in an error and require the existing primary
client to be removed first. Registering a new secondary client will automatically replace the existing one (if
exists).

These restrictions limit the amount of computation clients need to perform when sending encrypted
messages, as messages are encrypted individually between clients.

Upon successful client registration the server returns a client ID (Cid) which is unique per user ID.

The prekeys are used by other clients to initiate cryptographic sessions with the newly registered client and
are defined in section 4.1.1 on page 8 (Ref. Wire Whitepaper).

4.2.1 User Device Data

Following data will be collected during registration:
● Mobile (MSISDN) number
● Current IP Address (If available)
● IMIE (If available)
● Mobile Country Code
● Mobile Network Code
● Home Country Code (Available on Android)
● Home Mobile Network Code (Available on Android)
● Device name
● Device OS version
Moreover, the following additional data will be stored by the servers:

● Locale: An IETF language tag representing the user’s preferred language.

● Accent Color: A numeric constant.
● Picture: Metadata about a previously uploaded public profile picture, including a unique ID,
dimensions and a tag.
● Cookie Label: A label to associate with the user token that is returned as an HTTP cookie upon
successful registration.
● Web App Settings: Preferences such as emoji setting, link preview setting, sound alert settings
are stored.
● Password: If the user has a password, client registration requires re-authentication with this
password, with the exception of the first registered client of an account. Similarly, removing a
registered client also requires the password to be entered.
● Metadata: The server collects the following metadata for every newly registered client:

○ Timestamp: The UTC timestamp when the client was registered.

○ Location: The geographic coordinates of the IP address used to register the client.

This information is only collected to make notifications about new registrations more meaningful.

4.2.2 Single Device Activation

Users should be able to use the system only from two (2) devices - the Primary Device and the Secondary
Device. To access the service from the secondary device, he/she has to use the primary device (via QR
Code Scanning - similar to WhatsApp Web Access).

In case of a mobile primary device -

- The App can only be active on one (1) mobile device. This will be his/her primary device.
- The other mobile devices will be automatically logged out and app data will be deleted.

4.2.3 Device Sync

Users will be able to sync their devices, when moving from one device to another one. Example: One user
may change the device he/she was using. And, he/she should be able to back-up all his data into the
Cloud, and synced with his new device. And, that backup data will be deleted, once sync is done.

Insert a figure with proper caption.

This feature lets you take all the conversations, sent images, videos and files with you when upgrading to a
new phone or switching computers.

The backup file contains the textual content and meta-links to assets (images, videos, any files that you’ve
sent and received) on the servers, not the files themselves. This helps to keep the backup file sizes small.
When you import history backup into a new device the meta-links mean that all your images and files will
show up in the right places in conversations.

Assets on the servers are of course end-to-end encrypted and the server will not hold the keys to decrypt
them.

4.2.4 MAC Binding

All devices will be bound to their MAC address after successful registration. This is done to protect from the
access of unauthorized users.

4.3 Authentication

4.3.1 Tokens
API authentication is based on a combination of short-lived bearer tokens, referred to as access tokens, as
well as long-lived user tokens. Access tokens are used to authenticate requests to protected API resources
and user tokens are used to continuously obtain new access tokens.

User tokens are sent as HTTP cookies. All tokens are strings signed (A cryptographic Ed25519 signature
attached to the string) by the server and include the user ID (UUID v4) and the expiration time as a Unix
timestamp. The full format of user tokens and access tokens is specified in appendix A on page 14. (Wire
Whitepaper)

(token) ::= (signature)

‘.v=’ (version)
‘.k=’ (key-index )
‘.d=’ (timestamp)
‘.t=’ (type)
‘.l=’ (tag )
‘.’ (type-specific-data)

(version) ::= (Integer )

(key-index ) ::= (Integer )
(timestamp) ::= (Integer )
(type) ::=‘ a’ | ‘u’
(tag ) ::=‘ s’ | ‘’
(type-specific-data) ::=‘ a=’ (access-data) | ‘u=’ (user-data) (access-data) ::=
(UUID ) ‘.c=’ (Word64 )
 (user-data) ::= (UUID ) ‘.r=’ (Word32 )

The scope of user tokens, and thus cookies, can be persistent or session-based, with the same semantics
as those specified by the HTTP protocol. A client chooses the scope of the cookie during login. The HTTP
cookie attributes restrict their use to the domain of the backend server, to the path of the token refresh
endpoint as well as to the HTTPS protocol. Persistent cookies are stored in permanent, secure storage on
the client, whereas session cookies are kept in ephemeral storage only (e.g. a browser session). Persistent
cookies expire after 1 year and session cookies expire after 1 week.

Access tokens are comparatively short-lived (15 minutes). To refresh an expired access token a client uses
a cookie to refresh the access token (Fig. 4.3.1.1). If the cookie is valid, a new access token is generated
and returned. When an access token is refreshed, the server may additionally issue a new cookie, thus
continuously prolonging the expiration date. Such a cookie renewal typically occurs approx. every 3
months.

Figure 4.3.1.1: Token refresh.

A user may have a maximum of 32 persistent cookies and 32 session cookies, both of which are replaced
transparently from the least recent to the most recent.

After the initial registration, only a user login can generate a new long-lived user token and an access
token.

4.3.2 Login
Login via password: A client provides a user ID, email address or phone number, and the password that
are transmitted over TLS (Fig. 4.3.2.1). The server verifies the password using scrypt and issues a new
user token as an HTTP cookie and a new access token.
 Figure 4.3.2.1: Login via password.

Login via QR code: Elaborate and cite Fig. 4.3.2.2.

Figure 4.3.2.2: Login via QR code.

4.3.3 Password Reset

The system will provide a self-service password reset for any registered user with a password and a
verified email address or phone number. The procedure for a password reset is similar to the initial
verification of email address (Fig. 4.1.1.4) with the following differences:

● There can be only one (1) pending password reset for an account at any time. A new password
reset cannot be initiated before the timeout window expires.
● The password reset codes are valid for one (1) hour only.

The procedure for a password reset via SMS is sketched in Fig. 4.3.3.1.
 Figure 4.3.3.1: Password reset via SMS.

4.3.4 User Logout

- User will be able to logout from the App
- All app's data on device will be deleted. Option will be given to the user
(a) regular logout or
(b) logout with data removal
- App will return to login/registration screen

4.3.5 Remote Force Logout

- Admin can force user to logout from all the devices
- All app's data on device will be deleted
- App will return to registration screen

4.3.6 Screen Lock PIN Code/Biometric

- Accessing app will required PIN / Biometric
- Optionally user will be able select device's own Biometric security method
- Such security will be invoked anytime App is run first time or gets focus
- After three (3) try logout from App (wipe data)
- App will have a built-in inactivity timeout option. When this option is active app will timeout and
go to PIN/Biometric screen.

4.4 User Groups

- Groups could be created and users can be assigned to groups
- Announcements can be sent to a group
 - Group can have their own Custom contact
- A phone number needs to be assigned to group to be able to register
- Any number that is not in any group will be assigned to "public" group when register
- "Public" group can be set to allow or disallow new registration

4.5 Encrypted Voice Calls

Users can call each other in one-to-one or group conversations (Fig. 4.5.1). Calls are initiated to all
participants of a conversation and users who are not a participant of that conversation do not have access
to the call. All calls are encrypted.

Figure 4.5.1: Voice call interface.

Setting up a call involves three aspects: signaling, media transport, and encryption.

4.5.1 One-to-one Voice Call

- App to App Encryption
- Mobile data and WiFi detection
- Low data usage mode
- Poor connection warning
- Auto reconnect calls after drop-outs

4.5.2 Group/Conference Call

- Conference call can be initiated from group chat
- Total 50 party conference (initiator + 49)
- SCP based fast call merging and media transfer
- Attendee can leave and join again from recent screen
 - Attendee can join from only one device

4.5.3 Voice Call Recording

- Call can be recorded by either party on the app (based on both side’s permission)
- Recorded file will be stored in phone
OR
- System Admin may record any calls. In that case, the system has to run on Client/Server mode.

4.5.4 Integration with PBX (via SIP)

Users should be able to dial-out to PBX/Telco via SIP Gateway. In that case, voice communication will
break the encryption/security system for those specific calls.

4.5.5 Call Signaling

Call signaling establishes a connection between clients and negotiates their common capabilities by
exchanging SDP messages. These messages are sent between clients as Proteus messages, using the
same encryption as text messages.

4.5.6 Media Transport

Once connected, endpoints determine a transport path for the media between them. Whenever possible
the endpoints allow direct media flow between them, however, some networks may have firewalls or NATs
preventing direct streaming and instead require the media to be relayed through a TURN server. ICE
identifies the most suitable transport path.

While TURN servers are part of the Wire infrastructure, they do not know the user ID of the users that use
them. Clients use generic credentials to authenticate against the TURN servers, so that calls are
indistinguishable for TURN servers. Therefore TURN servers cannot log identifiable call records.

4.5.7 Encryption
Call media is exchanged between endpoints in an SRTP-encrypted media session. To initiate the session
the SRTP encryption algorithm, keys, and parameters are negotiated through a DTLS handshake. The
authenticity of the clients is also verified during the handshake.

When the endpoints of a call happen to be two phones (where WebRTC compatibility is not required), Wire
uses KASE (Key Agreement Signaling Extension) instead of DTLS. The advantage is that the key
negotiation is done ahead of time during the signaling phase and calls can be connected much quicker. For
both DTLS and KASE, the key negotiation is authenticated by the Proteus messages.

In a group call, every participant connects to every other participant as if they were in a one-to-one call.
Therefore, all legs of the group call are individually encrypted and encryption keys are not shared among
participants.
4.5.8 Encoding
The codec used for streaming is Opus for audio and VP8 for video. Opus can use variable bit rate
encoding (VBR) or constant bitrate encoding (CBR). Users can choose to enable CBR in the settings. CBR
has the advantage of eliminating potentially undesired information about packet length, but might have an
impact on call quality on slow networks [20]. It is sufficient if one of the two parties of a call enables the
CBR option, CBR will then always be used for calls of that user. When CBR is used, the calling screen
will display ’CONSTANT BIT RATE’. In group calls the CBR option is only enforced on the legs connected
to the participant that enabled the CBR option. It is up to the participants to set the option to ensure that all
legs use CBR encoding. The calling screen of group calls will not display ’CONSTANT BIT RATE’, even
when the option is set. In video calls the CBR option affects the audio streams like in audio calls, but the
calling screen will not display ’CONSTANT BIT RATE’.

4.5.8 WebRTC
The system will be fully compliant with WebRTC and existing IETF standards. As a result, native endpoints
can also securely exchange media with any WebRTC compliant web-browser such as Netscape, Google
Chrome or Mozilla Firefox.

These are the main IETF standards used by the system:

● UDP (RFC 768 [21])
● RTP (RFC 3550 [22])
● ICE (RFC 5245 [23])
● STUN (RFC 7350 [24])
● TURN (RFC 5766 [25])
● SDP (RFC 4566 [26])
● SRTP (RFC 3711 [27])
● DTLS (RFC 4347 [28])
● DTLS-SRTP (RFC 5764 [29])
● Opus (RFC 6716 [30])
4.6 Encrypted Video Calls

4.6.1 One-to-one Video Call (Fig. 4.6.1.1)

Figure 4.6.1.1: One-to-one video calling

- App to App encryption

- Mobile data and WiFi detection
- Low data usage mode
- Poor connection warning
- Auto reconnect calls after drop-outs

4.6.2 Group Video Call

- Maximum 4 participants in a Single Group (Fig. 4.6.2.1)

Figure 4.6.2.1: Group video call.

4.7 Encrypted Messaging

4.7.1 Messaging/Chat
Messaging refers exchanging text messages and assets (Fig. 4.7.1.1). All messaging is subject to
encryption to provide users with a strong degree of privacy and security.

Figure 4.7.1.1: Messaging and chats.

- Text messages with App to App encryption

- with edit, reply, delete for everyone, forward, draft options
- Voice message: User will be able to record a message from the app, and send that audio
message to any recipient.
- Offline Delivery Support: Sender will send the message, and the recipient will get the message
when he/she comes online.

4.7.2 Group Messaging/Chat

- App to App/Server encryption
- Maximum 500 participants in a Single Group
- Seen status
- Delivery status
- Departure notification
- Setting Admin/Moderator Role Facility

4.7.3 Emojis
- Send and Receive built-in emojis

4.7.4 Messaging activity

- Last activity
 - Show when remote user is Typing
- Message send status will be shown
- Waiting to be sent
- Message received for delivery
- Message received by remote party

4.7.5 Messaging/Chat Privacy

- Show my Online Status
- Show when I am typing
- Show “Seen” Status
- List of Blocked contacts

4.7.6 Time delayed message

- Message will be delivered at a given time
- It should be within 24 hours
- Chat screen will mark messages that has timed message
- Chat screen will also mark draft messages

4.7.7 Self-Destruct Message

- Message will be automatically erased from receivers chat window
- Sender will set the timer while sending the message

4.7.8 Broadcast Messages

- all user one-way message broadcast
- select user one-way message broadcast

4.7.9 IM Text Context: Date

- IM window will determine following formatted texts
- “on 20th May, 11:30pm”
- “1200 hours on 20th May 2019”

4.7.10 Watermark Chat Background

- There will option to change chat background with built-in images
- Those background images will have both fragile and robust watermarking
- Fragile watermarking will assist detecting any tampering attempt
- Robust watermarking will preserve chat relevant metadata to identify the originator, participants,
geo location, time etc.

4.7.11 Calendar Events

- If there is any time related events in the chatbox, the system will assign that event into mobile’s
default calendar (Fig. 4.7.11.1).
 Figure 4.7.11.1: Calendar integration.

Calendar Integrations: Calendar overview, Calendar notifications, Calendar alerts, Click-through to

calendar events.

4.7.12 Link Previews

When users share links, the apps can generate link previews. This feature is optional and can be turned
off. Link previews are generated on the sender’s side only, by fetching open graph data (a picture and
some text) from the website behind the link. The data is sent to the recipient and displayed there, but the
recipient does not make any network requests to the website, unless the link is clicked or tapped.

4.8 Files Transfer/Attachment

4.8.1 File Transfer

- Any type of files, transfer and view
- Download, share to external systems
- Compression: Files can be Zipped while transmitting (i.e., Best Quality, High Quality, Normal
and Low Quality) based on standard compression technique/algorithm.

4.8.2 Send to Server

File can be sent to the server (instead of any user) for collaboration. There should be a separate incon to
send the files to the server. Example: Someone wants to send a file to the system admin, or anyone
responsible for the platform. Users should be able to upload that file to server. And, system Admins should
be able to see that content; can use it for their own purpose.
Other third party applications i.e., OSINT, may be able to use files from that server location.

4.8.3 Malware/Virus/Phishing Detection

- The system will be able to check any virus, malware, phishing link etc. while transmitting
through the system. (3rd. Party integration).
- System Admin should be able to on/off this feature.

4.9 Share Content

- Our App to Other App
- Other App to our App

4.10 Security Features

4.10.1 Security Channel Encryption

End-to-end encryption (E2EE) takes place between two clients (cf. 2.2). Proteus [7] is the main
cryptographic protocol. It is an independent implementation of the Axolotl/Double Ratchet [8] protocol,
which is in turn derived from the Off- the-Record protocol, using a different ratchet[9].

Furthermore Wire uses the concept of prekeys [6] to use the protocol in an asynchronous environment. It is
not necessary for two parties to be online at the same time to initiate an encrypted conversation.

Proteus uses the following cryptographic primitives (provided by libsodium [14]):

● ChaCha20 stream cipher [15]

● HMAC-SHA256 as MAC [16]
● Elliptic curve Diffie-Hellman key exchange (Curve25519 [17])

Key derivation is done using HKDF [18].

Prekeys:
Every client initially generates some key material which is stored locally:

● Identity keypair: (a, ga) ∈R Zp × Curve25519 where g ∈ Curve25519

● A set of prekeys [6]: (k(a,i), gk(a,i) ) ∈R Zp × Curve25519 where 0 ≤ i ≤ 65535.

During client registration (section 2.2) a client uploads prekeys (gk(a,0) , ..., gk(a,j) ) bundled with its public
identity key ga. These are eventually used by other clients to asynchronously initiate an end-to-end
encrypted conversation, i.e. given a recipient’s prekey gk(a,i) and identity key ga the sender can
derive n initial encryption key even if the recipient is offline.
The prekey with ID 65535 is the so-called “last resort” prekey. Every prekey is intended to be used only
once, which means that the server removes every requested prekey immediately. In order to not run out of
prekeys the last resort prekey is never removed and clients should regularly upload fresh prekeys.
For further details on the remaining protocol flow and its security properties please refer to references [8],
[9], [10] and [13].

4.10.2 Message Exchange and Client Discovery

To send an encrypted message, the sending client needs to have a cryptographic session with every client
it wants to send the message to (usually all clients of all participants of a particular conversation). It will
encrypt the plain text message for every recipient and send the batch to the server. The server checks if
every client of every user who is a participant of the conversation is part of the batch. If a client is missing,
the server will reject the request and inform the sender of missing clients. The sender can then fetch
prekeys for the missing clients and prepare the remaining messages before attempting to resend the entire
batch.

By the same mechanism clients are also informed about redundant clients, i.e. clients they have prepared
an encrypted message for, but which are no longer part of the conversation. This includes deleted clients,
i.e. clients which are redundant and known to have been deleted. The sender can use this informa- tion to
update its own list of clients participating in a conversation and the corresponding cryptographic sessions.

Client discovery for the sender of a message is depicted in Fig. 4.10.2.1. #Rafsan

Figure 4.10.2.1: Client Discovery

Conversely, when a client receives an encrypted message from another client with whom no prior
cryptographic session exists, it initializes a new cryptographic session from the encrypted message.

To rule out man-in-the-middle attacks users need to compare identity key fingerprints out-of-band.
4.10.3 Assets
Assets are large binary entities sent between users, such as pictures.

Profile pictures are uploaded as plaintext assets with technical metadata (e.g. width, height, file type) and
are shared through a user’s profile.

Any other assets shared in conversations are end-to-end encrypted. Compared to regular text messages,
the encryption of assets applies an optimization proposed in [11] to reduce the required computational
overhead and network bandwidth for the sender. On Wire, the sending client does the following:

1. It generates a random symmetric key k for use with AES-256.

2. It encrypts the asset data with k using CBC mode with PKCS#5/7 padding and computes the
SHA-256 hash of the resulting ciphertext.
3. It encrypts the key k together with the hash and other asset metadata for each recipient via the
Proteus protocol.
4. It sends the encrypted asset data as well as the encrypted metadata pay- load for each recipient to
the server.

The receiving client of an asset metadata message then does the following:

1. It decrypts the asset metadata using the Proteus protocol, thus obtaining the symmetric key k as
well as the SHA-256 hash of the asset ciphertext.
2. It downloads the asset ciphertext, computes the SHA-256 hash and com- pares it to the received
hash to verify the integrity of the asset data.
3. It decrypts the asset data using the key k.

As with regular text messages, only clients in the same conversation can receive asset metadata
messages from one another and are authorized to download the corresponding asset ciphertext.

Assets are persistently stored on the server without a predefined timeout. This means that a client can
repeatedly download and decrypt the same asset to con- serve disk space on the device, since the client
persistently stores the decrypted symmetric key k together with the SHA-256 hash. These credentials have
the same sensitivity as the plaintext asset itself. Forward secrecy is not affected since the decryption key k
is sent using the Proteus protocol.

4.10.4 Screenshot Deactivation

Screenshot and recording will be deactivated when the app is active.

4.10.5 Local Data Protection Vault/Sandbox

All data will be stored in the local device with proper encryption so that no other application can decipher
those data. (SandBox).
The apps store the content of conversations such as text messages, images and other assets locally on
the device. Depending on the platform, different protection mechanisms exist:

1. Android: Local data is stored using SQLite and in files. Conversation content, cryptographic key
material or other sensitive data is not synced with Android Backup Service. The local data can only
be accessed from the Wire app, it is inaccessible to other apps thanks to the Android per- missions.
The app sometimes keeps cached data (i.e. downloaded im- ages) on the external storage (SD
card). Those files are encrypted using AES128, each file uses a different random key which is
stored in the private database.

2. Desktop Clients: Local data is stored using IndexedDB. The data is stored in the user’s folder. It
is strongly recommended to use full disk encryption like FileVault on macOS or Bitlocker on
Windows.

4.10.6 Encryption Mode (End-to-End, and Client/Server)

There will two encryption mode for the whole system. System Admin will be able to change the mode
based on their needs.

a). End-to-End Encryption (Regular, by default)

In this mode, all communication will be encrypted end-to-end, and there will be no copy stored in
the server side. All communication will happen from the devices. SERVER will not keep any
contents, and/or media.

b). Client/Server Encryption (select by Super User)

In this mode, communication will be encrypted, but everything will go over the server; and system
admin will be able to keep a copy of the communication i.e., messages (if they want).

Super User will be able to set this mode for users/system.

4.10.7 Transport Encryption

The clients interact with backend servers over HTTPS connections supporting only TLSv1.2. Only cipher
suites that support forward secrecy (PFS) are used. The server indicates the order preference of cipher
suites and communicates HTTP Strict Transport Security [1] to all clients. To mitigate man-in-the-middle
attacks caused by rogue or compromised CAs or caused by root certificates installed on the client-side,
Wire clients pin the public key of the leaf certificates to set of hard-coded values.

In addition to requests to HTTP resources, clients can maintain a websocket connection to receive real-
time push notifications, as well as register for push notifications through external transports such as FCM
[2] and APNs [3]. See section 4.5 on page 10 for details on push notifications.

4.11 Other Features

4.11.1 Request Current Geo-Location
- a user can request another user's location
- location will be only shares when receiver accepts the request

4.11.2 User Geo-Location Tracking

- User’s goe-location will be tracked on a regular basis.
- Geo-location will be displayed in Google Map under Admin Panel/Dashboard.
- In case, the user has gone offline (out of network), the device/app should be able to keep the
geo-locations stored within devices/app, and will update the location database while the user
comes online. In this way, the system will be able to track the users, even in offline mode.

4.11.3 Custom Address Book/Enterprise Directory

- Load contacts from CSV into server
- Push contacts to phone app
- only in App
- Group Based Phonebook
- Only Admin/Super-Admin will be able to manage and push it.
- Users will be able to access those Directory/Contacts after proper log-in. The directory listing
will not be available in the local devices (hiding the contact list from public misuse).

4.11.4 Notifications
Messages are delivered by the server to recipients via notifications. Users will be able to control how the
messages will be displayed in their devices.

Notifications are delivered by the system over 3 different channels.

Websocket connections: Every authenticated client can establish a websocket connection over HTTPS.
A client with an established websocket connection is considered online.

External push providers: The system will support FCM and APNs as external push providers. This
channel is used if a client is offline but has registered a valid FCM or APNs push token with the server. The
content is encrypted and not visible to the external push providers.

Notification queues: Every message sent by a user, as well as most metadata messages are enqueued
in a per-client notification queue that can be queried (and filtered) by every registered, authenticated client
of a user. The notification queue allows clients to retrieve messages they may have missed. The retention
period of notifications is 4 weeks.

4.12 Management Features

4.12.1 Enterprise User Management
There will be roles to operate the system on a daily basis. Following roles will be given --

Super Admin: Will be able to do everything in the platform. All access will be controlled by the Super
Admin.

Admin: Regular Admin will be able to run the basic services including some management roles.

Operator: Who will be able to monitor and run the system with limited access.

● Provision users
● Set roles for users
● Deprovision users
● User overview
● Contract overview

4.12.2 Configuration and Publishing

- Apps (Android) will be hosted in Local SERVER, and updated version can be PUSHED over Air.

4.12.3 Help
User will be able to find the help and support center from the app. Support can be given via email
or phone, which will be managed by separate system (mostly CRM).

4.12.4 Feedback to Admin

There should be an option for users to send any feedback to the admin. This can be built under
HELP/Support menu.

4.13 Microphone and Screen captured by other Apps (Research)

In many cases, it is a security concern that some other applications (or malware) may maliciously try to
access/capture the microphone and/or the screen while RiverWalk App is being used. Those apps can
then capture the audio and the contents from the screen.

We will research on whether this can be detected and find a probable solution to thwart such malicious
attempts by adversaries.

4.14 Common Features of WhatsApp, Viber, Emo etc.

Apart from above mentioned features, we will be building common features available in regular apps like
whatsApp, Viber, Emo etc. Some of the features are --
● Language Support for Bangla
● Auto Error correction while typing
 ● Privacy Settings
● Account Management
● Profile picture
● Data separation
● Contact separation
● Fingerprinting
● Contact verification
● Device access management
● Integrate calendar

5. Other Nonfunctional Requirements

5.1 Performance Requirements
The major performance criterion for a messenger app is response time. The following major factors affect
response time:
● Limited bandwidth
● Server or network capacity
● Server traffic
● Application processing constraints

Many of these factors are outside of the scope of the application and will always be an issue. The following
requirements will be met to prepare a high performance software:

● The system should operate without failure for a specified number of uses (transactions) or for a
specified period of time.
● The system shall be recovered within 10 minutes if it is down.
● The system shall be recovered without intervention at user terminal if it is down.
● The system shall show appropriate messages at terminal when system is down.
● The system shall have 99% reliability during operating hours.

To achieve this, the measures to be taken at development include the following:

● Logical memory management and efficient use of addressable memory space.

● Multithreaded operation when and where required.
● Measuring component interaction latency and interface latency.
● Load balancing at server end using efficient state-of-the-art techniques such as Docker.
● Optimal configurations of the relevant parameters from total memory for the database, total
allowable locks, network packet size, number of I/O demons, buffered I/O size, customized cache
configurations, etc.
5.2 Safety Requirements
The RiverWalk framework does not have any safety requirements other than authentication and
authorization issue. Theses issues will be addressed with secure design and development practice as
discussed in the next section. All the APIs used will be safe API, i.e., free from known vulnerability threats.
Safety issues and safety attributes will be addressed as part of the software testing effort at all levels.

5.3 Security Requirements

To ensure comprehensive security, security measures will be taken at server side as well as at the
messenger application (client).

Appropriate development strategies will be adopted to mitigate known attacks such as code injection, SQL
injection, buffer overflow, race condition, privilege escalation, cross-site scripting. All inputs will be validated
and sanitized to prevent entry of suspicious materials into the server. The issues to be addressed are
discussed below.
● Input validation: Improper input validation leads security issues like embedding malicious strings in
query strings, form fields, cookies, and HTTP headers. These include command execution, cross-
site scripting (XSS), SQL injection etc.
● Authentication: Improper authentication leads security issues like Identity spoofing. Password
cracking, privilege escalation and unauthorized access.
● Authorization: An improper authorization leads vulnerabilities like access to confidential or restricted
data, tampering, and execution of unauthorized operations.
● Session management: Improper session management leads vulnerabilities like session hijacking
and data tempering.
● Parameter Manipulation: parameter manipulations lead vulnerabilities like path traversal attacks,
command execution, and bypass of access control mechanisms among others, leading to
information disclosure, elevation of privileges, and denial of service.

The messenger application will maintain the following security standards:

● It will not execute as a privileged operating system process unless necessary to perform any app
functions.
● It must not enable other applications or non-privileged processes to modify software libraries.
● It will prevent from executing at higher privilege levels than users executing the software.
● It will clear or overwrite memory blocks used to process potentially sensitive data. Sensitive data
may include a user's location or authentication credentials.
● The app must remove cookies or information used to track a users identity when it terminates.
● The mobile app version of messenger must not call APIs or otherwise invoke resources external to
the mobile app unless such activity serves the documented purposes of the mobile app.
● It must not transmit error messages to any entity other than authorized audit logs or the device
display.
● The app must not write data to persistent memory accessible to other applications.

Finally, Vulnerability Assessment and Penetration Testing (VAPT) will be carried out to ensure the security
of the software.
5.4 Software Quality Attributes
The following Software Quality attributes will be maintained throughout the design and development phase.

5.4.1 Availability
Availability is the amount of time a system or component is online, ready to perform its specified function.
The major areas impacting on availability are:

● Inadequate testing/ weak program code

● Change management problems
● Lack of monitoring and analysis
● Operational errors
● Interactions with external services or applications
● Different operating conditions (usage level changes, peak overloads)
● Hardware faults

The messenger application will be designed keeping the major areas of impacts.

5.4.2 Load balancing and high-availability

Load balancing is not possible for audio/video, since STUN/TURN is a stateful protocol, so UDP packets
addressed to restund server 1, if by means of a load balancer were to end up at restund server 2, would
get dropped, as the second server doesn’t know the source address.

High-availability is nevertheless ensured by having and advertising more than one restund server.

5.4.3 Scalability
Scalability is the ability to increase system capacity by upgrading hardware and software without extensive
modifications to the application software. With the help of efficient deployment architecture using Docker
containers, scalability will be ensured. Docker’s container-based platform allows for highly portable
workloads and allows to dynamically manage workloads, scaling up or tearing down applications and
services as business needs dictate, in near real time. Using this technology a cost effective and scalable
deployment environment will be created. Load and stress testing will confirm that required number of users
will be able to have smooth use of the application.

5.4.4 Maintainability:
Software maintainability requires more developer effort than any other phase of the development life cycle.
The application would be designed in such a way that it can be maintained and repaired easily.

Maintainability is defined as the ease with which a software system or component can be modified to
correct faults or errors, improve performance or be adaptable to accept new functionality. Maintainability is
a measure of how easy it is to keep the system functioning. Maintainability requirements define how the
system is to be maintained at an operational level after it has been put into production.

Objectives of maintainability requirements are:

● Ensure that minor defects in an application or a component are easy to correct.

 ● Ensure that minor enhancements to an application or component are relatively easy to implement.
● Minimize maintenance costs and free up programmers for development rather than maintenance
work.

Maintainability requirements should be concerned only with modifications made between major releases of
an application and should be specified quantitatively.

5.4.5 Portability
The application is HTML & scripting language (java script) based so the end-user part is fully portable and
any system using any web browser should be able to use the features of the system including any
hardware platform that is available or will be available in the future. An end-user is used the system or any
OS; either it is windows/Linux. The system shall run on Pc, laptop, notebook, PDA, mobile etc.

5.5 Business Rules

The application will be accessed only by authenticated users having official phone numbers. The users will
be created by a system administrator with credentials. There will be administrative user roles for accessing
recorded message based on proper authority approved by the system owner.

6. Other Requirements
<Define any other requirements not covered elsewhere in the SRS. This might include database
requirements, internationalization requirements, legal requirements, reuse objectives for the project, and so
on. Add any new sections that are pertinent to the project.>
Appendix A: Glossary

<Define all the terms necessary to properly interpret the SRS, including acronyms and abbreviations. You
may wish to build a separate glossary that spans multiple projects or the entire organization, and just
include terms specific to a single project in each SRS.>

User Tokens:

(token) ::= (signature)

‘.v=’ (version)
‘.k=’ (key-index )
‘.d=’ (timestamp)
‘.t=’ (type)
‘.l=’ (tag )
‘.’ (type-specific-data)

(version) ::= (Integer )

(key-index ) ::= (Integer )
 (timestamp) ::= (Integer )
(type) ::=‘ a’ | ‘u’
(tag ) ::=‘ s’ | ‘’
(type-specific-data) ::=‘ a=’ (access-data) | ‘u=’ (user-data) (access-data) ::=
(UUID ) ‘.c=’ (Word64 )

(user-data) ::= (UUID ) ‘.r=’ (Word32 )

Appendix B: Analysis Models

<Optionally, include any pertinent analysis models, such as data flow diagrams, class diagrams, state-
transition diagrams, or entity-relationship diagrams.>

Appendix C: To Be Determined List

<Collect a numbered list of the TBD (to be determined) references that remain in the SRS so they can be
tracked to closure.>
Q&A for Authors:
I am just formatting the document, and putting the feature lists. Please feel free to
ask anything under this section as question. -- ZS

Authors:
1. Zakaria Swapan, Product Manager
2. Prof. Manzur Murshed, Federation University Australia
3. Mohsin Khan, iP
4. Dr. Anindya Iqbal, CSE, BUET
5. Istiak Ahmed, CSE/BUET/13-batch
6. Rafsan Mazumder, CSE/BUET/13-batch
7. Nasir Khan, Android

Probable Resources:
1. Raju Ahmed, 09 Batch, CSE, BUET -- Team Lead
2. Nasir, CSE. BUET, 14 Batch
3. Noor, Chem. BUET - 14 Batch
4. Anik - 14-Batch
5. Dhrubo - 14-Batch
6. Saad, 14-Batch
7. Nirjhar -- 13th. Batch (Google @ Jan, 2020)
8. Dr. Saifur Rahman, Teacher, CSE, BUET (Consultant)
9. A.H.M Kamal, Ex-PhD Student of Mahfuzul Islam
10.