WP2 UPF Contribution to MobiHealth Security in the MobiHealth BAN

1. WP2UPF Contribution to MobiHealthSecurity in the MobiHealth BAN Enschede2002/09/18-20

2. UPF Participation Workpackages and Tasks • WP2 - MobiHealth services and BAN integration • T2.2 - Development and integration of the BAN platform • T2.5 - Security Services for the BAN • Starting on M3: • WP2 - MobiHealth services and BAN integration (M3-M13) • T2.2 - Development and integration of the BAN platform (M3-M13) • T2.5 - Security services for the BAN (M3-M13)

3. WP2 Security Timetable • T2.5 - Security services in the MobiHealth BAN • Refinement of requirements M03-M05 (Aug-Sep) • BAN Test Security Platform Set-up M04-M06 (Sep-Oct) • BAN Network Security Tests M05-M08 (Oct-Dec) • BAN Transport Security Tests M05-M08 (Oct-Dec) • BAN Application Security Tests M05-M08 (Oct-Dec) • BAN Security Integration M08-M10 (Jan-Feb) • BAN Final Security Integration M10-M13 (Mar-May)

4. General security requirements • Data protection: • Components • Storage • Access • Communications • Hop­to­hop • End­to­end

5. Other security services • Traffic confidentiality (origin, destination, length, time, ... of messages) • Confidentiality of identity (anonymity, pseudonymity) • Confidentiality of location • Availability (counter DoS attacks) • Accountability • Reliability

6. MobiHealth System Architecture

7. MobiHealth System Components • Sensor • Actuator • Front-End • MBU (Mobile Base Unit) • WSB (Wireless Service Broker) • AppServer • WorkStation

8. MobiHealth System Components Security • Confidentiality / privacy: Data encryption and authentication • Data confidentiality • No data stored in some components • Authenticity / integrity • User authentication (password, smartcard, . . . ) • Terminal authentication (SIM, . . . ) • Application/server authentication (certificate, . . . )

9. MobiHealth Communications • Sensor <-> Front-End • Actuator <-> Front-End • Front-End <-> PDA • PDA<->WSB • WSB <-> AppServer • PDA <-> AppServer • AppServer <-> Workstation

10. Communications Security • Security can be added to most communication layers • Different security features depending on layer: • Data link layer: Bluetooth, GPRS/UMTS, ... • Network layer: IPsec, ... • Transport layer: SSL/TLS, HTTPS, ... • Application layer: Data encryption (OpenSSL Libraries, MIME)

11. Data Link Layer / Network Layer Security • Data Link Layer Security • Hop-to-hop protection (encryption and authentication). • No user or application authentication. • Security provided by Bluetooth or GPRS/UMTS, in each case, can be used. • Network Layer Security • Host-to-host protection (encryption and authentication) • Hop-to-hop protection • End-to-end protection • No user or application authentication. • IPsec can be used.

12. Transport Layer / Application Layer Security • Transport Layer Security • End-to-end protection (encryption and authentication). • Application-to-application protection; opt. user authentication • SSL/TLS or HTTPS can be used. • Application Layer Security • Application-to-application and application_user-to-application_user protection, including user authentication. • Usually through encryption or/and signature of data sent through the communications stack. • SMIME or OpenSSL libraries could be used to encrypt and sign data.

13. MobiHealth SecurityBAN and Rest of the System • BAN Security • Sensor <-> Front-End • Front-End • Front-End <-> PDA • PDA • PDA <-> WSB • PDA <-> AppServer • Rest of MobiHealth Security • WSB • AppServer • Workstation • WSB <-> AppServer • AppServer <-> Workstation

14. WP2 Security Timetable • T2.5 - Security services in the MobiHealth BAN • Refinement of requirements M03-M05 (Aug-Sep) • BAN Test Security Platform Set-up M04-M06 (Sep-Oct) • BAN Network Security Tests M05-M08 (Oct-Dec) • BAN Transport Security Tests M05-M08 (Oct-Dec) • BAN Application Security Tests M05-M08 (Oct-Dec) • BAN Security Integration M08-M10 (Jan-Feb) • BAN Final Security Integration M10-M13 (Mar-May)

15. Security Possible Setups First Approach • iPAQ Linux (GPRS) to Linux Gateway using IPsec tunnel with pre-shared keys. • iPAQ Linux (GPRS) to Linux Gateway using IPsec tunnel with x.509 certificates. • iPAQ Linux (GPRS) to Windows 2000/XP Gateway using IPsec tunnel with pre-shared keys. • iPAQ Linux (GPRS) to Windows 2000/XP Gateway using IPsec tunnel with x.509 certificates. • iPAQ Windows CE (GPRS) to Linux Gateway using IPsec tunnel with pre-shared keys. • iPAQ Windows CE (GPRS) to Windows 2000/XP Gateway using IPsec tunnel with pre-shared keys.

16. Setup Requirements • Common part: certificates creation • Set-up a Certificate Authority (CA) • Certificates Generation • Installation of certificates in Gateway Machines (Linux) • Installation of certificates in Linux machines (PPC 2002 & PC) • Installation of certificates in Windows 2000/XP machines (PC) • FreeS/WAN: IPsec for Linux (Linux PPC & PC) • Installation and configuration in Linux machines

17. Test Security Platform Set-up • Linux PC • Windows 2000 PC • iPAQ • Just arrived • Test iPAQ <-> GPRS connection • Serial port • Bluetooth • GPRS Phones • Received beginning September from Movilforum • 2 Motorola Timeport 260 GPRS • 1 Ericsson T32m Bluetooth

18. Software Requirements and Installation • Downloaded and installed • FreeS/WAN • X.509 Patch for FreeS/WAN (version 0.9.12 or better) • Patches to add multiple encryption ciphers, etc. (optional) • Marcus Müller's Windows 2000 VPN Tool • OpenSSL package in Linux • AdmitOne(r) VPN Client for Pocket PC • Linux on iPAQ

19. Test Security Platform Set-up Current Status Install. Config. Tests Linux GW and CA yes yes yes W2K/XP GW yes yes yes Linux PC vs. Linux GW yes yes no W2K/XP PC vs. Linux GW yes yes yes W2K/XP PC vs. W2K/XP GW yes yes no iPAQ WCE vs. Linux GW no no no iPAQ WCE vs. W2K/XP GW no no no iPAQ Linux vs. Linux GW no no no iPAQ Linux vs. W2K/XP GW no no no

20. Open Security Issues in the BAN (1/4) • What are the security requirements for the trial scenarios • Which components are to be protected • Internal network: sensors, front­end, MBU • External network: GPRS/UMTS, application server • How to integrate security into the BAN architecture • Hardware, BAN OS • What will be there at the server side? • Where is the “intelligence” of the system to be developed? • More cooperation required with the other WP2 partners

21. Open Security Issues in the BAN (2/4) • Communication Protocols • Sensor <-> Front-End • Actuator <-> Front-End • Front-End <-> PDA • PDA<->WSB • [WSB <-> AppServer] • PDA <-> AppServer • [AppServer <-> Workstation] • Communication Protocols Security

22. Open Security Issues in the BAN (3/4) • MobiHealth System Components Functionality • Sensor • Actuator • Front-End • MBU (Mobile Base Unit) • [WSB (Wireless Service Broker)] • [AppServer] • [WorkStation] • MobiHealth System Components Security • Storage • Access

23. Open Security Issues in the BAN (4/4) • MobiHealth System Components Platform: • PDA • OS: Windows CE / Linux • Application Server • Hardware: PC / Workstation • OS: Windows 2000 / Linux • Workstation • Hardware: PC / Workstation • OS: Windows 2000 / Linux

25. BAN Architecture

26. General Security Threats • Transmission or storage electronic data security threats • Interruption: Data transmission interrupted, or stored data deleted. • Interception: Data accessed and read during transmission or storage. • Modification: Data modified during transmission or storage. • Fabrication: Data created by a third party, supplanting the data originator. • Man in the middle: Third party introduced in the middle of communication, supplanting receiver from sender point of view, and supplanting sender from receiver point of view.

27. General Security Services • General security services to avoid security threats: • Confidentiality: Protect data to be (almost) impossible to interpret for non authorised user in communication or storage. • Integrity: Protect data against non allowed modification, insertion, reordering or destruction during communication or storage. • Authentication: Allows the way to corroborate identity of the entities implied in the data creation or communication. • Non Repudiation: Protects against unilateral or mutual data repudiation. • Access control: Protects system and resources against not authorised use.

28. General Security Services and Threads • Security services for security threats protection: • Interruption: -- • Interception: Confidentiality • Modification: Integrity, Authentication • Fabrication: Authentication • Man in the middle: Authentication • Threats addressed by security services: • Confidentiality: Interception • Integrity: Modification • Authentication: Fabrication, Man in the middle • Non Repudiation: -- • Access control: --

29. General Security Mechanisms • Symmetrical key encryption: “Low” computing power • Asymmetrical key encryption: “High” computing power • Encryption with public key of receiver • Encryption with private key of sender • Signature: Asymmetrical key encryption of message hash with private key of sender. “Low” computing power • Combined: F.e. Asymmetrical key encryption for interchange of symmetrical key + Symmetrical key encryption for data interchange.

30. General Security Services and Mechanisms • Confidentiality: Encryption. Symmetrical or asymmetrical. Symmetrical usually used. • Integrity: Signature or Encryption (Symmetrical or asymmetrical). Signature is better. • Authentication: Signature or Symmetrical Encryption with private sender key. Signature is better. • Non Repudiation: Signature. Single or mutual. • Access control: --

31. Communication layers • Layer 7: The application layer • Layer 6: The presentation layer • Layer 5: The session layer • Layer 4: The transport layer • Layer 3: The network layer • Layer 2: The data-link layer • Layer 1: The physical layer

32. Sensor <-> Front-End Security • In principle, no data encryption is foreseen, except in case Bluetooth is used for wireless. • Communications: • Wired: Maybe security is not really needed. • Wireless: Security may be required in the communication. • Bluetooth • Zigbee • Data encryption and/or authentication: Only in wireless communication? • Bluetooth

33. Front-End Security • Front-End stores data received from sensors. This data stored in the Front-End should be protected. • Data encryption and authentication: • SMIME • OpenSSL libraries

34. Front-End <-> PDA Security • It must be decided if security is really needed. • Communications: • Wired • Wireless: security is required. • Bluetooth • Flash memory • Data encryption and authentication: Could be required • Bluetooth • SMIME • OpenSSL libraries

35. PDA Security • PDA should act as communication component in BAN to get data from Front-end and send it secure through GPRS/UMTS to AppServer. • Data encryption and authentication: • No data should be stored in the PDA. • User authentication: May be required for accessing PDA • Password • SIM-card • X.509 key

36. PDA <-> WSB Security • Communications: • GPRS/UMTS • WAP + WML • HTTP / HTTPS + HTML • User authentication: May be required. • SIM-card based? • Terminal authentication: May be required. • SIM-card • X.509 key • Data encryption and authentication: • GPRS/UMTS • Network layer security (f.e. IPsec) may be required. • Transport layer security (SSL/TLS, HTTPS) may be required • Application layer security (data encryption) (SMIME, OpenSSL libraries) may be required.

37. PDA <-> AppServer Security • Should include some authentication and data encryption. • Communications: • TCP / IP (IPsec) • WAP + WML • HTTP / HTTPS + HTML • User Authentication: It should also include some user authentication. • SIM-card • X.509 key • Terminal authentication: Some terminal authentication may be required. • SIM-card • X.509 key • Data encryption and authentication: • Network layer security (f.e. IPsec) may be required. • Transport layer security (SSL/TLS, HTTPS) may be required • Application layer security (data encryption) (SMIME, OpenSSL libraries) may be required.

38. WSB Security • No data should be stored in the WSB. • Data encryption and authentication: • No data should be stored in the PDA.

39. AppServer Security • Data stored should be encrypted to avoid interception. • Data encryption and authentication: • SMIME • OpenSSL libraries • User authentication: May be required for accessing the AppServer. • Password • SIM-card • X.509 key

40. Workstation Security • Data Storage: • No data should be stored in the Workstation. • User authentication: Some user authentication may be required for accessing the Workstation. • Password • SIM-card • X.509 key

41. WSB <-> AppServer Security • Communications: • TCP / IP (IPsec) • WAP + WML • HTTP / HTTPS + HTML • Data encryption and authentication: • Network layer security (f.e. IPsec) may be required. • Transport layer security (SSL/TLS, HTTPS) may be required • Application layer security (data encryption) (SMIME, OpenSSL libraries) may be required.

42. AppServer <-> Workstation Security • Internal communication inside hospital or health centre. • Communications: • TCP / IP (IPsec) • WAP + WML • HTTP / HTTPS + HTML • Data encryption and authentication: • Network layer security (f.e. IPsec) may be required. • Transport layer security (SSL/TLS, HTTPS) may be required • Application layer security (data encryption) (SMIME, OpenSSL libraries) may be required.

43. Communications security • Communication layers: • Data link layer (Bluetooth, GPRS, . . . ) • Network layer (IPsec, . . . ) • Application layer (SSL/TLS, . . . ) • Data link layer security for hop­to­hop protection, • Application layer security for end­to­end protection

44. MobiHealth Communication • Sensor <-> Front-End: Wired / Bluetooth / Zigbee • Actuator <-> Front-End: Wired / Bluetooth / Zigbee • Front-End <-> PDA: Bluetooth • PDA<->WSB: GPRS / UMTS + [WAP + WML | HTTP / HTTPS + HTML] • WSB <-> AppServer: HTTP / HTTPS + HTML | WAP + WML • PDA <-> AppServer: HTTP / HTTPS + HTML | WAP + WML • AppServer <-> Workstation: HTML

45. Security services • Confidentiality / privacy • Data confidentiality • Authenticity / integrity • User authentication (password, smartcard, . . . ) • Terminal authentication (SIM, . . . ) • Application/server authentication (certificate, . . . )