1 / 41

563.5 Monitoring and Surveillance

563.5 Monitoring and Surveillance. Carl A. Gunter University of Illinois Fall 2007. Privacy. Made more important by advances in Networks Databases Sensor systems Has three aspects Technological Social Commercial. Case Studies.

gay-gomez
Download Presentation

563.5 Monitoring and Surveillance

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. 563.5 Monitoring and Surveillance Carl A. Gunter University of Illinois Fall 2007

  2. Privacy • Made more important by advances in • Networks • Databases • Sensor systems • Has three aspects • Technological • Social • Commercial

  3. Case Studies • Location services in smart buildings: using building management capabilities to provide location services • Assisted living: monitoring health information from medical devices in homes

  4. Case Study: LIS based on BAS • Smart buildings collect data on users through the Building Automation System (BAS) • BAS data protected because of privacy concerns • BAS data could be used to aid building users • It could be used to implement a Location Information System (LIS) Boyer Tan Gunter 06

  5. Raw Data Sources • Door Lock System • Occupancy Sensors • Network Jack Activity • Application Software, such as AIM • Video Surveillance • Wireless Network • GPS • RFID Tags • Telephone

  6. The Seibel Center • Andover Continuum BAS • Uses electronic door locks and occupancy sensors • Case study for a Location Information System

  7. How to Build an LIS • Define an Ownership Model • Determine the environment events of interest and how to deduce them • Develop a model for privacy-information sharing for events

  8. Ownership Model • U, set of users • L, setof locations • S, set of system events • T, a set of values with a linear ordering, signifying time • time : STwhich determines the time of an event • user : SU U {} which determines the users associated with an event • loc : S  L which determines the location in which an event occurred • o : L 2U which determines the owner of a location •  : S2U which determines the owner of an event

  9. Environmental Events • An aggregate event • Deduced from a set of system events • E is the set of environment events in an LIS • induce : 2S2E determines the set of environment events that can be deduced from a set of system events • Applies a set of deduction rules of the following form:

  10. Privacy Policy • System events protected to protect user’s privacy • We define 2 indexed families of functions: • filter : UxU(2S2S) • mask : UxU(2E2E) • Users are able to define 2 functions that establish their privacy policy • filteruv : 2S2S • maskuv : 2E2E

  11. Formal Definition of LIS • A Location Information System, L, between an ownership model and set, E, of environment events consists of three functions: • filter : UxU(2S2S) • mask : UxU(2E2E) • induce : 2S2E

  12. Reveal • We also define a family of functions reveal : UxU(2S2E) which performs a look of environment events in an LIS • revealuvis the function that v calls when he wishes to learn something about u

  13. Janus’s Map: Ownership • Locations in Siebel Center • G={floor, wing, room}, the set of location granularities • Lfloor L, Lwing L, Lroom L • Locations are defined as a tuple: Lfloor x (Lwing U {})x (Lroom U {}) • Events • Defined as a tuple (UU {}) x L x T x  •  is a set of event types • type : S  returns the type of an event

  14. Janus’s Map: Ownership (con’t) • ois static policy that maps room ownership •  assigns ownership of an event s first to the user(s) and then to o(loc(s))

  15. Janus’s Map: Environment Events • The main goal of Janus’s Map is to determine location information about users in the building • E is defined as a set of tuples U x L x T x P • P = {In,Near} defines a users proximity to a location

  16. Janus’s Map: Privacy Policy • Users define rules from which the functions filteruv and maskuv are derived • System events are filtered based on time, date, event type, and location • Environment events are masked to hide detailed location information

  17. An Example: System Events What happens when Bob searches for Alice?

  18. An Example: Filtering Events • Alice’s Filtering Policy for Bob: Events must: • Occur Any day between 08:00 and17:00 • Be of type ValidAccess, DoorAjar, or OccupancySensorTrue • After the filtering policy is applied:

  19. An Example: Event deduction • Rule: if a ValidAccess event occurs followed by a DoorAjar followed by a OccupancySensorTrue event all in the same location we can deduce that the users who performed the ValidAccess was in the room at the time of the OccupancySensorTrue event as well as that there were near the room at the time of the ValidAccess event. • We can deduce: • (Alice, SC4309, 1/1/2006 10:01, Near) • (Alice, SC4309, 1/1/2006 10:03, In)

  20. An Example: Masking • Alice’s Masking policy for Bob: • Bob can only know what floor Alice is on, not the room • Bob is finally returned: • (Alice, SC4, 1/1/2006 10:01, Near) • (Alice, SC4, 1/1/2006 10:03, In)

  21. Architecture for Janus’s Map Rule Database Door Rights List Rules Owners Door Access Database Access Control Module Alice’s door accesses Alice? Location Service Data Aggregator Alice’s Location For Bob Aggregated Data Data Cleaner Internet Occupancy Sensor System Room Occ.

  22. Rules in Janus’s Map • 3 Parts • Targets • Data Access • Visibility • Example: • Target: Bob, Carol • Number of past entries: 5 • Event types: Valid Access only • Event time: Between 8am and 5pm • Event date: From Jan. 1, 2006 to Jan 1, 2007 • Event days: Monday - Friday • Rooms: All • Visible fields: Event Type, Event Time, Room • Granularity: Wing

  23. Digital Rights Management Problem • Bob can keep track of long term data on Alice by aggregating the data himself • Similar to the problem of copying digital media • Alice has no control over what Bob does once he has her data. • An LIS should be designed to make it difficult for Bob to use Alice’s data in inappropriate ways

  24. Summary on Janus’s Map • It is possible to provide a foundation for sharing BAS data based on an ownership model, inference rules for environment events, and a system for discretionary control • This can be practically applied to develop an LIS in a smart building

  25. Growing industry in monitoring patients at home Options for chronic illnesses Reduces visits to hospitals and ERs Allows for remote monitoring of status Lets patients be more involved in their own care Case Study: Assisted Living

  26. State of the art • Telemedicine systems • Home health monitoring systems • Honeywell HomMed • Medical Monitors Limited, Australia • Bristol-Myers Squibb CML Medical Monitor • All are proprietary single-vendor solutions • Some communicate by telephone to a monitoring service • Some sell servers to clinicians so they can receive information from patients • Some are moving to using the Internet for communications

  27. Technical Goals • Let patients and clinicians communicate information via remote communication devices and protocols that… • Allow for extensible and multi-vendor solutions • Do not interfere with current medical information practice (i.e. referrals, sharing records, etc.) • Let patients access their records • Let authorized family members and caregivers access relevant records • Are provably secure against attack • Aid in enforcing regulatory compliance • Restricts a service provider to know only what it needs

  28. Toward Open Protocols • Specification of protocols for the various parties in the system • Step towards open APIs for multi-vendor device integration • Explicitly identifying steps for bootstrapping and transmission while supporting the technical goals • Pushing boundaries of formal protocol specification and security verification • Precise definition of messages, content • Verification of multi-party protocols with different agents and a concrete application • Verification of semi-trusted entity (ALSP) using a variation of a correspondence theorem May Shin Gunter 06

  29. Issues • Security • Privacy information must be protected during transmissions • Devices should be authenticated to use home-network resources • Reliability • Health information should be delivered correctly • Usability • Easy-of-use is important for elderly people • Interoperability • Heterogeneous and distributed devices should be integrated

  30. Architecture • Drop-Box architecture • Medical Devices • Monitoring Service • Clinician Service • Home-Network Protection • USB token-based approach • Web service-based approach • Web service standards: SOAP, WS-Security, WS-Reliability • Security • (End-to-End Confidentiality • and Integrity) • Reliability • Security • (Availability) • Usability • Interoperability

  31. Drop-Box Architecture Monitoring Service Clinician Medical Device Store & Forward Enc[Health status] Enc[Reminder ]

  32. Functionalities Home Network Protection & Usability Reliability End-to-End Secure Communication Interoperability

  33. Security tokens • Digital Signatures for authentication • Symmetric and asymmetric encryption • Individuals do not have public keys. Clinicians and ALSP do

  34. Message types • Report – standard message of medical reading • Alarm – non-standard medical reading • May require soon or immediate medical treatment

  35. Message Encryption • Messages are encrypted twice Header Information (Including sender, recipient, data ID etc.) Header Information (Including sender, recipient, data ID etc.) Header Information (Including sender, recipient, data ID etc.) Medical data (readings, checksum, etc) Medical data (readings, checksum, etc) Medical data (readings, checksum, etc) Only authorized people can see Stored in ALSP Transmitted over network

  36. Implementation

  37. Attack Model • Dolev-Yao style attack model • Often referred to as a “symbolic attacker” • Attacker controls the channel • Can insert garbage on the channel • Can indefinitely delay, repeat, and take apart messages • Log all previous messages to make new ones • Worst it can do is delete it • Cryptography is perfect • Attacker can not guess keys or correct signatures • Can not take apart or cryptographically analyze encrypted blobs • Proof is a correspondence theorem: If event B is observed then even A occurred before it • Attacker can not issue events

  38. Theorems • Messages received imply they were sent • If a clinician receives a reading, the patient sent it (trusting ALSP) • Attacker can not discover the reading, even if the ALSP reveals all of its secrets • Corollary: The ALSP can not discover the reading

  39. Formal Verification • TulaFale [MS Research Samoa] • An applied Pi calculus derived language • Agents are processes that communicate over named channels • Messages are composed with symbolic cryptographic primitives • Proofs [Blanchet’s ProVerif] • Correspondence between a message being received and having been sent by an authorized agent • Show that the ALSP can not derive the medical readings

  40. Summary on Assisted Living • Careful design of architecture and protocols • Formal specification of protocols • Formal verification of protocols • Success using off-the-shelf tools for a quick turn around on architecture design, protocol specification, and security verification

  41. Conclusions • There will be increasing opportunities for monitoring and surveillance • There will be increasing use of monitoring and surveillance • Techniques to control these techniques so that the best serve stakeholders will be a pivotal concern

More Related