USRE45348E1 - Method and apparatus for intercepting events in a communication system - Google Patents

Abstract

An intercept system provides more effective and more efficient compliance with legal intercept warrants. The intercept system can provide any combination of operations that include near-real-time intercept, capture of intercepted data in structured authenticated form, clear text intercept for communications where there is access to encryption keys, cipher text intercept for communications where there is no access to encryption keys, provision of transactional logs to the authorized agency, interception without altering the operation of the target services, and encryption of stored intercepted information.

Description

CROSS REFERENCE TO RELATED APPLICATIONS

The presentThis patent application is a reissue application for commonly assigned U.S. Pat. No. 7,680,281, issued from U.S. patent application Ser. No. 12/211,790, filed on Sep. 16, 2008, which is a continuation of U.S. patent application Ser. No. 11/255,291, filed on Oct. 20, 2005, now U.S. Pat. No. 7,441,271, which claims priority to U.S. Provisional Patent Application No. 60/620,889, filed on Oct. 20, 2004, each of which are hereby incorporated by reference in their entirety.

BACKGROUND

Wireless digital communication systems wirelessly transport electronic mail (email), text messages, text files, images, Voice Over Internet Protocol (VoIP) data, and any other types of digital data and communications to wireless devices. Wireless communication system providers are facing the prospects of having to comply with a variety of legal-intercept (wiretap) requirements. Authorization for a legal intercept may include warrants for “wiretap/interception”, “search and seizure”, or both. For example, the requirements outlined in CALEA (US Communications Assistance for Law Enforcement Act of 1994, http://www.askcalea.net/) may have to be met by any proposed solution. In another example, the requirements outlined by the Australian Communications Authority (http://www.aca.gov.au) in the Australia Telecommunications Act of 1997 may have to be met by any proposed solution.

There are several technical challenges complying with these legal intercept requirements that may not exist in conventional telephone systems. For example, the intercepted data may be encrypted. The wireless network provider must be able to intercept the encrypted data, and any other non-encrypted information, without tipping off the intercept target that the wiretap is taking place.

The wiretap warrant may require the communication system provider to provide any intercepted information in substantially real-time or may require the communication system provider to intercept and store communications in an automated manner for later retrieval and analysis by the law enforcement agency. Evidentiary problems exist with information intercepted outside the presence and control of the enforcement agency. For example, the intercepted communications could be either intentionally or inadvertently deleted. A system malfunction could also prevent some communications from being intercepted. There is also the evidentiary issue of whether or not someone has tampered with the intercepted information. It may also be necessary to prevent technicians operating the communication system from accessing or viewing the intercepted information.

The invention addresses these and other problems with the present technology.

SUMMARY OF THE INVENTION

An intercept system provides more effective and more efficient compliance with legal intercept warrants. The intercept system can provide any combination of operations that include near-real-time intercept, capture of intercepted data in structured authenticated form, clear text intercept for communications where there is access to encryption keys, cipher text intercept for communications where there is no access to encryption keys, provision of transactional logs to the authorized agency, interception without altering the operation of the target services, and encryption of stored intercepted information.

The foregoing and other objects, features and advantages of the invention will become more readily apparent from the following detailed description of a preferred embodiment of the invention which proceeds with reference to the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of a communication management system that operates a legal intercept system.

FIG. 2 is a diagram of an example log file generated for intercepted data.

FIG. 3 is a flow diagram showing in more detail how the log files inFIG. 2 are generated.

FIG. 4 is another block diagram showing how the legal intercept system operates with different types of encryption.

FIG. 5 is a diagram showing how intercepted data with different encryptions is converted into a log file.

FIG. 6 is a flow diagram showing in more detail how different types of encrypted data are formatted into a log file.

FIG. 7 is a diagram showing how a common transport is used for sending encrypted data.

FIG. 8 is a block diagram showing how an encryption schema in the communication management system is used in cooperation with the intercept system.

DETAILED DESCRIPTION

In the description below, an intercept event refers to an event where an agency issues a warrant requesting data interception for a targeted user. A targeted user is identified by a unique label, such as a username or account number, that corresponds to a user who is under intercept. A communication event, transaction, or intercept data is any message either sent or received by the targeted user. The intercept data can include synchronization messages, email data, calendars, contacts, tasks, notes, electronic documents, files or any other type of data passing through the communication management system.

Communication Management System

FIG. 1 shows an example of acommunication network12 that may operate similarly to the networks described in U.S. patent application Ser. No. 10/339,368 entitled: CONNECTION ARCHITECTURE FOR A MOBILE NETWORK, filed Jan. 8, 2003, and U.S. patent application Ser. No. 10/339,368 entitled: SECURE, TRANSPORT FOR MOBILE COMMUNICATION NETWORK, filed Jan. 8, 2003, which are both herein incorporated by reference.

Thecommunication system12 in one implementation is used for intercepting data pursuant to legal search warrants. For example, a law enforcement agency may require the operator ofcommunication system12 to intercept all messages sent to and from amobile device21. It should be understood that this is just one example of acommunication system12 and that the legal intercept system described in more detail below can operate with any communication network that is required to provide legal interception.

Thecommunication system12 includes amobile network14, anenterprise network18, and acommunication management system16 that manages communications between themobile network14 and theenterprise network18. Themobile network14 includesmobile devices21 that communicate with an IP infrastructure through a wireless or landline service provider. Sincemobile networks14 are well known, they are not described in further detail.

Theenterprise network18 can be any business network, individual user network, or local computer system that maintains local email or other data for one or more users. In the embodiment shown inFIG. 1, theenterprise network18 includes anenterprise data source34 that contains auser mailbox44 accessible using a Personal Computer (PC)38. In one example, theenterprise data source34 may be a Microsoft® Exchange® server and the PC38 may access themailbox44 through a Microsoft® Outlook® software application. Themailbox44 anddata source34 may contain emails, contact lists, calendars, tasks, notes, files, or any other type of data or electronic document.

The PC38 is connected to theserver34 over a Local Area Network (LAN)35. The PC38 includes memory (not shown) for storing local files that may include personal email data as well as any other types of electronic documents.Personal client software40 is executed by aprocessor37 in the PC38. Thepersonal client40 enables themobile device21 to access email, calendars, and contact information as well as local files inenterprise network18 associated with PC38.

Thecommunication management system16 includes one ormore management servers28 that each include aprocessor33. Theprocessor33 operates atransfer agent31 that manages the transactions between themobile device21 and theenterprise network18. Auser database42 includes configuration information for different users of the mobile communication service. For example, theuser database42 may include login data formobile device21.

While referred to as acommunication management system16 andmanagement server28, this can be any intermediary system that includes one or more intermediary servers that operate between themobile network14 and the enterprise orprivate network18. For example, a separate Smart Device Server (SDS)30 may be used inmanagement system16 for handling communications with mobile devices inmobile network14. Correspondingly, a SEVEN Connection Server (SCS)32 may be used for handling communications with personal clients inenterprise networks18.

Legal Interception

A Legal Intercept (LI)software module50 is operated by theprocessor33 and communicates with thetransfer agent31 in order to captureintercept data49 associated with targeteduser51B. An operator sets up aconfiguration file51 that is then used by the legal intercept module to automatically intercept communications for a particular target user and then format the intercepted communications into self authenticating log files.

An operator runs atoolkit utility54 from acomputer terminal52 to configure themanagement server28 for capturingintercept data49. Thetoolkit utility54 is used for creating and loading theconfiguration file51 into memory inmanagement server28 and can also display detectedintercept data49. To initiate an intercept, an entry is loaded into theconfiguration file51. To stop capturingintercept data49, the system administrator deletes the entry orconfiguration file51 from memory. Changes to theconfiguration file51 ofmanagement server28 may be automatically replicated to other management servers that are part of thecommunication management system16. Thetoolkit utility54 may have tightly controlled access that only allows operation by a user with an authorized login and password.

Thetoolkit54 allows the operator to view, add, modify, and delete awarrant sequence number51A, user identifier (ID)51B, andencryption key57 in theconfiguration file51. The warrant identifier may be the actual sequence number for a wiretap or search warrant issued by a court of law and presented to the operator ofcommunication management system16 by a federal, state, or municipal government agency. Theuser ID51B for example may be an identifier used bycommunication management system16 to uniquely identify differentmobile clients21.

Thepublic encryption key57 may be the public key component of a public/private key pair, such as a Pretty Good Privacy (PGP) or GNU Privacy Guard (GPG) public key, for encrypting theintercept data49. In one embodiment, thelegal intercept module50 may not allow themanagement server28 to start an interception process until a validpublic key57 is loaded intoconfiguration file51. This ensures that the intercepteddata49 can be immediately encrypted while being formatted into alog file56. If this encryption fails for any reason, thelegal intercept module50 may shut down the intercept process ensuring that nointercept data49 is stored in the clear.

Theconfiguration file51 may also include one or more entries defining a transport protocol, destination, and associated configuration values for the transmission of intercepted data via a network. In one embodiment, this could include a destination email address associated with a Simple Mail Transfer Protocol (SMTP) host and port number or other Internet Protocol (IP) destination address that is used by thelegal intercept module50 to automatically transmit theintercept data49 to mail box77 on aremote server76 that is accessible by the agency issuing the warrant.

After theconfiguration file51 is enabled, thelegal intercept module51starts intercepting data49 associated with the targeted user identified byuser ID51B. As mentioned above, this can include any emails, calendar information, contacts, tasks, notes, electronic documents, files or any other type of control or content data associated withuser ID51B. The intercepted data can include any type of communications such as email sent or received, calendar items sent or received, and other data sent/received by and from the targetedsmart device21. The capturedintercept data49 may then be encrypted using theencryption key57 contained in theconfiguration file51. The encrypted copy of the capturedintercept data49 may then be formatted and written to logfile56.

Data Delivery

Thelegal intercept module50 running on eachmanagement server28 may periodically poll the directory or location containing the encrypted intercept log files56 for each user ID under intercept for the presence of new files or data. The poll period in one example is approximately every minute. Of course this is only one example and any user configurable time period can be used.New intercept data49 which has been stored in one or more log files56 and identified by thelegal intercept module50 during the polling process may be automatically reprocessed and/or transmitted according to the specification inconfiguration file51. As an alternative to storingencrypted intercept data49 inlog file56 on a file system, intercept data may be stored indatabase42. Also, as shown inFIG. 4, thelog file56 may be stored in analternative file system53 located within themanagement server28. The agency issuing the warrant can then access the data contained in log files56 ordatabase42 in one of many different ways.

In one implementation, an official from the agency physically sits at terminal52 at the location ofcommunication management system16. The agency official then reads the log files56 in semi-real-time as theintercept events49 are being detected in themanagement server49. The agency official then uses terminal52 to store or copy the log files56 onto a portable storage medium, such as a Compact Disc (CD), memory stick, etc. In this implementation, the legal intercept log files56 may not reside inuser database42 at all, or may only reside indatabase42 for some relatively brief period of time while being transferred onto the portable storage media.

A copy of the log files may be stored onto the portable storage medium while the same log files remain in thecommunication management system16. The copy of the log files in themanagement system16 could then be used, if necessary, for evidentiary purposes when admitting the copy under control of the agency official into evidence.

In an alternative implementation, thelegal intercept module50 may automatically send the log files56 for the intercepted events to an email mailbox77 operated in aremote server76. Theremote server76 may be located in a wireless service provider network or may be located at the facilities of the enforcement agency issuing the warrant. In this implementation, a terminal72 at theremote location70 may include atoolkit utility54 that has some of the same functionality astoolkit54. Theutility54 only allows authorized users to decrypt and access the log files56 received fromcommunication management system16.

For example, thetoolkit utility54 may include public and private PGP orGPG encryption keys57 and55, respectively, that are associated with thepublic encryption key57 previously loaded intoconfiguration file51. Only personnel having authorized access to thetoolkit54 can decrypt and read the log files56 previously generated and encrypted bylegal intercept module50. This provides additional privacy of theintercept data49 from technical personnel of thecommunication management system16 that may not be authorized to view theintercept data49.

Theintercept module50 may transfer each capturedlog file56 to aSMTP email server76 via the Simple Mail Transfer Protocol (SMTP). TheSMTP server76 stores eachlog file56 in an inbox of mailbox77. The name of the mailbox77 may be the same as the warrant sequence number @ the agency's domain name. For example, warrant123@LAPD.com. The warrant sequence number may correspond with thewarrant identifier51A inconfiguration file51 and the domain name may correspond with theIP address51D inconfiguration file51. Once transmitted and accepted by theSMTP email server76, thelog file56 may be automatically deleted fromuser database42.

The agency issuing the warrant can retrieve the captured log files56 inremote server76 for a particular user ID under interception using for example the Post Office Protocol (POPv3). The agency is given the name ofemail server76, POP and SMTP port numbers, the mailbox id (warrant sequence number51) and a password to access the mailbox77. The agency then retrieves log files56 in mailbox77 using POP. Once a file is downloaded from the mailbox77 to anagency terminal72, thelog file56 may be automatically deleted from the mailbox77.

Log Files

Referring toFIGS. 1 and 2, thelegal intercept software50 generates log files56 in a structured manner that provides more secure and reliable data authentication. In this example, anintercept directory60 is loaded withlog files56 generated to account for every minute of a particular time period, such as an entire day. Thelegal intercept50 may generate a name fordirectory60 that identifies the contents as legal intercepts, for a particular user ID and for a particular day. Of course this is just one naming convention that can be used to more efficiently organize log files.

The log files56 stored indirectory60 may indicate the number of events intercepted for the targeted device during each minute. For example, afirst log file56A is identified by the following log file name: fe0-2005/09/23-00:00.ASC, containing a single line that reads as follows: “0 events logged in the last minute”. This indicates that a management server fe0 on Sep. 23, 2005, at 12:00 midnight logged zero intercept events for a particular user ID during the specified time period. Asecond log file56B is named to identify a next minute of the intercept period and indicates that between 12:00 A.M and 12:01 A.M, on the same day, no intercept events were logged.

The first detected intercept events for this particular user ID for this particular day were detected inlog file56C identified by the log file name: fe0-2005/09/23-00:02.ASC, the first and/or last line of which reads “3 events logged in the last minute”. Logfile56C indicates that 3 intercept events were detected on Sep. 23, 2005, between 12:01 A.M. and 12:02 A.M. Thelegal intercept50 generates this contiguous set of log files56 that cover each minute or other configured interval of the intercept period.

Thelegal intercept50 may also load a first entry into thelog file directory60 that lists thewarrant id51A,PGP key57, etc. Thelegal intercept50 may also generate alog file56 that indicates any management server status-change events. For example, if themanagement server28 conducts a graceful shutdown, alog file56 may be generated that indicates when the shut down occurred and possibly the cause of the shutdown.

This highly structured log file format provides the agency official a quick indicator of when intercept events are detected for a particular target user. Further, as shown above, the log files are created contiguously for predetermined time periods over a particular intercept period even when no intercept events are detected. This provides further verification that thelegal intercept50 was actually in operation and continuously monitoring for intercept events during the intercept period.

As described above, the log files56 may be stored into a portable storage media that can be transported by an agency official. Alternatively, the log files56 may be stored in theuser database42 in thecommunication management system16 for later retrieval by the agency official viatoolkit54. In another implementation, the log files56 may be sent to the mailbox77 in aserver76 in a mobile operator infrastructure which is accessible by the agency official.

FIG. 3 explains in further detail how thelegal intercept module50 might generate the log files. Inoperation61, communications are monitored for a particular targeted user for predetermined time periods over an intercept period. In one example as described above, the predetermined time period may be one minute. Of course, time periods of less than one minute or more than one minute may also be used. The duration of these time periods may also be configurable by setting a parameter inconfiguration file51. If no intercept events are detected during the predetermined time period inoperation62, an empty log file is generated for that time period inoperation63.

When intercept events are detected, all the intercepted data for that time period is formatted into asame log file56 inoperation64. The log file is encrypted inoperation65 using the encryption key57 (FIG. 1) loaded by thetoolkit54 intoconfiguration file51. All of the encrypted log files56 associated with a particular targeted user for a particular intercept period are stored in a same intercept directory60 (FIG. 2). For example, all log files generated for a particular user ID for a same day are stored in the same intercept directory. If the current day of legal interception is not completed inoperation66, further monitoring and interception is performed inoperation61.

When interception for a current interception period is completed, a Cyclic Redundancy Check (CRC) value, or some other type of digital certificate/signature, may be generated inoperation67. The CRC can be used to verify that the contents ofintercept directory60 have not been tampered with or deleted after their initial generation. The CRC may be encrypted in operation68 and then separately emailed to the agency or separately stored for later validation. As discussed above, the encrypted log files may then either be emailed to a mailbox or stored locally for later retrieval by the enforcement agency.

Thus, the individual log file encryption inoperation65 ensures the authenticity of intercepted events for a particular time period and the CRC generated inoperation67 ensures that none of the individual log files have been removed or replaced.

Encrypted Intercept Data

Referring toFIG. 4, as described above, the log files56 may be stored indatabase42 or in afile system53 within themanagement server28. A single or multi-tiered encryption scheme may be used innetwork12. For example, thepersonal client40 may make anoutbound connection25 to themanagement server28. Thepersonal client40 registers the presence of a particular user to themanagement server28 and negotiates a security association specifying a cryptographic ciphersuite (including encryption cipher, key length, and digital signature algorithm) and a unique, secret point-to-point encryption key29 overconnection25. In one example, the key29 is an Advanced Encryption Standard (AES) key. Of course, encryption ciphers other than AES can also be used. Theencryption key29 enables secure communication betweenmanagement server28 andPC38 overconnection25.

Themobile device21 also negotiates a point-to-point security association, specifying a cryptographic ciphersuite and aunique encryption key27, with themanagement server28. In one example, the point-to-point encryption key27 is also an AES encryption key. The negotiated security association that includesencryption key27 enables secure point-to-point communication between themobile device21 and themanagement server28 over connection23. Each differentmobile device21 negotiates a different security association that includes a unique encryption key27 with themanagement server28.

The point-to-point encryption key27 may be used for encrypting control data that needs to be transferred between themobile device21 andmanagement server28. The point-to-point encryption key29 may be used for encrypting control data that needs to be transferred between themanagement server28 andpersonal client40. For example, the control data may include login information and transaction routing information.

An end-to-end security association, specifying a cryptographic ciphersuite and aunique encryption key46, is negotiated between themobile device21 and thepersonal client40. In one example, the end-to-end encryption key46 is also an AES encryption key. The end-to-end encryption key46 in one example is used for encrypting transaction payloads transferred betweenpersonal client40 andmobile device21. For example, the end-to-end encryption key46 may be used for encrypting the content of emails, files, file path names, contacts, notes, calendars, electronic documents and any other type of data transferred between mobile device and the PC. The end-to-end encryption key46 is only known by themobile device21 and thepersonal client40. Data encrypted using the end-to-end key46 cannot be decrypted by themanagement server28.

Referring toFIGS. 4 and 5, thelegal intercept module50 can producelog files56 fromintercept data49 that have any combination ofunencrypted data49A sent in the clear, point-to-pointencrypted data49B encrypted using the point-to-point encryption keys27 or29, and end-to-end encrypted data49C encrypted using the end-to-end encryption key46.

Thecommunication management system16 has access to the point-to-point encryption keys27 and29 used for encrypting the point-to-pointencrypted information49B. Therefore, themanagement system16 can automatically decrypt the point-to-pointencrypted information49B before it is reformatted intolog file56.

The end-to-end encryption keys46 are only shared between theendpoints21 and38 and are unknown to thecommunication management system16. Therefore, the agency issuing the warrant may be required to extract the end-to-end encryption keys46 either at themobile device21 or at theenterprise server34 orpersonal computer38. The end-to-end encrypted information49C may then be decrypted at a later time separately from the point-to-pointencrypted information49B.

For example, after receiving and decrypting thelog file56, the enforcement agency may then independently conduct a seizure of the end-to-end encryption key46 from either theenterprise network18 or themobile device21. The enforcement agency could then separately decryptinformation56B inlog file56 with the seized end-to-end encryption key46.

FIG. 6 explains in more detail how thelegal intercept module50 handles the decryption and reformatting of intercept data into log files. Inoperation80, themanagement server28 is configured to conduct a legal intercept for a particular user ID as described above inFIG. 1. Accordingly, themanagement server28 begins intercepting data for the identified user ID inoperation82.

Inoperation84, any point-to-pointencrypted portion49B of the intercepted data49 (FIG. 5) is decrypted. Inoperation86, the decrypted point-to-point data is combined with anyinformation49A in theintercept data49 received in the clear. The unencrypted data is then formatted into anunencrypted portion56A of thelog file56 inFIG. 5. Any end-to-end encrypted data49C is then combined in thesame log file56 assection56B inoperation88. Thelog file56 is then possibly encrypted inoperation90 and then either stored in a local database or automatically sent to a remote server.

Detecting Different Types of Intercept Data

FIGS. 7 and 8 explain in more detail how a particular data format used by thecommunication system12 can be used to identify point-to-point and end-to-end encrypted intercept data.FIG. 7 shows how encryption can be performed differently for different types of data or for data associated with different destinations.Intercept data102 includescontent data108 such as the contents of an email message, an electronic document, or any other type of information that should only be accessed by two endpoints. Thecontent data108 in this example is encrypted using an end-to-end encryption key.

Asecond portion106 ofintercept data102 may include control information that only needs to be processed by one particular server. In this case,control data106 may be encrypted using a first point-to-point encryption key. Athird portion104 ofintercept data102 may have other control information, for example, error checking data, that needs to be processed by a different server. Accordingly, theerror checking data104 is encrypted using a second point-to-point encryption key different than either of the other two encryption keys used for encryptingdata108 and106.

FIG. 8 shows in more detail anencryption schema112 is used by themobile device21,management server28, andpersonal client40 when processing transactions between a source and a target device. In the example below, themobile device21 is operating as a source for sending atransaction110. Thetransaction110 requestspersonal client40 to send adocument114 located in a personal directory inlocal memory116 ofPC38. Thepersonal client40 operates as a target for thetransaction110 and themanagement server28 operates as the transfer agent for transferring thetransaction110 from themobile device21 to thepersonal client40.

It should be understood that this is only an example, and the devices shown inFIG. 8 can process many different types of transactions. For example, thetransaction110 may request synchronization of emails in thePC38 with emails in themobile device21. Further, any device can operate as a source or target for the transaction. For example, thepersonal client40 operates as a source and themobile device21 operates as a target when atransaction111 is sent as a reply to request110.

Themobile device21,management server28, and thepersonal client40 are all configured with anencryption schema112 that identifies how specific items in thetransaction110 are to be encrypted. Each device is also configured with different security associations as described above inFIG. 4. For example, themobile device21 has both Point-to-Point (PP)key27 and End-to-End (EE)key46.Management server28 has PP key27 and PP key29, and thePC38 has PP key29 andEE key46.

Themobile device21 forms therequest transaction110. One example of a request is as follows.

	Request:	{auth_token = “abc”,

	device_id = “xyz”,
	method_id = “GetDocument”,
	args = {path = “/docs”}
	}

Mobile device21 attaches an auth_token to transactions sent to themanagement server28. For example, themobile device21 may be required to authenticate to themanagement server28 by transmitting a username and password prior to being permitted to submit other transactions for processing. Themanagement server28 issues themobile device21 an auth_token after successfully validating the username and password against information in theuser database42. Themobile device21 then attaches the auth_token to subsequent transactions sent to themanagement server28. Themanagement server28 uses the auth_token to identify and authenticate the source of each transaction and to determine where to route the transaction.

The device_id identifies the particularmobile device21 sending therequest110. The device_id may be necessary, for example, when a user has more than one mobile device. Thepersonal client40 can use different device_id values to track when synchronization information was last sent to each of multiple different mobile devices. The device_id can also be used by either themanagement server28 or thepersonal client40 to determine how to format data sent to particular types ofmobile devices21. For example, data may need to be formatted differently for a cell phone as opposed to a personal computer. The device_id can also be used to correlate a known security association with a particular mobile device.

The method_id item in the example identifies a particular function GetDocument associated withrequest110. The method_id item also requires the inclusion of related argument items that identify the parameters for the GetDocument function. For example, the argument items might include the expression path=“/docs” identifying the pathname where the requested documents are located.

In order to prepare therequest110 for transmission, themobile device21 performs a pattern match of therequest110 using theencryption schema112. This pattern match separates the items inrequest110 into different channels. One example of the different channels is shown below. In this example, the items in each channel are associated with predefined security associations: clear, pp, and ee.

Channels:
	{clear = {device_id = “xyz”}
	pp = {auth_token = “abc”, method_id = “GetDocument”}
	ee = {args = {path = {path = “/docs”}}}
	}

The channel contents are encoded (via a process commonly known as serialization) into arrays of bits or bytes referred to as data groups. These groupings of bits or bytes are referred to generally below as arrays, but can be any type of partition, group, etc.

The contents of the clear channel are encoded into an array of bits referred to asdata_group_—1, the contents of the pp channel are encoded into an array of bits referred to asdata_group_—2, and the contents of the ee channel are encoded into an array of bits referred to asdata_group_—3. The contents of each channel need to be encoded into bit arrays so that they can be encrypted. The contents of the channels after being encoded into bit arrays are represented as follows.

	Encoded
	Channels:	{clear = data_group_1
		pp = data_group_2
		ee = data_group_3 }

The bit arrays are then encrypted according to the security association parameters for each channel. According to theencryption schema112, bits in the clear channel (data_group_—1) are not encrypted. The bits in thepp channel data_group_—2 are encrypted using the point-to-point security association betweenmobile device21 andmanagement server28, usingPP key27, and are referred to after encryption aspp_data_group_—2. The bits in theee channel data_group_—3 are encrypted using the end-to-end security association betweenmobile device21 andpersonal client40, usingEE key46, and are referred to after encryption asee_data_group_—3. The data groups are represented as follows after encryption:

	Encrypted
	Channels:	{clear = data_group_1
		pp = pp_data_group_2
		ee = ee_data_group_3}

The bits making up the encrypted and unencrypted channels are then encoded into one or more packets. For clarity, the description below will refer to a single packet, however, the data from the channels may be contained in multiple packets. Some of the contents of the packet are shown below.

Packet:

	Header	length
		version
		flags
	Payload	count = 3
		“clear”
		data_group_1
		pp_data_group_2
		“ee”
		ee_data_group_3

Information in the packet header may include the packet length, a version number, and other flags. The packet payload includes a count identifying 3 pairs of items. The three items include the non-encrypted contents in the clear channel, the pp encrypted contents of the pp channel, and the ee encrypted contents of the ee channel. The packet is then transported bymobile device21 to themanagement server28.

The transfer agent operating inserver28 receives the packet. The bits in the packet are separated into the different channels clear=data_group_—1, pp=pp_data_group_—2, and ee=ee_data_group_—3.

The data in the clear channel does not need to be decrypted. The transfer agent decrypts the only bits in channels for which it has a known security association. The transfer agent, as a member of the point-to-point security association betweenmobile device21 andmanagement server28, possesses thePP key27 and therefore decrypts the contents of the pp channel. The transfer agent is not a member of the end-to-end security association betweenmobile device21 andpersonal client40, does not have theEE key46 and therefore does not decrypt the data in the ee channel. Decryption produces the following data groups:clear data_group_—1, pp=data_group_—2, and ee=ee_data_group_—3.

The transfer agent decodes the contents of the clear and pp channels. The contents of the encrypted ee channel are not decoded, but instead are maintained in an unmodified state for eventual transport to thepersonal client40. Decoding produces the following contents.

Decoded
Channels:	{clear = {device_id = “xyz”}
	pp = {auth_token = “abc”, method_id = “GetDocument”}
	ee=ee_data_group_3
	}

A partial request is formed by merging the items of the clear and pp channels. The partial request in this example could look similar to the following:

	Partial Request:	{auth_token = “abc”,
		device_id = “xyz”,
		method_id = “GetDocument”,
		args = { }
		encrypted = {ee=ee_data_group_3}
		}

Thetransfer agent31 in themanagement server28 processes the partial request. In this example, the transfer agent may verify the request is authorized by matching the value of auth_token (“abc”) with contents in the user database42 (FIG. 8). The auth_token and the method_id (“GetDocument”) indicate that thetransaction110 is a document request directed to thepersonal client40.

The transfer agent may identify a user_id=“joe” associated with the auth_token=“abc” and generate the following new request.

	New Request:	{user_id = “joe”,
		device_id = “xyz”,
		method_id = “GetDocument”,
		args = { }
		encrypted = {ee=ee_data_group_3}
		}

Thelegal intercept50 inFIG. 1 may come into play at this point, or earlier in theencryption schema112. For example, thelegal intercept50 checks the user_id in the request with theuser id51B in theintercept configuration file51. In this example, if “joe” matches the user_id51B inconfiguration file51, then the contents in the request are formatted into alog file56 as described above. As can be seen, at this point the new request has already decrypted the auth_token=“abc” and method_id=“GetDocument”. Further, the device_id=“xyz” was received in the clear. Thelegal intercept50 simply has to format these different channels into a log file.

The end-to-end encrypted data ingroup 3 remains encrypted and therefore may not provide all of the information desired for the enforcement agency. However, the decrypted information does provide enough information to adequately indicate that the intercepted data is associated with a particular user_id. The intercepted unencrypted data may also provide further evidence that the enforcement agency can then use to obtain another warrant to seize the ee encryption key from the targeted user.

As described above inFIG. 2, thelegal intercept50 may then attach appropriate time/date stamp headers to this raw data frame to authenticate the time and date when the data was intercepted.

End-to-End Encrypted Data

As described above, thecommunication management system16 may not have access to the end-to-end encryption keys46 (FIG. 2). However, as shown inFIG. 8, themanagement server28 is still capable of identifying data streams belonging to users targeted for interception, as this identifying information is required for routing the datagrams shown above. Thus, thelegal intercept module50 can still intercept data that cannot be immediately decrypted.

The intercept logs56 can therefore contain data encrypted using encryption keys known only to the endpoints. For example, amobile device21 and a desktop connector running on personal computer38 (FIG. 1). Thetoolkit54 inFIG. 1 can facilitate the recovery of the end-to-end keys46.

In order to make use of this functionality, the enforcement agency seeking the information may need to obtain both an intercept warrant, and either a search-and-seizure warrant authorizing the extraction of the configuration data from the smart device client in themobile device21 or a search-and-seizure warrant authorizing the extraction of the end-to-end encryption key from the desktop connector in the PC38 (FIG. 1).

After the authorized agency has executed the necessary warrants, thetoolkit54 is used by the agency to facilitate the recovery of the end-to-end key46. Thetoolkit utility54 then uses the end-to-end key46 to decrypt the end-to-end encrypted information in the log files56.

The system described above can use dedicated processor systems, micro controllers, programmable logic devices, or microprocessors that perform some or all of the operations. Some of the operations described above may be implemented in software and other operations may be implemented in hardware.

For the sake of convenience, the operations are described as various interconnected functional blocks or distinct software modules. This is not necessary, however, and there may be cases where these functional blocks or modules are equivalently aggregated into a single logic device, program or operation with unclear boundaries. In any event, the functional blocks and software modules or features of the flexible interface can be implemented by themselves, or in combination with other operations in either hardware or software.

Having described and illustrated the principles of the invention in a preferred embodiment thereof, it should be apparent that the invention may be modified in arrangement and detail without departing from such principles. Claim is made to all modifications and variation coming within the spirit and scope of the following claims.

Claims (45)

The invention claimed is:

1. A method for intercepting data, comprising:

receiving, at a management server, a connection from a remote client, the connection being initiated by the remote client and established outbound from the remote client;

negotiating a point-to-point encryption scheme with a remote mobile device, the point-to-point encryption scheme negotiated between the management server and the remote mobile device;

receiving, at the management server, a value identifying an intercept target for a legal intercept and an indication that interception is authorized by a warrant, the intercept target corresponding to the remote mobile device;

automatically intercepting, at the management server, data received and/or sent by the intercept target identified by the value, wherein data is intercepted without altering operation of email application services that operate on the remote mobile device;

inspecting packets having the intercepted data to distinguish end-to-end encrypted information from other information that is encrypted according to the point-to-point encryption scheme negotiated with the remote mobile device;

preserving encryption that is included on the end-to-end encrypted information when received while removing encryption that is included on at least a portion of the other information, said other information decrypted using a key obtained during the point-to-point encryption scheme negotiation; and

transferring both the decrypted other information and the end-to-end information from the management server to a remote device.

2. The method ofclaim 1, wherein the packets are intercepted during a requested time period, and the method further comprises:

formatting the data that is intercepted during the requested time period and associated with the target user into one or more first log files, each of the first log files corresponding to a different time segment occurring during the requested time period and indicating one or more intercept events for its corresponding time segment; and

formatting one or more second different log files associated with the requested time period, the second log files indicating inactivity and corresponding to different remaining time segments that occur during the requested time period and that are unrepresented by the first log files that indicate the intercept events such that the first and second log files record monitoring for the entire requested time period independently of whether the data is intercepted intermittently during the requested time period.

3. The method ofclaim 2, wherein the data is intercepted according to an intercept configuration file that includes at least a unique intercept identifier and a user ID identifying the target user.

4. The method ofclaim 2, wherein the log files record an unbroken sequence of continuous monitoring over the requested time period independently of whether the data is intercepted intermittently.

5. The method ofclaim 2, further comprising transferring the log files to the remote device.

6. The method ofclaim 2, further comprising formatting the log files with different time values usable for verifying that communications from the remote mobile device were continuously monitored during the requested time period regardless of whether the data was intercepted intermittently.

7. The method according toclaim 1, wherein the encryption that is included on the end-to-end encrypted information uses a security association that is kept secret from the management server such that the end-to-end encrypted information is kept private with respect to employees associated with the management server.

8. The method ofclaim 1, further comprising determining whether to encrypt at least one of the end-to-end information and the decrypted information prior to said transferring.

9. The method according toclaim 1, further comprising:

combining, at the management server, the end-to-end encrypted information of the intercepted data with the decrypted other information of the intercepted data in a same log file.

10. The method according toclaim 1, further comprising:

storing, at the management server, the intercepted data in a structure format that identifies when the data was intercepted and at the same time provides authentication that the stored intercepted data has not been altered or deleted.

11. The method according toclaim 10, further comprising monitoring communications between the remote client and the remote mobile device for multiple contiguous time periods.

12. The method according toclaim 11, further comprising:

generating, using the management server, log files over an intercept period that encompasses the multiple contiguous time periods;

storing the log files in a same intercept directory;

inserting a warrant identifier received together with the value into the intercept directory; and

generating a name for the intercept directory that identifies the intercept target and the intercept period over which the log files were generated.

13. The method according toclaim 12, further comprising:

encrypting the log files in the intercept directory with an encryption scheme known by an agency issuing the warrant, said encryption performed using the management server that intercepted the data; and

sending the encrypted intercept directory to an electronic mailbox accessible by the agency.

14. The method according toclaim 13, further comprising:

generating a Cyclic Redundancy Check (CRC) or other digital signature value for all of the log files in the intercept directory;

encrypting the resulting generated value; and

providing the encrypted generated value to the enforcement agency, said encrypted generated value sent in a different communication than the encrypted intercept directory, said encrypted generated value verifying that the log files have not been altered.

15. The method according toclaim 1, further comprising: reading an intercept configuration file that contains a warrant identifier, the value identifying the user, an enforcement agency known encryption key and an electronic mailbox address;

upon reading the intercept configuration file automatically intercepting data received and/or sent by the remote mobile device;

formatting any intercepted data into log files that identify when the data was intercepted; and

encrypting the log files using the encryption key.

16. The method according toclaim 1, wherein the end-to-end encrypted information is associated with content and is protected with an end-to-end encryption scheme that is kept secret from any midpoints located on a call path between transmitting and receiving endpoints, and the other information is associated with transaction routing information and is protected with the negotiated point-to-point encryption scheme.

17. A communication management system, comprising:

a management server configured to receive a connection initiated by a remote client and established outbound from the remote client;

the management server configured to negotiate a point-to-point encryption scheme with a remote mobile device, the point-to-point encryption scheme negotiated between the management server and the remote mobile device;

the management server configured to receive a value identifying an intercept target for a legal intercept and an indication that interception is authorized by a warrant, the intercept target corresponding to the remote mobile device;

the management server configured to automatically intercept data received and/or sent by the intercept target identified by the value, wherein the data is intercepted without altering operation of email application services that operate on the remote mobile device;

the management server configured to inspect packets having the intercepted data to distinguish end-to-end encrypted information from other information that is encrypted according to the point-to-point encryption scheme negotiated with the remote mobile device;

the management server configured to preserve encryption that is included on the end-to-end encrypted information when received while removing encryption that is included on at least a portion of the other information, said other information decrypted using a key obtained during the point-to-point encryption scheme negotiation; and

the management server configured to transfer both the decrypted other information and the end-to-end information from the management server to a remote device.

18. The communication management system ofclaim 17, further comprising:

the management server configured to automatically format the intercepted data into log files;

the management server configured to generate multiple log files that identify any intercepted data for associated contiguous predetermined time periods extending over a continuous intercept period; and

the management server configured to generate the log files for back-to-back time periods, the management server further configured to generate each log file by selecting between inserting the intercepted data and an inactivity indication therein such that each of the log files contains at least one selected from the group comprising the intercepted data for the associated time period and an indication that no data was intercepted during the associated time period.

19. The communication management system ofclaim 18, further comprising:

the management server is configured to select a same duration for the time periods according to selectable time interval values included in an intercept configuration file.

20. The communication management system ofclaim 18, further comprising:

the management server configured to encrypt the log files according to an encryption key known by an enforcement agency associated with the warrant before emailing the encrypted log files to a mailbox for the enforcement agency.

21. The communication management system ofclaim 18, further comprising:

the management server configured to identify a first portion of the intercepted data encrypted using a first known security association for which the management server has knowledge of the encryption key and identify a second portion of the intercepted data encrypted using a second unknown security association, the management server configured to decrypt and store the first portion of the intercepted data into an associated one of the log files and combine the encrypted second portion of the intercepted data with the decrypted first portion of the intercepted data in the same associated log file.

22. The communication management system ofclaim 21, wherein the first portion of the intercepted data is encrypted with a known point-to-point encryption key and the second portion of the intercepted data is encrypted with an unknown end-to-end encryption key.

23. The communication management system ofclaim 21, further comprising:

the management server is configured to encrypt both the decrypted first portion of the intercepted data and the second encrypted portion of the intercepted data.

24. The communication management system ofclaim 21, wherein the first portion of the intercepted data includes transaction authentication and routing information and the second portion of the intercepted data includes the contents of email messages, electronic files, or other electronic data.

25. The communication management system ofclaim 17, wherein the management server is configured to process communications exchanged between a local device operating in an enterprise or local network and a mobile wireless device that synchronizes with a portion of the data in the local device.

26. A method for intercepting data, comprising:

in response to receiving a connection request, negotiating a point-to-point encryption scheme with a mobile device, the point-to-point encryption scheme negotiated between a management server and the mobile device;

automatically intercepting, at the management server, data received and/or sent by an intercept target, wherein data is intercepted without altering operation of application services on the mobile device;

inspecting packets having the intercepted data to distinguish end-to-end encrypted information from other information that is encrypted according to the point-to-point encryption scheme negotiated with the device;

preserving encryption that is included on the end-to-end encrypted information when received while removing encryption that is included on at least a portion of the other information, said other information decrypted using a key obtained during the point-to-point encryption scheme negotiation; and

transferring both the decrypted other information and the end-to-end information.

27. The method of claim 26, further comprising, receiving, at the management server, a value identifying the intercept target for a legal intercept and an indication that interception is authorized by a warrant, the intercept target corresponding to the mobile device.

28. The method of claim 26, wherein the packets are intercepted during a requested time period, and the method further comprises: formatting the data that is intercepted during the requested time period and associated with a target user into one or more first log files.

29. The method of claim 28, wherein: each of the first log files corresponding to a different time segment occurring during the requested time period and indicating one or more intercept events for its corresponding time segment.

30. The method of claim 29, further comprising:

formatting one or more second different log files associated with the requested time period, the second log files indicating inactivity and corresponding to different remaining time segments that occur during the requested time period and that are unrepresented by the first log files that indicate the intercept events such that the first and second log files record monitoring for the entire requested time period independently of whether the data is intercepted intermittently during the requested time period.

31. The method of claim 28, wherein the log files record an unbroken sequence of continuous monitoring over the requested time period independently of whether the data is intercepted intermittently.

32. The method of claim 28, further comprising formatting the log files with different time values usable for verifying that communications from the mobile device were continuously monitored during the requested time period regardless of whether the data was intercepted intermittently.

33. The method of claim 26, wherein the data is intercepted according to an intercept configuration file that includes at least a intercept identifier and a user ID identifying a target user.

34. The method of claim 26, wherein the encryption that is included on the end-to-end encryption information uses a security association that is kept secret from the management.

35. The method of claim 26, further comprising determining whether to encrypt at least one of the end-to-end information and the decrypted information prior to said transferring.

36. The method according to claim 26, further comprising:

combining the end-to-end encrypted information of the intercepted data with the decrypted other information of the intercepted data in a log file.

37. The method according to claim 26, further comprising:

storing the intercepted data in a structure format that identifies when the data was intercepted and provides authentication that the stored intercepted data has not been altered or deleted.

38. The method according to claim 26, further comprising monitoring communications between a remote client and the device for multiple contiguous time periods.

39. The method according to claim 38, further comprising:

generating log files over an intercept period that encompasses the multiple contiguous time periods;

storing the log files in a same intercept directory.

40. The method according to claim 39, further comprising:

inserting a warrant identifier received together with the value into the intercept directory; and

generating a name for the intercept directory that identifies the intercept target and the intercept period over which the log files were generated.

41. The method according to claim 39, further comprising:

encrypting the log files in the intercept directory with an encryption scheme known by an agency issuing the warrant, said encryption performed using the management server that intercepted the data; and

sending the encrypted intercept directory to an electronic mailbox accessible by the agency.

42. The method according to claim 39, further comprising:

generating a Cyclic Redundancy Check (CRC) or other digital signature value for all of the log files in the intercept directory;

encrypting the resulting generated value; and

providing the encrypted generated value to the enforcement agency, said encrypted generated value sent in a different communication than the encrypted intercept directory, said encrypted generated value verifying that the log files have not been altered.

43. The method according to claim 26, further comprising:

reading an intercept configuration file that contains a warrant identifier, the value identifying the user, an enforcement agency known encryption key and an electronic mailbox address;

upon reading the intercept configuration file automatically intercepting data received and/or sent by the remote mobile device;

formatting any intercepted data into log files that identify when the data was intercepted; and

encrypting the log files using the encryption key.

44. The method according to claim 26, wherein the end-to-end encrypted information is associated with content and is protected with an end-to-end encryption scheme that is kept secret from any midpoints located between transmitting and receiving endpoints, and the other information is associated with transaction routing information and is protected with the point-to-point encryption scheme.

45. A communication management system for intercepting data, comprising:

a processor;

a network interface configured to receive a connection request; and

a memory unit having instructions stored thereon, wherein the instructions, when executed by the processor, causes the communication management system to:

negotiate a point-to-point encryption scheme;

inspect packets having the data to be intercepted to distinguish end-to-end encrypted information from other information that is encrypted according to the point-to-point encryption scheme;

preserve encryption that is included on the encrypted information when received while removing encryption that is included on at least a portion of the other information, said other information decrypted using a key obtained in association with the point-to-point encryption scheme;

transfer both the decrypted other information and the end-to-end encrypted information;

automatically format the intercepted data into log files including:

generating log files that identify intercepted data for associated contiguous predetermined time periods extending over a continuous intercept period; and

generating the log files for back-to-back time periods, the management server generating each log file by selecting between inserting the intercepted data and an inactivity indication therein such that each of the log files contains at least one selected from the group including the intercepted data for the associated time period and an indication that no data was intercepted during the associated time period;

negotiate the point-to-point encryption scheme with a mobile device in response to receiving the connection request, and

intercept data received and/or sent by an intercept target, wherein data is intercepted without altering operation of application services on the mobile device.

Images