1.8. Security design¶
The CamCOPS security model is multi-layered. It is not enough to have a “secure” tablet app; there are other things you must do as well.
CamCOPS can operate in a de-identified mode, in which case security concerns are lower. What follows assumes the use of identifiable, high-risk data.
CamCOPS is designed to operate offline (i.e. the tablet will hold identifiable data for a while), but to move that data securely to the server as soon as possible.
On the tablet, data is always encrypted by CamCOPS. You can also enable whole-device encryption on your tablet defice. See tablet configuration. Details are below.
CamCOPS also provides security systems so (a) you can hand a device to a subject, without that subject seeing other subjects’ data, and (b) so it can be used in an institutional context where administrators apply security policies that individual clinicians can’t alter.
The link and the server also need to be secure. See below.
To meet NHS mobile data protection standards 1, a tablet holding “sensitive information” of a significant degree of sensitivity requires:
a strong password
For relevant CamCOPS platforms:
All CamCOPS clients apply AES-256 2 to all data. Additionally:
Android 3+ devices allow on-device encryption (encrypting applications’ data area) with a passcode 3.
Apple iPads and related iOS devices invoke encryption when a passcode is entered 4.
You should enable tablet encryption, choosing a strong password for your tablet; see tablet configuration.
The CamCOPS application has three security modes: LOCKED, UNLOCKED, and PRIVILEGED.
In the LOCKED mode, the application is locked to a single patient and can only view or add records pertaining to that patient, or anonymous tasks. This mode is designed for handing the device to a patient.
In the UNLOCKED mode, all data may be viewed and edited, and data may be uploaded to the server. This mode is designed for use by clinicians. The user may change the app password that unlocks the app.
PRIVILEGED mode is designed for administrator use. In PRIVILEGED mode, features such as the following are unlocked:
configuring the link to a server, and registering the device with a server;
viewing local data as SQL, and (if the device permits) exporting the local database to an SQL file in an insecure storage area (e.g. an SD card).
The application starts in the LOCKED mode. (Otherwise, someone handed a tablet with CamCOPS running in the LOCKED mode could restart the app and thereby gain UNLOCKED access.)
We envisage that in typical NHS use, an administrator would set up CamCOPS to point to the appropriate NHS server and then give the clinician(s) the app (unlock) password but not the privileged-mode password.
The app never sends patient-identifiable data to the tablet’s logging stream, so a malicious user who plugs the tablet into a debugging computer (e.g.: USB debugging enabled on tablet; run adb logcat on the computer) won’t see patient-identifiable data that way.
The CamCOPS app stores its app (unlock) and privileged-mode codes using bcrypt hashes (themselves stored in the AES-256-encrypted SQLCipher database). The passwords themselves are not stored.
The administrator may choose whether the CamCOPS app stores the user’s server password:
using reversible encryption (more convenient but fractionally less secure; the password would be vulnerable to a skilled attacker with both the tablet OS’s unlock code and the CamCOPS password)
not at all (more secure, but requires the user to enter it at each upload).
The app sets android:allowBackup=”false”, thus opting out of the Android backup-and-restore infrastructure 7 (otherwise, access to the CamCOPS database data would be possible for someone with the tablet password 8, though this would still be AES-256 encrypted).
The server requires username/password identification (or subsequent secure session token authentication) before it will accept an upload.
The server requires that the device (identified by a unique device number) be registered before it will accept an upload.
Users require an additional permission, set on the server, before they can register a device. (We envisage that in practice, device registration would be managed by an administrator for high-security environments.)
The server only accepts incoming data; it will not provide data to a device. (Therefore, even a hand-crafted application masquerading as an instance of CamCOPS and in possession of a valid username, password, and device ID cannot download any data.)
The server will not add new fields or tables based on the claims of the uploading agent.
The server takes standard precautions against SQL injection 9.
The web front end should be constrained to HTTPS to ensure link security.
Access is governed by username/password pairs. Additionally, multi-factor authentication can be required by the system administrator.
The server should be secured in standard fashion. These are matters outside CamCOPS. Standard security considerations include:
visibility on public networks (preferably not!)
inappropriate provision of information by a misconfigured web server
security of physical backups
The server stores CamCOPS passwords using bcrypt hashes.
Crashes in the CamCOPS application should not (and in our experience do not) affect data integrity, as the SQLite backend is designed to cope with this 10.
CamCOPS doesn’t send a copy of your data back to its base. Your data is private to you.
Tablet-side audit trails are minimal, but the application time-stamps all tasks at their creation, and time-stamps the last modification to any record, in addition to collecting information relevant to the time it takes to complete each task.
The CamCOPS application maintains a number of task-specific tables (e.g. patient, phq9, gad7). It uploads table-wise (and the entire upload process is atomic). To each record, the server adds fields allowing an audit trail; see table structure. When a record is modified or deleted, the old versions are kept.
The server’s tables therefore contain a snapshot of each device’s current state, and a complete audit trail, whose granularity is the frequency of uploads from a particular device.
Read access requests to the server (via the web viewer) are also audited, as are command-line CamCOPS operations.
The code is open-source, and should only include content from tasks/questionnaires that are in the public domain or where permission exists to use the task in perpetuity.
What would it take to steal CamCOPS data?
A non-technical attack 11.
Steal a tablet, the tablet’s password, and its CamCOPS app password together; this would allow records to be viewed on that device.
Steal a tablet, the tablet’s password, its CamCOPS app password, and its CamCOPS privileged-mode password together; this would allow records to be sent to a dark server of the attacker’s choosing.
Steal a tablet that hasn’t been properly secured with a device password; this would eliminate the requirement for the tablet’s password from all of the above.
Break into the server and gain direct access to its database. This emphasizes the importance of securing the server.
These methods of attack sound plausible but should not be possible:
Steal a tablet and the tablet’s password, root the device, and access the database directly; then you only have to break AES-256 to decrypt the database 2. (Hint: that’s hard.)
Steal a tablet and the tablet’s password, download the open-source CamCOPS application, modify it, install it over the existing application without deleting the application data, and use the modified application to export data. Why not? (1) Apps installed on both Android and iOS tablets are digitally signed, and an app attempting to install with a different digital signature will not be accepted as a replacement for the original, and therefore will not gain access to the original app’s data. (2) The CamCOPS database is still AES-256-encrypted.
Steal an Android tablet (but not the tablet password), modify the operating system, use it to read the data. Why not? (1) This should not work as long as filesystem encryption is enabled; the necessary keys are not stored on the device 13. (2) The CamCOPS database is still AES-256-encrypted.
I’ve not found an England-wide NHS mobile security standard, but the Scottish one is this: 1.
That standard classifies the data using a traffic-light system. CamCOPS data could include patient-identifiable information and information on patients’ mental states, so it would definitely not be GREEN. It might be AMBER (causing distress/significant embarrassment if lost; low risk to a person’s safety if lost); it might be RED (risk of harm to mental health if lost; causing significant distress if lost; constitute a substantial breach of privacy; etc.).
The standard specifies a minimum password strength.
For tablet passwords: this is primarily a device issue and both Android and iOS devices can be configured for alphanumeric passwords, not just 4-digit PINs.
CamCOPS doesn’t restrict password type for its app passwords; ensure that your users choose a sufficiently secure password 12.
AMBER and RED levels require whole-disk encryption for NHS-owned devices.
Personally-owned devices would be discouraged or prohibited for AMBER and RED information, since security is difficult to enforce. Specifically, they are prohibited for RED data, and may be considered for AMBER data but only if set up so that no data is stored on the device itself and a remote wipe is possible for residual data (which would negate the “transiently offline” capabilities of CamCOPS). Therefore, by these standards only NHS-owned official devices should be considered for CamCOPS.
Note, however, that all CamCOPS information is encrypted, even if CamCOPS is installed on an unencrypted device.
Removable media for AMBER or RED information must be encrypted. In practice, CamCOPS’s function to export to an SD card would only be accessible to administrative staff.
So the minimum for each tablet is likely to be:
mandate a decent password on iPads or Android tablets, and for CamCOPS;
mandate the whole-disk encryption option on Android tablets;
perhaps ensure that clinicians don’t have access to the Privileged mode (by having an administrator configure and password-protect each device – this takes ~30 seconds).
Full security is required on the server.
In particular, consideration should be given to restricting access to devices from within an appropriate domain (e.g. within a given NHS Trust or university).
NHS Scotland: CEL 25 (2012): http://www.sehd.scot.nhs.uk/mels/CEL2012_25.pdf
http://security.stackexchange.com/questions/10529/are-there-actually-any-advantages-to-android-full-disk-encryption; http://source.android.com/tech/encryption/android_crypto_implementation.html; http://support.google.com/android/bin/answer.py?hl=en&answer=1663755
xkcd Exploits of a Mom: https://xkcd.com/327/
xkcd Security: https://xkcd.com/538/
xkcd Password Strength: https://xkcd.com/936/