How do we take care about your data and security

Definitions

Assistant - an application launched on end devices along with the required server back-end.

End device - a mobile phone or a personal computer on which the assistant's software is running, with which the end user is working.

Back-end - back-up in the form of server infrastructure required for the correct work of the assistant.

Application server - a server or a set of servers responsible for data processing and implementation of the assistant's business logic. Index server - a server or set of servers responsible for indexing data and ensuring fast search and fast aggregation of indexed data.

TLS (Transport Layer Security) - a cryptographic protocol ensuring confidentiality of transmission in public networks. Android KeyStore - a mechanism for secure storage of cryptographic keys. In the case of phones with hardware support for Android KeyStore (most new phones), the cryptographic key is generated in the hardware layer and is not available to the operating system. The system can then perform cryptographic operations using this key, but can not learn it or copy it. The mechanism is equivalent to the Secure Enclave mechanism from Apple iOS.

Temporary Client Certificate - a certificate designed to temporarily authenticate the device and provide temporary use of a digital signature - issued for a short period of time to lead the user to process the Production Certificate of the Client.

Manufacturing Client Certificate - a certificate aimed at the production authentication of the device and ensuring the possibility of using a digital signature - issued for a long period of time, used in the normal operation of the Assistant. General introduction to security issues The assistant uses a number of protections to protect the data being processed due to its specificity. The document describes only selected security measures used by the Assistant. If the document does not contain a description of the security that is required by the user, please ask if the security is applied. Data encryption The Assistant uses strong encryption for data transmitted and stored. A detailed description of the encryption security used can be found in the following sections. In transit All data transferred between the Back-end and end devices is encrypted using strong encryption. TLS The Assistant uses TLS to encrypt connections, which is a secure successor to SSL encryption. Communication characteristics: The Android application uses secure TLS v1.2 and TLSv1.1 encryption (used in the given order), the Android application rejects older ones,

General introduction to security issues

The assistant uses a number of protections to protect the data being processed due to its specificity. The document describes only selected security measures used by the Assistant. If the document does not contain a description of the security that is required by the user, please ask if the security is applied.

Data encryption

The Assistant uses strong encryption for data transmitted and stored. A detailed description of the encryption security used can be found in the following sections.

In transit

All data transferred between the Back-end and end devices is encrypted using strong encryption.

TLS

The Assistant uses TLS to encrypt connections, which is a secure successor to SSL encryption.

Communication characteristics:

The Android application uses secure TLS v1.2 and TLSv1.1 encryption (used in the given order), the Android application rejects older, dangerous versions of encryption protocols (eg SSLv3).

Certificate Pinning

In order to additionally secure communication with the Back-end, the Certificate Pinning technique is used to verify the public issuer's certificate checksum for the HTTPS server. This protection is used in the Android application, which has built-in checksums from trusted exhibitors (main and / or intermediate offices). All connections to the API server are verified based on these checksums.

The objectives of the use of security:

Difficulty of attacks "Man in the Middle" - analysis of communication between the terminal device and the server requires additional work, which in practice extends the time needed to understand data structures and communication protocol, Protecting the user from unconscious use of the phone on which the attacker added to the certificate store own certification authorities, which in practice can significantly facilitate the capture of encrypted transmission.

Client certificates

Additional security for Back-end communication is the use of client certificates. The Android application when establishing a connection is presented with a certificate, which is verified on the side of the HTTPS server. The server will reject the connection if the certificate is not correct or has expired, in addition the API server will not communicate with the Android application if the certificate is not recognized as correctly issued and authenticated.

Objectives of security use:

Rare security is additionally hindered by the "Man in The Middle" attack - to be able to analyze communication, you should not only successfully override the Certificate Pinning security, but also have access to the private key store in Android KeyStore.

Automatic update of encryption libraries

Due to the complexity of encryption protocols and encryption algorithms, it is necessary to update libraries used for encryption on a current basis. The phone manufacturer may no longer provide support for a given phone model, however the Assistant uses the "Google Play Services Security Provider" service, which ensures the updating of encryption libraries without the need to update the phone system software. Purposes of using the protection: Providing secure data transmission also on older devices that are no longer supported by the manufacturer.

Resting

Data stored on the terminal devices (Android) and on the server are protected thanks to the encryption techniques described in the following sections.

Android

Due to the high risk of losing the mobile phone and / or incorrect configuration of the phone (no phone encryption enabled), the Android application uses its own data protection - ie encrypts data stored on the device.

Data areas to be encrypted:

1. SQLite and Realm - local databases on the phone

Data stored in local databases on the phone are encrypted using symmetric encryption, encryption key is stored in Android KeyStore (encryption key symmetric through asymmetric encryption),

2. Files on the phone

Encrypted notes - audio files are stored on the phone and are subject to symmetric encryption, the encryption key is stored in Android KeyStore (symmetric key encryption through asymmetric encryption).

Objectives of security use:

Protection against unauthorized access to data in the event of loss of a mobile device. The encryption applied additionally ensures verification of data integrity.

Back-end

Data stored in the Back-end infrastructure of the Assistant is stored on encrypted disks (operating system and data). Backups are encrypted via PGP / GnuPG. Passwords are stored using symmetric encryption and / or the HashiCorp Vault solution.

Purposes of using the security:

1. Securing access to data in the event of unauthorized access to the infrastructure,

2. Securing backups in case of unauthorized access.

Authentication and authorization

The Android application

The application uses authentication methods when communicating with the Back-end described below.

Client certificates

An application for user device authentication uses client certificates (X.509 standard). The process of issuing a client certificate consists of two stages - issuing a temporary certificate, which is used for basic communication with the server and is intended to enable the onboarding process to pass and user authentication. After user authentication, a production certificate is issued allowing access to other API methods.

The process of issuing a client certificate:

1. The Android application generates a private key, which is stored in the Android KeyStore and is not directly available to the application.

2. The application generates a request for signing a Certificate Certificate Request (CSR) which is sent to the server for signing by the Certification Authority competent for Edward.ai installation,

3. The server signs the Certificate Authority (CA) for Back-end request for signing a temporary certificate (CSR) with a short certificate validity period (1 hour),

4. The Android application receives the signed certificate and all requests for the API authenticates with using the issued Temporary Client Certificate, then the user undergoes the onboarding process by authenticating the user account (authentication method depends on the version of the Assistant - by default, the SMS code).

5. After successful user account authentication, the server asks the Android Application preparation of a production certificate signing request (CSR) and such a request is allowed by the server, the server signs the Certification Authority (CA) with a back-end production certificate with a long validity period (1 year),

6. The Android application receives a signed production certificate and all API requests authenticates using the issued production client certificate.

Renewing the Production Client Certificate:

1. 2 months before the expiration of the validity of the client's production certificate, the server sends a request to the Android Application to generate a new production certificate (CSR) request,

2. the Android application generates a new request to sign the production certificate (CSR) and the server receives the request,

3. the server signs Certification Authority (CA) competent for Back-end to sign a production certificate (CSR) with a long validity period (1 year),

4. The Android application receives a signed new production certificate and all requests to the API are authenticated using the issued Client Certificate.

Digital signature

The application for user device authentication also uses a digital signature with the use of a client certificate. This process is aimed at introducing an additional layer of security.

For each API call, the Android Application includes an HTTP header containing a signed message and an HTTP header with the digital signature of the message authenticating the user's device using the client certificate.

Signed message contains in itself The TOTP token, which is only valid for a short period of time, this token is additionally verified by the server.

In the case of a dedicated version of the Assistant, it is possible to use:

1. Inspection and control of network traffic using Web Application Firewall solutions (eg F5 Networks),

2. Delegation of traffic encryption to end devices with the use of SSL Offloading solutions.

If the above techniques are used and there is no Back-end control over the verification of the client's certificate, the digital signature passed in the HTTP header authenticates the device transparently for the TLS transmission layer itself.

TOTP Tokens (Time-based One-Time Password algorithm)

The Android application additionally uses TOTP tokens (RFC 6238) to protect communication against potential attacks related to the request time. The key used to generate tokens is generated on the server side and is passed to the Android Application in the onboarding process. After a one-time exchange of a key, it is no longer mentioned any more, only one-time codes of a valid, short-term are generated. The default window for verification of the TOTP token is 30 seconds.

Back-end

Authentication with a one-time password (with a QR code)

Access to the Assistant user panels and the Assistant user team manager is possible using a given login and password or a one-time password generated by the Android application.

The user enters the panel login page, enables the Assistant and scans the QR code, which in effect leads to user login.

The user thus confirms that he is in possession of the device with an active Assistant, ie he already has access to the data processed by the Assistant.

The server verifies a one-time TOTP code generated by the Android Application valid for 30 seconds. The key to the TOTP token is exchanged in the process of onboarding and user account authentication after installing the Android Application.

In special cases, it is possible to disable this authentication method.

Authentication with login and password

It is possible to give user login and password. This is a classic authentication method. Applied mainly to the manager accounts of the Assistant user team.

The user can reset the password by sending a reset link to the e-mail address assigned to the account.

Authentication via Active Directory / LDAP credentials

Access to the Administration panels of the Assistant is limited to selected, trusted IP addresses and additionally secured by logging using Active Directory / LDAP credentials. In the dedicated version of the Assistant, it is possible to connect Active Directory / LDAP authentication as the main method of authentication for users of the Assistant.

Additional security
Android application

The Android application uses a number of additional security features that are turned on or off depending on the version of the Assistant.

Blocking the possibility of backup of the application and data

The assistant by default has enabled blocking the backup of the application and data stored by the Android application.

Purposes of using security:

1. Avoid data loss by backing up the Android Application and its data by an uninformed user. Due to the data encryption used and the storage of encryption keys in Android KeyStore, it is not possible to restore data from a backup copy on a new device - no encryption key will be available.

2. Difficulty of copying encrypted user data in case of unauthorized access to the user's phone.

In the dedicated version of the Assistant, it is possible to enable or disable this security.

Blocking the ability to take a screen shot (screenshot)

By default, the assistant allows you to take a screenshot of each view of the Android application. This is dictated by usability considerations and the ability to diagnose service requests. In the dedicated version of the Assistant, it is possible to enable or disable this security.

Locking the application screen preview from the application switching view

The Assistant allows you to preview the application screen in the switching view between Android applications. This is dictated by usability considerations.

In the dedicated version of the Assistant, it is possible to enable or disable this security.

No storage of data outside the Application Storage (External Storage)

The Assistant defaults to the storage of encrypted audio files with voice notes outside the application container in the so-called an external container (External Storage). This is dictated by the limitations of available disk space on older phones. Data stored in an external container is encrypted.

In the dedicated version of the Assistant, it is possible to enable or disable this security (ie, store data only in the application container).

Disabled logging into the system log

By default, the Assistant does not log into the system log. The Android application has no control over the system log and is not able to provide secure log storage. Therefore, by default, logs are not transferred to the system log. The application saves the log in its container and at the first connection with the Back-end after creating the logs it is sent to the server and safely deleted from the device. Logs do not contain personal data. In the dedicated version of the Assistant, it is possible to enable or disable this security.

Safe erasing of files by multiple overwrites

The assistant by default deletes files created by them in a safe way - ie by repeated overwriting the file and then deleting.

Limited use of third party services

The Assistant limits the use of third party services to a minimum due to secure data processing practices. By default, the Assistant uses Google services:

1. Speech recognition - the voice is streamed to the Back-end then to the Google speech recognition service (in dedicated versions of the Assistant there is the option of replacing the server with another engine),

2. Firebase Cloud Messaging (former Google Cloud Messaging) - to immediately trigger the scenario or synchronization from the level the server uses the "push" push mechanism that arouses the Android Application. As part of this communication channel, no personal data is sent - only requests for synchronization with the server.

3. Analyst and error reporting - these services are helpful when solving service requests and statistics on the use of the Assistant.

In the dedicated version of the Assistant, it is possible to enable or disable the use of third party services (they are not critical to the work of the Assistant or have their replacements).

Obscuring the application code

The Android application has a default obfuscated code. This technique is designed to make it difficult for the attacker to analyze the application, which in turn may increase the time needed to carry out a potential attack.

In the dedicated version of the Assistant, it is possible to enable or disable this security.

Back-end

Assistant uses a number of security measures on the Back-end side. The following section describes selected issues from the point of view of the end user.

Forcing the use of encrypted HTTPS transmission

Back-end sends, by default, HSTS headers (HTTP Strict Transport Security), which are designed to protect the user from an attack involving the interception of a user session by entering through the HTTP protocol without encryption. The browser stores information that the Back-end expects an encrypted transmission and prevents entry to the server without encryption. Protection against XSS attacks (Cross-Site Scripting)

By default, Back-end uses a number of protections against XSS (Cross-Site Scripting) attacks. The following section describes the security used. Back-end simultaneously applies security for newer and older browsers:

New type protection - for newer Content Security Policy (CSP) browsers - comprehensive protection against XSS attacks defining the security policy for the entire website and selected subpages. Back-end minimizes the use of external scripts and has a restrictive default "none" policy that blocks all browser elements from processing the page. Processing for selected page elements is explicitly turned on, which avoids potential security errors, Protection for older browsers Protection against Clickjacking attacks by prohibiting embedding frames (iframe) - server sends the header "X-Frame-Options deny" Protection against changing the MIME type of the advertised through the server - the server sends the header "X-Content-Type-Options nosniff" Protection against various XSS attacks (Cross-Site Scripting) - the server sends the header "X-XSS-Protection" 1; mode = block ";"

Schedule a Demo Today and Witness the Power of Edward in Action!
SCHEDULE A DEMO SESSION WITH OUR TEAM
EDWARD is an AI powered enterprise assistant used by sales, HR and marketing teams in companies of all sizes.

We are waiting for you! Become one of our customers!
Any questions? meet@edward.ai‍
2040 Sp. z o.o. | All rights reserved.