1. CONNECTION ENCRYPTION
2. VIDEO, VOICE AND TEXT EXCHANGE ENCRYPTION
3. TWO-FACTOR AUTHENTICATION AND ROBUST PASSWORD
4. DATA AT REST SECURITY
5. LOCAL STORAGE ENCRYPTION
7. DATA BACKUPS
8. AUDIT LOGS
9. INDEPENDENT AUDITS
10. DATA FLOW MAP
11. SINGLE SIGN-ON (SSO)
1. Connection Encryption
All external access points to the Reacts APIs and services require secure connections using Transport Layer Security (TLS). All internal access points between Reacts services require secure connections using industry standards encryption methods.
Ports and Protocols
|Website / Service||Port||Protocol|
Denied Ciphers and Protocols
Explicitly blocked protocols: SSL 2, SSL 3, TLS 1.0, TLS 1.1
Explicitly blocked ciphers: 3DES, RC2, RC4 and DES56
2. Video, voice and text exchange encryption
Audio/video communications are established via WebRTC and utilize the DTLS-SRTP security context to encrypt and decrypt streams from end to end.
The signaling channels are completely separated from the media transport and are TLS secured. The certificate fingerprints are sent through this secure connection, reducing the possibility of MITM attacks. Every connection and session use unique keys.
For environments where Peer to Peer ("P2P") connections are not possible due to infrastructure and firewall restrictions, IIT provides access to its hosted TURN services. TURN acts as a relay service to connect parties together in places where only outbound connections are allowed. The DTLS-SRTP allows secure end to end protected sessions over either UDP or TCP. Given that UDP provides higher performance and lower bandwidth requirements, it is the preferred alternative.
Text messaging is always transmitted via the signaling service and is thus secured with TLS.
IIT's implementation of WebRTC prioritizes audio/video stream connections as follows:
1. P2P UDP;
2. P2P TCP;
3. TURN UDP;
4. TURN TCP.
Therefore, if an institution’s firewall allows P2P via UPD and/or P2P via TCP, the stream connection will be established in P2P. If an institution’s firewall blocks P2P connections, the stream will be established via URN UDP or TCP with TLS encryption.
3. Two-factor authentication and robust password
Reacts allows the use of two-factor authentication. The current implementation uses the principles of "Something you know" and "Something you have".
- Something you know: Username and password. The password is expected to remain confidential
and hard to guess.
- Something you have: IIT uses a TOTP standard algorithm implementation of "Something you
There are many free applications that can be used to calculate a token based on a secret the user stores in his/her device. The token is required if the user configures his/her Reacts account for two-factor authentication.
The two-factor authentication reduces enormously the chances of success of many types of exploits. Just to mention the most common ones, social engineering, brute force and dictionary attacks become extremely hard to succeed when a two-factor authentication is enabled. In the case a malicious individual gets access to a password, the "thing you know", it will be very difficult for such person to produce the right token, "something you have". In the contrary case, if the malicious user gets access to the device using "something you have", it will still be needed to figure out the "something you know" factor.
Upon registration, the user must provide the following security information:
- An email address;
- A robust password (8 characters minimum, including one upper-case, one lower-case and one
- When a user will have chosen the two-factor authentication, it will also be needed to register
Reacts in an application that can generate the TOTP tokens his/her device.
In order to access Reacts for the first time, the user will receive an activation key via email or
text message, allowing him/her to validate the ownership of the e-mail account.
4. Data at rest security
- The database and database backups are encrypted at rest using "Transparent Data
Encryption" (TDE) with AES 256 block mode encryption.
- The servers used for storage are located in a sub-network that is not exposed to the internet. Only
the computers and the Reacts services that require it as well as a restricted group of users have
access to this network.
- The stored user files are encrypted using AES 256 block mode encryption. The symmetrical keys
used to decrypt the data are stored separately in the database server. These keys are never
exposed to human users and are only made available to the services that provide access to these
files as per the authorized owner requests.
- Each file is encrypted using its own key and different Initialization Vectors (IV) (e.g. two files
belonging to the same user are encrypted using two different keys).
- Access to encrypted information by IIT or IIT suppliers is strictly prohibited by security and
access policies as well as by implemented security mechanisms.
- Access to the storage servers is strictly regulated by IIT’s internal policies and service
5. Local storage encryption
Client device security is mostly the responsibility of the owner of the device. However, Reacts implements a few measures to reduce the risk even on the client-owned devices.
On Windows-Based Devices
- Reacts creates a folder that will host a virtual drive where the user's Reacts data is stored with encryption.
- The local user data is encrypted with the Salsa20 encryption algorithm using symmetric keys.
- The keys are stored in the user's Windows vault.
- The data is encrypted at rest. Once the user is connected to Reacts, the data is accessible upon request.
- When Reacts is not running, the virtual drive's data is only accessible in encrypted form and therefore illegible.
On iOS (Apple) Devices
Reacts counts on the encrypted iOS sandbox to protect Reacts data at rest and from other
On Android Devices
Reacts ensures that the device encryption is enabled before allowing to store data in the device.
On Web Browsers
Reacts does not allow caching of files in the browser, preventing them to stay at rest. Session and
authentication cookies are stored with encryption.
6. High availability (HA) and disaster recovery
The Reacts platform infrastructure is designed with high availability (HA) and disaster recovery
(DR) in mind.
High Availability Measures
All virtual machines are deployed within Azure Availability Sets with two instances or more. Isolated fault domains of Availability Sets provide high availability and resiliency against local failures, such as connectivity and power outages.
Disaster Recovery Measures
Virtual machines and other cloud resources are hosted in two different Microsoft Azure regions:
1. Canada East – Primary region;
2. Canada Central – Secondary region.
Both the primary and secondary Azure regions contain a fully functional copy of the Reacts
Replication between regions is done automatically without any required human intervention.
In case of regional failure, disaster recovery mechanisms are handled by Azure Site Recovery, which is configured for automatic failover to the Canada Central region.
Azure Storage Accounts are configured with geo-redundant storage across the Canada East and Canada Central regions.
Disaster Recovery Objectives
Recovery point objective (RPO) is targeted at 60 seconds or less.
Recovery time objective (RTO) is targeted at 2 hours or less.
The primary and secondary Azure regions are currently physically separated by over 700 kilometers.
7. Data backups
3-Level Data Backup System
1. Active online backup: 0 data loss - IIT's primary database is actively replicated to a secondary server via a high-availability database cluster.
2. Passive online backup: +/- 1 hour of potential data loss - IIT performs passive backups on the primary database server. These backups don't automatically overwrite, allowing IIT to minimize data loss in case of corruption. The database backup files are stored on a secure and georedundant Azure storage account.
3. Persistent daily backups are performed on all virtual machine disks, and provide an extra layer of protection. They are stored to an Azure Recovery Services Vault following IIT's retention policies.
Encrypted data remains encrypted when backed up and is subject to IIT's security and remote
8. Audit logs
Reacts logs operations performed by users. These logs contain the following information:
• Date and time for each type of operation;
• Type of operation;
• Connection success;
• Connection failure;
• Session request;
• Session accepted;
• Session aborted;
• Document shared;
• Password reset;
• Password changed;
• Requester (user identifier);
• Message (description of operation type);
• Room ID (identifier of a session between users);
• Additional fields (other fields helping to read the log entry).
Log data is available upon request of the owner of the account.
9. Independent audits
Innovative Imaging Technologies (IIT) is dedicated to upholding its security and confidentiality
policies as well as the higher standards of quality for its solution.
In addition, IIT is committed to undergoing an annual IT pentesting of its Reacts solution by a
specialized external firm (“Hitachi Systems Security”), in order to ensure that the quality and
security of the Reacts platform as well as the IT network are maintained.
10. Data flow map
11. Single sing-on (SSO)
IIT uses the OAuth2 standard and the OpenId Connect protocol to establish a trust relationship between the partner system and Reacts platform. This trust allows the user to transition from the partner system to Reacts platform without having to re-authenticate (single sign-on).
IIT's servers are hosted in a localized instance of Microsoft Azure Cloud Services.
- Primary instance resides in Azure's Canada East Region.
- Secondary instance resides in Azure's Canada Central Region.