1 / 13

Enhancing MobiHealth Security Architecture: Confidentiality, Authentication, and Anonymity

This document presents a comprehensive overview of the security architecture proposed for MobiHealth, focusing on key aspects such as confidentiality, authentication, and patient anonymity. It outlines the security requirements addressed by the architecture, including data storage practices for sensor data, usage of SSL/TLS for secure communications, and robust patient identification methods. The proposed security measures aim to safeguard data transmitted through Body Area Networks (BAN), ensuring the privacy and integrity of personal health information while complying with industry standards.

lionel
Télécharger la présentation

Enhancing MobiHealth Security Architecture: Confidentiality, Authentication, and Anonymity

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. BAN Security Services MobiHealth Plenary Session Santorini 2003/05/26-27

  2. MobiHealth Security • MobiHealth security architecture • End-user security

  3. MobiHealth architecture

  4. MH security architecture proposal

  5. MobiHealth security architecture

  6. MobiHealth Security • MobiHealth security architecture • End-user security

  7. Security requirements addressed by the MobiHealth Security Architecture • Confidentiality • BAN devices (sensors/actuators) <-> MBU confidentiality • Provided by Bluetooth/(ZigBee) • Not foreseen for wired sensors • BAN external confidentiality • Confidentiality provided by SSL/TLS (e.g. HTTPS) • Back End System (Server) external confidentiality • Confidentiality provided by SSL/TLS (e.g. HTTPS) • External traffic characteristics confidentiality • Not foreseen • Can be provided partially by the SSL/TLS protocol

  8. Security requirements addressed by the MobiHealth Security Architecture • Authentication • Sensor authentication to BAN • Provided by Bluetooth/(ZigBee) • Not foreseen for wired sensors • BAN authentication • MBU authentication to SH through user/password • MBU authentication to WSB through HTTP user/password proxy authentication • Back End System (Server) authentication to BAN • HTTPS (SSL/TLS) through a server certificate • Back End System (Server) authentication to End-User Application • HTTPS (SSL/TLS) through a server certificate • End-User Application authentication to Back End System • HTTP User/Password

  9. Security requirements addressed by the MobiHealth Security Architecture • Data storage • Permanent local storage of sensor data • Secure storage in BANData Repository • Not foreseen in BAN, GPRS/UMTS Operator, etc. if not required • Temporary local storage of sensor data • Allowed secure temporary storage for buffering, out-of-coverage recovery, etc. • Keep log of sensor data • Not foreseen • To be provided by the BAN OS / Back-End System if required • Keep log of BAN external transmissions • Not foreseen • To be provided by the SSL/TLS communications module if required

  10. Security requirements addressed by the MobiHealth Security Architecture • Anonymity • Patients anonymity • No use of patients identification but BAN identification • Patients identification could be sent encrypted • Identifiers could be used for patients identification • Time stamping • Time stamping • Not foreseen • Timestamps should be included in packets if required

  11. MobiHealth PKI Server

  12. MobiHealth PKI Server • https://hayek.upf.es/pub/MobiHealth • X.509 certificates creation • Restricted access: • User/Password access • Hospital technical personnel/manager in charge of MBU setup and personalisation

  13. UPF Next Steps • Finishing & Delivering Deliverable 2.5 • Finishing Integration and Testing of MBU with HTTP Connect + HTTP Proxy authentication + HTTPS connection • Standardisation activities • Collaboration to Barcelona Trial • W-LAN tests • BAN security integration • Data Simulation • Safety/Availability study

More Related