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 often as possible.
- On the tablet, the single most important security measure is to
enable device encryption with a strong password. 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 [NHS Scotland: CEL 25
(2012)], a tablet holding “sensitive information” of a significant degree
of sensitivity requires:
- whole-disk encryption
- a strong password
For relevant CamCOPS platforms:
- Android 3+ devices allow on-device encryption (encrypting applications’
data area) with a passcode. [StackExchange;
- Apple iPads and related iOS devices invoke encryption when a passcode
is entered. [Macworld;
- Both these platforms have sandboxes to prevent one application seeing
another’s data. [Apple;
You must enable tablet encryption, choosing a strong password for your
tablet; see tablet configuration.
CamCOPS app security
- The CamCOPS application has three security modes: LOCKED, UNLOCKED, and
- 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
- 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
- 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
Internally in the tablet app
- 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
- The administrator may choose whether the CamCOPS app stores the user’s
server password using reversible encryption (more convenient but less
secure; the password would be vulnerable to a skilled attacker with the
tablet OS’s unlock code) or doesn’t store it (more secure, but requires the
user to enter it at each upload).
- The app sets
android:allowBackup="false", thus opting out
Android backup-and-restore infrastructure (otherwise, relatively easy
data access would be possible for someone with the tablet password; see
- The link to the server is constrained to use HTTPS and therefore link
- By default, the app will insist on a validated SSL certificate (though
this can be turned off by the administrator for low-security environments
using a self-signed [“snake oil”] SSL certificate).
- Privileged-mode access is required to change the server; therefore,
from a clinician’s point of view, the device is locked to a single
Communication between tablet and server
- The server requires username/password identification before it will
accept an upload.
- The server requires that the device (identified by a platform-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
- The server takes standard precautions against SQL injection.
Communication between user and server using the web front end
- If used, the web front end should be constrained to HTTPS to
ensure link security.
- Access is governed by username/password pairs.
Internally in the server
The server should be secured in standard fashion. These are
matters outside CamCOPS. Standard security considerations include:
- physical access
- visibility on public networks (preferably not!)
- firewall configuration
- SSH access
- inappropriate provision of information by a misconfigured web
- database security
- security of physical backups
- The server stores CamCOPS passwords using bcrypt hashes.
Security against data loss
- 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. [SQLite: testing,
CamCOPS doesn’t send a copy of your data back to its base. Your data is
private to you. However, by default, when the CamCOPS app or server
starts, it does send some basic usage details back to base (at
egret.psychol.cam.ac.uk), helping us to know how CamCOPS is being used and to
support users better; see server and tablet configuration. No patient-identifiable information,
per-patient information, or task details are sent. We hope this doesn’t
bother you, but if it does, you can turn this behaviour off.
- 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 tasks/questionnaires
that are in the public domain or where permission exists to use the task in
Black Hat’s options
What would it take to steal CamCOPS data?
- 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 and the tablet’s password, root the device, and access
the database directly.
- 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. The last two options emphasize the importance of
the tablet’s security features.
- 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
- 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? 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
- Steal an Android tablet (but not the tablet password), modify the
operating system, use it to read the data. Why not? This should
not work as long as filesystem encryption is enabled; the necessary keys
are not stored
on the device.
Match to NHS security requirements
- I’ve not found an England-wide NHS mobile security standard, but the
Scottish one is this: [NHS Scotland: CEL 25
- 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. This is primarily a
device issue and both Android and iOS devices can be configured for
alphanumeric passwords, not just 4-digit PINs.
- AMBER and RED levels require whole-disk encryption for NHS-owned
- 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.
- 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;
- mandate the whole-disk encryption option on Android tablets;
- 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).