Abstract:
A method is proposed for managing requests from Law Enforcement Agencies for interception or retention of data relating to a target user. The method detects a request of interception or retention on the target user and verifies whether an electronic warrant is activated with respect to the user.

Description:
TECHNICAL FIELD 
       [0001]    The present invention relates to lawful interception and data retention systems, in particular to systems and method for preventing illegal interception or illegal data requests. 
       BACKGROUND 
       [0002]    In many countries operators and Internet service providers are today obliged by legal requirements to provide stored traffic data generated from public telecommunications and Internet services for the purpose of detection, investigation and prosecution of crime and criminal offences, including terrorism. 
         [0003]    There are also initiatives within the European Union (EU) to regulate the legal basis for data retention. The EU Parliament adopted a set of amendments and by that approved the Council&#39;s proposed directive on data retention (Directive 2006/24/EC). In this directive, initial requirements and how an extension of the directive will be handled are described. Consequently, an essential part of operator&#39;s effort to comply with current legislation is to secure that processes and tools may be adapted to handle an expansion of the scope for data retention. Technical specification ETSI DTS/LI-00039 gives guidance for the delivery and associated issues of retained data of telecommunications and subscribers. In particular, ETSI DTS/LI-00039 provides a set of requirements relating to Handover Interfaces for the retained traffic data and subscriber data by law enforcement and other authorised requesting authorities. The requirements are to support implementation of Directive 2006/24/EC of the European Parliament and of the Council of 15 Mar. 2006 regarding the retention of data. 
         [0004]    Technical Specification ETSI DTS/LI-00033 contains handover requirements and a handover specification for the data that is identified in EU Directive 2006/24/EC on retained data. 
         [0005]    Usually there is a public official, for instance a judge, who authorises investigation on some persons, allowing to activate lawful interception on their communications or to query on data retention databases. The authorisation paper is named “warrant”. 
         [0006]    According to the received warrant the lawful enforcement agency may set targets of interception and/or query the data retention database. In general, in LI subsystems that allow to activate the interceptions (such as Ericsson Lawful Intercept Mediation System, LI-IMS), all commands are traced, so it is possible for a supervising authority to verify if the targets have been set without a warrant, or in a way not consistent with the original authorisation, and consequently remove them. 
         [0007]    In a similar way, all commands given to a data retention system such as Ericsson Automatic Data Retention Solution (ADRS) to order queries on some target users are traced, so it is possible for the supervisor to verify if some query has been ordered with no warrant, or in a way not consistent with the original authorisation. 
         [0008]    A problem in the current lawful interception and data retention solutions arises from the fact that an unauthorised use of the systems, that is an interception or a query on retained data performed without a granted warrant, may be detected only after the unauthorised use has been performed. 
         [0009]    In other words a command to set a target of interception or a query on some target users may be performed even if a warrant has not been granted, and these unauthorised activities may go on until a supervisor detects the situation. 
         [0010]    Another similar problem stems from the fact that in some countries it may be forbidden to intercept or to query the data retention database in respect of people having public official roles. However there is no automatic mechanism that may prevent lawful enforcement agencies to intercept or query retained data relating to such persons. 
       SUMMARY 
       [0011]    The aim of the present invention is to provide an enhanced warrant management system that overcomes the above mentioned drawbacks. 
         [0012]    According to a first aspect of the invention, an electronic warrant for Lawful Interception in a telecommunications system is disclosed. 
         [0013]    The electronic warrant comprises authorisation information defining a scope of retention or interception requests of data relating to a target user. 
         [0014]    Authorisation data in the electronic warrant may comprise one or more of: authorisation to intercept a target user; authorisation to extend interception to other known identities; authorisation to provisionally extend interception to other unknown identities; authorisation to access retained data of a target user; authorisation to extend access to retained data to other known identities; 
         [0015]    authorisation to provisionally extend access to retained data to other unknown identities; time intervals for interception of access to retained data. 
         [0016]    The electronic warrant may be coded in a standard format, for example in one of the formats selected among XML, BER and CSV. 
         [0017]    According to another aspect of the invention, a method for managing requests from Law Enforcement Agencies for interception or retention of data relating to a target user detects a request of interception or retention on the target user and verifies whether an electronic warrant is activated with regard to the user. 
         [0018]    The request may be granted in case an electronic warrant is activated on the target user and/or deny the request in case an electronic warrant is not activated on the target user. 
         [0019]    A notification to a supervisor may be issued in case an electronic warrant is not activated on the target user, and provisionally grant the request. In this case, it may be optionally checked whether an electronic warrant has been entered in respect of the target user after the notification, grant the request in case an electronic warrant has been entered in respect of the target user, and deny the request in case an electronic warrant has not been entered in respect of the target user. 
         [0020]    Additional identification information related to the target user and allowing retention or interception of data connected to the additional identification information may be detected. In this case, the disclosed method may further comprise the steps of detecting additional identification information directly or indirectly related to the target user, and allowing retention or interception of data connected to the additional identification information. The additional identification information may be at least one of: an identifier of a called party, including phone numbers and email address; an identifier of a third party, including phone numbers and email address. 
         [0021]    The aim and the objects of the invention are also achieved by a node in a telecommunications system provided with a function comprising means for receiving electronic warrants allowing interception or retention data relating to a target user, and filtering requests for interception or retention of data relating to a target user according to authorisation information contained in the electronic warrants. The function may be an Administration Function. 
         [0022]    In the disclosure, the expression “retention” of data generally indicates a query directed to retrieve retained data. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0023]    Further characteristics and advantages of the invention will become better apparent from the detailed description of particular but not exclusive embodiments, illustrated by way of non-limiting examples in the accompanying drawings, wherein: 
           [0024]      FIG. 1  is an arrangement of a service provided with Data Retention (DR) capabilities, enhanced with an electronic warrant module according to the invention; 
           [0025]      FIG. 2  is a known arrangement of a Lawful Interception system enhanced with an electronic warrant module; 
           [0026]      FIG. 3  is a table representing the record format of the electronic warrant; 
           [0027]      FIG. 4  is a table representing the record format of an electronic warrant containing a list of immune users; 
           [0028]      FIG. 5  is a flow diagram showing a method of setting an electronic warrant in a lawful interception system according to the present invention; 
           [0029]      FIG. 6  is a flow diagram showing a method of handling a target set without an electronic warrant in a lawful interception system according to the present invention; 
           [0030]      FIG. 7  is a flow diagram showing a method of setting an electronic warrant containing a list of immune users in a lawful interception system according to the present invention; 
           [0031]      FIG. 8  is a flow diagram showing another method of setting an electronic warrant containing a list of immune users in a lawful interception system according to the present invention; 
           [0032]      FIG. 9  is a flow diagram showing a method of setting an electronic warrant in a data retention system according to the present invention; 
           [0033]      FIG. 10  is a flow diagram showing a method of setting an electronic warrant containing a list of immune users in a data retention system according to the present invention; 
           [0034]      FIG. 11  is a flow diagram showing another method of setting an electronic warrant containing a list of immune users in a data retention system according to the present invention. 
       
    
    
       [0035]    It is noted that the term warrant is here used to indicate either a court order or a document containing target user information setting exception conditions on data interception and access to retained data, such as lists of immune target users. 
       DETAILED DESCRIPTION 
       [0036]      FIGS. 1 and 2  show a data retention system and a lawful interception system. 
         [0037]    Particularly,  FIG. 1  depicts an arrangement for retaining data in a Communication Service Provider  1  (CSP). Specifically, the CSP  1 , which may incorporate existing communication systems  2 , is provided with a Data Retention System (DRS)  3  for exchanging retained data relating information with a Requesting Authority  4 , which may be a Law Enforcement Agency (LEA). 
         [0038]    The data exchanged between the CSP  1  and the Requesting Authority  4  comprises requests from the Requesting Authority  4 , corresponding responses from the DRS and other DR information, such as results of the requests and acknowledgements of receipt. The interfaces through which the CSP and DRS exchange the above data with the Requesting Authority are denoted as Handover Interfaces. 
         [0039]    The generic Handover Interface adopts a two-port structure in which administrative request/response information and Retained Data Information are logically separated. In particular, a first Handover Interface port HI-A  5  is configured to transport various kinds of administrative, request and response information from/to the Requesting Authority  4  and an organization at the CSP  1  that is responsible for Retained Data matters, identified by an Administration Function  7 . 
         [0040]    A second Handover Interface HI-B  6  is configured to transport the retained data information stored in a repository  9  from the CSP  1  to the Requesting Authority  4 . The individual retained data parameters have to be sent to the Requesting Authority  4  at least once, if available. To this aim, a Mediation/Delivery function  8  may be provided, for retrieving the retained data from the memory means  9  and forward such data to the Requesting Authority  4  in a suitable format through the HI-B  6 . A Lawful Interception (LI) system for accessing communications related data is depicted in  FIG. 2 . The standard architecture  10  comprises an Intercepting Control Element (ICE)  11  providing the user equipment of the target user with an access to the telecommunications network. An ICE may be, for instance, a 3G Mobile service Switching Center (MSC) Server, a 3G Gateway MSC Server, a Serving GPRS Support Node (SGSN), or a Gateway GSN (GGSN). 
         [0041]    The architecture  10  further comprises one or more Law Enforcement Monitoring Facilities (LEMFs)  12  through which respective LEAs receive interception information. 
         [0042]    An Administration Function (ADMF) entity  13  may be further configured for sending the target identity and LI authorisation data from the LEAs to the ICE. 
         [0043]    The ADMF  13  interfaces through a first Handover Interface  14  (HI 1 ) with all the LEAs that may require interception in the intercepting network, keeps the intercept activities of individual LEAs separate and interfaces to the intercepting network. The ADMF  13  may also be used to hide from the ICE  11  that there might be multiple activations by different LEAs on the same target. The ADMF  13  may be partitioned to ensure separation of the provisioning data from different agencies. 
         [0044]    Every physical ICE  11  may be linked to the ADMF by means of its own X 1 _ 1  interface. Consequently, every single ICE performs interception, i.e. activation, deactivation, interrogation as well as invocation, independently from other ICEs. 
         [0045]    In order to deliver the intercepted information to the LEAs, two Delivery Functions (DF) entities are provided, each exchanging respective portions of information with the ADMF  13  (through X 1 _ 2  and X 1 _ 3  interfaces) and the LEMF  12 . 
         [0046]    In particular, a DF 2  entity  15  may be configured to receive Intercept Related Information (IRI) from the ICE, through an X 2  interface, and to convert and distribute the IRI to the relevant LEAs via a second Handover Interface  16  (HI 2 ) by means of a Mediation Function (MF)  17 . 
         [0047]    The IRI is a collection of information or data associated with telecommunication services involving the target identity, such as call associated information or data, e.g. unsuccessful call attempts, service associated information or data, e.g. service profile management by subscriber, and location information. 
         [0048]    A DF 3  entity  18 , instead, may be configured to receive Content of Communications (CC) information from the ICE  11  through an X 3  interface, and to convert and distribute such information to the relevant LEA through an MF  19  and a third Handover Interface (HI 3 ). 
         [0049]    The CC is information different from the IRI, which is exchanged between two or more users of a telecommunications service and, more in general, includes information which may, as part of some telecommunications service, be stored by one user for subsequent retrieval by another user. 
         [0050]    In both arrangements of  FIGS. 1 and 2 , electronic warrants  21  according to the inventions are loaded in an Administration Function. 
         [0051]    The electronic warrant may be in any electronic format, including standardised electronic formats. It may consist of a file, coded by using any commonly used format, containing the scope of the warrant, in terms of targets of the investigations. 
         [0052]    An example of a warrant record is shown in the table of  FIG. 3 . 
         [0053]    This record format may be extended to specify a blacklist of users, for whom it may not be possible to order interception and/or data retention queries, namely “immune users”. An example of a format of the record is shown in the table of  FIG. 4 . 
         [0054]    This record may be digitally signed in order for authentication and to ensure its integrity. The format may be unified for the scopes of lawful interception, data retention and for other investigation tools. The receiving system, e.g. a data retention system or a lawful interception management system, may be able to verify it by using a public key. Therefore, users having the rights to set warrants may be configured with its secure certificate. 
         [0055]    In case blacklist records are exchanged using an electronic or non electronic interface, or if, in general, they could be subjected to processing by operator&#39;s personnel, the user identities may be sent in encrypted format. In this way, user identities would not be known to users that do not have access to the related encryption key. 
         [0056]    Preferred embodiments of the invention are now discussed with references to  FIGS. 5 to 11 . 
         [0057]      FIG. 5  shows a first scenario that depicts the flow of information between the LEA and the lawful interception system. 
         [0058]    Two roles are assigned to different users at the LEA side: users with the LEA supervisor role ( 30 ) are enabled to manage (insert, modify, view, delete) warrants, and users with the LEA investigator role ( 31 ) are enabled to manage target of interceptions. 
         [0059]    At step  33  a LEA Supervisor  30  communicates with the LI-IMS  32  by sending a warrant containing a warrant record in the form described in  FIG. 3 . At step  34  the LI-IMS stores the warrant data, and at step  35  sends a message to the 
         [0060]    LEA indicating successful warrant setting. At a subsequent time, a LEA investigator  31  sets a target for interception at step  36 . At step  37  the LI-IMS checks if the target of interception is authorised by a warrant. Checks on the set target against the warrant may comprise checking that the LEA to which the investigator belongs is authorised, for instance that is included in the Authorised LEA&#39;s list in the warrant record, checking that the specified identities are authorised, checking that other options are authorised, for instance content of communication interception, and checking that the time period is authorised by the warrant. 
         [0061]    If the outcome of the check is positive, at step  38  the LI-IMS sends a message to LEA indicating successful setting of the target; otherwise at step  39  the LI-IMS sends a message to LEA indicating the rejection of target setting. 
         [0062]    The skilled in the art appreciates that there is no one-to-one relation between the warrant data and the target of interception. For example, if the LEA supervisor authorises by means of a warrant the interception on a user identified by a given MSISDN, and sets the warrant field “Extend the interception authorisation to other known identities” to “Yes”, then a LEA investigator may obtain other identities of the same user (e.g. IMEI or IMSI) by the reports of interceptions, and is authorised to set those identities as target of interception even without a specific warrant. 
         [0063]    In a similar way, if a warrant contains a field indicating that is possible to extend the interception authorisation to other identified users, then the investigator will be authorised to set as target of interception all users that communicate with the user for which the warrant was inserted. 
         [0064]    In some situations, it may be required to allow the setting of target of interception even when no warrant was inserted in advance. This scenario is depicted in  FIG. 6 . In this case a LEA investigator  31  at step  40  sets the target for interception; the LI-IMS  32  at step  41  acknowledges the setting by sending a message indicating successful target setting; after the target has been set, at step  42  the LI-IMS checks if the target is authorised by a warrant; if this is not the case, at step  43  the LI-IMS sends a notification to a LEA supervisor  30 ; the LEA supervisor may then decide to allow the continuation of the interception or, at step  44 , to order the removal of the target of interception.  FIG. 7  shows a possible embodiment of the flow between LEA and LI-IMS for handling warrants containing list of immune users, as discussed above. In this scenario two LEA supervisor roles are introduced; a standard LEA supervisor  30 , who can manage normal warrants, and a LEA supervisor 2   50 , who is enabled to manage warrants specifying a list of immune users. At step  51  the LEA Supervisor 2   50  communicates with the LI-IMS  32  by inserting a warrant containing a list of immune users. At step  52  the LI-IMS acknowledges the successful setting of the warrant. At step  53  LEA supervisor  30  communicates with the LI-IMS by inserting a warrant containing a list of target users; at step  54  the LI-IMS checks if the specified identities are immune, as specified by the warrant previously set by a supervisor 2  user, and if the authorised LEAs specified in the target warrant are included in the list of LEAs contained in the warrant specifying the immune users; in fact in case of immune users only authorised LEAs are enabled to set the interception. If the target identities are not immune, or if they are immune but the list of LEAs is included in the authorised LEAs, at step  55  the warrant is successfully set, otherwise at step  56  the warrant setting is rejected. 
         [0065]    In order to prevent the illegal interception of immune users, the insertion of both the warrant with immune users and the warrant with targets of interception is not mandatory; in case only the warrant with immune users is inserted, a possible embodiment of the flow between LEA and LI-IMS is depicted in  FIG. 8 . At step  61  the LEA Supervisor 2   50  communicates with the LI-IMS  32  by inserting a warrant containing a list of immune users. At step  62  the LI-IMS acknowledges the successful setting of the warrant. At a subsequent time, a LEA investigator  31  sets a target for interception at step  63 . At step  64  the LI-IMS checks if the target of interception belongs to a list of immune users as specified by a warrant: if the check is negative at step  65  the LI-IMS sends a message to LEA indicating successful setting of the target; otherwise at step  66  the LI-IMS sends a message to LEA indicating the rejection of target setting. 
         [0066]    According to the invention, the communication between the LEA and the data retention system for the managing of warrants is performed in a way very similar to the one described above for the communication between the LEA and the lawful interception system. 
         [0067]      FIG. 9  shows a scenario that depicts the flow of information between the LEA and the data retention system for setting a warrant according to the present invention. 
         [0068]    Two roles are assigned to different users at the LEA side: users with the LEA supervisor role ( 30 ) are enabled to manage (insert, modify, view, delete) warrants, and users with the LEA investigator role ( 31 ) are enabled to query the data retention database. At step  71  a LEA Supervisor  30  communicates with the ADRS  70  by sending a warrant containing a warrant record in the form of the one described in  FIG. 3 . At step  72  the ADRS stores the warrant data, and at step  73  sends a message to the 
         [0069]    LEA indicating successful warrant setting. At a subsequent time, a LEA investigator  31  sends a query request at step  74 . At step  75  the ADRS checks if the query parameters are authorised by a warrant: Checks on the query parameters against the warrant comprise: checking that the LEA to which the investigator belongs is authorised, that is included in the Authorised LEAs list in the warrant record, checking that the specified identities are authorised, and that the query time period is authorised by the warrant. 
         [0070]    If the check is positive at step  76  the ADRS sends a message to LEA indicating successful acknowledgement of the query request; otherwise at step  77  the ADRS sends a message to LEA indicating the rejection of the query request. 
         [0071]    Again, the skilled in the art appreciates that there is no one-to-one relation between the warrant data and the user identities specified in the query: for example, if the LEA supervisor authorises by means of a warrant the interception on a user identified by a given name, and sets the warrant field “Extend the query authorisation to other known identities” to “Yes”, then a LEA investigator may order the query on the given name and obtain other identities of the same user, and is authorised to extend the query also on those identities even without a specific warrant. 
         [0072]      FIG. 10  shows an illustrative embodiment of the flow between LEA and ADRS for handling warrants containing list of immune users, as discussed above. In this scenario two LEA supervisor roles are introduced; a standard LEA supervisor  30 , who can manage normal warrants, and a LEA supervisor 2   50 , who is enabled to manage warrants specifying a list of immune users. At step  80  the 
         [0073]    LEA Supervisor 2   50  communicates with the ADRS  70  by inserting a warrant containing a list of immune users. At step  81  the ADRS acknowledges the successful setting of the warrant. At step  82  LEA supervisor  30  communicates with the ADRS by inserting a warrant containing a list of users authorised for queries; at step  83  the ADRS checks if the specified identities are immune, as specified by the warrant previously set by a supervisor 2  user, and if the authorised LEAs specified in the target warrant are included in the list of LEAs contained in the warrant specifying the immune users; in fact in case of immune users only authorised LEAs are enabled to set queries. If the target identities are not immune, or if they are immune but the list of LEAs is included in the authorised LEAs, at step  84  the warrant is successfully set, otherwise at step  85  the warrant setting is rejected. 
         [0074]    In order to prevent illegal querying on the ADRS of immune users, the insertion of both the warrant with immune users and the warrant with targets of interception may not be mandatory; in case only the warrant with immune users is inserted, a possible embodiment of the flow between LEA and ADRS is depicted in  FIG. 11 . At step  90  the LEA Supervisor 2   50  communicates with the ADRS  70  by inserting a warrant containing a list of immune users. At step  91  the ADRS acknowledges the successful setting of the warrant. 
         [0075]    At a subsequent time, a LEA investigator  31  sends a query request at step  92 . At step  93  the ADRS checks if the user specified in the query belongs to a list of immune users as specified by a warrant: if the check is negative at step  94  the ADRS sends a message to LEA indicating acknowledgement of the query request; otherwise at step  95  the ADRS sends a message to LEA indicating the rejection of the query request. 
         [0076]    It has been shown that the invention fully achieves the intended aim and objects, since it allows to block automatically any illegal usage of the lawful interception and of the data retention systems. 
         [0077]    Besides the invention provides a simple and easy to implement solution, that does not require additional handover interfaces between the LEA and LI-IMS or ADRS. 
         [0078]    Clearly, several modifications will be apparent to and can be readily made by the skilled in the art without departing from the scope of the present invention. 
         [0079]    For example, in the embodiments described above the introduction of new messages on the handover interface (“Insert a warrant”, “Successful warrant insertion”, “Unsuccessful warrant insertion”) has been shown. As a possible alternative, the warrant record may be included as additional data in the operation used to set the target of interception or to order a query. 
         [0080]    Besides, several modification can be made in the management of immune users: for example, as an optional feature, the black-listing of targets could be applied by the LI-IMS system also on interceptions authorised on other users, if the black-listed target is involved in the communication. Possible actions the system may perform are completely deny the interception, aborting it when a blacklisted user is involved, or block the flow of information (call content and/or number identification) related to the black-listed target, leaving the rest of the communication available to the agency. 
         [0081]    Likewise, the black-listing of targets could be applied by the ADRS system also on queries authorised on other users, if the black-listed target is involved in the communication. In this case the system could filter out the related communications entirely or only the black-listed number from the query results. 
         [0082]    Therefore, the scope of the claims shall not be limited by the illustrations or the preferred embodiments given in the description in the form of examples, but rather the claims shall encompass all of the features of patentable novelty that reside in the present invention, including all the features that would be treated as equivalents by the skilled in the art. 
         [0083]    Where technical features mentioned in any claim are followed by reference signs, those reference signs have been included for the sole purpose of increasing the intelligibility of the claims and accordingly, such reference signs do not have any limiting effect on the interpretation of each element identified by way of example by such reference signs.