For more details, see these Objectives:
- Design of a two-tier monitoring architecture with data protection reversion bound to third-party cooperation. The proposed architecture will devise three components. A front-end tier will enforce data protection primitives on the captured data prior to its delivery to the relevant data controller. A back-end tier running at the data controller site will safely store, manage and coordinate access to and processing of the collected data. A third entity referred to as privacy-preserving controller (internally or externally administered, depending on the exploitation model - see section 18.104.22.168) will cryptographically control the front-end data protection mechanisms to prevent unnecessary data disclosure within the controller domain itself. It will be triggered by, and interoperate with, the back-end tier when selective removal of the front-end data protection mechanisms will be mandated (e.g. upon attacks, abuses, queries from public enforcement authorities).
- Extension and promotion of standard-based data export protocols. The project is in a privileged1 position to i) design, develop, and demonstrate extended versions of the IETF IPFIX (IP Flow Information eXport) protocol and information model, capable of describing, handling and managing protected data, and ii) promote through IETF standardisation privacy-protective data exporting. The extended version of IPFIX will be employed in the considered architecture for both front-end to back-end communication as well as for data export from the back-end.
- “Blind” intrusion detection. This is a high-challenge high-risk research goal. The final objective is to adapt signature-based (i.e. string-matching) intrusion detection mechanisms such as [BRO] or [SNORT] to “blindly” operate over anonymised traces with encrypted payload. In other words, IDS should be capable of detecting patterns and triggering alarms without the ability to decrypt the full data payload itself, thus preserving the privacy of the packet information content. Cryptographic mechanisms suitable for this purpose will be investigated and/or adapted, and (if necessary) complemented by meta-data extracted in the front-end (i.e. prior to encryption and with the crypto information available) and encoded into the data trace.
- Design of monitoring application friendly data protection mechanisms – With both reference to one-way anonymisation and two-way encryption, as well as to front-end and back-end, we will design data protection mechanisms capable of preserving properties of the packet header information fields (such as IP network prefix, uniqueness of socket addresses, etc), and of the events associated to the packet (such as time-stamp) to be used by monitoring applications for their operation. These mechanisms are referred to as “monitoring application friendly” since their goal is to avoid reducing the effectiveness of the monitoring application. With specific reference to the back-end (but also to the front-end when deployed as a stand-alone component – see section 22.214.171.124) and with the goal to export data to the public research community, the requirement of monitoring application friendliness will be loosened in favour of robust privacy requirements, and innovative anonymisation mechanisms will be devised for optimal privacy vs data utility trade-offs.
- High performance front-end implementation – An high performing front-end implementation based on special-purpose HW devices (Network Processors being the technology of choice) will be developed, to target accurate (precisely time-stamped) packet capture and related processing at link speed beyond 1 gigabit per second without loss. Leveraging hardware parallelism, the front-end will further support high performance / lightweight versions of the envisioned data protection algorithms and will integrate an IPFIX protocol stack version specifically redesigned and optimised for this purpose.
- Secure and high-performing back-end implementation – To increase its exploitability, the back-end will be designed to retain a secure and privacy-preserving operation even when deployed as a stand-alone component. It will be implemented as a distributed storage system to address both performance (load balancing) and security (data separation). Advanced database encryption technologies with multi-key decryption facilities (to defend against “single” insiders) will be employed. The middleware described next will manage authorisation-based access to the data and, for improved security, to further authorise and control access to the network management interfaces.
- Design of a privacy-aware back-end middleware – A highly innovative privacy-centric role-based access control middleware specifically tailored for network monitoring infrastructures will be designed. The middleware will incorporate a formal and machine readable representation of policy rules that originate from a semantic description of the monitoring application operation and purpose, of the data types, of the entities and subjects involved, and of the privacy legislation provisions. The policies will be matched against the specific context to take decisions (access to the data, application of the most appropriate anonymisation mechanism, application of a filtering/processing operation on the data, triggering of the front end data protection reversion process, etc).
- Regulatory compliancy – The middleware policies will ensure that the processing of data gathered through monitoring will be carried out in line with the set of rules and limitations provided by data protection legislation2. The ability to revert (in well specified and controlled cases) the front-end data protection mechanisms will further ensure enforceability of legislation aimed at guaranteeing security of citizens and states (for example lawful interception and data retention).
- Innovative approaches to privacy-respectful monitoring application design – The interest in monitoring applications reside in their results. While these may not bring about any privacy issue, their need to access a data trace does. The project will address the challenge of externalizing (out-sourcing) monitoring applications without privacy concerns. The availability of customisable data processing functionalities embedded in the back-end allows an external monitoring application to use these internal processing primitives as intermediaries for accessing the data. This new approach will be tested by adapting selected monitoring applications to operate in this manner.
- Integrated trial – The privacy-protective monitoring technologies developed in the project will be integrated and evaluated in a complete trial, involving all the system architecture components.
1) This is demonstrated by the current massive contribution of two project partners, namely Hitachi and Fraunhofer FOKUS, to the IPFIX standardisation activities (see http://www.ietf.org/html.charters/ipfix-charter.html). To the date of writing, of eight currently developing Internet Drafts elected by the IPFIX work-group, four are co-authored by key personnel explicitly mentioned in the partner description forms. Specifically, Elisa Boschi and Lutz Mark are co-authors for i) “IPFIX Implementation Guidelines” and ii) “Reducing Redundancy in IPFIX and PSAMP Reports”. Elisa Boschi is co-author of iii) “Bidirectional Flow Export using IPFIX” and iv) “IPFIX Applicability” (whose first author is Tanja Zseby, which although not explicitly mentioned as key personnel, is indeed affiliated to the FHG group that is participating to PRISM). In addition, v) Mark Lutz (FHG) technically reviewed the “Specification of the IPFIX Protocol for the Exchange of IP Traffic Flow Information” internet draft;
2) This is a significant strategic step, as compliance with data protection legislation in the field of communications traffic monitoring is an issue that has been frequently neglected up to now (and definitely not in favour of the individual’s right to privacy, as user data is typically acquired in “raw” form by monitoring applications, and user is usually not made aware of said gathering).