INDECT Deliverable D8.1 v20120116

European Seventh Framework Programme FP7-218086-Collaborative Project
Specification of Requirements for Security and Confidentiality of the System (D8.1)
The INDECT Consortium AGH University of Science and Technology, AGH, Poland Gdansk University of Technology, GUT, Poland InnoTec DATA GmbH & Co. KG, INNOTEC, Germany IP Grenoble (Ensimag), INP, France MSWiA1 - General Headquarters of Police (Polish Police), GHP, Poland Moviquity, MOVIQUITY, Spain Products and Systems of Information Technology, PSI, Germany Police Service of Northern Ireland, PSNI, United Kingdom Poznan University of Technology, PUT, Poland Universidad Carlos III de Madrid, UC3M, Spain Technical University of Sofia, TU-SOFIA, Bulgaria University of Wuppertal, BUW, Germany University of York, UoY, Great Britain Technical University of Ostrava, VSB, Czech Republic Technical University of Kosice, TUKE, Slovakia X-Art Pro Division G.m.b.H., X-art, Austria Fachhochschule Technikum Wien, FHTW, Austria
Copyright 2009-2012, the Members of the INDECT Consortium

1
MSWiA (Ministerstwo Spraw Wewntrznych i Administracji) Ministry of Interior Affairs and Administration. Polish Police is dependent on the Ministry
D8.1 Specification of Requirements for Security and Confidentiality of the System
INDECT Consortium www.indect-project.eu
Document Information
Contract Number Deliverable name Deliverable number Editor(s) 218086 Specification of Requirements for Security and Confidentiality of the System D8.1 Manuel Uruea (UC3M) Andrzej Ciarkowski (GUT) Jacek Dajda(AGH) Jos A. Hernndez (UC3M) Pawe Korus (AGH) Petr Machnk (VSB) Gema Maestro (MOV) Author(s) Mara J. Martnez (MOV) Marcin Niemiec (AGH) Ralph Roche (PSNI) Nikolai Stoianov (TUS) Pavel Svoboda (VSB) Manuel Uruea (UC3M) Plamen Vichev (TUS) Katarzyna Wasilewska (GHP) Jan Derkacz (AGH) Reviewer(s) David Larrabeiti (UC3M) Nikolai Stoianov (TUS) Ethics Board Reviewers Dissemination level Contractual date of delivery Delivery date Status Keywords Helen Petrie Plamen Vichev Public M12 December 23rd 2009 Revised (v12-20120116) Security, Privacy, Requisites, Requirements, WP8
This project is funded under 7 Framework Program

INDECT_Deliverable_D8.1_v12_revised version_CMS - Public 2/110
th
Table of Contents
1 2 3
Executive Summary ........................................................................................................ 7 Introduction ....................................................................................................................... 9 2.1 3.1 3.2 3.3 3.4 3.5 3.6 3.7 Structure of this document..................................................................................... 11 European Convention on Human Rights (ECHR) ............................................. 15 Directive 95/46/EC .................................................................................................. 17 Directive 97/66/EC .................................................................................................. 22 Directive 2002/58/EC ............................................................................................. 24 Directive 2006/24/EC ............................................................................................. 26 The Oviedo Convention ......................................................................................... 28 United Nation Convention on the Rights of the Child ........................................ 28 List of General Security and Privacy Requisites ................................................ 36 List of Information Confidentiality Levels ............................................................ 36 Intelligent Monitoring System (WP1) ................................................................... 39 General-purpose secure communication ..................................................... 39 Secure multimedia communication ............................................................... 41 Data storage ..................................................................................................... 42 List of Security and Privacy Requisites ........................................................ 42 Description of components............................................................................. 44 Security issues ................................................................................................. 44 List of Security and Privacy Requisites ........................................................ 45 Security issues ................................................................................................. 46 List of Security and Privacy Requisites ........................................................ 47 Security issues ................................................................................................. 48 Solutions ........................................................................................................... 50 List of Security and Privacy Requisites ........................................................ 51 Watermarking techniques............................................................................... 52 Requirements with respect to watermarking ............................................... 53 List of Security and Privacy Requisites ........................................................ 54
3/110
European Legal Framework for Security and Privacy ............................................. 15
General Security Requirements for Police Information Systems ........................... 31 4.1 4.2
Security and Privacy Requisites for INDECT Subsystems ..................................... 39 5.1 5.1.1 5.1.2 5.1.3 5.1.4 5.2 5.2.1 5.2.2 5.2.3 5.3 5.3.1 5.3.2 5.4 5.4.1 5.4.2 5.4.3 5.5 5.5.1 5.5.2 5.5.3
Mobile Urban Observation System (WP2) .......................................................... 44
INDECT-MAS (WP3) .............................................................................................. 46
Web-based crime detection (WP4) ...................................................................... 48
Watermarking (WP5) .............................................................................................. 52
INDECT_Deliverable_D8.1_v12_revised version_CMS - Public
5.6
Crisis Management Portal (WP6) ......................................................................... 55 Overview ........................................................................................................... 55 Security in Internet Protocol Suite................................................................. 57 EDI Electronic Data Interchange: Security mechanisms .......................... 58 Access control for INDECT PORTAL ........................................................... 59 Other threats to the Web Portal: ................................................................... 61 List of Security and Privacy Requisites ........................................................ 61 Biometrics ......................................................................................................... 63 Secure Wireless Communications ................................................................ 64 Security of IEEE 802.11 protocols ................................................................ 64 Security in GSM/GPRS/UMTS ...................................................................... 67 List of Security and Privacy Requisites ........................................................ 70
5.6.1 5.6.2 5.6.3 5.6.4 5.6.5 5.6.6 5.7 5.7.1 5.7.2 5.7.3 5.7.4 5.7.5 6 6.1
Biometrics and Wireless Security (WP7) ............................................................ 63
Security and Privacy Requirements for INDECT Security Technologies ............. 71 Virtual Private Networks (VPN) (T8.1) ................................................................. 71 General description of a VPN ........................................................................ 71 VPN Components ............................................................................................ 71 VPN Technologies ........................................................................................... 73 Choosing a suitable VPN ............................................................................... 74 List of Security and Privacy Requirements .................................................. 75 Basic cryptographic algorithms definitions .................................................. 77 Symmetric ciphers ........................................................................................... 77 Asymmetric ciphers ......................................................................................... 79 Key management............................................................................................. 80 List of Security and Privacy Requirements .................................................. 82 System requirements ...................................................................................... 84 End-user requirements ................................................................................... 85 List of Security and Privacy Requirements .................................................. 87 List of Security and Privacy Requirements .................................................. 90 Ad-hoc Security................................................................................................ 93 List of Security and Privacy Requirements .................................................. 95 6.1.1 6.1.2 6.1.3 6.1.4 6.1.5 6.2 6.2.1 6.2.2 6.2.3 6.2.4 6.2.1 6.3 6.3.1 6.3.2 6.3.3 6.4 6.5 6.4.1 6.5.1 6.5.2
Cryptographic Algorithms (T8.2)........................................................................... 77
Quantum Cryptography (T8.3) .............................................................................. 83
Federated Identity Management (T8.4) ............................................................... 88 Mobile Security (T8.5) ............................................................................................ 92
Ethical Issues ................................................................................................................. 97 7.1 7.2 Data security in Europe .......................................................................................... 97 Supervising and consulting bodies ...................................................................... 98
4/110
7.2.1 7.2.2 7.2.3 7.3 8
Ethics Board of INDECT ................................................................................. 98 European Data Protection Supervisor .......................................................... 98 Country data-protection authorities............................................................... 98
Future development: Data protection after Lisbon Treaty ................................ 99
Conclusions .................................................................................................................. 101
References ........................................................................................................................... 103 Glossary of Security & Privacy Terms .............................................................................. 107 Document Updates.............................................................................................................. 109
5/110
(This page is intentionally left blank)
6/110
1 Executive Summary
INDECT: "Intelligent information system supporting observation, searching and detection for security of citizens in urban environment" is a Collaborative Research Project funded by the EU 7th Framework Program. Its main aim is to develop costefficient tools for helping European Police services to enforce the law and guarantee the protection of European citizens. These tools must comply with both country-level laws as well as European-level directives including, among many others, the European Declaration on Human Rights. This document defines the general Security and Confidentiality requisites of all systems and tools that will be developed by the Work Packages of the INDECT project. In particular, it specifies the requirements of the security technologies -either developed in the project or adopted from standards- to be employed by Work Package 8. This WP defines and supervises the security and confidentiality of the overall INDECT project and develops new security mechanisms to further enhance it. The system requirements defined by this document are based on both, general ICT security standards (ITU-T X.800 and ISO/IEC 27000 series), as well as requisites specific to Police systems that have been gathered from INDECT end users. All these requirements do not only consider the high-security requisites of Police forces, but they also take into account the potential implications of these new tools on the privacy of European citizens. Therefore these requirements may be considered as the guidelines to develop secure systems and tools that comply with the stringent security requirements and procedures of Police forces. Moreover, they also include safeguards to prevent these tools to be abused and employed for unauthorized uses without the mandatory warrants defined by the applicable laws.
7/110
8/110
2 Introduction
This document is the first deliverable of the Work Package 8 of the INDECT (Intelligent Information System Supporting Observation, Searching and Detection for Security of Citizens in Urban Environment) collaborative research project. It reviews the work carried out by this work package during first year of the project. WP8 oversees the Security and Confidentiality of the overall INDECT project and addresses specific security technologies to make them progress beyond the current state of the art. This deliverable provides a compendium of the general security and privacy requisites of all subsystems and tools to be developed by the INDECT project in the following years. In particular it defines the specific requirements for the security technologies that will be employed by WP8 to enhance the security of the INDECT subsystems and tools. Although we consider that employing standard and wellstudied security technologies must be one of our main design rules when addressing security, WP8 will also research and develop novel security mechanisms such as new cryptographic algorithms and will study the application of quantum cryptography for the interconnection of highsecurity systems. Most of the systems developed in INDECT are Information and Communication Technology (ICT) applications. Therefore the requirements defined by WP8 are based on best security practices for ICT systems (i.e. ITU-T X80.5, ISO/IEC 27000 series). They have been defined after analysing the initial documentation of INDECT work packages descriptions and after reviewing the preliminary work reported in all the WPs. Since the detailed specificities of each INDECT application are not yet fully specified at this stage, these requirements specification should be considered a working document to be continuously reviewed during the project lifetime, and a final version needs to be included in the final deliverable in order to properly assess the level of fulfilment accomplished by the project. Another important step in the process has been the capture of Users requisites. In particular, the Users Questionnaire [1], sent to potential end-users of the INDECT subsystems (i.e. Police officers, IT system administrators, team leaders, and video surveillance system operators) included a specific Security Section. By means of this questionnaire we were able to identify the most relevant issues for end-users. For instance, in the first question, users were requested to rate the relative importance of different aspects of a communications system: Security (system and data are secure). Performance (quick access to data). Cost (cost of the system). Universality (can be deployed in different environments). Reliability (high availability of the system). Ease of use (does not require technical knowledge). We collected answers to this question from 318 prospective users. The mean importance of each requirement from 5 to 1, where 5 means the most important and 1 means the least important are presented in Figure 1.1.
9/110
Figure 1.1: Mean importance of general requirements from Users Questionnaire.
According to end-users answers, security is the most important feature of a networked Police information system. After security, the users highlight the interest of performance and of reliability, which usually also depends on the security level of the system. Universality and ease of use are deemed less relevant. Finally, the low qualification of cost reveals the fact that end users are not generally affected by cost, and that the investment required to achieve the previous features is necessary even if it is very high. Even though most of the detailed technical requirements of Police Users cannot be disclosed in a public deliverable like D8.1, it is still possible to draw some interesting general conclusions to feed the definition of requirements. As described, the survey shows that the Police is deeply concerned about security, thus it is interested in keeping improving its security mechanisms and procedures with state-of-the-art security technologies, such as employing a Public Key Infrastructure (PKI) to deploy Smart Cards, or using biometrics and other advanced authentication mechanisms. For security reasons, confidential information is most of the time tied to specific terminals, and it cannot ever leave the Police headquarters. All these measures are easily understandable, although they could limit the effectiveness of Police officers on the streets. Therefore here lies a great challenge for security research: being able to build secure mobile terminals that are able to access to certain confidential information (e.g. daily briefing, car plate ids, etc) anytime and anywhere, in order to help Police officers to be more effective in their daily work, while preserving the same levels of control achieved in the headquarters. Moreover, in order to avoid information leaking, the Police have strict procedures on how information can be shared with other security forces. These procedures could also limit joint crime investigation efforts among different agencies. Thus improving the procedures for information sharing without putting security at risk could become a very useful research line, where Watermarking and Federated ID technologies should be further developed and exploited.
10/110
2.1 Structure of this document

Chapters 1 and 2 provide an overview of the objectives, rationale and structure of this document. Chapter 1 is a one-page executive summary that provides a high level overview of this deliverable to quickly understand its scope and its contents. Chapter 2 is a longer introduction to the matters discussed in this document and its rationale after the security requisites captured by Users Questionnaire and End user reports. Chapter 3 provides an overview of the European conventions and directives that define the exercise of law enforcement, as well as the rights of European citizens that may be affected by those. Therefore this chapter summarizes the legal framework that regulates European Police forces. Chapter 4 defines the common security and privacy requirements of all subsystems and tools developed by the INDECT project. These IT system requirements are needed in order to comply with, and even enhance, the stringent security requirements of Police forces. The requirements and best practices contained in this chapter are based on security standards, such as ITU-T X.800 and ISO/IEC 27000 series, and thus they are quite general, in the sense that they could be applied to any high-security IT system. The specific security and privacy requirements of INDECT subsystems and tools are detailed in the following chapters. Chapter 5 specifies the security and privacy requirements that are specific of the different Work Packages that make up the INDECT project, and they are not covered in the previous Chapter. In particular, chapter 5 contains one section per each INDECT work package excluding: WP0 -the administrative WP-, -WP9 the implementation WP-, and WP8 -which is covered by next chapter-. Thus, all the sections of chapter 5 are: Section 5.1 defines the security requisites of WP1 Intelligent Monitoring and Automatic Detection of Threats. This Work Package deals with the capture, transmission and processing of video and audio streams to detect emergency or crime-related events. For instance the detection of abnormal events like an unattended luggage at an airport or identifying a shooting sound. Section 5.2 analyses the requirements of WP2 Identification and Observation of Mobile Objects in Urban Environment, which is focused on identifying and tracking mobile objects, such as a car leaving a crime-scene. Section 5.3 specifies the security requirements of WP3 Intelligent integrated agent-based system supporting observation, analysis and detection of criminal activities and threats in complex real-virtual environments, which aims to extend the law enforcement task of Police to the cyberspace, including wiretapping the Internet access of a particular suspect, or monitoring web sites where criminal activities take place, such as exchanging paedophilic photographs. Section 5.4 defines the privacy requirements of WP4 Extraction of Information for Crime Prevention by Combining Web Derived Knowledge and Unstructured Data, which applies Artificial Intelligence techniques to infer
entities and relationships from public web information or other unstructured data, for instance to identify the accomplices of known criminals. Section 5.5 deals with the watermarking technologies to be developed by WP5 Search Engine for Fast Detection of Person and Documents Based on Watermarking and Agent Technology and how they can be applied as an audit mechanism and privacy safeguard for Police systems. Section 5.6 specifies the security requirements of the INDECT portal defined by WP6 Interactive Multimedia Applications Portal for Intelligent Observation System that acts as a single entry point and interface for most INDECT subsystems and tools. Section 5.7 is focused on the security of Biometric and Wireless transmission technologies developed by WP7 Biometrics and Intelligent Methods for Extraction and Supplying Security Information and its applicability to authorisation and to identify known criminals from media streams. Chapter 6 specifies the detailed requirements of WP8 Security and Privacy Management, which overviews the security and privacy of the overall INDECT project. In particular defines the requisites of the different security technologies that are going to be employed, and even developed, by WP8 tasks: Section 6.1 Virtual Private Networks (VPN) is part of the T8.1 task, and is focused on the secure communication among INDECT subsystems and users by means of VPNs. It reviews the state-of-the art of this technology, and the different security requisites fulfilled by the different kinds of VPNs. This way it will be possible to choose the appropriate VPN technology for each particular communication scenario that appears within INDECT project. Section 6.2 Cryptographic Algorithms defines the security requirements of task T8.2, which aims to develop a new family of cryptographic algorithms based on S-Boxes, and to evaluate its applicability to the security forces environment. Moreover, Section 6.2 provides an overview of the different cryptographic algorithms existing today, in order to understand where they should be employed within the INDECT project. Section 6.3 Quantum Cryptography describes the main requirements of task T8.3, which proposes the usage of quantum cryptography technologies for securely exchanging information among top-security Police systems. These communications require an unbreakable channel that cannot be attacked by an eavesdropper, even when the opponent is a rival intelligence agency or other security force from an enemy country. Section 6.4 Federated Identity Management describes the security requirements of the Federated ID systems to be developed by task T8.4. Federated ID could be very useful in order to solve the authentication problem of interconnecting different Police subsystems from different departments of a single organization, or even among different regional or local Police forces. The standard solution proposed by OASIS and Liberty Alliance is analyzed as a candidate for the INDECT Federated ID subsystem. Section 6.5 Mobile Security is focused on the secure communication of mobile INDECT users by means of Ad-hoc networks provided by Task T8.5.
These autonomous self-organising networks have special security requirements and are still an area of research, but can be very useful for Police officers in the field and first emergency responders, or as an alternative communications channel when the fixed infrastructure is not available or it has been damaged by a catastrophe. Chapter 7 summarizes the Ethical Issues that could be raised because of the usage of INDECT tools and systems. Moreover, it analyzes whether those issues could be solved by the specified technical means, or they require additional procedures and mechanisms before being deployed. Chapter 8 provides a summary of the major requirements and novel objectives proposed through this deliverable. Finally, the References and the Glossary of security terms employed through this document are included at the end of this document.
13/110
14/110
3 European Legal Framework for Security and Privacy

This chapter reviews the most significant EU directives and conventions that regulate the research work and the subsystems developed by INDECT project. Each section details one convention or directive, including the most important articles, and concludes with some thoughts about how it may affect the research carried out by the INDECT project. European conventions and directives regulate but also motivate INDECT project. For instance the second article Right to life of the European Convention on Human Rights defines the role of the Police as to protect the life of European citizens. Therefore the legal framework presented in this chapter is essential in order to understand the purpose and scope of the INDECT project. In particular, all INDECT subsystems and tools MUST comply with all the European and international regulations and applicable national laws, both, during the research phase (e.g. informed consent of individuals participating in INDECT tests), and specially when deploying and operating INDECT systems.
3.1 European Convention on Human Rights (ECHR)

The Convention for the Protection of Human Rights and Fundamental Freedoms [37] has been signed by all European Union members and it must be signed by every future member. The articles of ECHR are quite broad and could be interpreted and applied in many ways. In this section we will focus its applicability to Police procedures and systems. Art. 2 Right to life - Everyone's right to life shall be protected by law. Limits the usage of violence to certain cases, and only when is absolutely necessary. Art. 3 - Prohibition of torture It also applies to inhuman treatment or punishment. Art. 5 - Right to liberty and security - No one shall be deprived of his liberty unless in accordance with a procedure prescribed by law: when convicted or when waiting for a trial. This article regulates the arrest procedures of European Police forces. Art. 6 Right to a fair trial This article applies to criminal law cases and includes fundamental rights such as the presumption of innocence. It regulates some aspects of Police investigations such as to guarantee the chain of custody of evidences related to a case. This must be also guaranteed in the case of electronic records. Furthermore, the right to examine the evidences against you requires Police to separate information about cases in different confidentiality levels. Art. 7 Retrospectivity No one may be punished by an act that was not against the law at the time of its commission. Therefore, it is essential to determine the time and date of any information that can be employed as an evidence. Moreover, information should not be kept indefinitely and shall be destroyed unless there is a legal reason to not do so. Art. 8 Right to respect for private life and family The privacy of the private life, home and correspondence is a fundamental right, and shall not be interfered by a
public authority unless it is strictly necessary in a democratic society. Therefore Police must have a justified motivation and clear procedures when to interfere with private life of one suspect. Art. 9 Freedom of thought, conscience and religion This article limits the personal information that can be obtained or filed under a criminal investigation. Art. 10 Freedom of expression One of the restrictions to the exercise of these freedoms is for preventing the disclosure of confidential information. Art. 11 - Freedom of assembly and association The recording of a peaceful assembly or obtaining information about the associates of some person may interfere with this right, unless these associations are not in accordance with law (e.g. a terrorist or criminal group). Art. 12 The prohibition of discrimination by sex, race, colour, language, religion or other criteria should limit the gathered information in order to avoid it to be employed later for any kind of discrimination. Art. 15 and 18 Define some limitations to the other rights, only for the purpose for which they are provided (e.g. arrest of a suspect) and derogate them in very special circumstances like a war or public emergencies.
Conclusions
Article 8 is the most interesting one from the INDECT project, since it covers the right of privacy of European Citizens. However most of the articles of ECHR must be also taken into consideration when designing which information could be gather, for how long and with what purpose, taking always into account its proportionality. Some articles specify some exceptions where some of part of the described rights may not fully apply. In case of Art. 8, this must be in accordance with the law and only when necessary in a democratic society in the interests of national security, public safety or the economic well-being of the country, for the prevention of disorder or crime, for the protection of health or morals, or for the protection of the rights and freedoms of others. Police investigation in general, and INDECT project in particular, may fall under some of these exceptions. However this does not mean that INDECT project can ignore this Right to Privacy. On the contrary, a great care must be put since interfering with the privacy of EU citizens should be one of the last resorts of Police forces, only when it is clearly justified and proportionally to the mischief. The European Convention of Human Rights only defines general rights that can have a broad interpretation and could be applicable to many situations. For this reason, in the remaining of this chapter we will focus on the directives that regulate specific activities, such as information processing or the privacy of electronic communications.
16/110
3.2 Directive 95/46/EC

Directive 95/46/EC - Protection of individuals with regard to the processing of personal data and on the free movement of such data [38]: Data-processing systems must balance the need to protect the interests and privacy of the individual with economic and social progress and trade expansion. Personal data should be able to flow freely between states, but safeguard the fundamental rights of individuals, particularly under Art. 8 of the European Convention on Human Rights. Once protection is standardised following the approximation of national laws, States cannot inhibit the free movement of personal data on grounds of protecting rights and freedoms of individuals, and in particular the right to privacy. This directive doesnt apply to processing of audiovisual data (e.g. video surveillance) if carried out for public security, defence, national security or State activities relating to criminal law or other activities not within the scope of Community law. The fact that the processing of data is carried out by a person established in a third country does not affect the protection of individuals, and data processing should be governed by the law of the State in which the means used are located, and there should be guarantees to ensure that the rights and obligations are respected in practice. Protection principles do not apply where data is anonymised, as opposed to merely coded. Processing of personal data must be carried out: i) with the consent of the data subject or be necessary for the conclusion or performance of a contract binding on the data subject; or ii) as a legal requirement; or iii) for the performance of a task carried out in the public interest or in the exercise of official authority; or iv) in the legitimate interests of a natural or legal person, provided that the interests or the rights and freedoms of the data subject are not overriding. Right of access to data relating to him which are being processed to verify in particular the accuracy of the data and the lawfulness of the processing. Right to know the logic involved in the automatic processing of data concerning him, at least in the case of the automated decisions, without adversely affecting trade secrets or intellectual property and in particular the copyright protecting the software. However, the data subject cannot be refused all information. When personal data is transmitted by a telecommunications or email service, the controller of the personal data in the message (and not the person offering the transmission service) will normally be considered to be the person from whom the message originates.
Exemptions from the obligation to notify may be provided for by Member States where processing is unlikely adversely to affect the rights and freedoms of data subjects, provided that it is in accordance with a measure taken by a State specifying its limits. This directive applies to both, public and non-public telecommunications systems. Art. 2 - Processing means "any operation or set of operations which is performed upon personal data, whether or not by automatic means, such as collection, recording, organization, storage, adaptation or alteration, retrieval, consultation, use, disclosure by transmission, dissemination or otherwise making available, alignment or combination, blocking, erasure or destruction". Art. 3 Directive applies to processing of personal data wholly or partly by automatic or non-automatic means if data is part of filing system, but doesnt apply to public security, defence, State security (including the economic well-being of the State when the processing operation relates to State security matters) and the activities of the State in areas of criminal law, or in a purely personal or household activity. Art. 4 Where national law is applicable: Where the controller is established in the states territory If national law applicable by virtue of international public law Controller not within the EC but uses equipment situated in a member state Art. 6 - Data controller must ensure that data is: Processed fairly and lawfully. Collected for specified, explicit and legitimate purposes, but further processing of data for historical, statistical or scientific purposes is not incompatible, provided there are appropriate safeguards. Adequate, relevant and not excessive for the purpose. Accurate and up to date. Kept in a form permitting identification of subjects for no longer than necessary. Art. 7 Requirements for processing: Data subject unambiguously consented; or Processing necessary for performance of contract made with subject; or Processing necessary for legal obligation; or Processing necessary to protect vital interests of subject; or Processing necessary for public interest or in exercise of official authority; or Necessary for pursuit of controllers legitimate interests, unless the subjects rights override.
18/110
Art. 8 Processing special categories of data: Prohibit processing of personal data on racial/ethnic origin, political opinions, religious or philosophical beliefs, trade-union membership, or data on health or sex life, unless: Subject explicitly consents; or Processing necessary for controllers rights and obligations in employment law; or Processing necessary for vital interests of subject; or Processing carried out in course of legitimate activities with appropriate guarantees by foundation, association or non-profit body if processing relates to members of the body or those closely associated with it; or Data made public by data subject or necessary for a legal claim. Processing data relating to offences, criminal convictions or security measures may be carried out only under the control of official authority, or if suitable safeguards provided under national law, subject to derogations. Art. 10 If data collected from subject himself, controller must give: Identity of controller and his representative; and Purposes of data processing; and Any possible recipients of data; and Whether responses are obligatory or voluntary; and Existence of right to access and rectify data. Art. 11 Where data not obtained from subject, controller must give Art.10 information to the subject as soon as data recorded or disclosure to third party is envisaged, unless subject already has the information. N.B. doesnt apply where providing information would be impossible, would involve disproportionate effort or if condoned by law, especially in historical, scientific or statistical research. Art. 12 Right of access to data: Confirmation as to processing and purposes, and any recipients of data. Communication in an intelligible form of data being processed. Knowledge of logic of automatic processing. Rectification, erasure of blocking of data which doesnt comply with directive. Art. 13 National legislative measures to restrict rights for reasons relating to national security, defence, public security, criminal processes, breaches of ethics for regulated professions, state economic or financial interests, exercise of official authority, protection of data subject.
19/110
Where data doesnt impact on particular individual and no risk of breaching subjects privacy, states may restrict Art.12 rights by legislative instruments, where data is processed purely for scientific research. Art. 14 Subjects right to object on request and free of charge on compelling legitimate grounds, save where otherwise provided by national legislation, especially where controller anticipates purposes of direct marketing. Art. 15 Everyone has the right not to be subject to a decision with legal effects based solely on automated data processing intended to evaluate personal aspects of him. Art. 16 Those with access to data must not process except on instructions from the controller. Art. 17 Security of processing - Controller must implement technical/organisational measures to protect data against accidental or unlawful destruction, loss, alteration, unauthorised disclosure or access. Controller must choose processor with sufficient guarantees on technical security and organizational measures. Art. 18 Controllers obligation to notify a supervisory authority before any automatic processing operation, unless States provide an exemption and controller provides a personal data protection official. States may stipulate that non-automatic processing of personal data shall be also notified. Art. 19 Art.18 notification should include: Name and address of controller and representative. Purpose of processing. Description of categories of data subjects and data. Possible recipients. Possible transfers of data to third countries. General description allows assessment of Art.17 measures. Art. 20 Processing operations should be assessed and checked by the supervisory authority before the start of processing. Art. 21 Processing operations should be publicised on a register of Art.18 notifications maintained. Art. 22 Breach of rights in processing will incur liability subject to a judicial remedy. Art. 23 Compensation for those damaged by breaches of the directive or approximated national laws, but the controller may be exempted from liability if proven that he is not responsible for the damage.
20/110
Art. 25 Transfer to states outside the EC (third countries) Need to ensure adequate protection in third country, assessed in light of all circumstances surrounding data transfer operations. States must inform each other if they consider that a third country doesnt ensure adequate protection, and ensure protection for the data itself. Art. 26 Derogations from Art.25, data transfer to third countries without adequate protection will be acceptable if: Subject consented unambiguously to transfer. Transfer necessary for performance of a contract in data subjects interest. Transfer necessary for public interest or a legal claim. Transfer necessary to protect vital interest of data subject. Transfer made from a register intended to provide information to the public. Authorised by the state and the controller adduces adequate safeguards. Art. 27 Codes of conduct are encouraged. Art. 28 Supervisory authorities shall be chosen by member states, and shall have investigative powers, powers of intervention and powers to engage in legal proceedings Art. 31 - Member States may provide that processing data already held in manual filing systems on the entry into force of the national provisions shall be brought into conformity with Articles 6, 7 and 8. Data subject has the right to obtain rectification, erasure or blocking of data which are incomplete, inaccurate or stored in a way incompatible with the controllers legitimate purposes. Member States may provide, subject to safeguards, that data kept for the sole purpose of historical research need not be brought into conformity with Articles 6, 7 and 8.
Conclusions
This is the most pertinent directive for INDECT project. It has already been implemented in the UK in the Data Protection Act 1998, and in Poland by the Act of August 29, 1997 on the Protection of Personal Data. It forms the basis of all the other data protection directives in this chapter. Art. 7-8 list the requirements that must be met for personal data to be lawfully processed across the whole of the EU. The INDECT Ethics Board will need to ensure that the data is sufficiently protected under EU and national law, and that the subjects of any data have the right to access the data and request amendments to it. There must be a supervisory authority to receive the Art.18 notifications in the case of the UK, this will be the Information Commissioner. The Ethics committee should be aware that if any data is transferred outside the EU in regards to the project, the controllers of the data (i.e. those leading the project, who are tasked with processing the data) will need to put extra measures in place to safeguard the data once it is transferred.
Proportionality is a key principle, and the data must only be used for limited purposes, in a limited and restricted fashion with appropriate safeguards regarding anonymity. The directive shows a more flexible approach towards data processing for scientific research, but the rights of the data subjects are still paramount. Irreversibly anonymising all personal data in the research could ensure compliance with this directive. The directive only applies to natural persons i.e. not companies/corporations. It is worth bearing in mind that the safeguards and controls set up in the directive are to facilitate the main aim of the directive to ease the free flow of data throughout the EU. Article 15 clearly specifies that automatic processing solely must not lead to actions with legal implications. Therefore all INDECT subsystems and tools that automatically process information are just helpers of Police officers or other human operators. Under no circumstances an alert or warning from an INDECT system must trigger any automatic action unless supervised and approved by the operator of the system. In summary, given that one of the main expected results of the INDECT project is the implementation of a distributed computer system that is capable of acquisition, storage and effective sharing on demand of the data as well as intelligent processing, this is a very important directive.

Directive 97/66/EC Processing of personal data and the protection of privacy in the telecommunications sector [39]: Confidentiality is guaranteed under the European Convention on Human Rights (ECHR). Specific requirements for personal data protection arise from new Integrated Services Digital Networks (ISDNs) and cross-border communications systems. States should co-operate in introducing and developing the protective technologies. In telecommunications, where this directive does not apply, Directive 95/46/EC will apply instead. Service providers must take appropriate security measures, if necessary in conjunction with the network provider, and inform subscribers of special risks of a security breach as assessed under Art.17 of Directive 95/46/EC. Relates largely to subscribers to telephone or internet services, and the processing of their personal data by the service providers. Art. 1 Ensuring protection of rights regarding personal telecommunications sector, complementing Directive 95/46/EC. data in the
Art. 3 Scope - processing personal data in connection with public telecommunications services in public telecommunications networks in the Community, in particular via the Integrated Services Digital Network (ISDN) and public digital mobile networks.
Art. 4 - Public telecommunications service providers must take appropriate technical and organisational security measures, if necessary in conjunction with the network provider. Having regard to the state of the art and the implementation cost, these measures shall ensure a level of security appropriate to the risk presented. Subscribers should be informed of any particular risk of security breach. Art. 5 Confidentiality of telecommunications services - Prohibit listening, tapping, storage or other kinds of interception or surveillance of communications, by others than users, without the consent of the users concerned, except when legally authorised. Art. 6 Traffic data on subscribers and users must be erased or made anonymous on termination of call. Processing of traffic and billing data must be restricted to persons acting under the authority of providers of the public telecommunications networks and/or services handling billing or traffic management, customer enquiries, fraud detection and marketing the provider's own telecommunications services. Art. 7 Customers can request non-itemised bills. Art. 8 Line identification Callers should have the right to withhold their line identification and to refuse caller identification. The public should be informed of the provision of caller identification made public. Art. 9 Exceptions to Art. 8 include storing data temporarily to trace malicious or nuisance calls or for organisations dealing with emergency services and law enforcement. Art. 10 Subscriber has right to stop automatic call forwarding. Art. 11 - Personal data contained in printed or electronic directories of subscribers available to the public or obtainable through directory enquiry services should be limited to what is necessary to identify a particular subscriber, unless the subscriber has given his unambiguous consent to the publication. Art. 12 Direct marketing unsolicited calls require the consent of the subscriber. Art. 13 - No mandatory requirements for specific technical features are imposed on terminal or other telecommunications equipment which could impede the placing of equipment on the market and the free circulation of such equipment. Art. 14 Rights under Art. 5, 6 and 8 can be restricted to safeguard national security, defence, public security, the prevention, investigation, detection and prosecution of criminal offences or of unauthorised use of the telecommunications system. Art. 15 Any national law implementations of this directive shall not be retrospective.
Conclusions
This directive complements the previous one, regularising data processing rules in the field of public telecommunications systems. Again, the basic principles of necessity and proportionality apply data should only be kept as long as necessary and it should not be excessive for the purpose for which it is being processed. Art. 5
and 6 are the most important restrictions on the controllers rights to process the data, but Art.14 restrictions are pertinent to INDECT project. Any data gathered from others searches performed on search engines may engage this directive.

Directive 2002/58/EC Privacy and electronic communications [40]: Furthers the protection of Art. 7 and 8 rights of the ECHR and confidentiality of communications. Any issue of protection of rights and freedoms not covered by this directive will be picked up by Directive 95/46/EC. Directive doesnt interfere with the states right to undertake lawful interceptions. A communication may include any naming, numbering or addressing information provided by the sender or the user of a connection to carry out the communication. Traffic data may include any translation of this information by the network over which the communication is transmitted. Traffic data may consist of data referring to routing, duration, time or volume of a communication, to the protocol used, to the location of the terminal equipment of the sender or recipient, to the network on which the communication originates or terminates, to the beginning, end or duration of a connection. Prohibition of storage of communications and traffic data by persons other than the users or without their consent doesnt prohibit any automatic, intermediate and transient storage of this information for the sole purpose of carrying out the transmission, so long as it is only stored for as long as necessary for transmission and traffic management purposes. Regarding cookies, it must ensure that users are made aware of information being placed on the terminal equipment they are using. Users should have the opportunity to refuse to have a cookie or similar device stored on their terminal equipment. Obligation to erase/anonymise traffic data when it is no longer needed to transmit a communication does not conflict with such procedures on the Internet as the caching in the domain name system of IP addresses or the caching of IP addresses to physical address bindings or the use of log-in information. Obligation to inform subscribers of the purpose(s) of public directories in which their personal data are to be included on the party collecting the data for such inclusion. Where the data may be transmitted to third parties, the subscriber should be informed of the recipients. Any transmission should be subject to the condition that the data may not be used for other purposes than those for which they were collected. Safeguards should be provided for subscribers against intrusion of their privacy by unsolicited communications for direct marketing purposes in particular by means of automated calling machines, telefaxes, and e-mails, including SMS messages. Prohibit the use of false identities or false return addresses or numbers while sending unsolicited messages for direct marketing purposes. Art. 3 The directive applies to publicly available electronic communications services.
Art. 4 Provider of the service must take appropriate technical and organisational measures to safeguard security, and inform subscribers of any particular risk. Art. 5 Communications and traffic data should be confidential, prohibiting tapping, listening, storage, interception or surveillance of communications and traffic data without consent, except when legally authorised. Art. 6 Traffic data on subscribers and users processed and stored by the network/service providers must be erased or anonymised when no longer needed for the transmission of the communication. Data processed for marketing can only be kept for the duration necessary for such services with the users consent, which can be withdrawn at any time. Users must be informed of the type of data processed and the duration of processing. Art. 7 Right to non-itemised billing. Art. 8 Users/subscribers have right to prevent calling line identification and to reject calls where line identification has been prevented. Art. 9 Location data other than traffic data can only be processed if anonymised or with the informed consent of the users/subscribers, which can be withdrawn at any time. Even if consent has been obtained, the users/subscribers have the right to temporarily refuse processing for each connection to the network or data transmission. Only those acting under the authority of the provider can process the data. Art. 10 Transparent procedures if network/service providers wish to override the elimination of calling line identification for tracing malicious/nuisance calls or for dealing with recognised emergency calls. Art. 11 Subscribers have right to stop automatic call forwarding by a third party. Art. 12 Subscribers are informed of the purpose of a printed/electronic subscribers directory that is publicly available which may include personal data. Subscribers have the right to determine whether their data is included in the directory, the extent of inclusion, and to verify, correct or withdraw personal data. Art. 13 - Automatic calling machines fax or email for direct marketing may only be allowed if subscribers have given prior consent to that marketing, or the details have been bought by the marketer and the customer was informed of this when they gave their details. Cannot conceal or disguise identity of the sender of direct marketing email Art. 14 No mandatory requirements for specific technical features imposed on terminal communication equipment which could impede free circulation of equipment. Measures may be adopted to ensure that terminal equipment is constructed in a way that is compatible with the right of users to protect and control the use of their personal data Art. 15 Can restrict Art.5, 6, 8 and 9 to safeguard national security (i.e. State security), defence, public security, and the prevention, investigation, detection and prosecution of criminal offences or of unauthorised use of the electronic
communication system. N.B. doesnt apply to data specifically required by Directive 2006/24/EC Art. 16 Art.12 doesnt apply to directories already produced.
Conclusions
This directive could be pertinent to the research within INDECT project, as it relates again to the storage, processing and sharing of personal data acquired from a publicly available communications service. The rights of the data subject are paramount, and the data should be anonymised, proportionate in amount and detail to the purpose and only kept for as long as necessary. This directive has widened the scope of protection from merely telecommunications systems to all electronic communications systems. It is basically translating Directive 95/46/EC (protection of personal data) into specific rules for electronic communications systems. The issue of digital watermarks may overlap with the provisions on cookies.

Directive 2006/24/EC Retention of data generated or processed in connection with publicly available electronic communications networks, amending Directive 2002/58/EC [41]: Legal/technical differences between national legislative instruments on the retention of data by service providers for the prevention, investigation, detection, and prosecution of criminal offences present obstacles to the internal electronic communications market. Conclusions of the Justice and Home Affairs Council of 19 December 2002 underline that, because of the growth in the possibilities afforded by electronic communications, data relating to the use of electronic communications are particularly important and a valuable tool in the prevention, investigation, detection and prosecution of criminal offences, in particular organised crime and terrorism. Ensure at European level that data generated or processed by providers of public electronic communications services/network are retained for a certain period. Directive relates only to data generated/processed as a consequence of a communication, not to the content of the information communicated. Data should be retained in such a way as to avoid being retained more than once. Data generated or processed when supplying the services refers to accessible data. For data retention regarding e-mail and Internet telephony, the obligation to retain data may apply only in respect of data from the providers' or the network providers' own services. Art. 1 Applies to location and traffic data, and data to identify the subscriber/user. Ensure data available for the investigation, detection and prosecution of serious crime, as defined by each Member State in its national law Art. 3 Obligation to retain data, including unsuccessful call attempts where those data are generated or processed, and stored (as regards telephony data) or logged
(as regards Internet data). N.B. this is derogation from Art.5, 6 and 9 of the previous directive. Art. 4 - Ensure that data retained in accordance with this Directive are provided only to the competent national authorities in specific cases. Conditions to be fulfilled in order to gain access to retained data in accordance with necessity and proportionality requirements shall be defined by each Member State Art. 5 Data to be retained: Data necessary to trace and identify the source of a communication. Data necessary to identify the destination of the communication. Data necessary to identify the date, time and duration of a communication. Data necessary to identify the type of communication. Data necessary to identify users communication equipment. Art. 6 Data shall be retained for not less than six months and not more than two years from the date of the communication. Art. 7 Retained data shall be of the same quality and subject to the same protections as network data; data subject to appropriate technical/organisational measures to protect data against accidental/unlawful destruction, accidental loss or alteration, or unauthorised or unlawful storage, processing, access or disclosure; appropriate measures to ensure accessed by specially authorised personnel only; data shall be destroyed at the end of period of retention. Art. 8 - Data retained and any other necessary information relating to such data can be transmitted upon request to the competent authorities without undue delay. Art. 9 - Designate one or more public authorities to be responsible for monitoring the application within its territory of the provisions. Art. 10 States to provide commission annually with retention statistics for data generated or processed in communication services/networks. Art. 12 States may extend maximum retention period in particular circumstances, and inform the Commission, who shall then adjudicate on the lawfulness of such measures. Art. 13 - Judicial remedies, liability and sanctions for breach. Art. 14 - Evaluation of the Directive application and impact on economic operators and consumers, taking into account developments in electronic communications technology and Art.10 statistics submitted by the Commission to the Parliament.
Conclusions
This Directive relates only to data generated/processed as a consequence of a communication, not to the content of the information communicated i.e. this directive does not cover intercepted data, but only relates to the information that would be collected by the service provider for the purpose of providing the service and the bill, as is expanded upon in Art.5.
If the INDECT project involves the storing of traffic or location data that does not include the actual content of emails or searches made, then this Directive will apply. Art. 6 on the retention period will need to be adhered to strictly, and the security measures to protect the retained data will need to be adequate for the purpose.
3.6 The Oviedo Convention

The European Convention on Human Rights and Biomedicine [42] (a.k.a. The Oviedo Convention) emphasises that the interests, welfare and rights of the individual prevail over the sole interest of society or science. Informed consent is required before any medical intervention by the subject or the legal representative if the subject is unable to consent, unless it is in an emergency situation. Everyone has the right to privacy regarding their health information and the right to access any health information stored about them Any discrimination against a person because of their genetic heritage is prohibited, as is any genome modification for eugenic purposes. Art. 15 - Scientific research in the field of biology and medicine shall be carried out freely, subject to the provisions of this Convention and the other legal provisions ensuring the protection of the human being. Art. 16 - Research on a person may only be undertaken if all the conditions are met: i. No alternative of comparable effectiveness to research on humans; ii. the risks are not disproportionate to the potential benefits of the research; iii. the research project has been approved by the competent body after independent examination of its scientific merit, including assessment of the importance of the aim of the research, and ethical review; iv. subjects have been informed of their rights and the legal safeguards; v. necessary consent given expressly, specifically and is documented. Such consent may be freely withdrawn at any time.
Conclusions
These are likely to be the most pertinent articles for the INDECT research if any biometric research involves human subjects. Again, the rights in this convention are subject to national security and crime prevention considerations. Most of the Work Packages will remain unaffected by this. It is only when biological material is involved that this convention will be engaged.
3.7 United Nation Convention on the Rights of the Child

The Convention on the Rights of the Child [43] obliges countries that have ratified the Convention to respect the rights of all minors under the age of 18 without discrimination. Where children are concerned, their best interests are paramount.
28/110
Art.5 - The rights, responsibilities and duties of parents/guardians/extended family are to be respected. Art. 6 + 8 - Children have right to life and to respect for identity and family relations. Right to respect for ideas and freedom of expression and association. Art. 16 - No child shall be subjected to arbitrary or unlawful interference with privacy, family, home or correspondence, or to unlawful attacks on his or her honour and reputation. Art. 19 States have an obligation to protect children from all forms of physical or mental violence, injury or abuse, neglect or negligent treatment, maltreatment or exploitation Art. 32 Right to be protected from economic exploitation and from performing any work that is likely to be hazardous or to interfere with the child's education, or to be harmful to the child's health or physical, mental, spiritual, moral or social development. Art. 36 Protect child against all forms of exploitation prejudicial to the childs welfare Art. 40 When a child infringes penal law, they must be treated in with respect for the child's sense of dignity and worth, reinforcing the child's respect for the human rights and fundamental freedoms of others. If considered to have infringed the penal law, to have this decision and any measures imposed in consequence thereof reviewed by a higher competent, independent and impartial authority or judicial body according to law. Respect for privacy at all stages of the proceedings. Importance of laws, procedures, authorities and institutions specifically applicable to children alleged as, accused of, or recognized as having infringed the penal law.
Conclusions
This directive just reiterates the need for special protective measures when dealing with children. Their welfare is paramount because they are unable to assert their own rights. Rather than imposing specific obligations relevant to the INDECT project, it should be viewed as laying out the principles to bear in mind when dealing with data concerning or studies involving children.
29/110
30/110
4 General Security Requirements for Police Information Systems

The main requirements and functions related to the Information security system defined in the initial documents issued on INDECT project are: - Specification of requirements and solutions for secure information transfer, storage and destruction. - Definition of rules and mechanisms to fulfil the requirements of privacy and civil liberties. - Definition of procedures and monitoring of access to confidential information. - Benchmarking of technological solutions capable to provide satisfactory level of security and privacy for the elaborated system. - Promotion and standardisation of the security network enhancements proposed and tested in the project at relevant standardisation forums, mainly ETSI and CEN/CENELEC. - Development of a Federated Identity management system specifically tailored to support the coordination of different departments and security forces. - Definition of the aspects of the information security and information protection. - Definition of the architectural framework of the security system. - Selection of the architectural approach for the whole systems development. - Definition of methods and means for end users, communication channels and data storage facilities protection. - Transparency for the users during the work with the elements of the system. - Use of EU approved mechanisms and standards incorporated in commercial off-the-shelf (COTS) products. This preliminary list of objectives is not structured and is not systematically presented. In this section we approach the security requirements from the global perspective of a system that may become a Police tool and under the light of relevant laws, standards and best current practices. Since INDECT is developing components that may potentially be integrated into a real Police information system, all INDECT subsystems should feature a number of general functions and protection schemes that are assumed to be present in a Police Information system in order to prevent structural security failures. Within such set of properties, especial attention deserves the distributed nature of most of the tools to be developed by INDECT (e.g. networked surveillance cameras, aircrafts) and, in some cases, the fact that INDECT software/hardware may be connected to the public Internet (e.g. crime detection agents). Therefore, we shall try to define general security requirements that rely on the set of security aspects identified by ISO/IEC 27000 and ITU X.800 families of security standards.
31/110
Figure 4.1: ITU-T X.805: Security Architecture for Systems Providing End-to-End Communications [2].
In particular ITU-T recommendation X.805 [2] (Figure 4.1) defines a reference security architecture for systems providing end-to-end secure communications, and introduces different security dimensions of a communication system. These dimensions can serve to structure general security requirements of a distributed Police Information system: Access Control (Authorization). Authentication. Non-Reputation. Data Confidentiality. Communication Security. Data Integrity. Efficiency. Reliability. Availability. Privacy. Each INDECT component must have built-in mechanisms to address the requirements established for each one of the eight dimensions, and on all the planes through which interaction with them is possible: a) End-User, b) Control/Signalling and c) Management planes. Let us review general requirements for each dimension.
Access control (Authorization)

The ability to control the level of access that individuals or entities have, to both network and information systems must be properly defined by system managers. This strongly depends on the types of users that Police define, the respective access capabilities for each user group, and the confidentiality levels established for each piece of information.
32/110
There must be appropriate mechanism to enforce such access control (e.g. firewalls, file systems permissions, secure log-in) including physical control of access to terminals. Furthermore the system must have a mechanism to fully trace and record the actions and the information accessed by each user at all times. Each INDECT component must have built-in access control mechanisms in all planes through which interaction with them is possible (namely end-user, control and management planes, according to X.805). A single authorization check can grant access to all the functionalities of an application or system (i.e. login). However access control has a broader definition and can be applied before accessing to each resource of a system. In particular, a good mechanism to avoid cases of abuse of authority is to clearly define what the usage limits of an application are. For instance, a judge may provide a warrant to investigate the associates of a particular suspect employing certain system or database. In this case a proper authorization scheme is to define the allowed queries to the database (e.g. associates name and contact info) instead of granting full access to a database containing personal data of people not involved with the investigated case.
Authentication
Authentication must guarantee that the system being accessed is the intended one and that the user is who claims to be. The authentication mechanism in Police systems should combine the use of a solid state-of-the-art Identity Management System (IdMS), including Public Key Infrastructure (PKI), Smart Cards to securely store private keys, and/or biometric authentication (e.g. fingerprint-based). However these technologies may be too expensive in order to be employed by every Police system and may hinder the interoperation between different systems. For this reason Federated ID mechanisms that centralize authentication for multiple systems may become very useful in this context. Therefore INDECT components must be prepared to work in this type of IdMS environment and the whole INDECT platform must be supported by an IdMS. Moreover, the federation of IdMSs in INDECT may be useful in order to support cooperative investigation.
Non-Repudiation
Due to the potential legal value of the digital data managed by INDECT tools, the capability to prevent system users from denying that data files were accessed, altered or deleted, might be useful for specific INDECT subsystems to enable highlysecure logging and auditing processes. Nevertheless, most of the tools and use cases developed in INDECT are not oriented to obtaining legal evidences by themselves, but to support an investigation with hints or automatic alarms. Therefore, this dimension does not translate into a compulsory general requirement for INDECT, but only for specific subsystems that may be employed to store evidences in electronic-format.
33/110
Data Confidentiality
The protection of information from unauthorized disclosure shall be made by: a) restricting per-user-group access to every type of information dealt with, b) by encrypting the information at least on transmission and possibly on storage, and c) establishing control mechanisms to the methods by which the information can be disclosed outside the group, supported by non-repudiation liability or watermarking techniques. This latter objective is the most complex to implement in practice since the ways of disclosing information are many. a) and b) should be compulsory requirements in INDECT, and some type of disclosure control is desirable, yet out of the scope of INDECT, since it must be a built-in feature of the Police information systems. A standard classification of confidential levels (sorted from highest to lowest one) that could be also employed for future INDECT information systems is: 1. Unclassified 2. Restricted 3. Confidential 4. Secret 5. Top Secret However it is worth noting that no classified information will be gathered, stored or processed during the duration of the INDECT project itself. These confidentiality levels are provided just as a reference inside the framework of Police information services. See section 4.2 for further details about INDECT confidentiality levels.
Communication Security
To ensure that communication only flows from a source to the intended destination, all communication must be made with secure tunnels using standard mechanisms for this purpose, always employing encrypted sessions (e.g. TLS/SSL, ssh). Security should be further reinforced with Virtual Private Network (VPN) technology, such us IPSec tunnels, where appropriate (e.g. between physically secure routers or IP cameras), or when employing any kind of wireless link (e.g. WiFi, WiMAX, GSM/GPSR, UMTS). In order to avoid man-in-the-middle attacks, the aforementioned technologies must support and employ mutual authentication by means of certificates or pre-shared keys.
Data Integrity
The ability to protect data from unauthorized, uncontrolled, or accidental alteration during storage or transmission is another essential feature that must be built-in in a Police information system. INDECT should use checksum and hash functions as well as digital signatures wherever possible to guarantee the consistency of data in transmission and for continuous intrusion detection into file systems. In order to guarantee the chain of custody, all INDECT systems that may gather or store electronic evidences must implement mechanisms to guarantee that this data has not been altered by any system user or any other third party. In the case of
processed information to be employed as evidence, both raw data and processed information must be protected from tampering.
Efficiency
Efficiency is one of the requirements which are connected with security. It is defined as a relationship between the results achieved and how well the resources have been used. It means that the aim to be achieved by the secure system also depends on the kind and quality of used methods and services. During the design process of the INDECT subsystems (security solutions and requirements directly connected with security) this requirements should be taken into account.
Reliability
Reliability is defined as the ability of a system to perform its functions for a period of time. The reliability of the system is one of the high-level requirements. It means that it consist of a few different requirements (i.e. availability and communication security). It is a good point to start a design process and it can be a source of another, more specific requirements. This is obvious that this requirement connected with security should be met by the INDECT subsystems.
Availability
The development of protection or back-up mechanisms for network/software/ hardware is also a desirable property of any IT system, as well as to defend from Denial of Service (DoS) attacks. This falls out of the scope of the INDECT work plan, but provisions can be made in all the deliverables that describe implementations on how the subsystem can be protected to increase its availability.
Privacy
Privacy may be defined as an entitys ability to control how, when, and to what extent personal information about it is communicated to others. In order to support privacy it is important to understand what personal information is and to be aware of the ways that personal information can be controlled and processed. Privacy and legality of INDECT will be supervised by the Ethics board. The technical requirements in this dimension are simply: to implement whatever is required to fulfil all the privacy requirements stated in chapter 2 and the guidelines established by the Ethics Board. During the five years duration of the INDECT research project no personal data will be employed for the development and test of the systems and tools, unless strictly necessary (i.e. biometrics and CCTV footage). In this case all people involved in those tests must fill a form to give their informed consent. Even in these cases, all personal data filed in the systems will be fictitious or at least anonymised.
35/110
4.1
List of General Security and Privacy Requisites
REQ-D8.1-4.0-01: All INDECT subsystems and tools to be deployed MUST comply with all applicable EU conventions, directives and national laws. REQ-D8.1-4.0-02: Information gathered, stored and processed by INDECT systems must be properly time-stamped and catalogued by defining (either explicitly or implicitly): its origin, intended use, whether it is editable or read-only, lifetime, confidentiality level, and possibly one or more integrity checks (i.e. to guarantee the chain of custody of an electronic evidence). REQ-D8.1-4.0-03: Information security subsystem must provide mechanisms for ensuring confidentiality and privacy of users, data and communications. These mechanisms must cover user, management and control planes of any networked software component. REQ-D8.1-4.0-04: All INDECT subsystems must provide techniques for secure and fine-grained access control. REQ-D8.1-4.0-05: Critical INDECT subsystems must feature reliability and high availability via redundancy.
4.2
List of Information Confidentiality Levels
The INDECT project does not handle any kind of classified information, therefore all information processed by INDECT systems will be Unclassified (see previous subsection). Nevertheless this broad confidentiality can be further split in the following sublevels: Level I: Open access This kind of information can be created, transmitted and stored without any security restriction. Everyone could have access to the information of this confidentiality level. Access to this information can be provided by means of Internet or other open communication network. Level II: Public access This kind of information can be accessed by everyone but after some special authentication procedure. This information is not freely accessible from Internet or other open communication networks. Special authentication procedures can be: signing of request for accessing the information or requesting it by means of a valid certificate or other secure credential. Users' activities could be logged for additional audit. Usually users should have read-only privilege. Level III: Restricted access This kind of information can be accessed only from government organizations (police, hospitals, fire brigade, security forces and etc.). All users must have a valid certificate to access this information. Users' activities must be logged for additional audit.
36/110
Level IV: For internal view only Only Police officers can access to this information from a Police station office or from a Police car. Police officers on the street (with PDA) cannot have access to this level on information (because of the widely used CCTV from banks, private buildings etc.) Additionally it is always necessary to apply the basic principle of need to know in order to access any kind of information. The principle need to know is to limit the access to information to only the persons whose duties or special assignment require such access. Non-classified information can be created, transmitted and stored in systems that have one of the above classification levels. Information between different systems (with different level of classification) can be exchanged if the following rules are observed: information can be transmitted from system with one classification level to system with the same or an upper level of classification of information. The mapping of this confidentiality levels to particular INDECT use cases will be provided in Deliverable D8.7 Definition of mechanisms and procedures for the security and privacy of the exchanged information (m48).
37/110
38/110
5 Security and Privacy Requisites for INDECT Subsystems

5.1 Intelligent Monitoring System (WP1)
This section describes the data exchange formats and protocols proposed for use for communications within Intelligent Monitoring System entities, namely Node Stations (NS) and Central Station (CS) developed by WP1 (to be described in detail in deliverables: D1.2 Report on NS and CS hardware construction (M20) and D1.5 Specification of procedures for data exchange including definition of system usage with respect to the law and police regulations (M50)), providing suitable level of security for data and media transmission. The choice of specific solutions has been determined by the availability of open standards related to discussed application and their functional suitability. Careful security analysis has been also performed in order to determine whether the specific solution grants sufficient protection for sensitive data, which are processed within the system. This factor affected the decisionmaking process towards the solutions which are mature and well-established within the industry, as this increases the chance that the design is free from child-age defects and minimizes the chance of discovering security exploits. The system comprising numerous Node Stations and Central Station should be able to support two types of communications traffic: Interactive, low volume data exchange capable of transporting arbitrary, selfdescribing control data. Real-time multimedia streaming for high volume on-demand traffic. Although there are protocols capable of supporting both types of traffic, such solutions are suboptimal, because of their vastly differing real-time characteristics. Therefore it was decided to use two separate communications protocols.
5.1.1 General-purpose secure communication Each entity connected to the system should be able to receive and send generalpurpose data to any other entity. This imposes the requirement on the addressability of the entities. It was decided that addressing based on IP addresses is not sufficient for the purpose, as it is possible to run several services based on the same machine. Therefore additional logical addressing was required to uniquely identify each communication entity. Moreover, the chosen solution must allow for easy communications with nodes that are located behind firewalls or NATs. These requirements may be easily fulfilled by using system with central server acting as a bus controller. This ensures that all the connections are initiated by the clients connecting to the public server, so the traffic will not be blocked by firewalls or NATs. The server also acts as a hub for the purpose of addressing connected clients, so that the connecting entities do not need know physical address of any other entity they wish to communicate with, only their ID number, name or other type of identification data or address. The actual communications routing is done by the server based on the logical addresses, what greatly enhances the flexibility and scalability of the system.
39/110
That discussed connection between clients and the server should be secure. As a general framework for secure transport layer TLS 1.0 should be used, which is currently most advanced and publicly-reviewed solution. TLS is extensible framework, which allows using arbitrary public-key and symmetric ciphers for the purpose of securing the communications channel. The specific choice of used cipher suite (i.e. set of ciphers) at this point is not required and should be a matter of further discussion with cryptography experts in order to find the cipher type and key lengths appropriate for long-term protection of sensitive data. The analysis of aforementioned requirements leads to the choice of XMPP protocol as a medium for inter-entity general purpose communications. XMPP protocol is based on the exchange of pieces of XML documents, called stanzas. This feature makes for its unlimited extensibility the data may be formed into arbitrarily complex structures, provided they conform to the XML Schema. XMPP protocol includes also support for entity addressing, as each connecting node is assigned an address very similar to e-mail addresses. The communication is secure the server may be configured to enforce TLS1.0 channel protection, it is also possible to perform mutual authentication of client and server via digital signatures (certificates). The protocol has built-in support for node and service discovery, so that it is possible to create service repositories. The XMPP community developed a number of protocol extensions. Some notable examples include XMPP-SOAP bindings, which allow for easy encapsulation of SOAP messages within XMPP stanzas, which is very useful for the purpose of constructing a XMPP-SOAP gateway enabling publishing of some services running within the system as Web Services. This feature is an enabler for interoperability with the other parts of the INDECT project, which may choose SOAP/WSDL as their primary means of communications. It is worth noting, that within the scope of Intelligent Monitoring System of WP1 the XMPP protocol would be used as a transport layer, on top of which a service layer is proposed, where XMPP stanzas are used as means of delivering information and invoking published functionality. Therefore, the XMPP server should not be mistaken with security system server, which (if any) would function as another service deployed within the XMPP network. An important feature of XMPP protocol, which greatly influences the way the aforementioned multimedia traffic is delivered, is its Jingle extension, which implements multimedia signalling protocol on top of XMPP. This way it is possible to use XMPP network directly as a means of controlling out-of-band multimedia sessions described in subsequent section. The proposed system should be able to operate in closed intranets as well as in open Internet environment. This is especially important for the purpose of connecting the mobile terminals, which should be able to communicate over general-purpose Internet access infrastructure like existing municipal wireless networks, 3G or upcoming WiMAX installations. This requirement increases the risk of attacks for the parts of the system which must be publicly available in order for the communication to succeed. Such crucial parts of the system include XMPP server and associated service nodes participating in media relaying. All other components of the system
should be protected by the firewall from outside world to reduce the number of attack vectors. The remaining components should be designed and developed with security in mind. Fault-tolerant solutions should be preferred and the number of gateways from open Internet to the internal Intelligent Monitoring System subnet should be kept low with their purpose well-defined and sensible.
5.1.2 Secure multimedia communication XMPP protocol is typically used with TCP streams plus TLS security layer. Such design together with additional XML encapsulation make it highly inefficient in terms of latency and overhead, when it comes to the transport of real-time, high-volume data, such as multimedia streaming. In order to efficiently transport such denselypacketized traffic, typically protocols based on UDP are used, which thanks to lower overhead allow much better bandwidth utilization. Industry standard pertaining this use is RTP protocol, commonly used in applications such as VoIP telephony and Internet TV or radio. RTP provides payload encapsulation and identification, packet numbering and synchronization and has provisions for exchange of various statistics relating to delivered streams. There is also an extension to the core protocol called SRTP which adds support for payload encryption and signing, adding channel protection. However, RTP by itself does not include any mechanisms for establishing and negotiating the session. For this purpose so-called signalling protocols are used, such as SIP, RTSP or aforementioned XMPP/Jingle. The choice of Jingle signalling allows exchanging information regarding the multimedia session in a secure, authenticated connection. This information includes parameters like IP addresses and UDP port numbers of communicating endpoints, definition of media formats used within session and security data for the configuration of block cipher used for data encryption. The use of RTP poses similar difficulty as described earlier when it comes to use of firewalls and NAT devices. However, it should be noted that there exist two approaches to the problem, both of which are applicable. The first one is the use of so-called Interactive Connectivity Establishment (ICE) methodology, designed specifically to aid in establishing RTP session in such complex environments. The second solution is the use of a proxy, which is less efficient than ICE; however, in the context of described system may still be a better option because it is possible to integrate the proxy with centrally-located media recording service, which should be implemented in the system anyway. Similarly to general-purpose communications, it is not required at this stage to identify the best cipher suite for use with SRTP encryption. The proposed solution is flexible, so it is possible to switch to any other encryption algorithm easily. WP1 communications framework architecture is presented in Figure 5.1.1.
41/110
Multimedia DB/ Service
XMPP XMPP Server Bus Controller
XMPP/Jingle Signalling Jingle/RTP Server/Proxy
XMPP/Jingle AVP/SRTP Terminal
Node Station
Mobile Terminal
Figure 5.1.1: Intelligent Monitoring System communications framework architecture. Green connections utilize XMPP/Jingle protocol for general purpose communication between systems entities, blue ones AVP/SRTP for multimedia streaming.
5.1.3 Data storage Intelligent Monitoring System apart from transmission of data includes means for storage of large quantities of multimedia and other information. This data should be generally treated as sensitive and protected from various forms of unauthorized access like disclosure or tampering. In order to ensure multimedia data integrity various watermarking techniques may be used during storage as well as for transmission. The problem of digital media watermarking is described in depth in section 5.5. To prevent unauthorized access the sensitive data should be stored in nodes located within trusted part of the network. The access to physical media should be regulated by appropriate safety procedures. Storage file system should be a subject of carefully designed access policy based on Access Control Lists or other similar OS-dependant measure.
5.1.4 List of Security and Privacy Requisites REQ-D8.1-5.1-01: General-purpose XMPP communication should enforce the use of TLS1.0 security layer.
REQ-D8.1-5.1-02: Mutual authentication of connecting parties via TLS1.0 certificates should be used whenever possible. REQ-D8.1-5.1-03: Ciphers used by security layers should use key strengths sufficient to withstand brute-force attacks carried out with a computational power predicted to be available to government agencies and multi-national corporations in the foresee future. REQ-D8.1-5.1-04: Access to communication system requires authorization via SASL (Simple Authentication and Security Level) protocol built-into XMPP stack, with TLSexternal mechanism used whenever possible. REQ-D8.1-5.1-05: Passwords used with SASL mechanisms based on the simple login-password verification scheme should be subject to security policies ensuring at least proper complexity, expiry period and non-repeatability. More secure authentication mechanisms may be also employed instead of login-password. REQ-D8.1-5.1-06: Services, monitoring stations and other nodes connecting noninteractively to communication system should be configured in a way that would prevent disclosure of credentials in the case that the computer system they are based on was physically accessed by an attacker. REQ-D8.1-5.1-07: Multimedia communication should use encryption and integrity protection built-into SRTP protocol. REQ-D8.1-5.1-08: Multimedia session security layer should be negotiated within scope of secure XMPP connection. REQ-D8.1-5.1-09: STUN and TURN servers used during ICE session establishment procedure should enforce client authentication. REQ-D8.1-5.1-10: Sensitive data within the system should be stored in trusted subnetwork. REQ-D8.1-5.1-11: Fragile watermarking should be applied to multimedia data stored in the system in order to detect tampering attempts. REQ-D8.1-5.1-12: Storage file system for sensitive data should use Access Control List-based access policy. REQ-D8.1-5.1-13: Storage file system for sensitive data should use encryption. REQ-D8.1-5.1-14: All accesses to stored sensitive data should be logged and audited.
5.2 Mobile Urban Observation System (WP2)

The goal of Work Package 2 of INDECT project is to develop a surveillance system capable of identifying and tracking mobile objects across the streets in urban areas. Such a surveillance system is expected to assist police officers in their daily patrol of streets, especially in highly populated urban areas, where identifying and tracking known criminals is a challenging task. A key component of this system is the so-called Unmanned Aerial Vehicles (UAV), a set of sophisticated aerial patrols, provided with software for an accurate identification and tracking of suspects in an urban area. Additionally, Police officers of the future are expected to be equipped with wireless connections that provide them full connectivity among them and both to a central operations office and to such UAVs. In terms of networking, both the police officers and the UAV can be characterised as a mobile sensor network that require special signalling, routing and fast restoration upon failure in order to full-connectivity between the different components.
5.2.1 Description of components From above, the Mobile Urban Observation System comprises the following components: 1) The UAVs which are a number of vehicles provided with highly accurate cameras and sensors These UAVs are controlled from a command center although they may exhibit intelligent and autonomous behaviour, and could cooperate among them. Additionally, the UAVs must record and/or stream to the control center or to Police officers video and data captured by its sensors. 2) In order to be truly effective, UAVs must cooperate, directly or through the command center, with nearby Police officers to identify and arrest criminals being tracked. Given their mobility and the dynamic nature of the urban areas, a secure wireless communications system is required for such cooperation. 3) The UAV command center which control deployed UAVs, receives live feeds of the onboard cameras and sensors and coordinates the actions of Police officers on the streets. All data from UAVs must be securely recorded, since this footage may be employed as evidence in court.
5.2.2 Security issues As in many other systems of the INDECT project, authentication and confidentiality in the communications between participants is mandatory. This comprises a set of requirements that must be fulfilled by the UAVs and the Police Officers, together with their respective communications. Concerning the UAVs, access control is required such that only authorised personnel are allowed to manipulate their data and control its movement and identification and tracking features. Additionally, the internal database of the UAVs must be encrypted and restricted to the appropriate personnel only, since it may contain critical evidence of criminal activity. The UAVs must also keep a log on what commands are given to
them and who sent them. In addition to this, the both control and data information exchange between UAVs, its command center, and other Police officers must be properly signed and encrypted in order to avoid intrusion and sniffing.
5.2.3 List of Security and Privacy Requisites REQ-D8.1-5.2-01: The UAVs must employ very restrictive access control, in order to guarantee that only the authorised personnel control them. REQ-D8.1-5.2-02: Data communications among the Police Officers, the command center, and the UAVs must be secure, guaranteeing its confidentiality, integrity and authenticity. REQ-D8.1-5.2-03: All evidence captured by the UAVs must be stored in a secure and restricted database, since this may result critical in court.
45/110
5.3 INDECT-MAS (WP3)

Work Package 3 of INDECT project aims at developing a set of techniques and software tools to do surveillance of Internet resources with a two-fold overall objective: firstly, detect criminal activity on Internet resources, and secondly, identify relationships between suspects from online sources. Given the challenging nature of collecting so much data from so many Internet sources (web sites, discussion forums, social networks, etc), it has been agreed to partition the challenge into a number of small and feasible sub-problems, each addressed by simple and modular agents. A Multi-Agent System (MAS) based approach, where multiple independent software agents cooperate in the task of collecting and correlating data from multiple Internet sources, is both flexible and feasible to fulfil the goals of this work package successfully. A few agent roles are listed below: - Identification of threads and criminal activity based on Internet services monitoring. - Botnet and malware detection and confinement. - Traffic monitoring. - Correlation of activity in social networks. In spite of the agents different and disparate roles and targets, all of them must operate collecting raw data, filtering and processing it, and storing only the valid/useful information. In other words, in all cases there are three functional units that may be resident in distinct distributed hosting units, and hence require separate analysis. These units are: 1) The Capture/Monitoring Unit is in charge of collecting information from an Internet. In a real setting it is very important that this process is kept properly secured, anonymous and must be performed will all required legal guarantees. Once the information is filtered and collected, it is sent to the Analysis Unit 2) The Analysis Unit receives raw data collected from various sources and tries to produce useful information out of it. Useful information refers to that aimed at identifying sources of criminal activity, and to infer interaction between different criminal entities. Once such information is obtained, it must be securely stored in a database. 3) The Storage Unit must provide the necessary capacity to allocate all such information with integrity guarantees since, in some cases, it may be expected to provide evidence against criminals at court. Again, this database is critical and must be protected against misuse and attacks. In other cases, the Agent integrates all this functions monolithically.
5.3.1 Security issues The type of information collected and transmitted between the units requires particularly secure communication in the chain Capture-Analysis-Storage and in the access to results. Essentially, it is necessary to guarantee that: (1) no information is lost or manipulated; (2) no third parties have access to this information; and (3) only the appropriate authorised members have access to each type of information, and (4) all important operations of the monitoring subsystem must be securely logged in order to be audited. To achieve these targets, all flows of information must be
digitally signed and encrypted before transmission, as the network (e.g. Internet) or link (e.g. WLAN or 3G) may be especially insecure in a distributed MAS. Additionally, using digital signatures guarantees the integrity of the captured data, that is, it proves that no third parties have manipulated the data at any time during the transmission between the two units or even later while in storage. Furthermore, active measures should also be taken against potential end-system intrusion. Finally, it must be emphasized that INDECT-MAS and its functionality are generally oriented towards Police operational and investigational activities, which means that its end-users are expected to be mostly Police Officers. This implies additional Police security procedures specific of each Police force, not public and out of the scope of the demonstrative nature of INDECT.
5.3.2 List of Security and Privacy Requisites REQ-D8.1-5.3-01: Communications among all the units of the INDECT-MAS must be secure, guaranteeing its confidentiality, integrity and authenticity. REQ-D8.1-5.3-02: All data fetched must be captured and safely transmitted and stored in a secure server to avoid losing vital information and/or tampering. REQ-D8.1-5.3-03: Only authorised users must be able to access INDECT-MAS data. REQ-D8.1-5.3-04: All of operations of users, such as queries, and result display, must be logged in a secure server to enable auditing procedures.
47/110
5.4 Web-based crime detection (WP4)

The main goal of WP4 is to search for web-based criminal traces and to store relevant data for further analysis. Therefore, a detection system that collects data based on some requested properties is to be developed in INDECT. By means of these input properties, the search for a possible threat will be executed, by employing Artificial Intelligence techniques, and only the appropriate data will be stored. Then it will be sent for analysis and returned to the end user in an easily readable form for further processing and eventual regular police investigation (out of the scope of INDECT). The security requirements are essentially similar to those of WP3. Because the whole project is considered as a decentralized system and all its components may work in an asynchronous fashion, they need to exchange a lot of data. Therefore parts of the project may face the problem of compromising data on each level of processing stack. Such threats may be prevented using different security technologies or methods. There are a lot of possibilities for compromising data on their way to or from WP4 subsystems. Let us divide them and discuss their own problems separately. Data between WP4 subsystems will probably be transferred as plain XML, to be easily exchanged and imported into a database for further processing. Therefore proper encrypting methods should be used in order to exchange confidential data, because it may contain personal information or other confidential information.
5.4.1 Security issues

Input data leak/damage
Because INDECT subsystems are decentralized, stand-alone applications communicating between users and/or other subsystem can be compromised in various ways like by modifying input properties. This could cause serious problems to the search phase and may return wrong results. Possible threats comprise the leak or damage of the input list of websites to be searched for, which could cause the deletion of content we want to search or making such search impossible, or modification of previously selected search properties. Such leakage of confidential information may occur in the system no matter on which level of the communications stack.
Output data leak/damage
As same as input data modification, output results should not be compromised. This can cause even more problems, because these data is further analyzed and then provided to a user, so her trust in the system is a critical issue for both the operational and legal points of view. They can also contain personal information of unspecified individuals that should not become public.
Authenticity/Authorization
Another problem can be the authenticity of tasks sent by some subsystem to another one. These subsystems need to solve the following problem: (1) who is really asking for the specified search? and (2) is this user really authorised to request such task?
The same security mechanisms to solve this problem should be used to control a user accessing the controller application.
Content security
Content is the most critical part to be protected because system will store a large amount of confidential information that could be compromised by a direct attack to the database server or by leaking such data directly from a daemon of the database server. Also there can be attempts to destroy whole database or to stop the system (e.g. intrusion, DoS) by attempts to attack the distribution of crawled or analyzed data.
System functionality
Subsystems should stay operative in order to be useful. Therefore all necessary steps should be taken in order to defend them. We have to protect against either using some code embedded in a query or by direct attack on systems inputs and outputs. Such operation could make system more vulnerable to other attacks.
Hardware threats
Potential threats to hardware should also be considered. The main threat seems to be the physical destruction of database server or its manipulation. The same threat applies to the crawler and to the analyzing server. WP4 will employ several mechanisms to ensure that none of above problems will happen. 1. Encryption and integrity of files are two of the requirements to deal with data leaks or manipulating the inputs or outputs from the system, respectively. The above problem can be solved by using encryption and hash functions. 2. Distributed data should have a strict structure. 3. Non-authorized users must not access the system or the stored information. Invalid login attempts should be logged to analyze possible threats. 4. Authorized users activities will be logged on a secure server in order to audit the system. 5. There may be attempts to compromise the database directly. The best solution seems to be to create a distributed database system with only one DBMS (Database Management System) while other parts of the database are divided on different machines, separated by a private firewalled network. 6. Subsystems themselves should be protected in various ways. Proxy server may protect the database system in cooperation with firewalls and virus protection software. 7. Although much less probable, protection against threats to underlying hardware should be also considered. A trusted provider for high security servers should be selected and then they should be physically protected to avoid tampering. We could consider some kind of HDD hardware or software encryption, although the latter could take more computing time than it is acceptable and it can therefore prove not to be useful and cause important processes to run slower.
49/110
5.4.2 Solutions
Integrity
Hash functions (e.g. SHA1) combined with some cryptographic algorithm, like RC4, will ensure acceptable data integrity without any additional steps. Such implementation should not take much time and will give us good results. To ensure the integrity of transferred data, we could consider XML-specific mechanisms like XML Signature or XML Encryption, or to use instead some data-agnostic secure protocol like SSL/TLS. Furthermore some different mechanism for encapsulating the transferred data could be developed to provide additional protection for the data.
Authentication/Authorization
Problem of authenticity can be taken from two sides: how user is authorized to use the system and how separated subsystems authenticate each other to collaborate on tasks. When we take a closer look on the side of a user defining properties of request to be searched and analyzed, we are definitely talking about the authentication and authorization of such user. For authentication a user should be provided with a unique login and password and all of his activities (including the list of websites to monitor and the employed search keywords) should be logged on a server side, for example on the DBMS server (mentioned in the next section) or even on the searching or analyzing server to ensure backward restoring of her actions.
Content protection
Content protection is understood here as the protection of stored data whether archived or newly crawled package sets to be further analyzed. Content security processes have to cooperate very closely with other parts of security components, like authentication and authorization and data integrity. Because there may be attempts to compromise the database, the best solution seems to create distributed database system with only one DBMS (Database Management System) and other parts of the database divided into different machines separated by a private firewalled network. There are various ways to do so, one of them is to use nowadays very popular virtualization and create more separated database servers on one physical machine. This is a cheap solution but it will not benefit from one of main advantages of distributed network that is if one node and its data fail, none or only a smaller part of data will be lost. Replication of data will ensure reliable transaction between nodes. Also cheaper scalability can be another advantage, because it is still cheaper to run smaller parts of database on smaller machines then to use one huge database on a big one. Last advantage seems to be that if some distributed database fails it will be still feasible to support data from remaining parts of the database and therefore the whole system will stay operational and will be able to support other subsystems. DBMS and all its subparts should be protected from outside internet by using a firewalled proxy server, giving us reliable protection against common attacks and also some virus protection. Main aim will be to hide real IP address of database servers mainly DBMS, because these are not critical for either the user or another subsystem to know and such behaviour will ensure another protection against external threats.
50/110
System protection
System parts themselves should be protected in various ways. Proxy server may protect the database system in cooperation with firewalls and virus protection software. Using of proxy server should be considered in the case of crawler operation because of possible unwanted filtering of some content may prove critical to make him operate properly. Therefore it may operate in a less protected zone and communicate with the database by using the same rules that are applied for communications among subsystems. We should also consider internal errors that may occur on separate subsystem, which may disable operation of those components. Those should be detected by regularly executed scripts to check of its operation. They will only request a simple task to prove that selected part of the subsystems is still operational. If it is not, than it will terminate such process and restart it.
5.4.3 List of Security and Privacy Requisites REQ-D8.1-5.4-01: To ensure integrity of data we have to use a strong hash function (e.g. SHA256) and a strong cryptographic algorithm (e.g. RC4). Such implementation should not take much time and will give good results for data integrity. REQ-D8.1-5.4-02: Data are transferred in XML format. Because of that, common compression algorithms for packaging should be used and that will be able to support hash checksum and some cryptographic algorithm may be used. Furthermore, a different way to encapsulate transferred data should be developed to provide further protection for the data. REQ-D8.1-5.4-03: It will be necessary to develop or use some of proven authenticity algorithms like for example digital signature for authentication. REQ-D8.1-5.4-04: Non-authorized users wont have access to the system or the stored information. Any invalid attempt to login should be logged in order to analyze possible threats. After a predefined number of login attempts, such username should be blocked for defined time period which system administrator will set. REQ-D8.1-5.4-05: All authorized users activities will be logged on server. Data about search activities must include the list of websites to monitor and the employed search keywords. REQ-D8.1-5.4-06: Because there may be attempts to compromise the database and content, the best solution seems to create distributed database system with only one DBMS (Database Management System) and other parts of the database divided on separated machines inside a private firewalled network. REQ-D8.1-5.4-07: System parts themselves should be protected in various ways. Proxy server may protect the database system in cooperation with firewalls and virus protection software.
5.5 Watermarking (WP5)

5.5.1 Watermarking techniques Digital watermarking is the process of embedding additional information into multimedia files. Ordinarily, when additional description of the multimedia is needed, the meta-data fields of certain file formats are used for that purpose. However, this information can be easily removed or simply lost during format changes. Digital watermarking embeds the data by modifying the digital signal (i.e., the sound of an audio file or the appearance of an image). Depending on the application, the introduced changes might be visible (e.g., an overlaid logo or the signature of the owner) or imperceptible. Regardless of this choice, this additional information should withstand any intentional (e.g., tampering, forgery) or accidental (e.g., JPEG compression, brightness changes) modifications. Over the years, plenty of applications of digital watermarking have emerged. The most popular of them is copyright protection (Fig. 5.5.1). Even after modifications, the original author of an image can be identified. There exist watermarking technologies that allow this ownership information to be recovered even after the image is printed and scanned afterwards.
Figure 5.5.1: Copyright protection with digital watermarking Analogous approach can be used to identify the recipients of multimedia content. (Fig. 5.5.2). Individual copies (watermarked with the name) are created before distribution. This way, it is possible to find the source of an information leakage, i.e. confidential police data. Nowadays this technology is widely used in the movie distribution business.
52/110
Figure 5.5.2: Recipient identification with digital watermarking
5.5.2 Requirements with respect to watermarking The INDECT project will be processing significant amounts of multimedia data. Implementation of digital watermarking is planned to ensure an additional layer of security. Certain requirements and expectations towards the watermarking technology can be identified at this point. Content description consistency Multimedia content present in the system will be processed by intelligent image analysis algorithms. Information about the content of the images and video clips will be automatically extracted and will complement the description made manually by the users of the system. This exhaustive description will be indexed to enable fast information retrieval and efficient searching features. Optimal information access time requires that the content descriptors are stored in a dedicated database, separated from the multimedia data and sorted in a format convenient for machine processing. Evidence in terms of digital images and videos are likely to be distributed to external parties. In such case, it would be problematic to extract the gathered content descriptors and carry them along with the image. Implementation of digital watermarking allows embedding this description in the images themselves. It would be present regardless of the image format most convenient for distribution and would be available to the recipients without direct access to the index of the system. A standardized format for content description with digital watermarking will be proposed to ensure a consistent way to handle meta-data. Processing efficiency The developed system is an intelligent monitoring solution and the amount of processed multimedia content will be a real challenge to existing computer systems. Therefore, the algorithms used for digital watermarking are expected to deliver near real-time operation abilities. This issue requires further investigation as the
expectations towards speed and efficiency are most likely a trade-off and multiple classes of final requirements are likely to be specified. Content Protection Multimedia content that is collected by the system is likely to be treated as evidence. Techniques based on digital watermarking can be implemented to protect the content of digital images. This content protection can be understood in two different contexts: Tampering detection, Content access protection.
The former is known in the literature as fragile watermarking. This term has been coined to indicate that the embedded watermark ought to be easy to destroy (in contrast to the original understanding of watermarking, whose desired property is robustness). This way, it would be possible to detect image fragments that have been altered. State-of-the-art fragile watermarking algorithms are able to reconstruct the original content, to some extent. The latter meaning of content protection can be seen as a means to selectively decide which parts of an image should be visible to certain individuals. Multimedia content present in the system will be processed by fully automated algorithms that allow detecting important patterns (e.g., faces, car license plates) and occlude them if necessary. The information necessary to reconstruct the original images is stored in the image itself using a secure watermarking-based method. Therefore, the same multimedia file appears with the occluded content when opened by an unauthorized person. Otherwise, the original appearance could be reconstructed in real time on the authorized person's device.
5.5.3 List of Security and Privacy Requisites REQ-D8.1-5.5-01: Watermarking algorithms must not have any backdoors allowing breaking it without the associated decryption key. REQ-D8.1-5.5-02: Watermarking algorithms must ensure high level of data integrity to ensure that evidence has not been tampered. REQ-D8.1-5.5-03: Watermarked files should be certificated by a trusted entity to avoid repudiation when disseminating personal or confidential police information.
54/110
5.6 Crisis Management Portal (WP6)

Main goal of INDECT Portal is to offer a unified interface for end users where they can access INDECT information and tools. For this purpose, it is necessary to develop a highly secure system. This aspect will be studied and supported by WP6, in charge of designing and developing the INDECT PORTAL, together with the WP8, responsible for the management of security issues.
5.6.1 Overview The portal is used for the presentation and handling of data taken from the WP6 sensor proxy server, other data systems, and multimedia calls to the portal. This information is only intended for a restricted group of registered users. INDECT portal provides functionality for the storage and transport of information that must be available to registered users that are granted access. Therefore, the main security objectives for the communications with the portal will be the following: Authentication: The security framework must provide mechanisms to verify that the identities of communicating parties are genuine. The techniques used for this purpose should be based on certificates, public key signatures, or preshared secrets. Authorisation: The security framework must provide mechanisms to control access to resources. Authorisation is generally linked to authentication. A requester is authenticated first, then access to resources is granted or not depending on access rights policies for this requester. Only registered users with their access rights will be able to process/manipulate editable data and modify the access rights when required (Administrator role, D6.2_4.3 [33] user roles) Confidentiality: Information must not be disclosed to unauthorised parties. That is, the security framework must provide mechanisms to ensure that sensitive data must neither be accessed nor copied by unauthorized persons. Confidentiality will then be required not only during transport of data but also in storage. Some models for control access (e.g. RBAC vs. ABAC or other) and encryption techniques should be used for this purpose Integrity/Authenticity: Unlawful data alteration, modification or destruction should be prevented at all costs. Therefore, the security framework must provide mechanisms to ensure that data and exchanged messages are not modified or altered in any way. These characteristics of the information should be preserved after any interaction with the portal. Extensive logging and the non-repudiation property of digital signatures may be employed for data integrity. Non-repudiation: It must be avoided that any of the entities denies having participated in a communication where they were involved. Security services should be provided in order to prove messages origin for monitoring, administration or authorisation purposes. Generally signature techniques are used on this purpose. Any actions performed by users will be registered (audit trails) and displayed in a timeline when necessary. Availability: accessibility of the information when needed must be guaranteed
55/110
To sum up, INDECT will provide several mechanisms that will be used to assure that information is secured and also to guarantee that citizens privacy is not violated. Registered INDECT Portal users are authorized to access different sets of documents stored in the system, and some of them have the rights to manipulate certain information, leaving an audit trail of their actions (administrative role, D.6.2). Therefore, an authentication and authorisation process is mandatory, which means that all users cannot be treated as a single group of users with equal rights and credentials. By means of access control, each registered user will have different capabilities and privileges according to her profiles. 1. Non-registered users will have only limited access to the system and the published information. 2. Access to the data will be secured with strong authentication mechanisms. In private and public computer networks, including the Internet, authentication is commonly done through logon passwords or other commonly used credentials. 3. For all actions taken in the WP6 portal, users must be previously authenticated. A dedicated module to handle that demand will be developed. The system will be able to produce reports, about the usage of sensitive data, and supervisors will be able to check if someone has abused of his privileges. 4. Privacy issues will be also taken into account when exporting data out from the system, for example to provide reports to prosecutors. All report must have an associated confidentiality level to avoid unauthorized information disclosure. In case of reports in digital form it will be possible to encrypt/sign documents. 5. If other WPs provide additional security mechanisms, such as watermarking techniques, they may be used to sign/encrypt digital media and increase the overall security level of the system To support the aforementioned security features related to WP6, several mechanisms should be implemented. They have to be introduced at the various levels of the web services architecture that is to be employed. WP6 will follow the SOA approach (Service Oriented Architecture) due to its potential for simplifying systems integration and organising distributed capabilities, under the control of different ownership domains, and through dynamic links between interdependent blocks (services). The quality of service for the architecture design (D6.2_3.4 Architecture design quality measures) refers to security attributes, involving all the layers of the TCP/IP protocol stack (D7.1_4.2_External Systems). Other INDECT subsystems will interact with WP6 Portal using SOAP-messages over HTTP with XML serialization. Data formats for each WP will be based in XML schemas (standardised documents for XML messaging). Standard protocols for internal and external data exchange and manipulation will be used. For example SAML (Security Assertion Markup Language) is a XML-based standard that will be employed for exchanging authentication and authorisation data between security domains.
56/110
5.6.2 Security in Internet Protocol Suite A specification of security extensions that will be implemented, and referred to each of the layers in the TCP/IP protocol stack, follows. Some additional mechanisms that need to be introduced for secure data exchange are also presented: - The session/application layer will be based on Hypertext Transfer Protocol (HTTP), more specifically on HTTPS (Hypertext Transfer Protocol over TLS/SSL) assuring compliance with OASIS Standard for WS_Security. Possible enhancements to SOAP/XML messaging to provide message integrity, confidentiality, and authentication are: o Mechanism for associating security tokens (XML-tokens) with messages: X.509 certificates. SAML token, username token. o XML Encryption to provide confidentiality. o XML Signature to provide message integrity and authentication. The cryptographic protocols to secure network connections between hosts at the transport layer (TCP (Transmission Control Protocol) as required by the above layer) are: o SSL/TLS (Secure Sockets Layer/Transport Layer Security). HTTP uses SSL 3.0 or TLS 1.0 for basic authentication (RFC 2617), as well as certificates (server and/or client side). SSL secures a connection between a client and a server over an insecure network. It simplifies the implementation of secure remote access and control systems for activity management in the portal, since it provides confidentiality, authenticity and integrity. o S/MIME: Electronic messaging standard that enables e-business by addressing the important issues of data privacy and authenticity. It is essential for any scenario where data must be securely transferred, stored, forwarded, and authenticated. It is used as a basis for EDI-INT, the Internet standard for EDI (Electronic Data Interchange). S/MIME uses public-key encryption technology to protect messages from unauthorized interception and forgery. At the network layer, IPSec could be employed to secure the low-level network packets in order to create a secure VPN over insecure channels such as Internet. It consists in introducing authentication and encryption headers in each IP packet of a data stream. It provides authentication, integrity, and confidentiality services.
The following table summarizes security mechanisms introduced in the different IP Suite layers in order to be compliant with crucial requirements for secure data storage and exchange:
57/110
TCP/IP-Layer (channel)
Security
Algorithms - Mechanism for associating security tokens (XML-tokens) with messages: X.509 certificates, SAML token, username token - XML Encryption (W3C Recommendation) - XML Signature (IETF/W3C recommendation) - Digital signatures: RSA - Encryption: RC4 - Digital signatures: RSA - Symmetric encryption: RC2, DES and 3DES - Hashing: MD5 and SHA1 - Key Exchange: Diffie-Hellman and/or RSA - Symmetric encryption: DES and 3DES. RC5 for increased security. - Hashing: SHA1
Requirements Integrity, Authentication (XML signature) Confidentiality (XML Encryption)
Application WS_security (SOAP/XML over HTTPS)
Transport SSL/TLS (TCP) S/MIME
Integrity/Authenticity, Confidentiality Integrity/Authenticity, Confidentiality
Internet IPSec (IPv6)
Integrity, Authentication, Confidentiality
Table 5.7.1: Security mechanisms in the TCP/IP Suite
Due to the relevance of data exchange within the context of INDECT Portal, a specific consideration of security in EDI, as a standard for Electronic Data Interchange over the Internet (secure messages between users, applications, and computers) follows.
5.6.3 EDI Electronic Data Interchange: Security mechanisms Electronic Data Interchange (EDI) is an electronic messaging standard used in the context of e-business: Electronic data interchange for administration, commerce and Transport (EDIFACT). It refers to the transfer of structured data (standardised messages) without human intervention from one computer system to another over the Internet (open system environment). EDI offers substantial advantages and opportunities for transferring documents/data among different organisations (administrative domains). It has been presented in D6.1-4.1.2 as one of the options that may be implemented for full functionality of INDECT portal. Due to the sensitivity of the data in this context, several security functions need to be implemented in order to support operational requirements: authentication, data integrity, privacy, access control and non-repudiation concerns. Mechanisms to meet different security objectives and levels of security are specified in several messaging standards: ISO 9735: Electronic data interchange for administration, commerce and transport (EDIFACT): Rules at the application level for the structuring of data in the interchange of electronic messages between computer systems.
o Part 5: security rules for batch EDI (authenticity, integrity, and nonrepudiation of origin). o Part 6: secure authentication and acknowledgement message (AUTACK). o Part 7: security rules for batch EdI (confidentiality). o Part 9: security key and certificate management message (KEYMAN). ISO/IEC 10021-9:1999 Information technology -- Message Handling Systems (MHS): Electronic Data Interchange Messaging System. Standard SDN 701: Secure Data Network System: Message Security Protocol (MSP) MSP is in accordance with the X.400 messaging system, which allows the provision of different types and levels of security service independent of the content type of the message being transferred. The security services defined in X.400 provide the link between the security requirements and objectives as described in a security policy, and the security mechanisms (i.e., digital signatures) and management controls (i.e., for the management of public keys) to satisfy these requirements. The MSP user agent in X.400 supports message encapsulation services (security headers) prior to data transfer. Security services support confidentiality, integrity, origin authentication, access control and non-repudiation S/MIME Mail Security WG (IETF) with the following standards among others: o RFC 1421 Privacy Enhancement for Internet Electronic Mail: Part I: Encryption and authentication. o RFC 1422 Privacy Enhancement for Internet Electronic Mail: Part II: Key Management. o RFC 1423 Privacy Enhancement for Internet Electronic Mail: Part III: Algorithms and identifiers. o RFC 1424 Privacy Enhancement for Internet Electronic Mail: Part IV: Key certification and algorithms. o RFC 1847 Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted. o RFC 1848 Security services in MIME objects. o RFC 2015 MIME security with Pretty Good Privacy (PGP). Improved security for S/MIME. Cryptographic signature and Message Encryption based in PKCS (Public Key Cryptography Standards) and Cryptographic Message Syntax.
5.6.4 Access control for INDECT PORTAL In general terms, for each role there is an indirect correspondence between the users and their access rights through, either the assignation of roles to users, or the assignation of permissions and privileges to the users. Data and applications that are accessible are determined by permissions associated to roles. Restricting access based on something other than the identity of the user is generally referred to as Access Control. Some techniques that can be used for access control are DAC (Discretionary Access Control), MAC (Mandatory Access Control) and RBAC (Role Based Access Control),
59/110
that combines the advantages of the other two and avoid their limitations (DAC is too weak and MAC is not flexible at all). Role Based Access Control (RBAC): Permissions are associated to roles and users have one or more roles, thus permissions are acquired through the roles. Each role represents a functional group with similar responsibilities (case owners, co-workers, analysts, supervisors, user managers, system maintainers, portal administrators and integration maintainers as registered users of INDECT portal). The assignation of individuals to functions or work profiles is separated from the definition of the access policies, which makes the administration in the access control (hierarchical construction of the politics of access through heritage or specialization) easier. It focuses on subjects and the permissions granted to them: a user can be assigned multiple roles and thereby indirectly acquire permissions to related resources. This is a suitable solution for a portal deployed within an institution (single Police agency). Attribute Based Access Control (ABAC): All aspects of an access request are considered and identified by attributes: the subject who is demanding access, the action that the subject wants to perform, the resource being accessed and the environment or context in which access is requested. Therefore finer granularity and context-aware authorizations are required. It can be used to create portable and reusable policies, which need to be enforced consistently across multiple platforms and applications. It is tailored for inter-connected systems across several institutions. This could be useful for the long term scope of INDECT Portal: considering the cooperation of multiple security organizations. Some examples of advance authentication and access control technologies that can be also employed in this context are Single Sign-On (SSO) and Federated ID: Single Sign-On (SSO) is a way to authenticate a user in a variety of disparate systems through a single set of credentials. When the user logs into a client or terminal using her SSO-based username and password, the system validates that user's authenticity and logs in to the underlying systems with a username and password unknown to the end user. The passwords to the underlying applications can be more complex than typical passwords, since the end user doesn't have to know or remember them. This also prevents the user from logging directly into the applications, since she doesn't know the passwords for the individual applications. Instead, access to all network resources is governed by the SSO system. The SSO paradigm offers a number of benefits for users as well as for overall organizational information security. Among those benefits are that users must remember only one password, the password requirements for the applications can be arbitrary complex, which improves the protection of the information. Federated Identity is a solution for interconnecting independent identity management systems across organizations. The objective is an efficient management of users, synchronization of identifying data, access management, grouping services, directory services, audit and reports, etc. Through Federated ID individuals may use the same personal identification (user and password) to have access to networks in different departments or companies. That way, companies may share information without sharing directory, security and authentication technologies (as happened with SSO). However standards that define the mechanisms that allow
the companies to share information between domains are needed. This model can be applied to a group of companies or a big company with multiple offices and is based in a circle of trust among those. Thus users could be identified inside the community and have access to specific services. This is a suitable security mechanism in the INDECT context. A more detailed description of Federated ID will be presented in section 6.4.
5.6.5 Other threats to the Web Portal: Nowadays web sites are complex systems that are composed of many underlying technologies that may be also be the target of different attacks. Cross-site scripting (XSS) is a type of computer security vulnerability typically found in web applications which enable malicious attackers to inject client-side script into web pages to be viewed by other users. An exploited cross-site scripting vulnerability can be used by attackers to bypass access controls with the same origin policy. Their impact may become a significant security risk due to the sensitivity of the data handled by the vulnerable site (which is quite high in the part of INDECT portal only accessible by registered users); therefore there must be a strong implementation of security mitigations by the site owner (i.e. preventing HTML code in user input). SQL injection exploits vulnerabilities in the database layer of an application. When user input is incorrectly filtered any SQL statements can be executed by the application. This attack occurs when an application processes user-provided data to create an SQL statement, without first validating the input, and then submits the statement to a database server for execution. When successfully exploited, SQL injection can give an attacker the means to access back-end database content, remotely execute system commands and in some circumstances take control of the server that is hosting the database.
5.6.6 List of Security and Privacy Requisites Security is defined as part of the quality of service considered in the design of the architecture for WP6 Portal (Preliminary architecture, business and logical view, as described in D6.2 Intelligent Portal for Crisis Management [33]). There is a security Management module that supports all the security structure presented. A summary of the main system requirements, regarding the security aspects, identified during the PORTAL scenarios definition and analysis can be found bellow. The complete justification, based on the scenarios and use cases defined, can be found in the D6.1 Intelligent Crisis Management Systems Concepts and Usage Scenarios [9]. REQ-D8.1-5.6-01: Register user in the system. The administrator will also add the users profile and their corresponding permissions for the system access during the users registration process.
61/110
REQ-D8.1-5.6-02: Log and audit of users activity. The need of introducing a log system to monitor some sensitive actions in the INDECT Portal has been also clearly identified. REQ-D8.1-5.6-03: Manage content properties. Not all users can access the entire contents of the system. Content is "marked" by levels of accessing. Moreover this functionality allows categorizing the information (level of relevance, topic or event associated, etc.). REQ-D8.1-5.6-04: Edit content: Any content that is created may be modified if the user has the corresponding permission. Only authorized users can modify information, and this action will always be logged. REQ-D8.1-5.6-03: User Authentication: When a user has been registered in the system, user can access to the granted content according to their permission. For a secure authentication, different levels of user can be defined. Important information will be stored in INDECT portal, so when a new user is registered, the system administrator must validate the registration. REQ-D8.1-5.6-04: Secure access: Only users with the proper permissions can access to specific content. Moreover, the system must grant the integrity of the information, avoiding information corruption. Only authorised users can modify sensitive information. REQ-D8.1-5.6-05: System protection: The INDECT portal should be protected against malicious software, i.e. viruses, Trojans etc. REQ-D8.1-5.6-06: Content encryption: the sensitive content that is transmitted through the network must be encrypted with protocols like TLS, SSL, SET, OpenPGP, DSS, SSH, in a manner that ensures the confidentiality of the content. REQ-D8.1-5.6-07: All user input must be sanitized and validated before querying any database of generating new content for the INDECT portal. As it has been pointed out previously, the WP8 functionality will support WP6 to meet these requirements.
62/110
5.7 Biometrics and Wireless Security (WP7)

WP7 involves the monitoring of phenomena in the environment and of people behaviour in urban areas, combined with complex multimodal biometric procedures for people authentication and recognition. Due to the field of application and in connection with the scope of work within WP8, the aim of this section is to consider security and privacy issues in this environment.
5.7.1 Biometrics The role of a biometric system is to recognize a person through specific physiological or behavioural traits. There is an increased awareness of the benefits of biometric systems as a technology applied to security systems or as part of identification programs. However, they do not establish the identity of an individual in any way, they merely check that they are who they say they are (in a verification or a positive identification system), or that they were not previously known to the system (in a negative identification system). The scope and performance of a biometric system is a key requirement to support its acceptance by public opinion due to the privacy rights that must be respected. False matches or no- matches due to lack of accuracy of the systems provoke a negative reaction by citizens and have a negative effect (or no effect at all) in terms of security. The three key performance metrics of a biometrics system are False Match Rate (FMR), False Non-Match Rate (FNMR), and Failure to Enrol Rate (FTER). A false match occurs when a system incorrectly matches an identity, and FMR is the probability of individuals being wrongly matched, which may violates civil rights of individuals. This constitutes an important refrain to the open deployment of this technology. Furthermore, there are several vulnerabilities of the systems that become risks in terms of security related to the protection of the individuals: - In verification and positive identification systems, unauthorized people can be granted access to facilities or resources as the result of incorrect matches. - In a negative identification system, the result of a false match may be to deny access. There is a need for the security process to account for limitations in technology, because deploying biometrics will not automatically eliminate all security risks. Successful use of biometric systems will depend on both application type and application environment. Therefore, the design phase will be determinant (activation quality of any biometric system will also depend on the application type). Moreover, efficiency will not be achieved if the technological solution is deployed in isolation, unless a continuous following and enforcing process regarding policies and procedures is considered. Alongside with this, there is ongoing work related to standardization of biometrics and therefore specify recommendations regarding functional security requirements for validating the systems. With a broad view on security related issues within the scope of WP7, and in order to support the capture and further processing of security information in urban environments, one of the main objectives to be accomplished within WP7 will be the integration of security systems with emergent wireless communication systems and self-organising computer networks.
The basic structure of the integration platform is described in D7.1 deliverable [34], where, by means of a graphical user interface, the workflow that needs to be considered in the implementation of a tailored security framework is presented. The interconnections describe the transfer of data and the corresponding interfaces between different applications and the data base with all the information to be shared among applications. There are a wide variety of devices and applications that capture and process the security information from the environment. Some examples are: modules for face or sound/speech recognition and for object tracking, cameras for surveillance, or devices for video recording. All the systems that need to be connected are specified in D7.1- 4.2 (External systems). They refer to the aforementioned applications and they are connected to the platform through node stations and wireless communication. 5.7.2 Secure Wireless Communications Within INDECT project all the communications between systems are based on the Internet Protocol suite, although a mapping to the OSI model could be also considered. For the defined communication requirements, the expected performance could be obtained using one of the following options on the link layer: Wireless Local Area Network (WLAN) according to IEEE 802.11 protocols Global system for mobile communications (GSM) with its extensions: GPRS and UMTS. Those communication media will need to comply with the following security requirements: Secure communications: assure integrity, authenticity, confidentiality and nonrepudiation of messages. Secure system: For the storage and the manipulation of the information (physical protection, authentication and aces control). Privacy: the identity of the peers of a private communication, as well as its content should be kept secret. Unless there is some legal circumstance that avoids this. 5.7.3 Security of IEEE 802.11 protocols In a wireless network it is very difficult to restrain and direct the range of the transmitted signals. Secure wireless communication relies on software link-level protection implementing cryptography to protect from network attacks (e.g. eavesdropping). The original IEEE 802.11 standard only offered WEP (Wired Equivalent Privacy) to secure the wireless network (encryption, authentication and key management). An introduction to WEP and its vulnerabilities follows, as well as a further description of IEEE 802.11i as the solution proposed later to overcome those. IEEE 802.11i is based on the Wi-Fi Protected Access (WPA), which was proposed as a quick fix for WEP weaknesses.
Wired Equivalent Privacy (WEP) Initially it was the only link-level security option defined in the 802.11 standard. Its main purpose was the protection of the confidentiality and integrity of wireless network traffic. WEP was designed to provide comparable confidentiality to a traditional wired network. To meet the proposed security requirements, WEP uses encryption to protect the data. It uses the RC4 stream cipher with a 64 or 128 bits key to provide data packet encryption (the effective key is even smaller because part of the WEP key is transmitted in clear text along with the data packet). In addition, WEP can be used as an access control mechanism, because once WEP is active, the Access Point will just establish communication with nodes that have the same shared secret key, rejecting others. In a WEP-protected wireless network, every member of this wireless cell shares the same secret key with the Access Point. In a WEP-protected wireless network, a data packet that gets into the link-level is encrypted before sending it off the air. The following diagram outlines the procedure for data packet encryption:
WEP Key (IV+ shared key)
RC4
Pseudo-random string (n bytes length)
Encryption: Plain Text Data Packet (n bytes length) Decryption: Encrypted Data Packet (n bytes length)
Encrypted Data Packet
XOR
Plain Text Data Packet
Figure 5.7.1: WEP Encryption/Decryption Process. (Black) Common steps, (Red) Encryption Process, (Blue) Decryption Process
WEP protocol contains a critical cryptographic weakness that allows an attacker to possible recover the shared secret key. There are several ways for an attacker to break into a wireless network (without knowing the shared secret key) just by passively capturing a large amount of data packets. Some of them are based on Web Key Recovery or IV Collision. A way to prevent the recovery of the secret key, without making any other vulnerability even worse, is by changing the shared secret key frequently (before the attacker could get enough data packets to crack the secret key). A solution for this is using the 802.1x protocol to provide automatic key delivery and periodic rekeying. With Dynamic-WEP the authentication server generates the WEP key whenever a user is authenticated and authorized
65/110
WPA (Wi-Fi Protected Access) WPA is a temporal solution proposed by the WiFi Alliance while a definitive security protocol is standardized. This protocol is based on IEEE 802.11 wireless network security protocol standard. It consists of three main components: TKIP, 802.1x, and MIC. Each of those components was designed and implemented to address specifics 802.11 weakness. One of the main security improvements is the introduction of a key hierarchy. TKIP (Temporal Key Integrity Protocol) This data-confidentiality protocol was designed to improve the security of legacy products that only implemented WEP. It addresses main WEP vulnerability maintaining compatibility with existing IEEE 802.11 hardware. It uses a message integrity code called Michael, which enables devices to verify that the packets are coming from the claimed source. Also TKIP uses a mixing function to defeat weak-key attacks, which allows attackers to easily decrypt traffic. MIC (Message Integrity Code) MIC is a keyed hashing function that protects data packet integrity. This is an 8-byte value, which is calculated across the entire unencrypted raw data packet before being encrypted and transmitted. The main purpose is to detect any kind of packet modification. The hashing function used by MIC is a new hashing function specially designed for low processing power devices, such as the hardware in wireless network interfaces. This gives low protection, thus WPA also relies on countermeasures against attacks that modify the data packets. The potential danger of MIC countermeasures is that they can be used for launching a denial of service attack to the wireless network by forging invalid data packets, making the Access Point to enforce the countermeasures continuously. 802.1x Port based Network Access Control 802.1x is a protocol designed to protect a network from the user link point, such as a port of a switch in a wired network, or the access point in a wireless network. This protocol has been implemented in dynamic WEP. WPA and 802.11i standard protocol implement this 802.1x protocol to improve the access control security to the wireless network. It offers an effective framework for authenticating and controlling user traffic towards the protected network, as well as dynamically varying encryption keys. 802.1x ties a protocol called EAP (Extensible Authentication Protocol) to both the wired and wireless LAN media, and it supports multiple authentication methods. EAP encapsulation over LANs (EAPOL) is a key protocol in IEEE 802.1x used for key exchange IEEE 802.11i defines two main EAPOL-key exchanges (first referred to as the 4-way handshake and second as the group key handshake) WPA-PSK (WPA Pre-Shared Key) WPA offers a special mode where there is no 802.1x authentication infrastructure, permitting the use of a pass phrase as a pre-shared key. Every station may have its own pre-shared key tied to its MAC address, but most of the manufacturers implement only one pre-shared key for the whole wireless network. The configuration of this mode is very similar to WEP, in which a user only needs to introduce a passphrase. A weakness has already been found on
this WPA operation mode. If the pre-shared key is configured with a weak pass phrase, an attacker can capture the authentication messages and then made an offline recovery of the passphrase. 802.11i security standard Furthermore, the IEEE 802.11i standard provides an algorithm for compliant client cards and access points to negotiate which protocol is used during specific traffic circumstances, and to discover any unknown security parameters (e.g. there are several protocols for data confidentiality). The key components provided by IEEE 802.11i are: Temporal Key Integrity Protocol (TKIP), IEEE 802.1x and WPA/PSK previously described. WRAP (Wireless Robust Authenticated Protocol): Encryption protocol based upon the Offset Codebook (OCB) mode of AES. Intellectual property issues (different parties filing for patents on WRAP) caused the IEEE to introduce CCMP into the 802.11i standard and make WRAP an optional component of RSN (Robust Secure Network) Counter-Mode/CBC-MAC Protocol (CCMP: Counter mode with Cipher-block chaining-Message authentication code): Data-confidentiality protocol that handles packet authentication as well as encryption. It may be useful for encryption because it generates MIC (Message Integrity Code) at the same time. For confidentiality, CCMP uses AES in counter mode. For authentication and integrity, CCMP uses Cipher Block Chaining Message Authentication Code (CBC-MAC). In IEEE 802.11i, CCMP uses a 128-bit key. CCMP protects some fields that aren't encrypted. The additional parts of the IEEE 802.11 frame that get protected are known as additional authentication data (AAD). AAD includes the packets source and destination and protects against attackers replaying packets to different destinations. 5.7.4 Security in GSM/GPRS/UMTS Security is needed to provide the customer of a cellular network with anonymity and privacy when making a call, to ensure the network operator bills the correct customer, and to make sure that operators don't interfere with each other either accidentally or intentionally. The security logic ruling user and network authentication, as well as the data ciphering, in the GSM architecture is characterized by the transactions between three nodes of the system: the SIM in the Mobile Station (MS), the visited Mobile Switching Centre (MSC)/Visited Location Register (VLR), and the Authentication Centre (AuC), which is attached to the Home Location Register (HLR) in most cases. These three nodes (MS, VLR, and HLR) are also involved in the authentication and data ciphering procedures. GPRS and UMTS architectures follow the heritage of the GSM's philosophy regarding the user/network authentication and the data ciphering. That is, UMTS security builds on top of GSM security, inheriting the proven GSM security features.
67/110
Security in GSM The first thing the network must do is identify and authenticate the customer. To do this the network sends a 128-bit challenge to the customer phone. The SIM in the phone then uses the A3 algorithm and the Individual Subscriber Authentication Key (Ki, unique to every different SIM) to compute a Signed RESponse (SRES) and sends it back to the base station. If the SRES matches the pre-computed value in the base station, then the user is authenticated and the next step takes place. Here the SIM uses a different algorithm, A8, Ki and the original challenge to compute a Session Key (Kc) and sends this to the base station. This session key is now used along with the A5 algorithm to encrypt the data for over the air transmission. This process is illustrated in the following picture:
Figure 5.7.2: Encryption procedure in GSM networks (Source: http://www.cs.huji.ac.il/~sans/ students_lectures/GSM%20Security.ppt)
The A3 and A8 algorithms implemented on the SIM are usually used together as one algorithm (A38) to compute SRES and Kc in parallel. These two algorithms use COMP-128 a keyed hash function (the specification for COMP-128 is readily available on the Internet). On the contrary, the design of A5 algorithm (stream cipher very efficiently implemented in HW) was never made public. Nowadays all these algorithms are considered weak because they can be cracked fairly easily. Better cryptographic algorithms will be discussed in Section 6.2 Regarding the equipment security, all handsets have an International Mobile Equipment Identity (IMEI) number that is stored in the Equipment Identity Register (EIR). This number is totally independent of the SIM and completely unique. For the individuals, they can be identified by the International Mobile Subscriber Identity on their SIM. Temporary IMSI is sent when communicating with the base station to avoid eavesdropping when the phone is switched on, or a call is being initialised.
68/110
Security in UMTS UMTS also provides a solution to the weaknesses of GSM security and adds security features for new 3G radio access networks and services. Unlike GSM, which has authentication of the user to the network only, UMTS uses mutual authentication which means the mobile user and the serving network authenticate each other, providing security against false base stations. This mutual authentication uses an authentication quintet which helps to ensure that a bill is issued to the correct person. The authentication quintet consists of the user challenge (RAND), expected user response (X(RES)), the encryption key (CK), the integrity key (IK) and the authentication token for network authentication (AUTN). UMTS also provides a new data integrity mechanism, which protects the messages being signalled between the mobile station and the radio network controller (RNC). The user and network negotiate and agree on cipher and integrity algorithms. Both the integrity mechanism and enhanced authentication combine to provide protection against active attacks on the radio interface.
USIM: User Service Identity Module K: Subscriber Authentication Key SQNms: Sequence number information at user SQNhe: Sequence number information at home system UE: User Equipments / SIM VLR: Visitor Location Register HLR/AuC:Home Location Register/Authentication Centre
Figure 5.7.3: Enhanced integrity and authentication in UMTS (Source: http:www.isrc.rhul.ac.uk/useca/OtherPublications/IIR-overview.pdf)
UMTS provides enhanced encryption which ensures that messages are not available to unauthorized users. In UMTS, encryption is processed by the Radio Network Controller (RNC) rather than by the base station, as is the case with GSM. The improved confidentiality has been achieved by using longer encryption keys, which (along with other UMTS security functions) are easier to upgrade than the GSM counterpart. It is clear to see UMTS boasts many security advantages over GSM including a data integrity mechanism, enhanced authentication and encryption, identity confidentiality, a potential for secure roaming and greater facilities for upgrading. However UMTS also has some security problems. For example, if encryption is disabled, then call hijacking is possible. Also, if the user is drawn to a false base station, then she is beyond reach of the paging signals of the serving network. Finally when the user is
registering for the first time in the serving network the permanent user identity (IMSI) is sent in cleartext.
5.7.5 List of Security and Privacy Requisites REQ-D8.1-5.7-01: INDECT Biometrics systems must achieve a low false non-match rate and even lower false match rates in order to limit the number of false negative and false positive events. False negatives may impact the security of the system, whereas false positives may generate false alarms that waste resources because they usually require additional checks. REQ-D8.1-5.7-02: A person shall not be enrolled into a biometric system that may interfere with his or her privacy or other civil liberties without the authorization of a judge or other competent authority. Also, the scope of the biometric supervision must be proportional to the mischief being considered. REQ-D8.1-5.7-03: Mobile INDECT stations or other devices that employ wireless communication technologies must implement strong security mechanisms. WEP and WPA are strictly forbidden for WiFi devices. WPA2 support is a mandatory requirement for all INDECT WiFi-enabled devices. REQ-D8.1-5.7-04: As an additional security layer, all data communications over wireless links (i.e. WiFi, GSM/GPRS, UMTS) must be encrypted employing a secure VPN tunnel (e.g. IPSec or SSL VPN).
70/110
6 Security and Privacy Requirements for INDECT Security Technologies

6.1 Virtual Private Networks (VPN) (T8.1)
Given the distributed nature of INDECT, with agents interconnected over public networks (Internet, wireless broadcast, etc), the use of VPNs will be required in many cases. This section provides a short review of current VPN (Virtual Private Network) technologies and how they can be used to secure data transmission over a public network infrastructure. There are many advantages and disadvantages for different VPN solutions, thus there is no one-size-fits-all VPN solution. Instead different optimal VPN solutions can be employed for each scenario. Additional information about VPN technologies can be found in [10], [11].
6.1.1 General description of a VPN A Virtual Private Network (VPN) is a means to securely and privately transmit data over an unsecured and shared network infrastructure. VPNs secure the transmitted data by encapsulating the data, encrypting the data, or both encapsulating the data and then encrypting the data. Encapsulating is often referred to as tunnelling because data is transmitted from one network to another, transparently across a public network infrastructure. VPN is typically a protected connection between two entities (specific devices or particular networks) that are not necessarily directly connected. A good VPN solution should address most of the following issues: Protecting data from eavesdropping by using encryption technologies. Protecting packets from tampering by using packet integrity hashing functions. Protecting against man-in-the-middle attacks by using identity authentication mechanisms. Protecting against replay attacks by using sequence numbers when transmitting protected data. Defining the mechanics of how data is encapsulated and protected, and how protected traffic is transmitted between devices. Defining what traffic actually needs to be protected. Not every VPN implementation should include all of these components or does not implement them as securely as other VPNs. Therefore, it is very important to define a security policy in order to determine what VPN technology is most suitable for a particular situation. It is often possible to use more than one VPN solution being deployed in the same network.
6.1.2 VPN Components The following sections will discuss some of the important components that are
typically part of a VPN implementation [10]: Authentication Encapsulation Method Data Encryption Packet Integrity Key Management Non-Repudiation Application and Protocol Support Authentication There are two types of authentication concerning VPN device authentication and user authentication: Device authentication allows restricting or permitting VPN access to the private network based on authentication information from a remote VPN device. For this purpose, pre-shared keys, digital signatures or digital certificates are used. Many VPN implementations add an additional type of authentication, called user authentication, to verify whether or not a VPN connection is allowed for the user. Normally this is used in remote access VPNs. With user authentication, the VPN user must usually supply a username and a password. This password can be a static password or a one-time password (through the use of a security token or card). Encapsulation Method An encapsulation method defines how user information should be encapsulated and transported across a network. Encapsulation also defines what can be placed in the payload of a VPN packet. Some VPN implementations encapsulate only application layer information, whereas others can encapsulate an entire layer 3 packet or layer 2 frame. How information is encapsulated is an important issue because it can affect whether or not data might experience problems with firewall or NAT devices. Data Encryption Data encryption is used to solve eavesdropping issues. Many encryption algorithms exist, such as 3DES, AES, RSA, SEAL, RC4, etc. However, not every VPN implementation supports all encryption algorithms. Packet Integrity Because of the possible packet tampering and packet spoofing, some VPN implementations give the option of performing packet integrity checking. With packet integrity check, a digital signature is attached to the packet. SHA and MD5 are examples of hashing functions used for packet integrity checking. Key Management It is also necessary to consider various forms of the key management for VPNs. Keys can be configured statically or generated dynamically. The important question is also how often it is necessary to change these keys.
Non-Repudiation In the VPN, non-repudiation involves two components Authentication and Accounting. Authentication was described earlier. Accounting is the recording of the VPN session. This can include the identities of the two devices establishing the connection, how long the connection was used, how much information was transmitted across it, what types of information traversed the connection, and so on. This can then be used to detect access attacks and for management purposes. Application and Protocol Support When choosing a VPN implementation, it is necessary to determine what kinds of traffic need to be protected (e.g. all IP traffic or traffic for specific applications, such as web and e-mail traffic). This can affect the choice while choosing a VPN solution.
6.1.3 VPN Technologies The following sections will discuss popular VPN implementation methods, including how they are implemented, and their basic advantages and disadvantages. Popular VPN technologies are: GRE PPTP L2TP MPLS IPSec SSL Generic Route Encapsulation (GRE) GRE is an encapsulation that enables to transport non-IP packets across an IP backbone. GRE can encapsulate many protocols IP, IPX, bridged traffic, CLNP, etc. On the other hand, GRE lacks protection capabilities, such as authentication, encryption and packet integrity checking. Therefore, GRE is typically not used alone, but it can be combined with another protocol, such as IPSec, to create more robust and scalable VPN solution. Point-to-Point Tunnelling Protocol (PPTP) PPTP is a data-link layer VPN technology that was developed by Microsoft. PPTP is used mainly as a remote access protocol. It allows Windows PC clients secure access to a network access server. Unlike IPSec, PPTP supports multiple protocols IP, IPX, and NetBEUI. Layer 2 Tunnel Protocol (L2TP) To provide an alternative solution to IPSec for smaller Windows PC-based environments, Microsoft, Cisco, and other vendors develop a standard that would allow all network vendors to produce compatible VPN products. L2TP is a data-link layer VPN technology that tunnels PPP over a public network, and provides services such as data confidentiality. L2TP supports multiple network layer protocols.
73/110
Multiprotocol Label Switching (MPLS) VPN MPLS VPN separates traffic of different users by using virtual channels. This is implemented by the tagging information in the MPLS label which is added to the transported data. On the other hand, the data is not encrypted. This can be solved by another VPN technology, such as IPSec over MPLS. MPLS supports multiple protocols, such as IP, Ethernet or ATM. Internet Protocol Security (IPSec) Like GRE, IPSec is a network-layer protocol. IPSec supports only TCP/IP protocols it cant natively transport protocols like IPX. However, it is possible to deploy a GRE tunnel through an IPSec VPN connection for non-TCP/IP traffic. IPSec was designed specifically to deal with moving sensitive data securely across an unsecured network. The framework of IPSec deals with three main issues data confidentiality, integrity, and authentication. For data confidentiality, IPSec supports DES, 3DES, and AES encryption algorithms. For data integrity, IPSec uses MD5 and SHA hashing functions. Three types of device authentication are supported pre-shared keys, RSA encrypted nonces, and RSA signatures (digital certificates). As compared to other VPN implementations, IPSec is the most popular and most widely deployed VPN technology because it is based on a set of open standards. Secure Socket Layer (SSL) SSL is a technology to encrypt data sent via a web browser connection. However, networking vendors have enhanced SSL to provide SSL-based VPNs. SSL VPNs are used as a remote access VPN solution. Other types of VPNs, such as IPSec, PPTP, and L2TP, require special client software to be installed on the remote access client. This requires special configuration and additional management. With clientless SSL VPNs, a user employs a web browser as the client software. And because most users have a web browser already installed on their PCs, there is no special client software involved to use the SSL VPN. Clientless SSL VPNs, however, have one limitation: only web-based applications can be protected. Other applications can be protected if the web browser is enhanced by a special Java or ActiveX applet that implements SSL tunnelling.
6.1.4 Choosing a suitable VPN To choose the most suitable VPN solution, it is necessary to consider following criteria [10]: Security. Implementation, Management, and Support. High Availability. Scalability and Flexibility. Cost. Security First, it is necessary to determine what data needs to be protected. If it is necessary to protect traffic for specific web applications, such as e-mail, file transfer, and others, it can be the best solution the SSL VPN. If it is necessary to protect all traffic for
specific hosts or network segments, it is probably better to use another type of VPN like IPSec. Second, it is necessary to consider what kind of protection is required encryption, packet integrity checking, authentication. And third, how much protection is needed? It means that it is necessary to choose a sufficiently strong encryption algorithm (3DES, AES) and a reliable authentication method (pre-shared keys, digital certificates). Implementation, Management, and Support Different VPN solutions have different demands on implementation, management, and support. For example, SSL VPNs are easier to set up, manage, and troubleshoot compared to IPSec. Regarding key management, certificates from a PKI are usually easier to manage and distribute than pre-shared keys. High Availability Some VPN implementations support redundancy but some others dont. When evaluating a redundancy solution, it is necessary to determine the type of redundancy you need chassis redundancy, connection redundancy and how well different VPN implementations can deal with the specific redundancy method. Finally, a networking vendor can have some other proprietary redundancy feature. Scalability and Flexibility When choosing a VPN implementation, it is convenient to ensure that the chosen solution is scalable and flexible. The solution needs to be scalable to accommodate the future growth of the network and flexible to deal with changes that occur within the network. In other words, if it is needed to add more sites to the VPN design, it is necessary to consider how much work it is required to perform this change, how many devices are needed to configure or reconfigure, how much configuration has to be performed on these devices, whether additional overhead can affect existing devices, etc. Cost Some costs that need to be evaluated are: Hardware devices Software products, including remote access clients and management (some vendors charge for remote access client software) Network vendor maintenance and support costs Personnel costs and personnel training costs Bandwidth for the VPN traffic and overhead
6.1.5 List of Security and Privacy Requirements REQ-D8.1-6.1-01: Data transmitted through a public or unsecure network should be protected from eavesdropping. REQ-D8.1-6.1-02: Data transmitted through a public or unsecure network should be protected from tampering.
REQ-D8.1-6.1-03: Data transmitted through a public or unsecure network should be protected against man-in-the-middle attacks. REQ-D8.1-6.1-04: Data transmitted through a public or unsecure network should be protected against replay attacks. REQ-D8.1-6.1-05: It should be defined how data is encapsulated and protected, and how protected traffic is transmitted between devices. REQ-D8.1-6.1-06: It should be defined what traffic actually needs to be protected (data about employed applications and protocols is required). REQ-D8.1-6.1-07: It should be predicted how much traffic needs to be protected. REQ-D8.1-6.1-08: It should be chosen an appropriate authentication method. REQ-D8.1-6.1-09: It should be chosen appropriate encryption algorithms (symmetric and asymmetric). REQ-D8.1-6.1-10: It should be chosen an appropriate hashing function. REQ-D8.1-6.1-11: It should be chosen an appropriate accounting method. REQ-D8.1-6.1-12: It should be chosen an appropriate key management method. REQ-D8.1-6.1-13: It should be considered the addressing of the network (public or private addresses, with or without NAT, IPv4 or IPv6). REQ-D8.1-6.1-14: It should be chosen an appropriate topology of the VPN. Point-toPoint, Mesh and Hub-and-Spoke are common VPN topologies. REQ-D8.1-6.1-15: An appropriate VPN technology should be chosen from the above requirements. REQ-D8.1-6.1-16: It should be considered an availability, scalability and flexibility of the chosen VPN implementation. REQ-D8.1-6.1-17: It should be considered how demanding is the implementation, management, and support of the chosen VPN implementation. REQ-D8.1-6.1-18: It should be considered the overall cost of the chosen VPN solution and its maintenance. Personnel costs and personnel training costs should be also considered.
6.2 Cryptographic Algorithms (T8.2)

This section reviews security basics of cryptographic algorithms, symmetric and asymmetric ciphers as well as key management issues, in order to properly define the requirements for the cryptographic algorithms to be employed and even investigated by INDECT project. 6.2.1 Basic cryptographic algorithms definitions The cryptographic algorithms are mainly applicable for: Providing data confidentiality, privacy and data integrity Identification and authentication processes. The cryptographic algorithm (cipher) is a mathematical function where one of the parameters is named key. The key is a binary string which is used for encrypting and decrypting. To encrypt the plain-text an encrypting algorithm is applied. To decrypt the ciphered text a decryption algorithm is applied. Formally, we can present: Encryption: Ek(M)=C, Decryption: Dk(C)=M, Then: Dk(Ek(M))=M Where M is plain-text (non-encrypted message); C is encrypted message; k is key, used during the encryption and decryption operations [12]. We can specify two types of cryptographic algorithms: symmetric and asymmetric.
6.2.2 Symmetric ciphers In symmetric algorithms the encryption key can be calculated from the decryption key and vice versa. In most of the cases the encryption and decryption keys are the same. Symmetric algorithms, which are also called secret key algorithms, require that both the sender and the recipient have in advance the respective keys and they are responsible to keep them in secret. The security of the symmetric algorithms is based on the key. If the secret key is found, everyone is able to encrypt and decrypt any message. Data Encryption Standard (DES) The Data Encryption Standard, as specified in FIPS Publication 46-3, is a block cipher operating on 64-bit data blocks. The encryption transformation depends on a 56-bit secret key and consists of sixteen Feistel iterations surrounded by two permutation layers: an initial bit permutation IP at the input, and its inverse IP 1 at the output. The decryption process is the same as the encryption, except for the order of the round keys used in the Feistel iterations. The 16-round Feistel network, which constitutes the cryptographic core of DES, splits the 64-bit data blocks into two 32-bit words (denoted by L0 and R0). In each iteration (or round), the second word Ri is fed to a function f and the result is added to the first word Li. Then both words are swapped and the algorithm proceeds to the next iteration. One purely algorithmic description of the DAS algorithms is given in [14]. Nowadays DES is considered a weak cipher and has been replaced by newer algorithms such as 3DES or AES.
Triple DES (3DES) The idea behind Triple-DES is to increase the number of DES encryptions three times with two or three different keys. This method gains strength both against cryptanalytic attacks as well as against exhaustive search. It is weak against related key attack and the speed is three times slower than single DES.
Figure 6.6.1: Triple DES [15]
In general, the Triple-DES encryption algorithm consists of three applications of DES. The ANSI X9.52 variant is defined as: C = EK3 (DK2 (EK1 (P))), where P and C are 64bit plaintext and ciphertext blocks, and EK() and DK() denote the DES encryption and decryption functions. The standard specifies three different ways of choosing the 56-bit keys K1, K2, and K3: Keying Option 1: K1, K2, and K3 are independent (168 secret bits). Keying Option 2: K1 and K2 are independent, K3 = K1 (112 secret bits). Keying Option 3: K1 = K2 = K3 (56 secret bits).
Advanced Encryption Standard (AES) On January 2, 1997, the United States' National Institute of Standards and Technology (NIST) announced the initiation of a new symmetric-key block cipher algorithm as the new encryption standard to replace the DES. The new algorithm would be named the Advanced Encryption Standard (AES). The call stipulated that the AES would specify an unclassified, publicly disclosed symmetric-key encryption algorithm(s); the algorithm(s) must support (at a minimum) block sizes of 128-bits, key sizes of 128-, 192-, and 256-bits, and should have a strength at the level of the triple DES, but should be more efficient than 3DES. In addition, the algorithm(s), if selected, must be available royalty-free, worldwide [17]. AES, originally published as Rijndael, is a block cipher with a variable block size and variable key size. The key size and the block size can be independently specified to 128, 192 or 256 bits. In the simplest scenario we have 128-bit key size and the same block size. In this case, a 128-bit message (plaintext, ciphertext) block is segmented into 16 bytes (a byte is a unit of 8 binary bits, so 128 = 16 x 8) [16]. Table 6.2.1 presents different types of AES algorithms.
78/110
AES Parameters Key size (words/bytes/bits) 4/16/128 6/24/192 8/32/256
Plaintext block size (words/bytes/bits) 4/16/128 4/16/128 4/16/128 Number of rounds Round key size (words/bytes/bits) Expanded key size (words/bytes) 10 12 14
4/16/128 4/16/128 4/16/128 44/176 52/208 60/240
Table 6.2.1: AES algorithm parameters [15]
Rijndael algorithm was designed to have the following characteristics: Resistance against all known attacks, Speed and code compactness on a wide range of platforms, and Design simplicity.
6.2.3 Asymmetric ciphers In asymmetric algorithms, which are called also algorithms with public keys, the encryption and decryption are made with two different keys a private key and a public key. In addition to this, the decrypting key cannot be calculated from the encryption key. The encryption key is called public and it is not necessary to kept in secret. Everyone can use it for encryption, but only the one who has the respective decryption key can decrypt the message. The decryption key is called personal or private [12]. We can encrypt messages by means of the asymmetric ciphers, as well as to authenticate a user in possession of the private key. RSA algorithm The most popular public-key cryptosystem is RSA, named after its inventors Rivest, Shamir and Adleman. RSA scheme is a cipher in which the plaintext and ciphertext are integers between 0 and n-1 for some n. A typical size for n is 1024 bits (n < 21024), or 309 decimal digits. The scheme developed by Rivest, Shamir, and Adleman makes use of an expression with exponentials. Plaintext is encrypted in blocks, with each block having a binary value less than some number n. That is, the block size must be less than or equal to log2(n). In practice, the block size is i bits long, where 2i < n 2i+1. Encryption and decryption are of the following form, for some plaintext block M and ciphertext block C: C = Me mod n M = Cd mod n = (Me)d mod n = Med mod n Both sender and receiver must know the value of n. The sender knows the value of e, and only the receiver knows the value of d. Thus: Public key is: PU = {e, n} and Private key is PU = {d, n}.
For this algorithm to be satisfactory for public-key encryption, the following requirements must be met [15]: It is possible to find values of e, d, n such that Med mod n = M for all M < n, It is easy to calculate mod Me mod n and Cd mod n for all values of M < n, It is infeasible to determine d given e and n.
6.2.4 Key management Different cryptographic systems have different levels of security, depending on how difficult it is to break them down and how long the encryption key is [20]. Thus, the security of one symmetric cryptographic system is a function of: Strength of the algorithm. Length of the key. Brute-Force Attack Let assume that a brute-force attack (check of all possible keys) is only effective (possible) for breaking one cryptographic system, naturally a lot of question appear How much time will be necessary? and How much will it cost? Two are the parameters defining the time of a successful direct (brute-force) attack: Number of keys for check. Speed (time) for one check. The selection of the key length for the specific application depends on the time we want the data to be protected and on the value of those data. Key management In real life the key management of a cryptographic system is one of the most important aspects of its security. Introduction of secure management of keys is crucial and often the attacks to cryptographic system are directed to the weaknesses in the key management [20]. In computer systems the key management is normally done by means of a Key Management Center. Key management implies: Generation. Distribution. Use. Storage. Time (period) of use. Change. Destruction. Key Generation The strength of one cryptographic algorithm is based on the key. That is why the key generation is the first problem to solve. Too often some bad practices are used [12]: Reduction (limitation) of the key length. Selection of a bad (weak) key.
ANSI X9.17 standard defines one method for generation of good keys and includes the use of cryptographic algorithms. Key distribution The key distributions security is covered via the use of [19, 20, 31]: Master key or key encryption key. Crypto algorithms with public keys (especially important for big computer networks). Use of the keys The use of software tools for encryption carries some risks. The availability of multiusers and multi-task operation systems is a precondition for compromising the key. The use of hardware solutions is preferred, but it is much more expensive. Key storage The possible solutions for key storage are: Remembering the key impossible for real systems. Storage of the key on a separate technical media (electronic or magnetic), sometimes consisting of two or more parts. Storage of the key in an encrypted format. Combination of methods. Time (period) of use of keys There is no cryptographic system with unlimitedly long period of use of keys. Always there is a policy, defining the period of use of different keys. The criteria for definition of this period are different: Depending on the purpose. Depending on the frequency of use. Depending on the type of the crypto algorithm. Destruction of keys The change of keys presumes the destruction of old keys. Methods of destruction have to prohibit the second use of the old keys. In the computer networks some problems may appear because of [20, 21]: The possibility that the keys to be easily copied and stored in many different places. Existence of memory controlling processes. Existence of swapping processes. Existence of buffering. Therefore it is necessary to create a model of distribution of keys, addressing the following requirements [19, 22]: Users characteristics are changed often;
Users do not have access to the Distribution, Control or Translation centers; Users communicate via open (non-secured) channels. Taking into account the complexity and the wide range of the INDECT system, as well as the big number and variety of end-users devices, we consider that the most favourable approach for creation of cryptographic Key Distribution and Management Center is the combined method. The center could support both symmetric and asymmetric algorithms. Additional functionality could be digital certification. It is worth to mention that some devices, i.e. video cameras, support this technique.
6.2.1 List of Security and Privacy Requirements REQ-D8.1-6.2-01: Private and confidential data should be encrypted. REQ-D8.1-6.2-02: The cipher algorithms employed to ensure data confidentiality must be strong and must not have any backdoors allowing decrypting data without the key. REQ-D8.1-6.2-03: Cryptographic algorithms should support the shared key service to ensure multiuser encryption. REQ-D8.1-6.2-04: The security of cipher must be based on the strength of the algorithm (must not be only based on the secrecy of the algorithm). REQ-D8.1-6.2-05: Symmetric ciphers instead of asymmetric ciphers should be used when performance of the system is crucial. REQ-D8.1-6.2-06: Keys should be generated by means of random number generators. REQ-D8.1-6.2-07: The policy of key management should be adequate to security level of the system and used security techniques. REQ-D8.1-6.2-08: The encryption keys in symmetric algorithms which are used to ensure data confidentiality should have 128 bits at least. REQ-D8.1-6.2-09: The encryption key in asymmetric algorithms which are used to ensure data confidentiality should have 2048 bits at least. REQ-D8.1-6.2-10: The encryption key in asymmetric algorithms which are used to ensure key negotiation should have 4096 bits at least. REQ-D8.1-6.2-11: For key negotiation a secure private channel or asymmetric algorithms should be used.
82/110
6.3 Quantum Cryptography (T8.3)

Nowadays, Quantum Cryptography (QC) is becoming a well known technique among researchers who are involved in system security and data confidentiality assurance. QC provides unbreakable communication via optical or wireless links. Usually, it is based on phase-encoding of the photons that are transmitted over a dedicated optical fiber, called dark fiber. QC ensures the highest security level, because it is not possible to eavesdrop the communication in a passive way. If an eavesdropper reads the data being transmitted, it will change the quantum states of the photons and he will be uncovered. A lot of Quantum Key Distribution (QKD) algorithms (i.e. BB84, E91, B92) have been designed, and many different QC devices (e.g. produced by idQuantique, SmartQuantum, MagiQ) have been constructed. Because QC is moving outside the research laboratories, it is now possible to apply this technique in practice. The crucial issue is the integration of QC with existing optical networks, because building additional optical infrastructure in metropolitan areas is very expensive. This is a reason why currently even institutions such as banks, big corporations or public administrations are not able to use quantum cryptography in practice.
Figure 6.3.1: Process of key establishment between Alice and Bob by means of BB84 protocol. The symbol means rectilinear basis and the symbol means diagonal basis. The double headed arrows represent the polarization states of individual photons
Although there are several QKD protocols, the most popular is still the BB84 protocol based on phase-encoding of the photons. In figure 6.3.1, the example process of key establishment between Alice and Bob is presented. When Alice wants to establish with Bob new secret key to encrypt data by means of a symmetric cipher, they define that photons with polarization 0 and -45 mean 0 and photons with polarization 90 and 45 mean 1. Now Alice sends to Bob some string of bits which is encoded by means of the polarization of photons. Bob receives this string employing a rectilinear basis (allows detecting perfectly polarizations: 0 and 90) or a diagonal basis (allows detecting perfectly polarizations: -45 and 45). Bob chooses his basis randomly but after, he informs Alice of all basis he has used. The new key consists of that bits for which Bob has chosen properly basis. The passive eavesdropping is not possible because when an intruder wants to receive photons, it will change quantum states of
photons. Besides, quantum mechanics do not allow cloning the unknown state of a photon. But the BB84 protocol is not only one algorithm which is exploited in QC. Another example is the B92 algorithm, which is similar to the BB84 coding scheme but only uses 2 out of the 4 BB84 states. It encodes classical bits in two non-orthogonal BB84 states. There is a completely different family of QC algorithms that are based on quantum entangled photon pairs. An entangled photon pair is a pair of photons with a unique correlation, such that the property of one photon is automatically and instantly determined at the moment the other photons property is measured, while their properties are ambiguous in principle before the measurement. Formally an entangled state can be presented as:
1 (| 2
| 1 |
)
|
2
It means that only two states are allowed: |
or | 1 |
Coefficient
1 / 2 means that probability of both states always amounted to 50%.
Although there are still a lot of problems with deploying the QKD in real optical or wireless communication networks, we can exchange information secured by means of the QC in specific environments. The QC in optical networks will be possible if we solve a few practical problems and meet some specific requirements. 6.3.1 System requirements We call system requirements to the requirements that express desirable system properties. They are important because, on the one hand, system requirements should lead to the achievement of some user requirements and, on the other hand, should indicate how to archive the optimal solution from the available technology point of view.
Confidentiality
One of the security dimensions presented in ITU-T recommendation X.805 is confidentiality of information transmitted in communication system. The best way to ensure confidentiality is data encryption. Currently, network communications are often protected using a symmetric encryption algorithm, like AES (Advanced Encryption Standard) or 3DES (Triple-DES). The security of these algorithms depends on the fact that the key is secret. Unfortunately, nowadays it is a serious problem to distribute the keys to other entities in network environment in secure way. If an intruder finds out secret key, then it will be able to decrypt all data. The QKD ensures the highest security level of distributed encryption key, because it is not possible to eavesdrop the communication in passive way any intruder will be uncovered. High security level of the QKD is ensured by means of the principles of quantum mechanics. When data confidentiality is the crucial requirement, QC in conjunction with strong symmetric cipher (e.g. AES with a key size of 256 bits) is really a good solution.
Besides, when a quantum computer will be constructed, all cryptosystems based on RSA, the most popular asymmetric algorithm, will become insecure.
Communication security
Security of communications is another security dimension introduced by X.805 document. It ensures that information flows only between the proper end points. The QC meets this requirement in the best way the quantum information is exchanged only between proper entities. Otherwise, an eavesdropper will be uncovered. The QC ensures communication security requirement by means of the principles of quantum mechanics.
Privacy
The information that might be derived from the observation of network activities can be used by intruders against users or communication system. Privacy assurance is the action when we provide the protection against the intruders who can collect this kind of information. When we have this requirement during system design process, we should consider the QKD technique. Again when eavesdroppers want to observe the quantum information, they change the quantum states and can be uncovered. Like previous requirements QC ensures the privacy by means of the principles of quantum mechanics.
Efficiency
One of the solutions which ensures data security is asymmetric encryption it protects private information and do not require confidential key establishment or exchange, but they are not very efficient. Therefore, asymmetric ciphers cannot be applied to every application. When efficiency of the communication system is one of the most important requirements, the best encryption algorithm will be a symmetric cipher with secure key distribution by means of QKD technique. Symmetric encryption algorithms are the fastest ciphers. Even though transmission of quantum information is quite slow, the encryption key is relatively short in comparison with users data. 6.3.2 End-user requirements At the beginning of the system design process, end-users should create the specific requirements concerning, among other things, security issues. The end-user requirements should come from stakeholders and express some properties of the communication system. When we consider the QKD technique, the potential endusers of systems which will be protected by means of QC are: banks, big corporations or public administration. The reason why only the big players can take the liberty of implementing QC technique is first of all the cost more about it will be presented in this subsection. Lets consider the following question: when end-user requirements of the communication system indicate that the QC will be a good solution? Below, some specific requirements will be presented in detail.
85/110
Security
Sometimes security of data is the crucial issue. Lets consider a communication system of the Police. The weak security system jeopardizes the Police to carry out cover investigations but could also put in risk many people. In such a situation the QKD may be the best solution since QC provides the highest security level. When security is one of the most important end-user requirements as in the case of Police, it is worth considering data protection by means of QC.
Cost
The cost of communication system is usually the most frequently end-user requirement which appears during the design process. Unfortunately, the QC is very expensive technique. Not only quantum devices and software applications generate big expenses but also the additional investment for the communication network. Currently, when we want to implement QC over some communication system, we have to build or rent a dedicated optical fiber (i.e. dark fiber). All components: hardware, software, and optical fibres generate a huge cost of QC implementation. Therefore, only when end-user requirements do not include severe cost restrictions, we can think seriously about deploying QC.
Performance
Performance is a feature of the system that is inseparably from security it is inversely proportional to the security level of the system. This relationship is presented in figure 6.3.2. Performance is the requirement that is usually directly felt by end-users and for this reason appears very often as an end-user requirement. Performance of QC should not be worse than other security solutions: in comparison with asymmetric ciphers, QC, which is based on symmetric encryption, provides much more efficient data encryption. Even QKD in comparison with traditional key exchange or other establishment protocols like the Diffie-Hellman key exchange algorithm, has not to have a worse performance. Diffie-Hellman protocol is based on prime number computation which is not an efficient process and has a lot of protocol overheads. For these reasons it is worthy to consider the QC technique, when enduser requirements require a high performance level for the communication system.
Figure 6.3.2: The relationship between performance and security. Performance is inversely proportional to security level of the system
86/110
Scalability
A scalable communication system could be another common end-user requirement. Lets consider the situation when a bank or other big corporation has to connect a new branch. This process should not require a change of whole security system but only an extension of the system. QC is surely a scalable technique which can be deployed in communication system when end-user requirements pay attention to scalability of the new security solution. 6.3.3 List of Security and Privacy Requirements In this subsection we present security requirements for quantum cryptography. We should meet these requirements to be sure that implemented quantum cryptography is really secure. REQ-D8.1-6.4-01: Quantum information should be coded by means of single photons to avoid split light and receive information in secret way. REQ-D8.1-6.4-02: Quantum communication should be transmitted in dedicated fibers (dark fibers). REQ-D8.1-6.4-03: Quantum cryptography protocol should compare enough bits to be sure that nobody has eavesdropped the communication. REQ-D8.1-6.4-04: Symmetric cipher algorithms that are used in quantum cryptography must not have any backdoors allowing encrypting or decrypting data without the secret key. REQ-D8.1-6.4-05: Cipher algorithms that are used in quantum cryptography must ensure high level of confidentiality. REQ-D8.1-6.4-06: Cipher algorithms that are used in quantum cryptography must use long keys to encrypt data.
87/110
6.4 Federated Identity Management (T8.4)

Many Internet services were originally conceived to be used anonymously. However, anonymity is not possible or desirable for commercial activities or business relations. To face this requirement Internet Identity systems have appeared, but these system are seldom interoperable. This lack of interoperability may inhibit emergent scenarios such as the cooperative usage of applications and services between different organizations. Federated Identity Management (IDM) faces this issue allowing the entities within a trust domain sharing identities across the borders that separate each other. Identity details and authentication complexity could be hidden behind the protocols and APIs elaborated by different Federated ID organizations like OASIS SAML TC, Liberty Alliance or WS-Federation. Federated Identity can be also seen as a simple way of being authenticated in several inter-connected systems. Network services need a trust relationship so as to uniquely identify a user in the system. For a better understanding of this idea a common example is explained: Suppose that a user owns a Gmail account. However her login is not valid for accessing Hotmail. The easiest solution is to use the same user name and password in all websites. However, this would be, not only a serious security flaw, but also very difficult to implement, because the user name could be already assigned, the format of passwords could be different, etc. Federated infrastructures solve part of this problem. They allow having a unique identity, hosted in an Identity Provider (IdP), that will be accepted by one or more Service Providers (SP). The system formed by (at least) one IDP and (at least) one SP is called a federation, and it is characterized by having a relationship of trust among its members, simplifying data communication and validation of the user in a secure way. Thus, it enables to achieve a connected world, based on standards where consumers, citizens, companies and governments can perform transactions easily, while privacy and security of personal data are guaranteed. Most important organizations that have developed Federated Identity standards are: Oasis, which defined SAML 1.1, a specification based in XML that allows crossdomain authentication. Microsoft and IBM proposed a web services security mechanism that included identity management. As an alternative, the Liberty Alliance Project was created for developing open and neutral standards for Federated Identity. Specification of Federated Identity and identity-based web-services are focused on giving solutions against identity theft, ensuring interoperability between manufacturers and their products by means of official certification programs, and collaborating with other standards organizations, private entities and governments. SAML v2.0 standard, jointly proposed by OASIS and Liberty Alliance, has boosted the use of federated identities because it removes the obstacles that existed when there were several protocols. SAML v2.0 describes two federation roles: Service Provider, an entity that allows a user to access a resource or an application; and an Identity Provider that is responsible for user authentication. Both Service Provider and Identity Provider exchange messages for allowing a unique signature and access log. The exchange of these messages can be initiated by both entities.
Figure 6.4.1: Liberty Architecture Overview
For the Single Sign-On (SSO) feature, the Identity Provider is in charge of creating and sending to the Service Provider an assertion which contains the user identity. On the other hand the Service Provider makes a validation of the SAML assertion before allowing accessing the application. An SAML assertion is a XML document which contains several elements related to the user identity, such as how the user has been authenticated and optionally, attributes about the identity itself. These messages may be exchanged by diverse methods: with HTTP via the users browser or by a SOA interaction. The convergence that SAML v2.0 facilitates will have a fundamental effect on the companies interest for using federation for sharing information about entities, without unnecessary restrictions. The election of technologies to be used is simplified and the need for complex, confusing and expensive multi protocol solutions is removed. From the end user and the Identity Provider point of view, the Federated ID service starts at the registration process. Registration at an IdP web site is only possible when an appropriate direct authentication method is employed during the registration process. Existing users may use their current identification data when registering to an IdP. In this latter case it should be considered whether the authentication mechanism is appropriate for all services. Therefore using the strongest authentication method available (e.g. PKI) is the most preferable solution for registration. Then SAML v2.0 allows a website (Service Provider) to give access to a user that is authenticated by other domain. For example: A user tries to access a website. If he has not been authenticated, his browser is redirected to a Local Federation Server.
89/110
The Local Federation Server redirects the user to a Remote Federation Server, which is charge of checking the identity. User authenticates with it, for instance by providing a name and password. The Remote Federation Server confirms user identity against a directory server (e.g. LDAP). If user credentials are verified, then the remote server creates an SAML assertion and sends it to the browser, before returning to the Local Federation Server. Local Federation Server extracts SAML assertion and creates a session cookie. Finally the users browser is redirected to the original website. All these capabilities can only be achieved when: First, businesses affiliate together into circles of trust based on Federated ID enabled technology and on operational agreements that define trust relationships between the businesses; and Second, users federate the otherwise isolated accounts they have with these businesses (known as their local identities). In other words, a circle of trust is a federation of service providers and identity providers that have business relationships based on Federated ID architecture and operational agreements and with whom users can transact business in a secure and apparently seamless environment. To sum up, Federated ID is a security mechanism that provides a suitable solution for web access control in the INDECT integrated intelligent portal. Its potential can be exploited so that specific groups of users have different access rights without having the necessity to remember the passwords for each individual application. The capabilities for each role are thoroughly described in D6.2-4.2.1. Thanks to Federated ID individuals may use the same personal identification (user and password) to have access to a circle of trust/confidence being able to share information between domains without sharing directory, security or authentication technologies. Efficiency in the submission of access control details lowers the risk of threats to the web portal based on bypassing login forms and others. However, there are some limitations associated with Federated ID, which are the complexity and refrains to deployment. They are mainly related to the lack of support by governmental organizations and the inexistence of an underlying legislation. 6.4.1 List of Security and Privacy Requirements REQ-D8.1-6.4-01: IDM (Identity Management) should support several authentication levels, i.e. from password-user code pair to digital certificates although the strong authentication methods should be emphasized REQ-D8.1-6.4-02: IDM service should support roaming between IdPs. REQ-D8.1-6.4-03: End user should be able to choose the role they are acting. REQ-D8.1-6.4-04: End user should be able to choose the information to be sent to federated Service Providers (user consent).
90/110
REQ-D8.1-6.4-05: End user should be able to connect to the service/content providers service through IdP. REQ-D8.1-6.4-06: End user should be able to connect for authentication from SP (Service Provider) to IdP. REQ-D8.1-6.4-07: End user should be able to use pseudonym and/or anonymity when connecting to services if possible. REQ-D8.1-6.4-08: Stored data in IDM service should be protected against unauthorized disclosure. Management of customer information should be then restricted to authorized personnel only. REQ-D8.1-6.4-09: All usage concerning the registration data should be stored in a log file (who, when, what). REQ-D8.1-6.4-10: End user information should not be delivered to third parties without user consent. However some data could be delivered to third parties who have the lawful right to access such information. REQ-D8.1-6.4-11: Responsibilities of each party should be stated and documented and communicated to the user, SPs and other parties involved. REQ-D8.1-6.4-12: Security levels for different kinds of authentication methods should be defined (internal function where end user has no rights or influence). REQ-D8.1-6.4-13: All transfers and messages containing end user specific information should be encrypted. REQ-D8.1-6.4-14: Any service or content provider violating the rules or agreements or end user privacy should be excluded from the CoT (Circle of Trust) immediately. REQ-D8.1-6.4-15: Any end user violating the rules or agreements should be excluded from the service immediately. REQ-D8.1-6.4-16: IdP should guarantee that the end user is identified and authenticated with proper identification method required by the SP.
91/110
6.5 Mobile Security (T8.5)

Recent advances in the development of affordable high-speed wireless technologies like WiFi have brought a lot of attention over the, so called, Ad-hoc networks. These wireless data networks are build automatically and on-demand among the devices in a certain range, without the need of careful design and deployment phases. This feature makes Ad-hoc networking a very appealing tool for security forces, especially for early responders or in big emergencies when traditional communication networks do not work or are saturated. Moreover, an ad-hoc network may be able to inter-communicate all the forces deployed in an emergency area, even when they belong to different agencies (e.g. police officers, fire-fighters and ambulance crew). Nowadays the coordination of different forces is an issue because they usually employ different communication technologies/frequencies. Therefore two persons that are just 20 meters away may need to communicate through their respective organizations, if they are able at all. On the other hand, if they have a communication terminal with a cheap WiFi interface they could build an Ad-hoc network to communicate effectively.
Figure 6.5.1: Multi-organization Ad-hoc network for emergency response.
Ad-hoc networking poses a number of challenges in order to provide truly autoconfiguration, user mobility, robust performance and security features. In particular, security is a must for an Ad-hoc network for security forces, especially when trying to interconnect different organizations. Although we should always consider security as a property of the whole system, in this case is worth focusing in two layers of the system that require additional research: the application layer and the network layer. The application layer (or the session layer in OSI terminology) is the appropriate place to implement end-to-end security, for instance to avoid impersonation or manin-the-middle attacks. Within a single organization this problem could be solvable by employing digital certificates from a single trusted Certification Authority. However, for a multi-organization network the problem is much more complex and it is necessary to employ more advanced techniques such as federated identity management, which enables ad-hoc applications for the discovery of ad-hoc users and the secure communication among them.
Unlike other layers of the TCP/IP stack employed in an Ad-hoc network, which could employ standard security techniques, the network layer requires additional scrutiny regarding security. There are two reasons for this observation. On one hand, Ad-hoc networking requires specialized routing protocols (e.g. AODV, OLSR) that are quite new and thus have not been fully validated from a security point of view. On the other hand, wireless links are far more susceptible to low-level attacks (e.g. jamming, noncooperative CSMA/CD medium access) than their wired counterparts. Moreover, it is quite difficult, if not impossible, to defend the network from these kinds of attacks (i.e. requires specialised hardware). Therefore it is better to assume that an adversary is able to disrupt any wireless link within a certain range, and design a routing protocol that is able to detect this damaged zone and quickly route around it. In particular a routing protocol with multipath capabilities, which is able to discover/employ different paths in parallel, may be quite useful in this case to limit the impact of a lower-layer attack and to quickly recover from it. Finally, all the proposed security mechanisms must also take into consideration the characteristics of an Ad-hoc network. In particular: - Self-configuration. The number of actions of a user in order to communicate employing the Ad-hoc network must be kept to a minimum, if any. This is a very hard challenge regarding security. - Battery powered devices. Most Ad-hoc devices are operated on batteries. Therefore energy consumption is an important issue to consider, which limits both the performance and the communication capabilities of the mobile devices. - Reduced bandwidth. Wireless technologies have a reduced performance when compared with their wired counterparts, especially in an unplanned adhoc network shared among many users. Therefore, bandwidth should be considered as a scarce resource and the size of messages should be limited (e.g. not sending a certificate in every routing message). - Isolated environment. Ad-hoc networks are especially useful in emergency scenarios when traditional communications have been damaged or saturated. Therefore Ad-hoc security solutions must work in a stand-alone fashion. That is, they should not rely on an Internet connection towards external servers or in general fixed infrastructure (e.g. centralized revocation lists).
6.5.1 Ad-hoc Security As previously stated, in order to enhance the security of an Ad-hoc network several layers of the TCP/IP stack should be considered. Application layer should deal with end-to-end security issues, whereas Ad-hoc routing and lower layers lack of all the security mechanisms developed for standard TCP/IP stacks. In particular, the application layer (or a session layer tightly coupled with it) should provide security at Users level. For instance provide Authentication of the other communicating peer, Confidentiality, Integrity, and non-Repudiation depending on the application. From a communication stand-point most of this problems can be solved with well know techniques such as TLS/SSL and User certificates. However, it is necessary to consider the especial characteristics of this scenario, namely the lack of fixed infrastructure and the need to locate nearby Users from different, not fully trusted organizations.
93/110
Probably, providing a secure Ad-hoc routing is the most challenging part of the system, since Ad-hoc routing is still in its infancy, moving from the research labs to initial large-scale deployments. For instance, there is not a single standard Ad-hoc routing protocol but many. Following a common taxonomy, Ad-hoc routing protocols can be classified in Pro-active protocols like OLSR [29], where nodes continuously exchange routes in order to populate its routing tables, and Reactive routing protocols like AODV [30] or DSR [31], where routes are found on demand, only when they are needed. Hybrid solutions like TORA [32] employ both reactive and proactive mechanisms. Each family of protocols has been designed with a different set of requirements. For instance Reactive protocols are best suited for mobile nodes, whereas OLSR has been mostly deployed in mesh networks with little mobility. Probably the most useful scenario for security and emergency forces it is the so called Mobile Ad hoc Networks or MANETs, where most nodes are mobile and relationships among nodes do not last long. For this reason we will focus on the security of reactive protocols, especially AODV and DSR, since they are the most popular routing protocols for MANETs. Although there are some works in the literature about security in Ad-hoc networks, there is still little experience with real wireless ad-hoc networks and far less applied security research when compared to their fixed counterparts. Most works [28] are more focused on identifying a particular attack for a given protocol and its specific countermeasure, than providing a global security solution. This is a brief list of the identified attacks (some of them are generic, whereas others only affect a particular routing protocol): Black/Gray hole attack. Attract all traffic towards an attacker node by means of routing and then drop it all or just a fraction of it in order to avoid detection. Sleep deprivation attack. Redirect traffic continuously towards a victim in order to quickly deplete its battery. Rushing attack. Destination nodes usually reply only to the first RREQ message. Thus an attacker could send its own RREQ message before others to choose the route it wants. Modify Hop/Sequence number (AODV). Attacker could promote himself by advertising a route with less hops or a greater sequence number. Modify Source Route (DSR). DSR specifies the full path in the RREP messages. Thus an attacker could modify the RREP route at its will. Broadcast false routes (DSR). In order to save bandwidth DSR nodes have a cache that populate just by overhearing RREP messages. An attacker could poison DSR route caches by generating false RREP messages. Falsify Route Errors. An attacker could generate a DoS attack by tearing down valid routes. Selfish/Malicious MAC layer. An attacker may configure its wireless interface with lower back-off values in order to gain some advantage. Jamming. An attacker may generate a strong signal that interferes with the channel employed by the Ad-hoc routing. There are a number of solutions for some of the above attacks, although most works usually focus just in one of them: Encrypt & Sign all messages. To avoid eavesdropping & message modification in transit. However this solution requires some kind of trusted key distribution mechanism.
Access Control. Exclude attackers from routing by authenticating new nodes before joining them to the MANET. Reputation mechanisms. When no authorization is possible, some authors propose to build a reputation mechanism in order to classify nodes into cooperative or uncooperative classes. Levels of security/trust. In order to limit insider attacks, the routing protocol chooses nodes from the same security level (e.g. Police officers) instead of choosing the best path. Randomize Message Forwarding. To avoid rushing attack, some authors propose to queue and send RREQ messages at random times. However this may add extra latency to path discovery. Do not use hop count. Since hop count field can be forged by intermediate node, ignore it and just reply to the first RREQ. Hash chains. Another alternative to secure the hop count is to generate a hash chain so no node can claim a shorter path. Onion routing. Encrypt the DSR source route between hops to avoid tampering. Overhearing / Probing / Feedback. To detect packet dropping by means of a black/grey hole attack.
6.5.2 List of Security and Privacy Requirements REQ-D8.1-6.5-01: Only authorised members of security agencies must be allowed to join the emergency ad-hoc network. REQ-D8.1-6.5-02: Users should be able to find each other in a secure fashion, that is, avoiding man-in-the-middle or other impersonation attacks, even when they belong to different organizations. REQ-D8.1-6.5-03: Users must be able to communicate in a secure way. Application running in the ad-hoc network must provide confidentiality, authenticity, integrity and non-repudiation (depending on the application). REQ-D8.1-6.5-04: Ad-hoc network must not suffer, or at least provide certain countermeasures, from any of the known logical attacks mentioned in the previous section. REQ-D8.1-6.5-05: Ad-hoc network may suffer low-level attacks that may hinder its availability or reliability like jamming or uncooperative/malicious nodes. In this case the routing protocol should be able to find an alternative route as soon as possible to minimise data loss. REQ-D8.1-6.5-06: All the developed protocols and security mechanisms should take into account the limitations of mobile nodes, such as: constrained computation, battery power, low bandwidth, etc. REQ-D8.1-6.5-07: Basic security mechanisms must keep working even if the ad-hoc network is isolated and does not have external connectivity. However, some of the advanced security features like certification revocation lists may be unavailable or have a degraded performance.
96/110
7 Ethical Issues
The objective of this document is to provide the requisites and specific requirements for both the Security and the Privacy aspects of the overall INDECT project. Therefore, most of the previous chapters already include many considerations related to Privacy, Civil Liberties and other Ethical Issues, which will not be repeated here. Instead, this chapter is focused on the different European bodies and internal mechanisms that are in place to ensure INDECT project develops its activities with respect of the ethical principles that are the foundations of European values. This chapter briefly reviews the current European legislation regarding privacy, which has been analyzed in detail in chapter 3, as well as some insight about the future legal framework arising from the Lisbon Treaty.
7.1 Data security in Europe

Recently, the approach towards data security has been undergoing considerable change. Until now it has been mainly considered as a set of tools and measures for protection of the legal standard and quality of services, and other similar processes. Now data security is regarded as a technological activity, but it also includes aspects of planning, management and most important - ethics. These trends are mirrored in the European legal framework on data security. The main principle, according to Article 22 of Regulation (EC) No 45/2001, is that the data controller shall implement appropriate technical and organisational measures to ensure an appropriate level of security in relation to the risks represented by the processing and the nature of the personal data to be protected. Such measures must be put in place for the prevention of any unauthorised disclosure or access, accidental or unlawful destruction or accidental loss, or alteration and any other unlawful form of processing. As already described in chapter 3 of this document, Directive 95/46/EC (also known as "Data Protection Directive") is the legislation basis at EU level in the field of data protection. The Directive is a framework law, meaning that it is implemented in EU Member States through national laws. It aims to protect the rights and freedoms of persons with respect to the processing of personal data by laying down guidelines determining when the processing is lawful. The guidelines mainly relate to: Quality of the data. Legitimacy of the processing. Processing of special categories of data. Information to be given to the data subject. Data subject's right of access to data. Right to object to the processing of data. Confidentiality and security of processing. Notification of the processing to a supervisory authority.
97/110
7.2 Supervising and consulting bodies

In order to cope with sensitive issue related to privacy and data protection, INDECT shall use both internal and external tools, mechanisms and bodies. 7.2.1 Ethics Board of INDECT Thriving to ensure respect of the legislation concerning privacy, data protection, to ensure genuine informed consent of all those participating in the project, and to ensure that information is only used for its intended purpose, INDECT has set up a special body, called Ethics Board, responsible for managing and monitoring all ethical aspects of the project. Therefore, the Ethics board shall establish general strategy for all ethics-related issues. Its function is also to consult the project-partners in the area of the legislation in force, to check profoundly all deliverables, as well as external liaison with other related projects. 7.2.2 European Data Protection Supervisor The European Data Protection Supervisor (EDPS) is an independent supervisory authority established in accordance with Regulation (EC) No 45/2001, on the basis of Article 286 of the EC. The mission of this European institution is to ensure that the fundamental rights and freedoms of individuals - in particular their privacy - are respected when the EU institutions and bodies process personal data. Among main responsibilities of the EDPS are: Monitoring and ensuring that the provisions of Regulation 45/2001, as well as other Community acts on the protection of fundamental rights and freedoms, are complied with when EC institutions and bodies process personal data (supervisory tasks). Advising the EC institutions and bodies on all matters relating to the processing of personal data. This includes consultation on proposals for legislation and monitoring new developments that have an impact on the protection of personal data (consultative tasks). Cooperating with national supervisory authorities and supervisory bodies in the "third pillar" of the EU (Police & Judicial co-operation in Criminal Matters) with a view to improving consistency in the protection of personal data. The EDPS intervenes in cases before the Court of Justice of the European Communities. The EDPS advises the European Commission, the European Parliament and the Council on proposals for new legislation and a wide range of other issues with data protection impact. In essence, the consultative task is to analyse how policies affect the privacy rights of the citizens. This assessment helps to enable proper political discussions on how new legislation can be effective with due respect and adequate safeguards for citizens' freedoms. The advice makes it possible for the legislators in Europe to adopt better legislation that is in line with European values. The EDPS cooperates with other data protection authorities in order to promote consistent data protection throughout Europe. 7.2.3 Country data-protection authorities In the country of each INDECT partner, there is at least one data protection body responsible for dealing with issues that relate to such processing. Such authorities are competent with all national regulations and legislation in force, so they shall be consulted by INDECT project about all country-specific issues connected to privacy and data protection.
7.3 Future development: Data protection after Lisbon Treaty

The reforms implemented by the Lisbon Treaty shall also have important consequences for data protection and privacy rules. The Treaty which entered into force on 1 December 2009 abolishes the three pillars structure (each with separate legal bases for legislative action): Community matters; Common Foreign and Security Policy; and Police and Judicial Cooperation in Criminal Matters. Consequently, until now solely the Council was empowered to adopt legislation in the third pillar on data protection. The Lisbon Treaty creates a new legal framework for data protection, as its Article 16(2) states: "The European Parliament and the Council, acting in accordance with the ordinary legislative procedure, shall lay down the rules relating to the protection of individuals with regard to the processing of personal data by Union institutions, bodies, offices and agencies, and by the Member States when carrying out activities which fall within the scope of Union law, and the rules relating to the free movement of such data. Compliance with these rules shall be subject to the control of independent authorities". Under Article 16 of the TFEU everyone has a right to the protection of his or her personal data. It means that this right shall be directly applicable to persons, and that they could consequently invoke it in court. Very important is also the fact that the Charter of Fundamental Rights of the European Union, including its Article 8 on data protection, has become binding. Article 8 summarises the main elements of the fundamental right to data protection, such as purpose limitation, the right of access to and rectification of personal data, as well as independent supervision.
99/110
100/110
8 Conclusions
This document specifies the Security and Confidentiality requirements of systems and tools to be developed by the INDECT project from different perspectives. In order to understand the motivations and limitations of INDECT project, an overview of the European Legal Framework has been provided in chapter 3. The most relevant conventions and directives for INDECT project have been listed and reviewed in detail, specifying how they may affect to the subsystems and tools to be developed within the INDECT project. These legal considerations, together with the User requisites obtained via detailed End user reports, as well as the Security and Privacy section of the Users Questionnaire, has led to the design of the general Security and Privacy requisites of the INDECT project (chapter 4), which are based on general ICT security requirements defined by the ITU-T X.800 and ISO/IEC 2700 family of standards. After these general requirements, an explicit list of requisites and the rationale for each of them has been given in chapter 5 for each Work Package within INDECT project. Moreover, chapter 6 provides the requirements intended for the security technologies to be investigated by WP8, in order to enhance the overall security and privacy techniques beyond the state of the art. In particular the usage of a Federated Identity Management system may ease the cooperation among different Police departments or even security agencies. Furthermore, by centralizing the authentication and authorization processes, it is simpler to deploy advanced authentication mechanism such as Smart Cards or Fingerprint-based checks for Police applications and IT systems. Since all work packages of the INDECT project are still in the early stages of the design process, the requisites contained in this document must be considered as an initial set of security features to start out the design of INDECT applications, and they are expected to be further refined and enhanced as the project progresses. Nevertheless it is essential to consider all these security and privacy requisites from the very beginning of the development in order to avoid structural security flaws in the design.
101/110
102/110
References
1. INDECT Project. Report on the collection and analysis of user requirements (D1.1). October 2009. 2. ITU-T X.805. Security architecture for systems providing end-to-end communications. 2003. 3. S. Brands. Rethinking Public Key Infrastructures and Digital Certificates: Building in Privacy. MIT Press, Cambridge, MA. 2000. 4. J. Canavan. Fundamentals of Network Security, London, Artech House, 2001. 5. H. C. A. van Tilborg . Encyclopaedia of Cryptography and Security. Springer Science+Business Media, Inc. 2005. ISBN-10: (eBook) 0-38723483-7 6. V. Tselkov, N. Stoianov. Security cryptographic application for computer systems and networks. New Star, Sofia. 2009. ISBN 978-954-8933-20-9 7. R. B. Natan. Implementing Database Security and Auditing. 1st edition. Digital Press. 2005. ISBN 978-1555583347. 8. J. M. Johansson. Windows Server 2008 Security Resource Kit. 1st edition. Microsoft Press, 2008. ISBN 978-0735625044. 9. INDECT Project. Intelligent Crisis Management Systems Concepts and Usage Scenarios (D6.1). WP6 Public Deliverable. October 2009. 10. R. Deal. The Complete Cisco VPN Configuration Guide. Cisco Press. 2006. 11. J. H. Carmouche, IPSec Virtual Private Network Fundamentals. Cisco Press. 2007. 12. B. Ryabko, A. Fionov. Basics of Contemporary Cryptography for IT Practitioners. World Scientific Publishing Co. Re. Ltd. 2005. ISBN 981-256405-5 13. Liberty Alliance. Liberty Metadata Description and Discovery Specification. 14. M. Stamp, R. M. Low, APPLIED CRYPTANALYSIS: Breaking Ciphers in the Real World. 2007. ISBN 978-0-470-1 1486-5 15. W. Stallings, Cryptography and Network Security Principles and Practices. Prentice Hall. 2005. eText ISBN-10: 0-13-187319-9 16. M. Wenbo. Modern Cryptography: Theory and Practice. Prentice Hall PTR. 2003. ISBN: 0-13-066943-1 17. Federal Information Processing Standards (FIPS). ADVANCED ENCRYPTION STANDARD (AES). Publication 197. November 26, 2001. 18. A. Menezes, P. van Oorschot, and S. Vanstone. Handbook of Applied Cryptography. CRC Press. 1996. 19. N. Stoianov. Models of security interaction in defence computer system. PhD Thesis. Sofia. 2003. 20. V. Tselkov, N. Stoianov, Security cryptographic application for computer
systems and networks. New Star, Sofia. 2009. ISBN 978-954-8933-20-9 21. V. Tselkov, N. Stoianov, Cryptographic basics for security architecture in computer systems. Science conference, Shoumen, Bulgaria. 2002. 22. N. Stoianov, V. Tselkov, One formal method for resource distribution based on group of access in security computer systems. Science conference, Shoumen, Bulgaria. 2004. pp.96-103. 23. C. Elliott. "Quantum cryptography". IEEE Security & Privacy, Vol. 2, Issue 4, Jul-Aug 2004. pp. 57 61. 2004 24. M. Niemiec. "Quantum cryptography - The analysis of security requirements". 11th International Conference on Transparent Optical Networks (ICTON '09). June 28-July 2 2009. 25. Liberty Alliance. ID-FF Architecture Overview. 26. Liberty Alliance. Authentication Context Specification. 27. Liberty Alliance. ID-FF Protocols and Schema Specification. 28. D. Djenouri, L. Khelladi, N. Badache. A Survey of Security Issues in Mobile Ad-hoc and Sensor Networks. IEEE Communications Surveys & Tutorials. Vol. 7, No. 4, pp. 2-28. 2005. 29. T. Clausen, P. Jacquet. Optimized Link State Routing Protocol (OLSR) RFC3626. October 2003. 30. C. Perkins, E. Belding-Royer, S. Das. Ad hoc On-Demand Distance Vector (AODV) Routing. RFC 3561. July 2003. 31. D. Johnson, Y. Hu, D. Maltz. The Dynamic Source Routing Protocol (DSR) for Mobile Ad Hoc Networks for IPv4. RFC 4728. February 2007. 32. V. Park, S. Corson. Temporally-Ordered Routing Algorithm (TORA) Version 1 Functional Specification < draft-ietf-manet-tora-spec-04>. July 2001 33. INDECT Project. Intelligent Portal for Crisis Management Functional Specification and Conceptual Architecture (D6.2). INDECT WP6 Public Deliverable. Work in progress. 34. INDECT Project. Overall self-organizing computer network architecture model (D7.1). INDECT WP7 Deliverable. 35. L. C. Wong. An Overview of 802.11 Wireless Network Security Standards & Mechanisms, GIAC Security Essentials Certification (GSEC), Practical Assignment 1.4c. October 2004 36. D. Mc Keon, C. Brewer, J. Carter, M. Mc Taggart. GSM and UMTS Security, 4BA2 Technology Survey. 37. Council of Europe. Convention for the Protection of Human Rights and Fundamental Freedoms. Rome 4 November 1950 38. European Parliament. Directive 95/46/EC of the European Parliament and of the Council of 24 October 1995 on the protection of individuals with regard to the processing of personal data and on the free movement of such data. 39. European Parliament. Directive 97/66/EC of the European Parliament and of the Council of 15 December 1997 concerning the processing of personal data and the protection of privacy in the telecommunications sector
40. European Parliament. Directive 2002/58/EC of the European Parliament and of the Council of 12 July 2002 concerning the processing of personal data and the protection of privacy in the electronic communications sector (Directive on privacy and electronic communications) 41. European Parliament. Directive 2006/24/EC of the European Parliament and of the Council of 15 March 2006 on the retention of data generated or processed in connection with the provision of publicly available electronic communications services or of public communications networks and amending Directive 2002/58/EC 42. Council of Europe. Convention for the Protection of Human Rights and Dignity of the Human Being with regard to the Application of Biology and Medicine: Convention on Human Rights and Biomedicine (The Oviedo Convention). Oviedo, 4 March 1997. 43. United Nations. UN Convention on the Rights of the Child. November 1989. 44. C. G. Combe. Ethical issues, data protection and privacy in the 7th Framework Program. Retrieved 12 December 2009 from http://ec.europa.eu/research/conferences/2009/rtd-2009/presentations/ethics/ caroline_gans_combe_-_ethical_issues_-_data_protection_and_privacy_in_ the_7th_framework_programme.pdf. 45. A. Scirocco. The Lisbon Treaty and the Protection of Personal Data in the European Union. Published in the digital magazine Dataprotectionreview.eu, Issue 5, February 2008. Retrieved 12 December 2009 from http://www.edps.europa.eu/EDPSWEB/webdav/shared/Documents/EDPS/ Publications/Speeches/2008/08-09-19_Scirocco_Lisbontreaty_DP_EN.pdf 46. EDPS European Data Protection Supervisor Web Site. Retrieved 09 December 2009 from http://www.edps.europa.eu/EDPSWEB/edps
105/110
106/110
Glossary of Security & Privacy Terms

These definitions of security terms are based on ITU-T recommendation X.800 and ISO/IEC standardization document 13335-1. Access control - The prevention of unauthorized use of a resource, including the prevention of use of a resource in an unauthorized manner. Accountability - The property that ensures that the actions of an entity may be traced uniquely to the entity. Active threat - The threat of a deliberate unauthorized change to the state of the system (modification of messages, replay of messages, insertion of spurious messages, masquerading as an authorized entity and denial of service) Authentication information - Information used to establish the validity of a claimed identity. Authorization - The granting of rights, which includes the granting of access based on access rights. Availability - The property of being accessible and useable upon demand by an authorized entity. Confidentiality - The property that information is not made available or disclosed to unauthorized individuals, entities, or processes. Credentials - Data that is transferred to establish the claimed identity of an entity. Cryptanalysis - The analysis of a cryptographic system and/or its inputs and outputs to derive confidential variables and/or sensitive data including cleartext. Cryptography - The discipline which embodies principles, means, and methods for the transformation of data in order to hide its information content, prevent its undetected modification and/or prevent its unauthorized use. Data integrity - The property that data has not been altered or destroyed in an unauthorized manner. Data origin authentication - The corroboration that the source of data received is as claimed. Denial of Service (DoS) - The prevention of authorized access to resources or the delaying of time-critical operations. Digital signature - Data appended to, or a cryptographic transformation (see cryptography) of a data unit that allows a recipient of the data unit to prove the source and integrity of the data unit and protect against forgery e.g. by the recipient. Key - A sequence of symbols that controls the operations of encipherment and decipherment. Key management - The generation, storage, distribution, deletion, archiving and application of keys in accordance with a security policy. Passive threat - The threat of unauthorized disclosure of information without changing the state of the system. Password - Confidential authentication information usually composed of a string of characters.
Privacy - The right of individuals to control or influence what information related to them may be collected and stored and by whom and to whom that information may be disclosed. Note Because this term relates to the right of individuals, it cannot be very precise and its use should be avoided except as a motivation for requiring security. Repudiation - Denial by one of the entities involved in a communication of having participated in all or part of the communication. Security service - A service, provided by a layer of communicating open systems, which ensures adequate security of the systems or of data transfers. Sensitivity - The characteristic of a resource which implies its value or importance, and may include its vulnerability. Threat - A potential violation of security. Traffic analysis - The inference of information from observation of traffic flows (presence, absence, amount, direction and frequency).
108/110
Document Updates
Version2 V01 V02 V03 V04 V05 V06 V07 V08 V09 V10 V11 V12 Date3 01/10/2009 18/11/2009 26/11/2009 27/11/2009 07/12/2009 08/12/2009 18/12/2009 23/12/2009 23/12/2009 10/01/2012 Updates and Revision History4 First Draft Second Version: Chapters 5 and 6 Internal review of previous version Final effort assignment after AC First complete version for review Updates for sections 5.4, 5.6, 5.7, 6.1, 6.4 Complete document plus major revision Minor revision Submitted version Revision after Mid-Term Review Author Manuel Uruea et al. Manuel Uruea et al. Manuel Uruea et al. Manuel Uruea Manuel Uruea et al. Manuel Uruea et al. Manuel Uruea et al. Manuel Uruea et al. Manuel Uruea Nikolai Stoianov et al. Katarzyna Wasilewska et al. Marcin Niemiec et al.
12/01/2012 GHP input added 16/01/2012 Final version after internal review
In form of vYYYYMMDD; Version number and edition should correspond to the actual document name conventions. 3 In form of DD/MM/YYYY 4 Attach as appendix document reviews when appropriate; describe also the current status of the document e.g. released for internal review, released for comments from partners
110/110

INDECT Deliverable D8.1 v20120116

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

INDECT Deliverable D8.1 v20120116

Uploaded by

Copyright:

Available Formats

European Seventh Framework Programme FP7-218086-Collaborative Project

Specification of Requirements for Security and Confidentiality of the System (D8.1)

Copyright 2009-2012, the Members of the INDECT Consortium

D8.1 Specification of Requirements for Security and Confidentiality of the System

INDECT Consortium www.indect-project.eu

This project is funded under 7 Framework Program

D8.1 Specification of Requirements for Security and Confidentiality of the System

INDECT Consortium www.indect-project.eu

European Legal Framework for Security and Privacy ............................................. 15

Mobile Urban Observation System (WP2) .......................................................... 44

INDECT-MAS (WP3) .............................................................................................. 46

Web-based crime detection (WP4) ...................................................................... 48

Watermarking (WP5) .............................................................................................. 52

INDECT_Deliverable_D8.1_v12_revised version_CMS - Public

D8.1 Specification of Requirements for Security and Confidentiality of the System

INDECT Consortium www.indect-project.eu

Biometrics and Wireless Security (WP7) ............................................................ 63

Cryptographic Algorithms (T8.2)........................................................................... 77

Quantum Cryptography (T8.3) .............................................................................. 83

Federated Identity Management (T8.4) ............................................................... 88 Mobile Security (T8.5) ............................................................................................ 92

INDECT_Deliverable_D8.1_v12_revised version_CMS - Public

D8.1 Specification of Requirements for Security and Confidentiality of the System

INDECT Consortium www.indect-project.eu

7.2.1 7.2.2 7.2.3 7.3 8

Future development: Data protection after Lisbon Treaty ................................ 99

Conclusions .................................................................................................................. 101

INDECT_Deliverable_D8.1_v12_revised version_CMS - Public

D8.1 Specification of Requirements for Security and Confidentiality of the System

INDECT Consortium www.indect-project.eu

(This page is intentionally left blank)

INDECT_Deliverable_D8.1_v12_revised version_CMS - Public

D8.1 Specification of Requirements for Security and Confidentiality of the System

INDECT Consortium www.indect-project.eu

INDECT_Deliverable_D8.1_v12_revised version_CMS - Public

D8.1 Specification of Requirements for Security and Confidentiality of the System

INDECT Consortium www.indect-project.eu

(This page is intentionally left blank)

INDECT_Deliverable_D8.1_v12_revised version_CMS - Public

D8.1 Specification of Requirements for Security and Confidentiality of the System

INDECT Consortium www.indect-project.eu

INDECT_Deliverable_D8.1_v12_revised version_CMS - Public

D8.1 Specification of Requirements for Security and Confidentiality of the System

INDECT Consortium www.indect-project.eu

Figure 1.1: Mean importance of general requirements from Users Questionnaire.

INDECT_Deliverable_D8.1_v12_revised version_CMS - Public

D8.1 Specification of Requirements for Security and Confidentiality of the System

INDECT Consortium www.indect-project.eu

2.1 Structure of this document

D8.1 Specification of Requirements for Security and Confidentiality of the System

INDECT Consortium www.indect-project.eu

D8.1 Specification of Requirements for Security and Confidentiality of the System

INDECT Consortium www.indect-project.eu

INDECT_Deliverable_D8.1_v12_revised version_CMS - Public

D8.1 Specification of Requirements for Security and Confidentiality of the System

INDECT Consortium www.indect-project.eu

(This page is intentionally left blank)

INDECT_Deliverable_D8.1_v12_revised version_CMS - Public

D8.1 Specification of Requirements for Security and Confidentiality of the System

INDECT Consortium www.indect-project.eu

3 European Legal Framework for Security and Privacy

3.1 European Convention on Human Rights (ECHR)

D8.1 Specification of Requirements for Security and Confidentiality of the System

INDECT Consortium www.indect-project.eu