Carelink Data Protection and Privacy

Alan Fitzpatrick, opensky Data Systems

 

opensky has researched on important areas in the context of CARELINK such as Privacy Impact assessment, Consent and security.

All data collected from a health or wellness wearable device should be considered sensitive, and thus require an affirmative and effective consent process before they can be collected and used.

Limitation on the collection and use of data. No data should be collected for ongoing processing until there is an affirmative expression from the consumer.

The following specific privacy requirements in relation to persons using CARELINK:

  • Patients should know who owns/accesses their health data and where that data is stored
  • Appropriate patient permission for using his/ her health data (e.g., power of attorney for a caretaker)
  • Anonymity or pseudonymity to hide real identities of the patient by means of dividing the identity of a person into sub-identities.
  • Location privacy to keep locations of users, devices, etc., private.
  • Emphasising privacy within the application design.

Wearable technology is vulnerable to location tracking.  There exists some security weakness that make such wearable devices vulnerable to attack. Because location information discloses a user’s movements in real time and creates a record of a user’s movements, this information can raise a host of privacy concerns. Geolocation information can also facilitate criminal behaviour i.e.  stalking, as such infor­mation can easily identify an individual’s presence or future location.

One of the critical attacks on wearable technology is authentication issue. The low processing due to less computing power of wearable device cause the developer’s inability to equip some complicated security mechanisms and algorithm on the device. Wearable computing brings new challenges and opportunities for user authentication.

In the case of CARELINK where accurate, real-time location data is critical, special attention needs to be paid to ensure clock synchronisation. Critical data (timestamps) need to be protected from attacks and countermeasures are proposed in the table below.

Attack Countermeasure
Modification of Timestamps A secret key is shared between the sender and receiver for the authentication.
Signal Jamming – Delay Delay attacks can be prevented by building in a maximum threshold value
Replay – compromise time syncing A node will maintain the value of last timestamp or sequence number from its parent. When it receives a broadcast from its parent, it will check if it is an old message. If so, it will regard it as a replay message and just simply discard it

 

Share to