Introduction
Alcosystems has an infrastructure design in order to achieve the following goals:
-
Scalable solution
-
Best practiced and best recommendation adherence based solution
-
Fit for purpose and secure
Each component of the solution implemented to make the system working in a way that every result gathering on a secure mobile phones and user devices transmitting data to a secure location over a secure end to end encrypted network, The architecture design fulfill the government agencies requirements.
Overview
The system is composed of the following main elements:
-
iBac breathe analyzer
-
Mobile phone (provided by Tutus) for running iBac application
-
iBac backend cluster (located on premise within RIK data center) with:
-
API server
-
storage
-
database
-
image processing (FRS)
-
-
Monitoring and Statistics services
Each component interaction occurs over a secure channel (using for example TLS 1.2 and AES 256 cipher).
Traffic is regulated by border firewall in each Rik location: firewall will manage connection from Mobiles to VPN concentrator and tunnel to the monitoring and statistics.
In a typical scenario the final user take 3 photos (front, right side and left side) of their face with the device in their mouth using thhe Mobile device.
The reference photos and the colour colour photos are transferred to the iBac backend for processing by FRS and long term storage
iBac device
Mobile Devices (Färist Mobile)
Secure mobile equipment and end to end VPN connection from user data gathering to the transition of the data from Estonia to IBAC pro platform as shown in the overall design figure below:
Tutus secure smartphone
|
|
VPN-tunnel
The VPN-tunnel secures all IP-communications with encryption using IPSEC in tunnel mode. The VPN-tunnel is mandatory and always-on. It is transparent for the apps and protects all traffic regardless of type of payload data (voice, e-mail, calendar, file share etc).
The encryption technology in the VPN-tunnel supports perfect forward secrecy, which means that encrypted traffic will remain secure even if the long term private key is compromised.
The VPN-tunnel will protect all IP-communication from being eavesdropped when transmitted over the network.
The VPN-tunnel guarantees that encrypted IP-packets are unmodified during transmission.
The VPN-tunnel prevents local network attacks targeting the smartphone since al lpackets not encrypted with the correct key will be dropped
Network IPS/IDS (Firewall)
Färist Mobile supports a central intrusion prevention and detection systems. The IPS can be of any brand and protect the smartphone the same way as any desktop pc or server.
The IPS can provide anonymity, by avoiding the smartphone IP-address to be exposed to Internet.
The IPS is able to block network attacks targeting the the smartphone, blocking malicious sites, scan for malicious content and centrally ”shutdown” Internet connection
Disk Encryption
Färist Mobile enforces disk encryption of all user data, making use of a strong external key stored on NFC-tag or QR-code in combination with a pin-code.
This will make sure that the user data will be safe from an attacker, even if the attacker has access to the device.
On Android, the local user database file is encrypted by 256-bit AES encryption.
On iOS is used Data Protection feature. It uses the built-in encryption hardware present on devices.
Application and Permission Whitelist
In Färist Mobile, only applications which are declared on a signed whitelist can be installed on the device.
This will prevent the end user from installing applications that is not approved by the deploying organisation.
This will also prevent other apps (even with extended privileges) to install apps or shared frameworks.
Further, the application whitelist can be used to immediately remove previously installed apps centrally if they should be considered untrusted in the future.
On each app it’s possibile to set a fine granular set of permissions in a centralized, enforcing the policy of least privilege for all installed apps in the device.
The Permission policy is set by the deploying organisation.
For example, an app can be prevented from
-
accessing the microphone
-
reading and writing the shared storage on the device
-
using the camera
-
communicate on the network
-
reading the users address book
-
read sms
Security Policy
Färist Mobile support security policies that can be enforced at global, organisation and user level.
The security policy will prevent the Färist Mobile to leak sensitive information, minimise attack vectors and comply with customer policies.
Global policy will supersede organisation policy, which in turn will supersede user policy.
Obligatory global policies in Färist Mobile policy will prevent
-
user access to developer settings
-
user access to debug access
-
Internet share using Wi-Fi or Bluetooth
-
low-level (L2) Wi-Fi communication
-
device access without screen password or pin
-
screen cast
-
etc
Customer (organisational) policy includes enforcement of
-
the use of Bluetooth BT 4.2 BLE
-
the use of camera
-
minimum screen lock requirements
-
emergency erase policies
-
Internet share (using USB-cable)
-
file share (using USB-cable)
-
application whitelisting (as described earlier)
-
permission whitelisting (as described earlier)
-
screen lock policy
The end-user can further restrict the organisational policy (but not bypass it), preventing apps from accessing resources in conflict with the end-user policy
The user can control individual apps access to
-
shared storage
-
GPS
-
address book
-
contacts
-
microphone
-
SMS / MMS
-
phone
-
calendar
Secure OTA updates
Färist Mobile is updated securely over-the-air; this will make sure that all devices have the latest security patches to protect themselves against known vulnerabilities.
The manufacturer of Färist Mobile, Tutus Data, will ensure that the system is security patched during the entire product life span.
Tutus Data is a certified Google Partner and will therefore receive patches and release updates before the vulnerabilities are publicly announced.
An update is provided minimum every month
Emergency erase
Färist Mobile implements a secure erase function using overwriting.
The function can be invoked centrally or by the end user, ensuring that attackers cannot recover any user data from the device after the emergency erase in invoked.
This function will ensure the protection of user data even if the attacker has access to
-
the device
-
the user pin
-
the external key to the disk encryption.
IBAC backend
The cluster is composed by at least 2 nodes with the following hardware
-
Rackmountable 2U form factor
-
128 GB 2933MHz ECC Registered DDR4 DIMMs
-
2x Intel Xeon Gold 16 core
-
6x 4.0TB SAS RI SFF SC DS Reman SSD
-
Redundant power supply
-
Redundant Gigabit network card
It’s used to store and process all user related data, assuring a physical location compliant with government requirements
Cluster serve as virtualization platform for the following services
-
Database
-
Face Recognition System (FRS)
-
Photo and Logging Storage
-
API Backend
The cluster will be managed using Proxmox VE 6.2 to serve as a virtualization platform to provide some Debian 10 (Buster) VM which in turn will provide the services
Each service will be provided by at least 2 VM (running at the different node) and in case of hardware failure the VM will be migrated to another node using the capabilities of the hypervisor
Database
We will use a MariaDB master/slave setup with the master read/write and the slave read-only.
Slave node will be used to
-
perform backup;
-
load balance read queries;
-
assure High Availability in case of master node go down due to hardware failure.
Application Logs
These Logs capture the following data:
-
Battery level info and alarms (or other specific info about the iBac device)
-
Tamper events / violations
-
Likely faults within test conditions like "blowing too hard", "alcohol detected" etc.
-
Any change and deletion of data in the database made by operator/user (including changes made when the offender is assigned to a different agency and/or another officer)
-
Unsuccessful attempts to access resources
-
System start-up and shut down;
-
Security profile changes;
All data could be replicated in a third location provided by the customer
Photo and Logging Storage
Photo storage will be handled by the S3-compatible local storage MinIO to a local volume backed by DRBD. All data could be replicated in a third location provided by the customer
FRS
FRS is composed by 2 or more instances in high availability
Data processed by FRS stays on the local hard drive for 2 weeks, then is archived back in the cluster storage
The face recognition system uses algorithms to detect the authenticity of the photos against the profile photos in the RIK DB for each offender.
The FRS system is also trained over time to learn device LED detection with less false positives whilst the data sets grows.
Security
All running instances, databases and their configuration are accessible only for authenticated users. System will provide options for setting user privileges and access rights for specific parts of the back-end system (REST API application, database etc, web application frontend etc.)
Backup strategy
The strategy change according to the service we want to backup
-
For database, we take a full backup of the slave every 12 hours, an incremental every 1 hour minutes and collect transaction log in between
-
For photos, we will use the Bakula backup system using the “Hanoi Tower” as backup rotation schema, so we can restore each file from 1 hour to 6 months ago
The backup will be stored on a block device backed by DRBD to replicate across nodes
For additional redundancy, an encrypted copy of all backup will be stored in a NAS external to the cluster
Monitoring services
The monitoring of the infrastructure will be handled using Shinken Monitoring
The solution will be deployed in all cluster nodes and will be effective at both server layer and service layer
Notification could be accomplished via RIK relay services ot external services
Client-Server connection
User authentication
To use iBac Pro/Group application user needs to log in with his iBac account. User authentication process is based on OAuth 2.0 protocol. Every request than carries authorization token in the header. This token is refreshed periodically.
Network communication
The network communication is done in a secure encrypted way via HTTPS protocol with TLS cryptographic protocol.
Application data security
All user’s data in the mobile phone are stored securely using encryption. The local user database file is encrypted by 256-bit AES encryption.
Failure & recovery
Connection loss
Application saves all all data (alcohol samples, raised alarms etc.) which were not able to send to the server. This can be caused by sudden connection drop. All these data are later uploaded to the server again until the upload is not successful.
All alcohol samples contain timestamp when the sample was taken, so the supervisor will always see the correct time of the test in the backend.
The app regullary tries to upload all stored information during these events: - when app is open - when heartbeat update is triggered (scheduled one or manual trigger by admin from backend) - when internet connection restore event is received from OS
The alcohol sample is directly connected to the open test in the app by test ID obtained from the server (in case of a currently an open test on the backend). So if the alcohol sample arrives after the test expires, because of the connection loss, the backend is able to correctly pair this sample to given test and correct the test outcome.
Data corruption
All data are stored in MariaDB database running on LPC cluster. On a regular basis full backup is performed and transaction log are stored. High availability is guaranteed via a master/slave setup.
Server unavailability
Each component is designed to be falut-tolerant and uses high availability systems
-
backend is hosted on a multi node solution behind load balancer with monitor and alarm to detect and recover from failures
-
FRS and storage are based on an high availability cluster